|
|
В.А. ВЛАСОВ, С.Ю. КОМИССАРЧУК,
В.О. ЛЕБЕДЕВ, А.В. ОБНОСОВ (МИФИ)
Системно-ориентированное программирование как средство решения задач реального времени.
С учетом опыта разработки и внедрения АСУТП сформулированы важнейшие принципы системно-ориентированного программирования, составляющие основу методики создания и тестирования программного обеспечения (ПО) для решения задач реального времени (РВ). Даны примеры практической реализации названных принципов для микропроцессорных контроллеров и ПЭВМ, в частности в рамках комплекса ПО MIK$Sys.
Fundamental concepts of system-oriented programming, which underpin the software development and testing technique for solving real-time problems, are formulated in account of the experience in the field of automatized process control systems introduction. Examples of the practical realizations of the principles formulated are given for micropro-cessor-based controllers and PCs, in particular concerning the software complex MIK$Sys.
Научная группа “Управление” кафедры автоматики МИФИ занимается разработкой ПО АСУТП с внедрением их в эксплуатацию около 30 лет. С 1987 г. системы базируются на использовании микропроцессорной техники, в том числе ПЭВМ и их сетей. Сотрудниками группы был создан и постоянно развивается инструментальный комплекс ПО для распределенных АСУТП MIK$Sys. С его помощью с 1991 г. силами группы или в тесном взаимодействии со специалистами пусконаладочных организаций разработаны и введены в эксплуатацию около 40 систем различной мощности, включающих в себя от нескольких десятков до нескольких тысяч датчиков и исполнительных механизмов. Несколько десятков систем были созданы пользователями коммерческой версии комплекса MIK$Sys, поступившей на рынок в 1993 г.
Большинство проектов реализовано на оборудовании и в тесном сотрудничестве с АО “ДЭП” (Москва). Однако достаточно интересные и сложные управляющие системы были созданы с применением отечественных контроллеров Ломиконт и Ремиконт, устройств Ш711, а также управляющих ЭВМ (УЭВМ) различных типов. Совместно с ТОО “Электронмаш-Систем” (при ИНЭУМ, Москва) разработан и развивается программно-технический комплекс МикСис. Он состоит из ПО MIK$Sys и семейства отечественных контроллеров МИК и ЕМ. Группой “Управление” разрабатывались также системные и управляющие алгоритмы, средства динамической идентификации, СУБД РВ, ПО для микропроцессорных контроллеров и УЭВМ, а также распределенные системы тренировки и обучения, предназначенные для работы в РВ и ПО для АСУТП.
Особое внимание было обращено на системные разработки и организацию вычислительного процесса как решающие факторы обеспечения выполнения АСУТП своих функций и их жизнеспособности. В целях определения требований к программным средствам АСУТП и систем автоматического управления (САУ), создания методики их построения и оптимизации в течение нескольких лет проводились и проводятся сейчас натурные и модельные эксперименты, анализировался опыт создания и эксплуатации систем собственной разработки, предлагаемых другими организациями, а также ПО отечественных и зарубежных производителей (Hewlett-Packard, DEC, Westinghouse, Sun, Intel, Novell, Microsoft, QSSL и др.). Хотя работа далеко не закончена, авторы предоставляют читателям некоторые полученные результаты и делятся опытом реализации программных средств АСУТП.
Отличительной чертой АСУТП и САУ является необходимость работы их основных компонентов в темпе РВ, т. е. их функции должны непрерывно выполняться с периодичностью, определяемой главным образом инерционностью объектов управления (ОУ). Этот период будем называть тактом РВ, его продолжительность обычно на порядок меньше минимальной значимой постоянной времени ОУ.
Под безотказностью здесь понимается непрерывная работа системы на рассматриваемом интервале времени с выполнением всех возложенных на нее функций и обеспечением стабильности тактов РВ (для задач системы, функционирующей в РВ, – СРВ), в том числе и в критические моменты, характеризующиеся наибольшими потоками информации и максимальной загруженностью процессоров расчетными задачами.
Такт РВ – это минимальный квант времени СРВ, в пределах которого все внешние события, измерения, управляющие воздействия, относящиеся к системе, происходят одновременно, что позволяет синхронизировать ее с внешними, асинхронными для нее процессами с точностью до такта РВ. Если система иерархическая, то с ростом уровня иерархии длительность такта обычно увеличивается.
Наконец, АСУТП отличаются спецификой работы с человеком-оператором не только как с субъектом, но и как с ОУ. Это обусловливает, с одной стороны, необходимость постоянного предоставления оператору всей требуемой для контроля ОУ информации и максимальной свободы в выборе адекватных управляющих воздействий, а с другой – принятие всякого рода ограничений на ошибочные действия оператора и минимизацию времени на их исправление (по возможности автоматически).
Таким образом, требования к СРВ оказываются принципиально отличными от требований к диалоговым системам, в том числе многопользовательским, обычно рассматриваемым в качестве систем массового обслуживания (СМО), а часто даже противоположны им. Так:
 |
