CC BY
88
УДК 621.311.002.51
ОСОБЕННОСТИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИИ СЛОЖНЫХ ИНТЕГРИРОВАННЫХ АСУТП
А. Г. Полетыкин
Институт проблем управления им. В. А. Трапезникова, г. Москва
Описаны основные задачи интегрирующего программного обеспечения (ПО), приведены типовые решения. Обсуждены основные трудности и проблемы, возникающие при интеграции разнотипного оборудования и ПО. Дан анализ опыта разработки ПО системы верхнего блочного уровня АСУТП для АЭС.
ВВЕДЕНИЕ
Сложные интегрированные АСУТП все шире применяются в промышленности. Необходимость в них возникает, когда объект автоматизации содержит большое число датчиков и механизмов, а особенности технологического процесса не позволяют разбить его на набор слабосвязанных подсистем, которые могут контролироваться и управляться отдельными АСУТП. Такие интегрированные АСУТП применяются для управления ядерными объектами, в частности, АЭС.
В подавляющем большинстве существующих интегрированных АСУТП, включая АСУТП большинства российских АЭС, проблема интеграции средств контроля и органов управления решается путем их размещения на единых пультах управления. Этот способ обладает своими достоинствами и недостатками, обсуждение которых выходит за рамки настоящей статьи.
С наступлением эпохи массового применения микропроцессорной техники разработчики АСУТП стали решать проблему интеграции с помощью компьютеризированных рабочих мест. В качестве удачного примера такого решения можно назвать компьютеризированный блочный пульт управления промышленным ядерным реактором № 4 (фирма ЕББ, Франция).
Российские ученые и инженеры также решили пойти по этому пути. Минатом РФ приобрел лицензию на производство программируемых контроллеров ТЕЬЕРЕЯМ МЕ у фирмы “Siemens”. Перед разработчиками была поставлена задача спроектировать для АЭС интегрированную АСУТП на их основе. Институту проблем управления им. В.А Трапезникова РАН было поручено разработать систему верхнего блочного уровня (СВБУ) АСУТП, включая программное обеспечение [1—3].
Система верхнего блочного уровня проектировалась как подсистема АСУТП, задача которой заключается в
интеграции информации и органов управления всех подсистем нормальной эксплуатации АЭС, систем безопасности и специальных систем, к которым относятся подсистемы внутриреакторного контроля, системы автоматического контроля нейтронного потока, система управления компенсирующими стержнями ядерного реактора и другие, всего двенадцать подсистем.
В настоящее время СВБУ, включая техническую и программную составляющие, изготовлена, испытана и поставлена на АЭС.
1. ФУНКЦИИ ИНТЕГРИРУЮЩЕГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Функции программного обеспечения (ПО) делятся на информационные, управляющие и вспомогательные.
Информационные функции предназначены для передачи информации от программируемых контроллеров до экранов дисплеев, посредством которых оперативный персонал должен контролировать объект. Таких дисплеев много (несколько десятков), персонал насчитывает несколько человек, у каждого своя зона ответственности, которые частично пересекаются (на 10—25 %). Поэтому логика распределения информации по экранам дисплеев имеет весьма сложный характер.
Функции управления служат для передачи управляющих воздействий, вводимых с помощью компьютерных органов управления (трекбола, мыши, клавиатуры) в программируемые контроллеры, которые затем осуществляют управление механизмами.
Вспомогательные функции обеспечивают требуемые показатели надежности и безопасности эксплуатации АСУТП. К ним, в частности, относятся: ведение единого времени, ведение долговременного архива, контроль отказов элементов АСУТП, обеспечение защиты от не-
санкционированного доступа, управление техническими и программными средствами АСУТП и др.
Рассмотрим конкретный пример.
В СВБУ информационные задачи должны обеспечивать оператора-технолога реакторного отделения оперативной (с задержкой не более двух секунд) информацией о состоянии систем нормальной эксплуатации (около 1500 датчиков, более 1000 механизмов), систем технологической безопасности (около 1000 датчиков, более 500 механизмов), системы внутриреакторного контроля (около 1500 измеряемых и расчетных параметров) и других подсистем (более 3000 аналоговых и дискретных параметров). При этом должна обеспечиваться возможность оперативного (с задержкой не более двух секунд) управления более чем тысячей механизмов, а вспомогательные задачи должны обеспечивать погрешность привязки событий не хуже 10 мс, запись всех событий в долговременный архив, контроль состояния более тысячи контроллеров, защиту их целостности от несанкционированного доступа, надежное управление расчетными задачами.
Общий вывод: интегрирующее ПО, предназначенное для применения в СВБУ, должно выполнять все функции, прямо или косвенно связанные с контролем и управлением, многочисленные вспомогательные функции, а также обеспечивать эффективную работу с большим числом сигналов (104—105), причем временная задержка при передаче информации не должна превышать 2 с.
2. ТРЕБОВАНИЯ К РЕАЛИЗАЦИИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Сложные интегрированные АСУТП, как правило, управляют большими, энергонасыщенными и потенциально опасными для человека и окружающей среды объектами. Поэтому ПО, работающее в их составе, само является источником опасности.
По нашему мнению, ошибки в ПО могут иметь не менее серьезные последствия, чем дефекты строительных конструкций, технологического и электрического оборудования.
Применительно к АЭС правила разработки и обращения с ПО регламентированы в нормативных документах МАГАТЭ и МЭК, в которых содержатся строгие требования к контролю процесса изготовления ПО на всех этапах его жизненного цикла. Хотя в России эти требования не действуют, при поставках ПО на зарубежные АЭС оно проходит контроль на соответствие международным требованиям по качеству и безопасности.
Это, в частности, относится и к входящему в состав СВБУ программному обеспечению, которое изначально планировалось как изделие на экспорт.
Рамки настоящей статьи не позволяют подробно остановиться на всех этапах процесса разработки ПО, однако стоит выделить несколько моментов.
■ Термин “разработка ПО” в применении к ПО для АСУТП должен относиться ко всем его компонентам, включая операционную систему, драйверы устройств и т. д., а не только к той части, которая непосредственно решает задачи контроля и управления. Это, безусловно, не означает, что все ПО нужно
“переписывать с нуля”. Можно и нужно использовать уже готовое ПО, которое в обязательном порядке следует подвергать процедурам верификации исходного кода и испытаниям по специально разработанным методикам [4].
В полезности и надежности такой строгой проверки убеждает следующий пример. В ПО для СВБУ применяется операционная система, в которую входят компоненты свободно распространяемой операционной системы Linux. В результате верификации исходного кода нами было выяснено, что ядро Linux не может работать более одного года без перезагрузки. Поэтому в регламент эксплуатации СВБУ была введена плановая перезагрузка операционной системы, которая не приводит к отказу СВБУ и не нарушает работу оперативного персонала.
■ Программное обеспечение должно работать в течение всего срока эксплуатации АСУТП, которая может продолжаться до 30—50 лет. В течение такого длительного периода времени многократно изменяются элементная база компьютеров, разрядность и другие параметры, а ПО должно продолжать работать без остановок. Как этого достичь?
Решение состоит в применении консервативных языков программирования, проверенных протоколов передачи информации, которые существуют уже более 20 лет; методов, которые не зависят от особенностей технических средств и носителей информации. В частности, ПО для СВБУ создано на основе таких проверенных временем стандартов как POSIX 1, TCP/IP, X Window и др.
■ По нашему мнению, испытания ПО и верификацию документации наряду с разработчиками должны проводить независимые группы специалистов, которые не участвовали в разработке ПО. Опыт показывает, что ошибки, выявленные независимыми специалистами, отличаются от тех, которые выявляют сами разработчики.
■ Насколько “открытым” должно быть ПО? Под этим полусленговым термином мы понимаем возможность внесения изменений в ПО, а не защиту от взлома. Наш опыт показывает: ПО должно быть открытым на 100 %, т. е. оно должно быть построено и документировано таким образом, чтобы можно было вносить изменения в любой его компонент.
Этот вывод сделан на основе наблюдения за тем способом планирования работ, который практикуется в российских организациях. Он характеризуется, с одной стороны, слабой проработкой технических решений на этапе проектирования, а с другой — низким уровнем исполнительской дисциплины. Применительно к ПО это означает, что перед началом работ, в которых задействованы различные организации и коллективы, не производится полной проработки интерфейсов между компонентами ПО, а те соглашения, которые все же установлены, часто не соблюдаются. Поэтому интегрирующее ПО, в силу своей специфики, должно приравниваться к различным протоколам, интерфейсам, алгоритмам обработки информации, т. е. быть гибким. Проиллюстрируем это примером.
Системаверхнего блочного уровня для АСУТП должна работать с контроллерами, производимыми по лицензии фирмы “Siemens” Всероссийским научно-иссле-
CDNTRDL SCIENCES № 4 • 2DD5
довательским институтом измерений и автоматики. Они обладают следующей особенностью: наряду с сигналами о состоянии механизмов, которые формируются инициативно и передаются в СВБУ, в них используются так называемые запросные сигналы, для получения которых в СВБУ необходимо формировать специальные запросы к контроллерам. Число таких контроллеров достигает более одной тысячи, а конструкция сети CS275 фирмы “Siemens” не позволяет производить более ста запросов в секунду без перегрузки сетевого трафика. Поэтому оперативное (с задержкой не более двух секунд) получение значений этих запросных сигналов невозможно простым циклическим опросом контроллеров.
Для решения проблемы оперативного представления значений запросных сигналов в состав интегрирующего ПО пришлось ввести специальный интеллектуальный алгоритм, который анализирует, какие именно запросные сигналы необходимы для управления в текущий момент времени.
3. СТРУКТУРА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ДЛЯ СВБУ
Остановимся на особенностях ПО для СВБУ, которое является примером интегрирующего ПО для АСУТП.
В качестве базового языка программирования был выбран язык программирования Си стандарта POSIX 1. Это один из наиболее распространенных языков программирования среднего уровня, который существует уже десятилетия и будет существовать еще десятки лет.
Непосредственно на этом языке реализовано так называемое интерфейсное программное обеспечение, которое представляет собой библиотеку программ и применяется для создания “шлюзовых” программ, предназначенных для обеспечения взаимодействия с программируемыми контроллерами и расчетными программами.
На основе языка Си и применения графической библиотеки Motif разработана программа, обеспечивающая отображение информации в графической и текстовой форме на любой UNIX или Linux машине, Х-терминале или эмуляторе Х-терминала под Windows.
Однако для реализации основных алгоритмов обработки информации используется язык логического программирования высокого уровня ABIS — оригинальная разработка Института проблем управления (ИПУ) [5, 6]. Он реализован также на основе языка Си, работает практически на всех операционных системах и может быть портирован на любую операционную систему. Язык ABIS чрезвычайно компактен и позволяет просто и быстро реализовывать сложные распределенные программные комплексы. Так, в частности, объем исходного ABIS-кода ПО для СВБУ не превышает 500 килобайт. При этом язык достаточно эффективен для задач АСУТП. Секрет его успешного применения состоит в том, что в нем реализованы действенные алгоритмы работы с базами данных. Это позволило использовать в качестве технических средств СВБУ слабые процессоры с тактовой частотой 500—760 МГц для обработки больших объемов информации с приемлемой скоростью (см. § 1).
В качестве операционной системы, которая рассматривается как часть интегрирующего ПО, используется оригинальная разработка ИПУ, называемая LICS (Linux
ПО контроля и управления рабочим ПО техническими средствами
Клиентское ПО
Серверное ПО ■
Интерфейсное ПО
ПО системы автоматического проектирования
Рис. 1. Структура программного обеспечения
Рис. 2. Структура технических средств
of the Institute of Control Science) [7] (см. третью страницу обложки). Она построена на основе свободно распространяемого ПО и является представителем семейства Linux, но имеет некоторые преимущества по отношению к другим представителям этого семейства. Все компоненты операционной системы LICS прошли верификацию и испытания. Данная операционная система обладает лицензионной чистотой и независимостью от ограничений каких бы то ни было государств, фирм и организаций.
На основе перечисленных базовых компонентов был разработан комплекс программ для разработки СВБУ, представленный на рис. 1.
Помимо интерфейсного ПО, в состав комплекса входят:
— серверное ПО, которое размещается на серверах СВБУ и осуществляет основные алгоритмы обработки и сохранения информации;
— клиентское ПО, осуществляющее диалог с операторами-технологами;
— ПО системы автоматического проектирования;
— специализированное ПО, в функции которого входит обеспечение централизованного дистанционного контроля всех компонентов ПО и технических средств, на которых оно функционирует.
Типовая схема технических средств, на которых инсталлируется данное ПО, представлена на рис. 2, где С1 и С2 — основной и резервный серверы, на которых инс-
таллировано серверное ПО; РС1, РСп — рабочие станции с одним или несколькими дисплеями, на которых инсталлировано клиентское ПО; Ш1, ..., Шп — шлюзовые компьютеры, на который инсталлировано интерфейсное ПО; СК — рабочая станция, на которой инсталлировано ПО контроля и управления рабочим ПО и технических средств; ЛВС — дублированная локальная вычислительная сеть.
ЗАКЛЮЧЕНИЕ
Из приведенных рассуждений можно сделать вывод, что интегрирующее ПО должно обладать следующими основными свойствами:
• выполнять все необходимые потребительские функции с заявленными временными, надежностными и прочими параметрами;
• быть спроектированным, изготовленным и протестированным по правилам, установленным в нормативной документации;
• быть максимально гибким и открытым.
Автор надеется, что приведенные в этой работе сведения будут полезны при разработке современных интегрирующих программно-технических комплексов в различных областях науки и техники.
Более подробную информацию о СВБУ и компонентах ПО можно найти на сайте www.31.ipu.rssi.ru.
ЛИТЕРАТУРА
1. Основные решения по созданию системы верхнего (блочного) уровня АСУТП АЭС / А. Г. Полетыкин, М. Е. Бы-вайков, Н. Э. Менгазетдинов, А. А. Байбулатов // Ядерные измерительно-информационные технологии. — 2004. — № 1—2.
2. Основные решения по созданию системы верхнего (блочного) уровня АСУТП АЭС / А. Г. Полетыкин, М. Е. Бы-вайков, Н. Э. Менгазетдинов, А. А. Байбулатов // Труды Ин-та проблем управления. — 2002. — Т. XVIII.
3. Опыт проектирования системы верхнего (блочного) уровня АСУТП АЭС / А. Г. Полетыкин, Н. Э. Менгазетдинов, М. Е. Бывайков и др. // Вторая междунар. конф. по проблемам управления / Ин-т проблем управления. — М., 2003.
4. Некоторые аспекты применения свободно распространяемых программных продуктов в АСУТП АЭС / А.В. Антонов, А. А. Байбулатов, С. И. Масолкин и др. // Труды Ин-та проблем управления. — 2001. Т. XIII.
5. Полетыкин А. Г., Байбулатов А. А. Основы языка ABIS // II междунар. конф. “Идентификация систем и задачи управления” / Ин-т проблем управления. — М., 2003.
6. Полетыкин А. Г., Бывайков М. E., Байбулатов А. А. Язык логического программирования — ABIS // Труды Ин-та проблем управления. — 2004. — Т. XXIV.
7. Системное программное обеспечение LICS как компонент подсистем АСУТП АЭС / С. И. Масолкин, В. Г. Промыслов, Е. Ф. Жарко и др. // Автоматизация в промышленности. — 2004. — № 10.
в (095) 334-75-71
□
XIII МЕЖДУНАРОДНАЯ КОНФЕРЕНЦИЯ
"ПРОБЛЕМЫ УПРАВЛЕНИЯ БЕЗОПАСНОСТЬЮ СЛОЖНЫХ СИСТЕМ"
(Москва, декабрь 2005 г.)
Предполагается рассмотреть: проблемы и методы оценки безопасности различного типа; механизмы управления безопасностью; правовое регулирование вопросов безопасности; формирование структур систем управления безопасностью; теорию и методы принятия решений, связанные с безопасностью; прогнозирование и моделирование процессов управления безопасностью; планирование и стратегическое управление в системах обеспечения безопасности; методы построения средств информационной поддержки принятия решений в системах управления безопасностью; системы управления силами и средствами при управлении безопасностью.
Конференция состоится в Институте проблем управления им. В.А. Трапезникова РАН по адресу: Москва, Профсоюзная ул., 65. Официальные языки конференции - русский, английский. Продолжительность работы конференции - 1 день.
Заявки на участие в конференции принимаются по адресу: 117997 Москва, ГСП-7, Профсоюзная ул., 65, Институт проблем управления, лаб. 20, Оргкомитет международной конференции; тел. (095) 334-89-59, e-mail: [email protected]
Материалы представляются на дискете плюс 1 экз. в распечатанном виде (2-4 стр.). На этикетке дискеты указать ф.и.о. авторов и имя файла, названного по фамилии первого автора; или высылается по электронной почте. В графе "Тема" укажите - Конференция. Необходимо сообщить сведения об авторах: фамилию, имя, отчество автора(ов); должность, ученое звание; место работы (полное название и аббревиатура); почтовый адрес для переписки (обязательно указать индекс) и(или) e-mail; номер телефона для связи.
Требования по оформлению. Материалы должны быть представлены в редакторе Word, версии не ниже 6.0; формат А4, заполняемый текстом 115x165 мм (параметры страницы: верхнее поле - 2,5 см; нижнее - 10,7 см; левое -4,7 см; правое - 4,8 см). Шрифт - Times New Roman, 10 пунктов через 1 интервал, красная строка - 0,5 см, страницы не нумеруются. Библиографические ссылки в тексте даются в квадратных скобках, рисунки должны допускать возможность масштабирования.
