книги / Теоретические основы автоматизированного управления

• согласованность критериев различных ЛПР.

Из сравнения концепций нетрудно заметить, что из всех концеп­ ций концепция ГАЗ проработана в наименьшей степени.

Перечисленные концепции дают общее направление работ и тре­ буют более детальной проработки.

3.4. МОДЕЛИ АДАПТИВНОГО АВТОМАТИЗИРОВАННОГО УПРАВЛЕНИЯ

Для адаптивных АСУ с оперативным переходом на выпуск новой продукции характерны следующие особенности.

1.Целенаправленность систем и ее элементов, проявляющаяся в процессе эксплуатации.

2.Качественное изменение цели, которое компенсируется изме-' нением структурных связей.

3.Выделение процесса планирования (формирование задающего воздействия) в относительно самостоятельную процедуру.

4.Интенсификация управленческих процессов в системе по срав­ нению с традиционными АСУ.

5.Многоуровневая структура системы с изменением масштабов по времени и координатам на границах уровней.

6.Высокая размерность системы.

7.Значительная доля неформальных процедур в процессе экс­ плуатации системы.

Фактически сформировался новый класс систем управления. Рассматриваемый класс систем, как показано в [4], не представляется возможным исследовать методами теории как традиционных АСУ, так и современной теории автоматического управления. Для форми­ рования нового метода исследования Целесообразно первоначально рассмотреть концепцию исследования подобного класса систем. Она определяется методологией структурно-алгоритмического модели­ рования (САМ), включающей следующую систему принципов.

СОЗДАНИЕ СИСТЕМЫ

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

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

II. Комплексное проектирование моделей функционирования и раз­ вития. С позиций «жизненного цикла» системы управления выделяют ее проектирование и эксплуатацию; с позиций работы системы — функционирование и развитие системы. Под функционированием понимается работа системы в рамках заданной (фиксированной) структуры. Развитие — работа системы в рамках острых противоре­ чий, которые могут вызвать и вызывают изменение структуры систе­ мы. При эксплуатации целенаправленных многоуровневых систем имеет место интеграция процедур функционирования и развития. Следовательно, необходима интеграция и моделей этих процедур. Такая интеграция может быть обеспечена лишь комплексным проекти­ рованием специфической модели функционирования и модели раз­ вития. Отметим, что при использовании подобных систем возможно совмещение эксплуатации модели функционирования с проектиро­ ванием (и последующей эксплуатацией) модели развития.

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

Следует четко различать цель проектирования и цель работы сис­ темы. Последняя может меняться в процессе работы системы.

ЭКСПЛУАТАЦИЯ СИСТЕМЫ

IV. Построение единого метода математического описания с исполь­ зованием составного критерия, учитывающего экономические и управ­ ленческие свойства системы.

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

ную модель, убедившись в ее адекватности системе, а затем улучшить характеристики системы.

VI. Оптимизация (с помощью модели) структурных и динамических характеристик системы. Использование оптимизации предопределя­ ется потребностью работы многоуровневой целенаправленной систе­ мы, оперирующей понятием «интерес». Оптимизационный инстру­ мент предоставляется вычислительной техникой: оптимум может быть удержан при изменяющихся условиях работы системы, что осо­ бенно необходимо и эффективно при оперативном переходе на вы­ пуск новой продукции, позволяя выбрать наиболее целесообразный способ такого перехода.

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

РЕАЛИЗАЦИЯ СИСТЕМЫ

VIII. Современный подход к построению системы управления. Речь идет о построении системы, базируясь на алгоритме управляемого процесса (бизнес-процесса), а не на некоторой системе документов. Иначе говоря, рассматривается автоматизация управления, а не авто­ матизация документооборота.

IX. Ориентация на использование динамических распределенных баз данных. По своей сути многоуровневые системы являются развиваю­ щимися. Это означает возможность оперативного и многократного дополнения и изменения данных: частота запросов становится соиз­ меримой с частотой обновления данных. К такой базе данных предъ­ являются дополнительные требования по быстродействию, объему памяти, адаптации к изменению алгоритмов обработки информации.

Структурно-алгоритмическое моделирование предполагает та­ кую последовательность решения проблемы: «обобщенная модель — обобщенная технология — система моделей и методов, составляю­ щих технологию».

