Построение информационно-управляющих систем реального времени на базе операционной системы QNX

 

Основным назначением любой операционной системы (ОС) является управление ресурсами компьютера. Все процессы в системе: планирование выполнения прикладных программ, запись файлов на диск, пересылка данных по сети и т.д. должны выполняться как можно более единообразно и бесконфликтно.

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

Для приложений, работающих в режиме реального времени, QNX является идеальной операционной системой. Она удовлетворяет всем основным требованиям, предъявляемым к системам реального времени: в ней реализован многозадачный режим, приоритетно-управляемое планирование и быстрое переключение контекста.

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

Уникальная эффективность, модульность и простота системы QNX определяется следующими параметрами:

– архитектурой ядра;

– взаимодействием между процессами посредством сообщений.

 

Архитектура ядра системы QNX

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

 

Ядро системы QNX

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

В системе QNX ядро является действительно ядром. Прежде всего, как и подобает ядру операционной системы реального времени, оно имеет небольшой размер – менее 8 кбайт. На ядро ОС QNX возложено выполнение только двух основных функций:

1. Передача сообщений – ядро QNX реализует передачу всех сообщений между всеми процессами во всей системе;

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

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

 

Системные процессы

Все функции, выполняемые ОС QNX, за исключением функций ядра, реализуются стандартными процессами. В типичной конфигурации системы QNX имеются следующие системные процессы:

1) администратор процессов (Proc);

2) администратор файловой системы (Fsys);

3) администратор устройств (Dev);

4) сетевой администратор (Net).

Системные процессы и процессы пользователя

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

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

Действительно, грань между ОС и прикладными программами весьма условна. Единственным принципиальным отличием системных процессов от прикладных является то, что системные процессы управляют ресурсами системы, предоставляя их прикладным процессам.

 

Драйверы устройств

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

Поскольку драйверы выполняются как стандартные процессы, то добавление нового драйвера в систему QNX не влияет на работу других компонентов ОС. Единственное изменение, которое происходит в среде QNX – это запуск нового драйвера.

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

Связь между процессами

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

Связь между процессами (interprocess communication – IPC) является ключом к разработке приложений, представляющих собой набор взаимосвязанных процессов, в котором каждый процесс выполняет одну строго определенную функцию.

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

Операционная система с передачей сообщений

QNX стала первой коммерческой ОС данного класса, в которой IPC основан на принципе передачи сообщений. Именно благодаря глобальному использованию передачи сообщений во всей системе, ОС QNX обладает присущей ей мощностью и простотой.

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

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

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

 

 

QNX как сеть

В основе собственной сети ОС QNX Neutrino лежит протокол Qnet, который реализуется в виде сети сильносвязанных машин. Этот протокол позволяет машинам эффективно обмениваться ресурсами с минимальными накладными расходами. В сети Qnet можно пользоваться стандартными утилитами (cp, mv,…) для управления файлами в любом месте сети. Кроме того, протокол Qnet не выполняет аутентификацию удаленных запросов, так как файлы защищаются обычными правами доступа, применяемыми для пользователей и пользовательских групп. Вы можете не только иметь доступ к файлам, но и запускать или останавливать процессы (в том числе различные администраторы) на любой машине в сети Qnet.

Возможности распределенных вычислений в сети Qnet позволяют эффективно выполнять следующие задачи:

1) использовать удаленную файловую систему,

2) масштабировать приложения с невероятной легкостью,

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

4) с легкостью переносить выполнение приложения с одного процессора или симметричной мультипроцессорной машины на несколько однопроцессорных машин, и распределять все процессы между этими процессорами,

5) разбивать приложения на несколько процессов, выполняющих разные функции (при этом процессы координируют свою работу с помощью механизма обмена сообщениями),

6) использовать собственную службу удаленного вызова процедур сети Qnet.

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

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

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

Однокомпьютерная модель

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

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

 

Гибкая сетевая обработка

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

