ЦП Автоматизированные системы управления и промышленная безопасность

ActiveX - технология Microsoft, предназначенная для написания сетевых приложений. Она предоставляет программистам наборы стандартных библиотек, значительно облегчающих процесс кодирования. Если раньше при написании программ использовались механизмы OLE (OLE Automation, OLE Documents, OLE Controls,...), основанные на компонентной объектной модели (COM - Component Object Model), то теперь библиотеки OLE переписаны так, чтобы обеспечивать функциональность, достаточную для написания сетевых приложений. Таким образом, теперь при написании программ используется DCOM (Distributed Component Object Model) - распределенная компонентная объектная модель, а реализуют ее библиотеки ActiveX, которые по объему оказались гораздо меньше, чем библиотеки OLE, а по скорости - быстрее. Сохранилась и совместимость - любой программный компонент OLE будет работать с библиотеками ActiveX.
Основные преимущества использования технологии ActiveX :
1) Ускорение написания программного кода. Программирование распределенных приложений становится очень похожим на программирование для отдельного компьютера. 
2) Стандартность. Технология ActiveX основана на широко используемых стандартах Internet (TCP/IP, HTML, Java) и стандартах, введенных в свое время Microsoft и необходимых для сохранения совместимости (COM, OLE). 
3) Открытость и переносимость. ActiveX является открытой технологией. Кроме того, Microsoft заканчивает реализацию технологий ActiveX для платформ Macintosh и UNIX. 
4) Возможность написания приложений с использованием знакомых средств разработки. Программные элементы ActiveX могут быть созданы с помощью Visual Basic, Visual C++, Borland Delphi, Borland C++, любых средств разработки на Java. 
5) Большое количество уже существующих программных элементов ActiveX, которые бесплатно могут применяться на серверах Web и в приложениях независимых разработчиков. Кроме того, почти 
любой программный компонент OLE совместим с технологиями 
ActiveX, и может применяться без модификаций в сетевых 
приложениях. 
Существует два основных способа реализации 
ActiveX-компонентов: 
1) встроенные в процесс (единое пространство памяти позволяет увеличить быстродействие); 
2) выполняемые в отдельном процессе (возможна организация распределенной архитектуры). 

Виды специализированных языков:
1.Языки для работы с базами данных:
а)Языки, входящие в состав промышленных клиент-серверных систем управления базами данных.(СУБД) (PL-SQL в СУБД Oracle, Transact-SQL в Microsoft SQL Server) 
б)Языки являющиеся частью других видов СУБД (Visual FoxPro, Microsoft Access, Paradox и т.п.) 
2. Языки предназначенные для web-программирования.
а) Языки, исполняющиеся на сервере, поддерживающего Web-сайт.(РНР, Perl, VBScript)
б) Языки, исполняющиеся на браузере (программе просмотра) клиента JavaScript, JScript, VBScript
3.Языки для математических расчетов
4.Языки для автоматизации работы определенных программных продуктов. (VBA в Microsoft Office)
6.Специализированные языки других видов.
К универсальным языкам можно отнести языки Visual C++, Visual C++.Net, Visual C#.Net, Visual J#.Net, Java, Delphi, Borland C#, Borland C++ Builder.
Хотя чаще всего специализированные языки происходят от универсальных языков например PHP, Perl и JаvаScript произошли от языка С++, VBScript и VBA произошли от языка Visual Bаsic'а, отличия между специализированными и универсальными языками очень значительны.
Языки программирования для инженеров по автоматизации (графические) 
LD — Язык релейных схем
FBD — Язык функциональных блоков
SFC — Язык диаграмм состояний — программирование автоматов
CFC — Не сертифицирован IEC61131-3, дальнейшее развитие FBD
Языки для программистов ПЛК (текстовые) 
IL — Ассемблер
ST — Паскале-подобный язык

OPC (OLE for Process Control) — технология связывания и внедрения объектов для систем промышленной автоматизации. Технология OPC определяет способ обмена данными между двумя программами на ПЭВМ под управлением ОС Windows. Разработана международной организацией OPC Foundation как промышленный стандарт для взаимодействия программ, обслуживающих комплексы телемеханики разных производителей. Опубликована спецификация OPC — набор документов, определяющий правила для реализации взаимодействия.

Технология OPC определяет 2 класса программ: ОРС-сервер (OPC server), непосредственно взаимодействующий с аппаратурой телемеханики, и ОРС-клиент (OPC client), получающий данные от ОРС-сервера для дальнейшей обработки и передающий в ОРС-сервер команды управления.
Используя спецификацию ОРС, производитель аппаратных средств имеет возможность разработать программу-сервер, обеспечивающую доступ к данным программам–клиентам различных производителей программного обеспечения. В свою очередь, производители ПО имеют возможность получать данные для обработки от нескольких различных систем по стандартному интерфейсу.
Структурная схема взаимодействия между аппаратурой, серверными и клиентскими программами:

