Essence для системной инженерии

(Systems Engineering Essence) [для предварительного обсуждения]

Москва22 мая 2013г.

2

Организационный контекстЭто первое мероприятие из серии обсуждения промежуточных результатов выполнения Roadmap с SEMAT (http://semat.org/?p=863):• 1 августа -- получить ответ на вопрос про онтологический статус моделей и

архитектуры в Essence• 1 сентября -- выложить драфт расширения ядра для системной инженерии

для публичного обсуждения• 1 декабря -- мэппинг основных сущностей системной инженерии в ISO

15926• конец декабря -- выдать продукт Русского отделения INCOSE "Основные

сущности системной инженерии и их мэппинг в ISO 15926".• В текущей серии мероприятий будут:• обсуждение в узком кругу (настоящее заседание, 22 мая 2013г.).• публичное обсуждение на конференции МЭСИ 6 - 7 июня 2013 г. (

http://www.mesi.ru/our/events/detail/121699/) в присутствии Ивара Якобсона (главный идеолог Essence).

• обсуждение на конференции OMG в Берлине http://www.omg.org/news/meetings/tc/berlin-13/info.htm (докладывать будет наш SEMAT liaison Андрей Байда).

3

MBSE

• MBSE is not about SysML (or AADL)• Models and descriptions (formal models and

model checking/verification+generative design/manufacturing + essays)

• 2 level modeling (high level/architectural/systems engineering + design/specialty engineering)

• Central note: architecture and architecture description (ISO 42010)

4

Язык, сущности, практики

...

ЯзыкСущности

(абстрактные)Практики

(конкретные)

...

5

Альфа: состояния = чеклисты : чекпойнтыALPHA -- Abstract-Level Progress Health Attribute.

6

Альфы инженерного проекта

7

Essence and architecture

• Not present in current standard• Need to be in description of systems

engineering methodology (design should be architectural)

• Essence choices:– Architecture is alpha– Architecture is subalpha of alpha “System”– Architecture is pattern

8

Systems Architecture ExtensionArchitecture is “System” subalpha

Pro:• Implementation as Essence kernel extension (not needed OMG

approval, standard extension mechanism)• Architectural design (common nature to other design artifacts:

unification of high and low level modeling)• Design can be subalpha of System too

Conrtra:• Not equal to “Requirements” alpha• Not convenient to systems engineering separation from specialty

engineering • Not distinguishing systems definition from system implementation

9

Systems Architecture Extension(кривое решение)

• This extension provides alpha to help teams to progress their System:• System architecture as a sub-ordinate of System (отношение – “drive”, причём только

для первого состояния “architecture selected”).• States:

– Planned – Systems Engineering Architecture effort planned and have resources– Initial – Architectural Drivers identified (факторы влияния) and Initial architectural model created– Referenced – opportunities for reuse of architectural elements identified– Visioned – candidate architectural visions created and most suitable Vision choosen– Developing – completing and maintained– Accepted – evaluated and agreed as a base for low level modeling– Maintained -- actualised– Generalized – prepared as a reference for future projects --- ??? [это какой альфы?]

• Осталось сформулировать чеклист.

• Но это неудовлетворительно!

10

Arguments for adapting Essence to Systems Engineering

• Hardware (cyberphysics/software-intensive/“atom” with possible humans included) System have other type of lifecycle then bit-composed due to physics constraints.

• V-diagram as a base systems engineering process intuition

• Requirements—Architecture—Design as applying more and more constraints in system implementation decisions.

11

Requirements, Architecture and System

*Requirements defined

System implementation(atoms)

System definition(bit)

*Detailed design

12

Variants

• System description (result of system definition activities) alpha with requirements, architecture and design as subalphas (with GORE, high-level and multiphisics models as work products)

• Architecture and design as first class kernel alphas• Architecture and design as subalpha of system

• Architectue as Patterns (according to Ian Dietz – link between requirements and system)

13

Развилка• Architecture: минимум шума и максимум кривизны: расширение

альфы системы, непосредственное использование ISO 42010 для архитектуры

• Descriptions: максимум шума и кривизны: альфа описания системы (с требованиями-архитектурой-дизайном – но не возможностями, ибо они из области интересов стейкхолдеров). Обобщение описаний прямо из ISO 42010 (дропаем «архитектурные», применяем вплоть до требований и дизайнов + все возможные модели обоснований).

• Проблема: как показываем гибридные модели GORE (ибо там половина модели про opportunities, половина про requirements). Это отражение двух альф в одном рабочем продукте?

14

Двумерное представление ЖЦ: практики, разворачиваемые во времени

определение потребностей

приемка в эксплуатацию

Архитектурное проектирование

рабочее проектирование изготовление

интеграция

валидация

верификация

верификация

definition realization operation

15

Предложение

16

Descriptions

• Descriptions (definitions) = Requirements, Architecture, Design

• Composed from models that grouped by views• Architectural frameworks are subalphas of way-

of-working (but we extend it to system definition frameworks: requirements, architectural, design)

• Architectural languages are subalphas of way-of-working too (usage of a language is a practice)

17

Состояния описания

• Начаты• Сформулированы• Используются для изготовления• Используются для верификации• Используются в следующих проектах

18

V-диаграмма подальф

19

ORIGINS

• Concepts: ISO 42010 – Systems and software engineering — Architecture description

• States: MFESA (Method Framework for Engineering Systems Architecture, as modelled in OPF)

20

ISO 42010

Альфы решения

Подальфы технологии

Рабочий продукт (метод)

21

ISO 42010 – Way of Working(подальфы технологии)

22

MFESA: архитектурные продукты работы

23

MFESA (OPFRO)System architecture engineering typically consists of the following architecting tasks:

• Plan and Resource Architecture Engineering Effort• Identify the Architectural Drivers• Create Initial Architectural Models• Identify Opportunities for Reuse of Architectural Elements• Create Candidate Architectural Visions• Analyze Reusable Components and their Sources• Select or Create Most Suitable Architectural Vision• Complete and Maintain the Architecture• Evaluate and Accept the Architecture• Maintain the Architecture and Its Representations

24

Архитектура по Jan Dietz

25

Спасибо за вниманиеАнатолий Левенчук,http://ailev.ruailev@asmp.msk.su(Президент Русского отделения INCOSE)

Виктор Агроскинvic5784@gmail.com

TechInvestLab.ru(495) 748-53-88