Разработка концепции системы: функциональный анализ и модульный синтез
Основные решения по устройству системы называют концепцией системы. Обычно концепция системы обрастает деталями, пока точность описания системы не оказывается достаточной для её изготовления на производственной платформе. Помним, что концепция системы «живая», она меняется в ходе развития системы, система постоянно модифицируется даже после начала её эксплуатации.
Содержание концепции системы заключается в описании совмещения функционального («как работает») и конструктивного («из чего сделано») разбиения, с учётом пространственной компоновки и результирующей полной стоимости владения (и помним, что кандидатом на включение в концепцию системы будет ещё описание разбиения работ).
В литературе для разных разбиений часто используют просто термин «структура», но нужно помнить, что это именно иерархия по какому-то виду разбиения: отношения элементов структуры --- это обычно иерархия отношений «часть-целое» (is_part_of, composition, состава) функциональных, конструктивных объектов, размещений, стоимостей и подобных им объектов (не только же основные виды используются в проектах!). Все другие отношения (специализации, классификации, предшествования во времени, взаимовлияния и т.д.) в этой «структуре» разбиений не учитываются. Если иерархия показана как разбиение/breakdown, то структура разбиваемого объекта-системы --- это структура частей-целых! И эти разные виды частей-целых не показывают объекты физической разборки-сборки, но просто указывают на выделение частей в физической системе разного сорта вниманием. Хотя продуктные/конструктивные части (affordances/аффордансы/подходяшки) --- это не только про выделение вниманием в ходе их взаимодействия, но и про реальную разборку-сборку, тут же время создания, время разборки-сборки.
Вот рисунок из стандарта IEC 81346-1, а этот стандарт взял этот рисунок из более раннего стандарта IEC 1392/09. Это базовая схема работыпо созданию концепции системы (и она же --- базовая схема изобретательства). Тут не учтены компоновка и стоимость, но при реальной работе они тоже обязательно присутствуют, как и варианты разных других специфичных для того или иного проекта разбиений. Но главное тут --- переход от функциональной декомпозиции кмодульной/продуктной композиции, от анализа к синтезу.
Рассмотрим целевую систему, которую в начальный момент мы рассматриваем как функциональный объект А (функция/поведение или функциональная/ролевая часть системы --- это по большому счёту тут неважно и зависит от принятых соглашений моделирования. Вы или говорите о поведении «забивка гвоздей», или функциональной/ролевой части «забиватель гвоздей»). Сам стандарт IEC 81346 имеет дело с функциональными частями системы/ролевыми объектами, а не их поведением/функциями. Реализовать (realize) --- это вынести «логический» объект-функциональную роль в физическую реальность конструктивных модулей (исполнителей ролей). Грубо говоря, «забивка гвоздей» или «забиватель гвоздей» назначаются на молоток, микроскоп или камень. Это основа изобретательской деятельности: для одной и той же функции можно выбрать множество самых разных конструктивных/физических объектов окружающего мира (аффордансов), которые дадут нам нужное поведение.
Первое, что происходит в ходе размышления о будущей системе --- это функциональная декомпозиция: функция и/или функциональные части разбиваются на более мелкие (на рисунке это B и другие четыре) и делается попытка выбрать для них продукты/модули, сервисы которых могут выполнить функции этих функциональных частей.
Помним, что функции системы формулируются на языке проектных ролей надсистемы, а сервисы --- на языке проектных ролей системы. Сервис молотка --- «бить по предмету». Этот сервис отлично подходит для функции «забивать гвозди». Изобретательство тут --- увидеть, что не только молоток, но и микроскоп оба предоставляют сервис «бить по предмету», и даже «камень» тоже может дать такой сервис. И за неимением молотка выбрать, например, камень (ибо микроскоп может быть большой и неудобный, а камень легко подобрать по размеру и форме --- соображения тут могут быть разные, и отнюдь не только соображения низкой цены камня).
На рисунке из стандарта IEC 81346 видно, что на первом шаге декомпозиции подобрать продукты/модули с подходящими сервисами удаётся только для двух подфункций из пяти (и показано это как подсистемы: они понятно какую выполняют функцию в надсистеме с функциональным именем А и из каких модулей они будут сделаны), только для двух из пяти кубиков первого уровня с жёлтеньким цветом (функциональные части) удаётся подобрать реализацию конструктивными частями/продуктами (показаны голубеньким цветом на тех же кубиках). На следующем шаге это уже удаётся для всех подфункций, в том числе для подфункций B. Эта часть функциональной декомпозиции иногда называется функциональным анализом. Анализ (предполагающий разъединение на части, декомпозицию) --- это нормально, если вы не забываете про его подчинённость синтезу (сборке из частей). Анализ плох только если он сам по себе, в отрыве от синтеза, не подчинён целям синтеза. Рисунок из стандарта IEC 81346 как раз показывает, как анализ/декомпозиция поддерживает синтез/сборку.
Дальше мы должны из всех модулей, используя их интерфейсы для соединения, собрать/синтезировать целевую систему-модуль, конечный продукт, который будет выполнять начально заявленную функцию. Для модуля-сборки B' на рисунке, реализующего функциональную часть B это получается только в два шага --- сначала собираются два промежуточных модуля, и только потом они объединяются. На следующем шаге модуль B' включается в состав модуля А', который реализует изначально задуманную функцию А. С этого момента функция и сервис совпадают, функциональная часть и конструктивная часть/модуль совпадают. Эту часть проектирования системы как составления целой системы (модуля/продукта/изделия) из её конструктивных частей называют модульный синтез.
Концепция системы иногда очевидна, но иногда включает в себя изобретательство (работу с аффордансами, «подходящими для выполнения требуемой функции объектами окружающего мира как частями конструкции»). В ТРИЗ[1] важно, что небольшое количество элементов конструкции будет выполнять большое количество функций (т.е. степень идеальности системы растёт: идеальная система --- это та, функции которой выполняются, а конструкции у неё нет, нет материального воплощения, модулей/аффордансов в системе ноль, изготавливать ничего не надо). Так что в ТРИЗ заведомо соотношение между функциональными и конструктивными элементами не 1:1 (как в случае ножниц и заварного чайника). всегда помним, что модульный синтез ---это изобретательская деятельность: желательно научиться много функций навешивать на один модуль, уменьшая количество модулей в системе.
В изобретательской деятельности мы решаем программу многоуровневой оптимизации, снимая конфликты между интересами, которые могут быть по поводу разных системных уровней.
John Doyle с сотрудниками указывал, что в природе всегда есть противоречия (из них он особо выделял противоречие между скоростью и точностью: бывают быстрые неточные части системы и медленные точные части) и это противоречие может быть снято использованием многомасштабных конструкций с многоуровневыми обратными связями, в один уровень такое противоречие не снимешь. Поэтому если нужно сделать быструю и точную систему, она по необходимости становится сложной ---и там много изобретательской работы, но эта работа поддержана математикой, им разработанной[2].
Обычно из имеющихся в наличии или легко изготавливающихся модулей/продуктов трудно подобрать такие, которые в конструкции реализуют все необходимые функциональные части с их функциями. Для этого приходится менять способ разбивки процессов в системе на функции каких-то функциональных частей (что эквивалентно предложению другого способа работы устройства, другого принципа работы). И тогда для реализации других функций можно подобрать другие модули, более доступные.
Модули/продукты/изделия приходится разрабатывать и изготавливать, если их нельзя купить готовые. Купить --- это простейший способизготовления модулей! В IEC 81346-1:2022 даже предлагают «продукт» называть «компонентом», если предполагается его закупка, настолько это частый случай. Терминология тут может быть самая разная, в другой литературе компонентом (или компонентой, в русском языке допустимы и мужской и женский род для этого слова) называют как раз функциональную часть, конструктивную часть будут называть «комплектующее», а предмет закупки будут так их называть «предмет закупки».