Как видно из схемы, программа ОРС-сервер выполняет непосредственное взаимодействие с аппаратурой, используя аппаратные интерфейсы компьютера. ОРС-cервер обеспечивает сбор данных, передачу команд управления, диагностику каналов связи и т.д. OPC-сервер создает программные интерфейсы, обеспечивающие доступ к данным.
Программа OPC-клиент получает данные через интерфейс сервера и выполняет их комплексную обработку — использует для визуализации, строит графики, выводит на печать, сохраняет на диске и т.д. 
Программы могут взаимодействовать по технологии ОРС как на одной и той же ПЭВМ, так и на разных, взаимодействуя через локальную сеть (при этом ОРС-сервер должен работать под ОС класса Windows NT).

Технология OLE (Object Linking and Embedding) ― технология управления и обмена информацией между программным интерфейсом других приложений. Связывание и внедрение объектов (Object Linking and Embedding). 
OLE позволяет передавать часть работы от одной программы редактирования к другой и возвращать результаты назад. Например, установленная на персональном компьютере издательская система может послать некий текст на обработку в текстовый редактор, либо некоторое изображение в редактор изображений с помощью OLE-технологии.
Основное преимущество использования OLE (кроме уменьшения размера файла) в том, что она позволяет создать главный файл, картотеку функций, к которой обращается программа. Этот файл может оперировать данными из исходной программы, которые после обработки возвращаются в исходный документ.
OLE используется при обработке составных документов (англ. compound documents), может быть использована при передаче данных между различными несвязанными между собой системами посредством интерфейса переноса (англ. drag-and-drop), а также при выполнении операций с буфером обмена. Идея внедрения широко используется при работе с мультимедийным содержанием на веб-страницах (пример — Веб-ТВ), где используется передача изображение звука, видео, анимации в страницах HTML (язык гипертекстовой разметки) либо в других файлах, также использующих текстовую разметку (например, XML и SGML). Однако, технология OLE использует архитектуру «толстого клиента», то есть сетевой ПК с избыточными вычислительными ресурсами. Это означает, что тип файла либо программа, которую пытаются внедрить, должна присутствовать на машине клиента. Например, если OLE оперирует таблицами Microsoft Excel, то программа Excel должна быть инсталлирована на машине пользователя.
OLE 1.0 был выпущен в 1990 году на основе технологии DDE (Dynamic Data Exchange), использовавшейся в более ранних версиях операционной системы Microsoft Windows. В то время как технология DDE была сильно ограничена в количестве и методах передачи данных между двумя работающими программами, OLE имел возможность оперировать активными соединениями между двумя документами либо даже внедрить документ одного типа в документ другого типа.
OLE сервера и клиенты взаимодействуют с системными библиотеками при помощи таблиц виртуальных функций (англ. virtual function tables, VTBL). Эти таблицы содержат указатели на функции, которые системная библиотека может использовать для взаимодействия с сервером или клиентом. Библиотеки OLESVR.DLL (на сервере) и OLECLI.DLL (на клиенте) первоначально были разработаны для взаимодействия между собой с помощью сообщения WM_DDE_EXECUTE, разработанного операционной системой.
OLE 1.1 позднее развился в архитектуру COM (component object model) для работы с компонентами программного обеспечения. Позднее архитектура COM была преобразована и стала называться DCOM.
Когда объект OLE помещен в буфер обмена информацией, он сохраняется в оригинальных форматах Windows (таких как bitmap или metafile), а также сохраняется в своём собственном формате. Собственный формат позволяет поддерживающей OLE программе внедрить порцию другого документа, скопированного в буфер, и сохранить её в документе пользователя.
Следующим эволюционным шагом стал OLE 2.0, сохранивший те же цели и задачи, что и предыдущая версия. Но OLE 2.0 стал надстройкой над архитектурой COM вместо использования VTBL. Новыми особенностями стали автоматизация технологии drag-and-drop, in-place activation и structured storage.

