Главная Пресс-центр Статьи и публикации Программное обеспечение систем контроля и управления и Windows-технологии, "Мир Компьютерной Автоматизации", N 3, 1999

Программное обеспечение систем контроля и управления и Windows-технологии, "Мир Компьютерной Автоматизации", N 3, 1999

Куцевич Н. А., Жданов А. А., ЗАО «РТСофт», Москва

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


Рис.1 Обобщенная схема системы контроля и управления


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

сущность новых, предложенных компанией Microsoft, технологий (COM/DCOM, ActiveX, OPC);

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

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

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

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

Новые технологии в современных системах

Практически на любом уровне схемы (рис. 1) возможно применение технологий, предложенных Microsoft — COM (Component Object Model), ActiveX-объекты, OPC технологий. Возможность использования определяется выбираемыми базовым и инструментальным программным обеспечением.


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

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

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


Рис.2 Компоновка нового приложения


Распределенные компоненты. С возрастанием производительности и общего значения сетей потребность в приложениях распределённых по различным узлам сети/сетей будет обостряться. Компонентная архитектура позволяет упростить процесс разработки подобных распределенных приложений. Приложения клиент-сервер — это шаг в сторону компонентной архитектуры, поскольку они разделены на 2 части, клиентскую и серверную.

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

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

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

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

Методы межпроцессной коммуникации. Существуют методы межпроцессной коммуникации, включая DDE, именованные каналы, разделяемую память. Однако COM использует локальный вызов процедуры (local procedure call, LPC). LPC — это средство связи между разными процессами на одной и той же машине, построенное на основе RPC (remote procedure call) — удаленного вызова процедур. С помощью разнообразных сетевых протоколов RPC обеспечивает коммуникацию между процессами на разных машинах. Распределенная модель COM (DCOM — Distributed COM) использует RPC для связи по сети.

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

Но вызвать соответствующую функцию еще недостаточно. Необходимо передать параметры функции из адресного пространства клиента в адресное пространство компонента. Этот процесс называется маршалингом (от marshaling; marshal — располагать, размещать или устанавливать в определенном порядке).

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

Клиент, которому необходимо взаимодействовать с компонентом в другом процессе, не может обращаться непосредственно к компоненту, но существует форма межпроцессного взаимодействия, поддерживаемого ОС. СOM обеспечивает эту коммуникацию в прозрачном режиме. Он перехватывает вызовы от клиента и направляет их в компонент в другом процессе. Рисунок 4 показывает, как библиотеки времени выполнения (run-time) COM/DCOM обеспечивают связь между клиентом и компонентом. Стандарт RPC определен OSF (OPEN Software Foundation) в спецификации DCE (Distributed Computing Environment) RPC.

Когда клиент и компонент находятся на разных машинах, DCOM заменяет локальную межпроцессную коммуникацию сетевым протоколом. Ни клиент, ни компонент «не знают» о сети. Следующий рисунок (рис.5) показывает DCOM архитектуру. COM- библиотеки исполнения (run time) обеспечивают объектно-ориентированный сервис клиенту и компоненту и используют RPC и Security provider, чтобы генерировать стандартные сетевые пакеты, которые соответствуют DCOM-сетевым протокольным стандартам.

Приложения компонентной архитектуры не ограничиваются более рамками одной машины. Причем прозрачный механизм расширения приложений компонентной архитектуры распространяется на Internet. DCOM, встраивается в ОС Windows NT 4.0.

Приложение, компоненты которого взаимодействуют по принципу «n-tier» — равный с равным — ответственно за управление технологическим процессом в реальном времени, визуализацию, выборку информации. Вышеуказанные операции реализуются на разных машинах, соединенных в сеть, причем в узлах размещаются исполняющие системы, ответственные за взаимодействие с контроллерами, за визуализацию информации, за регистрацию данных, за систему управления ресурсами предприятия.

ActiveX-объекты. Одной из реализаций интерфейсов COM/DCOM является создание управляющих компонент ActiveX. Разработчики приложений на Visual Basic, C, C++, Java, SCADA ( (Supervisory Control and Data Acquisition))-систем могут воспользоваться управляющими элементами ActiveX для ускорения разработки своих приложений, для использования опыта программистов, работающих на разных языках и различных платформах. Три основных понятия, определяющие несложный интерфейс — это Properties (данные), Methods (функции) и Events (события) (рис.6), наличие высокоуровневых программных средств для разработки профессионалами-программистами и простые возможности встраивания ActiveX-объектов в разрабатываемые приложения делают популярной ActiveX технологию.

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

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

