Методика и технология разработки программно-технических комплексов СМ ЭВМ для АСУТП
|
СМ1820.МП3 |
Octagon
6225 |
|
|
FastWell CPU686E |
|
|
Рис. 6. Графики предпочтения для
соотношения производительность / сложность задачи
Графики предпочтения для
соотношения цена/сложность задачи представлены на рис. 7.
С точки зрения цены для
наиболее простых задач выгодным решением является применение модулей СМ1820.МП3
и Octagon 6225. Т.к. применение более мощного модуля Fastwell CPU686E является более дорогим
решением для задач, которые могут быть выполнены более слабыми модулями. При достижении
уровня сложности 0,3 и до 0,6 целесообразность применения всех трех модулей
примерно равна, т.к. в этом промежуточном случае к ПТК могут быть предъявлены
такие требования, которые приведут к необходимости расширять возможности модулей
СМ1820.МП3 и Octagon 6225, такие как: объем оперативной памяти,
добавление интерфейсов передачи данных, объем пространства хранения данных и
т.д. При дальнейшем возрастании уровня сложности задачи (от 0,6 до 1) наиболее
приоритетным становится модуль Fastwell CPU 686E, т.к.
реализация подобных задач на двух других модулях может потребовать установки
большого количества дополнительного оборудования.
СМ1820.МП3 |
Octagon
6225 |
|
|
FastWell CPU686E |
|
|
Рис. 7. Графики предпочтения
для соотношения цена/сложность задачи
Графики соответствия операционных систем, которые
возможно установить и использовать к сложности задачи представлены на рис. 8.
Для реализации простых задач
контроля и управления, при использовании простых интерфейсов обмена данными (RS-232, RS-485)
не требуются возможности мощных операционных систем, таких как Linux
или QNX. Достаточно функций ОС DOS-RTK. Соответственно при
реализации задач сложностью до 0,3 приемлемым вариантом являются все три
модуля. Но соответствие требованиям модуля Fastwell CPU 686E
остается неизменным (1) на всех уровнях сложности задачи, т.к. на нем
гарантирована работа любых операционных систем. При сложности задачи в
промежутке от 0,3 до 0,6 модуль СМ1820.МП3 способен составить конкуренцию
модулю Octagon 6225, но при дальнейшем нарастании сложности его
функция принадлежности убывает до 0, т.к. ресурсы модуля не позволяют работать
под управлением ОС Linux или QNX из-за больших затрат
ресурсов на собственные нужды ОС. Использование модуля Octagon 6225 остается приемлемым
вариантом даже при максимально сложной задаче, но менее приоритетным чем Fastwell CPU 686E из-за ограничений в объеме
оперативной памяти и вычислительных ресурсов процессора. На модуле Octagon
6225 возможна работа всех предложенных операционных систем, но запас
производительности остается значительно меньшим, чем в случае Fastwell CPU 686E.
СМ1820.МП3 |
Octagon
6225 |
|
|
FastWell CPU686E |
|
|
Рис. 8. Графики соответствия
операционных систем, которые возможно установить и использовать к сложности задачи
2. Выбор модулей УСО.
Модули
УСО могут быть скомпонованы следующими вариантами:
2.1.
Наличие или отсутствие контроля линий связи. Недостатки – увеличение
стоимости модуля. Преимущества – углубленная диагностика состояний линий связи.
Диагностика выхода из строя оборудования.
2.2.
Подключение первичных аналоговых сигналов непосредственно к модулям или
использование преобразователей для формирования унифицированного сигнала 4 – 20
мА. Использование первичных сигналов повышает точность измерения, увеличивает надежность
системы из-за возможности отказа дополнительного оборудования. Недостаток – в
некоторых случаях увеличение стоимости кабелей линий связи из-за необходимости
борьбы с помехами. Выбор по данному пункту зависит от географического
расположения контроллера и объекта управления. Подключение первичных сигналов,
например, от термопар к контроллеру целесообразно при длине линии связи не
более 80 -
2.3.
Наличие гальванической развязки. Обеспечивает большую надежность системы,
предохраняя другие модули от бросков напряжения в сигнальных кабелях.
Недостаток: усложнение электрической схемы и как следствие – увеличение
стоимости модуля.
3. Выбор физических протоколов
связи между контроллерами и системами верхнего уровня.
При выборе физических
протоколов связи основным критерием, определяющим «сложность задачи» является
надежная доставка необходимого количества данных в единицу времени. Будем
считать простой задачей (0) тот случай, когда объем данных, передаваемых за 1с
не превышает 50 – 100 сигналов, причем сопутствующая сигналу служебная
информация сведена к минимуму, т.е. сигналы передаются без имен. Наиболее сложной
задачей является тот случай, когда необходимо транслировать большое количество
изменений сигналов (от 200-т и больше) за время меньше 500 мс с именами
сигналов и их статусами.
3.1.
Протокол RS-232. Преимущества заключаются в быстроте развертывания
систем, основанных на данном протоколе, простоте его программирования и низкой
стоимости оборудования. Т.к. данный интерфейс практически всегда присутствует
как на всех материнских платах машин верхнего уровня, так и на всех
процессорных модулях контроллеров. Недостатки заключаются в отсутствии
возможностей организации сети контроллеров, низкой скорости передачи данных,
низкий контроль ошибок в передачи данных, малые расстояния между контроллером и
машиной верхнего уровня. Фактически, использование этого протокола возможно
только в случае самых простых систем, где имеется один контроллер и одна машина
верхнего уровня, причем расположенных рядом друг с другом, а также задача, не требующая большого объема
передачи информации.
3.2.
Протокол RS-485. Промышленный протокол. Существует возможность организации
сети, но не в равноправном режиме. Т.е. при такой организации машина верхнего
уровня должна выступать в качестве master и отправлять запросы
устройствам slave (контроллерам), которые могут лишь отвечать на
запросы. Данный протокол хорош так же тем, что обеспечивает большую длину на
линии связи (до
3.3.
Протокол Ethernet. Обеспечивает высокоскоростную передачу данных на
большие расстояния (особенно при преобразовании интерфейса в
волоконно-оптическую сеть). Является наиболее часто используемым протоколом как
в бытовых, так и в промышленных сетях. Обеспечивает высокую надежность при
передаче данных.
Графики
предпочтений при выборе протоколов связи представлены на рис. 9 – 11.
RS-232 |
RS-485 |
|
|
Ethernet |
|
|
Рис. 9. Выбор протокола
связи в зависимости от сложности задачи
При выборе физического протокола
связи исходя лишь из функциональных возможностей протокола (рис. 9), определим
следующие предпочтения. Протокол RS-232 и RS-485
являются наиболее предпочтительным при реализации простых задач, т.к. они
представлены на любом из трех предложенных процессорных модуле и программная
реализация этих протоколов является наиболее простой. При усложнении задачи
(точка 0.3), когда возрастают требования к объемам передаваемой информации и к
скорости передачи данных их оценка падает до 0.5, т.к. возникают проблемы с
программной реализацией требований, а также аппаратные проблемы, например для
протокола RS-232 – отсутствие возможности организации сети
нижнего уровня. При дальнейшем усложнении задачи (от 0.6 до 1) возможность применения
протокола RS-232 снижается до 0, т.к. для передачи большого
объема данных с большой скоростью по данному протоколу необходимо реализовывать
сложные программно-технические решения. Возможность использования протокола RS-485
остается, но является менее удобным решением по сравнению с Ethernet.
Использование же Ethernet является неоправданным для простых задач, т.к. сама
по себе реализация протокола несколько сложнее чем RS-232/485, но его использование
становится более оправданным при усложнении задачи.
RS-232 |
RS-485 |
|
|
Ethernet |
|
|
Рис. 10. Соотношение
стоимости реализации протокола к сложности задачи
При рассмотрении вопроса стоимости реализации
протоколов связи (рис. 10) играют роль те же факторы, что были описаны с
технической точки зрения. Использование RS-232 и RS-485
являются наиболее дешевыми решениями для простых задач, т.к. они изначально
поддержаны и программно и аппаратно при любой структуре системы. Но при
усложнении задачи они могут потребовать добавления в систему определенных технических
решений для ускорения обмена данными и для обеспечения связи на больших
расстояниях, которые приведут к увеличению общей стоимости технических средств
и большие затраты на программную реализацию. Использование Ethernet
на простых задачах является неоправданно дорогим решением, т.к. требует дополнительной
установки сетевых карт и прочего сетевого оборудования. Но при сложных задачах
– это наиболее простой, удобный и дешевый вариант, т.к. реализация подобных
задач на других протоколах становится неудобной и дорогой.
Надежный обмен данными (рис.
11) при реализации простых задач возможен при использовании всех трех
протоколов связи по описанным выше причинам. По тем же причинам, при нарастании
сложности задачи наиболее приоритетным становится протокол Ethernet,
а показатели по RS-232 и RS-485 падают из-за
необходимости установки дополнительного оборудования и из-за усложнения
программного обеспечения.
RS-232 |
RS-485 |
|
|
Ethernet |
|
|
Рис. 11. Возможность
реализации надежного обмена данными
в зависимости от сложности
задачи
4. Варианты организации
обмена данными между SCADA–системой и контроллерами
(или другими системами нижнего уровня (НУ), такими как OM-690 - Siemens).
Основными требованиями в
рамках данной системы является надежная трансляция сигналов контроля и
управления из контроллера на верхний уровень и обратно с максимально возможной
задержкой 500 мс. Трансляция сигналов контроллера на несколько рабочих станций
верхнего уровня. Минимизация трафика обмена данными с системами нижнего уровня.
Обеспечение передачи большого количества именованных сигналов.
Варианты обмена данными с контроллером.
4.1 Использование
интерфейсной библиотеки SCADA-системы + службы обмена
данными (API + DRS). При данной компоновке на
сервере работает служба DRS, которая взаимодействует с
системами нижнего уровня по определенным протоколам и обеспечивает обмен
данными со SCADA-системой.
Преимуществами является возможность частичной
разгрузки логического модуля SCADA-системы за счет реализации
простейших логических функций внутри службы. Возможность online
переконфигурации системы связи без остановки SCADA-системы. Универсальный
подход при компоновке систем, в которых в качестве нижнего уровня используются
контроллеры СМ1820 или OM-690. Простота в наращивании
библиотеки систем нижнего уровня. Простота перехода на другую SCADA-систему,
путем замена интерфейсной библиотеки. Возможность трансляции сигналов в несколько
систем верхнего уровня без перегрузки каналов связи с контроллерами.
Недостатки – значительные задержки в цепях
управления, обусловленные временным циклом опроса выводных цепей SCADA-системы
службой (200 – 500 мс). Дополнительные задержки в цепях трансляции сигналов
контроля с нижнего уровня в SCADA-систему за счет отработки
логических функций.
4.2 Организация обмена
данными с помощью скриптового языка, встроенного в SCADA-систему. Преимущества –
возможность достаточно быстрого развертывания системы связи в простых задачах.
Недостатки. Скриптовые языки являются, как правило,
трансляторами, а следовательно значительно более низкая скорость выполнения
кода. Во многих SCADA-системах, в том числе и в WinCC, скриптовый язык не
поддерживает многопоточность, а следовательно задержки, которые могут
возникнуть при работе с системами связи, могут привести к временной или полной
остановке работы сервера. Кроме того, скриптовые языки имеют ряд ограничений,
что, иногда, не позволяет выполнить определенные задачи без разработки дополнительных
внешних модулей.
4.3 Механизм OPC.
Является универсальным механизмом обмена данными как с системами нижнего
уровня, так и между системами верхнего уровня. Преимущества - универсальный
подход к организации обмена данными. Недостатки: Необходимость разработки
сложных OPC клиентов. Для поддержки протокола OPC на
нижнем уровне – необходимость использования мощных операционных систем
семейства Microsoft, что требует значительных затрат вычислительных
ресурсов и одновременно резко снижает быстродействие и надежность контроллеров.
Кроме того, использование протокола OPC ведет к значительному
увеличению стоимости компоновки SCADA-системы, т.к. при этом используются
компоненты, требующие дополнительного лицензирования. Однако, данный механизм
является удобным инструментом при организации связи с посторонними системами
нижнего уровня, уже имеющими поддержку OPC.
Построим графики экспертных оценок для выбора
методов организации обмена данными между SCADA-системой и нижнем уровнем
исходя из различных критериев: наиболее удобные варианты с технической точки зрения
и с точки зрения трудозатрат на реализацию.
DRS |
Scripts |
|
|
OPC |
|
|
Рис. 12. Предпочтения
вариантов организации обмена данными с НУ в зависимости от сложности задачи
Рассмотрим графики
предпочтений вариантов организации обмена данными с технической точки зрения
(рис. 12.). При проектировании и разработке наиболее простых задач (см. п.1.),
т.е. задач, где не требуется высокой частоты опроса НУ, не требуется каких-либо
логических преобразований сигналов и количество сигналов не большое (до 200-т),
наиболее приоритетным решением является использование встроенного скриптового
языка SCADA-системы, позволяющего достаточно быстро организовать простой алгоритм
обмена данными с контроллером. Но при увеличении сложности задачи реализация подобным
образом становится менее удобной, т.к. возникает необходимость создавать
достаточно сложные программные модули, а реализация быстродействующих программ
на скриптовом языке просто невозможна из-за того, что эти языки являются трансляторами,
а следовательно, на их исполнение тратится значительно больше времени и ресурсов,
чем на исполнение скомпилированного кода. Таким образом, график предпочтения
для варианта скриптового языка будет линейно убывать от 1 до 0 при возрастании
сложности задачи от 0 до 1.
При использовании варианта
организации обмена данными с помощью специально разработанной службы DRS ситуация
выглядит следующим образом. Использование службы DRS для самых простых задач является
менее удобным вариантом, чем скриптовые языки, но возможным, т.к. для функционирования
этой схемы необходимо соблюсти некоторые требования, сопутствующие универсальному
решению. Это не оправдано для простых задач, т.к. в них не требуется реализация
основных функций, представленных в DRS, таких как распределение
данных на верхнем уровне (ВУ) или первичная обработка сигналов. При возрастании
сложности задачи (от 0.6 до 1) использование DRS становится наиболее
приоритетным вариантом, т.к. на этом уровне сложности возникает необходимость
использования всех функций, реализованных в DRS, реализация которых другими
средствами является более сложной и менее быстродействующей.
Использование механизма OPC на простых задачах является самым неудобным вариантом из-за необходимости соблюдения большого количества формальностей, связанных с реализацией универсального протокола. Механизм OPC очень сложен и влечет за собой реализацию сложнейших модулей как на нижнем так и на верхнем уровне. При возрастании сложности задачи (от 0.3 до 1) использование OPC становится более оправданным, но, тем не менее, менее удобным для применения с техническими средствами СМ1820М чем DRS. Механизм OPС, как и DRS, позволяет организовать распределение данных на верхнем уровне, но не имеет функций первичной обработки сигналов, что является очень важным моментом.
DRS |
Scripts |
|
|
OPC |
|
|
Рис. 13. Трудозатраты по
организации обмена данными в зависимости от сложности задачи
При построении графиков
предпочтений вариантов организации обмена данными с НУ с точки зрения
трудозатрат на реализацию (рис. 13) видно, что использование DRS
является наиболее удобным вариантом при любой сложности задачи и значение функции
принадлежности равно 1 и не меняется. Использование скриптовых языков для
простых задач является столь же удобным вариантом, но значение функции падает
до 0 линейно при возрастании сложности задачи из-за необходимости усложнять
программы для реализации всех необходимых требований. Использование OPC
является самым трудоемким решением при любой сложности задачи и следовательно,
значение функции принадлежности не меняется и остается близким к 0 для любой
сложности задачи.
5. Варианты реализации
распределенных серверов верхнего уровня.
Реализация подобной задачи
может быть необходима, когда часть данных одного и того же контроллера или
серии контроллеров требуется на одной группе серверов, а другая часть на другой
группе или даже при необходимости трансляции одних и тех же данных на несколько
серверов верхнего уровня. Основной задачей, в этом случае, является надежная
передача данных для все потребителей при минимизации сетевого трафика между системами
верхнего и нижнего уровня и при максимальном уменьшении нагрузки на процессор
контроллера по обработки запросов систем верхнего уровня.
Варианты реализации такого
обмена могут быть следующими:
5.1 Каждый
сервер связывается непосредственно с каждым контроллером. Данный способ имеет
недостаток в том, что линия связи должна иметь достаточную производительность
или, в случае использования интерфейса RS485, контроллер, т.к. он
выступает в режиме Slave, контроллер должен иметь отдельный физический интерфейс
для каждого потребителя верхнего уровня. Кроме того, подобный способ потребует
значительных затрат со стороны процессорного модуля контроллера, для обработки
индивидуальных запросов для каждого потребителя.
5.2 Данные с
систем нижнего уровня запрашиваются службой DRS, которая является
концентратором и транслирует эти данные для всех потребителей верхнего уровня.
Подобный способ увеличивает нагрузку на процессор сервера, что является менее
критичным, т.к. запас мощности сервера многократно выше, чем у контроллера.
Недостатком является снижение надежности системы, но эта проблема может быть
решена резервированием серверов и линий связи с нижним уровнем. Т.е. каждый
контроллер имеет 2 линии связи и опрашивается по ним разными серверами. Далее,
данные могут быть оттранслированы на неограниченное число систем верхнего уровня
с использованием высокоскоростных интерфейсов (Ethernet).
5.3 Данные
поступают в SCADA-систему и далее распределенность осуществляется
средствами SCADA-системы. В плане нагрузки на процессорный модуль
контроллера этот способ ничем не отличается от пункта 5.2, но недостаток
заключается в ограничениях по трансляции данных на верхнем уровне из-за
необходимости реализации, как правило, достаточно сложных протоколов обмена
данными со SCADA-системой.
Каждый сервер с каждым КП |
DRS |
|
|
SCADA
|
|
|
Рассмотрим графики
экспертных оценок реализации распределенности данных на ВУ в зависимости от
сложности задачи (рис. 14). Наиболее удобным в реализации и наиболее
быстродействующим вариантом является использование службы DRS,
т.к. функции для распределения потоков данных между системами верхнего уровня
закладывались во время разработки службы. Организация распределения данных за
счет организации индивидуального канала связи для каждого клиента верхнего
уровня до каждого контроллера является приемлемым вариантом для самых простых
задач и далее функция принадлежности линейно убывает, т.к. при возрастании
сложности задач подобный способ требует большого количества вычислительных
ресурсов контроллера и перегружает линии связи. Распределение данных средствами
SCADA системы является приемлемым вариантов при любом уровне сложности
задачи, но менее удобным чем DRS, а следовательно значение
функции остается неизменным, но это значение равно 0.5, при том, что вариант DRS
имеет значение 1.
2.4. Оптимизация. Результаты
расчетов
Приведем пример компоновки
ПТК на основании данных для системы АСКУ «Водород». Компоновка системы будет
осуществляться из 5-и компонентов: процессорный модуль контроллера, модули УСО контроллера,
протоколы связи контролера и систем верхнего уровня, компонент обмена данными
верхнего уровня с контроллерами, компонент распределения данных на верхнем уровне.
Разработанная программная
оболочка позволяет произвести компоновку нескольких вариантов ПТК и показывает
наиболее оптимальный вариант исходя из заданных системных требований.
Сначала определим вектор
системных требований для трех систем. Система 1 – простая система, в которой
контроллер выступает в роли транслятора сигналов без их внутренней обработки.
Для такой системы не требуется большого количества вычислительных ресурсов на
нижнем уровне. Также, в этом случае не предъявляется больших требований к
протоколам передачи данных. Система 2 – представляет собой более сложную
систему с реализацией простейших механизмов первичной обработки данных на нижнем
уровне. Кроме того, т.к. система может быть укомплектована несколькими контроллерами,
требуется обеспечить систему протоколом передачи данных, позволяющим
организовать сеть контроллеров. Система 3 – является сложной реализацией
автоматизированной системы управления, с автоматическим управлением на нижнем
уровне, и многотерминальной системой мониторинга на верхнем уровне с задачей
распределенной системы архивирования значений технологического процесса (АСКУ
«Водород»). Таким образом, контроллер для данной системы должен быть
укомплектован достаточно производительным процессором. Средства связи
контроллеров и верхнего уровня должны обеспечивать достаточную пропускную
способность, а службы на верхнем уровне должны иметь функцию оптимального
распределения данных по серверам.
Далее сформируем модули ПТК
в соответствии с требованиями к Системе 3. Выберем процессорный модуль Fastwel CPU 686E, протокол связи Ethernet,
компонент обмена данными с верхним уровнем
- DRS и компонент распределения данных на верхнем уровне
- DRS. С помощью описанной программы докажем, что данный набор модулей ПТК
является наиболее оптимальным для Системы 3 и не подходит для систем 1 и 2.
Исходя из вышеуказанных
требований, определим вектор системных требований (таблица 1).
Таблица 1.
|
Система 1 |
Система 2 |
Система 3 |
Процессоры |
1 |
1 |
1 |
Протокол связи |
0,2 |
0,5 |
0,8 |
Организация обмена данными
с ВУ |
0,5 |
0,2 |
0,9 |
Распределение данных на ВУ |
0,2 |
0,9 |
0,5 |
Модули УСО |
0,2 |
0,5 |
0,8 |
Представим графики
экспертных оценок для выбранных компонентов (рис. 15).
Процессор |
Протокол связи |
|
|
Протокол обмена данными с
ВУ |
Распределение данных на ВУ |
|
|
Модули УСО |
|
|
Рис. 15. Графики экспертных
оценок для выбранных компонентов
На основании представленных
графиков результирующих экспертных оценок компонентов получаем результат работы
программы в виде гистограммы (рис. 16).
Рис.
16. Результаты расчета
Полученный результат
показывает, что выбранная конфигурация ПТК оптимальна для применения в Системе
3.
Заключение.
Предложен модифицированный
ВСТ-СКВ метод, позволяющий выбирать структурно-компоновочный состав ПТК
оптимальным образом в смысле экспертных оценок значимости его элементов.
Предложены экспертные оценки
функций принадлежности для наиболее значимых компонентов, используемых при
компоновке программно-технических комплексов СМ1820М: процессорного модуля,
модулей УСО, протоколов обмена данными и др.
Разработана интерактивная
оптимизационная программа реализации нечетких вычислений по модифицированному
ВСТ-СКВ методу в среде табличного процессора EXCEL. Программа может быть
настроена на любое количество векторов СКВ и любую сложность (размерность)
самих векторов СКВ.
Литература.
1. Методы робастного, нейро – нечеткого и
адаптивного управления. //Под ред. Н.Д. Егупова. М.:МГТУ, 2002.
2. Ярушкина Н.Г. Основы теории нечетких и
гибридных систем. М.:Финансы и статистика, 2004.
3. Чернов
В.Г. Нечеткие контроллеры. Основы теории и построения. Владимир: Владим.гос.ун-т,
2003.
4. Заде Л. Понятие лингвистической переменной
и его применение к принятию приближенных решений. М.: Мир,
5. Шкамарда А.Н. Исследование и реализация
метода построения МикроЭВМ функционально-модульной архитектуры.//Дисс. канд.
техн. наук. М.