Анализируемые аппаратные и программные средства входят в наменклатуру технических и программных средств, используемых модели СМ1820М.

Компоновка контроллера

Построим графики экспертных оценок для процессорных модулей СМ1820. МП3, Octagon 6225 и FastWell CPU686E по различным характеристикам в зависимости от сложности задачи.

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

Наиболее простой задачей будем считать такую конфигурацию ПТК, где используется небольшое количество дискретных и аналоговых сигналов (до 200-т). Эти сигналы не подвергаются какой-либо логической или иной обработке на нижнем уровне (в контроллере), а просто транслируются контроллером от объекта управления на машину верхнего уровня и обратно. Кроме того, данная структура не подразумевает сложной схемы распределения информационных потоков на верхнем уровне. Т.е. контроллер опрашивается одной (или двумя, в случае дублирования) машиной верхнего уровня. При данной конфигурации снижаются требования к производительности интерфейсов передачи данных, т.к. отпадает необходимость именования сигналов непосредственно на нижнем уровне, что снижает объем дополнительной информации, передаваемой вместе со значением сигнала. Также, в рамках "простой задачи" не предъявляется высоких требований к времени реакции системы. Т.е. время реакции определяется от 1 с и более.

Сложной задачей будем считать такие задачи, когда существуют требования быстрого автоматического управления со временем реакции системы менее 500 мс и используется большое количество сигналов (от 200-т). При таких требованиях невозможно осуществлять управление с верхнего уровня, а следовательно необходимо закладывать алгоритмы управления и регулирования на нижнем уровне, что влечет за собой серьезные изменения в требованиях к вычислительным ресурсам контроллера, объему оперативной памяти, производительности интерфейсов обмена данными с верхним уровнем. Также, для обеспечения функций редактирования алгоритмов управления возникает необходимость буквенного именования сигналов на нижнем уровне, а это сильно увеличивает объем дополнительной информации при обмене сигналами. Кроме того, данные требования могут повлечь за собой необходимость использования более ресурсоемких операционных систем, таких как Linux, QNX, Windows CE.

Графики предпочтения для соотношения производительность / сложность задачи представлены на рис.6.

Для наиболее простых задач считаем, что производительность модулей СМ1820. МП3 и Octagon 6225 достаточна. И эти модули являются наиболее оптимальным решением. Мощность модуля Fastwell CPU686E является избыточной, а следовательно он является менее подходящим решением в данном случае. С нарастанием сложности задачи функция принадлежности модулей СМ1820. МП3 и Octagon 6225 линейно убывает, в то время как функция модуля Fastwell CPU686E возрастает и при достижении максимально сложной задачи (1) он становится наиболее приемлемым решением.

СМ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, т.к. реализация подобных задач на двух других модулях может потребовать установки большого количества дополнительного оборудования.

Рис.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.

Рис.8. Графики соответствия операционных систем, которые возможно установить и использовать к сложности задачи

2. Выбор модулей УСО.

Модули УСО могут быть скомпонованы следующими вариантами:

2.1. Наличие или отсутствие контроля линий связи. Недостатки - увеличение стоимости модуля. Преимущества - углубленная диагностика состояний линий связи. Диагностика выхода из строя оборудования.

2.2. Подключение первичных аналоговых сигналов непосредственно к модулям или использование преобразователей для формирования унифицированного сигнала 4 - 20 мА. Использование первичных сигналов повышает точность измерения, увеличивает надежность системы из-за возможности отказа дополнительного оборудования. Недостаток - в некоторых случаях увеличение стоимости кабелей линий связи из-за необходимости борьбы с помехами. Выбор по данному пункту зависит от географического расположения контроллера и объекта управления. Подключение первичных сигналов, например, от термопар к контроллеру целесообразно при длине линии связи не более 80 - 100 метров. При дальнейшем увеличении длины кабеля становится сложно осуществить фильтрацию помех, в следствии чего сильно снижается точность и требуется значительно больше времени для преобразования сигнала. В рамках поставленной задачи длина линий связи не более 20 метров, что дает возможность использовать в измерении первичные сигналы, тем самым, увеличив точность и скорость измерения.

2.3. Наличие гальванической развязки. Обеспечивает большую надежность системы, предохраняя другие модули от бросков напряжения в сигнальных кабелях. Недостаток: усложнение электрической схемы и как следствие - увеличение стоимости модуля.

3. Выбор физических протоколов связи между контроллерами и системами верхнего уровня.

При выборе физических протоколов связи основным критерием, определяющим "сложность задачи" является надежная доставка необходимого количества данных в единицу времени. Будем считать простой задачей (0) тот случай, когда объем данных, передаваемых за 1с не превышает 50 - 100 сигналов, причем сопутствующая сигналу служебная информация сведена к минимуму, т.е. сигналы передаются без имен. Наиболее сложной задачей является тот случай, когда необходимо транслировать большое количество изменений сигналов (от 200-т и больше) за время меньше 500 мс с именами сигналов и их статусами.

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

