"Стандартизация предмета системной инженерии", доклад А.Левенчука на методологической школе в Юрмале, 22 августа 2014 года

1. Стандартизация предмета системной
инженерии
Анатолий Левенчук
Юрмала
22 августа 2014г.

2. О чём будем говорить
• Методологическое самоопределение докладчика
• Почему стандартизация («объективация» -- shared)
• Справка по дисциплине системной инженерии
• Сюжеты «объектизации» (привнесения новых
объектов)
– Требования
– Архитектура
– Вид жизненного цикла
– Интеграция данных жизненного цикла
• SysMoLan
2

3. Методологическое самоопределение
История:
• считал себя "системным программистом" и "системным архитектором" с
середины 80-х, но не догадывался о специальном значении слова
"системный" и существовании "системной инженерии". Конечно, знал о
существовании системного подхода, но не понимал его сути и действенности.
• узнал о существовании системной инженерии как дисциплины осенью 2007
года, встретившись с особой задачей: удержание целостности при создании
АЭС. Ход был прост: а как удерживают эту целостность на Западе?
• развернул исследования в области методологии системной инженерии в
кооперации с зарубежными организациями (INCOSE, SEMAT)
• получил дополнительную онтологическую экспертизу (POSCCaesar Association,
Ontology Summit) и экспертизу в ситуационной инженерии методов (OPF, ISO
24744, SEMAT).
• нахожусь рядом с СМД-методологией уже 26 лет (с Ростовской игры февраля
1987г.), занимаюсь методологией "в рабочее время" в силу
профессиональной необходимости, но никогда не считал и не считаю себя
сейчас СМД-методологом.
• Обычно занимаю позицию методолога: рынка ценных бумаг, интернет-
сервисов, рыночной электроэнергетики, электронного правительства,
системной инженерии.
3

4. Методологическое
самоопределение
Мои проекты по формулированию предмета
системной инженерии/системноинженерного
мышления:
• создание учебного курса (содержание образования
должно включать знания об объектах предметной
области).
Текущие материалы:
http://techinvestlab.ru/files/systems_engineering_thinking/systems_engineer
ing_thinking--TechInvestLab_2014.pdf
• создание схемного языка системного
моделирования SysMoLan (понятия языка должны
отражать понятия предметной области). Основные идеи:
http://ailev.livejournal.com/1127145.html
4

5. Disclaimer
• Я не СМД-методолог, поэтому необязательно совпадение схем
и терминологии с терминологией и схемами СМДМ. Про
«объективацию» я не могу рассказать, но расскажу про
осознание системными инженерами собственной дисциплины.
• Мнение автора по поводу системной инженерии не совпадает с
мнением системных инженеров, стандартов и т.д.. Ругать нужно
отдельно мысли автора, и отдельно системную инженерию. [по
опыту предыдущих обсуждений]
• Системная инженерия это вовсе не «обзывание новыми
словами давно известной со времён СССР деятельности».
Отнюдь. Но это предмет другого доклада.
• Социотехнические (кибер-физико-человеческие) системы
затронуты по-минимуму, равно как и проблемы системо-
системной инженерии. Изложение ограничено рамками
классической «железной» системной инженерии (автомобили,
самолёты, подводные лодки и прочий транспорт).
5

6. Стандартизация как место
онтологической работы в 21 веке
Рассказывал об этом и раньше:
• Подробный доклад на XV щедровицких
чтениях 2009,
http://ailev.livejournal.com/664154.html (и есть
публикация в материалах чтений)
• Реплика на XVIII чтениях, 2012:
«институализация это стандартизация по
сути», http://ailev.livejournal.com/982274.html
• Доклад «организации стандартизации как
протопарламенты» на Лебедевских чтениях --
http://g-l-memorial.ice.ru/322014
6

7. Стандарты и построение
дисциплина (объективация:)
• Предмет: ответ на вопрос «что есть в мире»
(онтика, часто называют онтологией, путают с
онтологическим описанием).
• Онтология – это разделяемая людьми (shared)
спецификация концептуализации (Том Грубер)
• Стандарты дают:
– По форме – спецификацию (т.е. онтологическое
описание)
– какую-то гарантию разделяемости людьми (т.е.
коллективную работу по проверке описания)
– проверяемы использованием в деятельности
7

8. Причины появления стандартов
в системной инженерии
• Цеховая работа:
– Нормирование «правильной деятельности»,
соответствия дисциплине (сертификация, и только)
– ISO 15288
– Обучение и аттестация (трансляция предмета
системной инженерии): Systems Engineering
Handbook, Systems Engineering Body of Knowledge
• Необходимость соорганизации деятельности
разных стейкхолдеров: онтологические
стандарты.
8

9. Стандарты системной инженерии
• «Обычные» (ISO 15288), намёк на схемы
(ISO 24774)
• Предлагающие схемы и стандарты
схематизирования (ISO 42010, OMG Essence,
ArchiMate)
• Онтологические aka модели данных,
полноценное моделирования (ISO 15926,
«стандарты де-факто» современных PLM)
9

10. 10
«Процесс»
«Процедура»
«Функция»
«Деятельность»
«Шаблон проекта»
ПланировщикМенеджер
по качеству
Менеджер
Консультант
Аналитик
По материалам
компании FutureModels
От речевых сообществ к сообществам значений

11. PP656.11
Международные стандарты сложны
Размещено с разрешения FIATECH
Не хочу видеть никаких сумасшедших торговцев –
ты что, не видишь, что тут битва идёт!

12. Системная инженерия
Как удерживать целое?! -- системноинженерное
мышление и управление жизненным циклом
Как создать успешную систему?! – практики системной
инженерии
12
Systems Engineering (SE) is an interdisciplinary approach and means to enable the realization of successful systems. It focuses on holistically and
concurrently understanding stakeholder needs; exploring opportunities; documenting requirements; and synthesizing, verifying, validating, and
evolving solutions while considering the complete problem, from system concept exploration through system disposal.
http://www.sebokwiki.org/1.0.1/index.php?title=Systems_Engineering_%28glossary%29

13. Ситуационная инженерия методов
• Как говорить о дисциплине?
• Инженерия методов, ситуационная инженерия методов
• Как узнать: Body of Knowledge (SEBoK),
практики/processes (ISO 15288 – ISO 24774). Каждый
изобретает «язык» ситуационной инженерии методов.
• Первое поколение стандартов: стандартизация языка
(OPF, ISO 24744, SPEM 2.0).
• Второе поколение стандартов OMG Essence (2013): язык
и дисциплина + контрольные вопросы
• Software Engineering Essence
• Systems Engineering Essence
13

14. Проблемы с языками первого
поколения
Сложны в использовании, требуют сложного софта:
• Ориентированы на методологов, а не применяющих. Ответом будет
упрощённый «карточный синтаксис» и рекомендации по процедурам
использования (карточным играм).
Даётся только язык, но не «общая земля» (общие реалии проекта,
используемые всеми практиками и методами).
• практики и методы оказываются несопоставимы друг с другом! Команда из
людей, практикующих разное, не может быть составлена без долгих
переговоров и недопониманий. Ответом будет упор не на рабочие
продукты, а на модель предметной области инженерии -- онтологию
инженерной дисциплины. Вводятся основные идеальные объекты-альфы
(альфы, деятельности/пространства операций, компетенции), имеющиеся
во всех проектах.
Это впрямую заявка на определение основных объектов (программной)
инженерии.
Откуда брали «общие объекты»? Вручную просмотрели порядка 250
методологий разработки «из интернета»!
14

