Файл: Общая характеристика объектно-ориентированного подхода и его сравнение с другими подходами.pdf

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

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

Глава 2. Методология разработки информационной системы на основе объектно-ориентированного подхода

2.1 Онтология информационной системы и ее построение

Потребность в разработке онтологий возникает по некоторым причинам:

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

- для возможности повторного использования знаний в предметной области;

- для отделения знаний в предметной области от оперативных знаний;

- для анализа знаний в предметной области.

Совместное использование людьми или программными агентами общего понимания структуры информации является одной из наиболее общих целей разработки онтологии. К примеру, пусть есть несколько различных датчиков, которые аккумулируют информацию об окружающей среде. Если все эти датчики совместно используют и отдают одну и ту же базовую онтологию терминов, которыми они все пользуются, то компьютерные программы могут извлекать информацию из этих датчиков и использовать ее^[13].

Обеспечение возможности использования знаний предметной области стало одной из движущих сил недавнего всплеска в изучении онтологий. Например, для моделей многих различных предметных областей необходимо сформулировать понятие времени. Это представление включает понятие временных интервалов, моментов времени, относительных мер времени и т.д. Если одна группа ученых детально разработает такую онтологию, то другие могут просто повторно использовать ее в своих предметных областях. Кроме того, если нам нужно создать большую онтологию, можно интегрировать несколько существующих онтологий, описывающих части большой предметной области. Отделение знаний предметной области от оперативных знаний - это еще один вариант общего применения онтологий. Можно написать задачу конфигурирования продукта из его компонентов в соответствии с требуемой спецификацией и внедрить программу, которая делает эту конфигурацию независимой от продукта и самих компонентов. Можно разработать онтологию компонентов и характеристик ЭВМ и применить этот алгоритм для конфигурирования нестандартных ЭВМ [8].

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

В общем виде формальная модель онтологии может быть описана следующим кортежем^[14]:

0 = {L,C,F, G,H,R,A},

где L = LC U LR - словарь онтологии, содержащий набор лексических единиц (знаков) для понятий LC и набор знаков для отношений LR;

C - набор понятий онтологии, причем для каждого понятия с £ С в онтологии существует по крайней мере одно утверждение;

F и G - функции ссылок такие, что F: FLC ^ 2C и П: FLR ^ 2R, то есть F и G связывают наборы лексических единиц {Lj} с L с наборами понятий и отношений, на которые они соответственно ссылаются в данной онтологии, при этом одна лексическая единица может ссылаться на несколько понятий или отношений и одно понятие или отношение может ссылаться на несколько лексических единиц;

H - фиксирует таксономический характер отношений (связей), при котором понятия онтологии связаны нерефлексивными, ациклическими, транзитивными отношениями H с C х C, выражение Н(Сг, C2) означает, что понятие C является подпонятием C2;

R - обозначает бинарный характер отношений между понятиями онтологии, фиксирующей пары области применения (domain)/области значений (range);

A - набор аксиом онтологии.

Более простая модель онтологии (без словаря и без определения типа отношений) приведена ниже. Под онтологией в этой работе понимается упорядоченная тройка вида^[15]:

0 = (C,R,F),

где C - конечное множество концептов (понятий, терминов) предметной области, которую представляет онтология О;

R - конечное множество отношений между концептами заданной предметной области;

F - конечное множество функций интерпретации (аксиоматизации), заданных на концептах и/или отношениях онтологий О.

Естественным ограничением, налагаемым на множество С, является его конечность и не пустота.

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

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

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

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

На практике разработка онтологий включает^[16]:

- определение классов в онтологии;

- расположение классов в таксономическую иерархию (подкласс- надкласс);

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

- связывание слотов с классами.

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

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 клиент и сервер идентифицируют себя цифровыми сертификатами. Во-вторых, в рамках соединения создается сессия - логическое соединение клиента и сервера^[17]. Параметром сессии являются уже права отдельного пользователя, использующего OPC клиент, так как OPC-сервер может вводить ограничения на операции чтения/записи отдельных элементов для разных пользователей. Уже в рамках сессии производится собственно передача данных (выполнение запросов на чтение/запись), а также производится инициализация списка элементов, об изменениях значений которых сервер направляет клиенту уведомление.

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

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

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

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

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

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

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

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

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