Компонентные технологии в системах промышленной автоматизации

Все разработчики приложений для систем SCADA (Supervisory Control and Data Acquisition) ощущали недостаток функциональных возможностей — ни один законченный продукт не может удовлетворить всех потребностей пользователей: из нескольких тысяч доступных графических объектов нет именно того, который нужен вам; ваш контроллер так экзотичен, что драйвера ввода/вывода именно для него не удается найти среди нескольких сотен драйверов, поставляемых разработчиком или третьими фирмами; алгоритм обработки настолько уникален, что именно его не предусмотрели в поставляемом комплекте. Это перечисление можно продолжать. Разработчики, принимая это во внимание, предлагают инструментальные средства, позволяющие разрабатывать драйверы ввода/вывода, создавать графические объекты и т.д. Однако реализация подобных компонентов часто требует профессиональных навыков программирования. А нельзя ли использовать модули, профессионально созданные кем-то и где-то? Зачастую необходимые решения уже имеются, и вопрос лишь в том, каким образом их использовать. Новые компонентные архитектуры, нашедшие свое отражение в таких технологиях для среды 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 для организации межпроцессного взаимодействия используется механизм локального вызова процедуры LPC (local procedure call) — средство связи между разными процессами на одной и той же машине, построенное по аналогии с удаленным вызовом процедуры RPC (remote procedure call), который отвечает за взаимодействие между процессами на разных машинах. Распределенная модель COM (DCOM - Distributed COM) использует именно RPC.

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

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

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

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

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

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

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

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

Безусловно, компонентная архитектура систем комплексной автоматизации существовала и до появления технологии COM/DCOM. Для организации сетевого взаимодействия использовались протоколы типа NetDDE или частные протоколы фирм-производителей. Например, компания Wonderware (www.wonderware.com) предложила протокол SuiteLink, который позволил принципиально преодолеть недостатки протокола DDE. COM/DCOM позволяет уйти от частных решений.

Так, в состав пакета FactorySuite2000 разработки Wonderware входит компонент InControl, ответственный за управление контроллерным оборудованием и процессами. Механизм взаимодействия между исполняющими системами InControl основан на технологии DCOM.

Многие распределенные приложения надо интегрировать в уже существующие на производстве сетевые инфраструктуры. Необходимость в специфическом сетевом протоколе повлекла бы обновление всех уже существующих компонентов. Однако DCOM поддерживает ряд транспортных распространенных протоколов, включая TCP/IP, UDP, IPX/SPX и NetBIOS. Поэтому использующие технологию DCOM пакеты комплексной автоматизации индифферентны к сетевым протоколам и позволяют с небольшими затратами наращивать существующие системы.

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

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

Технология ActiveX складывалась в течение нескольких лет; часто ее модернизация совпадала по времени с выпуском новых версий Microsoft Windows. Вспомним краткую историю технологий. Первоначальной целью разработки COM было желание сделать программные модули более гибкими и настраиваемыми, поддержав концепцию связывания и внедрения объектов (OLE, Object Linking and Embedding). Первая версия OLE для связи между клиентом и компонентом использовала аппарат динамического обмена данными (dynamic data exchange - DDE). В OLE 1 не было COM; технология DDE построена на основе архитектуры передачи сообщений Windows, он не очень надежен и гибок, не отличается хорошими скоростными характеристиками.

Но, начиная с DDE, Windows поддерживает открытые и стандартные методы для обмена данными. Используя DDE, приложения могут посылать и принимать данные от других приложений. DDE обеспечивает метод создания горячих связей (?hot links?), позволяющих одному приложению информировать другие приложения об изменении данных. Обмен данными происходит не непрерывно, а лишь по необходимости. Это делается для того, чтобы уменьшить привлекаемые ресурсы.

Еще одна важная концепция, введенная в DDE, — способность одного приложения выполнить команду в другом приложении. Благодаря этому одно приложение получило возможность управлять другим приложением. Позднее эта концепция нашла свое развитие в ActiveX automation.

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

Технология OLE 1.0 - первый шаг в направлении создания документа или контейнера, содержащего различные типы объектов. OLE 1.0 позволяла встраивать объекты в документ или связывать их с документом. В последнем случае связанный файл хранился отдельно. Например, электронная таблица Excel могла быть встроена в документ Microsoft Word. OLE 1.0 допускала естественное редактирование объекта. OLE 1.0 появился в эру Windows 2.x и 3.0.

OLE сопоставляет с каждым объектом два основных типа данных: визуальные (presentation data) и внутренние (native data). Объект может быть связан с некоторым документом или внедрен в него. Связывание (linking) - процесс, при котором в документ включаются только визуальные данные и ссылки на внутренние данные. Последние остаются связанными с объектом-источником, расположенным где-то в другом месте. Как только приложение обновляет объект, он обновляется и в документе. Связанный объект действует так, что пользователю кажется, будто он целиком включен в документ. Внедрение (embedding), напротив, приводит к физическому включению в документ как визуальных, так и внутренних данных объекта. В результате вся информация, необходимая для редактирования этого объекта, оказывается в документе.

