Стандартизация предмета системной инженерии

Анатолий Левенчук

Юрмала22 августа 2014г.

2

О чём будем говорить

• Методологическое самоопределение докладчика• Почему стандартизация («объективация» -- shared)• Справка по дисциплине системной инженерии• Сюжеты «объектизации» (привнесения новых

объектов)– Требования– Архитектура– Вид жизненного цикла– Интеграция данных жизненного цикла

• SysMoLan

3

Методологическое самоопределениеИстория:• считал себя "системным программистом" и "системным архитектором" с середины

80-х, но не догадывался о специальном значении слова "системный" и существовании "системной инженерии". Конечно, знал о существовании системного подхода, но не понимал его сути и действенности.

• узнал о существовании системной инженерии как дисциплины осенью 2007 года, встретившись с особой задачей: удержание целостности при создании АЭС. Ход был прост: а как удерживают эту целостность на Западе?

• развернул исследования в области методологии системной инженерии в кооперации с зарубежными организациями (INCOSE, SEMAT)

• получил дополнительную онтологическую экспертизу (POSCCaesar Association, Ontology Summit) и экспертизу в ситуационной инженерии методов (OPF, ISO 24744, SEMAT).

• нахожусь рядом с СМД-методологией уже 26 лет (с Ростовской игры февраля 1987г.), занимаюсь методологией "в рабочее время" в силу профессиональной необходимости, но никогда не считал и не считаю себя сейчас СМД-методологом.

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

4

Методологическое самоопределение

Мои проекты по формулированию предмета системной инженерии/системноинженерного мышления:• создание учебного курса (содержание образования

должно включать знания об объектах предметной области). Текущие материалы: http://techinvestlab.ru/files/systems_engineering_thinking/systems_engineering_thinking--TechInvestLab_2014.pdf

• создание схемного языка системного моделирования SysMoLan (понятия языка должны отражать понятия предметной области). Основные идеи: http://ailev.livejournal.com/1127145.html

5

Disclaimer

• Я не СМД-методолог, поэтому необязательно совпадение схем и терминологии с терминологией и схемами СМДМ. Про «объективацию» я не могу рассказать, но расскажу про осознание системными инженерами собственной дисциплины.

• Мнение автора по поводу системной инженерии не совпадает с мнением системных инженеров, стандартов и т.д.. Ругать нужно отдельно мысли автора, и отдельно системную инженерию. [по опыту предыдущих обсуждений]

• Системная инженерия это вовсе не «обзывание новыми словами давно известной со времён СССР деятельности». Отнюдь. Но это предмет другого доклада.

• Социотехнические (кибер-физико-человеческие) системы затронуты по-минимуму, равно как и проблемы системо-системной инженерии. Изложение ограничено рамками классической «железной» системной инженерии (автомобили, самолёты, подводные лодки и прочий транспорт).

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

7

Стандарты и построение дисциплина (объективация:)

• Предмет: ответ на вопрос «что есть в мире» (онтика, часто называют онтологией, путают с онтологическим описанием).

• Онтология – это разделяемая людьми (shared) спецификация концептуализации (Том Грубер)

• Стандарты дают:– По форме – спецификацию (т.е. онтологическое описание)– какую-то гарантию разделяемости людьми (т.е.

коллективную работу по проверке описания)– проверяемы использованием в деятельности

8

Причины появления стандартовв системной инженерии

• Цеховая работа:– Нормирование «правильной деятельности»,

соответствия дисциплине (сертификация, и только) – ISO 15288

– Обучение и аттестация (трансляция предмета системной инженерии): Systems Engineering Handbook, Systems Engineering Body of Knowledge

• Необходимость соорганизации деятельности разных стейкхолдеров: онтологические стандарты.

9

Стандарты системной инженерии

• «Обычные» (ISO 15288), намёк на схемы (ISO 24774)

• Предлагающие схемы и стандарты схематизирования (ISO 42010, OMG Essence, ArchiMate)