DDE — давний и прижившийся протокол обмена данными между разными приложениями, появившийся еще на заре эры Windows. С тех пор на его базе был создан интерфейс OLE, а в 32-разрядном API Windows появились и другие методы межпрограммного взаимодействия. Но ниша, занимаемая DDE, осталась неизменной — это оперативная передача и синхронизация данных в приложениях.
Приложения, использующие DDE, разделяются на две категории — клиенты и серверы (не путать с одноименной архитектурой СУБД). Оба участника процесса осуществляют контакты (conversations) по определенным темам (topic), при этом в рамках темы производится обмен элементами данных (items). Устанавливает контакт клиент, который посылает запрос, содержащий имена контакта и темы. После установления контакта всякое изменение элемента данных на сервере передается данным клиента. Подробно функции DDE описаны в [4].
Первоначально программирование DDE было чрезвычайно сложным делом — оно требовало взаимосвязанной обработки более чем десяти сообщений Windows. В версии Windows 3.1 появилась библиотека DDEML, которая перевела управление DDE на уровень вызова процедур. Разработчики подсистемы DDE в Delphi, верные идеологии создания VCL, свели интерфейс этого протокола к четырем компонентам — двум для сервера и двум для клиента.
Обмен данными по протоколу DDE состоит из трех этапов:
• установка соединения
• собственно обмен данными
• разрыв соединения
Каких-то особенностей, характерных именно для протокола DDE, здесь, как видите, нет: можно легко провести параллели между протоколом DDE и файлами (открытие, работа, закрытие), между протоколом DDE и протоколом TCP (установка соединения, обмен данными, разрыв соединения) и т.д. В процессе установки соединения один из участников является его инициатором (в терминологии DDE - клиентом), а второй находится в постоянной готовности к установке соединения (в терминологии DDE - сервер). И сервер, и клиент - это некие приложения (упрощенно - *.exe-файлы), запущенные на одном или на разных компьютерах, хотя одно и то же приложение в принципе может являться одновременно и сервером, и клиентом протокола DDE (пример такого приложения - электронные таблицы Microsoft Excel). Со стороны клиентского приложения каких-либо предварительных действий в протоколе DDE делать не требуется, а вот серверное приложения должно сначала зарегистрироваться в Windows в качестве сервера протокола DDE. Если этого не сделать, клиент DDE не сможет подсоединиться к серверу. Сервер DDE при регистрации сообщает Windows то имя, под которым он будет "известен" на данном компьютере. В терминологии DDE это имя называется Application. Разработчики DDE-серверов обычно стараются сделать это имя совпадающим с именем самого приложения, например Application-имя упомянутых выше таблиц Microsoft Excel - "EXCEL", DDE-сервер системы Intouch имеет имя "VIEW" и т.д. В принципе, имя для своего DDE-сервера можно задавать любое, лишь бы оно вписывалось в традиционные понятия об имени (латинские буквы, цифры, знаки подчеркивания) и имело длину не более 8 символов. Именно по этому имени и будет подсоединяться к серверу клиент DDE-протокола.

При рассмотрении стоимостных характеристик необходимо учитывать особенности компонентов SCADA и требования к ним в зависимости от выбранной архитектуры АСУ. В рамках принятой нами архитектуры (распределенная двухуровневая АСУ) предполагаемая система управления должна иметь станцию оператора с возможностью визуализации ТП и архивирования данных на верхнем уровне и около десятка контроллеров на нижнем уровне.
Такой комплект предусматривает наличие как минимум двух компонентов SCADA-системы: для верхнего уровня и для нижнего уровня. Используя данные фирм-разработчиков отечественных пакетов по состоянию на осень 2004 г. [1–7] имеем следующую картину стоимости двухкомпонентных SCADA-систем, отраженную в таблице 1. В этой таблице учитывается только стоимость компонентов SCADA-систем без стоимости используемых операционных систем.
Эксплуатационные характеристики
Эксплуатационные характеристики SCADA-системы имеют большое значение, поскольку от них зависит скорость освоения продукта и разработки прикладных систем. Они в конечном итоге отражаются на стоимости реализации проектов.
Удобство использования. Следует отметить, что сервис, предоставляемый SCADA-системами на этапе разработки прикладного ПО, обычно очень высок это вытекает из основных требований к таким системам. Почти все они имеют Windows-подобный пользовательский интерфейс, что во многом повышает удобство их использования, как в процессе разработки, так и в период эксплуатации прикладной задачи.
Наличие и качество поддержки. Необходимо обращать внимание не только на наличие технической поддержки SCADA-систем, как таковой, но и на ее качество. Для зарубежных систем в России возможны следующие уровни поддержки: услуги фирмы-разработчика; обслуживание региональными представителями фирмы-разработчика; взаимодействие с системными интеграторами. Судя по большому количеству установок зарубежных систем, исчисляющихся в тысячах (InTouch 80000, Genesis 30000), можно предположить, что поддержка этих системдостаточно эффективна.
Русификация. Любая система управления, имеющая интерфейс с оператором, должна допускать возможность общения с человеком на его родном языке. Поэтому крайне важна возможность использования в системе различных шрифтов кириллицы, ввод/вывод системных сообщений на русском языке, перевод документации, различных информационных материалов. Для некоторых систем (Image, Trace Mode) эта проблема вообще отсутствует, так как они разрабатывались отечественными фирмами. Для многих зарубежных продуктов проблема русификации в значительной мере снимается, во всяком случае, для подсистем исполнения или подсистем исполнения (RunTime), если они используют наборы шрифтов Windows. Часть зарубежных систем имеют переводы документации на русский язык (InTouch). Нужна ли русифицированная среда разработки? Положительный ответ не очевиден. Но если да , то среда, обязательно протестированная и рекомендованная фирмой-разработчиком. Так как с технической точки зрения проблем с русификацией нет (использование редакторов ресурсов из любой среды разработки Borland C++, Visual C++), то проблема лишь в легитимности этой процедуры. 