Каждому узлу сети QNX присвоен номер, являющийся его идентификатором. Этот номер служит единственным признаком, позволяющим определить, работает ли QNX как сеть или как однопроцессорная ОС.

Такая высокая степень прозрачности является еще одним примером исключительной мощности архитектуры ОС QNX, основанной на передаче сообщений. Во многих операционных системах такие функции, как сетевая обработка, связь между процессами (IPC) или даже передача сообщений, выполняются не ядром, а надстройкой над ОС. В результате получается интерфейс «двойного стандарта», в котором отдельно организована связь между процессами и совершенно иначе – доступ к закрытому монолитному ядру.

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

 

На базе сетевой операционной системы реального времени QNX построен специализированный пакет программ для построения АСУ ТП с использованием стандартных вычислительных техник. Базовый пакет Real Flex (средство построения) представляет собой весь необходимый набор средств для создания программного обеспечения средств АСУ ТП.

 

 

SCADA – системы

 

Выбор SCADA-системы для конкретного комплекса технологических процессов – это многокритериальная задача, связанная с поиском компромиссного решения относительно надежности, стоимости, технического уровня, удобства HMI, затратами на сервисное обслуживание.

Ниже перечислены только некоторые из популярных на западном и российском рынках SCADA-систем, имеющих поддержку в России[5]:

 

Таблица 1.1

SCADA	Фирма изготовитель	Страна
Factory Link	United States DATA Co.	США
InTouch	Wonderware	США
Genesis	Iconics	США
WinCC	Siemens	Германия
Realflex	BJ Software Systems	США
Sitex	Jade Software	Англия
FIX	Intellution	США
Trace Mode	AdAstra	Россия
RSView	Rockwell Software Inc.	США
…	…	…

 

 

Общий анализ подобных пакетов позволяет сформулировать некоторые основные возможности и характерные особенности SCADA-систем.

 

Существенное влияние на выбор SCADA-системы оказывают следующие параметры:

1) характеристики, особенности динамики объекта автоматизации;

2) учет использования SCADA-системы на других объектах автоматизации;

3) компьютерная платформа, число и расположение АРМ;

4) число, типы контроллерного оборудования, датчиков, исполнительных механизмов;

5) тип интерфейсов, протоколов, сетевая архитектура;

6) число измеряемых и управляющих величин на АРМ;

7) степень защиты, надежность.

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

 

SIMATIC WinCC. WinCC – это сокращение от Windows Control Center (Центр управления Windows), он предоставляет вам все возможности для надежного управления вашим процессом в стандартной среде Windows NT.

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

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

В WinCC встроена стандартная база данных Sybase SQL Anywhere, в которой хранятся все списковые данные проектирования и процесса. Доступ к базе данных WinCC возможен без всяких проблем с помощью языка структурированных запросов к базе данных SQL или через драйвер ODBC.

 

RealFlex [6] – это программный продукт автоматизации, работающий в жестком реальном

времени. Масштаб использования: от мини-проектов под Windows до сложных мультиплатформенных систем.

Основные преимущества RealFlex:

1. Надежность и проверенность временем. RealFlex4 развивается с 1982 года, RealFlex6 с 2001. Сервера RealFlex базируются на надежных операционных системах реального времени QNX4, QNX6/Neutrino.

2. Высокая производительность. Программное обеспечение с самого начала ориентировано на работу с большими проектами и обработку большого количества данных в единицу времени. RealFlex4 поддерживает по 32K точек каждого типа. RealFlex6 спроектирован для поддержки 4M точек каждого типа. В данный момент ограничение, продиктованное структурой проекта FlexView, 64K точек каждого типа.

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

4. Поддержка резервирования. RealFlex4 поддерживает резервирование серверов. Т.е. 2 RealFlex4 сервера могут устанавливаться в режиме 'failover', обеспечивающем автоматический старт второго сервера, в случае остановки/поломки основного. RealFlex6 имеет продвинутую hot/standby архитектуру, отличающуюся повышенной скоростью переключения standby-cервера в активный режим. Достигается это фактической параллельной обработкой поступающих данных и загруженностью всех необходимых модулей в память. По большей части время переключения ограничено в основном временем обнаружения неисправности. В среднем время переключения RealFlex6 - 2 секунды.