• Онтологические aka модели данных, полноценное моделирования (ISO 15926, «стандарты де-факто» современных PLM)

10

«Процесс»

«Процедура»

«Функция»

«Деятельность»

«Шаблон проекта»

ПланировщикМенеджерпо качеству

Менеджер

Консультант

Аналитик

По материаламкомпании FutureModels

От речевых сообществ к сообществам значений

PP656.11

Международные стандарты сложны

Размещено с разрешения FIATECH

Не хочу видеть никаких сумасшедших торговцев – ты что, не видишь, что тут битва идёт!

Системная инженерияКак удерживать целое?! -- системноинженерное мышление и управление жизненным циклом

Как создать успешную систему?! – практики системной инженерии

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

Проблемы с языками первого поколенияСложны в использовании, требуют сложного софта:• Ориентированы на методологов, а не применяющих. Ответом будет упрощённый

«карточный синтаксис» и рекомендации по процедурам использования (карточным играм).

Даётся только язык, но не «общая земля» (общие реалии проекта, используемые всеми практиками и методами).• практики и методы оказываются несопоставимы друг с другом! Команда из людей,

практикующих разное, не может быть составлена без долгих переговоров и недопониманий. Ответом будет упор не на рабочие продукты, а на модель предметной области инженерии -- онтологию инженерной дисциплины. Вводятся основные идеальные объекты-альфы (альфы, деятельности/пространства операций, компетенции), имеющиеся во всех проектах.

Это впрямую заявка на определение основных объектов (программной) инженерии.Откуда брали «общие объекты»? Вручную просмотрели порядка 250 методологий разработки «из интернета»!

14

15

Соглашение о терминологии(“язык” по мотивам OMG Essence)

• Дисциплина – основные сущности (идеальные объекты, alpha) предметной области, типовые деятельности с ними (activity spaces), компетенция [“объективация” тут]

• Технология – рабочие продукты и операции• Практика = дисциплина + технология• Метод = достаточный для достижения цели

набор практик

Язык, практика, дисциплина, технология

16

...

ЯзыкДисциплина(абстракции)

Технология(конкретности)

...

Практика

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

17

Адаптация к системной инженерии• Работа Русского отделения INCOSE в кооперации

с SEMAT• Опора на V-diagram, как основную схему

системной инженерии• Главное: разделение на определение системы и

воплощение системы

18

V-диаграмма сущностей инженерного решения

19

Подальфы определения системы

приёмка

проверка

проверка

20

Дисциплины системной инженерии• [моделеориентированная] инженерия требований• [моделеориентированная] инженерия системной

архитектуры• [моделеориентированные] проверка и приёмка

(V&V)• [моделеориентированный] системноинженерный

менеджмент (управление жизненным циклом)

• В ситуационной инженерии методов обычно более мелкое деление (ISO 15288)

21

Подпредметы и основные объекты системной инженерииГлавный объект – реализация системы

Определения системы:• Определение черного ящика – требования• Определение прозрачного ящика – архитектураРеализация системы• Соответствие различных определений, определений и реализации –

испытания/тесты (проверка и приёмка)

Менеджмент системноинженерной деятельности – обеспечивающая система• Обеспечение метода (практик работы) -- жизненный цикл (project model) • Обеспечение целостности --конфигурация (product model), изменения

(issues)

Требования к системеsystem requirement

Подальфа определения системы:определение системы как чёрного ящика.

• Путаница: инженерия требований vs. управления требованиями

• Ещё путаница: stakeholders needs, stakeholder requirements, system requirement, constraints, деонтическими высказываниями. Близки: цели, use cases.

• Стейкхолдеров много, им нужно договориться о том, какую систему делаем. ИХ ТРЕБОВАНИЯ ПРОТИВОРЕЧИВЫ!

• Стандартизовать «управление»: доступ, конфигурация, изменения… 22

Стандарты представления требований

Текстовые строчки:• 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

Метамодель MBRD

Требование

