Разработка концепции системы: функциональный анализ и модульный синтез
Основные решения по устройству системы называют концепцией системы. Обычно концепция системы обрастает деталями, пока точность описания системы не оказывается достаточной для её изготовления на производственной платформе. Помним, что концепция системы «живая», она меняется в ходе развития системы по мере выпуска новых и новых версий системы, то есть в современном мире система не просто создаётся и эксплуатируется в неизменном после её создания виде, но система постоянно модифицируется даже после начала её эксплуатации. Это отражается в том, что вместо «жизненного цикла системы, от рождения до смерти» говорят сейчас о «создании и развитии системы» (создание MVP системы и последующий выпуск множества версий системы с новыми и новыми функциями/возможностями/сервисами, которые дают новые и новые фичи/features). В любом случае, концепция системы разрабатывается начально для выпуска MVP (minimal viable product, минимально жизнеспособная версия системы, то есть версия системы, способная принести хоть какую-то пользу при её эксплуатации), а затем продолжает дорабатываться.
Основное с****одержание концепции системы заключается в описании совмещения функционального («как работает») и конструктивного («из чего сделано») разбиения, с учётом пространственной компоновки и результирующей совокупной стоимости владения**.** Но это только основное содержание, а вот дальше напомним, что кандидатом на включение в основное содержание концепции системы будет ещё описание разбиения работ. Кроме этого, рассматривается описание не только работ, но и методов работы — это мы уже выходим не на собственно концепцию системы, а на концепцию системы с учётом создателей из графа создателей. Тем самым концепция системы так или иначе начинает затрагивать создателей, и всё больше приобретать черты концепции создания системы времени эксплуатации (то есть описание создателей системы, а не самой системы), а не просто концепции системы (описание системы в момент её эксплуатации, но затрагивающее какие-то связи с созданием — прежде всего выбор аффордансов, «изобретение»). Но этого разделения на концепцию системы и концепцию создания системы в современной инженерии пока нет, хотя иногда и встречается (скажем, в строительстве есть ПОС, проект организации строительства — это оно и есть, хотя ПОС обычно много детальней концепции).
Границы того, что включают в концепцию системы, определены очень нечётко (подробней о том, как создавать концепцию системы, будет в руководстве по системной инженерии), но консенсус в том, что самое основное в этой концепции — это показ совмещения
- функционального разбиения с учётом его прохождения через ограничения по линии требуемой функциональности (поэтому кроме разбиений обычно включают функциональные описания — какие-то инженерные расчёты характеристик, 1D моделирование)
- конструктивного разбиения с учётом его прохождения через ограничения в наличии аффордансов (поэтому тут часто исследуют наличие заказных конструктивов/компонент/модулей, возможности изготовления элементов конструкции, характеристики конструктивов),
- компоновки с учётом прохождения пространственных ограничений,
- стоимостного разбиения с учётом прохождения ограничений по затратам.
В отечественной литературе концепция использования и концепция системы часто совмещаются под названием технико-экономического проекта (а если система, например, блок атомной электростанции, то название может быть другим — ОБИН, обоснование инвестиций, или аван-проект). Инженеры до сих пор спорят, технический ли это проект без экономической части, или технико-экономический. Но наличие обязательности стоимостного описания среди основных системных описаний говорит, что обязательно это технико-экономический проект, чисто технический проект не имеет смысла.
После обрастания технико-экономического проекта подробностями переходят к собственно созданию более детальных проектов — сначала эскизного (и иногда даже эскизный проект путают с менее детальной концепцией системы), потом рабочего (с точностью, достаточной для изготовления). В русском языке это всё проект/design, поэтому часта путаница с проектом/project. Так что фраза «проект создания системы» двусмысленная по-русски: то ли это проект/project::работа по созданию системы, то ли это проект/design::описание системы. Как это различать? Как всегда: обращать внимание на тип понятия, обозначаемого термином «проект» и уточнять тип из контекста или прямо переспрашивать. Если сами говорите или пишете, старайтесь избегать ошибок из-за этой встроенной многозначности. «Проект скворечника по проекту скворечника» — такое слышишь часто, не забывайте проставить тип к каждому «проекту», это разные типы! И помним, что под словом «проект» часто имеют в виду ещё и третье значение — организация проекта.
Но вернёмся к концепции системы. Она начинается с того, что в ней согласовываются описания четырёх (а часто больше) основных ипостасей системы, описанных через части системы, которые мы находим в основных разбиениях/breakdowns. Так что для начала надо понять, как проходит вот это совмещение разбиений, для начала сосредоточимся только на двух из них — функциональном/ролевом и конструктивном/продуктовом/модульном.
В литературе для разных разбиений часто используют просто термин «структура», но нужно помнить, что это не любая «структура» как какой-то граф объектов и отношений, а именно иерархия по какому-то виду отношения часть-целое как основе разбиения/breakdown. Тем самым «структура» оказывается иерархией по отношению «часть-целое» (is_part_of, composition, состава) объектов функциональных, конструктивных, пространственных, стоимостных и им подобных (не только же основные виды частей системы используются в проектах, системы представляются не только в их основных ипостасях, но и во многих других!). Все другие отношения (специализации, классификации, предшествования во времени, взаимовлияния и т.д.) в этой «структуре» разбиений не учитываются.
Если иерархия показана как разбиение/breakdown, то структура разбиваемого объекта-системы — это именно структура частей-целых! И эти разные виды частей-целых показывают не объекты физической разборки-сборки, но просто указывают на выделение вниманием разного вида частей в физической системе. За одним исключением: конструктивные/продуктовые части, входящие в состав системы (affordances/аффордансы/«подходяшки») не только выделяются вниманием в ходе их взаимодействия при эксплуатации, когда они воплощают какие-то функциональные части, но и указывают на реальную физическую разборку-сборку, ибо они рассматриваются во время создания, где есть и разборка-сборка в ходе изготовления/воплощения системы.
Вот рисунок из стандарта IEC 81346-1:2022 (а этот стандарт взял этот рисунок из более раннего стандарта IEC 1392/09):
Это базовая схема работы по созданию концепции системы (и она же**—** базовая схема изобретательства). Тут не учтены компоновка и стоимость, но при реальной работе они тоже обязательно присутствуют, как и варианты разных других специфичных для того или иного проекта разбиений. Но главное тут**—** переход от функциональной декомпозиции к модульной/продуктов****ой композиции, от анализа к синтезу. То, что это «переход» и там есть «сначала» и «потом», задаётся линией времени (timeline**).**
Рассмотрим целевую систему, которую в начальный момент мы рассматриваем как функциональный объект А (подсистема::роль А в надсистеме для А). Первое, что происходит в ходе размышления о будущей системе — это функциональная декомпозиция: функциональные части разбиваются на более мелкие (на рисунке это B и другие четыре безымянные) и делается попытка подобрать для них конструктивные/материальные объекты как аффордансы, которые могут выполнить во время эксплуатации готовой системы функции этих функциональных частей. Вот этот подбор (догадка о том, какой из миллионов материальных/конструктивных объектов мог бы выполнить нужную роль, причём возможно такой объект надо будет ещё и изготовить, то есть речь может идти не об уже существующем объекте, а только о том, который надо будет ещё специально создать с нужными свойствами) — это и есть модульный синтез, а если задача представляется нетривиальной (то есть это не задача, а проблема: непонятно, что делать, если аффорданс сразу не нашёлся), то это называется изобретательством.
Типовое поведение молотка — «бить по предмету, передавать энергию бойка этому предмету». Это ожидаемое поведение отлично подходит для функции «забивание» с предметом функции «гвозди» (синоним: метод с его предметом метода, но терминология «метода работ» обычно применяется к одушевлённым предметам или роботам, а вот для простых агентов вроде молотка чаще говорят о функциях).
Изобретательство тут — увидеть, что не только молоток, но и микроскоп может дать ожидаемую функцию «забивать гвозди». И у молотка и у микроскопа есть ожидаемое поведение «бить по предмету, передавать энергию твёрдой массы этому предмету». И даже «камень» тоже может быть использован для воплощения роли «забивала» гвоздей, предложение задействовать для забивания гвоздей камень — тоже изобретение. Изобретатель за неимением молотка может выбрать в качестве аффорданса камень, ибо молотка нет, микроскоп может быть большой и неудобный, а камень легко подобрать по размеру и форме — соображения тут могут быть разные, и отнюдь не только соображения низкой цены камня.
Это ключевой момент: чтобы изобретение было возможно, на текущем уровне развития цивилизации должны существовать известные аффордансы для нужной функции. Если изобретение невозможно, то системы не будет. Хороший тут пример — изобретение вычислительной машины. Функционально с ней всё было понятно ещё Чарльзу Бэббиджу и Аде Лавлейс в начале 19 века. Но вот аффордансы для потребных функций логических операций работали ненадёжно: механика сбоила (это пробовал сам Бэббидж), пневматика не работала, электрические реле тоже сбоили, гидравлика тоже не работала! В итоге сработала электроника, после изобретения: было предложено использовать для создания универсального вычислителя логические вентили на радиолампах-триодах, задействованных не в режиме усилителя (для чего они первоначально и использовались), а в ключевом режиме. Эти лампы были доступны и относительно дёшевы, но изобретены они сами были только 1906 году, а изобретение компьютера на базе радиоламп состоялось только в 1945 году, но примерно половину времени компьютер не работал из-за ненадёжности радиоламп, супер-надёжные радиолампы появились только в 1948 году. Подробней эта история рассказана в руководстве по методологии, она и имеет отношение к стратегированию: вы не должны полагаться на то, что сделаете изобретение в проекте. Наоборот, вы можете начинать проект новой системы, если сделали изобретение! Если вы не понимаете, какова концепция системы хотя бы в общих чертах, если не понимаете, какие есть аффордансы — не начинайте проекта! Возможно, вы будете гениальным изобретателем, но возможно, это вы пытаетесь изобрести летательный аппарат тяжелее воздуха ещё до того момента, как появились лёгкие двигатели внутреннего сгорания (недаром братья Райт, изобретатели самолёта, были владельцы мотоциклетной мастерской). Концепция системы как раз говорит о том, что изобретение сделано, и можно приступать к детальному проектированию.
На рисунке из стандарта IEC 81346 видно, что на первом шаге декомпозиции подобрать конструктивы/продукты/модули с подходящими ожидаемыми функциями для воплощения/реализации подсистем удаётся только для двух подсистем из пяти (и показано это в левой части как подсистемы первого уровня с жёлтой и голубенькой гранью одновременно: жёлтая грань — описан функциональный аспект, то есть понятно какую выполняют функцию в надсистеме с именем А, а голубенькая грань — понятно, из каких конструктивов в правой части диаграммы эта подсистема будет будут сделана). На следующем шаге декомпозиции на подсистемы это уже удаётся для всех подсистем, в том числе для подсистем подсистемы B. Эта часть функциональной декомпозиции, когда мы пытаемся систему в её функциональной ипостаси разбить не на любые подсистемы, а на такие, какие потом удастся воплотить хоть какими-то аффордансами, иногда называется функциональным анализом**.** Анализ (предполагающий разъединение на части, декомпозицию) — это нормально, если вы не забываете про его подчинённость синтезу (сборке из частей). Анализ плох только если он сам по себе, в отрыве от синтеза, не подчинён целям синтеза. Рисунок из стандарта IEC 81346 как раз показывает, как функциональный анализ/декомпозиция поддерживает конструктивный/модульный синтез/сборку из аффордансов — трудно сразу предложить такой одноуровневый набор конструктивов, который реализует функциональность системы A, это много легче сделать, сначала разбив функциональность по отдельным подсистемам, а затем и конструктивы тоже объединять в целую систему в несколько шагов, через «сборочные единицы»/узлы[1] в какой-то их иерархии, а не одноуровнево.
После (помним стрелку логического времени на диаграмме) функциональной декомпозиции мы должны из всех конструктивов собрать/синтезировать целевую систему-конструктив (систему, рассматриваемую как конструктив), то есть конечный продукт/изделие, который будет выполнять начально заявленную функцию во время использования/эксплуатации/работы системы.
Для конструктива/модуля/узла B’ на рисунке, реализующего функциональную часть B это получается только в два шага — сначала собираются два промежуточных конструктива, и только потом они объединяются. На следующем шаге конструктив/модуль/узел B’ включается в состав конструктива А’, который реализует изначально задуманную систему А (когда говорим тут «система», то имеем ввиду её главную ипостась: функциональную).
Эту часть создания концепции системы, то есть составления целой системы в её конструктивной ипостаси (конструктив/модуль/продукт/изделие/узел) из её более мелких конструктивных частей называют модульный синтез. Иногда метод модульного синтеза (синтеза продукта из конструктивов) подают как метод «разузловки», то есть разборки на узлы, но нет — логически «разбираются», то есть декомпозируются именно функциональные части (подсистемы), а для конструктивных частей логически идёт именно сборка в конечный конструктив, то есть движение по диаграмме идёт от целой системы-роли к середине как набору подсистем, реализующих мелкие функции, а затем эти подсистемы воплощаются мелкими модулями/узлами, которые затем объединяются в конечную систему-конструктив (продукт/изделие). Так что речь тут идёт по факту о «сузловке», хотя этот термин никогда не используется. Почему же «разузловка», а не «синтез узлов»? Описываемый нами метод создания концепции системы был осознан инженерами не так давно, а нынешняя производственная терминология появилась много раньше. Инженерам казалось, что они «разбирают в уме» уже готовую конструкцию, но нет — узлы как раз собирают, это «сборочные единицы».
Концепция системы иногда очевидна, ничего изобретать не надо — вы просто знаете уже сделанное раньше изобретение. То, что для вычислительной машины нужно использовать электронику — это сегодня очевидно. Но, конечно, иногда приходится и изобретать (чаще всего, повторимся, не в ходе выполнения какого-то проекта, а перед его появлением — изобретения лежат в основе инженерных проектов, а не являются результатом проектных работ!).
В ТРИЗ[2] как теории изобретательства важно, что небольшое количество конструктивов будет выполнять большое количество функций (т.е. степень идеальности системы растёт: идеальная система — это та, функции которой выполняются, а конструкции у неё нет, нет материального воплощения, модулей/аффордансов в системе ноль, изготавливать ничего не надо). Так что в ТРИЗ заведомо соотношение между функциональными и конструктивными элементами не 1:1 (как и в наших примерах заварного чайника и ножниц).Ж****елательно научиться много функций навешивать на один конструктив/модуль/продукт/изделие**, уменьшая** их количество в системе.
Лучше всего это удаётся с компьютерами и роботами — поэтому общий тренд инженерии — в создании универсальных модулей, которые легко перепрограммировать для новых функций. В биологической эволюции природа пришла к более-менее универсальной и сложно устроенной клетке, самые разные функции которой (функции клеток печени, клеток мозга, клеток лёгких) получаются небольшим перепрограммированием. В техноэволюции смотрите на смартфон, компьютер и быстро развивающиеся идеи универсальных создателей, которые сегодня чаще всего проектируются как (само)программируемые интеллектуальные антропоморфные роботы.
В изобретательской деятельности мы решаем программу многоуровневой оптимизации, снимая конфликты между интересами, которые могут быть по поводу разных системных уровней. JohnDoyleс сотрудниками указывал, что в природе всегда есть противоречия (из них он особо выделял противоречие между скоростью и точностью: бывают быстрые неточные части системы и медленные точные части) и это противоречие может быть снято использованием многомасштабных конструкций с многоуровневыми обратными связями, в один уровень такое противоречие не снимешь. Поэтому если нужно сделать быструю и точную систему, она по необходимости становится сложной**—** и там много изобретательской работы, но эта работа поддержана математикой, им разработанной[3].
Обычно из имеющихся в наличии или легко изготавливающихся конструктивов трудно подобрать такие, которые при сборке их в готовую систему-конструктив реализуют все необходимые функциональные части, дающие во время эксплуатации систему со всеми необходимыми функциями. Для этого приходится нарушать логический порядок создания концепции системы, то есть менять уже разработанный вариант функционального разбиения на новый, в котором проще выполнить модульный синтез. Тем самым в жизни логический однократный метод создания концепции системы (сначала функциональная декомпозиция, потом модульный синтез) по факту оказывается итерационным: идут попытки функциональной декомпозиции, но в случае неудачи модульного синтеза на основе текущего функционального разбиения возвращаются к анализу — и дальше пробуют провести модульный синтез, то есть сделать изобретение, подобрать аффордансы, опираясь уже на новый вариант функционального разбиения. Опора на другой набор функциональных объектов по факту эквивалентно предложению другого способа работы устройства, другого принципа работы**.** И тогда для реализации других функций можно подобрать другие конструктивы, более доступные.
Скажем, универсальный компьютер можно реализовывать как набор функциональных подсистем квантового компьютера или классического логического компьютера. Аффордансы (конструктивы) для хорошо и надёжно работающего квантового компьютера неизвестны. А вот аффордансы для классического компьютера — известны, это сегодня транзисторы, которые можно изготавливать массово в электронных чипах-микросхемах. Так что сначала мы задаём какую-то декомпозицию компьютера на подсистемы, а потом проверяем: есть ли дешёвые аффордансы (и есть ли они вообще сегодня), и если нет — пытаемся поменять функциональную декомпозицию. Ну, или можно надеяться на то, что мы в какой-о момент сделаем изобретение — и найдём аффордансы для текущей функциональной декомпозиции, но тут можно промахнуться на сотню лет (как при изобретении компьютеров или самолётов).
Конструктивы/узлы/модули/продукты/изделия приходится разрабатывать и изготавливать, если их нельзя купить готовые. Купить— это простейший способ изготовленияконструктивов! В IEC 81346-1:2022 даже предлагают «продукт», если предполагается его закупка, называть «компонентом», настолько это частый случай. Терминология тут может быть самая разная, в другой литературе компонентом (или компонентой, в русском языке допустимы и мужской и женский род для этого слова) называют как раз функциональную часть, конструктивную часть будут называть «комплектующее», а предмет закупки будут так и называть — «предмет закупки».