5. Унифицированная система резервного копирования (“бэкапа”) сервера RealFlex на ftp-сервер, вклющая RealFlex4 и RealFlex6. Восстановление происходит очень быстро, что является немаловажным фактором обеспечения надежности. Например, для восстановления RealFlex4 производится загрузка со специального CD, оператор вводит 3-4 команды, далее все время восстановления ограничено в основном пропускной способностью сети, т.е. временем загрузки упакованного бекапа системы с ftp-cервера и одновременной распаковки его на жесткий диск. При этом происходит восстановление операционной. Восстановление RealFlex6 требует установки операционной системы с инсталляционного CD RealFlex, но эта операция также требует всего несколько минут. Поэтому восстановление RealFlex6 также возможно за очень короткий промежуток времени.

6. Репликация инсталяций. Подсистема “бэкапа”/восстановления позволяет производить быструю репликацию инсталляций. Если вам требуется несколько однотипных серверов, тогда может быть инсталлирован и настроен один сервер, а после этого сделан “бэкап” и восстановление этой инсталляции на несколько компьютеров.

7. Независимость от третьестороннего программного обеспечения. Программное обеспечение RealFlex использует минимум внешнего программного обеспечения. Соответственно его надежность и быстродействие не ограничиваются третьесторонними SQL-серверами или другим подобным программным обеспечением. Кроме того, это улучшает пользовательскую поддержку, поскольку вас не пошлют, например, в микрософт.

8. Гибкость при создании проектов. Проекты могут создаваться как на высоком уровне, встроенные средства RealFlex и CSL, так и на низком уровне. Для программирования может применяться Custom Development Kit (C/C++).

9. Мультиплатформенность. В данный момент существуют версии RealFlex4 под QNX4, RealFlex6 под Neutrino и RealWin – под Windows. В зависимости от потребностей (а также требований к проверенности, соображений консерватизма или по экономическим причинам) может быть использована версия под любую из операционных систем.

10. Преемственность проектов. Проекты, созданные для RealFlex4 автоматически конвертируются без дополнительных усилий в проекты для RealFlex6 или RealWin.

11. Мультиобъеденение удаленых мест в единую сеть. Возможность подключения к одному серверу большого количества удаленных мест. Множество операторских мест на базе FlexView подключаются к серверу RealFlex4/RealFlex6 или RealWin одновременно.

12. Универсальность. Одно и то же операторское программное обеспечение (FlexView или набор модулей FlexWin) используется для подключения к серверу на базе любой из платформ. Соответственно софт хорошо оттестирован и проекты выглядят одинаково.

13. Зональные ограничения. FlexView позволяет описывать в проекте так называемые зоны, определяющие доступ к различным элементам проекта операторов. Иными словами каждый оператор в зависимости от настроек видит не весь проект, а только разрешенные дисплеи и тэги. Отдельно может ограничиваться возможность управления. Т.е. тэг виден, но управление разрешается отдельным флагом.

14. OPC стандарт поддерживают RealFlex4 и RealFlex6. Т.е. возможно получение RealFlex-ом данных с OPC-серверов, а также работа RealFlex в режиме OPC-сервера.

15. Масштабируемость и объединение проектов, RealFlex-ов между собой. Программное обеспечение RFLink, позволяющее связь RealFlex-ов между собой в "кластер". При этом RealFlex-ы между собой реплицируют часть или всю базу данных и позволяют управление, подтверждение тревог, установку информационных/управляющих тегов, ручное переписывание значений тэгов на удаленном сервере. При этом благодаря унификации протокола взаимодействия возможно объединение в кластеры как однотипных, так и разнотипных RealFlex-ов. Т.е. могут связываться между собой как RealFlex4-RealFlex4, RealFlex6-RealFlex6, так и RealFlex4-RealFlex6.