удовлетворяетСловарь

определяет термины в

реализует

Цель

Владеет

Обоснование

обосновывает

КачествоФункция Ограничение

Заинтер. сторона

Неоперационная

Операционная *

Измерение

делает проверяемым

Испытание

реализует

проверяет

противоречит,способствует

Сценарий

играет роль в

реализует

Обычная

Препятствие/Угроза

угрожаетсмягчает

Приоритет

приоритизирует

До решения

После решения

включаетпроизводит

Граничное событие

Интерфейс

имеет событие

ИсходящееВходящее

Система

имеет интерфейс

указывает

объясняет

Развилка

использует как критерий

оценивает варианты

создает

* Операционные= вовлеченные в эксплуатацию, но не обязательно взаимодействующие с продуктом «акторы»(с) Ян Александер, 2010

25

Практики в MBRDАнализ

заинтересованных сторон

Моделированиеконтекста

Моделирование целей

Приоритезация

Написание требований, повторное

использование, шаблоны, стандарты

Анализобоснований

Анализ развилок

Анализсловаря

Анализ измерений

Моделированиесценариев

23

(с) Ян Александер, 2010

26

Валидация требований на основе модели

• Убедиться в том, что для всех объектов модели:– Цель принадлежит какой-то Заинтересованной стороне– Операционное заинтересованное лицо играет роль в Сценарии– Цели приоритизирована определенным Приоритететом– Высокоприоритетные цели используются как критерии при выборе

Развилок– Конфликты между целями устраняются в процессе прохождения

Развилок– Препятствия/Угрозы смягчаются Целями– Цель удовлетворяется Требованием– Требование делается проверяемым Измерением– Развилка объясняется Обоснованием– <Термин>* в Требованиях определяется в Словаре

* <Термин> может быть любым Состоянием, Целью, Операционной ролью, Измерением

(с) Ян Александер, 2010

I* -- задаёт тон в GOREhttp://www.cs.toronto.edu/km/istar/

Goal-oriented requirements engineering1995г.: 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

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

28

Архитектура системыопределение «прозрачного ящика»

• Раньше: от требований к дизайну• Сейчас: от требований к архитектуре, потом

неархитектурным решениям (дизайн поделили на архитектуру и неархитектурные решения)

• Проблема: конструкция следует из функции (форма следует из функции), как в архитектуре. Но что это не в инженерии? И как это выразить?

• Консенсус зафиксирован на сегодня в ISO 42010 – схемное введение понятия

29

Архитектура• Как документировать

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

• Практика: инженерия системной архитектуры.

30

Для чего используется архитектура?• Рассуждения о системе для команды проекта

(«архитектурные описания для инженеров как шахматная доска для игроков в шахматы»). – («шахматная доска для зрителей и судей»).

• Архитектурную работу можно делать плохо, а можно хорошо (но делается она в любом случае). Чтобы её делать хорошо, нужно её обсуждать специально, знать лучшие архитектурные практики!

31

Определение архитектуры• Из 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

Альтернативное определение

Архитектура – это обо всём важном. Что бы это ни было.

Ralf Johnson

33

Архитектурные и неархитектурные решения

34

• Субъективны – где заканчиваются архитектурные решения знает только архитектор системы (системный инженер)

• Относительны – что уже не архитектурные решения для архитектора системы, то может быть архитектурными решениями для архитектора подсистемы

Критерий, где остановиться системному инженеру, спускаясь (по отношениям часть-целое): там, где вы

• дошли до того уровня деления системы на элементы, на котором вам кажется, что уже нет важных ваших решений.

• уже поделили работу между отдельными исполнителями-разработчиками модулей и дальше будут их важные решения.

Архитектурные знания• Очень редко архитектурные (важные, требующие

существенных переделок при их изменении) решения изобретаются заново, чаще они повторноиспользуемы (т.е. «знания»).

• Архитектурные решения – это чаще всего накопленные человечеством, отраслью, организацией, конструктором/проектировщиком знания.

