Автоматизация технологических процессов - весьма консервативная область применения компьютеров. Она менее подвержена изменчивой моде на "новые" информационные технологии, а ее главными критериями были и всегда будут оставаться эффективность и безопасность. Программное и аппаратное обеспечение систем автоматизации создается тщательно, на базе проверенных годами платформ и технологий. Иногда это уникальные, заказные разработки, имеющие соответственно высокую стоимость. Подобные системы сложны и трудоемки в сопровождении и администрировании. С другой стороны, непрерывно возрастающая мощность при сравнительной дешевизне делают иногда экономически оправданными попытки широкого внедрения систем на базе ПК на крупных технологических объектах. Однако вместе с персоналками в автоматизацию просачиваются "персональные технологии" и методы их продаж: ПК, набитый платами ЦАП/АЦП, рекламируется как универсальный промышленный контроллер, а система управления под MS Windows - как средство автоматизации атомных электростанций. Очевидно, что необходимы системы, надежность и функциональные возможности которых адекватны возлагаемым на них задачам. Определение границ этой очевидности и является предметом рассмотрения данной статьи.
Четыре уровня
К сегодняшнему моменту все производители систем автоматизации технологических процессов придерживаются 4 уровневой структуры для архитектуры индустриальных систем.
По части расчетов и анализов у компьютера нет конкурентов, и проблемы этой области непосредственного отношения к оперативному управлению технологическим объектом не имеют.
Попытки превратить компьютер в контроллер успеха не имели и иметь не могут по причине принципиального различия конструкций и идеологий. Все контрпримеры разделяются на два случая: либо за основу взят не компьютер, либо получается не контроллер.
Компьютер в составе комплексов автоматизации функционирует в качестве станции оперативного технологического персонала и выполняет следующие задачи:
История больших систем
Первыми компьютерами, которые выступили в роли индустриальных систем управления технологическими процессами, были рабочие станции. Снабженные операционными системами Uтшч или VMS, они прекрасно справлялись с задачами 2-5. Для этого имелись надежные средства - от X-Window до скоростных файловых систем.
А вот со сбором данных, тем более в объеме нескольких тысяч параметров в секунду, возникали проблемы. Применяемые операционные средства были предназначены для МНОГОПОЛЬЗОВАТЕЛЬСКОГО режима, а сбор данных и управление предполагают поддержание сеансов связи со многими контроллерами и их логическими блоками (контуры регулирования и т.д.) одновременно, для чего требуется выполнение операций в режиме реального времени.
Решили проблему просто: сделали устройство, которое опрашивает контроллеры и оптом по высокоскоростному каналу (Ethernet, SCSI) отправляет собранные данные "главной машине". Устройство представляет собой "машинку" на базе специального процессора для встраиваемых систем (очень любят Motorolа, но и у Intel тоже есть что сказать в этой сфере), с прошитой в ROM операционной системой реального времени и необходимым программным обеспечением, c достаточным количеством RAM, с аппаратными интерфейсами связи. Иначе как "сокомпьютером" такое устройство не назовешь. Мало того, что цены на рабочие станции устойчиво высоки, к их стоимости добавляется еще десяток тысяч долларов. Потребность в резервном рабочем месте еще удваивает сумму. Хорошо, если система используется на крупном технологическом объекте, а если на объекте три сотни параметров? "Овчинка" получается нерентабельной.
История малых систем
Когда быстродействие ПК доросло до того, что им можно было доверить интерфейс с оператором технологического объекта, количество систем для малого и среднего числа параметров стало неуклонно расти. Архитектура систем осталась прежней: рабочую станцию заменил ПК, и "сокомпьютер" заменил ПК. В наследство остались болезни немасштабируемости системы (теперь уже вверх) и неэффективного использования аппаратных ресурсов при нестандартных конфигурациях.
Неувязки
Подобные системы работают и способны еще прекрасно функционировать, но демон противоречия вопиет: для сбора данных выделяется ЦЕЛАЯ машина, а чем хуже подсистемы архивирования и отображения?! Им ТОЖЕ по машине! Все будет не работать, а летать. А чтобы экономный заказчик вопросов не задавал, расскажем ему про технологию клиент-сервер... Но как быть с вариантом на триста параметров? Клиенту хотелось бы все "в одном флаконе"... А 5000 в двух?! И заказчик как всегда прав.
На каждом технологическом объекте своя архитектура системы сбора данных и управления. Она определяется количеством, типами и конфигурациями контроллеров, различными вариантами рабочих мест и используемыми аппаратными средствами. Облечем свои смутные догадки и желания в форму требований к программной системе.
Требования к программному обеспечению систем сбора данных и управления
1) Скорость, удобство использования, соответствие решаемой задаче, логичность интерфейса.
Данные требования должны предъявляться вообще к любому программному продукту. Для систем сбора данных и управления выработаны определенные правила. Они нестандартизированны, но все разработчики известных систем их придерживаются. Основная преследуемая цель - минимизация ошибок персонала по вине путанного интерфейса. Иначе говоря, если вы работаете с контуром регулирования, то для вас это должно выглядеть как управление, а не перескакивание по системам меню и выставление опций.
2) Переконфигурация "на лету".
Возможность изменения настроек внешнего вида системы (форм представления, графиков, мнемосхем) и условий обработки информации о технологическом объекте (шкалы, уставки, размерность и т. д.) в конкретной подсистеме, не прерывая работы и не мешая другим подсистемам.
3) Надежность. Выборочное резервирование.
Одно из самых ресурсоемких, но обязательных требований для систем повышенной ответственности. Однако на практике не вся информация требует резервирования, поэтому резервирование должно быть выборочным, настраиваемым.
4) Масштабируемость.
Способность системы работать как с малым, так и с очень большим количеством параметров, эффективно используя аппаратные ресурсы.
5) Внешний доступ к информации системы сбора данных и управления.
Для решения многих задач (например, для расчета финансово-экономических показателей) требуется доступ к информации, получаемой системой сбора данных и управления в ходе работы. Этот доступ должен быть оперативным, простым, но с разграничением прав (экономист не должен иметь возможности управлять объектом). Какой бы ни была интенсивность работы "внешних" пользователей, никакого влияния на работоспособность системы управления они оказывать не должны.
6) Расширяемость.
Под расширяемостью понимается количественное добавление новых типов контроллеров, новых типов рабочих мест, новых форм хранения информации и так далее - возможность развития системы в будущем.
7) Модернизируемость.
Очень часто ошибки при модернизации одной из подсистем (обычно с целью оптимизации) приводят к появлению ошибок в других подсистемах. Проблема усугубляется тем, что системы подобной сложности создаются не одним человеком, а целой группой разработчиков.
Модель программной системы
При проектировании программных систем высокой сложности и ответственности основным является этап создания функциональной модели. Исследуя модель, можно прогнозировать поведение проектируемой программной системы, ее функциональные возможности, недостатки и ограничения. Программная система не должна выходить за рамки своей модели. Иначе это будет "мутант" с непредсказуемым поведением.
Нет ничего удивительного в том, что 3 пункта из 7 перечисленных требований относятся к проблемам технологии программирования. Жизнеспособность любого сооружения зависит от продуманности архитектуры и качества кирпичиков. И строительный материал выбирается в соответствии с архитектурой. Исходя из этих азбучных инженерных истин, придумаем сначала архитектуру и только затем подберем материал.
В предыдущих рассуждениях "капризного" заказчика прозвучало желание то разрезать систему на несколько компьютеров, то собирать на одном все или часть. При этом подразумевается, что компьютеры соединены в сеть. Информация, полученная одним из компьютеров извне, должна быть доступна всем компьютерам. Количество узлов в сети зависит от физических характеристик используемых компьютеров (быстродействие CPU, максимально возможное число каналов связи с контроллером и так далее.) и потребностей конкретного технологического объекта.
Из-за тотальной распространенности DOS и Netware в массовом сознании укоренилось неверное понимание технологии клиент-сервер: в качестве клиента должен быть использован целый компьютер, в качестве сервера - целый компьютер, помощнее. Сервер ассоциируется с компьютером, а должен ассоциироваться с РЕСУРСОМ. Далее, чтобы избежать путаницы, будем использовать нейтральную терминологию.
Предложим нашему заказчику программную систему на основе технологии интеллектуальных сервисов. Сервис представляет собой автономный программный модуль, выполняющий определенные функции и оперирующий определенным ресурсом. Доступ к ресурсу осуществляется только через соответствующий сервис. Сервис очень похож на привычный сервер, за тем исключением, что сервер, в отличие от сервиса, не может являться инициатором обмена информацией, а только лишь отвечает на запросы.
В программной системе станции оперативного сбора данных и управления можно выделить три основных типа сервисов: сервис связи с контроллером - Controller Link Service (CLS), сервис интерфейса пользователя - User Interface Service (UIS) и сервис архивов истории и протоколов событий - Archive Base Service (ABS). Ресурсом для CLS является канал связи с контроллером, для UIS - устройства ввода и визуализации, для ABS - диски и тому подобное.
В роли клиента сервисов выступает программный модуль, который так и будем называть клиентом. Только клиент знает, какие данные из какого сервиса должны быть взяты и в каком формате в какой сервис направлены. Сервис может обслуживать нескольких клиентов и обеспечивать им одновременный доступ к ресурсу, сохраняя при этом целостность и непротиворечивость данных. Один клиент в состоянии работать с несколькими сервисами одновременно независимо от их типа.
Сервисы и клиенты могут быть любых типов, но они обязаны подчиняться определенным правилам взаимодействия. Общаясь с любой службой сферы обслуживания, мы исходим из двух характеристик: режима, принципа работы и специализации службы. Попытка в 3 часа ночи воспользоваться услугами прачечной ни к чему не приведет, хотя железнодорожный вокзал в это время работает. Попытка заказать бифштекс в той же прачечной в 12 часов дня вызовет в лучшем случае отказ, однако в киоске в это время можно купить и газету и календарь. Важно, что клиент априори знает, с какой службой на каком языке и когда разговаривать.
Если формализовать все сказанное, то каждая служба (сервис) подчиняется определенной дисциплине и общается с клиентами по определенному протоколу. Дисциплина регламентирует порядок функционирования сервиса - какие действия, в каком порядке, в какое время, в каком случае и как необходимо совершать. Протокол определяет, какая информация, какого содержания и в каком формате передается от клиента к сервису и обратно. Сервис может одновременно иметь несколько дисциплин и протоколов, используя их в соответствии с потребностями клиентов.
При всей наглядности такой модели необходимо отметить, что предметом услуг, предоставляемых программными сервисами, является информация, обладающая уникальным свойством мультипликативности, суть которого в том, что можно создавать много абсолютно идентичных ее копий.
Информация, циркулирующая в системе, интепретируется в соответствии с протоколом как:
Возвращаясь к аналогии со службами сферы обслуживания, конфигурацию можно сравнить с подпиской на газету (долгосрочный заказ), команду с вызовом сантехника, запрос на получение данных с обращением в справочное бюро, получение данных с результатом вышеперечисленных действий.
Теперь попробуем уложить нашу модель в прокрустово ложе наших же требований.
Соответствие модели выдвигаемым требованиям:
1) Скорость, удобство использования, соответствие решаемой задаче, логичность интерфейса .
Логичность интерфейса и удобство использования скорее связаны не с моделью, а с осознанием создателями программной системы потребностей пользователя, специфики применения и условий эксплуатации. Скорость зависит от качества программирования и соответствия средств программирования решаемой задаче. Обсуждением этой проблемы мы займемся ниже.
2) Переконфигурация "на лету".
Клиент в любой момент может переконфигурировать свою информацию на сервисе, удалить часть конфигурации или добавить. Эта возможность заложена в свойствах сервиса при его создании.
3) Надежность. Выборочное резервирование.
Надежность имеет непосредственное отношение к функциональной модели. Например, выход из строя сервиса архивирования данных (ABS) по какой-либо причине (ошибки программирования, разрушение ресурса и т. д.) не приведет к выходу из строя интерфейсов пользователей-операторов и сервисов связи с контроллерами. В результате оперативное отображение текущего состояния технологического объекта и управление будут доступны пользователю и начнут нормально функционировать.
Горячее резервирование реализуется на основе способности клиента соединяться одновременно с несколькими сервисами любого типа. Для горячего резервирования используются сервисы одного типа. Например, у нас имеются два компьютера, на каждом из которых установлен сервис архивирования данных. Клиент отправляет данные истории на оба сервиса. При выходе из строя одного из них клиент распознает это и запрашивает информацию (графики истории, протоколы) из другого, работающего сервиса. При восстановлении вышедшего из строя сервиса клиент распознает его, конфигурирует и продолжает работу с ним. Параметры, подлежащие резервированию, определяются в конфигурации.
4) Масштабируемость.
Система на базе сервисов абсолютно масштабируема. Минимальный вариант: все сервисы и клиенты располагаются на одном компьютере, разделяя процессорное время. Максимальный вариант: каждый сервис имеет в своем монопольном владении не только свой ресурс, но и целый процессор. Промежуточные варианты: часть системы находится на одном компьютере, а часть на другом. В результате система может быть масштабирована в зависимости от количества информации, которую нужно обрабатывать и необходимой скорости обработки. Можно также использовать разнокалиберные ПК в одной системе, распределяя нагрузку соразмерно мощности. Последнее свойство особо ценно, если уже имеется некоторый парк унаследованных машин.
5) Внешний доступ к информации системы сбора данных и управления.
Поскольку сервису все равно, какие функции выполняет клиент (если последний поддерживает правильные дисциплины и протоколы), то можно создать клиент нового типа, который будет пользоваться информацией, имеющейся в системе. Например, клиент, подсоединенный к сервисам связи, расположенным на разных технологических объектах (установках), будет получать с каждого сервиса некоторое количество параметров, в совокупности отражающих работу более крупного подразделения (цеха, завода).
6) Расширяемость.
При необходимости, скажем, добавления нового типа контроллера нужно создать новый сервис с описанными выше свойствами (дисциплинами и протоколами).
7) Модернизируемость.
Внутренняя оптимизация сервиса для увеличения производительности согласно модели не выходит за рамки протокола и дисциплины и на работу других сервисов повлиять не может.
В результате для конкретной технологической установки можно складывать систему из сервисов-"кирпичиков" в соответствии с потребностями. Число и мощность необходимых компьютеров определяется числом необходимых ресурсов. Число ресурсов и их типы определяются требуемым количеством рабочих мест операторов, количеством подключаемых контроллеров и количеством баз архивирования.
Операционная среда
Сервисы должны прозрачно взаимодействовать в сети компьютеров - неважно, находятся они на одном узле сети или на разных. Сеть из компьютеров выглядит для программ как один большой компьютер. Такие системы называют распределенными.
То, что лукаво было названо сервисом, следует признать объектом ООП в чистом виде по всем пяти статьям: децентрализация функций, контрактный характер отношений (протоколы и дисциплины), классификация (типы сервисов), связность объектов в системе (п. п. 6-7 требований), инкапсуляция (по определению). Таким образом, наша модель ничто иное как набор взаимодействующих распределенных объектов.
Первое, что вспоминается в этой связи - CORBA, DSOM, Network OLE. Простая, казалось бы, модель вдруг обрастает ограничениями: прощай real-time, прощай экономное использование ресурсов, "унаследованные" - на свалку! Но эти распределенные среды призваны решать задачи, отличные от поставленных нами, и их использование неоправданно.
Для реализации нашей модели нужна многозадачная распределенная среда реального времени с эффективным и простым механизмом передачи информации между задачами-объектами и сносными потребностями в ресурсах. Для этого она должна быть модульной. Например, если на каком-то компьютере не нужна видеосистема, то эту часть ОС можно и не запускать, а при необходимости запустить на ходу. К счастью, такая операционная система существует, и называется она QNX.
Последнее замечание
Целью автора было доказать не только достаточность технологии распределенных объектов для решения задач автоматизации, но и необходимость ее применения. Ясная функциональная схема и правильный выбор средств реализации позволяют получить программную систему с лучшими функциональными характеристикам и уменьшают вероятность ошибок, которые в системах управления обходятся дорого.
Большинство операционных систем насаждают "совковую" идеологию отношений между OС и программами: для улучшения условий жизни и просто для выживания программе-гражданину приходится постоянно обманывать операционную систему-государство. На что последнее отвечает непредсказуемостью и даже репрессиями. Идеология OС QNX достойна подражания: для всех членов общества, от Высокорожденного Драйвера до партикулярной программки, установлены единые правила и механизмы. Быстродействие и высокая эффективность механизмов OС являются следствием подобной унификации.
QNX - 32-разрядная многозадачная распределенная операционная система реального времени, обладающая модульной архитектурой и простым (поэтому высокоэффективным) механизмом передачи сообщений между процессами независимо от их местонахождения в сети. Именно эти исключительные характеристики делают QNX идеальной операционной средой для реализации предлагаемой модели, и, пожалуй, единственной, если вспомнить про "унаследованные" 386-е и 486-е.
SWD Real Time Systems,http://www.swd.ru
