January 21st, 2012

2019

Курс "Введение в системную инженерию"

Традиционно "Введение в системную инженерию" (Foundations of systems engineering) читается как быстрый проход по типовому жизненному циклу, чтобы потом медленно и глубоко прорабатывать отдельные практики с пониманием их контекста -- застревать на специфических методах инженерии требований, инженерии системной архитектуры и т.д., понимая при этом, что в ходе жизненного цикла системы еще много чего происходит. Обычно это 3 "кредита" (порядка 48 учебных часов, не считая самостоятельной работы дома), но на производстве часто ограничиваются посылкой инженеров на пятидневные курсы (примерно 2 "кредита").

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

1. Дисциплина системной инженерии и роль системного инженера.
Дисциплина системной инженерии, ее отличия от инженерии по специальностям и инженерного менеджмента. Роль системного инженера, отличия системного инженера от проектного менеджера и инженеров по специальностям. Связь и отличия системной инженерии и программной инженерии, инженерии и исследований.

2. Понятие системы.
Системный подход. Понятие системы. Целевые и обеспечивающие системы, системы в эксплуатационной среде. Заинтересованные стороны. Функция, конструкция, механизм, архитектура, модульность системы. Холархии.

3. Понятие жизненного цикла.
Понятие жизненного цикла. Типовость (уровни воплощения) и разнообразие жизненных циклов, связь жизненнных циклов разных уровней структуры вещества в составе системы. Основные формализмы представления жизненного цикла. Виды жизненных циклов: последовательный, инкрементальный, итерационный. Пошаговое выделение ресурсов (ICM).

4. Стандарты системной инженерии.
Стандартизация как методологическая и онтологическая работа. Краткая характеристика ISO 15288 (практики жизненного цикла системной инженерии), ISO 42010 (архитектурное описание), ISO 24744 (описание методов разработки), OMG ArchiMate (архитектурный язык для предприятий). Справочные данные, основанные на инженерных стандартах (онтологическая интеграция данных жизненного цикла в технологии ISO 15926).

5. Моделеориентированная системная инженерия.
Описания и модели систем. Устранение коллизий (обоснования, интеграция данных) и порождающее («автоматическая разработка», трансформация моделей) проектирование и изготовление. Управление конфигурацией и изменениями. Модель продукта и модель организации. Документоцентрические и датацентрические архитектуры современных САПР и СУЖЦ. Инженерные онтологии.

6. Практики определения системы.
Инженерия требований, работа инженера по требованиям. Инженерия системной архитектуры, работа системного архитектора. Описания требований и архитектурные описания.

7. Практики воплощения системы.
«Вынос в реальность». Системная интеграция. Верификация и валидация, инженерные обоснования. Переход к эксплуатации.

8. Системы систем. Организационная инженерия.
Подход системы систем. Организация как система. Расширенное предприятие, «эко-система». Организационная архитектура. Ситуационная инженерия методов. Управление проектами, процессами, кейсами.

9. Инженерный менеджмент
Инженерный менеджмент. Управление технологиями и дилемма инноватора. Освоение практик системной инженерии в организации. Стратегия и стратегирование.