• Развитие и лидерство в инженерии – это обычно добавление знаний, предложение новых архитектур, исходя «из первых принципов».

35

Определение системы

36

Функция:

требования со стороны

использующей (над)системы

Архитектура(совмещение

функциональной и физической

декомпозиции)

Конструкция: рабочий проект

(изготавливаемые части) целевой

системы

Описывается «чёрный ящик» (реверс-инжиниринг системы использования)

Описывается «прозрачный ящик» с детальностью, достаточной для изготовления

Описываются основные принципы структуры «прозрачного ящика», который выполнит роль «чёрного ящика»

Фокусирование (сужение пространства решений)

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

«Просто» проектирование/конструирование

Определения и описания: альфы и рабочие продукты(обобщение ISO 42010)

37

Подальфы технологии (задаются стандартами)Подальфы определения системы:

требования, архитектура, рабочка. Рабочие продукты для них:

• Описания требований, тематические группы описаний требований, модели требований

• Архитектурные описания, тематические архитектурные группы описаний, архитектурные модели

• Рабочие описания, тематические группы рабочих описаний, рабочие модели

view viewpoint

definition realization

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

38

Архитектурные описания: что поменялось за тридцать лет (1984-2014)?

По сравнению с советским способом производства сейчас на Западе:• Системная архитектура и архитектурные описания обсуждаются явно («объекты первого

класса»), выделена профессиональная позиция системного архитектора, устоялась терминология, вышли стандарты (ISO 42010, ISO 15288 и т.д.)

• От описаний неформальных к формальным (понимаемым компьютером, выраженных на языке моделирования)

• От отдельных непровязанных групп описаний к провязанным (в компьютере, а не «в голове»)

• От описаний мультифизических («аналоговых») к добавлению структурных («дискретных»)

• Появление объект-ориентированных и акаузальных (декларативных, непроцедурных) языков моделирования – облегчение накопления структурного знания, создание библиотек.

• Расчётные обоснования архитектурных выборов (множество методов), первые эксперименты по компьютерной оптимизации архитектуры

• От малого числа методов описаний (3-5) к большому их числу (18-26).• Упор на повторноиспользуемость, открытость архитектуры (NATO), модульность

конструкций (переход от интеграционных к объединительным технологиям: больше роль проектирования, чем конструирования) 39

ISO 81346

40

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

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

41

Совмещение логической и физической архитектур по версии ISO 81346-1Figure 7

42

«Логическая архитектура» (функциональная декомпозиция, структура компонент) итеративно совмещается с «физической архитектурой» (продуктная декомпозиция, структура модулей)

Сколько «базовых структур» в системе?

• ISO 15926 – две основных: функциональные объекты, физические объекты. Остальные могут вводиться по потребности.

• ISO 81346 – «по меньшей мере» три (функция, продукт, место)

• Garlan et. al – три стиля (компоненты, модули, размещения, и разные варианты структур внутри стиля)

• СМД-методология – «по меньшей мере» пять (процессы, элементы и связи, внешние функции, морфология, материал) -- http://www.mmk-documentum.ru/glossary/6

• …

43

Базовые структуры определения системы

• =Компоненты• -Модули• +Места

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

стили.

44

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

45

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

функционирование)• Не интерфейсы, а «порты» связей с другими

элементами. Компоненты взаимодействуют друг с другом не непосредственно, а только через связи-соединения.

• Чаще всего компоненты и соединения выражаются «схемой».

• Важная практика: мультифизическое моделирование (по схеме проводятся расчёты «режимов» и характеристик отдельных компонентов – используются солверы, иногда поставленные под контроль оптимизатора). 46

Примеры модульных описаний

47

FR160B PCB 2-Layer USB Portable Power Module -- - Green (3.5 x 2.6 x 1.5cm)

Model FR160BQuantity 1Color GreenMaterial 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