На основе анализа процесса проектирования подобных систем [7, 43] сформирована обобщенная модель адаптивного управления, по­ казанная на рис. 3.13.

Модель позволяет описывать следующие процессы.

Руководитель

А. ФУНКЦИОНИРОВАНИЕ СИСТЕМЫ (структурные связи фиксированы).

Ф1.1. Синтез (построение) структуры системы нового предпри­ ятия или изменение структурных элементов (реконструкция) старой структуры. В последнем случае имеют место значительные затраты, в силу чего чаще приходится рассматривать другую разновидность про­ цесса Ф1 (Ф1.2).

Ф1.2. Идентификация структуры действующего предприятия. Ф.2. Интегрированное планирование.

ФЗ. Интегрированное управление Б. РАЗВИТИЕ СИСТЕМЫ (изменение структурных связей при

оперативном переходе на выпуск новой продукции).

Р1. Модернизация структуры. Здесь выделяют два случая:

1)изменение только структурных связей;

2)изменение элементов и структурных связей.

Второй случай (реконструкция) связан с серьезными затратами и рассматривается гораздо реже, чем первый, который далее и будет об­ суждаться.

Первый случай характеризуется понятием «гибкость» — способ­ ность системы изменять цели функционирования без существенных затрат (реконструкции).

Р2. Интегрированное планирование с учетом «структурной со­ ставляющей».

РЗ. Интегрированное управление с учетом оперативного перехода на выпуск новой продукции.

Полное, достаточно объемное описание обобщенной модели при­ ведено в работах [13, 14]. Здесь приведем описание лишь процесса управления ФЗ:

Рис. 3.13. Обобщенная модель:

ЭП — элемент планирования: УЧ, ОУ — элементы управляющей части и объекта управления; Э, {р, г ) —Л-й элемент процесса планирования на уровне Л в масштабе времени th\p —признак планирования; Э * (и,/Л) — элемент процесса управления; и — признак управления; Э* (d, fi)— эле­ мент объекта управления (Л- Q ) ‘ d —признак объекта управления; у® — выход объекта управления; р \ — план элемента к на уровне А

где Э/’+ '(и, / А+ '), ЭА(и, t h), Э/А(у, t h) — k -t и /-е элементы соответст­ вующих уровней управляющей части и объекта управления; и, у — векторы управления и выхода; t h — отсчет времени на уровне А; * — оператор замыкания, учитывающий обратные связи; Kh — число эле­ ментов на уровне А; А=170; 0 — число уровней системы; S — связи ме­ жду элементами Э; / еС(к), С(к) = {/: ГЭ А + 1 = ЭА}, |С(£)| = Nt, к — 1,

