06-41

для высших
118 УЧЕБНЫХ ЗАВЕДЕНИЙ

Б.Я. Советов, В.В.Цехановский, В.Д. Чертовской

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

о
 06-41
1 “ П Г ~ _____

Б.Я. Советов, В.В.Цехановский, В.Д. Чертовской

Теоретические
основы
автоматизированного
управления
Допущено
Министерством образования и науки
Российской Федерации
в качестве учебника для студентов
высших учебных заведений,
обучающихся по специальности
«Автоматизированные системы обработки
информации и управления» направления подготовки
«Информатика и вычислительная техника»

Москва «Высшая школа» 2006

УДК 681.5
ББК 32.965
С 56

2006029003

Рецензенты:

засл. деятель науки и техники РФ, д-р техн. наук, проф. 1Д. В. Гаскаров\
(Санкт-Петербургский государственный университет водных коммуникаций);
кафедра интеллектуальных технологий и систем Московского государственного
института радиотехники, электроники и автоматики (технического университе­
та) (зав. кафедрой д-р физ.-мат. наук, проф. В.В. Нечаев)

Советов, Б.Я.
С 56 Теоретические основы автоматизированного управления:
Учебник для вузов/Б.Я. Советов, В.В. Цехановский, В.Д. Чер­
товской,— М.: Высш. шк., 2006. — 463 с.: ил.

ISBN 5-06-005496-9

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

на основе моделей М RP/ERP, PLM, гибкого автоматизированного завода, адап­
тивного автоматизированного управления с использованием функционального
анализа на основе бизнес-процессов. Изложено современное состояние при­
кладных вопросов автоматизированного управления: математического, алго­
ритмического, программного, технического, эргономического, организацион­
ного и правового обеспечения, значительное место занимают проблемы проек­
тирования автоматизированных систем управления.
Для студентов вузов, обучающихся по специальности «Автоматизированные
системы обработки информации и управления» направления подготовки «Инфор-
цтельная техника», а также «Информационные системы».
г о с у д а р с т в е н н а я
БИБЛИОТЕКА
2006
УДК 681.5
ББК 32.965

ISBN 5-06-005496-9 © ФГУП «Издательство «Высшая школа», 2006

Оригинал-макет данного издания является собственностью издательства «Выс­

шая школа», и его репродуцирование (воспроизведение) любым способом без согласия
издательства запрещается.
 ПРЕДИСЛОВИЕ

Предлагаемый учебник раскрывает содержание дисциплины

«Теоретические основы автоматизированного управления», являю­
щейся основополагающей в направлении подготовки кадров 230100
(654600) Информатика и вычислительная техника по специальности
230102 (220200) — Автоматизированные системы обработки инфор­
мации управления (АСОИУ). Цель преподавания данной дисципли­
ны — ознакомление с современным состоянием теории автоматизи­
рованного управления, идеологией построения АСОИУ, изучение
различных аспектов структуры АСОИУ и математического аппарата
их формализации, рассмотрение возможностей и путей использова­
ния информационных технологий при анализе, синтезе и проектиро­
вании АСОИУ. В результате освоения материала учебника студенты
изучат основы системного подхода к исследованию и оптимизации
процесса автоматизированного управления, ознакомятся с формаль­
ным аппаратом анализа и синтеза структуры АСОИУ, получат пред­
ставление об идеологии построения автоматизированных систем на
базе информационной технологии.
Учебник построен на основе применения в автоматизированном
управлении новейших математических и экономико-математиче­
ских моделей, а также перспективных средств вычислительной и те­
лекоммуникационной техники. Для анализа структуры АСУ исполь­
зованы следующие виды моделей: информационно-логическая,
функциональная и модель на основе бизнес-процессов. Особое вни­
мание уделено таким моделям автоматизированного управления, как
MRP (Material Requirement Planning — планирование материальных
потребностей), ERP (Enterprise Resource Planning — планирование
ресурсов предприятия), PLM (Product Lifecycle Management — управ­
ление жизненным циклом изделия), модели гибкого автоматизиро­
ванного завода, модели адаптивного автоматизированного управле­
ния.
Возникшая в настоящее время эволюция автоматизированного
управления во многом связана с переходом от плановых к рыночным
отношениям. Это выразилось в появлении новых моделей управле­
ния и новых подходов к построению АСУ. В соответствии с этим в
книге последовательно рассмотрен переход от подсистемного подхо­
да к автоматизированному управлению через внедрение стандартов
ERP, QMS, методологию планирования материальных ресурсов
предприятия MRP, концепцию логистических цепочек, концепцию
виртуального бизнеса. На современном этапе развития автоматизи­
рованного управления важное значение приобретает решение задачи
адаптации к быстро изменяющимся внешним условиям. Возникает
проблема создания теории адаптивного автоматизированного управ­
ления. В учебнике приведено общее математическое описание адап­
тивного управления, являющегося основой для исследования задач
планирования и управления при изменяющемся спросе.
Теория автоматизированного управления служит основой эффек­
тивного проектирования автоматизированных систем различного на­
значения. Этой цели отвечает излагаемая в учебнике методология
проектирования АСУ как коллективного процесса. Проанализирова­
ны основные этапы и задачи проектирования АСУ на основе объект­
но-ориентированной технологии как основы создания открытых,
гибких, многофункциональных систем для различных предметных
областей.
Содержание предлагаемого учебника соответствует программе
дисциплины «Теоретические основы автоматизированного управле­
ния». Авторы надеются, что его издание будет способствовать повы­
шению качества подготовки кадров российской высшей школой.

Авторы
 ВВЕДЕНИЕ

Автоматизированное управление прошло длительный путь разви­

тия. Исходным на начальном этапе явилось ручное управление объ­
ектами, при котором обратная связь по результатам управления вос­
принималась органами чувств человека и задача заключалась в
уменьшении мускульных усилий, прикладываемых к рычагам управ­
ления исполнительного органа. Совершенствование управления ста­
ло возможным, когда человек начал использовать средства вычисли­
тельной техники. Возникло два контура: контур управления и контур
обработки информации, которые взаимодействовали через человека.
Развитие средств вычислительной техники позволило создать
программные средства, которые не только поддерживали вычисли­
тельный процесс, но могли на базе предварительно разработанных
алгоритмов осуществить в реальном времени управление требуемым
объектом. Это привело к возникновению автоматического управле­
ния объектом, в котором человек выполнял функцию оператора, не
внося в процесс управления творческого начала, а лишь исполняя
требования инструкций.
Автоматическое управление получило глубокое творческое обос­
нование на основе исследований замкнутых систем управления. Воз­
никла теория автоматического регулирования, в которой основное
внимание акцентировалось на проблемах устойчивости, чувствитель­
ности, организации обратной связи и т. д. Существенным объектом
управления при автоматическом управлении стал технологический
процесс, что позволило выделить технологический уровень управле­
ния производством. Наряду с ним самостоятельное значение приоб­
рел и организационно-экономический уровень управления. На этом
уровне в основе управления оказался процесс принятия решения, вы­
полняемый человеком — руководителем производства. Управление
приобрело автоматизированный характер.
В общем случае процесс принятия решения не поддается форма­
лизации. Оказывается возможным разработать набор типовых реше­
ний, из которых человек-руководитель может осуществить эффек­
тивный выбор оптимального решения с использованием средств вы­
числительной техники. Однако математическая поддержка процес­
сов принятия решений является основным фактором эффективности
автоматизированного управления. Поэтому в учебнике рассмотрена
общая проблема формализации и алгоритмизации процессов приня­
тия решений в условиях автоматизированного управления.
Содержание математического обеспечения дано на примере ряда
областей традиционного автоматизированного управления произ­
водством. Подробно проанализированы вопросы математического
обеспечения задач тактического планирования и стратегических за­
дач управления: технико-экономическое планирование, материаль­
но-техническое снабжение и сбыт, маркетинг, стратегическое управ­
ление. Значительное внимание уделено математическому обеспече­
нию задач оперативного управления основным производством, мето­
дам оперативного управления КАНБАН и Just-In-Time (JIT).
В целом автоматизированная система управления (АСУ) относит­
ся к классу разомкнутых систем, для которых разработанная традици­
онная теория автоматического управления не может быть применена.
Это заставляет с иных позиций подойти к исследованию процесса ав­
томатизированного управления и разработке соответствующей тео­
рии. Рост сложности задач, повышение требований к оперативности
принятия решений приводят к необходимости дальнейшего развития
автоматизированного управления в различных предметных областях.
Этому способствует появление новых математических и экономи­
ко-математических моделей, а также непрерывное совершенствова­
ние средств вычислительной и телекоммуникационной техники.
В учебнике сделана попытка изложить теорию автоматизирован­
ного управления. Исторически в основе построения автоматизиро­
ванных систем управления использовался системный подход. Авторы
предлагают развитие системного подхода в направлении системной
инженерии как нового средства анализа и проектирования системы.
Отличительная особенность рассматриваемой теории состоит в реа­
лизации функционального анализа на основе бизнес-процессов, что
обеспечивает комплексный подход к анализу функционирования
объекта автоматизированного управления. Цель теории — обеспе­
чить эффективное проектирование автоматизированного управле­
ния.
В рамках общей теории изложены два подхода: подсистемный и
процедурный. Подсистемный подход показан на примере автомати­
зированного управления производством. В процедурном подходе ис­
следованы следующие компоненты: ERP-стандарт, международный
стандарт QMS, упорядочение решения задач, «плоская» структура
управления, реинжиниринг, схематика и компьютерная поддержка
представления. Несмотря на специфику конкретных объектов, уда­
лось разработать модели автоматизированного управления.
Сформировавшиеся к настоящему времени идеология и практика
применения автоматизированного управления требуют дальнейшего
развития средств анализа информационных процессов и технологий
как целостной системы. Авторы излагают подходы системной инже­
нерии, позволяющие совместно рассматривать все компоненты АСУ.
Методы системной инженерии позволяют оценить варианты архи­
тектуры и выбрать из них наилучшие. Анализ структуры АСУ
предложено проводить на базе следующих моделей: информацион­
но-логической, функциональной и модели на основе бизнес-процес­
сов. Информационно-логическая модель АСУ базируется на анализе
предметной области и использует два подхода: функционально-мо-
дульный (структурный) и объектно-ориентированный. Функцио­
нальная модель исходит из анализа функциональных возможностей и
использует три аспекта рассмотрения: функциональный, информа­
ционный, организационный. Модель на основе бизнес-процессов
направлена на комплексный анализ деятельности объекта автомати­
зированного управления.
Отличительной особенностью учебника является рассмотрение
теории адаптивного автоматизированного управления. Приведено
общее математическое описание адаптивного управления, являюще­
гося основой для исследования задач планирования и управления
при изменяющемся спросе. В рамках задачи планирования при изме­
няющемся спросе последовательно рассмотрены технология реше­
ния задачи планирования, ресурсное обеспечение плана, согласова­
ние интересов элементов и уровней при определении плана, форми­
рование плана при переходе на выпуск новой продукции, расчет пла­
на с помощью декомпозиции (по частям). В рамках задачи
управления при изменяющемся спросе исследованы векторное свой­
ство элементов и этапы его изучения, анализ свойств элементов с по­
мощью декомпозиции, координация управления элементов и уров­
ней системы, управление при изменяющихся структурных связях.
Теория автоматизированного управления должна предоставить
разработчику системы конструктивный аппарат и средства проекти­
рования. В книге проанализованы основные этапы и задачи проекти­
рования АСУ на основе объектно-ориентированной технологии как
основы создания открытых, гибких, многофункциональных АСУ для
различных предметных областей. Рассмотрены вопросы создания
АСУ при подсистемном и процедурном построении, исследованы во­
просы использования реинжиниринга в процессе проектирования
АСУ. Особое внимание уделено современному подходу к построению
АСУ. Дана характеристика основному инструментальному средст­
ву — CASE-технологиям. Материал подкреплен изложением вопро­
сов практического проектирования АСУ. Таким образом, данный
учебник охватывает широкий круг тем, обеспечивая студенту ком­
плексное представление о содержании современной теории автома­
тизированного управления, а также направлениях ее конструктивно­
го использования при исследовании, разработке и проектировании
автоматизированных систем управления.
 ГЛАВА 1
Общая характеристика
автоматизированного управления

Рост сложности задач, повышение требований к оперативности принятия

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

1.1. ПОНЯТИЕ АВТОМАТИЗИРОВАННОГО

УПРАВЛЕНИЯ

Управление — целенаправленный перевод системы из одного со­

стояния в другое желаемое.
Система управления — совокупность взаимодействующих компо­
нентов: объекта управления и управляющих частей.
Структура — совокупность элементов и их связей.
Простейшая структура приведена на рис. 1.1. Структура системы
управления может быть многоуровневой (структурой подчинения).
Объект управления (ОУ) — динамическая система любой природы,
преобразующая ресурсы в продукты и находящаяся под действием
управляющих и возмущающих воздействий.
Возмущающее воздействие — воздействие, выводящее систему в
нежелательное состояние.
 Рис. 1.1. Простейшая структура системы управления

Решение {управляющее воздействие, управление) — воздействие,

выбранное из множества возможных на основе поставленной цели и
принятого критерия.
Критерий — оценка вариантов решений.
Цель — состояние, к которому стремится система.
Управляющая часть (УЧ) — часть системы, вырабатывающая ре­
шения и передающая их на объект управления.
Среда — метасистема, в которую рассматриваемая система управ­
ления входит составной частью.
Функционирование системы — работа системы в рамках заданной
структуры.
Развитие системы — работа системы в условии острых противо­
речий, которые могут вызвать изменение структуры.
Рассмотрим подробнее объект управления (рис. 1.2) как систему
преобразования ресурсов в продукты. Объект управления использует
следующие виды общих ресурсов: материальные, трудовые, финан­
совые, оборудование.
При более подробном рассмотрении процессов в управляющей
части возможно получить совокупность этапов (рис. 1.3). Эта схема
М атериалы (энергия)
Трудовые ресурсы
Техническая информация Продукты
ОУ
Оборудование
Ф инансовые ресурсы

ю
 Рис. 1.3. Цикл управления

пригодна для ручного, автоматического и автоматизированного

управления.
Хорошо известны системы автоматического управления, рабо­
тающие без участия человека. В основе автоматического управления
лежит управление отдельными объектами на базе заданных алгорит­
мов, реализуемое техническими средствами. Используется три прин­
ципа управления: разомкнутое, замкнутое (обратная связь), компен­
сация возмущений.
По мере развития автоматического управления определились его
основные направления: автоматическое регулирование (стабилиза­
ция), программное управление, следящие системы, экстремальное
регулирование, поисковые системы, оптимальное управление, само­
настраивающиеся системы.
Однако внедрение автоматических систем управления не позво­
лило исключить человека из контура управления, а тенденции разви­
тия общественного производства, наоборот, усложнили функции,
выполняемые им. Эти причины, а также появление ЭВМ способство­
вали бурному развитию автоматизированного управления, отличи­
тельными чертами которого являются автоматизация комплексов
процессов или объектов, включение человека в контур управления,
информационный и вероятностный подход к процессу управления,
использование ЭВМ как основного технического средства, реали­
зующего функции управления.
Схема, приведенная на рис. 1.3, позволяет точнее определить по­
нятие «автоматизированная система» как систему, в которой хотя бы
на одном этапе цикла управления используются компьютеры и тех­
нические средства.
Очевидно, что могут быть выделены разные уровни автоматиза­
ции (режимы работы). Наиболее известны информационно-поиско­
вый (рис. 1.4) и информационно-советующий режимы (рис. 1.5).
 Рис. 1.4. Информационно-поисковая система

Автоматизированное управление базируется на теории информа­

ции, теории сложных систем, теории автоматического управления,
теории принятия решений.
Современные проблемы управления характеризуются следующи­
ми особенностями.
1. Рост объемов и масштабов производства, усложнение матери­
альных и, следовательно, информационных связей.
2. Существенный рост потоков информации, скорость поступле­
ния которой превышает возможности ее обработки человеком-руко-
водителем, или лицом, принимающим решения (ЛПР).
3. Дефицит времени при принятии решений приводит к отсече­
нию части информации, возможно и полезной. Это может вызвать
резкое снижение качества принимаемых решений, принятие оши-
бочных решений. Ошибки оказываются тем масштабнее, чем выше
уровень иерархии принятия решений.
4. Для исправления последствий ошибочных решений могут по­
надобиться дополнительные ресурсы и время.
Рыночные отношения связаны следующими особенностями:
• серийностью выпуска (производства) продукции при ее инди­
видуализации в зависимости от запросов потребителей;
• ростом требований к качеству продукции;
• потребностью в создании конкурентоспособной продукции за
счет сокращения производственного цикла.
Перечисленные особенности повышают требования к качеству
управления.
Улучшить качество управления возможно двумя путями:
• экстенсивным (увеличением численности работающих) — воз­
можности этого пути ограничены как возможностями человека, так и
конечным количеством трудовых ресурсов;
• интенсивным — широким использованием в управлении вы­
числительной техники и созданием автоматизированных, челове­
ко-машинных систем управления. Место человека в таких системах
определим позднее.
Последние исследования (компании Garter и Standish Group) пока­
зывают, что автоматизация позволяет сократить потребность в мате­
риалах и денежных средствах на 30 %, увеличить прибыль на 5...10 %,
сократить время обслуживания клиентов на 20 %.
В то же время успехами во внедрении АСУ могут похвастаться
лишь 16 % компаний, причем 53 % из них потратили денег и времени
в 1,9 раза больше, чем первоначально планировали, а 31 % проектов
провалился. Основная причина неудач — недостаточно умелое про­
ведение автоматизации.
Таким образом, интенсивный путь имеет большие перспективы.
Однако для его использования требуется более детально изучить про­
цесс управления.

1.2. ОСНОВНЫЕ АСПЕКТЫ

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

Важнейшими аспектами автоматизированного управления явля­

ются:
• главенствующая роль информации в процессе управления;
• иерархический характер процесса управления;
 • системный подход к процессу построения автоматизированны
систем.
Все виды деятельности человека по преобразованию природы и
общества сопровождались получением новой информации. Логиче­
ская информация, адекватно отображающая объективные законо­
мерности природы, общества и мышления, получила название науч­
ной информации. Ее делят по областям получения или использова­
ния на следующие виды: политическую, техническую, биологиче­
скую, химическую, физическую и т. д.; по назначению — на
массовую и специальную. Часть информации, которая занесена на
бумажный носитель, получила название документальной. Любое
производство при функционировании требует перемещения доку­
ментов, т. е. возникает документооборот. Наряду с научной информа­
цией в сфере техники при решении производственных задач исполь­
зуется техническая информация. Она сопровождает разработку но­
вых изделий, материалов, конструкций, агрегатов, технологических
процессов. Научную и техническую информацию объединяют терми­
ном «научно-техническая информация».
Верхним уровнем информации как результата отражения окру­
жающей действительности (результата мышления) являются знания.
Знания возникают как итог теоретической и практической деятель­
ности. Информация в виде знаний отличается высокой структуриза­
цией. Это позволяет выделить полезную информацию при анализе
окружающих нас физических, химических и прочих процессов и яв­
лений. На основе структуризации информации формируется инфор­
мационная модель объекта. По мере развития общества информация
как совокупность научно-технических данных и знаний превращает­
ся в базу системы информационного обслуживания научно-техниче­
ской деятельности общества.
При анализе процесса управления ввиду сложности объекта про­
изводят его расчленение на части по различным признакам. Одним из
главных признаков является вид иерархии. Характерны следующие
виды иерархии: временная, пространственная, функциональная, си­
туационная и информационная. Следует отметить, что деление ка­
кой-либо системы на части не может быть однозначным, так как вы­
деление границ между частями всегда является в какой-либо мере
субъективным. Выбор того или иного принципа выделения состав­
ных частей должен удовлетворять следующим основным условиям:
обеспечивать их максимальную автономность, учитывать необходи­
мость координации их действий для достижения общей цели функ­
ционирования, а также совместимость отдельных частей.
 Временная иерархия. Признаком деления здесь является интервал
времени от момента поступления информации о состоянии объекта
управления до выдачи управляющего воздействия. Чем больше ин­
тервал, тем выше уровень (ранг) элемента. Управление может осуще­
ствляться в реальном времени, с интервалом сутки, декада, месяц,
квартал и т. д. Причем управляющий интервал выбирается не произ­
вольно, а исходя из критериев, определяющих устойчивость и эффек­
тивность функционирования всей системы.
Пространственная иерархия. Признаком деления здесь является
площадь, занимаемая объектом управления. Чем больше площадь
объекта, тем выше его ранг. Данный признак — субъективный, так
как не всегда площадь, занимаемая объектом, соответствует его зна­
чимости, и его можно использовать в случае аналогичности парамет­
ров элементов одного уровня.
Функциональная иерархия. В основе лежит функциональная зави­
симость (подчиненность) элементов системы. Такое разделение так­
же является субъективным, так как в этом случае трудно выделить
границы между элементами системы.
Ситуационная иерархия. Деление на уровни в данном случае про­
изводится в зависимости от эффекта, вызываемого той или иной си­
туацией, например от ущерба, возникающего в результате аварии или
выхода из строя оборудования.
Информационная иерархия. В настоящее время этот вид иерархии
является очень существенным в связи с возросшим значением ин­
формации для управления. В основе деления на уровни лежат опера­
тивность и обновляемость информации. Именно через эти характе­
ристики прослеживается иерархия информации по уровням управле­
ния предприятием.
На первом уровне хранится и обрабатывается повторяющаяся,
часто обновляющаяся информация, необходимая для повседневной
деятельности, т.е. для оперативного управления. Следующий уровень
составляет информация более обобщенная, чем оперативная, и ис­
пользуемая не так часто. Информация группируется по функцио­
нальным областям и применяется для поддержки принятия решения
по управлению производством. На верхнем уровне хранится и обра­
батывается стратегическая информация для долгосрочного планиро­
вания. Для нее характерны высокая степень обобщенности, неповто-
ряемость, непредсказуемость и редкое использование.
В общем виде функциональная модель процесса управления
представлена на рис. 1.6. Учет информации об объекте управления
состоит в регистрации, классификации и идентификации. На основе
разнообразных математических моделей, описывающих реальное и
 Рис 1.6. Функциональная модель системы управления

требуемое состояние объекта, и критериев оптимальности анализи­

руют информацию о состоянии объекта управления. Окончательную
модель прогнозируемого состояния объекта управления формируют
в виде плана. Возникающие за счет внешних воздействий отклонения
от плана корректируют путем сравнения учетной и плановой инфор­
мации, нового анализа и формирования управляющих воздействий
(регулирования).
В большинстве случаев при информационном анализе процесса
управления обычно рассматривают пассивную форму проявления
информации, отражающую свойства внешней среды, объекта управ­
ления и самой управляющей системы. Однако не менее важное значе­
ние имеет и активная форма информации, являющаяся причиной из­
менения состояния управляемого объекта.
Принято выделять следующие качественно различимые формы
проявления информации: осведомляющую /„с, преобразующую /п,
принятия решения /пр и управляющую /у.
К осведомляющей относят информацию о состоянии внешней
среды, объекта управления и управляющей системы. Преобразующая
включает информацию, содержащуюся в алгоритмах управления.
Информация принятия решения является отражением образов и це­
лей на конечное множество принимаемых решений. Управляющая
информация вызывает целенаправленное изменение состояния объ­
екта управления.
В любой системе управления можно выделить два информацион­
ных канала: целевой и рабочий. В целевом канале на основе инфор­
мационных процессов происходит выбор цели и принятие решения
по выбору управляющего воздействия. В рабочем канале формирует­
ся информация, реализуемая исполнительным органом, осуществ­
ляющим целенаправленное изменение состояния объекта управле­
ния через вещественно-энергетические характеристики. Целевой ка­
нал может находиться как на одном уровне иерархии с рабочим, так и
на более высоком. На рис. 1.6 выделены целевой и рабочий каналы, а
также приведены основные формы проявления информации.
Классическое проектирование автоматизированных систем берет
свое начало в 70-х годах прошлого столетия. Одно из первых направ­
лений получило название «каскадной» схемы проектирования. Она
широко использовалась при проектировании АСУ и включала сле­
дующие стадии проекта: запуск, обследование, концепцию техниче­
ского задания, эскизный проект, технический проект, рабочий про­
ект, ввод в действие (внедрение). Основной особенностью данной
методики является последовательная организация работ при разбие­
нии структуры проектируемой системы на заранее определенный ряд
подсистем: организационное, методическое, информационное, про­
граммное и аппаратное обеспечения. В западной литературе такая
схема организации работ получила название «водопадной модели»
(waterfall model) и включала дополнительно итерационные процеду­
ры уточнения требований к системе и рассмотрения вариантов про­
ектных решений. Основными недостатками «каскадной» схемы про­
ектирования являются запаздывание получения конечных результа­
тов и низкая эффективность.
В процессе совершенствования разработки автоматизированных
систем появилась схема непрерывной разработки (рис. 1.7), исполь­
зовавшаяся при реализации больших проектов фирмы IBM в 70—80-х
годах XX в. Характерной особенностью данной методики стал непре­
рывный спиральный процесс разработки автоматизированных сис­
тем с планируемыми точками передачи в эксплуатацию новых версий
и новых функциональных подсистем.
Развитие схемы непрерывной разработки связано с совершенст­
вованием циклических форм проектирования. Пример такого подхо­
да — ускоренный метод проектирования, получивший название «бы­
строе прототипирование». В проектный цикл дополнительно были
включены стадии разработки макета-прототипа и его опробования.
Недостатками схемы непрерывной разработки являются жесткость
используемых моделей проектирования и закрытость создаваемых
автоматизированных систем.
Следствием недостатков классических методов проектирования
стал переход к системному проектированию.
Системный подход оперирует рядом категориальных понятий.
Фундаментальным понятием системного подхода является понятие
системы, при определении которой необходимо преследовать кон­
кретную цель. Если целью является познание уже существующей сис­
темы, то вполне пригодным оказывается ее дескриптивное определе­
ние, которое заключается в следующем: система — это совокупность
объектов, свойства которой определяются отношением между этими
объектами [45]. Объекты называют подсистемами или элементами
системы. Каждый объект при самостоятельном исследовании может
рассматриваться как система. Функции объекта определяются внут­
ренним устройством объекта. Таким образом, дескриптивное опреде­
ление системы играет познавательную роль для объяснения функ­
ций, реализуемых системой. Функции системы проявляются в про­
цессе взаимодействия ее с внешней средой. При этом важно опреде­
лить границу между внешней средой и создаваемой системой на
основе конструктивного определения системы. Для технических сис­
тем особое значение имеет конструктивный подход. Любая техниче­
ская система создается под заранее известную цель. Цель такой систе­
мы обычно является субъективной, поскольку она предлагается раз­
работчиком, но эта цель должна исходить из объективных потребно­
стей общества. Таким образом, можно считать, что цель формируется
в процессе взаимодействия между явлениями окружающей действи­
тельности. При этом возникает ситуация, которая заставляет строить
новую систему. Ситуация может стать проблемной, если она не разре­
шается имеющимися средствами и приводит к необходимости созда­
ния новых недостающих средств.
Все, что не вошло в состав системы, относят к окружающей среде.
Очевидно, что окружающая среда включает в себя другие системы,
которые реализуют свои цели функционирования. Входы и выходы
системы связаны с внешней средой. На модельном уровне выделяют
модель системы, модель внешней среды на входе системы, модель
внешней среды на выходе системы и модели связей между системой и
внешней средой на входе и выходе.
Дескриптивный подход реализуется путем изучения функции
либо структуры системы. В соответствии с этим в теории систем полу­
чили применение функциональный и структурный подходы.
Учитывая, что структура отображает связи между элементами
системы с учетом их взаимодействия в пространстве и во времени,
можно утверждать, что структурный подход есть развитие дескрип­
тивного подхода. Он служит для изучения (познавания) какой-то су­
ществующей системы. Функциональный подход отображает функции
системы, реализуемые в соответствии с поставленной перед ней це­
лью. Поэтому функциональный подход есть развитие конструктив­
ного. Функции системы должны быть заданы при ее построении и
должны реализовываться при функционировании системы.
Структура системы описывается на концептуальном, логическом
и физическом уровнях. Концептуальный уровень позволяет качест­
венно определить основные подсистемы, элементы и связи между
ними. На логическом уровне могут быть сформированы модели, опи­
сывающие структуру отдельных подсистем и взаимодействия между
ними. Физический уровень означает реализацию структуры на из­
вестных программно-аппаратных средствах. Так как техническая
система создается искусственно, цель ее функционирования заранее
субъективно известна. Можно считать, что этой цели соответствуют
определенный перечень функций и некоторая оптимальная структу­
ра системы. Такая структура получила название формальной. Под ней
понимают совокупность функциональных элементов и отношений
между ними, необходимых и достаточных для достижения системой
заданной цели. Формальная структура есть некоторая идеальная, не
имеющая физического наполнения. Эта структура реализуется раз­
личными средствами, поэтому формальной структуре может соответ­
ствовать ряд материальных как реальных наполнений формальной
структуры. Внешняя среда, взаимодействуя с информационной тех­
нологией как с системой, может выступать как метасистема, ставя пе­
ред ней определенные задачи и формулируя цели. Внедрение инфор­
мационных технологий в жизнь общества за конечный временнбй
интервал будет иметь эффект, если будут типизированы системы, в
которые внедряются информационные технологии, и определены
типовые структуры информационной технологии. В зависимости от
системы, в которую внедряются информационные технологии, воз­
можно различное пространственное распределение пользователей и
средств информационной технологии. Разным может быть и ком­
плекс решаемых задач. Характер и временнбй интервал реализации
целей автоматизированного управления также зависят от того, в ка­
кой области оно используется, т.е. в промышленности, научных ис­
следованиях, проектировании, обучении и т. д. Весьма важно согла­
сование структуры информационных технологий с организационной
структурой той системы, в которой она используется.
 1.3. КЛАССИФИКАЦИЯ АСУ

ГОСТ 34.003—90 дает такое понятие автоматизированной систе­

мы управления (АСУ): «АСУ — система «человек — машина», обес­
печивающая эффективное функционирование объекта, в которой
сбор и обработка информации, необходимой для реализации функ­
ций управления, осуществляются с применением средств автомати­
зации и вычислительной техники».
Выделяют следующие виды автоматизированных систем:
АСУТП — АСУ технологическими процессами; АСОУ — автомати­
зированные системы организационного управления; ИАСУ — ин­
тегрированные АСУ; ОАСУ — отраслевые АСУ; АСУП — АСУ пред­
приятия; АСУО — АСУ объединения; ИПС — информационно-по­
исковые системы; ИСС — информационно-советующие системы;
ИУС — информационно-управляющие системы.
В силу значительного разнообразия АСУ их целесообразно клас­
сифицировать. АСУ — понятие многогранное и потому имеет боль­
шое число признаков классификации. Из них рассмотрим три основ­
ные (рис. 1.8).
1. Анализируя первый признак классификации, следует отметить
что объектом управления в АСУТП являются машины или системы
машин, а в АСОУ (АСУ на уровне цеха, предприятия и выше) —
люди. В АСУТП информация передается сигналами, а в АСОУ — с
помощью документов.
В последнее время появился новый класс систем — ИАСУ, объе­
диняющий в одну систему АСУТП и АСОУ. Среди них выделяют
ИАСУ гибкими автоматизированными заводами, для которых из­
вестны три основные рассмотренные далее концепции: ГАЗ (СССР),
ESPRIT (ЕЭС) и ICAM (США). ИАСУ гибкими автоматизированны-
ми заводами за рубежом называют компьютерными интегрирован­
ными производствами (Computer Integrated Manufacturing CIM).
2. Иерархия управления отражена во втором классификационном
признаке (см. рис. 1.8). В дальнейшем будем рассматривать АСУП,
т. е. АСУ, предназначенную для управления предприятием.
3. АСУ существенно отличаются по уровню автоматизации. ИПС
предназначены для записи и длительного хранения информации, ко­
торая считывается по запросу. Такая система может быть самостоя­
тельной (библиотеки) или входить составной частью в АСУП. База
данных является основой таких систем. В ней может быть отражена
как структурированная (в виде таблиц), так и неструктурированная
(текстовая) информация. В последнем случае это системы компьюте­
ров офисов, учреждений, получившие широкие возможности благо­
даря электронной почте.
ИСС вырабатывают для ЛПР соответствующие решения-советы в
логической, числовой или символьной форме, при этом окончатель­
ное решение остается за человеком. В ИСС широко используют диа­
логовый режим.
Сложности реализации таких систем определяются трудностями
формирования алгоритмов этапов анализа, выработки вариантов ре­
шений и принятия решений в цикле управления. Первоначально ал­
горитмизацией этих этапов занимались разработчики автоматизиро­
ванных систем. Пользователь вводил данные и получал результат.
Если результат его удивлял, он желал получить (и не получал) объяс­
нение, КАК получено то или иное решение. Выяснилось к тому же,
что логики решений разработчика и ЛПР серьезно отличаются.
В связи с этим попытались использовать опыт принятия решений
руководителем, выявляя систему используемых ими правил. ЛПР за­
давали вопрос: «Ваше подразделение не выполнило план за предыду­
щий день и с начала месяца — Ваши действия?».
Ответы ЛПР представляли собой систему правил по схеме:
ЕСЛИ недостаточно определенного ресурса,
ТО предпринимаются определенные действия по их получению
или замене.
Подобные правила позволили не только в значительной мере пре­
одолеть отчужденность ЛПР по отношению к компьютерам, но и реа­
лизовать экспертные системы, которые позволяли не только выраба­
тывать решения-советы, но и давать объяснения (в виде системы ис­
пользованных правил), КАК получено то или иное решение.
Вместе с тем только около 5 % существующих автоматизирован­
ных систем реализованы как информационно-советующие системы.
Подавляющее большинство АСУП являются по своей сути информа­
ционно-поисковыми системами.
ИУС фактически являются синонимами автоматической системы
в виде, например, гибкого автоматизированного завода (компьютер­
ного интегрированного производства — КИП).
Каждый класс АСУ характеризуется общими или специфически­
ми положениями. Для иллюстрации общетеоретических и приклад­
ных положений выбран наиболее распространенный класс АСУП.
Круг объектов управления чрезвычайно широк и разнообразен:
экономика, территория, социальная сфера, производство, научный
эксперимент, образование и др.
В настоящее время автоматизированное управление все шире ис­
пользуется в различных областях: в управлении производствами
(предприятиями) — АСУП, технологическими процессами — АСУТП,
в автоматизации научных исследований — АСНИ, в обучении.
Наиболее широко автоматизация проводится в управлении про­
изводствами и технологическими процессами.
Уже до 1985 г. XX в. в нашей стране было введено в строй свыше
6000 традиционных АСУ различных классов. Распад СССР сильно за­
медлил в России работы по построению и внедрению АСУ, однако в
последние пять-шесть лет в этой области наблюдается оживление. В
традиционных АСУП наметился переход от подсистемного построе­
ния к процедурному. Разработаны отечественные тиражируемые
АСУП, получившие название корпоративных информационных сис­
тем (КИС) «Галактика» и «Парус».
Условно выделяют тиражируемые, полузаказные и заказные сис­
темы.
Тиражируемая КИС не требует доработки со стороны разработчи­
ка, существует сама по себе, не предоставляет возможности внесения
изменений. Такая система предназначенадля малых предприятий.
Заказная система создается для производств с очень большой спе­
цификой.
Полузаказная система является наиболее гибкой, в большей сте­
пени удовлетворяет требованиям заказчика, требует меньших капи­
тальных затрат. Основная область применения — крупные предпри­
ятия (сотни документов в месяц и более пяти человек в цепочке биз­
нес-процессов).
Внедрение АСУП предполагает автоматизацию управления тех­
нологическими процессами. АСУТП находят широкое применение в
управлении как детерминированными процессами, так и процессами
с вероятностным характером, способствуют повышению производи­
тельности труда, росту загрузки оборудования, сокращению непроиз­
водительных потерь.
В настоящее время в области АСУТП господствующей является
концепция открытых систем на основе системной интеграции, бази­
рующаяся на следующих принципах:
• совместимость программно-аппаратных средств различных
фирм производителей снизу вверх;
• комплексная проверка и отладка всей системы на стенде фир­
мы-интегратора на основе спецификации заказчика.
В большинстве случаев АСУТП представляет двухуровневую сис­
тему управления. Нижний уровень включает контроллеры, обеспечи­
вающие первичную обработку информации, поступающей непосред­
ственно с объекта управления. Программное обеспечение контролле­
ров обычно реализуется на технологических языках (язык релей-
но-контактных схем).
Верхний уровень АСУТП составляют мощные компьютеры, вы­
полняющие функции серверов баз данных и рабочих станций, обес­
печивающих хранение, анализ и обработку всей поступающей ин­
формации, а также взаимодействие с оператором. Основой про­
граммного обеспечения верхнего уровня являются пакеты SCADA
(Supervision Control And DATA Acquisition).
Наиболее ярко концепция открытых систем прослеживается в от­
крытой модульной архитектуре контроллеров — ОМАС (Open
Modular Architecture Controls), разработанной фирмой «General
Motors». Близкие к ним концепции предложены европейскими
(European Open Systems Architecture for Controle within Automation
Systems — OSACA), японскими (Japan International Robotics and
Factory Automation — I FORA; Japan Open Systems Environment for
Controller Architecture — OSEC) и американскими (Technologies
Enabling Agile Manufacting — TEAM Projects) организациями. Содер­
жание ОМАС-требований заключается в основных терминах:
• Open — открытая архитектура, обеспечивающая интеграцию ап­
паратного и программного обеспечения;
• Modular — модульная архитектура, позволяющая использовать
компоненты в режиме Plug and Play;
• Scaleable — масштабируемая архитектура, позволяющая легко
изменять конфигурацию для конкретных задач;
• Economical — экономичная архитектура;
• Maintenable — легко обслуживаемая архитектура.
Аппаратная платформа контроллеров базируется на миниатюр­
ных PC-совместимых компьютерах, обладающих высокой надежно­
стью, быстродействием, совместимостью в силу «родственности» с
компьютерами верхнего уровня. Операционная среда РС-контролле-
ров также должна удовлетворять требованиям открытости. Здесь наи­
более распространена операционная система QNX (фирма QSSL, Ка­
нада), архитектура которой является открытой, модульной, легко мо­
дифицируемой. Специфика работы с контроллерами — использова­
ние языков технологического программирования, описывающих сам
технологический процесс и ориентированных на работу не програм­
мистов, а технологов.
АСУТП работают в реальном масштабе времени и строятся на ос­
нове средств вычислительной техники, позволяющих получать на
выходе системы электрические сигналы. Это дает возможность ин­
тегрировать АСУТП и АСУП, минуя ручной ввод оперативной ин­
формации в АСУП. Такие системы называют интегрированными
(ИАСУП).
Высокоавтоматизированная разновидность ИАСУП, использую­
щая современный подход к проектированию, получила название
«гибкий автоматизированный завод» (ГАЗ). За рубежом подобные
системы называют компьютерными интегрированными производст­
вами (Computer Integrated Manufacturing — CIM).
В ГАЗ производства, приспосабливаясь к изменчивому спросу по­
требителя, становятся динамичными, что, в свою очередь, требует ав­
томатизации конструкторской и технологической подготовки, преж­
де всего в части формирования новой продукции. Возрастает роль
подсистем испытаний изделий на качество.
Для ускорения разработки принципиально новой продукции тре­
буется автоматизация научных исследований и экспериментов. Авто­
матизация научных экспериментов может носить и автономный ха­
рактер.
Проведение научных исследований на современном этапе сопро­
вождается постановкой экспериментов на базе уникального оборудо­
вания с необходимостью обработки большого объема информации.
Оперативная компьютерная ее обработка позволяет выявлять крити­
ческие ситуации и своевременно принимать решения по дальнейше­
му ходу эксперимента. Автоматизация позволяет резко повысить опе­
ративность и сократить сроки проведения эксперимента.
Растущий уровень автоматизации и компьютеризации в различ­
ных областях требует подготовки квалифицированных специалистов.
В последнее время складывается направление, связанное с автомати­
зацией и компьютеризацией обучения. Такая автоматизированная
система состоит из комплекса изучаемых дисциплин, связанных еди-
 Методы
Управление проектами
ERP-стандарт
Управление точно в срок
Управление
серийным
производством
Управление
потоками

Секунды Минуты Дни Недели Месяцы

Время

Нефть Пищевые Бытовая техника, Строи­ Авиа­ Строи­

продукты, легкая тельная строе­ тель­
лекарства промышленность, техника ние ство
машино- и зданий,
приборостроение, корабле­
электронная строение
промышленность

Рис. 1.9. Классификация систем производственного управления:

1 — массовый тип производства; 2 — серийный; 3 — единичны й тип производства

ной «цепочкой» последовательности их рассмотрения, и сопровожда­

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

Классификацион­ Классы
ный признак 1 2 3 4
1. Разделение за­ Конструиро­ Изготовле­ Сборка на Изготовле­
казчиков вание на заказ ние на заказ заказ ние на склад
2. Способ изготов­ Единичный Серийный Массовый -
ления
3. Спектр продук­ Индивиду­ Типовой Стандар­ Стандарт­
ции альный тный без ва­ ный с вариа­
риаций циями
4. Изменение за­ В большом Случайные Незначи­ --
казов в процессе из­ объеме тельные
готовления
5. Автоматизация Высокая Средняя Малая Отсутствует
6. Экономический Прибыль Зарплата Выпуск —
интерес
7. По уровням Одноуров­ Многоуров­ — —
управления невые невые
8. По выпускае­ Одноно­ Многоно­ — —
мой номенклатуре менклатурные менклатурные
9. По возмущени­ Целевые Структурные Параметри­ Сигнальные
ям ческие
10. Описание по Непрерыв­ Непрерыв- Дискретное -
цехам ное но-дискретное
11. Запас Нулевой Оптималь­ — -
(JIT) ный
12. Протекание Остров Линия Поток -
изготовления
13. Способ соеди­ Последо­ Параллель­ С обратной -
нения вательный ный связью
14. Протекание Групповой Остров Линия Поток
монтажа монтаж

При плановой экономике превалирующим классом являлся класс

4.1 (см. табл. 1.1). Соответствующие ему многоуровневые системы
управления для сильно инерционных производств подробно изучены
в процессе создания традиционных АСУ [1, 11,44, 50, 53, 58, 59], при
этом в подавляющем большинстве работ рассмотрен статический ре­
жим (планирование и учет), опирающийся на статические базы дан­
ных. В то же время динамическим процессам, имеющим место из-за
действующих на систему управления многочисленных возмущений,
посвящено незначительное число работ [36, 43], рассматривающих
лишь отдельные аспекты проблемы.
При цивилизованных, регулируемых государством рыночных от­
ношениях потребитель все более характеризуется растущей индиви­
дуализацией требований к продукту, существенной и оперативной
изменчивостью запросов на товары, повышением требований к каче­
ству продукции [14—16]. Иными словами, все большую долю потре­
бителей следует отнести к более динамичному классу 2.1, частным
случаем которого является класс 3.1, и даже 1.1. Дальнейший анализ
проведен для дискретных многономенклатурных производств.
Перечисленные классы связаны с быстрым изменением (дина­
мичностью) спроса, которое обусловлено либо быстрыми измене­
ниями в технологии (радиоэлектронная и химическая промышлен­
ность, приборо- и машиностроение, производство бытовых товаров),
либо сильной конкуренцией (при отсутствии монополии — легкая
промышленность, полиграфия).
Несмотря на разнообразие областей применения автоматизации,
существуют общие тенденции, которые ведут к формированию тео­
рии автоматизированного управления. Она рассматривает методоло­
гические основы и общие принципы построения АСУ разных клас­
сов. В то же время каждая автоматизируемая область имеет свою спе­
цифику. Для иллюстрации общетеоретических и детализации специ­
фических положений выбраны АСУП, для которых представлены
организационные, функциональные и обеспечивающие аспекты.
В современной АСУ выделяют следующие компоненты, обеспе­
чивающие ее функционирование: методическое, правовое, эргоно­
мическое, математическое, информационное, инструментальное,
программное и техническое обеспечения.
Методическое обеспечение АСУ представляет собой совокупность
документов, поддерживающих процессы проектирования, внедре­
ния и эксплуатации. Одной из основных задач методического обеспе­
чения является унификация и стандартизация.
Правовое обеспечение АСУ представляет собой совокупность
норм, выраженную в нормативных актах, устанавливающих и закреп­
ляющих организацию процессов проектирования, внедрения и экс­
плуатации, а также регламентирующих правовой статус АСУ.
Эргономическое обеспечение — это совокупность методов и
средств, обеспечивающих оптимальные условия деятельности чело­
века в условиях автоматизированного управления.
 Математическое обеспечение АСУ представляет собой совокуп­
ность математических и экономико-математических моделей управ­
ления заданным объектом.
Информационное обеспечение предназначено для хранения, поиска
и доступа к информационным ресурсам, на основе которых реализу­
ется жизненный цикл АСУ.
Под инструментальным обеспечением понимается комплекс про­
граммных и технических средств, обеспечивающих эффективное
функционирования АСУ.
Программные средства АСУ можно разделить на две большие
группы: базовые и прикладные. Базовые программные средства
включают в себя: операционные системы; языки программирования;
программные среды; системы управления базами данных. Приклад­
ные программные средства предназначены для решения комплекса
задач или отдельных задач АСУ.
Комплекс технических средств — это совокупность взаимосвя­
занных единым управлением средств вычислительной техники и те­
лекоммуникационных средств.

КОНТРОЛЬНЫЕ ВОПРОСЫ

1. В чем сущность автоматизированного управления?

2. Какие существуют уровни (режимы работы) автоматизированного управ­
ления?
3. В чем суть «каскадной» схемы проектирования АСУ?
4. Укажите основные преимущества схемы непрерывной разработки.
5. Сформулируйте основные понятия системного подхода.
6. В чем различие дескриптивного и конструктивного подхода?
7. Укажите основные виды информационных потоков в структуре автомати­
зированного управления.
8. Перечислите основные классификационные признаки АСУ.
9. Приведите классификацию систем производственного управления в зави­
симости от временнбй иерархии.
10. Дайте характеристику основных видов обеспечения АСУ.
 ГЛАВА 2
Методология построения
автоматизированных систем

Эволюция автоматизированного управления во многом связана с переходом

от плановых к рыночным отношениям. Это выразилось в появлении новых моде­
лей управления и новых подходов к построению АСУ. В данной главе последова­
тельно рассмотрен переход от подсистемного подхода к автоматизированному
управлению через внедрение стандартов ERP, QMS, методологию планирования
материальных ресурсов предприятия MRP, концепцию логистических цепочек,
концепцию виртуального бизнеса.
Подсистемный подход показан на примере автоматизированного управле­
ния производством. В процедурном подходе рассмотрены следующие компонен­
ты: ERP-стандарт, международный стандарт QMS, упорядочение решения задач,
«плоская» структура управления, реинжиниринг, схематика и компьютерная
поддержка представления.

2 .1 . ОСНОВНЫЕ ЭТАПЫ СТАНОВЛЕНИЯ

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

В процессе своего развития и становления автоматизированное

управление прошло сложный эволюционный путь, который отмечен
использованием разнообразных моделей и методов. До 90-х годов
XX в. при реализации и функционировании автоматизированного
управления использовалось подсистемное представление.
С 90-х годов совершенствование автоматизированных систем
проходило в несколько этапов.
1) построение ERP — стандарта (80-е годы XX в.);
2) разработка стандарта QMS — конец XX в.;
3) переход к процедурному построению — с конца XX в. по на­
стоящее время.
 Таким образом, можно выделить два основных подхода: подсис­
темный и процедурный
Подсистемное построение ставит своей целью решение в рамках
подсистем соответствующих математических задач. Подход, осно­
ванный на подсистемном построении, сформировался и оформился в
СССР в 70-е годы XX в., детально проработан методически, в частно­
сти, в виде документа «Общеотраслевые руководящие методические
материалы по созданию АСУ предприятий и отраслей» — ОРММ-2,
выпущенного в 1975 г. С использованием этого подхода к 1990 г. в
СССР было построено свыше 6000 АСУ различных классов.
Подсистемное проектирование основано на делении системы на
составные части — подсистемы. Подсистема — часть системы, выде­
ленная по неформальному признаку. На практике выделение подсис­
тем осуществляется по функциям (учет, анализ, контроль, планиро­
вание и т. д.), интервалу управления (реальное время, сутки, месяц,
квартал и т. д.), иерархии управления (подразделение, предприятие,
объединение и т. д.), типу управляемого ресурса (финансы, кадры,
материалы, готовые изделия и т. д.). Признак деления является опре­
деляющим для определения структуры АСУ.
Функциональной подсистемой называют часть системы управле­
ния, выделенную по общности функциональных признаков. Сущест­
вуют три аспекта разделения системы на функциональные подсисте­
мы: алгоритмическая общность, включающая единство критериев
управления, математических моделей и методов решения задач; ин­
формационная общность, основанная на использовании информа­
ции, определяемой одной и той же предметной областью; функцио­
нальная общность, подразумевающая единый характер управляющих
воздействий.
П одсистемная структура характерна для традиционных АСУ и для
первой стадии создания АСУ с современным подходом к проектиро­
ванию. В силу многообразия типов АСУ во многом формирование
структуры АСУ зависит от характера и специфики объекта управле­
ния. Формирование такого построения в сильной мере было обуслов­
лено существованием только информационной технологии масси­
вов, позволившей строить подсистемы относительно самостоятель­
но.
С появлением и широким внедрением в 80-е годы XX в. техноло­
гии баз данных резко изменилась структура АСУ. Теперь ряд функ­
циональных подсистем «питались» не от автономных информацион­
ных массивов данных, а от единого источника — базы данных.
 К тому же выяснилось:
1) необходимость разработки процедур использования результа­
тов задач, решенных в функциональных подсистемах;
2) потребность в изменении (реинжиниринге) существующей на
предприятии системы документооборота на основе проведенного
предпроектного обследования (инжиниринга).
К 90-м годам XX в. в нашей стране были созданы предпосылки
для методичного внедрения процедурного подхода.
Процедурное (процессное) построение предполагает наличие про­
цедур использования результатов решенных задач, при этом в качест­
ве элементов процедуры могут выступать как формальные процессы
(математическое решение задачи), так и неформальные процедуры с
участием ЛПР.
Распад СССР привел к резкому сокращению работ по АСУ, в том
числе и методического характера. «Вакуум» быстро заполнился копи­
рованием зарубежных разработок. При этом не обратили внимание
на то, что эти системы ориентированы на специфический документо­
оборот, особенно в сфере бухгалтерского учета (аудита). В результате
пропала ясность понимания и изложения как технологии работы та­
ких АСУ, так и методов их проектирования
Автоматизированное управление (в более узком смысле — корпо­
ративное управление) в настоящее время опирается на различные ин­
формационные технологии, так как, к сожалению, не существует
универсальной. Можно выделить следующие три группы методов
управления: ресурсами, процессами, корпоративными знаниями
(коммуникациями). Среди информационных технологий наиболее
часто используются СУБД, Workflow, стандарты ассоциации
Workflow Management Coalition, Intranet. На рис. 2.1 показаны место и
назначение каждой из информационных технологий [4, 20].
На рис. 2.2 интенсивность цвета соответствует степени поддерж­
ки информационными технологиями методов управления.
Задача управления ресурсами относится к числу классических ме­
тодик управления и является первой, где стали широко использовать­
ся информационные технологии. Это связано с наличием хорошо от­
работанных экономико-математических моделей, эффективно реа­
лизуемых средствами вычислительной техники. Рассмотрим эволю­
цию задач управления ресурсами.
Первоначально была разработана методология планирования
материальных ресурсов предприятия MRP (Material Requirements
Planning), которая использовалась с методологией объемно-кален­
дарного планирования MPS (Master Planning Shedule). Следующим
 Производство £

Стратегии
Системы и
Структуры
процедуры
Жесткие
ЭЛЕМ ЕНТЫ
Мягкие
Системы и Системы и
процедуры процедуры
Совместно4
разделяемые
. ценности >

здение коммуникаи'
Оперативные здания
Интранет

Рис. 2.1. Место и назначение информационных технологий

Ресурсы Процессы Коммуникации

знания
СУБД
Workflow
Интранет

Рис. 2.2. Степень поддержки информационными технологиями

методов управления

шагом было создание методологии планирования производственных

ресурсов (мощностей) — CRP (Capacitiy Requirements Planning). Эта
методология принципиально похожа на MRP, но ориентирована на
расчет производственных мощностей, а не материалов и компонен­
тов и требует больших вычислительных ресурсов даже на современ­
ном уровне.
Объединение указанных методологий привело к появлению задачи
MRP «второго уровня» MRP IT (Manufacturing Resource Planning) —
интегрированной методологии планирования, включающей MRP/CRP
и использующей MPS и FRP (Finance Resource/requirements
Planning) — планирование финансовых ресурсов. Далее была пред­
ложена концепция ERP (Economic Requirements Planning) — интег­
рированное планирование всех бизнес-ресурсов предприятия.
 Рис. 2.3. Соотношение между понятиями CSRP, ERP и стадиями жизненного
цикла товара

Эти методологии были поддержаны соответствующими инстру­

ментальными средствами. В большей степени к поддержке данных
методологий применимы СУБД.
Следующим шагом было создание концепции управления произ­
водственными ресурсами — CSRP (Customer Synchronized Resource
Planning) — планирование ресурсов, синхронизированное с потреб­
лением. Отличием данной концепции является учет вспомогатель­
ных ресурсов, связанных с маркетингом, продажей и послепродаж­
ным обслуживанием. На рис. 2.3 показано соотношение между поня­
тиями CSRP, ERP и стадиями жизненного цикла товара.
В связи с тем, что в современном производстве задействовано
множество поставщиков и покупателей, появилась новая концепция
логистических цепочек (Supply Chain). Суть этой концепции состоит
в учете при анализе хозяйственной деятельности всей цепочки (сети)
превращения товара из сырья в готовое изделие (рис. 2.4).
Логистическая цепочка

3-2742
 Поставщики Покупатели

Рис. 2.5. Идея виртуального бизнеса

При этом акцент сделан на следующие факторы:

• стоимость товара формируется на протяжении всей логистиче­
ской цепочки, но определяющей является стадия продажи конеч­
ному потребителю;
• на стоимости товара критическим образом сказывается общая
эффективность всех операций;
• наиболее управляемыми являются начальные стадии производ­
ства товара, а наиболее чувствительными — конечные (продажные).
Дальнейшим развитием концепции логистических цепочек явля­
ется идея виртуального бизнеса (рис. 2.5), представляющего распре­
деленную систему нескольких компаний и охватывающего полный
жизненный цикл товара, или разделение одной компании на не­
сколько «виртуальных бизнесов».
В настоящее время в автоматизированном управлении широко
используется бизнес-процессный подход.
Бизнес-процесс [ 19] —множество из одной или нескольких связан­
ных операций или процедур, в совокупности реализующих некото­
рую цель производственной деятельности, осуществляемое обычно в
рамках заранее определенной структуры, которая описывает функ­
циональные роли участников этой структуры и отношения межау
ними.
Бизнес-функция (функциональная роль) — набор элементарных
предписаний, которые могут быть привязаны ко времени или иметь
другие условия запуска. Для компьютера — это программа, для чело­
века — инструкция.
Бизнес-процесс может иметь иерархическую структуру и образует
бизнес-модуль, который является самодостаточным. В соответствии
с определением бизнес-процесса участники бизнес-модуля как
структурной единицы выполняют определенные функции, связан­
ные с управлением потоками ресурсов (материальных, трудовых,
оборудования).
В бизнес-модуле один работающий выполняет обычно несколько
функций. Это позволяет снизить количество уровней организацион­
ной структуры, сделав ее более «плоской». В то же время структура са­
мих процессов (планирования и управления) остается многоуровне­
вой. Таким образом, бизнес-процесс определяет упорядоченный на­
бор процессов или задач (в терминах традиционных АСУ).
Основной недостаток ERP-систем заключается в том, что плани­
рование выполняется, а исполнение реализуется только внутри одно­
го блока, хотя бы и очень большого (например, MRP II). Дальнейшее
развитие автоматизированного управления связано с появлением в
середине 90-х годов XX в. новых идей интегрированного управления,
направленных на информационное обеспечение всей цепочки про­
цессов жизненного цикла изделия. Стандарты ИСО 9000 предписы­
вают не только функциональный контроль и «прослеживаемость» на
протяжении всего жизненного цикла, но и управление полной себе­
стоимостью продукции, с учетом затрат функционального жизненно­
го цикла. Решения, предназначенные для поддержки функциональ­
ного жизненного цикла, получили название PLM (Product Lifecycle
Management — управление жизненным циклом). Основное различие
между PLM и ERP заключается в том, что PLM-системы ориентиро­
ваны на определение изделия, а ERP-системы — на управление про­
изводственными процессами.
Для удобства изучения представленного материала ниже приведе­
ны основные сокращения, используемые в современном подходе к
автоматизированному управлению.
• HRM (Human Resource Management) — управление персона­
лом;
• MRP (Material Requirements Planning) — планирование потреб­
ности в материалах;
• MRP II (Manufacturing Resource Planning) — планирование про­
изводственных ресурсов;
• MES (Management Execution System) — система управления ис­
полнением (производственных заданий), или система диспетчерова-
ния;
• CRP (Capacity Requirements Planning) — планирование потреб­
ности в производственных мощностях;
• PLM (Product Lifecycle Management) — управление жизненным
циклом;
 • EAM (Enterprise Assets Management) — управление бизнес-ак-
тивами;
• CSRP (Customer Synchronized Resource Planning) — планирова­
ние ресурсов, синхронизированное с потребителями;
• COMMS (Customer oriented manufacturing management
system) — система управления производством, ориентированная на
покупателя;
• PRM (Partnership Relation Management) — управление отноше­
ниями с партнерами;
• SCP (Supply Chain Planning) — планирование логистических
цепочек;
• SCM (Supply Chain Management) — управление логистически­
ми цепочками;
• SCE (Supply Chain Execution) — исполнение логистических
транзакций;
• SCEM (Supply Chain Event Management) — управление собы­
тиями в логистической цепочке.
Рассмотренные выше методологии нашли проявление как в от­
дельных программных продуктах, так и в рамках Интранета как инст­
румента корпоративного управления.
Интранет представляет собой технологию управления корпора­
тивными коммуникациями в отличие от Интернета, являющегося
технологией глобальных коммуникаций. В телекоммуникационных
технологиях выделяют три уровня реализации: аппаратный, про­
граммный и информационный. С этой точки зрения Интранет отли­
чается от Интернета только информационными аспектами, где выде­
ляются три уровня: универсальный язык представления корпоратив­
ных знаний, модели представления, фактические знания.
Универсальный язык представления корпоративных знаний не за­
висит от конкретной предметной области и определяет грамматику и
синтаксис. На данном этапе не существует единого языка описания и
к этой категории могут быть отнесены графические языки описания
моделей данных, сетевых графиков, алгоритмов и др. Задачей универ­
сального языка представления корпоративных знаний являются уни­
фикация представления знаний, однозначное толкование знаний,
разбиение процессов обработки знаний на простые процедуры, до­
пускающие автоматизацию.
Модели представления определяют специфику деятельности орга­
низации. Знания этого уровня являются метаданными, описываю­
щими первичные данные.
 Фактические знания отображают конкретные предметные области
и являются первичными данными.
Интранет дает ощутимый экономический эффект в деятельности
организации, что связано в первую очередь с резким улучшением ка­
чества потребления информации и ее прямым влиянием на произ­
водственный процесс. Для информационной системы организации
ключевыми становятся понятия «публикация информации», «потре­
бители информации», «представление информации».

2 .2. ПОДСИСТЕМНЫЙ ПОДХОД

К АВТОМАТИЗИРОВАННОМУ УПРАВЛЕНИЮ

Наиболее ярко подсистемный подход к автоматизированному

управлению можно проследить на примере АСУП. Подавляющее
большинство АСУП, в которых применялось подсистемное пред­
ставление, использовали информационно-поисковый режим (ИПР).
Такой режим назывался автоматизацией документооборота. Его
цель — трансформировать с помощью компьютера одну систему
входных документов в другую, удобную для пользователя. И ПРхоро-
шо обеспечен методически (ОРРМ, ГОСТ).
Для демонстрации подсистемного подхода рассмотрим подроб­
нее объект управления (см. рис. 1.2) как систему преобразования ре­
сурсов в продукты и «развернем» его совместно со схемой управляю­
щей части (см. рис. 1.3), при этом получим схему, приведенную на
рис. 2.6. Эта схема строится в таком порядке.
Первоначально в объекте управления формируется технологиче­
ская линия материальных ресурсов. Далее к ней добавляются осталь­
ные виды ресурсных сетей из рис. 1.2. Очевидно, что сформирован­
ный объект управления работает нормально, если на него не действу­
ют возмущения.
Компенсация возмущений осуществляется на нижнем уровне
структуры управляющей части (УЧ) системы. Согласование работы
элементов нижнего уровня проводится на уровнях диспетчера и руко­
водства.
Из рис. 2.6 можно сделать следующие выводы.
1. Для удобства управления ОУ и УЧ разделяют на связанные эле­
менты.
2. Отдельные элементы ОУ и соответствующие им элементы УЧ
образуют локальные системы управления с рассматриваемой ранее
простейшей структурой. Эти системы при ручном управлении назы-
 |2
«Я
S -йр а*з 3**
о -5S Й
S®
о я. Чо
С S

t
о
>>
к О
и
О

Л
ь
ю
О о

3
о,
о
о
в
X
S
о
с
m
н
с _
g
о
Р1
u s
S со 3я 5Й * я
о g
£5 хо
5а У2 ё Яa вs
л з ! | «о
LZZTlJ ж
ls .8
L_____
§s
р£ к
S К
о . о.
5О Ер >.
to
w
с а

ч I5
OI D 5 йз s3
О i;g«X *
о !& gаз ко
О О * о°
н
S На
Рис. 2.6. Предприятие как система управления:
ТЭП — технико-экономическое планирование; Т П П — техническая подготовка производства;
БУ — бухгалтерский учет; ОУОП — оперативное управление основным производством; МТС —
материально-техническое снабжение; О ГК — отдел главного конструктора; ОГТ — отдел главного
технолога; ОМ — отдел маркетинга
 Рис. 2.7. Укрупненная схема связей функциональных подсистем при плановых
отношениях

Рис. 2.8. Укрупненная схема связей функциональных подсистем при рыночных

отношениях

вают службами, при автоматизированном — функциональными под­

системами.
Функциональная подсистема — часть системы, выделенная по не­
формальному признаку.
3. Структура УЧ предприятия является многоуровневой (иерархи­
ческой).
4. Система управления в целом и локальные системы управления
характеризуются целенаправленностью, проявляющейся в цели
функционирования («экономическом интересе»), формальное выра­
жение которого может быть представлено ограничениями и/или це­
левыми функциями.
Из рис. 2.6 видно, что возможно построить схему связей подсис­
тем для плановых (рис. 2.7) отношений. Подсистемное представле­
ние первоначально использовалось и для рыночных отношений (рис.
2.8). Его схема представляет собой некоторую трансформацию схе­
мы, приведенной на рис. 2.7.
В каждой функциональной подсистеме выделяется система свя­
занных задач (рис. 2.9). В любой функциональной подсистеме воз­
можно выделить формальную часть (персональный компьютер) и не­
формальную часть (ЛПР). Формальная часть может быть описана не-
 ЛХ) Y
ПК х ' | ЛПР
Y=F(X) a

в
Рис. 2.9. Состав функциональных подсистем: соотношение формальной и не­
формальной частей (а), алгоритм подсистемы (б), задачи АСУП и их связь (в)

задач задачи
Рис. 2.10. Схема решения задачи

которым укрупненным векторным алгоритмом Y = F(X), где Y и X —

векторы входных и выходных данных. Алгоритм — правило преобра­
зования входной информации в выходную.
Размерности векторов X и Y значительны в любой подсистеме.
Реализация, равно как и использование в процессе эксплуатации
АСУП, такого алгоритма неудобна. В связи с этим алгоритм F подсис­
темы делят на связанные части, которые носят название задач АСУП.
Схема решения любой задачи может быть представлена в виде,
показанном на рис. 2.10.
Задача АСУП — часть алгоритма функциональной подсистемы,
выделенная по неформальному признаку и рассматриваемая относи­
тельно самостоятельно.
 пэо
I______
Расчет Расчет Расчет Расчет Расчет
плана про­ производ­ плана количества фонда
изводства ственных реализации основных зарплаты
мощностей рабочих
ОМТС
ZT

10
Расчет Расчет Расчет Расчет Расчет
потребности себесто­ амортиза­ оптовых плана по при­
в материалах имости ционных цен были и рента­
отчислений бельности
т
[r e j |jn J jjn J Ijn J JjTfsJ jjn J [jre J [j m J jjTloJ |^T5j
Рис. 2.11. Функциональная схема подсистемы ТЭП:
ОМ ТС — отдел материально-технического снабжения; ПЭО — планово-экономический отдел

База данных

Изделия План

Шифр_и Дата

Название и
Ед_изм_и

Материалы Нормы
Ш иф рм m
Ш иф рм

Ш иф ри
Название м
Ед_изм_м Норма
Цена_м

Потребность
в материалах
Рис. 2.12. Фрагмент информационной модели подсистемы

РОССИЙСКАЯ
ГОСУДАРСТВЕННАЯ
БИБЛИОТЕКА
___________ 2006
Рис. 2.13. Технология функционирования автоматизированной системы (плановые отношения) при подсистемном пред­
ставлении:
связи сплош ными линиям и — связи по задачам, пунктирными линиям и — связи подан н ы м ; КТБД — конструкторско-технологическая база дан ­
ных; А — продукция новая
Рис. 2.14. Технология функционирования автоматизированной системы (рыночные отношения) при подсистемном пред­
ставлении:
связи сплош ными линиям и — связи по задачам, пунктирными линиям и — связи по данным
 Схема связей задач для подсистемы ТЭП показана на рис. 2.11,
данные для задач размещены в базе данных (БД) (рис. 2.12). Нетрудно
видеть, что схемы связей всех задач подсистем определяют техноло­
гию работ АСУП в целом (рис. 2.13, 2.14).
Перечисленные существенные недостатки вызвали появление ра­
бот по совершенствованию автоматизированных систем и привели к
созданию процедурного представления. Один недостаток попыта­
лись устранить созданием ERP-стандарта (ERP-системы). Остальные
недостатки удалось в значительной мере устранить после введения
системы стандартов Quality Management System (QMS), включающей
стандарты ISO 9000 - ISO 9004 (ИСО 9000 - ИСО 9004 в русской
транскрипции).
Изменилась и терминология. Автоматизированные системы ста­
ли называть корпоративными информационными системами (КИС).
КИС — информационная система, поддерживающая оперативный и
управленческий учет на предприятии и поставляющая информацию
для принятия управленческих решений.

2 .3 .ПРОЦЕДУРНОЕ ПРЕДСТАВЛЕНИЕ

Основу процедурного представления составляют следующие ком­

поненты:
• ERP-стандарт;
• международный стандарт QMS;
• упорядочение решения задач;
• «плоская» структура управления;
• реинжиниринг;
• схематика и компьютерная поддержка представления.
ERP-стандарт предназначен для стандартизации вычислительных
работ (рис. 2.15) и охватывает лишь часть автоматизированной систе­
мы, как это показано в подсистемном представлении на рис. 2.16. Эту
часть в последнее время называют производством.
Из сравнения рисунков 2.13 и 2.15 следует, что функциональная
структура в обоих представлениях совпадает. В то же время задачи
Рис. 2.16. Место ERP-системы в рамках корпоративной информационной (авто­
матизированной) системы:
А — продукция новая

(функции) перераспределены между разными элементами организа­

ционной структуры.
Второй предпосылкой процедурного представления послужило
создание системы стандартов QMS.
Под качеством понимается степень, с которой совокупность соб­
ственных характеристик (отличительных свойств) выполняет требо­
вания. Требование — потребность или ожидание, которое установлено
и является обязательным.
Основу «Системы менеджмента качества» составляют стандарты
ИСО 9000 — ИСО 9004, которые продублированы в России нацио­
нальными стандартами ГОСТ Р ИСО 9000:2001 — ГОСТ Р ИСО
9004:2001. Поскольку эти стандарты положены в основу любой совре­
менной организации, в число которых входит и промышленное про­
изводство, рассмотрим их суть более подробно.
Международные стандарты базируются на понятии «бизнес» —
деятельность, ориентированная на получение прибыли. Цель систе­
мы стандартов — определение и удовлетворение потребностей по­
требителей, обеспечение преимуществ в конкурентной борьбе.
 Использование рекомендаций стандартов влияет на доход и долю
рынка организации, оперативную реакцию на изменения внешней
среды. Под организацией понимается группа работников и необходи­
мых средств с распределением ответственности, полномочий и взаи­
моотношений. Частным случаем организации является промышлен­
ное производство.
Стандарты предоставляют возможность создавать ценности как
для организации, так и для потребителей. Средствами для этого слу­
жат оптимизация затрат и ресурсов, быстрота реакции на изменения
рынка введением свойства гибкости системы и построением цепи
процессов.
Под процессом понимается совокупность взаимосвязанных и
взаимодействующих видов деятельности, преобразующая входы в
выходы.
Процедура — установленный способ осуществления процесса.
Процессы, получившие в литературе название «бизнес-процес­
сов», рассматриваются с точки зрения добавленной стоимости и по­
стоянного улучшения процессов.
Постоянное улучшение — повторяющаяся деятельность по увели­
чению способности удовлетворять требования. Улучшение предпо­
лагает анализ существующего положения, формирование целей улуч­
шения, поиск и выполнение решений по улучшению, измерение,
анализ и проверку результатов выполнения.
Менеджмент — скоординированная деятельность по руководству
и управлению организацией. Система менеджмента качества (СМК) —
совокупность взаимосвязанных и взаимодействующих элементов для
разработки политики и целей, достижения целей в области качества.
Под удовлетворенностью потребителей понимается восприятие
потребителем степени удовлетворения их требований.
Рассмотрим сущность блоков модели, приведенной на рис. 2.17.
1. Процессы жизненного цикла — здесь осуществляются плани­
рование процессов, определение и анализ требований, проектирова­
ние и разработка продукции, закупки и поставки ресурсов, производ­
ство и обслуживание.
2. Измерения, анализ и улучшения — здесь предполагается оценка
качества управления за счет:
а) проверки (аудита) выполнения требований к СМК, т. е. к про­
цессам, распределению обязанностей;
б) анализа СМК (оценки результативности и эффективности). Ре­
зультативность — степень реализации запланированных результа-
 Постоянное улучшение системы
менеджмента качества

Потре­ А1 Ответственность Потре­

бители руководства бители

AI Менеджмент ^ И зм ерен и я, анализ

ресурсов и улучшения

Требо­ _УПроцессы жизненного Продук­ Удовлет­

вания цикла продукции ция ворен­
ность
Вход Выход

---------— деятельность, добавляющая ценность

-------- — поток информации

Рис. 2.17. Модель системы менеджмента качества

тов. Эффективность — связь между достигнутым результатом и ис­

пользованными ресурсами;
в) постоянного улучшения системы менеджмента качества;
г) предупреждающего действия, предпринимаемого для устране­
ния причины потенциального несоответствия и предотвращения воз­
никновения нежелательного события, и корректирующего действия,
предпринимаемого для устранения причины обнаруженного несоот­
ветствия и предотвращения повторного возникновения нежелатель­
ного события.
3. Ответственность руководства — обеспечение разработки поли­
тики и целей в области качества, которые должны быть ориентиром в
организации. Политика служит основой для разработки и анализа це­
лей, а цели должны быть согласованы с политикой. Высшее руково­
дство осуществляет анализ работы СМ К и обеспечение производства
необходимыми ресурсами.
4. Менеджмент ресурсов — определение и обеспечение необходи­
мыми ресурсами, подготовка квалифицированного персонала, под­
держка инфраструктуры, создание производственной среды (сово­
купность условий, в которых выполняется работа).
Иногда модель, приведенную на рис. 2.17, называют PDCA (по
именам Plan, Do, Check, Act блоков 4, 3, 2, 1 соответственно).
Работа СМК поддерживается системой документов (информаци­
ей на соответствующих носителях). Комплект документов называют
документацией.
 Выделяют документы об СМК, о применении СМ К к конкретной
продукции, документы-требования, документы-записи (с фиксацией
достигнутых результатов).
СМ К базируется на следующей системе основных принципов:
• ориентация на потребителя;
• лидерство руководителя;
• вовлечение работников;
• системный подход к менеджменту;
• постоянное улучшение;
• взаимовыгодные отношения с поставщиками;
• принятие решений, основанных на фактах;
• процедурный (процессный) подход: деятельностью и ресурсами
управляют как процессами.
Таким образом, можно сделать следующие выводы:
• определена сеть процессов, включающая всю деятельность
предприятия;
• для каждого процесса должен быть назначен владелец процесса;
• должна быть создана документация, регламентирующая про­
цессы (при этом степень детализации процессов и соответствующих
документов определяется принципом управленческой целесообраз­
ности);
• определены стратегические цели компании, показатели и кри­
терии их достижения; на основе этих показателей верхнего уровня
определены показатели процессов;
• каждый процесс должен управляться на основе требований про­
цессного подхода (т. е. должна быть внедрена система управления
процессами на основе цикла PDCA);
• процесс управления предприятием должен быть детально разра­
ботан, задокументирован и обязательно включать в себя функции по
стратегическому планированию и управлению на основе системы по­
казателей.
На рис. 2.18 показан подробнее рис. 2.17. На рис. 2.19 дана при­
вязка позиций стандарта ИСО 9000 к модели СМК. Заметим, что рис.
2.17 может быть представлен в виде блок-схемы (рис. 2.20), т. е. в виде
цикла управления. Это означает, что рассматривается цикл управле­
ния в целом, а не отдельные этапы (планирование, учет, контроль),
как это делалось при подсистемном представлении результатов реше­
ния задач на компьютере.
Из рис. 2.20 нетрудно видеть, что схема стандарта представляет
собой фактически схему цикла управления в целом (см. рис. 1.5), а не
 —границы процесса < К > —контроль продукта процесса

Рис. i2.18. Общая схема управления процессом

только «поставку» информации пользователю, как в ИПР. Иными

словами, ИСО 9000 представляет собой ИСР.
В соответствии с ИСО 9004:2000 организация должна определить
процессы, их последовательность, методы математического «запол­
нения» процессов математическими моделями, критерии эффектив­
ности процессов. В качестве критериев возможно использовать
функциональность (скорость обработки), потребность в ресурсах, те­
кущие и будущие требования к менеджменту, сравнение с лучшими
процессами и системами, взаимодействие потребителей и поставщи­
ков.
Основной идеей процедурного представления [11, 59] является
упорядочение задач, т. е. выстраивание их при решении в технологиче­
ские цепочки (бизнес-процессы), за которые есть ответственные и в
которых могут присутствовать задачи из разных подсистем (рис. 2.21).
Структурными элементами вместо подсистем становятся биз­
нес-процессы, а задачи АСУП — бизнес-функциями. Не имеется ус­
тановившегося понятия «бизнес-процесс». Более того, существует
свыше 15 определений бизнес-процессов. Для определенности вос­
пользуемся стандартом ИСО 9000.
 ВЫШЕСТОЯЩИЙ РУКОВОДИТЕЛЬ
5.6.3. Выходные 5.6.2. Входные
данные анализа 5.4. Планирование данные для анализа
5.5.Полномочия и взаимодействие
5.6.Анализ руководства

8.4. Данные от
поставщиков ВЛАДЕЛЕЦ ПРОЦЕССА
8.2.2.Внутренние аудиты
1.5.2. Корректирующие
1.5.3. Предупреждающие 8.4. Анализ данных
действия
8.2.1. Удовлетворенность
потребителя

7.1. Планирование 8.2.3. Мониторинг

6.2.Людские ресурсы
выпуска продукции процесса
6.3. Инфраструктура
6.4. Среда
-- -------- —■ г " ' 8.2.4 Мониторинг
Поставщик входов

продукта

7. Выпуск продукции
(технология процесса)

8.3.Управление
несоответствующим продуктом
Контроль продуктов
^чччччччЧчччч*; процесса
кБ рак!
 Рис. 2.19. Требования стандарта ИСО 9001:2000:
К — контроль продуктов процесса

Рис. 2.20. Цикл управления в соответствии с ИСО 9000

Рис. 2.21. Пример бизнес-процесса

Процесс — совокупность взаимосвязанных или взаимодействую­

щих видов деятельности, преобразующая «входы» в «выходы».
Бизнес-процесс — процесс, добавляющий стоимость.
Бизнес-функция (роль) — набор элементарных предписаний, ко­
торые могут быть привязаны ко времени или иметь другие условия за­
пуска. Для компьютера — это программа, для человека — инструк­
ция.
В соответствии с определением бизнес-процессы делятся на ос­
новные и вспомогательные (рис. 2.22). Основные бизнес-процессы
расположены по ходу технологического процесса и добавляют стои­
мость. Вспомогательные бизнес-процессы стоимости не добавляют, а
обеспечивают основные бизнес-процессы.
Отсутствует устоявшаяся система бизнес-процессов. Один вари­
ант структуры для процедурного представления показан на рис. 2.21,
второй — на рис. 2.23.
 Основные процессы Вспомогательные процессы

Управление
Аналитика финансами
внешней среды

Управление персоналом
Разработка стратегии (набор, обучение,
аттестация)

Маркетинг
внутреннего и Управление
внешнего рынков информационными
ресурсами

Разработка продукта
Управление природными
ресурсами (экология,-
охрана труда и т.д.)
Закупки сырья и
оборудования
Управление внешними
связями (PR,
общественность и т.д.)
Производство
продуктов

Управление развитием
Сбыт продукции и улучшением

Рис. 2.22. Пример выделения сети процессов для крупной организации

 Первоначальной задумкой процедур­ Руководитель
ного представления было использование
в производственных системах «плоской»
матричной структуры управления, приме­
нявшейся до сих пор в проектных учреж­
дениях (рис. 2.24). ----- — научные связи
Предполагается, что все процессы на ------ — связи подчинения
нижнем уровне (см. рис. 2.6) делятся меж­
ду ответственными (руководителями), ко­ Рис. 2.24. Матричная струк­
тура управления:
торые располагают и распоряжаются со­
ГКП — главный конструктор про­
ответствующими финансовыми ресурса­ екта; И — исполнитель
ми, что позволяет оперативнее реагиро­
вать на изменения внешней среды.
Величина ресурса определяется величиной приращения стоимости
соответствующих видов продукции.
Руководители нижнего уровня нанимают для правильного тече­
ния хода процессов диспетчеров, плановиков, руководство предпри­
ятия и других руководителей. В то же время руководители нижнего
уровня по административной линии подчиняются руководству.
Реализация такой организационной структуры встречает серьез­
ные затруднения не только у нас, но и за рубежом. Этим объясняется
отсутствие в литературе схем организационной структуры предпри­
ятия, которые скрываются под термином «ноу-хау» или «коммерче­
ская тайна». В России по-прежнему применяется иерархическая ор­
ганизационная структура.
Процедурное представление упрощает процедуру реинжини­
ринга.
Реинжиниринг — фундаментальное переосмысление и радикаль­
ное перепроектирование бизнес-процессов компаний для достиже­
ния коренных улучшений их деятельности: стоимости, качества, ус­
луг и темпов роста.
Для описания бизнес-процессов используют графическую схема­
тику — нотации стандартов IDEF и ARIS.
Управление

Вход Фун кциональный Выход

блок

Механизм
USED АТ: AUTHOR: Иванов П.И. DATE: 18.05.2002 1 WORKING READER DATE CONTEXT
PROJECT: Пример модели REV: 24.02.2003 DRAFT
бизнес-процесса RECOMMENDED
NOTES: 1 2 3 4 5 6 7 8 9 10 PUBLICATION. A-0
Порядок подготовки документа А
Заполненные
подразделениями Запрос на уточнение
формы информации
Собрать и
проверить Проверенные
информацию формы Указание начальника отдела на
А1 доработку проекта документа А
£ Проект
Обработать документа А Указание руководителя на
полученную доработку проекта документа А
информацию
А2
Выполнить
анализ проекта
документа А Проект
АЗ документа
Замечания А
начальника отдела
Согласовать
и утвердить Документ А
Замечания документ А
руководителя А4

Начальник Руководитель
Экономист отдела
NODE: TITLE: Бизнес-процесс подготовки документа А NUMBER:
АО Р-1
 Стандарт IDEF (Icam DEFinition) насчитывает более десяти вари­
антов, из которых наиболее часто используются IDEFO, IDEF1,
IDEF3.
Модель IDEF0 предназначена для построения функциональных
моделей. Их построение возможно представить четырьмя позиция­
ми.
1. В качестве элемента модели используется функциональный
блок (рис. 2.25). Связи могут быть горизонтальными и вертикальны­
ми (декомпозиция).
2. Элементы соединяются дугами (обычно сплошной линией со
стрелкой). Пунктирными дугами показывают комментарии, а дугами
с двойной стрелкой — потоки. Число блоков на одном уровне от трех
до шести, число дуг каждого вида у блока не более четырех. Пример
модели второго уровня приведен на рис. 2.26.
3. По вертикали производится декомпозиция блоков. Блок самого
верхнего уровня называют контекстной диаграммой. Число уров­
ней — не более семи.
4. Для пояснения модели создается глоссарий, включающий не­
обходимые определения и ключевые слова.
Недостатком IDEF0 является завуалированная привязка процес­
сов к исполнителям через вход «Механизм».
1DEF3 является стандартом документирования технологических
процессов в производстве и управлении. Последовательность про­
цессов называют сценарием.
Данная модель — фактически граф с узлами и дугами. В зависи­
мости оттого, что приписывается узлам и дугам, возникает две разно­
видности моделей.
Если процессы — узлы, а связи — дуги, то получается диаграмма
описания потоков процесса PFDD (Process Flow Description
Diagram), показанная на рис. 2.27, 2.28. В этом случае используются
обозначения логических операций, приведенных в табл. 2.1.
Если процессы — дуги, а связи приписаны узлам, то получается
сеть изменения состояния объекта OSTN (Object State Transition
Network), представленная на рис. 2.29.
ARIS (ARchitecture of integrated Information System) — это и мето­
дология проектирования бизнес-процессов со своей нотацией, и се-
USED АТ: AUTHOR: Иванов П.И.
PROJECT: Пример модели
DATE: 18.05.2002
REV: 24.02.2003
■ WORKING
DRAFT
READER DATE CONTEXT

бизнес-процесса C=1
RECOMMENDED cm
NOTES: 1 2 3 4 5 6 7 8 9 10 PUBLICATION A l.l ^

NODE: TITLE: Собрать и проверить информацию NUMBER:

A l.l P -l

Рис. 2.27. Модель IDEF3

 Рис. 2.28. Пример PFD D -диаграммы

иов/
Тестировать
иов/ слой краски
Окрасить 3/1
деталь
1/1

иов/
Высушить
деталь иов/
2/1 Тестировать
слой краски
3/1

Рис. 2.29. Пример OSTN-диаграммы

мейство программных продуктов, разработанных компанией IDS

Scheer AG (Германия).
Методология ARIS позволяет по сравнению с предыдущими но­
тациями строить более широкий спектр моделей. Модели в ARIS
классифицируются с помощью понятия «методологический фильтр».
При использовании простого фильтра возможно строить органи­
зационную схему, функциональную модель (дерево функций), мо­
дель данных (модель технических терминов), модель процессов
управления (событийная цепочка процесса, диаграмма окружения
функции, производственный и офисный процессы, диаграмма це­
почки добавленного качества).
 Смысл в случае Смысл в случае
Обозначе­ Наименование слияния стрелок
ние разветвления стрелок
(Fan-in-Junction) (Fan-oit-Junction)

Асинхронное Все предшествующие Все следующие

& AND процессы должны процессы должны
быть завершены быть завершены

Синхронное Все предшествующие Все следующие

& AND процессы завершены процессы запускаются
одновременно одновременно

Один или несколько Один или несколько

Асинхронное предшествующих следующих процессов
0 OR процессов должны должны быть
быть завершены запущены

Один или несколько Один или несколько

Синхронное предшествующих следующих процессов
0 OR процессов завершаются запускаются
одновременно одновременно

XOR Только один Только один

X (Исключительное предшествующий следующий процесс
OR) процесс завершен запускается

Таблица 2.2

Название модели Назначение модели

Диаграмма целей Описание целей организации и построе­
ние их иерархии
Диаграмма типа прикладной системы Моделирование прикладных информа­
ционных систем
Расширенная модель «сущность — связь» Описание данных
Диаграмма атрибутов предыдущей мо­ Описание атрибутов любого вида сущ­
дели ности
Диаграмма структуры знаний Моделирование процесса управления
знаниями
Диаграмма информационных потоков - Описание потоков информации между
функциями
Матрица процессов выбора Сценарии выполнения процесса
Карта знаний Отображение типов знаний, которыми
обладают служащие
Диаграмма цепочки процесса Отображение процесса
Диаграмма движения продуктов Маршруты движения продуктов
Дерево продуктов Состав продуктов
 Цель моделирования Используемые модели
Общее описание Диаграмма целей
определение целей Организационная схема
описание организационной структу­ Диаграмма цепочки добавленного каче­
ры ства
выделение и описание процессов Дерево функций
верхнего уровня Диаграмма цепочки процесса
описание функций и процессов Диаграмма окружения функции
документирование деятельности Офисный и производственный процес­
сы
Внедрение системы управления SAP R/3 Организационная схема
Дерево функций
Структурная модель SAP SERM «сущ­
ность — связь»
Диаграмма взаимодействий
Диаграмма окружения функции

Стандартный и расширенный методологические фильтры обла­

дают более широкими возможностями. Сюда входит построение
функциональной модели (диаграмма целей, диаграмма типа при­
кладной системы), модель данных (расширенная ER-диаграмма, диа­
грамма атрибутов ER, диаграмма структуры знаний), модель процес­
сов управления (диаграмма информационных потоков, матрица вы­
бора процессов, диаграмма в виде столбцов, карта знаний, диаграмма
цепочки процесса, диаграмма движения продуктов/услуг).
Имеется набор диаграмм на универсальном языке UML (Unified
Modeling Language): диаграммы действий, класса, описания класса,
взаимодействия компонентов, состояний, использования приложений.
Назначение ряда моделей стандартного и расширенного методо­
логических фильтров ARIS приведено в табл. 2.2.
Методология ARIS насчитывает большое количество моделей,
применение которых зависит от поставленной цели исследования. В
табл. 2.3 приведены рекомендации по выбору видов моделей.
Система моделей ARIS оперирует системой обозначений, приве­
денной в табл. 2.4. Для ARIS характерны следующие правила.
Каждая функция должна быть запущена событием и должна за­
канчиваться событием. В каждую функцию не может входить более
одной стрелки, запускающей выполнение функции, и выходить бо­
лее одной стрелки, описывающей завершение выполнения функции.
Для построения IDEF- и ARIS-нотаций используются программ­
ные продукты BPWin, ARIS.
 №
Наименование
Графическое
Описание
п/п представление
1 Функция Объект “Функция” служит для описания
функций (процедур, работ), выполняемых Function
подразделениями/сотрудниками предприятия V У

2 Событие Объект “Событие” служит для описания

реальных состояний системы, влияющих ^ Event )
и управляющих выполнением функций

3 Организаци­ Объект отражает различные организацион­

онная ные звенья предприятия (например, ( o ^ n iz a tio r ^ u ^ t)
единица управление или отдел)

4 Документ Объект отражает реальные носители инфор­ Document

мации, например бумажный документ

5 Прикладная Объект отражает реальную прикладную

система систему, используемую в рамках технологии Application system
выполнения функции

6 Кластер Объект характеризует данные, как набор

информации сущностей и связей между ними. Использу­ || Cluster
ется для создания моделей данных

7 Стрелка свя­ Объект описывает тип отношений между

зи между другими объектами, например активацию ---------- ►
объектами выполнения функции некоторым событием

8 Логическое Логический оператор, определяющий связи

И между событиями и функциями в рамках
процесса. Позволяет описать ветвление
процесса
©
9 Логическое Логический оператор, определяющий связи
ИЛИ между событиями и функциями в рамках
процесса. Позволяет описать ветвление
процесса
©
10 Логическое Логический оператор, определяющий связи
исключающее между событиями и функциями в рамках
ИЛИ процесса. Позволяет описать ветвление
процесса
®
Недостатком BPWin является отсутствие связей с программными
средствами (BAAN, SAP/R3), с помощью которых реализуется спро­
ектированное процедурное представление.
Рис. 2.30. Пример модели ARIS
 От этого недостатка свободен программный продукт ARIS. При­
мер модели ARIS приведен на рис. 2.30. ARIS предназначен для опи­
сания, анализа и совершенствования бизнес-процессов. Имеются
следующие разновидности программного продукта ARIS:
• ARIS Toolset — средство разработки и реинжиниринга биз­
нес-процессов;
• ARISABC — расчет стоимости выполнения бизнес-процессов;
• ARIS BSC — стратегическое управление компанией;
• ARIS for mysap.com — внедрение объектно-ориентированных
решений в SAP/R3 на основе решений;
• ARIS Process Perfomance Manager — анализ и оптимизация биз-
нес-процессов с помощью технологии OLAP;
• ARIS ProcessRisk Scout — анализ рисков выполнения биз­
нес-процессов;
• ARIS Redocumentation Scout — документирование бизнес-про­
цессов.
Программный продукт BPWin прост в использовании, но имеет
ограниченные функциональные возможности и целесообразен в
применении для малых и средних проектов. Приложение ARIS обла­
дает расширенными функциональными возможностями и удобен для
больших проектов.
Специфичными являются процедуры проектирования и адапта­
ции к изменениям параметров (спрос, ресурсное обеспечение) из­
менчивой внешней среды.
КОНТРОЛЬНЫЕ ВОПРОСЫ
1. Какие информационные технологии используют в информационном
управлении?
2. Поясните концепцию логистических цепочек.
3. В чем идея виртуального бизнеса?
4. Дайте определение бизнес-процесса и бизнес-функции.
5. Поясните назначение концепции PLM (управление жизненным циклом)
и укажите его составные части.
6. На каких принципах основана архитектура Интранет?
7. Укажите основные особенности подсистемного подхода.
8. Укажите достоинства и недостатки подсистемного подхода.
9. Что составляет основу процедурного представления?
10. Укажите основные недостатки подсистемного представления.
11. Какие компоненты являются основой процедурного представления?
12. Каково назначение ERP-стандарта?
13.На каких принципах базируется система менеджмента качества?
14. Какова основная идея процедурного подхода?
15. Дайте определение процесса, бизнес-процесса, бизнес-функции.
16. Что такое реинжиниринг?
17. Какие графические модели могут быть использованы для описания биз-
нес-процессов?
18. Каковы основные правила методологии AR1S?
 ГЛАВА 3
Модели автоматизированного управления

Несмотря на специфику конкретных объектов, удалось разработать модели

автоматизированного управления, что позволяет снизить затраты и сократить
сроки разработки систем управления. В данном разделе рассмотрены модели пла­
нирования материальных потребностей MRP (Material Requirement Planning),
планирования ресурсов предприятия ERP (Enterprise Resource Planning), управ­
ления жизненным циклом изделия PLM (Product Lifecycle Management), гибкого
автоматизированного завода, адаптивного автоматизированного управления.
Раскрывается содержание моделей, области применения.

3 .1 . МОДЕЛИ MRP/ERP

Модели MRP — ERP с момента возникновения развивались эво-

люционно. С целью оптимального управления производством в сере­
дине 60-х годов XX в. APICS сформулировало принципы управления
материальными запасами предприятия. Эти принципы легли в основу
концепции планирования материальных потребностей MRP
(Material Requirement Planning), основными положениями которой
являются:
• описание производственной деятельности как потока взаимо­
связанных заказов;
• учет ограничения ресурсов при выполнении заказов;
• обеспечение минимизации производственных циклов и запа­
сов;
• формирование заказов снабжения и производства на основе
реализации и производственных графиков;
• привязка движения заказов к экономическим показателям;
• завершение выполнения заказа к тому моменту, когда он необ­
ходим.
Развитие вычислительных средств и наличие концепции привели
к тому, что в 70-х годах стали появляться первые автоматизированные
системы, реализующие MRP-концепцию. Методика MRP деклари­
рует, какие процессы учета и управления должны быть реализованы
на предприятии, в какой последовательности они должны выпол­
няться, и содержит рекомендации о том, как они должны выпол­
няться.
Дальнейшее развитие концепции MRP шло по пути расширения
функциональных возможностей предприятия в сторону более полно­
го удовлетворения потребностей клиентов и снижения производст­
венных издержек. В результате в конце 70-х годов концепция MRP
была дополнена положениями о формировании производственной
программы в масштабах всего предприятия и контроля ее выполне­
ния на уровне подразделений (Closed Loop MRP или, другими слова­
ми, воспроизведение замкнутого цикла в MRP-системах). Следую­
щий шаг — появление концепции планирования производственных
ресурсов MRPII (Manufacturing Resource Planning), основным содер­
жанием которой стало прогнозирование, планирование и контроль
производства по всему циклу, начиная от закупки сырья и заканчивая
отгрузкой товара потребителю.
MRPII представляет собой методологию, направленную на эф­
фективное управление всеми ресурсами производственного пред­
приятия. В общем случае она обеспечивает решение задач планирова­
ния деятельности предприятия в натуральных единицах, финансовое
планирование в денежном выражении. Эта методология представля­
ет собой набор проверенных на практике принципов, моделей и про­
цедур управления и контроля, использование которых способствует
улучшению показателей экономической деятельности предприятия.
Стандарт APICS на системы класса MRPII содержит описание 16
групп функций системы:
1. Sales and Operation Planning — планирование продаж и произ­
водства. 4
2. Demand Management — управление спросом.
3. Master Production Scheduling — составление плана производства.
4. Material Requirement Planning — планирование материальных
потребностей.
5. Bill of Materials — спецификации продуктов.
6. Inventory Transaction Subsystem — управление складом.
7. Scheduled Receipts Subsystem — плановые поставки.
8. Shop Flow Control — управление на уровне производственного
цеха.
9. Capacity Requirement Planning — планирование потребностей в
мощностях.
10. Input/output control — контроль входа/выхода.
11. Purchasing — материально-техническое снабжение.
 12. Distribution Resource Planning — планирование ресурсов рас­
пределения.
13. Tooling Planning and Control — планирование и управление
инструментальными средствами.
14. Financial Planning — управление финансами.
15. Simulation — моделирование.
16. Performance Measurement — оценка результатов деятельности.
По мере накопления опыта моделирования производственных и
непроизводственных операций содержание этих групп уточняется,
постепенно охватывая все больше функций. При этом следует иметь в
виду, что перечисленный функциональный состав относится только
к управлению производственными ресурсами предприятия.
Стандарт MRPII делит сферы отдельных функций (процедур) на
два уровня: необходимый и опциональный. Для отнесения к классу
MRPII автоматизированные системы управления должны выполнять
определенный объем необходимых (основных) функций (процедур).
Состав функциональных модулей и их взаимосвязи имеют глубо­
кое обоснование с позиции теории управления. Они обеспечивают
интеграцию функций планирования и согласование различных про­
цессов управления во времени и пространстве. Представленный на­
бор модулей является не избыточным, что позволяет в основном со­
хранять его неизменным в системах следующих поколений. Более
того, многие понятия, методы и алгоритмы, заложенные в функцио­
нальные модули MRPII, остаются неизменным в течение длительно­
го времени и входят в качестве элементов в системы следующих поко­
лений. По этой причине методологию MRPII можно считать базовой.
Для каждого уровня планирования MRPII характерны такие па­
раметры, как степень детализации плана, горизонт планирования,
вид условий и ограничений. Эти параметры для одного и того же
уровня MRPI1 могут изменяться в широком диапазоне в зависимости
от свойств производственного процесса на предприятии. С другой
стороны, в зависимости от характера производственного процесса
возможно применение на каждом отдельном предприятии опреде­
ленного набора функциональных модулей MRPII. Таким образом,
MRPII является гибкой и многофункциональной системой, приме­
нение которой возможно в широком спектре условий.
Принадлежность АСУП к классу MRPII должна означать функ­
циональную поддержку программным обеспечением выполнения
следующего цикла: «планирование заказов —> планирование потреб­
ности в сырье и материалах -> планирование производственных ре­
сурсов -» контроль над исполнением производственной программы
-> обратная связь».
5 -2742 65
 Дадим краткую характеристику функциональным блокам MRPII.
Бизнес-планирование — процесс формирования плана предпри­
ятия наиболее высокого уровня; планирование долгосрочное, план
составляется в стоимостном выражении; наименее формализован­
ный процесс выработки решений.
Планирование спроса — процесс прогнозирования (планирова­
ния) спроса на определенный период.
Планирование продаж и производства — преобразование биз­
нес-плана и плана спроса в планы продаж основных видов продукции
(как правило, от 5 до 10). При этом производственные мощности мо­
гут не учитываться или учитываться укрупненно. План носит средне­
срочный характер. План продаж по видам продукции преобразуется в
объемный или объемно-календарный план производства видов про­
дукции. Под видом здесь понимаются семейства однородной продук­
ции. В этом плане впервые в качестве планово-учетных единиц вы­
ступают изделия, но представления о них носят усредненный харак­
тер. Например, речь может идти о всех моделях телевизоров с одина­
ковым размером экрана, выпускаемых на заводе (без уточнения
моделей). Часто этот модуль объединяется с предыдущим.
План-график выпуска продукции — преобразование плана произ­
водства в график выпуска продукции. Как правило, это среднесроч­
ный объемно-календарный план, задающий количества конкретных
изделий (или партий) со сроками их изготовления.
Планирование потребностей в материальных ресурсах — определе­
ние в ходе планирования в количественном выражении и по срокам
потребности в материальных ресурсах, необходимых для обеспече­
ния графика выпуска продукции. Входными данными для планиро­
вания потребностей в материалах являются спецификации изделий
(состав и количественные характеристики комплектующих конкрет­
ного изделия) и размер текущих материальных запасов.
Планирование производственных мощностей — выполнение расче­
тов по определению и сравнению располагаемых и потребных произ­
водственных мощностей. С наибольшими изменениями этот модуль
может применяться не только для производственных мощностей, но
и для других видов производственных ресурсов, способных повлиять
на пропускную способность предприятия. Обычно подобные расче­
ты производятся после формирования планов практически всех пре­
дыдущих уровней с целью повышения надежности системы планиро­
вания. Иногда решение данной задачи включают в модуль соответст­
вующего уровня. Входными данными при планировании производст­
венных мощностей являются также маршруты выпускаемых изделий.
 Управление заказами клиентов — сопоставление реальных потреб­
ностей клиентов с планами выпуска продукции.
Управление на уровне производственного цеха — формирование
оперативных планов-графиков. В качестве планово-учетных единиц
могут выступать детали (партии), сборочные единицы глубокого
уровня, детали-, партии-операции и т. п. Длительность планирова­
ния невелика (от нескольких дней до месяца).
Оценка исполнения — по сути, в данном модуле оценивается ре­
альное исполнение всех вышеперечисленных планов с тем, чтобы
внести корректировки во все предыдущие циклы планирования.
Связь между уровнями в MRPII обеспечивается универсальной
формулой, на которой строится система. Задача планирования на ка­
ждом уровне реализуется как ответ на четыре вопроса:
1) что необходимо выполнить?
2) что необходимо для этого?
3) что есть в наличии?
4) что необходимо иметь?
Ответом на первый вопрос всегда выступает план более высокого
уровня. Этим и обеспечивается связь между уровнями. Структура от­
ветов на последующие вопросы зависит от решаемой задачи.
Дальнейшее развитие систем MRPII связано с их перерастанием в
системы нового класса — «Планирование ресурсов предприятия»
(Enterprise Resource Planning — ERP). Системы этого класса ориенти­
рованы на работу с финансовой информацией для решения задач
управления большими корпорациями с территориально разнесенны­
ми ресурсами. Сюда включается все необходимое для получения ре­
сурсов, изготовления продукции, ее транспортировки и расчетов по
заказам клиентов. Помимо перечисленных функциональных требо­
ваний к системам ERP предъявляются и новые требования по приме­
нению графики, использованию реляционных баз данных, CASE-тех-
нологий для их развития, архитектуры вычислительных систем типа
«клиент — сервер» и реализации их как открытых систем. Системы
этого класса активно развиваются с конца 80-х годов XX в.
Следует отметить, что подход к решению задач планирования
производства в системах ERP до недавнего времени оставался в ос­
новном неизменным, т. е. в том виде, в каком он утвердился в систе­
мах MRPII. Коротко его можно определить как подход, базирующий­
ся на активном применении календарно-плановых нормативов на
производственные циклы. Недостаток такого подхода состоит в том,
что он вступает в противоречие с необходимостью оптимизации пла­
нирования. Элементы оптимизации планирования в традиционных
системах M RPII/ERP встречаются только на нижнем уровне — при
решении задач оперативного планирования с применением методов
теории расписаний. С ростом мощностей вычислительных систем,
внедрением M RPII/ERP, поиском новых более эффективных мето­
дов управления в условиях конкуренции с середины 90-х годов на
базе систем M RPII/ERP появляются системы нового класса, которые
получили название «Развитые системы планирования» (Advanced
Planning/Scheduling — APS). Для этих систем характерно применение
экономико-математических методов при решении задач планирова­
ния с постепенным снижением роли календарно-плановых нормати­
вов на производственные циклы.
Рост производительности и снижение незавершенного производ­
ства за учет внедрения таких систем объясняется тем, что при опреде­
лении длительности производственного цикла в него не закладывает­
ся заранее усредненное время пребывания сырья в очередях. Данный
подход особенно эффективен для сложного многономенклатурного
производства, в то же время он требует существенного повышения
профессионального уровня управленческого персонала.
Следующее направление в развитии автоматизации управления
предприятиями состоит в интеграции систем M RPII/ERP с другими
автоматизированными системами, имеющимися на предприятиях. В
их числе — системы CAD/CAM, управления технологическими про­
цессами и системами, системы финансовой отчетности и т. п. Систе­
мы такого класса получили название «Компьютерные интегрирован­
ные системы» (Computer Integrated Manufacturing — CIM). Эти систе­
мы используются с 90-х годов XX в.
Таким образом, система MRPII постоянно эволюционирует и со­
вершенствуется. В каждый момент времени в концепциях
M RPII/ERP можно выделить условно три слоя.
В первом слое находятся те методы и средства, которые провере­
ны практикой и закреплены в виде стандартов.
Второй слой составляют достаточно устойчивые, часто применяе­
мые методы и приемы, которые, однако, не носят обязательного ха­
рактера. Их можно обнаружить при более глубоком анализе функ­
циональных структур. В качестве примеров можно привести методо­
логию скользящего планирования в MPS/MRP, алгоритмы образова­
ния партий в MRP, правила приоритетов в SFC и др. Этот слой,
жестко не регламентируемый, тем не менее представляет собой до­
вольно стройную систему взаимосвязанных идей и методов.
К третьему слою идей и методов M RPII/ERP следует отнести то
новое, что вносят в свои базовые системы фирмы—производители
программных продуктов. Реализованные на их основе новые инфор­
мационные технологии представляют собой «ноу-хау» фирм-разра-
ботчиков. Как правило, именно в этом слое можно обнаружить зна­
чительные отличия в продуктах различных фирм. Некоторые из но­
вых технологий в состоянии оказывать серьезное влияние на эффек­
тивность построения крупных информационных систем.
Видное место среди идей и методов систем M RPII/ERP принад­
лежит специально разработанным методикам внедрения систем.
Анализ литературы показывает, что на Западе сложилось устойчивое
представление о том, в какой последовательности и какими методами
следует внедрять системы типа M RPII/ERP. Тщательное планирова­
ние проектов по внедрению, организация деятельности коллективов,
упор на переподготовку персонала всех уровней (особенно высше­
го) — вот далеко не полный перечень условий достижения положи­
тельных результатов. Наличие мощной инфраструктуры и методоло­
гии построения систем способствовало в итоге достижению высокого
уровня эффективности при внедрении систем управления типа
M RPII/ERP на промышленных предприятиях. По некоторым оцен­
кам, внедрение подобных систем способно привести к сокращению
запасов на 8—30 %, росту производительности труда на 8—27 %, воз­
растанию количества заказов, выполненных в срок, на 7—20 %.
Дальнейшим развитием моделей M RPII/ERP являются архитекту­
ры, ориентированные на сервисы (service oriental architecture — SOA) и
сервисы бизнес-приложения (service oriental business application —
SOBA). Развитие этих направлений связано с тем, что существенным
недостатком ERP является отраслевая специфика [24]. MRPII, слу­
жащая основой для многих ERP,— это методология планирования
дискретных, большей частью машиностроительных производств. Ряд
факторов привел к многочисленным неудачным попыткам внедре­
ния подобных систем на других производствах и к проблеме адапта­
ции программного продукта под конкретное производство. Ситуа­
цию усугубило распространение таких методологий планирования,
как заказное производство, гибкое производство (agile manufacturing)
и «экономичное производство» (lean manufacturing). Таким образом,
возникла проблема гибкости и универсальности интерфейса управ­
ления производством.
В основе идеологии SOA — интеграция множественных, одовре-
менно работающих разных предприятий, территориально разнесен­
ных бизнес-приложений. Это могут быть как вновь внедряемые, так и
унаследованные, в том числе традиционные ERP-системы. В опреде­
ленном плане появление SOA — возврат к идеологии мэйнфреймов,
но на другом качественном уровне. Если мэйнфреймы объединяли
вычислительные ресурсы, то SOA объединяют и позволяют использо­
вать данные и приложения.
 3 .2 . МОДЕЛИ PLM

В настоящее время остро стоит проблема перехода от использова­

ния отдельных информационных технологий к созданию единых ин­
тегрированных комплексов. Одним из направлений являются модели
PLM (Product Lifecycle Management — управление жизненным цик­
лом изделия).
Появление PLM связано с развитием электронного бизнеса, клас­
сификация которого, предложенная компанией Gartner Group [57],
представлена на рис. 3.1. Выделено четыре фазы развития: присутст­
вие, взаимодействие, передача данных (транзакции) и трансформа­
ция бизнеса. Начиная с 2000 г. активно развиваются третья и четвер­
тая фазы. Другая классификация, предложенная Дэйвом Фишером,
основана на использовании данных и развитии электронного бизнеса
и рассматривается как восхождение от простого обмена данными к
обеспечению средствами технологий потоков работ и потоков приня­
тия решений (рис. 3.2).
Бурное развитие PLM прослеживается в следующем. Современ­
ный бизнес решает триединую задачу: во-первых, необходимо уста­
навливать более тесные и доверительные отношения с поставщиками
и заказчиками, во-вторых, повышать уровень собственной операци­
онной эффективности и, в-третьих, повышать конкурентоспособ­
ность выпускаемой продукции. Первая составляющая обеспечивает­
ся системами поддержки отношений, получающими все большее рас-
2000-2005 гг.
Т рансформация
1998-2003 гг. бизнеса
Обмен Общие плат­
транзакциями формы для
выполнения
Электронная приложений.
1997-2000 гг.
коммерция, Предприятие
Взаимодействие
системы ERP, реального вре­
SCM мени.Усиление
1996-1999 гг. Персонализиро­
Присутствие ванное персонализации
интерактивное
Публикация взаимодействие
маркетинговых
материалов
 Четвертое поколение:
“Поток решений управляет пото­
ком работ, который, в свою оче­
редь, управляет потоком данных”
Третье поколение: “Поток работ
управляет потоком данных”

Второе поколение: “Поток данных

управляет потоком работ”
Первое поколение:
“Передача данных”

Ш Поток решений (DecisionFlow)

□ Поток работ (Workflow) □ Поток данных (Dataflow)

Рис. 3.2. Поколения электронного бизнеса

пространение, такими как системы SCM (Supply Chain Management —

управления цепочками поставок) и CRM (Customer Relations
Management — управления отношениями с заказчиками), вторая —
еще более популярными системами ERP, а вот третья пока не имеет
достаточного комплексного информационного обеспечения. На то,
чтобы занять это место, претендует подход, названный «new PLM».
Он заметно отличается от традиционного представления о том, чтб
такое управление жизненным циклом изделий. Раньше под PLM (в
узком смысле) чаще всего понимали то, что имело отношение к жиз­
ненному циклу материальных изделий, начиная от запуска в произ­
водство, регулирования объемов выпуска, определения времени вы­
пуска новых или обновленных изделий и, конечно же, сопровожде­
ние и сервис. Изменения в видении роли и места PLM произошли в
последние несколько лет. Теперь под этим термином понимают авто­
матизацию практически всех видов работ, которые составляет основу
выпуска продукции — от проектирования до сбыта. Разные авторы
расходятся в определениях; одни включают SCM, CRM и ERP в со­
став нового управления жизненным циклом изделий, другие [57] счи­
тают эти системы взаимодополняющими (рис. 3.3).
В соответствии с триединой задачей «new PLM» можно разделить
на три взаимосвязанных составляющих управления жизненным цик­
лом:
• жизненный цикл определения изделий (интеллектуальные ак­
тивы предприятия);
• жизненный цикл производства (материальные активы предпри­
ятия);
• жизненный цикл операционной поддержки.
 Разработка
изделий

.уШЫЙ цикл
Поддержка,
сервис и Производство
использование продуктов
изделий Взаимодействие
и интеграция

Г ^ ^ ный цикл

Маркетинг
и продажи

CRM
Клиенты Поставщики

Рис. 3.3. Взаимосвязь корпоративных приложений

Первичным является жизненный цикл управления интеллекту­

альными активами; он начинается с оценки пользовательских требо­
ваний, выработки концепции продукта, а завершается, когда пред­
приятие полностью отказывается от продукта, в том числе и от его
сервисной поддержки.
PLM-решения — один из самых быстрорастущих и перспектив­
ных сегментов рынка информационных технологий (ИТ-услуг), что в
значительной степени связано со способностью PLM-приложений
существенно сокращать расходы на проектирование и ускорять тем­
пы выпуска продуктов на рынок. В числе факторов, способствующих
принятию решений об использовании услуг PLM, — высокий уро­
вень использования информационных технологий в производстве,
сложность производственных процессов, а также разобщенность
подразделений предприятия, ответственных за конструирование,
производство, сбыт и обслуживание продуктов.
Одно из наиболее полных определений PLM [57] состоит из четы­
рех пунктов:
• стратегический подход к бизнесу, предлагающий непрерывный
набор бизнес-решений, который поддерживает режим сотрудничест­
ва создания, управления, распределения и использования определе­
ния изделий (интеллектуальных активов предприятия);
 • поддержка «расширенного представления о предприятии»
(extended enterprise), в том числе поддержка процессоров проектиро­
вания, пользователей и партнеров;
• действие во времени от момента рождения концепции изделия
до снятия его с производства и окончания сервисного периода;
• интеграция людей, процессов, систем и информации.
Важно подчеркнуть, что в этом определении PLM рассматривает­
ся не как часть или части технологий, а как бизнес-подход, цель кото­
рого состоит в поиске ответов на вопросы «как работает бизнес?» и
«что создается?»
На основании этого определения выделяются три основные кон­
цепции PLM:
• возможность универсального, безопасного и управляемого спо­
соба доступа и использования информации, определяющей изделия;
• поддержание целостности информации, определяющей изде­
лие, на протяжении всего жизненного цикла изделия;
• управление и поддержка бизнес-процессов, используемых при
создании, распределении и использовании подобной информации.
Концепция PLM охватывает все этапы жизненного цикла изделия
(рис. 3.4) и подразумевает управление данными, получаемыми от сле­
дующих компонентов:
• PDM (Product Data Management) — управление данными об из­
делиях;
• САМ (Computer-Aided Manufacturing) — система автоматизиро­
ванной подготовки производства;
• CAE (Computer-Aided Engineering) — система автоматизиро­
ванного инженерного анализа;
• CAD (Computer-Aided Design) — система автоматизированного
проектирования;
• МРМ (Manufacturing Process Management) — планирование и
моделирование производства с использованием обрабатывающих
центров с ЧПУ, роботов и т. п.;
 • BOM (Bill of material Management) — инженерная специфика­
ция;
• CRM (Customer Relationship Management) — управление отно­
шениями с клиентами.
Одним из важнейших компонентов PLM является система управ­
ления данными об изделии (PDM), обеспечивающая обмен данными
о составе изделия и вносимых в него изменениях и позволяющая соз­
давать и поддерживать множество взаимосвязанных спецификаций
изделия, благодаря чему пользователь получает согласованное пред­
ставление о составе изделия по ходу работы над ним.
Система PDM должна реализовывать следующие функции.
1. Функция управления составом изделия, которая может быть
представлена совокупностью следующих возможностей: ведение спе­
цификаций; многоуровневые спецификации, отображающие как де­
рево сборки изделия, так и полный набор конструкторских, техноло­
гических и прочих атрибутов; динамический просмотр иерархически
организованной информации; отслеживание принадлежности каж­
дой детали, сборки, узла изделия модельному ряду; определение ус­
ловий применимости и отображение ограничений применимости;
ведение протоколов изменения версий вплоть до версий каждой дета­
ли; отслеживание действия внесенных изменений и модификаций.
2. Функция отслеживания ссылок на документы электронного ар­
хива, соответствующих каждой детали, сборке, узлу, изделию. Полу­
чение данных непосредственно из электронного архива или непо­
средственно из САПР сборок.
3. Функция сравнения структур изделий, сопровождение и обслу­
живание информации об изделии с учетом специфики различных
подразделений, включая предприятия-соисполнители (поставщики
комплектующих, субподрядчики) и внешние торговые площадки.
4. Дополнительные сервисные функции представления трехмер­
ных данных (геометрические электронные модели изделия, детали,
сборки). Возможности визуализации в системе PDM не должны зави­
сеть от типов и форматов исходных данных, что особенно актуально
для предприятий, использующих разнотипные САПР. Сама визуали­
зация должна поддерживать анимацию, построение сечений и разре­
зов, ведение комментариев на изображении и т. д.
Рассмотрим содержание каждого из этапов жизненного цикла.
Концепция проекта. На основе анализа требований рынка форми­
руется общая идея нового изделия или, что случается значительно
чаще, концепция усовершенствований в проекте уже существующего
продукта. Система PLM представляет собой информацию, которая
может использоваться для анализа жизнеспособности полученной
концепции.
Анализ требований рынка. Производитель должен понять, на­
сколько востребован рынком новый продукт, и оценить выполни­
мость этих требований. На этом этапе система PLM используется для
извлечения данных из различных информационных систем, которые
могут способствовать получению более точной картины.
Проектирование. Конструкторы создают проект нового изде­
лия — соответствующие САПР- и PDM -решения являются инте­
гральной частью PLM -решения. При проектировании используется
вся необходимая дополнительная информация, поставщиками кото­
рой являются PLM-модули, включая факторы, связанные с после­
продажным обслуживанием изделия, информация о предпочтениях
заказчика, данные о производственных возможностях и т. д.
Определение источников поставок (PLM-sourcing). Отдел закупок
должен провести предварительную работу по поиску источников
приобретения необходимых для производства изделия деталей, мате­
риалов, компонентов, оборудования и т. д. Задача систем PLM —
предоставить достоверные данные о доступности тех или иных дета­
лей/компонентов/материалов, их стоимости, потенциальных по­
ставщиках и возможных альтернативных источниках.
Производство. В соответствии с определенными на этапе проек­
тирования спецификациями и с использованием полученных на эта­
пе поставок деталей и материалов производится продукт. Реализо­
ванные в PLM специальные методы контроля качества позволяют га­
рантировать соответствие производимого изделия заданным специ­
фикациям.
Дистрибуция. Готовое изделие поставляется либо дистрибьютору,
который размещает его на своем складе до поступления соответст­
вующего заказа, либо непосредственно заказчику. Полученные из
системы PLM исторические данные о потребностях рынка помогают
производителю свести к минимуму число уровней инвентаризации
готовой продукции.
Техническая поддержка и обслуживание. На этом этапе выполня­
ются техническое сопровождение, обслуживание и ремонт — в тече­
ние гарантийного срока или как дополнительно оплачиваемый сер­
вис. PLM позволяет учесть различную информацию об изделии, посту­
пающую на этом этапе жизненного цикла, при разработке последующих
проектов и тем самым способствует повышению привлекательности
продукции для клиентов.
В PLM доступ к данным организован на ролевой основе. Система
позволяет предоставлять пользователю информацию в форме, соот­
ветствующей выполняемым им функциям в жизненном цикле изде­
лия: трехмерные модели, схематические диаграммы, инженерные
спецификации (bill of materials — BOM), календарные планы или
прогнозы на основе анализа требований рынка. Этим обеспечива­
ется работа каждого пользователя в привычной ему среде. Так, на­
пример, конструкторы и технологи могут использовать САПР
(CAD/CAM/CAE), а сотрудники маркетингового подразделения по­
лучать из системы представление трехмерной сборки, пригодное для
размещения в рекламной брошюре. С помощью информации, кото­
рую интегрирует система PLM, даже не обладая специальными тех­
ническими знаниями, сотрудники отдела закупок смогут заниматься
поиском нужных деталей и выбором оптимальных каналов поставки
непосредственно поданным, поступающим из конструкторских под­
разделений.
Важным преимуществом системы PLM, объединяющей все
структурные подразделения предприятия, является возможность ре­
шения многих проблем на этапе проектирования. В результате появ­
ляется возможность увязать проект со сложностями производствен­
ного цикла и задачами закупок, что позволит сохранить оптимальную
цену и высокое качества продукции.
Другая характерная черта PLM — эффективная работа с постав­
щиками, внешними контрагентами и смежниками за счет безбумаж­
ных форм обмена информацией.
Знания проблем технического сопровождения готовой продук­
ции, ее гарантийного или платного обслуживания оказывают влия­
ние на последующие проекты. PLM предоставляет производителю
возможность получения таких данных, их анализ и устранение выяв­
ленных проблем в следующих проектах. Это позволяет удовлетворять
запросы клиентов, повысить имидж и конкурентоспособность про­
изводителя.
В целом, преимущества, которые дает PLM-решение, можно
сформулировать следующим образом:
• ускорение вывода новой продукции на рынок благодаря при­
влечению к процессам проектирования в реальном времени всех за­
интересованных участников, включая внешних поставщиков и заказ­
чиков;
• совершенствование характеристик разрабатываемой продукции
и повышение качества, обнаружение недостатков и ограничений
проекта на самых ранних стадиях;
• увязка проектирования и производственных процессов — инже­
неры-технологи становятся интегральной частью команды проекти­
ровщиков, благодаря чему проект сразу создается с учетом специфи­
ки производственного процесса, включая тестирование, контроль ка­
чества и т. д.;
• возможность учета и использования опыта других проектов;
• реализация новой бизнес-модели «виртуального предприятия» —
к процессу проектирования и производства привлекаются поставщи­
ки, либо работы определенного этапа жизненного цикла продукции
передаются на аутсорсинг внешним компаниям.

3 .3 . МОДЕЛИ ГИБКОГО АВТОМАТИЗИРОВАННОГО

ЗАВОДА

Одним из перспективных направлений развития АСУП является

создание гибких автоматизированных заводов (ГАЗ), развитие кото­
рых началось в 80-е годы XX в. Это особенно важно при быстром и су­
щественном изменении спроса.
За рубежом такие системы называют компьютерными интегриро­
ванными производствами (КИП), а в оригинале — Computer Integrated
Manufacturing (CIM). Встречается и название «завод будущего» —
Factory Of Future (FOF).
Под гибким автоматизированным заводом понимают автоматизи­
рованную систему, обеспечивающую выпуск продукции при опера­
тивно изменяющемся рыночном спросе и работающую — в силу вы­
сокой степени автоматизации процессов производства и управле­
ния — при ограниченном количестве обслуживающего персонала.
По экспертным оценкам, ГАЗ позволяет:
1) повысить производительность труда в 8—10 раз, выпуск про­
дукции на единице площади — 1,5—2 раза;
2) снизить длительность производственного цикла в 2—10 раз, а
договорного срока заказов в 8—10 раз;
3) увеличить коэффициент использования оборудования на
3 0 -4 0 %;
4) повысить коэффициент использования материалов за счет ис­
пользования малоотходных технологий до 0,85—0,9.
Существенной новизной таких систем является высокий уровень
интеграции различных процессов. Вместе с тем надо отметить высо­
кую трудоемкость создания подобных систем. Отсюда следует обра­
тить особое внимание как на экономическую целесообразность по­
строения, так и на методологию создания подобных систем.
Общая схема ГАЗ представлена на рис. 3.5.
ЭКСПЛУАТАЦИЯ

Текущее
планирование ЛПР А=3 ПК
ГАЗ

Календарное ЛПР А=2 ПК

АСУП
планирование

ц
ПК ЛПР й=1

ГАЛ2

ГАЛ1

ГАЦ* ГАЦ* АСУ

Микропроцессоры
ГПС

Склад с> Транспорт Станок Штаблер *> ГАУ„ ГАУдг

гпм
ГАУ1

ПРОЕКТИРОВАНИЕ Автоматизированное
АСНИ САПР АС ТП П САПРП проектирование
(CAD/CAM)

Рис. 3.5. Схема гибкого автоматизированного завода

 ГАЗ является одним из классов гибкого автоматизированного
производства. В нем выделяется родовое понятие «гибкая производ­
ственная система», позволяющее произвести классификацию.
По уровням организационной структуры выделяют гибкий про­
изводственный модуль (ГПМ), гибкий автоматизированный участок
(ГАУ), гибкую автоматизированную линию (ГАЛ), гибкий автомати­
зированный цех (ГАЦ), гибкий автоматизированный завод.
По ступеням автоматизации различают гибкий производствен­
ный комплекс (ГПК) и гибкое автоматизированное производство
(ГАП).
Таким образом, ГАП, а следовательно, и ГАЗ — гибкая производ­
ственная система, состоящая из одного или нескольких ГПК, объеди­
ненных автоматизированной системой управления производством и
транспортно-складской системой и осуществляющая автоматизиро­
ванный переход на изготовление новых изделий, основанный на ав­
томатизированной системе научных исследований (АСНИ), системе
автоматизированного проектирования (САПР) и автоматизирован­
ной системе технологической подготовки производства (АСТПП).
Приведем краткую характеристику ГАЗ.
1. Основной целью ГАЗ является интенсификация процессов
производства путем оперативного перехода на выпуск новых изделий
посредством автоматизированной перестройки программного обес­
печения системы. Для этого требуется иметь компьютерное управле­
ние соответствующим приводом (например, станки с программным
управлением).
2. Ускорение процесса перехода требует автоматизации техноло­
гической подготовки производства (АСТПП), что, в свою очередь,
вызывает необходимость автоматизации конструкторского проекти­
рования (САПР).
3. Для перехода на принципиально новые конструкции и техно­
логии требуется ускорить процедуру фундаментальных исследова­
ний, осуществляемых в автоматизированной системе научных иссле­
дований (АСНИ).
Известны следующие основные концепции ГАЗ.
1. Integrated Computer Aided Manufacturing (ICAM) — США.
2. European Strategic Planning for Research in Information Theory
(ESPRIT) — страны—участницы Европейского экономического со­
общества (ЕЭС).
3. Гибкий автоматизированный завод (ГАЗ).
Сравнительные характеристики концепций приведены в табл. 3.1.
Все концепции построены по одной схеме: выявление состояния
«как есть» («as is») и недостатков существующего состояния, форми­
рование состояния «как должно быть» («to be»). В последней процеду­
ре широко используются неформальные приемы.
Таблица 3.1

Свойство ICAM ESPRIT ГАЗ

Цель Снижение затрат на Повышение конку­ Повышение конку­
авиакосмический рентоспособности рентоспособности
комплекс
Как есть Выделение шести Изучение текущего
элементов верхнего состояния на основе
уровня «активности компа­
ний»
Как должно Трансформация Выделение четырех Выделение групп
быть структурных элемен­ систем (24 подсисте­ процессов с определе­
тов в совокупность мы) нием основных техно­
центров логических и органи­
зационных решений
Уровни Любые уровни Любые уровни Нижние уровни
иерархии
Математиче­ IDEF0, модель IDEF0 -
ская модель Джордано — Демарко
Информаци­ IDEF1 CIM-OSA -
онный язык
Принципы Система приклад­ Стратегии: данных; -
ных принципов процессов; связей
Формальный Методы, ориенти­ Эвристическое опи­ Использование
аппарат рованные на знания сание формальных и экс­
пертных методов
Техническое Распределенная Система АРМов,
обеспечение база данных, система локальная вычисли­
АРМов, локальная вы­ тельная сеть
числительная сеть

Суть названных концепций подробно представлена в работе [58],

поэтому ограничимся кратким ее изложением.

КОНЦЕПЦИЯ ICAM
Основная идея концепции — комплексная автоматизация авиа­
космических предприятий, а не отдельных участков и цехов. Цель
достигается решением следующих задач: снижение расходов; улуч­
шение качества; улучшение руководства людьми; сокращение време­
ни простоя; уменьшение сроков поставок; повышение производст­
венной гибкости; повышение конкурентоспособности.
 Прикладной аппарат построения модели «как есть» базируется на
CASE-технологии [61] с широким использованием группы методов
от 1DEF0 (функциональное моделирование) до ID EF11 (информаци­
онные и программные языки).
Суть процедуры перехода от модели «как есть» к модели «как
должно быть» показана в табл. 3.2, а структура «системы будущего» —
на рис. 3.6.
Таблица 3.2

Состояние «как есть» Инвариантные функции Состояние «как должно

быть»
Управление связью с по­ Центр маркетинга Центр развития фирмы
требителем и обслуживание
Управление заводом Управление заводом Центр диспетчерского
управления
Определение потребно­ Центры планирования и Центр разработки техно­
стей в изделиях и требова­ определение потребностей логии
ний к производству в изделиях
Обеспечение ресурсами Обеспечивающие центры Центр управления ресур­
сами
Изготовление изделий Производственные цен­ Производственные цен­
тры (цехи) тры
Материально-техниче­ Центры снабжения Центр поддержки реше­
ское обеспечение ния
Управление информацией Сеть передачи информа­ Центр знаний
ции (центр управления ин­
формацией)

В предположении успешности решения технологических про­

блем производства на основе изучения функций управления «как
есть» путем определения действий, инвариантных к структуре управ­
ления и последующей классификации этих действий, были выделе­
ны семь основных категорий «как должно быть»:
1) управление информационными ресурсами;
2) управление заводом;
3) определение потребностей в изделиях и планирование произ­
водства;
4) управление финансовыми ресурсами;
5) управление материальными ресурсами;
6) обеспечение качества изделий;
7) управление трудовыми ресурсами.
 Рис. 3.6. Сеть центров предприятия

Так, анализ современного управления информационными ресур­

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

Функции Требования
Управление заводом Интеграция текущего, календарного и оператив­
ного планирования
Совершенствование перехода от одного вида пла­
на к другому
Поддержка принятия решений
Определение потребностей в Применение стандартизации продукции
изделиях Лучшее использование ресурсов
Применение общей БД
 Функции Требования
Управление информацией Наличие архитектуры для интеграции информа­
ции
Построение распределенной БД
Наличие удобных интерфейсов и средств управ­
ления данными для поддержки принятия решений

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

является центр знаний. Схема связей центров в концепции ICAM
приведена на рис. 3.7

Рис. 3.7. Подсистемное представление ICAM

КОНЦЕПЦИЯ ESPRIT
Цель концепции — улучшение технико-экономических характе­
ристик западноевропейских производств и продукции для повыше­
ния конкурентоспособности прежде всего по отношению к странам,
обладающим дешевыми ресурсами.
Исследования в рамках концепции велись широким фронтом, о
чем свидетельствует восьмитомная документация.
1. Синопсис — введение, указатели проектов, адреса разработчи­
ков.
2. Микроэлектроника.
3. 4. Система обработки информации.
5. Офисные и деловые системы.
6. Компьютерные интегрированные производства CIM.
 7. Система обмена информацией.
8. Мероприятия по фундаментальным исследованиям.
Исследование системы управления базируется на системе прин­
ципов, объединенных в три стратегии: данных; процессов; связей.
В стратегиях не все принципы одного уровня, поэтому из них пе­
речислим лишь основополагающие.
Стратегия данных:
• принцип «главного авторства» — только один источник возник­
новения данного типа информации;
• принцип пригодности данных (сохранения часто обновляемых
данных);
• принцип генерации данных для принятия решений;
• принцип выбора уровня хранения и накопления данных;
• принцип распределения данных.
Стратегия процессов:
• принцип интеллектуальной локальной обработки;
• возможность увеличения размерности решаемых задач;
• наличие системы диагностики;
• задачи обработки в реальном времени должны быть хорошо оп­
ределены;
• широкое использование базовых компонентов;
• системы программирования и управления должны быть разде­
лены.
Стратегия связей:
• модификация сети не должна вести к прекращению ее работы;
• сеть должна противостоять помехам;
• отказ одного компонента сети не должен воздействовать на тра­
фик оставшейся части сети;
• компромисс производительности и надежности сети;
• возможность использования сообщений с приоритетами;
• единообразная и гибкая система адресации;
• эффективная защита от несанкционированного доступа к дан­
ным.
В рамках концепции ESPRIT предполагается построение четырех
систем, состоящих из 24 подсистем.
К системам относятся:
CAD (автоматизированного проектирования), в которой имеются
подсистемы концептуального проектирования (D1); технического
проектирования (D2); детального проектирования (D3);
 ^Маркетинг,
Набор (С А Р Р )
Производ­ возможных
ственные стратегий Р10
планы производства
Р20
(cape; Разработать
E120 стратегию
Техно- производства
ттлги а компонентов

Р40
Cj c a p i o
Изменение
возможности Р40
Стратегия
и/или (и) СП произ-
vBOflCTBaJ

P6Q
Изменение
поставщиков,
потребителей -(RAMS)
и/или СП

Да | Р50
Изменение воз­ ГСАРР^
Р70 можности тран­
Р80
спортных и Стратегия
Нет складских произ­
систем или СП водства^

Р100
Изменение но­
менклатуры
личного сос­ - p ( P E R S )
тава и/или СП

Вывести
ССАРР)
на печать
проверенную Р110
стратегию
производства -------- --

Рис. 3.8. Система САРР. Подсистема Р1:

А — соответствуют ли возможности производства данной стратегии? В — можно ли преобразовать
материалы и инструмент в соответствии с данной стратегией? С — удовлетворяют ли возможности
склада и транспортных систем данную стратегию? D — соответствует ли номенклатура личного со­
става предприятия данной подсистемы; САРР —технология; CAD — планы и заказы; САРЕ — тех­
нология; PAMS — поставщики; PERS — персонал; MSTD, ESTD — обращение к подсистемам
CAM/CAST, CAD, САРР — главный файл
 Производ­
ственные
заказы
по изделиям
и по датам
Р140
САРР Выбрать
Р110 планируемые
Стратегия темпы
произ- производства
^водства Нет
Р150
Изменить,
если требу­ Да
ется, темпы
производства Р160
Сравнить
планируемые
темпы с
требуемыми

Р130

Получить Напечатать
^СА РР)
допустимые производ­
и макси­ ственные Р190
мальные заказы
требования к датам ^ ------^

Рис. 3.9. Система САРР. Подсистема Р2:

А —требуется ли примерная оценка мощностей? В —является ли требование допустимым?

САРЕ (технической подготовки производства), содержащая под­

системы проектирования для оценки производства (Е1), классифи­
кации и кодирования (Е2), выбора процесса (ЕЗ), выбора оборудова­
ния (Е4), выбора режущего инструмента (Е5);
САРР (планирования производства), куда входят подсистемы тех­
нико-экономического планирования (Р1), приема заказов (Р2), ка­
лендарного планирования (РЗ), оперативного планирования (Р4);
CAM/CAST (управления производством), содержащая подсисте­
мы требований общего количества (Т 1), учета и сопровождения осна­
стки и инструмента (Т2), контроля за установкой приспособлений
(ТЗ), оценки ранних поставок (Y1), определение материального за-
А — вычислить потребность в комплектующих изделиях на данный период времени? В — выбрать
потребность в деталях на следующий период времени? С — вычислить ожидаемый задел на началь­
ный период времени? D — добавить потребности в планируемых деталях на основе запаса? Е — со­
кратить потребность на необходимое количество (в счет запаса)? F — потребные материалы могут
быть поставлены? G — необходимо повторное планирование?

проса (Y2), координации материалов (Y3), программ ЧПУ (XI),

управления программами ЧПУ (Х2), отладки программ ЧПУ (ХЗ), ка­
лендарного планирования ресурсов (M l), управления поставками
(М2), управления трудовыми ресурсами (М3).
Во всех подсистемах заложена схема метода MRPII.
Концепция ESPRIT предполагает четырехэтапный расчет плана в
системе САРР:
1) в подсистеме Р1 определяется (на уровне руководства), можно
ли выполнить соответствующие заказы (имеются ли необходимые ре­
сурсы), т. е. проводят предварительное планирование;
 Рис. 3.11. Система САРР. Подсистема Р4:
А —достаточна ли доступная производственная мощность? В, D, F, Н — необходимо перепланиро­
вание? С —достаточно ли доступные мощности склада и транспорта? Е —доступна ли необходимая
рабочая сила? G — есть ли потребный инструмент и приспособления? I — остались ли периоды для
планирования?
 Рис. 3.12. Подсистемное представление ESPRIT

2) в подсистеме Р2 проводится уточнение возможности получе­

ния ресурсов и формируется так называемый портфель заказов;
3) в подсистеме РЗ ведется расчет для технологической линии в
целом (календарное планирование);
4) в подсистеме Р4 осуществляется планирование на уровне це­
хов.
Оптимизация плановых расчетов не предполагается.
 Схемы потоков подсистем PI — Р4 системы САРР приведены на
рис. 3.8—3.11.
Подсистемное представление [4] автоматизированной системы в
рамках концепции ESPRIT показано на рис. 3.12.

КОНЦЕПЦИЯ ГАЗ
Целями создания концепции ГАЗ явились:
• существенное повышение научно-технического уровня маши­
ностроения;
• создание конкурентоспособной продукции.
В этой концепции впервые более детально рассмотрен вопрос по­
строения математической модели системы, правда, для нижнего
уровня иерархии управления. Для системы в целом приведена описа­
тельная модель. Иными словами, акцент сделан на техническую под­
готовку производства.
Для математической модели предложено использовать два подхо­
да: теоретический с использованием оптимизационных и имитаци­
онных моделей и эмпирический, учитывающий опыт специалистов.
Процедура построения системы в данной концепции та же, что и в
рассмотренных концепциях.
Выделены следующие группы процессов и процедур:
1) формирование технико-экономической стратегии;
2) составление производственной программы с использованием
фактически метода ERP;
3) выполнение конкретного заказа (разделение заказов на узлы,
детали, формирование партий деталей и узлов, изготовление деталей,
комплектация сборки и сборка изделий).
На основе выделенных технологических процессов определены
основные технологические и организационные решения.
В части организационных решений в основу положено:
• компьютеризация учета и прогнозирования спроса;
• создание иерархической структуры управления с частичной де­
централизацией и распределением функций управления;
• интеграция подсистем с использованием локальных вычисли­
тельных сетей и распределенных баз данных;
• использование советующих методов принятия решений;
• применение методов математического моделирования и опти­
мизации;
• минимизация материальных и информационных потоков;
• создание системы локальной вычислительной сети и АРМов;
 • согласованность критериев различных ЛПР.
Из сравнения концепций нетрудно заметить, что из всех концеп­
ций концепция ГАЗ проработана в наименьшей степени.
Перечисленные концепции дают общее направление работ и тре­
буют более детальной проработки.

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

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

продукции характерны следующие особенности.
1. Целенаправленность систем и ее элементов, проявляющаяся в
процессе эксплуатации.
2. Качественное изменение цели, которое компенсируется изме­
нением структурных связей.
3. Выделение процесса планирования (формирование задающего
воздействия) в относительно самостоятельную процедуру.
4. Интенсификация управленческих процессов в системе по срав­
нению с традиционными АСУ.
5. Многоуровневая структура системы с изменением масштабов
по времени и координатам на границах уровней.
6. Высокая размерность системы.
7. Значительная доля неформальных процедур в процессе экс­
плуатации системы.
Фактически сформировался новый класс систем управления.
Рассматриваемый класс систем, как показано в [4], не представляется
возможным исследовать методами теории как традиционных АСУ,
так и современной теории автоматического управления. Для форми­
рования нового метода исследования "целесообразно первоначально
рассмотреть концепцию исследования подобного класса систем. Она
определяется методологией структурно-алгоритмического модели­
рования (САМ), включающей следующую систему принципов.

СОЗДАНИЕ СИСТЕМЫ
I. Первичность цели проектирования и структуры модели объекта
управления по отношению к структуре модели управляющей части сис­
темы. При проектировании процесса функционирования системы
этот принцип определяет процедуру построения структуры системы
управления на базе предварительно разработанной технологии про­
изводства и соответственно структуры объекта управления. Исполь­
зование в качестве базы для построения структуры динамической
системы управления штатного расписания, по мнению авторов, не­
корректно в силу значительной субъективности результата, а приме­
нение в качестве первоосновы понятия «функции» связано с недоста­
точной формальной четкостью определения. При проектировании
процесса развития характерна частичная фиксация структуры объек­
та управления, связанная с выпуском прежней продукции.
II. Комплексное проектирование моделей функционирования и раз­
вития. С позиций «жизненного цикла» системы управления выделяют
ее проектирование и эксплуатацию; с позиций работы системы —
функционирование и развитие системы. Под функционированием
понимается работа системы в рамках заданной (фиксированной)
структуры. Развитие — работа системы в рамках острых противоре­
чий, которые могут вызвать и вызывают изменение структуры систе­
мы. При эксплуатации целенаправленных многоуровневых систем
имеет место интеграция процедур функционирования и развития.
Следовательно, необходима интеграция и моделей этих процедур. Та­
кая интеграция может быть обеспечена лишь комплексным проекти­
рованием специфической модели функционирования и модели раз­
вития. Отметим, что при использовании подобных систем возможно
совмещение эксплуатации модели функционирования с проектиро­
ванием (и последующей эксплуатацией) модели развития.
III. Интеграция исследований динамических процессов и процессов
изменения структурных связей. В силу интенсификации процессов в
объекте управления возникает потребность в исследовании динами­
ческих процессов в рассматриваемом классе систем. Поскольку в
системе возможны структурные изменения, вызванные изменения­
ми целей и влияющие на динамику системы, следует вести совмест­
ное исследование структурно-динамических свойств в процессе са­
монастройки и самообучения самой системы.
Следует четко различать цель проектирования и цель работы сис­
темы. Последняя может меняться в процессе работы системы.

ЭКСПЛУАТАЦИЯ СИСТЕМЫ
IV. Построение единого метода математического описания с исполь­
зованием составного критерия, учитывающего экономические и управ­
ленческие свойства системы.
V. Последовательный переход от имитационного к оптимизационно­
му описанию системы. В силу неопределенности в получении данных
об управляющей части целесообразно сначала построить имитацион­
ную модель, убедившись в ее адекватности системе, а затем улучшить
характеристики системы.
VI. Оптимизация (с помощью модели) структурных и динамических
характеристик системы. Использование оптимизации предопределя­
ется потребностью работы многоуровневой целенаправленной систе­
мы, оперирующей понятием «интерес». Оптимизационный инстру­
мент предоставляется вычислительной техникой: оптимум может
быть удержан при изменяющихся условиях работы системы, что осо­
бенно необходимо и эффективно при оперативном переходе на вы­
пуск новой продукции, позволяя выбрать наиболее целесообразный
способ такого перехода.
VII. Горизонтальное и вертикальное согласования интересов. Целе­
направленные элементы системы могут иметь интересы, не совпа­
дающие с интересами самой системы. Для увеличения эффективно­
сти работы системы управления имеется потребность в согласовании
интересов структурных элементов в процессе управления с учетом из­
менения масштабов процессов по времени и координатам на грани­
цах уровней.

РЕАЛИЗАЦИЯ СИСТЕМЫ
VIII. Современный подход к построению системы управления. Речь
идет о построении системы, базируясь на алгоритме управляемого
процесса (бизнес-процесса), а не на некоторой системе документов.
Иначе говоря, рассматривается автоматизация управления, а не авто­
матизация документооборота.
IX. Ориентация на использование динамических распределенных баз
данных. По своей сути многоуровневые системы являются развиваю­
щимися. Это означает возможность оперативного и многократного
дополнения и изменения данных: частота запросов становится соиз­
меримой с частотой обновления данных. К такой базе данных предъ­
являются дополнительные требования по быстродействию, объему
памяти, адаптации к изменению алгоритмов обработки информации.

Структурно-алгоритмическое моделирование предполагает та­

кую последовательность решения проблемы: «обобщенная модель —
обобщенная технология — система моделей и методов, составляю­
щих технологию».
На основе анализа процесса проектирования подобных систем [7,
43] сформирована обобщенная модель адаптивного управления, по­
казанная на рис. 3.13.
Модель позволяет описывать следующие процессы.
.\ I/

X > 3 ? ( d , /° )
й=0 А -----------
 А. ФУНКЦИОНИРОВАНИЕ СИСТЕМЫ (структурные связи
фиксированы).
Ф1.1. Синтез (построение) структуры системы нового предпри­
ятия или изменение структурных элементов (реконструкция) старой
структуры. В последнем случае имеют место значительные затраты, в
силу чего чаще приходится рассматривать другую разновидность про­
цесса Ф1 (Ф1.2).
Ф1.2. Идентификация структуры действующего предприятия.
Ф.2. Интегрированное планирование.
ФЗ. Интегрированное управление
Б. РАЗВИТИЕ СИСТЕМЫ (изменение структурных связей при
оперативном переходе на выпуск новой продукции).
Р1. Модернизация структуры. Здесь выделяют два случая:
1) изменение только структурных связей;
2) изменение элементов и структурных связей.
Второй случай (реконструкция) связан с серьезными затратами и
рассматривается гораздо реже, чем первый, который далее и будет об­
суждаться.
Первый случай характеризуется понятием «гибкость» — способ­
ность системы изменять цели функционирования без существенных
затрат (реконструкции).
Р2. Интегрированное планирование с учетом «структурной со­
ставляющей».
РЗ. Интегрированное управление с учетом оперативного перехода
на выпуск новой продукции.

Полное, достаточно объемное описание обобщенной модели при­

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

М"А/(1) = {Эот+ 2(u, t h + 2) * Эк + \ и , t h + ' ) * (3.1)

* э?(и, t h) • э?(у, t h) * 9j (y, / % i = Т7К, h = ore,

Ф *(5) —> max, (3.2)

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

ЭП — элемент планирования: УЧ, ОУ — элементы управляющей части и объекта управления;
Э* (р, l h) — А-й элемент процесса планирования на уровне Ив масштабе времени t h\ p — признак
планирования; Э* (и, t Л) —элемент процесса управления; и — признак управления; Э к ( d, Р) — эле­
мент объекта управления (h = 0)' d— признак объекта управления; — выход объекта управления;
р к — план элемента к на уровне Л
где Э А+ '(u, t h + '), Э/Л(и, t h), Э/А(у, t h) — к-е и 1-е элементы соответст­
вующих уровней управляющей части и объекта управления; и, у —
векторы управления и выхода; t h — отсчет времени на уровне А; * —
оператор замыкания, учитывающий обратные связи; Kh — число эле­
ментов на уровне A; h = 1,0; 0 — число уровней системы; S — связи ме­
жду элементами Э; I еС(к ), С(к) = {/: ГЭ*А+ 1= Э/А}, |С(А:)| = Nh к = \,
Kh + U l = 1, Kh; j е С(Г), С{1) = {/: ГЭ / = Э,Л}, |С(/)| = N j , j = 1, Nf, C(r) = {г:
ЭА= Г 'Э А+ 1}, |C(r)| = N r ; Г — прямая связь двух смежных элемен­
тов.
На основе обобщенной модели составим обобщенную технологию
моделирования системы.
Выделяют процессы идентификации, планирования и управле­
ния.
В идентификации, в свою очередь, можно выделить такие этапы.
И1. Формирование цели Ц исследования.
И2. Определение по выбранной цели моделирования модели
М(0): перечня элементов, числа уровней 0, количества А* элементов
на каждом уровне.
ИЗ. Построение структуры. Если число уровней более трех — вы­
деление базовой трехуровневой «скользящей» топологии и переход к
ее изучению. При формировании топологии полезно использовать
такой порядок: определение топологии объекта управления; после­
довательное выявление топологии управляющей части.
И4. Определение на документальной основе алгоритмов плани­
рования, описание алгоритмов объекта управления; формирование
алгоритмов управляющей части.
И5. Выявление числовых значений параметров полученного опи­
сания.
И6. Определение адекватности модели исходной системе.
В процессе планирования возможно выделить следующие этапы.
П1. Проверка ресурсного обеспечения для выпуска продукции.
П2. Учет векторного критерия с определением чувствительности
решения.
ПЛ1. Планирование при оперативно изменяющихся структурных
связях.
ПЗ. Согласование работы элементов и уровней.
П4. Выделение (классификация) сильно связных множеств, опре­
деляющих соответствующие компоненты.
П5. Декомпозиционное определение оптимальных планов.
В процессе управления выделяют такие этапы.
 У1. Изучение свойств элементов и компонентов. По свойствам
осуществляются анализ и синтез динамических характеристик систе­
мы. Выбор управления (решения) следует проводить по векторному
свойству, включающему совокупность экономических и управленче­
ских характеристик (затраты на управление, устойчивость, ошибки и
качество управления).
УЛ1. Управление при оперативно изменяющейся структуре.
У2. Координация управления элементами и уровнями.
УЗ. Выделение компонентов.
У4. Использование декомпозиции.
Нетрудно видеть различия процессов планирования и управления
с точки зрения их математического описания.
КОНТРОЛЬНЫЕ ВОПРОСЫ

1. Укажите основные принципы концепции MRP.

2. Перечислите основные функции модели MRPII.
3. Укажите основные параметры модели MRPII.
4. Каковы основные функциональные блоки модели MRPII?
5. Укажите основные отличия модели MRP от модели ERP.
6. С каким фактором связано появление модели PLM?
7. Назовите составляющие управления жизненным циклом.
8. Дайте определение PLM.
9. Перечислите основные компоненты PLM.
10. Дайте краткую характеристику основных этапов жизненного цикла.
11. Укажите основные преимущества PLM.
12. Дайте определение гибкого автоматизированного завода.
13. Перечислите концепции гибкого автоматизированного завода.
14. Какие задачи решают на основе концепции ICAM?
15. Какие принципы использованы в концепции ESPRIT?
16. Какие системы используются в концепции ESPRIT?
17. Какие особенности характерны для адаптивного автоматизированного
управления?
18. Какие принципы положены в основу концепции адаптивного автомати­
зированного управления?

7-2742
 ГЛАВА 4
Функциональный и структурный анализ
автоматизированных систем

В настоящее время в целом сформировались идеология и практика примене­

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

4 .1 . СИСТЕМНАЯ ИНЖЕНЕРИЯ КАК СРЕДСТВО

АНАЛИЗА АСУ

Системная инженерия определяет систему как совокупность ком­

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

К сх
Д Л
<Я

я
я §
К £

корректности разработчикам
архитектуры продукта

Рис. 4.1. Процесс системной инженерии при определении архитектуры

Разработанные АСУ часто не оправдывают ожиданий пользовате­

лей. Это возникает из-за применения множества разрозненных инст­
рументов, несогласованных попыток анализа требований и неадекват­
ных критериев выбора функций и разделения архитектуры. В итоге
формируется противоречивый набор требований к системе, создаются
неполные определения архитектур, оказываются пропущенными не­
которые необходимые компоненты.
Рассмотрим основные проблемы с учетом ряда ограничений,
свойственных разработке реальной АСУ.
Сложность. Системы могут обладать иерархией с любым числом
физических компонентов, логическим разбиением, несколькими
уровнями подсистем, структур и компонентов. Подобные иерархии
часто асимметричны, а аппаратные иерархии могут не соответство­
вать программной архитектуре.
Унаследованные системы (компоненты). Проектируемая система
может функционировать в окружении унаследованных компонентов,
будь то инструменты, компьютерное оборудование, программное
обеспечение, сети, протоколы, алгоритмы.
Существующие бизнес-соглашения. Иногда проекты АСУ прихо­
дится реализовывать в рамках существующих соглашений с изготови­
телями или разработчиками компонентов.
 Конфликтующие требования. При реализации проекта приходится
учитывать часто не связанные друг с другом требования пользовате­
лей или меняющиеся требования к системе, а также приходится до­
бавлять функции или отказываться от запланированных.
Существующая технология. В силу сложившихся обстоятельств
при проектировании системы приходится использовать технологии,
которые отвечают различным требованиям к функциональности, ин­
терфейсу, работе и производительности, однако могут оказаться не­
достаточно совершенными.
Чтобы разрешить эти проблемы, специалисты по системной ин­
женерии применяют различные стратегии, специальным образом
предназначенные разрешить проблемы междисциплинарного взаи­
модействия. Они используют ряд представлений архитектуры, на­
пример, логическое, физическое, представление данных, представле­
ние процессов. Чтобы определить и выразить различные аспекты
процесса разработки, применяются такие методики, как «сети Пет­
ри» (помогают определить параллельность и синхронизацию), маши­
ны с конечным числом состояний (состояния и режимы), структур­
ный анализ (потоки данных) и PSL/PSA (Problem Statement
Language/Problem Statement Analysis).
К сожалению, для этих методик не существует единого представ­
ления; они в разной степени применимы для таких этапов цикла жиз­
ни продукта, как формулировка требований, проектирование, реали­
зация и тестирование.
В рамках разработки АСУ объектно-ориентированный подход
обеспечивает инкрементальный подход к определению требований,
проектированию и разработке систем, интенсивно использующих
программное обеспечение.
Инкрементальный подход — подход к проектированию по нарас­
тающей, снизу — вверх (проектирование блоков, объединение бло­
ков в модули и т. д.). Существуют три подхода к проектированию —
итеративный, эволюционный и инкрементальный.
Для определения и представления этих требований служит язык
UML — Unified Modeling Language (разработка групп OMG Unified
Modeling Language Specification, Object Management Group). UML до­
пускает создание спецификации продукта, не зависящей от языка
программирования или конкретного процесса разработки.
Объектно-ориентированный подход должен стать механизмом
для объединения технологий разработки АСУ и уменьшить диссо­
нанс между спецификацией и реальными параметрами готовой сис­
темы.
 Новые методы объектно-ориентированной системной инжене­
рии OOSE (Object Oriented System Engineering) расширяют методики
объектно-ориентированного подхода за счет использования иерар­
хии систем, подсистем и наборов компонентов, позволяя сформиро­
вать исчерпывающую инфраструктуру для процесса, показанного на
рис. 4.1, и управлять им. По своему предназначению методы OOSE
охватывают всю систему, от верхнего уровня до самых мелких ее дета­
лей.
Методика OOSE допускает расширение, превращающее ее в ин­
струментарий анализа программных систем управления информаци­
ей; это происходит, если в нее интегрировать представление сборки
системы, изображенное на рис. 4.2. Данное представление является
попыткой урегулировать несоответствие между различными физиче­
скими, аппаратными и программными архитектурами. Оно накапли­
вает объекты по мере их описания и помогает создавать из элементов
искомую архитектуру, согласующуюся со всеми действующими огра­
ничениями, с верхнего уровня до конечных компонентов.
В OOSE для обозначения компонентов иерархии продукта не ис­
пользуется термин «узел» (node), поскольку узлами в UML представ­
ляют вычислительное аппаратное обеспечение. Вместо этого в OOSE
используют термин «элемент» (element), который может обозначать
физический узел, но, как правило, под ним подразумевается логиче­
ская группировка сущностей со сходным поведением.
Задача OOSE — учитывать все ограничения и требования по мере
их возникновения. OOSE предоставляет строгую методику практиче­
ского решения сотен новых вопросов, которые возникают в ходе раз­
работки продукта. В рамках данного унифицированного процесса
выполняются процессы (см. рис. 4.1) для каждого элемента систем-
Система

С В1 В2 D

Cl С2

Рис. 4.2. Представление сборки системы

 Рис. 4.3. «4 + 1 представление»

ной иерархии (см. рис. 4.2) путем систематического использования,

анализа и наращивания модели, получившей название «4 + 1 пред­
ставление» (рис. 4.3).
Группа системного проектирования может разработать множество
конкурирующих представлений архитектуры, дополняющих «4 + 1
представление». OOSE также включает в себя два специальных пред­
ставления архитектуры.
Диаграмма контекста верхнего уровня. Диаграмма контекста верх­
него уровня (рис. 4.4) описывает систему, внешние интерфейсы, ог­
раничения, требования к производительности, тестовые конфигура­
ции, а также требования к разработке и ограничения на элементы.
Она включает в себя и иные представления архитектуры (IEEE Std.
1471-2000, IEEE Recommended Practice for Architectural Description of
Software-Intensive Systems, IEEE, 2000), описывающие другие струк­
турированные наборы концепций для определения систем (ISO/IEC
 ----- 1 ----- 1
Внешние Тестовые
Система
интерфейсы конфигурации

Процесс
развертывания

Ограничения Требования

Рис. 4.4. Диаграмма контекста верхнего уровня

JTC1/SC21/WG7 10746-1, Reference Model of Open Distributed

Processing, Project 21.43, 1995). Эти представления проясняют вопро­
сы, касающиеся разработки элементов, требований и ограничений;
они формируют контекст для других представлений.
Данная диаграмма создает основу для формирования иерархии
элементов продуктов и оказывает значительное влияние на разработ­
ку системы. Она объединяет эти объекты в своего рода пакеты, что
позволяет поддержать декомпозицию, сгруппировав их в соответст­
вии с влиянием, которые они оказывают на систему. Иерархия паке­
тов гарантирует, что аналитик и разработчик при описании продукта
могут использовать контекст, установленный для конкретного эле­
мента.
Представление сборки системы. Это представление устанавливает
предполагаемую иерархию продукта и формирует контекст для руко­
водства разработкой «4 + 1 представление», что согласуется с другими
представлениями и дополняет их. Представление сборки системы на­
чинается с конфигурирования или группировки аппаратного обеспе­
чения верхнего уровня. Проектная группа может быстро расширить
это представление с помощью группировок элементов более низкого
уровня, что необходимо для поддержки анализа требований и функ­
циональной декомпозиции.
Данное представление, в частности, включает в себя физическую
структуру оборудования, компоненты и механизмы, которые опреде­
ляют поведение системы в целом. Разработчики устанавливают тре­
бования к эффективности и нефункциональные ограничения на фи­
зические атрибуты элементов более низкого уровня в иерархии струк­
туры с помощью анализа, как зависящего, так и не зависящего от
предметной области. В ходе этого анализа изучаются такие парамет­
ры, как точность алгоритмов, диапазон ошибок и финансирование, а
также выработка критериев, устанавливающих параметры для эле­
ментов продукта. Это представление также включает в себя элемен­
ты, касающиеся вопросов, влияющих на анализ требований, опреде­
ление функций и формирование архитектуры. Именно это много­
уровневое дерево предполагаемых физических элементов системы и
концептуального поведения воздействует на процессы OOSE в во­
просах, связанных с взаимодействием элементов продукта, которое
позволяет реализовывать предполагаемые функции системы. Таким
образом, представление сборки системы — это представление архи­
тектуры, которое определяет роли и взаимозависимости между роля­
ми элементов (см. рис. 4.2). Оно выделяет критически важные роли,
поведение, параметры разработки и ставит вопросы, требующие ре­
шения.
В 1995 г. было предложено использовать модель «4 + 1 представле­
ние» в разработке программного обеспечения. С тех пор данная мо­
дель была расширена; ее стали применять к разработке и других сис­
тем (см. рис. 4.4).
Представление случаев применения. Центр рис. 4.3 отображает
представление случаев применения; он подчеркивает центральную
роль, которую эти случаи играют в OOSE. Представление случаев
применения определяет предполагаемое поведение системы с помо­
щью текстового описания — случай применения — и диаграммы по­
следовательности, которая моделирует взаимодействие элементов в
представлении системной структуры с помощью внешних воздейст­
вий.
Было предложено расширить это описание и диаграмму последо­
вательности, добавив предполагаемые взаимодействия подэлемен-
тов, необходимых для реализации поведения, с учетом внешних ис­
точников. Именно это расширение для анализа случаев применения
разработчики используют в OOSE для непрерывного выявления,
группировки, изменения и описания поведения элементов более
низкого уровня.
OOSE определяет требования к производительности в итоговых
случаях применения для подэлементов. Аналогичный подход был
предложен специалистами компании Rational Software, активного
сторонника объектно-ориентированных методов. Разработчики ис­
пользуют представление архитектуры (диаграмму согласования) вме­
сте с диаграммой последовательности случаев применения, чтобы
поставить и решить вопросы, касающиеся назначения функций, ин­
терфейса, производительности и взаимодействия.
Логическое представление. Это представление определяет связи
зависимостей между системными элементами. В частности, оно изо­
бражает разделение системы на вычислительные службы и службы
физических элементов, которые совместно формируют поведение
системы.
Разработчики создают эти диаграммы непосредственно из уни­
фицированных описаний поведения подэлементов, и эти диаграммы
устанавливают зависимость между элементами.
Представление процессов. Это представление определяет состоя­
ния, режимы, согласованность и отношения синхронизации. Тради­
ционные диаграммы функций, данных и управляющих потоков можно
в той или иной степени создать с помощью механизмов, предлагаемых
в UML. Основное представление — диаграмма действий, определен­
ная как часть UML. Эта диаграмма определяет взаимоотношения и
действия, которые трудно определить и выразить только с помощью
описаний случаев применения. Разработчики могут также создать
диаграммы активности непосредственно из унифицированных опи­
саний поведения элементов.
Представление развертывания (физическое представление). При
разработке программного обеспечения это представление иногда на­
зывают представлением развертывания, однако разработчики систем
также воспринимают его как физическое представление, поскольку
оно связано с физическими компонентами. Это представление опи­
сывает уже существующее распределение ресурсов обработки унасле­
дованных систем и компонентов, их физические взаимосвязи и в ко­
нечном итоге синтез архитектуры, который выливается в иерархию
декомпозиции системы. Это представление вместе с логическим
представлением и представлением сборки системы определяет ре­
зультирующую архитектуру уровня элементов и влияет на эту архи­
тектуру с учетом формулирования вычислительных задач, правил на­
значения вычислительных файлов и выбранных шаблонов проекти­
рования.
Метод OOSE учитывает, что эти шаблоны проектирования влия­
ют на проектирование и описание фундаментального поведения всех
элементов. Поэтому он использует шаблоны для совершенствования
представления системной структуры.
Представление реализации. Это представление описывает реали­
зованные функциональные компоненты системы. Например, оно
определяет параметры, касающиеся только аппаратного обеспече­
ния, такие как структура и потоки, в виде компонентов. Добавление
механических структур действительно помогает разработчикам ука­
зывать дополнительные требования к производительности и времени
ответа для программных элементов управления. К примеру, про­
граммное обеспечение не может заставлять систему возлагать слиш­
ком большую нагрузку на механические соединения.
 Взаимодействие представлений. Разработчики одновременно со­
вершенствуют все перечисленные выше представления, постепенно
формируя согласованный образ системы — вплоть до компонентов
самого нижнего уровня. Зачастую оказывается, что унаследованные
компоненты, которые изначально предполагалось разместить внутри
системы, обладают иной, нежели ожидалось, функциональностью.
Случается, что эти представления помогают выявить аппаратные не­
достатки, которые заставят добавить и описать новые возможности
элементов системы. Конечный продукт — синтезированная архитек­
тура конечных компонентов, позволяющая получить список сущно­
стей, необходимых для производства системы.
После того как специалисты проектной группы создали набор
представлений для системы, настает время для формулирования нис­
ходящих требований, фиксирования функциональности и определе­
ния необходимой для этого архитектуры.
Процесс разработки. Разработка в рамках OOSE, начиная с сис­
темного анализа верхнего уровня и до определения терминальных
компонентов, проистекает так, как показано на рис. 4.5. Проектная
группа повторяет этот процесс для каждого элемента в системной
иерархии. Конечный результат анализа каждого из элементов — это
доведенное до совершенства представление системы, вспомогатель­
ные «4 + 1 представление», а также описания, показывающие распре­
деление функциональности во всей системе. Эти описания проеци­
руют функциональные требования на элементы, расположенные в
системной иерархии непосредственно под ними. Так же они фикси­
руют другие архитектурно значимые, но не функциональные требо­
вания и ограничения, в частности те из них, которые влияют на ин­
терфейс, работу, производительность, физическую структуру, тести­
рование или производство. Одновременно создается документация,
описывающая задания для субподрядчиков.
На верхних уровнях системы может существовать общая специ­
фикация, в которой указаны требования, касающиеся функций, опе­
раций, предполагаемой производительности, интерфейсов и других
аспектов.
Разработчики могут также добавить в спецификацию вопросы,
поставленные ранее в процессе анализа. Для любого числа уровней
декомпозиции может быть определена концепция операций. Кроме
того, сюда могут быть включены планы перевода унаследованных
систем на новую системную конфигурацию.
На более низких уровнях системы могут быть созданы руково­
дства по эксплуатации и обслуживанию.
 Рис. 4.5. Типичный процесс системной инженерии применительно к OOSE

Дерево спецификаций часто схематически описывает предпола­

гаемую взаимосвязь аппаратного обеспечения, либо определяемую
пользователем, либо необходимую для реализации предполагаемых
функций системы. Такое дерево следует тщательно продумать, преж­
де чем приступить к анализу требований. Деревья спецификаций час­
то описывают ситуации, возникающие после сбоев программы, и мо­
гут дополняться группами предполагаемых физических или логиче­
ских функций. Точнее говоря, это многоуровневое дерево планируе­
мых в системе физических элементов, которое дает первоначальное
общее представление о системе и определяет дальнейший анализ.
Зачастую данная иерархия является неадекватной, поскольку на
уровне системного представления, где она формировалась, функцио­
нальность и интерфейсы, необходимые для выполнения требований,
107
не были очевидны. Пример такой проблемы — требования, предъяв­
ляемые к выявлению аномалий или к поддержке унаследованных
производственных процессов.
Разработчики, дополняя данную иерархию, добавляют к систем­
ному представлению элементы, представляющие сходные, сгруппи­
рованные функции. Эти добавленные элементы формируют структу­
ру и функции элементов следующего уровня так, чтобы выполнить
указанные требования. Разработки, выполненные с помощью мето­
дов OOSE, гарантируют согласованность всех уровней этой допол­
ненной иерархии в течение всего времени ее использования.
Выбор возможных сценариев — одна из самых важных составляю­
щих во всем процессе. Разработчики получают первоначальное пред­
ставление о системе и ее логических компонентах и группах, анализи­
руя концепцию операций системы и требования более высоких уров­
ней. Они проводят серию практикумов по различным дисциплинам,
чтобы прояснить для себя аспекты, связанные с разработкой и реали­
зацией продукта. Эти практикумы позволяют выяснить, как лучше
всего определить сценарии верхнего уровня, используя системное
представление как руководящие принципы при формулировании во­
просов и концепций проектирования.
Опыт показывает, что сценарии верхнего уровня необходимо оп­
ределить таким образом, чтобы можно было гарантированно выявить
эти концепции проектирования элементов подсистем. Хотя на дан­
ном этапе процесса разработки нет полного понимания, эти концеп­
ции могут существенным образом повлиять на всю системную архи­
тектуру. При таком анализе определяются сценарии, касающиеся
функционирования, обслуживания, тестирования и развертывания
системы.
Зачастую между этими аспектами нет четких границ. Что касается
небольших программ и систем на базе графического пользователь­
ского интерфейса, то многие практики начинают с трех сценариев:
одного — для внешнего интерфейса, другого — для основной обра­
ботки и третьего — для хранения данных. Разработчики также опре­
деляют, расширяют и объединяют сценарии по мере создания этих
описаний.
Однако крупномасштабные системы часто обладают поведением,
которое не очевидно на текущем уровне декомпозиции, в силу чего
трудно полностью описать эти требования, последовательность опе­
раций или состояний и режимы функционирования, продиктован­
ные нижележащими в иерархии элементами. Например, возмож­
ность системы выполнять обычные операции и поддержку, или опре­
делять и устранять аномалии в типовых модулях относятся к требова­
ниям системного уровня, которые не так-то просто отобразить на
интерфейсы. Тем не менее разработчики могут знать, как низкоуров­
невые системные компоненты выполняют эти требования, несмотря
на то, что они не проявляются на системном уровне.
Таким образом, изучение сценариев особо важно для формирова­
ния общего поведения планируемой системы, при этом оно дает воз­
можность позже определить предполагаемое поведение элементов
более низких уровней, не описывая его на текущем уровне декомпо­
зиции. Поэтому описания сценариев уровнем выше являются более
обобщенными. Они начинают приобретать конкретные детали по
мере того, как разработчики «опускаются» до анализа терминальных
компонентов.
OOSE в проектировании. Как только разработчики определили
сценарии верхнего уровня, они могут обратить свое внимание на тре­
бования этих сценариев, архитектуру и проектировать продукты.
Разработка сценариев. Сценарии описывают последовательность
действий при выполнении задачи или транзакции в приложении.
При создании сценариев проектные группы разрабатывают требова­
ния к функциональности, интерфейсам и работе и фиксируют их для
элементов следующего уровня системной иерархии.
Описания сценариев задают внешнее воздействие на элементы и
их предполагаемые ответные действия. В сценарии эти ответные дей­
ствия добавляются в виде текстового описания, содержащего:
• внешнее представление поведения элемента в ответ на воздейст­
вия через эти интерфейсы;
• внутреннее представление, которое предполагает, как в соответ­
ствии с этим сценарием могут взаимодействовать зависимые подэле-
менты.
Именно в рамках обсуждения внутреннего представления проект­
ная группа определяет, совершенствует и меняет разделение подэле-
ментов в системном представлении.
Описания сценариев. OOSE ограничивает описание внутреннего
представления подэлементами, расположенными на уровне деком­
позиции, непосредственно следующим за уровнем анализируемых
элементов. Например, если разработчики изучают поведение подсис­
темы В, изображенной на рис. 4.6, то они должны рассмотреть внут­
реннее поведение подэлементов С, B l, В2 и D. Однако в этот момент
их не интересует поведение подэлементов С1 и С2.
Проектная группа может предполагать либо знать конкретное по­
ведение или функциональность, которые будут реализованы на более
низких уровнях систем, чем тот, который анализируется в данный
момент. Однако группа должна тщательно следить за тем, чтобы опи-
 Подсистема В(внешняя)

С В1 В2 D
(внутренняя) (внутренняя) (внутренняя) (внутренняя)

Cl С2

Рис. 4.6. Иерархическое внутреннее представление

сания касались только взаимодействия элементов следующего уров­

ня иерархии композиции. Таким образом, следование системной
структуре позволяет гарантировать согласованность проектных ре­
шений на каждом уровне декомпозиции. Там, где это возможно,
группа указывает альтернативные пути выполнения сценариев и ус­
ловия возникновения ошибок и разрабатывает их параллельно с ос­
новными путями.
Проектные решения. Результаты анализа архитектуры для каждого
элемента содержат описание операций логических или физических
компонентов на каждом уровне декомпозиции системы. Эти реше­
ния содержат описания сценариев и вспомогательные диаграммы по­
следовательностей, которые фиксируют предполагаемое взаимодей­
ствие между подэлементами. Диаграммы разбора сценариев по нис­
ходящей описывают назначенную функциональность вспомогатель­
ных подсистем и компонентов. Описания подэлементов фиксируют
глобальные ограничения на элементы более низкого уровня и уста­
новленные для них требования.
Представления процессов (в виде диаграмм активности и диа­
грамм классов) фиксируют зависящие от времени взаимосвязи. На
этом этапе также создаются представления развертывания, соответ­
ствующие этим представлениям процессов.
В этот момент проектная группа может выяснить, что первона­
чально предлагаемая аппаратная конфигурация неадекватна. Тогда
группа меняет системное представление с учетом элементов, которые
были изъяты или перенесены в другие физические элементы. Обнов­
ленное системное представление также фиксирует совместную рабо­
ту низкоуровневых физических компонентов в их новых ролях. Эти
действия приводят к созданию более элегантной по структуре архи­
тектуры, снижая стоимость владения.
Заметим, что проектная группа в процессе анализа не сохраняет
все свои проектные разработки. Она сохраняет их только на том уров­
не, который требуется для поддержки проектных решений, утвержде­
ния операций в сценариях, установки требований и дальнейшего
проектирования. К примеру, для некоторых систем может оказаться
непрактичным создание диаграмм классов для компонентов, являю­
щихся просто искусственными элементами иерархии декомпозиции.
Такие элементы могут выражаться с помощью умышленно расплыв­
чатых системных требований к системе, таких как «выявить и устра­
нить аномалии», «поддерживать систему» или «развернуть систему».
Функциональность компонентов, разработанная в поддержку этих
требований, видима только на самом нижнем уровне декомпозиции
системы. Поэтому проектировать и поддерживать все классы для всех
уровней системы может оказаться попросту неразумно.
Дополнительные требования. Сценарии также определяют, фикси­
руют и назначают требования, связанные с весом, температурой,
электропитанием, размером, полосой пропускания, временем реак­
ции, емкостью и точностью алгоритмов.
Эти ограничения и требования, как правило, возникают и уста­
навливаются в результате нисходящего анализа производительности,
который ведется вне процесса разработки, но согласованно с ним.
Наличие этого дополнительного контекста часто влияет на описание
поведения внутреннего представления и, как следствие, назначение
требований к элементам более низкого уровня. Этот контекст также
ограничивает выбор возможностей на уровне физических компонен­
тов.
Вопросы анализа. OOSE оставляет нерешенными проблемы опи­
сания совместного асинхронного поведения элементов, которое не­
зависимо и непредсказуемо. Например, простор для творчества дает
такая тема, как ограничения UML применительно к попыткам опи­
сать информацию, зависящую от времени.
В рамках OOSE описания сценариев специально упрощаются с
учетом того, что эти методики будут использовать сотрудники, не
знакомые с системной инженерией. Там, где возможно, OOSE ис­
пользует для описаний структурированный английский язык. Это
позволяет сделать информацию более ясной, действия элементарны­
ми и структуру удобной для тестирования. Диаграммы активности
дополняют описания сценариев, изображая асинхронное поведение
системных элементов.
 Из-за часто асинхронной и механической природы проектируе­
мых систем описания сценариев должны фиксировать обе стороны
взаимодействий. К примеру, один из пунктов внутреннего представ­
ления может утверждать, что X -» У(А) (т.е. элемент X общей архитек­
туры управляет функцией А элемента У). Однако многие системы яв­
ляются асинхронными и запрашивающий протокол (как правило,
широковещательная рассылка UDP или сила, приложенная к конст­
рукции) часто существенно отличается от протокола, возвращающе­
го состояние (протокола FTP или механического движения). Описа­
ния сценариев фиксируют дополнительные внутренние пункты, спе­
циально подчеркивающие, что элемент Y выполняет функцию А. Эта
особая тщательность в описании поведения элемента гарантирует
возможность обсуждения уникальных для У(А) вопросов, протоко­
лов, ответных действий, безопасности и тестовых требований, когда
необходимо получить более детальное представление о требованиях к
разработке, ограничениях и ролях компонентов.
Унификация проектных решений. OOSE унифицирует пункты
внутреннего представления сценариев с целью создания возможного
набора сценариев для элементов на следующем уровне декомпозиции
системы. Во время анализа общего понимания и четко сформулиро­
ванных требований к взаимодействию иерархических элементов мо­
жет не быть.
В отличие от диаграмм последовательностей, которые напрямую
связаны с классами, диаграммы последовательностей системного
уровня предоставляют механизм для передачи взаимодействий сис­
темной иерархии. Зачастую подробности, касающиеся подсистем бо­
лее низкого уровня, становятся ясны позже. Они могут изменить пер­
воначальное понимание и, как следствие, заставить перераспреде­
лить функции.
На рис. 4.7 приведен пример декомпозиции сценария от общих
системных требований к элементам более низких уровней. В рамках
этого процесса разработчики расширяют, устраняют избыточность и
меняют представления (сценариев, логическое, процесса разработки,
реализации и системное), добиваясь их согласованности. Затем на
этом этапе формируются итоговые описания, позволяющие опреде­
лить предполагаемое поведение подэлементов.
На этапе расширения ликвидируются возможные пробелы в том,
как аналитики понимают требования, а также в последующем опре­
делении функциональности элементов разных уровней. В этот мо­
мент процесса аналитики задают себе вопрос о том, действительно ли
элементу Y необходимо выполнять функцию А. Они проверяют, дей­
ствительно ли предполагаемое поведение Увезде, где последователь-
 Конкретное

Рис. 4.7. Результаты формирования представления системы

ности сценариев описывают У(А), всегда одно и то же. В результате

этого анализа ставятся новые вопросы и выявляются новые требова­
ния и тем самым решаются проблемы, вызванные неадекватными на­
чальными требованиями.
Этап сокращений устраняет избыточные и аналогичные возмож­
ности. В этот момент процесса аналитики задают вопросы: действи­
тельно ли необходима вся указанная функциональность? Действи­
тельно ли нужны все эти многочисленные варианты? Есть ли общая
нить во всех рассуждениях, которая действительно выделяет предпо­
лагаемые функции? В результате такого анализа удаляется сходная
функциональность и тем самым предотвращается избыточность тре­
бований.
Описания элементов. На этом этапе анализируются результаты
первых двух этапов с тем, чтобы определить сценарии для следующе­
го уровня декомпозиции системы. В этот момент процесса группа
«выявляет» известное или предполагаемое поведение элементов бо­
лее низкого уровня, и это поведение накладывает ограничения на
описания внутреннего представления текущего элемента.
Однако до тех пор, пока анализ не достиг терминального компо­
нента, группе по-прежнему приходится назначать и выполнять де­
композицию этих требований и поведения для следующего уровня
нижележащих элементов. Таким образом, этот шаг определяет и за­
крепляет множество сценариев, которые лучше всего описывают по­
ведение элементов на следующем уровне после уровня текущего эле­
мента.
Для каждого из этих подэлементов следующего уровня по итогам
анализа результат формируется за счет расширения и сокращения
пунктов внутреннего представления, полученного на предыдущем
шаге. Эти пункты становятся пунктами внешнего представления сце­
нариев для подэлементов следующего уровня.
Преимущества унификации. На основе этих результатов фиксиру­
ются требования и ограничения, которые применяются к элементу
глобально. Здесь также фиксируются и решаются вопросы и утвер­
ждаются проектные решения. Кроме того, на этом этапе формирует­
ся рабочий пакет для создания элементов и выявляются требования к
функциональности, производительности, срокам, пропускной спо­
собности, размерам и т. д., которые глобально применяются к данно­
му элементу.
Проектная группа расширяет сценарии уровня элемента, опреде­
ляя взаимодействия подэлементов в сценарии. Унификация и после­
дующая разработка сценариев более низкого уровня выполняются
для каждого уровня декомпозиции системы до тех пор, пока не дос­
тигнет терминальных компонентов.
Преимущества OOSE. Использование этого строгого подхода
имеет определяющее значение для успеха совместной деятельности
группы специалистов разного профиля, работающих над созданием
систем. Описанный строгий подход дает существенные преимущест­
ва для понимания системы и позволяет представить ее детально на
более раннем этапе разработки продукта, чем в подходах, использо­
вавшихся ранее.
Сценарии, которые описывают унаследованные или предпола­
гаемые аппаратные конфигурации, позволяют представить режимы
работы оборудования и их влияние на анализ целей. Они позволяют
сделать это на более ранних этапах процесса проектирования, чем
обычно бывает в таких случаях. Исторически сложилось так, что про­
ектные группы не вникают в такие вопросы практически до самого
конца процесса разработки и делают это лишь на критических этапах
анализа архитектуры или даже позже, при покупке оборудования.
OOSE заставляет проектные группы учитывать влияние аппаратной
конфигурации на архитектуру сразу же, как только это влияние ста­
новится очевидным, что неизбежно вынуждает их либо переписывать
сценарии верхнего уровня и проводить дополнительные исследова­
ния в поисках компромиссных решений, либо вносить изменения в
системное представление.
 В OOSE проектные группы обычно обсуждают функциональ­
ность и производительность после утверждения всех требований к
интерфейсу, работе и производительности вплоть до логических тер­
минальных компонентов. Это позволяет понять и схематически опи­
сать логику системы, подсистем и компонентов на значительно более
ранних этапах. К моменту, когда анализ достигает терминальных
компонентов, программная логика и вспомогательные интерфейсы
часто бывают уже очевидны.
OOSE стимулирует обсуждение вопросов, которые касаются
сборки, интеграции и тестирования, на самых ранних этапах. Про­
ектная группа получает представления об этом влиянии на итоговую
архитектуру системы, подсистем и компонентов максимально рано, а
не ждет критических этапов проектирования или тестирования, когда
бывает слишком поздно вносить исправления в проект. Это эконо­
мит бессчетные часы тестирования и последующей доработки.
Проектная группа может определить сценарии верхнего уровня с
учетом требований и ограничений, накладываемых производствен­
ным процессом. Учет производственных ограничений на итоговую
архитектуру гарантирует, что инженеры и маркетологи не предложат
ничего такого, что невозможно будет осуществить на производстве.
По мере того как проектная группа обсуждает каждый новый уро­
вень иерархии, она определяет взаимодействия операторов компо­
нентов и подсистем и выполняет их системный анализ. Эти действия
гарантируют, что в проекте не только учитываются концепции верх­
него уровня, но и создается архитектура, которая поддерживает дея­
тельность операторов подсистем. В частности, если разработчики бу­
дут откладывать рассмотрение вопросов о взаимодействии операто­
ров подсистем до тех пор, пока продукт не будет развернут, то в
результате может потребоваться серьезная переработка.
Кроме того, подход, закрепленный в OOSE, позволяет учесть тре­
бования, касающиеся процесса обучения, и их влияние на разработку
продукта. Они становятся просто частью процесса проектирования,
как и любые другие ограничения.
СЦЕНАРИИ ВЕРХНЕГО УРОВНЯ
Производство. Эти сценарии касаются различных конфигураций,
возникающих в процессе эволюции системы, от первоначальной
концепции до финального продукта. Требования, предъявляемые к
этим различным конфигурациям, часто приводят к расширению
функциональности элемента, причем в значительно большей степе­
ни, чем предполагалось.
Тестирование. Здесь разработчики определяют сценарии, касаю­
щиеся множества тестовых сред и условий. Зачастую поддержка тес­
товых конфигураций налагает на архитектуру определенные требова­
ния, связанные с оборудованием и контролем. Такие требования ни­
как не проявляются при обычном использовании продукта.
Внедрение. Сценарии этой группы учитывают влияние на архи­
тектуру процедур хранения, обучения, обслуживания и транспорти­
ровки. Во время анализа этих сценариев разработчики часто выявля­
ют взаимодействия операторов подсистем.
Использование. Эти сценарии касаются основных требований,
предъявляемых к архитектуре с тем, чтобы она действительно выпол­
няла предполагаемые для системы функции. Сценарии этой группы
описывают получение команд (физические силы в случае чисто меха­
нической системы), управление системой, генерацию планов работы
системы, выполнение этих планов или алгоритмов, сетевые связи и
хранение результатов этой деятельности.
Обслуживание. Эти сценарии описывают требования к архитекту­
ре, необходимые для поддержки системы. Сценарии описывают на­
чальную загрузку системы и подсистем, выключение, резервное ко­
пирование и восстановление баз данных, а также приостановку рабо­
ты подсистем и повторный запуск («горячая загрузка»). Эти сценарии
также часто предусматривают регулярные модернизации, необходи­
мые для поддержки баз данных и обслуживания физических компо­
нентов, и учитывают их влияние на требования к архитектуре.
Модернизация. Эти сценарии описывают множество способов, с
помощью которых компьютерное оборудование, программное обес­
печение и физические компоненты в различных подсистемах модер­
низируются так, чтобы они могли соответствовать запланированным
требованиям к их работе. Они помогают разработчикам представить
себе требования к архитектуре с учетом поддержки и замены дефект­
ных компонентов.
Исправление. Эти сценарии, как правило, касаются выявления и
устранения аномалий в подсистемах. Они также содержат планы дей­
ствий по устранению дефектов в подсистемах и учитывают их влия­
ние на архитектуру.

4 .2 . ИНФОРМАЦИОННО-ЛОГИЧЕСКАЯ МОДЕЛЬ АСУ

Неоднородность (разнородность) информационных ресурсов ха­

рактерна для многих предметных областей автоматизированного
управления.
Основной задачей данного вида модели является разбиение пред­
метной области на составные части путем декомпозиции, осуществ­
ляемой по определенным правилам.
 В настоящее время существуют два основных подхода к этому
процессу, отличающихся критериями декомпозиции: функциональ-
но-модульный (структурный) и объектно-ориентированный.
Функционально-модульный подход основан на принципе алгорит­
мической декомпозиции с выделением функциональных элементов и
установлением строгого порядка выполняемых действий, т. е. в осно­
ве лежит иерархический подход с выделением вначале функциональ­
ных действий, далее независимых компонентов и дальнейшей их де­
тализации.
Объектно-ориентированный подход основан на объектной деком­
позиции с описанием поведения системы в терминах взаимодействия
объектов.
Главным недостатком функционально-модульного подхода явля­
ется однонаправленность информационных потоков и недостаточ­
ная обратная связь. В случае изменения требований к системе это
приводит к полному перепроектированию, поэтому ошибки, зало­
женные на ранних этапах, сильно сказываются на времени и стоимо­
сти разработки. Другой важной проблемой является неоднородность
информационных ресурсов, используемых в большинстве информа­
ционных систем. В силу этих причин в настоящее время наибольшее
распространение получил объектно-ориентированный подход [26].
Кратко рассмотрим его основные положения.
Декомпозиция на основе объектно-ориентированного подхода
основана на выделении следующих основных понятий:
Объект — это абстракция множества предметов реального мира,
обладающих одинаковыми характеристиками и законами поведения.
Объект характеризует собой типичный неопределенный элемент та­
кого множества. Основной характеристикой объекта является состав
его атрибутов (свойств).
Атрибуты — это специальные объекты, посредством которых
можно задать правила описания свойств других объектов.
Экземпляр объекта — это конкретный определенный элемент
множества. Например, объектом может являться государственный
номер автомобиля, а экземпляром этого объекта — конкретный но­
мер К 173 ПА.
Класс — это множество предметов реального мира, связанных
общностью структуры и поведением. Элемент класса — это конкрет­
ный элемент данного множества. Например, класс регистрационных
номеров автомобиля.
Обобщая эти определения, можно сказать, что объект — это ти­
пичный представитель класса, а термины «экземпляр объекта» и
 Класс Типичный Объект
представитель
Множество предметов Типичный
реального мира, Соответствует неопределенный
обладающих общностью элемент данного
структуры и поведения множества предметов
Множество Л Обобщение
Предмет
Конкретный
- Состоит ИЗ -I <— Обобщает -
предмет
реального мира
Элемент Экземпляр

Рис. 4.8. Отношения между классами, объектами и предметами

«элемент класса» равнозначны. На рис. 4.8 показаны отношения ме­

жду классами, объектами и предметами реального мира.
Важная особенность объектно-ориентированного подхода свя­
зана с понятием инкапсуляции, обозначающим сокрытие данных и
методов (действий с объектом) в качестве собственных ресурсов
объекта.
Понятия полиморфизма и наследования определяют эволюцию
объектно-ориентированной системы, что подразумевает определе­
ние новых классов объектов на основе базовых классов.
Полиморфизм интерпретируется как способность объекта принад­
лежать более чем одному типу.
Наследование выражает возможность определения новых классов
на основе существующих с возможностью добавления или переопре­
деления данных и методов.
Модель представления информации о предметной области — это
синтаксически и семантически определенная средствами ядра сово­
купность конфигураций, позволяющая описывать, анализировать и
документировать заданные аспекты проектируемой системы на за­
данных стадиях разработки с различными уровнями детализации ее
элементов. В основе ядра моделей представлений лежат функцио­
нальные спецификации
Функциональные спецификации — это часть исходных данных для
проектирования автоматизированной системы, определяющая, что
должна сделать система и как она должна быть взаимосвязана с окру­
жением.
Основа описания модели представления — граф, отражающий ти­
пизированные связи между типизированными компонентами. Каж­
дый компонент представляется парой: <имя типа>; <имя компонен­
тах
 Каждая связь представляется пятеркой: <имя типа>; <имя ис­
ходного компонента>; <имя вида отношения>; <имя типа>; <имя свя­
занного компонента>.
Определим составляющие, используемые при анализе предмет­
ной области.
Метаобъекты — это базовые компоненты для конструирования
модели предметной области.
Виды элементов — это экземпляры конкретного метаобъекта.
Модель представления конкретной предметной области есть опи­
сание совокупности видов элементов и их взаимосвязей.
Элемент — это экземпляр вида элемента.
Конкретные проектные данные, полученные при анализе пред­
метной области, представляются в виде совокупности элементов и их
разнообразных взаимосвязей.
Используется три вида цепочек связей:
• <метаобъект>. <имя метаобъекта> — описание структуры мета­
объектов;
• <имя метаобъекта>. <имя вида элемента> — описание структуры
видов элементов;
• <имя вида элементах <имя элемента> — описание связей эле­
ментов.
Конфигурация определяется как граф, представляющий интере­
сующий разработчика аспект проектируемой системы. Вершинам
этого графа ставятся в соответствие элементы различных видов сис­
темы. Дугам графа ставятся в соответствие интересующие отношения
между элементами. С дугами и вершинами могут быть связаны разно­
образные количественные меры, задаваемые соответствующими
функциями принадлежности.
Структура — прочная, относительно устойчивая связь (отноше­
ние) и взаимодействие элементов, сторон, частей предмета, явления,
процесса как целого. В нашем случае структура — это совокупность
конфигураций. Таким образом, структура системы определяется че­
рез множество выбранных видов элементов, множество элементов,
множество рассматриваемых видов отношений и множество функ­
ций принадлежности, характеризующих количественно связи эле­
ментов.
Ядро — это система понятий, посредством которой можно опреде­
лять интересующие разработчика конфигурации и структуры проек­
тируемой системы. Основными понятиями ядра являются:
• вид элемента — определяет устойчивый для конкретной пред­
метной области набор свойств, объединяющий конкретные проекти­
руемые компоненты в группы;
 in
Рис. 4.9. Ядро моделей представления функциональных спецификаций АСУ

• вид отношения — определяет устойчивые для конкретной пред­

метной области группы связей между проектируемыми компонента­
ми;
• отношение — определяется видами элементов, вступающими во
взаимосвязь и видом отношения, задающим семантику связей.
Ядро позволяет описывать требуемые виды отношений, виды эле­
ментов и отношения.
На рис. 4.9 приведена схема ядра моделей представления функ­
циональных спецификаций АСУ.
Предлагается ввести три основные модели представления для
описания информации о предметной области:
• функциональная модель (ФМ);
• модель данных (МД);
• логика.
Модели представления в качестве основных используют следую­
щие виды элементов:
• действие;
• данное;
• система;
• объект;
• атрибут.
Функциональная модель ориентирована на описание систем, спо­
собных выполнять действия над данными.
Модель данных ориентирована на описание структуры информа­
ционных объектов, их функциональных взаимосвязей, необходимых
для поддержания заданных действий.
Указанные две модели взаимно дополняют друг друга, разрабаты­
ваются совместно и не требуют привлечения понятий языков про­
граммирования высокого уровня.
 Учебные планы Работа Расписание
с расписанием
ч
д 02-УчПом
Учебные помещения -
бд 05-Расп ф 01-СпрРасп
д 03-Преп
Преподаватели D -. -С □ ------
Расписание Справки по расписанию
д 04-Запр
Запросы

Рис. 4.10. Схема внешних информационных связей

Логика ориентирована на описание потока управления (последо­

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

call w 02-СостРасп
Составление
расписания

w 03-КорРасп
Коррекция
расписания

w 04-0бр3апр
Обработка запросов
к расписанию
документов. Все действия желательно фиксировать в виде определен­
ных документов на бумаге или в памяти компьютера. Форма фикса­
ции может быть любая: структурная схема, блок-схема, таблица и

об Пом

Рис. 4.13. Схема классифика- Рис. 4.14. Схема классифика­

ции расписания ции помещения
 Рис. 4.15. Схема классификации запросов к расписанию

т. д., например, можно использовать д 01-СпрРасп

следующие виды документов: схема
внешних информационных связей, схе­
ма детализации действия, схема потоков
данных, схема классификации, схема де­
тализации.
Рассмотрим пример анализа пред­
метной области. Выберем область дея­
тельности, знакомую всем студентам, —
учебный процесс. Предположим, нам
поручили разработать информационную
систему «Расписание занятий». Исполь­
зуем предложенные типы документов.
1. Схема внешних информационных
связей (рис. 4.10). Действие — рабо-
та_с_расписанием.
2. Схема детализации действия (рис.
4.11). Действие — работа_с_расписани-
ем.
3. Схема потоков данных (рис. 4.12).
Действие — работа_с_расписанием.
4. Схема классификации (рис. 4.13).
Объект — пользователи расписания.
5. Схема классификации (рис. 4.14). Рис. 4.16. Схема детализации
Объект — помещение. справок о расписании
 Рис. 4.17. Схема классификации расписания

6. Схема классификации (рис. 4.15). Данные — запросы к распи­

санию.
7. Схема детализации (рис. 4.16). Данные — справки по расписа­
нию.
8. Схема классификации (рис. 4.17). Данные — справки по распи­
санию.

4 .3 . ФУНКЦИОНАЛЬНАЯ МОДЕЛЬ АСУ

При построении функциональной модели (ФМ) основополагаю­
щими являются три аспекта рассмотрения:
• функциональный;
• информационный;
• организационный.
Функциональный аспект отражает то, что должна выполнять (вы­
полняет) проектируемая система. Основным видом элементов в этом
случае выступает действие.
 Действие определяется как деятельность, направленная на дости­
жение определенного результата. Этот результат связан со значения­
ми данных. В дальнейшем ограничимся рассмотрением лишь дис-
кретныхдействий. Для каждого дискретного действия можно опреде­
лить моменты времени его начала и завершения.
Действие предполагает наличие объектов действий, под которы­
ми будем понимать данные. Будем считать, что всякий результат дей­
ствия может быть выражен через соответствующее значение данных.
Информационный аспект характеризует состав и структуру данных
как объектов действий, составляющих информационный фонд сис­
темы. Основными видами элементов в данном случае являются дан­
ные.
Данные определяются как информация об объектах, которая хра­
нится, перемещается и изменяется путем выполнения действий.
Организационный аспект характеризует структуру исполнитель­
ных элементов системы, которые способны выполнять заданные дей­
ствия над заданными данными и поддерживают ее информационный
фонд. Основным видом элементов в этом случае является система.
Система определяется как исполнительный элемент, способный
во взаимодействии с другими системами выполнять заданные дейст­
вия над заданными данными и обеспечить их хранение.
Отметим основные отношения (конфигурации) функциональной
модели.
Идентификатор каждой конфигурации будем образовывать сле­
дующим образом: <имя вида элем ентаХ пробелХ им я вида отноше-
н ияХ про б ел Х им я вида элементах
В качестве основных видов отношений для описания ФМ исполь­
зуют следующие:
• требует (call);
• состав (composition) (contain);
• вход (in);
• выход (out);
• использует (use);
• предоставляет (let);
• класс (class).
Вид отношения требует определяет необходимость существова­
ния элементов одного вида для реализации элементов исходного
вида. Строя схему требований конкретного элемента, надо ответить
на вопрос: «Какие элементы необходимо иметь, чтобы реализовать
заданный элемент»?
 Вид отношения состав определяет включение одних элементов в
состав других. Каждый элемент может входить в состав только одного
элемента.
Вид отношения вход указывает на то, что некоторый информаци­
онный элемент используется как аргумент без изменения его значе­
ния.
Вид отношения выход указывает на то, что некоторый информа­
ционный элемент используется как результат с изменением его зна­
чения.
Вид отношения использует указывает на элементы, которые тре­
буются для заданного элемента, но не входят в его состав. *
Вид отношения предоставляет указывает на элементы, которые
входят в состав заданного элемента, но предоставляются для исполь­
зования другими элементами из его окружения.
Используя введенные виды отношений и виды элементов, опи­
шем следующие отношения для представления ФМ:
• ДЕЙСТВИЕ требует ДЕЙСТВИЕ (W call W);
• ДЕЙСТВИЕ вход ДАННЫЕ (W in D);
• ДЕЙСТВИЕ выход ДАННЫЕ (W out D);
• СИСТЕМА состав СИСТЕМА (S comp S);
• СИСТЕМА состав ДЕЙСТВИЕ (S comp W);
• СИСТЕМА состав ДАННЫЕ (S comp D);
• СИСТЕМА вход ДАННЫЕ (S in D);
• СИСТЕМА выход ДАННЫЕ (S out D);
• СИСТЕМА предоставляет ДАННЫЕ (S let D);
• СИСТЕМА предоставляет ДЕЙСТВИЕ (S let W);
• СИСТЕМА использует ДЕЙСТВИЕ (S use W);
• ДЕЙСТВИЕ класс ДЕЙСТВИЕ (W class W);
• СИСТЕМА класс СИСТЕМА (S class S);
• ДАННОЕ класс ДАННЫЕ (D class D).
Семантическая диаграмма функциональной модели приведена на
рис. 4.18.
Основным в функциональной модели является отношение
ДЕЙСТВИЕ требует ДЕЙСТВИЕ. Графическое представление этого
отношения назовем СХЕМОЙ ТРЕБОВАНИЙ ДЕЙСТВИЙ. Схема
требований действий для каждого действия показывает множество
действий, которые необходимы для выполнения заданного действия.
Отношение ДЕЙСТВИЕ вход ДАН НЫ Е определяет входные дан­
ные для каждого действия.
Отношение ДЕЙСТВИЕ выход ДАННЫЕ определяет выходные
данные для каждого действия.
 class
кл Об
Объект
key кл Ат
Атрибут
kji БТ кл Фт
class
Базовый тип Формат
out
кл ВС /[\кл Пар
Вид связи Параметр
class J
Рис. 4.18. Семантическая диаграмма функциональной модели

Совместно эти два отношения задают информационные связи дей­

ствий. ^граф ическое представление назовем ИНФОРМАЦИОННОЙ
СХЕМОЙ. Для каждого отдельного действия указанных два отношения
в графическом представлении задают схему внешних информацион­
ных связей. Если объединить схемы внешних информационных свя­
зей всех действий, которые непосредственно связаны с некоторым
действием в схеме требований, то получим схему потоков данных
действия.
Особое место занимают схемы классификации систем, действий
и данных, задаваемые соответствующими отношениями. Схемы
классификации уже на ранних стадиях проектирования позволяют
зафиксировать информацию об общих свойствах компонентов про­
ектируемой системы.
Состав видов элементов функциональной модели может расши­
ряться. Обычно такое расширение осуществляется путем введения
потомков уже имеющихся видов. Например, предлагается рассматри­
вать три вида процедурных элементов (действий):
• функциональная область;
• процесс;
• функция.
Для всех потомков сохраняется преемственность свойств родителя.
Поэтому все виды связей, указанные для вида элемента-родителя,
справедливы и для видов элементов- потомков. Применительно к при­
меру справедливы, например, следующие отношения: СИСТЕМА со­
став ПРОЦЕСС, ПРОЦЕСС вход ДАННЫЕ и др.
Рассмотрим возможные стратегии построения схем требований
действий:
 • построение дерева требований;
• построение сети требований.
Построение дерева требований включает в себя следующие шаги:
• функциональное назначение проектируемой системы опреде­
ляется путем перечисления не более 10 действий;
• для каждого действия независимо определяется не более 10 дей­
ствий, которые необходимы, по мнению разработчика, для реализа­
ции заданного действия;
• последовательно выполняя п. 2 для вновь вводимых действий,
добиваемся необходимой степени детализации. Действие не требует
дальнейшей детализации, если его реализация уже существует или
известна, или реализация действия проста и понятна разработчикам.
Дерево требований наглядно представляется в виде иерархии схем
требований.
Построение сети требований отличается от построения дерева
требований тем, что на каждом шаге детализации необходимо выби­
рать поддерживающие действия с учетом всего множества объявлен­
ных действий.
Декомпозиция действий представляется в виде схем требований
действий, а декомпозиция данных — в виде схем состава данных. Рас­
смотрим основные схемы декомпозиции действий и данных ФМ.
1. Декомпозиция действий на основе состава выходных данных. Це­
левое назначение действия отражается в составе выходных данных.
Если выходные данные по своему содержанию разнородны, то с каж­
дым элементом выходных данных можно связать свое действие. Каж­
дое из вновь введенных действий войдет в схему требований исходно­
го действия.
2. Декомпозиция действий на основе входных данных. В некоторых
случаях определяющим для детализации действий является состав
входных данных. Если известен состав входных данных и можно каж­
дый элемент входных данных интерпретировать как задание на за­
данную обработку.
3. Декомпозиция действий на основе представлений о промежуточ­
ных результатах. Для каждого выходного данного надо ответить на во­
прос: «Какие исходные данные необходимы для получения соответ­
ствующего результата»? Выполняем указанную операцию для всех
вновь введенных данных, пока информационная цепочка не замк­
нется на входных данных детализируемого действия. Далее с каждым
вновь введенным данным и выходным данным детализируемого дей­
ствия связываем соответствующее действие, рассматривая данные
как выходные.
 4. Декомпозиция действий на основе представлений о фазах обра­
ботки. Данная схема декомпозиции требует указать последователь­
ность действий, приводящих к желаемому результату. В качестве вы­
ходных данных последнего действия последовательности выступает
выходное данное исходного действия. В качестве входного данного
первого действия последовательности выступает входное данное ис­
ходного действия.
5. Декомпозиция действий на основе представлений об альтернатив­
ных действиях. Данная схема декомпозиции предполагает наличие
нескольких вариантов для получения искомого результата. В соответ­
ствии с каждым вариантом вводится новое действие и производится
декомпозиция входных данных.
Возможны преобразования ФМ на основе анализа информацион­
ной связности действий и схем требований действий (агрегирование
действий на основе анализа их информационной связности). Для
анализа рекомендуется такая последовательность действий.
1. Выбирается действие на одном из верхних уровней детализа­
ции.
2. Отбираются все действия, входящие в схему требований исход­
ного действия одного уровня детализации.
3. Для полученного подмножества действий также отбираются все
действия, входящие в соответствующие схемы требований одного
уровня детализации.
4. Для полученного подмножества действий второго уровня дета­
лизации строится информационная схема.
5. Оценивается информационная прочность действий первого
уровня детализации.
6. Проводится анализ информационной связности действий вто­
рого уровня детализации и выделяются информационно сильно свя­
занные области.
7. Если прочность новых групп действий больше прочности дей­
ствий первого уровня детализации, то:
а) действия первого уровня детализации удаляются из схемы тре­
бований исходного действия;
б) объявляются новые действия на основе выделенных групп дей­
ствий;
в) новые действия включаются в схему требований исходного дей­
ствия;
г) строятся новые схемы требований для вновь объявленных дей­
ствий на основе состава сильно связанных областей.
9-2742 129
 Разработку ФМ рекомендуется выполнять в такой последователь­
ности:
1. Строится схема внешних информационных связей исходного
действия.
2. С использованием подходящих вариантов декомпозиции стро­
ится дерево требований действий. Рекомендуется, чтобы число тре­
буемых действий на каждом уровне детализации не превышало 10.
3. Для каждого вновь объявленного действия разрабатывается
схема внешних информационных связей.
4. Проверяется возможность преобразований полученной функ­
циональной модели путем:
• декомпозиции действий с использованием процедурной абст­
ракции (путем классификации действий и на этой основе изменения
состава декомпозиции);
• агрегирования действий на основе анализа их информационной
взаимосвязи.

4 .4 . ФУНКЦИОНАЛЬНЫЙ АНАЛИЗ НА ОСНОВЕ

БИЗНЕС-ПРОЦЕССОВ

Прежде чем перейти к изложению методики функционального

анализа на основе бизнес-процессов, раскроем основные термины.
Анализ бизнес-процесса — комплекс работ по изучению деятельно­
сти организации, направленный на получение информации о теку­
щем состоянии заданного бизнес-процесса, позволяющей оценить
бизнес-процесс по отношению к требованиям, предъявляемым к его
функционированию, управлению, эффективности, выходам и степе­
ни удовлетворенности клиента.
Бизнес-процесс — устойчивая, целенаправленная совокупность
взаимосвязанных видов деятельности (последовательность работ),
которая по определенной технологии преобразует входы в выходы,
представляющие ценность для потребителя.
Владелец бизнес-процесса — должностное лицо, которое имеет в
своем распоряжении персонал, инфраструктуру, программное и ап­
паратное обеспечение, информацию о бизнес-процессе, управляет
ходом бизнес-процесса и несет ответственность за результаты и эф­
фективность бизнес-процесса.
Вход бизнес-процесса — ресурс, обеспечиваемый внешним постав­
щиком.
 Выход бизнес-процесса — результат (продукт, услуга) выполнения
бизнес-процесса.
Документооборот — система документального обеспечения дея­
тельности предприятия.
Заказчик — должностное лицо, имеющее ресурсы и полномочия
для принятия решения о проведении работ по описанию, регламента­
ции или аудиту (проверке) бизнес-процесса.
Информационный поток (поток данных) — движение информации
от одной работы бизнес-процесса к другой.
Модель бизнес-процесса — графическое, табличное, текстовое,
символьное описание бизнес-процесса либо их взаимосвязанная со­
вокупность.
Нотация — см. формат описания бизнес-процесса.
Отчет по аудиту — документ, содержащий информацию о ре­
зультатах анализа бизнес-процесса и рекомендации по улучшению
деятельности бизнес-процесса.
Показатели бизнес-процесса — количественные и/или качествен­
ные параметры, характеризующие бизнес-процесс и его результат.
Показатели эффективности бизнес-процесса (ПЭ) — параметры
бизнес-процесса, характеризующие взаимоотношение между достиг­
нутым результатом и использованными ресурсами.
Показатели продукта (услуги) (ПП) — параметры продукта биз­
нес-процесса.
Показатели (данные) удовлетворенности клиента (потребителя)
(ДУК) — параметры, характеризующие удовлетворенность клиента.
Поставщик — субъект, предоставляющий ресурсы.
Потребитель (клиент) — субъект, получающий результат биз­
нес-процесса. Потребитель может быть:
а) внутренний — находящийся в организации и в ходе своей дея­
тельности использующий результаты (выходы) предыдущего биз­
нес-процесса;
б) внешний — находящийся за пределами организации и исполь­
зующий результат (выход) бизнес-процесса.
Проверка адекватности модели бизнес-процесса — работа по ана­
лизу модели бизнес-процесса на соответствие реально существующе­
му в организации бизнес-процессу.
Проверка корректности модели бизнес-процесса — работа по анали­
зу соответствия исполнения модели бизнес-процесса утвержденным
требованиям по оформлению.
Операция (работа) — часть бизнес-процесса, имеющая вход и вы­
ход.
 Регламент бизнес-процесса — документ, описывающий последо­
вательность операций, ответственность, порядок взаимодействия ис­
полнителей и порядок принятия решений по улучшениям.
Ресурсы — информация (документы, файлы), финансы, материа­
лы, персонал, оборудование, инфраструктура, среда, программное
обеспечение, необходимые для выполнения бизнес-процесса и нахо­
дящиеся в распоряжении владельца бизнес-процесса.
Структура ответственности — распределение ответственности
за выполняемые в рамках бизнес-процесса операции и принимаемые
решения между сотрудниками организации.
Функция — совокупность однородных операций (в том числе раз­
ных бизнес-процессов), выполняемых структурным подразделением
на постоянной основе.
Формат описания бизнес-процесса (нотация) — способ формирова­
ния графической модели бизнес-процесса.
Сокращения:
IDEF О (FI PS 183 США «Integration definition for function modeling
(IDEFO)») — «Интеграционное определение для моделирования
функций»;
IDEF 3 (workflow modeling, Process Description Capture Method) —
методология описания бизнес-процессов (потоков работ);
DFD (Data Flow diagramming) — модель бизнес-процесса, состав­
ленная по принципу отражения потоков данных;
УР — управление развития компании.
Понятие бизнес-процесса, операции и их иерархий поясняет
рис. 4.19.
Отнесение деятельности к категории «бизнес-процесс» или «опе­
рация» зависит от уровня рассмотрения. Уровень детализации описа-
ния бизнес-процесса определяет владелец бизнес-процесса совмест­
но с разработчиками автоматизированной системы. Важным момен­
том является определение целей описания бизнес-процессов. В табл.
4.1 приведен возможный вариант формирования таких целей для раз­
личных уровней представления.
Таблица 4.1

Номер Уровень Содержание бизнес-процесса

операции управления
1.1 Руководители Формирование эффективной системы управления на
верхнего уровня основе бизнес-процессов
1.2 Четкое разграничение ответственности и полномочий
между руководителями и подразделениями в рамках биз­
нес-процессов
1.3 Разработка показателей эффективности бизнес-про­
цессов и методик их оценки и анализа
1.4 Создание механизмов (процедур и методик) повыше­
ния и оперативности бизнес-процессов
1.5 Создание и внедрение автоматизированной системы
управления
2.1 Руководители Разработка нормативных документов, регламенти­
среднего звена рующих бизнес-процессы
2.2 Создание механизмов (процедур и методик) непре­
рывного улучшения бизнес-процессов
2.3 Обучение персонала по вопросам, связанным с уча­
стием в бизнес-процессах
2.4 Подготовка персонала к внедрению и эксплуатации
автоматизированной системы управления
3.1 Специалисты Создание инструкций и методик, определяющих дея­
тельность специалистов в рамках бизнес-процессов
3.2 Подготовка к внедрению и эксплуатации автоматизи­
рованной системы управления

При описании бизнес-процесса на верхнем уровне (рис. 4.20) в

обязательном порядке должны быть определены:
• название бизнес-процесса;
• входы бизнес-процесса;
• выходы бизнес-процесса;
• исполнитель: структурные подразделения, отдельные работни­
ки, внешние (по отношению к организации) исполнители;
• управляющие входы бизнес-процесса: нормативные, организа ­
ционно-распорядительные.
 Входы Выходы
бизнес- бизнес-
процесса процесса
Бизнес-процесс

Исполнитель

Рис. 4.20. Бизнес-процесс на верхнем уровне

Описание бизнес-процессов должно сопровождаться разработ­

кой ряда документов, например, таких, как:
• положения, должностные и рабочие инструкции;
• спецификация операций бизнес-процесса;
• спецификации входов/выходов;
• спецификации на ресурсы;
• графические схемы бизнес-процесса и их текстовое описание;
• показатели бизнес-процесса;
• глоссарий;
• перечень документов бизнес-процесса;
• альбом документов бизнес-процесса.
При описании бизнес-процесса должна быть собрана информа­
ция, приведенная в табл. 4.2.
Таблица 4.2

Номер Характеристика Информация по бизнес-процессу, подлежащая

процесса бизнес-процесса сбору
1 Название и назна­ Название бизнес-процесса. Назначение биз-
чение бизнес-про- нес-процесса. Заказчик работ по описанию биз­
цесса нес-процесса
2 Информация о Полное и сокращенное название подразделения
подразделении или (или подразделений), выполняющего бизнес-про-
подразделениях цесс или участвующего в выполнении бизнес-про-
цесса. Схема организационной структуры подразде­
ления
3 Владелец биз- Должность, приложение, ссылка на должностную
нес-процесса инструкцию владельца бизнес-процесса или поло­
жение о подразделении, или на распорядительный
документ, определяющий сферу ответственности
владельца бизнес-процесса
4 Основные опера­ Перечень основных операций, выполняемых при
ции проведении бизнес-процесса, и ответственные за их
выполнение в подразделении
 Номер Характеристика Информация по бизнес-процессу, подлежащая
процесса бизнес-процесса сбору
5 Клиенты и выходы Перечень клиентов бизнес-процесса с указанием
бизнес-процесса получаемых ими выходов
5.1 Выход первого Выходы бизнес-процесса: продукт, услуга, доку­
бизнес-процесса мент, информация. Краткая спецификация выхода
или ссылка на нее. Потребитель (указывается, кто
является потребителем данного выхода бизнес-про­
цесса)
5.2 Выход второго Выходы бизнес-процесса: продукт, услуга, доку­
бизнес-процесса мент, информация. Краткая спецификация выхода
или ссылка на нее. Потребитель (указывается, кто
является потребителем данного выхода бизнес-про­
цесса)
6 Входы бизнес-про- Входы бизнес-процесса и их поставщики
цесса и их поставщики
6.1 Вход первого биз- Входы бизнес-процесса: продукт, услуга, доку­
нес-процесса мент, информация. Краткая спецификация входа
или ссылка на нее. Поставщик (указывается, кто яв­
ляется поставщиком данного входа или внешним
инициатором действий в данном подразделении)
6.2 Вход второго биз- Входы бизнес-процесса: продукт, услуга, доку­
нес-процесса мент, информация. Краткая спецификация входа
или ссылка на нее. Поставщик (указывается, кто яв­
ляется поставщиком данного входа или внешним
инициатором действий в данном подразделении)
7 Ресурсы 1.Перечисляются ресурсы, которые используются
при проведении бизнес-процесса. Краткая специ­
фикация на каждый ресурс или ссылка на документ,
где приведена.
2. Поставщик данного ресурса
8 Графические схемы Графические схемы и текстовое описание биз-
бизнес-процесса и их нес-процесса
текстовое описание
9 Показатели биз- Заполняются указанные ниже составляющие по­
нес-процесса казателей
9.1 Показатели биз- 1. Заполняются названия количественных показа­
нес-процесса телей, характеризующих ход бизнес-процесса, абсо­
лютные и/или относительные затраты на его прове­
дение.
2. Ссылка на документ, где зафиксирован данный
показатель и методика его расчета (или описание
этой методики).
3.Использование показателя для:
а) принятия управленческих решений;
б) отчета перед вышестоящим руководителем
 Номер Характеристика Информация по бизнес-процессу, подлежащая
процесса бизнес-процесса сбору
9.2 Показатели про­ Заполняются названия количественных показате­
дукта бизнес-про­ лей, характеризующих продукт (выход) бизнес-про-
цесса цесса
9.3 Показатели удов­ Заполняются названия количественных показате­
летворенности и по­ лей, по которым можно оценить степень удовлетво­
требителя биз- ренности потребителя (заказчика) результатами
нес-процесса бизнес-процесса
10 Глоссарий терми­ Термины, используемые при выполнении биз­
нов нес-процесса
11 Перечень доку­ Перечень и краткое описание документов, ис­
ментов бизнес-про­ пользуемых при выполнении, описании и регламен­
цесса тации бизнес-процесса

Выбор формата для описания рассматриваемого бизнес-процесса

определяется масштабом и степенью его детализации. Выделяется
несколько уровней детализации бизнес-процесса:
• 1-й условный уровень: бизнес-процесс организации в целом, ре­
комендуемая глубина детализации 2—3 уровня;
• 2-й условный уровень: бизнес-процесс подразделения организа­
ции (возможна детализация операций бизнес-процесса 1-го уровня),
рекомендуемая глубина детализации 2—3 уровня;
• 3-й условный уровень: бизнес-процесс рабочего места подразде­
ления (возможна детализация операций бизнес-процесса 2-го уров­
ня), рекомендуемая глубина описания 1—2 уровня.
Уровень детализации модели бизнес-процесса является услов­
ным понятием, определяемым для задач разработки моделей биз­
нес-процесса. Для целей регламентации бизнес-процесса должен
быть выбран уровень описания, удобный для понимания выполняе­
мых операций всеми участниками бизнес-процесса. Каждый биз-
нес-процесс может быть детализирован в модели от верхнего уровня
до нижнего, если это целесообразно. Целесообразность детализации
модели определяет владелец бизнес-процесса совместно с разработ­
чиками автоматизированной системы. Они осуществляют выбор
цели и формата описания бизнес-процесса.
В зависимости от поставленных целей для описания бизнес-про-
цессов используются рекомендуемые форматы принятых стандартов
(табл. 4.3).
На рис. 4.21 представлена последовательность формирования мо­
делей бизнес-процесса.
№ п/п Задача описания Тип модели Используемый
бизнес-процесса формат
1 Описание бизнес-процес- 1. Функциональная мо­ 1DEF0
са уровня организации дель бизнес-процесса
2. Модель потоков дан­ DFD
ных
2 Регламентация бизнес- 1. Функциональная мо­ IDEF0
процесса уровня организа­ дель бизнес-процесса
ции 2. Модель потока работ IDEF3
3. Модель потока дан­ D FD
ных
3 Описание бизнес-процес­ 1. Функциональная мо­ IDEF0
са уровня структурного под­ дель бизнес-процесса
разделения 2. Модель потока работ IDEF3
3. Модель потока дан­ D FD
ных
4 Разработка регламента 1. Модель потока работ 1DEF3
выполнения бизнес-процес­ 2. Модель потока дан­ DFD
са структурного подразделе­ ных
ния
5 Описание бизнес-процес­ Модель потока работ IDEF3
са для рабочего места испол­
нителя
6 Разработка регламента Модель потока работ IDEF3
выполнения бизнес-процес­
са для рабочего места испол­
нителя

Рассмотрим правила формирования моделей бизнес-процессов в

IDEF0. Функциональная модель бизнес-процесса (IDEF0) представ­
ляет бизнес-процесс как совокупность выполняемых функций (на­
правлений деятельности). Для определяемого в каждом конкретном
случае уровня детализации модели функции должны рассматривать­
ся уже как операции, выполняемые в ходе бизнес-процесса. На ниж­
нем уровне модели в качестве функций рассматриваются отдельные
операции. Модель IDEF0 рекомендована к применению при описа­
нии бизнес-процессов на верхнем уровне.
При составлении функциональной модели бизнес-процесса
(IDEF0) описываются выполняемые функции и входные, выходные
потоки материальных, финансовых ресурсов и информации (доку­
ментов, файлов).
При описании бизнес-процесса одновременно могут применять­
ся комбинации различных моделей IDEFO, IDEF3 и DFD. Модель в
IDEF0 можно декомпозировать на модели IDEF3 и DFD.
 Рис. 4.21. Последовательность формирования моделей бизнес-процесса

Условные обозначения формата IDEF0 представлены в табл. 4.4.

На диаграмме IDEF0 стрелки связывают выполняемые функции.
Стрелки-входы обозначают материальные, финансовые и информа­
ционные ресурсы, которые преобразуются функцией. Стрелки-выхо­
ды обозначают материальные, финансовые и информационные ре­
сурсы, являющиеся результатом выполнения функции. Стрел­
ки-управления обозначают правила, стандарты, указания, нормати­
вы и т. д., в соответствии с которыми выполняется функция. Каждая
функция должна иметь хотя бы одну стрелку-управление. Стрел­
ки-управления изображают только входящими в верхнюю грань бло-
 № Наименование Графическое
Описание
п/п представление
1 Модуль поведе­ Объект служит для описания функций
/
ния (функции (операций, работ), выполняемых подраз­
или операции) делениями/сотрудниками предприятия

2 Стрелка слева Стрелка описывает входы функции

г ...........
(операции)

3 Стрелка справа Стрелка описывает выходы функции / ...........

(операции)

4 Стрелка сверху Стрелка описывает управляющие воз­

действия, например распоряжение,
нормативный документ и т.д.
5 Стрелка снизу Стрелка снизу описывает нерасходуемые /
ресурсы (например, персонал), исполь­
зуемые для выполнения бизнес-
процесса t
ка, обозначающего функцию. Стрелки-механизмы обозначают сред­
ства выполнения функций: персонал, оборудование, станки, устрой­
ства, информационные системы и т. д. Стрелки показывают верти­
кальными и горизонтальными отрезками прямых с наконечником на
одном конце, пересекающиеся под прямым углом и сопряженные ду­
гами. Стрелки соединяются с блоком следующим образом:
• концы стрелок должны касаться внешней стороны блока, но не
пересекать ее;
• стрелки должны подсоединяться к блоку на его сторонах, при­
соединение в углах не допускается.
При изображении стрелок допускаются их слияние и разветвле­
ние. В случае разветвления стрелок их именование и создание меток
подчиняются следующим правилам:
• если стрелка именована до разветвления, а после разветвления
ни одна из ветвей не именована, то подразумевается, что каждая ветвь
моделирует те же данные или объекты, что и ветвь до разветвления;
• если стрелка именована до разветвления, а после разветвления
какая-либо из ветвей не именована, то подразумевается, что она мо­
делирует те же данные или объекты, что и до разветвления;
• недопустима ситуация, когда до разветвления стрелка не имено­
вана, а после разветвления не именована какая-либо из ветвей.
 Правила именования сливающихся стрелок полностью аналогич­
ны. В рамках одной диаграммы существует шесть типов отношений
между блоками: доминирование, управление, выход — вход, обратная
связь по управлению, обратная связь по входу, выход — механизм.
Блоки, расположенные на диаграмме выше и левее, «доминиру­
ют» над блоками, расположенными ниже и правее. Отношение
управления возникает, если выход одного блока служит управляю­
щим воздействием на блок с меньшим доминированием. Отношение
выход — вход возникает при соединении выхода одного блока с вхо­
дом другого блока с меньшим доминированием. Обратная связь по
управлению возникает, когда выход некоторого блока создает управ­
ляющее воздействие на блок с большим доминированием. Отноше­
ние обратной связи по входу возникает, если выход блока становится
входом другого блока с большим доминированием.
При построении модели бизнес-процесса в IDEF0 используется
принцип декомпозиции. Декомпозиция функций производится для
более подробного описания выбранной для декомпозиции функции.
При декомпозиции функция раскладывается на множество функций,
выполнение которых полностью обеспечивает реализацию декомпо­
зированной функции.
Диаграмма, представляющая собой результат декомпозиции, на­
зывается дочерней, а декомпозируемая диаграмма — родительской
диаграммой. Декомпозируемый блок, обозначающий функцию, на­
зывается родительским блоком.
Функциональная модель IDEF0 представляется в виде совокуп­
ности иерархически упорядоченных диаграмм. Выполнение функ­
ции, отображенной на диаграмме верхнего уровня, детализируется на
диаграммах нижнего уровня.
Моделирование бизнес-процесса в IDEF0 начинается с построе­
ния так называемой контекстной диаграммы, которая представляет
собой самое общее описание системы и ее взаимодействия с внешней
средой. На контекстной диаграмме должна быть представлена цель
моделирования и соответствующая ей точка зрения. При формирова­
нии моделей в IDEF0 используют стрелки, называемые туннельны­
ми. Туннельные стрелки обозначаются как круглые скобки в конце
или начале стрелок. Допускается использование квадратных скобок
вместо круглых. Стрелка, помещенная в «туннель» там, где она при­
соединяется к блоку, означает, что данные, выраженные этой стрел­
кой, не обязательны на следующем уровне декомпозиции. Стрелка,
помещенная в туннель на свободном конце, означает, что выражен­
ные ею данные отсутствуют на родительской диаграмме. Все гранич­
но
ные стрелки на дочерней диаграмме, за исключением стрелок, поме­
щенных в туннель, должны соответствовать стрелкам родительского
блока.
Правила составления моделей IDEF0 следующие.
В составе диаграмм должна присутствовать контекстная диаграм­
ма. Блоки на диаграмме располагаются по диагонали — от левого
верхнего угла диаграммы до правого нижнего в порядке присвоенных
номеров.
Диаграммы (кроме контекстной) должны содержать не менее трех
и не более восьми блоков. Каждый блок диаграммы получает номер,
помещаемый в правом нижнем углу; порядок нумерации — от верхне­
го левого к нижнему правому блоку (например, номера от 1 до 8). Ка­
ждый блок, не имеющий декомпозиции, помечается небольшой диа­
гональной чертой, расположенной в левом верхнем углу блока. Име­
на блоков (выполняемых функций) должны быть уникальными. Сле­
дует обеспечить максимальное расстояние между блоками и
поворотами стрелок, а также между блоками и пересечениями стре­
лок для облегчения чтения диаграммы. Блоки всегда должны иметь
хотя бы одну управляющую и одну выходную стрелку, но могут не
иметь входных стрелок.
Если одни и те же данные служат и для управления, и для входа,
показывается только стрелка управления. Стрелки сливаются, если
они представляют сходные данные и их источник не указан на диа­
грамме.
Обратные связи по управлению изображают «верхней петлей»
(вверх и над), обратные связи по входу — «нижней петлей» (вниз и
под). Стрелки объединяют, если они имеют общий источник или
приемник, или они представляют связанные данные.
При соединении большого числа блоков необходимо избегать не­
обязательных пересечений стрелок. Следует минимизировать число
петель и поворотов каждой стрелки.
При описании функций, преобразующих информационные пото­
ки, на диаграммах нижних уровней названиям стрелок-входов дол­
жен быть поставлен в соответствие конкретный документ или пере­
чень документов. Построение стрелок-выходов подчиняется тем же
правилам, что и стрелок-входов.
Все стрелки-механизмы на диаграммах нижнего уровня должны
иметь в своем названии точное название отдела, выполняющего дан­
ную функцию. Стрелки управления на диаграммах нижнего уровня
должны быть детализированы до названия документа, регламенти­
рующего данное действие.
 На диаграммах верхнего уровня разрешается использовать назва­
ния групп документов только в том случае, если они раскрываются до
названия регламентирующего документа на нижних уровнях деком­
позиции. Все прочие условия (кроме регламентирующих докумен­
тов) должны быть показаны на диаграмме как обычные входы, а не
как стрелки управления.
Формат IDEF3 применяется для описания бизнес-процессов в
виде потоков операций (работ). Условные обозначения формата
IDEF3 представлены в табл. 4.5 и 4.6.
Таблица 4.5

№ Наименование Графическое
Описание
п/п представление
I Модель Объект служит для описания операций
операции (работ), выполняемых подразделениями/
(работы) сотрудниками предприятия

Ссылочный Объект, используемый для описания

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

Логическое Логический оператор, определяющий

И связи между операциями в рамках
процесса. Позволяет описать ветвление &
процесса

Логическое Логический оператор, определяющий

ИЛИ связи между операциями в рамках
процесса. Позволяет описать ветвление О
процесса
Логическое Логический оператор, определяющий
исключающее связи между операциями в рамках
ИЛИ процесса. Позволяет описать ветвление X
процесса

Таблица 4.6

№ Тип стрелки Графическое представле­

п/п ние
1 Стрелка предшествования. Соединяет последо­
вательно выполняемые операции ---------------- ►
2 Стрелка отношения. Используется для привяз­
ки объектов-комментариев к операциям _________ ♦
3 Стрелка потока объектов. Показывает поток
объектов (финансовых, материальных) от одной
операции к другой
 Операции (работы) обозначают преобразования потоков матери­
альных, финансовых ресурсов и информации (документов, файлов).
Операции изображаются прямоугольниками со сплошными грани­
цами, при этом нижняя часть прямоугольника отделена сплошной
линией. Каждая операция имеет название и номер. Название опера­
ции выражается глаголом или отглагольным существительным. Н о­
мер операции используется для ее идентификации в модели.
Стрелки связей обозначают взаимосвязи между выполняемыми
операциями, которые выражаются через связь операций посредством
потока объектов или последовательность выполнения операций во
времени. Связь между операциями, выраженная как последователь­
ность выполнения во времени, может быть двух видов: старшая связь;
связь-отношение. Старшая связь показывает, что для начала работы
одной операции необходимо завершение выполнения другой. Стар­
шая связь изображается однонаправленной сплошной стрелкой с од­
ним наконечником. Связь-отношение показывает, что для выполне­
ния операции нет необходимости в завершении выполнения другой
операции — необходимо только начать выполнение этой операции.
Связь-отношение изображается однонаправленной пунктирной
стрелкой с одним наконечником.
Рекомендуется строить диаграммы IDEF3 так, чтобы стрелки,
обозначающие связи, были направлены слева направо либо сверху
вниз. Стрелки изображаются вертикальными и горизонтальными от­
резками прямых с одним или двумя наконечниками на конце, пересе­
кающиеся под прямым углом и сопряженные дугами. Стрелки соеди­
няются с прямоугольниками, изображающими операции, следую­
щим образом:
• концы стрелок должны касаться внешней стороны прямоуголь­
ника, но не пересекать ее;
• стрелки должны подсоединяться к прямоугольнику на его сто­
ронах, присоединение в углах не допускается;
• в отличие от диаграмм IDEF0 стрелки могут подходить и исхо­
дить из любых граней прямоугольников.
Объект модели типа «перекресток» используется для отображения
логики взаимодействия стрелок при слиянии и разветвлении или для
отображения множества событий, которые могут или должны быть
завершены перед началом выполнения следующей операции. Пере­
крестки используются для обозначения следующих ситуаций: окон­
чание реализации одной операции может служить сигналом к началу
выполнения нескольких операций, или же одна операция для своего
запуска может ожидать окончания выполнения нескольких опера­
ций. Стрелки могут сливаться и разветвляться только через перекре­
стки.
В табл. 4.7 приведены типы используемых перекрестков.
Таблица 4.7

№ Наименование Смысл в случае Графическое

п/п
слияния стрелок разветвление стрелок представление
1 Асинхрон­ Все предшествую­ Все следующие опе­ II&I
ное И щие операции должны рации должны быть за­
быть выполнены пущены
2 Сихронное Все предшествую­ Все следующие опе­ II&II
И щие операции должны рации должны быть за­
быть завершены одно­ пущены
временно
3 Асинхрон­ Одна или несколько Одна или несколько II о |
ное ИЛИ предшествующих опе­ следующих операций
раций должны быть должны быть запуще­
завершены ны
4 Сихронное Одна или несколько Одна или несколько II О ||
ИЛИ предшествующих опе­ следующих операций
раций должны быть должны быть запуще­
завершены одновре­ ны одновременно
менно
5 Исключаю­ Только одна пред­ Только одна пред­ |Х |
щее ИЛИ шествующая операция шествующая операция
завершена запускается

Перекресток изображается квадратом с двойной правой или ле­

вой границей. Рассмотрим правила создания перекрестков.
На одной диаграмме IDEF3 может быть создано несколько пере­
крестков различных типов. Каждому перекрестку для слияния дол­
жен предшествовать перекресток для разветвления. Перекресток для
слияния И не может следовать за перекрестком для разветвления
типа синхронного или асинхронного ИЛИ либо исключающего
ИЛИ.
Перекресток для слияния типа исключающего ИЛИ не может
следовать за перекрестком для разветвления типа И.
Перекресток, имеющий одну стрелку на одной стороне, должен
иметь более одной стрелки на другой.
Ссылки используются для указания некоторой дополнительной
информации об операциях или перекрестках. Ссылки применяются
для указания следующих свойств операций и перекрестков:
• участия важного объекта в выполнении операции;
 • циклов выполнения операций;
• частоты выполнения операций;
• другой важной информации.
Ссылки изображаются прямоугольником, похожим на прямо­
угольник, обозначающий операцию, и соединяются сплошной лини­
ей с операцией и перекрестком, к которому они относятся.
При построении диаграмм в IDEF3 используется принцип деком­
позиции, в результате которой образуется иерархическая структура
диаграмм IDEF3.
Родительская диаграмма, расположенная на вершине иерархиче­
ской структуры диаграмм, должна быть либо диаграммой IDEF0,
либо диаграммой DFD. Если диаграмма IDEF3 не дополняет модель
IDEF0 или DFD, а является самостоятельной моделью, то на роди­
тельской диаграмме верхнего уровня должна быть обозначена цель
моделирования и точка зрения создателя модели.
В качестве контекстной диаграммы рекомендуется использовать
контекстную диаграмму, выполненную в нотации IDEF0.
Построение диаграмм IDEF3 основано на следующих правилах.
На вершине дерева декомпозиции диаграмм должна находиться
либо контекстная диаграмма в нотации IDEF0 с указанием цели мо­
делирования и точки зрения, либо IDEF0 или D FD -диаграмма (в слу­
чае если диаграммы IDEF3 дополняют модель в нотации IDEF0 или
DFD).
Рекомендуется стрелки, обозначающие связи, направлять либо
слева направо, либо сверху вниз.
Диаграммы должны содержать не менее трех и не более восьми
операций. Каждая операция имеет свой уникальный номер и имя.
Связь через потоки объектов должна иметь имя, которое является
уникальным. Старшая связь и связи-отношения могут иметь имена,
которые также должны быть уникальными. Уникальными именами
должны обладать и объекты ссылок.
Каждому перекрестку присваивается уникальный номер. При на­
личии стрелок со сложной топологией целесообразно повторить имя
для удобства ее идентификации.
Каждая операция, не имеющая декомпозиции, помечается не­
большой диагональной чертой, расположенной в левом верхнем углу
прямоугольника, изображающего эту операцию.
Дочерние диаграммы (описания и сценарии) должны иметь один
вход. Один выход должна иметь дочерняя диаграмма-описание.
Стрелки должны сливаться и разветвляться через перекрестки.
 При соединении большого числа прямоугольников необходимо
избегать необязательного пересечения стрелок, для этого надо мини­
мизировать число петель и поворотов каждой стрелки.
Следует обеспечить максимальное расстояние между прямо­
угольниками и поворотами стрелок, а также между прямоугольни­
ками и пересечениями стрелок для облегчения чтения диаграммы.
Одновременно уменьшается вероятность перепутать две разные
стрелки.
В случаях сложных диаграмм рекомендуется использовать раз­
личные цвета или «уровни» для прямоугольников и стрелок, позво­
ляющие показывать или распечатывать только часть схемы и доби­
ваться ее большей наглядности.
Диаграммы должны быть декомпозированы до уровня, на кото­
ром присутствуют операции обработки конкретных документов (или
совокупности документов).
В ссылках на операции обработки документов должны быть ука­
зания на обрабатываемые документы.
Рассмотрим правила формирования моделей бизнес-процессов в
формате DFD, который применяется для описания бизнес-процессов
в виде потоков данных. Условные обозначения формата DFD приве­
дены в табл. 4.8.

Таблица 4.8

№ Наименование Графическое
Описание
п/п представление
1 Модель Объект служит для описания операций ... „
операции (работ), выполняемых подразделениями/
(работы) сотрудниками предприятия

2 Хранилище Объект, используемый для описания

данных носителей информации (документов,
файлов)

3 Внешний Объект модели, используемый для

объект описания субъектов внешней среды
бизнесс-процесса 1□
Для отображения потоков данных между операциями и хранили­
щами используется стрелка потока данных —к
Модель информационных потоков бизнес-процесса DFD пред­
ставляет бизнес-процесс как совокупность выполняемых операций в
привязке к движению информационных потоков. Модель информа­
ционных потоков DFD описывает:
 • операции обработки информации;
• документы и информацию;
• объекты, организационные единицы, сотрудников и т. д., кото­
рые участвуют в обработке информации;
• внешние объекты, которые участвуют в бизнес-процессе, но на­
ходятся за его границами;
• хранилища документов, данных и информации.
В модели информационных потоков должны отражаться испол­
нители, атакже субъекты, взаимодействующие с бизнес-процессом.
Основными объектами моделей DFD являются операции, храни­
лища данных, внешние объекты (сущности), потоки данных и объек­
тов.
Операции обозначают преобразования потоков материальных,
финансовых ресурсов и информации (документов, файлов). Опера­
ции изображаются прямоугольниками со сплошными границами и
скругленными углами и выделяются серым фоном.
Хранилища данных (объектов) обозначают места хранения данных.
Внешние объекты (иначе говоря, внешние сущности) обозначают
некоторые объекты, которые участвуют в бизнес-процессе, но нахо­
дятся за его границами, т. е. являются частью внешней среды. Внеш­
ние объекты поддерживают обмен потоками объектов из внешней
среды в систему и обратно через входы и выходы моделируемой сис­
темы. Один внешний объект может быть использован многократно в
рамках одной модели (на одной или нескольких диаграммах). Внеш­
ние объекты изображаются в виде прямоугольников со сплошными
границами. Обычно изображение внешних объектов размещается по
краям диаграммы. Рекомендуется присваивать внешним объектам
наименования, выраженные отглагольными существительными.
Потоки данных и объектов обозначают движение объектов, ин­
формации и данных из одной части системы в другую. Потоки объек­
тов, включая данные, связывают операции, внешние объекты и хра­
нилища. Потоки данных и объектов изображаются стрелками. В от­
личие от моделей IDEF0 в моделях DFD нет стрелок, обозначающих
механизмы реализации функции и управление функцией.
Стрелки изображаются вертикальными и горизонтальными от­
резками прямых с наконечником на одном или двух концах, пересе­
кающимися под прямым углом и сопряженные дугами. Стрелки с на­
конечником на одном конце изображают однонаправленный поток
объектов. Стрелки соединяются с прямоугольниками, изображаю­
щими операции, хранилища и внешние объекты, следующим обра­
зом:
 • концы стрелок должны касаться внешней стороны блока, но не
пересекать ее;
• стрелки должны подсоединяться к прямоугольнику на его сто­
ронах, присоединение в углах не допускается;
• в отличие от диаграмм IDEF0 стрелки могут подходить и исхо­
дить из любых граней прямоугольников.
Рекомендуется использовать левую грань прямоугольника, обо­
значающего операцию, в качестве входа и правую грань в качестве
выхода и располагать прямоугольники по направлению слева напра­
во и сверху вниз.
При изображении стрелок допускается их слияние и разветвле­
ние, которые применяются для уменьшения загруженности диаграмм
графическими элементами. В случае разветвления стрелок их имено­
вание и создание меток подчиняются тем же правилам, что и в модели
IDEF0.
При формировании моделей в DFD может использоваться деком­
позиция.
Методика построения диаграмм DFD основана на следующих
правилах.
На вершине дерева декомпозиции диаграмм должна находиться
либо контекстная диаграмма, либо диаграмма IDEF0 (если диаграм­
мы DFD дополняют модель в нотации IDEF0).
Связи системы с внешней средой отображаются исключительно
внутренними стрелками, которые связывают внешние объекты с од­
ной стороны и операции хранилища с другой.
Ограничений по количеству операций на диаграмме нет. Реко­
мендуется создавать диаграммы, которые позволяют размещать их на
листе формата АЗ.
Следует обеспечить максимальное расстояние между прямо­
угольниками и поворотами стрелок, а также между прямоугольника­
ми и пересечениями стрелок для облегчения чтения диаграммы. Од-
Порядок подготовки документа А

Заполненные
подразделениями
формы
1 Запрос на
уточнение информации
Бизнес-процесс
подготовки документа А Документ А

Экономист Начальник Руко­

отдела водитель
Заполненные Запрос на уточнение
подразделе­ информации
ниями формы Собрать и
проверить Проверенные Указание начальника
информацию формы отдела на доработку
проекта документа А
£ Проект Указание руководителя на
Обработать документа А доработку проекта
полученную документа А
информацию

Выполнить
анализ проекта| ■ Проект
документа А доку­
Замечания мента А
начальника отдела
Согласовать Документ А
и утвердить
Замечания документ А
руководителя

Начальник Руководитель
Экономист отдела

Рис. 4.23. Формирование бизнес-процесса подготовки документа А на нижнем уровне

 Рис. 4.24. Формирование бизнес-процесса подготовки документа А. Собрать и
проверить информацию

Рис. 4.25. Формирование бизнес-процесса подготовки документа А. Обработать

полученную информацию

новременно уменьшается вероятность перепутать две разные стрел­

ки. Максимально увеличенное расстояние между параллельными
стрелками облегчает размещения меток, их чтение и позволяет про­
следить пути стрелок. Стрелки связываются (сливаются), если они
представляют сходные данные и их источник не указан на диаграмме.
Стрелки объединяются, если они имеют общий источник или прием­
ник либо они представляют связанные данные. Общее название луч­
ше описывает суть данных. Следует минимизировать число стрелок,
 Проект Выполнить анализ ' Передать проект Проект
документа А показателей документа А на документа А
проекта . F1151
I Да составление и
документа А утверждение
АЗ. 1.8 | АЗ.1.11 |

Показатели
соответствуют
требованиям?

Указания Указания
руководителя начальника отдела
на доработку на доработку
проекта проекта
документа А Выполнить Сформировать документа А
анализ указания на
замечаний доработку проекта Замечания
Замечания 4 0 — - начальника
руководителя документа А
руководителя отдела
АЗ. 1.10 АЗ. 1.9 I

Есть замечания
начальника отдела
или руководителя

Рис. 4.26. Формирование бизнес-процесса подготовки документа А. Анализ про­

екта документа А

касающихся каждой стороны блока, если, конечно, природа данных

не слишком разнородна. Если возможно, стрелки присоединяются к
прямоугольникам в одной и той же позиции. Тогда соединение стре­
лок конкретного типа с прямоугольниками будет согласованным и
чтение диаграммы упростится. При соединении большого числа пря­
моугольников необходимо избегать необязательных пересечений
стрелок. Следует минимизировать число петель и поворотов каждой
стрелки.
При описании операций, преобразующих информационные по­
токи, на диаграммах нижних уровней названиям стрелок-входов дол­
жен быть поставлен в соответствие конкретный документ или пере­
чень документов.
Рекомендуется, чтобы хранилища данных соответствовали либо
информационным системам, либо бумажным архивам.
На рис. 4.22—4.27 представлен комплексный пример формирова­
ния модели бизнес-процесса в соответствии с последовательностью
действий, указанной на рис. 4.21.
Рис. 4.27. Формирование бизнес-процесса подготовки документа А. Согласовать
и утвердить документ А

КОНТРОЛЬНЫЕ ВОПРОСЫ

1. Укажите основные задачи системной инженерии при разработке АСУ.

2. Каковы отличительные особенности объектно-ориентированной систем­
ной инженерии?
3. Для чего предназначена диаграмма контекста верхнего уровня?
4. Назовите основные этапы процесса разработки АСУ в рамках системной
инженерии?
5. Назовите основные составляющие сценариев верхнего уровня.
6. Какие подходы используют при построении информационно-логической
модели АСУ?
7. Дайте определение полиморфизма и наследования.
8. Какие модели используют для описания информации о предметной об­
ласти?
9. Какие аспекты рассмотрения функциональной модели являются осново­
полагающими?
10. Перечислите основные виды отношений для описания функциональной
модели.
11. Укажите основные схемы декомпозиции действий и данных функцио­
нальной модели.
12. Дайте определение бизнес-процесса.
13. Определите содержание уровней детализации бизнес-процесса.
14. Какова последовательность формирования моделей бизнес-процесса?
 ГЛАВА 5
Математическое и алгоритмическое
обеспечение автоматизированного
управления

Математическая поддержка процессов принятия решений является основ­

ным фактором автоматизированного управления. Вначале рассмотрена общая
проблема формализации и алгоритмизации процессов принятия решений в ус­
ловиях автоматизированного управления, а затем содержание математического
обеспечения на примере ряда областей традиционного автоматизированного
управления производством. Подробно проанализированы вопросы математиче­
ского обеспечения задач тактического планирования и стратегических задач
управления: технико-экономическое планирование; материально-техническое
снабжение и сбыт; маркетинг; стратегическое управление. Не менее подробно
исследовано математическое обеспечение задач оперативного управления: опе­
ративное управление основным производством; методы оперативного управле­
ния КАНБАН и Just-In-Time (JIT).

5 .1 . ПОДДЕРЖКА ПРИНЯТИЯ РЕШЕНИЙ

В УСЛОВИЯХ ФУНКЦИОНИРОВАНИЯ АСУ

5.1.1. Формализация и алгоритмизация процессов

принятия решений в условиях автоматизированного
управления
Поддержка принятия решений является наиболее важным дейст­
вием, выполняемым АСУ при обслуживании пользователей. Ш иро­
кая альтернатива принимаемых решений приводит к необходимости
использования разнообразных математических моделей [25, 30].
В зависимости от степени информированности о состоянии
управляемого процесса, полноты и точности моделей объекта и сис­
темы управления, взаимодействия с окружающей средой процесс
принятия решения протекает в различных условиях.
 1. Принятие решений в условиях определенности. В этой задаче
модели объекта и системы управления считаются заданными, а влия­
ние внешней среды — несущественным. Поэтому между выбранной
стратегией использования ресурсов и конечным результатом сущест­
вует однозначная связь, откуда следует, что в условиях определенно­
сти достаточно использовать решающее правило для оценки полез­
ности вариантов решений, принимая в качестве оптимального то, ко­
торое приводит к наибольшему эффекту. Если таких стратегий не­
сколько, все они считаются эквивалентными. Для поиска решений в
условиях определенности используют методы математического про­
граммирования.
2. Принятие решений в условиях риска. В отличие от предыдуще­
го случая для принятия решений в условиях риска необходимо учиты­
вать влияние внешней среды, которое не поддается точному прогно­
зу. Известно только вероятностное распределение состояний внеш­
ней среды. В этих условиях использование одной и той же стратегии
может привести к различным исходам, вероятности появления кото­
рых считаются заданными или могут быть определены. Оценку и вы­
бор стратегий проводят с помощью решающего правила, учитываю­
щего вероятность достижения конечного результата.
3. Принятие решений в условиях неопределенности. Как и в пре­
дыдущей задаче, между выбором стратегии и конечным результатом
отсутствует однозначная связь. Кроме того, неизвестны также значе­
ния вероятностей появления конечных результатов, которые либо не
могут быть определены, либо не имеют в контексте содержательного
смысла. Каждой паре «стратегия — конечный результат» ставится в
соответствие некоторая внешняя оценка в виде выигрыша. Наиболее
распространенным является использование критерия получения
максимального гарантированного выигрыша.
4. Принятие решений в условиях многокритериальности. В любой
из перечисленных выше задач многокритериальность возникает в
случае наличия нескольких самостоятельных, не сводимых одна к
другой целей. Наличие большого количества решений усложняет
оценку и выбор оптимальной стратегии. Одним из возможных путей
решения является использование методов моделирования.
Решение задач с помощью искусственного интеллекта заключает­
ся в сокращении перебора вариантов при поиске решения, при этом
программы реализуют те же принципы, которыми пользуется в про­
цессе мышления человек.
 Экспертная система пользуется знаниями, которыми она облада­
ет в своей узкой области, чтобы ограничить поиск на пути к решению
задачи путем постепенного сужения круга вариантов.
При решении задач в экспертных системах используются следую­
щие методы:
• логического вывода, основанный на технике доказательств, на­
зываемой резолюцией и использующей опровержение отрицания
(доказательство «от противного»);
• структурной индукции, основанный на построении дерева при­
нятия решений для различения объектов из большого количества
данных на входе;
• эвристических правил, основанный на перенимании опыта у
экспертов-людей, а не на абстрактных правилах формальной логики;
• машинной аналогии, основанный на представлении информа­
ции о сравниваемых объектах в удобном виде, например в виде струк­
тур данных, называемых фреймами.
Источники «интеллекта», проявляющегося при решении задачи,
могут оказаться бесполезными либо полезными или экономичными в
зависимости от определенных свойств области, в которой поставлена
задача. Исходя из этого может быть осуществлен выбор метода по­
строения экспертной системы или использования готового про­
граммного продукта.
Процесс выработки решения на основе первичных данных, схема
которого представлена на рис. 5.1, можно разбить на два этапа: выра­
ботка допустимых вариантов решений путем математической форма­
лизации с использованием разнообразных моделей и выбор опти­
мального решения на основе субъективных факторов.
Информационные потребности лиц, принимающих решение, во
многих случаях ориентированы на интегральные технико-экономи-
ческие показатели, которые могут быть получены в результате обра­
ботки первичных данных, отражающих текущую деятельность пред­
приятия. Анализируя функциональные взаимосвязи между итоговы­
ми и первичными данными, можно построить так называемую ин­
формационную схему, которая отражает процессы агрегирования
информации. Первичные данные, как правило, чрезвычайно разно­
образны, интенсивность их поступления высока, а общий объем на
интересующем интервале велик. С другой стороны, состав интеграль­
ных показателей относительно мал, а требуемый период их актуали­
зации может быть значительно ниже периода изменения первичных
данных — аргументов.
 Рис. 5.1. Процесс выработки решения на основе первичных данных

Для поддержки принятия решений обязательным является нали­

чие следующих компонентов:
• обобщающий анализ;
• прогнозирование;
• ситуационное моделирование.
В настоящее время принято выделять два типа информационных
систем поддержки принятия решений.
Системы поддержки принятия решений DSS (Decision Support
System) осуществляют отбор и анализ данных в различных разрезах и
включают следующие средства:
• доступа к базам данных;
• извлечения данных из разнородных источников;
• моделирования правил и стратегии деловой деятельности;
• деловой графики для представления результатов анализа;
• анализа «если что»;
• искусственного интеллекта на уровне экспертных систем.
Системы оперативной аналитической обработки OLAP (On Line
Analysis Processing) для принятия решений используют следующие
средства:
 • мощную многопроцессорную вычислительную технику в виде
специальных OLAP-серверов;
• специальные методы многомерного анализа;
• специальные хранилища данных Data Warehouse.
Реализация процесса принятия решений заключается в построе­
нии информационных приложений. Выделим в информационном
приложении типовые функциональные компоненты, достаточные
для формирования любого приложения на основе БД:
• PS (Presentation Services) — средства представления. Обеспечи­
ваются устройствами, принимающими ввод от пользователя и ото­
бражающими то, что сообщает ему компонент логики представления
PL, плюс соответствующая программная поддержка. Может быть
текстовым терминалом или Х-терминалом, а также персональным
компьютером или рабочей станцией в режиме программной эмуля­
ции терминала или Х-терминала;
• PL (Presentation Logic) — логика представления. Управляет
взаимодействием между пользователем и ЭВМ. Обрабатывает дейст­
вия пользователя по выбору альтернативы меню, по нажатию кнопки
или выборе элемента из списка;
• BL (Business or Application Logic) — прикладная логика. Набор
правил для принятия решений, вычислений и операций, которые
должно выполнить приложение;
• DL (Data Logic) — логика управления данными. Операции с ба­
зой данных (SQL-операторы SELECT, UPDATE и INSERT), которые
нужно выполнить для реализации прикладной логики управления
данными;
• DS (Data Services) — операции с базой данных. Действия СУБД,
вызываемые для выполнения логики управления данными, такие как
манипулирование данными, определения данных, фиксация или от­
кат транзакций и т.п. СУБД обычно компилирует SQL-приложения;
• FS (File Services) — файловые операции. Дисковые операции
чтения и записи данных для СУБД и других компонентов. Обычно яв­
ляются функциями ОС.
Среди средств разработки информационных приложений можно
выделить следующие основные группы:
• традиционные системы программирования;
• инструменты для создания файл-серверных приложений;
• средства разработки приложений клиент — сервер;
• средства автоматизации делопроизводства и документооборота;
• средства разработки Интернет/Интранет-приложений;
• средства автоматизации проектирования приложений.
 При внедрении автоматизированного управления процесс дол­
жен быть описан математически.
Формализация тесно связана с алгоритмизацией. К математиче­
ским моделям предъявляются следующие требования.
1. Достаточная полнота описания с возможностью оценки точно­
сти и достоверности.
2. Гибкость описания с целью воспроизведения различных ситуа­
ций при варьировании сигналов, параметров, структуры и алгорит­
мов.
3. Минимум длительности разработки и реализации формального
описания и алгоритмизации.
4. Блочность структуры описания.
5. Возможность работы алгоритма с базами данных.
6. Простота проверки и тестирования полученных результатов.
Напомним, что формализация — процедура неформальная. Дей­
ствительно, результат формального описания в значительной мере
определяется математическим аппаратом, которым исследователь
владеет лучше всего. При математическом описании стараются ис­
пользовать прежде всего известные типовые проверенные математи­
ческие схемы. Обращаться к оригинальным математическим моде­
лям целесообразно, если типовые модели «не работают».
При математическом описании не следует упускать из виду смы­
словой аспект («физический смысл») как математических формул,
так и получаемых результатов. Это позволит избежать при описании
грубых ошибок.
Ввиду большого количества предметных областей, где использу­
ется автоматизированное управление, и задач, решаемых ими, рас­
смотрено содержание математического обеспечения на примере ряда
областей автоматизированного управления производством (см. под-
разд. 5.2 и 5.3).

5.1.2. Принятие решений на основе технологий

искусственного интеллекта
В условиях резкого увеличения объемов информации переход к
работе со знаниями на основе искусственного интеллекта становится
одним из наиболее важных направлений автоматизированного
управления.
Воспользуемся определением интеллектуальной системы проф.
Д.А. Поспелова [39]: система называется интеллектуальной, если в
ней реализованы следующие основные функции:
 • накапливать знания об окружающем систему мире, классифи­
цировать и оценивать их с точки зрения прагматической полезности
и непротиворечивости, инициировать процессы получения новых
знаний, осуществлять соотнесение новых знаний с ранее хранимы­
ми;
• пополнять поступившие знания с помощью логического выво­
да, отражающего закономерности в окружающем систему мире или в
накопленных ею ранее знаниях, получать обобщенные знания на ос­
нове более частных знаний и логически планировать свою деятель­
ность;
• общаться с человеком на языке, максимально приближенном к
естественному человеческому языку, и получать информацию от ка­
налов, аналогичных тем, которые использует человек при воспри­
ятии окружающего мира, уметь формировать для себя или по просьбе
человека (пользователя) объяснение собственной деятельности, ока­
зывать пользователю помощь за счет тех знаний, которые хранятся в
памяти, и тех логических средств рассуждений, которые присущи
системе.
Перечисленные функции можно назвать функциями представле­
ния и обработки знаний, рассуждения и общения. Наряду с обяза­
тельными компонентами в зависимости от решаемых задач и области
применения в конкретной системе эти функции могут быть реализо­
ваны в различной степени, что определяет индивидуальность архи­
тектуры. На рис. 5.2 в наиболее общем виде представлена структура
интеллектуальной системы в виде совокупности блоков и связей ме­
жду ними [47, 60].
Первая функция — база знаний — представляет собой совокуп­
ность сред, хранящих знания различных типов. Рассмотрим кратко
их назначение.
База фактов (данных) хранит конкретные данные, а база пра­
вил — элементарные выражения, называемые в теории искусствен­
ного интеллекта продукциями. База процедур содержит прикладные
программы, с помощью которых выполняются все необходимые пре­
образования и вычисления надданными. База закономерностей вклю­
чает различные сведения, относящиеся к особенностям той среды, в
которой действует система. База метазнаний (база знаний о себе) со­
держит описание самой системы и способов ее функционирования:
сведения о том, как внутри системы представляются единицы инфор­
мации различного типа, как взаимодействуют различные компонен­
ты системы, как было получено решение задачи.
База целей содержит целевые структуры, называемые сценария­
ми, позволяющие организовать процессы движения от исходных
 Рис. 5.2. Общая структура интеллектуальной системы

фактов, правил, процедур к достижению той цели, которая поступила

в систему от пользователя либо была сформулирована самой систе­
мой в процессе ее деятельности в проблемной среде.
Управление всеми базами, входящими в базу знаний, и организа­
цию их взаимодействия осуществляет система управления базами
знаний. С ее же помощью реализуются связи баз знаний с внешней
средой. Таким образом, машина базы знаний осуществляет первую
функцию интеллектуальной системы.
Выполнение второй функции обеспечивает часть интеллектуаль­
ной системы, называемая решателем и состоящая из ряда блоков,
управляемых системой управления решателя. Часть из блоков реали­
зует логический вывод. Блок дедуктивного вывода осуществляет в ре­
шателе дедуктивные рассуждения, с помощью которых из закономер­
ностей из базы знаний, фактов из базы фактов и правил из базы пра­
вил выводятся новые факты. Кроме этого данный блок реализует эв­
ристические процедуры поиска решений задач, как поиск путей
решения задачи по сценариям при заданной конечной цели. Для реа­
лизации рассуждений, которые не носят дедуктивный характер, т. е.
поиск по аналогии, по прецеденту и пр., используются блоки индук­
тивного и правдоподобного выводов. Блок планирования применяется в
задачах планирования решений совместно с блоком дедуктивного
вывода. Назначение блока функциональных преобразований состоит в
решении задач расчетно-логического и алгоритмического типов.
Третья функция — функция общения — реализуется как с помо­
щью компонентов естественно-языкового интерфейса, так и с помо­
щью рецепторов и эффекторов, которые осуществляют так называе­
мое невербальное общение и используются в интеллектуальных ро­
ботах.
В зависимости от набора компонентов, реализующих рассмот­
ренные функции, можно выделить следующие основные разновид­
ности интеллектуальных систем:
• интеллектуальные информационно-поисковые системы;
• экспертные системы (ЭС);
• расчетно-логические системы;
• гибридные экспертные системы.
Интеллектуальные информационно-поисковые системы являются
системами взаимодействия с проблемно-ориентированными (факто­
графическими) базами данных на естественном, точнее ограничен­
ном как грамматически, так и лексически (профессиональной лекси­
кой) естественном языке (языке деловой прозы). Для них помимо
базы знаний, реализующей семантическую модель представления
знаний о проблемной области, характерно использование лингвисти­
ческого процессора.
Экспертные системы являются одним из бурно развивающихся
классов интеллектуальных систем. Данные системы в первую очередь
стали применяться в математически слабоформализованных облас­
тях науки и техники, таких как медицина, геология, биология и др.
Для них характерна аккумуляция в системе знаний и правил рассуж­
дений опытных специалистов в данной предметной области, а также
наличие специальной системы объяснений.
Расчетно-логические системы позволяют решать управленческие
и проектные задачи по их постановкам (описаниям) и исходным дан­
ным вне зависимости от сложности математических моделей этих за­
дач. При этом конечному пользователю предоставляется возмож­
ность контролировать в режиме диалога все стадии вычислительного
процесса. В общем случае по описанию проблемы на языке предмет­
ной области обеспечиваются автоматическое построение математиче­
ской модели и автоматический синтез рабочих программ при форму­
лировке функциональных задач из данной предметной области. Эти
свойства реализуются благодаря наличию базы знаний в виде функ­
циональной семантической сети и компонентов дедуктивного выво­
да и планирования.
В последнее время в специальный класс выделяются гибридные
экспертные системы. Указанные системы должны вобрать в себя луч­
шие черты как экспертных, так и расчетно-логических и информаци-
онно-поисковых систем. Разработки в области гибридных эксперт­
ных систем находятся на начальном этапе.
Наиболее значительные успехи в настоящее время достигнуты в та­
ком классе интеллектуальных систем, как экспертные системы (ЭС).
ЭС называют вычислительную систему использования знаний
эксперта и процедур логического вывода для решения проблем, кото­
рые требуют проведения экспертизы и позволяют дать объяснение
полученным результатам.
ЭС обладают способностями к накоплению знаний, выдаче реко­
мендаций и объяснению полученных результатов, возможностями
модификации правил, подсказки пропущенных экспертом условий,
«ведение» целью или данными. ЭС отличают следующие характери­
стики: интеллектуальность; простота общения с компьютером; воз­
можность наращивания модулей; интеграция неоднородных данных
(способность разрешения многокритериальных задач при учете пред­
почтений лиц, принимающих решения); работа в реальном времени;
документальность; конфиденциальность; унифицированная форма
знаний; независимость механизма логического вывода; способность
объяснения результатов.
В настоящее время можно выделить следующие основные сферы
применения ЭС: диагностика, планирование, имитационное моде­
лирование, предпроектное обследование предприятий, офисная дея­
тельность, а также некоторые другие.
Практика показывает, что по сравнению со статическими ЭС го­
раздо больший эффект дают ЭС, используемые в динамических про­
цессах (экспертные системы реального времени — ЭСРВ), которые
занимают около 70% рынка таких систем и находят все более широ­
кое применение в управлении непрерывными процессами (химиче­
ские производства, цементная промышленность, атомная энергетика
и т.д.).
По сравнению с общей схемой (см. рис. 5.2) в ЭС часто отсутству­
ет возможность общения с системой на близком к естественному язы­
ке или с использованием визуальных средств, поскольку взаимодей­
ствие с такой системой проводится с использованием языка типа
ПРОЛОГ или с применением ПРОЛОГ-идей.
Важное место в теории искусственного интеллекта (ИИ) занимает
проблема представления знаний. В настоящее время выделяют сле­
дующие основные типы моделей представления знаний:
• семантические сети, в том числе функциональные семантиче­
ские;
• фреймы и сети фреймов;
• продукционные модели.
Семантические сети определяют как граф общего вида, в котором
можно выделить множество вершин и ребер. Каждая вершина графа
представляет некоторое понятие, а дуга — отношение между парой
понятий. Метка и направление дуги конкретизируют семантику.
Метки вершин семантической нагрузки не несут, а используются как
справочная информация.
Различные разновидности семантических сетей обладают различ­
ной семантической мощностью, следовательно, можно описать одну
и ту же предметную область более компактно или громоздко.
Фреймом называют структуру данных для представления и описа­
ния стереотипных объектов, событий или ситуаций. Фреймовая мо­
дель представления знаний состоит из двух частей:
• набора фреймов, составляющих библиотеку внутри представ­
ляемых знаний;
• механизмов их преобразования, связывания и т. д.
Существует два типа фреймов:
• образец (прототип) — интенсиональное описание некоторого
множества экземпляров;
• экземпляр (пример) — экстенсиональное представление фрейм-
образца.
В общем виде фрейм может быть представлен следующим корте­
жем:
<ИФ, (ИС, ЗС, ПП)..... (ИС, ЗС, ПП)>,
где ИФ — имя фрейма; ИС — имя слота; ЗС — значение слота;
ПП — имя присоединенной процедуры (необязательный параметр).
Слоты — это некоторые незаполненные подструктуры фрейма,
заполнение которых приводит к тому, что данный фрейм ставится в
соответствие некоторой ситуации, явлению или объекту.
В качестве данных фрейм может содержать обращения к процеду­
рам (так называемые присоединенные процедуры). Выделяют два
вида процедур: процедуры-демоны и процедуры-слуги. Процеду­
ры-демоны активизируются при каждой попытке добавления или уда­
ления данных из слота. Процедуры-слуги активизируются только при
выполнении условий, определенных пользователем при создании
фрейма.
Продукционные модели — это набор правил вида «условия — дей­
ствие», где условиями являются утверждения о содержимом базы
данных, а действия представляют собой процедуры, которые могут
изменять содержимое базы данных.
Формально продукция определяется следующим образом:

(0; <2; р-, С; Л -> в- N,

где (0 — имя продукции (правила); Q — сфера применения правила;
Р — предусловие (например, приоритетность); С — предикат (отно­
шение); А -> В — ядро; N — постусловия (изменения, вносимые в сис­
тему правил).
Практически продукции строятся по схеме «ЕСЛИ» (причина,
или иначе посылка), «ТО» (следствие, или иначе цель правила).
Полученные в результате срабатывания продукций новые знания
могут использоваться в следующих целях:
• понимание и интерпретация фактов и правил с использованием
продукций, фреймов, семантических цепей;
• решение задач с помощью моделирования;
• идентификация источника данных, причин несовпадений но­
вых знаний со старыми, получение метазнаний;
• составление вопросов к системе;
• усвоение новых знаний, устранение противоречий, системати­
зация избыточных данных.
Процесс рассмотрения компьютером набора правил (выполнение
программы) называют консультацией. Ее наиболее удобная для поль­
зователя форма — дружественный диалог с компьютером. Интер­
фейс может быть в форме меню, на языке команд и на естественном
языке.
Диалог может быть построен на системе вопросов, задаваемых
пользователем, компьютером, или фактов — данных, хранящихся в
базе данных. Возможен смешанный вариант, когда в базе данных не­
достаточно фактов.
При прямом поиске пользователь может задавать две группы во­
просов, на которые компьютер дает объяснения:
1) КАК получено решение. При этом компьютер должен выдат
на экран трассу в виде ссылок на использованные правила;
 2) ПОЧЕМУ компьютер задал какой-то вопрос. При этом на эк­
ран выдается своеобразная трасса, которую компьютер хотел бы ис­
пользовать для вывода после получения ответа на задаваемый вопрос.
Вопрос ПОЧЕМУ может быть задан как в процессе консультации, так
и после выполнения программы.
Специфичен алгоритм поиска, реализуемый логическими языка­
ми: он является фактически последовательным перебором по дереву
«сверху-вниз-слева-направо».
Выделим следующие характеристики ЭС: назначение, проблем­
ную область, глубину анализа проблемной области, тип используе­
мых методов и знаний, класс системы, стадию существования, инст­
рументальные средства.
Назначение определяется следующей совокупностью параметров:
цель создания экспертной системы — для обучения специалистов,
решения задач, автоматизации рутинных работ, тиражирования зна­
ний экспертов и т. п.; основной пользователь — не специалист в об­
ласти экспертизы, специалист, учащийся.
Проблемная область может быть определена совокупностью пара­
метров: предметной областью и задачами, решаемыми в предметной
области, каждый из которых может рассматриваться с точки зрения
как конечного пользователя, так и разработчика экспертной систе­
мы.
С точки зрения пользователя предметную область можно характе­
ризовать описанием области в терминах пользователя, включающим
наименование области, перечень и взаимоотношения подобластей и
т. п., а задачи, решаемые существующими экспертными система­
ми,— их типом. Обычно выделяют следующие типы задач:
• интерпретация символов или сигналов — составление смысло­
вого описания по входным данным;
• диагностика — определение неисправностей (заболеваний) по
симптомам;
• предсказание — определение последствий наблюдаемых ситуа­
ций;
• конструирование — разработка объекта с заданными свойства­
ми при соблюдении установленных ограничений;
• планирование — определение последовательности действий,
приводящих к желаемому состоянию объекта;
• слежение — наблюдение за изменяющимся состоянием объекта
и сравнение его показателей с установленными или желаемыми;
• управление — воздействие на объект для достижения желаемого
поведения.
 С точки зрения разработчика целесообразно выделять статиче­
ские и динамические предметные области. Предметная область назы­
вается статической, если описывающие ее исходные данные не изме­
няются во времени (точнее, рассматриваются как не изменяющиеся
за время решения задачи). Статичность области означает неизмен­
ность описывающих ее исходных данных. При этом производные
данные (выводимые из исходных) могут и появляться заново, и изме­
няться (не изменяя, однако, исходных данных). Если исходные дан­
ные, описывающие предметную область, изменяются за время реше­
ния задачи, то предметную область называют динамической. Кроме
того, предметные области можно характеризовать следующими аспек­
тами: числом и сложностью сущностей, их атрибутов и значений атри­
бутов; связностью сущностей и их атрибутов; полнотой знаний; точно­
стью знаний (знания точны или правдоподобны: правдоподобность
знаний представляется некоторым числом или высказыванием).
Решаемые задачи с точки зрения разработчика экспертной систе­
мы также можно разделить на статические и динамические. Принято,
что ЭС решают динамическую или статическую задачу, если процесс
решения задачи изменяет или не изменяет исходные данные о теку­
щем состоянии предметной области.
В подавляющем большинстве существующие ЭС исходят из пред­
положения о статичности предметной области и решают статические
задачи. Будем называть такие ЭС статическими, а ЭС, которые имеют
дело с динамическими предметными областями и решают статиче­
ские или динамические задачи,— динамическими.
Решаемые задачи, кроме того, могут характеризоваться следую­
щими аспектами: числом и сложностью правил, используемых в зада­
че; связностью правил; пространством поиска; количеством актив­
ных агентов, изменяющих предметную область; классом решаемых
задач.
По степени сложности выделяют простые и сложные правила. К
сложным относятся правила, текст записи которых на естественном
языке занимает 1/3 страницы и больше. Правила, текст записи кото­
рых занимает менее 1/3 страницы, относят к простым.
Можно сказать, что степень сложности задачи определяется не
просто общим количеством правил данной задачи, а количеством
правил в ее наиболее связной независимой подзадаче.
Пространство поиска может быть определено по крайней мере
тремя факторами: размером, глубиной и шириной. Размер простран­
ства поиска дает обобщенную характеристику сложности задачи. Вы­
деляют малые (до 10! состояний) и большие (свыше 10! состояний)
пространства поиска. Глубина пространства поиска характеризуется
средним числом последовательно применяемых правил, преобразую­
щих исходные данные в конечный результат, ширина пространст­
ва — средним числом правил, пригодных к выполнению в текущем
состоянии.
Класс решаемых задач характеризует методы, используемые ЭС
для решения задачи. Данный аспект в ЭС принимает следующие зна­
чения: задачи расширения, доопределения, преобразования. Задачи
доопределения и расширения являются статическими, а задачи пре­
образования — динамическими.
К задачам расширения относятся задачи, в процессе решения ко­
торых осуществляется только увеличение информации о предметной
области, не приводящие к изменению ранее выведенных данных. За­
дачей этого класса являются задачи классификации.
К задачам доопределения относятся задачи с неполной или неточ­
ной информацией о реальной предметной области, цель решения ко­
торых — выбор из множества альтернативных текущих состояний
предметной области то, которое адекватно исходным данным. В слу­
чае неточных данных альтернативные текущие состояния возникают
как результат ненадежности данных и правил, что приводит к много­
образию различных доступных выводов из одних и тех же исходных
данных. В случае неполных данных альтернативные состояния явля­
ются результатом доопределения.
Большинство существующих ЭС решают задачи расширения, в
которых нет ни изменений предметной области, ни активных аген­
тов, преобразующих предметную область. Подобное ограничение не­
приемлемо при работе в динамических областях.
По степени сложности структуры ЭС делят на поверхностные и
глубинные. Поверхностные ЭС представляют знания об области экс­
пертизы в виде правил (условие-действие). Условие каждого правила
определяет образец некоторой ситуации, при соблюдении которой
правило может быть выполнено. Поиск решения состоит в выполне­
нии тех правил, образцы которых сопоставляются с текущими дан­
ными (текущей ситуацией в РП). При этом предполагается, что в про­
цессе поиска решения последовательность формируемых таким об­
разом ситуаций не оборвется до получения решения, т. е. не возник­
нет неизвестной ситуации, которая не сопоставится ни с одним
правилом. Глубинные ЭС, кроме возможностей поверхностных сис­
тем, обладают способностью при возникновении неизвестной ситуа­
ции определять с помощью некоторых общих принципов, справедли­
вых для области экспертизы, какие действия следует выполнить.
По типу используемых методов и знаний ЭС делят на традицион­
ные и гибридные. Традиционные ЭС используют в основном нефор­
мализованные методы инженерии знаний и неформализованные
знания, полученные от экспертов. Гибридные ЭС используют и мето­
ды инженерии знаний, формализованные методы, а также данные
традиционного программирования и математики.
Совокупность рассмотренных характеристик позволяет опреде­
лить особенности конкретной ЭС. Однако пользователи зачастую
стремятся охарактеризовать ЭС каким-либо одним обобщенным па­
раметром. В этой связи говорят о поколениях ЭС. В настоящее время
выделяют ЭС первого и второго поколений. Однако, по-видимому,
следует говорить о трех поколениях ЭС. К первому поколению следу­
ет отнести статические поверхностные ЭС, ко второму — статические
глубинные ЭС (иногда ко второму поколению относят гибридные
ЭС), а к третьему — динамические ЭС (вероятно, они, как правило,
будут глубинными и гибридными).
В последнее время выделяют два больших класса ЭС (существен­
но отличающиеся по технологии их проектирования), которые услов­
но называют простыми и сложными ЭС. К простым ЭС можно отне­
сти поверхностную и традиционную (реже гибридную) ЭС, выпол­
ненные на персональной ЭВМ, содержащие от 200 до 1000 правил. К
сложным ЭС можно отнести глубинную и гибридную ЭС, выполнен­
ные либо на символьной, либо на мощной универсальной ЭВМ, либо
на интеллектуальной рабочей станции, содержащие от 1500 до 10 тыс.
правил.
Стадия существования характеризует степень проработанности и
отлаженности ЭС. Обычно выделяют следующие стадии: демонстра­
ционный прототип, исследовательский прототип, действующий про­
тотип, промышленная система, коммерческая система.
Демонстрационным прототипом называют ЭС, которая решает
часть требуемых задач, демонстрируя жизнеспособность метода ин­
женерии знаний. При наличии развитых интеллектуальных систем
для разработки демонстрационного прототипа требуется примерно
1—2 мес. Демонстрационный прототип работает, имея 50—100 пра­
вил. Развитие демонстрационного прототипа приводит к исследова­
тельскому прототипу.
Исследовательским прототипом называют систему, которая реша­
ет все требуемые задачи, но неустойчива в работе и не полностью про­
верена. Исследовательский прототип обычно имеет в базе знаний
200—500 правил, описывающих проблемную область.
Действующий прототип надежно решает все задачи, но для реше­
ния сложных задач может потребоваться чрезмерно много времени и
(или) памяти. Число правил в такой системе равно 500—1000.
 Экспертная система, достигшая промышленной стадии, обеспе­
чивает высокое качество решения всех задач при минимуме времени
и памяти. Обычно процесс преобразования действующего прототипа
в промышленную систему состоит в расширении правил до 1000 —
1500 и переписывании программ с использованием более эффектив­
ных интеллектуальных систем.
Обобщение задач, решаемых на стадии промышленной системы,
позволяет перейти к стадии коммерческой системы, пригодной не
только для собственного использования, но и для продажи различ­
ным потребителям. В базе знаний такой системы 1500—3000 правил.
Диапазон возможных средств построения ЭС простирается от
языков высокого уровня до средств поддержки низкого уровня. Раз­
делим инструментальные средства построения ЭС на четыре основ­
ные категории:
• языки программирования;
• языки инженерии знаний;
• вспомогательные средства;
• средства поддержки.
Языки программирования, применяемые для работы в области
ЭС, — это, как правило, или проблемно-ориентированные языки
(Фортран, Паскаль и т.д.), или языки обработки текстов (Лисп, Про­
лог). Проблемно-ориентированные языки разработаны для специ­
ального класса задач: например, Фортран удобен для выполнения ал­
гебраических вычислений и чаще всего применяется в научных, мате­
матических и статистических вычислениях. Языки обработки текстов
разработаны для прикладных областей искусственного интеллекта:
например, Лисп имеет механизмы для манипулирования символами
в форме списковых структур. Список является просто набором эле­
ментов, заключенных в скобки, где каждый элемент может быть или
символом, или другим списком. Списковые структуры являются
удобным строительным материалом для представления сложных по­
нятий. В языке Лисп все отношения между объектами описываются
через списки, содержащие отношения объекта с другими объектами.
Добавим, что Лисп существует в разных версиях, например, И н­
терлисп и Маклисп имеют различные средства поддержки (редакто­
ры и средства отладки), но одинаковый синтаксис.
Языки программирования, подобные Лиспу, предоставляют мак­
симальную гибкость разработчику ЭС, но никак не подсказывают
ему, как представлять знания или как построить механизм доступа к
базе знаний. С другой стороны, языки инженерии знаний, такие как
KAS, обладают меньшей гибкостью, поскольку разработчик системы
должен пользоваться схемой управления, определяемой встроенным
в язык механизмом вывода. Эти языки, однако, обеспечивают неко­
торое руководство и готовые механизмы вывода для управления и ис­
пользования базы знаний.
Язык инженерии знаний является искусным инструментальным
средством разработки ЭС, погруженным в обширное поддерживаю­
щее окружение. Языки инженерии знаний можно разделить на ске­
летные и универсальные. Скелетный язык инженерии знаний являет­
ся просто «раздетой» экспертной системой, т. е. ЭС без специальных
предметных знаний, включающей в себя только механизм вывода и
средства поддержки.
Универсальный язык инженерии знаний может быть применим к
проблемам разного типа в различных прикладных областях. Он обес­
печивает более широкие возможности управления поиском данных и
доступом к ним, чем скелетные системы, но его может оказаться
труднее использовать. Разные универсальные языки значительно
варьируют в смысле общности и гибкости.
Вспомогательные средства построения ЭС состоят из программ,
оказывающих помощь эксперту-человеку в приобретении и представ­
лении знаний, и программ, которые помогают разрабатывать проек­
ты экспертных систем.
Средства поддержки — это просто пакеты программ, которые
прилагаются к средству построения ЭС, чтобы упростить его исполь­
зование, облегчить диалог и сделать его более эффективным: средства
отладки, средства ввода/вывода, средства объяснения, редакторы баз
знаний.
Интеллектуальные системы расчетно-логического типа предпола­
гают организацию базы знаний в виде функциональной семантиче­
ской сети. Рассмотрим кратко алгоритмы поиска решений на функ­
циональной семантической сети. Первой задачей, которая должна
быть решена, является выбор представления, в котором реализуются
процедуры поиска решений и организации вычислительного процес­
са. В качестве такого представления целесообразно выбрать пред­
ставление в пространстве состояний. В данном представлении задача
поиска решений формально представляется следующим образом:

Т =< S , S q , S K, F >,

где Sq — начальное состояние; SK — конечное состояние или состоя­

ния; S — множество промежуточных состояний; F = {F^} — множе­
ство операторов, которые переводят процесс поиска из одного со­
стояния в другое. Каждому математическому отношению ^ поставим
в соответствие список (кортеж) параметров, которые в него входят.
Таким образом, рассматриваемый алгоритм предусматривает работу
со списочными структурами данных.
При поиске решений на ФСС в качестве множества операторов
выступают разрешения математических отношений F ^, реализуемые
в виде отдельных программных модулей, совокупность которых для
данной проблемной области составляет локальную (может одну из
многих) базу процедур. Здесь верхний индекс г| указывает на пара­
метр, который в данном разрешении выступает как функция, а ниж­
ний индекс / — на номер соответствующего математического отноше­
ния в совокупности математических отношений. Задание исходных
даннных определяет начальное состояние So, а искомое реше­
ние — конечное (целевое) состояние. Выбор на каждом очередном
шаге некоторого конкретного оператора осуществляется в соответст­
вии с некоторыми правилами, которые для данной проблемной об­
ласти составляют локальную базу правил.
Первый алгоритм реализует стратегию обратной волны, начиная
поиск решения задачи с целевого состояния, т. е. от искомого пара­
метра. Суть алгоритма состоит в следующем. В соответствии с алго­
ритмом поиска решений Нильсона образуем следующие списки: Ji —
список параметров, которые должны быть рассчитаны; S2 — список
параметров, для которых выбраны разрешения для расчета. Дополни­
тельно образуем еще два списка: S3 — список разрешений, включае­
мых в план решения задачи; 54 — список оценок сложности реализа­
ции разрешения, выбранного в план решения задачи. Данные оцен­
ки позволяют при наличии нескольких планов выбрать наилучший,
т. е. реализовать классическую постановку задачи принятия реше­
ний.
Во втором алгоритме реализуется стратегия прямой волны, т. е.
планирование идет от исходных данных к целевому параметру. Суть
алгоритма состоит в следующем
,0
Обозначим N — число параметров в математическом отноше­
нии; D — число заданных исходных данных (значений параметров);
N — число параметров, оставшихся неизвестными; NA — число пара­
метров, найденных на данном шаге применением соответствующего
оператора F.
Многофункциональность разрабатываемых систем обработки
интеллектуальной информации может быть обеспечена за счет совре­
менного подхода к хранению и использованию знаний проектиров­
щиков.
Основной принцип данного подхода заключается в том, что зада­
чи решаются на основе не просто данных, а знаний. Последние явля­
ются существенно более мощными и позволяют решать на их основе
сложные задачи.
Традиционные ЭС имеют лишь один механизм поддержки при­
нятия решений — логический вывод и лишь одно средство представ­
ления знаний — правила. В последнее время активно развивается но­
вое поколение ЭС — гибридные экспертные системы (ГЭС).
Для использования ГЭС в качестве средства поддержки принятия
управленческих решений необходимо предусмотреть возможность
учета характеристик лица принимающего решение (ЛПР). В этом
случае в экспертной системе должна присутствовать гибкая схема ло­
гического вывода, а поддержка принятия решений должна осуществ­
ляться в соответствии с конкретной аналитической моделью пользо­
вателя.
Эксперт соответствующей предметной области должен иметь воз­
можность задавать оценки объектов, выявленные в результате его
взаимодействия с подсистемой обработки экспертных знаний. Полу­
ченные таким образом экспертные знания будут храниться в базе экс­
пертных знаний.
Одним из основных этапов решения задачи многокритериального
выбора является настройка модели на систему предпочтений ЛПР.
Она выявляется в результате взаимодействия ЛПР и подсистемы вы­
явления предпочтений ЛПР. Найденные таким образом характери­
стики ЛПР сохраняются в базе характеристик ЛПР.
Банк моделей должен содержать широкий набор решающих пра­
вил, выражающих различные стратегии поведения пользователя.

5 .2 . МАТЕМАТИЧЕСКОЕ ОБЕСПЕЧЕНИЕ
ЗАДАЧ ТАКТИЧЕСКОГО ПЛАНИРОВАНИЯ
И СТРАТЕГИЧЕСКИХ ЗАДАЧ УПРАВЛЕНИЯ

5.2.1 .Технико-экономическое планирование

Технико-экономическое планирование предназначено для состав­
ления плана на достаточно длительные (как правило, год) периоды
времени и контроля за выполнением этих планов и включает следую­
щие расчеты: плана производства; производственных мощностей; пла­
на реализации; численности основных рабочих; фонда заработной
платы; потребности в материалах; себестоимости; амортизационных
отчислений; оптовых цен; плана по прибыли и рентабельности.
Основными особенностями технико-экономического планиро­
вания являются:
 1) высокая размерность выхода (планы) и входа (ресурсы);
2) многовариантность расчетов, что вызвано различными вариан­
тами ограничений по ресурсам;
3) итеративность расчета плана;
4) комплексность задач и алгоритмов, поскольку связываются
выпускаемая продукция и ресурсы.
Все задачи в подсистеме делятся на две группы: «прямого счета»
(расчеты не выходят за четыре действия арифметики) и оптимизаци­
онные.
1. Задача «прямого счета» (расчет плана по прибыли и рентабель­
ности).
Введем обозначения: j — 1, / — вид выпускаемой продукции; Спру,
Спр — прибыль от выпускау'-й продукции и всей продукции; Pj — ко­
личество у'-й продукции, выпускаемой за год; Sj, S — цена единицы
у-й продукции и стоимость всей продукции. Тогда

C n p = tC n Wf ;, S ^ S jP j.
j =I i =I

2. Оптимизационная задача.
Примем обозначения:/ = 1, / — вид выпускаемой продукции; (7)
и [ 7] — момент и интервал времени (например, месяц); Pj[ 7] — опре­
деляемый план; aX]/j, у = 1, 'F — норма расхода ресурса vj/-ro вида на
единицу продукции вида у; bxv, f v — наличное и резервное количество
ресурса у-го вида; Rj~[T\ и R / [7] — нижняя и верхняя границы вы­
пуска, величины которых определяются позднее; Q — цена единицы
продукции. Тогда задача составления оптимального плана имеет вид:

R J[T]<=P j [T ]<=R J[T ], у = й ; (5-1)

i > vy/^ ] < = M ° ) { +A(o)};

у=1

J? \ " ’Г Т Р ГТ1 (5 -3 )

Задача (5.1)—(5.3) представлена в общей детерминированной по­

становке. В силу статистического характера спроса вместо нее следует
решать задачу стохастического программирования [26], построенно­
го для целого ряда законов распределения. В силу действия на спрос
множества независимых факторов чаще всего используют нормаль­
ный закон распределения, характеризующийся интегральной и диф­
ференциальной (плотностью вероятностей) кривыми.
Полагаем, что при принятых предположениях маркетинговые ис­
следования проведены и имеются соответствующие числовые дан­
ные.
Возможны различные варианты математической записи стохас­
тического программирования.
Так, часто используют такие параметры случайной переменной х,
как математическое ожидание М(х) и среднеквадратическое отклоне­
ние с(х).
В этом случае в выражении (5.1)

Р Г \Т \ = M (Rj[7]) - a(Rj[T\y,

R+j = M(Rj[T\) +
где Rj — спрос.
Учет вероятностного характера коэффициентов в выражениях
(5.2) и (5.3) осуществляется с помощью Р- и Л/-моделей [32].
M-модель имеет следующий вид:
( J \
(5.4)
M Y^C j, Pj[T] ->max;

(5.5)

M (R j[T ])-3 a (R j[T ]) < P[T] < Л/(Я,[Г])+За(Л,.[Г]), (5.6)

где М — математическое ожидание; В — вероятность; а 0 — заданное

значение вероятности (обычно оно более 0,5, но чаще всего а 0 = 0,8);
а — среднеквадратическое отклонение. Искомое значение Pj[T\ при­
нимается как детерминированное.
Вместо выражения (5.6) часто используют

d j < P j[T \< Dj, (5.7)

где dj и Dj — детерминированные значения.

В этих условиях целевая функция М-модели принимает вид
j (5.8)
'£t M(CJ)Pj [Л - > т а х ,
а детерминированный эквивалент ограничений (при нормальном
распределении)

М { а М Ц + {Ца0)[а 2{а ^ }Р /[Т \ + a 2(bv )]°’5},

где t{а 0) — обратное значение стандартного нормального распреде­

ления. Очевидно, что при заданной величине а 0величина в фигурных
скобках постоянна.
Значения элементов aVj и by принимаем детерминированными, в
силу чего остается ограничение (5.2).
Р-модель имеет вид:

dj < Р \ Т \ < Dj.

Для Z5- модели первоначально строятся эквивалентные законы

интегрального распределения и плотности вероятностей, а затем осу­
ществляется переход к детерминированному варианту, как в Л/-моде-
ли [32].
Нетрудно видеть, что в любом случае задача сводится к задаче ли­
нейного программирования вида (5.1)—(5.3).

5.2.2. Материально-техническое снабжение и сбыт

Назначение данной подсистемы — автоматизация процедур по
обеспечению бесперебойной работы предприятия с помощью соот­
ветствующей организации снабженческо-сбытовых процедур. На
крупных предприятиях данный комплекс задач рассматривают от­
дельно: снабжение и сбыт.
Основные особенности:
1) работа сбытовой и снабженческой частей практически по оди­
наковым законам, поэтому далее рассмотрим только снабженческую
часть;
2) наличие большой номенклатуры ресурсов (тысячи и десятки
тысяч);
3) потребность своевременной подачи ресурсов в производство;
 Рис. 5.3. График изменения запасов:
а — реальный; б — при мгновенных поставках

4) существование двух крайних направлений построения подсис­

темы: работа «с колес» — с помощью метода JIT (Just-In-Time); соз­
дание соответствующих (оптимальных) запасов. Чаще используется
второе направление, о котором далее и пойдет речь;
5) непосредственная связь подсистемы со средой, т. е. откры­
тость. Поскольку подсистема не может прямо воздействовать на сре­
ду, формальный учет ее влияния проводится методами теории веро­
ятностей. Для описания процессов в данной подсистеме сформиро­
валась специальная теория, получившая название «теория управле­
ния запасами». Процессы в подсистеме могут быть отображены
графически (рис. 5.3).
Имеется много разновидностей реализации, в связи с чем следует
провести их классификацию. Ниже приведены основные классифи­
кационные признаки:
• по периоду Т поступления ресурсов — класс с Т = const и класс с
Т — var;
• по иерархии подсистемы — одноуровневые и многоуровневые;
• по изменению спроса — стационарные (темп или скорость
спроса постоянен) и нестационарные (темп спроса меняется);
• по характеру спроса — детерминированные (полностью опреде­
ленные) и стохастические (вероятностные);
• по поставкам p{t) — непрерывные (чаще всего речь идет о по­
ставке энергетических ресурсов) и дискретные (поставки партиями);
• по времени запаздывания т в поставках по отношению к потреб­
ности — нулевое (мгновенный ответ поставщика), детерминирован­
ное и случайное запаздывание;
 • по величине партии поставки —детерминированная и статисти­
ческая;
• по критерию работы подсистемы —линейный и нелинейный.
Перечень основных решаемых задач.
1. Планирование:
• потребности в материалах и комплектующих изделиях в укруп­
ненной номенклатуре на производственную программу;
• специфицированные потребности в материалах и комплектую­
щих;
• лимитно-заборные ведомости поступления материалов;
• график подачи материалов на участки под календарный план;
• потребности в материалах на ремонт оборудования;
• потребности в топливе и энергетических ресурсах.
2. Оперативный учет и контроль:
• оперативный учет движения материалов по складам и предпри­
ятию в целом;
• определение дефицитных материалов;
• учет потерь материалов от брака;
• учет отходов материалов;
• контроль за ходом выполнения поставок.
3. Задачи анализа:
• определение фактических затрат материалов и выявление от­
клонений от нормативов;
• анализ обеспеченности производства материалами на предстоя­
щий плановый период;
• составление сводного статистического отчета.
Оптимизационными задачами могут быть: расчет оптимальной
партии поставок; расчет оптимальных уровней запасов на складах.
Пример задачи (определение оптимальной партии поставок).
Полагаем, что период поставки Т — const, темп поставок p(t) = <х>.
Введем обозначения (см. рис. 5.3): С — цена хранения единицы това­
ра в единицу времени; r(t) — темп потребления; Зпз — затраты на под­
готовительно-заключительные работы для одной партии; П — раз­
мер партии поставок; 0,5П — среднее значение запасов на складе;
Зхр — затраты на хранение; 3 — общие затраты.
Тогда затраты в единицу времени

3 = Зпз/Г + 0,5СП.
Учитывая, что П = гТ, получим
 3 — З п з /-/П + 0 ,5 С П .

Определяя первую производную по П и приравнивая ее к нулю,

получим оптимальное значение
П* = (23пзг/0 ° -5.

5.2.3. Маркетинг
Назначение маркетинга — автоматизация процессов изучения
спроса и активного влияния на рынок путем выпуска пробной про­
дукции.
На поведение рынка оказывает влияние большое число факторов.
В связи с этим описать рынок возможно статистическими методами с
помощью теории вероятностей и теории массового обслуживания.
Чаще всего спрос описывают нормальным законом с помощью мате­
матического ожидания и среднеквадратического отклонения. Кроме
того, особенно в зарубежной практике, широко используют эмпири­
ческие методы описания. Иногда в описании рынка выделяют три
группы задач [4]:
• модели поведения потребителей (изучения рынка);
• модели выработки политик (принятие решений о выпуске на
рынок пробной продукции);
• модели отклика (выявление влияния на рынок выпуска пробной
партии продукции).
Все решаемые задачи возможно разделить на группы. Перечис­
лим основные задачи.
1. Изучение рынка:
• определение спроса;
• определение необходимого количества товара на одного потре­
бителя;
• определение числа потребителей;
• определение общего спроса на рынке;
• определение доли рынка;
• учет влияния конкурирующих товаров;
• определение спроса на новый товар.
2. Политика в отношении покупателя:
• сегментация рынка;
• выбор целевых групп, для которых предназначен товар.
3. Товарная политика:
• определение размера выпуска продукции;
 • рекомендуемая производственная программа;
• рекомендуемые изменения технологии;
• рекомендации по инвестиционным проектам;
• рекомендации по качеству товара, распределение средств по
статьям маркетинга.
4. Ценовая политика:
• определение цен на товар;
• дифференциация и изменения (скидки) цен.
5. Политика распространения товара:
• структура торговой сети;
• логистическая структура (транспорт, складские помещения в
целом, т. е. система снабженческо-сбытовых операций).
6. Рекламная политика:
• разработка концепции рекламы;
• формирование бюджета на рекламу.
7. Коммуникационная политика:
• использование средств массовой информации для рекламы то­
вара.
Рассмотрим алгоритм задачи распределения средств между статья­
ми маркетинга.
Введем обозначения / = 1 ,7 — разновидности рекламных средств;
j = 1, / — сегменты рынка; /= 1, Т — интервалы времени; Ту, = ? — ис­
комая маркетинговая переменная; О — суммарный доход; ку, — цена
единицы маркетинговой переменной; а , р — ограничения на марке­
тинговую переменную; А — общая сумма бюджетных средств; / —
функция (в общем случае нелинейная).
Математически задача может быть сформулирована как задача
программирования:

О = A h) m ax>

,=i j =\t=i

а < Iу, < (3.

5.2.4. Стратегическое управление

Назначение стратегического управления — определение и изме­
нение цели предприятия, ресурсов, необходимых для достижения на
длительный промежуток времени цели и политики, направленной на
приобретение этих ресурсов [37]. Выделяют краткосрочный разрез
(от 2 до 5 лет) и долгосрочный (от 5 до 20 лет).
Специфическая терминология, характерная для стратегического
управления, приведена ниже.
Функционирование — работа системы в рамках заданной структуры.
Развитие — работа системы в рамках острых противоречий, кото­
рые могут вызвать изменение структуры.
Состояние — множество фиксированных характеристик сущест­
венных свойств системы.
Миссия (производственный профиль) — генеральная цель, четко
отражающая причину существования фирмы: каковы ее клиенты и их
потребности.
Стратегия — набор правил и приемов, с помощью которых дос­
тигается основополагающая цель развития той или иной системы.
Политика — провозглашение общих намерений, принципов ра­
боты фирмы.
Тактика — кратковременная стратегия.
Ситуация — совокупность состояний системы и среды.
Программа — совокупность мероприятий, осуществляемых фир­
мой для достижения своих целей и реализации стратегий и требую­
щих определенных ресурсов.
Составной частью стратегии является проект.
Сценарий — множество взаимосвязанных и непротиворечивых
ситуаций будущего.
Характерными для стратегического управления являются:
1) значительная доля неформальных процедур;
2) нестабильность среды, с которой взаимодействует подсистема:
• малая, при которой возможно использование методов экстрапо­
ляции;
• средняя — с использованием экспертных оценок;
• большая — с применением так называемых гибких экспертных
оценок;
3) наличие стратегических возмущений, которые могут быть тех­
нологическими, экономическими, экологическими, политическими
и юридическими. При стабильной экономике наиболее сильны тех­
нологические возмущения.
Компенсация возмущений возможна в следующих направлениях:
конструкторско-технологические изменения в продукции; расшире­
ние доли рынка старой продукции; освоение новой продукции при
старом рынке; освоение новой продукции при расширенной доле
рынка.
 Выпуск
изделий

1198 1999 2000 2001 2002 2012 Годы

Рис. 5.4. Гладкий прогноз потребности в выпускаемой продукции

Перечисленные направления обеспечиваются следующими груп­

пами методов:
• прямыми, при непосредственном влиянии на рынок;
• непрямыми (финансовые, научные, организационные).
В прямых методах в условиях острой конкуренции возможны та­
кие разновидности, как атака, оборона, отступление.
При выборе направления возможно в качестве критериев исполь­
зовать прибыль, рентабельность, безубыточность.
Все решаемые задачи возможно разделить на две группы:
1) обеспечение рынка сбыта, совершенствование старой (выпус­
каемой) продукции;
2) создание и выпуск нового изделия.
В первом случае речь идет о прогнозах на достаточно длительные
промежутки времени. Во втором случае следует оценивать инвести­
ционные проекты.
Рассмотрим первую группу задач. На длительных интервалах воз­
можен гладкий (эволюционный) прогноз в предположении, что си­
туация революционно не изменится (рис. 5.4). Различные революци­
онные, скачкообразные изменения возможно учесть только при экс­
пертном прогнозе.
На основе гладкого и экспертного прогнозов строится програм­
мно-целевой подход (рис. 5.5). Гладкий прогноз «приходит» в точку А.
Экспертный прогноз может приходить в точку В (разность е значений
в точках А и В отрицательна, т.е. е > 0) или точку С (г < 0). Если е < 0,
возникает вопрос о дополнительном выпуске продукции, для чего
строится дерево целей.
Для экспертного прогнозирования в методике ПАТТЕРН [37]
предусмотрены следующие этапы:
1) составление возможных сценариев развития мира с оценкой
вероятности каждого сценария;
 Рис. 5.5. Схема программно-целевого подхода

Рис. 5.6. Дерево целей

2) построение дерева целей для наиболее вероятного сценария

(рис. 5.6);
3) определение коэффициентов важности различных элементов
дерева целей;
4) оценка состояния разработки элементов и сроков выполнения
отдельных этапов;
5) учет взаимовлияния элементов дерева целей.
Существует множество вариантов экспертных оценок, одним из
которых является методика Delphi (рис. 5.7).
Чаще всего оценка ведется в три тура, при этом предпочтительнее
(для уменьшения влияния экспертов авторитетов в данной предмет­
ной области) применение закрытых оценок. Обычно в первом туре
предлагается только перечень вопросов, а во втором туре они «привя­
зываются» к соответствующим датам. В третьем туре осуществляется
уточнение названных дат.
Во второй группе решаются следующие основные задачи.
1. Учет действия рынка.
2. Учет условий конкуренции.
3. Учет сильных и слабых сторон фирмы.
 4. Учет риска и неопределенности текущей
стратегии. *
5. Оценка инвестиций. Составление
вопросника
6. Выявление ресурсных ограничений.
7. Выбор стратегии (в том числе инвестици­
онной).
Рассмотрим в качестве примера выбор (от­
бор) инвестиционных проектов [34]. В этой зада­
че, как и в других задачах данной подсистемы,
велика доля неформальных процедур.
Схема инвестиционного проектирования
показана на рис. 5.8. Под бизнес-планом понима­
ют текст, содержащий в структурированном
виде всю информацию о проекте, необходимую
для его осуществления. Из рисунка видно, что
маркетинговые исследования могут выявить по­
требность в новых продуктах, для создания кото­
рых потребуются инвестиции.
Под инвестированием понимается долго­ ( К о н ец )
срочное вложение капитала с целью дальнейше­
Рис. 5.7. Схема метода
го получения прибыли. Инвестирование пред­
полагает получение прибыли «завтра», а не «се- . номер количество
годня». Инвестиционный проект — план вложе- туров соответственно
ния материальных и финансовых ресурсов в
любую коммерческую сферу деятельности (бизнес) с целью получения
дохода в течение определенного временнбго промежутка. Срок жизни
проекта (горизонт исследования) — промежуток времени, в пределах
которого оценивается эффект от осуществляемых инвестиций.
Следовательно, нужно уметь оценить каждый инвестиционный
проект, сравнить оценки и выбрать подходящий проект.
Оценки нужны прежде всего руководителю предприятия для при­
нятия решений о финансировании проектов из собственных средств.
Если собственных средств недостаточно, используют заемные сред­
ства, для получения которых фирме следует представить кредитору
соответствующие оценки проектов.
Общая схема процедуры отбора инвестиционных проектов пока­
зана на рис. 5.9. Рассмотрим подробнее блок «Оценка инвестицион­
ных проектов».
Оценку инвестиционных проектов осуществим на основе модели
движения денежных средств (бюджетный подход) в процессе выпол­
нения проекта. Критерии могут быть финансовыми и экономически­
ми, например коэффициент ликвидности или коэффициент эконо­
мической эффективности.
 К инвесторам

Рис. 5.8. Отбор инвестиционных про­ Рис. 5.9. Место инвестиционного

ектов:
проект А — соответствует миссии; Б — соот­
ветствует целям организации; В — способст­
вует осуществлению выбранной стратегии;
Г — ресурсы имеются; Д — оценка проекта
положительна
процесса в системе управления:
1,2 — традиционные и новые продукты;
3 — бизнес-план (оценка инвестицион­
ных проектов) для новых видов продук­
ции и отбор инвестиционных проектов;
4 — общий бизнес-план; 5 — собствен­
ные финансовые средства имеются

Коэффициент экономической эффективности — отношение еже­

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

Рис. 5.10. Функции чувствительности NPV к цене и затратам

В силу сказанного расчеты ведутся в постоянных ценах, а все не­

точности (устойчивость проектов) учитываются на основе чувстви­
тельности текущей стоимости проекта (NPV) к различным парамет­
рам (цена продукции, объем ее производства, инвестиционные затра­
ты и т. д.).
На рис. 5.10 приведена функция чувствительности к цене и инве­
стиционным затратам. Характерно, что для приемлемых проектов
должно соблюдаться условие NPV > 0 (условие безубыточности). Из
рис. 5.10 видно, что безубыточность достигается при цене на 20 % ниже
расчетной и инвестиционных затратах, превышающих норму на 30 %.
Если результаты расчетов проекта не нарушаются при отклонени­
ях параметров на величину не менее 10 % от «номинала», то такие
проекты считаются приемлемыми. Если эта величина колеблется от
5 до 10 %, то проект следует либо отклонить, либо подобрать для него
другой вариант.
Необходимо отметить большую трудоемкость подобных задач, в
силу чего для них создаются специальные приложения (COMFAR,
PROJECT EXPERT, Альт-Инвест).

5 .3 . МАТЕМАТИЧЕСКОЕ ОБЕСПЕЧЕНИЕ ЗАДАЧ

ОПЕРАТИВНОГО УПРАВЛЕНИЯ
5.3.1 .Оперативное управление основным производством
Назначение оперативного управления — автоматизация планиро­
вания, учета, контроля и анализа оперативной информации при при­
нятии решений по выполнению плановых заданий на коротких про­
межутках времени (смена, день, пятидневка, декада, месяц).
 Характерной особенностью является дискре­
тизация по времени и координатам в силу дис­
кретного характера продукции. Дискретизация по
времени обусловлена и дискретным характером
процессов самого компьютера.
Отсчет по времени может проводиться с фик­
сированной датой изготовления; с заданным ин­
(',-■)________ (4) тервалом календарного времени; на интервал ка­
лендарного времени.
['/] Дискретизация может быть двух видов (рис.
б 5.11):
Рис. 5.11. Выпуск
1) [</] = М = const, / = 1, 2, 3,... (прецессион­
продукции (о) и от­ ный отсчет по времени);
счет по времени (б) 2) [/,] = var — событийный отсчет.
Отсчет по координатам также может быть раз­
личным: заказ, изделие, сборочная единица, деталь, узел, партия про­
дукции.
Пусть Щ — время изготовления единицы продукции j - го вида.
Тогда количество единиц продукции вида j , выпущенной на интерва­
ле времени [/,], равно

Ц Ш = [/,]/[/,].

Если Nj[tj] 2> 1, то это система с непрерывной координатой, чему

соответствуют объемные процессы, серийный тип производства (рис.
5.11, а, кривые 7 и 2).
Если jV/[//] ~ 1, то это система с дискретной координатой, т. е. ей
способствуют временные процессы, единичное и массовое производ­
ства (рис. 5.11, а, кривая 3).
Для первого случая возможно использовать аппарат линейного
программирования, для второго — алгоритмы календарного плани­
рования (теория расписаний).
Подсистема имеет явно выраженную двухуровневую структуру
управляющей части, в которой верхний уровень осуществляет коор­
динацию элементов нижнего уровня.
Все задачи делятся на две группы: для отдельных подразделений
(внутрицеховые) и для технологической линии в целом (межцехо­
вые).
В межцеховых задачах, в свою очередь, можно выделить следую­
щие группы: согласование работы элементов, задачи упорядочения
соответственно для системы, непрерывной и дискретной по коорди­
натам.
 В задачах согласования темпы отдельных подразделений транс­
формируются в единый темп системы. Описание такой задачи воз­
можно с помощью аппарата линейного программирования.
Задача упорядочения формулируется следующим образом. Имеет­
ся К подразделений, которые чаще называют станками. Порядок за­
пуска деталей на станки может варьироваться. Время обработки каж­
дой детали на каждом станке задано. Необходимо найти такой поря­
док запуска деталей, который доставлял бы экстремум выбранной це­
левой функции. Насчитывается свыше десяти разновидностей
целевых функций, из которых чаще всего используется время изго­
товления всех деталей.
Задача упорядочения имеет аналитическое решение для К = 2, 3
и — при определенных ограничениях — для К = 4. При К > 4 задача
аналитического решения не имеет и потому используются различные
эвристические алгоритмы, в том числе — алгоритмы, справедливость
которых доказана для частных случаев.
Далее будем говорить — если нет специальных оговорок — о се­
рийном типе производства.
Задачи внутрицехового уровня делятся на следующие группы.
1 .Задачи планирования:
• план выпуска по изделиям;
• разработка плана производства деталей;
• определение потребностей в материалах;
• расчет производственных мощностей;
• определение нормативного опережения запуска;
• календарное планирование для отдельных цехов;
• расчет фонда зарплаты;
• расчет загрузки оборудования;
• оперативное планирование материально-технического снабже­
ния.
2. Задачи учета и контроля:
• оперативный учет выполнения плана выпуска деталей;
• учет потерь от брака;
• учет использования материалов;
• учет заработной платы;
• оперативный учет и контроль загрузки оборудования.
3. Задачи анализа:
• анализ выполнения плана;
• анализ использования материалов;
• анализ использования оборудования;
 • анализ незавершенного производства;
• анализ использования фонда заработной платы.
4. Задачи регулирования:
• оперативный учет материалов, необходимых для корректировки
плана;
• корректировка плановых заданий;
• регулирование величины нормативного опережения запуска.
Рассмотрим примеры алгоритмов оперативного управления ос­
новным производством.
Пример 1. Алгоритм расчета плана выпуска (внутрицеховая зада­
ча). ___
Введем обозначения: имеется к-е (к = 1, К) подразделение (цех);
план его выпуска за интервал [/,] = [/] = const, / = 1,1, составляет Рк[Ь].
Существует более крупный интервал [7] = m[t]\ amj — норма расхода
материальных ресурсов; Ьтк — запас материальных ресурсов в цехе к;
<%> Ьцк — нормы расхода и фонды других видов ресурсов; Cjk — цена
работ по производству единицы продукции у'-го вида в &-м цехе;
Pj[ 7 ] — план выпуска продукции завершающим подразделением тех­
нологической линии.
Тогда формальная запись получает вид:
j
^ j amj Рjk IЛ' l'5'- Ьтк (tj ~ 0)
7=1

К к (и -I);
j =i

' £ P j k[tl ]>=Pj[T\, к = К;

7=1

J
F ki = [*,]-> max.
7=1

Пример 2. Календарный план (внутрице­

ховая задача).
Задача согласования представлена выра­
жениями примера 1 совместно со следующи­
ми выражениями (рис. 5.12)
Рис. 5.12. Выпуск продук- у. . 1<= Y Р \t V
ции соседними подразде- Z j mj jk ” i ‘ 2—t jk -\ L*/ Ь
лениями 7=1 7=1
 E E amj Pjk [ft ]<= bmk (0), к = 1;
У = 1 «=1

F = Y L F k t - > max.
*=i/=1
Поскольку задачи в подсистеме динамические (на коротких про­
межутках времени), то для их описания могут использоваться имита­
ционные модели, в частности —динамическая имитационная модель
(ДИМ).

5.3.2. Методы оперативного управления КАНБАН

и JIT (Just-In-Time)
Метод КАНБАН характеризуется децентрализованным управле­
нием («вытягиванием ресурсов»), метод JIT — централизованным
управлением («проталкиванием ресурсов»). Считается, что метод
КАНБАН является разновидностью метода JIT.
В методе КАНБАН предполагается, что полуфабрикаты переда­
ются от транспортно-производственных единиц в контейнерах опре­
деленной емкости. Структурная схема метода [59] показана на рис.
5.13.
Работа определяется спросом в последнем цехе К. Если в контей­
нере на выходе технологической линии имеется готовая продукция,
то она выдается в соответствии со спросом. Если контейнер пуст, то
производственные канбаны (ярлыки) находятся в картотеке 1. Эти
канбаны курьер передает в сборку 2 в соответствии с требуемым коли­
чеством деталей. Если контейнер 5 пуст, то транспортные канбаны
находятся в картотеке 4. Курьер идет в предыдущий цех, снимает с

Цех АТ-1 | ЦехАГ

Транспортные Производственные
канбаны канбаны
контейнера 3 с полуфабрикатами имеющиеся производственные
канбаны и прикрепляет транспортные канбаны. Затем контейнеры
переводятся в следующий цех. Эта процедура повторяется вплоть до
первых цехов. Последние элементы как бы вытягивают ресурсы из
предыдущих элементов, осуществляя децентрализованное управле­
ние. Достоинство метода — изготовление такого количества полу­
фабрикатов, которое нужно в соответствии со спросом, а недоста­
ток — возможная длительность процедуры от конечного цеха к на­
чальному.
При большом количестве канбанов выигрыша от метода нет, при
малом количестве канбанов возможен простой.
Одним из способов расчета оптимального количества канбанов
является теория массового обслуживания. Оптимальное количество
канбанов определяется выражением [11]
N = max{l, [ - ln(l - P \)/ln F — 1]},

где Р] — заданный высокий уровень (например, 0,95) удовлетворения

внешнего спроса; F = p ( 1 —q )/q (\ —р)\ q — вероятность спроса на
контейнеры; F = {0, 1} — случайный процесс (производительность
оборудования); р — вероятность {F = 1}.
Чистый запас по времени [t\ равен

y [t + 1] = tf/] + *М - <?М>

где х и q — фактическое производство и спрос на контейнеры:

[0, ^ N или E[t] = 0;
x[t] =
11, у[/]< N или E[t ] = L

Математическое ожидание объема запасов в накопителе

N 1 ' 1
I (N ) = Y p ( y ) = N ---- — + --------— — .
£ F - 1 (F -l){F }

Вероятность наличия неудовлетворенного спроса

I \ ( N ) = X Р(У) = --------
( f - \ ) { f n+'}

где Р(у) — вероятность нахождения системы в состоянии у.

В методе JIT возможно использовать аппарат линейного програм­
мирования. Имеется несколько вариантов этого метода. В предлагае­
мо
 W'i - Л ~ /i ^ lH -^ + in A+ir *1wk \AP k
к +1 AT
а
тс, ТС,
тыс. долл. тыс.долл.

Рис. 5.14. Метод Just-In-Time:

схема технологической части системы (о); зависимость общих затрат от емкости контейнера для ли­
нейной (б) и нелинейной (в) моделей

мом варианте [8] используются четыре единицы измерения: единица

продукции (или просто единица); контейнер; цена (в долларах) еди­
ницы продукции; период времени (ПВ). Полупродукты передаются
между производственными подразделениями в контейнерах. Запол­
ненные (целиком) контейнеры, находящиеся в данном подразделе­
нии, образуют буферную емкость.
Модель (рис. 5.14) построена при следующих предположениях.
1. Буферная емкость (БЕ) определяется только максимальным
спросом.
2. Между производственными подразделениями (ПП) могут пе­
редвигаться только полностью заполненные контейнеры.
3. Каждое ПП посылает продукцию в свой буфер в конце каждого
промежутка времени (ПВ).
4. Каждое ПП может взять полупродукты только из буфера пре­
дыдущего подразделения.
5. Канбаны собираются в стек (набор) в БЕ в течение ПВ и посы­
лаются в ПП в начале следующего ПВ, чтобы запустить производство
(начать выпуск продукции).
Введем следующие обозначения: к = 1, К — номер производст­
венного подразделения; к = Q м к = К + 1 — среда; [Г,], i = ~ 1 , — ин­
тервал времени.
Параметры: Нк — цена хранения запаса в подразделении к за пе­
риод времени; Sk — цена невыполненных заказов в подразделении /с;
Кк — цена контейнеров, включающая плату за хранение и цену рабочего
пространства в подразделении к\ р — норма передачи; D[tj\ = Dk[t,] —
спрос на конечную продукцию; а* — время опережения запуска (дли­
тельность технологического цикла) в подразделении к\ Uk[t,] — затра­
ты производства в подразделении к', Атк — норма амортизационных
отчислений ;fk — время обработки продукции в подразделении к.
Переменные решения: 0*[/,] — количество заказов (пустых контей­
неров в подразделении к) за ПВ; РкШ — количество продукции (чис­
ло полных контейнеров) в подразделении к; Мк — объем продукции,
загруженной в контейнер; Wk[t] — количество единиц товаров, ос­
тающихся в частично заполненных контейнерах за ПВ; /*[/,-] — число
полных контейнеров в буфере за период [/,-] в подразделении к;
РкШ — число пустых контейнеров за период [/,-] в подразделении к\
Ск — вместимость буферной емкости; Л* — максимальное количест­
во контейнеров в буфере в подразделении к.
Целевая функция — общая стоимость (минимизируется):

T C = ^ ( U k [ti ]+f k A m k ) M k Pk [ti ] + ^ U k [ti ]+Wk [ti ]+

к=\Ы 1 * = 1 /= 1

К I К I К I
+ Е Е в в ] +Z Е W k в к в ]+ Z I X в Vек -> min-
* = 1 / =1 k = \i= \ k = \i= l

Соответствующие слагаемые отражают стоимость продукции в

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

МкРкШ + W M * м кс к

для любых к и /;
б) общее количество продукции не должно превышать количест­
во продукции в процессе хранения предыдущего подразделения

Мк+ \Рк+ i[l] + Щ+ i[l] ^ МкРк{— ак) + Мк 1к[0], / = 1; к = 2, К;

Мк + \Рк+ it^/1 + Щ+ 1[Л] ^ MkPk([ti-1] - + M k h [ t i - i] -

— MkBk[t\- i], / = 2; к — 2, К;
 Л/,/> ,[!]+ Wx[l]<MoIo[0], i = 1,

М \Р\Ш + 1V M < M o № - i], / = 2, /;

в) количество продукции не должно превышать количество про­

дукции текущего запаса буфера

Р\[Ц + 4[0] < Хк, к = 1, К- / = 1;

РМ + Ш < Хк, к — I, К, i = 2 , I.
2. Уравнения баланса продукции, находящейся в частично запол­
ненных контейнерах:
W&\] = М & Д Ц - D&\]-

m t & = m t i - .] - MkO M + D M , i = 2, /;
= m u - .] - MkOk[ti] + Mk+ lPk + dti], k = 1, К - 1; / = 1, /.

3. Уравнения баланса запасов:

— М х Ы 0 ] - М кВ/Л 1] + М к Р к ^ Щ — ак) —

- Z ) * [0 ] , / = 1 ; k = К;

М КШ — М к Ы Ь - 1] = M /(B f( [ti\ — М к В & Ь - i] + М х Р к { Ш — a k) —

- Dn[ti\, i —(ak + 1 ),/ ;

MkIk[ 1] - MkIk[0] = MkBk[ 1] - MkBk[0] + M M 1] - ak) -

- M k + ,Pk+i [\] + Wk + l[l], k = \ , ( K - \ y ,

MkIk[ti\ — MkIk[ti _ i] = MkBk[tj\ — MkBk[ tj- i] + MkPk([tj] — a k) —

—Mk + \Pk + i[/,] + Wk + i[/,-], i = ( a k + 1), /; A: = 1, ( A " - 1).

4. Уравнение баланса количества заказанной продукции в едини­
цах: количество заказанной продукции равно спросу (общему коли­
честву продукции подразделения) плюс невыполненные заказы пре­
дыдущего ПВ минус запас «на руках» в предыдущий период време­
ни минус единицы, находящиеся в частично заполненных контейне­
рах в предыдущий ПВ:

л/*о*ш= Arfi] - м кы оу,

13-2742 193
 MgOfciti] — DK[ti\ + M KBK[ti^ i] — i] — |], i — 2, /;

MkO k[ 1] = M k + l Pk + ] [ 1] - M kIk[0] + Wk + ,[1], к = \ Л К - 1);

MkO k[tj\ = M kPk[tj] + MkBk[tj _ |] - MkIk[ti_ |] - Wk[ t j - 1] + Wk + I[/,],

к = 1, ( К - 1); /= 2 7 7 .

5. Границы буфера:

Хк < max {Dk[ti\, i — 1 , 1}/М к для любого к',

Xk > m m {D k[ti], i = ~ D / M k для любого к.

6. Верхняя граница единиц продукции, остающейся в частично

заполненных контейнерах:

Щ Ш < М к- 1

для любого / и к.
7. Нижняя и верхняя границы емкости

Ск > р , Ск < 1/(fkMk)

для любого к.
8. Неотрицательность переменных

0*[//] > 0, Wk[t] < 0

для любого /' и к.

Из приведенной модели видно, что задача линейна при заданных
(фиксированных) параметрах и нелинейна при переменных парамет­
рах.
Соответственно в ее решении может быть два случая.
1. Задача линейна и представляет собой задачу линейного про­
граммирования.
2. Задача нелинейна и решается статистическими методами, при
этом критерий не минимизируется, а только вычисляется.
Рассмотрим результаты решения этой задачи для К = 3.
В первом случае (см. рис. 5.14) оптимальная вместимость контей­
нера Мк близка к единице.
Во втором случае для зафиксированных параметров количество
испытаний должно быть не менее 10 (\Мк\ = 10). Если учесть все ком­
бинации параметров (даже для случая трех значений каждого из них),
194
то можно убедиться, что количество испытаний должно быть весьма
значительным.
В связи с этим принято К = 3, время опережения запуска — нуль,
вместимость буферной емкости зависит только от максимального
спроса D[tj\. Характер кривых ТС = G{Mk), D =[20, 40], В = [30, 50]
для k = 1, к = 2, к = 3 показан на рис. 5.14, из которого видно, что в
более общем случае оптимальное значение емкости контейнера Мк
близко к трем. Изменение спроса сильнее всего сказывается на по­
следнем подразделении, которое непосредственно воспринимает все
изменения. Для начальных элементов возмущения сказываются в бо­
лее сглаженном виде.

КОНТРОЛЬНЫЕ ВОПРОСЫ

1. Что такое алгоритм и задача?

2. Какие существуют особенности процесса принятия решения?
3. Какие существуют методы решения задач в экспертных системах?
4. Какие компоненты являются обязательными для поддержки принятия ре­
шений?
5. Перечислите требования, предъявляемые к математическим моделям.
6. Какие функции реализует интеллектуальная система?
7. Какова структура интеллектуальной системы?
8. Какие существуют разновидности интеллектуальных систем?
9. Каковы основные свойства информационно-поисковых систем?
10. Каковы основные свойства экспертных систем?
11. Каковы основные свойства расчетно-логических систем?
12. Каковы основные свойства гибридных экспертных систем?
13. Каковы типы моделей представления знаний в искусственном интеллек­
те?
14. В чем отличие фреймовых моделей от продукционных?
15. На какие типы предметных областей ориентированы экспертные систе­
мы?
16. Какие методы используются экспертными системами для решения за­
дач?
17. В чем отличие поверхностных экспертных систем от глубинных?
18. По совокупности каких характеристик определяют особенности кон­
кретной экспертной системы?
19. Что называют демонстрационным прототипом экспертной системы?
20. Какие инструментальные средства используют для построения эксперт­
ных систем?
21. Какие алгоритмы поиска решений используют в интеллектуальных сис­
темах расчетно-логического типа?
22. Каковы особенности гибридной экспертной системы?
23. Определите основные задачи технико-экономического планирования.
24. Каковы особенности задач технико-экономического планирования?
25. В чем отличие оптимизационных задач от задач «прямого счета»?
26. Укажите метод решения оптимизационных задач технико-экономиче­
ского планирования.
 27. Перечислите основные особенности задач материально-технического
снабжения и сбыта.
28. По каким признакам осуществляют классификацию задач материаль­
но-технического снабжения и сбыта?
29. Перечислите основные задачи материально-технического снабжения и
сбыта.
30. Раскройте содержание задач маркетинга.
31. Укажите характерные признаки стратегического управления.
32. Что такое программно-целевой подход?
33. Что такое бизнес-план?
34. Что такое инвестиционный проект?
35. Какую модель используют для оценки инвестиционных проектов?
36. Что такое чувствительность текущей стоимости проекта?
37. Каково назначение оперативного управления основным производством?
38. Какой математический аппарат используют для решения задач опера­
тивного управления основным производством?
39. Укажите примеры алгоритмов оперативного управления Основным про­
изводством.
40. Дайте характеристику методов оперативного управления КАНБАН и JIT.
 ГЛАВА 6
Математическое и алгоритмическое
обеспечение адаптивного
автоматизированного управления

На современном этапе развития автоматизированного управления важное

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

6 .1 . ОБЩЕЕ МАТЕМАТИЧЕСКОЕ ОПИСАНИЕ

АДАПТИВНОГО УПРАВЛЕНИЯ

К формальным методам, используемым в обобщенной техноло­

гии, следует предъявлять такие требования:
1) достаточная адекватность описания процессов в реальных сис­
темах;
2) полное использование возможностей компьютерной техники;
3) возможность поддержания рациональных режимов работы
системы;
4) простота и универсальность алгоритмов, реализующих эти ре­
жимы;
5) более компактный спектр используемых методов, стремление к
однородному аппарату описания процессов;
6) возможность описания процессов в иерархической структуре;
7) учет понятия «экономический интерес»;
 Рис. 6.1. Единая математическая модель многоуровневой системы управления

8) возможность описания стационарного и нестационарного ре­

жимов;
9) учет динамики системы.
Единый аппарат описания (рис. 6.1) может иметь следующий вид:
объект управления
z = Az(0 + Bu(/);

У(0 = CZ(0;

HG(p(0, u(0) < b(/), (6.1)

управляющая часть
e(t) = р(/) - у(0;
т т
/ = - | < С 3, p(/)>dr+ J{<C3, e ( 0 > + < C 2, u ( / ) > } d r +
о о
т
+ |{ et(0Q e(0 + uT(0Ru(0] d/- » min, (6.2)
о
где р, z, и, у, е, b — векторы плана, состояния, управления, выхода, от­
клонения, ресурсов; А, В, С, Н — матрицы, характеризующие дина-
198
мику; G — функция; С3 — стоимостная оценка плана (например,
прибыль); С2 — потери за счет отклонения от плана и потребности в
дополнительных ресурсах для управления; Q, R — симметричные
матрицы, характеризующие процесс управления.
Действительно, данная модель охватывает все возможные режи­
мы и варианты описания.
Из (6.1) следует, что процесс управления в многоуровневых систе­
мах может быть декомпозирован на процесс планирования (целепо-
лагания) и (собственно) управления.
При планировании вектор возмущений |(/) не учитывается и по­
тому е(/) = и(0= 0, р(0 = y (t),z (t) = Р(0 и описание получает вид:

Р(0 = АР(0;

р(/) = СР(/);

H G (p(0)< b(0;
т
J = - J < C 3, p(/)>-»min, (6.3)
о

где р(0 — ежедневный план или размер запускаемой партии; Р(г) —

план с накоплением (например, с начала месяца). Выражение (6.3)
доказывает возможность сочетания аппаратов линейного програм­
мирования и оптимального управления.
Нетрудно заметить, что модель представляет собой систему мето­
дов динамического линейного программирования (ДЛП) и опти­
мального управления (ОпУ). Возможны следующие сочетания этих
методов:
1) ОпУ - ОпУ;
2) Д Л П - Д Л П ;
3) О п У - Д Л П ;
4) ДЛП - ОпУ.
Достоинством первых двух методов является полная однотип­
ность описания процессов.
Однако в первом случае применение ОпУ для описания процесса
планирования избыточно. Кроме того, использование, как правило,
квадратичных критериев в ОпУ затрудняет экономическую интер­
претацию результатов.
Во втором случае применение ДЛП для процесса управления вы­
зывает серьезные математические затруднения. К тому же возникают
сложности с согласованием интересов элементов и уровней, для ко­
торого чаще используют квадратичные критерии.
Третий случай страдает недостатками первых двух случаев.
Четвертый случай позволяет использовать как экономические (в
процессе планирования), так и «управленческие» (в процессе управ­
ления) критерии. Он является самым подходящим и используется в
дальнейшем.
К относительно самостоятельному процессу планирования в
многоуровневых управляющих системах предъявляются следующие
требования [35]:
• использование методов, обеспечивающих оптимальные и ра­
циональные режимы функционирования;
• учет высокой размерности описываемого процесса;
• многовариантность планирования;
• многоуровневый характер планирования;
• возможность корректировки текущего плана с сохранением ко­
нечного значения его выполнения (терминальное управление);
• учет многокритериальное™ и приоритетов критериев при рас­
чете планов;
• учет возможностей форсированных режимов, сохранения вели­
чины нормативных сроков изготовления, минимальных значений за­
пасов (незавершенного производства), ритмичности работы систе­
мы;
• возможность замены (перераспределения) используемых ресур­
сов;
• работа со стохастическими исходными данными;
• стыковка с методами управления.
В плановой экономике в процессе планирования широко исполь­
зовалась детерминированная задача линейного программирования,
которая в общем случае имеет такой вид:

Р[т] > R[x];

АР[т] < Ь[т];

<С,Р[т]> -> max, (6.4)

где Р, R — вектор-столбцы плана и директивных цифр; А, С — матри­

цы норм расходов ресурсов и стоимостная оценка единицы продук­
ции (например, прибыль); b — матрица наличных запасов ресурсов;
т — интервал времени; <.,.> — скалярное произведение.
 При переходе к рыночной экономике R[ t ] — спрос на продукцию,
полученный в результате маркетинговых исследований. Часто мно­
жество R[x], представляющее собой набор видов продукции, которые
возможно производить на данном производстве, называют портфе­
лем заказов.
При современной рыночной экономике спрос и стоимостная
оценка носят вероятностный (стохастический) характер и в силу мно­
жества независимых действующих на них факторов имеют чаще всего
нормальное распределение.
Полагаем, что при принятых предположениях маркетинговые ис­
следования проведены и имеются соответствующие числовые дан­
ные. В этих условиях следует использовать [26] стохастическое про­
граммирование в виде Р- и А/-моделей, которые приводятся к эквива­
лентным детерминированным вариантам вида (6.4).
Следует отметить, что возможно использовать несколько алго­
ритмов для решения задачи динамического линейного программиро­
вания.
«Косвенные» приемы характеризуются следующими методами:
1) пересчет плана после каждого шага по времени. Задача получа­
ет большую размерность и может стать несовместной на последних
интервалах времени;
2 ) переход к задаче статического линейного программирования
при соблюдении определенных условий на состояние системы. К со­
жалению, это условие часто не соблюдается.
«Прямые» приемы связаны со следующими методами:
1) метод А.И. Пропоя, проводящий аналогию с методами статиче­
ского линейного программирования. Однако в рамках этого метода
фактически отсутствуют конструктивные алгоритмические решения;
2) метод А.И. Егорова [17], использующий свойства фундамен­
тальной матрицы. Применение метода связано с некоторыми затруд­
нениями в автоматическом нахождении фундаментальной матрицы
при сложном описании (передаточной функции) исследуемого эле­
мента, к тому же появляются сложности в согласовании интересов
элементов;
3) метод Р. Габасова[ 14], связанный с «опорным» решением задач
как динамического линейного программирования, так и оптималь­
ного управления. Процесс решения получается достаточно кропот­
ливым, однако здесь унифицирован аппарат решения математиче­
ских задач различных классов.
Методы описания процедуры управления должны отвечать сле­
дующим основным требованиям:
 • возможность синтеза на базе комплекса свойств (векторного
свойства), которые, с одной стороны, удовлетворяли ЛПР, а с дру­
гой — позволили обеспечить высокое качество процессов управле­
ния (управленческие критерии);
• возможность описания различных видов технологических про­
изводственных структур;
• учет многомерности, многоуровневого характера управления;
• поддержание (удержание) с помощью управления оптимальных
режимов функционирования систем, характеризующихся многокри-
териальностью и приоритетностью экономических критериев, опре­
деляющих динамику;
• учет замены ресурсов;
• возможность описания изменения структуры и определяемых
ею динамических свойств.
Всем этим требованиям удовлетворяет предложенный ранее ап­
парат описания.
В процессе управления возможны два случая:
1) осуществляется слежение за заранее рассчитанным планом Р(/)
при достаточном количестве ресурсов для управления — в стацио­
нарном режиме;
2) меняется план Р(/) — в стационарном режиме при недостатке
ресурсов с последующим выходом на начальный план, в нестацио­
нарном режиме при переходе на выпуск новой продукции.
В первом случае значение первого интеграла выражения (6.2) по­
стоянно и не влияет на значение и(/) в критерии. Иными словами, ис­
пользуется критерий
т т
/= J{<Cb 8(1) > + <с2, u( 0 >}dr+ jV(0Qc(0 +
о о
+uT(/)Ru(0}df -* min. (6-5)
Можно показать, что в этом случае, не снижая общности, крите­
рий приводится к виду
т
J = J{eTi(/)Qei(0 + uTi(r)Rui(/)}df-> min. (6 -6 )
о
Тогда объект управления имеет вид
к
г k (t) = A*z*(/) + B*u*(0 + X A # z 7-(0 + B0jfcU0(/) + w * (0 ,
j= \J * k
 z*(0) = z*o, Ук{1) = C kz k(t), u*(Oj*=o = U0(/), (6.7)
или
К
Й-z к (Т) — AicZic( 7) + Вкик(Т)+ Y j A kjz j ( 7’) + В0Аи 0(7 ) + v/k(T),

к = 0,К ,

z*(0) = z*o , y k( T ) = C kz k( 7) (6.8)

при

где г к, uA, у к, v/k — вектор-столбцы состояний, управления, выхода,

возмущений; А к, Вк, A kJ, В0А, В0, С* — матрицы подходящей размерно­
сти; [Г] = ц[7], ц = 1/25, ц — малый параметр, учитывающий измене­
ние масштаба по времени; К — число элементов системы. Отсчет по
времени t называют быстрым, а по Т — медленным.
Описание управляющей части имеет вид:

e*(P) = P*(P) - У*(Р), Р = t или р = Г;

Jkl = 0 M ( y ) S k£ k(y) + 0,5yj{e*T(P )Q ^ (P ) + U*T(P)R*/U*(p)}dp -> min

о

/ = 1, Lk, у = T или у = x, (6.9)

к
J\ - ’ (6. 10)
k=\

где г к — вектор-столбец отклонений; Qt/, Rkl — положительно полу-

определенная и определенная матрицы; S kl — матрица, определяю­
щая конечные условия; Jkl — целевая функция; Lk — число целевых
функций; дискретный план заменен на непрерывный р^(Р).
Оптимальные модели позволяют провести согласование эконо­
мических интересов, выявить предельные возможности системы, по­
лучить аналитическое, обозримое решение. Однако оптимальный ал-
горитм может дать недостаточно адекватное описание системы, вы­
зывая, например, сложности с учетом алгоритма работы ЛПР.
В связи с этим полезно применить такую последовательность:
сначала строят имитационную модель, которую затем улучшают пу­
тем применения оптимальных алгоритмов. Подробно процедура ис­
пользования предложенного единого математического описания
приведена в работе [46].

6 .2 . ПЛАНИРОВАНИЕ ПРИ ИЗМЕНЯЮ ЩЕМСЯ

СПРОСЕ

6.2.1 .Технология решения задачи планирования

Процесс планирования выполняет функцию целеполагания в ин­
теллектуальной (в терминах адаптивной) системе управления.
Возможно выделить два режима планирования:
1 ) стационарный — при фиксированных (неизменяющихся)
структурных связях;
2 ) нестационарный — с изменяющимися структурными связями
системы при переходе на выпуск новой продукции.
Математическое описание второго режима базируется на матема­
тическом описании первого режима. В связи с этим первоначально
рассмотрим стационарный режим, а затем — нестационарный.
Реальная производственная задача — линейное программирова­
ние (ЛП) имеет высокую размерность (порой значительно превы­
шающую 1000 х 3000) и большое время [/р] решения. Для решения та­
ких высокоразмерных задач сложились две группы методов (рис. 6 .2 ):
1 ) решение задачи «целиком» с помощью «скоростных» методов;

2 ) декомпозиционные методы.

В первом направлении для снижения трудоемкости вычислений

используют адаптивные, эллипсоидные и другие родственные мето­
ды, методы, учитывающие разреженность матрицы А в выражении
(6.4). При этом скорость вычислений возрастает примерно на поря­
док.
Большим, на наш взгляд, эффектом обладают декомпозиционные
методы, являющиеся порой единственной возможностью решения
задачи.
К декомпозиции целесообразно обращаться при выполнении од­
ного из условий: 1 ) [/р] > [/о]; 2 ) [/р] > [7Ь], где [/р] — время решения
задачи; [/о] — время, отводимое на решение задачи; [ 7Ь] — нефор­
мально установленный интервал времени (например, смена, не­
 Рис. 6.2. Технология процесса планирования:
А — режим статический; Б — решение целиком

Рис. 6.3. Согласование интересов

сколько часов), количественно характеризующий понятие «значи­

тельное время решения задачи».
Принятие решения о выборе декомпозиционных методов полез­
но осуществлять в диалоге с компьютером (рис. 6.3).
При расчете «целиком» количество уровней структуры решения
(см. подразд. 6.2.1—6.2.4) совпадает с числом уровней структуры опи­
сания процесса. При расчете по частям структура решения (см. под­
разд. 6.2.5) имеет на один уровень больше, чем структура описания.
 В общем случае искомая величина оптимального плана Р[ 7] опре­
деляется ограничениями A/(R[7]) —3o(R[7]) < Р[7] < M(R[7]) +
+ 3ct(R[ 7]). В дальнейшем для удобства будем это выражение записы­
вать в виде R+[ 7] > Р [7] > R~[ 7]. В ряде случаев может быть использо­
вано только одностороннее ограничение P[7]>R ~ [7],
Рассмотрим сначала решение задачи целиком.
Возьмем за основу описание процесса планирования в виде Т-за­
дачи:

APfo] - z[//_,] < 0;

m
R+[7 1 > X P [/,]> R -[7 ];
/=1

m
]>>(/,_,)< b(rm_ ,), b(?o) = b(0 ), (6 . 1 1 )
/=1
m
/XP[4]) = Z < C /, P W > -> m ax , / = 1ТТ.
/=i
Имеется важная разновидность, учитывающая возможность за­
мен ресурсов ( К-задача). Эта задача ранее не встречалась, потому рас­
смотрим ее подробнее.
Для верхнего уровня h = 3 в случае возможности замены ресурсов,
обеспечивающих гибкость к процессам, можно записать:

АР[/,] - V[/,] < 0, / = Т77й;

m
R [7] > 2 p [/,]> r -[71;
/= 1

m
QV[/J й z(f,-- 1 ), £ > (/, _ ,)< b (/ffl_ ,), b(/0) = b(0), (6.12)
/= 1

m
Ш Ч '/]) = £ < С /, P W > - < D /, Ь(//я- ,)> -» max, / = ITT,
/= 1

где P = { P /M ,У= 177}, R[7]_f {R/[7]}T, b(f,) = ^ V = V *7, V = m, q,

s; m = 1, M, q — 1, Q, s = 1, 5}T — вектор-столбцы исходных планов,
спроса и наличия ресурсов (материальных т, трудовых s, оборудова­
ния q);j(j = T j ) , \|/ — виды выпускаемой продукции и потребляемых
206
ресурсов; А = {aVj} — матрица норм расходов ресурсов; С] = {с1у} —
вектор-строка коэффициентов /-Й (/ = 1, L) целевой функции; V[/(] =
= {Vr[^,], г = 1 , Л} — вектор-столбец конструкции (совокупности
взаимозаменяемых ресурсов); г (f,) b (tm_ ,) — вектор-столбцы ресур­
сов; Q = { ^ г} — матрица, определяющая долю ресурсов \\/ в конст­
рукции г ; D/ — вектор-строка размерности у ; < , > — скалярное
произведение.
Очевидно, что

v=i

Процесс решения задачи (6.12) с позиций математических имеет

формальное представление, с позиций же прикладных носит ярко
выраженный неформальный характер.
Следует отметить, что целевая функция в формуле (6 .11) ориенти­
рована на имеющиеся ресурсы. Поскольку в ней последнее скалярное
произведение постоянно и не влияет на решение, его можно исклю­
чить из целевой функции. При учете потребных ресурсов целевая
функция
т т
F m t A ) = <С/, XР[*,]> - <D/, £ а р [,.)> _> таХ) / = T7L,
/=! /= 1

или
т
FffltA) = <С/, £ Р [/,]> -> max, l = \ T L ,
(=1

где С/ = С ,—D,A.
В связи с этим далее будем в целевой функции вида (6.12) учиты­
вать первое скалярное произведение.
Отметим, что задачи (6.11) или (6.12) имеют /«-интервальную
структуру и, как следствие, чрезвычайно высокую размерность задачи.
Для снижения размерности Г-задач возможно, как доказано в [13,
14], применение агрегирования описания и переход к двухинтерваль-
ной структуре с последующим решением (т — 1 ) двухинтервальных
задач. Тогда задача (6.11) получает вид:

АР[Тр\ < Ъ(ТГ), Ь(/0) = Ь(0);

R+[TP] > Р[ Тр] > R 1 7 ,]; (6.13)

207
 F/(P[7>]) = <C/, P[ 7>]> + <D/, Ь(ГГ)> -> max, 1 = 1 , L,
где P, b, R — вектор-столбцы искомого плана, ресурсов, спроса;
А — матрица норм расходов; С, — вектор-строка цен на готовую про­
дукцию; L — количество разновидностей целевых функций. Если
есть возможность замены ресурсов, выражение (6.13) незначительно
усложняется:

A P[7> U V [7y;
R+[7>] > Р[7>] > R [7>]; (6.14)
\ [ Т Р\< Ъ(Т Г), b(0) = Ь(0),

F№[TP]) = <С/, Р[Гр]> -> шах, / = 1, L.

В матричной форме выражения (6.11)—(6.14) представлены в ра­
ботах [13, 14].
Для среднего уровня h = 2 можно записать
А*Р*[ Гр] < М Тг), к = Т7К, (6.15)

Fi(PklTp]) = £ < C lk, Р*[7>]> -» max, lk = T7Z*, (6.16)

*=i
b*(Tr) = b*(0) + [ 7ЖР*- i[7>] - А Л ] Tr]), (6 .17)
где К — число элементов на уровне, а остальные обозначения те же,
что и в (6 . 1 2 ).
С учетом А*Р*[/,] = [ r ' ] _lbt;(//_ 0, где \ Т'] — диагональная матри­
ца длительности технологического цикла обработки полуфабрика­
тов, выражение (6.16) можно представить так:

[П(р*[/,-+.] - рmm = (а*)-1р*- ,[/,] - р*[/,]. (6.18)

Нетрудно видеть, что в (6.18) величина Р*[/,] отражает величину
партии запуска, а [ Т'\ — время опережения запуска. Достоинством
записи (6.18) является явная системная зависимость всех переменных
в процессе планирования.
Удобно выражение (6.18) с приемлемой точностью заменить на
следующее:
m m
G k = A k 1 В Д 1 - X P * - .№ 0 . (6.19)
/ =г+1 /=/■+1
 Выражение (6.18) описывает горизонтальные связи, а вертикаль­
ные имеют вид
т
Н, = А, Х р ,[г,]-Ь (7 ;)< 0 ; (6 .20)
i=r+1

т
Н* = ^ Р к[Г,]-ЩТр )йО. (6.21)
i—г+\

Нижний уровень h = 1 характеризуется набором несвязных фикси­

рованных (к = fixe) элементов, описываемых ограничениями (6.15) и
целевой функцией:

F/*(P[Тр\) = <С/*, Рк[Тр]> -> max, (6.22)

к = fixe, fcel, К. (6.23)

Для рассмотренного оптимального планирования с одной целе­

вой функцией (скалярным критерием) характерны следующие обсто­
ятельства:
1 ) выбор вида целевой функции — процедура неформальная и не­
однозначная;
2 ) вид целевой функции оказывает существенное влияние на ха­
рактер функционирования системы;
3) использование только одного критерия характеризуется полу­
чением «крайних» решений, не учитывающих в достаточной мере
факторов, имеющих место в реальной системе.
Для «сглаживания» этих крайностей применяют векторную целе­
вую функцию (многокритериальную постановку задачи). В качестве
элементов векторных целевых функций могут использоваться крите­
рии, указанные в [39].
Составляющими критерия могут быть: выпуск товарной продук­
ции; производительность труда; рентабельность; фондоотдача;
удельные затраты на выпуск продукции; объем и стоимость незавер­
шенного производства; себестоимость. В [43] в качестве составляю­
щих векторного критерия выбраны прибыль, доход, объем товарной
продукции в оптовых ценах, нормативно-чистая продукция. Незави­
симо от выбора критериев формально в линейном варианте они раз­
личаются коэффициентами (весами) а/ при целевых функциях.
Нахождение решений при векторной целевой функции математи­
чески существенно усложняется и связано с определением равнове­
сия по Парето [10].
 Полученные ранее оптимальные значения планов Р[ Тр\, P\[tj\
вычислены для скалярных целевых функций. Не снижая общности,
считаем их первыми (/ = 1 , 4 = 1 ) в векторных целевых функциях
(6.12), (6.14), (6.21) и обозначим через Р/ [Тр], Р /*[/,■] (илиР« [Тр]). ^
Аналогично решаются задачи для критериев Fi Р [ Тр]) и F/(P*[/,])
для I = 2, L и lk = 2, Lk соответственно и получим значения Р/ [ Тр],
Р !кЩ. Результаты решения векторной задачи в значительной мере
определяются самой (неформальной) постановкой (схемой компро­
мисса) задачи — переходом от векторного критерия к скалярному.
Учет L критериев возможен двумя основными группами спосо­
бов:
1 ) веса критериев заданы (назначены) априорно (экспертами);

2 ) веса определяются в процессе решения задачи, сводящимися в

итоге к сворачиванию векторного критерия F/ к скалярному У7 через
веса а/:

F(P *[7’/,]) = ^ < x l.F](P *[Тр]) —>max, £ а , -1, а , >0. (6.24)

/=1 /=1

Воспользуемся анализом методов векторной оптимизации [7],

который рекомендует использовать способы второй группы.
При этом возможны следующие методы:
а) наименьших потерь локальных целевых функций от оптималь­
ных значений (метод С1);
б) минимальных потерь от всех критериев (метод С2);
в) идеальной точки (метод СЗ).
Для их формального представления введем (при F/mщ = 0) обозна­
чение
g/(P[7>])= 1 +d/(P[7>]),
d/(P[7>]) = - F,(V\TP])/F,mm,
где FlmaX' Flmin — максимальное и минимальное значения целевых
функций.
Очевидно, что g/ -» min соответствует Fi —> max.
В методе С2 задача векторной оптимизации приводится к виду
АР[7>] < Ь(7»;
г! > g, ( В Д ) , (6.25)
z/ -> min.
 В методе СЗ первоначально определяют оптимальные значения
Р { Тр] и Г/тахдля отдельных l-х критериев, а затем решают задачу

АР[ТР] < Ъ(ТГ);

F(P[Tp ]) = ^ { F , max - Fx(Р[Тр D} 2 - > min.

i =i

Окончательный выбор применяемого метода векторной оптими­

зации определяет исследователь (ЛПР). Для работы ЛПР с позиций
простоты алгоритма и времени его реализации можно дать следую­
щие качественные рекомендации:
• метод СЗ наиболее подходит по физическому смыслу, однако
осложнен необходимостью решения задачи квадратичного програм­
мирования;
• при дробно-линейных целевых функциях [46] метод С2 также
трансформируется в задачу квадратичного программирования.
Поскольку векторный критерий может быть приведен к виду
(6.24), далее оперируем с описанием вида (6.11).
Для сложной многоуровневой системы, описываемой выраже­
ниями (6.13), (6.15), (6.16), (6.17), (6.19)—(6.22), рассмотрим более
подробно выделенные ранее такие технологические стадии (см. рис.
6 .2 ) получения решений.
П1. Учет векторного критерия с определением чувствительности
решения.
П2. Проверка ресурсного обеспечения для выпуска продукции.
ПЗ. Согласование работы элементов и уровней.
П Л1. Планирование при оперативно изменяющихся структурных
связях.
П4. Выделение (классификация) сильно связных множеств, опре­
деляющих соответствующие компоненты.
П5. Декомпозиционное определение оптимальных планов.
На стадиях П 1, П2, П4, П5 используют прежде всего стандартные
локальные алгоритмы, в силу чего речь идет о выборе наиболее под­
ходящих из них. Описание некоторых алгоритмов преследует лишь
цель сохранения системности описания процессов.
На стадии ПЗ (см. подразд. 6.2.3) предложены оригинальные алго­
ритмы, описанные более детально в приложении 2 .
Первоначально введем следующие допущения:
Д1) целевые функции элементов и уровней согласованы;
Д2) структурные связи системы не изменяются.
Ограничения снимаются в данной главе позднее.
 6.2.2. Ресурсное обеспечение плана
Задача ресурсного обеспечения плана (и прежде всего спроса Rj~,
j = 1 ,J) (см. рис. 6 .2 ) с математической точки зрения означает выпол­

нение второго этапа решения задачи линейного программирования

(ЛП) — нахождение допустимых решений, т.е. совместности систе­
мы ограничений (6.13).
Наиболее часто система неравенств высокоразмерной задачи ЛП
является несовместной, т.е. спрос R~ = {/?у- } не обеспечивается необ­
ходимыми ресурсами. Следовательно, надо определить условия, га­
рантирующие совместность. Здесь возможно несколько случаев:
1) определение плана Р'[7] < Р[7] < R~[7], который может быть
выполнен при имеющихся ресурсах;
2 ) определение минимального дополнительного количества ре­

сурсов АЬ(7’Г), позволяющих выполнить заказ R [ Тр]\

3) сочетание первого и второго случаев.
Для определения условий совместности, как показано в [43], воз­
можно использовать методы квазиобратных матриц, прямое вычис­
ление, метод невязок, в том числе многокритериальную оптимиза­
цию. Два первых метода проще в решении, однако они определяют
лишь границу совместности, не учитывая стоимостных характери­
стик.
В связи с этим предпочтителен последний метод. При его исполь­
зовании в общем виде необходимо решитьдополнительную задачу:

Р[ 7"р] + AR~[ Тр\ > R-[7>];

АР[7>] < Ь(Гг) + АЬ(7»; (6.26)

F = <С, AR_[7]J> + <D, Ab(7»> -> min,

где С и D — стоимостные веса.

Для определения степени превышения границы совместности
информативны двойственные w* и wr оценки задачи (6.26):

ATw*( Tr) —W/?[ Тр] > 0;

w*[ Тр] < - С;

w*( 7» < —D;

F = <Ъ(ТГ), у/ь(Тг)> + <R“ [ r p], W/}[7],]> -> min.

 Чем выше эти оценки, тем более расширяется область
Ь*( Тг) = Ь(ГГ) + АЬ( Тг) и сужается область R [ Тр\ = R [ Тр] + AR_[7}J.
Чаще всего используется вариант AR [ 7},] = 0 и ЛЬ( Тг) ф 0, кото­
рый рассмотрен далее.
Вопросы ресурсного обеспечения тесно связаны с постоптималь-
ным анализом чувствительности решений:
• определяют область [bymin( Tr), bymax( Тг)\ инвариантности реше­
ния Y[Tp], т. е. границы изменения вектора Ь^(ГГ), в рамках которых
вектор решения не изменяется;
• определяют «грубость» решения и осуществляют более рацио­
нальный выбор значения вектора Ь*( Тг).
Совместность задачи (6.13) в целом может быть проверена и с ис­
пользованием декомпозиции, как показано в [7].
После определения (одним из рассмотренных способов) величи­
ны Ь*( Тг) возможно решить задачу (6.13) «целиком» любым из извест­
ных (в том числе последовательных [46]) методов.
Далее полагают, что системы неравенств, используемых на раз­
ных уровнях иерархии управления задач линейного программирова­
ния, совместны.

6.2.3. Согласование интересов элементов и уровней

Снимем допущение Д1 (целевые функции элементов и уровней
согласованы) подразд. 6 .2 . 1 и рассмотрим более подробно процесс
согласования работы (координации целевых функций и ограниче­
ний) элементов и уровней.
В задаче согласования интересов в принятой трехуровневой сис­
теме могут быть выделены два класса задач:
1 ) горизонтальное согласование элементов к = 1 , А" на уровне
И = 2 (см. рис. 6 .2 );
2 ) вертикальное согласование:

а) элементов к = 1, К уровня h = 1 с элементами уровня И = 2 (см.

рис. 6 .2 );
б) элементов уровней h = 2 и h = 3.
Для решения перечисленных классов задач представим описание
(6.15), (6.19)—(6.22) уровня И = 2 в несколько иной форме:

^ i(P J ^ ]) = I ^ ( P ^ ] ) - > m a x ;
к =1

\ \ Р к[Тр] < Ь2к(Т г), к = [ , к- (6.27)

213
 А \ Рк[Тр] < Р к' . Л Т р], к = 2, К;

p k- d T P\ > р ; _ , [ Тр]- (6.28)

РЛТр] > R“ [7>], к = К-

А \Р ,[Тр\ < Ь(7;), к = 1, (6.29)

где P fc_ | — минимально необходимое количество материальных ре-

Выражения (6.28) характеризуют горизонтальные (класс 1) связи,

а выражения (6.29) — вертикальные (классы 2а и 26) связи. Ограни­
чения в выражении (6.27) будем называть локальными.
Отметим, что при определении P*[f,-] вместо Р к[Тр\ размерность
задачи существенно увеличится. Однако ^-интервальную задачу мож­
но по-прежнему решать как ( р — 1 ) двухинтервальных задач.
Для решения задачи класса 1 используем выражения (6.22), (6.27),
(6.28). Не снижая общности, можно положить, что целевые функции
к-х элементов — векторные.
В задаче класса 1 рассмотрим два случая:
1) локальные ограничения (6.28) не влияют на решения, т. е. все
да соблюдаются условия

А2кРк[Тр] < Ъ\(ТГ), к = I, К; (6.30)

2) условия (6.30) не соблюдаются.

В первом случае ограничениями (6.30) можно пренебречь. Для
этого случая предлагается алгоритм 2 . 1 приложения 2 .
Возможно использовать теорию игр — равновесие по Нэшу (ал­
горитм 2 . 2 приложения 2 ) и методы решения задач с векторным кри­
терием.
При использовании теории игр можно, не снижая общности, счи­
тать, что для элементов к = 1 , п величины AFk < 0 , а для элементов
к = п + \, К (п, я + 1 е 1, А) величины AFk > 0. ______
Очевидно, что при плане Ргк[ Тр\ потери несут элементы к = п + 1, К
и система в целом, при плане Р \[ТР] потери характерны для элемен­
тов к = 1, п. Тогда в интересах системы в целом целесообразно допол­
нительный выигрыш
 к

r=n+l

при плане Р*[ Тр] перераспределить с учетом элементов k = 1, п по

правилу

5/v = ( b AFr\ AFL (6.30a)

Kr=n +1 k=\

Можно показать, что решение (6.30а) существует. Тогда компро­

миссным (равновесным) решением будет Р'*.[ Тр], а значения целевых
функций

Fk <Pl[Tp ])+8Fk , k = l , n ,
Рк Г к[Тр\) = (6.306)
Fk (P'k[Tp] ) - 8 F k , k = n + l , K .

Устойчивость равновесия по Нэшу показана в алгоритме 2.3 при­

ложения 2 .
Недостатки использования равновесия по Нэшу — итеративный
характер решения и потребность для к -го элемента информации о
всех других элементах (что практически исключено и избыточно).
Эти недостатки не имеют места при использовании предложен­
ных авторами в [46] методов решения векторных задач. Введем обо­
значения:

Fk <p'k[Tp ]), k = l,n,

к min (6.31)
Fk (P£[Tp ]), k = n + l , K ;

'Fk (P2k [Tp ]), к = й ,

к max (6.32)
Fk (Pl[Tp ]), k = ~ n 7 l K ;

s k ={Fk max - F k (P'k[Tp ])}/{Fkmax - F kmin}, (6.33)

где P^[ Tp] — компромиссное решение.

Тогда для решения задачи согласования можно использовать ме­
тоды С2 — СЗ векторной оптимизации.
При использовании метода идеальной точки (СЗ) целевые функ­
ции могут иметь вид
F ' = ^ Fk ^ l [ T p])-Fkr k[Tp\)}2+ £ { ^ ( Р ^ ] ) - / ^ ( Р В Д ) } 2^ т т
k =I k=n+\ (0.34)

ИЛИ

^ = 1 { Р * [ ^ ] - Р ; [Tp]}2 + h ^ T p]-P'klTpr -»m in.

k= 1 *=л+1

В силу выпуклости области ограничений и целевой функции ре­

шение, если оно существует, единственно.
Во втором случае — если условия (6.30) не соблюдаются — необ­
ходимо предварительно рассмотреть одну из задач ресурсного обес­
печения:
1 ) определить потребность в минимуме дополнительных ресурсов

АЬ\ { Т Г), обеспечивающих условия (6.30);

2 ) если дополнительных ресурсов нет (АЬ2*(7» = 0 ) или решена
лишь задача

А?кР'к[Тр] - Ь2к(Тг) -» min,

необходимо найти новое значение плана Р*[ Тр] (очевидно,

Р "к[Тр] < ¥\[Тр]), которое можно использовать в алгоритме 2.1. Значе­
ния Р \[Тр] определяют следующим образом.
1. Находят значения P 'j[ Тр] = [A2k]'b2k(Tr), где [А*]+ — квазиоб-
ратная матрица, к = I, К.
2. Определяют число г (г е 1, К), для которого выполняется усло­
вие

АРГ[ТР] = max {Р'V[TP\ - Р '\[ТР]), v = Т7Х

3. Тогда Р В Д = Р " 2 [ Тр], Р'; + ,[7 у = Р" 2 [7>] для к > г, Р " _ Х[ТР] =
= [Аг]+Р" 2 [7],] для к < г, где [А2 + i] — по-прежнему квазиобратная
матрица.
Задачи (6.29) вертикального согласования (класс 2а) решаются
наиболее просто. Напомним, что элементы являются согласованны­
ми, если целевые функции монотонны, а области определения реше­
ний совпадают. Монотонность функции F = F( F\\,..., F\x) уже отме­
чалась. Область определения решений (6.20) является частью области
определения решений задачи (6.30), если b\(Tr) = b \ \ T r), и величина
b \ ( T r) определяется значением Ъ \ \ Т Г) в выражении (6.28), где b{(7r),
216
 k(Tr) , f = 1,2 — величины на уровнях h = 2 и h = 1. Таким образом,
интересы (целевые функции (6.22) и (6.27)) согласованы [39].
Перейдем к решению задач (6.29) вертикального согласования
(класса 26). Лагранжиан для этого случая имеет вид

L , = {<С„, PdTp]> + <С/к, Р^7>]> + А*Р,[ Тр] - Ь(7>)> +

+ <ХК +ь R[TP] - Pj&ТР]> + <уь Gi> + <ук, G*>} -> шах, (6.35)

где G| и G Kопределяются выражением (П.2) приложения 2; y xj K, Я.,,

Хк — множители Лагранжа.
В [7] показано, что при выполнении условия (6.30) области опре­
деления задач (6.13) и (6.27), (6.28)—(6.29) совпадают, а целевая
функция (6.13) является составной частью функции Fi(Pk[ Тр]). Следо­
вательно, F^Pk[Tp]) монотонна, а интересы уровней h = 2 и h = 3 со­
гласованы.

6.2.4. Переход на выпуск новой продукции

Снимем ограничение Д2 (структурные связи системы не изменя­
ются) подразд. 6 .2 . 1 .
Исходными дополнительными данными при переходе на выпуск
новой продукции служат [46]:
1 ) характеристики и начальные условия построения старой струк­
туры;
2) перечень/ = 1, J' новой продукции, спрос Ry4 на нее, сроки вы­
пуска и экономические характеристики;
3) технические характеристики новой продукции;
4) нормы расходов ресурсов для новой продукции;
5) наличное и резервное количество ресурсов;
6 ) приоритетность выпуска новой продукции.

Чтобы перейти от старого стационарного режима (со старыми

связями) к нестационарному, структурно возмущенному процессу,
необходимо определить новый стационарный режим (план при но­
вых структурных связях).
Поскольку в литературе отсутствует исследование такого неста­
ционарного режима, воспользуемся технологией его изучения, изло­
женной в подразд. 6 .2 .2 —6.2.3.
Основная идея формирования модели нового плана — запись в
отклонениях от известного старого плана.
Возьмем за основу описание планирования (6.13). Сначала рас­
смотрим первое ограничение (6.13), а во втором ограничении примем
План Рис. 6.4. Процедура ежедневно­
го перехода на выпуск новой
Р4 продукции и одновременного
снятия старой Р3 продукции:
1 ,2 — мгновенное и постепенное пол­
ное снятие старой продукции; 3, 4 —
мгновенное и постепенное частичное
снятие старой продукции; 5 — 8 —
мгновенная и постепенная постановка
на выпуск новой продукции во время и
после снятия старой продукции; 9 —
постепенная постановка на выпуск но­
вой продукции после снятия старой
(через время запаздывания 7",)

Р*_ i[/] = bk(t— 1), т. е. рассмотрим уровень h = 2. При необходимо­

сти переменную [/] будем заменять на [Тр\ или на [/,].
Пусть в момент времени (t) = (т — 1) возникает необходимость в
оперативном переходе на выпуск новой продукции Р 4 *;[т] = { Р ^ т ],
j е 1, J4k}. При этом старая продукция Рз*[т] из Р*[т] снимается с про­
изводства полностью (Р'3 *[т] = 0) или частично (Р'з*[т] < Рз* [т]).
Возможны следующие варианты запуска новой и снятия старой
продукции (рис. 6.4, 6.5).
I. Продукция Рз/t снимается постепенно за время Тс = тз= шах
где /3 = {тзj , j е Уз с У}; J, / 3 — множества выпускавшейся ранее (кри­
вые 2 и 4 на рис. 6.4) и снимаемой продукции — вектор постоянных
времени, а для новой продукции используются:
1 ) последовательный непрерывный способ запуска (только после

снятия старой продукции) с мгновенным выпуском (кривая 7, рис.

6.4, в);
2) последовательный непрерывный способ с выпуском продук­
ции через время Тп (кривая 8, рис. 6.4, в)\
3) последовательный прерывный способ (кривая 9, рис. 6.4, г);
 Рис. 6.5. Процедура перехода (с накоплением) на выпуск новой продукции

4) параллельный способ запуска в процессе снятия старой про­

дукции (кривые 5, 6, рис. 6.4, б).
II. Старая продукция Рз* снимается мгновенно (кривые / и 3, рис.
6.4, а, Тп = 0), а в момент времени (t) = (х — 1):
1 ) мгновенно производится новая продукция Р ^ М > R ^M (кри­
вая 5, рис. 6.4, б)\
2) начинается выпуск новой продукции с временем Тп выхода на
устойчивый уровень (кривая 6, рис. 6.4, б).
Первоначально рассмотрим вариант 1.1. Виды продукции Р ^ т ] и
РзлМ, Рза:[т] и Р 2 а[т] имеют (попарно) общие ресурсы и не имеют об­
щих ресурсов с продукцией Pi*[t].
Очевидно, что старый план Р*[т] = {РиМ , Р г/М , Рз*МЬ |Р* I =
= |Pi*| + |Р2*| + |Рз*|, где |.| — размерность вектора, Ь "(т - 1) = {Ь,*(т -
- 1), b2*т(т - 1), Ь3*т(т - 1)}т, Сс = {С,, / = 1, 3}.
Для выпуска новой продукции выделяются дополнительные ре­
сурсы Ь4 *;(т — 1), Ьз*(т — 1), b\k(x — 1). Предположим, что наличие ре­
сурсов {Ь2*(т - 1) + b'2*(T - 1)}, {Ь3 Аг(т - 1) + Ь'заг(т - 1)}, b4 yt(t - 1) обес­
печивает выполнение нового плана Р "т[х] = {Pi*M> P 2 /tM, Рз*М,
? 4 /t [т]} при Р 4 *[т] > R4 [х]. В противном случае следует решить вопрос
ресурсного обеспечения (подразд. 6 .2 .2 ).
Новый план Р ”[х] может быть рассчитан с помощью выражений
(6.11) по алгоритму 2.4 приложения 2.
Если значение Р'з*[х] задано и фиксировано, целевая функция в
выражении (П.5) имеет вид

F = <С 4 *, P 4 t[x]> -» max.

Таким образом, получены результаты для варианта 1.1, который

является идеальным и абстрактным. Поэтому следует оценить другие,
более реальные варианты «переходной» структуры.
В варианте II. 1, являющемся также достаточно идеальным, следу­
ет учесть потери за счет незавершенного производства, определяемо­
го величиной (Р 3 *[х] —pImM). Э т и м и потерями можно пренебречь в
варианте 1.4.
В вариантах II. 1 и II.2 из-за незавершенного производства старой
продукции имеют место потери

ДF3k = <Ак, z3 *(x)> (6.36)

при

Z3 *(t) = z3*(x - 1) + М(хз*[х] - А9 *Р3 *[т]), (6.37)

Z3 *2 (т) = [/]х3* [х],

где Ак — вектор-строка цен единицы ресурсов; z3 *(x) = {z3 *(x),

z зХ(х)}т; z3 *(x), z3 *(x) — вектор-столбцы затраченных на момент вре­
мени (х) накапливаемых и ненакапливаемых ресурсов; хЗАг[х] =
= {z3 *[x], z [х]}т — вектор-столбец плана запуска ресурсов для ста­
рого плана РЗА:; индекс «т» — признак транспонирования.
В варианте II.2 выигрыш составляет

Д / 4* = < С 4*> Е Р 4 * М > . <6 -3 8 )

(=1

где п = const, / 3 = n*[t\.

Таким образом, в варианте II.2 выпуск новой продукции выгоден,
если AFik < А / 4 * или продукция Р3* морально устарела.
220
 В варианте 1.4 потери AF3k = 0, а выигрыш AF^k определяют из вы­
ражения (6.38), где Р 4 *[//] устанавливают на основе маркетинговых
исследований:

R'3*{[x - 1] + № = R3*[T - 1] - T3jfc/[/]({R3Jt[T - 1] - rU -

- R 3* [x -1 ]),
где I = ~ n , T3 1 = diag{/3 *J, j e J3 cz W }.
В варианте 1.2 при AF3k — О
П
F*k = < С 4к, 2 P 4 *U/]>, (6.39)
1=1

где Р4*[/,] определяется при P3/t[/] = Р3*[/].

При использовании варианта 1.3 возникают дополнительные по­
тери
«з
^ Л к = < С 4 к , ^ Р 4 * :М >’
/= 1

где я 3 определяют из значения Т3 = я 3 И ; Т3 — запаздывание выпуска

продукции по отношению к моменту полного снятия с производства
продукции РЗА.
В вариантах 1.2 — 1.4 за счет лучшей организации возможен до­
полнительный выигрыш
я ,-л 2
^ 4 к = < С 4к, ^ P 4 *;[f/]>, (6.40)
/=I
где х4 = n2[tj] = n2[t\, ([/,] = [/] = const) — наибольшая длительность
технологического цикла для новой продукции; t4 = «,[/] — запазды­
вание в выпуске продукции, связанное с организационными факто­
рами; т4 < /4 и, следовательно, п2 < пх.
Очевидно, что вариант 1.4 предпочтительнее вариантов 1.1 и 1.3,
однако организационно он сложнее. В итоге окончательный выбор
варианта определяет исследователь.
Выражения, аналогичные (П.5) приложения 2, можно составить
для уровней А = 1 и h = 2.
Для уровня h = 1 справедливо выражение (П.5) и
m
Fk = Z<< c 4 i . Р 4 * [ '/] > - < С 3*, P j* [^ ]>}->max, (6.41)
/= # •+ 1
а для уровня h = 2 , где имеет место горизонтальное взаимодействие
элементов, в дополнение к (6.41) получим выражения (6.42) для
материальных ресурсов
А'6*,0 Р$*М -Рз*М 0
< Рз*- М -Рз*-1 М (6.42)
^ 9 к ’ Ац* Р4*М
А 'пк Р4*- [т]
и целевой функции
к
^ = 1 Ff (6.43)
k-\

Выражения (6.36)—(6.43) фактически составляют математическую

модель процесса определения нового плана, исследование которого
можно провести методами, описанными в подразд. 6 .2 .2 —6.2.3.

6.2.5. Расчет с помощью декомпозиции (по частям)

До сих пор считалось, что размерность задач позволяла решать их
целиком.
При большой размерности векторов Р и Р * решения находят ис­
пользуя декомпозиции (см. рис. 6 .2 ) с постепенным укрупнением
структуры по схеме «компонент — элемент — уровень — система»,
где под компонентами понимают составные части, на которые разде­
ляется элемент структуры.
Далее рассмотрим задачу (6.13) без второго выражения, полагая,
что оно соответствующим образом введено в первое.
Декомпозиция подразумевает:
• выделение сильно связных множеств (классификацию);
• декомпозиционное решение задачи.
При выполнении процедуры классификации полезно учитывать
следующие предварительные рекомендации:
1) выбирать количество классов К в пределах 6 — 8 с одинаковым
по возможности числом элементов т в каждом [46];
2 ) иметь между классами минимум связей, чтобы уменьшить ин­
формационный обмен и значительно увеличить скорость решения;
3) использовать для классификации предпочтительно простые,
быстродействующие и эффективные алгоритмы.
Данная задача является нестандартной задачей кластеризации,
ибо проводится на двудольном графе. Ее трудно представить фор­
мально в виде задачи целочисленного программирования, что служит
одной из причин применения для решения таких задач эвристиче­
ских алгоритмов [7].
Предлагается использовать известный алгоритм 2.5 приложения 2.
Для декомпозиции можно применять алгоритмы выделения силь­
но связных множеств [46].
Задача содержательно ставится так. Необходимо разделить N эле­
ментов, связи которых характеризуются коэффициентами матрицы
А = {aqv}, на К классов по тк (к = К) элементов в каждом так, чтобы
взвешенная сумма связей между классами была минимальна.
Рассмотрим случай, когда заданы количество классов К и число
элементов в классе тк (часто тк — т = const).
Используемые методы возможно разделить на точные и прибли­
женные.
Точная постановка данной задачи [39] имеет вид алгоритма 2.6
приложения 2 .
Это задача целочисленного квадратичного программирования,
обладающая большим количеством переменных / = KN + K N 2 и зна­
чительным числом ограничений т = K N 2 + К. Уже при К = 2 и N = 6
размерность задачи / х т = 84 х 74.
Задача (П. 6 )—(П.10), как показано в [7], может быть приведена к
линейной целочисленной:
К N N

-> max;
k= 1q=1 v=l

Z Z j v * =™ 2; (6-44)
q=1 v=l

К N

k=1 v=l

К N
ЦЦУяУк
A=1 9=1

где Удук= { °> !}, mk = m .

Задача имеет размерность lx m = K N 2 x (K + 2N) и уже для К = 2 и
N = 6 размерность 1 х т = 72 х 14. Следовательно, такая задача при
значительных величинах K w N характеризуется высокой размерно­
стью (и длительным временем решения).
 В связи с этим предпочтительнее использовать приближенные
методы:
• метод эквивалентных преобразований;
• последовательные методы.
Из двух разновидностей метода эквивалентных преобразований
[39] более универсальным и конструктивным является метод, состав­
ленный из двух процедур: нахождение первого приближения; улуч­
шение решения путем целенаправленной перестановки строк и
столбцов матрицы А.
В процедуре нахождения первого приближения задача (П.6 )—(П. 10)
алгоритма 2 . 6 заменяется на линейную задачу целочисленного про­
граммирования. Ее применение описано в [39], там же формально из­
ложена процедура улучшения решений, которая в общем случае мо­
жет не привести к оптимальному решению.
Процедуры метода эквивалентных преобразований при большой
размерности матрицы А являются задачами достаточно сложными и
самостоятельны ми.
Желание упростить и совместить эти процедуры привело к широ­
кому использованию последовательных методов.
Их идея заключается в последовательном выделении А:-го семей­
ства (класса) и исключения его элементов (и связей) из матрицы А на
последующих итерациях. Центром, вокруг которого образуется каж­
дый к- й класс, служит опорный элемент, выделяемый по критерию

F = Y j a qv m a X ' ( 6 ‘4 5 )
v=l

На базе последовательных методов сформулирован [46] и предло­

жен алгоритм, отличительной чертой которого является [74] рассмот­
рение на каждой итерации только двух классов (алгоритм 2.7 прило­
жения 2 с разновидностями А1 — А5).
Отметим также, что структура матрицы А задачи (6.13) с выделен­
ными подматрицами — кластерами может быть двух видов:

А = {Ау}, /,У = ТТО, (6.46)

где диагональные элементы А, характеризуют выделенные классы, а

матрицы А(у определяют связи между классами, или
 А1 А2 А3 .. Ап

^0 0 0 .. 0
0 а 2 0 .. 0

0 0 0 ••

при использовании более прогрессивного лимитного метода деком­

позиции.
Сказанное относится и к матрицам А* выражений (6.15). Нетруд­
но видеть, что структура (6.47), являясь частным случаем (6.46), не
всегда может быть получена. В связи с этим основные методы класси­
фикации рассмотрены для структуры (6.46).
Сравнительный анализ методов кластеризации, проведенный в
[7], позволяет рекомендовать последовательные методы (разновид­
ности A l, А4 алгоритма 2.7).
После выделения П классов в структуре матрицы А задачу можно
переписать в виде:

АшРсЛТр] ^ К ( Т Г), (о — 1, Q; (6.48)

Х А “ Рш[7’р] < Ь 0[7^]; (6.49)

СО=1

w r , ] = £ < С /И, Рш[Гр ] > -> шах, (6.50)

(0=1

где ЫТГ) = (Ь0Т(ГГ), ЬШ

Т(ГГ), (О = ТГП}Т; К ( Т Г), Ь0 ( Тг) - вектор-столбцы
локальных и общих (глобальных) ресурсов системы; Р[ 7^,] =
= {Р о№ }Т, С, = {С/й, со = ТТЛ}.
Аналогичные преобразования могут быть сделаны для выражений
(6.16), (6.19)—(6.23).
Если каким-либо образом, например лимитным методом, удается
представить (6.49) в виде

Ь0 (7’г) = Е Ь ш0(Гг),
(0 = 1

то задача (6.48) — (6.50) декомпозируется на Q прямых локальных за­

дач
 А“РЮ[Тр] < bUTr)\

К К [ т р] < K ( T ry,

/ ’1 ( P J 7 ’p ] ) = X < C ,MPa)[7’/,]> ->m ax (6.51)

СО=1

и одну глобальную задачу

f x 5- ' ) ^ ) < 1,0(7 ;),

со=1

F{b0[Tr]} = | > n w (Tr) - > max, (6.52)

(0=1

где 5 (s = 1 , 6 ) — номер итерации; w“ — двойственная переменная.

При декомпозиционном подходе необходима проверка совмест­
ности задач (6.51) и (6.52). Условия совместности со-задачи (6.51) и за­
дачи (6.52) трансформируются с заменой [13] Ьо° на (Ь“ + ЛЬ®), Ьшна
(Ьш + ДЬт) с ценами D “ и Dm соответственно.
Потребное количество ресурсов для решения задач определяется
выражениями bo ^ (Ьо + АЬ“), Ью ^ (Ьш + ДЬШ).
При декомпозиционном решении задачи (6.13), равно как и
(6.15), (6.22), имеет место следующий сходящийся итерационный ал­
горитм 2.7 приложения 2.
Таким образом, определен оптимальный план Р [Тр] для задачи
(6.13) при ее решении целиком (ю = 1) или через со-компоненты при
декомпозиционном решении [46].
Аналогично получаем решения Р*[/(] для отдельных к-х (к = fixe,
к = \ , К ) элементов, описываемых выражениями (6.15), (6.22).
Отметим, что «факторизованная» задача при декомпозиционном
способе дает то же решение, которое получается при рассмотрении
задачи целиком.
Сказанное в данном подразделе справедливо и для нестационар­
ного режима.
6 .3 . УПРАВЛЕНИЕ ПРИ ИЗМЕНЯЮ Щ ЕМСЯ СПРОСЕ

6.3.1. Векторное свойство элементов

и этапы его изучения
Специфика многоуровневой системы заключается в том, что в
критериях ее работы должны быть учтены как экономические, так и
управленческие (динамические) характеристики
В подразд. 6.2 сильный акцент сделан на экономическую состав­
ляющую, рассмотрен лишь один вариант задания динамических ха­
рактеристик. При этом детально не обсуждались условия обеспече­
ния характеристик динамического режима, не рассматривались след­
ствия неопределенности в получении информации для управляющей
части системы. В то же время степень оптимизации в значительной
мере определяется динамическими характеристиками.
Допустим, что целеполагание проведено и цели определены мето­
дами, приведенными в подразд. 6 .2 .
Математический аппарат описания процедуры должен удовле­
творять противоречивому требованию — удовлетворения ЛПР и
обеспечения высокого качества процессов.
Описание должно позволять учитывать, с одной стороны, алго­
ритм работы ЛПР, что возможно сделать только с помощью имитаци­
онной модели, с другой стороны, интересы структурных элементов с
последующим улучшением режимов использования ресурсов, что
возможно лишь в оптимизационной модели. Иными словами, полу­
чение данных для модели из реальной системы удобнее осуществлять
в рамках имитационной модели, тогда как улучшение характеристик
процедуры управления требует наличия модели оптимального управ­
ления.
Выходом из создавшегося противоречия является уточненная тех­
нология: построение имитационной модели процедуры управления с
последующим улучшением характеристик процедуры путем перехода
к оптимальной модели.
Для построения имитационной модели предложено использовать
технологию, приведенную в подразд. 6.2.1. Одна из разновидностей
имитационной модели приведена в [7, 43, 46].
Имитационная модель может предусматривать принятие оконча­
тельного решения человеком на основе решений — советов компью­
тера. Достоинство имитационной модели — простота ее построения,
хотя в оценке адекватности имеются сложности [46].
Полезной стороной имитационной модели является учет нели­
нейностей (по координатам), близость описания решений модели к
решениям ЛП Р. Однако в ней слабо описана связь (прежде всего эко­
номическая) между уровнями, а удержание заранее выработанного
плана Рд[/,] может сказаться неблагоприятно. Принятие решений с
учетом только ограничений и численный характер модели затрудня­
ют выявление общих закономерностей. К тому же большое разнооб­
разие описания различных элементов неудобно и вызывает потреб­
ность в более единообразной форме представления с учетом опти­
мальности режима функционирования.
Желательна возможность использования аналитических методов,
что фактически означает [7] асимптотический переход от дискретных
имитационных моделей к непрерывным. Одновременно создаются
предпосылки для построения оптимальной [46] многоуровневой мо­
дели процесса управления с согласованием интересов (целевых
функций). С этой целью перейдем к описанию в пространстве со­
стояний с линейно-квадратичным критерием. Такой критерий по­
зволяет учесть:
• линейную, экономическую аддитивную составляющую, при
этом вновь полученный критерий может быть снова приведен к ли-
нейно-квадратическому варианту с другими числовыми параметра­
ми;
• корректировку плана и слежение за планом (рис. 6 .6 ).
Тогда описание процедуры управления получает вид (6 .8 )—(6 .10).
Заметим, что если в (6 .8 ), (6.10) Wk(t) = р*(/) = 0, решение имеет
вид
М О = - Kkzk(t),
гдеКА— матрица, и замкнутая система описывается уравнением
z*(0 = {А* - В*К*} = Gkzk(t).
В выборе собственных значений матрицы G* или коэффициентов
матрицы К* имеется два направления: модальное и оптимальное
управления.
При модальном управлении значение матрицы К* выбирается так,
чтобы обеспечить заданное расположение корней матрицы G*, при
этом не учитывается приведенный ранее критерий, а реализация по­
лучается сравнительно простой. Однако такое решение неоднознач­
но, порой избыточно и существенно затрудняет согласование интере­
сов элементов. В связи с этим предпочтение отдано второму направ­
лению.
В силу рассмотренных обстоятельств описание (6 .8 )—(6.10) поло­
жим в основу исследования свойств многоуровневой системы с помо-
 lM
На уровень ^ Pjk 5!djk
Л=2
..... Е З - ^ г /
^ J 3 il [/]| I /
[■*]—<Ь
f t "( 3jk ......

S t; W4jk
*jk

V6jk - v 5jk ■--(w^k)*—

! f ‘ 0 « ijk

h= 1
Л= 0 _A _
zljk z 2jk = > У)к
Xljk Уljk x ljk Уик' y2jk

Рис. 6.6. Схема имитационной модели к-го подразделения

щью предложенной технологии, в которой выделены следующие ста­

дии (рис. 6.7):
1 ) исследование свойств элементов по частям, что предполагает
выделение стадий классификации и декомпозиции;
2 ) координация работы элементов и уровней;

3) управление при оперативно изменяющейся структуре (струк­

турный переходный процесс).
Интенсификация процедур в системе требует оценки и задания
для синтеза динамических свойств. В силу сложности системы невоз­
можно определить какой-либо скалярный критерий и, на наш взгляд,
следует сформировать векторный критерий (векторное свойство).
Определим векторное свойство, с помощью которого осуществим
исследование системы.
Поскольку в конечном счете динамику в режиме диалога опреде­
ляет ЛПР, начнем [14] с понятных ему свойств, от которых перейдем
к специфическим «автоматическим» свойствам системы.
А. Время на устранение отклонения в выполнении плана (с помо­
щью которого ЛПР может задать динамику) связано со степенью ус­
тойчивости а (а = 3/Т, Т = max Tj , где Т — длительность переходного
 Описание системы Описание системы
с фиксированной с изменяющейся
структурой структурой

Задание начальных
условий

Число ^ Размерность
классов задано? велика?

Выделение
сильносвязанных
Число множеств
элементов в классе
задано?

Децентрализация
Выделение N . нужна?
сильносвязанных
компонентов

Децентрализация

К лассиф икация I
 Управляемость и
наблюдаемость
I ~
Качество
(экспоненциальная Горизонтальное
устойчивость) согласование

Устойчивость Вертикальное
согласование 1
Чувствительность
Вертикальное
согласование 2
Точность слежения
при скалярном и Согласование
векторном
критериях
/ С тр ук тур ах^
на предыдущей
итерации
\ м енялась?/

Структура
Изучение свойств меняется?
элемента уровня
Декомпозиция

Конец

Окончание рис. 6.7

процесса), определяющей качество функционирования (обеспечи­

вающее экспоненциальную устойчивость). С учетом величины а при
фиксированном значении к (и потому индекс к отдельного элемента
уровня А = О опускается) выражения (6 .8 ), (6 . 1 0 ) получают вид:

i(t ) = Az(0 + Bu(0 + w(r), z(0) = z0;

у(/) = Cz(/);
 с(0 = р(/) - у(0;
т
J = 0,5е2а/ t r (T)Se(T)+0,5 J e 2“'{eT(r)Qe(/) + u T(/)Ru(/)}d/ ->min, (6.53)
1=о

где вместо А записано А,. Подставив z,(/) = z(t)eal, u,(0 = u(/)ect,)

Уi(0 = У(0е“', p,(0 = p(0e“', E|(0 = e(/)e“', w,(/) = w(/)ea', опустив под­
строчный символ 1, получим выражения, в которых А = А, —аЕ, где
Е — единичная матрица соответствующей размерности.
Задание а позволяет обеспечить устойчивость по Ляпунову: пока­
зано, что если элемент (6 .8 ) асимптотически устойчив по Ляпунову,
то и элемент (6.53) устойчив со степенью устойчивости а. В связи с
этим далее рассмотрим вопросы устойчивости для элемента (6 .8 ), т. е.
будем осуществлять синтез по а.
Б. Для исследования (асимптотической) устойчивости (6 .8 ) чаще
всего используют положительно определенную функцию Ляпунова
(ФЛ), имеющую в данном случае такой вид:

m m = zTWHz(o,
где Н — квадратная симметричная положительно определенная мат­
рица.
Чтобы элемент был устойчив, необходимо, чтобы
V(z(t)) = - z T(t)Gz(t),

где G — симметричная положительно определенная матрица.

Матрицы Н и G связаны уравнением Ляпунова

АТН + НА = - G.
В. Необходимым условием устойчивости является наличие
управляемости (наблюдаемости) элемента. Для этого в стационарных
элементах должны выполняться условия:
rank (А АВ ... А"- 1В) = л;

rank (Ст АТСТ ... (А1)" - *СТ) = п, (6.54)

где п — порядок квадратной матрицы А.
Г. Квадратичная целевая функция (6.53) элемента, гарантируя ус­
тойчивость системы, позволяет одновременно обеспечить:
а) минимум ошибки е(/);
 б) минимум стоимости (суммы затрат на управление и потерь
из-за отклонений);
в) минимум чувствительности к параметрам и связям.
Действительно, квадратичный критерий является взвешенным
критерием (с матрицами-весами Q и R).
Если матрица R выбрана исходя из требований к динамике, то в
соответствии с теорией векторной оптимизации ошибка e(t) эффек­
тивно минимизируется, если вес матрицы Q много больше (в 50—100
раз) веса матрицы R. В ряде работ матрицу Q предлагается выбирать
так, чтобы обеспечить нужное расположение в комплексной плоско­
сти корней характеристического уравнения замкнутой системы по
выделенному на этой плоскости сектору или заданной степени устой­
чивости. Представляется, что алгоритмы такого выбора достаточно
сложны для подобных систем.
В квадратичной целевой функции (6.53) можно учесть и стоимо­
стную (экономическую) составляющую.
Для элемента ( 6 .8 ) управление ищем в виде

u(0 = - R -'[c2t + BTK(/)z(0 - BTg(/)], (6.55)

где К(0 — решение уравнения Риккати; g(/) — вектор-функция вре­
мени.
Уравнение Риккати для К(/)

К(0 + К(0А+ АТК(0 - K(0BR_ 1BTK(/) + CTQC = 0, К(7) = CTSC; (6.56)

функция g(t ) находится из выражения

т = ( - Ат + K(0BR-'BT)g(0 - CTQ P(0, g(7) = CTSP(7). (6.57)

При дискретном описании во времени уравнение Риккати

К(/)А - {А-т + A“TQBR“ 'BT}K(/ +1) - К (t + 1)BR~'BtK(7 + 1) +

+ A“TQA = 0.

Заметим, что решение и(/) при Р(/) = w(/) = 0 позволяет осущест­

вить анализ системы по величине степени устойчивости а. Действи­
тельно, а есть наименьшее по модулю значение вещественной части
собственных значений характеристического уравнения замкнутой
системы F = А,Е —(А — BR~'BTK), где Е — единичная матрица
В общем случае для решения задачи (6 .8 ) возможно использовать
рассмотренные ранее методы векторной оптимизации. На наш
взгляд, наиболее подходит метод идеальной точки, решение для кото­
рого существует в силу выпуклости целевой квадратичной функции
(критерия) и области, определяемой динамическими ограничениями
( 6 . 8).
Если для всех / = 1, L выбрана степень устойчивости а , то она со­
храняется для критерия компромисса, который фактически имеет бо­
лее высокую размерность по сравнению со случаем / = 1 , и устойчи­
вость элемента обеспечивается в силу отрицательной определенно­
сти произвольной функции Ляпунова.
Д. Оценку грубости решения (6.55) возможно осуществить с по­
мощью определения чувствительности. Формируются функции чув­
ствительности выхода (или состояния, или целевой функции) эле­
мента (компонента) к параметрам.
Пусть рассматривается чувствительность состояния z(/) к пара­
метру р. В общем случае (du/dp) * 0) выражения (6 .8 ) трансформиру­
ется к виду

у(0 = А,у(/) + B,u(f) + w(/), у(0) уо;

т
J =0,58т (T)S] 6 (Г) +0,5 J{6T(0Q,5(0 + u T(/)Ru(/)}d/->-min, (6.58)
/=о

где у(/) = {z\ t ) , o \ t ) } T, У( 0 = {гт(t), 6 Т(/)}т , а = dzjd р, а = d/dr(az/ap),

6(0 = {ет(0, ат(0}т,
А(Р) 0||
А, -
dA(P)/c>p-B(P)c)L/c>p A(P)-B(P)L|| ’

в = (ВТ(Р)ВРУ , Вр = ав/ар , u(t) = - Lz(/), l = r ~ 'в т(р)К(о, к (о -

решение уравнения Риккати.
Последнее имеет вид

ж /а р + ак/ар{А(р) - B(p)R 'в‘(р)К} + {А(р)

- B(p)R_ 'вт(р)к}ак/ар + [каА/ар + (аАт/арак] - щав/dpR- 'вт(р) +
+ B(p)R“ 1(aB/ap)‘K = o,

а щ о у ар = о, Ар = ад/ар,

S о Q 0
s ,= Q. =
0 Е О q2
где Sj и Qj — симметричные положительно определенные матрицы.
Выбранное значение а сохраняется.
Заметим, что, выбрав в (6.58) определенные значения матрицы
весов Qi, можно сделать чувствительность элемента достаточно ма­
лой, а элемент — грубым. За это приходится платить увеличением
размерности элемента (6 .8 ).
Свойство Д определяется по закономерностям и включает в себя
свойство Г. В силу этого далее будем рассматривать только свойство Г.
Таким образом, в состав векторного свойства входят:
А — качество функционирования;
Б — устойчивость по Ляпунову;
В — управляемость (наблюдаемость);
Г — ошибка (точность) слежения за входным сигналом (планом).
По свойствам А, Б, Г осуществляется прежде всего синтез, а по
свойству В — анализ элемента.
На основе предложенного векторного свойства возможны два ва­
рианта получения решений в процедуре управления.
• структура решений имеет на один уровень больше, чем структу­
ра описания (изучение по частям, декомпозиция);
• структура описания совпадает со структурой решений (изучение
целиком).
Рассмотрим выработку решений в указанном порядке. При изуче­
нии свойств элементов системы с использованием декомпозиции его
начальной процедурой является разделение элемента на связанные
компоненты (классификация) с последующим расчетом.

6.3.2. Исследование свойств элементов

с помощью декомпозиции
Поскольку в элементе (системе) управления используется прин­
цип обратной связи, структура управления по сравнению со структу­
рой планирования приобретает новое свойство — сильную связ­
ность.
В связи с этим в классификации могут иметь место следующие
процедуры:
1 ) выделение максимально сильно связных или сильных компо­
нентов [39];
2 ) формирование сильно связных множеств, если выделенные
компоненты еще имеют высокую размерность;
3) децентрализация по входам или выходам.
Первая процедура предполагает формирование квазидиагональ-
ной (после перестановки строк и столбцов) матрицы
 М = S <8 > ST= quasi diag{Afr, r = 1, /?}, (6.59)

где ST— транспонированная матрица S; <8 >— операция поэлементно­

го умножения матриц; R — число классов; S — матрица связей.
Блоки Мг, составленные из единиц и имеющие размерность
тг х тг при
П
Z m/-
1=1

характеризуют максимально сильно связные компоненты. Сильно

связные компоненты могут быть получены из сильных компонентов
с использованием функционально-целевой информации.
Возможно использовать и алгоритм 2.8 приложения 2, базирую­
щийся на работах Ф. Харари.
Из формулы (П. 13) приложения 2 видно, что в управлении г -м
компонентом выделяются две составляющие: локальная, обуслов­
ленная только г-м компонентом, и глобальная, вызванная влиянием
остальных компонентов элемента.
Наличие глобальной составляющей существенно осложняет
управление из-за дополнительных информационно-обменных про­
цессов, увеличивает длительность получения решений. В связи с
этим целесообразна, если это возможно, полная децентрализация (по
входам), когда управление r-м компонентом осуществляется только
локальной составляющей иД/). Каждый компонент при этом рассчи­
тывается относительно самостоятельно, упрощается и определение
свойств элемента производят по свойствам отдельных компонентов.
Описание объекта управления (см. (П. 13) приложения 2) получает вид
R
z r(t) = A rz r (t)+Briir (t) + ^ А гаг и ( / ) + Г ^ г(/), (6.60)
Ю=1,(0 *Г

где R — число классов (компонентов).

Процедура преобразования (П .13) в (6.60) для случая R = т, где
т — число столбцов матрицы В (или Вг), предложена Д. Луенберге-
ром, Д. Шилаком, М. Вукчевичем.
Отметим, что если п > Rm или п > т , где R — число классов;
п — размерность вектора состояния, то перед децентрализацией по­
лезно путем классификации разделить элемент на большее количест­
во компонентов. В противном случае использование децентрализа­
ции невозможно.
 Воспользуемся для децентрализации каноническим представле­
нием элемента (6 .8 ), при этом полагаем, что размерность вектора
Ь;г е В,., / = 1, тг, не менее тг.
В предлагаемом к использованию алгоритме выделяют две ста­
дии:
1 ) преобразование описания к канонической форме с помощью
матрицы Qr;
2) перестановка строк описания с использованием матрицы Р.
В [7] дан модифицированный алгоритм этих преобразований,
опирающийся на свойства определителя Грама и перестановочных
матриц. В результате из уравнения (6 .8 ) получим выражение (6.60).
Рассмотрим элементы (6 .8 ) уровня h = 1 с масштабом времени t.
Отметим, что интересы компонентов и элемента согласованы (скоор­
динированы).
Полагаем, что осуществлено исследование и определены условия
существования (с помощью введения дополнительных связей или
корректировки результатов классификации) векторного свойства
(свойства А — Г) для отдельных компонентов.
В силу иерархичности структуры и при декомпозиции векторное
свойство в процессе синтеза, который начинается с нижнего уровня,
трансформируется при переходе на более высокий уровень (рис. 6 .8 ).
В таких условиях следует прежде всего обеспечить заданное ЛПР зна­
чение аи = а*. Это можно сделать двумя путями [7]:
1 ) прямым преобразованием а /,— > а*;
2 ) обеспечением а/,, для чего необходимо изучить законы транс­
формации свойств Б — Г при переходе с уровня (h — 1) на уровень h.
Один из путей может быть контрольным по отношению к другому.
А. Можно показать, что устойчивость (со степенью а) элемента
может быть гарантирована, если все компоненты устойчивы (с той же
степенью а ) и соблюдается условие

ш т Я т (Рг)}>2ушах{Х,м(Кл)} + 2 5 т а х Я м(Кг)}, (6.61)

г г г
R R
где у =Х,°М’5 (А ^ А т ) = X Z y ™ ; >-«(•), К (- ) максимальное и минималь-
Г= 1 (0 =1
ное собственные значения соответствующих матриц: Pr = CT rQrCr +
+ К ^ Д Г 'В Х 8 (НтгаН га) = 2 8 то; D(/) = w(/) + R -'B Tg(/); g(t)
r= 1
определяется из выражения (6.57); E — единичная матрица; В(/) =
= - (А - BR_lBTK){CT(CCT)_l}P(0 = Н{СТ(ССТГ '}Р(0 = АР(0-
Рис. 6.8. Связь динамических свойств по уровням
 Оценка (6.61) достаточно грубая, поэтому исследуем законы
трансформации других свойств.
Б. Рассмотрим вопросы управляемости (наблюдаемости). Между
компонентами возможны прямые и обратные связи. Проведем иссле­
дования для чаще встречающихся прямых связей, тем более что усло­
вия для обратных связей в значительной степени аналогичны.
Если элемент децентрализованный (описание в виде (6.60)), то
наличие управляемости компонентов независимо от видов связей ме­
жду ними обеспечивает управляемость элемента.
Для описания уравнения вида (П. 13) приложения 2 при последо­
вательных связях компонентов элемент управляем, если соблюдают­
ся условия:

rank (Ai - Л/Е ВО = п\, / = 1 , Ль (6.62)

А,1 / 0 В,
rank =п, + п 2; (6.63)
а 2) а 2 -X j E В2

А,-Х?Е 0 0 0 0 В,
А2| а 2-я.?е 0 0 0 в2
А3 -Я?Е .. 0 0 в3 Г
А 31 А 32
rank =Х Ч = и,
г—
Г—11

А Д-1,1 А Д-1,2 А Я-1,3 АЛ_,-Я?Е 0 В Д -]

А Я, 1 А Я, 2 А «,з АЛ,Д-1 ал- я?е ВR (6.64)

где X/ — собственные значения матриц А г ; пг — размерность г-го

компонента. Подобные условия получены и при соединении компо­
нентов с помощью обратных связей.
Условия, аналогичные (6.62)—(6.64), имеют место и для наблю­
даемости.
Следует заметить, что определение управляемости с помощью вы­
ражений (П. 13) приложения 2, (6.62)—(6.64) связаны с определением
большого числа собственных значений, что само по себе является ем­
кой задачей, и предпочтительнее приводить описание к виду (6.60).
В. Рассмотренные условия управляемости (наблюдаемости) эле­
мента суть необходимые условия устойчивости этого элемента (по
Ляпунову), которая может быть выражена через свойство устойчиво­
сти отдельных r-х компонентов.
Введем для r-го компонента функцию Ляпунова V^z/t)) =
= Zr(t)HiZr(t)), Для которой справедливы неравенства
 c r,IM2 < VAzАО) < c r2|M2, VAzAf)) < - C r M 2- (6-65)

Определение устойчивости собственно многокомпонентного

элемента (иAt)) = 0) возможно провести методами векторной (ВФЛ)
или скалярной (СФЛ) функций Ляпунова.
Для ВФЛ на основе выражений (6.65) и (6.60) можно записать

Vr(zr( t ) ) < - C r3Vr(z r(t))/2Cr2+ £ 2 { С г22 а ^ ш(2 <а(0)}/{Сг3 Си1},

ю=1, <а*г

где ат = sup | | A J | .
Ге|0 , Т]
Тогда элемент ( 6 .8 ) равномерно асимптотически устойчив [39],
если матрица

г 2 а \2Д - \ ~ 2 2
■^13 7с\2а 22 2
АС\2а 2 с 12А | Л

2 с 12
С 1 3 С 21 с 1 3 с Д - |,1 С 1 3 С Я1

l2 cс R2a
2 а R\
2
z2 cг R2a
2 п R2
2 2 c R 2a R J i - 1 ~ °R 3

С Л З С 11 С Й З С 21 С Д З С Л - 1 ,1 2 CR2

является М-матрицей, т. е. для нее соблюдаются условия Севастья­

нова—Котелянского (положительность четных и отрицательность
нечетных главных миноров).
При использовании СФЛ функция Ляпунова для всей системы
(элемента)

V(/) = i > rVr (/).

г=1

Тогда можно записать выражение

R R
у (» = Е у Л - с, з 1 К Н 2+ Z 2crfl™llz r llllzJ I}-
Г=1 (0=1, (0*г

В этом случае система (6 .8 ) равномерно асимптотически устойчи­

ва, если матрица
 с 13 ~2С\2а\2 -2 с 12й 13 ■ ~ ^ с \2а \R

- 2 с 2 2 Й21 с 23 —2 с 22° 2 3 .. ~ 2 с 22« 2 Л

<7 =

- 2 С |Ла Я| -2 cR2aR2 - 2cR1aR3 CR3

является М-матрицей.
Неудобство использования матриц (6 .6 6 ) и (6.67) заключается в
том, что назначение коэффициентов с^, j = 1, 3, в выражении (6.65)
становится практически искусством исследователя.
Для упрощения расчетов целесообразно связать коэффициенты с9-
с характеристиками компонентов: коэффициенты с^, j = 1 7 ?; г = 1 , Л,
выражены через собственные значения соответствующих матриц Нги
G,. и получена система дифференциальных уравнений для скаляров
ur, z, размерность которой снижается до величины R. Если система
уравнений устойчива по Ляпунову, то устойчив и весь элемент.
Г. Точность слежения определяется при решении задачи (П. 13)
приложения 2 или (6.60) оптимального слежения. Нетрудно видеть,
что целевая функция декомпозированного элемента монотонно за­
висит от целевых функций компонентов, т. е. целевые функции ком­
понентов и элемента согласованы. К тому же наличие эквивалентно­
сти позволяет гарантировать сходимость итеративного процесса ре­
шения.
Декомпозиционное решение задачи оптимального слежения воз­
можно при использовании для одноуровневой структуры управления
многоуровневой структуры решения для задач (6.60).
Многоуровневый процесс решения одноуровневых задач (урав­
нений) использует свойства монотонности и эквивалентности. Часть
переменных фиксируется на нижнем уровне, а затем итеративно
уточняется на верхнем уровне. В зависимости оттого, какие перемен­
ные фиксируются, возможно использовать следующие известные ме­
тоды:
1) прогнозирование взаимодействий — INPRE (модельная коор­
динация, возможный метод);
2) баланс взаимодействий — INBAL (целевая координация, не­
возможный метод).
Определенное предпочтение следует отдать второму методу, где
на нижнем уровне решения фиксируется двойственная переменная Хг
при уравнении связи компонентов
 х г (0 ” Е А ™ги (0

Значение Хг итеративно определяется на верхнем уровне решения.

Учет векторного характера целевой функции (6.60) возможно осу­
ществить в таком порядке. Первоначально для каждого г ( г — 1,R) и каж­
дого lr (Jr = 1 ; Lr) находят оптимальные решения u r/(t) и координаты
zrf(0, Уг/(0> £w(0- Затем решают задачу для объекта управления (6.60) и
целевой функции
я л г
у = °’5Z Z Г( [у */ W ■- У r(0 ]TQ и[у г/ (0 - у г (01+
г=1 /= 1 о

Ф * / ( 0 - и г (0 ТR г/ [“ */ (0 —Ur (/)])d/ —>min (6 .6 8 )

и определяют компромиссное решение ur(/) и координаты zr(t), уr(t),

z£t). Можно показать, что заданная степень устойчивости а при ком­
промиссном решении сохраняется.
Перечисленными путями и способами возможно обеспечить гру­
бость решений (малую чувствительность) задач (П. 13) приложения 2
и (6.60).
На этом процедуру изучения свойств отдельных элементов уров­
ней h = 1 и И — 3 завершают и в соответствии с предлагаемой техноло­
гией расчета (см. рис. 6.7) далее исследуют взаимодействие элементов
на одном уровне и уровней между собой.
При синтезе свойств уровня h = 2 возникает понятие «координа­
ция экономических интересов (целевых функций)» элементов — го­
ризонтальная координация.
Вертикальная координация («координация экономических инте­
ресов» уровней) имеет место в двух случаях взаимодействия:
1 ) уровней h = 1 и И = 2 ;

2 ) уровней И = 2 и h = 3.

Назовем эти случаи соответственно первой и второй вертикаль­

ной координацией.

6.3.3. Координация управления элементов

и уровней системы
Рассмотрим первоначально процедуру горизонтальной коорди­
нации. Этот процесс описан выражениями (6.60), (6.62) при Во* = 0.
Он фактически представляет собой децентрализованное взаимодей­
ствие к-х элементов. В силу этого трансформация свойств устойчиво­
сти (со степенью устойчивости а), управляемости (наблюдаемости),
устойчивости по Ляпунову, чувствительности та же, что и при деком­
позиции элемента на компоненты. Точность слежения существенно
зависит от характера координации целевых функций к-х элементов
выражений (6 .8 ) и выражений (для к = fixe, к = 1 , К):
к
M 0 = A az * (0 + B * u *(0 + ^A^-ZyW +w^O;
j= \,j* k

Z*(0) = z*o, УАit) = c kzk(t);

*k(t) = Pk(t) - у k(ty,

T
Jk = 0,5e* (T)Sk c k (T)+0,5 J{ej (t)Qk t k (/)+u^ (t)Rku k (t)}dt ->min,
о

k, j — 1, K, (6.69)
где учитывается воздействие остальных элементов.
Сумма в первом уравнении формул (6.69) рассматривается как
возмущение, действующее на к-й элемент. Здесь по-прежнему воз­
можны два случая:
1 ) целевые функции скоординированы;

2 ) необходима координация целевых функций.

Первый случай имеет место при соблюдении условия монотонно­

сти:

1 •••, ^к—1 , Jk, •4 + ь Jfd<J(J\, ..., J k - ь Jk, Jk+ ь ...» Jk),

если Jk < Jk , где Jk ( k = 1, К) — целевые функции отдельных элемен­

тов. Частным случаем этого условия является зависимость

к =1

В случае монотонности точность слежения при скалярном и век­

торном критериях определяют способами, описанными в подразд.
6.3.2.
Во втором случае возникает задача децентрализованной коорди­
нации (равноправных) элементов. Для этой цели удобно использо­
вать игровой подход — равновесие по Нэшу, определяемое условием
 Jk {МО. U*_i(0, u*(/), U*+l(0, ... M O } > 4{u*(0,
uk- 1(0 , u*(0, u*+i(0, ..., ujf(0}. (6-7°)
В реализации (6.70) вводится фиктивный элемент.
Процедура решения такой задачи — двухуровневая, итеративная,
связанная с вопросом сходимости. К тому же для определения ком­
промиссного решения на каждой итерации необходима информация
и решения от других (К — 1) элементов. Такая информация избыточ­
на для к-го элемента и часто не имеет места. В связи с этим предлага­
ется следующая процедура ([алгоритм 2.9 приложения 2).
1 . Определяют решения Uyt(0, координаты для к = 1 , ^выражения
(6 . 10).
2. Находят координированные решения Uk(t) и координаты z*(0,
У*(0,£*(0 из описания объекта управления (6.69) и целевой функции:

J = °>5 Z IV * (*) ' У к (')т Q* [У* (0 - У* (01+

*=| о
-Hu *( 0 -u * (/)]TR A.[u*^(0 - u ,t (0 ]} d /^ m in ,

где Qk, R* — матрицы весовых коэффициентов. Можно показать, что

заданное значение а не меняется, если выполнено (6.61).
Такой же прием можно использовать при векторных критериях
элементов, при этом и*(0 — оптимальные решения для А;-го (много­
критериального) элемента.
С окончанием исследования уровня И = 2 (горизонтальная коор­
динация) завершают изучение отдельных уровней и переходят к рас­
смотрению процедур межуровневого взаимодействия (вертикальной
координации).
Первая вертикальная координация характеризуется межуровне-
вым изменением масштабов по координатам. Оно описывается выра­
жениями (6.69), (6 .8 ) при ВоЛ: = 0.
Надо отметить, что эквивалентность действия объектов управле­
ния двух уровней в значительной степени определяется горизонталь­
ным взаимодействием. Поэтому для исследования управляемости
(наблюдаемости), устойчивости (со степенью а), устойчивости по
Ляпунову снова полезно использовать приемы, описанные в про­
цедуре декомпозиции подразд. 6.3.2.
Особо обсудим вопросы точности слежения, зависящие от коор­
динации целевых функций (6 .6 8 ), (6 .8 ) при Во* = 0 .
Возможны два случая:
1 ) целевые функции скоординированы;
 2 ) целевые функции требуется скоординировать.
к
Первый случай имеет место при выполнении условия J
k=1
монотонности критерия J.
Во втором, более общем случае применение для централизован­
ного управления (с приоритетом уровня h = 2 ) децентрализованного
игрового подхода (с ( К + 1)-м игроком) с равновесием по Нэшу про­
блематично.
В связи с этим предлагается алгоритм 2.8 приложения 2, анало­
гичный рассмотренному в процессе планирования.
Перейдем к обсуждению процесса второй вертикальной коорди­
нации. Процесс взаимодействия уровней h = 2 и h = 3 описывается
выражениями (6 .8 ) и (6 . 1 0 ), необходимо скоординировать целевые
функции.
Удобно представить объект управления (6 .8 ) в векторной форме:

цг(7) = Az(7) + Bu(7) + ВоЩ Т);

y(7) = Cz(7); (6.71)

Z 0 (7) = AoZo(7) + A'z(7) + B^U0 (7);

Yo(7) = CoZo(7), (6.72)

где z(jT) = {z*T( T), k = T 7 W ; В = quasi diag {B^_k = T7A}; Bq = {B0*,

A: = 1, A}; A = {Aj, А:,у e 1, A}; A' = {A j, A: = 1, А}т; С = quasi diag {Ck,
k = 1, A}.
Заметим, что выражения (6 .8 ), (6.10) описывают разномасштаб­
ную по времени (с быстрой и медленной составляющими) систему,
имеющую связанные элементы на нижнем (И = 2) уровне. Поэтому
полезно обратиться к аппарату описания сингулярно возмущенных
систем. Для этого выделим в (6.71), (6.72) медленную и быструю со­
ставляющие. Полагая в (6.73) ц = 0 и det А ф 0, получлм

z'(7) = - A _ l № ( 7 ) - A _ 1Bu'(7). (6.73)

Подставляя (6.73) в (6.72), найдем

Z s { T , = A o Z s ( D + В ,Щ 7 ) + B2 u,<7),

Y s( T) = C 0Z s { T) , (6.74)
где В, = (В0 —А'А 'В0); В2 = —А'А 'в0; Т) — медленная состав­
ляющая. Быстрая составляющая определяется выражением

ц г / 7) = Az/ 7) + B u/ 7) + RdU /7 );

У /7) = C z/7). (6.75)

Разделение процессов на медленную и быструю составляющие
(6.74) и (6.75) позволяет анализировать последние порознь: первона­
чально быструю, а затем медленную. Одновременно упрощается изу­
чение перечисленных ранее свойств: управляемость (наблюдае­
мость), устойчивость по Ляпунову, устойчивость со степенью а (ка­
чество функционирования), ошибка слежения.
Задача определения условий устойчивости системы со степенью а
может быть сведена, как показано ранее, к задаче В устойчивости по
Ляпунову.
Для исследования трансформации управляемости воспользуемся
известной теоремой: если матрица А — несингулярна и
rank (В3 Ао В3 ... Ао" 1 ~ 'В3) = ns, п\ = ns,
rank (В4 А В4 ... А"2 _ | В4) = й/, п2 = я/,

где В3 = (В,, В2); В4 = (В, Bq); ns, nf — размерность составляющих, то

существует ц* > 0 такое, что сингулярно возмущенная система (6.74),
(6.75) управляема при 0 < ц < ц*.
В. Для оценки устойчивости возмущенной системы (6 .8 ) по Ляпу
нову воспользуемся результатами. Положим в (6.71), (6.72) Uo(T) =
= «(7) = 0:

Z o(7) = AoZo(7) + A'z(7);

£(7) = ц~ ’Az(7).
Введем функции Ляпунова
К0( 7) = Zo(7)S 0 Z0( 7), v( 7) = zT( 7)Sz( 7),
пусть a' = sup||A'||. Полагаем

Co2||Zo(7)||2 < K0( 7 ) < Co,||Zo(7)||2, K0( 7 ) < - C03||Z0( 7)||2;

c 2||z ( 7 ) ||2 < v (7 ) < c,||z(7)||2, v(7) < - c3 ||z(7)||,

где ||.|| — норма вектора или матрицы.
246
 Тогда с помощью векторной функции Ляпунова (ВФЛ) можно за­
писать:

К(7) < - C03Fo(7)/C o, + 2 c , V v( 7 ) / ( c 3C2)

v(7) < c3 v(7)/(2(ici),

и система устойчива, если матрица

л ||-Соз/(2С01) 2c fa'2 / ( c 3c2)

(6.76)
О 2 с 3 /(н е,)

является М-матрицей.
Применение скалярной функции Ляпунова (СФЛ) дает аналогич­
ный результат: матрица

» ЦСоз _ 2
а ' с , II

2I I 0 с ,/ 4 <6-77>

должна быть М-матрицей.

В силу специфики системы (6 .8 ) а* = а = 0, как видно из (6.76) и
(6.77), достаточна устойчивость уровней h = 2 и /г = 3 порознь. Заме­
тим, что для исследования устойчивости этой двухуровневой системы
возможно использовать иерархическую схему СФЛ.
Г. Для изучения точности слежения используем выражение (6 .8 ) с
записью объекта управления в виде (6.74), (6.75) и исследуем случай,
когда необходима координация целевых функций при скалярных
критериях уровней. Можно предложить алгоритм 2.10 приложения 2.
Таким образом, получается координированное решение для специ­
фической двухуровневой системы с разными масштабами процессов по
времени и координатам. Следует отметить, что такой же алгоритм может
быть использован при векторных критериях в описании (6 .8 ).
Данный алгоритм завершает исследование — с помощью состав­
ной модели — системы управления при фиксированной структуре.

6.3.4. Управление при изменяющихся

структурных связях
Нестационарный режим исследуем на базе формального описа­
ния (6 .8 ) в линейной системе, что позволит выявить фундаменталь­
ные свойства системы в «чистом виде», без наложения нелинейных
эффектов. Математической базой для изучения нестационарного ре­
жима послужит формальное описание стационарного режима.
По-прежнему исследуем трехуровневую структуру с числом уровней
0 = 3 (А = 0, 0) и следующим числом элементов К на уровне А:
Кз = = 1, К\ = Ко = К. На границе уровней А = 1 и А = 2 происхо­
дит изменение масштаба по коэффициентам, а на границе уровней
А = 2иА = 3 — изменение масштаба по коэффициентам и времени.
Тогда объект управления уровня А = 2 имеет описание
к
i k (t) = A kz k (t)+ £А Л (/)+В*М 0 + В 0 * и 0(/)+ * с* (');
j= \j* k

z*(0 ) = z*o, k = T7K;

yk(t) = Ckz *(/), (6.78)
где zk, u^, U0, yk, y/k — вектор-столбцы состояния, управлений на
уровнях А = 2 и А = 3, выхода, сигнальных возмущений; A*, k kJ, Въ
В0„ С, — матрицы подходящей размерности; t — принятый масштаб
времени. Если AkJ = B0/fe = 0, k = fixe при к е 1, А, то получим описа­
ние объекта управления уровня А = 1.
Для уровня А = 3 объект управления формально может быть пред­
ставлен в виде

Z , ( r ) = A 0 Z 0 ( r ) +B 0 U 0 ( r ) + X A 0 ,z * (7 ) + W0c(r);
к =I

Z 0(0) = Zoo, Y0<7) = CoZo( 7 ), (6.79)

где T — новый масштаб времени, а остальные обозначения те же, что

и в выражении (6.78).
При координации уровней А = 3 и А = 2 выражение (6.78) часто
записывают в другом масштабе времени:

lizk (T) = \ kz k (T)+ 2 A * ;Z ;( r ) + B * M 7 ’)+Bo*u 0 ( 7 > w c*(7’);

j= \J * k

z*(0 ) = z*o, k = 1 , К;

Ук( 7) —C*z*( 7), (6.80)

где ц — малый параметр; Т = mt.

Для управляющей части возможна следующая запись.
 Для уровня h = 1 (A*j = Во* = 0)

£k(t) = р*(0 - Ук((), к = fixe,

т
J kl(T) =0,5 j { e T
k (t)Qkle k ( t ) + u l ( t ) R k, u k ( t ) ) d t ^ m m , (6.81)
о
где ек, р* -вектор-столбцы отклонения и плана; Q kh Rkl — неотрица­
тельно и положительно определенные матрицы; / = \ , L \ L — количе­
ство целевых функций в векторном критерии.
Для уровня h = 2

t k(t) = Р*(/) - Уkit), к = 1, К-,

к __
//= 2 У й , '/ = и . (6.82)
*=i
Для уровня А = 3
Е о(7) = Р о ( 7 ) - ¥ о ( 7 ) ,

J 0I = 0 ,5 f{ET
0 (7 ’)Q 0 /E 0 (7 ’)+ U T
0 ( r)R 0 /U 0 (r)}d 7 ’ ->m in, (6.83)
о

где т — длительность интервала моделирования; / = 1 , L, остальные

обозначения те же, что и в (6.81).
Рассмотрим только уровень h = 2, поскольку для остальных уров­
ней рассуждения аналогичны.
Технология исследования процесса может быть представлена в
виде алгоритма 2 . 1 1 приложения 2 .
Фактически для определения «структурных» управлений u(Y)(0 =
= u<ry)( 0 + ugY)(/), у * ф; ф = s или ф = л; 5 = к или 8 = г, а, стало быть,
выходов у8 Т>(/), для линейной системы достаточно решить уравнение

г (y\ t ) = Asy)z8(y)(/) + B^y)u5<y)(0 + w5<y)(0- (6-84)

Из его решения udY)(0 = u§Y)(/) + u§cY)(/) следует вычесть собствен­
ные движения usc(Y)(0> определяемые из (6.84) при wgcY)(0 = 0- Для ис­
следования процессов (6.84) можно использовать методы изучения
стационарного режима, минимизируя длительность р структурного
переходного процесса. Очевидно, что zgY)(P) = 0 и начинается стацио­
нарный процесс для новой структуры.
 Отметим, что на интервале времени р может изучаться и вектор­
ное свойство (степень устойчивости, устойчивость по Ляпунову,
управляемость, точность, чувствительность).
Следует сказать, что приведенный математический аппарат опи­
сания динамических свойств позволяет проводить анализ и синтез
динамических свойств (процессов) при изменениях целей (структур­
ных связей при прежнем составе структурных элементов), парамет­
рических изменениях и изменениях структуры (с новым составом
структурных элементов и соответствующими связями между ними).
Отметим, что фактически учтен случай появления (удаления) но­
вых структурных элементов, что имеет место при модернизации и ре­
конструкции системы. Сказанное относится и к процессу планирова­
ния.

КОНТРОЛЬНЫЕ ВОПРОСЫ

1. Какие методы используют при решении задачи планирования в адаптив­

ном управлении?
2. Какие требования предъявляют к процессу планирования в многоуровне­
вых управляющих системах?
3. Какие алгоритмы используют для решения задач динамического линей­
ного программирования?
4. Укажите области применения оптимальных и имитационных моделей.
5. Каким требованиям должны отвечать методы описания процедуры управ­
ления?
6. Какие существуют режимы планирования?
7. Укажите условия, гарантирующие совместность при ресурсном обеспече­
нии плана.
8. Для каких целей используют методы квазиобратных матриц?
9. Какие классы задач выделяют в задаче согласования интересов?
10. При каких условиях элементы ресурсного обеспечения являются согла­
сованными?
11. Перечислите исходные дополнительные данные при переходе на выпуск
новой продукции.
12. Укажите варианты запуска новой и снятия старой продукции.
13. В каких случаях используют расчет с помощью декомпозиции?
14. Укажите достоинства и недостатки имитационной модели.
15. Какие функции выполняет линейно-квадратичный критерий?
16. Определите основное свойство, с помощью которого ЛПР может задать
динамику (время на устранение отклонения в выполнении плана).
17. Какие составляющие входят в состав векторного свойства?
18. Какие свойства используются при многоуровневом процессе решения
одноуровневых задач?
19. Раскройте понятия горизонтальной и вертикальной координации.
 ГЛАВА 7
Информационное обеспечение
автоматизированного управления

Автоматизированное управление базируется на реализации информацион­

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

7 .1 . ИНФОРМАЦИОННОЕ ОБЕСПЕЧЕНИЕ
АВТОМАТИЗИРОВАННОГО УПРАВЛЕНИЯ
НА ОСНОВЕ ТЕХНОЛОГИИ БАЗ ДАННЫХ

В настоящее время определяющими направлениями информаци­

онного обеспечения автоматизированного управления является кон­
цепция базы данных, склада (хранилища) данных [47].
База данных может быть определена как совокупность взаимосвя­
занных данных, используемых несколькими пользователями и хра­
нящихся с регулируемой избыточностью. Хранимые данные не зави­
сят от программ пользователей, для модификации и внесения изме­
нений применяется общий управляющий метод.
Банк данных — система, представляющая определенные услуги по
хранению и поиску данных определенной группе пользователей по
определенной тематике.
Система баз данных — совокупность управляющей системы, при­
кладного программного обеспечения, базы данных, операционной
системы и технических средств, обеспечивающих информационное
обслуживание пользователей.
Хранилище данных (ХД), также применяют термины «склад дан­
ных», «информационное хранилище», Data Warehouse — это база
данных, хранящая данные, агрегированные по многим измерениям.
Основные отличия ХД от БД: агрегирование данных; данные из ХД
никогда не удаляются; пополнение ХД происходит на периодической
основе; автоматическое формирование новых агрегатов данных, за­
висящих от старых; доступ к ХД осуществляется на основе многомер­
ного куба или гиперкуба.
Альтернативой хранилищу данных является концепция «витрин
данных» (Data Mart). Витрины данных — множество тематических
БД, содержащих информацию, относящуюся к отдельным информа­
ционным аспектам предметной области.
Еще одним важным направлением развития баз данных являются
репозитарии. Репозитарий, в упрощенном виде, можно рассматри­
вать просто как базу данных, предназначенную для хранения не поль­
зовательских, а системных данных. Технология репозитариев проис­
текает от словарей данных, которые по мере обогащения новыми
функциями и возможностями приобретали черты инструмента для
управления метаданными.
Каждый из участников действия (пользователь; группа пользова­
телей; «физическая память») имеет свое представление об информа­
ции.
По отношению к пользователям для описания предметной облас­
ти принято использовать трехуровневое представление: концепту­
альное, логическое и внутреннее (физическое) (рис. 7.1).

Группа пользователей А Группа пользователей В

Внешняя модельА^) (ТЗнешняя моделГв^)

Концептуальная Концептуальное
модель представление

2= £
%щ Логическая Логическое
ч
< id
аL> ° модель представление
С
Ч ' Физическое
Физическая модель
(хранимая база представление
данных)
1
Рис. 7.2. Фрагмент предметной базы данных «Сбыт» и одно из возможных его
концептуальных представлений

Концептуальный уровень связан с частным представлением данных '

группы пользователей в виде внешней схемы, объединяемых общно­
стью используемой информации. Каждый конкретный пользователь
работает с частью БД и представляет ее в виде внешней модели. Этот
уровень характеризуется разнообразием используемых моделей (мо­
дель «сущность — связь», ER-модель, модель Чена, бинарные и ин-
фологические модели, семантические сети). На рис. 7.2 представлен
фрагмент предметной базы данных «Сбыт» и одно из возможных его
концептуальных представлений, которое отражает не только объекты
и их свойства, но и взаимосвязи между ними.
Логический уровень является обобщенным представлением дан­
ных всех пользователей в абстрактной форме. Используются три
классических вида моделей: иерархические, сетевые и реляционные.
Сетевая модель — модель объектов-связей, допускающая только
бинарные связи «многие к одному» и использующая для описания
модель ориентированных графов.
Иерархическая модель — разновидность сетевой, являющаяся со­
вокупностью деревьев (лесом).
Реляционная модель использует представление данных в виде таб­
лиц (реляций), в ее основе лежит математическое понятие теорети-
Рис. 7.3. Представление предметной базы данных «Сбыт» на логическом уровне
для различных моделей

ко-множественного отношения, базируется на реляционной алгебре

и теории отношений.
Представление предметной базы данных «Сбыт» на логическом
уровне для различных моделей приведено на рис.7.3.
Дальнейшим развитием логического представления данных явля­
ется переход к объектно-ориентированным моделям данных, что свя­
зано с процессом «перекачки» в них огромных объемов информации,
которая в настоящее время хранится преимущественно в реляцион­
ных базах данных.
Суть объектно-ориентированной базы данных (ООБД) определяет­
ся объектно-ориентированным подходом.
Объектно-ориентированный подход подразумевает объектно-ори­
ентированное проектирование и объектно-ориентированное програм­
мирование.
Объектно-ориентированное проектирование — методология про­
ектирования, соединяющая в себе процесс объектной декомпозиции и
приемы представления логических и физических, а также статиче­
ских и динамических моделей проектируемой системы.
Объектно-ориентированное программирование — методология
программирования, основанная на представлении программ в виде
связанной совокупности объектов, каждый из которых является эк­
земпляром определенного класса, а классы образуют иерархию по на­
следованию.
 Объектно-ориентированное проектирование предполагает не
только деление (декомпозицию) базы знаний или базы данных на со­
ставные части, но и рассмотрение общей этапности реализации БД,
выбор инструмента реализации с учетом оговоренных в техническом
задании вариантов реализации.
Свойства реляционных, сетевых, иерархических, объектно-иерар-
хических и объектно-реляционных моделей данных (многомерные
модели считаем разновидностью иерархических моделей данных)
возможно систематизировать и сравнить, как это сделано в табл. 7.1.

Таблица 7.1

Вид модели Достоинства Недостатки

Иерархическая Простота понимания Отношения М:М могут быть
Высокое быстродействие при реализованы только искусствен­
совпадении структур базы дан­ но
ных и запроса Могут быть избыточные дан­
ные
Усложняются операции вклю­
чения и удаления
Удаление исходных сегментов
приводит к удалению порожден­
ных сегментов
Процедурный характер по­
строения структуры БД и мани­
пулирования данными
Доступ к любому порожденно­
му сегменту возможен только че­
рез корневой сегмент
Сильная зависимость логиче­
ской и физической моделей
Ограниченный набор структур
запроса
Невозможность реализации
таблиц с нелинейной структурой
Сетевая Сохранение информации при Отношения М:М могут быть
уничтожении записи-владельца реализованы только искусствен­
Более богатая структура за­ но
просов Необходимость программисту
Меньшая зависимость логи­ знать логическую структуру БД
ческой и физической моделей Процедурный характер по­
Возможность реализации строения структуры БД и мани­
таблиц с нелинейной структу­ пулирования данными
рой Возможная потеря независи­
мости данных при реорганиза­
ции БД
 Вид модели Достоинства Недостатки
Реляционная Произвольная структура за­ Отношения М:М могут быть
проса реализованы только искусствен­
Простота работы и отражения но
представлений пользователя Необходимость нормализации
Отделение физической моде­ данных
ли от логической и логической Возможность логических оши­
от концептуальной бок при нормализации и реали­
Хорошая теоретическая про­ зации
работка Невозможность реализации
таблиц с нелинейной структурой
Объектно-ори- Неограниченный набор ти­ Сложность освоения модели
ентированная пов данных из-за сложности структуры БД
Возможность реализации Нечеткий язык программиро­
таблиц с нелинейной структу­ вания
рой Недостаточная защита данных
Послойное представление Нечетко проработанный одно­
данных временный доступ
Высокая скорость работы Плохая обозримость структу­
из-за отсутствия ключа ры
Ненужность нормализации
Легкая расширяемость струк­
туры и ее гибкость
Повторное использование
типов данных и компонентов
Реализация отношений М:М

Физический (внутренний) уровень связан со способом фактическо­

го хранения данных в физической памяти ЭВМ. Во многом определя­
ется конкретным методом управления. Основными компонентами
физического уровня являются хранимые записи, объединяемые в
блоки; указатели, необходимые для поиска данных; данные перепол­
нения; промежутки между блоками; служебная информация.
По наиболее характерным признакам БД можно классифициро­
вать следующим образом:
по способу хранения информации:
• интегрированные;
• распределенные;
по типу пользователя:
• монопользовательские;
• многопользовательские;
по характеру использования данных:
• прикладные;
 • предметные.
В настоящее время при проектировании БД используют два под­
хода. Первый из них основан на стабильности данных, что обеспечи­
вает наибольшую гибкость и адаптируемость к используемым прило­
жениям. Применение такого подхода целесообразно в тех случаях,
когда не предъявляются жесткие требования к эффективности функ­
ционирования (объем памяти и время поиска), существует большое
количество разнообразных задач с изменяемыми и непредсказуемы­
ми запросами.
Второй подход базируется на стабильности процедур запросов к
БД и является предпочтительным при жестких требованиях к эффек­
тивности функционирования, особенно это касается быстродейст­
вия.
Важным аспектом проектирования БД является проблема инте­
грации и распределения данных. Господствовавшая до недавнего време­
ни концепция интеграции данных при резком увеличении их объема
оказалась несостоятельной. Этот факт, а также увеличение объемов
памяти внешних запоминающих устройств при их удешевлении, ши­
рокое внедрение сетей передачи данных способствовали внедрению
распределенных БД. Распределение данных по месту их использова­
ния может осуществляться следующими способами.
1. Копируемые данные. Одинаковые копии данных хранятся в
различных местах использования, так как это дешевле передачи дан­
ных. Модификация данных контролируется централизованно.
2. Подмножество данных. Группы данных, совместимые с исход­
ной базой данных, хранятся отдельно для местной обработки.
3. Реорганизованные данные. Данные в системе интегрируются
при передаче на более высокий уровень.
4. Секционированные данные. На различных объектах использу­
ются одинаковые структуры, но хранятся разные данные.
5. Данные с отдельной подсхемой. На различных объектах ис­
пользуются различные структуры данных, объединяемые в интегри­
рованную систему.
6. Несовместимые данные. Независимые базы данных, спроекти­
рованные без координации, требующие объединения.
Важное влияние на процесс создания БД оказывает внутреннее со­
держание информации. Существует два направления:
• прикладные БД, ориентированные на конкретные приложения,
например может быть создана БД для учета и контроля поступления
материалов;
 • предметные БД, ориентированные на конкретный класс дан­
ных, например предметная БД «Материалы», которая может быть ис­
пользована для различных приложений.
Конкретная реализация системы баз данных, с одной стороны, оп­
ределяется спецификой данных предметной области, отраженной в
концептуальной модели, а с другой стороны, типом конкретной СУБД
(МБД), устанавливающей логическую и физическую организацию.
Для работы с БД используется специальный обобщенный инстру­
ментарий в виде СУБД (МБД), предназначенный для управления БД
и обеспечения интерфейса пользователя.
Основные стандарты СУБД:
• независимость данных на концептуальном, логическом, физи­
ческом уровнях;
• универсальность (по отношению к концептуальному и логиче­
скому уровню, типу ЭВМ);
• совместимость, неизбыточность;
• безопасность и целостность данных;
• актуальность и управляемость.
Существует два основных направления реализации СУБД: про­
граммное и аппаратное.
Программная реализация (в дальнейшем СУБД) представляет со­
бой набор программных модулей, работает под управлением кон­
кретной ОС и выполняет следующие функции:
• описание данных на концептуальном и логическом уровнях;
• загрузку данных;
• хранение данных;
• поиск и ответ на запрос (транзакцию);
• внесение изменений;
• обеспечение безопасности и целостности.
Она обеспечивает пользователя следующими языковыми средст­
вами:
• языком описания данных (ЯОД);
• языком манипулирования данными (ЯМД);
• прикладным (встроенным) языком данных (ПЯД, ВЯД).
Аппаратная реализация предусматривает использование так назы­
ваемых машин баз данных (МБД). Их появление вызвано возросши­
ми объемами информации и требованиями к скорости доступа. Сло­
во «машина» в термине МБД означает вспомогательный периферий­
ный процессор. Термин «компьютер БД» — автономный процессор
 Рис. 7.4. Совокупность процедур проектирования БД

баз данных или процессор, поддерживающий СУБД. Основные на­

правления МБД:
• параллельная обработка;
• распределенная логика;
• ассоциативные ЗУ;
• конвейерные ЗУ;
• фильтры данных и др.
На рис. 7.4 представлена совокупность процедур проектирования
БД, которые можно объединить в следующие этапы.
На этапе формулирования и анализа требований устанавливают
цели организации, определяют требования к БД. Эти требования до­
кументируют в форме, доступной конечному пользователю и проек-
тировщику БД. Обычно при этом используют методику интервьюи­
рования персонала различных уровней управления.
Этап концептуального проектирования заключается в описании и
синтезе информационных требований пользователей в первоначаль­
ный проект БД. Результатом этого этапа является высокоуровневое
представление информационных требований пользователей на осно­
ве различных подходов.
В процессе логического проектирования высокоуровневое пред­
ставление данных преобразуется в структуре используемой СУБД.
Полученная логическая структура БД может быть оценена количест­
венно с помощью различных характеристик (число обращений к ло­
гическим записям, объем данных в каждом приложении, общий объ­
ем данных и т.д.). На основе этих оценок логическая структура может
быть усовершенствована с целью достижения большей эффективно­
сти.
На этапе физического проектирования решают вопросы, связанные
с производительностью системы, определяют структуры хранения
данных и методы доступа.
Весь процесс проектирования БД является итеративным, при
этом каждый этап рассматривается как совокупность итеративных
процедур, в результате выполнения которых получают соответствую­
щую модель.
Взаимодействие между этапами проектирования и словарной
системой необходимо рассматривать отдельно. Процедуры проекти­
рования могут использоваться независимо в случае отсутствия сло­
варной системы. Сама словарная система может рассматриваться как
элемент автоматизации проектирования.
Этап расчленения БД связан с разбиением ее на разделы и синте­
зом различных приложений на основе модели. Основными фактора­
ми, определяющими методику расчленения, помимо указанных на
рис. 7.4, являются: размер каждого раздела (допустимые размеры);
модели и частоты использования приложений; структурная совмес­
тимость; факторы производительности БД. Связь между разделом БД
и приложениями характеризуется идентификатором типа приложе­
ния, идентификатором узла сети, частотой использования приложе­
ния и его моделью.
Модели приложений могут быть классифицированы следующим
образом:
1. Приложения, использующие единственный файл.
2. Приложения, использующие несколько файлов, в том числе
допускающие:
 • независимую параллельную обработку;
• синхронизированную обработку.
Сложность реализации этапа размещения БД определяется мно­
говариантностью. Поэтому на практике рекомендуется в первую оче­
редь рассмотреть возможность использования определенных допу­
щений, упрощающих функции СУБД, например допустимость вре­
менного рассогласования БД, осуществление процедуры обновления
БД из одного узла и др. Такие допущения оказывают большое влия­
ние на выбор СУБД и рассматриваемую фазу проектирования.
Средства проектирования и оценочные критерии используются
на всех стадиях разработки. Любой метод проектирования (аналити­
ческий, эвристический, процедурный), реализованный в виде про­
граммы, становится инструментальным средством проектирования,
практически не подверженным влиянию стиля проектирования.
В настоящее время неопределенность при выборе критериев яв­
ляется наиболее слабым местом в проектировании БД. Это связано с
трудностью описания и идентификации бесконечного числа альтер­
нативных решений. При этом следует иметь в виду, что существует
много признаков оптимальности, являющихся неизмеримыми свой­
ствами, которые трудно выразить в количественном представлении
или в виде целевой функции. Поэтому оценочные критерии принято
делить на количественные и качественные. Наиболее часто исполь­
зуемые критерии оценки БД, сгруппированные в такие категории,
представлены ниже.
Количественные критерии: время ответа на запрос, стоимость мо­
дификации, стоимость памяти, время на создание, стоимость на ре­
организацию.
Качественные критерии: гибкость, адаптивность, доступность для
новых пользователей, совместимость с другими системами, возмож­
ность конвертирования в другую вычислительную среду, возмож­
ность восстановления, возможность распределения и расширения.
Трудность в оценке проектных решений связана также с различ­
ной чувствительностью и временем действия критериев. Например,
критерий эффективности обычно является краткосрочным и чрезвы­
чайно чувствительным к проводимым изменениям, а такие понятия,
как адаптируемость и конвертируемость, проявляются на длительных
временных интервалах и менее чувствительны к воздействию внеш­
ней среды.
Предназначение хранилища данных — информационная под­
держка принятия решений, а не оперативная обработка данных. По-
 Приложение 1 Приложение 2
Операции Информационная Операции
чтения/записи система чтения/записи
базы данных руководителя базы данных
Информационные С"
Оперативная запросы Оперативная
база данных база данных
Склад
Периодическое данных Периодическое
обновление -------- обновление
содержимого склада содержимого склада
Периодическое
обновление
содержимого склада

Приложение 3 Оперативная Приложение 4

Операции база данных Операции
чтения/записи чтения/записи
базы данных базы данных

Рис. 7.5. Архитектура ХД

этому база данных и склад данных не являются одинаковыми поня­

тиями. Архитектура хранилища данных (ХД) представлена на рис. 7.5.
Основные принципы организации хранилищ данных следующие
[45].
1. Предметная ориентация. В оперативной базе данных обычно
поддерживается несколько предметных областей, каждая из которых
может послужить источником данных для ХД. Например, для магази­
на, торгующего видео- и музыкальной продукцией, интерес пред­
ставляют следующие предметные области: клиенты, видеокассеты,
CD -диски и аудиокассеты, сотрудники, поставщики. Явно просле­
живается аналогия между предметными областями ХД и классами
объектов в объектно-ориентированных базах данных. Это говорит о
возможности применения методов проектирования, применяемых в
объектно-ориентированных СУБД.
2. Средства интеграции. Приведение разных представлений од­
них и тех же сущностей к некоторому общему типу.
3. Постоянство данных. В ХД не поддерживаются операции моди­
фикации в смысле традиционных баз данных. В ХД поддерживается
модель «массовых загрузок» данных, производимых в заданные мо­
менты времени по установленным правилам в отличие от традицион­
ной модели индивидуальных модификаций.
 4. Хронология данных. Благодаря средствам интеграции реализу­
ется определенный хронологический временнбй аспект, присущий
содержимому ХД.
Основные функции репозитариев:
• парадигма включения/выключения и некоторые формальные
процедуры для объектов;
• поддержка множественных версий объектов и процедуры управ­
ления конфигурациями для объектов;
• оповещение инструментальных и рабочих систем об интересую­
щих их событиях;
• управление контекстом и разные способы обзора объектов ре­
позитария;
• определение потоков работ.
Рассмотрим кратко основные направления научных исследова­
ний в области баз данных:
• развитие теории реляционных баз данных;
• моделирование данных и разработка конкретных моделей раз­
нообразного назначения;
• отображение моделей данных, направленных на создание мето­
дов преобразования моделей данных и конструирования коммута­
тивных отображений, разработку архитектурных аспектов отображе­
ния моделей данных и спецификаций определения отображений для
конкретных моделей данных;
• создание СУБД с мультимодельным внешним уровнем, обеспе­
чивающих возможности отображения широко распространенных
моделей;
• разработка, выбор и оценка методов доступа;
• создание самоописываемых баз данных, позволяющих приме­
нять единые методы доступа для данных и метаданных;
• управление конкурентным доступом;
• развитие систем программирования баз данных и знаний, кото­
рые обеспечивали бы единую эффективную среду как для разработки
приложений, так и для управления данными;
• совершенствование машины баз данных;
• разработка дедуктивных баз данных, основанных на примене­
нии аппарата математической логики и средств логического програм­
мирования в области баз данных;
• разработка пространственно-временных баз данных;
• интеграция неоднородных информационных ресурсов.
 7 .2 . РАЗВИТИЕ ИНФОРМАЦИОННОГО
ОБЕСПЕЧЕНИЯ АВТОМАТИЗИРОВАННОГО
УПРАВЛЕНИЯ НА ОСНОВЕ
ОБЪЕКТНО-ОРИЕНТИРОВАННЫХ
И ОБЪЕКТНО-РЕЛЯЦИОННЫХ БАЗ ДАННЫХ

7.2.1. Объектно-ориентированные базы данных

Серьезные недостатки реляционной модели данных привели к
необходимости поиска других моделей. Такой прогрессивной и пер­
спективной моделью данных является объектно-ориентированная
модель данных. В ней собственно база данных, интерфейс пользова­
теля и алгоритм приложения построены с использованием объект­
но-ориентированного подхода.
Автор реляционной модели данных Э.Ф. Кодд первоначально
сформулировал дюжину требований к БД, чтобы она могла называть­
ся реляционной. В дальнейшем этот перечень увеличился до 333 тре­
бований. Им, несмотря на широкое распространение реляционных
баз данных, не удовлетворяет ни одна из известных СУБД.
Более того, при значительных объемах данных начинают прояв­
ляться недостатки реляционных баз данных. К этим недостаткам от­
носятся: сложность структуры, вызванная необходимостью проведе­
ния нормализации; низкая производительность из-за поиска по клю­
чу, что в 3—5 раз увеличивает количество операций доступа; ограни­
ченный набор типов данных; представление данных только в виде
двумерных таблиц и невозможность реализации таблиц с нелинейной
структурой; невозможность послойного рассмотрения данных (на­
пример, «работающие» — в одном слое, «научные сотрудники» и
«преподаватели» — в другом, подчиненном слое); нестыковка с
принципами все более широко применяемого объектно-ориентиро­
ванного подхода; невозможность задать для определенного типа дан­
ных набор операторов-методов, которые приходится вводить в кон­
кретном приложении; возникновение конфузии — утраты при много­
численных обновлениях третьей (а порой и второй) нормальной фор­
мы; сложность совмещения с другой парадигмой хранилищ данных.
Одним из способов устранения указанных недостатков является
построение объектно-ориентированной базы данных (ООБД). Ее по­
явление стимулировано и требованиями большой быстродействую­
щей памяти (свыше 20 Гбайт) для систем конструирования/произ­
водства (CAD/CAM).
 В соответствии с «Манифестом ООБД», опубликованным в
1989 г., используется формула
ООСУБД = СУБД + ООЯП,
где сокращения 0 0 и ЯП означают объектно-ориентированный и
язык программирования. ООСУБД должна поддерживать объекты с
нелинейной структурой (сложные объекты, в том числе с иерархией
типов), что достигается инкапсуляцией и наследованием. Легко поддер­
живаются расширяемость, вычислительная полнота, языки запроса.
В 1991 г. была сформирована группа Object Database Management
Group (ODMG), перед которой была поставлена цель построить
стандарты для ООБД хотя бы на уровне стандартов для реляционных
БД. В 1993 г. эта группа предложила своеобразный стандарт для
ООБД, названный 0D M G -3, который включал:
1) объектную модель Object Data Model (ODM);
2) язык определения объектов Object Definition Language (ODL);
3) объектный язык запроса Object Query Language (OQL);
4) интерфейсы языков программирования (С и др.).
В настоящее время насчитывается свыше 300 объектно-ориенти­
рованных СУБД (ООСУБД), данные некоторых из них приведены в
табл. 7.2. Сфера их применения указана в табл. 7.3.
Таблица 7.2

Фирма-производи­ Название Средства разработ­ Подход к разра­

тель ООСУБД ки ботке
Objectivity Objectivitv/DB С, С ", SOL, Java Расширение объ-
Poet Software Poet С, C *\ ODBC, Java ектно-ориентиро-
Object Design Object Store С, C+\ Java ванных библиотек
— классов
Ontos Inc. C *\ Java
Versant Object Ontos DB, Versant C \ Java
Technology
Computer Jasmine C+\ Java
Associate
НПЦ «Интелтек ODB-Jupiter C,+
Плюс»
0 2 Technology 02 C ” , Java, Вставка объектно-
ориентированного
языка БД в обычный
базовый язык
GemStone Inc. GemStone C *\ Java Расширение язы­
ка (С ") возможно­
стями работы с БД
InterSystems CACHE Semantic Informa­ Новый язык базы
tion Manager, Cache данных или модели
ObjectScript данных
 Область применения Versant GemSton 02 ObjectSto РОЕТ
е O'
Моделирование + + + + +
САПР + + + + +
Управление производством — + + + +
Обработка изображения + + — + +
CASE + + — + +
Планирование + — — —

Гипертекстовые системы + — + + ■
Издательство — — — + —

Экспертные системы + — — + Н. д.

Суть объектно-ориентированной БД определяется объектно-ори­

ентированным подходом (рис. 7.6), который подразумевает объект­
но-ориентированное проектирование и объектно-ориентированное
программирование.
Объектно-ориентированное проектирование — методология про­
ектирования, соединяющая в себе процесс объектной декомпозиции
и приемы представления логических и физических, а также статиче­
ских и динамических моделей проектируемой системы.
Объектно-ориентированное программирование — методология
программирования, основанная на представлении программ в виде
связанной совокупности объектов, каждый из которых является эк­
земпляром определенного класса, а классы образуют иерархию по на­
следованию. Объектно-ориентированное проектирование предпола­
гает не только деление (декомпозицию) базы знаний или базы данных
на составные части (рис. 7.7), но и рассмотрение общей этапности
реализации БД, выбор инструмента реализации с учетом оговорен­
ных в техническом задании вариантов реализации.
 Объектно-ориентированное програм- ! Компьютер
мирование (рис. 7.8) берет за основу мо­ Алгоритм База
дель атомарного элемента. Дело в том, что работы данных
несмотря на мощные средства отладки
программ, для повышения производи­
тельности процедуры программирования Интерфейс
целесообразно отлаживать программы пользователя
последовательно, по блокам. Программа в
целом отлаживается быстрее, если блоки Пользователь
были отлажены заранее. Эти предпосыл­
ки и положены в основу объектно-ориен­ Рис. 7.7. Объектно-ориенти­
рованное проектирование
тированного программирования.
Выделяется несколько специфиче­
ских понятий. Данные называют свойствами, а алгоритмы — метода­
ми. Доступ к классу осуществляется через свойства — в статическом
режиме написания и отладки программы или через методы — в про­
цессе выполнения (работы) программы.
Начало работы класса задается с помощью специальных внутрен­
них (например, нажатие кнопки) или внешних (вызов из другой под­
программы) сигналов, называемых событиями.
Программную реализацию класса называют компонентом. Реа­
лизация компонента в некоторой программе получила название объ­
екта.
В объектно-ориентированном программировании используют три
основных принципа: инкапсуляция, наследование, полиморфизм.
Инкапсуляция — выделение класса с доступом к нему через свой­
ства или методы.
Наследование — трансформация класса путем изменения свойств
и методов с помощью методов, называемых конструктором и дест­
руктором.
 Все классы (компоненты) строятся по иерархическому принципу
с происхождением от некоторого исходного класса.
Полиморфизм позволяет использовать метод с одним именем как в
базовом, так и в производных классах. Дело в том, что количество
классов значительно: уже сейчас оно приближается к ста и продолжа­
ет расти. Если для производных классов применять для однотипных,
«похожих» методов (например, начертание квадрата и окружности)
разные имена, пользователю, особенно начинающему, будет сложно
освоиться с таким разнообразием имен.
Приведем основные положения 0 0 БД, базирующиеся на объект­
но-ориентированном подходе.
1. В качестве значения столбца может быть использован произ­
вольный кортеж. Иными словами, столбец может являться как бы не­
которой другой таблицей. Таким образом, создается возможность
реализации таблиц с нелинейной структурой.
2. Процедура манипуляции данными позволяет присоединять
процедуры, определенные значениями столбцов.
3. Данные столбцов могут наследоваться.
4. Элементами отношений могут служить не только отдельные
элементы, как в реляционных БД, но и множества.
5. Формируются классы данных, которые организуют столбцы в
иерархию.
Базовым языком ООБД чаще всего является С++. Для работы с та­
кими ООБД разрабатывается новый вариант языка программирова­
ния SQL, получивший название SQL3 и содержащий внутри себя в
качестве частного случая реляционную модель (SQL2). Если SQL2
определяет семь способов связывания со стандартными языками
программирования, в SQL3 это количество предполагается увели­
чить.
В технологии разработки ООБД конкурируют два направления:
1) Distributed Object Linking and Embedding (OLE) фирмы
Microsoft.
2) Common Object Request Broker Architecture (CORBA) группы
OBDMG, поддерживаемое фирмами IBM, Novell, DEC, с ориентаци­
ей на все платформы. В рамках этого направления выделены и сфор­
мированы указанные ранее язык определения объектов Object
Definition Language (ODL); объектный язык запроса Object Query
Language (OQL); язык определения интерфейсов Interface Definition
Language (IDL).
Во втором направлении обычно выделяют [52] два стандарта
управления БД:
 • ODL/OQL, в котором объекты и методы формируются обычно с
помощью языка программирования С;
• язык программирования SQL3.
Необходимо отметить, что к объектно-ориентированным воз­
можно отнести только те базы данных, у которых все структурные
элементы реализации построены с использованием объектно-ориен-
тированного подхода. Если хотя бы один структурный элемент реали­
зации не использует объектно-ориентированный подход, говорят об
объектно-реляционной базе данных (ОРБД).
Таким образом, чтобы воспользоваться объектно-ориентирован-
ным подходом в построении собственно БД, необходимо:
1) провести инкапсуляцию данных, т. е. выделить классы и объ­
екты;
2) определить возможные виды структуры реализуемых таблиц:
3) создать наследование классов данных;
4) обеспечить полиморфизм.
Реализация даже первой позиции неоднозначна и различна, на­
пример, в ООСУБД и ОРСУБД. Имеется некоторое отличие даже в
рамках различных ООСУБД.
По сравнению с реляционными БД ООБД обладают следующими
преимуществами:
• лучшими возможностями моделирования систем из блоков, об­
ладающих произвольными связями;
• легкой расширяемостью структуры за счет создания новых ти­
пов данных (свойств), наследования, установления новых связей и
корректировки методов;
• возможностью использования рекурсивных методов при нави­
гационном методе доступа к большим объемам данных;
• повышением производительности в 10 — 30 раз;
• более широкой сферой применения (например, использование
в мультимедийных системах).
Преимущества ООБД [42] приведут, видимо, к очень широкому
их распространению. Однако прежде следует решить ряд задач по уст­
ранению недостатков ООБД: создать гибкую структуру БД; постро­
ить четкий язык программирования; отработать синтаксис разбора
запросов, в том числе — вложенных; определить несколько методов
доступа к данным; отработать вопросы одновременного доступа (раз­
решение конфликтов при множественном наследовании); опреде­
лить сложный перебор данных; отработать защиту и восстановление
данных; уточнить семантику (действия) операторов при динамиче­
ских изменениях; встроить изменение атрибутов дочерних объектов.
 Однако и после устранения названных недостатков переход к
ООБД будет носит