АСДУ без границ. Преодоление архитектурных ограничений программно-вычислительных комплексов в автоматизированной системе диспетчерского управления

Диспетчерское управление (ДУ) трубопроводным транспортом нефти и газа – сложный непрерывный технологический процесс, предъявляющий высокие требования к АСУ, в том числе, к её программному обеспечению.

На каждом уровне ДУ применяются специализированные прикладные программные средства, являющиеся сложными системами, которые решают такие задачи, как:

• структурированное хранение данных;

• направленный поиск и представление в произвольной форме информации для анализа текущих и ретроспективных режимно-энергетических показателей;

• решение режимно-технологических задач адаптивного моделирования, оптимального планирования и прогнозирования режимов работы трубопроводных систем.

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

В последнее десятилетие разработка ПО перешла от разработки стационарных программ к разработке ПО как услуг (Software as a Service, SaaS) на основе облачных технологий.

Данный переход является результатом совокупности факторов:

• Появление и широкое распространение многоядерных процессоров привело к противоречию существующей массовой парадигмы программирования — создание последовательных программ – с многоядерностью и многопроцессорностью.

• Увеличение разрыва в производительности клиентских и серверных ЭВМ. Создание высокопроизводительных ЦОД позволяет не только снизить требования к клиентским устройствам, но и решать задачи, превосходящие ресурсоемкостью возможности отдельных рабочих станций.

• Ускорение цикла разработки ПО до практически непрерывного: разработчики стараются по возможности поддерживать контакт с пользователями для улучшения своего продукта. Идет взаимовыгодное сотрудничество: пользователи оперативно получают обновления, а разработчики – отчеты об ошибках и пожеланиях. Однако это ведет к проблеме быстрого и прозрачного для пользователей получения обновлений.

• Развитие мобильных устройств и сетей передачи данных, методов и средств защиты передаваемой информации дает возможность организации удалённого доступа к информации практически в любой момент.

• Расширение списка клиентских устройств за счет мобильных телефонов и планшетных компьютеров, имеющих отличные от персональных компьютеров характеристики и программно-аппаратную платформу, усугубило проблему переносимости ПО с одной платформы на другую.

На первых этапах построения ПВК разработка, как правило, ведется рабочими группами небольшого размера, причем работа нередко носит инициативный характер. Для этих этапов характерно отсутствие должного внимания к документированию и формализации проектирования, поскольку основные усилия разработчиков направлены на реализацию ключевых функциональных возможностей.

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

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

Рост размерности решаемых задач повышает требования к вычислительным мощностям, в частности, к объёму памяти. В существующих ПВК в оперативную память процесса загружается полная объектная модель, с которой и происходит дальнейшая работа. Механизм сохранения объекта в виде байтовых последовательностей с последующим восстановлением называется сериализацией. Сериализация решает задачу устойчивости объекта – одной из важнейших характеристик объектно-ориентированного подхода, обеспечивающей возможность его существования во времени и пространстве независимо от процесса, породившего объект. Кроме того, сериализация обеспечивает максимальное быстродействие, но по мере роста числа объектов и задач, связанных с обработкой нестационарных процессов на длительных интервалах времени, такое решение становится неприемлемым из-за ограничений на доступные объемы оперативной памяти и необходимо совершать переход к новым способам организации хранения и работы с данными.

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

Переход на распределённую модель взаимодействия

Решением отдельных проблем стали концепция открытых стандартов и спецификаций для разработчиков ПО и развертывание ПО в высокопроизводительных ЦОД (облаках) с предоставлением доступа функциональности через тонкие клиенты.

На данный момент в России отсутствует стандарт, определяющий понятие «облако», наиболее распространённое определение облачным технологиям было сформулировано в 2011 г. в рекомендациях Национального института стандартов и технологий США (НИСТ).

Согласно рекомендациям НИСТ, облако должно удовлетворять следующим критериям:

• самообслуживание по требованию (self-service on demand);

• доступ по сети для любых тонких и толстых клиентов;

• объединение ресурсов (англ. resource pooling);

• эластичность, или масштабируемость;

• учёт объёма предоставленных услуг.

Таким образом, облако даёт возможность потребителю самостоятельно получать доступ с практически любого клиентского устройства в тот момент времени и к тому набору услуг, когда ему это необходимо, без необходимости взаимодействия с поставщиком услуг.

В свою очередь поставщики услуг объединяют ресурсы в единый пул, с возможностью динамического перераспределения ресурсов в зависимости от количества клиентов. Объём предоставляемых услуг конкретному клиенту контролируется, как правило, автоматически и может быть изменен по требованию клиента. При этом поставщиком ведется учёт объёмов предоставленных услуг.