15. Соглашение о терминологии
(“язык” по мотивам OMG Essence)
• Дисциплина – основные сущности
(идеальные объекты, alpha) предметной
области, типовые деятельности с ними
(activity spaces), компетенция
[“объективация” тут]
• Технология – рабочие продукты и операции
• Практика = дисциплина + технология
• Метод = достаточный для достижения цели
набор практик
15

16. Язык, практика, дисциплина, технология
16
...
Язык
Дисциплина
(абстракции)
Технология
(конкретности)
...
Практика

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

18. Адаптация к системной
инженерии
• Работа Русского отделения INCOSE в кооперации
с SEMAT
• Опора на V-diagram, как основную схему
системной инженерии
• Главное: разделение на определение системы и
воплощение системы
18

19. V-диаграмма сущностей инженерного решения
19
Подальфы
определения
системы
проверка
проверка

20. Дисциплины системной
инженерии
• [моделеориентированная] инженерия требований
• [моделеориентированная] инженерия системной
архитектуры
• [моделеориентированные] проверка и приёмка
(V&V)
• [моделеориентированный] системноинженерный
менеджмент (управление жизненным циклом)
• В ситуационной инженерии методов обычно более
мелкое деление (ISO 15288)
20

21. Подпредметы и основные
объекты системной инженерии
Главный объект – реализация системы
Определения системы:
• Определение черного ящика – требования
• Определение прозрачного ящика – архитектура
Реализация системы
• Соответствие различных определений, определений и реализации –
испытания/тесты (проверка и приёмка)
Менеджмент системноинженерной деятельности – обеспечивающая система
• Обеспечение метода (практик работы) -- жизненный цикл (project model)
• Обеспечение целостности --конфигурация (product model), изменения
(issues)
21

22. Требования к системе
system requirement
Подальфа определения системы:
определение системы как чёрного ящика.
• Путаница: инженерия требований vs. управления
требованиями
• Ещё путаница: stakeholders needs, stakeholder
requirements, system requirement, constraints,
деонтическими высказываниями. Близки: цели, use
cases.
• Стейкхолдеров много, им нужно договориться о
том, какую систему делаем. ИХ ТРЕБОВАНИЯ
ПРОТИВОРЕЧИВЫ!
• Стандартизовать «управление»: доступ,
конфигурация, изменения… 22

23. Стандарты представления
требований
Текстовые строчки:
• SysML
• AP233
• RIF
• ISO 29148
• Форматы представления в DOORS, IRQA
Проблема: обрывки текста продолжают быть неоднородными по
своей природе, и – дьявол! – противоречивы! Нужно эту
противоречивость хоть как-то представлять!
GORE с выходом на выражение оппозиции «цель-средства» [дисциплина определяется тут – цели
взаимно определяют средства, требования взаимно определяют архитектуру]
• Social modeling for requirements engineering: i*framework – agent- and goal-oriented
• ITU Z.151 (URN=GRL+UCM) [i*]
• Motivation models в инженерии предприятий: BMM, расширение ArchiMate,
• MBRD
• Planguage
23
Наш вывод: требования – подальфа определения системы

24. 24
Метамодель MBRD
Требование
удовлетворяет
Словарь
определяет
термины в
реализует
Цель
Владеет
Обоснование
обосновывает
КачествоФункция Ограничение
Заинтер. сторона
Неоперационная
Операционная *
Измерение
делает
проверяемым
Испытание
реализует
проверяет
противоречит,
способствует
Сценарий
играет роль в
реализует
Обычная
Препятствие/
Угроза
угрожает
смягчает
Приоритет
приоритизирует
До решения
После
решения
включает
производит
Граничное
событие
Интерфейс
имеет событие
ИсходящееВходящее
Система
имеет интерфейс
указывает
объясняет
Развилка
использует как критерий
оценивает
варианты
создает
* Операционные= вовлеченные в эксплуатацию, но не обязательно
взаимодействующие с продуктом «акторы»(с) Ян Александер, 2010

25. 25
Практики в MBRD
Анализ
заинтересованных
сторон
Моделирование
контекста
Моделирование
целей
Приоритезация
Написание требований,
повторное
использование,
шаблоны, стандарты
Анализ
обоснований
Анализ
развилок
Анализ
словаря
Анализ
измерений
Моделирование
сценариев
23
(с) Ян Александер, 2010

26. 26
Валидация требований на основе
модели
• Убедиться в том, что для всех объектов модели:
– Цель принадлежит какой-то Заинтересованной стороне
– Операционное заинтересованное лицо играет роль в Сценарии
– Цели приоритизирована определенным Приоритететом
– Высокоприоритетные цели используются как критерии при выборе
Развилок
– Конфликты между целями устраняются в процессе прохождения
Развилок
– Препятствия/Угрозы смягчаются Целями
– Цель удовлетворяется Требованием
– Требование делается проверяемым Измерением
– Развилка объясняется Обоснованием
– <Термин>* в Требованиях определяется в Словаре
* <Термин> может быть любым Состоянием, Целью, Операционной ролью,
Измерением
(с) Ян Александер, 2010

27. I* -- задаёт тон в GORE
http://www.cs.toronto.edu/km/istar/
Goal-oriented requirements engineering
1995г.: Agents attribute intentional properties (such as goals, beliefs, abilities, commitments)
to each other and reason about strategic relationships. Dependencies between agents give rise
to opportunities as well as vulnerabilities. Networks of dependencies are analyzed using a
qualitative reasoning approach. Agents consider alternative configurations of dependencies to
assess their strategic positioning in a social context.
Стандарты: 2008г. ITU-T Z.151 (Goal-oriented Requirements Language + Use Case Maps)
27

28. Motivation model ArchiMate 2.0
[инженерия предприятия – поддисциплина системной инженерии]
28

29. Архитектура системы
определение «прозрачного ящика»
• Раньше: от требований к дизайну
• Сейчас: от требований к архитектуре, потом
неархитектурным решениям (дизайн
поделили на архитектуру и неархитектурные
решения)
• Проблема: конструкция следует из функции
(форма следует из функции), как в
архитектуре. Но что это не в инженерии? И как
это выразить?
• Консенсус зафиксирован на сегодня в ISO
42010 – схемное введение понятия
29

30. Архитектура
• Как документировать
крыло птицы для того,
кто не знает, что это
такое? Там ведь
огромное количество
разноуровневых
структур, повторения с
вариациями, критические
для полёта качества
элементов и свойства
крыла, невыводимые из
свойств отдельных его
частей.
• Практика: инженерия
системной архитектуры.
30

31. Для чего используется архитектура?
• Рассуждения о системе для команды проекта
(«архитектурные описания для инженеров как
шахматная доска для игроков в шахматы»).
– («шахматная доска для зрителей и судей»).
• Архитектурную работу можно делать плохо, а
можно хорошо (но делается она в любом
случае). Чтобы её делать хорошо, нужно её
обсуждать специально, знать лучшие
архитектурные практики!
31