Литература
1. Материалы заседаний Русского отделения INCOSE (http://incose-ru.livejournal.com/).
2. Стандарты ISO 15288, ISO 42010, ISO 24744, OMG ArchiMate (на английском языке и переводы).
3. В.К.Батоврин, Системная и программная инженерия. Словарь-справочник. ДМК-Пресс, 2010.
2. BKCASE Guide to the Systems Engineering Body of Knowledge (SEBoK v.05, 2011) -- http://www.sebokwiki.org/index.php/Guide_to_the_Systems_Engineering_Body_of_Knowledge_%28SEBoK%29_v._0.5
3. NASA Systems Engineering Handbook, 2007 -- http://education.ksc.nasa.gov/esmdspacegrant/Documents/NASA%20SP-2007-6105%20Rev%201%20Final%2031Dec2007.pdf
4. MITRE Systems Engineering Guide, 2011 -- http://www.mitre.org/work/systems_engineering/guide/index.html
5. SEVOCAB: Software and Systems Engineering Vocabulary -- http://pascal.computer.org/sev_display/index.action

У меня в блоге было за последние четыре года огромное количество обзорных материалов по темам этого курса, а в этих обзорах ссылки на литературу для углублённого самостоятельного изучения. Электронные версии западных учебников системной инженерии на всяких library.info находятся в изобилии.
2019

Онтологическая инженерия в помощь системной инженерии

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

2. Онтологическая инженерия помогает создавать формальные языки описания инженерного метода, и тем самым формализует порождение инженерного процесса. Это позволяет говорить не только о generative design, но и generative manufacturing.

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

4. Непосредственное использование инженерной онтологии в качестве модели данных PLM-систем, ибо требуется в рамках общей картины мира объединить частные онтики специальных инженерий. Это накладывает дополнительные требования к формальности выражения онтологии с одной стороны плюс не даёт успокоиться частными решениями, особо пригодными для конкретных предметных областей и полностью неприемлемых для других предметных областей. Кроме "атрибутного моделирования" тут требуется еще развитое представление геометрии с мереотопологией, работы с данными реального времени (для мультифизического моделирования), представление трансформаций, моделирование работы с кейсами, моделирование работы с причинностью (трассировки), моделирование отношений "мета" (порождение артефактов согласно правилам), адекватное моделирование модальностей и возможных миров (проектные альтернативы), моделирование программного обеспечения (кибер-физические системы), моделирование инженерного процесса (человеческой деятельности). Суть данного пункта даже не в том, что адекватного подхода нет в рамках отдельных инженерных онтологий (а хоть и онтологии софта!), а в том, что нужна объемлющая для всех этих частных онтик онтология -- куда можно "заземлить" и софт, и человеческую деятельность, и модели сопротивления материалов.

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

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

7. Онтологическое знание и онтологический метод в его нынешнем варианте основано на простейших логиках, а вот инженерное знание и инженерный метод основан на эвристиках (то есть нетрадиционных логиках). То есть в самой своей сути наличествует логическая неадекватность современной онтологической инженерии используемому "железной инженерией" подходу. Плюс сам набор эвристик непрерывно меняется (но тут уж см. пункт 6).

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

9. Сама системная инженерия как метод представляет собой что-то невнятное: то есть речь не идёт о том, чтобы адекватно выразить основные ее понятия (они, скорее, сводятся к понятиям системного подхода -- и тут всё ОК), сколько выразить то общее, что есть в практиках различных системных инженеров. И тут выясняется, что нет никакого согласованного сообществом системных инженеров мнения о том, что является такими практиками -- дальними подступами тут является стандарт ISO 15288, но с уходом от документ-ориентированной системной инженерии он стремительно теряет адекватность. Более того, опыт системной инженерии Boeing и NASA (классика жанра) широко известен, но больше хотелось бы услышать об опыте системной инженерии в проектах частного космоса, производителей смартфонов, работах по возведению промышленных зданий Broad Group: именно эти проекты указывают на уникальный опыт, и именно используемые в этих проектах онтики (или, если свезёт их обнаружить, онтологии) хорошо было бы использовать для создания контринтуитивной онтологии системной инженерии, и именно эту онтологию нужно было бы закреплять в схемах данных современных PLM.

Если подытожить, то можно себе представить Systems Engineering Service Smart Bus (можно назвать это также Единым Информационным Пространством инжениринговой фирмы, или PLM нового поколения), которая как фикус в кадке сидит в горшке с наличным инженерным знанием (справочными данными -- регулированием, каталогами оборудования, стандартами и нормативами), а кроной-листочками взаимодействует с самыми разными агентами-авторами (которые даны в виде интерфейсов авторских систем). Эта Systems Engineering Service Smart Bus способна выполнять интеллектуальные запросы с их маршрутизацией или к наличным знаниям, или к отдельным авторам, а также способна интеграцию данных и интеграцию workflow крупного инженерного проекта. Это абсолютно системноинженерная система, ибо вся специальная инженерия уходит в авторские системы, а системноинжерное мультидисциплинарное онтологическое (в отличие от опирающихся на онтики специальных авторских систем) ядро "держит целое".

И любые крохотные шажочки в выполнении описанной в данном постинге исследовательской программы в области онтологической инженерии приведут к драматическим улучшениям в возможностях и принципиальной реализуемости этой Systems Engineering Service Smart Bus.
2019

Импульсный радар Novelda как еще один датчик+спецпроцессор

Импульсный радар на микросхеме, по моему мнению, мог бы привести к похожим на "кинект-эффект" последствиям, если бы его довести до ума: http://www.novelda.no/ (спасибо lseder за наводку). Он меряет и движения (например, засекает дыхание -- в том числе за непрозрачными стенками). Всё это очень свеженькое, пара антенн для этой микросхемы была заявлена только в октябре 2011 (три месяца назад) -- а это ведь всё одно, что объективы к тушке фотоаппарата.

Дальше весь вопрос в цене. Майкрософт свой Кинект (который можно считать одновременно development kit и конечным устройством) продавала не слишком задорого, и огромное количество народу смогло с ним поэкспериментировать. Поскольку Novelda поступает как Qualcomm ("мы поставляем компоненты, а вы разрабатывайте из них конечные устройства сами"), то партнёры тут являются определяющими. Если честно, то меня несколько озадачил выбор первого готового устройства -- датчика глубины снежного покрова (от 15см до 2 метров, точность 3.5см -- http://www.flatearthinc.com/index_files/Page434.htm). Будем надеяться, что дальше дела пойдут лучше.

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