Файл: Применение объектно-ориентированного подхода при проектировании информационной системы (общая характеристика).pdf

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

Естественно, чтобы обеспечить такие возможности коммуникаций, должна быть проделана огромная работа. Как со стороны разработчиков программного обеспечения, так и со стороны поставщиков оборудования. Найти общий язык, наладить интерфейсы, призван стандарт IEC 61499.

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

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

Первая стадия предполагает применение так называемых P&ID (Process and Instrumentaion Diagrams) - структурных схем, отражающих в некотором роде суперпозицию физического процесса или объекта и применяемых в нем технических средств. На создаваемой схеме наносятся различные технологические установки, указывается расположение датчиков и т.д. Этот документ является своеобразной отправной точкой, началом проекта, и индикатором уровня профессионализма, причем не только разработчика системы, но и заказчика проекта. От того, насколько грамотно выполнена это стадия проекта, во многом определяется его конечный успех. В настоящий момент существует огромное количество программ разного уровня и ориентации, облегчающих создание P&ID, среди них AutoCAD, CADWorx, SmartPlant и многие другие.

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

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

Стандарт разделен на четыре части, доработка которых велась достаточно долго. Объяснить это можно глобальностью самой идеи, ведь стандарт рассчитан не только на производителей различных контроллеров и разработчиков программного обеспечения. Все положительные стороны этого стандарта проявятся только в случае, если будут выпускаться стандартные (с точки зрения производства) устройства, такие как котлы, печи, станки, насосы, обладающие определенным набором качеств, обеспечивающих совместимость с требованиями IECА61499. Производители промышленных систем управления, поставщики оборудования из США, Японии, Англии, Европы вошли в рабочую группу IEC, и появилась первая часть стандарта, описывающая архитектуру функциональных блоков, подходы к созданию и применению их на практике. Этот документ содержит описание следующих ключевых позиций:

- правила описания функциональных блоков;

- правила поведения событий в функциональных блоках;

- правила использования функциональных блоков в конфигурации распределенной промышленной системы;

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

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

- требования соответствия стандартам.

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

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

Extensible Markup Language (Расширяемый язык разметки) - средство, позволяющее структурно описать любой тип данных в текстовом виде для дальнейшего хранения и транспортировки. Основное преимущество - крос- сплатформенность. Данные, закодированные в XML, будут одинаково интерпретированы везде.

Для того, чтобы «функциональный блок» действительно стал функциональным, разработчик должен проделать работу по созданию алгоритмов или функций, которые придадут его объекту необходимые свойства. Для того чтобы задать эти свойства, можно будет воспользоваться языками стандарта IECA61131 (SFC, FB, LD, ST, IL), что, безусловно, очень удобно. Новый стандарт в своей основе будет иметь именно эти технологии программирования. Таким образом, обеспечивается преемственность решений, и тысячи разработчиков смогут легко перейти к созданию программ по объектноориентированной методологии [4].

OPC Unified Architecture (Унифицированная архитектура OPC) - спецификация, определяющая передачу данных в промышленных сетях и взаимодействие устройств в них.

Для упрощения и удешевления реализации информационных обменов в системах промышленной автоматизации была предложена технология OPC (OLE for Process Control), в системах промышленной автоматизации взаимодействие с «внешним миром» достигается за счет использования определенного шлюза, унифицирующего интерфейс взаимодействия с клиентом и скрывающего частный протокол отдельных средств автоматизации. Использование «классической» OPC ограничено платформой Windows, так как это не протокол передачи данных, а именно программная технология, основанная на механизме удаленного вызова процедур с использованием стека DCOM. Это накладывает свой негативный отпечаток на такие параметры процесса взаимодействия по OPC, как безопасность, надежность и резервирование.

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

Говоря о «классической» OPC, в первую очередь имеют в виду передачу данных согласно спецификациям OPC DA (Data Access - в масштабе реального времени), OPC HDA (Historical Data Access - архивов изменений параметров) и OPC A&E (Alarm and Events - тревог и событий).

Популярность спецификаций OPC HDA и OPC A&E существенно меньше, чем у OPC DA, потому, что передача данных архивов и аварийных событий требовала от производителя оборудования разработки еще двух отдельных программ, а от разработчика системы диспетчеризации - настройки еще одного или двух дополнительных информационных стыков c серверами OPC HDA и OPC A&E, имеющими независимые и не связанные с OPC DA адресные пространства. В OPC UA предусматривается объединение механизмов адресации и доступа к разным категориям данных.

Типовая схема использования OPC для доступа к данным ПЛК и SCADA- систем показана на рисунке 1.

Рисунок 1 - Схема применения «классической» OPC

Итак, первая особенность OPC UA - получение текущих и архивных значений параметров и событий происходит теперь единообразно от одного источника. При этом унифицированное адресное пространство еще и содержит больше семантических сведений, доступных при его просмотре. Для примера рассмотрим объект «бойлер», которым управляют через события «вклю- чен/выключен», по изменению температуры и давления, а также анализируют, как эти параметры влияют друг на друга. Логично, что данные свойства нужно группировать и анализировать все вместе. Семантика OPC UA позволяет это сделать. Один объект здесь представлен набором свойств (температура, давление), методов (включен/выключен) и событий (температура слишком высокая, давление слишком низкое).

Вторая особенность OPC UA - полностью переработанный механизм взаимодействия OPC-клиента и OPC-сервера. Произошел отказ от DCOM в пользу обмена бинарными или XML-сообщениями, то есть OPC UA - это именно протокол передачи данных; к такому механизму намного «дружественнее» относятся межсетевые экраны и прочие средства информационной безопасности; с другой стороны, отказ от DCOM вызван и ростом популярности решений под Linux. Также стандарт определяет гибкий механизм управления сетевыми и логическими соединениями OPC-серверов и OPC-клиентов для поддержки резервированных конфигураций и т.п. Более того, интерфейс OPC-сервера рассматривается как набор сервисов, а значит, данные систем автоматизации могут стать доступными другим приложениям в единой сервисной шине предприятия, построенной по технологии SOA.

Третья особенность OPC UA - отказ от использования механизмов контроля прав доступа Windows (основанных на проверке имени/пароля пользователя, от имени которого запускается OPC-клиент), разработчики OPC UA предложили более современный способ контроля с использованием сертификатов.

Также предусмотрена возможность шифрования передаваемых данных.

Естественно, уделено внимание и вопросу сохранения уже сделанных предприятиями инвестиций. Использование «классической» OPC возможно и в OPC UA-среде: специальная оболочка обеспечивает доступ к обычному OPC DA-серверу, а proxy-модуль позволяет OPC DA-клиенту взаимодействовать с новыми OPC UA-серверами [5].

Спецификация OPC UA является многоэлементной и состоит из следующих частей:

- концепция;

- модель безопасности;

- модель адресного пространства;

- службы;

- информационная модель;

- распределение служб;

- профили;

- доступ к данным;

- аварийная сигнализация и условия;

- программы;

- доступ к историческим данным.

В отличие от спецификаций основывающихся на COM, спецификации UA не являются чистыми определениями приложения. Обычно они описывают внутренние механизмы Унифицированной архитектуры, обрабатываемые коммуникационным стеком и нормально лежащие вне пределов интереса тех, кто портирует стек на специфическое устройство, или тех, кто хочет реализовать свой собственный стек UA. Разработчик приложений OPC UA разрабатывает код против OPC UA API и, следовательно, взамен будет в основном использовать документацию API [6].

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

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

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

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