Поиск-ориентированная системная инженерия и другая пост-моделеориентированная жизнь
Что будет с системной инженерией дальше?
1. Классическая системная инженерия, в которой чертежи и диаграммы даны "картинками" (то есть недоформализованы, компьютер отрабатывает их как наборы линий, а не наделённые смыслом модели), знание оформляется главным образом документацией, текстами с картинками. Расчёты даны в виде бумажных описаний, отражающих проведённые самым разным способом (от логарифмической линейки и калькулятора до различных компьютерных программ) вычисления. Это сегодня мейнстрим, текущая действительность.
2. Моделеориентированная (model-based systems engineering) это текущая цель INCOSE, ближайшее будущее. Формализация рабочих продуктов определения системы, прежде всего архитектурных описаний -- для целей верификации принятых конструкторских решений и объединения различных решений в одно. Ключевые тут моделеры и имеющиеся в них солверы: солверы геометрические, солверы системы уравнений в Modelica.
Эпицентром всей этой работы сейчас является архитектурный язык SysML в связке с языком мультифизического моделирования Modelica, которую обеспечивает стандарт OMG SysML-Modelica Transformation (SyM, http://www.omg.org/spec/SyM/, рабочая группа http://www.omgwiki.org/OMGSysML/doku.php?id=sysml-modelica:sysml_and_modelica_integration, это преобразование идёт для некоторых продуктов в обе стороны, а для некоторых только в одну сторону и есть даже open source реализации -- https://github.com/SysMLModelicaIntegration).
Это всё развитие линии объект-ориентированного моделирования, но в этой связке уже налицо явный ход на гибридные вычисления:
-- численные методы интегрировали в объектный язык (Modelica), используется главным образом для компонентного моделирования (принципиальные схемы самого разного толка, вплоть до экономических моделей).
-- SysML это профиль UML, для них можно прописывать ограничения в логическом языке OCL (а сами они "написаны на" OMF). Это структурные модели, главным образом ориентированные на описание модульной структуры, можно прописывать и интерфейсы и протоколы.
Киберфизические системы (а именно, авионика) больше поддерживаются архитектурным языком AADL, и там те же тренды на связь с Modelica (http://link.springer.com/chapter/10.1007%2F978-3-642-41674-3_13, http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=6662050&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D6662050).
Конечно, есть связки и с геометрическими моделями (компоновками, размещениями) -- но там сложней, ибо для геометрического представления нет явных лидеров стандартизации, каждый 3D САПР сам себе стандарт.
Отдельная задача -- это интеграция моделей жизненного цикла (я определяю модели жизненного цикла так же, как и данные жизненного цикла -- модели, которые порождаются и используются в какой-либо момент прохождения системой её жизненного цикла). Тут начинает побеждать семантический подход и онтологии:
-- ISO 15926, который тут не нужно комментировать специально.
-- работы по архитектуре семантической интеграции данных системноинженерных моделей DANSA (Designing for adaptability and evolution in system of systems engineering) для случая, когда моделирование шло для независимо разрабатываемых систем (системно-системная инженерия), и нельзя ожидать использования общего для всех инструментария моделирования и предписанной последовательности использования инструментов (Tool Chain). В этом случае говорят о Tool-Net (сети инструменов) и semantic mediation (основанной на стандартах Semantic Web): https://www.danse-ip.eu/home/images/deliverables/danse_d8.1.3_conceptual_and%20architecture%20principles_of_sos_design_and_semantic_interoperability_of_systems_platform_and_sos_design_tool_net.pdf, http://www.iltam.org/files/the-voice-of-the-systems-en-dec.2013.web.pdf (работа заняла первое место на INCOSE International Workshop 2013г.).
-- OSLC стандарт семантического объединения данных жизненного цикла (Open Services for Life Cycle Collaboration -- "lifecycle intergration inspired by the web"): http://open-services.net/, который широко использует IBM, Atlassian и прочие производители систем управления изменениями/issue trackers --http://open-services.net/software/. Эта работа сейчас уходит в комитеты по стандартизации OASIS.
Итак, моделеориентированная системная инженерия заканчивается в тот момент, когда вам удалось объединить все имеющиеся модели и софт солверов: вы можете определить вашу систему и по результатам моделирования понять, как она себя поведёт в тех или иных условиях.
А дальше начинается самое интересное: что происходит в тот момент, когда модель уже есть?
3. Поиск-ориентированная системная инженерия (search-based systems engineering), исследуемое пока программистами наше более далёкое инженерное будущее. Если честно, то сейчас существует только search-based software engineering (SBSE, термин появился в 2001 году). Обзоры:
-- краткая справка: http://en.wikipedia.org/wiki/Search-based_software_engineering
-- http://www.infoq.com/presentations/sbse-search-based-software-engineering (слайды и видео полуторачасовой презентации),
-- http://seams2014.uni-paderborn.de/downloads/Harman_Keynote_slides.pdf,
-- тьюториал и "таксономия" в http://www0.cs.ucl.ac.uk/staff/mharman/laser.pdf,
-- репозиторий свежей литературы по теме (сейчас порядка 1200 работ): http://crestweb.cs.ucl.ac.uk/resources/sbse_repository/
-- ежегодный симпозиум (конечно, с challenge -- современная прикладная наука соревновательна): http://ssbse.org/
Конечно, для SBSE есть и много других названий и ключевых слов:
-- Metaheuristics &Software Engineering (метаэвристики -- это эвристики об инженерных эвристиках. Помним, что инженерия базируется не на науке, а на эвристиках, как хорошо показано в работах Billy Koen об инженерном методе): http://neo.lcc.uma.es/mase/
-- Dynamic Adaptive Automatied Software Engineering (проект четырёх британских университетов): http://daase.cs.ucl.ac.uk/
-- Genetic and Evolutionary Computation -- http://www.sigevo.org (и там можно поглядеть в success stories -- http://www.sigevo.org/wiki/tiki-index.php?page=Success%20stories).
Основные темы - тестирование и отладка (порядка половины всех работ), дальше проектирование (например, качественная модуляризация), требования/спецификации (какими требованиями пренебречь с минимальным ущербом для пользы) и так далее по всему списку практик жизненного цикла (включая практики самого управления жизненным циклом и операционного управления, в том числе оценки риска срыва сроков проекта).
Это уже проходилось много раз: идеи начинаются в software engineering, а затем с некоторым лагом приходят в системную инженерию. Мы просто считаем, что этот лаг можно сокращать сознательно. Мы уже начали это делать с OMG Essence, так почему же это не делать с Search-Based Software/Systems Engineering? Конечно, переход от "программ" к "железу" много чего поменяет, но рано или поздно этим переходом нужно будет заняться, так почему не сейчас?
Если в моделеориентированной системной инженерии мы формализовали набором моделей сам объект работы инженеров -- целевую систему и подвергали эти модели анализу солверов, то в поиск-ориентированной системной инженерии мы формализуем также и синтетические практики системной инженерии: инженерии требований, инженерии системной архитектуры и инженерии проверки и приёмки.
Прежде всего, нужно указать на возможность постановки всех расчётных и даже геометрических моделей (которые тут тоже можно считать "расчётными") под управление оптимизатора. Это самый простой случай. Настолько простой, что его часто даже не считают следующим поколением системной инженерией, а просто частным примером использования методов моделе-ориентированной системной инженерии.
Но вот если мы хотим, чтобы менялись не параметры модели, а сами модели определения системы, их структура -- это совсем другое дело. Человек при этом будет задавать (функциональные) требования, а вот модели для удовлетворения этих требований с учётом всех возникающих технических противоречий, будет делать компьютер. То есть мы задаём пространство технических решений, и будем искать в этом пространстве оптимальные решения -- "поиск" технических решений тут ключевое слово. Отсюда и search-based systems engineering.
Тем самым по сравнению с моделе-ориентированной системной инженерией для компьютерного поиска решений нужно дополнительно формализовать предмет системной инженерии:
-- формализовать пространство решений
-- предъявить формальные количественные и качественные (любимый пример -- формализовать понятие "элегантности" для архитектуры) критерии к результату
4. Контракты и так далее. Конечно, генетические алгоритмы, являющиеся общим местом именно в поиск-ориентированной инженерии, не единственный свет в окошке. Работают и другие методы гибридного вывода (вычисления в логике -- вывод, но тут не только логика, так что можно говорить и про "гибридные вычисления") для того, что раньше было вывести/вычислить нельзя -- вычислений оптимальных технических решений.
Так, тот же проект DANSA (https://www.danse-ip.eu/home/index.php/info-material/deliverables) использует новый стандарт Goals and Contracts Specification Language (GCSL, https://www.danse-ip.eu/home/index.php/77-danse/109-gcsl). Стандарт базируется на существующих исследованиях по контрактам -- формальным спецификациям модулей на логическом языке и привязывается к SysML/OCL http://arxiv.org/pdf/1311.3631.pdf или другим логическим языкам -- https://project.inria.fr/plasma-lab/gcsl/). Интересно, что контракты когда-то тоже были предложены в программировании (причём contract programming предложил Бертран Мейер, который вошёл и в Тройку SEMAT/Essence -- узок круг этих революционеров).
The idea is to use a requirement language more understandable than raw logic. GCSL requirement would then be translated into a low-level logic. The GCSL is a text-pattern based specification language with an formal semantics given by a temporal logic. This bridges the gap between natural language requirements and formal requirements and supports thereby the requirement formalization process. A early formalization allows reasoning about a architecture before the components are available.
После описания целей и контрактов делается синтез и оптимизация архитектуры, соответствующей целям и контрактам (методология DANSA изложена тут: https://www.danse-ip.eu/home/images/deliverables/danse_d4.3_methodology_v2.pdf, кратенько диаграммки работы с софтами для этой технологии -- http://tx.technion.ac.il/~gordoncn/2013/Henry%20Broodney.pdf).
Интересны также и сдвиги в терминологии. Раньше все эти "генетические алгоритмы" и "обучаемые нейронные сетки" безусловно относились к тематике artificial intelligence. Сегодня ищутся новые слова. Так, новый термин, лежащий под всеми этими методами поиска решений в огромных их пространствах -- "искусственное воображение" (http://en.wikipedia.org/wiki/Artificial_imagination). Термин относительно старый, но используется всё более и более широко (вот, например, это пиарится недавно хорошо продавшимся Vicarious -- http://www.wired.com/2014/04/vicarious-ai-imagination/, хотя они в about используют более аккуратные формулировки: http://vicarious.com/about.html).
Ещё одно направление, где компьютер используется для непосредственного размышления над инженерным проектом, а не документирования размышлений человека-инженера -- это generative design (и по сопричастности generative manufacturing). Исторически тут больше идёт "воображение формы", 3D моделирование и главным образом используются 3D САПРы. Но это направление работ также связано с синтезом модели (3D модели в данном случае).
5. Компьютерный поиск (порождение, вывод, вычисление) требований, архитектуры, тестов -- это и есть следующее поколение системной инженерии, непосредственно следующее за переходом к моделеориентированности.
Для этого нужно искусственное инженерное воображение (экономная генерация всё более и более подходящих вариантов инженерных решений) и искусственный инженерный вкус (умение оценить эти варианты).
Во всех случаях для инженерии необходимо использовать гибридные (численные+логические) выводы/вычисления -- ибо железка в конечном итоге описывается в терминах структур системы (компонент, модулей, размещений в их иерархиях) и численных параметров (физических свойств), и нужно работать не только с логическими и не только с мультифизическими моделями, но и с их гибридами. В конце концов, архитектура системы получается путём нахождения (поиска, воображения, а хоть и искусственного) совмещения логической/функциональной и физической архитектур, то есть логического идеального структурного мира с грубым материальным численно описываемым физическим миром.
1. Классическая системная инженерия, в которой чертежи и диаграммы даны "картинками" (то есть недоформализованы, компьютер отрабатывает их как наборы линий, а не наделённые смыслом модели), знание оформляется главным образом документацией, текстами с картинками. Расчёты даны в виде бумажных описаний, отражающих проведённые самым разным способом (от логарифмической линейки и калькулятора до различных компьютерных программ) вычисления. Это сегодня мейнстрим, текущая действительность.
2. Моделеориентированная (model-based systems engineering) это текущая цель INCOSE, ближайшее будущее. Формализация рабочих продуктов определения системы, прежде всего архитектурных описаний -- для целей верификации принятых конструкторских решений и объединения различных решений в одно. Ключевые тут моделеры и имеющиеся в них солверы: солверы геометрические, солверы системы уравнений в Modelica.
Эпицентром всей этой работы сейчас является архитектурный язык SysML в связке с языком мультифизического моделирования Modelica, которую обеспечивает стандарт OMG SysML-Modelica Transformation (SyM, http://www.omg.org/spec/SyM/, рабочая группа http://www.omgwiki.org/OMGSysML/doku.php?id=sysml-modelica:sysml_and_modelica_integration, это преобразование идёт для некоторых продуктов в обе стороны, а для некоторых только в одну сторону и есть даже open source реализации -- https://github.com/SysMLModelicaIntegration).
Это всё развитие линии объект-ориентированного моделирования, но в этой связке уже налицо явный ход на гибридные вычисления:
-- численные методы интегрировали в объектный язык (Modelica), используется главным образом для компонентного моделирования (принципиальные схемы самого разного толка, вплоть до экономических моделей).
-- SysML это профиль UML, для них можно прописывать ограничения в логическом языке OCL (а сами они "написаны на" OMF). Это структурные модели, главным образом ориентированные на описание модульной структуры, можно прописывать и интерфейсы и протоколы.
Киберфизические системы (а именно, авионика) больше поддерживаются архитектурным языком AADL, и там те же тренды на связь с Modelica (http://link.springer.com/chapter/10.1007%2F978-3-642-41674-3_13, http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=6662050&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D6662050).
Конечно, есть связки и с геометрическими моделями (компоновками, размещениями) -- но там сложней, ибо для геометрического представления нет явных лидеров стандартизации, каждый 3D САПР сам себе стандарт.
Отдельная задача -- это интеграция моделей жизненного цикла (я определяю модели жизненного цикла так же, как и данные жизненного цикла -- модели, которые порождаются и используются в какой-либо момент прохождения системой её жизненного цикла). Тут начинает побеждать семантический подход и онтологии:
-- ISO 15926, который тут не нужно комментировать специально.
-- работы по архитектуре семантической интеграции данных системноинженерных моделей DANSA (Designing for adaptability and evolution in system of systems engineering) для случая, когда моделирование шло для независимо разрабатываемых систем (системно-системная инженерия), и нельзя ожидать использования общего для всех инструментария моделирования и предписанной последовательности использования инструментов (Tool Chain). В этом случае говорят о Tool-Net (сети инструменов) и semantic mediation (основанной на стандартах Semantic Web): https://www.danse-ip.eu/home/images/deliverables/danse_d8.1.3_conceptual_and%20architecture%20principles_of_sos_design_and_semantic_interoperability_of_systems_platform_and_sos_design_tool_net.pdf, http://www.iltam.org/files/the-voice-of-the-systems-en-dec.2013.web.pdf (работа заняла первое место на INCOSE International Workshop 2013г.).
-- OSLC стандарт семантического объединения данных жизненного цикла (Open Services for Life Cycle Collaboration -- "lifecycle intergration inspired by the web"): http://open-services.net/, который широко использует IBM, Atlassian и прочие производители систем управления изменениями/issue trackers --http://open-services.net/software/. Эта работа сейчас уходит в комитеты по стандартизации OASIS.
Итак, моделеориентированная системная инженерия заканчивается в тот момент, когда вам удалось объединить все имеющиеся модели и софт солверов: вы можете определить вашу систему и по результатам моделирования понять, как она себя поведёт в тех или иных условиях.
А дальше начинается самое интересное: что происходит в тот момент, когда модель уже есть?
3. Поиск-ориентированная системная инженерия (search-based systems engineering), исследуемое пока программистами наше более далёкое инженерное будущее. Если честно, то сейчас существует только search-based software engineering (SBSE, термин появился в 2001 году). Обзоры:
-- краткая справка: http://en.wikipedia.org/wiki/Search-based_software_engineering
-- http://www.infoq.com/presentations/sbse-search-based-software-engineering (слайды и видео полуторачасовой презентации),
-- http://seams2014.uni-paderborn.de/downloads/Harman_Keynote_slides.pdf,
-- тьюториал и "таксономия" в http://www0.cs.ucl.ac.uk/staff/mharman/laser.pdf,
-- репозиторий свежей литературы по теме (сейчас порядка 1200 работ): http://crestweb.cs.ucl.ac.uk/resources/sbse_repository/
-- ежегодный симпозиум (конечно, с challenge -- современная прикладная наука соревновательна): http://ssbse.org/
Конечно, для SBSE есть и много других названий и ключевых слов:
-- Metaheuristics &Software Engineering (метаэвристики -- это эвристики об инженерных эвристиках. Помним, что инженерия базируется не на науке, а на эвристиках, как хорошо показано в работах Billy Koen об инженерном методе): http://neo.lcc.uma.es/mase/
-- Dynamic Adaptive Automatied Software Engineering (проект четырёх британских университетов): http://daase.cs.ucl.ac.uk/
-- Genetic and Evolutionary Computation -- http://www.sigevo.org (и там можно поглядеть в success stories -- http://www.sigevo.org/wiki/tiki-index.php?page=Success%20stories).
Основные темы - тестирование и отладка (порядка половины всех работ), дальше проектирование (например, качественная модуляризация), требования/спецификации (какими требованиями пренебречь с минимальным ущербом для пользы) и так далее по всему списку практик жизненного цикла (включая практики самого управления жизненным циклом и операционного управления, в том числе оценки риска срыва сроков проекта).
Это уже проходилось много раз: идеи начинаются в software engineering, а затем с некоторым лагом приходят в системную инженерию. Мы просто считаем, что этот лаг можно сокращать сознательно. Мы уже начали это делать с OMG Essence, так почему же это не делать с Search-Based Software/Systems Engineering? Конечно, переход от "программ" к "железу" много чего поменяет, но рано или поздно этим переходом нужно будет заняться, так почему не сейчас?
Если в моделеориентированной системной инженерии мы формализовали набором моделей сам объект работы инженеров -- целевую систему и подвергали эти модели анализу солверов, то в поиск-ориентированной системной инженерии мы формализуем также и синтетические практики системной инженерии: инженерии требований, инженерии системной архитектуры и инженерии проверки и приёмки.
Прежде всего, нужно указать на возможность постановки всех расчётных и даже геометрических моделей (которые тут тоже можно считать "расчётными") под управление оптимизатора. Это самый простой случай. Настолько простой, что его часто даже не считают следующим поколением системной инженерией, а просто частным примером использования методов моделе-ориентированной системной инженерии.
Но вот если мы хотим, чтобы менялись не параметры модели, а сами модели определения системы, их структура -- это совсем другое дело. Человек при этом будет задавать (функциональные) требования, а вот модели для удовлетворения этих требований с учётом всех возникающих технических противоречий, будет делать компьютер. То есть мы задаём пространство технических решений, и будем искать в этом пространстве оптимальные решения -- "поиск" технических решений тут ключевое слово. Отсюда и search-based systems engineering.
Тем самым по сравнению с моделе-ориентированной системной инженерией для компьютерного поиска решений нужно дополнительно формализовать предмет системной инженерии:
-- формализовать пространство решений
-- предъявить формальные количественные и качественные (любимый пример -- формализовать понятие "элегантности" для архитектуры) критерии к результату
4. Контракты и так далее. Конечно, генетические алгоритмы, являющиеся общим местом именно в поиск-ориентированной инженерии, не единственный свет в окошке. Работают и другие методы гибридного вывода (вычисления в логике -- вывод, но тут не только логика, так что можно говорить и про "гибридные вычисления") для того, что раньше было вывести/вычислить нельзя -- вычислений оптимальных технических решений.
Так, тот же проект DANSA (https://www.danse-ip.eu/home/index.php/info-material/deliverables) использует новый стандарт Goals and Contracts Specification Language (GCSL, https://www.danse-ip.eu/home/index.php/77-danse/109-gcsl). Стандарт базируется на существующих исследованиях по контрактам -- формальным спецификациям модулей на логическом языке и привязывается к SysML/OCL http://arxiv.org/pdf/1311.3631.pdf или другим логическим языкам -- https://project.inria.fr/plasma-lab/gcsl/). Интересно, что контракты когда-то тоже были предложены в программировании (причём contract programming предложил Бертран Мейер, который вошёл и в Тройку SEMAT/Essence -- узок круг этих революционеров).
The idea is to use a requirement language more understandable than raw logic. GCSL requirement would then be translated into a low-level logic. The GCSL is a text-pattern based specification language with an formal semantics given by a temporal logic. This bridges the gap between natural language requirements and formal requirements and supports thereby the requirement formalization process. A early formalization allows reasoning about a architecture before the components are available.
После описания целей и контрактов делается синтез и оптимизация архитектуры, соответствующей целям и контрактам (методология DANSA изложена тут: https://www.danse-ip.eu/home/images/deliverables/danse_d4.3_methodology_v2.pdf, кратенько диаграммки работы с софтами для этой технологии -- http://tx.technion.ac.il/~gordoncn/2013/Henry%20Broodney.pdf).
Интересны также и сдвиги в терминологии. Раньше все эти "генетические алгоритмы" и "обучаемые нейронные сетки" безусловно относились к тематике artificial intelligence. Сегодня ищутся новые слова. Так, новый термин, лежащий под всеми этими методами поиска решений в огромных их пространствах -- "искусственное воображение" (http://en.wikipedia.org/wiki/Artificial_imagination). Термин относительно старый, но используется всё более и более широко (вот, например, это пиарится недавно хорошо продавшимся Vicarious -- http://www.wired.com/2014/04/vicarious-ai-imagination/, хотя они в about используют более аккуратные формулировки: http://vicarious.com/about.html).
Ещё одно направление, где компьютер используется для непосредственного размышления над инженерным проектом, а не документирования размышлений человека-инженера -- это generative design (и по сопричастности generative manufacturing). Исторически тут больше идёт "воображение формы", 3D моделирование и главным образом используются 3D САПРы. Но это направление работ также связано с синтезом модели (3D модели в данном случае).
5. Компьютерный поиск (порождение, вывод, вычисление) требований, архитектуры, тестов -- это и есть следующее поколение системной инженерии, непосредственно следующее за переходом к моделеориентированности.
Для этого нужно искусственное инженерное воображение (экономная генерация всё более и более подходящих вариантов инженерных решений) и искусственный инженерный вкус (умение оценить эти варианты).
Во всех случаях для инженерии необходимо использовать гибридные (численные+логические) выводы/вычисления -- ибо железка в конечном итоге описывается в терминах структур системы (компонент, модулей, размещений в их иерархиях) и численных параметров (физических свойств), и нужно работать не только с логическими и не только с мультифизическими моделями, но и с их гибридами. В конце концов, архитектура системы получается путём нахождения (поиска, воображения, а хоть и искусственного) совмещения логической/функциональной и физической архитектур, то есть логического идеального структурного мира с грубым материальным численно описываемым физическим миром.