Средства разработки и реализации верхнего уровня АСУ ТП

Промышленные терминалы

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

Отображение – на Ж.К.Д.

Управление – набор клавиш:

- смена изображения;

- управление процессом.

Большой выбор типоразмеров терминалов с функциональными или программируемыми сенсорными клавишами.

Могут программироваться с IBM PS по RS 232/422, создается до 200-500 экранных форм. Недостаток - ограниченные возможности разрешающей способности экранов, гибкости изображений.

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

Верхний уровень системы реализуется в виде так называемых рабочих (операторских) станций, выполняемых на вычислительных машинах чаще всего ПЭВМ. В зависимости от условий эксплуатации имеют общее исполнение или защищенное (промышленные компьютеры). Укрупненная структура средств ПА комплекса верхнего уровня АСУ ТП может быть представлена Рис. 10 и 11.

Рис. 10

Рис. 11

При создании первых поколений АСУ ТП, разработчики были вынуждены пользоваться средствами создания прикладного программного обеспечения (ППО), совершенно не приспособленными для решения задач такого рода:

- для решения задач вычислительного характера – языки Фортран, Паскаль и др.;

- для программирования логических операций и вычислений, связанных с реализацией всех функций системы, а самое главное, организации функционирования ППО в реальном времени, использовался ”Ассемблер”.

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

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

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

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

Но настоящий рывок в создании действительно интегрируемых пакетов для проектирования АСУ ТП произошел при появлении операционных систем реального времени. Одной из первых таких ОС, нашедших широчайшее применение при создании АСУ ТП, явилась ОС QNX. Она обладает очень высоким быстродействием (до 15мкс/опер.), обеспечивает практически параллельное выполнение всех программных блоков ППО.

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

Среди отечественных следует отметить ППП для программно-технических комплексов “УНИКОНТ”, Северодонецкого НПО “КВАНТОР”, система “СКАТ-X” тверского АО “Центропрограммсистем”, “СИРИУС” московской фирмы “Вира-инвеста”.

Каждая из фирм-производителей программно-технических комплексов создает свои ППП для создания систем супервизорного контроля и сбора данных, ориентированных на специфику создаваемых ими программно-аппаратных средств: Сименс, Allеn-Bradley, Beily и др.

Каждый из этих пакетов ориентирован на определенный класс (марку) технических средств и применение их как универсальных пакетов проблематично.

Одновременно развиваются универсальные ППП, ориентированные на IBM PC и базирующихся на различных операционных системах. Отметим лишь некоторые из них:

TRACC MODE под MS DOS

Real Flex для OC QNX

RTAP на OC UNIX на RISC – IBM

In Touch для OC Windows NT

В целом эти ППП имеют структуру, изображенную на Рис. 12.

Рис. 12

Создание интегрированных ППП позволяет автоматизировать разработку ППО АСУТП, сводя её, по сути, к конфигурированию системы. Оно заключается в описании вход/выходных сигналов и данных, требований к их хранению и архивированию, описанию экранных форм, динамических элементов, трендов и прочих компонентов и функций. Причем для описания каждой из функций, каждого из сигналов и прочих структурных элементов разработчику предоставляется достаточно удобный графический интерфейс. В том случае, когда таковых процедур (алгоритмов) и функций оказывается недостаточно для выполнения поставленных перед системой задач, для создания новых прикладных программных модулей имеются средства программирования на языках высокого уровня, обычно С++ или другие его модификации. Если требуется написать новый драйвер, то для этого также имеется свой инструмент. Сконструированный соответствующим образом программный модуль RUN-time является исполняемым ПРОГРАММНЫМ модулем, загружаемым в персональную ЭВМ с соответствующей операционной системой.

Таким образом, при построении АСУТП с использованием интегрированных ППП программирование (в обычном его понимании) отходит на второй план, уступая место конфигурированию системы. Эту работу в состоянии выполнить разработчик системы, не имеющий спецподготовки в программировании, но освоивший ППП.

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

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

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

Очевидно, что если пакет базируется на специальных операционных системах реального времени (QNX), то он обладает более высокой скоростью реакции. Пакеты под DOS более «тихоходны», имеют наименьший размер базы данных (но они наиболее дешевы). RTАП (unix) имеет огромные возможности БД, но более неповоротлив (в сравнении с RealFlex). Трудно сопоставить названные пакеты с InTouch (Windows NT), так как нет достаточной информации.

Приведенные сравнительные оценки характеристик пакетов – это наше видение ситуации на текущей момент. Чтобы дать более достоверный анализ пакетов, необходимо иметь их в своем распоряжении, работать с ними. Такой возможности мы не имеем. Цены ППП очень высоки. Достаточно сказать, что монитор реального времени (Run-time) этих пакетов стоит около 5000$. Средства же конфигурирования и инструментальные средства (в зависимости от комплектности и типа пакета) могут стоить от 7000 до 25000$.

При стоимости Run-time 5000 и практическом отказе от услуг программистов – затраты на конкретную АСУ ТП резко уменьшаются. Всю картину портят, на первый взгляд, 25000$ затрат на инструментальные средства.

И вот здесь надо хорошо обосновать (с системных позиций) необходимость и выгоду применения ППП:

- надежность и возможность развития ПО АСУ.

- снижение затрат на создание других систем.