Kh+ ,, / = 1, Kh;j еС([), С{1) = {/: ГЭ/ = Э ?}, |С(/)| = N jJ= 1 , Nf, C(r) =* {г:

Эг —Г~'ЭА+ 1 }, |С(г)| = Nr ; Г — прямая связь двух смежных элемен­ тов.

На основе обобщенной модели составим обобщенную технологию моделирования системы.

Выделяют процессы идентификации, планирования и управле­ ния.

В идентификации, в свою очередь, можно выделить такие этапы. И1. Формирование цели Ц исследования.

И2. Определение по выбранной цели моделирования модели М(0): перечня элементов, числа уровней 0, количества Кн элементов на каждом уровне.

ИЗ. Построение структуры. Если число уровней более трех — вы­ деление базовой трехуровневой «скользящей» топологии и переход к ее изучению. При формировании топологии полезно использовать такой порядок: определение топологии объекта управления; после­ довательное выявление топологии управляющей части.

И4. Определение на документальной основе алгоритмов плани­ рования, описание алгоритмов объекта управления; формирование алгоритмов управляющей части.

И5. Выявление числовых значений параметров полученного опи­ сания.

И6 . Определение адекватности модели исходной системе.

Впроцессе планирования возможно выделить следующие этапы. П1. Проверка ресурсного обеспечения для выпуска продукции. ГО. Учет векторного критерия с определением чувствительности

решения.

ПЛ1. Планирование при оперативно изменяющихся структурных связях.

ПЗ. Согласование работы элементов и уровней.

П4. Выделение (классификация) сильно связных множеств, опре­ деляющих соответствующие компоненты.

П5. Декомпозиционное определение оптимальных планов. В процессе управления выделяют такие этапы.

ГЛАВА 4

Функциональный и структурный анализ автоматизированных систем

В настоящее время вцелом сформировались идеология и практика примене­ ния автоматизированного управления. Однако необходимы средства анализа ин­ формационных процессов и технологий как целостной системы. Ниже приведе­ ны подходы системной инженерии, позволяющие совместно рассматривать все компоненты АСУ. С помощью методов системной инженерии можно оценить варианты архитектуры и выбрать из них наилучшие. Далее представлены следую­ щие виды моделей, используемых для анализа структуры АСУ: информацион­ но-логическая, функциональная и модель на основе бизнес-процессов. Инфор­ мационно-логическая модель АСУ базируется на анализе предметной области и использует два подхода: функционально-модульный (структурный) и объект­ но-ориентированный. Функциональная модель исходит из анализа функцио­ нальных возможностей и использует три аспекта рассмотрения: функциональ­ ный, информационный, организационный. Модель на основе бизнес-процессов направлена на комплексный анализ деятельности объекта автоматизированного управления.

4.1. СИСТЕМНАЯ ИНЖЕНЕРИЯ КАК СРЕДСТВО АНАЛИЗА АСУ

Системная инженерия определяет систему как совокупность ком­ понентов (физические системы, аппаратное обеспечение, программ­ ное обеспечение и персонал), которые совместно реализуют предпо­ лагаемые функции конечного продукта [55]. Разработка продуктов — это логическая последовательность оценок затрат на циклы жизни продукта, управление исследованием технических компромиссных решений, анализ эффективности затрат, моделирование эффектив­ ности, проектирование архитектуры и процесса изготовления. Все вместе эти шаги преобразуют цели в параметры эффективности и предпочтительную конфигурацию системы.

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

Разработанные АСУ часто не оправдывают ожиданий пользовате­ лей. Это возникает из-за применения множества разрозненных инст­ рументов, несогласованных попыток анализа требований и неадекват­ ных критериев выбора функций и разделения архитектуры. В итоге формируется противоречивый набор требований к системе, создаются неполные определения архитектур, оказываются пропущенными не­ которые необходимые компоненты.

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

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

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

Существующие бизнес-соглашения. Иногда проекты АСУ прихо­ дится реализовывать в рамках существующих соглашений с изготови­ телями или разработчиками компонентов.

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

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

Чтобы разрешить эти проблемы, специалисты по системной ин­ женерии применяют различные стратегии, специальным образом предназначенные разрешить проблемы междисциплинарного взаи­ модействия. Они используют ряд представлений архитектуры, на­ пример, логическое, физическое, представление данных, представле­ ние процессов. Чтобы определить и выразить различные аспекты процесса разработки, применяются такие методики, как «сети Пет­ ри» (помогают определить параллельность и синхронизацию), маши­ ны с конечным числом состояний (состояния и режимы), структур­ ный анализ (потоки данных) и PSL/PSA (Problem Statement Language/Problem Statement Analysis).

К сожалению, для этих методик не существует единого представ­ ления; они в разной степени применимы для таких этапов цикла жиз­ ни продукта, как формулировка требований, проектирование, реали­ зация и тестирование.

В рамках разработки АСУ объектно-ориентированный подход обеспечивает инкрементальный подход к определению требований, проектированию и разработке систем, интенсивно использующих программное обеспечение.

Инкрементальный подход — подход к проектированию по нарас­ тающей, снизу — вверх (проектирование блоков, объединение бло­ ков в модули и т. д.). Существуют три подхода к проектированию — итеративный, эволюционный и инкрементальный.

Для определения и представления этих требований служит язык UML — Unified Modeling Language (разработка групп OMG Unified Modeling Language Specification, Object Management Group). UM L до­ пускает создание спецификации продукта, не зависящей от языка программирования или конкретного процесса разработки.

Объектно-ориентированный подход должен стать механизмом для объединения технологий разработки АСУ и уменьшить диссо­ нанс между спецификацией и реальными параметрами готовой сис­ темы.