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

Итак, первая особенность 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 процентов сократить затраты по сравнению с архитектурой на основе тегов, поэтому является основой для построения подобных систем.

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

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

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

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

Рассмотрен стандарт IEC 61499, а также спецификация OPC UA ориентированная на объектно-ориентированный подход.

2.2. Структура программного обеспечения конфигурирования автоматизированной информационной системы как элемент объектно-ориентированного подхода

Диаграмма размещения программных средств состоит из следующих уровней:

- сервера базы данных;

- автоматизированной системы учета энергоресурсов;

- конфигуратора;

- OPC UA-клиента;

- OPC UA-сервера;

- приборов учета.

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

База данных содержит информацию о приборах учета.

Конфигуратор - позволяет создавать, удалять, выполнять резервное копирование баз данных. Конфигуратор позволяет: создавать дерево объектов учета и учитываемых энергоресурсов; добавлять приборы учета и их свойства; задавать параметры связи с приборами учета [13].

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

OPC-клиент получает информацию о конкретном приборе учета.

OPC-сервер получает данные о приборах учета энергоресурсов и передает эти данные автоматизированной системе учета энергоресурсов.

Структуре программных средств представлена на рисунке 2.

Рисунок 2 - Структура автоматизированной системы с использованием спецификации OPC UA

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

На рисунке 3 - представлена сущность взаимодействия OPC-клиента и OPC-сервера

Рисунок 3 - Сущность взаимодействия OPC-клиента и OPC-сервера

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

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

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

OPC UA реализует важные изменения и в части организации данных сервера, то есть адресного пространства. В OPC DA теги были сгруппированы иерархически с помощью папок. У каждого тега были обязательные свойства: значение (скалярное или векторное, одного из предопределенных простых типов данных - Int16, Float, String и т.п.); признак достоверности (quality); метка времени. Разработчик OPC-сервера мог определять дополнительные свойства для тегов, такие как описание единиц измерения и т.п.; было желательным, чтобы OPC-клиент мог считывать значения этих дополнительных свойств наряду с обязательными свойствами. В OPC UA адресное пространство организовано иерархически за счет введения объектов (в терминах объектноориентированного программирования), то есть экземпляров классов. Класс (и объект) может содержать переменные, ссылки на другие объекты и даже методы - функции, доступные для вызова OPC-клиентом. При этом тип переменной может быть сложным, аналогично понятию структуры из языка программирования, объединяя поля разных типов, включая таблицы (массивы) и т.д.

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

В адресном пространстве OPC UA-сервера может быть реализована явная типизация объектов, то есть сопоставление однотипных групп технологических параметров шаблону (классу). Благодаря этому появляется возможность в приложении-клиенте контролировать полноту получаемой информации и в случае изменения ее объемов в сервере автоматически на это реагировать.

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

Заключение

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

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

Преимущества объектно-ориентированного метода:

- работают на более высоком уровне абстракции;

- нет «прыжков» между фазами;

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

- поощряют и поддерживают классические достоинства хорошего программирования и проектирования;