Модули• - (префикс для обозначения в ISO 81346)• Элемент конструкции, продукт, сборочная единица.• Интерес: что нужно разрабатывать и изготавливать (время

разработки и изготовления, но не работы системы).• Что от чего зависит (отношение «зависит») в плане

разработки.• Имеет интерфейс, у которого есть «видимость»

(доступность). Зависимый элемент имеет слот с таким интерфейсом.

• Важная практика: Dependency Structure Matrix (DSM).• Модуль может присутствовать во многих компонентах.

48

Размещения

• + (префикс для обозначения в ISO 81346)• Место установки в системном окружении

(здании, комнате, отсеке, серверной стойке) • Место транспортировки (например, в каком

ящике), место хранения (например, на позиция складского хранения)

• Где будет производиться или проектироваться• …

49

Гибридные описания• Чистых видов описания не бывает: смесь самых разных в одном

тексте, таблице, диаграмме, схеме, чертеже.• Онтологов мало, поэтому не ждите какого-то формализма там, где

его нет.• Терминология не устоялась, поэтому ожидайте встретить самую

разную (модулем могут назвать компоненту, а компоненту элементом, слот техпозицией и т.д.).

50

Практики системного проектирования

• Их множество (см. обзор в первой главе книги М.Левина «Технология поддержки решений для модульных систем»: http://www.mslevin.iitp.ru/Levin-bk-Nov2013-071.pdf)

• У всех один «недостаток»: хорошему инженеру эти методы помогают, плохому инженеру они помочь не могут.

• Наиболее известны ТРИЗ и DSM (практикуются во многих центрах разработки). Но есть огромное число методов, практикующихся в рамках одной-двух лабораторий (реже – центров разработки).

• На сегодня наиболее активно развиваются компьютерные методы не только «проверочных архитектурных расчётов», но и методы оптимизации (выбора оптимальной архитектуры).

51

ТРИЗ• Противоречия: приёмы ТРИЗ, «грозовая туча» 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

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

Как делить на модули: 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

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

Модель мотора в Modelica (не требуется переписывание уравнений, блоки согласованы с компонентным составом мотора – описание архитектурно)

Жизненный цикл• Жизненный цикл системы (system life cycle) -- это

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

• Жизненный цикл проекта – та часть жизненного цикла, которая попадает в инженерный проект.

56

В какой последовательности и какие проводятся работы?

• Проблема: кто что в какой момент делает из толпы собравшихся стратегов, инженеров и менеджеров? Как им договориться, если у каждого есть собственное представление о деятельности?!

• Стратеги: система и сервисы как деньги, проданные где и когда они нужны;• Инженеры: содержательные состояния системы и содержательные операции над ней,

«реактор». Case management.• Менеджеры: логистическая труба, «конвейер» (система и её перемещения по местам

проведения операций, потребление ресурсов). Project management.

• Проблема коммуникации: каков должен быть общий объект «система»?

Управление жизненным циклом (какие практики использовать, «как работать») инженерная дисциплина, управление проектами (как логистически выстроить работы, чтобы минимизировать затраты и сделать все вовремя – менеджерская, как продать – предпринимательская, отчасти тоже логистическая (последняя доставка, покупатели -- это тоже покупаемый ресурс).

57

Стандарты представления жизненного цикла• BoK и частные их стандарты (ISO 15288 – ISO 24774)• Стандарты ситуационной инженерии методов (языки

«методологий разработки»): OPF, ISO 24744, OMG SPEM 2.0, • Второе поколение: альфы -- OMG Essence.• Lifecycle modeling language (военные разработки, 2014)

Проблемы жизненные циклы слишком разные, жизненные циклы отдельных частей проекта несовместимы, значительные части жизненного цикла системы проходят вне жизненного цикла проекта: • Виды жизненных циклов, невиданные ранее: agile, DevOp из

программирования. Примеры agile из инженерии (SpaceX).

58

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

59

Жизненный цикл против проекта• Жизненный цикл – это кейс из кейс менеджмента, issue tracking

как текущая инкарнация, adaptive case management как ближайшее будущее.

• Проект – это проект из проектного управления, диаграмма Гантта и критическая цепь, предсказуемость и «управляемость».

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

60

Системы систем, мягкие системыКиберфизические системы и resilience

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

• Проблема: владеемая одними людьми автономная система «не хочет» быть частью владеемой другими людьми надсистемы: классическая системная инженерия не работает в случае системы систем.

61

Развитие и совершенствование инженерии

62

РЕЗУЛЬТАТЫ

ВРЕМЯ

III поколениеМоделе-ориентированная (model-based) инженерия: формальные языки (вычисляемый «код»)

II поколениеСовременная («классическая») инженерия: диаграммы и чертежи («псевдокод»)

I поколение«Алхинженерия»: неформальные тексты и эскизы

199018601400

IV поколениеИскусственный интеллект: гибридные вычисления

2020

Мечта о формализме• «Псевдокод» – это когда нет формальной семантики.• «Код» – это когда есть формальная семантика (в инженерии по

факту не используется, редко – в программной инженерии).• Идут эксперименты в рамках 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

Типология знаний инженерного проекта• Знания включают

– Нормативно-справочную информацию (НСИ), которая включает

• Справочные данные, которые включают

– Мастер-данные

формализация

Инженерия знаний – это документирование и учёт знаний, в т.ч. преобразование из менее формальных представлений в более формальные. Включает:

–Инженерию НСИ, которая включает:• Инженерию справочных данных,

которая включает:– инженерию мастер данных

формализация

65

Инженерная работа: САПРы

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

Люди общаются, компьютеры – только после доработки. Деньги нужны на «линии между овалами»

• 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

Главная проблема: мультимоделирование

• «Единое информационное пространство» как линия горизонта• Федерирование структурных моделей (ISO 15926)• От Tool-chain к Tool-Net (поиск-ориентированная системная инженерия,

оптимизация)• Федерирование имитационных моделей (но пока не структурных!):

– Modelica 3.3– Simantics 1.7, MIC (Model-integrated computing)– FMI (functional mockup interface) 2.0

67https://modelica.org/, http://simantics.org/ https://www.fmi-standard.org/, http://www.isis.vanderbilt.edu/research/MIC

Проектирование Закупка Постро

йкаСдача

заказчику

Эксплуатация

Ремонт/модернизац

ия

Вывод из эксплуатаци

и

Жизненный цикл, САПРы, PLM, ERP

НСИПоставщики оборудования и материалов

Как устроить обмен данными?!

Судоэкспорт

ERPДЗО ДЗО

Технический

проект

Рабоче-технически

й проект

Рабочий

проект Подготовка производст

ваПостройка

Подготовка технического

заданияПроведение

конкурсаРазмещение

заказа Приемка

Разработка проекта

Размещение заказов у

подрядчиковСборка Сертификация Передача на

стройкуУчастие в

испытаниях

испытания испытания

Подрядчик

Конструкторские Бюро

PLMSP Foundation

ENOVIAVault…

CADAutodesk PLANT

IntergraphCATIABentley…

Строительные организации

ERP…

PLM…

CAD…

строительные организации

ERP

SAP…

PLMSP

FoundationENOVIA…

CADP&ID и

3D…

68

Осложнение: concurrent engineering – все стадии жизненного цикла одновременно!

Информационные системы в жизненном цикле задвижки

69

Ситуация

Объект

Спецификация функции (СФ)Спецификация компонента (СК)Спецификация продукта (СП)Индивидуальный журнал (ИЛ)Физический образец

Объект «мотор» «Задвижка» в обычном

языке

Реальный, функционирующийЗапланированный, историческая запись, и т.п.

PLM

ERP

EAM

Разные цвета – разные «моторы»: • комплектующее (PLM), • предмет снабжения (ERP), • установленное оборудование («актив» в EAM).

Информационных систем больше, чем только PLM, ERP, EAM. Ручной переввод информации в среднем 7 раз в ходе проекта!!! Это:• медленно, • вносятся ошибки, • очень дорого (работа людей).Чьи данные? Кто ответственен за оригинал?

Новый класс систем: регистрационные

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)

DMSOwner/Operator Engineering Schematic Drawing

Document Management Systems

ERP, ERM, PORTEnterprise Resource Planning Systems, Enterprise Risk

Management Systems and Enterprise KPI/Event Portals

MESProduction Forecasting & Scheduling Systems

OPMOperational Performance Modelling & Optimization Systems

CONTROLDCS, PLC, SCADA, HMI

and Historians

ORMOperational Risk

Management Systems (SHES, PSMS, AHMS, QMS)

MMSMaintenance

Management Systems(EAM, CMMS)

CMSCondition 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 PDMManufacturer Product Data

System

REG-STRUCTURERegistry of

Segments with Configuration

O&M Data Sheets, Asset Installs/

Removals, Monitored Tags,

Port Connections, Breakdown

Structures, and Topology

Configurations

REG-PRODUCTRegistry of

Product Template O&M Data Sheets

and Product Model O&M Data Sheets with BOM

Component Composition

REG-ASSETRegistry of

Serialized Assets (including

Documents, Software and

Firmware) and associated

Segment Installs/Removals, Product

Make/Model Associations and

O&M Data Sheets

CONSTRUCTAs-Built

Construction System

ENGOwner/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

Поколения инженерных информационных систем: от «машинночитаемости» к «машинообрабатываемости»

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 году выпустили «нейтральную» модель данных инженерного проекта.• Попытались сделать ставку на факт-ориентированную модель (но с этим сильно

перемудрили).• Сейчас они отрабатывают представление модели системы в виде паттернов (очередная

попытка «приблизиться к инженерам»).

73

перевод

Перевод

Перевод

переводПриложенияпроектанты

ПриложенияПоставщики

Приложениятехнология

ПриложенияЭксплуатация

<подставьте свой любимый стандарт> = «английский» для

данных жизненного цикла

Нейтральная схема данных («словарь английского»)

Типовая архитектура федерирования систем

74

Семантические технологии против «обычного стирального порошка»

• Открытый мир против закрытого мира: пополняемость (XML – это закрытый мир, проблемы с merge независимо сделанных правок)

• «Антиаристотель»: снимается проблема разного деления мира на объекты и их атрибуты в разных проектах: интеграция разных данных и унификация запросов

• Связь раскиданных в Сети моделей (URI):• Самоописываемость моделей данных (resolvable URI), при этом

описания как для людей, так и для программ – в зависимости от того, кто обратился к URI

• Отсутствие деления на схему и данные: множество уровней метамоделирования, справочные данные

• У трипл-сторов выше производительность на сложных запросах• Готовые обменные форматы: RDF и OWL• Формальные проверки (логика в OWL)

75

iRING архитектура: ничего нового?

Product data

model

ISO 15926RDL

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) нужно определиться с одной картиной мира: как совмещать разные объекты (например, комплектующее стадии проектирования, предмет поставки стадии строительства, установленное оборудование стадии эксплуатации).

