Стадии создания системы телеизмерений и телеуправления:

проектирование, воплощение в железе, рассмотрение возможных проблем на пути реализации

(Обзорная статья для технических специалистов)

Наверняка большинство читателей сталкивались с проблемой совместимости оборудования и программного обеспечения даже на одном «самосборном» компьютере, не говоря о локальной сети своего предприятия, и знают, что некоторые «выкрутасы» бывает довольно сложно заставить работать так, как хочется конечному пользователю. Однако несмотря на сложности, это задача достаточно тривиальная: масса материалов в интернете почти на все случаи жизни как от профессионалов, так и от любителей. Обычный запрос о «симптомах» несовместимости железа или программного обеспечения, и вы можете разобраться если не во всех, то, по крайней мере, в большинстве возможных проблемных ситуаций. Поэтому мы попробуем рассмотреть эту тему внимательнее, с приближением к промышленным нуждам, и дадим, наверное, довольно очевидный (для тех специалистов, которые на личном опыте прошлись по всем этапам), но полезный материал. Всё-таки, согласитесь, гораздо эффективнее познакомиться с чьим-то опытом решения проблемы, чем на собственных ошибках…

Итак, мы с вами затронем ситуацию, которая может возникнуть у промышленных предприятий (и, возможно, не только у них), которым необходимо удаленно измерять показания приборов или управлять какими-либо собственными ресурсами при помощи автоматики. Сразу оговоримся, что удобнее всего (и далее речь будет идти именно об этом) управлять датчиками и исполнительными механизмами централизовано, когда они подключены к многофункциональному программируемому контроллеру, а сам контроллер имеет постоянное соединение с локальной сетью организации — для осуществления возможностей оперативного управления и диспетчеризации, хотя возможны и другие способы управления приборами, напрямую с пульта оператора. Пример одного из путей организации распределенной локальной сети был приведен в отдельной статье, поэтому останавливаться на этом вопросе мы не будем, выбор конкретной технической реализации оставим специалистам-проектировщикам, знающим возможности своих предприятий.

Для начала озвучим стоящие перед нами задачи по внедрению системы учета и управления ресурсами на удаленных друг от друга объектах, а потом разберем каждую из них более подробно:

  1. Закупить оборудование и ПО;
  2. Организовать телеизмерения и телеуправление на запланированных объектах;
  3. Обеспечить совместимость с уже работающим оборудованием и ПО;
  4. Развернуть центр удаленных измерений и управления (центр доступа).

Закупка оборудования и ПО

В первую очередь, на этом этапе закладываются затраты на необходимое и достаточное «железо», которое позволит нам осуществить все запроектированные возможности по дистанционному обслуживанию объекта. Все мы прекрасно понимаем, что для предприятия не всегда подходит вариант: «А закажем мы всё и сразу по максимуму, чтобы возможностей хватило на десять лет вперед!» Ограничителей для избыточного финансирования у хозяина предприятия, экономящего деньги и реально видящего перспективу дальнейшего развития, в этом случае будет сразу несколько:

  • неподъемная цена, обычно измеряемая десятками, а возможно, и сотнями миллионов рублей даже при закупке только необходимого оборудования (не говоря о максимуме);
  • время осуществления столь масштабной модернизации (даже силами нескольких подрядчиков не всегда удается уложиться в год-два);
  • отсутствие в нужном количестве обученных специалистов для осуществления квалифицированного технического обслуживания и управления системой;
  • заведомая избыточность, которая приводит к тому, что 90% возможностей никогда не будет использовано.

Так как предприниматели любят экономить деньги и обожают, когда специалисты предприятия максимально загружены, можно с уверенностью сказать, что надеяться на программу-максимум нельзя. Скорее всего, стоит рассчитывать на вариант с поэтапной, сильно растянутой во времени, модернизацией оборудования на объектах, да ещё и с полной загрузкой собственных технических специалистов (а как же, двойная выгода: и деньги можно сэкономить на услугах подрядчика, и собственные специалисты получат некоторые навыки монтажа и наладки!).

