Особенности организации программной архитектуры адаптивных систем обработки информации, моделирования и управления

Введение. На сегодняшний день для решения комплекса задач, связанных с управлением и моделированием сложных технологических процессов в различных отраслях промышленности, в частности аэрокосмической отрасли, используются программные и алгоритмические средства, позволяющие обеспечить функции идентификации и управления процессом. Одним из примеров подобного рода средств является адаптивные системы управления технологическим процессами, функционирование которых осуществляется с использованием непараметрической теории [1–5]. Использование непараметрических алгоритмов идентификации и управления позволяет осуществлять моделирование, прогноз и ведение процесса в рамках технологического регламента в условиях недостатка априорной информации, когда параметрическая структура модели исследуемого процесса остается неизвестной из априорной информации [6–9]. Эта ситуация довольно часто встречается при разработке компьютерных систем управления, так как в большинстве случаев исследователю приходится работать с малоизученными процессами, для которых не представляется возможным обоснованно подобрать параметрическую структуру модели. При этом к разрабатываемой системе управления предъявляется ряд требований, к которым относятся: синхронизации данных с различных точек ведения контроля; возможность работы с разнотипными данными (система самостоятельно производит преобразование данных в единый формат); возможность как автономной работы системы управления, так и коррекции управляющих действий системы экспертом-технологом; обеспечение безопасности путем осуществления шифрования и резервного копирования данных. Таким образом, основной задачей данного исследования является разработка и проектирование архитектуры программно-алгоритмического обеспечения, позволяющей оптимальным образом обеспечить функционирование системы.

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

Expert

Рис. 1. Функциональная схема работы разрабатываемой адаптивной системы обработки информации, моделирования и управления

Fig. 1. Functional scheme of the developed adaptive information system for data processing, modeling and control

Контроль переменных технологического процесса осуществляется через интервал времени At. Вход и выход процесса представлен измерениями, формирующими выборку вида {u, xt}, i = 1, s, где s - объем выборки; ui, xi - измерения входа и выхода объекта в момент времени t . Эта выборка содержится в блоке «База данных предприятия». Модуль обработки данных осуществляет импорт данных различного формата, производит преобразование данных в единый формат, с которым работает система. Также в этом модуле реализованы алгоритмы предобработки данных: нормализация, центрирование, анализ выбросов и пропусков в выборке наблюдений. Результатом работы модуля является внутренняя база данных системы, которая содержит конвертированные данные в едином формате.

Модуль идентификации технологического процесса реализует непараметрические алгоритмы идентификации [10].

В работе рассматриваются классы технологических процессов управления, допускающие описание уравнениями вида:

xt = F ⁽ xt - 1 , • • •, x t - k , ut ’ ^ t ) .                                        ⁽¹⁾

Здесь F - неизвестный функционал; k - порядок разностного уравнения, который ограничен k <  k _max; u_t - входная переменная объекта; x_t - выходная переменная объекта; индекс t - дискретное время; £ ( t ) - векторная случайная помеха.

Введем следующие обозначения:

z t = ( z 1 ’ • • • ’ z k + 1 ) = ⁽ xt - 1 , • • •, xt - k , ut ) ’                             ⁽²⁾

тогда xt = F ( zt ) .

C учетом переобозначений (2) модель рассматриваемого технологического процесса может быть сведена к модели динамической системы в дискретном времени, когда на вход последней поступают не только переменные u_t , но и x_t__x,__t__T,...,x_t__k и т. д.

В рассматриваемых условиях в качестве непараметрической модели объекта может быть принята следующая непараметрическая оценка функции регрессии по данным наблюдений {x;, ut, i = 1,5} [11]:

x_s ^t

s

Z Х.-Ф i=1

u_s - u i

u

V ^C5

k

П ф

⁷ j = 1