32. Определение архитектуры
• Из ISO 42010: Архитектура (системы) – основные понятия или
свойства системы в её среде, заключающиеся в её элементах, их
отношениях и принципах её проектирования и развития.
• Architecture (of a system) – fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the
principles of its design and evolution
• Из книжки Garlan et al.: Архитектура системы это набор структур,
необходимых для рассуждений о системе, каковые структуры состоят
из элементов, отношений и свойств этих элементов и отношений.
• The architecture of a system is the set of structures needed to reason about the system, which comprise software elements, relations among
them, and properties of both.
• Набор из более чем 150 определений:
http://www.sei.cmu.edu/architecture/start/glossary/community.cfm
• Выражается в архитектурных описаниях (рабочих продуктах).
• Архитектура у системы есть всегда, но не всегда при разработке
тщательно делаются архитектурные описания («устная архитектурная
традиция» -- заделы, опыт, наработки. Архитектурные решения
передаются из уст в уста, «народный эпос»).
• Итого: важно, какие типы структур системы
документируются, какие принципы
проектирования/конструирования и развития
документируются. 32

33. Альтернативное определение
Архитектура – это обо всём
важном. Что бы это ни было.
Ralf Johnson
33

34. Архитектурные и
неархитектурные решения
34
• Субъективны – где заканчиваются
архитектурные решения знает только
архитектор системы (системный инженер)
• Относительны – что уже не архитектурные
решения для архитектора системы, то может
быть архитектурными решениями для
архитектора подсистемы
Критерий, где остановиться системному инженеру,
спускаясь (по отношениям часть-целое): там, где вы
• дошли до того уровня деления системы на
элементы, на котором вам кажется, что уже нет
важных ваших решений.
• уже поделили работу между отдельными
исполнителями-разработчиками модулей и
дальше будут их важные решения.

35. Архитектурные знания
• Очень редко архитектурные (важные, требующие
существенных переделок при их изменении)
решения изобретаются заново, чаще они
повторноиспользуемы (т.е. «знания»).
• Архитектурные решения – это чаще всего
накопленные человечеством, отраслью,
организацией, конструктором/проектировщиком
знания.
• Развитие и лидерство в инженерии – это обычно
добавление знаний, предложение новых
архитектур, исходя «из первых принципов».
35

36. Определение системы
36
Функция:
требования
со стороны
использующей
(над)системы
Архитектура
(совмещение
функциональной и
физической
декомпозиции)
Конструкция:
рабочий проект
(изготавливаемые
части) целевой
системы
Описывается
«чёрный ящик»
(реверс-
инжиниринг
системы
использования)
Описывается
«прозрачный
ящик» с
детальностью,
достаточной для
изготовления
Описываются основные
принципы структуры
«прозрачного ящика»,
который выполнит роль
«чёрного ящика»
Фокусирование (сужение пространства решений)
Архитектурное проектирование/конструирование
«Просто» проектирование/конструирование

37. Определения и описания: альфы и рабочие продукты
(обобщение ISO 42010)
37
Подальфы
технологии
(задаются
стандартами)Подальфы определения системы:
требования, архитектура, рабочка.
Рабочие продукты для них:
• Описания требований,
тематические группы описаний
требований, модели требований
• Архитектурные описания,
тематические архитектурные
группы описаний, архитектурные
модели
• Рабочие описания, тематические
группы рабочих описаний, рабочие
модели
view viewpoint
definition realization

38. Архитектурные описания: ISO 42010
38

39. Архитектурные описания: что
поменялось за тридцать лет (1984-2014)?
По сравнению с советским способом производства сейчас на Западе:
• Системная архитектура и архитектурные описания обсуждаются явно («объекты
первого класса»), выделена профессиональная позиция системного архитектора,
устоялась терминология, вышли стандарты (ISO 42010, ISO 15288 и т.д.)
• От описаний неформальных к формальным (понимаемым компьютером,
выраженных на языке моделирования)
• От отдельных непровязанных групп описаний к провязанным (в компьютере, а не
«в голове»)
• От описаний мультифизических («аналоговых») к добавлению структурных
(«дискретных»)
• Появление объект-ориентированных и акаузальных (декларативных,
непроцедурных) языков моделирования – облегчение накопления структурного
знания, создание библиотек.
• Расчётные обоснования архитектурных выборов (множество методов), первые
эксперименты по компьютерной оптимизации архитектуры
• От малого числа методов описаний (3-5) к большому их числу (18-26).
• Упор на повторноиспользуемость, открытость архитектуры (NATO), модульность
конструкций (переход от интеграционных к объединительным технологиям:
больше роль проектирования, чем конструирования)
39

40. ISO 81346
40
На основе рис.3
в ISO 81346-1

41. Множество разбиений
(отношения «часть-целое»)
41

42. Совмещение логической и физической архитектур
по версии ISO 81346-1
Figure 7
42
«Логическая архитектура»
(функциональная
декомпозиция, структура
компонент) итеративно
совмещается с «физической
архитектурой» (продуктная
декомпозиция, структура
модулей)

43. Сколько «базовых структур» в системе?
• ISO 15926 – две основных: функциональные объекты,
физические объекты. Остальные могут вводиться по
потребности.
• ISO 81346 – «по меньшей мере» три (функция, продукт,
место)
• Garlan et. al – три стиля (компоненты, модули,
размещения, и разные варианты структур внутри стиля)
• СМД-методология – «по меньшей мере» пять
(процессы, элементы и связи, внешние функции,
морфология, материал) -- http://www.mmk-documentum.ru/glossary/6
• …
43

44. Базовые структуры определения системы
• =Компоненты
• -Модули
• +Места
• Огромное число вариантов представления каждого.
• Это только базовые, есть огромное число других!
• В чистом виде не бывают, распространены гибридные
стили.
44

45. Примеры компонентных описаний
45

46. Компоненты (и соединения)
• = (префикс для обозначения в ISO 81346)
• Взаимодействующая с другими часть системы.
• Интерес: «как оно работает» (runtime, operation,
функционирование)
• Не интерфейсы, а «порты» связей с другими
элементами. Компоненты взаимодействуют друг с
другом не непосредственно, а только через связи-
соединения.
• Чаще всего компоненты и соединения выражаются
«схемой».
• Важная практика: мультифизическое
моделирование (по схеме проводятся расчёты
«режимов» и характеристик отдельных
компонентов – используются солверы, иногда
поставленные под контроль оптимизатора).
46

47. Примеры модульных описаний
47
FR160B PCB 2-Layer
USB Portable Power
Module -- - Green (3.5
x 2.6 x 1.5cm)
Model FR160B
Quantity 1
Color Green
Material PCB
Features
Input: 5V/800mA;
Output: 5V/1A; LED
lightening; With
protection board on
COB; Output current
limited protection
Application Great for DIY project
Other
ON (Press button) / OFF
(Automatically)
Packing List 1 x Module

48. Модули
• - (префикс для обозначения в ISO 81346)
• Элемент конструкции, продукт, сборочная единица.
• Интерес: что нужно разрабатывать и изготавливать
(время разработки и изготовления, но не работы
системы).
• Что от чего зависит (отношение «зависит») в плане
разработки.
• Имеет интерфейс, у которого есть «видимость»
(доступность). Зависимый элемент имеет слот с таким
интерфейсом.
• Важная практика: Dependency Structure Matrix (DSM).
• Модуль может присутствовать во многих компонентах.
48