в СМО одной из основных характеристик является среднее время реакции на запрос; максимальное время в общем случае ограничено желанием пользователя добиться при обработке запроса положительного результата [соединения с нужным телефонным абонентом, в том числе автоматического, поиска требуемой информации в базе данных (БД) и т.п.]; в СРВ один из критериев работоспособности – максимальное время реакции системы, которое не должно превышать такт РВ; для СМО характерна независимость отдельных параллельно выполняемых задач и процессов, а в СРВ, как правило, задачи связаны между собой по данным и требуют строгой синхронизации, поскольку обрабатывают данные одного ОУ, состоящего из связанных между собой частей [1]; это стало особенно очевидно с массовым внедрением микропроцессорной техники и сетей ПЭВМ, когда появилась возможность оптимально распределить по отдельным вычислителям задачи с учетом их пространственной и временн?й взаимосвязанности; |
|
в СМО обычно не столь страшен отказ системы, если при этом нет потери данных и возможно восстановление системы в разумные сроки; напротив, в СРВ потеря данных одного такта не так критична, но недопустимо длительное (в несколько тактов и более) прерывание системой выполнения необходимых функций. |
Это сравнение может быть продолжено, но уже из приведенного видно, насколько различаются требования к СРВ и диалоговым системам, в том числе многопользовательским, на которые ориентированы не только почти все распространенные операционные системы (ОС), но и средства и методы организации вычислительного процесса, а также подходы и средства программирования. Именно отсюда следует, что диалоговые системы неэффективны для построения СРВ и необходимо выработать специальные подходы, методы и средства построения СРВ. Справедливости ради, надо отметить, что в АСУТП очень часто имеются диалоговые компоненты, в том числе многопользовательские, и возникают задачи их совместной работы с компонентами РВ, но всегда при наивысшем приоритете последних.
Работа в РВ (РВ не следует путать с разделением времени) означает фактическую детерминированность вычислительного процесса, в том числе временнyю синхронизацию. Это обеспечивается автоматически последовательным выполнением алгоритмов с тактированием; любая многозадачность, любые прерывания мешают удовлетворению требований РВ. Однако на необходимые жертвы приходится идти в случаях:
|
невозможности или недостаточности аппаратного буферирования ввода-вывода, когда бывает надо организовывать программное буферирование силами собственного процессора, используя как минимум аппаратные прерывания с максимальной скоростью их обработки; |
|
наличия свободных ресурсов в системе для решения фоновых задач, не относящихся к РВ (под фоновой понимается задача, не требующая синхронизации), эти задачи должны иметь минимальный приоритет. |
Понятно, что при этом приходится жертвовать качеством реализации функций РВ. Совершенно верно отмечено в работе [2], что только одна задача наивысшего приоритета может быть полностью детерминирована, именно она и обеспечивает адекватно функции РВ, остальные задачи могут осуществлять правильно только фоновые функции.
Вообще говоря, изложенные выводы во многом очевидны и давно известны, но в свете сложившейся ситуации с программными и аппаратными средствами АСУТП их формулирование и обобщение представляются актуальными. Исходя их этих положений был разработан и апробирован на практике системно-ориентированный подход к программированию, основанный на рассмотрении всех компонентов АСУ и ОУ как автономной единой системы с проектно-заданными свойствами, которая должна обладать устойчивостью к проектно-определенному диапазону внешних воздействий. Чем он шире, тем эффективнее и надежнее система, что предполагает выбор наиболее эффективных по выполняемым функциям (а не по времени разработки) решений для каждого компонента системы; ПО состоит из взаимосвязанных и синхронизированных между собой и с внешней средой компонентов, что логически вытекает из требований к организации СРВ.
Основными положениями системно-ориентиро-ванного подхода являются:
|
полная доступность всех данных системы для любого ее компонента, что подразумевает использование механизма общей памяти для межзадачного взаимодействия и делает чрезвычайно неудобным защищенный режим работы процессора; |
|
векторная организация данных, а также их векторная обработка, что обеспечивает максимальную производительность вычислительного процесса; |
|
синхронизация работы всех компонентов системы между собой и с темпом РВ всей системы путем организации последовательного обхода компонентов по детерминированным таблицам при детерминированном максимальном времени их выполнения с исключением прерываний программ и, естественно, многозадачности; там, где не удается избежать асинхронности (прежде всего при обмене данными между различными аппаратными средствами), синхронизация должна осуществляться аппаратным буферированием; |
|
при сетевом обмене между отдельными аппаратными компонентами: |
|
предпочтительное использование широковещательного режима передачи данных с необходимым числом повторов, обеспечивающего детерминированное время обмена в случае большого числа узлов; |
|
образование канала точка – точка в случае необходимости гарантированной доставки данных при работе с микропроцессорными контроллерами и дистанционном управлении (предпочтительнее дисциплина мастер – слейв, которая гарантирует время доставки информации в отличие от дисциплины клиент – сервер, когда ответ сервера может быть задержан на неопределенное время из-за его загруженности); |
|
использование дисциплины клиент – сервер только там, где это эффективно: при непериодическом сетевом взаимодействии низкой интенсивности |
|
построение интерфейса отображения с возможностью доступа к любой информации в системе при его проектировании и со строгой детерминированностью расположения элементов, управления и смены контекста отображения в процессе эксплуатации; интерфейс планируется исходя из функциональной необходимости с максимальным использованием площади экрана и средств отображения; |
|
при взаимодействии с другими программными средствами, не относящимися к РВ, предоставление им ресурсов системы только в случае, если они не нужны для собственных нужд, с сохранением постоянного контроля оператора за ходом технологического процесса хотя бы в минимальном объеме. |
Очевидно, что сформулированные принципы отличаются от широко распространенного сейчас объектно-ориентированного подхода к программированию и связанных с ним событийной обработкой информации, поддержкой межзадачного обмена с помощью механизма сообщений, организацией сетевого взаимодействия по принципу клиент – сервер, а также свободно компонуемым в процессе работы многооконным “интуитивным” интерфейсом (технология Windows). Все эти часто традиционно используемые средства организации вычислительного процесса требуют для поддержания своей жизнеспособности весьма сложного и ресурсоемкого варианта механизма многозадачности.
Разница между описанными подходами вызвана различием решаемых с их помощью задач: создание АСУТП, с одной стороны, и разработка диалоговых, обычно офисных систем, с другой.
Системно-ориентированный подход наиболее близок к исходным, низовым алгоритмам функционирования вычислительных систем, чем и объясняется его эффективность.
Понятно, что приходится учитывать широкое распространение ПО офисных систем типа MS Windows, а в то же время – дороговизну и закрытость даже весьма часто применяемых ОС РВ (например, QNX фирмы QSSL), которые к тому же не лишены недостатков (к примеру, в QNX основным механизмом межзадачного взаимодействия является малоэффективный в СРВ механизм сообщений). Ввиду этого наиболее доступна сейчас доработка (приспособление) уже внедренных ОС, включая офисные, или хотя бы сосуществование ПО РВ с ними в одной ПЭВМ, если это необходимо в АСУТП.
Неудивительно, что наиболее последовательно изложенные принципы построения СРВ удалось реализовать в микропроцессорных контроллерах, где проблемы с ОС, характерные для ПЭВМ, отсутствуют. Алгоритм и структура вычислительного процесса РВ, предложенные специалистами группы “Управление”, например, были реализованы совместно с программистами ТОО “Электронмаш-Систем” в отечественном контроллере МИК СМ 9107.
Вычислительный процесс представляет собой последовательный перебор отдельных “кубиков” – компонентов, которые по аналогии с системами программирования контроллеров сер. Ломиконт и Ремиконт будем называть алгоблоками. Обсуждаемая система является развитием идеологии программирования контроллеров сер. Ремиконт. Перебор алгоблоков осуществляется под управлением задачи-диспетчера, располагающейся в постоянной памяти (например, ПЗУ), с таблично заданной периодичностью.
Алгоблок – это элементарный универсальный модуль исполняющей системы или ОС (он же – оператор языка программирования), обеспечивающий гарантированную обработку любых поступивших на вход данных, тип, размерность которых и вид операций над ними задаются совокупностью параметров, и выполняющий обработку не более чем за детерминированное время. Алгоблоки располагаются в постоянной памяти и осуществляют вместе с выполнением математических функций и операций, необходимых для решения расчетных и управляющих задач, обслуживание модулей ввода-вывода и сетевого взаимодействия. В основном связь алгоблоков по входам и выходам описывается матричным методом, облегчающим векторную обработку данных, с доступом ко всем промежуточным результатам расчетов. Алго-блоки могут вызываться и в каждый такт РВ и с нужными пропусками, что позволяет регулировать загруженность процессора в соответствии с требованиями РВ для различных функций, избегая необходимости программных прерываний. От известных алгоблоков языка Микрол описываемые далее алгоблоки отличаются своей универсальностью и гибкостью, а также тем, что являются единственными операторами языка программирования.
Каждому включенному пользователем в таблицу обхода (циклограмму) алгоблоку в соответствии с его типом выделяется оперативная память для его входных и выходных данных, распределяемая системой при инициализации. Эти данные составляют общий вектор данных системы, являющийся базой входных и выходных сигналов.
Информационный обмен между алгоблоками осуществляется путем подачи на их входы данных с выходов алгоблоков в соответствии с таблицей, которую далее будем называть БД связок. Содержательная часть алгоритмов определяется настроечными данными – параметрами алгоблоков (параметр может не только задавать коэффициенты модели, но и указывать на тип операции: сложение, вычитание, умножение, логарифм и т.д.). Они сведены в вектор структур и составляют БД параметров.
Разработаны технические требования и алгоритмы для следующих алгоблоков:
|
обработки входных аналоговых сигналов термопар (коррекции температуры холодного спая) и термосопротивлений (в том числе подключенных по трехпроводной схеме): |
|
с восстановлением температуры по градуировочной характеристике, |
|
с реализацией фильтрации, |
|
со сравнением с уставками по значению и скорости изменения, |
|
с проверкой на достоверность по допустимым границам значения и скорости его изменения, |
|
с дополнительными преобразованиями для улучшения метрологических характеристик с использованием кусочно-линейной аппроксимации; |
|
обработки дискретных входных сигналов: |
|
с фильтрацией и накоплением кольцевого буфера истории, с одновременной обработкой дискретных сигналов так же, как и импульсных или частотно-модулированных; |
|
обработки выходных дискретных сигналов одновременно потенциальных и импульсных, в том числе с широтно-импульсной модуляцией (ШИМ); |
|
ПИД-регулятора: |
|
с расширением алгоритма для случаев аналогового выхода и выхода сигналов с ШИМ, включая пропорциональные, интегральные, дифференциальные и дифференциально-дифференциальные компоненты, |
|
с каскадированием, |
|
с алгоритмами безударного включения, |
|
с обработкой зоны нечувствительности на входе и выходе, |
|
с учетом ограничений мощности управляющего воздействия, |
|
с входом по возмущению, |
|
с различными средствами подавления помехи входного сигнала при дифференцировании и т.д.; |
|
логической обработки сигналов – построения логических выражений произвольного вида с матричным представлением; |
|
и другие алгоблоки. |
По мере разработки, отладки и апробирования новых алгоритмов и их компонентов они включаются в систему ее разработчиками.
Надежность функционирования системы обеспечивается расположением в постоянной памяти всех исполняемых модулей (диспетчера и алгоблоков), дублированием и защитой контрольными суммами управляющих таблиц и БД параметров с соответствующими алгоритмами обработки результатов их проверки (исключаются из исполнения только те функции, в данных которых обнаружены нарушения).
Описанная организация системы не позволяет пользователю не только разрушить ее память при ее настройке и программировании, но и сделать синтаксическую ошибку или зациклить программу, т. е. любая созданная программа будет работоспособна, причем время ее выполнения детерминировано. Для поддержки пользователя-разработчика в системе имеются встроенные средства отладочных и синхронизационных остановов. Удаленный (сетевой) доступ к данным может осуществляться как асинхронно, так и синхронно с задачами РВ.
Приведенная структура организации вычислительного процесса адаптирована под графическое программирование с помощью языка функциональных блоков и позволяет избежать этапа трансляции блок-схемы в язык более низкого уровня. Обладая всеми достоинствами интерпретирующего языка, структура обеспечивает высокое быстродействие, так как не нужен анализ инструкций программы (синтаксического, семантического и др.) во время ее выполнения (он не проводится и при составлении, вернее он обеспечивается ограничениями при ее создании). Механизм тактирования с возможностью разделения по тактам вызовов отдельных алгоблоков, составляющих сложные вычисления и алгоритмы, осуществляет детерминированное распределение ресурсов вычислительной системы и проектную оптимизацию вычислительного процесса, что трудно или совсем недостижимо в системах с разделением времени при помощи прерываний.
Работа и эффективность описанного ПО проверены эксплуатацией на нескольких промышленных предприятиях, еще ряд АСУТП находится в стадии разработки. В частности, были предложены элементы методики отработки АСУТП чрезвычайных ситуаций на экологически опасных объектах [3], предусматривающие в экстренных случаях переход к другой циклограмме вычислительного процесса.
Переходя к описанию комплекса ПО MIK$Sys для ПЭВМ класса IBM PC и их сетей, следует еще раз сказать о вынужденной необходимости встраивать ПО АСУТП в наиболее распространенные ОС прежде всего по экономическим соображениям: они дешевы. Текущие версии комплекса проектировались для MS-DOS и Windows’95, обеспечивается их функционирование в рамках эмуляторов MS-DOS в Windows NT, OS/2, Linux (с поддержкой сетевого взаимодействия).
Основные компоненты комплекса составляют четыре уровня:
|
средства связи с внешней средой, в том числе с устройствами связи с объектами управления, и сетевое обеспечение; |
|
средства поддержки функций РВ; |
|
то же, интерфейса оператора; |
|
инструментальные средства для разработки, модификации и сопровождения. |
Более подробно внутренняя организация комплекса изложена в работе [4]. Здесь будут рассмотрены некоторые характерные для АСУТП особенности комплекса ПО MIK$Sys.
К первому уровню относятся драйверы и драйверные системы связи с различными типами микропроцессорных контроллеров, а также сетевое ПО, поддерживающее связь как с другими ПЭВМ, так и с микропроцессорными контроллерами с IBM PC-совместимой архитектурой; ПО первого уровня реализует:
|
взаимодействие драйверов связи с контроллерами преимущественно посредством механизма общей памяти кроме отдельных исключений (например, через интерфейс DDE); |
|
сетевое взаимодействие в соответствии с изложенными принципами системно-ориентированного программирования; дисциплины обслуживания типа клиент – сервер используются только в тех случаях, когда это эффективно: |
|
установление нового канала обмена; |
|
обработка одним узлом сети носящих случайный характер запросов от нескольких узлов при инициативном управлении, синхронизации и т.п. |
Второй уровень включает в себя ПО, реализующее функции РВ АСУТП (опрос, расчет управляющих воздействий и т.д.), и программные средства организации всего вычислительного процесса и управления им в темпе РВ. Организация вычислительного процесса в РВ аналогична описанной здесь для микропроцессорных контроллеров с несовместимой с IBM PC архитектурой, но имеет, как и алгоблоки, возможность программирования на языках высокого уровня, что применяется для реализации сложных и нестандартных алгоритмов (по мере необходимости включающихся в систему в виде алгоблоков). Предусмотрены средства поддержки программирования, в том числе стыковки частей ПО, разрабатываемого несколькими программистами, а также визуализации результатов в темпе РВ, ориентированные на язык программирования FORTRAN, обеспечивающий наибольшую эффективность вычислительных операций. Соответствие программ требованиям РВ контролируется при помощи многоуровневой тестовой подсистемы, позволяющей получить максимальные и средние характеристики тестов функционирования как всей системы, так и отдельных ее компонентов.
Оба эти уровня используются как в IBM PC-со-вместимых ПЭВМ, так и в промышленных контроллерах на базе IBM PC-совместимых процессоров (например, Micro PC фирмы Octagon Systems).
Третий уровень обеспечивает как динамический интерфейс [включая просмотр архивов, подготовки и анализ технико-экономических показателей (ТЭП); генерацию отчетов] системы с человеком-оператором в соответствии с его динамическими характеристиками, так и оперативную, без останова системы перенастройку и модификацию функций первых двух уровней, в том числе изменения состава БД и алгоритмов обработки. При этом сохраняется контроль оператора над технологическим процессом. В зависимости от мощности и целевого назначения ПЭВМ могут применяться несколько разных взаимозаменяемых исполнений этого уровня – начиная от текстового варианта интерфейса до графического высокого разрешения. Отличительной чертой подсистем предоставления и анализа архивной информации, системы контроля и анализа ТЭП и подготовки отчетов является обеспечение возможности текущего контроля технологического процесса. При этом следует отметить, что функции систем требуют отдельного рассмотрения, однако в данной статье не обсуждаются.
Четвертый уровень обеспечивает модификацию третьего уровня – интерфейса оператора – как при работающей системе, на фоне задач РВ, так и автономно. Графический динамический интерфейс оператора организован в соответствии с описанными ранее принципами системно-ориентированного подхода, упор делается на растровую графику и проектное планирование экрана. При этом достигается возможность создания и модификации графического интерфейса оператора путем перемещения, тиражирования, копирования с модификацией любой уже существующей части, задаваемой как свободно выбираемыми координатами, так и принадлежностью к типу данных, или технологической группе, или их сочетанием. Следовательно, любой имеющийся рисунок, мнемосхема, проект являются источниками для нового проекта решений не только по отдельным узлам и агрегатам, но и по их объединению, взаимодействию как частей единой системы в любом сочетании. Еще раз хотелось бы подчеркнуть практическую недостижимость этого для систем, построенных по объектно-ориентированным принципам, где невозможно оперировать частями существующих объектов
Программные компоненты всех уровней системы взаимодействуют в основном через общую память с использованием иных механизмов лишь при инициализации, изменении конфигурации компонентов или в особых случаях. Адреса общих для ряда задач областей памяти содержатся в глобальном дескрипторе (он располагается также в общей памяти) и изменяются только при реконфигурации системы. Проблемы блокировок при реконфигурации решаются благодаря жесткой последовательности выполнения задач и простейшим семафорам в том же глобальном дескрипторе. Если создавать структуры данных исходя из положения о непрерываемости процессора при соблюдении элементарных инструкций типа MOV, даже в многозадачных ОС при использовании общих для нескольких задач областей данных нет необходимости вводить критические секции, семафоры и принимать прочие меры, снижающие быстродействие системы в целом.
Программные компоненты всех уровней обладают свойствами автономности, они могут применяться как по отдельности, так и в любом сочетании одновременно на одном компьютере или в сети ПЭВМ. При этом обеспечивается возможность разграничения доступа к этим компонентам или их отдельным функциям с помощью паролированного доступа встроенной системы защиты.
Выводы
Перечисленные особенности ПО комплекса MIK$Sys будут сохраняться и развиваться при адаптации к вновь появляющимся и развивающимся ОС. Однако ни одна из ранее рассмотренных ОС (в том числе различные реализации Unix) не соответствует требованиям жесткого РВ. Это вынуждает разработчиков средств РВ делать собственные добавления к ним, фактически реализуя новые ОС РВ, в некоторых исходные ОС (например, Windows NT) являются фоновыми задачами [2]. Очевидно, что приходится либо идти по этому пути, либо пытаться, наконец, создать ОС поддержки жесткого РВ, обеспечивающую не минимальную вероятность нарушения такта РВ путем сокращения времени обработки программного или аппаратного прерывания, а гарантированный для данных аппаратных средств и вычислительных алгоритмов такт РВ.
Контактные телефоны: (095) 323-92-30, 323-90-28. Факс 171-96-95.
Список литературы
возврат к меню номеров журнала