Преодолением недостатков DDE, а, следовательно, и OLE 1.0, и стала технология COM, которая меньше, быстрее, гибче и надежнее DDE. Вторая версия OLE 2.0 (далее просто OLE) была написана именно с использованием COM. Объекты OLE 2.0 стали объектами COM. В OLE 2.0 введены важные концепции: идентификаторы Globally Unique Identifier, Object Presentation и OLE Automation.

GUID (Globally Unique Identifier), своего рода «серийные» номера для OLE-объектов позволяют OLE-объектам удовлетворять ключевому требованию: они могут быть уникально идентифицированы. Не может быть двух OLE-объектов с одинаковым номером.

OLE Automation (также называемый ActiveX Automation) позволяет приложениям выставлять объекты в другие приложения. OLE Automation делает возможным для объектов не только обмен данными и выполнение команд в другом объекте, но и определение элементов данных и команд в другом объекте.

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

Многие системы MMI поддерживают OLE технологию для встраивания OLE-объектов, разработанных третьими фирмами и, следовательно, расширяющими функциональные возможности SCADA-систем, а также для интеграции компонентов пакета.

Так, программный пакет InTouch компании Wonderware поддерживал спецификацию OLE еще с времен Windows 3.1. Система управления производством Wonderware InTrack снабжена средствами управления базой данных, оформленными как сервер OLE Automation. В текущей реализации этот сервер использует СОМ, чтобы выставлять объекты для манипулирования базой данных InTrack. InTouch-приложения могут быть использованы как клиенты для сервера InTrack OLE Automation. Для этого в приложении-клиенте определяются ссылки на объекты сервера InTrack OLE Automation. Когда в приложении-клиенте изменяется свойство объекта, то сервер InTrack информируется об изменении состояния.

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

Спецификация определила механизм обмена данными и функциями. Однако один ключевой элемент был упущен. Он касался способности объекта информировать приложение-контейнер о событии (event). Например, если объект OLE хотел предупредить контейнер о некотором событии, скажем, о нажатии клавиши на мыши, не было стандартного способа сделать это. Как признание этого ограничения аппарат OLE был расширен возможностью извещать о происшедших событиях. Соответствующий механизм, расширивший возможности взаимодействия между объектом и контейнером, был назван OLE control (OCX) или ActiveX control.

Изменения в терминологии совпали с ростом популярности Internet. ActiveX control позволяет эффективно использовать распределенную объектную серверную архитектуру Internet. Однако, хотя OCX были переименованы в ActiveX именно «в честь» Internet, было бы ошибкой ассоциировать ActiveX исключительно с Internet.

Последние версии MMI-систем интенсивно используют ActiveX, COM, DCOM. Так, компоненты компании Wonderware InTouch и InControl являются ActiveX контейнерами, а IndustrialSQL Server, InBatch и InTrack включают клиентские объекты как объекты ActiveX. Технология ActiveX представляет стандартный открытый метод для расширения возможностей приложений. Приложения InTouch и InControl могут легко расширять свои функциональные возможности, используя объекты ActiveX, предлагаемые IndustrialSQL Server, InBatch, InTrack.

Существуют три основных понятия, определяющих интерфейс и возможности взаимодействия объектов ActiveX с контейнерами: это Properties (данные), Methods (функции) и Events (события) (рис.4). Каждый из этих интерфейсов доступен из ActiveX Automation.

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

Methods - это функции, которые объект ActiveX представляет; они оперируют, в основном, на данных этого объекта. Функции являются другим типом интерфейса объекта ActiveX и используются контейнером для управления объектом.

Events — это методы, которые объект ActiveX использует, чтобы сообщить контейнеру о том, что произошло некоторое событие. Контейнер может затем информировать об этом пользователя или автоматически реагировать на возникшее событие.

Существует несколько путей, чтобы реализовать объект ActiveX. Такой объект играет роль сервера по отношению к контейнеру, являющемуся клиентом. Объекты ActiveX могут быть реализованы в двух основных формах: как встроенный в процесс (in-process) сервер и как сервер, исполняющийся в отдельном процессе (out-of-process). Этим двум формам соответствуют две реализации объектов ActiveX в виде динамических библиотек и в виде исполняемых модулей.

Чтобы описать разницу между двумя способами реализации, рассмотрим понятие пространства процесса. Пространство процесса - часть памяти, которая выделяется для определенного процесса. В Windows 95 и NT только операционная система и сам процесс имеют доступ к этому пространству. В Windows 3.x и более ранних версиях ОС любой процесс мог иметь доступ в любую память. Это приводило к ситуациям, когда процесс модифицировал память другого процесса, что сопровождалось фатальными ошибками защиты памяти (General Protection Fault). Концепция пространства процесса устранила возможность разрушения одним процессом памяти другого процесса, но усложнила возможности доступа к разделяемым данным. Для передачи данных из одного процесса в другой вводится механизм маршаллинга.