16. Визуализация и наглядность. Под RealFlex4 и RealFlex6 существует собственный графический интерфейс. Дисплеи для RealFlex4/RealFlex6/FlexView имеют одинаковый формат, а также отображаются максимально одинаково, насколько это возможно для разных платформ.

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

18. Руссификация продукции, локализация. RealFlex4 и продукты FlexView (FlexWin) руссифицированны. Руссификация RealFlex6 планируется в ближайшее время.

19. Отчеты в Excel. RealFlex поддерживает возможность получения отчетов в формате Excel.

20. База даннных SQL. FlexBase – предоставляет возможность импортирования в реальном режиме времени исторических данных в SQL базу данных, что в свою очередь позволяет производить интеграцию с иными системами управления предприятия, менеджмента и планирования.

С помощью базового пакета Real Flex реализуется выполнение нескольких функций.

1. Сбор и обработка данных в реальном времени. Real Flex поддерживает несколько типов устройств управления процессами:

- логический программируемый контроллер (PLC);

- одноконтурные контроллеры (SLC);

- удалённые терминальные устройства (TRU);

- разнообразные анализаторы;

- измерительные приборы.

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

2. Создание и редактирование баз данных (БД).

В системе Real Flex существует таблица базы данных, которая интерактивно расширяется в темпе реального времени.

3. Обработка сообщений.

Процессор Real Flex обеспечивает пять уровней приоритета сигнала:

- прямой доступ к последнему возникшему сигналу;

- индивидуальный или полный запрет сигналов;

- формирование сводок по текущим активным сигналам и их предыстории;

- выбор элементов сигнала (события по заданному критерию), их распечатка по запросу или по заданному расписанию;

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

4. Создание диаграмм анализа состояния и конфигурации систем.

Real Flex поддерживает высокоскоростной анализ состояния системы в реальном времени с учётом предыстории. На одном экране дисплея может быть выведено до восьми диаграмм состояния.

5. Графические построения. Система Real Flex обеспечивает проектирование и конструирование графических образов.

6. Редактирование символов, в том числе и создание пользователями своих символов.

7. Создание отчетов. Real Flex предусматривает создание и печать отчета в стандартной форме, создание заказного отчета по требованиям заказчика.

В стандартную форму отчета входит:

- сводка коммуникаций;

- сводка активных тревог;

- сводка сигналов событий;

- сводка устройств управления процессами;

- сводка выбранных сигналов событий.

Кроме базового пакета Real Flex существует ряд других программ, например:

- BJScan, обеспечивающей взаимодействие по каналам связи;

- LunFlex, являющейся версией Real Flex для функционирования на узле локальной сети;

- Failever, управляющей горячим резервированием;

- Renflex, обеспечивающей доступ удалённого пользователя к данным реального времени станции Real Flex;

- Temflex, предоставляющей возможность работы с окнами Real Flex удаленному пользователю;

- RealFlex/DDE Bridge, управляющей обменом данными между программами Real Flex и Windows Bridge.

 

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

 

Программный комплекс Factory Suite компании Wonderware предназначен для разработки систем автоматизации промышленных предприятий и состоит из следующих взаимодействующих друг с другом компонентов: InTouch – SCADA-система для визуализации и управления технологическими процессами; IndustrialSQL Server – реляционная СУБД реального времени; InControl – пакет для управления контроллерным оборудованием; Scout – средство программирования через Internet/Intranet – сети; InTrack – система управления производством; InBatch – система управления процессами дозирования и смешивания.

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

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

InTouch представляет набор инструментов для графического отображения состояния процесса. Графические объекты могут быть анимированы с использованием следующих динамических атрибутов: цвет, положение, мигание, вращение, заполнение, указатели или процедуры для активации процедуры пользователя. SCADA InTouch позволяет организовать взаимодействие с другими приложениями, используя стандартные механизмы: DDE – обмен (большинство серверов ввода/вывода поддерживает DDE – обмен для передачи данных в InTouch-приложение); OLE – технология (используется для взаимодействия с некоторыми компонентами FactorySuite и другими пользовательскими приложениями); OPC – программы.

 