ISO 15926 даёт в плюс к семантике соглашение о моделировании мира, плюс моделирование представления мира в компьютере

• 4D extensionalism• Отношения, которые при федерации

пересекают границы информационных систем. Эти отношения главным образом – TemporalWholePart (Whole, Part)

• Понятие «система» -- пример смены насоса.

• Множественные классификации (классы классов)

77

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

!

!!

78

ISO 15926 как механизм стандартизации

RDL

RDL (ГОСТы)

RDL (стандарты отрасли)

RDL проекта

RDL каталога

Проектная информация

Данные каталога

ISO/JORD

Национальная ассоциация

Отраслевая ассоциация

Поставщик каталога

Инжиниринговая компания

79

Итого: текущее состояние с осознанием дисциплины (объектов) системной инженерии

• Аналогия 2014г. в осознании дисциплины системной инженерии: физика начала двадцатого века: отдельные парадигмы и обрывки знания на месте, связной картины мира нет, использование знаний толком не началось (GPS, атомная бомба, лазер ещё не изобретены), работ Поппера и Лакатоса ещё нет.

• Отдельно идут «хотелки» разных viewpoints -- архитектурные frameworks (без языков) и body of knowledge. Отдельно россыпь «однопарадигмальных» языков. Синтетический подход превалирует, нет «конфигуратора».

