История одного проекта
История одного проекта
Персональные компьютеры широко используются для контроля и управления работой таких технологических процессов, как конвейеры автомобильных заводов, установки производства нефтепродуктов, системы учета потребления энергоресурсов и т.д. Подобные технологические процессы могут содержать тысячи единиц разнообразного оборудования, которым необходимо согласованно управлять в режиме реального времени для обеспечения нормальной работы всего технологического процесса. Системы контроля и управления часто состоят из большого числа различных датчиков, счетчиков и контроллеров, рассредоточенных на значительных расстояниях и объединенных разнообразными каналами связи. И все это опрашивается и управляется одним или несколькими компьютерами, на которых функционирует специальное программное обеспечение (ПО) автоматизированных систем управления технологическими процессами (АСУТП).
Разработка ПО даже для небольших АСУТП очень трудоемка. Необходимо запрограммировать низкоуровневые операции обмена с контроллерами и счетчиками, отображение информации в различном виде, архивирование и обработку измерительных данных, логику контроля и управления самим технологическим процессом и заставить все это работать в режиме реального времени. В создании АСУТП большую роль играют специалисты по "железу", что требует тесного взаимодействия программистов и электронщиков. Поэтому разработкой ПО АСУТП занимаются отдельные коллективы, имеющие опыт и собственные наработки. Но даже наличие большого опыта и накопленных за много лет собственных библиотек оказывается недостаточным в современных экономических условиях, особенно с учетом бурного развития информационных технологий. Еще 5-7 лет назад можно было создавать АСУТП на базе 286-х и 386-х компьютеров под управлением MS-DOS и тратить на разработку и внедрение более полугода. В настоящее время требуется применение Windows 9x на рабочих местах и внедрение готовых систем в течение одного-двух месяцев. Да еще необходимо обеспечить упрощенную замену морально (но не физически) устаревшего оборудования.
В развитых странах уже давно существует разделения труда - ряд фирм выпускает специализированные инструментальные системы (SCADA-пакеты), которые используются прикладными разработчиками для реализации конкретных АСУТП. Для белорусских программистов АСУТП зарубежные SCADA-пакеты практически недоступны из-за их высокой стоимости (от нескольких тысяч до нескольких десятков тысяч долларов, в зависимости от конфигурации), а отечественных SCADA-пакетов просто нет. Процветающие предприятия (нефтехимического комплекса, например) имеют возможность покупки не только SCADA-систем, но и готовых АСУТП западного производства, стоимость которых измеряется десятками тысяч долларов. Однако, подавляющее большинство отечественных заказчиков, заинтересованных во внедрении компьютеризированных АСУТП, не могут позволить себе подобных затрат и обращаются к белорусским разработчикам. А у последних нет средств на приобретение SCADA-пакетов, и создание АСУТП значительно усложняется и затягивается. Сложность разработки приводит к увеличению стоимости, а увеличенная стоимость и длительность внедрения АСУТП отпугивает многих потенциальных клиентов, и круг замыкается.
На первый взгляд может показаться, что разработка отечественного SCADA-пакета является наилучшим выходом из сложившейся ситуации. Но это слишком далеко от истины, что подтверждается опытом отдела ПО АСУТП гомельского КБ системного программирования.
В начале 90-х годов в данном отделе сложилось отчетливое представление о необходимости создания собственного, дешевого, но мощного инструментария разработки ПО АСУТП, который бы позволял быстро и качественно выполнять заказы любой сложности. А стоимость разработки конкретных систем не превышала бы возможностей большинства белорусских предприятий в современной экономической ситуации. Время подтверждало правильность намерений, и с 1994-го года начались работы по созданию собственного SCADA-пакета, получившего в дальнейшем название SCADA Objectizer.
При создании SCADA Objectizer была осуществлена попытка применить объектно-ориентированный подход к проектированию и реализации ПО АСУТП. В традиционных SCADA-пакетах конструирование ведется на уровне обезличенных каналов ввода-вывода (тегов). Поэтому в них нет возможности агрегирования нескольких конструируемых элементов в один более крупный. Нельзя, например, получить объект "Насосная станция", включающий в себя состояние всего установленного на насосной станции оборудования. Вместо этого приходится оперировать набором тегов, каждый из которых связан с конкретным датчиком или контроллером. Хорошо, если набор содержит не более десяти тегов, но бывает, что набор содержит сотни, а то и тысячи тегов. И нет способа разбивать проект на несколько уровней детализации - всегда существует только множество тегов.
От SCADA Objectizer требовалась поддержка конструирования на уровне объектов и разбиения представления конкретной задачи на несколько уровней детализации. В результате двухлетних поисков была выработана специально предназначенная для этого агентно-ориентированная модель, согласно которой SCADA Objectizer оперирует множеством агентов. Каждый агент может находиться в нескольких определенных проектировщиком состояниях. Агент может иметь набор определенных проектировщиком атрибутов. Агенты обмениваются между собой сообщениями. Для каждого агента задаются сообщения, которые он может обрабатывать в том или ином состоянии. Агенты обрабатывают сообщения посредством событий, имеющих назначенные проектировщиком приоритеты. Возникающие в результате получения сообщений события обрабатываются в реальном времени в зависимости от приоритета события. Фокус в том, что в отличие от равноправных тегов, агенты играют совершенно различные роли, назначаемые самим проектировщиком АСУТП. Агенты могут управлять наборами подчиненных агентов, ничего не зная об их внутреннем устройстве. Достаточно только знать, какие сообщения обрабатываются подчиненными агентами. В свою очередь, подчиненные агенты могут управлять своими подчиненными агентами и т.д.
В общем-то очень простая и удобная модель. Только реализация SCADA-пакета на ее основе оказалась на удивление трудоемкой и длительной. К сожалению, время опровергло два важнейших решения, принятых в начале разработки. Во-первых, в качестве операционной системы была выбрана система OS/2, не имевшая в 1994-1995 годах конкурентов по поддержке многозадачности и требовательности к ресурсам. Однако, IBM проиграл в войне с Microsoft и OS/2 стала экзотикой. Но к моменту, когда доминирование Windows стало окончательно ясным, уже был создан огромный объем кода, перенос которого под Windows до последнего времени является головной болью создателей SCADA Objectizer.
Во-вторых, SCADA Objectizer планировался в качестве визуального инструмента, требующего только эпизодического программирования на C++. Как оказалось на практике, создание удобного визуального инструмента является чрезвычайно трудоемкой работой, выполнить которую можно либо небольшим коллективом за длительное время, либо наняв большое количество программистов, занимающихся исключительно программированием пользовательского интерфейса. Именно по второму пути пошла российская фирма AdAstra, разработчик SCADA-пакета TRACE MODE. Судя по тому, что объявления о приеме на работу в AdAstra публиковались в течение длительного времени, поиск подходящих специалистов для них был не очень простым делом. Естественно, создатели SCADA Objectizer не обладали подобными финансовыми возможностями и были вынуждены обходиться собственными силами.
Но хуже всего то, что визуальное конструирование объективно содержит в себе множество трудностей. Пусть, например, есть десяток объектов, содержащих атрибут, который необходимо изменить с одного значения на другое. Если визуальный инструмент не поддерживает поиска объектов по содержимому атрибутов объекта, то необходимо вручную двигаться по списку объектов, вызывать для каждого окно свойств, искать там значение атрибута и только затем, если нужно, изменять значение атрибута. После нескольких повторений подобной операции задаешься вопросом о том, почему же инструмент не поддерживает поиска по значению атрибута в объекте. Только реализовать подобный поиск чрезвычайно тяжело. В то же время, средствами поиска и замены в текстовом файле обладает практически любой текстовый редактор. И если бы описания объектов хранились в текстовом файле, то выполнение указанного поиска и замены выглядело бы тривиальной задачей даже с использованием Norton Commander.
Несмотря на все объективные и субъективные трудности, в 1998 году была создана первая работоспособная версия SCADA Objectizer, а в 1999 году произошло первое успешное внедрение АСУТП, созданной средствами SCADA Objectizer, на одном из предприятий Гомельской области. SCADA Objectizer образца 1998, 1999 и начала 2000 годов работал в OS/2, состоял из визуального конструктора и модуля времени исполнения. В конструкторе создавались векторные мнемосхемы, описания агентов, их состояний, сообщений и событий. Код обработки событий писался на C++ и помещался в указанные разработчиком DLL. Созданные в конструкторе описания, включая векторные мнемосхемы, сохранялись в объектно-ориентированной базе данных. Модуль времени исполнения считывал описания из базы данных, подгружал необходимые DLL и обеспечивал циркуляцию сообщений и обработку событий в реальном времени.
Весной 2000 года для оставшихся разработчиков SCADA Objectizer стало очевидно, что продолжение развития SCADA Objectizer в выбранном направлении практически невозможно. Во-первых, просто не было людских ресурсов на развитие визуального конструктора. Во-вторых, предложения о применении OS/2 на рабочих местах АСУТП вызывало негативную реакцию у потенциальных заказчиков по объективным (сложность администрирования в гетерогенных сетях, сложность с драйверами современных периферийных устройств) и субъективным (существенные отличия от Windows) причинам. В-третьих, отсутствие для OS/2 таких же возможностей в поиске дополнительного программного обеспечения (реляционных СУБД, например), как в случае Windows и Linux. Последние две причины требовали перевода SCADA Objectizer на другую платформу, а именно - Windows. В-четвертых, несмотря на доминирование Windows в сфере офисных приложений, в сфере АСУТП для инструментальных пакетов часто желательна поддержка сразу нескольких операционных систем, например, QNX и Windows, QNX и Solaris, Linux и VxWorks. Это означало, что новую версию SCADA Objectizer требуется изначально создавать в переносимом виде, но даже простое переписывание имеющегося кода под Windows выглядело весьма утопическим.
Безуспешные поиски бесплатной, развитой и доступной переносимой оконной библиотеки для Windows, X-Windows и, желательно, OS/2, ввергли разработчиков SCADA Objectizer в еще большее уныние. И это при том, что агентно-ориентированная модель, заложенная в SCADA Objectizer, прекрасно зарекомендовала себя на практике и превзошла ожидания ее создателей. В итоге, выбор состоял либо в прекращении работ над проектом вообще, либо в поиске нового решения. И это решение было найдено.
Прежде всего, было решено отказаться от громоздкого визуального конструктора. Для описания агентов, состояний, сообщений и событий был разработан высокоуровневый событийно-ориентированный язык описания SOL (Scada Objectizer Language) и создан транслятор, преобразующий описания агентов и код обработчиков событий в C++ текст. Часть модуля времени исполнения, занимающаяся поддержкой реального времени, была выделена в отдельную библиотеку. В результате, C++ текст, полученный после трансляций SOL-описаний, компилируется C++ компилятором и линкуется с библиотекой поддержки реального времени. На выходе получается единственный исполнительный модуль, который содержит в виде черного ящика всю логику АСУТП. Для взаимодействия "черного ящика" и остального мира был разработан протокол взаимодействия исполнительного модуля (сервера) и всеми заинтересованными приложениями (клиентами). Данный протокол реализован на основе TCP/IP, а для его поддержки в клиентских программах предназначена вспомогательная DLL. Отображение мнемосхем полностью написано на Java, что позволяет не только создавать рабочие места АСУТП для любых платформ, но и оформлять их в виде Web-страниц. Из предыдущей версии SCADA Objectizer остался только редактор мнемосхем, работающий в настоящее время под OS/2 с промежуточным хранением мнемосхем в объектно-ориентированной базе данных, но выходное представление мнемосхем для Java подготавливается на XML.
В результате транслятор SOL, результирующий C++ код, и библиотека реального времени уже работают под управлением Win32 (Windows 98, NT 4.0), OS/2, Linux и легко могут быть перенесены на любую платформу, поддерживающую нити и имеющую современный компилятор C++ с библиотекой STL. Средства отображения переносимы по определению, т.к. написаны на Java. Протокол взаимодействия сервера и клиентов позволяет осуществлять взаимодействие узлов сети с разной аппаратной архитектурой.
Использование нового SCADA Objectizer в тестовых примерах оказалось на удивление простым и удобным. Действия, которые в визуальном конструкторе требовали длительной и утомительной работы, выполняются в текстовых файлах в считанные мгновения. А возможность распространения мнемосхем технологического процесса по Intranet в виде обычных Web-страниц заложена в SCADA Objectizer изначально и не требует ни малейших усилий со стороны разработчика конкретной АСУТП. Совсем недавно многие производители коммерческих SCADA-пакетов встраивали аналогичные средства в последние версии своих продуктов, преподнося это как величайшее достижение и продавая по большим ценам.
То, что SCADA Objectizer создает исполнительный модуль в виде "черного ящика", не имеющего средств диалогового интерактивного интерфейса, может показаться неудобным, т.к. требуется вручную создавать диалоговые программы для рабочих станций АСУТП. Но это поверхностное представление. Протокол клиент-серверного взаимодействия SCADA Objectizer чрезвычайно прост. Более того, для всех поддерживаемых платформ имеется клиентская библиотека на C++, скрывающая детали протокола. Для платформы Win32 данную библиотку можно использовать в таких средах, как Delphi и VisualBasic (не говоря уже о Visual C++, Watcom C++ и C++Builder). В результате даже очень сложные формы для диалоговых программ можно без проблем подготовить в VisualBasic и они действительно будут управлять исполнительным модулем. Еще на форме посредством ActiveX можно разместить элементы WebBrowser, которые будут отображать мнемосхемы технологического процесса. И для этого совсем не нужны глубокие знания C++. А еще диалоговые программы для рабочих станций АСУТП можно писать на Java. Это не так просто, но зато однажды написанная форма сможет работать на любой поддерживающей Java платформе и на любом узле, соединенным с исполнительным модулем SCADA Objectizer. Например, руководитель предприятия может наблюдать и управлять технологическими процессами собственного предприятия через Internet, даже находясь где-нибудь на Гавайях (хотя это еще не удалось протестировать).
В настоящее время SCADA Objectizer содержит около шестидесяти тысяч строк кода на C++ и Java, а его развитием занимается очень небольшой коллектив. Понятно, что SCADA Objectizer не имеет такого красочного вида, как, например, TRACE MODE или Genesis. Но SCADA Objectizer наглядно показывает, что правильная идея, стройная, логичная и четкая концепция даже при отсутствии красивого оформления способна спорить с очень дорогими SCADA-пакетами. Однако, какой бы привлекательной ни была идея и насколько бы совершенной ни была реализация, востребованность продукта определяется реальными внедрениями. А это уже зависит от общего состояния отечественной экономики. И то, что крайне мало предприятий способны сейчас позволить себе внедрение современных АСУТП (а те, кто способен, предпочитают или вынуждены приобретать проверенные зарубежные SCADA-пакеты), не вселяет в авторов SCADA Objectizer большого оптимизма. Тем не менее, коллектив отдела ПО АСУТП гомельского КБСП, имея на вооружении SCADA Objectizer, не теряет веры в себя и собирается продолжать свои разработки. Евгений Охотников, eao197@altavista.com (c) компьютерная газета
Персональные компьютеры широко используются для контроля и управления работой таких технологических процессов, как конвейеры автомобильных заводов, установки производства нефтепродуктов, системы учета потребления энергоресурсов и т.д. Подобные технологические процессы могут содержать тысячи единиц разнообразного оборудования, которым необходимо согласованно управлять в режиме реального времени для обеспечения нормальной работы всего технологического процесса. Системы контроля и управления часто состоят из большого числа различных датчиков, счетчиков и контроллеров, рассредоточенных на значительных расстояниях и объединенных разнообразными каналами связи. И все это опрашивается и управляется одним или несколькими компьютерами, на которых функционирует специальное программное обеспечение (ПО) автоматизированных систем управления технологическими процессами (АСУТП).
Разработка ПО даже для небольших АСУТП очень трудоемка. Необходимо запрограммировать низкоуровневые операции обмена с контроллерами и счетчиками, отображение информации в различном виде, архивирование и обработку измерительных данных, логику контроля и управления самим технологическим процессом и заставить все это работать в режиме реального времени. В создании АСУТП большую роль играют специалисты по "железу", что требует тесного взаимодействия программистов и электронщиков. Поэтому разработкой ПО АСУТП занимаются отдельные коллективы, имеющие опыт и собственные наработки. Но даже наличие большого опыта и накопленных за много лет собственных библиотек оказывается недостаточным в современных экономических условиях, особенно с учетом бурного развития информационных технологий. Еще 5-7 лет назад можно было создавать АСУТП на базе 286-х и 386-х компьютеров под управлением MS-DOS и тратить на разработку и внедрение более полугода. В настоящее время требуется применение Windows 9x на рабочих местах и внедрение готовых систем в течение одного-двух месяцев. Да еще необходимо обеспечить упрощенную замену морально (но не физически) устаревшего оборудования.
В развитых странах уже давно существует разделения труда - ряд фирм выпускает специализированные инструментальные системы (SCADA-пакеты), которые используются прикладными разработчиками для реализации конкретных АСУТП. Для белорусских программистов АСУТП зарубежные SCADA-пакеты практически недоступны из-за их высокой стоимости (от нескольких тысяч до нескольких десятков тысяч долларов, в зависимости от конфигурации), а отечественных SCADA-пакетов просто нет. Процветающие предприятия (нефтехимического комплекса, например) имеют возможность покупки не только SCADA-систем, но и готовых АСУТП западного производства, стоимость которых измеряется десятками тысяч долларов. Однако, подавляющее большинство отечественных заказчиков, заинтересованных во внедрении компьютеризированных АСУТП, не могут позволить себе подобных затрат и обращаются к белорусским разработчикам. А у последних нет средств на приобретение SCADA-пакетов, и создание АСУТП значительно усложняется и затягивается. Сложность разработки приводит к увеличению стоимости, а увеличенная стоимость и длительность внедрения АСУТП отпугивает многих потенциальных клиентов, и круг замыкается.
На первый взгляд может показаться, что разработка отечественного SCADA-пакета является наилучшим выходом из сложившейся ситуации. Но это слишком далеко от истины, что подтверждается опытом отдела ПО АСУТП гомельского КБ системного программирования.
В начале 90-х годов в данном отделе сложилось отчетливое представление о необходимости создания собственного, дешевого, но мощного инструментария разработки ПО АСУТП, который бы позволял быстро и качественно выполнять заказы любой сложности. А стоимость разработки конкретных систем не превышала бы возможностей большинства белорусских предприятий в современной экономической ситуации. Время подтверждало правильность намерений, и с 1994-го года начались работы по созданию собственного SCADA-пакета, получившего в дальнейшем название SCADA Objectizer.
При создании SCADA Objectizer была осуществлена попытка применить объектно-ориентированный подход к проектированию и реализации ПО АСУТП. В традиционных SCADA-пакетах конструирование ведется на уровне обезличенных каналов ввода-вывода (тегов). Поэтому в них нет возможности агрегирования нескольких конструируемых элементов в один более крупный. Нельзя, например, получить объект "Насосная станция", включающий в себя состояние всего установленного на насосной станции оборудования. Вместо этого приходится оперировать набором тегов, каждый из которых связан с конкретным датчиком или контроллером. Хорошо, если набор содержит не более десяти тегов, но бывает, что набор содержит сотни, а то и тысячи тегов. И нет способа разбивать проект на несколько уровней детализации - всегда существует только множество тегов.
От SCADA Objectizer требовалась поддержка конструирования на уровне объектов и разбиения представления конкретной задачи на несколько уровней детализации. В результате двухлетних поисков была выработана специально предназначенная для этого агентно-ориентированная модель, согласно которой SCADA Objectizer оперирует множеством агентов. Каждый агент может находиться в нескольких определенных проектировщиком состояниях. Агент может иметь набор определенных проектировщиком атрибутов. Агенты обмениваются между собой сообщениями. Для каждого агента задаются сообщения, которые он может обрабатывать в том или ином состоянии. Агенты обрабатывают сообщения посредством событий, имеющих назначенные проектировщиком приоритеты. Возникающие в результате получения сообщений события обрабатываются в реальном времени в зависимости от приоритета события. Фокус в том, что в отличие от равноправных тегов, агенты играют совершенно различные роли, назначаемые самим проектировщиком АСУТП. Агенты могут управлять наборами подчиненных агентов, ничего не зная об их внутреннем устройстве. Достаточно только знать, какие сообщения обрабатываются подчиненными агентами. В свою очередь, подчиненные агенты могут управлять своими подчиненными агентами и т.д.
В общем-то очень простая и удобная модель. Только реализация SCADA-пакета на ее основе оказалась на удивление трудоемкой и длительной. К сожалению, время опровергло два важнейших решения, принятых в начале разработки. Во-первых, в качестве операционной системы была выбрана система OS/2, не имевшая в 1994-1995 годах конкурентов по поддержке многозадачности и требовательности к ресурсам. Однако, IBM проиграл в войне с Microsoft и OS/2 стала экзотикой. Но к моменту, когда доминирование Windows стало окончательно ясным, уже был создан огромный объем кода, перенос которого под Windows до последнего времени является головной болью создателей SCADA Objectizer.
Во-вторых, SCADA Objectizer планировался в качестве визуального инструмента, требующего только эпизодического программирования на C++. Как оказалось на практике, создание удобного визуального инструмента является чрезвычайно трудоемкой работой, выполнить которую можно либо небольшим коллективом за длительное время, либо наняв большое количество программистов, занимающихся исключительно программированием пользовательского интерфейса. Именно по второму пути пошла российская фирма AdAstra, разработчик SCADA-пакета TRACE MODE. Судя по тому, что объявления о приеме на работу в AdAstra публиковались в течение длительного времени, поиск подходящих специалистов для них был не очень простым делом. Естественно, создатели SCADA Objectizer не обладали подобными финансовыми возможностями и были вынуждены обходиться собственными силами.
Но хуже всего то, что визуальное конструирование объективно содержит в себе множество трудностей. Пусть, например, есть десяток объектов, содержащих атрибут, который необходимо изменить с одного значения на другое. Если визуальный инструмент не поддерживает поиска объектов по содержимому атрибутов объекта, то необходимо вручную двигаться по списку объектов, вызывать для каждого окно свойств, искать там значение атрибута и только затем, если нужно, изменять значение атрибута. После нескольких повторений подобной операции задаешься вопросом о том, почему же инструмент не поддерживает поиска по значению атрибута в объекте. Только реализовать подобный поиск чрезвычайно тяжело. В то же время, средствами поиска и замены в текстовом файле обладает практически любой текстовый редактор. И если бы описания объектов хранились в текстовом файле, то выполнение указанного поиска и замены выглядело бы тривиальной задачей даже с использованием Norton Commander.
Несмотря на все объективные и субъективные трудности, в 1998 году была создана первая работоспособная версия SCADA Objectizer, а в 1999 году произошло первое успешное внедрение АСУТП, созданной средствами SCADA Objectizer, на одном из предприятий Гомельской области. SCADA Objectizer образца 1998, 1999 и начала 2000 годов работал в OS/2, состоял из визуального конструктора и модуля времени исполнения. В конструкторе создавались векторные мнемосхемы, описания агентов, их состояний, сообщений и событий. Код обработки событий писался на C++ и помещался в указанные разработчиком DLL. Созданные в конструкторе описания, включая векторные мнемосхемы, сохранялись в объектно-ориентированной базе данных. Модуль времени исполнения считывал описания из базы данных, подгружал необходимые DLL и обеспечивал циркуляцию сообщений и обработку событий в реальном времени.
Весной 2000 года для оставшихся разработчиков SCADA Objectizer стало очевидно, что продолжение развития SCADA Objectizer в выбранном направлении практически невозможно. Во-первых, просто не было людских ресурсов на развитие визуального конструктора. Во-вторых, предложения о применении OS/2 на рабочих местах АСУТП вызывало негативную реакцию у потенциальных заказчиков по объективным (сложность администрирования в гетерогенных сетях, сложность с драйверами современных периферийных устройств) и субъективным (существенные отличия от Windows) причинам. В-третьих, отсутствие для OS/2 таких же возможностей в поиске дополнительного программного обеспечения (реляционных СУБД, например), как в случае Windows и Linux. Последние две причины требовали перевода SCADA Objectizer на другую платформу, а именно - Windows. В-четвертых, несмотря на доминирование Windows в сфере офисных приложений, в сфере АСУТП для инструментальных пакетов часто желательна поддержка сразу нескольких операционных систем, например, QNX и Windows, QNX и Solaris, Linux и VxWorks. Это означало, что новую версию SCADA Objectizer требуется изначально создавать в переносимом виде, но даже простое переписывание имеющегося кода под Windows выглядело весьма утопическим.
Безуспешные поиски бесплатной, развитой и доступной переносимой оконной библиотеки для Windows, X-Windows и, желательно, OS/2, ввергли разработчиков SCADA Objectizer в еще большее уныние. И это при том, что агентно-ориентированная модель, заложенная в SCADA Objectizer, прекрасно зарекомендовала себя на практике и превзошла ожидания ее создателей. В итоге, выбор состоял либо в прекращении работ над проектом вообще, либо в поиске нового решения. И это решение было найдено.
Прежде всего, было решено отказаться от громоздкого визуального конструктора. Для описания агентов, состояний, сообщений и событий был разработан высокоуровневый событийно-ориентированный язык описания SOL (Scada Objectizer Language) и создан транслятор, преобразующий описания агентов и код обработчиков событий в C++ текст. Часть модуля времени исполнения, занимающаяся поддержкой реального времени, была выделена в отдельную библиотеку. В результате, C++ текст, полученный после трансляций SOL-описаний, компилируется C++ компилятором и линкуется с библиотекой поддержки реального времени. На выходе получается единственный исполнительный модуль, который содержит в виде черного ящика всю логику АСУТП. Для взаимодействия "черного ящика" и остального мира был разработан протокол взаимодействия исполнительного модуля (сервера) и всеми заинтересованными приложениями (клиентами). Данный протокол реализован на основе TCP/IP, а для его поддержки в клиентских программах предназначена вспомогательная DLL. Отображение мнемосхем полностью написано на Java, что позволяет не только создавать рабочие места АСУТП для любых платформ, но и оформлять их в виде Web-страниц. Из предыдущей версии SCADA Objectizer остался только редактор мнемосхем, работающий в настоящее время под OS/2 с промежуточным хранением мнемосхем в объектно-ориентированной базе данных, но выходное представление мнемосхем для Java подготавливается на XML.
В результате транслятор SOL, результирующий C++ код, и библиотека реального времени уже работают под управлением Win32 (Windows 98, NT 4.0), OS/2, Linux и легко могут быть перенесены на любую платформу, поддерживающую нити и имеющую современный компилятор C++ с библиотекой STL. Средства отображения переносимы по определению, т.к. написаны на Java. Протокол взаимодействия сервера и клиентов позволяет осуществлять взаимодействие узлов сети с разной аппаратной архитектурой.
Использование нового SCADA Objectizer в тестовых примерах оказалось на удивление простым и удобным. Действия, которые в визуальном конструкторе требовали длительной и утомительной работы, выполняются в текстовых файлах в считанные мгновения. А возможность распространения мнемосхем технологического процесса по Intranet в виде обычных Web-страниц заложена в SCADA Objectizer изначально и не требует ни малейших усилий со стороны разработчика конкретной АСУТП. Совсем недавно многие производители коммерческих SCADA-пакетов встраивали аналогичные средства в последние версии своих продуктов, преподнося это как величайшее достижение и продавая по большим ценам.
То, что SCADA Objectizer создает исполнительный модуль в виде "черного ящика", не имеющего средств диалогового интерактивного интерфейса, может показаться неудобным, т.к. требуется вручную создавать диалоговые программы для рабочих станций АСУТП. Но это поверхностное представление. Протокол клиент-серверного взаимодействия SCADA Objectizer чрезвычайно прост. Более того, для всех поддерживаемых платформ имеется клиентская библиотека на C++, скрывающая детали протокола. Для платформы Win32 данную библиотку можно использовать в таких средах, как Delphi и VisualBasic (не говоря уже о Visual C++, Watcom C++ и C++Builder). В результате даже очень сложные формы для диалоговых программ можно без проблем подготовить в VisualBasic и они действительно будут управлять исполнительным модулем. Еще на форме посредством ActiveX можно разместить элементы WebBrowser, которые будут отображать мнемосхемы технологического процесса. И для этого совсем не нужны глубокие знания C++. А еще диалоговые программы для рабочих станций АСУТП можно писать на Java. Это не так просто, но зато однажды написанная форма сможет работать на любой поддерживающей Java платформе и на любом узле, соединенным с исполнительным модулем SCADA Objectizer. Например, руководитель предприятия может наблюдать и управлять технологическими процессами собственного предприятия через Internet, даже находясь где-нибудь на Гавайях (хотя это еще не удалось протестировать).
В настоящее время SCADA Objectizer содержит около шестидесяти тысяч строк кода на C++ и Java, а его развитием занимается очень небольшой коллектив. Понятно, что SCADA Objectizer не имеет такого красочного вида, как, например, TRACE MODE или Genesis. Но SCADA Objectizer наглядно показывает, что правильная идея, стройная, логичная и четкая концепция даже при отсутствии красивого оформления способна спорить с очень дорогими SCADA-пакетами. Однако, какой бы привлекательной ни была идея и насколько бы совершенной ни была реализация, востребованность продукта определяется реальными внедрениями. А это уже зависит от общего состояния отечественной экономики. И то, что крайне мало предприятий способны сейчас позволить себе внедрение современных АСУТП (а те, кто способен, предпочитают или вынуждены приобретать проверенные зарубежные SCADA-пакеты), не вселяет в авторов SCADA Objectizer большого оптимизма. Тем не менее, коллектив отдела ПО АСУТП гомельского КБСП, имея на вооружении SCADA Objectizer, не теряет веры в себя и собирается продолжать свои разработки. Евгений Охотников, eao197@altavista.com (c) компьютерная газета
Компьютерная газета. Статья была опубликована в номере 37 за 2000 год в рубрике программирование :: разное