Широкие возможности сетевого обмена данными предоставляет пользователям SCADA-система Advantech Studio (AStudio) фирмы Advantech. В данную SCADA-систему заложена концепция – сделать информацию о производственных процессах более доступной для всех подразделений предприятия, его клиентов, обеспечить возможность работы с этой информацией в любое время и в любом месте.

Это позволяет решать следующие задачи:

1) контроль производства в реальном масштабе времени;

2) доступ к технологической информации из любого отдела предприятия или удаленного офиса, возможность оперативного принятия решений не только на технологическом уровне, но и на уровне управления предприятием;

3) интеграция данных АСУ ТП с программными системами управления предприятием;

4) удаленный мониторинг, необходимый в задачах диспетчеризации транспортных предприятий, систем жизнеобеспечения зданий; удаленная диагностика оборудования, оперативное оповещение персонала о предаварийных ситуациях и авариях;

5) улучшение сервиса при обслуживании клиентов путем предоставления информации в реальном масштабе времени о прохождении заказа, состоянии склада.

Все уровни предприятия: производственные цеха, офисы, филиалы, мобильный персонал, клиенты, – объединены одной сетью и используют Internet-технологии для доступа к информации. Ключевой элемент SCADA-системы AStudio – это Web-сервер. Пакет AStudio представляет программное обеспечение, совмещающее функции SCADA-систем. К его основным свойствам относятся: среда исполнения как для Windows XP/2000, так и для ОС для встраиваемых систем Windows CE; возможность публикации данных в виде HTML-страниц, встроенный Web-сервер, совместимый с MS Internet Explorer, Netscape, подключение по сети или телефонной линии; OPC-совместимость, поддержка технологии клиент-сервер; более 100 встроенных драйверов устройств; поддержка формата XML; передача сообщений по электронной почте; графический редактор, библиотека графических символов; возможность построения графиков на основе текущей и накопленной информации; DDE-совместимость; гибкая система формирования отчетов; возможность удаленного создания, редактирования и загрузки проектов; динамическое переключение языка проекта; большая библиотека встроенных функций для создания скриптов, значительно расширяющая возможности системы; гибкая система ограничения доступа к информации.

SCADA-система AStudio имеет базу данных тегов – единое хранилище всех переменных, используемых в проекте. Редактор графических форм AStudio имеет набор инструментов для создания информационных форм: статические объекты – кнопки, геометрические фигуры, текст, импорт готовых графических изображений, библиотека готовых производственных технологических символов; динамические свойства – команды, гиперссылки, столбцовые диаграммы, ввод/вывод числовых значений и текста, изменение цвета, положения на экране и размера по условию, вращение линий и т.п.; активные объекты – окно сообщений об авариях, окно вывода текущей и архивной информации в виде графиков, списки с возможностью выбора числового значения или сообщения, окна вывода сообщений по условию и т.д. Имеется возможность добавления в экранные формы ActiveX компонентов.

В AStudio поддерживается собственный текстовый формат архивных файлов, возможно чтение/запись данных в БД, совместимые с ODBC. Имеется возможность получения информации об авариях и тревогах в реальном масштабе времени, сортировка и фильтрация сообщений, печати в реальном масштабе времени. В AStudio имеется функция включения передачи информации по e-mail. AStudio предусматривает возможность создания пользовательских скриптов – последовательности выражений со встроенными функциями, условиями, циклами. Скрипты можно привязывать к экранным формам, оформлять как отдельные задачи, выполняющиеся в фоновом режиме.

SCADA-система AStudio имеет встроенную библиотеку из более чем ста драйверов аппаратных средств под стандартные протоколы: Modbus, Modbus on TCP/IP, Profibus-DR и др. Пакет AStudio поддерживает технологию OPC и может быть как клиентом, так и сервером OPC. Обмен данными между приложениями Windows и AStudio возможен средствами ODBC, TCP/IP, DDE.

 