OPC позволят определять на уровне объектов различные системы управления и контроля, работающие в распределенной гетерогенной среде;

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

У потребителя появится больший выбор при разработке приложений.

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

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

Широкому распространению OPC-компонент способствует наличие инструментальных средств, которые:

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

Базовое и прикладное ПО

Базовое ПО по применению разделяется на встраиваемое и настольное. Чаще всего в качестве встраиваемого используются операционные системы (ОС) реального времени, для настольных приложений — ОС общего назначения, хотя Microsoft в настоящее время предлагает некоторые решения, позволяющие рассматривать специализированные ОС Windows в качестве кандидата на встраиваемое ПО в системах реального времени.

Использование базового ПО и традиционных языков программирования не всегда лучшее решение при создании проектов. И в настоящее время широко используются инструментальные программные средства, упрощаюшие и ускоряюшие процесс разработки. С точки зрения области применения можно выделить CASE (Computer Aided Software Engeneering)-системы, ориентированные на разработку программ управления внешними устройствами, контроллерами, и SCADA-системы, специализирующиеся на визуализации процессов и регистрации информации с других подсистем. Для обеспечения связи SCADA-систем с другими подсистемами используется коммуникационное ПО. Не может остаться без внимания в этом разделе и применение баз данных (БД), используемых как для хранения учрежденческой информации в традиционных реляционных БД, так и технологических данных в специализированных БД реального времени.

Встраиваемое ПО

Современное встраиваемое ПО включает операционные системы (ОC) т.е. файловые подсистемы, сетевые средства, оконные подсистемы и другие возможности, которые можно ожидать от полнофункциональной настольной ОС. И все они поддерживают какой либо интерфейс прикладных программ (API — Application Programming Interface), используемый программистами как способ получения системного сервиса. Большинство современных встраиваемых ОС являются модульными. Начинаются они обычно с маленького ядра и загрузчика программ, к которому как строительные блоки присоединяются системные службы и утилиты. Часто ОС оцениваются по частям, доступным пользователю, прежде всего, по API интерфейсу (для конечного пользователя). Большая часть встраиваемых ОС имеет UNIX-подобный API. Исключением из этого правила является ОC Windows CE, поскольку в нее встроен широкораспространенный API интерфейс Win32.

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

Системы управления в реальном времени

Ранее СASE-системы отличались набором поддерживаемых функций, нестандартным и немобильным языком программирования. После выпуска в 1992 году стандарта MЭК 1131-3 определены 5 языков программирования контроллеров, выдвинуты требования открытости системы, включающие:

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

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

Разработка приложений в последних версиях этих продуктов стала носить принципиально новый характер. Раньше разработка представляла собой алгоритмизацию работы для каждого узла с реализацией коммуникационных связей, обеспечивающих согласованное функционирование узлов для решения некоторой задачи. Сейчас в рамках инструментальной системы описываются отдельные узлы как ресурсы с правилами их функционирования по определенному алгоритму по отношению друг к другу. Реализация распределенного характера приложения встраивается в сам процесс его разработки в рамках систем управления в реальном времени. Встраивание распределенности в процедуру разработки приложения реализуется по-разному в продуктах различных фирм. В системах, ориентированных на Windows NT (www.microsoft.com), таких как InControl (www.wonderware.com), используются механизмы COM/DCOM, в многоплатформных системах, типа ISaGRAF (www.isagraf.com), чаще всего, протокол TCP/IP.

Более подробно имеет смысл остановиться на реализации указанных систем на Windows NT/NTE. Последние версии этих продуктов предлагают более широкие возможности и лучшую производительность благодаря поддержке следующих новых технологий:

ActiveX-объектов типа органов управления для PID-регулирования, управления интегрированным движением и с нечеткой логикой.. Вы можете создавать свои собственные алгоритмы на языке С++ и обращаться к ним из CASE-систем типа InControl как к ActiveX-объектам. Объекты типа Fuzzy Logic нечеткой логикой) позволяют повысить точность и стабильность сложных процессов.