Совет технарям: постарайтесь убедить начальство в необходимости производства подрядчиками хотя бы шефмонтажа, с обязательным гарантийным обслуживанием оборудования на пару-тройку лет. Здравомыслящий владелец предприятия тоже не хочет лишних проблем, поэтому вам нужно лишь найти нужные аргументы! Это очень облегчит вашу жизнь — ведь оборудование, даже самое лучшее, всё равно иногда выходит из строя. Лучше первое время, пока вы не в полной мере освоили все возможности и особенности обслуживания нового железа, не жить с постоянной мыслью о том, что «вдруг, эта новая штуковина сломается, и что мы потом будем с ней делать?» Можно ведь не успеть разобраться с проблемой за время, отведенное внутренними регламентами на ремонт!

Имейте в виду, что уже на стадии выбора программно-аппаратного комплекса для специалистов организации должна быть чётко обрисована стратегия развития: либо для обеспечения совместимости нужно закупить то же самое оборудование, которое было когда-то давно установлено на объектах (и, например, пять лет назад морально устарело и даже было снято с серийного производства) — или совместимое с ним, либо выбрать вариант с закупкой более современного оборудования, возможно, не совместимого с ранее используемым, но менее дорогого и более функционального (технологии ведь не стоят на месте!). Тут целая дилемма: начальству следует выбрать приоритет — работа со старьём, которое нужно заказывать небольшими разовыми партиями и долго ждать поставки, либо — работа с малоизвестным оборудованием, но при этом придётся думать, что можно сделать для обеспечения совместимости хотя бы на уровне конечного пользователя.

Первая стратегия — делать всё единообразно — один из лучших вариантов, но только для случая, когда все работы по монтажу и наладке можно уложить в год-два. Неожиданностей она не несет и применима в небольших по длительности проектах.

Вторая стратегия, как нам кажется, более вероятная в современных условиях жизни, когда, допустим, появляется новый закон, требующий наличия таких специальных технических характеристик у контроллера или исполнительно-измерительного оборудования, которые всего лишь два года назад никому не были нужны из-за слишком высокой цены или из-за отсутствия необходимости заменять менее функциональные устройства (живым примером могут быть требования к точности вновь устанавливаемых приборов учета энергоресурсов для участия в торгах на новых рынках, принятые в 2006 году), а это означает, что новые контроллеры, исполнительные устройства, датчики и приборы учета могут оказаться несовместимыми с используемым ранее оборудованием и программным обеспечением.

Организация телеизмерений и телеуправления на объектах

Это, прежде всего, монтаж контроллера и сопутствующего оборудования, прокладка каналов связи на объекте, подключение датчиков и управляющих элементов к контроллеру, конфигурирование программного обеспечения и установка драйверов устройств, вывод контроллера в локальную сеть организации (настоятельно рекомендуем выделить для этого в сети закрытую группу IP-адресов, работать с контроллерами по строго определенным портам и не забыть при этом об авторизации с ведением подробных логов доступа).

На самом деле, всё это обычно делают сотрудники фирмы-изготовителя заказанного оборудования, не доверяя установку зачастую неподготовленному персоналу заказчика. На этом этапе специалисту рассматриваемого предприятия можно немного расслабиться и заняться изучением практической стороны работы нового оборудования, например, посетить специальные курсы завода-изготовителя по обучению премудростям технического обслуживания. Правда, скажем по секрету, гораздо полезнее бывает съездить вместе бригадой монтажников хотя бы на один из оснащаемых объектов и посмотреть, как это делают специально обученные люди, а заодно увидеть, с какими реальными проблемами установки и настройки они сталкиваются, какими способами их решают, какие эксплуатационные ограничения накладываются — ведь, при заключении договора представители предприятия-исполнителя обещает золотые горы и массу невероятных возможностей, а на самом деле, когда дело доходит до монтажа, предоставляют спецификацию на необходимое и достаточное оборудование, только чтобы выполнить задачи, поставленные в техническом задании (помните, что лучше заранее внести в проект все требования и указать их в условиях заказа обязательными к исполнению!).