49. Размещения
• + (префикс для обозначения в ISO 81346)
• Место установки в системном окружении
(здании, комнате, отсеке, серверной стойке)
• Место транспортировки (например, в каком
ящике), место хранения (например, на
позиция складского хранения)
• Где будет производиться или проектироваться
• …
49

50. Гибридные описания
• Чистых видов описания не бывает: смесь самых разных в одном
тексте, таблице, диаграмме, схеме, чертеже.
• Онтологов мало, поэтому не ждите какого-то формализма там,
где его нет.
• Терминология не устоялась, поэтому ожидайте встретить самую
разную (модулем могут назвать компоненту, а компоненту
элементом, слот техпозицией и т.д.).
50

51. Практики системного проектирования
• Их множество (см. обзор в первой главе книги М.Левина
«Технология поддержки решений для модульных систем»:
http://www.mslevin.iitp.ru/Levin-bk-Nov2013-071.pdf)
• У всех один «недостаток»: хорошему инженеру эти методы
помогают, плохому инженеру они помочь не могут.
• Наиболее известны ТРИЗ и DSM (практикуются во многих
центрах разработки). Но есть огромное число методов,
практикующихся в рамках одной-двух лабораторий (реже –
центров разработки).
• На сегодня наиболее активно развиваются компьютерные
методы не только «проверочных архитектурных расчётов»,
но и методы оптимизации (выбора оптимальной
архитектуры).
51

52. ТРИЗ
• Противоречия: приёмы ТРИЗ, «грозовая туча» TOC,
СМДМ.
• ТРИЗ: попытка «открыть паттерны» (а не изобрести
способы) – законы развития технических систем,
патентные обобщения
• Нельзя научить «просто инженеров», но можно
научить хороших инженеров. Есть сертификация,
уровни мастерства и т.д.
• За рубежом известна сейчас уже больше, чем в
России. Изучается в ВУЗах (курс системной
инженерии в MIT), самый знаменитый пример –
массовое использование в Samsung.
• Кроме принципов нахождения противоречий в
ТРИЗ есть и много чего другого.
52http://ru.wikibooks.org/wiki/%D0%9E%D1%81%D0%BD%D0%BE%D0%B2%D1%8B_%D0%A2%D0%A0%D0%98%D0%97

53. 40 приёмов устранения системных противоречий
• 1. Принцип дробления:
а) разделить объект на независимые части;
б) выполнить объект разборным;
в) увеличить степень дробления объекта.
• 2. Принципвынесения:
отделить от объекта “мешающую” часть (“мешающее” свойство) или, наоборот, выделить единственно нужную часть (нужное свойство).
• 3. Принципместного качества:
а) перейти от однородной структуры объекта (или внешней среды, внешнего воздействия) к неоднородной;
б) разные части объекта должны иметь (выполнять) различные функции;
в) каждая часть объекта должна находиться в условиях, наиболее благоприятных для ее работы.
• 4. Принципасимметрии:
а) перейти от симметричной формы объекта к асимметричной;
б) если объект асимметричен, увеличить степень асимметрии.
• 5. Принципобъединения:
а) соединить однородные или предназначенные для смежных операций объекты;
б) объединить во времени однородные или смежные операции.
• 6. Принципуниверсальности:
объект выполняет несколько разных функций, благодаря чему отпадает необходимость в других объектах.
• 7. Принцип“матрешки”:
а) один объект размещен внутри другого, который, в свою очередь, находится внутри третьего и т. д.;
б) один объект проходит сквозь полости в другом объекте.
• 8. Принципантивеса:
а) компенсировать вес объекта соединением с другим, обладающим подъемной силой;
б) компенсировать вес объекта взаимодействием со средой (за счет аэро- и гидродинамических сил).
• 9. Принциппредварительного антидействия:
а) заранее придать объекту напряжения, противоположные недопустимым или нежелательным рабочим напряжениям;
б) если по условиям задачи необходимо совершить какое-то действие, надо заранее совершить антидействие.
• 10. Принцип предварительного действия:
а) заранее выполнить требуемое действие (полностью или хотя бы частично);
б) заранее расставить объекты так, чтобы они могли вступить в действие без затраты времени на доставку и с наиболее удобного места.
• 11. Принцип “заранее подложенной подушки”:
компенсировать относительно невысокую надежность объекта заранее подготовленными аварийными средствами.
• 12. Принцип эквипотенциальности:
изменить условия работы так, чтобы не приходилось поднимать или опускать объект.
• 13. Принцип “наоборот”:
а) вместо действия, диктуемого условиями задачи, осуществить обратное действие;
б) сделать движущуюся часть объекта или внешней среды неподвижной, а неподвижную — движущейся;
в) перевернуть объект “вверх ногами”, вывернуть его.
• 14. Принцип сфероидальности:
а) перейти от прямолинейных частей к криволинейным, от плоских поверхностей к сферическим, от частей, выполненных в виде куба и
параллелепипеда, к шаровым конструкциям;
б) использовать ролики, шарики, спирали;
в) перейти от прямолинейного движения к вращательному, использовать центробежную силу.
• 15. Принцип динамичности:
а) характеристики объекта (или внешней среды) должны меняться так, чтобы быть оптимальными на каждом этапе работы;
б) разделить объект на части, способные перемещаться относительно друг друга;
в) если объект в целом неподвижен, сделать его подвижным, перемещающимся.
• 16. Принцип частичного или избыточного действия:
если трудно получить 100% требуемого эффекта, надо получить “чуть меньше” или “чуть больше” — задача при этом существенно упростится.
• 17. Принцип перехода в другое измерение:
а) трудности, связанные с движением (или размещением) объекта по линии, устраняются, если объект приобретает возможность перемещаться
в двух измерениях (т. е. на плоскости). Соответственнозадачи, связанные с движением (или размещением) объектов в одной плоскости,
устраняются при переходе к пространству в трех измерениях;
б) использовать многоэтажную компоновку объектов вместо одноэтажной;
в) наклонить объект или положить его “на бок”;
г) использовать обратную сторону данной площади;
д) использовать оптические потоки, падающие на соседнюю площадь или обратную сторону имеющейся площади.
• 18. Принцип использования механических колебаний:
а) привести объект в колебательное движение;
б) если такое движение уже совершается, увеличить его частоту (вплоть до ультразвуковой);
в) использовать резонансную частоту;
г) применить вместо механических вибраторов пьезовибраторы;
д) использовать ультразвуковые колебания в сочетании с электромагнитными полями.
• 19. Принцип периодического действия:
а) перейти от непрерывного действия к периодическому (импульсному) ;
б) если действие уже осуществляется периодически, изменить периодичность;
в) использовать паузы между импульсами для другого действия.
• 20. Принцип непрерывности полезного действия:
а) вести работу непрерывно (все части объекта должны все время работать с полной нагрузкой);
б) устранить холостые и промежуточные ходы.
• 21. Принцип проскока:
вести процесс или отдельные его этапы (например, вредные или опасные) на большой скорости.
• 22. Принцип “обратить вред в пользу”:
а) использовать вредные факторы (в частности, вредное воздействие среды) для получения положительного эффекта;
б) устранить вредный фактор за счет сложения с другими вредными факторами;
в) усилить вредный фактор до такой степени, чтобы он перестал быть вредным.
• 23. Принцип обратной связи:
а) ввести обратную связь;
б) если обратная связь есть, изменить ее.
• 24. Принцип “посредника”:
а) использовать промежуточный объект, переносящий или передающий действие;
б) на время присоединить к объекту другой (легкоудаляемый) объект.
• 25. Принцип самообслуживания:
а) объект должен сам себя обслуживать, выполняя вспомогательные и ремонтные операции;
б) использовать отходы (энергии, вещества).
• 26. Принцип копирования:
а) вместо недоступного, сложного, дорогостоящего, неудобного или хрупкого объекта использовать его упрощенные и дешевые копии;
б) заменить объект или систему объектов их оптическими копиями (изображениями). Использовать при этом изменение масштаба
(увеличить или уменьшить копии);
в) если используются видимые оптические копии, перейти к копиям инфракрасным и ультрафиолетовым.
• 27. Принцип дешевой недолговечности взамен долговечности:
заменить дорогой объект набором дешевых объектов, поступившись при этом некоторыми качествами (например, долговечностью).
• 28. Принцип замены механической схемы:
а) заменить механическую схему оптической, акустической или “запаховой”;
б) использовать электрические, магнитные и электромагнитные поля для взаимодействия с объектом;
в) перейти от неподвижных полей к движущимся, от фиксированных — к меняющимся во времени, от неструктурных — к имеющим
определенную структуру;
г) использовать поля в сочетании с ферромагнитными частицами.
• 29. Принцип использования пневмо- и гидроконструкций:
вместо твердых частей объекта использовать газообразные и жидкие: надувные и гидронаполняемые, воздушную подушку,
гидростатические и гидрореактивные.
• 30. Принцип использования гибких оболочек и тонких пленок:
а) вместо обычных конструкций использовать гибкие оболочки и тонкие пленки;
б) изолировать объект от внешней среды с помощью гибких оболочек и тонких пленок.
• 31. Принцип применения пористых материалов:
а) выполнить объект пористым или использоватьдополнительные пористые элементы (вставки, покрытия и т. д.);
б) если объект уже выполнен пористым, предварительно заполнить поры каким-то веществом.
• 32. Принцип изменения окраски:
а) изменить окраску объекта или внешней среды;
б) изменить степень прозрачности объекта или внешний среды.
• 33. Принцип однородности:
объекты, взаимодействующие с данным объектом, должны быть сделаны из того же материала (или близкого ему по свойствам).
• 34. Принцип отброса и регенерациичастей:
а) выполнившая свое назначение или ставшая ненужной часть объекта должна быть отброшена (растворена, испарена и т. д.) или
видоизменена непосредственно в ходе работы;
б) расходуемые части объекта должны быть восстановлены непосредственно в ходе работы.
• 35. Принцип изменения физико-химических параметров объекта:
а) изменить агрегатное состояние объекта;
б) изменить концентрацию или консистенцию;
в) изменить степень гибкости;
г) изменить температуру.
• 36. Принцип применения фазовых переходов:
использовать явления, возникающие при фазовых переходах, например, изменение объема, выделение или поглощение тепла и т. д.
• 37. Принцип применения теплового расширения:
а) использовать тепловое расширение (или сжатие) материалов;
б) использовать несколько материалов с разными коэффициентами теплового расширения.
• 38. Принцип применения сильных окислителей:
а) заменить обычный воздух обогащенным;
б) заменить обогащенный воздух кислородом;
в) воздействоватьна воздух и кислород ионизирующим излучением;
г) использовать озонированный кислород;
д) заменить озонированный кислород (или ионизированный) озоном.
• 39. Принцип применения инертной среды:
а) заменить обычную среду инертной;
б) вести процесс в вакууме.
• 40. Принцип применения композиционныхматериалов:
перейти от однородных материалов к композиционным.
53

