Геометрический канал и его компонентная архитектура. Распределенная модель системы управления

Реестр, DCOM, Реализация сервера в процессе, реализация сервера за пределами процесса. Пример реализации COM сервера на C++. Компонентная модель системы управления.

Связь программного обеспечения с физическими устройствами в системах автоматизации осуществляется с помощью методов DDE, OLE, COM, DCOM и OPC.

Технология обмена данными между приложениями Windows с аббревиатурой DDE (Dynamical Data Exchange - "динамический обмен данными") - появилась в 1987 г. вместе с Windows 2.0. В промышленной автоматизации DDE использовалась для обмена данными между SCADA в качестве DDE-клиента и физическим устройством, которое поставлялось с DDE сервером.

После появления OLE (Object Linking and Embedding - "связывание и внедрение объектов") фирмы Microsoft, а позже COM (Component Object Model - "модель многокомпонентных объектов") и DCOM (Distributed COM - "СОМ для распределенных систем") технология DDE была полностью вытеснена этими новыми средствами, которые оказались гораздо более эффективными.

Технология COM предоставляет средства для взаимодействия между разрозненными программными модулями, написанными на разных языках программирования, которые собираются в единую систему во время исполнения. Взаимодействие COM объекта с другими программами или программными модулями выполняется через программные интерфейсы c использованием метода "клиент-сервер".

Одной из составляющих COM является Automation - средства взаимодействия программ, написанных на С++ с программами на языке VBA (Visual Basic for Application) или Delphi, а также с программами на языках сценариев (VBScript, JScript). Благодаря автоматизации COM-объект может быть также размещен и исполняться на веб-странице.

Расширение COM в виде DCOM позволяет программам взаимодействовать между собой, даже если они исполняются на разных компьютерах локальной сети. Поэтому DCOM явилась универсальной программной технологией, которая как нельзя лучше позволяет осуществить взаимодействие между SCADA в качестве клиента и сервером, обеспечивающим интерфейс к аппаратным средствам промышленной автоматизации. Именно благодаря этому свойству DCOM была использована в качестве базы для разработки стандарта OPC - "OLE for Process Control" - "OLE для управления процессами", который лежит в основе всех современных SCADA пакетов, взаимодействующих с аппаратурой через OPC сервер.

Компонентный СОМ-подход поддерживает распределенную систему функционирования, когда модули системы СУ могут работать в разных потоках (threads) и разных системах, а также выступать в качестве СОМ-серверов (компонентов) и СОМ-клиентов. Традиционно коммуникационную среду системы СУ трактуют как некоторый набор интерфейсных API-функций (Application Program Interface functions, функции прикладного интерфейса) для обмена данными с ядром системы СУ, при этом общее число API-функций может достигать нескольких сот. При таком подходе, однако, любое изменение в архитектуре системы требует немалых усилий разработчиков. Таким образом, существующая ситуация состоите том, что API задает некоторый общий интерфейс подключения модулей в системе СУ, но не поддерживает их интеграцию. Решение проблемы следует искать в использовании продвинутых технологий фирмы Microsoft.

Посмотрим, как выглядит интерфейс Win32 API, обеспечивающий доступ к операционной системе Windows NT (рис. 14, а).

Непосредственный доступ осуществляется с помощью Win 32 API-функций. Более высокий уровень сервиса для доступах операционной системе обеспечивается с помощью классов библиотеки MFC, что уменьшает время разработки приложений. На базе объектов выстраивают СОМ (Component Object Model) и OLE (Object Linking and Embedding) механизмы третьего уровня, которые предполагают соответствующую структуру интерфейсов прикладных программ.

а) б)

Рис. 14. Модели прикладного интерфейса: а - интерфейс Win 32 API, обеспечивающий доступ к операционной системе Windows NT; б - интерфейс прикладных программ, обеспечивающий доступ к коммуникационной среде

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

Дата добавления: 2014-01-20