September 26th, 2016

2019

Модульность коллаборативных роботов: компонуемость и композициональность

Робот -- это киберфизическая система, к ним в полной мере применим CPS Framework, в котором в том числе определяются интересы (concern) composability и compositionality (компонуемость и композициональность), я рассказывал о них в http://ailev.livejournal.com/1294242.html. Напомню:
Для понимания модульности критичны понятия компонуемости (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, но оба её свойства -- и компонуемость, и композициональность. И если первое (сделать, чтобы было как Лего -- всё во всё втыкалось и легко собиралось) легко, то со вторым (чтобы из сертифицированных на безопасность платформ и использующих эти платформы частей получался безопасный робот) придётся помучиться.
2019

Ошибки и как от них избавляться

Сегодня я сделал десяток демонстраций, когда висел слайд с типичными ошибками, и после их комментирования я задавал вопрос кому-то из магистрантов (в Красноярске интересные магистранты, например, директор завода там тоже магистрант, да и многие другие тоже пришли на эту программу за вторым высшим). При задании вопроса язык отвечающего абсолютно автоматически делает все эти типичные ошибки, к ужасу и радости всех присутствующих (пока не спросили этих присутствующих). Это одна из причин, по которой я против выкладывания материалов этих занятий в широкий доступ: после короткого тренинга ошибки уйдут, и нечего сохранять эти неловкие моменты для публики.

Типичный пример -- это упражнение "кто у вас был на прошлом совещании". Нужно назвать стейкхолдеров.

Напомню, что стейкхолдеры -- это роли. Деятельностно/культурно-обусловленные роли людей (и организованных их групп), исполнение которых как-то влияет на инженерный проект по созданию, эксплуатации и выводу из эксплуатации системы, или же на исполнение которых влияет такой проект. То есть стейхколдеры -- это Гамлеты и Буратины, а не старшие актёры, народные артисты или исполняющие эти роли в утренних спектаклях Васи Пупкины.

Слайд перечисляет наиболее типичные ошибки, когда называются:
-- Исполнитель, т.е. конкретный человек (ФИО или подразделение)
-- «ответственный» (должность, оргместо, позиция в штатном расписании)
-- Звание (учёная степень, воинское звание, категория мастерства)
-- Тип организации (там внутри много стейкхолдеров!)

Спрошенный человек вспоминает конкретных участников совещания, смотрит на слайд и... называет участников так, как привык, попадая практически в каждый ошибочный пункт. Ибо нет привычки к определению стейкхолдеров, но вот всех остальных определять приходилось. Те, кто за этим наблюдают, в гораздо лучшем положении. Они слышат какие-то слова и не представляют себе реальных людей, они эмоционально не вовлечены. Они радостно указывают незадачливому отвечальщику на его ошибки, они отличники на чужих задачах, но только пока не спросили их самих. В реальной живой ситуации собственного совещания, которое они представляют, они делают точно такие же ошибки -- почти все из предложенного списка. Напомню анекдот, почему в живых (ситуация, в которой вы сами участвовали -- живая, а чужая ситуация -- она вполне себе "из учебника", "схематичная", в ней в разы легче ориентироваться) ситуациях всё так трудно: http://cartmendum.livejournal.com/214886.html (заодно там говорится, почему участие в тренинге отличается от просмотра видео -- в видео нет живых ситуаций!).

Что с этой ошибочностью делать? Я много об этом писал, и в курс это встроено:

а) узнать, что есть правильные ответы, а есть ошибки. Признать, что в этом всём нужно как-то разбираться. Запомнить материал, уметь как-то пересказать, помнить что означают все эти новые незнакомые слова. Прочесть, наконец, учебник -- http://techinvestlab.ru/systems_engineering_thinking/ [и, конечно, делать ошибки -- "прочесть учебник" это даже не "уметь решать задачи"]

б) потренироваться в тепличных условиях, т.е. на сформулированных задачах. Напомню, что задач у нас там набирается на 18 часов решений. Задачи на стейкхолдеров там тоже есть. Это не даст возможности свободно распознавать стейкхолдеров в реальном мире (когда Иван Петрович ваш начальник, академик, и орёт на вас, брызгая слюной, вам даже после решения задач будет трудно вникать в предмет его ора, как-то обзывать Ивана Петровича "по науке", вычленять его интерес и точно на него отвечать. Вам бы выжить!). Но задачи позволяют хотя бы потренироваться в безопасной игрушечной обстановке, проконтролировать себя -- что вы вообще поняли изо всех объяснений. Вот первая задача из нашего набора (а вообще про стейкхолдеров сейчас 15 задач):
В Центре медицинских разработок города Нью-Васюки есть идея разработать новый прибор для диагностики рака. Каких стейкхолдеров было бы правильно учитывать в проекте?
-- Базовая больница N5 при Центре медицинских разработок города Нью-Васюки
-- Больница
-- Методический центр Министерства здравоохранения
-- Врач-онколог
-- Больной с подозрением на рак
-- Пациент отделения онкологии
-- Директор Центра медицинских разработок города Нью-Васюки
-- Программист Центра медицинских разработок города Нью-Васюки
-- Программист проекта
-- Онколог больницы N 5 Валентина Ивановна
в) начать смотреть на реальный мир, замечая в нём все эти вновь выученные концепты, под какими бы именами и модификациями они бы ни скрывались. То есть на каждом совещании аккуратно выполнять эту мыслительную операцию: из содержания речей (а не из названий должностей или внешнего вида, или ещё каких-нибудь признаков) выуживать догадку о том, какие у вас там стейкхолдеры, делать догадку о том, какие у этих стейкхолдеров интересы, а потом отвечать на эти интересы (даже когда о них явно не говорят). Рутинно, каждый день, из совещания в совещание. Нейронная сетка тренируется медленно. Когда это войдёт в привычку, то маленький кусочек системного мышления окажется вами освоен.

Кто у вас был на последнем совещании?