| Из всех искусств для нас важнейшим является software engeneering.
Автоматизация технологических процессов весьма консервативная область применения компьютеров. Она менее подвержена изменчивой моде на "новые" информационные технологии. Главными критериями были и будут эффективность и безопасность. Программное и аппаратное обеспечение систем автоматизации создается тщательно, на базе проверенных годами платформ и технологий. Эти платформы и технологии производятся в небольших количествах (иногда только по заказу) и имеют соответствующую высокую стоимость. Подобные системы сложны и трудоемки в сопровождении и администрировании.
Непрерывно возрастающая мощность при сравнительной дешевизне делают экономически оправданными попытки широкого внедрения систем на базе "персональных" компьютеров (будем далее их называть "PC компьютерами") на крупных технологических объектах. Но вместе с персоналками в автоматизацию просачиваются "персональные технологии" и методы их продаж: PC набитый платами ЦАП/АЦП рекламируется как универсальный промышленный контроллер, а система управления под MS WINDOWS средством автоматизации атомных электростанций. Очевидно, что необходимы системы, надежность и функциональные возможности которых адекватны ответственности возлагаемых на них задач. Определение границ этой очевидности и является предметом рассмотрения данной статьи.
Четыре уровня.
Не нарушая традиций, совершим исторический экскурс. К настоящему времени выработана 4-х уровневая структура, которой придерживаются все производители систем автоматизации технологических процессов.
- Расчет и анализ финансово-экономических показателей
- Станции оперативного технологического персонала
- Программируемые логические контроллеры
- Датчики и исполняющие устройства
По части расчетов и анализов у компьютера нет конкурентов и проблемы этой области непосредственного отношения к оперативному управлению технологическим объектом не имеют.
Попытки превратить компьютер в контроллер успеха не имели и иметь не могут по причине принципиального различия конструкций и идеологий. Все контрпримеры разделяются на два случая: либо за основу взят не компьютер, либо получается не контроллер.
Компьютер в составе комплексов автоматизации функционирует в качестве станции оперативного технологического персонала и выполняет следующие задачи:
- сбор данных от контроллеров;
- обработка данных;
- отображение результатов обработки;
- обработка действий персонала по управлению технологическим объектом и передача соответствующих команд контроллерам;
- накопление результатов обработки данных и действий персонала.
История больших систем
Первыми компьютерами, которые выступили в этой роли, были рабочие станции. Снабженные операционными системами типа UNIX или VMS, они прекрасно справлялись с задачами 2-5 (см. выше). Для этого имелись прекрасные средства от X-Windows до скоростных файловых систем.
А вот со сбором данных, тем более в объеме нескольких тысяч параметров в секунду, возникали проблемы. Применяемые операционные средства были предназначены для МНОГОПОЛЬЗОВАТЕЛЬСКОГО режима, а сбор данных и управление предполагают поддержание сеансов связи со многими контроллерами и их логическими блоками (контура регулирования и т.д.) одновременно, для чего требуется выполнение операций в режиме реального времени.
Решили проблему просто: сделали устройство, которое опрашивает контроллеры и оптом по высокоскоростному каналу (Ethernet, SCSI) отправляет собранные данные "главной машине". Устройство представляет из себя "машинку" на базе специального процессора для встраиваемых систем (очень любят Motorol'у, но у Intel'а тоже есть), с прошитой в ROM операционной системой реального времени и необходимым программным обеспечением, c достаточным количеством RAM, с аппаратными интерфейсами связи. Иначе как "со-компьютером" такое устройство не назовешь. Мало того что цены на рабочие станции устойчиво высоки (несколько десятков тысяч долларов), к этой цене добавляется еще десяток тысяч долларов. Потребность в резервном рабочем месте удваивает стоимость. Хорошо если система используется на крупном технологическом объекте, а если на объекте три сотни параметров? Овчинка получается нерентабельной.
История малых систем
Когда быстродействие PC компьютеров доросло до того, что им можно было доверить интерфейс с оператором технологического объекта, количество систем для малого и среднего числа параметров стало неуклонно расти. Архитектура систем осталась прежней: рабочую станцию заменил PC компьютер, и "со-компьютер" заменил PC. В наследство остались болезни немасштабируемости системы (теперь уже вверх) и неэффективного использования аппаратных ресурсов при нестандартных конфигурациях.
Неувязки
Подобные системы работают и будут прекрасно еще работать, но демон противоречия вопиет: для сбора данных выделяется ЦЕЛАЯ машина, а чем хуже подсистемы архивирования и отображения?! Им ТОЖЕ по машине! Все будет не работать, а летать. А что бы экономный заказчик вопросов не задавал, расскажем ему про технологию клиент-сервер... Но как быть с вариантом на триста параметров? Клиенту хотелось бы все "в одном флаконе"... А 5000 в двух?! И заказчик как всегда прав.
На каждом технологическом объекте своя архитектура системы сбора данных и управления. Она определяется количеством, типами и конфигурациями контроллеров, различными вариантами рабочих мест и используемыми аппаратными средствами. Облечем свои смутные догадки и желания в форму требований к программной системе.
Требования к программному обеспечению систем сбора данных и управления.
1) Скорость, удобство использования, соответствие решаемой задаче, логичность интерфейса.
Данные требования должны предъявляться вообще к любому программному продукту. Для систем сбора данных и управления выработаны определенные правила. Они нестандартизированны, но все разработчики известных систем их придерживаются. Основная преследуемая цель - минимизация ошибок персонала по вине путанного интерфейса. То есть, если Вы работаете с контуром регулирования, то для Вас это должно выглядеть как управление, а не как скакание по системам меню и выставление опций.
2) Переконфигурация "на ходу".
Возможность изменения настроек внешнего вида системы (форм представления, графиков, мнемосхем) и условий обработки информации о технологическом объекте (шкалы, уставки, размерность и т.д.) в конкретной подсистеме не прерывая и не мешая другим подсистемам.
3) Надежность. Выборочное резервирование.
Одно из самых ресурсоемких, но обязательных требований для систем повышенной ответственности. Однако на практике не вся информация требует резервирования, поэтому резервирование должно быть выборочным, настраиваемым.
4) Масштабируемость.
Способность системы работать как с малым количеством параметров, так и с очень большим эффективно используя аппаратные ресурсы.
5) Внешний доступ к информации системы сбора данных и управления.
Для решения многих задач (например для расчета финансово-экономических показателей) требуется доступ к информации получаемой системой сбора данных и управления в ходе работы. Этот доступ должен быть оперативным, простым, но с разграничением прав (экономист не должен иметь возможности управлять объектом). Какой бы ни была интенсивность работы "внешних" пользователей, никакого влияния на работоспособность системы управления они оказывать не должны.
6) Расширяемость.
Под расширяемостью понимается количественное добавление новых типов контроллеров, новых типов рабочих мест, новых форм хранения информации и т.д.. Т.е. возможность развития системы в будущем.
7) Модернизируемость.
Очень часто ошибки при модернизации одной из подсистем (обычно с целью оптимизации) приводят к появлению ошибок в других подсистемах. Проблема усугубляется тем, что системы подобной сложности создаются не одним человеком, а целой группой разработчиков.
Модель программной системы.
При проектировании программных систем высокой сложности и ответственности основным является этап создания функциональной модели. Исследуя модель мы можем прогнозировать поведение проектируемой программной системы, ее функциональные возможности, недостатки и ограничения. Программная система не должна выходить за рамки своей модели. Программная система выведенная разработчиками за рамки предполагаемой модели - мутант с непредсказуемым поведением.
Нет ничего удивительного в том, что 3 пункта из 7 наших требований относятся к проблемам технологии программирования. Жизнеспособность любого сооружения зависит от продуманности архитектуры и качества кирпичиков. И строительный материал выбирается в соответствии с архитектурой. Исходя из этих азбучных инженерных истин, придумаем сначала архитектуру и только затем подберем материал.
В предыдущих рассуждениях "капризного" заказчика прозвучало желание то разрезать систему на несколько компьютеров, то собирать на одном все или часть. В этих манипуляциях подразумевается, что компьютеры соединены в сеть. Информация , полученная одним из компьютеров извне, должна быть доступна всем компьютерам. Количество узлов в сети зависит от физических характеристик используемых компьютеров (быстродействие CPU, максимально возможное число каналов связи с контроллером и т.д.) и потребностями конкретного технологического объекта.
Из-за тотальной распространенности систем DOS и Netware, в массовом сознании укоренилось неверное понимание технологии клиент-сервер: в качестве клиента должен быть использован целый компьютер, в качестве сервера - целый компьютер помощнее. Сервер ассоциируется с компьютером, а должен ассоциироваться с РЕСУРСОМ. Далее, что бы не порождать путаницу, будем использовать нейтральную терминологию.
Предложим нашему заказчику программную систему на основе технологии интеллектуальных сервисов (от английского "service" - "служба"). Сервис представляет собой автономный программный модуль, выполняющий определенные функции и оперирующий определенным ресурсом. Доступ к ресурсу осуществляется только через соответствующий сервис. Сервис очень похож на привычный сервер, за тем исключением, что сервер, в отличии от сервиса, не может являться инициатором обмена информацией, а только лишь отвечает на запросы.
В программной системе станции оперативного сбора данных и управления можно выделить 3 основных типа сервисов: сервис связи с контроллером - Controller Link Service (CLS), сервис интерфейса пользователя - User Interface Service (UIS) и сервис архивов истории и протоколов событий - Archive Base Service (ABS). Ресурсом для CLS является канал связи с контроллером, для UIS - устройства ввода и визуализации, для ABS - диски и тому подобное.
В роли клиента сервисов выступает программный модуль, который так и будем называть клиентом. Только клиент знает какие данные из какого сервиса должны быть взяты, в какой сервис направлены и в каком формате (Рис.1). Сервис может обслуживать нескольких клиентов (Рис.2) и обеспечивать им одновременный доступ к ресурсу, сохраняя при этом целостность и непротиворечивость данных. Один клиент может работать с несколькими сервисами одновременно независимо от их типа (Рис.3).
Сервисы и клиенты могут быть любых типов, но они обязаны подчиняться определенным правилам взаимодействия. Общаясь с любой службой сферы обслуживания мы исходим из двух характеристик : режима и принципа работы и специализации службы. Попытка в 3 часа ночи воспользоваться услугами прачечной никчему не приведет, хотя ж/д вокзал в это время работает. Попытка заказать бифштекс в той же прачечной в 12 часов дня вызовет в лучшем случае отказ, однако в киоске можно купить и газету и календарь. Важно, что клиент априори знает с какой службой на каком языке и во сколько разговаривать.
Если формализовать все выше сказанное, то каждая служба (сервис) подчиняется определенной дисциплине и общается с клиентами по определенному протоколу. Дисциплина определяет как функционирует сервис - какие действия в каком порядке в какое время в каком случае и как их совершает. Протокол определяет какая информация в каком формате и в каком смысле передается от клиента к сервису и обратно. Сервис может одновременно иметь несколько дисциплин и протоколов и использовать их в соответствии с потребностями клиентов.
При всей наглядности такой модели, необходимо отметить что предметом услуг, предоставляемых программными сервисами, является информация. Информация (данные) обладают уникальным свойством мультипликативности, которое заключается в том что можно создавать много абсолютно идентичных копий какой-либо информации.
Информация циркулирующая в системе интепретируется в соответствии с протоколом как:
- конфигурация;
- команда сервису;
- запрос на получение данных;
- данные (значения параметров).
Возвращаясь к аналогии со службами сферы обслуживания, конфигурацию можно сравнить с подпиской на газету (долгосрочный заказ), команду с вызовом сантехника, запрос на получение данных с обращением в справочное бюро, получение данных с результатом вышеперечисленных действий.
Теперь попробуем уложить нашу красавицу-модель в прокрустово ложе наших же требований.
Соответствие модели выдвигаемым требованиям.
1) Скорость, удобство использования, соответствие решаемой задаче, логичность интерфейса.
Логичность интерфейса и удобство использования связаны скорей не с моделью, а с пониманием создателей программной системы потребностей пользователя, специфики применения и условий эксплуатации. Скорость зависит от качества программирования и соответствия средств программирования решаемой задаче. Обсуждением этой проблемы мы займемся ниже.
2) Переконфигурация "на ходу".
Клиент в любой момент работы может переконфигурировать свою информацию на сервисе, удалить часть конфигурации или добавить. Эта возможность следует из свойств сервиса заложенных при его создании.
3) Надежность. Выборочное резервирование.
Надежность имеет непосредственное отношение к функциональной модели. Например, выход из строя сервиса архивирования данных (ABS) по какой-либо причине (ошибки программирования, разрушение ресурса и т.д.) не приведет к выходу из строя интерфейсов пользователей-операторов и сервисов связи с контроллерами. В результате оперативное отображение текущего состояния технологического объекта и управление будет доступно пользователю и будет нормально функционировать.
Горячее резервирование реализуется на основе способности клиента соединяться одновременно с несколькими сервисами любого типа. Для горячего резервирования используются сервисы одного типа. Например, у нас имеются два компьютера, на каждом из них имеется сервис архивирования данных. Клиент отправляет данные истории на оба сервиса . При выходе из строя одного из сервисов клиент распознает это и будет запрашивать информацию (графики истории, протоколы) из другого сервиса, который работает. При восстановлении вышедшего из строя сервиса клиент распознает это, сконфигурирует сервис и продолжит с ним работу. Какие параметры должны резервироваться определяется в конфигурации.
4) Масштабируемость.
Система на базе сервисов абсолютно масштабируема. Минимальный вариант: все сервисы и клиенты располагаются на одном компьютере, разделяя процессорное время. Максимальный вариант: каждый сервис имеет в своем монопольном владении не только свой ресурс, но и целый процессор. Промежуточные варианты: часть системы находится на одном компьютере, а часть на другом. В результате система может быть масштабирована в зависимости от количества информации которую нужно обрабатывать и необходимой скорости обработки. Вы можете также использовать "разнокалиберные" PC компьютеры в одной системе, распределяя нагрузку соразмерно мощности. Последнее свойство особо ценно если уже имеется некоторый парк "унаследованных" машин (386-х, 486-х).
5) Внешний доступ к информации системы сбора данных и управления.
Так как сервису безразлично какие функции выполняет клиент (если последний поддерживает правильные дисциплины и протоколы), то можно создать клиента нового типа, который будет пользоваться информацией имеющейся в системе. Например, клиент, подсоединенный к сервисам связи расположенных на разных технологических объектах (установках), будет получать с каждого сервиса некоторое количество параметров, которые в совокупности отражают работу более крупного подразделения (цеха, завода).
6) Расширяемость.
При необходимости, например, добавления нового типа контролера необходимо создать новый сервис с описанными выше свойствами (дисциплинами и протоколами).
7) Модернизируемость.
Внутренняя оптимизация сервиса с целью увеличения производительности согласно модели не выходит за рамки протокола и дисциплины и на работу других сервисов повлиять не может.
Результат.
В результате, для конкретной технологической установки мы можем складывать систему из сервисов-кирпичиков в соответствии с потребностями. Число и мощность необходимых компьютеров определяется числом необходимых ресурсов. Число ресурсов и их типы определяются требуемым количеством рабочих мест операторов, количеством подключаемых контроллеров и количеством баз архивирования.
Операционная среда.
Сервисы должны прозрачно взаимодействовать в сети компьютеров, то есть независимо от того на одном узле сети находятся они или на разных. Сеть из компьютеров выглядит для программ как один большой компьютер. Такие системы называют распределенными.
Тот, что был лукаво назван сервисом, должен быть признан объектом в чистом виде ООП по всем пяти (!) статьям: децентрализация функций (без комментариев), контрактный характер отношений (протоколы и дисциплины), классификация (типы сервисов), связность объектов в системе (п.п. 6-7 требований), инкапсуляция (по определению). Таким образом наша модель ничто иное как набор взаимодействующих распределенных объектов.
Первые что вспоминаются - CORBA, DSOM, Network OLE. Простая, казалось бы, модель вдруг обретает такие оковы: прощай realtime, прощай экономное использование ресурсов, "унаследованные" - на свалку! Но эти распределенные среды призваны решать задачи, отличные от нами поставленных, и их использование не оправдано.
Для реализации нашей модели нужна многозадачная, распределенная среда реального времени с эффективным и простым механизмом передачи информации между задачами-объектами и божескими потребностями в ресурсах (для этого она должна быть модульной, т.е. если, например, на каком-то компьютере не нужна видеоподсистема, то эту часть ОС можно и не запускать, а при необходимости запустить на ходу). К счастью такая операционная система существует и называется она QNX.
Большинство операционных систем насаждают "совковую" идеологию отношений между OS и программами: для достижения лучшей жизни и просто выживания программе-гражданину приходится постоянно обманывать операционную систему-государство. На что последнее отвечает непредсказуемостью правил поведения и даже репрессиями. Идеология OS QNX достойна подражания: для всех членов общества, будь ты хоть Высокорожденный Драйвер или партикулярная программка, установлены единые правила и механизмы. Быстродействие и высокая эффективность механизмов OS являются следствием подобной унификации.
QNX - 32-х разрядная многозадачная распределенная операционная система реального времени. QNX обладает модульной архитектурой и простым (поэтому высокоэффективным) механизмом передачи сообщений между процессами независимо от их местонахождения в сети. Именно эти исключительные характеристики делают QNX идеальной операционной средой для реализации предлагаемой модели, и, пожалуй, единственной, если вспомнить про "унаследованные" 386-е и 486-е.
Последнее замечание.
Целью долготрудных стараний автора было доказать не только достаточность технологии распределенных объектов для решения задач автоматизации, но и необходимость ее применения. Ясная функциональная схема и правильный выбор средств реализации позволяют получить программную систему с лучшими функциональными характеристикам и уменьшают вероятность ошибок, которые в системах управления дорогого стоят.
Дмитрий Пустовалов
[email protected]
Данная статья oпубликована в 5-м номере журнала "Открытые система" за 1997-й год. |