Обеспечение совместимости оборудования и ПО, развертывание центра доступа

Обеспечение совместимости оборудования и ПО, а также развертывание центра удаленных измерений и управления объектами лучше всего будет осуществлять параллельно друг другу, заранее продумав общую для этих этапов техническую политику. Другими словами, ещё до этапа осуществления закупок оборудования нам следует выяснить, как именно мы будем осуществлять совместимость, какие программно-аппаратные средства для этого выберем, и как это будет выглядеть в жизни?

Один из путей решения — создание некоего основного сервера (условно назовём его центром доступа), на совместимость с которым мы и будем ориентироваться при разработке пользовательских приложений и диспетчерских АРМ. То есть этот сервер и его программное обеспечение — это будет наш эталон, к которому мы будем приводить всё остальное «несовместимое», и с которым будет работать все программное обеспечение операторов центра доступа.

Основное достоинство такого подхода в том, что какая бы ни была система управления установленным на объектах оборудованием, для каждой программно-аппаратной платформы она всё равно имеет пользовательский интерфейс и, в большинстве случаев, даже некоторые стандартные интерфейсы (и программно-аппаратные инструменты) обмена данными. Например, в контроллерах часто используют SQL-совместимые базы данных, web-интерфейсы для управления настройками и для ввода/вывода пользовательских данных. Конечно, на стадии выбора оборудования желательно отдать предпочтение тому железу, которое легче подстроится под нашу программно-аппаратную базу, не забывая, однако, о его стоимости и доступности.

Мы настоятельно рекомендуем начать проектирование сервера для центра доступа (выбор мощности, масштабируемости, программного обеспечения для него, а также поддерживаемых им протоколов обмена информацией и даже наличия необходимого количества COM-портов для подключения специфических «железяк» типа устройства синхронизации времени или GPRS-коммуникатора) до момента закупок остального оборудования, так как считаем, что наш эталон должен быть максимально приспособленным к работе с различными вариантами программно-аппаратных ресурсов. Говоря простым языком: очень желательно, чтобы наш сервер знал как можно больше протоколов и стандартных интерфейсов для обмена информацией, это в дальнейшем очень облегчит нам настройку совместимости во всей проектируемой системе.

Исходя из этого, проблему совместимости при дистанционных измерениях на разном оборудовании можно решить относительно простым способом — написать (либо заказать у производителя оборудования или разработчика программного обеспечения к нему) программы-конверторы из форматов документов, которые нам выдают различные контроллеры, в формат базы данных нашего эталонного сервера. Проверено на личном опыте — форматы эти обычно простые, стандартизованные (xml, html, sql БД и тому подобные), которые легко поддаются машинному разбору (наверно, тут более уместно применить программистскую фразу «поддаются парсингу»), так что даже силами одного-двух программистов из ИТ-отдела организации всего за одну неделю можно написать добротный конвертер-репликатор данных, задача которого — быть связующим звеном между эталоном-сервером и определенным типом контроллера. Таким образом, задача обеспечения съема измерений с удаленных несовместимых контроллеров решается относительно быстро и легко, а главное — последовательно, растянуто во времени! Ведь обновлять или писать новый конвертер нужно только при появлении нового типа оборудования, не совместимого с ранее установленным.

С удаленным управлением всё заметно интереснее и даже проще, особенно если заранее правильно выбрана программно-аппаратная конфигурация центрального сервера. Ведь все устройства дистанционного управления представляют собой не что иное, как переключатели, регуляторы и рубильники (это разделение, конечно, утрировано, для наглядности). Особых сложностей в непосредственном управлении ими (как в механике, так и в электронике) не возникает. Разве что придется ограничивать выбор устройств теми, которые «умеют» работать по сетевому протоколу, поддерживаемому контроллером (или одной из наших программ-конвертеров).

