February 6th, 2013

2019

lytdybr

В воскресенье пойду на робототехническую конференцию, поэтому полдня пытался разобраться, что происходит в современной робототехнике прямо сейчас. Самое простое для этого -- начинать с http://www.willowgarage.com/blog и поглядеть на условия соревнования http://mobilemanipulationchallenge.org/. Очень интересно, что в робототехнике (почему-то слово "роботика" в русском практически не используется) растёт число специализированных информационных форматов, разных вариантов XML. Через некоторое время они там все взвоют, ибо форматы не резиновые, и передать всё нужное ни один из них не сможет. Первым делом стандартизуется информация о конфигурации робота -- там всё то же самое, что для любого оборудования, включая геометрию и некоторое количество именно робототехнической специфики. Ну, нам хорошо известен как минимум один "резиновый" стандарт для упихивания в один файл нейтрального формата всей нужной для разных ситуаций информации...

Поизучал GitHub -- штука сложная и могучая, кроме собственно навороченного репозитория там ведь есть issue tracker, вики, генератор страниц вебсайта, работа с пользователями, Service Hooks API и много всего разного. Три миллиона пользователей. Много инноваций, вплоть до поддержки пайплайна удалённой распечатки на 3D принтере. И платная версия, разворачивающаяся на виртуальной машине за корпоративным файерволом (каждые полные или неполные 20 пользователей -- $5000 в год, это $21 за пользователя в месяц. Дорого? Тогда доверяйте github.com, как все, и уговорите службу безопасности своего предприятия).

Пописал "в стол". Увы, отнюдь не всё из мной написанного попадает клиентам или публикуется в блоге или комьюнити. Более того, чем интереснее те мысли, которые приходят мне в голову, тем более вероятно, что я пару-тройку раз перед записью, например, в блог, напишу чего-то "в стол". Вот и сегодня написал.

На выходных вынес ещё полкубометра старой аппаратуры и проводов. И запланировал ещё полкубометра на очередные выходные. Дитятко удивил: выхватил древний плеер Duna (одна из самых моих неудачных гаджет-покупок) и аккуратно развинтил на мелкие детальки. Вообще-то это он первый раз такое сделал, я всё удивлялся, почему у него нет никакой страсти чего-нибудь из аппаратуры разломать, чтобы посмотреть, как оно там устроено. Я бы на его месте вёл себя совсем по-другому, в его возрасте я твёрдо знал, что поступлю в радиотехнический институт, активно рыскал по окрестностям, находил и разматывал горелые трансформаторы (их почему-то всегда вокруг было изобилие), разламывал какие-то шасси каких-то старых приёмников и усилителей. Нет, сыну это не передалось. Впрочем, судя по этой ВНЕЗАПНО развинченной Дюне, это ещё не конец истории.

Три часа вчера обсуждали возможности для создания качественного открытого онлайн-курса "Введение в системную инженерию". Увы, системная инженерия, как она сейчас есть, больше напоминает humanities (т.е. литературу, театр, живопись, философию, историю и прочие предметы, где передаются "субъективные восприятия"), чем физику, химию или любые другие предметы, в которых можно решать задачи в рамках какого-то формализма. Так что все проблемы hunanities в MOOC -- это будут проблемы курса системной инженерии. Это означает, что без обеспечивающего работу группы тьютора ничему научить не удастся: онлайн-курс будет просто супер-пупер учебником, не более. Я сам считаю, что MBSE, плавно переходящая в MDSE, если к ней добавить настоящий "системный" язык, позволит эту самую системную инженерию перевести в существенной мере в разряд тренируемых в онлайне, но это я уже сильно забегаю в те темы, на которые я писал сегодня в стол.

Как-то быстро в Сети меняются темы для обсуждений. Пару дней подряд все плевались на православную церковь, а сегодня по этому поводу уже тишина -- но обсуждаемые вопросы-то никуда не делись! Вообще, у всех этих взбесившихся крестов и принтеров очень хорошая стратегия уходить от глубокого общественного обсуждения: выдавать один повод за другим, один круче другого. Депардьирование в Мордовии, затем больница для судей, затем православие отакуе, затем геи в ассортименте, затем город имени рябого, затем... -- всегда есть на что переключиться, не дадут соскучиться. Ну, общественное внимание, конечно, переключается -- куда ж деться! Выдаётся очередной опус симфонии властей и церкви, затем пара суток на высказывания общественности, затем цикл повторяется -- а кто не успел поучаствовать в этой двухсуточной какофонии народа, тот опоздал. А в целом же ничего не происходит, кроме смены поводов с одного безобразного на другой ещё более безобразный. Вот никак не понимаю, что было бы осмысленно делать в такой ситуации (если, конечно, не делать ноги. Но я бы предпочёл всё-таки делать что-то другое, полезное не только мне и близким, но и чуть бОльшему числу людей).
2019