• В программировании УЖЕ ЛУЧШЕ – мультипарадигмальные языки рулят (несмотря на все вопли сторонников языков одной парадигмы), сдвиг произошёл где-то в 1989 году. В системной инженерии этого пока нет.

• Идея сделать мультипарадигмальный системноинженерный язык, поддерживающий и интеграцию данных (Python ad hoc – 1989г., Scala уже как абсолютно осознанный шаг – 2003г).

• Нужно закатать рукава и сделать свой «большой проект» по созданию схемного языка системного подхода/системной инженерии.

80

Что делаем: SysMoLanSysMoLan (Systemese): System Modeling Language

http://ailev.livejournal.com/1127145.html

«Иметь возможность нарисовать на одной схеме системы то, что раньше рисовалось только на двух разных, чтобы явно указать связи и обсудить».

• Ничего нового: такая была дизайн-цель ArchiMate (прожекторный язык, факт-ориентированный).

• Отличия от SysML: в самом SysML множество диаграмм изначально, нет языка запросов и мэппинга, нет факт-ориентированности, нет upper ontology и т.д.

• Одновременно product и project модели

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

Контекст объективации• Когда системноинженерный подход сформулирован, можно прийти в

предметную область (объективацию) уже с ним• Не пирамида знаний, не конвейер знаний, не жизненный цикл знаний. Это

