Сервер OPC

     Стандарт  ОРС, в отличие, например, от устаревшего DDE (Dynamic Data Exchange), хотя и основан на универсальном фундаменте - COM/DCOM, разрабатывался специально для использования в промышленной автоматизации, поэтому он имеет вполне содержательную концептуальную сторону, т. е. свою проблемно-ориентированную модель взаимодействия, которая и реализована через совокупность СОМ-интерфейсов. Эта концептуальная сторона в известной степени независима и представляет самый большой интерес, особенно для пользователя-непрограммиста, для которого тонкости реализации СОМ-интерфейсов не столь важны. В принципе, основные идеи ОРС могли бы быть реализованы и с помощью других объектных технологий (получилось бы что-нибудь вроде CORBA for Process Control), однако распространенность Windows-платформ предопределила выбор в пользу стандартов Microsoft. 

     5.2. Выбор и обоснование  выбора спецификаций  программного изделия 

     Разрабатываемый OPC-сервер использует спецификацию DataAccess для взаимодействия с OPC-клиентами. Это самая старая и отработанная спецификация, сейчас действует ее вторая версия.

     Базовым понятием этой спецификации является элемент  данных (Item). Каждый элемент данных (т. е. фактически - параметр ТП) имеет значение, время последнего обновления (timestamp) и признак качества, определяющий степень достоверности значения. Значение может быть практически любого скалярного типа (булево, целое, с плавающей точкой и т.п.) или строкой (на самом деле это так называемый OLE VARIANT). Время представляется с 100-наносекундной точностью (на самом деле это FILETIME Win32 API). Качество - это код, содержащий в себе грубую оценку достоверности параметра -UNCERTAIN, GOOD и BAD (не определено, хорошее и плохое), а на случай плохой оценки - еще и расшифровку, например, QUAL_SENSOR_FAILURE -неисправность датчика.

     Следующим вверх по иерархии является понятие группы элементов (ОРС Group). Группа создается ОРС-сервером по требованию клиента, который затем может добавить в группу элементы (Items). Для группы клиентом задается частота обновления данных, и сервер старается обновлять и передавать клиенту все данные в группе с заданной частотой. Отдельно стоящих вне группы элементов быть не может. Клиент может создать для себя на сервере несколько групп, различающихся требуемой частотой обновления. Группа (кроме так называемых публичных групп) всегда создается для каждого клиента своя, даже если состав элементов и частоты обновления совпадают. Отсоединение клиента приводит к уничтожению созданных для него групп.

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

5.3. Выбор и обоснование  методов решения  задачи, описание  методов 

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

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

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

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

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

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

      UML не является языком визуального программирования, но модели, созданные с его помощью, могут быть непосредственно переведены на различные языки программирования. Иными словами, UML-модель можно отобразить на такие языки, как Java, C++, Visual Basic, и даже на таблицы реляционной базы данных или устойчивые объекты объектно-ориентированной базы данных. Те понятия, которые предпочтительно передавать графически, так и представляются в UML; те же, которые лучше описывать в текстовом виде, выражаются с помощью языка программирования.

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

      Для разработки UML-модели настоящего программного продукта была использована система Rational Rose компании Rational Software.  Компания Rational Software уже несколько лет является лидером в области создания инструментальных средств для проектирования, разработки, тестирования и сопровождения программного обеспечения. Основным продуктом в линейке Rational является CASE-средство Rational Rose. Rational Rose поддерживает визуальное объектно-ориентированное моделирование (UML), поддерживает генерацию кода и обратное проектирование (построение модели по программному коду) для многих языков программирования, позволяет строить объектную модель разрабатываемой программной системы, определять спецификации классов, объектов, атрибутов и операций.

      Так как Rational Rose обладает всеми необходимыми характеристиками для проектирования архитектуры системы любого масштаба, напрашивается идея использования Rose с такой мощной и популярной системой программирования, как Delphi. В стандартной поставке Rational Rose не предусмотрена возможность работы с Delphi, но Rational Software ведет программу по поддержке сторонних производителей программ-мостов (Links) между Rose и другими средствами разработки. В рамках этой программы фирмой Ensemble Systems была разработана программа-мост Rose Delphi Link (RDL), связывающая Rational Rose и Delphi. Основные функции RDL - генерация кода и обратное проектирование. Следует помнить, что генерируемый RDL код не содержит реализацию функциональности! Генерируются только декларативные элементы: определения классов, интерфейсов, записей, типов, директивы видимости и т.д.

      Также в процессе разработки  были использованы следующие  дополнительные компоненты:

      sOPC – свободно распространяемый пакет библиотек для Delphi, обеспечивающий возможность обмена данными по протоколу ОРС, использующего спецификацию OPC DataAccess 2.0.

      OPCConvertion – компонент, служащий для конвертирования интерфейсов ОРС в стандартные функции Delphi.

      bComPort – библиотека для работы с СОМ-портом в Windows.

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

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

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

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

      В процессе проектирования была предложена следующая UML-модель системы:

рис.3 Схема взаимодействия модулей программы.

(развернутую  схему см. в приложении 1)

      Класс TOPCForm является основным модулем программы, хранящим в себе главную форму, элементы управления, визуализации, функции обработки исключительных ситуаций. Являясь наследником класса TObject и реализацией абстрактного класса TForm, данный модуль использует как стандартные компоненты Delphi (TButton, TBevel и т.д.), так и разработанные в рамках данной работы классы, служащие для решения поставленной задачи.

      Класс TOPCInterraction служит для подключения OPC-клиентов и передачи им требуемой информации в виде тегов. Реализация методов OPC-взаимодействия протокола DataAccess 2.0 хранится в модулях OPCDA, uOPCNode, uOPC.

      Класс TXMLDocument и являющийся его реализацией компонент XMLTree предназначен для хранения информации о получаемых значениях в виде XML-дерева. XML как язык удачно нашел свое применение в данной работе в первую очередь из за удобства работы с классом TXMLDocument.

      В классе TReadingThread содержатся функции опроса контроллеров путем передачи и приема массива байтов с помощью методов Send/Receive библиотеки BComPort.

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

5.5 Описание протоколов  обмена данными.  

      5.5.1 «ЭСКО-Т»

      Протокол  обмена приборов ЭСКО является сетевым с возможностью включения в одну ветвь сети до 128 абонентов и унифицирован для приборов различного типа – счетчики, сумматоры, регуляторы и др. выпускаемых и разрабатываемых компанией приборов. Наиболее приемлемая физическая реализация – RS485 или M-bus для сети и RS232 для монопольного доступа.  Протокол имеет все необходимые процедуры для конфигурирования сети без информации о количестве и типах подключенных приборов, а также не требует предварительной установки сетевых адресов отдельно на каждом. Размеры пакетов передаваемых данных выбраны исходя из аппаратных особенностей ПК для оптимальной работы в многозадачных средах (Windows и т.п.). 

      Обмен данными происходит путем челночного обмена блоками по 14 байт. Процесс обмена всегда инициирует ПК или устройство-сервер. Для всех команд формат запрос-ответ является идентичным – запрос блоком 14 байт и ответ блоком 14 байт. Допустимый таймаут при передаче соседних байт не более 0.5с. Задержка очередного передаваемого «ведущим» байта более 0.5 с рассматривается как сброс буферов приема в исходное состояние и , таким образом, задержанный байт будет принят как первый в пакете.

       Запрос: