Программное обеспечение высоконадежной АСУ реального времени для предприятий горнодобывающей промышленности

А.И.Благодарный, научн. сотр.; Л.С. Каратышева, научн. сотр.;
Г.П.Чейдо, к.т.н., зав. лабораторией, КТИ ВТ СОРАН

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

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

Исходные положения проекта АСУ-системы

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

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

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

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

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

Основные решения проекта АСУ-системы

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

Описываемая в настоящей статье АСУ-система реализована как распределенная вычислительная сеть, которая одновременно является локальной вычислительной сетью (ЛВС) на основе сетевых протоколов ОС QNX 4.25.xx, что обеспечивает быстрый и прозрачный обмен данными между различными узлами локальной вычислительной сети. Локальные вычислительные сети АСУ ТП также называются технологическими сетями.

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

В иерархическом плане программное обеспечение АСУсистемы разделено на две подсистемы: подсистема верхнего уровня и подсистема нижнего уровня – по направлению передачи и обработки потоков данных состояния объектов технологического оборудования.

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

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

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

Необходимое для этого распараллеливание потоков данных осуществляют указанные выше вспомогательные буферные программы подсистемы нижнего уровня. Подсистема верхнего уровня может быть организована и по модели Client – Server. В этом случае в роли сервера выступает база данных. Клиентские приложения интерфейса оператора могут быть доступны и из других операционных систем, например, из Windows NT/2000/XP с помощью утилиты Phindows OC QNX 4.25 удаленного доступа.

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

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

Средой исполнения в ОС QNX 4.25 является графическая оболочка Photon 1.14.xx. В качестве среды разработки был выбран системный графический редактор Application Builder Photon 1.14.xx и компилятор фирмы Watcom версии 10.6. Разработка программного обеспечения осуществлялась на языке программирования высокого уровня C/C++.

Разработка или модификация конкретного проекта АСУ ТП на основе указанной АСУ-системы сводится к следующим трем основным операциям:

- построение графического интерфейса с помощью системного построителя приложений (графического редактора) Application Builder Photon 1.14.xx;

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

Технологическая сеть АСУ-системы представлена некоторой совокупностью вычислительных машин под управлением OC QNX 4.25, объединенных в локальную вычислительную сеть на основе сетевого протокола Ethernet. Рабочие места оператора реализованы на персональных компьютерах (ПК), которые подразделяются на основной ПК и резервные ПК. В том случае, когда в конкретном проекте АСУ ТП нет функций автоматического управления технологическими процессами, то никаких различий между основным ПК и резервными ПК нет, в противном случае, функции автоматического управления могут быть разрешены только для одного ПК, в данном случае, – для основного ПК. Переключение основного ПК на резервный ПК и обратно осуществляется, при необходимости, непосредственно оператором с разрешения системного администратора на панелях настройки рабочего места оператора, причем это переключение производится динамически, т.е. без перезагрузки ПК рабочих мест оператора.

Остальные вычислительные машины технологической сети представлены вычислительными контроллерами в промышленном и, возможно, взрывобезопасном исполнении. На этих контроллерах реализуется подсистема нижнего уровня. В технологической сети вычислительных контроллеров может и не быть – в этом случае подсистема нижнего уровня развертывается на ПК рабочих мест оператора.

Программное обеспечение подсистемы нижнего уровня представлено набором драйверов ввода/вывода (на рисунке программы драйверов обозначены как «Драйвер»), которые отвечают за сопряжение с конкретными объектами технологического оборудования. Вся необходимая для работы драйвера исходная информация об объектах технологического оборудования записывается в текстовые конфигурационные файлы подсистемы нижнего уровня. Обмен данными с программным обеспечением подсистемы верхнего уровня драйверы осуществляют через вспомогательные буферные задачи «ОПД» (отправитель пакетов данных) и «ППУ» (получатель пакетов управления), с которыми драйверы связаны через кольцевые буферы в разделяемой оперативной памяти.

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

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

Задача «ППУ» принимает данные телеуправления объектами технологического оборудования от подсистемы верхнего уровня и записывает их в кольцевой буфер управления в разделяемой памяти. В системах управления технологическими объектами различают импульсные и непрерывные сигналы управления. Драйверы работают только с непрерывными сигналами управления. Преобразование импульсных сигналов управления в непрерывные осуществляет вспомогательная задача «ПрУ» (преобразователь управления), которая избавляет драйвер от необходимости вести отсчет времени снятия импульсного сигнала управления.

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

