Для понимания модульности критичны понятия компонуемости (composability) и композициональности (сompositionality), например их особо оговаривают в CPS PWG Cyber-Physical Systems (CPS) Framework https://pages.nist.gov/cpspwg/ для киберфизических систем. Увы, поздно подбирать русскоязычные переводы этих слов, электронные переводчики их знают. Можно только запомнить мнемонику, чтоДля коллаборативного робота главное -- это безопасность, он должен уметь работать без заборчика вокруг него, останавливаясь при встрече любого препятствия или обходя его. Для этого робота комплектуют хитрой системой управления, которая и заданные движения может повторять, и останавливаться вовремя.
-- компонуемость (composability) -- это про возможность сложить целую систему из частей-подсистем. Модульный аспект сборки, компоновки, создания холархии: интерфейсы воткнутся друг во друга, целая система, собранная из подсистем, заработает. Обратите внимание, что "выращиваемые" системы не компонуемы! Их не соберёшь из частей, и хотя в них тоже присутствует холархия, нельзя сказать, что на неё как-то существенно можно влиять, отдельные модули не взаимозаменяемы путём подключения к известному интерфейсу, требуются разные "врастания".
-- композициональность (compositionality) требует некоторого "композиторства" -- речь идёт о свойстве собранного из частей целого обходиться без неожиданной эмерджентности типа отрицательных побочных эффектов. Система композициональна по какому-то свойству, когда её это свойство напрямую трассируется к свойству отдельных модулей. Это хитрое антисистемное понятие, потому как целая композициональная система в отношении какого-то свойства не больше суммы своих частей, а равна сумме своих частей! Композициональная система имеет какое-то свойство, если её модули имеют это свойство, поэтому для композициональной системы простая сборка её из обладающих каким-то свойством модулей будет означать доказательство того, что вся система обладает этим свойством. Если модули системы критичны к работе во времени и требуется их синхронизация, то создать систему, синхронно работающую "в силу конструкции", обычно нельзя. Так что свойства с плохой композициональностью обычно попадают в список интересов стейкхолдеров отдельными пунктами и в проектах им уделяется много внимания.
Беда в том, что поставщики коллаборативных роботов не могут укомплектовать их особыми инструментами ("кистями"), которые будут крутить отвёртки, распылять краску, сверлить дырки, передвигать предметы, заглядывать в дырочки и что-то там замерять, сваривать и т.д.. Каждый такой инструмент может потребовать особого управления. Например, сварной инструмент нужно немного двигать под контролем видеокамеры, чтобы шов был равномерный. Это означает, что одновременно работают две системы позиционирования: родная коллаборативного робота и чужая сварочная. При этом робот, безусловно, должен уметь сохранять все свойства коллаборативности и все свойства специальности. По факту, робот представляет собой механо-электронную платформу, с которой могут поставляться разные системы управления, и лучше бы одна -- с ней робот сертифицируется на безопасность, ибо безопасна не железка с моторчиками, а робот в целом. Но на безопасность (остановки при появлении в рабочей зоне препятствия) нужно тогда сертифицировать в том числе с добавленной "специальной" системой, да ещё и с добавленным спецоборудованием захвата (сварка сама по себе может быть небезопасной).
Как бы сделать так, чтобы собранный из частей (базовой платформы со "спинным мозгом с безопасностью" и специнструментом с тонкими или даже грубыми настройками движений) робот был безопасным? Для этого нужно
а) сделать его компонуемым -- разделить на платформу манипулятора и специнструмент с добавками управления, это означает, что должен появиться стандарт интерфейса механического, электрического, управленческого, но также
б) сделать его композициональным, чтобы при сборке робота не требовалась его пересертификация -- чтобы безопасность сохранялась просто в силу сборки его из частей. Для этого нужно разработать такой алгоритм управления, который умеет и информацию выученного движения принять (база), и информацию от датчиков препятствий в рабочей зоне (обеспечение безопасности в базе) и и информацию от датчиков инструмента (камеры для контроля сварного шва, например).
Это довольно хитрый получается API с хитрыми управленческими протоколами. И всей головной болью при смене версии софта базового робота при прежней версии софта предметной специализации.
Сегодня ситуация довольно печальна: робот в базовой комплектации никому не нужен, а робот со специнструментом получается доработкой базового робота задорого (вплоть до выдачи исходных алгоритмов базового робота авторам доработки -- так, программа доступа разработчиков специальных роботов на базе универсальных манипуляторов UR3, UR5, UR10 была открыта только в июне, и там пока только 10 разработчиков на годовую программу выпуска в 7тыс. роботов).
Я ожидаю, что поставщики "роботов" честно станут поставщиками "робототехнических платформ", на базе которых будут компоноваться (composability) предметноспецифические роботы-"профессионалы". При этом API у них будет стандартизован (я писал о стандартизации в робототехнике очень давно, и эти стандарты будут, никуда не денутся -- вот обзорчик двухлетней давности: http://ailev.livejournal.com/1103887.html), но в 2016 году я добавляю к этим стандартам ещё одно важное свойство. Они должны не просто поддерживать модульность, как я писал в 2014, но оба её свойства -- и компонуемость, и композициональность. И если первое (сделать, чтобы было как Лего -- всё во всё втыкалось и легко собиралось) легко, то со вторым (чтобы из сертифицированных на безопасность платформ и использующих эти платформы частей получался безопасный робот) придётся помучиться.