книги / Микропроцессорные средства автоматизации энергетических систем. Сети автоматизации

граммирования, предназначенной для ввода программ в этот ПЛК. Первоначально компания Modicon использовала протокол для соединений «точка-точка» с ПЛК по интерфейсу EIA-232C (RS-232C). Хотя ограничения этого протокола достаточно очевидны, он используется и в настоящее время. Он привлекает простотой логики и независимостью от типа интерфейса. Данный протокол достаточно прост для понимания, и многие инженеры получили первый опыт работы именно с ним. Кроме того, он построен по принципу открытой системы, и пользоваться им можно бесплатно. Область применения этого протокола не ограничивается только промышленной автоматизацией. Modbus можно встретить и во многих других областях, включая системы автоматизации зданий, в электроэнергетике и т.д.

В 1984 году IEC приступила к разработке единого стандарта для полевой шины, определению требований для сети на производстве, устройств удаленного I/O, контроллеров, коммутаторов и т.п., удовлетворяющих условиям открытости. Основной целью было обеспечить согласованную работу узлов на всех уровнях системы. Внимание IEC привлек стандарт IEC 61158, который к моменту своего согласования уже сильно устарел как морально, так и технически и не был принят. Он был ориентирован на применение в химической и нефтехимической промышленности. Однако разработчики понимали: требования и области применения Fieldbus достаточно широки, единый объективный промышленный стандарт Fieldbus разработать в принципе невозможно, поэтому взяли курс на создание стандарта, способного поддержать многофункциональные решения в области промышленной связи для самых разных областей применения. В настоящее время IEC 61158-2 – многофункциональный стандарт, определяющий требования к сети во взрывоопасных отраслях производства (Profibus PA, Foundation Fieldbus Н1).

В 1987 году к конкурирующим разработкам спецификаций открытой СА подключилось Германское федеральное министерство по исследованиям и технологиям. Оно явилось инициатором проекта Fieldbus, к разработке которого впоследствии подключилась группа

41

специалистов из 13 компаний и 5 институтов. Основные усилия пред-

приняли компании Siemens, Bosch, Klockner-Moeller. Проект был ос-

нован на модели ISO/OSI, и в настоящее время мы его знаем под названием PROcess Field BUS (Profibus). Четырьмя годами позже проект былсертифицированвГермании, получивназваниеDIN 19245.

Фирмы WorldFIP и ISP Foundation начали разрабатывать единый стандарт для Fieldbus в 1992 году. После двух лет исследований, на определенном этапе разработок независимые ранее компании объединились, создав ассоциацию Fieldbus Foundation. Итогом их совместных разработок стал выход на рынок в 1996 году нового варианта полевой шины Fieldbus Foundation (FF), стандартом для физического уровня которой стал модифицированный стандарт IEC 1158-2.

К этому времени европейские разработчики и производители Fieldbus решили подвести итоги и создать единый европейский стандарт на физическом уровне (European Fieldbus Standard – EFS).

В результате обсуждений в EN 50170 вошли без изменений три на-

циональных Fieldbus-стандарта: Profibus, FIP (Factory Information Protocol, Франция) и P-NET (Pattern Network, Дания). В дальнейшем этот международный стандарт получил название CENELEC EN 50170, или Profibus DP.

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

ния – Actuator Sensor Interface (ASI). Цикл опроса – 31 узел за 5 мс.

Максимальный объем данных с одного ASI-узла – 4 бит. Однако, поскольку датчики и исполнительные устройства становятся все более интеллектуальными, применение ASI затормозилось.

История CAN-протокола началась в начале 1980-х годов, когда технология создания и эксплуатации современных транспортных средств потребовала установки на них большого числа датчиков, соединяемых в единую информационную сеть с замыканием на борто-

42

вом компьютере автомобиля. Компания Bosch (Германия) разработала для этой цели протокол CAN (Control Area Network), получивший статус международного стандарта ISO 11898. По своим характеристикам он удовлетворяет не только требованиям времени, но и реализует высокуюстепеньобнаруженияиисправленияошибочныхтелеграмм.

CANbus – это последовательная шина с децентрализованным доступом на основе модели CSMA/CM. Возможные коллизии, связанные с одновременным запросом шины, разрешаются на основе приоритетности передаваемых сообщений.

История развития этого протокола – яркий пример того, как не доведенная до конца работа по стандартизации приводит к появлению целого семейства не совместимых друг с другом протоколов. Дело в том, что развитие CAN остановилось на определении первых двух уровней OSI-модели. Появилось большое число разработок 7-го уровня для CAN, оформленных как самостоятельные прото-

кольные решения: SDS (Honeywell), DeviceNet (Allen Bradley), CAL (CiA-ассоциация), CAN11 (BMW), SeleCAN (Selectron), Kingdom (Kvaser), MiCAN (RMI) и несколько других. Ясно, что такая ситуация мало устраивает пользователей: им самим предлагается сделать выбор в пользу того или иного варианта CAN. При этом лидерами в этом семействе, безусловно, являются SDS и DeviceNet (США)

