Моделирование управления (Control) в процессе разработки IDEF0 функциональных моделей

Одним из категорических требований федерального стандарта США IDEF0  является требование иметь для каждой, без исключения, Activity (функции) любой функциональной модели (ФМ) - не менее одной стрелки Control (не менее одного канала управления).

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

IDEF0 так определяет сущность стрелки Control:

"…2.17 Control Arrow: The class of arrows that express IDEF0 Control, i.e., conditions required  to produce correct output.  Data or objects modeled as controls may be transformed by the function, creating output.  Control arrows are associated with the top side of an IDEF0 box…".

2.17 Стрелка управления: Класс стрелок, которые выражают управление IDEF0, то есть требуемые условия, чтобы произвести корректный выход[1]. Данные или объекты, моделируемые как управления, могут быть преобразованы функцией, создающей выход. Стрелка управления связана с верхней стороной бокса IDEF0.

На рис. 1 представлена предельно простая, но корректная по IDEF0 диаграмма ФМ. Все её Controls - применены в смысле приведённого определения. Но их сущность остаётся не слишком ясной. Дело в том, что управление является функционально неоднозвенным процессом. Распространён взгляд на управление как на процесс, состоящий из четырёх взаимосвязанных функций: Plan - Do - Check - Act (PDCA) так называемый "Цикл Демминга"[2].

Цикл Демминга может быть представлен в графическом IDEF0 формате - как на рис. 2. Для этого его функции должны быть пополнены стрелками - связями. Поэтому "Процесс 1" (соответствует Do в цикле Демминга) на рисунке пополнен входом "Plan 1", являющимся выходом с "Генерация Plan 1" ( Pl an ), информационным выходом "Инф(ормация) о проц 1", управлением "Управляющее воздействие 1", делающим излишним "Control 1". "Управляющее воздействие" является выходом с "Осуществл Act 1" ( Act ), инициированным выходом "Решение об управлении 1" с функции "Осуществл. Check 1" ( Check ), являющимся для него управлением. Решение об управлении является результатом сопоставления входов функции "Осуществл. Check 1" - "Plan 1" и "Инф. о проц. 1". Тоесть это последствие проверки текущего состояния выполнения Plan 1.

Здесь управляющее воздействие, в отличие от Control, является реальным воздействием на процесс, направленным на восстановление соответствия процесса - плану (Do - Plan).

В итоге этих построений получаем замкнутый контур управления Процессом 1 - КУ 1.

В таком представлении управления становится ясной и однозначной роль чертежа в ФМ. Это только информационный вход. А управлением является реальное воздействие на осуществляемый процесс - в случае расхождения результатов обработки с информацией чертежа. Например - перемещение суппорта токарного станка в положение, при котором станок будет обеспечивать в обработке её размеры - в соответствии с чертежом.

Продолжая корректное обустройство диаграммы, аналогично должен быть обеспечен связями "Процесс 2" - см. рис. 3. Создаётся контур управления КУ 2: генерация Plan 2 - Процесс 2 - Осуществление Check 2 - Осуществление Acct 2.

В результате этого возникает, также, Activity "Координация Plan 1 - Plan 2".

Дальнейшее аналогичное обустройство "Процесс 3" здесь не рассматриваем.

Как только мы признаём приведённую доктрину комплексного отражения управления в ФМ, мы получаем дальнейшие дополнительные трудности моделирования. Эти трудности состоят в том, что, помимо упомянутых КУ 1 и КУ 2 (также, далее, и КУ 3) возникает необходимость подобного же обустройства ВСЕХ Activities ВСЕХ КУ.

На рис. 4 - для примера - приведена соответствующая картина обустройства только Activity "Осуществление Check 2" (из КУ 2). Эта функция встраивается в контур управления: "Plan Check 2" - ("Осуществление Check 2") - "Check - Check 2" - "Act Check 2". Обозначим этот контур управления - как КУ 3.

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

И так далее.

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

В дополнение к резкому расширению числа Activity - функций в ФМ мы должны учесть, что все эти функции должны быть поддержаны инфраструктурно, тоесть получить исполнителя (Mechanism - для IDEF0) для каждой из них.

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

С другой стороны функциональные модели, разработанные с представлением управления в них - как на рис. 1 в действительности игнорируют процедуры управления. Это модели с неформализованным управлением. Это следует и из определения назначения стрелки Control в IDEF0 - "2.17 … стрелки, которые ВЫРАЖАЮТ управление IDEF0…" А не осуществляют его. Так что сами действия управления могут находиться вне ФМ.

Управление такими системами в процессе работы осуществляется их производственным персоналом. Это человекомашинные системы при разработке которых, мы полагаемся на импровизацию производственного персонала, затрудняя и задерживая, поэтому, процесс их введения в работу.

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

Чаще всего многоуровневое управление разрабатывается для процедур планирования. По мере развития таких систем, широта формализованного управления увеличивается. Это можно видеть на примере истории компьютерной поддержки управления в производственных системах. Эти сложные системы, интенсивно развивающиеся в настоящее время, переживают создание четвёртого поколения - MRP - MRP11 - ERP - CSRP с расширением компьютерной поддержки охвата управления от поддержки планирования потребностей в материалах (MRP - Material Requirements Planning[3]) до планирования ресурсов, синхронизированного с покупателем - CSRP [4] (Customer Synchronized Resources Planning).

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

Компенсируя некомплектность моделирования системы, мы должны внимательно прорабатывать Mechanisms её Activities, не имеющих разработанных КУ, чтобы обеспечить ручное управление ими. Единственное, что мы даём при этом персоналу в нашей модели - это информация о "…требуемых условиях, чтобы произвести корректный выход…". "Индульгенцию" на такие решения мы получили, фактически, от IDEF0.

Рис. 1. Диаграмма ФМ с тремя Activities, обустроенными связями в соответствии с регламентацией IDEF0

 

В статье не приводится информация о собственно функциональном моделировании, так как в отечественной практике имеется достаточно материалов по этому поводу. В том числе - см., например, [1].

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

Литература:

1. Дубейковский В. И. Эффективное моделирование с AllFusion Process Modeler 4.1.4 и AllFusion PM. Изд. ДИАЛОГ-МИФИ, 2007 г. 

[1] Выделение наше