Сразу подчеркнем, что централизовать удаленное управление в сравнении с телеизмерениями несколько сложнее только из-за несговорчивого посредника — контроллера, который не предоставит просто так возможностей доступа к каждому устройству в отдельности. Можно провести параллели с работой web-сервиса в интернете: на чтение доступ дадут каждому желающему, а на запись и управление ресурсом — только избранным. То есть для телеуправления понадобится и авторизованный доступ более высокого (администраторского) уровня, и, возможно, специализированное программное обеспечение от завода-изготовителя, с продажи и внедрения которого завод зарабатывает дополнительные деньги.

Выходов из положения целых два:

  • Разработка (самостоятельная или совместно с предприятием-изготовителем) программного обеспечения, позволяющего производить управление из центра доступа различными типами контроллеров. Надо сказать, что кроме разработки в этом случае потребуется периодическая модернизация ПО для работы с каждым новым контроллером, применяемым на объектах предприятия. Плюсами такой разработки являются, во-первых, максимальная оптимизация и интеграция существующего программно-аппаратного комплекса, а во-вторых, невысокая стоимость создания и внедрения (но не для всех возможных случаев). А минусом может стать большая длительность создания специализированного ПО — «неповоротливость» при освоении управления новыми устройствами.
  • Применение мощных программных продуктов класса MMI/SCADA (например, Пирамида, Энергоресурсы, ClearSCADA, Elipse и им подобные), которые поддерживают сотни типов исполнительных устройств и контроллеров, и постоянно обновляются с выходом новых модификаций оборудования. Самый очевидный и приятный плюс SCADA — возможность применения практически любых доступных на рынке исполнительных устройств и контроллеров, а также скорость появления обновлений драйверов и программного обеспечения для поддержки самых свежих железок. Минусом в этом варианте будет довольно высокая стоимость комплекса, настройки его под нужды организации и, возможно, даже обновления до самой новой версии.

Подведем итог

Хотелось бы объяснить, почему в этой статье мы не стали максимально конкретно описывать путь построения, настройки и обеспечения совместимости всего того «зоопарка» оборудования, установленного на определенном предприятии. Нам кажется, что этого и не нужно в обзорном материале, так как сам по себе он имеет небольшую ценность без реального технического воплощения. На самом деле, для технических специалистов обычно достаточно указать путь, дать несколько названий (оборудования, программного обеспечения, протоколов связи и тому подобного), типичных для реализации задачи, и они сами придумают наиболее оптимальный вариант воплощения идеи для своей организации. Мы можем лишь пожелать им всяческих успехов в этом!




17 октября 2007 Г.

: , ,

:

, ,

( )

, , , , . , : , . , , , , . , , , , ( , ), . -, , - , …

, , (, , ), - . , ( ) , , — , , . , , -, .

, :

  1. ;
  2. ;
  3. ;
  4. ( ).

, , . , : , ! , , :

  • , , , ( );
  • ( -);
  • ;
  • , , 90% .

, , , - . , , , , ( , : , !).

: , - . , ! — , , . , , , , , ? , !

, - : , - (, , ) — , , , , ( !). : — , , — , , .

— — , , -. .

, , , , , , - , - - ( , 2006 ), , , , .

, , , , , , ( IP-, ).

, - , . , , - . , , , , , , , — , - , , , , , (, !).

,

, , . , , , - , ?

— ( ), . — , «», .

, , - , , ( - ) . , SQL- , web- / . , , - , , , .

( , , , COM- GPRS-) , , - . : , , .

, — ( ) - , , . — , (xml, html, sql ), (, ), - - - , — - . , , — , ! , .

, - . , , ( , , , ). ( , ) . , , ( -).

, - — , . web- : , — . () , , , -, .

:

  • ( -) , . , , . , -, - , -, ( ). — «» .
  • MMI/SCADA (, , , ClearSCADA, Elipse ), , . SCADA — , . , , , .

, , , . , , . , , (, , ), , . !