иСANopen и CAL (Европа).

Внастоящее время на рынке присутствуют более 50 различных полевых шин. Вместе с тем количество широко поддерживае-

мых шин невелико. В настоящее время главенствуют только

4платформы, а именно:

–CAN (DeviсeNet, CAL, CANopen, SDS, SAE J1939 и др.);

–Profibus (FMS, DP, PA, ASI, Profinet);

–NetLinx (Ethernet/IP, DeviсeNet, ControlNet);

–Foundation Fieldbus (Н1 + HSE).

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

43

лексов, управлении жизнеобеспечением (освещением, отоплением, вентиляцией и т.д.), в интегрированных системах безопасности (охранная и пожарная сигнализация, видеонаблюдение и доступ) и др. Появились и новые стандарты СА. Это технологии KNX/EIB, BacNet, C-Bus, SmartBus, LanDrive, DALI, Х10, Z-Wave идр. Данные сетевые стандарты перенимают лучшее из наработанного, но учитывают и требованияконкретныхсферприменения.

В последующих главах рассмотрим наиболее распространенные в настоящее время протоколы, стандарты и их основные спецификации.

1.3. ЗАКРЫТЫЕ И ОТКРЫТЫЕ СИСТЕМЫ

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

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

Открытой называется модульная система, которая допускает замену любого модуля на аналогичный другого производителя, имеющийся в свободной продаже по конкурентоспособной цене, а интеграция системы с другими системами (в том числе с пользователем) выполняется без преодоления чрезмерных проблем. Понятие открытости обсуждается на сайте OMAC (Open Modular Architecture Controls, www.omac.org).

44

Открытость можно рассматривать на разных уровнях иерархии программного и аппаратного обеспечения системы или ее составных частей. Открытыми, например, могут быть:

♦физические интерфейсы, протоколы обмена, методы контроля ошибок, системы адресации, форматы данных, типы организации сети, интерфейсы между программами, диапазоны изменения аналоговых сигналов;

♦пользовательские интерфейсы, языки программирования контроллеров, управляющие команды модулей ввода-вывода, языки управления базами данных, операционные системы, средства связи аппаратуры с программным обеспечением;

♦конструкционные элементы (шкафы, стойки, корпусы, разъемы, крепежные элементы);

♦системы, включающиевсебяперечисленныевышеэлементы. Под открытостью системы иногда понимают ее соответствие со-

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

Как следует из определения, необходимыми условиями открытости являются:

♦модульность;

♦соответствие стандартам (необязательно официальным, но обязательно общепринятым и легко доступным по цене, компенсирующей только затраты на его разработку, поддержку и распространение);

♦наличие в свободной продаже аналогичных систем других производителей(подсистем, модулей) поконкурентоспособнымценам.

Требование модульности вытекает из требования возможности замены части системы (т.е. модуля) аналогичными изделиями других производителей. Для этого система должна состоять из модулей.

45

Соответствие стандартам необходимо для обеспечения совместимости.

Наличие в свободной продаже и конкурентоспособность цен являются требованиями, вытекающими из практического аспекта: без выполнения этого условия открытая система может существовать только на бумаге.

Понятие открытости достаточно многогранно и не стандартизовано, поэтому на практике можно говорить только о степени открытости системы, указывая, что именно понимается под открытостью в каждом конкретном случае. Степень открытости можно оценить количеством реализованных признаков открытости.

Например, для SCADA-системы признаками открытости являются совместимость со стандартом ОРС, совместимость с широкодоступными компьютерами с различными ОС (желательно), совместимость с ActiveX, COM и DLL компонентами других производителей, поддержка языков стандарта МЭК 61131-3, наличие встроенного стандартного алгоритмического языка (например, Visual Basic) для реализации функций, которые невозможно осуществить другими средствами SCADA-пакета, возможность работы как с малым, так и с большим количеством тегов без необходимости переобучения обслуживающего персонала, возможность применения веб-браузера в качестве пользовательского интерфейса для увеличения количества подключаемых рабочих станций, наличие пользовательского интерфейса, аналогичного интерфейсам других производителей, совместимость со стандартными базами данных и другими приложениями (например, MS Office), расположенныминалюбыхкомпьютерахсети.

Для СА открытость означает наличие в свободной продаже сетевой аппаратуры от разных производителей по конкурентоспособным ценам, совместимой с открытыми стандартами.

Идеальным примером открытой системы является современный ПК. Огромное число производителей в разных странах изготавливают множество аппаратных и программных компонентов, которые можно собрать в единую систему, заменить один компонент на другой, нарастить функциональные возможности. Любой компонент

46

можно найти по достаточно низкой цене; отсутствуют производители, которые могли бы устанавливать монопольные цены.