54. Как делить на модули:
Design Structure Matrix (DSM).
• Множество разных имён (Dependency Structure Matrix, Problem Solving Matrix,
Design Precedence Matrix)
• Возможны самые разные анализы (например, помним о законе Конвея – как
разложить дизайн по командам). Может быть Domain Mapping Matrix, а также
Multiple-domain Matrix=DSM+DMM.
• Требует указания значимых межмодульных интерфейсов, потом
математически обрабатывается матрица связности.
54http://www.dsmweb.org/

55. Акаузальное мультифизическое моделирование и
архитектура
55
Модель мотора в Matlab/Simulink (при стыковке блоков модели
требуется переписывание уравнений, блоки не согласованы с
компонентным составом мотора – описание неархитектурно)
Модель мотора в Modelica (не требуется переписывание
уравнений, блоки согласованы с компонентным составом
мотора – описание архитектурно)

56. Жизненный цикл
• Жизненный цикл системы (system life cycle) -- это
деятельность всех обеспечивающих систем,
ведущих целевую систему от её замысла
("рождения" определения системы) до вывода из
эксплуатации ("смерти" воплощения системы),
обычно эта деятельность разбита на стадии (stages),
которые вполне могут быть не только
последовательными, но и перекрываться во
времени друг с другом.
• Жизненный цикл проекта – та часть жизненного
цикла, которая попадает в инженерный проект.
56

