ООП и схемы программ реального времени для систем управления техническими средствами (1.2)

2. Состав программного обеспечения

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

Такое разделение позволяет смягчить проблему "интерференции" процессов (см. очень актуальную статью В.Е.Зюбина и А.Д.Петухова "Распределение вычислительных ресурсов в средах с многопоточной реализацией гипер-автомата" на сайте www.SoftCraft.ru). Дело в том, что ОС РВ позволяет распараллеливать процессы как на одном, так и на множестве процессоров намного эффективнее по сравнению с общеупотребительными форточками (в частности квантование по времени при разделении процессов в однопроцессорной системе в ОСРВ выполняется на уровне микросекунд). Поэтому большинство разработчиков ПОРВ стараются использовать параллельные процессы и где необходимо и там, где вполне можно ограничиться традиционным последовательным выполнением программ. Вот как раз в тех случаях, где параллелизм применен не по существу, а чохом, и возникает жуткое перекрытие параллельных (а на самом деле псевдопараллельных на однопроцессорной системе) процессов, которое и приводит к нарушению функционирования системы (читайте указанную статью). Если программа строится как совокупность параллельных и независимых процессов, реагирующих каждый на свои определенные события типа аппаратных и программных прерываний, то неизбежны описываемые Зюбиным коллизии при одновременном (условно) наступлении нескольких событий - обычного явления в реальных системах управления техникой.

Поэтому разделение ПОРВ на базовое и функциональное обеспечивает значительное снижение риска критических накладок во времени параллельных процессов. При этом функциональное ПО представляет собой набор последовательно вызываемых подпрограмм с бесконечным циклическим повторением одной и той же последовательности подпрограмм. А базовое ПО есть, в основном, совокупность вылизанных по критерию максимального быстродействия независимых процедур, реагирующих на то или иное прерывание. Как правило в них преимущественно используется Ассемблер. Базовые процедуры настроены на конкретный вид используемого периферийного оборудования типа конкретного набора типовых модулей дискретного и аналогового ввода-вывода и передачи данных по линиям межпроцессорных связей. Но и при таком подходе существенную роль играет назначение приоритетов прерываний. (В нашей практике был случай, когда из-за ложной установки наивысшего приоритета сетевому обмену была потеряна точность вычисления важных параметров аналоговых сигналов и пришлось выдумывать хитрые алгоритмы, компенсирующие получающиеся погрешности и сбои в работе программ приема данных от каналов АЦП, потом же выяснилось, что можно использовать общее прерывание)

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

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

Отработанный набор драйверов используется на нескольких проектируемых СУТС, использующих одно и то же аппаратное поколение.

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


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