Теория и проектирование датчиков, приборов и систем
Автоматизированные системы управления
УДК 681.327.8
ПРОЕКТИРОВАНИЕ КОММУНИКАЦИОННОЙ СИСТЕМЫ В ЗАДАЧАХ АВТОМАТИЗАЦИИ ТЕХНОЛОГИЧЕСКИХ ОБЪЕКТОВ
А.Н. Бевзов, С.А. Лылов
Рассмотрен подход к проектированию коммуникационной системы, предназначенной для организации диспетчерского уровня автоматизации Новосибирской ГЭС.
ВВЕДЕНИЕ
При решении задач автоматизации промышленных объектов необходимо создание программно-аппаратного комплекса, позволяющего осуществлять сбор и обработку данных. В нашем случае объектом автоматизации является Новосибирская ГЭС, которая состоит из нескольких гидроагрегатов. Наблюдение и контроль за работой гидроагрегатов осуществляется с помощью автоматизированной системы технического обслуживания и управления (АСТОУ) [1], имеющей архитектуру распределенной, иерархической компьютерной сети. Компоненты этой сети изображены на рис. 1. Основная обработка и визуализация данных происходит на диспетчерском компьютере (DC1), где работает приложение (IntchApp), написанное с использованием программного SCADA пакета InTouch [2]. Данные для этого приложения поступают сначала в агрегатные компьютеры (АС1...АС7), затем передаются в коммуникационную программу (NodeApp) диспетчерского компьютера и, наконец, от коммуникационной программы поступают в само приложение. Часть данных также передается от диспетчерского компьютера в производственную сеть Intranet.
Рис. 1. Основные компоненты распределенной сети АСТОУ Новосибирской ГЭС
Особенность данной системы автоматизации заключается в том, что она создавалась поэтапно, в течение ряда лет, интегрируя на каждом более позднем этапе предыдущие разработки. Этим обусловлено наличие в ней различных типов компьютеров, операционных систем и коммуникационных средств.
На первом этапе настоящей работы задача состояла втом, чтобы обеспечить необходимый информационный обмен между диспетчерским и агрегатными компьютерами. При этом проектирование велось с учетом того, чтобы основные особенности и архитектура создаваемой коммуникационной программы могли использоваться любым компьютером, задействованным в передаче данных.
ТРЕБОВАНИЯ К КОММУНИКАЦИОННОЙ СИСТЕМЕ
Исходя из перечисленных особенностей, а также требований заказчика, были выработаны и сформулированы основные положения, согласно которым коммуникационная часть АСТОУ Новосибирской ГЭС должна быть:
• максимально переносимой на другие операционные системы;
• организованной таким образом, чтобы допускать манипуляции по добавлению-удалению передаваемых параметров без вмешательства в логику работы коммуникационной программы того или иного компьютера, задействованного в передаче данных;
• легко расширяемой, чтобы иметь возможность подключать (отключать) гидроагрегаты по мере их вво-да(вывода) в(из) эксплуатацию (эксплуатации);
• способной представлять необходимый интерфейс для того, чтобы прикладные программы в любом из компьютеров, задействованном в передаче данных, могли получать доступ к передаваемой информации и осуществлять мониторинг всех необходимых параметров.
ПРОЕКТИРОВАНИЕ КОММУНИКАЦИОННОЙ СИСТЕМЫ
В процессе проектирования предполагалось выполнение нескольких основных этапов:
• выработка концептуальной модели, в рамках которой решалась поставленная задача;
• выявление основных инвариантов, касающихся предметной области, в терминах которых может быть формально описана данная задача;
• создание некоторых удобных описательных структур, позволяющих определить выявленные инварианты применительно к конкретной задаче.
• построение архитектуры базовых модулей, опирающихся на выявленные сущности и реализующие основные алгоритмы работы с ними. Рассмотрим кратко перечисленные этапы.
ВЫРАБОТКА КОНЦЕПТУАЛЬНОЙ МОДЕЛИ
Основная идея при создании коммуникационной системы данного проекта состояла в реализации максимально гибкой среды передачи данных, не требующей (или, по крайней мере, уменьшающей вмешательство программиста) необходимости перекомпиляции программы в случае изменения передаваемых данных, замены используемых протоколов, перегруппировки параметров по подсистемам и других возможных вариаций, связанных с изменением передачи параметров.
Такой подход привел к концепции обеспечения единого информационного поля всех передаваемых в системе автоматизации параметров. Эта концепция подразумевает использование файла конфигурации узла передачи данных, конфигурационного файла всех передаваемых параметров системы, а также наличие коммуникационных модулей на каждом узле передачи данных [3].
ОПРЕДЕЛЕНИЕ ИНВАРИАНТОВ ФОРМАЛЬНОГО ОПИСАНИЯ ЗАДАЧИ
Формальное описание задачи или хотя бы ее части необходимо для возможности максимальной автоматизации процесса решения данной конкретной задачи, а также для облегчения решения подобного рода задач в будущем. Инварианты формального описания можно выявить, опираясь на словарь предметной области, а также на расширенный словарь, который отражает уже выбранную стратегию проектирования и реализации [4]. В терминах такого словаря можно формально описать конкретную задачу на абстрактном уровне. Это описание занимает промежуточное положение между техническим заданием, выполненным на обычном языке, и формулировкой части этого же задания на языке, понятном компьютеру.
В данном случае формальное описание задачи может выглядеть следующим образом. Распределенная сеть может быть представлена в виде множества узлов передачи данных. Узел передачи данных — это программно-аппаратный модуль, обеспечивающий передачу информации в сети. Каждый узел, в свою очередь, состоит из нескольких звеньев передачи данных, которые позволяют осуществлять связь между двумя смежными узлами передачи данных. Информация по каждому звену передачи данных передается в виде параметров, сгруппированных по подсистемам.
Таким образом, имея в качестве инвариантов формального описания такие понятия, как узел передачи данных, звено передачи данных, параметр, подсистема, мы можем описать достаточно широкий класс задач, связанных с передачей данных в распределенной компьютерной сети, имеющей топологию дерева. Приведенные четыре инварианта формального описания являются основными для данной задачи, однако, конечно же, не единственными. Так, например, для определения звена передачи данных необходимо, в свою очередь, использовать такие понятия, как тип используемого сетевого и прикладного протокола, идентификационная строка данного узла передачи данных и т. д.
СОЗДАНИЕ ОПИСАТЕЛЬНЫХ СТРУКТУР
С помощью подходящих описательных структур, составленных в терминах формального описания, можно производить настройку уже на конкретный объект автоматизации. В данном проекте используется два типа такого рода описательных структур: файл конфигурации узла передачи данных и файл конфигурации передаваемых параметров. Эти описательные структуры предоставляют информацию о том, как необходимо настраивать коммуникационную систему.
Файл конфигурации узла передачи данных определяет, какое количество звеньев передачи данных будет установлено на данном компьютере, какие сетевые протоколы будут использоваться на каждом звене передачи данных, по каким подсистемам будут формироваться блоки параметров, какую индикацию необходимо выдавать в случае наличия или отсутствия соединения по данному узлу передачи.
Файл конфигурации передаваемых параметров [3] позволяет описать основные характеристики и направление движения всех передаваемых параметров в данной системе автоматизации. На основе этой информации осуществляется автоматическая настройка соответствующих информационных структур приемников и передатчиков в звеньях передачи данных.
Такие описательные структуры, как файл конфигурации узла передачи данных и файл конфигурации передаваемых параметров, позволяют достаточно гибко настраивать коммуникационную систему для конкретного объекта автоматизации. В данном случае это означает, что при необходимости исключения или добавления некоторых данных (что бывает при проведении ремонтных работ, вводу или выводу из эксплуатации новых блоков гидроагрегатов) достаточно будет внести необходимые модификации в описательных структурах без необходимости перекомпиляции программы.
ПОСТРОЕНИЕ АРХИТЕКТУРЫ И ОПРЕДЕЛЕНИЕ ИНТЕРФЕЙСА ОСНОВНЫХ КЛАССОВ
После выявления необходимых понятий для создания формального описания задачи, определения описательных структур, необходимых для задания фактических элементов, были определены основные классы, их архитектура, предоставляемый интерфейс и отношения, в которых они находятся.
Наибольший интерес представляют диаграммы классов (рис. 2), иллюстрирующие устройство звеньев передачи данных, выполняющих основную работу по передаче данных. В данных диаграммах используется нотация языка иМЬ [5].
Датчики и Системы • № 9.2001
3
Рис. 2. Диаграмма классов для звеньев передачи данных диспетчерского компьютера (а) и эмулятора агрегатного компьютера (б)
Каждое звено передачи данных имеет базовый абстрактный класс CGnrlLnk. В этом классе определены основные интерфейсные функции, которые переопределяются в наследуемых от него подклассах. Этот класс служит для создания единого интерфейса и скрывает от клиентской части программы узла передачи данных детали реализации и конфигурации различных звеньев передачи данных. Задачей клиентской части программы является вызов с определенной периодичностью соответствующих функций приема-передачи данных каждого узла передачи данных. Благодаря наличию этого класса клиентская часть программы может осуществлять передачу данных, вообще ничего не зная о структуре передаваемого пакета, группировке параметров по подсистемам и самих параметрах.
Классы CTcpClnt и CTcpSrvr ориентированы на конкретный сетевой протокол (в данном случае TCP/IP) серверной и клиентской частей звена передачи данных. Эти классы являются общими для тех звеньев передачи данных, которые работают с протоколом TCP/IP в режиме клиента или сервера соответственно, даже если параметры группируются по различным подсистемам. В случае изменения сетевого протокола для поддержания функционирования звена передачи
Для дальнейшего прочтения статьи необходимо приобрести полный текст. Статьи высылаются в формате PDF на указанную при оплате почту. Время доставки составляет менее 10 минут. Стоимость одной статьи — 150 рублей.