Прикладное ПО: CASE и SCADA-пакеты Известны два пути разработки прикладного программного обеспечения систем управления: 1) создание собственного прикладного ПО с использованием средств традиционного программирования (стандартные языки программирования, средства отладки и т.д.); 2) использование для разработки прикладного ПО существующих (готовых) инструментальных средств. Первый вариант является наиболее трудоемким. Применение высокоуровневых языков требует соответствующей квалификации разработчиков в теории и технологии программирования, знания особенностей конкретной операционной системы, тонкостей аппаратного обеспечения (контроллеров). С точки зрения основных критериев - стоимости и времени разработки - этот вариант неприемлем в большинстве случаев. Второй вариант является более предпочтительным, так как на сегодняшний день уже создано несколько десятков инструментальных систем, хорошо поддерживаемых, развиваемых и нашедших применение при создании десятков и сотен тысяч проектов автоматизации. Эти проверенные временем программные средства упрощают (разработчики интерфейсов - не высококлассные программисты, а специалисты по автоматизации), ускоряют и значительно удешевляют процесс разработки. С точки зрения области применения готовые инструментальные средства можно разделить на два класса: 1) средства, ориентированные на разработку программ управления внешними устройствами, контроллерами - CASE-системы (Computer Aided Software Engineering); 2) средства, ориентированные на обеспечение интерфейса оператора/ диспетчера с системой управления – SCADA-системы(Supervisory Control And Data Acquisition - диспетчерское управление и сбор данных). Фирмы, производящие оборудование для построения систем автоматизации, всегда стремились сопровождать свою продукцию набором программных инструментов, с помощью которых пользователь по определенным правилам и соглашениям мог бы описывать логику работы контроллера. На раннем этапе развития этих программных средств набор поддерживаемых ими функций обеспечивался нестандартными языками. Со временем правила и соглашения совершенствовались и на определенном этапе были оформлены в виде специальных языков программирования, образовав то, что сейчас называется CASE-инструментарием. В 1992 году Международная Электротехническая Комиссия (МЭК, IEC - International Electrotechnical Commission,) взяла под контроль процессы, связанные с развитием этого типа прикладного ПО. Были выдвинуты требования открытости системы, выполнение которых позволило бы унифицировать программные средства и упростить разработку: 1) возможность разработки драйверов для контроллеров самими пользователями, т.е. сопровождение программных продуктов по программированию контроллеров специальными инструментальными средствами; 2) наличие коммуникационных средств (интерфейсов) для взаимодействия с другими компонентами системы управления; 3) возможность портации ядра системы на ряд программно-аппаратных платформ. К CASE-пакетам относятся: 1) RSLogix 500, RS Logix 5, RSLogix 5000 фирмы Rockwell Software для программирования контроллеров различных семейств Allen-Bradley; 2) DirectSOFT для контроллеров семейства Direct Logic фирмы Koyo; 3) пакеты PL7и Concept-ПО для программирования контроллеров различных семейств компании Schneider Electric; 4) пакеты STEP 5, STEP 7 Micro, STEP 7 для программирования контроллеров семейств S5 и S7 фирмы Siemens; 5) пакет Toolbox для конфигурирования контроллеров семейства Moscad; 6) пакет TelePACEдля программирования контроллеров серий TeleSAFE Micro 16 и SCADAPack фирмы Control Microsystems; 7) пакет CoDeSys разработан фирмой 3S (Smart Software Solutions). К SCADA-пакетам относятся: 1) Trace Mode/Трейс Моуд (AdAstrA) - Россия; 2) InTouch (Wonderware) - США; 3) FIX (Intellution ) - США; 4) Genesis (Iconics Co) - США; 5) Factory Link (United States Data Co) - США; 6) RealFlex (BJ Software Systems) - США; 7) Sitex (Jade Software) - Великобритания; 8) Citect (CI Technology) - Австралия; 9) WinCC (Siemens) - Германия; 10) RTWin (SWD Real Time Systems) - Россия; 11) САРГОН (НВТ - Автоматика) - Россия; 12) MIK$Sys (МИФИ) - Россия; 13) Cimplicity (GE Fanuc) - США; 14) RSView (Rockwell Automation) - США и многие другие. Комплекс CoDeSys Комплекс CoDeSys разработан фирмой 3S (Smart Software Solutions). Это универсальный инструмент программирования контроллеров и встраиваемых систем на языках МЭК 61131-3, не привязанный, к какой-либо аппаратной платформе и удовлетворяющий современным требованиям быстрой разработки программного обеспечения. Ядро системы исполнения CoDeSys написано на языке С. Существует несколько модификаций оптимизированных для различных микропроцессоров (включая PC-совместимые). Для привязки к конкретному ПЛК требуется адаптация, касающаяся низкоуровневых ресурсов — распределение памяти, интерфейс связи и драйверы ввода-вывода. Среди особенностей данного пакета можно отметить следующее. 1) Прямая генерация машинного кода. Генератор кода CoDeSys — это классический компилятор, что обеспечивает очень высокое быстродействие программ пользователя. 2) Полноценная реализация МЭК-языков, в некоторых случаях даже расширенная. 3) «Разумные» редакторы языков построены таким образом, что не дают делать типичные для начинающих МЭК программистов ошибки. 4) Встроенный эмулятор контроллера позволяет проводить отладку проекта без аппаратных средств. Причем эмулируется не некий абстрактный контроллер, а конкретный ПЛК с учетом аппаратной платформы. При подключении реального контроллера (режим online) отладчик работает аналогичным образом. 5) Встроенные элементы визуализации дают возможность создать модель объекта управления и проводить отладку проекта без изготовления средств имитации. 6) Очень широкий набор сервисных функций, ускоряющих работу программиста. Строение комплекса CoDeSys Базовый состав комплекса программирования ПЛК состоит из двух обязательных частей: система исполнения и рабочее место программиста. Система исполнения функционирует в контроллере и кроме непосредственно исполнения управляющей программы обеспечивает загрузку кода прикладной программы и отладочные функции. Система исполнения должна иметь связь с компьютером рабочего места программиста. Как физически организована связь ПК и ПЛК, не столь важно. В простейшем случае ПЛК подключается к компьютеру через стандартный com-порт (RS232) нуль-модемным кабелем. В условиях цеха может использоваться более помехоустойчивый и дальнобойный интерфейс (RS422, RS485 или токовая петля). В комплексе CoDeSys посредником между средой разработки и ПЛК служит специальное приложение — шлюз связи (gateway). Шлюз связи взаимодействует с интегрированной средой через Windows сокет-соединение, построенное на основе протокола TCP/IP. Такое соединение обеспечивает единообразное взаимодействие приложений, работающих на одном компьютере или в сети (рис. 6.1).  Рисунок – Соединение интегрированной среды программирования с ПЛК По умолчанию шлюз связи настроен на локальную работу (local host) и запускается автоматически при установлении связи с ПЛК из интегрированной среды. Для соединения с ПЛК через com-порт достаточно только настроить параметры драйвера интерфейса в соответствии с руководством по применению ПЛК (порт, скорость, контроль паритета и число стоп-бит). Благодаря этому программист может абсолютно полноценно работать на удаленном компьютере. Причем удаленность не ограничивается рамками локальной сети. ПК, выполняющий задачу шлюза связи, может одновременно взаимодействовать с ПК программиста через Интернет и с ПЛК через модемное соединение. SCADA-пакеты Программное обеспечение типа SCADA предназначено для разработки и эксплуатации автоматизированных систем управления технологическими процессами. SCADA-системы позволяют минимизировать участие операторов/диспетчеров в управлении процессом, но оставляют за ними право принятия решения в особых ситуациях. Одной из первых задач, поставленных перед разработчиками SCADA, стала задача организации многопользовательских систем управления, то есть систем, способных поддерживать достаточно большое количество АРМ пользователей (клиентов). В результате появилась клиент - серверная технология или архитектура. Рисунок - Клиент-серверная архитектура. Клиент - серверная архитектура характеризуется наличием двух взаимодействующих самостоятельных процессов - клиента и сервера, которые, в общем случае, могут выполняться на разных компьютерах, обмениваясь данными по сети. Клиент-серверная архитектура предполагает, что вся информация о технологическом процессе от контроллеров собирается и обрабатывается на сервере ввода/вывода (сервер базы данных), к которому по сети подключаются АРМ клиентов. Под станцией-сервером в этой архитектуре следует понимать компьютер со специальным программным обеспечением для сбора и хранения данных и последующей их передачи по каналам связи оперативному персоналу для контроля и управления технологическим процессом, а также всем заинтересованным специалистам и руководителям. По определению сервер является поставщиком информации, а клиент – ее потребителем (рабочие станции операторов/диспетчеров, специалистов, руководителей). Количество операторских станций, серверов ввода/вывода (серверов БД) определяется на стадии проектирования и зависит, прежде всего, от объема перерабатываемой в системе информации. Для небольших систем управления функции сервера ввода/вывода и станции оператора (HMI) могут быть совмещены на одном компьютере. В сетевых распределенных системах средствами SCADA/HMI стало возможным создавать станции (узлы) различного функционального назначения: · станции операторов/диспетчеров; · серверы с функциями HMI; · “слепые” серверы (без функций HMI), · станции мониторинга (только просмотр без прав на управление) для специалистов и руководителей и другие. SCADA-программы имеют в своем составе два взаимозависимых модуля: · Development (среда разработки проекта); · Runtime (среда исполнения). В целях снижения стоимости проекта эти модули могут устанавливаться на разные компьютеры. Например, станции оператора, как правило, являются узлами Runtime (или View) с полным набором функций человеко-машинного интерфейса. При этом хотя бы один компьютер в сети должен быть типа Development. На таких узлах проект разрабатывается, корректируется, а также может и исполняться. Некоторые SCADA-системы допускают внесение изменений в проект без остановки работы всей системы. Программное обеспечение SCADA-серверов позволяет создавать полный проект системы управления, включая базу данных и HMI. Важным аспектом в структурном построении сетевых систем управления является централизованная или распределеннаяструктура базы данных реального времени (База данных, обработка данных в которой, происходит по принципу реального времени). В одних случаях для доступа к данным на компьютере-клиенте создается «своя» база данных, копируемая с удаленных серверов. Дублирование данных может привести к определенным проблемам. Например, при модификации базы данных с такой организацией, например, при введении дополнительной переменной потребуются изменения в каждой сетевой копии, использующей эту переменную. В других случаях компьютерам-клиентам не требуются копии баз данных. Они получают необходимую им информацию по сети от сервера, в задачу которого входит подержание базы данных. Серверов может быть несколько, и любая часть данных хранится только в одном месте, на одном сервере. Поэтому и модификация базы данных производится только на одном компьютере – сервере базы данных, что обеспечивает ее единство и целостность. Такой подход к структурному построению системы снижает нагрузку на сеть. С точки зрения структурного построения SCADA-пакетов различают: 1) системы, обеспечивающие полный набор базовых функций HMI; 2) системы, состоящие из модулей, реализующих отдельные функции HMI. Системы, обеспечивающие полный набор базовых функций, могут комплектоваться дополнительными опциями, реализующими необязательные в применении функции контроля и управления. Во втором случае система создается полностью модульной (сервер ввода/вывода, сервер алармов, сервер трендов, и т.д.). Для небольших проектов все модули могут исполняться на одном компьютере. В проектах с большим количеством переменных модули можно распределить на несколько компьютеров в разных сочетаниях. Вариант клиент-серверной архитектуры такой системы представлен на рисунке 2. Рисунок 2 - Архитектура модульной SCADA. В клиент-серверной архитектуре системы управления, представленной на рисунке 2, функции сбора и хранения данных, управления алармами и трендами распределены между тремя серверами. Функция HMI реализуется на станциях-клиентах. В качестве примера можно рассмотреть SCADACitect. Данная системаимеет в своем составе пять функциональных модулей (серверов или клиентов): 1) I/O - сервер ввода/вывода. Обеспечивает передачу данных между физическими устройствами ввода/вывода и другими модулями Citect. 2) Display - клиент визуализации. Обеспечивает операторский интерфейс: отображение данных, поступающих от других модулей Citect, и управление выполнением команд оператора. 3) Alarms - сервер алармов. Отслеживает данные, сравнивает их с допустимыми пределами, проверяет выполнение заданных условий и 4) отображает алармы на соответствующем узле визуализации. 5) Trends - сервер трендов. Собирает и регистрирует трендовую 6) информацию, позволяя отображать развитие процесса в реальном 7) масштабе времени или в ретроспективе. 8) Reports - сервер отчетов. Генерирует отчеты по истечении 9) определенного времени, при возникновении определенного события или по запросу оператора. В одной сети можно использовать только один сервер алармов, сервер трендов и сервер отчетов. В то же время допускается использование нескольких серверов ввода/вывода (I/O Server). Количество компьютеров с установленным модулем Display(обеспечивающим операторский интерфейс) в сети практически не ограничено. |