(x — x

'-ji-j r _ [ j ]

V ^cs      7

s

Еф i =1

^us u i

u

V ^C5

k

П ф

7 j = 1

V

' 5 - j  ^_ - j

P ^{_ [} j ]

сs

где Ф ( • ) - колоколообразная функция; c ^ , с _ ^[ j ^] - коэффициенты размытости ядра, которые при наличии обучающей выборки находятся из задачи минимизации показателя соответствия выхода объекта и выхода модели, основанного на методе скользящего экзамена, когда в непараметрической модели (4) по индексу i исключается q -е наблюдение переменной, предъявляемой для экзамена: 5                                        ²

R ^{( С} " , ^{С _ [1] ,}-> ^{С _ [} k ^{] )} = Х( X ^{( u} q ^, x q -1”-” x q - k ) - x q ) =„ xmin ^^{, 9} * i ^{,         (5)}

u ^{_[ [}!^{]       _ [} k ^]

q = 1                                                            ^c 5 , ^c 5 ’■•.’ ^c 5

где индекс i фигурирует в непараметрической модели (4). В качестве алгоритма оптимизации реализован неградиентный метод многомерной оптимизации - метод Нелдера - Мида, так как данный метод является эффективным при низкой скорости вычисления минимизируемой функции. Для выбора начальных вершин деформируемого многогранника была задана область возможных значений коэффициентов размытости ядерной функции cs е [0.01,4], из которой произвольным образом выбрана n+k+1 точка, где n - количество входных переменных; k - порядок разностного уравнения, которые образуют симплекс n+k-мерного пространства.

Модуль управления технологическим процессом реализует схему управления, представленную на рис. 2.

CU

Рис. 2. Схема дуального управления динамическим объектом

• Fig. 2.    Scheme of dual control of a dynamic object

Непараметрический алгоритм дуального управления имеет вид [12]: u s + 1 = u * ^{+ A} u s + 1 ,

где u ^* – составляющая, накапливающая информацию об объекте исследования, а

A u_{s+ 1} = e ( x_{s+ 1} — x ) - «изучающие» поисковые шаги. Дуализм алгоритма (6) заключается в следующем. На первых тактах управления основную роль при формировании управляющих воздействий играет слагаемое A u_s+1 из формулы (6). Но уже по мере накопления информации об объекте возрастает роль слагаемого u_s ^* .

В данном случае в качестве слагаемого u_s ^* из уравнения (6) можно принять выражение:

* u _s

s

£ и,-Ф i=1

s

Хф i=1    V

*

x s + 1

V     ^Cs

' s + 1

с _s

k

П ^ф

7 j = 1

xs—j — xi—j сs

k

П ^ф

7 j = 1

.

x s — j    xi — j

V      ^Cs     7

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

• 1.    Время регулирования t р – время с начала управления до момента, когда выходная величина отличается от задания не более некоторой заданной величины α. Обычно принимают: α= 0,05y уст .

• 2.    Относительная ошибка управления Wp , равная суммарному отклонению фактического выхода процесса от задающего воздействия в течение всего времени регулирования по отношению к задающему воздействию, выраженная в относительных величинах, в %.

  W p =

  
  

¹ il ¹ ' ^{- T} 'l ^A i =1 ______________

* x

Вычисленные значения управляющих воздействий u доступны к корректировки экспертом-технологом. Таким образом, разрабатываемая система представляет собой инструментарий, включающий в себя следующие основные модули: модуль обработки данных, моделирования и прогноза выходных переменных процесса, модуль управления технологическим процессом.

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

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

Г Monolith

Monolithic

Service - Oriented

большая часть исходного кода дублирует код уже имеющихся подсистем.

Рис. 3. Сравнение архитектур

• Fig. 3.    Architecture Comparison

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

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

Главное отличие и преимущество композитной архитектуры перед SOA в том, что композитная архитектура обеспечивает гибкость на всех слоях (уровнях) приложения в то время, как SOA предоставляет гибкость только на одном слое – слое приложения (бизнес-логики) [13], так как композитная архитектура по своей сути является дальнейшим развитием сервис-ориентированной архитектуры и, соответственно, обладает всеми преимуществами сервис-ориентированного подхода в разработке программного обеспечения. Композитные приложения, как правило, являются дальнейшим развитием уже разработанной группы отдельных приложений, из которых выделяются базовые наборы компонентов и контейнеров для их дальнейшей интеграции друг с другом. В настоящее время идея построения сервис-ориентированных приложений на основе композитной архитектуры находит широкое распространение в различных областях разработки программного обеспечения и является предметом изучения во многих научноисследовательских центрах. Одной из самых крупных подобных организаций является Институт инженерии программного обеспечения (англ., Software Engineering Institute, SEI) [14]. На данный момент институт является признанным международным лидером в изучении вопроса построения композитных сервис-ориентированных приложений. Композитная сервис-ориентированная архитектура – это подход к проектированию программных систем для организации уже существующих программных продуктов таким образом, чтобы разрозненные наборы сложных распределенных систем и приложений можно было превратить в сеть интегрированных простых и гибких ресурсов.

Основываясь на методологических рекомендациях SEI, мы спроектировали и применили гибридный архитектурный подход и таким образом получили композитную сервис-ориентированную программную систему, которая представляет собой совокупность сервисов, сервисных компонентов и компонентов доступа к данным, способных проектироваться и разворачиваться в одном приложении [15]. Взаимодействие между сервисами и различными компонентами осуществляется путем обмена сообщениями.

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

• –    описывают и реализуют операции предметной области;

• –    задают правила операций;

• –    передают сообщения между компонентами системы.

Сами сервисы обеспечивают взаимодействие между композитным приложением и его потребителями. Связь с сервисом осуществляется по заданным протоколам (например, SOAP/HTTP). Компоненты доступа к данным служат для извлечения и модификации данных на основе сообщений, переданных от сервисных компонентов. Связи описывают способы обмена информацией между сервисами и сервисными компонентами, между различными сервисными компонентами или сервисными компонентами и компонентами доступа к данным.

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

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