Одной из популярных SCADA-систем для промышленной автоматизации является система Trace Mode 5, 6.0 – интегрированный инструментальный пакет для разработки АРМ оператора АСУ ТП, а также для программирования ПЛК (Softlogic система). Система Trace Mode была разработана в 1993 г. фирмой AdAstra Research Group, Ltd (Россия, г. Москва). Пятая версия интегрированной SCADA и Softlogic систем Trace Mode 5 основана на DCOM-базовой технологии корпорации Microsoft (США), положенной в основу всех ее современных продуктов (Windows NT, Windows 2000, SQL Server, MS Office и др.). Основу Trace Mode составляют мощный сервер и БД, оптимизированная для работы в реальном масштабе времени (рис. 1.4). Все внутренние и внешние программные интерфейсы максимально стандартизированы. Связь с PLC осуществляется через интерфейсы OPC и DDE, а также через собственный высокопроизводительный интерфейс T-COM. Взаимодействие сервера Trace Mode с клиентами и независимыми приложениями также производится через OPC, DDE и DCOM. Для связи Trace Mode с СУБД используется стандарт SQL/ODBC. Графические формы отображения информации пользователь может разработать не только в редакторах Trace Mode, но и на языках программирования Visual C, Visual Basic, Borland Delphi – как ActiveX объекты.

 

Рис. 1.4. Архитектура SCADA-системы Trace Mode 5

 

Система разработки Trace Mode 5 для Windows NT содержит ряд новых технологий проектирования АСУ ТП, отличающих ее от других SCADA-систем. Среди них следующие: обеспечение единых инструментальных средств (единой линии программирования) как для разработки операторских станций, так и для программирования PLC; разработка распределенной АСУ ТП как единого проекта; технология автопостроения проекта.

В систему Trace Mode 5 введены функции программирования ПЛК на основе исполнительной системы для контроллеров – Микро монитор реального времени (Микро-МРВ). Редактор базы каналов приведен в соответствие со стандартом IEC-61131-3, регламентирующим синтаксис языков программирования ПЛК. В соответствии с требованиями стандарта, программирование ПЛК осуществляется визуальными, интуитивно понятными инженерам-технологам методами в виде языка функциональных блоков (язык Техно FBD) или на языке инструкций (Техно IL).

Реализованные в инструментальной среде Trace Mode язык Техно FBD и Техно IL существенно расширены по сравнению с базовыми требованиями стандарта, включают набор более 150 элементарных и библиотечных функций. Среди встроенных алгоритмов – пропорционально-интегрально-дифференциальное (ПИД) регулирование, нечеткое, позиционное регулирование, преобразование на основе широтно-импульсной модуляции (ШИМ), статистические функции расчета технико-экономических показателей и т.д. Существенным развитием стандарта является добавление ряда интегрированных функциональных блоков управления типовыми технологическими объектами (клапан, задвижка, привод, мотор, насос, группа моторов и т.д.). Проектировщик имеет возможность наращивать библиотеки языков собственными функциями, учитывающими особенность задач, решаемых в проектах. Разработки пользовательских функциональных блоков можно осуществлять на языке Техно IL или С.

Trace Mode 5 имеет распределенную БДРВ. Поэтому распределенная АСУ ТП, включающая в себя несколько ПК и контроллеров, рассматривается системой как единый проект. Каждый узел (ПК или ПЛК) в распределенной АСУ ТП, работающей под управлением Trace Mode 5, имеет информацию об остальных узлах системы, и в случае его модификации автоматически обновляет соответствующие БД на других узлах. При этом АСУ можно рассматривать как в архитектуре клиент-сервер, так и в виде распределенной системы управления. Автопостроение это группа оригинальных технологий, реализованных в Trace Mode 5. Суть автопостроения заключается в автоматическом генерировании баз каналов операторских станций и ПЛК, входящих в состав проекта АСУ ТП, на основе информации о количестве точек ввода/вывода, номенклатуре ПЛК и плат устройств связи с объектом (УСО), наличии и типе связей между ПК и ПЛК.