Рис. 1 Общая схема сетевой архитектуры технологической сети

Рис. 1 Общая схема сетевой архитектуры технологической сети

В состав программного обеспечения подсистемы верхнего уровня входят следующие основные задачи (рис. 1):

- задача интерфейса оператора «ИФ»;

- задача управления базой данных «БД»;

- задача декодирования данных «ПКД»;

- вспомогательные буферные задачи «ОПС», «ППС» и «ОПУ»:

- задача «IP сервер» обмена данными с АСУ-системами, функционирующими в других ОС.

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

Прием сообщений о действиях персонала осуществляет задача «ППС» (получатель пакетов сообщений), которая записывает принятые сообщения в кольцевые буферы данных в разделяемой памяти задач интерфейса оператора и базы данных. Передача данных телеуправления технологическими объектами в подсистему нижнего уровня производится задачей «ОПУ» (отправитель пакетов управления), которая берет данные из кольцевого буфера управления в разделяемой памяти задачи интерфейса оператора.

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

В свою очередь, сигналы состояния и управления делятся на три категории или типа:

- сигналы телесигнализации (ТС), принимающие два значения 0 и 1;

- сигналы телеизмерения (ТИ), значения которых лежат в некотором диапазоне;

- сигналы телеуправления (ТУ).

В описываемой АСУ-системе используются две системы кодировок сигналов состояния и управления объектами технологического оборудования: кодировка сигналов в подсистеме нижнего уровня и кодировка сигналов в подсистеме верхнего уровня.

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

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

Задача интерфейса оператора «ИФ» – та единственная задача подсистемы верхнего уровня, которая подлежит модификации и настройке при разработке конкретного проекта АСУ ТП на основе данной АСУ-системы.

Основные функции задачи:

- отображение на экране монитора состояния объектов технологического оборудования с помощью выбранной системы графических знаков;

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

- контроль входа (выхода) персонала в систему.

База данных АСУ-системы представляет собой набор файлов, состоящих из записей событий в их хронологическом порядке, т.е. упорядоченных по времени их поступления.

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

В конце каждых суток система управления базой данных «БД» производит контроль количества хранящихся архивных файлов и, при необходимости, осуществляет удаление устаревших по времени архивных файлов. Размер одной единицы записи базы данных является стандартным и составляет 32 байта. Это позволяет, во-первых, хранить на дисковых накопителях относительно небольшой емкости многолетние базы данных, а во-вторых, резко увеличить скорость обработки всех запросов к базе данных.

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

Задача «IP-сервер» работает в паре с задачей «IP-клиент», которая запускается в другой операционной среде Windows NT/2000/XP и предназначена для организации обмена данными с АСУ-системами по технологии ОРС. Обмен данными между задачами «IP-сервер» и «IP-клиент» осуществляется на основе транспортного протокола ТСР, причем список передаваемых данных также задается соответствующим текстовым конфигурационным файлом.

Кроме рассмотренных выше задач, в состав программного обеспечения АСУ-системы включены также задачи диагностики состояния всех вычислительных машин технологической сети, диагностики состояния программного обеспечения на всех вычислительных машинах той же технологической сети, диагностики состояния устройств сопряжения с технологическими объектами и диагностики состояния непосредственно самой локальной вычислительной сети.

Вся указанная диагностика выводится на экраны мониторов всех рабочих мест оператора и записывается во все базы данных. Сетевая конфигурация технологической сети и расписание программного обеспечения АСУ-системы по узлам ЛВС задается своими текстовыми конфигурационными файлами.

Общие замечания по разработке графического интерфейса оператора

Построение графического интерфейса оператора осуществляется помощью системного построителя приложений (графического редактора) Application Builder Photon 1.14.xx. Графический интерфейс оператора представляет собой набор видеокадров, каждый из которых является мнемосхемой некоторой части технологического оборудования или всего технологического оборудования (главный видеокадр).

Главный видеокадр постоянно находится на экране монитора. Остальные видеокадры вызываются, по мере необходимости, оператором и при вызове накрывают головной видеокадр, автоматически удаляя предыдущий видеокадр. Кроме видеокадров существуют панели состояния и управления технологическим оборудованием. Их отличие от видеокадров заключается в том, что в них отображается состояние только одного технологического объекта (смотри ниже) и они вызываются на экран монитора в любом количестве и независимо друг от друга.

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

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

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

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

Рис. 2 Графический интерфейс оператора

Рис. 2 Графический интерфейс оператора

Графический интерфейс оператора, в общем случае, имеет вид, изображенный на рис. 2. Рабочее поле экрана монитора разбито на три области: верхнюю, среднюю и нижнюю. В верхней части экрана монитора расположена строка с элементами управления, общими для всех видеокадров мнемосхем технологического оборудования. В нижней части экрана монитора находится окно сообщений, в котором выводятся последние три по времени сообщения о происшедших событиях.

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

Основные правила составления конфигурационных файлов

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

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

Каждому логическому объекту в АСУ-системе сопоставлен некоторый класс объекта (в смысле объектно-ориентированного программирования), например, те же конвейеры, двигатели привода и т.д. Но есть и универсальные классы объектов, которые годятся для любых логических объектов.

При необходимости достаточно легко ввести в АСУ-систему и новые классы объектов со своими специфическими функциями обработки данных.

Выбирается некоторая система кодирования логических объектов, в которой каждому объекту присваивается определенный код и определяется список сигналов состояния и управления объектом, и далее составляются конфигурационные файлы подсистемы верхнего уровня. Код любого сигнала в подсистеме верхнего уровня представляет собой строку из пятнадцати буквенно-цифровых символов в латинской транскрипции. Первые 11 символов определяют код объекта, которому принадлежит данный сигнал, а последние 4 символа задают код сигнала в списке сигналов указанного объекта.

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

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

- файл списка всех логических объектов;

- файлы списков сигналов для каждого логического объекта;

- файлы отображения состояния логических объектов на графическом интерфейсе экрана монитора.

Последний тип файлов составляется уже после того, как разработан графический интерфейс оператора и всем активным графическим знакам интерфейса присвоено некоторое имя или тег в системе Photon 1.14.xx.

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

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

Файлы отображения состояния логических объектов содержат списки тегов видеокадров и панелей интерфейса оператора и списки тегов активных графических знаков на этих видеокадрах и панелях с указанием кодов отображаемых сигналов и методов их отбражения. Методы отображения сигналов на активные графические знаки – это просто числа, которыми нумеруются свойства графических объектов в инспекторе объектов построителя приложений.

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

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

• узел – номер узла контроллера подсистемы нижнего уровня;

• порт – логический номер порта устройства ввода/вывода данных;

• канал – логический номер устройства сопряжения с объектом технологического оборудования;

• тип сигнала – ТС, ТИ или ТУ;

• номер сигнал – последовательный номер строки описания сигнала заданного типа.

Ввод и вывод данных драйверами подсистемы нижнего уровня всегда осуществляется через некоторый порт, который должен быть задан его логическим номером. Логические номера портов в АСУ-системе являются предопределенными. Например, порты 21, …, 28 соответствуют последовательным портам контроллера COM1, …, COM8; порту с номером 0 соответствуют платы ввода/вывода непосредственно на внутренней шине контроллера и т. д.

С каждым устройством ввода/вывода данных связывается понятие канала. Канал – это набор правил описания данных, которые считываются с данного устройства или записываются на него. Каждому каналу присваивается некоторый произвольный, но уникальный для заданного порта и заданного узла логический номер в диапазоне от 1 до 255.

Для описания каналов используются текстовые конфигурационные файлы подсистемы нижнего уровня (конфигурационные файлы каналов). Конфигурационный файл канала состоит из директив, строк описания сигналов и комментариев.

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

Строки описания сигналов следуют после задания директив, и каждая строка состоит из некоторого числа полей, разделенных символом запятой. Поля строк описания сигналов содержат параметры алгоритмов предварительной обработки сигналов (драйверами и программой декодирования «ПКД»), а также кодировку сигналов в подсистеме верхнего уровня.

Заключение

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

Журнал "Горная Промышленность" №2 2009