Category: армия

Category was added automatically. Read all entries about "армия".

2019

Цифровой -- это новый информационный, цифровая нить -- это новая интеграция данных

Цифровая трансформация, инженерия, модель, тень, нить и так далее
В языке медленно, но верно слово цифровой/digital заменяет слово информационный/information. Где лет десять назвали бы "информационный", сегодня называют "цифровой". Означает ли это хоть что-нибудь? Нет, ничего особенного, кроме как вы будете попадать в правильные строчки бюджетов, если будете следовать моде. Под "организационные изменения" и даже "организационную трансформацию", равно как и под "автоматизацию/компьютеризацию" деньги не дадут, а вот под "цифровую трансформацию" -- пожалуйста. Ещё объяснят, что это ж вы будете думать и о людях, и о компьютерах, и о бизнес-моделях, как будто это в голову не придёт при использовании более старых терминов для того же (подробней я писал об этом год назад в "Об цифровую трансформацию: то же оргразвитие, и даже не в профиль", https://ailev.livejournal.com/1497402.html, там был и слоган про "больше buzzwords богу buzzwords"). Но новых "цифровых" терминов в коропоративной цифре (раньше бы сказали "айти", но поддамся тренду) к началу 2021 года резко набежало, давайте с ними разберёмся.

Речь пойдет о digital transformation, digital engineering, digital engineer, digital twins, digital model, digital shadow, digital thread, SDM (simulation data management), model-based engineering, model-based systems engineering, digital mission engineering, и тут давайте пока остановимся (игнорируя всякие маркетинговые терминологические затеи одной фирмы, типа specification data management, который формулируется как "высокоуровневый PLM", https://specright.com/blog/specright/whats-the-difference-between-product-lifecycle-management-and-specification-data-management/).

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

С цифровыми двойниками мы разобрались ("Цифровые двойники: физика ведёт математику, математика ведёт компьютерную науку", https://ailev.livejournal.com/1549559.html). Цифровые двойники/digital twin -- информационные/цифровые модели aka виртуальные системы для киберфизических систем (реальных экземпляров hardware), существующие на всём протяжении их жизненного цикла, особенно включая эксплуатацию.

Если мы провалимся на системный уровень выше, то получим сеть цифровых двойников/digital twins network. Если провалимся на уровень ниже, то получим целый ряд моделей как по разным viewpoints на стадии эксплуатации, так и по жизненному циклу (все эти механические, электрические, тепловые и прочие модели).

Цифровая инженерия: делаем цифрового двойника и связываем его цифровой нитью
Цифровая нить/digital thread -- это технология (инструменты и практика федерирования-объединения-интеграции данных, обычно на основе так называемых семантических моделей данных/semantic data models, тысячи их), связывающая между собой все эти отдельные модели, а также цифровые двойники окружения и физического двойника. Инженер старой закалки скажет "интеграция данных жизненного цикла" и помянет множество PLM (а если это не машиностроение, то помянет "корпоративную шину данных"), менеджер новой закалки скажет "цифровая нить" и помянет PLM, ERP, EAM и даже CRM (и вообще всё остальное). И, поскольку "цифровой -- это новый информационный", то заметят, что для какого-нибудь здания или моста кроме BIM/building information model цифровая нить добавит к цифровому двойнику данные дронов, сенсоры интернета вещей и какой-нибудь искусственный интеллект обнаружения аномалий для ремонта по состоянию. А разве это не предусматривалось концепцией BIM? Предусматривалось, но тогда и деньги были бы прежние. А цифровая нить -- это новый бюджет, новые слова для новых денег! Скажем, вы просите денег на интеграцию данных жизненного цикла, какие слова будете говорить? А тут говорят так: Digital thread -- golden thread of information that runs right throuht the life cycle of a project, the thread that grows and gathers more strands until it develops the heft and weight of a digital twin (https://www.raconteur.net/technology/digital-engineering-what-is-it-and-why-you-need-to-know-about-it/). Инженеры старой закалки продолжают говорить "управление информацией" или "управление данными", их эта менеджерская поэзия не увлекает. Так, если нужно сшить между собой мультифизическую модель (модели нескольких физик -- механическую модель, электрическую модель, тепловую модель, акустическую модель и т.д.), то инженеры будут говорить управление данными имитационного моделирования/SMD/simulation data management, а менеджеры старой закалки предпочтут говорить управление информацией (имитационного/мультифизичного) моделирования/simulation information management (но говорят так довольно редко, менеджеры до этих тонкостей уже не доходят, они больше про "нить").

Цифровая инженерия/digital engineering -- это создание цифрового двойника путём сплетения цифровой нитью различных его моделей, экземпляра его физического двойника и цифровых двойников окружения. Цифровой инженерией занимается цифровой инженер/digital engineer, и сразу признаётся, что знания цифрового инженера должны быть настолько широки (вся просто инженерия и всё просто айти), что его роль выполняется обычно большими командами.

Если цифровая нить не привязывает экземпляр цифровой модели цифрового двойника к физическому двойнику (экземпляру киберфизической системы, чей двойник), то это просто цифровая модель/digital model, данные к ней и из неё попадают "вручную", асинхронно. Если цифровая нить привязывает физического двойника к модели, и модель обновляется автомагически, то это будет цифровая тень/digital shadow. И только если цифровая нить привязывает не только физического двойника как источника калибровочной информации для модели, но и модель как источник калибровочной информации для физического двойника -- вот тогда это полноценный цифровой двойник/digital twin. И помним, что формально для ответов на вопросы "а что если..." можно породить несколько digital siblings (ибо они не будут соответствовать полностью физическому двойнику, их не любят называть цифровыми двойниками, но признают кровное родство).

Вот в этой картинке (из https://www.cadmatic.com/en/resources/blog/digital-model,-digital-shadow,-or-digital-twin-%E2%80%93-what-is-at-the-core-of-data-driven-shipbuilding/) пунктирная нить означает ту самую цифровую нить:

Вот типичное софтовое предложение для организации цифровой нити, найдите хоть одно отличие от предложений по организации PLM и интеграции данных жизненного цикла: https://prostep.us/cpmn/apidt/digital-thread-and-digital-twin-solutions/ (и да, это предложение от фирмы, которая традиционно занималась тематикой PLM, а дальше просто переписала свои тексты с использованием модной лексики).

Вот картинка новой V-диаграммы от Boeing, в которой поминается ещё один синоним для цифровой инженерии: моделеориентированная инженерия/model-base engineering/MBE, и теперь это не V, а MBE-ромб/diamond, с 2018 (https://www.incose.org/docs/default-source/midwest-gateway/events/incose-mg_2018-11-13_scheurer_presentation.pdf):

В этой диаграмме к традиционной V-диаграмме физической системы/двойника добавлена симметричная Λ-диаграмма цифрового двойника, а серединка отдана цифровой нити (вместо показа традиционных для этой диаграммы проверок и приёмок).

MBE любят в NIST и туда включают модели требований, архитектуры мультифизику и всё остальное, в отличие от INCOSE, которая любит MBSE/model-based systems engineering/моделеориентированную системную инженерию с акцентом на модели требований и архитектуры и меньшим акцентом на мультифизику -- но в INCOSE тоже переобуваются на ходу, и ветер там дует с военной стороны (см., например, как определяют digital engineering в SEBoK, https://www.sebokwiki.org/wiki/Digital_Engineering -- прямо ссылаются на DoD и в тексте, и в литературе).

Цифровая трансформация/digital transformation -- это прежде всего постановка практики цифровой инженерии, переход к тому, чтобы физические двойники (предприятие в ходе его работы, пациенты в ходе операции, здания в ходе эксплуатации, самолёты в полёте) управлялись со стороны своих цифровых двойников. Если этого нет, а просто вы ставите какую-то ещё одну базу данных и ещё одну систему аналитики, вроде как можете говорить о big data всём таком прочем модном, можете добавлять что-нибудь про цифровую тень но слово "цифровой" для такой трансформации говорить должно быть неудобно. Но с этим, конечно, никто не считается.

Военная цифровая инженерия
Как всегда, волну новой терминологии оседлали военные, прежде всего США. Они сходу объявили, что у них теперь цифровая инженерия, а в ней цифровая инженерия (военных) миссий/digital mission engineering -- удостоверение того, что вся инженерная работа как-то повлияет на результативность военных миссий. Если вы начнёте искать в сети всю эту цифровую терминологию, то найдёте много военного (они хорошо разрабатывают регламенты, стандарты и прочее подобное, что в нормальном бизнесе аккуратно срезается lean-подходом) -- так что аккуратней с источниками. Вот вам ссылки на тексты военных, прелесть ведь как всё структурировано, но не факт, что именно в этом виде оно будет хорошо работать в коммерческом секторе (факт, что не будет):
-- "What Is Digital Engineering and How Is It Related to DevSecOps?", ноябрь 2020, https://insights.sei.cmu.edu/sei_blog/2020/11/what-is-digital-engineering-and-how-is-it-related-to-devsecops.html (помним, что DevSecOps -- это те же DevOps, только с добавкой безопасности. Это ж военные!). При этом чётко говорится, что это всё для спасения жизней в том числе разработчиков и испытателей (во время испытаний F100 в 50-е погибли 324 пилота и потеряно 889 самолётов, https://en.wikipedia.org/wiki/North_American_F-100_Super_Sabre, а "цифровые испытания" позволяют сократить потери в подобных проектах).
-- "Digital Engineering Metrics. Supporting Technical Report SERC-2020-SR-003", июнь 2020, https://sercuarc.org/wp-content/uploads/2020/06/SERC-SR-2020-003-DE-Metrics-Summary-Report-6-2020.pdf (в этом отчёте старинное MBSE/model based systems engineering из INCOSE используется как синоним с Digital engineering, хотя MBSE это только часть digital engineering, ибо в MBSE обычно поддержка работы с требованиями, архитектурой и планами испытаний, а в digital engineering ещё и non-architectural part of design как минимум, плюс ремонт и обслуживание на стадии эксплуатации, во время работы digital twin. И это ж военные и государственные: если вы хотите попросить приличных денег за цифровую инженерию, то вам сюда: десятки метрик для оценки этой самой цифровой инженерии! KPI получите в количестве, никаких денег не хватит, чтобы их выполнять и по ним отчитываться! И упор тут именно на digital transformation: как определить, идёт трансформация, или таки не очень. Но если вам вдруг выпало заняться информатизацией, тьфу, цифровизацией, тьфу, цифровой трансформацией в части постановки цифровой инженерии, то это хорошие чеклисты: о чём нужно подумать -- но ни в коем случае не делать всё сразу, ибо тогда точно не сделаете, но зато освоите много денег, по круглой сумме за каждую метрику. Вот прямо берёте метрику и заключаете какой-нибудь договор на её реализацию с кем-нибудь, будет не хуже, чем в армии США).
-- digital mission engineering, https://www.agi.com/digital-mission-engineering (больше всего тут материалов от AGI, an ANSYS company -- поставщик софта для системной инженерии в военных применениях, вот и смотрите материалы на этой странице). Можно ли это применить гражданским? Ну, считайте, что речь идёт о нацеленности всей инженерии на эксплуатацию в условиях разнородного окружения целевой системы.

Смотреть новости по всему этому богатству цифровой инженерии можно на порталах https://www.plmportal.org, https://www.digitalengineering247.com, на немецком https://www.digital-engineering-magazin.de/. А что со старинными названиями? Например, "автоматизация"? Тоже всё найдёте, https://www.automation.com/ -- ресурс международного общества автоматизации. Ну, вы поняли: где раньше занимались PLM, автоматизацией, САПРами, инженерным моделированием, там и продолжают заниматься. Но слов стало больше, и ресурсов стало больше. Ну, и старые слова тоже вполне живут, люди-то никуда не делись. По последней ссылке вы найдёте и smart manufacturing (Industry 4.0), и integrated manufacturing business operations, и IIoT/Industrial Internet of Things.

Для не-заводов всё тоже цифровое, но единства в терминологии ещё меньше
У банка, страховой компании, вуза, логистической компании и многих других нет PLM, но цифровая трансформация есть. У нас для них советы:
-- иметь таки для их целевых систем цифровых двойников, а для этого целевую систему придётся таки найти в физическом мире как физического двойника.
-- считать, что прохождение кейсов по проектированию, как бы "изготовлению" и как бы "эксплуатации" (как это у них называется? у всех ведь по разному) -- это цифровой банкинг, цифровое образование, цифровое страхование и т.д.. Тем более что все эти слова есть (и означают в том числе уход в онлайн плюс ту же автоматизацию и биг дату с data-driven enterprise, тьфу, это ж теперь цифровая трансформация!).
-- смело пересказывать тексты и идеи промышленников, заменяя слова, там ведь всё то же самое. Не забывайте только вставлять слова про privacy, safety и security, хотя и у промышленников compliance через слово. С другой стороны, там везде и своих слов хватает. Но если вам приходится работать и с промышленными предприятиями, и банками, то лучше бы как-то экономить мышление и научиться думать о самой разной цифровой трансформации одинаково.

Обычно непромышленные организации идут впереди промышленных, у них что сейчас происходит с цифровизацией? Ну, hyperautomation/AI-Transformation/Digital Process Automation/Intelligent process automation (и ряд других терминов от разных лавок, пока совсем-совсем не договорились, вот обзор терминологии: https://research.aimultiple.com/hyperautomation/ (там полный винегрет изо всех идей, абсолютно разноуровневый). Отличается всё это от цифровой инженерии только тем, что явно и специально поминается через слово искусственный интеллект и машинное обучение, но не говорится о том, куда этот интеллект употребляется (а тут как с людьми и употреблением естественного интеллекта: нельзя ничего сказать, использовать-то можно везде!). В инженерии проще: объявляем эти "искусственные интеллекты" просто какими-то отдельными моделями/вычислителями и вплетаем их цифровой нитью в состав цифрового двойника. А что тогда RPA? Ну, это инструментарий цифровой нити, который может связать и текущий корпоративный софт, и вплести в него а хоть и людей. Интерфейсы к живым людям в PRA тоже есть, Текущий RPA состоит из набора коннекторов к софту, набора коннекторов к человеку (все эти распознавания речи), плюс BPM-движка (можно думать, насколько там близко к case management -- они ж себя процессниками считают, и языки там типа CMMN есть, хотя пока выглядит как "голимый недоBPMN". Но это ж ровно то же самое, что PLM, только данные берём не сапровские, и не только через API, но и через формы, и непосредственно от живых людей!

Так что терминологию цифровизации/цифровой трансформации для всех этих разных предприятий меняем, а мышление -- нет. Оно продолжает быть системным и вычислительным, трансдисциплинарным.

UPDATE: обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10220193584883882, обсуждение в чате блога -- с https://t.me/ailev_blog_discussion/5866
2019

Военная MBSE в 2020: мои заметки по лекции Dr. Warren Vaneman

Двухмесячной давности лекция для членов INCOSE по современному пониманию MBSE (model-based systems engineering) в INCOSE от Dr.Warren Vaneman (Professor of Practice in the Systems Engineering Department at the Naval Postgraduate School, Monterey, CA) -- https://youtu.be/BPlphC88xR4.

Инициатива с MBSE была поднята любителями SysML в INCOSE ещё в 2007 году (www.omgwiki.org/MBSE/doku.php и там сайт на OMG не случайно, ибо в MBSE доминирует SysML -- я в 2009 году даже выступил в INCOSE INSIGHT с возражениями против использования термина для одного-единственного языка моделирования, явно не лучшего языка для моделирования систем, https://levenchuk.com/2009/12/08/sysml-is-the-point-of-departure-for-mbse-not-the-destination/).

В лекции Warren Vaneman этих языков системного моделирования уже множество, и он сам рулит разработкой и использованием LML (https://www.lifecyclemodeling.org/?page_id=10). Но к его чести, в лекции LML даже не особо выпячивается военная специфика не слишком выпячивается, хотя лекция полна военно-морских иллюстраций и речь лектора полна бюрократизмов из системно-инженерных стандартов DoD. Тем не менее, само содержание лекции IMHO существенно отражает специфику дорогого долгостроя военной системной инженерии и поэтому далеко от описания state-of-the-art.

Делается утверждение, что сегодня MBSE включает четыре принципиальные составляющие:

1. Языки моделирования (типа SysML, LML и т.д.. Если бы был SysMoLan, то он тоже бы попал сюда. Вот, насколько я понимаю, мой первый заход на SysMoLan, 2013 год, и это как раз из переписки в INCOSE по поводу языков моделирования в MBSE -- https://ailev.livejournal.com/1061167.html, а вот текущая цепочка текстов -- https://ailev.livejournal.com/1443879.html). Позиция Vaneman тут утопическая: "язык должен быть основан на онтологии для независимости от представлений/presentations и независим от инструментов". Развитие языков программирования показывает, что побеждает в конечном итоге не язык-стандарт со множеством его инструментальных реализаций, а один и тот же язык-компилятор (реализация языка как "стандарт языка"). Vaneman говорит, что мышление должно быть tool-agnostic, в терминах даже не языка, а онтологии этого языка -- и это так и есть, но вот множественность инструментов для этой онтологии, если она становится распространённой -- вот это утопично. Насчёт того, что ориентация на общую онтологию позволит объединять модели на разных языках, поддержанные разными инструментами -- это тоже оказалось утопией. И на замечание, что произойдёт с моделями, для которых поставщики софта прекратили поддержку инструментов, у Vaneman тоже нет ответа. Всё произойдёт: потеряем мы эти модели через десяток лет с момента их создания.

2. Практики, опирающиеся на моделирование (model-based processes) на всём жизненном цикле. Переход к этим практикам Vaneman представляет как смену культуры работы/culture change с каких-то отдельных рабочих продуктов к "виртуальному представлению"/virtual system representation. Это абсолютно совпадает с пониманием производственной культуры как совокупности практик работы, которое я дал при описании мереологии практик в https://ailev.livejournal.com/1508228.html). Vaneman подчёркивает, что это требует хорошего понимания разницы между описаниями и их артефактами, тот самый переход к "виртуальности" в обсуждениях вместо ориентации на отдельные рабочие продукты-"документов". И тут важен аспект programmatic, чтобы эта культура охватывала всех контракторов "программы" (помним, что речь идёт о военных "закупках", структурируемых по "программам", более-менее совпадающим в части менеджмента с программами проектного управления), (https://www.dsiintl.com/support/publications/article-index/independent-systems-engineering-vs-programmatic-systems-engineering/). Сюда же отнесём обсуждения управлением конфигурацией и изменениями зоопарка моделей в проекте (Vaneman это называет data governance).

3. Подходы к представлениям (presentation frameworks, список view/viewpoints и мета-модели для этого списка, соотнесённый к разным проектным ролям, которым они нужны для принятия решений). От архитектурных подходов (architecture frameworks) Vaneman предлагает отличать тем, что архитектурные описания через набор традиционных архитектурных veiwpoints/systems perspectives только часть всех описаний, нужных для работы над системой: ещё нужны описания для неархитектурных проектных ролей -- финансовые описания, описания для управления работами и т.д.. Как я понял, текущая позиция в том, что в каждом проекте нужно делать этот список представлений заново ввиду полной недостаточности всяких DoDAF и TOGAF (в которых требуются view, которые никому не нужны в проекте, но не указываются view, которые нужны и важны -- постоянный предмет критики использования этих якобы всеохватных стандартов, которые переохватны в одних частях и явно недоохватны в других).

4. "Структура"/structure (ужас полный, использование в специальной терминологии таких общих и многозначных слов должно быть запрещено инквизицией и жёстко преследоваться!) это по Vaneman необходимость отображения отношений между частями как системы, так и разными описаниями (concordance -- согласованность разных описаний одного и того же объекта и traceability -- отслеживаемость связей между описаниями). Холистичность тут, решением вроде как является интеграция данных жизненного цикла -- и Vaneman считает огромной проблемой недостаток внимания к этим вопросам. Пока он будет называть это "структурой" внимания и не будет. Опять же, пока он будет игнорировать опыт попыток интеграции данных жизненного цикла -- не будет видеть и проблем.

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

Итого: старички отрасли по-прежнему думают о МBSE и говорят примерно те же слова, что и в 2007 году, только уточняя их. Жизнь же поменялась. Так, в лекции ничего не говорится о digital twins, ничего не говорится об очевидных затыках с онтологической интеграцией данных жизненного цикла (был же огромный опыт за прошедший десяток лет! Десяток лет назад PLM-системы только-только появлялись, а сейчас это общее место. И языки системного моделирования в них вроде как входили поначалу как организующее начало, но потом как-то сдулись -- я думаю, что они просто ушли в текстовую и табличную форму, это визуальные представления диаграммных языков сдулись).

То есть это хорошее описание текущего состояния и проблем, но не описание state-of-the-art и трендов. Военные всё-таки такие военные!
2019

Интернет воюющих вещей

Интернет воюющих вещей, какой термин! Это статья "Challenges and Characteristics of Intelligent Autonomy for Internet of Battle Things in Highly Adversarial Environments" от Alexander Kott, U.S. Army Research Laboratory -- https://arxiv.org/abs/1803.11256.

В понедельник 9 апреля 2018 мне выступать на нашей IoT конференции -- http://internetofthings.ru/sobytiya/208-iot-day-moscow-2018, с кратеньким сообщением "Может вещь в интернете системно мыслить?". Но именно это и хотят армейские от вещей в интернете. Вещи в интернете по их версии должны а) системно мыслить, почему бы и нет, б) быть автономными, все вычисления on the edge, ибо интернет не гарантирован, время реальное и задержки в сети мешают быстро двигаться -- а двигаться это менять физический мир, действовать в) универсальными, ибо кто знает чем им придётся заниматься в быстро меняющемся мире, в) быть всегда на связи, друг с другом и выяснять, что вокруг происходит, кто и что делает, согласовывать планы и действия, г) отлично общаться с людьми, кратко и по делу, ибо длинно общаться некогда -- вокруг ведь нервно. Всё как в "обычном IoT", только армейские добавляют, что работать Battle Things должны в крайне враждебном окружении и поэтому чётко делить мир на своих и чужих.

Я на слайдах "всё будет быстро" уже давно зачёркиваю: "будет" и пишу "всё быстро". Похоже, большинство людей вокруг меня не понимают, насколько всё уже быстро. Человечество стало вдруг резко умнее, ткацкие машины для творческой работы уже изобретены. Работа мысли уже не вся порождается мокрыми мозгами, и это происходит уже повсеместно там, где этого не ждёшь. Мысль ткётся ткацкой машиной существенно быстрей и качественней, чем ткацким станком: Computer Sapience с интеллект-стеком (http://ailev.livejournal.com/1356016.html, с когнитивной архитекторой внутри него -- https://ailev.livejournal.com/1322862.html) совершенно другая штука, чем традиционный компьютер для записи, хранения и обработки информации -- где информация обрабатывалась без интеллект-стека.

Этого поумнения человечества за счёт интеллект-стека современных компьютеров пока народные массы не замечают: вы же не замечаете, что какие-то ваши коллеги поумнели за последний десяток лет. А тут поумнели компьютеры, это не бросается в глаза так же, как не бросается в глаза поумнение обычных людей.

Вот, например, неестественный интеллект сочиняет форму зубной коронки с качеством лучше, чем люди -- https://arxiv.org/abs/1804.00064. Берём коронки, изготовленные людьми, но кроме этого берём естественные здоровые зубы и учим, как должен выглядеть правильный зуб, правильно взаимодействующий с противоположной челюстью. Учим компьютер, дальше даём ему челюсть с дыркой в ряду зубов и противоположную челюсть. Компьютер сочиняет идеальный (beyond human expertize, как говорится в статье) зуб, который встал бы на это место. Дальше 3D-модель печатаем на 3D-принтере, профит. И это доступно уже сейчас, можно масштабировать. Даже не обсуждаем, что будет потом: робот, который поставит эту коронку с качеством beyond human expertise, или печать как-то пройдёт на биологическом принтере, и роботы просто пересадят зуб, или биологи придумают что-то по восстановлению зуба -- и все эти короночные изобретения уйдут в прошлое, едва появившись, или человечество вдруг резко захочет что-то изменить вообще в конструкции (а то и функции) зубов, а у нас просто сегодня фантазии это предвидеть не хватает.

А вот как компьютер сочиняет картинки, чтобы нас разжалобить. Берём руины, и спрашиваем, какие более душещипательные. Я сознательно снижаю тут пафос, юмор у меня тут чёрный и мрачный. Учим нейросетку понятию "душещипательность" в руинах (перенос стиля, это ж оно! Это ж отработано давно и в совершенстве). Далее спрашиваем, какой город ваш самый любимый. Переносим стиль душещипательной руинности, и вас пробирает до самой лимбической системы -- https://deepempathy.mit.edu/. Глубокая эмпатия, тщательно спланированная -- против кого эта эмпатия (ага, "против кого дружить будем?").

Берём дофаномику (бихевиористские игры с правильно расставленными "подкреплениями", как в дрессировке -- все эти лайки и залипания в фейсбуке, проверки почты по ночам, видеоклипы, ожидания выхода очередной серии неважно чего, https://knife.media/dopamine-loop/) и добавляем глубины: учим нейросеточку тому, что нас там цепляет. И переносим этот стиль, отработанная уже процедура. "Это не спам, это direct mail" -- помните такое "оправдание"? Так и тут: "это не интернет воюющих с вашим мозгом вещей, это просто такой хороший нейромаркетинг". А ведь это воюющие с моим мозгом вещи, которые тщательно настраиваются неестественным интеллектом на уровне beyond human expertise, чтобы победить. И ведь победят.

Один интернет воюющих вещей будет биться за землю, а другой за куски вашего мозга. Впрочем, это будет один и тот же интернет вещей, а не два. Помните в Spora была одна раса, которая выигрывала войны пропагандой? Нынешние войны тоже серьёзно завязаны на пропаганду. А это тот же "глубокий нейромаркетинг", он уже идёт (все скандалы с Cambridge Analytica ровно про это, и это сегодняшние скандалы, а не скандалы будущего -- https://ru.wikipedia.org/wiki/Cambridge_Analytica).

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

С людьми ведь тоже так: злые гении есть, но на одного злого гения приходится два десятка нормальных. И военный бюджет, равно как и маркетинговые бюджеты отравляют жизнь человечества, но не на все 100% всех бюджетов. С компьютерами всё будет так же: затраты на военные и маркетинговые бюджеты на компьютеры будут всего лишь долей затрат на продуктивное использование компьютеров, на продуктивный интернет созидательных вещей. Так что пусть военные и спамеры занимаются интеллект-войной и интеллект-спамом, а я займусь другими интересными вещами. Например, системно мыслящими вещами в компанию к системно мыслящим людям. Я могу сколько угодно отказываться работать с военными (вот буквально пару дней назад отказался в очередной раз), но желающих помочь в создании воюющих вещей всегда будет достаточно. А все остальные пусть определяются сами, на какие бюджеты они работают.

Вот, например, сотрудники Гугля пытаются что-то делать в этом направлении -- https://geektimes.ru/post/299713/ (и мне нравится, что используется традиционный аргумент -- "что вы, у нас не министерство нападения, у нас министерство обороны!", то есть технология «призвана спасать человеческие жизни и избавить людей от необходимости выполнять очень утомительную работу»). Пожелаем им успеха. Я вот не могу представить, что что-то подобное сбору подписей против подобных проектов проходит в каком-нибудь Яндексе, или Cognitive Technologies. Ну, и от этих одиночных сопротивлений милитаризму в его самых оборонных (конечно, конечно, верим!) проявлениях IMHO мало что зависит. Так что будем обсуждать (и давно обсуждаем, вот пост 2009 года -- https://ailev.livejournal.com/662638.html) этику военных роботов, но не само строительство таких роботов.

Реальный успех в демилитаризации был бы только, если бы были сокращены военные бюджеты, и во всём мире. Тогда бы на интернет воюющих вещей просто не было бы денег, и разговоры оставались разговорами. А пока имеем, что имеем.

UDATE: обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10212696776948369
2019

Онлайн курсы системной инженерии: насколько современной?

Перед тем, как брать западные онлайн-курсы системной инженерии, нужно прочесть, например, текст "Сколько стоит вертолёт" -- https://lenta.ru/articles/2017/01/18/helidev/ (зажравшийся аэрокосмос, на три четверти военный и на четверть регуляторно гипербезопасный по сравнению почти с чем угодно) в сочетании с текстом "что на свете всех сложнее? автомобили вырываются вперёд!" https://ailev.livejournal.com/1398456.html. Ну, или материал о том, как космическая инженерия ULA отличается от космической инженерии SpaceX с точки зрения траты денег американских налогоплательщиков (к нашей космической промышленности эта дискуссия тоже относится): https://www.nextbigfuture.com/2018/01/spacex-crushing-ula-in-terms-of-value-for-us-taxpayer-dollars.html

На планете сейчас много разных системных мышлений, много разных системных инженерий. И много дедушек (часто в форме! военные системные инженеры!), готовых поделиться рецептами выигрыша в прошлой войне. Крайне дорогими рецептами выигрыша, которым они выигрывали деньги и бюджеты лет тридцать назад, а десять лет назад которые они переложили в курсы и вот сейчас довели их до онлайна.

Вот NASA и Boeing делали курсы моделеориентированной системной инженерии с MIT, по сходной цене: https://mitxpro.mit.edu/courses. Догадайтесь с трёх раз, какая из самых разных вариантов системных инженерий там представлена? Дорогая и медленная, или быстрая и подешевле? Кстати, я всегда выступал против курса https://www.coursera.org/learn/systems-engineering -- заучивать стадии жизненного цикла типового военного проекта IMHO просто бессмысленно, для меня это не системная инженерия, а "военная инженерия" (но, конечно, в самом курсе никто этого уточнения про "военность" не сделает, об этом не принято говорить).

В курсах от MIT, конечно, SysML, как же иначе. Мне очень по совокупности причин не нравится SysML. AADL в этом плане может быть не хуже. И даже для многих случаев ArchiMate 3.0 (который к тому же теперь расширяемый) тоже может быть использован. И это не учитывает самые разные варианты развития DSL для моделирования -- информатика-то на месте не стояла. Так, можно бы возвращаться к разговорам про SysMoLan на базе а хоть и Julia, особенно после того как Modelica и Julia нашли друг друга: https://ailev.livejournal.com/1366789.html

Так что я бы сейчас ориентировался в методах даже больше не на аэрокосмос, где бегают лишние деньги и поэтому не всё эффективно, сколько на automotive -- и какой-нибудь совсем-совсем передовой automotive, а не тех дедушек, которые ушли на пенсию и помнят как круто делались автомобили в 2008 году. В 2018 году совсем другой time to market, делать нужно совсем другую киберфизику (роботакси), на совсем других САПР и PLM, с совсем другим станочным парком на производстве. Это другая системная инженерия, и учить нужно этой другой системной инженерии.

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

Так что чему учить в системной инженерии прямо сегодня, нужно тщательно выбирать. В университетах раньше были авторские курсы всегда, исследователи-профессора читали самое свежее ими наработанное. Сейчас ВУЗы разделились на "вторичные" и "первичные" ровно по этому признаку. В одних читается свежатинка и state-of-the-art, в других -- "классика". С одной бедой: в инженерии "классика" (классика -- это ведь "образец для подражания") безнадёжно устаревает каждые несколько лет. И её нужно безжалостно менять, инженерам нечего подражать инженерам древности, им не нужно пользоваться кульманами и логарифмическими линейками. К учебным программам системной инженерии это тоже относится, они не должны учить системной инженерии прошлого.

UPDATE: обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10212099338732787
2019

SpaceX и подрыв военной системной инженерии

Александр Кудрявцев указал, что SpaceX своими действиями подрывает устои системной инженерии, сложившейся в госсекторе авиакосмоса -- и указывает, что классикам ракетостроения трудно признать, что жизнь изменилась, и их когда-то прорывные технологии становятся тормозами в развитии отрасли: https://www.facebook.com/permalink.php?story_fbid=1887814108137774&id=100007276098500 (пост там "только для френдов", но я попросил его открыть, так что ждём).

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

Тут ещё важно, что речь идёт об авиакосмосе, существенно государственном и военном. Я всегда в своих курсах оговариваю, что системную инженерию ни в коем случае нельзя копировать из военных и государственных проектов, хотя именно там она и процветает больше всего. Именно там она из лекарства становится болезнью: вместо целей недопущения превышения бюджета она позволяет легко обосновывать бюджет любой величины, услужливо предоставляя аргументацию -- ведь идёт борьба с рисками, что святое.

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

-- Я клиентам не рекомендую использовать впрямую стандарт ISO 15288, я его характеризую как "посмотрите, сколько всего можно было бы сделать в инженерном проекте, что можно было бы легко обосновать! Поэтому стандарт хорош только для военных и государственных контрактов, можно обосновать по нему любой бюджет -- но затраты явно будут завышены".

[ В ряде контрактов на разработку просто ставится требование заказчика - ничего не придумывать нового.]
-- Это называется "референсные решения": если хотя бы где-то решение не использовалось уже, его нельзя использовать. Именно это требование приводит к стагнации в строительстве и конструировании атомных электростанций.

[Маск говорил про системную инженерию на базе физики]
-- Там двухходовка: Маск говорил про физику и инженерную мысль (которая должна работать от первых принципов). Что же касается системного мышления, то Маск понабрал спецов из NASA, а уж с ними пришли системные инженеры -- и дальше он уже от них нахватывался. Так что у него отдельно физика и инженерное мышление, и отдельно нахлобучка системности сверху этого. Системность сама по себе не про физику, она отдельным слоем.

[если всё так быстро меняется, то нужно менять образование для "собирателей из кубиков"]
-- Что же касается образования, то у проектантов и конструкторов разные образования -- но софт там стремительно сближается, и становится очевидным, что это по большому счёту всё одно и то же. Конструирование (формирование сложной формы неразборных детальков, включая изготавливаемые на 3D-принтерах сверхсложной формы) и проектирование (сборка нестандартного из стандартных детальков) пока изучается в разных ВУЗах, но дисциплины стремительно сближаются. И системная инженерия там по большому счёту одна и та же. Так что я бы не делал тут особых акцентов. Напомню, что разница между "сборкой из кубиков" и "творением формы" обсуждалась недавно отдельной темой в треде по очередному изобретению системной инженерии в робототехнике http://ailev.livejournal.com/1356445.html

[создание нестандартных деталей в интересах нестандартной сборки]
-- Нет! Нестандартных деталей как раз полно, и на этом неплохо зарабатывают (вписывают интерфейс в условия контракта вместо того чтобы брать интерфейс из открытого стандарта -- т.е. не используют принцип "открытой архитектуры", с этим очень трудно бороться и это серьёзно удорожает контракт. Скажем, сделать дырку не стандартного размера 100, а размера 97 и балку в неё не стандартного размера 100, а нестандартного размера 97 будет в разы дороже в изготовлении -- на этом и зарабатывают). Но вот конструктивное решение будет именно "опробованное", разве что все размеры и интерфейсы нестандартные. Если сталь какой-то марки, то только она, и никаких таких композитов. Если насос какого-то древнего типа, то никаких других новых типов не предлагать. Или там быстро будет цена испытаний стоимостью клинических испытаний, но вместо потом миллионных тиражей как в медицине тираж в десяток штук для какой-то серии атомных станций -- если сильно свезёт попасть в аж целый десяток проектов.

UPDATE: дискуссия в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10210691091887496
2019

lytdybr

Открыл пару дней назад самокатный сезон, активно пользуюсь тем, что на улице сухо.

Нашёл, наконец, танго "Тайна" с пластинки фирмы "Мелодия" 1970 года "Танго (II серия)" -- это оказалось Tango Bolero в исполнении Klaus Wunderligh, с пластинки Mr.Hammond Gag 1965 года, https://www.youtube.com/watch?v=9iIwOUfq5fs. Ещё мне оттуда очень-очень нравится "Старое танго" Оскара Строка в исполнении Ёити Сугавара -- https://www.youtube.com/watch?v=rKbTDr9cw4A. Всегда там слышал вторую строчку как "моя машина", очень меня это в отрочестве развлекало.

На занятии аутентичной кизомбой-сембой Илья показывал много разных усложнений основного шага. После чего посмотрел, как мы это всё выплясываем, и печально сказал, что это всё понты, а кто их не может делать -- пусть шагает без этих усложнений, так тоже можно. Сразу стало понятно: мы пока -- беспонтовые танцоры.

В лицее организуются специфические экскурсии в связи с 23 февраля. Вьюнош пропустит. У нас в прошлой школе полкласса ушло в кадеты, патриотическим милитаризмом были методично прогружаемы по самые уши, в лицее надеемся от этого отдохнуть. Кто очень интересуется историей 23 февраля, могут почитать материал http://www.istorya.ru/articles/23fevr.php -- никакой романтики, всё прозаично, кроваво и ужасно, как и всё остальное в те постреволюционные годы. Потом годы и годы романтизации и украшений тех печальных событий. Теперь целая индустрия, выстроенная на мифе.

Обнаружили сегодня, что с понедельника будет зимняя физматшкола для 2-11 классов в МФТИ на Климентовском, 20-24 февраля 2017: http://edu-mipt.ru/index.php/sezonnaya-shkola. Вот туда мы отрока и отправим, пусть ему мозги чем-нибудь полезным промоют.

Чтобы не потерять ссылку: лингвистический аналог polandballs -- языковой конгресс, http://pikabu.ru/profile/unerriar.

Никогда не думал, что мужские и женские голоса, объявляющие остановки, означают направление движения -- http://mosmetro.livejournal.com/229066.html. Мнемоника там -- к центральным станциям на работу зовёт начальник, а домой из центра -- жена. По кольцу -- по часовой звучит мужской голос, а против часовой -- женский. Ну, и ещё ряд мелких особенностей. И это с 1984 года, для ориентирования слепых и слабовидящих (голос из вагонов хорошо слышен на остановках).

FireFox начал регулярно подвешиваться на полминуты при открытии страниц. Грешу на AdNauseum, но возвращаться на AdBlock Plus не хочу. C одной стороны, появились ужасные рекламные заставки в видео ВКонтакте. Сейчас там рекламируется "Совесть" -- это банковская карточка такая! Сама эта реклама вызывает вопрос о совести всех причастных: у них ведь ничего личного у каждого, "это просто работа". В AdBlock этих реклам никогда не было. С другой стороны, в фейсбуке вырезается огромное количество лишних завлекалочек, что очень приятно -- и это не вырезалось в AdBlock. Ну, и AdNauseum этически чуток получше, чем AdBlock Plus в части программ аффилированности. Щит, в котором можно купить персональную дырку для твоего копья -- это что-то неправильное, такое не хочется у себя иметь.

Аниме, которые я так и не собрался посмотреть, но когда-нибудь ещё соберусь: Omoide no Marnie (http://anidb.net/perl-bin/animedb.pl?show=anime&aid=10313), Ookami Kodomo no Ame to Yuki (http://anidb.net/perl-bin/animedb.pl?show=anime&aid=8832), Kimi no Na wa (http://anidb.net/perl-bin/animedb.pl?show=anime&aid=11829). Вот попытался вспомнить, когда же я последний раз смотрел аниме -- и не вспомнил. Ибо сначала манга оказалась интересней, а полгода назад начались танцы-шманцы-зажиманцы.
2019

Быстро ползёт улитка по глади воды

Видео моего прудовика -- как он выпускает из себя пузыри, ползёт по изнанке водной глади, и даже как его атакует сомик (снято вчера старинным Lumix GF1):
-- https://youtu.be/U5oON5THVQk
-- https://youtu.be/3XDdr4-kb6o

Никогда не думал, что улитки такие путешественники. Особенно интересны манёвры подводной лодки. Например, доплыть по поверхности на середину аквариума, быстро выпустить из себя пузырики и камнем пойти на дно, не спеша ползать там по камушкам, потом быстро-быстро вдруг выползти по стеклу на поверхность -- и опять резвиться на водной глади.
2019

lytdybr

Мой отрок таки прошёл практически без подсказок Human Resource Machine полностью (кроме оптимизаций – но решены все уровни) – крайне рекомендую, http://store.steampowered.com/app/375820/. Это классический Assembler, в смешной игровой форме. Заканчивается там набор задач разложением чисел на простые множители (причём в наборе команд операций умножения-деления нет, только сложение-вычитание), сортировка тоже встречается (команда может исполняться для какой-то ячейки памяти, а может для вычисленного адреса, указанного в ячейке). Задания очень лёгкие, если вас не интересует оптимизированный код. Как только вы начнёте оптимизировать (оптимальность вам замеряют), то игра будет вызывать некоторую задумчивость даже для программистов. В любом случае, я не знаю сегодня более простого и наглядного способа продемонстрировать отроку дух и вкус программирования на ассемблере -- ибо для любого настоящего ассемблера там будет превалировать не дух и вкус, а буква многочисленных технических подробностей.

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

Государство в США не будет вмешиваться в добычу на астероидах частными компаниями полезных ископаемых (вы только задумайтесь о самой постановке вопроса! без законодательства предполагалось, что вмешательство неминуемо!), добытое будет считаться собственностью добытчиков -- http://www.planetaryresources.com/2015/11/president-obama-signs-bill-recognizing-asteroid-resource-property-rights-into-law/

124 страницы свежайший учебничек (lecture notes) по распределённым представлениям в обработке естественного языка от тамошнего лидера, Kyunghyun Cho -- http://arxiv.org/abs/1511.07916. Многоэтажные формулы в ассортименте на каждой странице и 113 источников в списке литературы. Царских путей в геометрию до сих пор нет:
duckrabbit

Наш SysMoLan начали изобретать в DARPA -- даже интересно, сколько инженеров в мире смогут им воспользоваться (это я исхожу из моего скромного опыта. Похоже, сложность там будет побольше, чем у Coq и Agda вместе взятых -- недаром vvagr ехидничает в http://vvagr.livejournal.com/2114327.html). Но он не совсем ехидничает, там и впрямь может оказаться что-то интересное. Скажем, геометрические движки тоже сложны, и царских путей туда нет, но обёртка в виде 3D-САПР к этим движкам как-то позволяет их употреблять в жизнь. Это у DARPA очередная инкарнация META и META II, зовут её на этот раз CASCADE, слова те же -- "fundamentally change how we design systems", только в этот раз не джипы проектировать хотят, а systems for real-time resilient response within dynamic, unexpected environments. Ну, а дальше всё, что мы говорили про SysMoLan, только сразу с упором на математику -- "Applied mathematics, especially in category theory, algebraic geometry and topology, and sheaf theory" (ага, именно applied mathematics, исключительно прикладная) и военные применения, с намёком на оборону городов (или нападения на города, у военных ведь не разберёшь -- военные любой страны ведь о себе всегда говорят "оборона" вне зависимости от ситуации, а противоположная сторона у них всегда "агрессоры", так же вне зависимости от ситуации. Нет ни одной страны с "министерством нападения"). Вот, почитайте сами: http://www.darpa.mil/news-events/2015-11-20. Картинка там иллюстрирует использование mathematical sheaves для того, чтобы отслеживать датчики и объединять их информацию:


Интересно, с какой следующей страной у России напрягутся отношения? Глобус-то большой, выбор велик. Ага, страна в кольце врагов, исключительно обороняется -- и они, гады, этим пользуются, всё нападают и нападают, всё предают и предают, всё дальше и дальше от наших границ! Пока самая лучшая гипотеза о военно-курортном комплексе. Египет и Турция уже из курортных стран выбыли, дальше на очереди нужно будет ругаться с Китаем и Финляндией (сами поглядите: http://www.russiatourism.ru/content/8/section/82/detail/3768/).

Всё это не мешает народу развлекаться. Sony Playstation 4 преодолела планку в 30 миллионов проданных консолей. Это только одна фирма, только одна модель игровой приставки.
2019

Музеи как лакмусовая бумажка культуры

В сегодняшней ленте что-то много про музеи:
-- отношение соотечественников и иностранцев к Сурикову (в залах Сурикова в Третьяковке россияне и восточные азиаты оснанавливаются, а западные люди быстро-быстро пробегают мимо), в объяснялках когнитивная слепота и алгебра этики Лефевра -- http://perevodika.ru/articles/28284.html
-- Лурк переведён в режим консервации и памятника культуры (https://www.facebook.com/david.homak/posts/10153008781993525 и там много такого за последнюю пару дней), "просьбы трудящихся" таки победили.
-- ночь музеев, призванная приобщать к мировой культуре, вдруг превратилась в тематические массовые гуляния (например, Екатеринбург: в одном и том же тексте сначала на выбор предлагается семь маршрутов, а затем через несколько строчек остаются только два: литературный и победный, согласно эпиграфу к ночи музеев, "строчке из произведения Александра Твардовского: «Мы за Родину пали, но она — спасена»", http://kulturmultur.com/companies/fest/item165396/).
-- и даже рок-фестиваль "Нашествие" (хотя это не совсем музей) теперь совмещается с выставкой оружия и военно-патриотическим воспитанием молодёжи (https://slon.ru/posts/53010), "Когда у нас говорят, что на «Нашествии» теперь «большая военная компонента», это не совсем корректно. Корректнее было бы сказать, что в рамках военно-спортивного мероприятия выступят «также и рок-музыканты». Собственно о музыкальной составляющей в этом году даже не пишут – пишут именно о военной технике".
2019

Почему военная системная инженерия -- не совсем системная инженерия

Военная системная инженерия образец того, как завышать цены. Если тебе платят "затраты плюс", то каждый следующий проект просто автомагически получается чуть дороже и чуть дольше, чем предыдущий. И конкуренции нет, всё залицензировано напрочь, все места на этом якобы "рынке" давно куплены. Поэтому я не рекомендую считать образцами системной инженерии военные проекты. Вот прямо сейчас SpaceX сражается в судах за право делать военные запуски. На слушаниях в Конгрессе США (http://nextbigfuture.com/2015/05/air-force-should-certify-spacex-falcon.html):
[SpaceX COO] Shotwell "told Congress it would cost "on the order of $80 million to $90 million" apiece to put a Falcon 9 rocket in low Earth orbit, or "$150 million to $160 million" to build and launch a Falcon Heavy (a Falcon 9 rocket with two additional boosters). Averaged across both rocket types, she put the cost at about $120 million. In contrast, ULA charges taxpayers $400 million every time it launches a rocket into space. Commented Shotwell, "I don't know how to build a $400 million rocket. ... I don't understand how ULA are as expensive as they are."
И так можно обсуждать каждый военный проект, в любой стране (Россия тут мало отличается от США или Германии, все генералы мира более-менее одинаковы).