Построенная на основе этих принципов архитектура подсистемы в рамках АСДУ может быть представлена следующим образом (рисунок 1).

Рисунок 1 Общая архитектура системы

Основными компонентами системы являются:

• расчётные комплексы;

• менеджеры схем, отвечающих за запуск комплексов с заданной схемой и обеспечивающих равномерную нагрузку между доступными вычислительными мощностями;

• веб-приложение, связывающее тонкие клиенты с расчётными комплексами, осуществляющее контроль доступа клиентов к задачам в соответствии с матрицей полномочий и ведущее учёт клиентских сессий;

• сетевой менеджер, осуществляющий взаимодействие между компонентами системы;

• тонкие клиенты, в качестве которых выступают веб-браузеры.

Архитектура системы позволяет организовывать через веб-приложение взаимодействие как между ПВК одного уровня ДУ, так и между ПВК смежных уровней управления [1].

Сравнительный обзор платформ разработки веб-приложений

Выбор платформы разработки веб-приложения основывался на следующих критериях:

1. Отказоустойчивость веб-сервера.

2. Уровень защищенности и безопасности веб-приложений: сервер является важным функциональным звеном в любой клиент-серверной системе, наличие уязвимостей в серверных компонентах делает уязвимой всю систему.

3. Уровень развития и сопровождения: выбранная платформа должна оперативно включать поддержку новых возможностей и технологий.

4. Механизмы разработки модульных приложений: возможность разработки сложных модульных проектов, с поддержкой параллелизма и многопоточности.

5. Кроссплатформенность: возможность использования веб-серверов под управлением основных ОС.

6. Стоимость разработки и развёртывания.

7. Совместимость с технологиями построения других компонентов среды: хотя взаимодействие компонентов можно организовать через универсальные протоколы, использование однородных технологий помогает не только ускорить обмен информацией между компонентами, но и дает возможность повторного использования кода в разработке смежных компонентов.

8. Использование распространенных языков программирования: использования специализированного языка программирования повышает порог вхождения в разработку и затрудняет процесс сопровождения.

В качестве альтернатив рассматривались наиболее популярные платформы по данным W3techs.com: PHP (более 80%), ASP.NET (около 16%) и Java (примерно 3%).

Основными преимуществами PHP являются свободное распространение, низкий порог вхождения, широкий набор возможностей за счет подключаемых модулей и возможность использования web-сервера под всеми основными ОС. Кроме того, PHP – скриптовый язык без строгой типизации, отсутствие которой можно отнести и к плюсам, и к минусам языка, в зависимости от решаемой задачи, уровня квалификации и профессиональных предпочтений. Как скриптовый язык PHP также проигрывает компилируемым языкам в производительности. Кроме того, недостатками являются отсутствие обратной совместимости между разными версиями платформы, отсутствие многопоточности и средств синхронизации для совместного доступа к ресурсам. Основная же проблема лежит в области безопасности: примерно четверть уязвимостей, собранных в базе National Vulnerability Database с 1996 г. связаны с PHP. Это объяснятся не только долгой историей и огромной популярностью технологии, но и ее относительной простотой: в результате отдельные расширения пишутся программистами невысокой квалификации, которые допускают ошибки и не уделяют должного внимания безопасности своих модулей.

Плюсами Java-приложений является кроссплатформенность и масштабируемость: за счет использования Java Virtual Machine, приложения выполняются одинаково на различных устройствах, независимо от программно-аппаратной платформы. Область применения Java распространяется от встраиваемых устройств и мобильных устройств до корпоративных серверов и суперкомпьютеров, хотя её использование на персональных компьютерах распространено не так широко. Особенно широко используется Java в корпоративном секторе. С момента создания Java взяла на себя роль интегратора внешнего мира и бизнес-логики предприятия и легла в основу построения некоторых стандартов разработки приложений. Популярности Java способствует также разнообразие инструментов сторонних разработчиков. Недостатками Java являются относительно высокий порог вхождения (Java-разработчик должен обладать хорошими знаниями в области ООП), производительность из-за необходимости компиляции кода во время исполнения и большое количество уязвимостей, в том числе, уязвимостей нулевого дня. При этом найденные уязвимости не всегда своевременно исправляются компанией Oracle, что подвергает опасности конечных пользователей, которые вынуждены блокировать Java из соображений безопасности.

ASP.NET (Active Server Pages) – платформа для создания серверных web-приложений корпоративного класса, разработанная Microsoft как альтернатива Java. Лежащая в её основе платформа разработки классических приложений .NET Framework используется в том числе и в некоторых ПВК АСДУ, таких как «Волна» и ПВК семейства ИРС [2]. Хотя в других ПВК используются иные технологии, изначальная их ориентированность на ОС Windows делает их схожими по общим принципам и инструментам разработки.