модульная диаграмма деятельности объективации (целевое предпринятие – endeavour, нижний слой – собственно инженерия).

• Деятельность – это класс endeavours (при этом endeavours это individuals в 4D)• Конечно, есть и закон Конвея: но как выглядит закон Конвея, если предметом

являются предпринятия?! Разделение труда в объективации (организация труда в обеспечивающем предпринятии объективации).

• Забавно: в онтологических схемках endeavour – пользовательский уровень внизу, а в инженерных модульных обычно пользовательский уровень сверху. Так что можно выбирать: кто мы, и как рисовать схему.

• В модулях самое интересное – это интерфейсы. Интерфейсы определяются стандартами. Стандарты подразумевают множественность реализаций модулей.

• Кроме модульных схем важны компонентные схемы. И гарантии соответствия модульных и компонентных схем в архитектуре.

• Опять же: какие требования для архитектуры? Кто их ставит? 1. Техническое задание для школы (эксплицирование). 2. Я сам, проект 2010 года, RuSEC.

82

Модульная структура объективации. • Философские логики – знаковые системы и их связь с окружающим

миром, предельные онтологи• Рефлексирующие модельеры данных – MOF, Part 2 (Upper ontology,

foundational ontology). Компьютерщики: преобразования одних выражений мысли в другие (теоркатегорное представление, не теория множеств – операции главные, вычисление)

• Модельеры данных/intermediate ontology – одна логика, помогают выразить мысль непротиворечиво (теоретико-множественное представление – объекты главные).

• Ситуационные инженеры методов, кейс менеджмент, BPM, проектные управленцы, оргдизайнеры – мысли о деятельности

• Рефлексирующие инженеры/микротеоретики=онтики – мысли о своей дисциплине (объекты-предметы: системная инженерия, программная инженерия, инженерия предприятия, инженерия психика)

• Профессионалы-инженеры – мысли о своих конкретных целевых объектах (софтинках, самолётиках) и обеспечивающих объектах (то бишь субъектах).

83

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/systems_engineering_thinking--TechInvestLab_2014.pdf