Все, имеющие дело с разработкой приложений для систем SCADA (Supervisory Control and Data Acquisition) ощущали недостаток заложенных функциональных возможностей. Ни один законченный продукт не может удовлетворить всех потребностей пользователей: из нескольких тысяч доступных графических объектов нет именно того, который нужен вам; ваш контроллер так экзотичен, что драйвера ввода/вывода именно для него не удается найти среди нескольких сотен драйверов, поставляемых разработчиком или третьими фирмами; ваш алгоритм обработки настолько уникален, что именно его не предусмотрели в поставляемом комплекте.

Это перечисление можно продолжать. Подобных требований не избежать при создании SCADA-приложений. Разработчики, принимая это во внимание, предлагают инструментальные средства, позволяющие разрабатывать драйверы ввода/вывода, создавать графические объекты и т.д. Однако реализация подобных компонентов часто требует профессиональных навыков программирования. А нельзя ли использовать модули, профессионально созданные кем-то и где-то? Зачастую необходимые решения уже имеются, и вопрос лишь в том, каким образом их использовать. Новые компонентные архитектуры, нашедшие свое отражение в таких технологиях для среды Windows, как СОМ/DCOM, OLE, ActiveX, предлагают способы организации взаимодействия и диктуют требования к использующим их программам.

Сам смысл аббревиатуры MMI за несколько лет претерпел значительные изменения. Раньше понятия пакетов промышленной автоматизации MMI (Man-Machine Interface) и SCADA были взаимозаменяемы, поскольку их основные функции совпадали. Различие состояло в том, что SCADA предполагает безопасные соединения с устройствами, распределенную обработку данных и сигналов тревоги, а главным аспектом MMI были графические возможности представления данных. В 1990-е годы посредством MMI стали обозначать информационную систему управления производством в целом — систему Managing Manufacturing Information.

Опирающиеся на стандарты компонентные технологии позволяют заменить сегодняшние уникальные решения стройной архитектурой взаимозаменяемых систем и устройств. Применение новых технологий позволит обеспечить совместимость и взаимозаменяемость устройств, систем управления и информационных систем. Разработчики современных систем MMI предусматривают возможность подключения к ним программных модулей OLE и ActiveX; в число механизмов взаимодействия компонентов MMI-систем входят COM/DCOM.

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

Компонентная объектная модель Microsoft

Основой многих новых компонентных технологий является модель Component Object Model, предложенная Microsoft. Естественно, в Windows предлагается максимальная поддержка COM-программирования, однако большая часть этого кода может быть реализована и на других платформах. Ряд компаний занимается переносом модели COM в другие распространённые операционные системы.

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

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

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

Распределенные компоненты

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

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

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

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

COM - спецификация, указывающая, как создавать динамически взаимозаменяемые компоненты. COM определяет стандарт, которому должны следовать компоненты и клиенты, чтобы обеспечить совместную работу. Компоненты COM состоят из исполняемого кода, распространяемого в виде динамически компонуемых библиотек DLL или EXE-файлов Win32. Но сама по себе динамическая компоновка не обеспечивает компонентной архитектуры. Компоненты COM объявляют о своем присутствии стандартным способом. Используя схему объявлений COM, клиенты могут динамически находить нужные компоненты.

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

Методы межпроцессного взаимодействия

В модели COM для организации межпроцессного взаимодействия используется механизм локального вызова процедуры (local procedure call, LPC). LPC - средство связи между разными процессами на одной и той же машине, построенное по аналогии с удаленным вызовом процедуры RPC (remote procedure call, RPC), который отвечает за взаимодействие между процессами на разных машинах. Распределенная модель COM (DCOM - Distributed COM) использует именно RPC.

LPC использует системные вызовы. Операционной системе известны физические адреса, соответствующие логическому адресному пространству каждого процесса, следовательно, ОС может вызывать функцию внутри любого процесса (рис.2). Но вызвать соответствующую функцию еще недостаточно — надо передать параметры функции из адресного пространства клиента в адресное пространство компонента. Для обозначения этого процесса в англоязычной литературе используется термин marshaling (от marshal - располагать, размещать или устанавливать в определенном порядке).

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

Клиент, которому необходимо взаимодействовать с компонентом в другом процессе, не может обращаться непосредственно к компоненту, но существует форма межпроцессного взаимодействия, поддерживаемого операционной системой. СOM обеспечивает это взаимодействие в прозрачном режиме, перехватывая вызовы от клиента и направляя их в компонент в другом процессе. Стандарт RPC определен OSF.

Когда клиент и компонент находятся на разных машинах, DCOM заменяет локальное межпроцессное взаимодействие сетевым протоколом. Ни клиент, ни компонент «не знают» о сети. Библиотеки COM обеспечивают объектно-ориентированный сервис клиенту и компоненту и используют механизмы RPC, чтобы генерировать стандартные сетевые пакеты.

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

Компонентная архитектура в системах MMI

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

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