Язык системного моделирования

Меня включили в некоторую весьма специфическую частную переписку по поводу MBSE, аргументы сторон этой переписки были примерно следующие:
-- ничего "системного" в вашей MBSE нет, только обрывки. Какое-то моделирование систем было и раньше, та же системная динамика. Системного языка и системной инженерии вы не развиваете, это всё языки описания систем и развитие инженерии систем -- к системной инженерии и системному подходу это отношения не имеет. В SysML систем нет. SysML и Modelica про "моделирование систем", а не про "системное моделирование". Мозги с хорошо поставленным системным мышлением ваше моделирование не поддержит, а только отразит бледным светом уже принятые без подобного моделирования уникальные инженерные решения.
-- наоборот, это у вас не системная инженерия, а системные humanities (искусства, истории, философия и прочие байки с иллюстрациями), сплошное blah-blah-blah. Пока не будет формальных методов, не будет инженерии. То есть у вас не системная инженерия, а системные humanities. А у нас хоть и не системные, но модельки, и мы вдесятеро быстрее работаем часто на тех же задачах, ибо с blah-blah-blah переходим на прямые вычисления или логический вывод.

Ужас ситуации в том, что правы обе стороны: MBSE сегодняшнее это про "моделирование систем" и точно не "системное моделирование", а классическая системная инженерия -- это humanities, формальных общепринятых средств выражения для основного своего понятия ("система") нет.

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

