Доклад АнатолияЛевенчука «Essence для системной инженерии: опыт моделирования» на 76 заседании Русского отделения INCOSE (совместно с Русским отделением SEMAT), 22 мая 2013г.

1. 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 Андрей Байда).
2

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)
3

4. Язык, сущности, практики
4
...
Язык
Сущности
(абстрактные)
Практики
(конкретные)
...

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

6. Альфы инженерного проекта
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
7

8. Systems Architecture Extension
Architecture 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
8

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 --- ??? [это какой альфы?]
• Осталось сформулировать чеклист.
• Но это неудовлетворительно!
9

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.
10

11. Requirements, Architecture and System
11
*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)
12

13. Развилка
• Architecture: минимум шума и максимум кривизны:
расширение альфы системы, непосредственное использование
ISO 42010 для архитектуры
• Descriptions: максимум шума и кривизны: альфа описания
системы (с требованиями-архитектурой-дизайном – но не
возможностями, ибо они из области интересов стейкхолдеров).
Обобщение описаний прямо из ISO 42010 (дропаем
«архитектурные», применяем вплоть до требований и дизайнов
+ все возможные модели обоснований).
• Проблема: как показываем гибридные модели GORE (ибо там
половина модели про opportunities, половина про
requirements). Это отражение двух альф в одном рабочем
продукте?
13

14. 14
Двумерное представление ЖЦ:
практики, разворачиваемые во времени
определение
потребностей
приемка в
эксплуатацию
Архитектурное
проектирование
рабочее
проектирование
изготовление
интеграция
валидация
верификация
верификация
definition realization operation

15. Предложение
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)
16

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

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

19. ORIGINS
• Concepts: ISO 42010 – Systems and software
engineering — Architecture description
• States: MFESA (Method Framework for
Engineering Systems Architecture, as
modelled in OPF)
19

20. ISO 42010
20
Альфы решения
Подальфы
технологии
Рабочий продукт
(метод)

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

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

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
23

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

25. 25
Спасибо за внимание
Анатолий Левенчук,
http://ailev.ru
ailev@asmp.msk.su
(Президент Русского отделения INCOSE)
Виктор Агроскин
vic5784@gmail.com
TechInvestLab.ru
(495) 748-53-88