Содержание к диссертации
Введение
1. Анализ проблем разработки и интеграции программно-вычислительных комплексов в АСДУ ЕСГ 14
1.1.Системы поддержки принятия решений в АСДУ ЕСГ 14
1.2. Характеристики эксплуатируемых комплексов моделирования 24
1.3.Оценка текущего состояния эксплуатируемых ПВК 36
1.4.Выводы по главе 1 38
2. Разработка методологии проектирования программно-вычислительных комплексов на основе открытой интеграционной платформы 40
2.1.Классификация интеграционных архитектур 40
2.2.Эволюция архитектуры ПВК «Веста» 49
2.3.Открытая интеграционная платформа как основа построения распределённых ПВК в АСДУ ЕСГ 55
2.4.Выводы по главе 2 60
3. Математическое моделирование компонентов открытой интеграционной платформы 62
3.1.Программно-вычислительные комплексы как сложные системы 62
3.2. Эволюция парадигм программирования и проектирования 64
3.3.Модели, основанные на формальных автоматах 74
3.4.Модели, основанные на сетях Петри 79
3.5.Модель состояний и оценка показателей функционирования системы 87
3.6.Имитационные модели 102
3.7.Выводы по главе 3 104
4. Применение современных информационных технологий в разработке программных систем на основе открытой интеграционной платформы 106
4.1.Этапы жизненного цикла интегрированного наукоёмкого программного обеспечения 106
4.2. Разработка высокопроизводительных систем 121
4.3.Принципы организации распределённого программного обеспечения 131
4.4.Переносимость программного обеспечения и кроссплатформенная разработка 142
4.5.Выводы по главе 4 157
5. Автоматизация программной реализации компонентов открытой интеграционной платформы 159
5.1.Автоматизация формирования программного кода компонентов ОИП на основе сетей Петри 159
5.2.Реализация сетевого взаимодействия 163
5.3.Организация хранения данных 177
5.4.Поддержка пользователей 187
5.5. Приложения, реализованные на основе ОИП 195
5.6.Выводы по главе 5 203
Заключение 205
Список сокращений и условных обозначений 208
Список литературы 210
Приложение А. Структура XML-шаблона SOA-транслятора 230
Приложение Б. XSLT-шаблон для преобразования CPN/CPP 231
Приложение В. Структура XML-описания технологических схем 232
- Характеристики эксплуатируемых комплексов моделирования
- Эволюция парадигм программирования и проектирования
- Разработка высокопроизводительных систем
- Приложения, реализованные на основе ОИП
Введение к работе
Актуальность проблемы
Диспетчерское управление Единой системой газоснабжения (ЕСГ) России – сложная распределённая иерархическая система, вертикальные уровни которой определяются административной системой соподчинённости, а горизонтальная распределённость соответствует категориям технологических комплексов ЕСГ (добыча, транспорт, переработка, хранение, распределение). В общей административной структуре диспетчерское управление занимает промежуточное положение между системами управления технологическими процессами и корпоративными системами управления. Автоматизированные системы диспетчерского управления (АСДУ) играют ключевую роль в управлении непрерывными технологическими процессами и объектами в ЕСГ, формируя в процессе своей работы как горизонтальные, так и вертикальные информационные потоки.
Автоматизация планирования, контроля и анализа состояния технологических процессов, а также оценки последствий возможных управляющих воздействий осуществляется с помощью систем поддержки принятия диспетчерских решений (СППДР), пронизывающих все уровни диспетчерского управления. К важнейшим элементам СППДР относятся специализированные программно-вычислительные комплексы (ПВК), которые обеспечивают как проведение режимных расчётов, так и решение задач многовариантного планирования, идентификации и поиска рациональных режимов с различными уровнями детализации. С ПВК тесно связаны тренажёрные комплексы, использующие общее с ними информационное и математическое обеспечение для моделирования деятельности систем газоснабжения в процессе обучения диспетчерского персонала.
Необходимость взаимодействия с информационными потоками АСДУ порождает задачу интеграции ПВК в Единое информационное пространство (ЕИП) ПАО «Газпром», создание и развитие которого осуществлялось в рамках Стратегии информатизации и Комплексной целевой программы технического перевооружения, реконструкции и развития автоматизированных систем управления технологическими процессами объектов ПАО «Газпром».
Поскольку интеграция не является фиксированным достигнутым состоянием, интеграционное решение должно обеспечивать дальнейшее эволюционное развитие, расширяемость и масштабируемость, то есть быть открытым.
Данная проблема не только имеет отраслевой масштаб, но и носит фундаментальный математический, программно-технический и организационный
характер. В настоящее время она не имеет удовлетворительного решения: оценка текущего состояния ЕИП показывает, что состояние инструментов моделирования и прогнозирования стационарных и нестационарных режимов функционирования систем газоснабжения не соответствует современным требованиям к автоматизации диспетчерского управления, а внедрённые решения носят незавершённый характер, фрагментарны, гетерогенны, уникальны для отдельных дочерних обществ даже в рамках одного вида деятельности и плохо интегрируются в единое информационное пространство.
Существующие принципы и организация разработки ПВК имеют ряд серьёзных недостатков:
вычислительные подсистемы ПВК используют, как правило, закрытые реализации моделей и алгоритмов, что приводит к дублированию реализации сходных вычислительных задач, увеличивает трудоёмкость разработки, затрудняет согласование результатов их работы;
отсутствуют как общий формат хранения и обмена данных, так и общие протоколы взаимодействия, что значительно затрудняет обмен данными между ПВК, а тем более использование одним ПВК вычислительных методов, реализованных в подсистеме моделирования другого;
несмотря на постепенный отход от монолитной архитектуры, основным способом организации взаимодействия компонентов ПВК является использование общей базы данных в рамках строго иерархичного взаимодействия «клиент-сервер»;
средства интеграции, предоставляемые комплексами, ориентированы в первую очередь на импортирование актуальных оперативных данных из SCADA-систем и на экспортирование отчётов по проведённым расчётам, но не на управление процессом вычислений;
текущий уровень разработки ПВК в целом плохо соответствует текущему уровню развития современных информационных технологий: лишь немногие ПВК используют в своих вычислительных подсистемах средства распараллеливания вычислений, ограничиваясь при этом реализацией многозадачности, ориентированной на многоядерные и многопроцессорные системы, использующие общую память; практически не используются реализации, ориентированные на вычислительные кластеры и массово-параллельные сопроцессоры; пользовательский интерфейс большинства ПВК традиционно ориентирован на работу с помощью полнофункциональных «толстых» клиентов, что затрудняет кроссплатформенную реализацию и использование мобильных платформ;
большинство эксплуатируемых ПВК разрабатывается малочисленными рабочими группами, что в сочетании с закрытостью реализаций обостряет роль человеческого фактора, а именно риски потери исходного кода и ряда компетенций, связанных с построением математических моделей и реализацией ключевых алгоритмов.
Таким образом, технология разработки ПВК, доминировавшая на протяжении всех лет развития АСДУ, затрудняет их использование в рамках единого информационного пространства и приводит к постепенному снижению качества их поддержки и усложнению модернизации из-за зависимости от отдельных разработчиков.
Необходим переход к качественно новой технологии разработки, изначально ориентированной на построение интегрированных распределённых систем, обеспечивающей открытость и эволюционное развитие программного продукта; от ориентации на разработку изолированных ПВК к разработке механизмов и определению правил взаимодействия разнородных комплексов, в том числе, разных уровней ДУ.
В качестве подобного принципиально нового решения в диссертационной работе предлагается создание открытой интеграционной платформы (ОИП), обеспечивающей унифицированность, расширяемость и масштабируемость, а также возможность выделения реализаций отдельных задач из монолитных комплексов в слабосвязанные сервисы в целях продления их жизненного цикла. Открытость подразумевает максимальное использование документированных спецификаций и интерфейсов, реализация которых в разнородных ПВК обеспечивает их прозрачное подключение к ОИП.
Решением проблемы эволюционного развития программного обеспечения является автоматизация его разработки, в основе которой лежит формализованное представление выбранных архитектурных решений, а именно модели отдельных компонентов системы и модели поведения системы в целом. Предложенные в диссертационной работе модели позволили перейти непосредственно к средствам автоматизации и методам оценки эффективности полученного результата.
Таким образом, комплекс исследований, проведённых в диссертации и направленных на формирование целостного представления о задачах построения современных распределённых интегрированных программно-вычислительных комплексов, является актуальным и требует определения соответствующих подходов к построению распределённых архитектур, способов формализации (математического моделирования) представления о проектируемых системах, а также ряда информационных технологий, обеспечивающих автоматизацию проектирования ПВК и используемых на различных этапах разработки.
Совокупность предложенных в диссертации алгоритмов и архитектурных принципов формирует методы решения поставленных проблем и задач, формализация с целью автоматизации которых достигается с помощью предлагаемых моделей, а рассматриваемые технологии обеспечивают практическую реализацию.
Степень проработанности темы исследования
Создание и развитие современных вычислительных систем разбивается на ряд разнородных задач, требующих рассмотрения различных подходов к организации управления процессом разработки, парадигм программирования и технологий построения распределённого гетерогенного программного обеспечения, которые не находили своего удовлетворительного решения до проведённых в диссертации исследований.
Интеграция разнородных компонентов требует привлечения понятийного аппарата, позволяющего описать процессы функционирования как отдельных компонентов, так и их взаимодействие. Для моделирования отдельных компонентов системы эффективным инструментом стало использование механизма конечных автоматов. Для перехода к моделированию их взаимодействия в рамках системы в целом в диссертации предложено применение аппарата иерархических раскрашенных сетей Петри. Это позволило формализовать взаимодействие существующих компонентов системы, провести эксперименты по подключению проектируемых компонентов и подготовить основу для дальнейшего автоматизированного формирования каркаса программного кода, отвечающего за взаимодействие ПВК и отдельных компонентов, использующих ОИП.
Модели на основе сетей Петри отражают структуру рассматриваемой системы, но не учитывают её поведение во времени и не позволяют оценить её эффективность и устойчивость к отказам, поэтому было предложено моделировать функционирование ОИП с помощью марковских случайных процессов с дискретными состояниями и непрерывным временем.
В ходе работы был изучен и проанализирован вклад отечественных и
зарубежных учёных в областях науки, связанных с темой диссертационного
исследования: Бермана Р.Я., Боэма Б., Буча Г., Вентцель Е.С., Воеводы А.А.,
Григорьева Л.И., Коротикова С.В., Костогрызова А.И., Котова В.Е.,
Митичкина С.К., Овчарова Л.А., Панкратова В.С., Питерсона Дж.,
Сарданашвили С.А., Селезнева В.Е., Ставровского Е.Р., Стёпина Ю.П., Сухарева М.Г., Трахтенгерца Э.А., Фаулера М., Флинна М. Дж., Шалыто А.А. и др.
Объектом диссертационного исследования являются специализированные программно-вычислительные комплексы, входящие в состав систем поддержки принятия диспетчерских решений в АСДУ ЕСГ.
Предметом диссертационного исследования являются методы, модели и технологии, обеспечивающие автоматизацию разработки и интеграцию распределённых гетерогенных программных комплексов в АСД У ЕСГ.
Цель и задачи исследования
Целью работы является построение, теоретическое обоснование и практическое подтверждение применимости методов, обеспечивающих решение проблемы автоматизированной разработки и интеграции распределённых гетерогенных программно-вычислительных комплексов в информационную инфраструктуру АСДУ ЕСГ.
Достижение поставленной цели потребовало решения следующих взаимосвязанных задач и проблем:
анализ и оценка проблем построения и функционирования существующих ПВК;
анализ подходов и проблем разработки интегрированного программного обеспечения и управления жизненным циклом сложных, в том числе, распределённых программных систем;
разработка архитектурных решений открытой интеграционной платформы c учётом технологий построения современных распределённых гетерогенных систем;
обоснование и построение моделей функционирования ОИП на основе адекватного выбранного способа формализации представления проектируемых распределённых систем;
построение моделей, обеспечивающих анализ и оценку показателей эффективности функционирования разрабатываемой системы;
разработка методов автоматизированного построения программных систем на основе предложенных моделей;
программная реализация компонентов, обеспечивающих функционирование в условиях гетерогенного окружения и применение полученных решений для разработки интегрированных ПВК.
Методы исследования
Для решения поставленных задач были использованы принципы системного анализа, объектно-ориентированного проектирования и программирования, построения распределённых и распараллеленных систем, а также модели и методы теории сетей Петри, теории марковских цепей и динамики средних.
Научная новизна работы
Наиболее существенными научными результатами, обеспечивающими теоретическое обоснование методов автоматизированной разработки и интеграции распределённых гетерогенных программно-вычислительных комплексов, являются:
разработка архитектурных решений ОИП, обеспечивающих интеграцию ПВК в единую гетерогенную распределённую программно-вычислительную среду АСДУ на основе стандартизированных протоколов и программных интерфейсов;
разработка моделей, описывающих функционирование и взаимодействие компонентов ОИП, интегрирующих программно-вычислительные комплексы в единую гетерогенную распределённую среду;
построение математических моделей, позволяющих провести анализ и оценку показателей эффективности функционирования ОИП;
разработка методов автоматизированного формирования программного кода для адаптируемого распределённого прикладного программного обеспечения.
Положения, выносимые на защиту
-
Архитектурные решения по построению ОИП, обеспечивающие интеграцию ПВК в единую распределённую вычислительную среду на основе стандартизированных протоколов и программных интерфейсов.
-
Комплекс математических моделей, описывающих работу и взаимодействие компонентов ОИП и интегрируемых с её помощью в единую распределённую гетерогенную среду программно-вычислительных комплексов.
-
Математические модели, позволяющие провести анализ и оценку показателей эффективности функционирования ОИП.
-
Методы автоматизированной разработки адаптируемого распределённого прикладного программного обеспечения на основе предложенных моделей построения ОИП.
Практическая ценность
Практическая ценность работы заключается в разработке открытой интеграционной платформы, обеспечивающей решение задачи интеграции разнородных ПВК в инфраструктуру АСДУ ЕСГ.
Предложенное решение позволит повысить эффективность процессов обработки и передачи данных в системах диспетчерского управления, обеспечив:
автоматизацию формирования программного кода на основе разработанного
транслятора;
преемственность и продление жизненного цикла эксплуатируемых ПВК с помощью предоставления доступа к реализованным в них задачам;
постепенный переход на новые реализации прикладных задач;
создание основы для применения распределённых вычислений и облачных технологий, для подключения мобильных и тонких клиентов. Средства ОИП были применены при разработке сетевого тренажёрного
комплекса ПВК «Веста-Тренажёр», обеспечивающего обучение диспетчерского персонала по управлению газотранспортной и газораспределительной системой, при разработке тонкого клиента, реализующего функциональность профессионального калькулятора диспетчера газотранспортной организации «Веста-Web», а также в рамках работ по созданию комплекса online-моделирования для использования в составе СППДР ООО «Газпром-трансгаз Санкт-Петербург».
Обоснованность и достоверность
Обоснованность разработанных в диссертации моделей и методов обеспечивается корректностью применяемого математического аппарата. Достоверность предложенных архитектурных решений и инструментальных средств, обеспечивающих интеграцию гетерогенных распределённых ПВК, подтверждается документами о внедрении результатов исследования и свидетельствами об официальной регистрации программы для ЭВМ [34-46].
Апробация работы
Основные результаты работы обсуждались на следующих конференциях: IV Всероссийская научно-методическая конференция «Тренажеры и компьютеризация профессиональной подготовки» (Москва, 1994); International Conference of Engineering Education (Москва, 1995); «Компью-Маркетинг’96» (Москва, 1996); I, VI-VIII, X, XI научно–технические конференции «Актуальные проблемы состояния и развития нефтегазового комплекса России» (Москва, 1997, 2005, 2007, 2010, 2014, 2016); 1-я Международная научно-техническая конференция «Развитие компьютерных комплексов моделирования, оптимизации режимов работы систем газоснабжения и их роль в диспетчерском управлении технологическими процессами в газовой отрасли» (Москва, 2002); 2-я Международная научно-техническая конференция Discom 2004 «Теория и практика разработки, промышленного внедрения компьютерных комплексов поддержки диспетчерских решений в газотранспортной и газодобывающей отраслях» (Москва, 2004); 3rd International Symposium on Hydrocarbons and Chemistry (Algerie, Ghardaia, 2006); III-VI Международные научно-технические конференции «Компьютерные технологии поддержки принятия решений в диспетчерском управлении газотранспортными и газодобывающими системами» (Москва, 2007, 2009, 2012, 2014); XIV Всероссийский научный семинар «Математические модели и методы анализа и
оптимального синтеза развивающихся трубопроводных и гидравлических систем» (Белокуриха, 2014); VII международная научно-техническая конференция «Газотранспортные системы: настоящее и будущее (GTS-2017)» (Москва, 2017).
Публикации
По теме диссертации опубликовано свыше 60 научных работ, основные из которых приведены ниже [1-46], в том числе 1 монография [17], разделы в 5 коллективных монографиях [18-22], 16 работ в изданиях из перечня ведущих рецензируемых научных изданий, рекомендованных ВАК РФ для публикации основных результатов диссертаций [1-16], из которых 12 работ — в журналах группы специальностей 05.13.00 «Информатика, вычислительная техника и управление» [2-12, 15], 13 программ для ЭВМ, зарегистрированных в качестве объектов интеллектуальной собственности [34-46]. Все результаты, включённые в диссертацию, получены лично автором.
Структура и объём работы
Диссертация состоит из введения, пяти глав, заключения, списка используемых сокращений, списка литературы и приложений. Общий объём работы — 235 страниц, в том числе 1 таблица, 69 рисунков, 6 листингов, 3 приложения, список литературы из 194 наименований.
Характеристики эксплуатируемых комплексов моделирования
Для разрабатываемых в настоящее время ПВК характерна модульная архитектура и клиент-серверный или распределённый подход, что соответствует рекомендации СТО Газпром 093-2011 [55]. Рассмотрим функциональность, архитектурные решения и подходы к интеграции наиболее распространённых российских и зарубежных ПВК (по информации из открытых источников).
ПВК «Астра-газ» (Рисунок 4) установлен и эксплуатируется во всех газотранспортных обществах (ГТО) и в ряде других дочерних обществ ПАО «Газпром», что делает его самым распространённым российским комплексом моделирования. Комплекс разработан ООО «Газпромразвитие», в настоящее время сопровождением ПВК «Астра-газ» занимается ООО «Газпром информ». Является стандартным компонентом типовой информационно-управляющей системы предприятия.
Комплекс широко используется при планировании комплексов планово-профилактических работ и оперативном управлении режимами работы ЕСГ [139; 140]. Для моделирования режимов работы газовых промыслов разработана версия ПВК «Астра-добыча».
В числе особенностей комплекса разработчики называют хранение фактических схем загрузки газотранспортных систем и создание система сопровождения комплекса разработчиками практически в реальном времени.
Программы комплекса реализованы с помощью языков программирования Fortran и Object Pascal (Delphi), и работают под управлением ОС семейства Windows. Интеграция со сторонними системами осуществляется на уровне данных, с помощью текстовых файлов, файлов MS Excel и прямого доступа к базам данных.
ПВК «Веста» (Рисунок 5) разрабатывается сотрудниками РГУ нефти и газа (НИУ) имени И. М. Губкина в качестве многоцелевого компьютерного тренажёрного комплекса для диспетчерских служб газотранспортных и газодобывающих обществ. Его назначением является подготовка и повышение квалификации диспетчерского персонала в области планирования диспетчерских графиков транспорта газа и управления динамическими режимами ГТС в штатных, предаварийных и аварийных ситуациях, а также проведение гидравлических расчётов газодобывающих промыслов, межрегиональных газотранспортных систем и региональных систем газоснабжения [69; 103; 170].
Заложенные в архитектуру ПВК «Веста» принципы модульности и объектно-ориентированного подхода позволили наращивать функциональность комплекса путём подключения дополнительных загружаемых модулей, сохраняя при этом преемственность с предыдущими версиями, в том числе обратную совместимость со старыми расчётными схемами. Базовая архитектура ПВК «Веста» послужила основой создания семейства комплексов, отличающихся основными решаемыми задачами и используемыми расчётными подсистемами (в том числе с поддержкой параллельных вычислений): «Веста-ГТС», «Веста-ГРС», «Веста-ГРО», «Веста-КС», «Веста-развитие», «Веста-тренажёр», «Веста-тренажёр (ЕСГ)», «Веста-Web».
Текущая архитектура комплекса изображена на рисунке 6. ПВК «Веста» реализован на С++ с использованием библиотеки MFC (Microsoft Foundation Classes) и работает под управлением ОС Windows. Интеграция со сторонними решениями осуществляется на уровне данных (текстовые файлы, файлы MS Excel, XML-файлы, доступ к СУБД). Проведённая оптимизация расчётных алгоритмов и использование многопоточных математических библиотек позволяет расчётной подсистеме эффективно использовать локальные вычислительные ресурсы.
Помимо локального режима работы, возможно функционирование ПВК «Веста» в режиме сетевого тренажёрного комплекса, позволяющего отрабатывать ситуации, требующие взаимодействия диспетчерских служб [71; 79].
В этом режиме активно используется транспортный модуль асинхронной передачи сообщений для организации сетевого взаимодействия ядра с распределёнными компонентами комплекса, ставший основой для реализации транспортного уровня интеграционной платформы.
Разработанный ФГУП «РФЯЦ-ВНИИТФ им. акад. Е.И. Забабахина» ПВК «Волна» предназначен для стационарного и нестационарного моделирования, мониторинга и оптимизации газотранспортных систем. Комплекс обеспечивает выполнение расчёта текущих режимов транспортировки газа в реальном времени и прогнозов процесса по заданному сценарию управляющих воздействий и оптимальных плановых режимов [3].
ПВК имеет распределённую архитектуру, предоставляя возможность эксплуатации в многопользовательском режиме (Рисунок 7). Система состоит из сервера расчёта, сервера с архивом данных, базы данных и консольных клиентов. Взаимодействие между компонентами осуществляется через отдельный модуль – коммуникатор [4].
Результаты расчёта с заданной периодичностью сохраняются в БД Oracle, клиентские консоли обычных могут подключаться к архиву для просмотра результатов расчётов в режиме онлайн либо за заданный промежуток времени, а также (при наличии соответствующих прав доступа) управлять сервером и корректировать входные данные. Также доступен режим автономного расчёта.
Обеспечивается получение информации из SCADA по протоколу OPC, а также экспорт результатов работы в СУБД Oracle, текстовые файлы и файлы MS Excel. ПВК «Волна» реализован на платформе .NET и работает под управлением ОС Windows.
Эволюция парадигм программирования и проектирования
Рассмотрим основные направления развития парадигм программирования с точки зрения применимости к построению больших интегрированных систем. Существует множество классификаций парадигм программирования, ни одна из которых не является строго иерархической из-за активного взаимопроникновения удачных концепций. Наиболее традиционной является классификация по отношению к способу описания логики программы: в виде последовательности действий либо в виде спецификации решения задачи. Другая важным признаком является отношение к способу взаимодействия компонентов: синхронное либо асинхронное программирование.
Императивное программирование — парадигма программирования, для которой характерно представление кода программы в виде последовательно исполняющихся инструкций (команд), при выполнении которых исходные и результирующие данные считываются и записываются в оперативную память. Интенсивно используются оператор присваивания и именованные переменные. Данная парадигма находит прямое соответствие в архитектуре большинства компьютерных систем, оперирующих с последовательным выполнением машинных команд, и в течение долгого времени являлась основным направлением, в рамках которого развивались технологии разработки.
Первым этапом в развитии императивного подхода стал переход от машинных кодов к первым ассемблерам — низкоуровневым языкам программирования, каждая команда которых соответствовала отдельному машинному коду, имея при этом представление, понятное человеку. Далее возникли первые языки программирования высокого уровня, одна инструкция которых уже могла транслироваться в несколько машинных команд. К основным языкам программирования этого поколения относятся Fortran, Cobol, Basic, Algol.
Структурное программирование
Дальнейшая борьба с возрастающей сложностью программного обеспечения привела к созданию методологии структурного программирования, основные положения которой были разработаны в конце 1960-х годов Э. Дейкстрой, Ч. Хоаром и Н. Виртом [40]. Предложенная в рамках структурного подхода идея декомпозиции стала основой и для последующего развития парадигм программирования. К основным принципам структурного программирования относятся: отказ от использования безусловного оператора перехода; использование произвольно вложенных друг в друга основных управляющих конструкций, включающих последовательность, ветвление, цикл; оформление логически законченных групп инструкций в виде блока, а повторяющихся блоков в виде подпрограмм. Для структурного программирования характерна пошаговая разработка методом «сверху вниз» [52]. К языкам программирования, создававшимся с учётом этой методологии, относятся Pascal, Modula-2, Ada.
Программные системы, построенные на принципах структурного подхода, представимы в виде тройки: = G, P, D , (2) где G – главная программа; P – множество подпрограмм; D – множество глобальных и общедоступных данных [65].
Применение идей структурного подхода к анализу и проектированию систем привело к созданию методологии структурного анализа и проектирования (SADT, structured analysis and design technique), развитием которой стала методология функционального моделирования IDEF0, ориентированная на представление изучаемой системы в виде набора взаимосвязанных функций.
Объектно-ориентированный подход
Несмотря на то, что структурное программирование было основано на декомпозиции алгоритмов, уже тогда возникло понимание важности правильной организации структур данных [18]. Дальнейшее развитие языков программирования шло по пути повышения роли абстрактных типов данных. Окончательное перемещение внимания на данные в качестве ключевых абстракций предметной области, обладающих самостоятельным поведением, привело к возникновению объектной декомпозиции, лежащей в основе объектно-ориентированного подхода, и вытесняющей алгоритмы на второй план.
Объектно-ориентированное программирование (ООП), ставшее основной методологией программирования с 1990-х годов, использует представление программы в виде совокупности взаимодействующих объектов, являющихся экземплярами определённых классов, в свою очередь образующих иерархию на основе наследования [12].
Помимо абстрагирования, отвечающего за формирования набора ключевых абстракций, описывающих предметную область, в ООП выделяется ряд компонентов, направленных на упрощение управления получившимся набором абстракций: инкапсуляция, позволяющая отделить внутреннее представление объекта от его внешнего поведения; модульность, позволяющая разложить систему на отдельные компоненты, решающие разные задачи; иерархия, позволяющая упорядочить набор абстракций, разложив его по уровням восприятия с помощью отношений «is-a» и «part-of». Модули являются основным элементов конструкции объектно-ориентированных систем. Они играют роль контейнеров для логически связанных классов и объектов, связанных отношением наследования и отделяющих внешний интерфейс от внутренней реализации. Структура программы представлена в виде графа, а не дерева, характерного для структурного подхода, область глобальных данных отсутствует или значительно уменьшена.
Для ООП характерно описание поведения системы в терминах состояний, переход между которыми осуществляется в процессе обработки отправленных сообщений [149]. Это создаёт хорошие предпосылки для формализации программных систем в терминах конечных автоматов.
Основным средством описания программных систем в терминах ООП стал язык UML, обеспечивающий создание диаграмм двух основных типов: диаграмм, описывающих структуру системы (диаграммы классов, объектов, компонентов и т.п.) и диаграмм, описывающих поведение системы (диаграммы состояния, взаимодействия и т.п.). Отношения между классами также могут быть представлены с помощью моделей «сущность-связь» на основе методологий IDEF1 и IDEF1X, что позволяет перейти к реляционному представлению объектной модели. Параллельно с разработкой UML разрабатывалась методология построения объектно-ориентированных систем IDEF4, которая получила значительно меньшее распространение.
Существенное влияние на первые объектно-ориентированные языки программирования оказал язык Simula-67. К первым языкам программирования, полностью реализующим принципы ООП, относятся Smalltalk, Oberon, Eiffel, C++, Object Pascal, далее поддержка ООП входила практически в каждый современный язык программирования.
Модель объектно-ориентированных систем представима в виде кортежа: = G, M, I, O1, O2 , (3) где G – управляющая программа; М – множество модулей; I – информационная модель системы; O1 – множество моделей поведения объектов; O2 – модель взаимодействия объектов [65].
Способность объектного подхода справляться со сложностью систем различной природы привела к его широкому распространению за пределы задач традиционного программирования, от проектирования пользовательского интерфейса до построения баз данных и компьютерных архитектур [38; 59].
Объектный подход легко допускает масштабирование, и может быть применён на все более высоких уровнях, формируя многослойную структуру, на каждом уровне которой можно выделить группы взаимодействующих объектов.
Аспектно-ориентированный подход
При построении сложных автоматизированных систем управления крупномасштабными объектами неизбежно возникают задачи, реализацию которых невозможно локализовать в отдельных программных элементах, полученных на основе структурной, модульной и объектной декомпозиции [54]. В целях эффективного управления подобной функциональностью, которая получила название сквозной или рассеянной (scatter), группой специалистов Xerox PARC под руководством Г. Кичалеса была предложена аспектно-ориентированная методология [167]. Наиболее популярной реализацией этого подхода является ActiveJ — аспектно-ориентированное расширение Java.
В основе аспектно-ориентированного подхода лежит выделение сквозной функциональности в отдельную сущность, называемую аспектом (aspect). Аспект подключается в различные фрагменты кода приложения с помощью точек соединения (join point). Правила подключения аспекта задаются с помощью срезов (pointcut). Применение аспекта в точке соединения задаётся с помощью совета (advice) и может быть осуществлено до или после среза, после успешного возврата либо в случае возникновения ошибки. Также можно задать вариант с самостоятельной обработкой среза, от вызова и передачи параметров, до обработки ошибок.
Разработка высокопроизводительных систем
Применение параллельных вычислительных систем стало ключевым направлением развития вычислительной техники, призванным преодолеть технологические ограничения на производительность устройств, обеспечивающих последовательные вычисления. Переход на параллельные вычисления требует рассмотрения вопросов, связанных с использованием различных аппаратных архитектур и подходов к организации программного кода, принципиально отличающихся от используемых в традиционных последовательных вычислениях.
Для аппаратных архитектур параллельных вычислительных систем существует несколько классификаций, в основном восходящих к уже ставшей канонической классификации Майкла Флинна [162; 163].
Согласно этой базовой классификации, выделяются четыре класса систем, отличающихся по отношению к потокам команд и потокам данных. В зависимости от подхода к реализации в некоторых из этих классов можно выделить отдельные подклассы.
1. SISD — ОКОД (Single Instruction Single Data, Одиночный поток Команд и Одиночный поток Данных). Этому классу соответствуют все традиционные вычислительные однопроцессорные машины.
2. SIMD — ОКМД (Single Instruction Multiple Data, Одиночный поток Команд и Множественный поток Данных). Этому классу соответствуют векторные системы (такие как Сгау-1), сопроцессорные расширения, такие как MMX/SSE в процессорах Intel, процессоры для обработки графики (GPU). Они используются для единообразной обработки больших наборов данных, представленных в виде векторов и матриц. Для описания модели вычислений в современных GPU выделятся следующий подкласс
3. MISD — МКОД (Multiple Instruction Single Data, Множественный поток Команд и Одиночный поток Данных). Системы этого класса отсутствуют, хотя некоторые исследователи относят к ним конвейерные системы.
4. MIMD — МКМД (Multiple Instruction Multiple Data, Множественный поток Команд и Множественный поток Данных). Наиболее обширный класс параллельных систем, которому в общем случае соответствуют системы, состоящие из распределённых по различным узлам вычислительным устройствам (процессорам), обрабатывающим различные наборы данных с возможностью взаимной синхронизации и обмена данных. Для систем класса MIMD можно выделить несколько подклассов. С точки зрения отношения к единообразности потока команд:
- SPMD — ОПМД (Single Program Multiple Data, Одна Программа и Множественный поток Данных): вариант MIMD, при котором на различных узлах выполняется один и тот же поток команд (программа); архитектура характерна для вычислительных кластеров;
- MPMD — МПМД (Multiple Programs Multiple Data, Множество Программ и Множественный поток Данных): развитие SPMD до ситуации, при которой на множестве узлов выполняется не менее двух независимых потоков команд (программ); типичная реализация подразумевает наличие одной управляющей программы, распределяющей данные для обработки по рабочим узлам; архитектура применялась в Sony PlayStation 3 и проектах распределённых вычислений distributed.net.
С точки зрения доступа к потоку данных:
- SM-MIMD — МКМД-ОП (Shared Memory, Общая или разделяемая Память), также известен как архитектура SMP (Symmetric Multiprocessing, архитектура с симметричной мультипроцессорностью); к этому классу относятся многопроцессорные и многоядерные системы с общей памятью.
- DM-MIMD — МКМД-РП (Distributed Memory, Распределённая Память), архитектура МРР (Massive Parallel Processing, массово-параллельная архитектура): память физически разделена, система строится из множества узлов, взаимодействующих между собой по коммуникационным каналам; возможна гибридная реализация, при которой один узел содержит несколько процессоров, имеющих доступ к общей памяти.
Модели программирования, ориентированные на параллельные вычисления, могут быть рассмотрены как с точки зрения организация взаимодействия между компонентами, так и с точки зрения декомпозиции вычислительной задачи [19].
Выделяется два основных подхода к организации взаимодействия между компонентами параллельной системы: через разделяемую память (типично для SMP) и с помощью механизма сообщений, которыми обмениваются узлы, входящие в систему (типично для MPP). В случае MPP-систем, каждый узел которых представляет собой SMP-систему, возможен гибридный подход, при котором узлы взаимодействуют с помощью сообщений, а потоки на отдельном узле обмениваются данными через общую память.
Использование разделяемой памяти ограничено рамками одной вычислительной многопроцессорной системы, единицей исполнения в данном случае является поток исполнения. Данный подход требует синхронизации доступа к общим данным для устранения возможных конфликтов с помощью объектов синхронизации, как правило, предоставляемых операционной системой. В случае превышения числом потоков исполнения числа доступных процессоров возрастают накладные расходы на переключение между потоками [131].
С точки зрения декомпозиции вычислительной задачи выделяются параллелизм задач, параллелизм данных и неявная декомпозиция. При параллелизме задач первичными являются потоки исполнения и способы организации их совместной работы. Параллелизм данных, характерный для SIMD и SIMT, подразумевает подготовку больших массивов данных в виде векторов и матриц, однотипно обрабатываемых множеством потоков. В случае неявной декомпозиции ответственность за распараллеливание берёт на себя среда исполнения (характерно для функциональных языков) либо компилятор, выявляющий поддающиеся распараллеливанию фрагменты кода.
Базовые средства распараллеливания
К базовым средствам распараллеливания относится использование низкоуровневых API операционных систем, позволяющих создавать потоки управления (таких как Win32/64 API и POSIX Threads) и синхронизировать их работу. Сюда же можно отнести библиотеки языков программирования, по-прежнему управляющие потоками в явном виде, но позволяющие абстрагироваться от API конкретной платформы [135] (например, класс thread стандартной библиотеки C++). Их использование обеспечивает максимальную гибкость, но требует существенного перестроения логики вычислений, ориентированных на последовательное исполнение, а также интенсивного использования механизмов синхронизации для устранения конфликтов при доступе к общим данным.
Организация параллелизма на уровне задач
Переход от программирования на уровне потоков к программированию на уровне задач позволяет переложить рутинную работу по синхронизации и планированию потоков с программиста на компилятор и среду исполнения.
Эти возможности постепенно проникают в языки программирования с помощью дополнительных библиотек более высокого уровня. Так, характерная для функциональных языков программирования концепция отложенных вычислений, обеспечивающая неявное распараллеливание, была добавлена в стандарт C++ с помощью классов async, future и promise.
Значительным шагом в популяризации параллелизм на уровне задач стал открытый интерфейс OpenMP (Open Multi-Processing), который можно рассматривать как высокоуровневую кроссплатформенную надстройку над стандартным механизмом создания потоков [83]. OpenMP допускает использование как директив компилятора, так и библиотечных функций. Использование библиотечных функций требует явного подключения заголовочных файлов OpenMP, директивы используются для разметки участков кода, которые необходимо распараллелить, и переменных, которые будут совместно использоваться. При вхождении в размеченные области приложения главный поток по необходимости порождает вспомогательные группы потоков. Их применение возможно и при отсутствии поддержки OpenMP, без указания специального флага компилятора они будут проигнорированы, что устраняет неоходимость создавать и поддерживать параллельную и последовательную версию программы.
Приложения, реализованные на основе ОИП
Рассмотрим основные программные продукты, разработка и развитие которых стали возможными благодаря применению принципов и программных решений, реализуемых в ОИП.
Первым применением предложенных решений стала реализация сетевого режима тренажёрного комплекса ПВК «Веста-Тренажёр», который обеспечивает обучение диспетчерского персонала по управлению газотранспортной и газораспределительной системой, включая совместное коллективное обучение диспетчерских кадров в целях отработки взаимодействия, отражая тем самым естественный распределённый характер взаимодействия диспетчеров ГТС разных уровней [79; 102]. Архитектура комплекса была рассмотрена в разделе 2.2.
Основным назначением тренажёрного комплекса является формирование у диспетчерского персонала навыков принятия правильных решений в условиях дефицита времени и технологических ресурсов на основе отработки различных сценариев управления, включающих имитацию реальных нестационарных режимов, различных аварийных ситуаций, а также взаимодействия диспетчерских служб ПДС ГДО, ГТО, ГРО и их филиалов. Применение тренажёрного комплекса позволяет сформировать виртуальную среду технологического процесса систем газоснабжения, обеспечивающую:
моделирование, ситуационный анализ и многовариантное планирование стационарных режимов систем газоснабжения;
решение задач управления системами газоснабжения в штатных ситуациях, включающих переход с одного плана поставок на другой, вывод оборудования в ремонт, а также при резком изменении параметров потребления/поставок газа в ГТС;
решение задач управления системами газоснабжения в нештатных ситуациях, включающих аварийные ситуации на линейных участках при полном разрыве трубопровода, при образовании местных засорений, а также аварийные ситуации на КС, при аварийном отключении ГПА КЦ. Тренажёрный комплекс предусматривает как режим индивидуального тренинга, в котором работа каждого обучаемого автономна и не предусматривает взаимодействие с другими обучаемыми при выполнении учебно-тренировочных задач, так и режим коллективного сетевого тренинга, в котором задача моделирования режимов работы ГТС выполняется на вычислительном сервере, а клиентские модули обучаемых работают с фрагментами технологических схем, объединённых общей вычислительной средой нестационарного моделирования. Как правило, для совместных тренировок выбираются смежные участки ГТС.
Типовые сценарии обучения в режиме коллективного тренинга предусматривают совместное выполнение диспетчерских заданий, связанных с переходами на новый режим или план поставок газа, а также совместную отработку нештатных и аварийных ситуаций, требующих активного скоординированного взаимодействия. Процесс обучения координируется с рабочего места преподавателя.
Компоненты, обеспечивающие сетевой режим работы тренажёра, включают: сетевой агент, обеспечивающий задание основных сетевых настроек и мониторинг действий обучаемых (Рисунок 61); рабочее место преподавателя, позволяющее контролировать действия обучаемых и включающее модуль сетевого брокера (Рисунок 62); основной тренажёрный модуль, обеспечивающий моделирование и выступающий в роли «толстого» клиента, обеспечивающего доступ обучаемых к управлению (Рисунок 63).
Интерфейс модулей обучаемых обеспечивает передачу управляющих воздействий (закрытие/открытие кранов, изменение оборотов ГПА и т.п.) основному расчётному модулю и отображение полученных от него результатов расчётов в разрезе заданных подсистем. При необходимости преподаватель может вмешаться в процесс моделирования, внося управляющие воздействия в полную схему.
Дальнейшим развитием сетевого режима тренажёрного комплекса является переход к полностью распределённой модели взаимодействия (Рисунок 65). Она предполагает, что компьютеры обучаемых территориально распределены или находятся в различных сегментах сети Интернет, а также учитывает возможность использования вычислительных ресурсов корпоративного центра обработки данных (ЦОД).
Репозитарий доступных расчётных схем, УТЗ, отчёты о выполнении УТЗ и прочие данные находятся в централизованном хранилище на сервере БД ГТО. Вычислительная подсистема отделяется от АРМ преподавателя и даёт возможность задействовать ресурсы отдельного вычислительного кластера.
Помимо традиционных АРМ, предполагается использование тонких клиентов, обеспечивающих авторизованный доступ через web-интерфейс к статистическим данным выполнения обучаемыми УТЗ и прочим данным.
Перспективным направлением развития является разработка многоуровневого тренажёра, обеспечивающего взаимодействие диспетчеров как смежных участков, так и межуровневое взаимодействие, при котором обучаемым требуется согласовывать свои действия с диспетчерской службой верхнего уровня.
Применение ОИП к разработке тонких клиентов было осуществлено при разработке профессионального калькулятора диспетчера газотранспортной организации «Веста-Web» [88; 92; 93].
В его задачи входят:
импорт текущего среза оперативных данных;
загрузка данных из диспетчерского журнала;
анализ данных и при необходимости ручная корректировка;
проведение расчётов текущего или планируемого режимов участка ГТС в зоне ответственности филиала ЭО;
определение расчётным путём требуемых параметров и режимов работы оборудования компрессорных цехов. Тонкий клиент использует три основных режима отображения информации:
вывод полной расчётной схемы рассматриваемой ГТС (Рисунок 66);
отображение сводной информации по ГТС и отдельным цехам (Рисунок 67);
вывод отчётов по результатам расчётов (Рисунок 68). Подключение «Веста-Web» к основному расчётному комплексу осуществляется с помощью подсистемы взаимодействия с web-клиентами ОИП, описанной в разделе 5.2.2.