Программно-аппаратные платформы, на которых реализована SCADA-система. Анализ перечня таких платформ необходим, поскольку от него зависит ответ на вопросы распространения SCADA-системы на имеющиеся вычислительные средства, а также оценка стоимости эксплуатации системы (прикладная программа, разработанная в одной операционной среде, может выполняться в любой другой, которую поддерживает выбранный SCADA-пакет). В различных SCADA-системах этот вопрос решен по разному.
Подавляющее большинство SCADA-систем реализовано на платформах MS Windows. Именно такие системы предлагают наиболее полные и легко наращиваемые человеко-машинные интерфейсные (Man Machine Interface MMI) средства. Учитывая продолжающееся усиление позиций Microsoft на рынке операционных систем (ОС) следует отметить, что даже разработчики многоплатформных SCADA-систем, такие как United States DATA Co, приоритетным считают дальнейшее развитие своих SCADA-систем на платформе Windows NT. Некоторые фирмы, до сих пор поддерживавшие SCADA-системы на базе ОС реального времени (РВ), начали менять ориентацию, выбирая системы на платформе Windows NT. Все более очевидным становится применение ОС реального времени, в основном, во встраиваемых системах. Таким образом, основным полем, где сегодня разворачиваются главные события глобального рынка SCADA-систем, стала ОС MS Windows NT на фоне всё ускоряющегося сворачивания активности в области MS DOS, MS Windows 3.xx/95.
Имеющиеся средства сетевой поддержки. Одна из основных особенностей современного мира систем автоматизации высокая степень интеграции этих систем. В любой из них могут быть задействованы объекты управления, исполнительные механизмы, аппаратура, регистрирующая и обрабатывающая информацию, рабочие места операторов, серверы баз данных и т.д. Очевидно, что для эффективного функционирования в этой разнородной среде SCADA-система должна обеспечивать высокий уровень сетевого сервиса. Желательно, чтобы она поддерживала работу в стандартных сетевых средах (ARCNET, ETHERNET и т.д.) с использованием стандартных протоколов (NETBIOS, TCP/IP и др.), а также обеспечивала поддержку наиболее популярных сетевых стандартов из класса промышленных интерфейсов (PROFIBUS, CANBUS, LON, MODBUS и т.д.) Обобщенная схема подобной системы приведена на рис.1.
Встроенные командные языки. Большинство SCADA-систем имеют встроенные языки высокого уровня, VBasic-подобные языки, позволяющие сгенерировать адекватную реакцию на события, связанные с изменением значения переменной, с выполнением некоторого логического условия, с нажатием комбинации клавиш, а также с выполнением некоторого фрагмента с заданной частотой относительно всего приложения или отдельного окна.
Поддерживаемые базы данных. Практически все SCADA-системы, в частности, Genesis, InTouch используют синтаксис ANSI SQL, который не зависит от типа базы данных. Таким образом, приложения виртуально изолированы, что позволяет менять базу данных без серьезного изменения самой прикладной задачи, создавать независимые программы для анализа информации, использовать уже наработанное программное обеспечение, ориентированное на обработку данных.
Графические возможности. Для специалиста-разработчика системы автоматизации, также как и для специалиста- технолога , чье рабочее место создается, очень важен графический пользовательский интерфейс (Graphic Users Interface MMI). Функционально графические интерфейсы SCADA-систем очень похожи. В каждой из них существует графический объектно-ориентированный редактор с определенным набором анимационных функций. Используемая векторная графика дает возможность осуществлять широкий набор операций над выбранным объектом, а также быстро обновлять изображение на экране, используя средства анимации.

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