Распределенного управления на базе DCOM. Механизм взаимодействия между исполняющими подсистемами вышеуказанных компонент, ответственных за управление контроллерным оборудованием и процессами, основан на технологии COM/DCOM.

Новых редакторов. Вы можете использовать для создания своей собственной системы управления самые различные графические и текстовые языки программирования. Поддерживает прямое взаимодействие с самыми разными устройствами ввода/вывода, двигателями, датчиками и прочим заводским оборудованием, а также все широко распространенные и новейшие открытые интерфейсы с устройствами.

Следует отметить ту особенность, что многие распределенные приложения должны быть интегрированы в уже существующие на производстве сетевые инфраструктуры. Требование специфического сетевого протокола повлекло бы обновление всех уже существующих компонент, но DCOM поддерживает ряд распространенных транспортных протоколов, включая TCP/IP, UDP, IPX/SPX и NetBEUI. Таким образом, пакеты комплексной автоматизации, использующие DCOM технологию, например, FactorySuite2000 (Wonderware, USA) индифферентны к сетевым протоколам и поэтому позволяют с небольшими затратами наращивать существующие системы.

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

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

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

SCADA-системы

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

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

Функциональные возможности по разработке приложений

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

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

Технология проектирования систем автоматизации на основе различных SCADA-систем во многом схожа с проектированием приложений в системах управления реального времени, т.е. возможно два подхода:

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

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

Графические возможности

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

Открытость систем

Программная система является открытой, если для нее описаны форматы данных и интерфейс для подключения независимо разработанных компонент, таких как:

собственных программных модулей;
драйверов ввода-вывода;
компонент, реализованных в соответствии с новыми технологиями — OPC, ActiveX.

Большинство SCADA-систем в настоящее время реализовано для OC Windows NT, поэтому значительная часть вышеперечисленных свойств касалась именно таких SCADA-систем.

Применение новых технологий

Использование OPC-технологии

Взамен ограниченного по производительности и надежности механизма DDE компания Microsoft предложила более эффективное и надежное средство передачи данных между процессами. С точки зрения SCADA-систем появление OPC-технологии означает разработку программных стандартов обмена с технологическими устройствами.

С OPC решениями интеграция в гетерогенные (неоднородные) системы становится достаточно простой (рис.8). С точки зрения SCADA-систем следует подчеркнуть, что OPC серверы, расположенные на компьютерах всего производственного предприятия, стандартным способом могут поставлять данные в программу визуализации, базы данных и т.п.. В некотором смысле уничтожая само понятие неоднородной системы. Учитывая, тем более, что массовый приход Windows NT во встраиваемые, в частности в контроллерные, приложения не за горами


Рис.8 Интеграция OPC — решений в гетерогенные системы

Встраиваемые объекты ActiveX

Ряд CASE-систем и большинство SCADA-систем являются контейнерами, которые уведомляются ActiveX о происшедших событиях. Любые ActiveX-объекты могут загружаться в систему разработки SCADA-систем и использоваться при создании прикладных программ. Управление ActiveX-объектами осуществляется с помощью данных, методов и событийных функций, свойственных выбранному объекту.

Программно-аппаратные платформы, на которых реализованы CASE и SCADA-системы. Некоторые из этих систем являются многоплатформными. Ниже в таблице 1 представлены платформы, для ISaGRAF (CJ International) и SCADA FactoryLink (United States Data Co.). Но, из-за усиления позиций Microsoft на рынке ОС следует отметить, что разработчики даже многоплатформных инструментальных программных средств (United States Data Co.) приоритетным считают развитие своих систем на Windows NT.

Коммуникационное программное обеспечение

Описанная система управления движением транспорта показала прекрасные результаты по управлению Рассматриваемые ниже программно-аппаратные решения, обеспечивающие взаимодействие SCADA-систем или пользовательских приложений с программируемыми контроллерами, офисными и промышленными сетями, являющиеся обобщенными решениями, поддерживаемыми компаниями Schneider Electric, Applicom, Trebing and Himstent и др. Аппаратная поддержка выражается в спектре вставных плат типа ISA, PCI, CompactPCI, обеспечивающих реализацию протоколов промышленных сетей. Для указанных плат предлагается многоуровневое программное обеспечение, количество уровней зависит от ОС и включает следующие типы:

статические библиотеки для использования в традиционных языках программирования , С++, Паскаль и др.);
динамические библиотеки, применяемые со всеми Windows языками программирования;
DDE- серверы;

OPC-серверы, поддерживающие интерфейс, определенный OPC-спецификацией.

На рис.9 представлена схема коммуникационного аппаратно-программного обеспечения. Она является достаточна общей и применима в большинстве случаев.

Базы данных

Большой объем информации, регистрируемой на предприятиях, способствует широкому распространению баз данных. Применение баз данных позволяет предоставить пользователям нужную информацию в нужном месте и в нужное время. В рамках данной статьи мы не будем останавливаться на ставших стандартом де-факто реляционных базах данных. Остановим свое внимание на достаточно уникальном явлении — реляционной базе данных реального времени IndustrialSQL Server (Wonderware, USA), позволяющей регистрировать информацию с высокой скоростью,. архивиривать данные с целью экономии места на диске, обеспечивать стандартный доступ к данным со стороны клиентских приложений. Реализован IndustrialSQL Server на основе Microsoft SQL Server (рис.10).


Рис.10 IndustrialSQL Server на основе MS SQL Server

Высокопроизводительный сервер

Сервер может накапливать производственную информацию с высокой разрешающей способностью, получая ее от драйверов или серверов ввода/вывода, от операторских станций и исполняющих систем реального времени. IndustrialSQL Server обеспечивает сбор данных в сотни раз быстрее, чем любые другие реляционные базы данных, и сохраняет их на гораздо меньшем дисковом пространстве. Многоуровневая клиент-серверная архитектура служит мостом между управленческими и производственными сетями, предоставляя вышележащему уровню всю информацию в реальном масштабе времени. Опирающаяся на Windows NT Server многоуровневая архитектура представляет собой масштабируемое решение любых пользовательских требований. IndustrialSQL Server может использоваться как в небольших цехах с сотней регистрируемых технологических параметров, так и на крупных промышленных предприятиях с сотнями тысяч параметров. Высокую производительность системы и целостность данных гарантирует тщательный выбор аппаратных средств.

Уменьшение объема хранения

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

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

Гибкий открытый доступ

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

SQL с поддержкой временных параметров

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

Программные средства многоуровневой системы контроля и управления

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

Контроллерный уровень

К аппаратно-программным средствам данного самого нижнего уровня предъявляются жесткие требования по надежности, времени реакции на исполнительные устройства, датчики и т.д. Контроллерная система с программным управлением должна гарантированно откликаться на внешние события, поступающие от объекта, за время в пределах установленного для каждого события интервала. В общем, для решения подобных задач рекомендуется применение ОС реального времени. Выбор ОС зависит от жесткости требований реального времени. Так для достаточно большого спектра задач применима OS-9 (Microware Systems Corp., www.microware.com), более критичные задачи требуют использования VxWorks (Wind River Systems). Для ряда задач возможным оказалось и применение расширений реального времени для Windows NT и Windows NTE, Windows СЕ от компании VenturCom. Первоначально ядро Windows СЕ предназначалось для использования в бытовых электронных устройствах, интеллектуальных приставках и т.д. Однако впоследствии в поле зрения СЕ попали и такие традиционные встроенные приложения, как промышленные, телекоммуникационные и транспортные системы, контрольно-измерительные приборы и медицинское оборудование. Некоторые компании уже сейчас предлагают специализированный сервис для СЕ, инструментальные средства и поддержку.

От контроллерной базы зависит выбор программных средств, в том числе CASE-инструментария. Так ISaGRAF (CJ International) может быть использован для OS-9, VxWorks, Windows NT, а InControl (Wonderware, USA) только для Windows NT. Взаимодействие между InControl исполняющими узлами построено на COM/DCOM — технологии и протокол обмена выбирается автоматически из стека протоколов DCOM. В последней версии ISaGRAF «пошли» не по пути DCOM, а по пути реализации взаимодействия между узлами — targets по протоколу TCP/IP. Выбор этот, скорее всего, определяется разработкой единого решения для всех платформ, на которые ISaGRAF может быть портирован.