Поскольку встроенные объекты ActiveX размещаются в пространстве процесса контейнерного приложения, нет необходимости в использовании маршаллинга для организации передачи данных между приложением-контейнером и объектом ActiveX. Это уменьшает накладные расходы и увеличивает производительность. Существует ряд преимуществ в реализации объекта ActiveX как встраиваемого сервера. Главное преимущество - в достижении максимальной производительности за счет размещения объекта в пространстве контейнера. Другое преимущество состоит в возможности использования любым Automation клиентом, в том числе приложениями Microsoft Office.

Исполняемые ActiveX-объекты загружаются вне пространства приложения-контейнера. Поскольку не существует разделяемой памяти между этими приложениями, для передачи данных между объектом ActiveX и контейнером используется механизм маршаллинга. Его использование заметно увеличивает накладные расходы и заметно влияет на производительность. Соответственно для работы приложений требуется достаточно «приличная» аппаратная ПК-платформа.

Серверы OPC

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

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

Основная цель стандарта OPC (OLE for Process Control) заключается в определении механизма доступа к данным с любого устройства из приложений. ОРС позволяет производителям оборудования поставлять программные компоненты, которые стандартным способом обеспечат клиентов данными с ПЛК. При достаточном распространении данной технологии, OPC позволят определять на уровне объектов различные системы управления и контроля, работающие в распределенной гетерогенной среде; отпадет необходимость в использовании нестандартного оборудования и соответствующих коммуникационных драйверов; у потребителей появится больший выбор при разработке приложений.

Благодаря технологии OPC интеграция компонентов в гетерогенные системы становится чрезвычайно простой (рис. 5). Серверы OPC обеспечат стандартный способ передачи информации в программу визуализации, базы данных и т.д.

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

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

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

Метка времени и информация о качестве данных особенно важны для регистрации критических ситуаций (alarm) и архивирования данных. Так, IndustrialSQL Server, информационная основа пакета FactorySuite2000 позволяет сохранять информацию с меткой времени и качества. Метка времени может быть меткой ПЛК, если протокол взаимодействия с ПЛК поддерживает ее передачу, в противном случае «компьютерное» время записывается в метку времени. Системы SCADA обеспечивают два режима обмена с серверами OPC:

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

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

Ряд компаний, специализирующихся на разработке драйверов ввода/вывода, отдали предпочтение инструментарию независимого производителя — компании FactorySoft (www.factorysoft.com), предлагающей OPC Server Toolkit и OPC Client Toolkit для разработки серверов и клиентов OPC соответственно. Использование специализированных инструментальных средств значительно упрощает разработку OPC-компонентов, поскольку предлагают готовую реализацию OPC-интерфейса. Разработчику лишь необходимо добавить специализированный код, отражающий логику взаимодействия с конкретным ПЛК или сетевым протоколом.

Несмотря на то, что многие разработчики систем MMI предоставляют клиентские интерфейсы для серверов OPC, однако оценки скорости передачи больших объемов данных оставляют простор для дискуссии. Так, в информационных материалах компании Intellution публикуются результаты тестов, проведенных для локальных и удаленных серверов OPC. Так для конфигурации, обеспечивающей передачу 5000 элементов в секунду на компьютере с процессором Рentium/233 МГц в случае локального сервера загрузка центрального процессора составляет около 8%. Для удаленного сервера OPC загрузка процессора на стороне клиента составляет 7,5%, а на узле сервера - 9%.

В материалах компании Wonderware отмечается, что большинство реализованных серверов OPC создают для каждого подключаемого к серверу клиента новый канал связи (нить). Для текущей обработки каждого клиента сервер должен переключаться между нитями. Каждая нить использует механизм DCOM для организации обмена данными; DCOM также управляет переключением нитей. В итоге возможно снижение сетевой производительности.

Тесты, проведенные Wonderware, показали, что в случае, когда сервер OPC обслуживал 7 клиентов (при передаче 4 целых чисел в режиме обновления) сервер на 95% занимал ресурсы центрального процессора. Это означает, что ресурсы компьютера практически целиком были заняты переключением нитей и процедурами DCOM.

Поэтому на текущем этапе реализации технологий DCOM некоторые разработчики систем MMI предлагают «свои» решения для преодоления этих недостатков. Так, компания Wonderware предлагает свой протокол SuiteLink, основанный на TCP/IP. Параметры производительности протокола SuiteLink превосходят параметры текущей реализации DCOM. Поставляемый в комплекте FactorySuite (Wonderware) OPCLink Server обеспечивает прием информации с сервера OPC и передачу ее по протоколу SuiteLink в SCADA-систему InTouch и наоборот.

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

Надежда Куцевич (nak@rtsoft.ru) — сотрудник, компания RTSof, (Москва).