Соединяя точки. Моделе-ориентированный процесс системного проектирования

ЛОЙД БЕЙКЕРСоединяя точки. Соединение информации в MBSE процессе

ДокладчикЛойд Бейкер – вице-президент по технологиям компании 3SL, имеет обширный опыт в обучении автоматизированным MBSE методам крупных американских корпораций и правительственных агентств, таких как НАСА, Федеральное агентство воздушного транспорта США и Министерство энергетики США.Проводит обучение по Cradle (https://www.threesl.com) – инструменту системного проектирования, выбранному НАСА в качестве основного инструмента управления требованиями.В прошлом президент Хантсвиллского отделения Международного совета по системному проектированию (INCOSE)Лауреат премии НАСА "Серебряный Снупи" по поддержке полетов "Аполлона", включая "Аполлон 13".

Инженеры используют большое количество различных «элементов информации» в проектировании, анализе, разработке и проверке новой системы или при изменении уже существующей системы

Примеры «элементов информации»• Потребности заинтересованных сторон• Варианты использования• Сценарии работы•Требования заинтересованных сторон• Системные требования• Интерфейсы• Системная архитектура• Цели верификации• Тесты• и т.д.

Информация

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

Разворачивающийся список

значений категории

Изображение

Бинарный атрибут

Связанные элементы

Описание требования

У каждой точки есть свои виды "атрибутов/свойств", в которых хранятся такие детали, как описание требования, тип требования, и т.д.

Соедините точки вместе, чтобы «рассказать историю» или описать архитектуру

Сам по себе каждый элемент информации имеет ограниченную ценность, но если он связан с другими элементами информации посредством отношений (например, перекрестных ссылок), в таком случае эта информация имеет большую ценность для проекта

relationship relationship

built from

satisfies

derived req

has test plan

consist of

has result

verified by has test

Product (PBS)

1 System Element

2

System Requirement

3

Stakeholder Requirement

4

Test Plan

5

Test Case

6

Test Result

7

Verification Objective

10

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

• Модели используются для того, чтобы «рассказать историю» или описать концепцию.

• Модели повышают качество общения между членами команды, и с клиентом.

• Модели оказались успешными в выполнении различных исследований и разработок (личный опыт)

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

Cradle eFFBD

Проблема...В прошлом Документы и Чертежи в проектах создавались при помощи “элементов информации”, но возникала проблема с сохранением и управлением данными “элементами информации и их связями”.Проблема: Когда информация о проекте распределена по многим документам, отсутствие быстрого доступа и согласованной трассируемости может вызвать проблемы при использовании данных проекта.

Сложно оценить:• Завершенность проекта• Согласованность требований• Интеграцию архитектуры• Влияние изменений• Верификацию• Валидацию• Сквозную трассируемость

=

Современное Системное проектирование, основанное на моделях (MBSE) пропагандирует процессы, ориентированные на модель и данные, а не на традиционные процессы, ориентированные на документы.

Ориентация на документ (в прошлом)

Ориентация на модели и данные (в будущем)

Reference DocumentReference

Document

System

PerformanceRequirement


ConstrainingRequirementConstraining

Requirement

Cradle

Orders

MADP StatusSignals

fromEnvironment

SensorPulses

Supplies

SupplyRequests

EmergencySupply

Request

InformationExchange 1


Node A

*1*

Node B

2

Node C

3

* OV-2 (Operational Node Connectivity Description) *

ForwardArea Commandand Control

Threat

Logistics Support Depot Other MADPs

EmergencySupplyies

Orders

MADP StatusSignals

fromEnvironment

SensorPulses

Supplies

SupplyRequests

EmergencySupply

Request



Node A

*1*

Node B

2

Node C

3



Threat


EmergencySupplyies

ISSUE Verification

SBS

Trade Study

Mission 1Mission 2

Pre-Launch Launch On-orbitPre-Launch Launch On-orbit

Pre-Launch Launch On-orbit

Operation Scenario #3Pre-Launch Launch On-orbitOperational Scenario #1

Pre-Launch Launch On-orbit-Point

CameraTake

picture

Operational Scenario #2

Store picture

Mission 1Mission 2





CameraTake

picture


Store picture

Func 1 Func 2

Func 3

Func 4

Data

Func 1 Func 2

Func 3

Func 4

Data

Func 1 Func 2

Func 3

Func 4

DataData

Func 1 Func 2

Func 3

Func 4

Data

Func 1 Func 2

Func 3

Func 4

DataData

Func 1 Func 2

Func 3

Func 4

DataData

Func 1 Func 2

Func 3

Func 4

DataData

Analysis


Document

System




Requirement

Cradle

Orders

MADP StatusSignals

fromEnvironment

SensorPulses

Supplies

SupplyRequests

EmergencySupply

Request



Node A

*1*

Node B

2

Node C

3



Threat


EmergencySupplyies

Orders

MADP StatusSignals

fromEnvironment

SensorPulses

Supplies

SupplyRequests

EmergencySupply

Request



Node A

*1*

Node B

2

Node C

3



Threat


EmergencySupplyies

ISSUE Verification

SBS

Trade Study

Mission 1Mission 2





CameraTake

picture


Store picture

Mission 1Mission 2





CameraTake

picture


Store picture

Func 1 Func 2

Func 3

Func 4

Data

Func 1 Func 2

Func 3

Func 4

Data

Func 1 Func 2

Func 3

Func 4

DataData

Func 1 Func 2

Func 3

Func 4

Data

Func 1 Func 2

Func 3

Func 4

DataData

Func 1 Func 2

Func 3

Func 4

DataData

Func 1 Func 2

Func 3

Func 4

DataData

Analysis


Document

System




Requirement

Cradle

Orders

MADP StatusSignals

fromEnvironment

SensorPulses

Supplies

SupplyRequests

EmergencySupply

Request



Node A

*1*

Node B

2

Node C

3



Threat


EmergencySupplyies

Orders

MADP StatusSignals

fromEnvironment

SensorPulses

Supplies

SupplyRequests

EmergencySupply

Request



Node A

*1*

Node B

2

Node C

3



Threat


EmergencySupplyies

ISSUE Verification

SBS

Trade Study

Func 1 Func 2

Func 3

Func 4

Data

Func 1 Func 2

Func 3

Func 4

Data

Func 1 Func 2

Func 3

Func 4

DataData

Func 1 Func 2

Func 3

Func 4

Data

Func 1 Func 2

Func 3

Func 4

DataData

Func 1 Func 2

Func 3

Func 4

DataData

Func 1 Func 2

Func 3

Func 4

DataData

Analysis


Document

System




Requirement

Cradle

Orders

MADP StatusSignals

fromEnvironment

SensorPulses

Supplies

SupplyRequests

EmergencySupply

Request



Node A

*1*

Node B

2

Node C

3



Threat


EmergencySupplyies

Orders

MADP StatusSignals

fromEnvironment

SensorPulses

Supplies

SupplyRequests

EmergencySupply

Request



Node A

*1*

Node B

2

Node C

3



Threat


EmergencySupplyies

ISSUE Verification

SBS

Trade Study

Func 1 Func 2

Func 3

Func 4

Data

Func 1 Func 2

Func 3

Func 4

Data

Func 1 Func 2

Func 3

Func 4

DataData

Func 1 Func 2

Func 3

Func 4

Data

Func 1 Func 2

Func 3

Func 4

DataData

Func 1 Func 2

Func 3

Func 4

DataData

Func 1 Func 2

Func 3

Func 4

DataData

Analysis

Проектное хранилище данных сохраняется и передается клиенту

Процессы системного проектирования определяют данные для управления

Выберите MBSE процесс, который будет использоваться в вашем проекте, изучая существующие задокументированные процессы

Процессы технического управления • Анализ решения • Техническое планирование• Техническая оценка • Управление требованиями • Управление архитектурой• Управление рисками • Конфигурационное управление• Управление техническими данными • Управление интерфейсами • Управление трассируемостью

Технические процессы • Разработка требований • Логическая архитектура• Физическая архитектура• Проектное решение • Реализация • Интеграция • Верификация • Валидация • Переход

На основе ваших SE процессов в проекте и результатах проекта, определяется набор “точек” и их “связей”, которые будут получены для вашего проекта. Ниже представлен пример структуры базы данных для большого проекта НАСА.

Данные первичные параллельные/ повторяющиеся задачи выполняются

для каждого проектного уровня архитектуры проекта/системы

Определение требований

• Заинтересованные стороны и исх. материалы• Контекст работ и варианты использования •Сценарии работ, обмен информацией• Набор требований заинтересованных сторон•Проектные и MOE ограничения•Проблемы/Риски/Решения

Анализ логическойархитектуры

• Разработать функциональные модели системы• Провести трассировку между функциямии требованиями• Определить логические входы и выходы•Привязать функции к архитектурным сущностям•Привязать логические входы/выходы

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

Анализ физическойархитектуры

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

•Оценка рисков•Оценка соответствия и затрат•Верификация и Валидация проекта

Оценка продукта и генерация документов

Результаты анализаСпецификации

•Управление конфигурацией•Планирование тестирования•Метрики

Функциональные модели Представления физической архитектуры

Список архитектурных сущностей

Технические правила, стандарты, конвенции

R1-1

R1 R2

R

Проблема

Риск

F1 F5

F2 F3

F4

Система систем

Mission 1Mission 2





CameraTake

picture


Store picture

Задача 1Задача 2



Operation Scenario #3Pre-Launch Launch On-orbitСценарий работы #1

Pre-Launch Launch On-orbit-Выбрать

КамеруСделать

снимок

Сценарий работы #2

Сохранитьснимок

Определить:

Интерфейсы

Пример процесса системного проектирования, основанного на моделях

Примените Процессы проекта в Уровнях, чтобы снизить риск

Задачи по проектированию архитектуры продукта используются для преобразования согласованных исходных требований и ограничений в проектное решение с правильным

балансом между производительностью, риском, затратами, и расписанием.

Определение требований Анализ логическойархитектуры

Анализ физической

Оценкапроекта

иГенерациядокумента

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

иисходные

материалы

Функц.моделисистемы

ПривязатьФункции кСистеме

и перейти вниз

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

ПроектУровень

“1” Ограниченияпроекта Структура

системы

Контекстработ,

Вариант использ.,

сценарии

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

ПроектУровень

“n”

Design in Layers

Специф.системы

Анализпривязанных

функцийи

интерфейсов

архитектуры

Определение требований Анализ логическойархитектуры

Анализ физическойархитектуры

Оценкапроекта

иГенерациядокумента

Специф.подсистемы

Контекстработ,

Вариант использ.,сценарии

Ограниченияпроекта

Требования подсистемы

Функц.модели

подсистемы

ПривязатьФункции кподсистемеи перейти

вниз

Структураподсистемы

Интерфейсыподсистемы

Анализпривязанных

функцийи

интерфейсов

Интегрируйте модели и требования на каждом уровне структуры архитектуры

Архитектура Уровень 1 Модели

Child Child Child

Requirementтребование

Подсист.X.3 функц.модель

(SBS)

Переходот родительского элементак дочернему

Горизонтальная трассировка

Вертикальная трассировка

Equip X.3

Equip X.3.1 Equip X.3.2 EquipX.3.3

SBS 1.3.1 SBS 1.3.2 SBS 1.3.3

SBS 1

SBS 1.1 SBS 1.3SBS 1.2

Child Child Child

Requirement

Дочер. Дочерн. дочерн

требование

Equip X

Equip X.1 Equip X.2 EquipX.3

Система X

Подсист.X.1

operation1

Data

operation2операция 1

Dataданные

операция 2

operation1

Data

operation2operation1

DataData

operation2

Сценарий работы

Структурная Декомпозиция Системы

Архитектура Уровень 2 Модели

Переходот родительского элементак дочернему

Подсист.X.2 Подсист.X.3

Система X.3

Подсист.X.3.1 Подсист.X.3.2 Подсист.X.3.3

дочь дочь дочь

Сценарий работы Подсист.X. функц.модель

1. "Основные понятия Системного проектирования на основе моделей,"доклад, INCOSE, Model Driven System Design Interest Group, Международный совет по системному проектированию, 15 июля 2000, Лойд Бейкер, Пол Клемент, Боб Коен, Ларри Перментер, Байорн Первес, Пит Салмон

2. Комплексные инженерные системы с Моделями и Объектами, Дэвид В. Оливер, Тимоти П. Келлиэр и Джеймс Г. Кигэн

3. Оптимизация Разработки требований посредством Системного проектирования на основе моделей, Роберт Бейт, Энн Кристиан, Филип Неррен и Рич Делуф, НАСА PM Challenge 2010

4. Практическое руководство по SysML, Фридентал Сэнфорд, Алан Мур, и Рик Штайнер

5. SysML с нуля, Краткое руководство по системному языку моделирования, Ленни Деллигэтти

6. Разработка и управление требованиями с использованием Cradle, Лойд Бейкер, 2014,

https://www.threesl.com/pages/news/webletter-November14/REQ-Cradle-white-paper-v8-1.pdf

Ссылки на материалы по Системному проектированию, основанному на модели (MBSE)

Характеристики Системное проектирование, основанное на модели

Системное проектирование, ориентированное на документы

Хранилище данных Модели (Данные и Схемы) ДокументыРецензирование (SDR, PDR, CDR)

Посредством запросов к данным и диаграммам (автоматизированно)

Читает и интерпретирует текст, а затем сравнивает

Верификация Неявная, инкрементальная, автоматизированная, встроенная в процесс

Проведение аудита человеком

Коммуникации Воспроизводимая и непротиворечивая

Ответы могут зависеть от перспективы читателей

Валидация Выполняется в различных контекстах (например, контексте клиента, контексте конечных пользователей, и т.д.)

Испытание, рецензии

Трассируемость Интегральная Поддержание точной крайне трудоемкая задача

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

Преимущества MBSE над процессами, ориентированными на документы, состоят из двух существенных признаков хорошей модели:

Данная информация взята с 1 источника на предыдущем слайде.

• Для поддержки каждого процесса были определены нотации моделирования. Для поддержки системного проектирования использовался Cradle.

• Cradle не поддерживал SysML в момент разработки проекта, поэтому использовались традиционные eFFBDs (улучшенные Функциональные блок-схемы) и PADs (схемы Физической архитектуры). Поддержка SysML станет доступна в начале 2016, что позволит будущим проектам выбирать наиболее подходящие нотации.

• В проекте были выполнены исследования Временной шкалы событий миссии, при помощи Аналитического инструмента Временной шкалы Cradle-Excel.

• Фактические модели НАСА здесь не представлены, поскольку они не были одобрены для публичного показа.

На следующих слайдах представлены задачи MBSE, успешно используемые в проекте НАСА

Задачи MBSE сгруппированы в восемь этапов и отражены на следующем рисунке.

Узлы "Iterate" (кружки с символом I внутри) означают, что все этапы, расположенные между двумя такими узлами, повторяются для каждого уровня системной архитектуры. Параллельные узлы (кружки с символом "AND" внутри) показывают, что этапы 3,4 и 5 между двумя узлами "AND", могут выполняться параллельно.

Задачи MBSE, успешно используемые в проекте НАСА

Этап 1 - Разработка концепции системы и требований заинтересованных сторон:

Эти действия выполняются в начале проекта и необходимы для определения границ проекта, подготовки документа концепции функционирования системы (ConOps), после чего осуществляется разработка требований заинтересованных сторон и публикуется документ в Stakeholder Requirements Specification (StRS).

Диаграммы Cradle типа PFD (Process Flow Diagram) используются для описания действий, необходимых для осуществления вариантов использования. Данные PFD диаграммы также называются диаграммами сценариев работы. Выявленные операции помогают пользователю получить необходимые требования заинтересованных сторон.

Этап 1 - Разработка концепции системы и требований заинтересованных сторон :2

Следующая таблица трассируемости Cradle показывает требования заинтересованных сторон, полученные из сценария работы, который описывает определенный вариант использования. Сценарий работы был показан на схеме PFD на предыдущем слайде. Автоматизированные инструменты необходимы для поддержки просмотра информации различными способами в соответствии с требованиями клиента.

Этап 1 - Разработка концепции системы и требований заинтересованных сторон :3

Этап 2 – Определение границ системы и ее контекстаВ рамках этого этапа выполняется разработка контекстной диаграммы для элемента, соответствующего системе в целом, на которой определяются все внешние сущности, которые должны взаимодействовать с системой и требуемые внешние интерфейсы. Эти внешние интерфейсы должны быть определены до начала этапов 3-7.

Этап 3 – Определение элементов системыНа этом этапе осуществляется определение физических характеристик системного элемента, затем определяются соответствующие производные системные требования, после чего производится его декомпозиция на составные части (на один уровень вниз по иерархии), а также определение предварительных физических характеристик для каждого подчиненного элемента.

Первичный “ элемент системы ”, для которого формируются требования в течение текущего цикла проектированияВсегда идите на один уровень ниже в иерархии и определяйте кандидатов в дочерние “ элементы системы”. В течение следующего цикла каждый дочерний элемент становится основным, и этот процесс повторяется

Структура элемента системы (составные части на один уровень вниз по иерархии) определяется для того, чтобы привязать функции и требования к составным частям. Эта Cradle схема также известна как Диаграмма физической архитектуры (PAD).

Этап 3 – Определение элементов системы :2

Этап 4 – Определение функций и поведения системыНа данном этапе определяются системные функции и их входы и выходы, которые удовлетворяют функциональным требованиям для системного элемента, выявленных на предыдущем цикле проектирования. Эти функции, собранные вместе, описывают желаемое поведение, которым должна обладать система. На 5 этапе, функции/интерфейсы должны быть распределены по конкретным элементам системы (т.е. по тем, которые должны выполнять эти функции).

Функция 3

Функция 2 AND Данны е

Функция 4

Функц-ое системное требование

Да нны е

Подфункция функции 4

Подфункция функции 4

Функц- ое системное

требование

удовлетворяет

удовлетворяет

производные

Функц-ое системное требование

Расширенная блок-схема функций (Functional Flow Block Diagram, eFFBD) описывает желаемое поведение, которым должна обладать система. Эта Cradle схема также известна как Диаграмма поведения. Она используется для определения системных функций, из которых получены функциональные требования.

Этап 4 – Определение функций и поведения системы :2

Следующая таблица трассируемости Cradle показывает функциональные требования, полученные из функционального поведения системы, показанного на схеме eFFBD, представленной на предыдущем слайде.

Этап 4 – Определение функций и поведения системы :3

Этап 5 – Привязка функций и интерфейсов к элементам системыНа этом этапе функции и соответствующие входы/выходы (определенные на этапе 4) назначаются различным подсистемам и интерфейсам. 1. Распределение функций присваивает желаемое поведение различным

элементам системы.

System Element System Element

System

INTERFACEDerived

Nonfunctional System Requirements

Derived Functional System

Requirements

Derived Interface System

Requirements

allocate

satisfy

satisfy

allocate

satisfyData

ANDFunction 1 Function 2

Function 3

Function 4

Data

satisfy

Этап 5 – Привязка функций и интерфейсов к элементам системы :22. На основе входа-выхода, произведенного и использованного функциями,

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

Производные не функциональные системные требования

Производные требования к интерфейсам

3. Поскольку у каждой привязанной функции и привязанного интерфейса есть ссылки трассируемости к удовлетворяемым требованиям, эти требования косвенно привязываются элементам системы и интерфейсам.

Этап 5 – Привязка функций и интерфейсов к элементам системы :3

Функция 1 Функция 2

Система

Элемент системы

Элемент системы

Удовл.

Удовлетв.

Данные

AND

Функция 3

Д ан ны е

Удовл. Удовл.

Производные

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

Производные не функц-ые системные требования

Производные не функц-ые системные требования

Привязка Привязка

Функция 4

ИНТЕРФЕЙС

Следующая таблица трассируемости Cradle показывает функциональные и нефункциональные требования, привязанные к элементам системы. (например, элемент оборудования в Cradle).


Следующая таблица трассируемости Cradle показывает требования к интерфейсу, привязанные к интерфейсам Определения данных (DD), показанные на схеме физической архитектуры (PAD).


Этап 6 – Планирование анализа и верификации системных требованийНа этом этапе системные требования, полученные на этапах 3-5, анализируются для определения их ясности, полноты, согласованности и трассируемости к требованиям заинтересованных сторон/системным, полученным в конце предыдущего цикла проектирования. Кроме того, должны быть запланированы действия по проверке новых системных требований, а затем установлена подходящая трассируемость.

built from

satisfies

derived req

has test plan

consist of

has result

verified by

identifies

has test

Product (PBS)

1 System Element

2

System Requirement

3

Stakeholder Requirement

4

Test Plan

5

Test Case

6

Test Result

7

Use Case (Specification)

8

Verification Objective

10

Присвойте время (продолжительность, и дополнительно настраиваемое время начала) к Функциям, и выполните их в динамическом режиме. Для проверки: функции выполняются в упорядоченной последовательности желаемого времени.

Модельное время (Дни/Часы: Минуты: Секунды)

Выполните анализ временной анализ определенного поведения (например, функциональных моделей)

Загрузите функциональные модели Cradle в Excel для Анализа Временной шкалы

Лист настроек Временной шкалы выводит список функций и времени, скачанных с Cradle

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

Маркер декомпозиции считывается из диаграммы группы атрибутов в базе данных Cradle. Он устанавливается на 1 в базе данных, чтобы показать, что декомпозиция функций включена в анализ.

Результаты моделирования выводятся на “Листе результатов Временной шкалы”

Вычисленное время моделирования (функциональный запуск и время окончания)

Проверьте функции, выполненные в желаемом порядке с корректным входом-выходом

Этап 7 – Генерация документации для системы и элементов системыБудь то рецензирование, утверждение, ведение документации, обучение или другие цели; подготовка документации является важной и часто трудоемкой задачей для проекта. Возможность Cradle составлять отчеты и документы Word автоматизированным и специализированным способом, поддерживает все потребности проекта по генерации документов, при этом экономя время и обеспечивая согласованность с форматами и стандартами документации.


Document

System




Requirement

Cradle

Orders

MADP StatusSignals

fromEnvironment

SensorPulses

Supplies

SupplyRequests

EmergencySupply

Request



Node A

*1*

Node B

2

Node C

3



Threat


EmergencySupplyies

Orders

MADP StatusSignals

fromEnvironment

SensorPulses

Supplies

SupplyRequests

EmergencySupply

Request



Node A

*1*

Node B

2

Node C

3



Threat


EmergencySupplyies

ISSUE Verification

SBS

Trade Study

Mission 1Mission 2





CameraTake

picture


Store picture

Mission 1Mission 2





CameraTake

picture


Store picture

Func 1 Func 2

Func 3

Func 4

Data

Func 1 Func 2

Func 3

Func 4

Data

Func 1 Func 2

Func 3

Func 4

DataData

Func 1 Func 2

Func 3

Func 4

Data

Func 1 Func 2

Func 3

Func 4

DataData

Func 1 Func 2

Func 3

Func 4

DataData

Func 1 Func 2

Func 3

Func 4

DataData

Analysis


Document

System




Requirement

Cradle

Orders

MADP StatusSignals

fromEnvironment

SensorPulses

Supplies

SupplyRequests

EmergencySupply

Request



Node A

*1*

Node B

2

Node C

3



Threat


EmergencySupplyies

Orders

MADP StatusSignals

fromEnvironment

SensorPulses

Supplies

SupplyRequests

EmergencySupply

Request



Node A

*1*

Node B

2

Node C

3



Threat


EmergencySupplyies

ISSUE Verification

SBS

Trade Study

Mission 1Mission 2





CameraTake

picture


Store picture

Mission 1Mission 2





CameraTake

picture


Store picture

Func 1 Func 2

Func 3

Func 4

Data

Func 1 Func 2

Func 3

Func 4

Data

Func 1 Func 2

Func 3

Func 4

DataData

Func 1 Func 2

Func 3

Func 4

Data

Func 1 Func 2

Func 3

Func 4

DataData

Func 1 Func 2

Func 3

Func 4

DataData

Func 1 Func 2

Func 3

Func 4

DataData

Analysis


Document

System




Requirement

Cradle

Orders

MADP StatusSignals

fromEnvironment

SensorPulses

Supplies

SupplyRequests

EmergencySupply

Request



Node A

*1*

Node B

2

Node C

3



Threat


EmergencySupplyies

Orders

MADP StatusSignals

fromEnvironment

SensorPulses

Supplies

SupplyRequests

EmergencySupply

Request



Node A

*1*

Node B

2

Node C

3



Threat


EmergencySupplyies

ISSUE Verification

SBS

Trade Study

Func 1 Func 2

Func 3

Func 4

Data

Func 1 Func 2

Func 3

Func 4

Data

Func 1 Func 2

Func 3

Func 4

DataData

Func 1 Func 2

Func 3

Func 4

Data

Func 1 Func 2

Func 3

Func 4

DataData

Func 1 Func 2

Func 3

Func 4

DataData

Func 1 Func 2

Func 3

Func 4

DataData

Analysis


Document

System




Requirement

Cradle

Orders

MADP StatusSignals

fromEnvironment

SensorPulses

Supplies

SupplyRequests

EmergencySupply

Request



Node A

*1*

Node B

2

Node C

3



Threat


EmergencySupplyies

Orders

MADP StatusSignals

fromEnvironment

SensorPulses

Supplies

SupplyRequests

EmergencySupply

Request



Node A

*1*

Node B

2

Node C

3



Threat


EmergencySupplyies

ISSUE Verification

SBS

Trade Study

Func 1 Func 2

Func 3

Func 4

Data

Func 1 Func 2

Func 3

Func 4

Data

Func 1 Func 2

Func 3

Func 4

DataData

Func 1 Func 2

Func 3

Func 4

Data

Func 1 Func 2

Func 3

Func 4

DataData

Func 1 Func 2

Func 3

Func 4

DataData

Func 1 Func 2

Func 3

Func 4

DataData

Analysis

Хранилище данных Cradle

Этап 8 – Трассируемость системной верификации и валидации (V&V) Зафиксируйте статус каждой задачи по верификации и валидации в базе данных с трассировкой обратно к затрагиваемым требованиям и сценариям работы системы. • Трассируемость верификации. Цель процесса верификации заключается в подтверждении, что системой выполняются указанные проектные требования (например, системные требования).• Трассируемость валидации. Целью данного процесса валидации является предоставление объективных доказательств, что услуги, которые предоставляются системой при использовании в соответствии с требованиями заказчиков, реализуют поставленные цели в соответствующем рабочем окружении.

SysML– это новый язык моделирования, который может использоваться для поддержки MBSE

Язык моделирования систем (SysML) был разработан Консорциумом по технологии управления объектами (OMG) наряду с другими представителями данной отрасли. Существует девять SysML диаграмм, используемых для описания следующих областей системы:

• Структура• Поведение• Требования• Параметрические ограничения• Пакеты

Примеры таких диаграмм, представлены на следующих слайдах

Cradle SysML диаграмма вариантов использования (uc) и сценарии работыДиаграмма вариантов использования отображает набор вариантов использования (цели для подсистемы), а также действующих лиц/заинтересованные стороны, которые задействованы в этих вариантах использования.Чтобы понять вариант использования, мы "рассказываем истории" (т.е., создаем один или несколько сценариев работы для каждого варианта использования). Эти истории описывают, как успешно достигнуть цели/миссии, и как справиться с любыми ошибками/проблемами, которые могут возникнуть на пути. Для создания этих сценариев используется Диаграмма задач (см. следующий слайд).

Cradle SysML диаграмма вариантов использования (uc) и сценарии работы :2Диаграмма задач используется для создания сценариев работы,связанных перекрестными ссылками с вариантом использования, который описывает сценарий.

Cradle SysML диаграмма определения блока (bdd) – Структура системыbdd диаграмма показывает структуру предлагаемой системы (т. е. составных частей). Блоки - основной структурный элемент, используемый для моделирования структуры системы. Блок может быть двух типов: тип 'вещь' (например, система, свет, доклад, организация, человек и т. д.), и тип ‘блок-ресурсы' – т.е. потоковые ‘вещи’, такие как материя, энергия или данные. Обратите внимание, каким образом некоторые из составных частей показывают компоненты нижнего уровня.

Cradle SysML диаграмма определения внутреннего Блока (ibd)Диаграмма внутреннего блока (ibd) используется для определения как части указанных блоков должны соединяться между собой и как эти части соединяются со внешними сущностями. Как они отображают информацию по интерфейсу.

Диаграмма задач используется для моделирования поведения ‘вещи' или ‘процесса'. Поведение (представленное на Диаграмма задач) показывает трансформацию входов в выходы посредством регулируемой последовательности действий в хронологическом порядке.

Cradle SysML диаграмма задач (act)

Диаграмма конечных автоматов используется в SysML для описания зависящего от состояния поведения блока в течение всего жизненного цикла, с точки зрения его состояний и переходов между ними.

Cradle SysML диаграмма конечных автоматов (stm)

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

Cradle SysML схема последовательности (sd)

Модели параметров изображают сеть уравнений, которые ограничивают свойства блоковСвойства системы связаны с параметрами аналитических уравнений (например, масса механизма связана с ‘m’ в уравнении F=m x a),В примере Диаграммы параметров, переменные состояния системы связаны с параметрами уравнений, используемых для анализа системных ограничений. Таким образом модели параметров помогают выявить свойства системы, которые имеют решающее значение для удовлетворения потребностей.

Cradle SysML диаграмма параметров (par)

Cradle SysML диаграмма пакетов (pkg)Диаграмма пакетов разработана для того, чтобы группировать элементы модели, диаграммы и другие пакеты. Поскольку пакет может содержать в себе другой пакет, можно определить иерархию пакетов, чтобы сгруппировать/организовать диаграммы и элементы моделирования.

Cradle SysML таблица требованийТребования отображаются в 'табличной форме', при помощи генератора вложенного табличного представления Cradle.

Является ли Системное проектирование, основанное на моделях (MBSE) чем-то новым? Нет. MBSE методы и приемы самостоятельно практикуют многие хорошие инженеры и аналитики на протяжении многих лет. Процесс MBSE, представленный в этой презентации, описывает Общее представление о соединении информации в единое целое.Основная проблема заключается в том, что управление проектом направлено на ‘отчетные документы’ вместо создания проектной модели данных, которая может использоваться для поддержания анализа, сквозной трассируемости, и автоматической генерации отчетных документов из модели данных.• Проектная модель данных обычно состоит из сущностей, атрибутов,

отношений и диаграмм, которые определяют архитектуру системы. • Помните, что диаграмма (графическая модель) передает информацию

лучше тысячи слов. Эти схемы помогают связывать идеи/концепции между персоналом проекта и клиентом.

• Новым же является язык моделирования SysML. Он должен помочь с решением вопросов коммуникации, путем стандартного способа описания архитектуры систем.

Если у вас есть вопросы по MBSE процессам, свяжитесь со мной по электронной почте [email protected]

Заключение

mailto:[email protected]

Engineering

Соединяя точки. Моделе-ориентированный процесс системного проектирования