Промежуточный уровень

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

ПО интеллектуальных контроллеров

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

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

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

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

База данных реального времени. До появления IndustrialSQL Server (Wonderware, США) задача регистрации информации в реальном времени могла быть решена либо на уровне ПО интеллектуального контроллера, либо на уровне SCADA-системы. Сейчас появилась дополнительная возможность обеспечить высокоскоростное хранение информации в БД.

Для организации доступа к базе данных IndustrialSQL Server поддерживается язык SQL, являющийся расширением Microsoft TRANSACT-SQL, с временными характеристиками данных.

Верхний уровень

ПО верхнего уровня включает традиционные SCADA-системы и базы данных. Среди имеющегося разнообразия SCADA-систем важно:

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

Условия на рынке реляционных баз данных сейчас диктует «большая пятерка» (IBM, Informix, Microsoft, Oracle и Sybase), на которую падает львиная доля всех расходов на разработку баз данных. Большая часть из них, возможно с перевесом в пользу Oracle и Microsoft, популярна и на нашем рынке. Имеет шанс применяться на верхнем уровне и IndustrialSQL Server, поскольку предлагает стандартный язык SQL для доступа к информации.

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

Выбор базового и прикладного ПО

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

Наиболее трудоемкими с точки зрения разработки представляются системы собственной разработки. Они требуют высокого профессионализма разработчиков и, конечно, будут оптимальными для конкретной системы, но по настоящему золотыми в смысле вложенных средств. Поэтому использование готовых инструментальных средств не вызывает сомнений. Степень использования готовых инструментальных средств, степень их интеграции между собой влияет на сложность разработки. Для разработки идеальной представляется картина, когда ПО всех уровней реализовано в единой ОС с использованием встроенных в нее COM/DCOM механизмов. Применяемое для разработки Вашей системы прикладное ПО, использующее COM/DCOM технологию, автоматически обеспечит вертикальные и горизонтальные связи между компонентами из стека DCOM-протоколов. ActiveX-объекты и OPC-серверы предлагают дружественный интерфейс для расширения функциональных возможностей CASE или SCADA-систем, для стандартного подключения в том числе и нестандартного оборудования.

Именно с целью максимального упрощения разработки (за разумную цену, конечно) ряд компаний (Таблица 2) предлагают пакет средств комплексной автоматизации, включающий SCADA-систему, систему управления в реальном времени (стандарт МЕК1131-3), систему управления производством и процессами дозирования и смешивания. Если требования к разрабатываемой системе и контроллерному оборудованию позволяют использовать пакеты комплексной автоматизации, то разработка систем становится максимально простой и высокотехнологичной.


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



Пока большая часть разрабатываемых систем контроля и управления реализуется с использованием инструментальных систем с применением новых технологий в части использования OPC-компонент, ActiveX-объектов.

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

Ограниченное применение DCOM-технологий объясняется:

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

Для систем, реализуемых в разных ОС, также возможны технологичные решения. Например, исторически или исходя из жестких требований к реальному времени необходимо использовать на нижнем контроллерном или промежуточном уровне ОС реального времени, для которой пока нет встроенного механизма реализации COM/DCOM. А для визуализации используется SCADA под Windows NT. Чтобы организовать взаимодействие между подобными подсистемами могут быть использованы OPC-спецификации. Так, для ISaGRAF исполняющих систем (targets) написан OPC-сервер, обеспечивающий обмен между SCADA-приложением на Windows NT и ISaGRAF-приложением, активизированном в OS-9.

Заключение

В настоящее время для разработки систем автоматизации активно начинают применяться COM/DCOM-технологии, причем как квалифицированными разработчиками прикладного ПО, так и в предлагаемых на рынке инструментальных системах. Новые технологии находят свою реализацию в виде:

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

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

Активному внедрению предложенных Microsoft технологий способствует как реализация LPC/RPC механизмов в ОС Windows NT, так и наличие высокоуровневых инструментальных средств, упрощающих разработку ActiveX-объектов, OPC-компонент.

Следует отметить, что применение упомянутых технологий поддерживается пока далеко не во всех ОС, но ряд компаний занимаются переносом COM на другие распространённые операционные системы (ОС).

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

19.04.2014