Опубликован Control Architecture Design (CAD) Principle Framework (1/2)

В библиотеке FPF появился DPF архитектурного проектирования управления Человек удерживает равновесие при беге, энергосистема согласует производство и потребление нескладируемой электроэнергии, холдинг распределяет ресурсы между своими предприятиями. Природа этих систем разная, но архитектура управления у них имеет общие принципы. Какие изменения нужно отслеживать, какие пытаться сделать? Кто или что может на эти изменения повлиять? Какие решения принимаются вместе с кем-то, а какие самостоятельно кем-то? Что должно успеть произойти в системе управления до следующего действия? Как локально разумные управленческие решения складываются в приемлемый общий результат, а не противоречат друг другу? Пару дней назад в составе FPF Library появился Control Architecture Design Principles Framework (CAD DPF) -- можно его найти в https://fpf.tools/CAD (в том числе там в MCP) и https://github.com/ailev/FPF/blob/main/DPFs/Engineering%20DPF%20Suite/CONTROL-ARCHITECTURE-DESIGN-PRINCIPLES-FRAMEWORK.md. Предметная область архитектуры управления -- структура наблюдений (измерений), памяти, решений, обменов информацией и воздействий (команд управления), позволяющая получить требуемое поведение какой-то системы при известных и не очень известных ограничениях. CAD представляет концептуальный и методологический синтез современных (SoTA) исследований архитектур управления. Концептуальный — потому что различает объекты и отношения (концепты в мышлении об управлении, "онтология управления"), которые удобно, но опасно смешивать. Методологический — потому что соединяет исследовательские результаты концептуального синтеза в способы построить и сравнить целые варианты управления, методы архитектурного проектирования систем управления. Кибернетики нет, и хорошо. Но общая архитектура управления в живом и неживом -- есть. Общий язык для управления в живом и неживом был исходной амбицией кибернетики. В названии книги Норберта Винера 1948 года уже стоят рядом управление и связь в животном и машине [1]. Изучая живые системы, можно объяснять, как управление справляется с несовершенными компонентами, задержками и неполнотой сведений на разных масштабах. Но идеи собственно кибернетики (которую одно время считали чуть ли не синонимом системного подхода) оказались не слишком продуктивными. Часть идей потом была переиспользована в ТАУ/ТАР (теориях автоматического управления и регулирования, между ними есть некоторые нюансы, но общая постановка задачи была близка к кибернетической, хотя без амбиций всеобщей науки). Работы Doyle, Matni и их коллег по многослойным архитектурам систем управления заново рассмотрели общую постановку задачи на общую уже не науку, а инженерию систем управления (control system engineering), разделяющую идеи управления в биологических системах, киберфизических системах и организационных системах на принципах многоуровневости системы управления с опорой не столько на внешние петли обратной связи, как в кибернетике, сколько на внутренние обратные связи. Инженерные сети, роботы и теория распределённого управления дают другие конструкции, нежели пыталась предлагать кибернетика или ТАУ/ТАР. В статье Matni, Ames и Doyle 2024 года [2] рядом обсуждаются естественные и технические системы, причём один из истоков подхода к декомпозиции систем управления на слои -- управление перегрузками в сетях. История подхода здесь много богаче одностороннего «подсмотрели регулирование в бактериях или даже в мозге и скопировали в машину». Старинную кибернетическую интуицию часто сворачивают в одну внешнюю петлю: результат измерили, сравнили с желаемым, воздействовали, снова измерили. Для знакомства с обратной связью этого достаточно. Для объяснения архитектуры — уже мало. Внутри управляющей системы тоже происходят существенные информационные обмены: она использует сведения о собственных действиях ("внутренние обратные связи"), оценивает ещё не наблюдённые, а только спрогнозированные изменения, сопоставляет эти прогнозы, согласует решения и готовит продолжение выдачи команд на эффекторы-актуаторы ещё до прихода внешнего ответа от датчиков [3]. Какое внутреннее устройство позволяет получить приемлемое управление из компонентов, каждый из которых ограничен по своим свойствам и не может сам выдать нужные скорость и точность, а также устойчивость управления? В современных архитектурах управления предлагается многослойная (речь идёт о функциональной структуре, системная структура при этом будет многоуровневой) архитектура управления, где сама структура слоёв и внутренние обратные связи, работающие на разных частотах, оптимизированы для получения необходимых характеристик. Конечно, использование моделей с предсказаниями, многочастотное управление и даже многослойность давно существовали, ещё в старинной кибернетике. Новизна современного синтеза системы управления в вычислении оптимального архитектурного решения, где каждый функциональный элемент работает на достижение оптимальных характеристик. Что меняется по сравнению с ТАР и ТАУ (теориями автоматического регулирования и управления) В привычной задаче синтеза регулятора устройство управления в существенной части уже задано: известны измеряемые величины, доступные воздействия и заданные ограничения в поведении объекта управления (это даже не всегда система). Дальше выбирается закон, по которому из полученной информации рассчитывается управляющее воздействие. В архитектурной работе, в отличие от работы в рамках ТАР и ТАУ, предметом выбора становится и сама архитектура управления в целом: какие измерения надо получать, что сохранять в памяти, какие методы обработки информации замеров и выдачи предсказаний и команд разделить между какими слоями, как часто выполнять расчёты и выдачу команд, какими сообщениями соединить какие слои, а также систему управления с системой, которой надо управлять. CAD обобщает рассуждения по выбору архитектуры управления. Например, изменение частоты планирования рассматривается вместе с требованиями к быстрой коррекции и затратами на вычисление; изменение набора датчиков — вместе с возможностью оценивать состояние и выбирать допустимую команду. Для инженера-менеджера такой переход особенно полезен в междисциплинарном проекте. Можно обсуждать, какая информация нужна каждому слою, какие воздействия он вправе и способен выбирать и какие общие ограничения должны сохраняться при его работе. В техническом проекте эти вопросы приводят к моделям динамики и расчётам. В организационном — к распределению обязательств, ресурсов и полномочий, для которых тоже можно проверять сроки и совместную выполнимость. Общая методология позволяет удерживать один тип мышления по поводу управления при переходе между специальностями. Что общего в управлении системами разной природы Между системами разной природы переносится общая методология управления, опирающаяся на общую онтологию: описание управления идёт в терминах различений, наблюдений (измерений), действий, "последних полезных моментов" и т.д., а вот сама функция управления при этом остаётся предметно-зависимой. В биологии, например, речь идёт о сигналах управления, позволяющих скорректировать точное скоростное движение. В технике — о пригодности измерения для выбора момента и силы действия. В компании — успеет ли информация о срыве поставки попасть к тому, кто вправе договариваться об обязательствах. Во всех этих случаях есть доступная информация о ситуации, эта ситуация будет изменяться, и для коррекции (управляющего воздействия) есть некоторое временнОе окно. Никто не путает мышцы и нервы с моторами и контроллерами, моторы и контроллеры с подразделениями и правлением компании. Разговор ведётся на более высоком уровне абстракции, но потом идёт заземление на конкретную архитектуру. В любом случае в архитектурном проектировании систем управления можно говорить о проектах реверс-инженерии действующей архитектуры (исследование, например, в биологии), можно предложить другую архитектуру системы управления (скажем, поменять интерфейс, предложить другой датчик), можно как-то обосновать достижимость конкретного свойства, вроде времени реакции на изменения или соблюдения ограничения, устойчивости той или иной архитектуры управления, реализованной на той или иной элементной базе (провести анализ предложенной архитектуры ещё на стадии архитектурного проекта, до изготовления системы управления). У этой общности есть точная опора в FPF Core. Паттерн C.32.LCA описывает общий метод построения и сравнения архитектур управления, включая организационные ситуации. C.30.LCA помогает описать отношения управления. CAD DPF опирается на эти онтологические и методологические основания и предлагает уже более конкретные инженерные идеи, включая методы количественных расчётов динамических моделей для многослойных архитектур. Общая идея многослойной архитектуры управления получает строгие частные реализации, при этом в CAD DPF прописаны связи с другими областями знаний -- архитектурой как таковой, системной инженерией, математическим моделированием и т.д. Формулу границы ошибки линейного регулятора нельзя переносить на холдинг заменой букв в формулах словом «распоряжение». Но какие сведения, полномочия, ресурсы и сроки совместно делают распоряжение исполнимым -- это вполне может быть отмоделировано. Математика CAD DPF общая для техники, биологии, компаний. Но надо внимательно следить, чтобы она применялась корректно. Архитектура определяет зависимости между слоями, а их число не так важно Разделение управления на слои должно следовать из зависимостей между решениями, принимаемыми на каждом из этих слоёв. Некоторые решения требуют немедленной реакции от среды, другие — более богатой информации и рассмотрения отдалённых последствий. Некоторые тесно влияют друг на друга; какие-то решения можно принимать локально, никому о них не сообщая, пока соблюдаются какие-то общие для всех слоёв условия -- но при несоблюдении этих условий придётся эти решения согласовывать. Выделение слоя полезно, если он позволяет получить результат, который трудно обеспечить одним решением одного слоя. Быстрая коррекция в одном слое управления может продолжаться, пока более длительный расчёт на другом слое уточняет план. Локальное решение одного слоя может использовать сведения, которые теряют ценность до передачи в центр как отдельный слой. Общая координация может удерживать соблюдение важного ограничения, невидимого отдельными участниками. Для выделения каких-то решений в отдельные слои могут быть разные основания, иногда и сочетание нескольких оснований. Так, в модели движения можно разделить подготовку маршрута и компенсацию текущего возмущения. В энергосистеме планирование и локальная реакция должны согласоваться с общей доступной мощностью. В холдинге предприятия могут самостоятельно выбирать часть действий, пока их совместные обязательства помещаются в финансовые и производственные возможности группы. В каждом случае нужно показать, какую зависимость сохраняет соединение частей, какие характеристики удерживаются в приемлемых значениях. Если два подразделения независимо обещали заказчикам работу одного специалиста в одно и то же время, каждое могло принять разумное решение по своему плану. Общая архитектура не сохранила ограничение на занятость специалиста. Возможны разные решения: совместное планирование, заранее выделенные интервалы, запрос и подтверждение ресурса, изменение технологии работы. Аналогичные проблемы и похожие варианты архитектуры могут быть у двух устройств, использующих общий источник энергии. Функциональный слой архитектуры управления не равен административному уровню, физической детали или масштабу объекта. Один человек как "модуль" может оценивать состояние, планировать и выполнять коррекцию. Один процессор может исполнять вычисления для нескольких слоёв архитектуры управления. Работу одного слоя управления могут совместно делать несколько систем как конструктивных единиц. Чтобы увидеть слой, нужно понять метод его работы и отношения с другими слоями, и только затем можно разбираться с исполнителями работы по этим методам -- исполнители вместе должны иметь возможности (capabilities: умения и ресурсы, а также полномочия) выполнить работы по этим методам. Три этажа структуры холдинга не становятся многослойной архитектурой управления, CAD DPF не про структуры модулей и интерфейсов систем управления. Прагматика слоёной архитектуры: информация нужна для выбора действия Рассмотрим архитектуру, в которой разделены медленное планирование и быстрая коррекция поведения. Для слоя быстрой коррекции нужны сведения о текущем отклонении от требуемого поведения: насколько изменилась скорость, упало напряжение, отстало выполнение производственного задания. Слою планирования нужны сведения, позволяющие выбрать дальнейший ход работы: маршрут движения, режим энергосистемы, распределение заказов по производственным площадкам. Информация полезна в силу управляющего действия, которое с её помощью удастся выбрать и вовремя выполнить. Отсюда в архитектуре появляются требования к точности измерений, срокам подготовки отчётов и памяти о прошлых действиях. Состояние управляемой системы приходится оценивать по доступным сведениям. Точное и быстрое измерение описывает состояние только в момент самого измерения, а к моменту выбора управляющей команды система уже могла измениться. Поэтому система управления использует модель, дающую поправку на эти изменения: учитывает прошедшее с момента замера время, фактически выполненные действия, команды, ещё ожидающие исполнения, и их ожидаемые последствия. Выданная исполнителю команда может быть задержана, ограничена исполнительным механизмом или не исполнена. Если очередь исполнения известна, её можно включить в модель состояния, а если неизветна -- расхождение остаётся частью неопределённости. Получается и оценка нынешнего состояния, и оценка того, насколько это состояние может отличаться от реальности. В CAD.5 рассматривается, какие наблюдения и какая память позволяют получить информацию, достаточную для следующего управляющего действия. В модели управления движением сведения о собственном воздействии на моторы позволяют учесть изменение положения ещё до получения нового сигнала от датчика. В управлении компанией такую же архитектурную работу можно увидеть в учёте принятых заказов. Во вчерашнем отчёте была свободная производственная мощность на следующую неделю, но после подготовки отчёта часть этой мощности уже пообещали заказчикам. Слой, распределяющий новые заказы, должен учитывать эти обещания сразу. Ждать следующего отчёта о фактической загрузке производства здесь слишком долго: один и тот же ресурс успеют продать несколько раз. Это и есть "внутренние обратные связи" между слоями, основное отличие от кибернетической обратной связи от среды. При этом feedback часто на русском рекомендуют переводить как "отклик", ибо "обратная связь" менее точно определяет происходящее: слои системы управления дают информацию и получают отклики друг друга, а не только дают воздействия и получают информацию с датчиков от окружающей среды. Ситуации в биологии, киберфизических системах, предприятиях архитектуры управления описывают одинаково, тут общее мышление. Верхние слои системы управления получают информацию о выданных нижними слоями командах, принятых нижними слоями обязательствах, других выполненных действиях -- и используют их для следующего расчёта. Состояние окружающей среды получим замерами от датчиков. Сопоставляя текущие замеры с прогнозом, можно уточнять оценку состояния, а при выявленной непригодности модели — пересматривать способ прогнозирования. В биологическом исследовании нас интересует, каким сигналом и по какому пути передаются эти внутренние отклики и команды; в техническом проекте мы выбираем эти сигналы и пути; в компании устанавливаем, кто, когда и как узнаёт о принятом обязательстве -- всё то же самое, "сигналы о внутренних действиях, внешних замерах и пути их распространения". Общая архитектурная зависимость во всех трёх случаях одна: последующий выбор управляющего воздействия должен учитывать уже сделанное, "планирование от достигнутого", "управление на марже". Память нужна для сохранения тех различий между состояниями системы, от которых зависит дальнейшее управление. Например, одинаковое число незавершённых заказов может означать очень разную оставшуюся работу. Для планирования сроков нужны сведения об объёме этой работы и занятой ею мощности. Если отчёт сохраняет только количество заказов, слой планирования теряет информацию, которая определяет возможность принять следующий заказ. При проектировании архитектуры приходится выбирать, какие сведения сохранять и как обновлять их при поступлении новых наблюдений. CAD позволяет поставить этот вопрос строго: какие состояния системы совместимы с доступными наблюдениями и есть ли управляющее действие, допустимое во всех этих состояниях? Если такое действие есть, можно действовать и при неполном знании состояния. Если общего допустимого действия нет, то в рамках данной модели для гарантированного управления потребуется дополнительная информация либо изменение задаваемых ограничений. Точность датчика, подробность отчёта о выполнении и сам объём памяти подчиняются требованиям задачи управления. Иногда для решения этой задачи достаточно более грубого измерения или короткого отчёта о сделанном: они сохраняют все различия, влияющие на выбор очередных команд. Компоненты с разной скоростью и точностью в одной архитектуре У компонентов системы управления есть ограничения. Быстрый канал ограничен по пропускной способности и даст неполную информацию, а более точная оценка может требовать большого времени для её вычисления. При слоёной архитектуре эти особенности можно распределить между разными работами, требующими разного времени для работы по разным методам: быстро реагировать на уже возникшее небольшое отклонение от ожидаемого состояния и одновременно готовить будущие уточняющие действия по более подробной, но более медленно вычисляемой модели. Архитектор выбирает, какие датчики брать, какие каналы к ним использовать, каким слоям передавать их сигналы и внутренние сигналы от других слоёв, как согласовать полученные по разным каналам оценки состояния, как выдавать внешние команды и по каким каналам их будут получать какие эффекторы-актуаторы. В исследованиях Nakahira и коллег [4] разбираются сочетания разнородных компонентов, при которых управление получает полезное сочетание скорости и точности. В работах Li и коллег [3] исследуется другой связанный механизм: внутренние обратные связи позволяют учитывать собственные действия и прогнозируемые изменения при задержке внешних сигналов. В CAD.5 эти результаты обобщаются: разнообразие компонентов даёт разные возможности, а архитектура определяет, как эти возможности будут совместно использованы для достижения требуемого проектом сочетания точности, скорости и устойчивости управления для текущей элементной базы и окружающей среды, а также ресурсов проектирования. В компании, например, оперативное сообщение об остановке оборудования планировщику позволяет сразу скорректировать выдачу текущих производственных заданий на сутки. Более медленная оценка сроков ремонта после этой остановки нужна для пересмотра общего плана выпуска на какой-то длинный период -- неделю, а то и месяцы. Здесь можно выделить две работы с разными требованиями к информации и времени: ограничить поступление новых заданий на остановленное оборудование и перераспределить оставшиеся заказы на другое оборудование, чтобы соблюсти сроки работы (может быть, даже выдать команду на проведение переговоров с получателями продукции, чтобы предупредить их о проблемах). При проектировании управления нужно обеспечить согласование: к моменту подготовки нового плана работ учесть уже изменённую поломкой загрузку, а после утверждения плана ещё и быстро сообщить исполнителям, какие задания теперь действуют. Архитектор определяет, надо ли иметь для подобных случаев дополнительные каналы связи, дополнительные мощности для пересчёта планов, дополнительные слои системы управления -- или достаточно и текущих. В любом случае, это делается не интуитивно. CAD DPF говорит, что всё это можно посчитать, каким оно там должно быть, а не просто "предложить в надежде, что сработает". CAD показывает, какие зависимости можно рассчитать для выбранной модели и как по результатам расчёта сравнить варианты архитектуры. Выполнение расчётов можно поручать AI-агенту, но инженеру-менеджеру нужно понимать постановку задачи, ситуацию управления, а также смысл полученного результата рассчёта. Но главное -- понимать, что это в принципе считаемо, а не является результатом догадок. Когда планирование и быстрая коррекция заданий разделены, слой планирования должен передать слою коррекции выполнимое задание, а не произвольно выбранное. Для управления движением таким заданием может быть целевая координата или траектория — требуемое положение в каждый момент времени. Если передаётся траектория, слой коррекции сравнивает текущее положение с требуемым в данный момент и рассчитывает воздействие, уменьшающее отклонение. Но это только отработка отклонений, а вот траекторию этот слой коррекций получает с вышестоящего уровня управления. Нужно также определить, когда новое задание вступает в силу и что слой коррекции делает между обновлениями задания. Можно сохранять последнее заданное значение до следующего сообщения, можно продолжать переданную траекторию экстраполяцией, пока не придёт новое значение, можно вычислять какие-то промежуточные значения по согласованному правилу. Каждый способ задаёт свою динамику ошибки слежения — изменения разницы между требуемым и фактическим состояниями. В CAD.2 динамика ошибки выводится из выбранного взаимодействия слоёв и методов их работы, а затем по динамике ошибки в CAD.3 и CAD.4 рассчитываются допустимые задания на управление и проверяются характеристики всего управления в целом. В компании, например, можно разделить помесячное планирование выпуска и оперативное ежедневное управление производством. Слой планирования получает помесячный прогноз продаж, проверяет доступную мощность и готовит производственные задания. Слой оперативного управления (операционного менеджмента) распределяет текущую работу по оборудованию и корректирует её при отклонениях. Утверждённое задание сообщает ему, какой выпуск и к какому сроку требуется обеспечить; сообщение о недоступности оборудования возвращается в слой планирования для пересмотра заданий. При этом предварительный расчёт возможного объёма выпуска за период и принятое обязательство по поставке имеют разный смысл: для обязательства уже должны быть согласованы ресурсы и срок, для предварительного объема выпуска ещё можно поуправлять и ресурсами, и сроком. Сбыт должен получать сведения о том, какая поставка подтверждена производством и что можно обещать клиенту, производство должно получать сведения о том, что уже обещано. Обмен между слоями включает и сведения об ограничениях исполнения. При планировании движения нужно учитывать, какую скорость изменения команды допускает исполнительный механизм и какое усилие он способен развить. При планировании выпуска — доступную мощность оборудования, уже занятые интервалы работы и полномочия того, кто принимает задание. Часть ограничений известна заранее и включается в модель планирования. Об изменениях, например о выходе оборудования из строя, слой планирования должен узнавать достаточно рано, чтобы подготовить исполнимое задание. Для реверс-инженерии биологического управления в клетке, органе, организме здесь возникает исследовательский вопрос: что передаваемый между частями системы сигнал меняет в подготовке или исполнении действия? Предположение о том, что сигнал передаёт прогноз, можно проверять по тому, как изменится поведение при изменении этого сигнала. Так от наблюдаемой связи между частями организма переходят к гипотезе о методе их совместной работы. В техническом и организационном проекте тот же вопрос задаётся чаще не как исследовательский вопрос, а как вопрос проектирования: какую работу позволит выполнить получателю каждое сообщение между проектируемыми слоями системы управления? Частота работы слоёв, задержки и горизонт планирования выбираются вместе Время входит в архитектуру несколькими способами. Период обновления каждого слоя (они работают циклически, смотри DPF ритмики -- там объясняется, что акцентов не должны непроизвольно тяготеть к долям основного ритма, а доли основного ритма не должны сбиваться акцентами) показывает, как часто слой заново рассчитывает команду или план. Задержка показывает, сколько времени проходит от события до получения и использования информации о нём. Горизонт планирования показывает, насколько далеко вперёд рассматриваются последствия возможных действий. Например, производственный план может пересчитываться раз в сутки, использовать сведения двухчасовой давности и охватывать следующую неделю. Все три характеристики влияют на управление, каждая своим способом. Слой быстрой коррекции получает смысл там, где ждать нового плана слишком долго. Пока слой планирования рассчитывает маршрут или распределение производственных заданий, слой коррекции продолжает компенсировать текущие отклонения в пределах уже выданного задания. Для такого разделения нужно установить, какие изменения нижний слой может обработать самостоятельно и при каких изменениях требуется пересчёт плана. Тогда частоты работы слоёв выбираются по скорости изменений управляемой системы и времени, необходимому для расчёта и исполнения команд. Полное время реакции складывается из обнаружения изменения, передачи сведений, выбора управляющего действия и его исполнения. В организации сюда входит и ожидание разрешения: специалист может уже знать, как восстановить поставку, но ещё не иметь права заказать перевозку другим способом. В технической системе таким же образом учитывается ожидание доступа к вычислительному ресурсу. Архитектуру проверяют по тому, успеет ли вся необходимая работа завершиться до момента, после которого повлиять на результат уже невозможно. Общий ресурс может задержать работу нескольких слоёв. Если два расчёта требуют по десять минут одного процессора и оба должны завершиться через пятнадцать минут, двадцать минут вычислений в этот срок не помещаются. При проектировании придётся изменить способ расчёта, вычислительные ресурсы или требование к сроку. Аналогично можно анализировать загрузку специалиста, который должен последовательно согласовать два срочных изменения производственного плана. Для архитектурного выбора существенно, где именно теряется время. Аналитическая система может готовить отчёт за секунду, а разрешение изменить работу будет ждать директора до понедельника. Ускорение подготовки отчёта почти не изменит срок восстановления работы. Здесь надо рассмотреть распределение полномочий и заранее разрешённые способы реакции. В другом проекте полномочий достаточно, но опаздывает измерение — тогда менять придётся канал наблюдения или способ прогнозирования состояния. Зависимость общая: каждый слой должен получить возможность выполнить свою работу до того, как её результат понадобится следующему слою или управляемой системе. В системе Helix 02 [5] для управления антропоморфным роботом Figure используются три слоя: System 0 выдаёт команды исполнительным механизмам с частотой 1 кГц, System 1 формирует целевые положения суставов всего тела с частотой 200 Гц, а System 2 задаёт семантические цели и последовательности поведения (частота в этой версии не указана, но в прошлой версии аналогичный слой работал на 20 Гц). Продолжение в https://ailev.livejournal.com/1815160.html