Тут нужно также помянуть про трудности верхнеуровневого моделирования (неочевидность полезности моделирования в его текущем виде, неудержание целостности на этом верхнем уровне, отсутствие моделера, непонятность моделей ключевым стейкхолдерам, отсутствие практик коллективного моделирования, отсутствие практики накопления знаний моделирования, хотя бы в форме библиотек -- подробнее в http://ailev.livejournal.com/1056723.html).

На мой взгляд, ситуацию решит в формальный язык системного моделирования, который:

1. будет основан в том числе на логицистской линии введения формальности в предмет (подробнее в http://ailev.livejournal.com/1059168.html), и не будет зациклен исключительно на матане и матстатистике. Формализация -- это про формальные рассуждения прежде всего, и только во вторую очередь про квантификацию.

2. будет содержать "из коробки" понятие системы (в том числе модуля, жизненного цикла и т.д.) во всём его разнообразии (подробнее в докладе "О понятии системы в системной инженерии" http://ailev.livejournal.com/1056311.html), что требует и особого представления времени (а именно, 4D), и поддержки экстенсионализма (для совмещения функциональных и физических объектов), и много других онтологических выборов.

3. будет содержать вариант Upper Ontology, чтобы задавать общую картину мира для всех мэппящихся затем к системным моделям предметным моделям (это означает, что онтологических выборов, определяемых по пункту 2 -- много больше. Там и мереология, и что такое информация, и что такое модель, и как выражать единицы измерения, и много-много разного другого).

4. будет основан на факт-ориентированной парадигме, а не программистской объект-ориентированной (чтобы избежать ситуации "что для одного проекта объект, то для другого атрибут, и наоборот"

5. будет поддерживать минимально следующие синтаксисы:
-- абстрактный (т.е. формально определять концепты -- т.е. при полном отсутствии определения любых объектов в связи с какими-то характеристиками нотации/презентации), но с сериализацией (чтобы иметь возможность передачи моделей из одного моделера в другой) для абстрактной модели
-- текстовый (чтобы иметь возможность работать с большими моделями)
-- графический (чтобы быть максимально выразительным на маленьких модельках, т.е. для презентационных целей)

6. будет иметь штатные возможности расширения (т.е. поддерживать модульность в самом языке -- можно вспомнить про "онтолеты" или "моделеты", использование паттернов для формулирования DSL, поддержку библиотек как в той же Modelica, или поддержку библиотек паттернов моделирования, позволять метаописание других уровней языка, если в этом возникает необходимость -- это прямая отсылка к дискуссии о DSL, повторение рассуждений, которые привели к созданию MOF -- http://ailev.livejournal.com/1053878.html). Тут пока целина непахана.

7. обеспечит формальность (т.е. будет иметь формально проверяемую непротиворечивость и безошибочность моделей), но при этом не требуется decidability (приемлемого времени логического вывода). Это означает, что совсем необязательно использовать какие-то подмножества классических логик первого порядка, или даже полный вариант FOL. Вполне возможны варианты современных логик, в том числе логик высокого порядка. Это очень спорные требования, но на эту тему есть обширная дискуссия, и это осознанный дизайн-выбор.

8. будет поддерживать "из коробки" стык с численными моделями (например, модели могут обсчитываться, как модели на Modelica -- но при этом структурирование модели делается стандартными возможностями языка по описанию систем. Это примерно та же линия рассуждений, которая заставляет людей из комьюнити SysML думать о связке с Modelica. Но Modelica -- это совсем-совсем другой синтаксис, плюс объект-ориентированность, так что нужно "переизобрести" моделику, сделать её по-настоящему встроенной в язык системного моделирования). Как именно поддерживать стык с численными моделями нужно подглядывать у Simantics (http://simantics.org).

9. Поскольку будет "из коробки" понятие модуля/подсистемы, то возможно и встраивание constraints для них (это может быть выходом на contract-based design и другие методы оптимизации дизайна, подробнее в http://incose-ru.livejournal.com/31890.html).

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

11. будет понятно выражать информацию не только о самой целевой системе и её операционном окружении, но и информацию об обеспечивающей системе, задающей жизненный цикл системы (например, развивая линию OMG Essence -- http://ailev.livejournal.com/1051048.html).

12. Будет поддержан современным моделером (т.е. язык без реализации его -- это не язык, а хотелка, упражнение в фантазии), подробнее про критерии современности моделера -- http://ailev.livejournal.com/1041274.html

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

MBSE сможет перейти в MDSE (http://ailev.livejournal.com/1015692.html), т.е. от поглядывания на свои модели как вспомогательные, хотя и крайне полезные артефакты, системный инженер будет использовать менее детальные и более асбтрактные модели как основные свои выходные рабочие продукты, воплощающий результаты своего труда (сейчас этими воплощающими системное мышление результатами являются тонны самых разных полуформальных диаграмм, текстовых документов и верхние уровни предметных моделей). К этим моделям будет применим generative design и generative manufacturing подход, когда добавляя справочные данные, мы в диалоге получаем более детальные и менее абстрактные модели, доходя до предметных моделей, в том числе таких моделей, которые являются программами по изготовлению и сборке целевой системы.

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

С чего начать, если реализовывать такой проект?

С абстрактного синтаксиса и его сериализации, проверяя, как укладывается в него понятие "система". Для этой цели лучше всего подходит пока ISO 15926, но именно в части понятия "система" были исследования Мэтью Веста с его HQDM. Сериализация, хотя и не идеальная, есть в ISO 15926. HQDM, в принципе, имеет мэппинг в ISO 15926. Так что с этим вполне можно разобраться.

Затем нужен какой-то внешний синтаксис, позволяющий моделировать быстро, наглядно, и в больших количествах. Это может быть поначалу и текстовый синтаксис. Затем почти сразу потребуется графический синтаксис, и здесь нам может быть в помощь подход к диаграммам, предлагаемый книжкой BORO и какое-нибудь средство саморазводки типа тех, что используются в yEd (http://ailev.livejournal.com/1052859.html).

Потом нужно будет победить средства расширения языка и явно обеспечить его модульность.

В общем, двигаться нужно последовательно по каждому из указанных пунктов, и везде искать какие-то уже имеющиеся прототипы и частные решения, которые можно было бы взять в работу.
.
Собственно, какой-то начальный набор "системных" паттернов в ISO 15926 и поддержка в .15926 Editor внятной нотации для моделирования в этих "системных" паттернах спасли бы в части начальных экспериментов. Ибо в абстрактном синтаксисе и его деревянном отображении много не намоделируешь, а выразительность "родных" диаграмм оставляет желать (плюс это диаграммы Части 2, а с тех пор у нас появились и темплейты, и паттерны -- для них же ничего ещё не придумано), чтобы трудиться их реализовывать. Может быть, какой-то простейший текстовый синтаксис спасёт, а может быть и какие-то другие нотационные идеи.