3.2. Протокол RS-485. Промышленный протокол. Существует возможность организации сети, но не в равноправном режиме. Т.е. при такой организации машина верхнего уровня должна выступать в качестве master и отправлять запросы устройствам slave (контроллерам), которые могут лишь отвечать на запросы. Данный протокол хорош так же тем, что обеспечивает большую длину на линии связи (до 1,5 км). Сравнительно не большая скорость передачи данных ограничивает возможности по трансляции сигналов. Поэтому, данный протокол является оптимальным для применения в системах среднего уровня сложности.

3.3. Протокол Ethernet. Обеспечивает высокоскоростную передачу данных на большие расстояния (особенно при преобразовании интерфейса в волоконно-оптическую сеть). Является наиболее часто используемым протоколом как в бытовых, так и в промышленных сетях. Обеспечивает высокую надежность при передаче данных.

Графики предпочтений при выборе протоколов связи представлены на рис.9 - 11.

Рис.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, но его использование становится более оправданным при усложнении задачи.

Рис.10. Соотношение стоимости реализации протокола к сложности задачи

При рассмотрении вопроса стоимости реализации протоколов связи (рис.10) играют роль те же факторы, что были описаны с технической точки зрения. Использование RS-232 и RS-485 являются наиболее дешевыми решениями для простых задач, т.к. они изначально поддержаны и программно и аппаратно при любой структуре системы.

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

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

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

Надежный обмен данными (рис.11) при реализации простых задач возможен при использовании всех трех протоколов связи по описанным выше причинам.

По тем же причинам, при нарастании сложности задачи наиболее приоритетным становится протокол Ethernet, а показатели по RS-232 и RS-485 падают из-за необходимости установки дополнительного оборудования и из-за усложнения программного обеспечения.

Рис.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-системой и нижнем уровнем исходя из различных критериев: наиболее удобные варианты с технической точки зрения и с точки зрения трудозатрат на реализацию.

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

Рис.13. Трудозатраты по организации обмена данными в зависимости от сложности задачи

При построении графиков предпочтений вариантов организации обмена данными с НУ с точки зрения трудозатрат на реализацию (рис.13) видно, что использование DRS является наиболее удобным вариантом при любой сложности задачи и значение функции принадлежности равно 1 и не меняется. Использование скриптовых языков для простых задач является столь же удобным вариантом, но значение функции падает до 0 линейно при возрастании сложности задачи из-за необходимости усложнять программы для реализации всех необходимых требований. Использование OPC является самым трудоемким решением при любой сложности задачи и следовательно, значение функции принадлежности не меняется и остается близким к 0 для любой сложности задачи.

5. Варианты реализации распределенных серверов верхнего уровня.

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

Варианты реализации такого обмена могут быть следующими:

5.1 Каждый сервер связывается непосредственно с каждым контроллером. Данный способ имеет недостаток в том, что линия связи должна иметь достаточную производительность или, в случае использования интерфейса RS485, контроллер, т.к. он выступает в режиме Slave, контроллер должен иметь отдельный физический интерфейс для каждого потребителя верхнего уровня. Кроме того, подобный способ потребует значительных затрат со стороны процессорного модуля контроллера, для обработки индивидуальных запросов для каждого потребителя.

5.2 Данные с систем нижнего уровня запрашиваются службой DRS, которая является концентратором и транслирует эти данные для всех потребителей верхнего уровня. Подобный способ увеличивает нагрузку на процессор сервера, что является менее критичным, т.к. запас мощности сервера многократно выше, чем у контроллера. Недостатком является снижение надежности системы, но эта проблема может быть решена резервированием серверов и линий связи с нижним уровнем. Т.е. каждый контроллер имеет 2 линии связи и опрашивается по ним разными серверами. Далее, данные могут быть оттранслированы на неограниченное число систем верхнего уровня с использованием высокоскоростных интерфейсов (Ethernet).

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

Рис.14. Реализация распределенности в зависимости от сложности задачи

Рассмотрим графики экспертных оценок реализации распределенности данных на ВУ в зависимости от сложности задачи (рис.14). Наиболее удобным в реализации и наиболее быстродействующим вариантом является использование службы DRS, т.к. функции для распределения потоков данных между системами верхнего уровня закладывались во время разработки службы. Организация распределения данных за счет организации индивидуального канала связи для каждого клиента верхнего уровня до каждого контроллера является приемлемым вариантом для самых простых задач и далее функция принадлежности линейно убывает, т.к. при возрастании сложности задач подобный способ требует большого количества вычислительных ресурсов контроллера и перегружает линии связи. Распределение данных средствами SCADA системы является приемлемым вариантов при любом уровне сложности задачи, но менее удобным чем DRS, а следовательно значение функции остается неизменным, но это значение равно 0.5, при том, что вариант DRS имеет значение 1.

2.3 Оптимизация. Результаты расчетов