57. В какой последовательности и какие
проводятся работы?
• Проблема: кто что в какой момент делает из толпы собравшихся стратегов,
инженеров и менеджеров? Как им договориться, если у каждого есть
собственное представление о деятельности?!
• Стратеги: система и сервисы как деньги, проданные где и когда они нужны;
• Инженеры: содержательные состояния системы и содержательные операции
над ней, «реактор». Case management.
• Менеджеры: логистическая труба, «конвейер» (система и её перемещения по
местам проведения операций, потребление ресурсов). Project management.
• Проблема коммуникации: каков должен быть общий объект «система»?
Управление жизненным циклом (какие практики использовать, «как
работать») инженерная дисциплина, управление проектами (как
логистически выстроить работы, чтобы минимизировать затраты и сделать
все вовремя – менеджерская, как продать – предпринимательская, отчасти
тоже логистическая (последняя доставка, покупатели -- это тоже
покупаемый ресурс).
57

58. Стандарты представления жизненного цикла
• BoK и частные их стандарты (ISO 15288 – ISO 24774)
• Стандарты ситуационной инженерии методов (языки
«методологий разработки»): OPF, ISO 24744, OMG SPEM
2.0,
• Второе поколение: альфы -- OMG Essence.
• Lifecycle modeling language (военные разработки, 2014)
Проблемы жизненные циклы слишком разные, жизненные
циклы отдельных частей проекта несовместимы,
значительные части жизненного цикла системы проходят
вне жизненного цикла проекта:
• Виды жизненных циклов, невиданные ранее: agile, DevOp
из программирования. Примеры agile из инженерии
(SpaceX).
58

59. Что проходит жизненный цикл?
Рабочий продукт или альфа? Или оба?
59

60. Жизненный цикл против проекта
• Жизненный цикл – это кейс из кейс менеджмента, issue
tracking как текущая инкарнация, adaptive case
management как ближайшее будущее.
• Проект – это проект из проектного управления,
диаграмма Гантта и критическая цепь, предсказуемость
и «управляемость».
Проблема: на сегодняшний день стыковки нет. PLM
системы (при проектировании) поддерживают issue
tracking, проектного управления почти нет. Стройка –
проектное управление, issue tracking почти нет.
Стандарты кейс-менеджента почти отсутствуют, стандарты
проектного управления не дают внятных ответов на
вопросы. Дисциплины дрейфуют друг ко другу в части
софта (моделей данных «кейсов с диаграммами Гантта»). 60

61. Системы систем, мягкие системы
Киберфизические системы и
resilience
• Проблема: модель должна быть и в САПР/PLM, и в
самой системе (чтобы обеспечивать resilience –
киберфизика). Классическая системная инженерия
не работает в дикой смеси программной
инженерии, control systems engineering и
собственно системной инженерии.
• Проблема: владеемая одними людьми автономная
система «не хочет» быть частью владеемой
другими людьми надсистемы: классическая
системная инженерия не работает в случае системы
систем.
61

62. Развитие и совершенствование инженерии
62
Р
Е
З
У
Л
Ь
Т
А
Т
Ы
ВРЕМЯ
III поколение
Моделе-ориентированная (model-
based) инженерия: формальные
языки (вычисляемый «код»)
II поколение
Современная («классическая»)
инженерия: диаграммы и
чертежи («псевдокод»)
I поколение
«Алхинженерия»:
неформальные тексты и
эскизы
199018601400
IV поколение
Искусственный
интеллект:
гибридные
вычисления
2020

63. Мечта о формализме
• «Псевдокод» – это когда нет формальной семантики.
• «Код» – это когда есть формальная семантика (в инженерии по
факту не используется, редко – в программной инженерии).
• Идут эксперименты в рамках MBSE инициативы INCOSE (группа
онтологии:
http://www.omgwiki.org/MBSE/doku.php?id=mbse:ontology).
What an engineer calls a model a logician calls an axiom set; what a
logician calls a model an engineer calls a simulation. This
equivalence of concepts leads to application of well-established
methods of logic to engineering. (Henson Graves,
http://www.omgwiki.org/MBSE/lib/exe/fetch.php?media=mbse:mathemataical_foundation_engineering.pdf)
• Не стоит забывать: «чем больше формализация, тем меньше
люди обращают внимание на смысл» (vit_r в ЖЖ).
• Пример: OWL и ISO 15926.
63

64. Типология знаний инженерного проекта
• Знания включают
– Нормативно-справочную
информацию (НСИ), которая
включает
• Справочные данные, которые
включают
– Мастер-данные
64
формализация
Инженерия знаний – это документирование и учёт
знаний, в т.ч. преобразование из менее формальных
представлений в более формальные. Включает:
–Инженерию НСИ, которая включает:
• Инженерию справочных данных,
которая включает:
– инженерию мастер данных
формализация

65. Инженерная работа: САПРы
65
Модель редуктора, используемого в приводах на линиях сварки
кузова ВАЗ 2110 (инженер-конструктор Андрей Магомедович Алиев,
2004)
http://www.sapr.ru/article.aspx?id=7171&iid=293

66. Люди общаются, компьютеры – только после доработки.
Деньги нужны на «линии между овалами»
• ISO 11354-1, пункт 5.4.1:
There are three approaches to achieve enterprise interoperability:
-- integrated, [разрабатываются вместе]
-- unified, [следуют стандартам]
-- and federated. [адаптеры, мэппинг]
These three approaches were first identified in ISO 14258.
ISO 11354-1 Advanced automation technologies and their applications — Requirements for establishing
manufacturing enterprise process interoperability — Part 1: Framework for enterprise interoperability. 66

67. Главная проблема:
мультимоделирование
• «Единое информационное пространство» как линия горизонта
• Федерирование структурных моделей (ISO 15926)
• От Tool-chain к Tool-Net (поиск-ориентированная системная
инженерия, оптимизация)
• Федерирование имитационных моделей (но пока не структурных!):
– Modelica 3.3
– Simantics 1.7, MIC (Model-integrated computing)
– FMI (functional mockup interface) 2.0
67
https://modelica.org/, http://simantics.org/ https://www.fmi-standard.org/, http://www.isis.vanderbilt.edu/research/MIC

68. Проектирование Закупка Постройка
Сдача
заказчику
Эксплуатация
Ремонт/
модернизация
Вывод из
эксплуатации
Жизненный цикл, САПРы, PLM, ERP
НСИПоставщики оборудования и материалов
Как устроить обмен данными?!
Судоэкспорт
ERP
ДЗО ДЗО
Технический
проект
Рабоче-
технический
проект
Рабочий
проект
Подготовка
производства
Постройка
Подготовка
технического
задания
Проведение
конкурса
Размещение
заказа
Приемка
Разработка проекта
Размещение заказов у
подрядчиков
Сборка Сертификация Передача на стройку Участие в испытаниях
испытания испытания
Подрядчик
Конструкторские Бюро
PLM
SP Foundation
ENOVIA
Vault
…
CAD
Autodesk PLANT
Intergraph
CATIA
Bentley
…
Строительные организации
ERP
…
PLM
…
CAD
…
строительные организации
ERP
SAP
…
PLM
SP Foundation
ENOVIA
…
CAD
P&ID и 3D
…
68
Осложнение: concurrent engineering – все
стадии жизненного цикла одновременно!

69. Информационные системы
в жизненном цикле задвижки
69
Ситуация
Объект
Спецификация
функции (СФ)
Спецификация
компонента
(СК)Спецификация
продукта (СП)
Индивидуальный
журнал (ИЛ)
Физический
образец
Объект
«мотор» «Задвижка» в обычном
языке
Реальный,
функционирующий
Запланированный,
историческая
запись, и т.п.
PLM
ERP
EAM
Разные цвета – разные «моторы»:
• комплектующее (PLM),
• предмет снабжения (ERP),
• установленное оборудование («актив» в EAM).
Информационных систем больше, чем
только PLM, ERP, EAM. Ручной переввод
информации в среднем 7 раз в ходе
проекта!!! Это:
• медленно,
• вносятся ошибки,
• очень дорого (работа людей).
Чьи данные? Кто ответственен за оригинал?
Новый класс систем: регистрационные

70. As-Designed and
As-Built System
Turnover of P&ID,
PFD, and Breakdown
Structures of
Segments, Tags, and
Ports
(15926 to MIMOSA)
As-Maintained
Segments, Tags, and
Ports with Installed
Serialized Assets
(MIMOSA to 15926)
As-Built
Serialized Asset
Instances Including
Equipment,
Documents, Software
and Firmware with
Segment Install
(15926 to MIMOSA)
Segment Installs &
Removals For an Asset
(MIMOSA to 15926)
As-Maintained Segment
Configuration O&M Data
Sheets, Monitored Tags,
Port Connections,
Breakdown Structures and
Topology Configurations
(MIMOSA)
As-Maintained Asset
Installs & Removals On a
Segment (MIMOSA)
As-Maintained
Product Data Sheets
With BOM (MIMOSA)
As-Maintained
Serialized Asset
O&M Data Sheets
(MIMOSA)
As-Maintained Segment
Installs & Removals For
an Asset (MIMOSA)
Production Orders
(B2MML &
PRODML)
Production
Performance
(B2MML & PRODML)
MES KPIs
(MIMOSA, B2MML
& PRODML)
Forecasted
Demand (B2MML
& PRODML)
Asset Performance
Prediction (B2MML
& PRODML)
OPM KPIs
(MIMOSA, B2MML
& PRODML)
Detailed
Production
Performance
(B2MML &
PRODML)
Detailed
Production
Schedules
(B2MML)
Significant Actual &
Early Warning ORM
Events (MIMOSA)
Performance KPIs
(MIMOSA)
Planned
Asset
Unavailability
Schedule
(MIMOSA)
Hist. Op.
Data &
Events
(OPC)
Op. Work
Status &
Work
History
(MIMOSA)
Maintenance Work
Status & Work
History (MIMOSA)
Maintenance KPIs
(MIMOSA)
CBM
Advisories
(MIMOSA)
`
CBM
Advisories
(MIMOSA)
Usage Readings
(MIMOSA)
CBM/Calib. Start
Activity Event
(MIMOSA)
CBM/Calib.
Work
Completed
(MIMOSA)
Control Data
(Fieldbus) Current Op. Data
& Events (OPC)
Full-Resolution Condition
Data & Events (MIMOSA)
OpenO&M-ISO 15926 Transform Engine OpenO&M Information Service Bus Model (ISBM) OpenO&M Common Interoperability Register (CIR)
REFERENCE ENVIRONMENT EXECUTION ENVIRONMENT
MIMOSA CCOM O&M Reference Data Dictionary (REG-DICTIONARY)
MIMOSA CCOM O&M Reference Data Taxonomies (REG-TAXONOMY)
Product Template and
Product Data Sheets
with BOM
(15926 to MIMOSA)
As-Maintained Asset
Installs & Removals
(MIMOSA)
As-Built Asset Installs On
a Segment (MIMOSA)
As-Built Segment
Where Asset is
Installed (MIMOSA)
Product Template
And Product Data
Sheets (MIMOSA)
DMS
Owner/Operator Engineering Schematic Drawing
Document Management Systems
ERP, ERM, PORT
Enterprise Resource Planning Systems, Enterprise Risk
Management Systems and Enterprise KPI/Event Portals
MES
Production Forecasting & Scheduling Systems
OPM
Operational Performance Modelling & Optimization Systems
CONTROL
DCS, PLC, SCADA, HMI
and Historians
ORM
Operational Risk
Management Systems
(SHES, PSMS, AHMS, QMS)
MMS
Maintenance
Management Systems
(EAM, CMMS)
CMS
Condition Monitoring Systems
(Measurements, Events, Inspections, Calibrations, Conditions, Usage and Sensed O&M Actions)
I&C Device
Monitoring
Performance
Monitoring
(Sand, Water, Gas,
Crude)
Corrosion
Monitoring
Rotating Machinery Monitoring
(Vibration, Electrical,
Thermography, Ferrography LIMS)
OEM PDM
Manufacturer
Product Data
System
REG-STRUCTURE
Registry of
Segments with
Configuration
O&M Data Sheets,
Asset Installs/
Removals,
Monitored Tags,
Port Connections,
Breakdown
Structures, and
Topology
Configurations
REG-PRODUCT
Registry of
Product Template
O&M Data Sheets
and Product
Model O&M Data
Sheets with BOM
Component
Composition
REG-ASSET
Registry of
Serialized Assets
(including
Documents,
Software and
Firmware) and
associated
Segment Installs/
Removals, Product
Make/Model
Associations and
O&M Data Sheets
CONSTRUCT
As-Built
Construction
System
ENG
Owner/Operator
Engineering
Systems
Потоки проектной и
эксплуатационной информации
Open Standards Which Define Data Content for
Information Exchange
OAGIS, CIDX
OpenO&M Common Interop. Registry
ISO 15926 / iRING
B2MML
B2MML & PRODML
MIMOSA, B2MML & PRODML
MIMOSA
OPC
Fieldbus (Foundation, Profibus, etc.)
70

71. Поколения инженерных информационных систем:
от «машинночитаемости» к «машинообрабатываемости»
1. Электронная бумага (.pdf, .tiff, .jpeg и т.д.)
2. «Документооборот»: отдельные файлы в формате
САПР. Выборок по факту нет («нет индексации» – по
аналогу с поисковыми системами). Поддерживается
только подписывание и визирование
(административная работа).
3. Гибридные (файлы в формате САПР+база данных
существенной информации). Intergraph SPF.
Ограниченные инженерные выборки, учёт и почта.
4. Датацентричные системы. ENOVIA V6, 3DExperience.
Неограниченные инженерные выборки, верификация.
5. Семантические системы (пока нет). Возможности
искусственного интеллекта (нахождение неочевидных
инженерных коллизий).
71

72. Интеграция, объединение, федерирование
Как говорить о взаимодействии (interoperability) в ходе проекта: ISO 11354:2011
(Integrated, Unified, Federated). Снятие контептуальных, технологических,
организационных барьеров на пути обмена физическими или
информационными объектами.
Провал проекта STEP (ISO 10303) для целей федерирования. Две проблемы:
• нет общей для всех дисциплин модели мира! Обмен данными САПРов одной
дисциплины не даёт возможности обмениваться данными в PLM.
Онтологические выборы для «общей модели мира» трудны, нужно экономить
время исследовательской работы – это нужно делать за пределами проектов!
• Нужна факт-ориентированная модель данных (итоги работы консорциума
EPISTLE).
Все поставщики САПР/PLM приняли подход с «общей моделью мира для разных
САПР в PLM» и unified подход, но не приняли факт-ориентированности (ибо у них
всё уже unified).
Разработчики ISO 15926:
• В 2003 году выпустили «нейтральную» модель данных инженерного проекта.
• Попытались сделать ставку на факт-ориентированную модель (но с этим
сильно перемудрили).
• Сейчас они отрабатывают представление модели системы в виде паттернов
(очередная попытка «приблизиться к инженерам»).
72

73. 73
Приложения
проектанты
Приложения
Поставщики
Приложения
технология
Приложения
Эксплуатация
<подставьте свой любимый
стандарт> = «английский» для
данных жизненного цикла
Нейтральная
схема данных
(«словарь
английского»)
Типовая архитектура федерирования систем

74. Семантические технологии против
«обычного стирального порошка»
• Открытый мир против закрытого мира: пополняемость (XML –
это закрытый мир, проблемы с merge независимо сделанных
правок)
• «Антиаристотель»: снимается проблема разного деления мира
на объекты и их атрибуты в разных проектах: интеграция
разных данных и унификация запросов
• Связь раскиданных в Сети моделей (URI):
• Самоописываемость моделей данных (resolvable URI), при этом
описания как для людей, так и для программ – в зависимости от
того, кто обратился к URI
• Отсутствие деления на схему и данные: множество уровней
метамоделирования, справочные данные
• У трипл-сторов выше производительность на сложных запросах
• Готовые обменные форматы: RDF и OWL
• Формальные проверки (логика в OWL)
74

75. iRING архитектура: ничего нового?
75
Product
data
model
ISO 15926
RDL
federation
Product
data
model
Product dataProduct data
1 ISO 15926 Rule ISO 15926 2
circle radius radius*2 diameter окружность
mappingmapping
1. Редактор
мэппинга
4. адаптор
3. SPARQL
endpoint
2. Редактор
справочных
данных
5. адаптор
фасады

76. Добавили онтологию!
Стек стандартов Semantic Web (RDF и OWL) достаточен для федерации
информационных моделей только в рамках одной стадии жизненного цикла!
В рамках федерации разных стадий (ISO 24744: life cycle stages определяются через
change of mental framework) нужно определиться с одной картиной мира: как
совмещать разные объекты (например, комплектующее стадии
проектирования, предмет поставки стадии строительства, установленное
оборудование стадии эксплуатации).
76
ISO 15926 даёт в плюс к семантике
соглашение о моделировании мира, плюс
моделирование представления мира в
компьютере
• 4D extensionalism
• Отношения, которые при федерации
пересекают границы информационных
систем. Эти отношения главным образом
– TemporalWholePart (Whole, Part)
• Понятие «система» -- пример смены
насоса.
• Множественные классификации (классы
классов)

77. ISO 15926 и жизненный цикл
77
!
!!

78. ISO 15926 как механизм стандартизации
78
RDL
RDL (ГОСТы)
RDL (стандарты
отрасли)
RDL проекта
RDL каталога
Проектная информация
Данные каталога
ISO/JORD
Национальная ассоциация
Отраслевая ассоциация
Поставщик каталога
Инжиниринговая компания

79. Итого: текущее состояние с осознанием дисциплины
(объектов) системной инженерии
• Аналогия 2014г. в осознании дисциплины системной инженерии:
физика начала двадцатого века: отдельные парадигмы и обрывки
знания на месте, связной картины мира нет, использование знаний
толком не началось (GPS, атомная бомба, лазер ещё не изобретены),
работ Поппера и Лакатоса ещё нет.
• Отдельно идут «хотелки» разных viewpoints -- архитектурные
frameworks (без языков) и body of knowledge. Отдельно россыпь
«однопарадигмальных» языков. Синтетический подход превалирует,
нет «конфигуратора».
• В программировании УЖЕ ЛУЧШЕ – мультипарадигмальные языки
рулят (несмотря на все вопли сторонников языков одной парадигмы),
сдвиг произошёл где-то в 1989 году. В системной инженерии этого
пока нет.
• Идея сделать мультипарадигмальный системноинженерный язык,
поддерживающий и интеграцию данных (Python ad hoc – 1989г., Scala
уже как абсолютно осознанный шаг – 2003г).
• Нужно закатать рукава и сделать свой «большой проект» по созданию
схемного языка системного подхода/системной инженерии.
79

80. Что делаем: SysMoLan
SysMoLan (Systemese): System Modeling Language
http://ailev.livejournal.com/1127145.html
«Иметь возможность нарисовать на одной схеме
системы то, что раньше рисовалось только на двух
разных, чтобы явно указать связи и обсудить».
• Ничего нового: такая была дизайн-цель ArchiMate
(прожекторный язык, факт-ориентированный).
• Отличия от SysML: в самом SysML множество
диаграмм изначально, нет языка запросов и
мэппинга, нет факт-ориентированности, нет upper
ontology и т.д.
• Одновременно product и project модели
80

81. SysMoLan
• Три языка в одном (данных, прожективный-запросы, синтетический-мэппинг
для «инженерии в большом»). Проблема.
• Факт-ориентированный [как Архимейт], со внешним представлением, но не
семантический веб. Проблема.
• Графический и текстовый синтаксисы. Проблема
• Онтологический (конфигуратор для дисциплин: upper ontology, общая модель
мира – против онтик-микротеорий-без-объединения) – как ISO 15926, но со
внешним представлением. Проблема.
• Требования и архитектура [как SysML]
• Гибридные вычисления [тексты и эскизы, псевдокод, код в одном флаконе].
Выход на поиск-ориентированность. Проблема.
• Аказуальное моделирование [как Modelica и SyM]
• Киберфизические системы [как AADL]. Исполняемость [как xUML] – проблема.
• Язык как стандарт отдельно, моделеры как софт отдельно.
• Архитектурные библиотеки (как в Modelica) + каталоги продукции (как ISO
15926): поддержка языком «инженерии в большом»
• Жизненный цикл и ситуационность (независимость от проекта) [как Essence].
• Стык product model и project model (case management и project management).
Проблема.
• 20% выразительных фич должны закрыть 80% случаев использования.
Проблема. Но это и есть определение предметной области.
81

82. Контекст объективации
• Когда системноинженерный подход сформулирован, можно прийти в
предметную область (объективацию) уже с ним
• Не пирамида знаний, не конвейер знаний, не жизненный цикл знаний. Это
модульная диаграмма деятельности объективации (целевое предпринятие –
endeavour, нижний слой – собственно инженерия).
• Деятельность – это класс endeavours (при этом endeavours это individuals в 4D)
• Конечно, есть и закон Конвея: но как выглядит закон Конвея, если предметом
являются предпринятия?! Разделение труда в объективации (организация
труда в обеспечивающем предпринятии объективации).
• Забавно: в онтологических схемках endeavour – пользовательский уровень
внизу, а в инженерных модульных обычно пользовательский уровень сверху.
Так что можно выбирать: кто мы, и как рисовать схему.
• В модулях самое интересное – это интерфейсы. Интерфейсы определяются
стандартами. Стандарты подразумевают множественность реализаций
модулей.
• Кроме модульных схем важны компонентные схемы. И гарантии соответствия
модульных и компонентных схем в архитектуре.
• Опять же: какие требования для архитектуры? Кто их ставит? 1. Техническое
задание для школы (эксплицирование). 2. Я сам, проект 2010 года, RuSEC. 82

83. Модульная структура объективации.
• Философские логики – знаковые системы и их связь с
окружающим миром, предельные онтологи
• Рефлексирующие модельеры данных – MOF, Part 2 (Upper
ontology, foundational ontology). Компьютерщики:
преобразования одних выражений мысли в другие
(теоркатегорное представление, не теория множеств –
операции главные, вычисление)
• Модельеры данных/intermediate ontology – одна логика,
помогают выразить мысль непротиворечиво (теоретико-
множественное представление – объекты главные).
• Ситуационные инженеры методов, кейс менеджмент, BPM,
проектные управленцы, оргдизайнеры – мысли о
деятельности
• Рефлексирующие инженеры/микротеоретики=онтики –
мысли о своей дисциплине (объекты-предметы: системная
инженерия, программная инженерия, инженерия
предприятия, инженерия психика)
• Профессионалы-инженеры – мысли о своих конкретных
целевых объектах (софтинках, самолётиках) и
обеспечивающих объектах (то бишь субъектах).
83

84. 84
Спасибо за внимание!
Анатолий Левенчук,
ailev@asmp.msk.su
Блог: http://ailev.ru
Виктор Агроскин,
vic5784@gmail.com
TechInvestLab.ru (член POSCCaesar Association)
+7 (495) 748-53-88
Материалы (306 страниц) «Системноинженерное мышление
в упралении жизненным циклом» --
http://techinvestlab.ru/files/systems_engineering_thinking/sy
stems_engineering_thinking--TechInvestLab_2014.pdf