Понятие открытости не подразумевает открытость программного кода, как, например, в ОС Linux. Хотя открытость кода позволяет добавлять в систему программные модули других производителей, что является признаком открытости. Однако открытость исходного кода существенно снижает надежность системы вследствие потенциальной возможности появления в ней дополнительных ошибок, внесенных во время модификации и компиляции, поэтому открытость программного кода является спорным признаком открытости системы.

В отличие от открытых, закрытые системы разрабатываются по внутренним стандартам отдельных предприятий. Части (модули) закрытых систем не могут быть заменены аналогичными изделиями других производителей, а заказчик, однажды применив закрытую систему, навсегда оказывается привязанным к ее разработчику.

Наиболее подробное и ясное изложение требований к контроллерам с открытой архитектурой дано в документе ISA, назы-

вающемся Requirements of Open Modular Architecture Controllers for Applications in the Automotive Industry («Требования к контроллерам с открытой модульной архитектурой применительно к автомобильной индустрии»). Во время его написания в 1994 году были распространены частно-фирменные решения. Это приводило к тому, что потребитель средств автоматизации, однажды купив изделие одной фирмы, попадал в ценовую зависимость от нее, поскольку интерфейсы средств автоматизации разных фирм были различными и их сопряжение резко увеличивало общую стоимость системы. Расширение такой системы было дорогим, а обслуживающий персонал должен был проходить дополнительное обучение работе с нестандартным оборудованием.

Разновидностью и предельным случаем открытых систем являются системы, удовлетворяющие идеологии Plug and Play («Включил, и заиграло (заработало)»), когда вообще не требуется усилий для конфигурирования или настройки модулей после их подключения

47

или замены на модули других производителей. Идеология Plug and Play существенно снижает требования к квалификации системных интеграторов, сокращает срок ввода системы в эксплуатацию, а также издержки потребителей натехническуюподдержку иэксплуатацию.

Итак, открытые системы должны обладать следующими положительными свойствами:

♦модульностью;

♦платформенной независимостью;

♦взаимозаменяемостьюскомпонентамидругихпроизводителей;

♦интероперабельностью (возможностью совместной работы)

скомпонентами других производителей;

♦масштабируемостью.

Отметим, что закрытые системы тоже могут быть модульными, интероперабельными, масштабируемыми. Отличие открытых систем состоит в том, что всеми перечисленными свойствами должны обладать компоненты, изготовленные разными производителями и имеющиесяв свободнойпродаже.

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

Модульность – это способность аппаратного или программного обеспечения к модификации путем добавления, удаления или замены отдельных модулей (компонентов) системы без воздействия на оставшуюся ее часть. Модульность обеспечивается при проектировании системы на архитектурном уровне. Базой для построения модульного ПО является объектно-ориентированное программирование. Главным достижением в направлении развития модульности ПО СА является выделение в нем независимых подсистем: программы

48

в ПЛК, OPC-сервера, баз данных, операторского интерфейса и алгоритмической части, реализуемой на языках стандарта IEC 61131-3, а также деление SCADA на серверную и клиентскую части.

Платформенная независимость – возможность выполнения программ на разных аппаратно-программных платформах, обеспечивающая независимость от поставщика этих платформ. Применение ОС Windows является одним из путей повышения открытости систем, поскольку эта ОС может быть установлена на максимальное число типов производимых компьютеров. В данном случае монополия фирмы MS компенсируется ее размерами и стабильностью. Платформенную независимость ПО и, как следствие, повышение открытости обеспечивает также язык Java, хотя он и уступает С++ по быстродействию приложений.

Для улучшения открытости при компиляции исполняемых модулей программ важно избегать «улучшений» компилятора, применения плагинов, надстроек, скачанных «откуда-то из Интернета», поскольку они могут сделать невозможным выполнение программы на других платформах.

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

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

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

49

ля, улучшить качество уже работающей системы, исключить ценовую зависимость от поставщика.

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

Интероперабельность труднодостижима, но она обеспечивает возможностьвыбора аппаратныхи программныхсредств из огромного разнообразия, представленного на рынке, вместо ограниченного выборакомпонентовмонопольногопроизводителязакрытойсистемы.

Открытая интероперабельная система должна обладать способностью коммуникации и с другими уровнями АСУ предприятия, обеспечивая одновременно безопасность поступающей извне информации.

Одним из методов обеспечения интероперабельности платформ Windows и Unix может быть применение стандарта CORBA.

Масштабируемость (наращиваемость) – возможность применения одного и того же аппаратного и программного обеспечения (баз данных, пользовательских интерфейсов, средств коммуникации) для систем разного размера (больших и малых). Для обеспечения масштабируемости достаточно, чтобы ПО больших и малых систем было совместимо по операторскому интерфейсу, языкам программирования, а также интерфейсу с аппаратными средствами и не требовало дополнительного обучения персонала. Масштабируемая система должна обеспечивать возможность простого наращивания функциональных возможностей и размеров путем включения новых компонентов как в аппаратную, так и в программную часть системы без модификации старых, опробованных программных и аппаратных модулей.

Масштабируемость позволяет применять одни и те же аппаратные и программные средства как для больших, так и для малых

50