Распространению платформы способствовали следующие факторы:

• развитые механизмы работы с базами данных (ADO.NET и Entity Framework (EF)), язык встроенных запросов LINQ (Language-Integrated Query) и другие технологии;

• возможность разработки .NET приложений как для ОС Windows, так и для Mac OS X, Unix/Linux;

• совместимость между версиями платформы: разработанное под более ранние версии платформы ПО продолжает функционировать после обновления системы;

• разнообразие поддерживаемых языков программирования: C#, Visual Basic, F# и другие, причем в одном проекте может быть использовано несколько языков;

• общий набор типов данных для всех поддерживаемых языков;

• возможность низкоуровневого программирования.

Функции .NET Framework доступны для приложений ASP.NET, что позволяет создавать web-приложения, максимально приближенные по функциональности и внешнему виду к приложениям для ПК.

Анализ различных баз уязвимостей показал, что ASP.NET мало подвержен атакам. Например, в открытой базе уязвимостей OSVDB по запросу «ASP.NET» предоставляется информация всего о нескольких десятках уязвимостей с 2002 г., из них за 2014 г. – всего 7.

Недостаток ASP.NET заключался в необходимости в специализированном web-сервере MS IIS (Internet Information Services), являющегося частью ОС Windows. Однако в следующей версии платформы, ASP.NET 5, в числе изменений появилась возможность использования любого web-сервера для размещения разработанных приложений, улучшена производительность, а также совершился переход на свободное распространение и открытый исходный код.

Соответствие рассмотренных платформ сформулированным критериям представлено в таблице 1 (0 – невыполнение критерия, 0,5 – условное выполнение критерия, 1 – выполнение критерия).

Таблица 1 Сводные результаты сравнения платформ

Таким образом, для разработки веб-приложения была выбрана платформа ASP.NET, а именно ASP.NET MVC.

Для создания тонких клиентов используется стек HTML5+CSS3+Javascript [3], в частности для работы с Javascript используется AngularJS.

Переход на работу с единым хранилищем данных

При объединении ресурсов в облако важным элементом становится единое хранилище данных, переход от использования отдельных файлов для хранения схем к базам данных. Этот подход позволяет решить и проблемы обеспечения устойчивости объектов при использовании механизма сериализации.

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

Подобная задача обеспечения хранения значительных объемов данных в сочетании с оперативным доступом к ним и возможностями манипулирования характерна для СУБД. После рассмотрения возможных подходов к обеспечению устойчивости объектной модели на основе СУБД в качестве основного было выбрано решение, основанное на ее объектно-реляционном отображении в «развернутую» реляционную модель [4]. Данное решение обеспечивает приемлемые показатели производительности при сохранении достаточной гибкости и обратной совместимости с ранее созданными технологическими схемами. СУБД является компонентом общей расчётной среды, доступ к которой имеют только программно-вычислительные комплексы. Место модулей по работе с СУБД и веб-частью в общей архитектуре ПВК «Веста» представлено на рисунке 2.

Рисунок 2 Архитектура программно-вычислительного комплекса

Реализованная подсистема взаимодействия с СУБД предназначена для переноса технологических схем в корпоративные клиент-серверные базы данных и в локальные базы формата SQLite. Она также позволяет упростить задачу организации взаимодействия в распределенных вычислительных комплексах и интеграции в единое информационное пространство предприятия [5].

Литература:

1. Инновации в подготовке диспетчерского персонала газодобывающих и газотранспортных обществ/ Сарданашвили С.А., Митичкин С.К., Леонов Д.Г., Швечков В.А.// М.: Газовая промышленность. – 2015, №3. – С. 80-84.

2. Платформа для построения программно-вычислительных комплексов моделирования технологических цепей/ Бальченко А.С., Белинский А.В., Попов Р.В., Халиуллин А.Р.// Трубопроводные системы энергетики: математическое и компьютерное моделирование. Новосибирск: Наука, 2014. – С. 191-197.

3. Папилина Т. М. Платформа разработки прикладных web-инструментов для диспетчерского персонала нефтегазовой отрасли [Текст]/Папилина Т.М.// М. : Автоматизация, телемеханизация и связь в нефтяной промышленности. — 2015, №11. — С. 41-46.

4. Леонов Д.Г. Сравнительный анализ способов организации хранения информационных объектов с динамической структурой. М.: Информационные технологии и вычислительные системы. — 2015, №1. — C. 83-90.

5. Леонов Д.Г. Архитектурные решения, направленные на совершенствование пользовательских характеристик программно-вычислительных комплексов, применяемых в автоматизированных системах диспетчерского управления транспортировкой нефти и газа. М.: Автоматизация, телемеханизация и связь в нефтяной промышленности. 2015. № 10. С. 13-18.