Соединяя точки. Моделе-ориентированный процесс системного проектирования
Download as PPTX, PDF4 likes6,850 views
Доклад Ллойда Бейкера освещает использование методов системного проектирования на основе моделей (MBSE) в компаниях и государственных агентствах, таких как NASA. Основное внимание уделяется необходимости объединения различных элементов информации и их взаимосвязей для достижения успешного проектирования и управления требованиями. Упоминается важность автоматизированных инструментов, таких как Cradle, для повышения эффективности проектирования и уменьшения рисков, связанных с распределенной информацией.
Соединяя точки. Моделе-ориентированный процесс системного проектирования
- 1. ЛОЙД БЕЙКЕР Соединяя точки. Соединение информации в MBSE процессе
- 2. Докладчик Лойд Бейкер – вице-президент по технологиям компании 3SL, имеет обширный опыт в обучении автоматизированным MBSE методам крупных американских корпораций и правительственных агентств, таких как НАСА, Федеральное агентство воздушного транспорта США и Министерство энергетики США. Проводит обучение по Cradle (https://www.threesl.com) – инструменту системного проектирования, выбранному НАСА в качестве основного инструмента управления требованиями. В прошлом президент Хантсвиллского отделения Международного совета по системному проектированию (INCOSE) Лауреат премии НАСА "Серебряный Снупи" по поддержке полетов "Аполлона", включая "Аполлон 13".
- 3. Инженеры используют большое количество различных «элементов информации» в проектировании, анализе, разработке и проверке новой системы или при изменении уже существующей системы Примеры «элементов информации» • Потребности заинтересованных сторон • Варианты использования • Сценарии работы •Требования заинтересованных сторон • Системные требования • Интерфейсы • Системная архитектура • Цели верификации • Тесты • и т.д. Информация Стандартные процессы и автоматизированные инструменты могут стать большим подспорьем в управлении всеми «точками» на сегодняшнем конкурентном рынке.
- 4. Разворачивающийся список значений категории Изображение Бинарный атрибут Связанные элементы Описание требования У каждой точки есть свои виды "атрибутов/свойств", в которых хранятся такие детали, как описание требования, тип требования, и т.д.
- 5. Соедините точки вместе, чтобы «рассказать историю» или описать архитектуру
- 6. Сам по себе каждый элемент информации имеет ограниченную ценность, но если он связан с другими элементами информации посредством отношений (например, перекрестных ссылок), в таком случае эта информация имеет большую ценность для проекта 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
- 7. • Системные инженеры строят модели, чтобы лучше понять проблемы, разработать способы их решения, а также проверить проектные решения. • Модели используются для того, чтобы «рассказать историю» или описать концепцию. • Модели повышают качество общения между членами команды, и с клиентом. • Модели оказались успешными в выполнении различных исследований и разработок (личный опыт) Некоторые концепции или истории лучше всего передаются через диаграмму (т.е. концептуальную модель) Cradle eFFBD
- 8. Проблема...В прошлом Документы и Чертежи в проектах создавались при помощи “элементов информации”, но возникала проблема с сохранением и управлением данными “элементами информации и их связями”. Проблема: Когда информация о проекте распределена по многим документам, отсутствие быстрого доступа и согласованной трассируемости может вызвать проблемы при использовании данных проекта. Сложно оценить: • Завершенность проекта • Согласованность требований • Интеграцию архитектуры • Влияние изменений • Верификацию • Валидацию • Сквозную трассируемость =
- 9. Современное Системное проектирование, основанное на моделях (MBSE) пропагандирует процессы, ориентированные на модель и данные, а не на традиционные процессы, ориентированные на документы. Ориентация на документ (в прошлом) Ориентация на модели и данные (в будущем) Reference DocumentReference Document System Performance Requirement Performance Requirement Constraining RequirementConstraining Requirement Cradle ISSUE Verification SBS Trade Study Mission 1 Mission 2 Pre-Launch Launch On-orbit Pre-Launch Launch On-orbit Pre-Launch Launch On-orbit Operation Scenario #3Pre-Launch Launch On-orbit Operational Scenario #1 Pre-Launch Launch On-orbit -Point Camera Take picture Operational Scenario #2 Store picture Mission 1 Mission 2 Pre-Launch Launch On-orbit Pre-Launch Launch On-orbit Pre-Launch Launch On-orbit Operation Scenario #3Pre-Launch Launch On-orbit Operational Scenario #1 Pre-Launch Launch On-orbit -Point Camera Take picture Operational Scenario #2 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 Reference DocumentReference Document System Performance Requirement Performance Requirement Constraining RequirementConstraining Requirement Cradle ISSUE Verification SBS Trade Study Mission 1 Mission 2 Pre-Launch Launch On-orbit Pre-Launch Launch On-orbit Pre-Launch Launch On-orbit Operation Scenario #3Pre-Launch Launch On-orbit Operational Scenario #1 Pre-Launch Launch On-orbit -Point Camera Take picture Operational Scenario #2 Store picture Mission 1 Mission 2 Pre-Launch Launch On-orbit Pre-Launch Launch On-orbit Pre-Launch Launch On-orbit Operation Scenario #3Pre-Launch Launch On-orbit Operational Scenario #1 Pre-Launch Launch On-orbit -Point Camera Take picture Operational Scenario #2 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 Reference DocumentReference Document System Performance Requirement Performance Requirement C R Cradle ISSUE Verificat SBS Mission 1 Mission 2 Pre-Launch Launch On-orbit Pre-Launch Launch On-orbit Pre-Launch Launch On-orbit Operation Scenario #3Pre-Launch Launch On-orbit Operational Scenario #1 Pre-Launch Launch On-orbit -Point Camera Take picture Operational Scenario #2 Store picture Mission 1 Mission 2 Pre-Launch Launch On-orbit Pre-Launch Launch On-orbit Pre-Launch Launch On-orbit Operation Scenario #3Pre-Launch Launch On-orbit Operational Scenario #1 Pre-Launch Launch On-orbit -Point Camera Take picture Operational Scenario #2 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 Reference DocumentReference Document System Performance Requirement Performance Requirement C R Cradle ISSUE Verificat SBS Mission 1 Mission 2 Pre-Launch Launch On-orbit Pre-Launch Launch On-orbit Pre-Launch Launch On-orbit Operation Scenario #3Pre-Launch Launch On-orbit Operational Scenario #1 Pre-Launch Launch On-orbit -Point Camera Take picture Operational Scenario #2 Store picture Mission 1 Mission 2 Pre-Launch Launch On-orbit Pre-Launch Launch On-orbit Pre-Launch Launch On-orbit Operation Scenario #3Pre-Launch Launch On-orbit Operational Scenario #1 Pre-Launch Launch On-orbit -Point Camera Take picture Operational Scenario #2 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 Проектное хранилище данных сохраняется и передается клиенту Процессы системного проектирования определяют данные для управления
- 10. Выберите MBSE процесс, который будет использоваться в вашем проекте, изучая существующие задокументированные процессы Процессы технического управления • Анализ решения • Техническое планирование • Техническая оценка • Управление требованиями • Управление архитектурой • Управление рисками • Конфигурационное управление • Управление техническими данными • Управление интерфейсами • Управление трассируемостью Технические процессы • Разработка требований • Логическая архитектура • Физическая архитектура • Проектное решение • Реализация • Интеграция • Верификация • Валидация • Переход
- 11. На основе ваших SE процессов в проекте и результатах проекта, определяется набор “точек” и их “связей”, которые будут получены для вашего проекта. Ниже представлен пример структуры базы данных для большого проекта НАСА.
- 12. Данные первичные параллельные/ повторяющиеся задачи выполняются для каждого проектного уровня архитектуры проекта/системы Определение требований • Заинтересованные стороны и исх. материалы • Контекст работ и варианты использования •Сценарии работ, обмен информацией • Набор требований заинтересованных сторон •Проектные и MOE ограничения •Проблемы/Риски/Решения Анализ логической архитектуры •Разработать функциональные модели системы •Провести трассировку между функциями и требованиями •Определить логические входы и выходы • Привязать функции к архитектурным сущностям • Привязать логические входы/выходы к интерфейсам Анализ физической архитектуры •Определить архитектуру структуры (т.е., Иерархию архитектурных сущностей) и физические интерфейсы •Проанализировать привязанные функции и Входы/выходы Привязать ограничивающие требования к Архитектурным сущностям • Оценка рисков • Оценка соответствия и затрат • Верификация и Валидация проекта Оценка продукта и генерация документов Результаты анализа Спецификации • Управление конфигурацией • Планирование тестирования • Метрики Функциональные модели Представления физической архитектуры Список архитектурных сущностей Технические правила, стандарты, конвенции R1-1 R1 R2 R Проблема Риск F1 F5 F2 F3 F4 Система систем Mission 1 Mission 2 Pre-Launch Launch On-orbit Pre-Launch Launch On-orbit Pre-Launch Launch On-orbit Operation Scenario #3Pre-Launch Launch On-orbit Operational Scenario #1 Pre-Launch Launch On-orbit -Point Camera Take picture Operational Scenario #2 Store picture Задача 1 Задача 2 Pre-Launch Launch On-orbit Pre-Launch Launch On-orbit Pre-Launch Launch On-orbit Operation Scenario #3Pre-Launch Launch On-orbit Сценарий работы #1 Pre-Launch Launch On-orbit -Выбрать Камеру Сделать снимок Сценарий работы #2 Сохранить снимок Определить: Интерфейсы Пример процесса системного проектирования, основанного на моделях
- 13. Примените Процессы проекта в Уровнях, чтобы снизить риск Задачи по проектированию архитектуры продукта используются для преобразования согласованных исходных требований и ограничений в проектное решение с правильным балансом между производительностью, риском, затратами, и расписанием. Определение требований Анализ логической архитектуры Анализ физической Оценка проекта и Генерация документа Потребности Заинт.сторон и исходные материалы Функц. модели системы Привязать Функции к Системе и перейти вниз Интерфейсы системы Проект Уровень “1” Ограничения проекта Структура системы Контекст работ, Вариант использ., сценарии Требования системы Проект Уровень “n” Design in Layers Специф. системы Анализ привязанных функций и интерфейсов архитектуры Определение требований Анализ логической архитектуры Анализ физической архитектуры Оценка проекта и Генерация документа Специф. подсистемы Контекст работ, Вариант использ., сценарии Ограничения проекта Требования подсистемы Функц. модели подсистемы Привязать Функции к подсистеме и перейти вниз Структура подсистемы Интерфейсы подсистемы Анализ привязанных функций и интерфейсов
- 14. Интегрируйте модели и требования на каждом уровне структуры архитектуры Архитектура Уровень 1 Модели Child Child Child Requirementтребование Подсист.X.3 функц.модель (SBS) Переход от родительского элемента к дочернему Горизонтальная трассировка Вертикальная трассировка Equip X.3 Equip X.3.1 Equip X.3.2 EquipX.3.3 SBS1.3.1 SBS1.3.2 SBS1.3.3 SBS1 SBS1.1 SBS1.3SBS1.2 Child Child Child Requirement Дочер. Дочерн. дочерн требование Equip X Equip X.1 Equip X.2 EquipX.3 Система X Подсист.X.1 operation 1 Data operation 2операция 1 Dataданные операция 2 operation 1 Data operation 2operation 1 DataData operation 2 Сценарий работы Структурная Декомпозиция Системы Архитектура Уровень 2 Модели Переход от родительского элемента к дочернему Подсист.X.2 Подсист.X.3 Система X.3 Подсист.X.3.1 Подсист.X.3.2 Подсист.X.3.3 дочь дочь дочь Сценарий работы Подсист.X. функц.модель
- 15. 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)
- 16. Характеристики Системное проектирование, основанное на модели Системное проектирование, ориентированное на документы Хранилище данных Модели (Данные и Схемы) Документы Рецензирование (SDR, PDR, CDR) Посредством запросов к данным и диаграммам (автоматизированно) Читает и интерпретирует текст, а затем сравнивает Верификация Неявная, инкрементальная, автоматизированная, встроенная в процесс Проведение аудита человеком Коммуникации Воспроизводимая и непротиворечивая Ответы могут зависеть от перспективы читателей Валидация Выполняется в различных контекстах (например, контексте клиента, контексте конечных пользователей, и т.д.) Испытание, рецензии Трассируемость Интегральная Поддержание точной крайне трудоемкая задача •Выразительность. Возможность выразить сложную информацию понятными способами. Модели могут достичь этой выразительности при помощи логических и физических представлений. •Строгость. По сравнению с текстовыми представлениями, исполняемые модели обеспечивают четкие и однозначные определения. Преимущества MBSE над процессами, ориентированными на документы, состоят из двух существенных признаков хорошей модели: Данная информация взята с 1 источника на предыдущем слайде.
- 17. • Для поддержки каждого процесса были определены нотации моделирования. Для поддержки системного проектирования использовался Cradle. • Cradle не поддерживал SysML в момент разработки проекта, поэтому использовались традиционные eFFBDs (улучшенные Функциональные блок-схемы) и PADs (схемы Физической архитектуры). Поддержка SysML станет доступна в начале 2016, что позволит будущим проектам выбирать наиболее подходящие нотации. • В проекте были выполнены исследования Временной шкалы событий миссии, при помощи Аналитического инструмента Временной шкалы Cradle-Excel. • Фактические модели НАСА здесь не представлены, поскольку они не были одобрены для публичного показа. На следующих слайдах представлены задачи MBSE, успешно используемые в проекте НАСА
- 18. Задачи MBSE сгруппированы в восемь этапов и отражены на следующем рисунке. Узлы "Iterate" (кружки с символом I внутри) означают, что все этапы, расположенные между двумя такими узлами, повторяются для каждого уровня системной архитектуры. Параллельные узлы (кружки с символом "AND" внутри) показывают, что этапы 3,4 и 5 между двумя узлами "AND", могут выполняться параллельно. Задачи MBSE, успешно используемые в проекте НАСА
- 19. Этап 1 - Разработка концепции системы и требований заинтересованных сторон: Эти действия выполняются в начале проекта и необходимы для определения границ проекта, подготовки документа концепции функционирования системы (ConOps), после чего осуществляется разработка требований заинтересованных сторон и публикуется документ в Stakeholder Requirements Specification (StRS).
- 20. Диаграммы Cradle типа PFD (Process Flow Diagram) используются для описания действий, необходимых для осуществления вариантов использования. Данные PFD диаграммы также называются диаграммами сценариев работы. Выявленные операции помогают пользователю получить необходимые требования заинтересованных сторон. Этап 1 - Разработка концепциисистемы и требований заинтересованныхсторон :2
- 21. Следующая таблица трассируемости Cradle показывает требования заинтересованных сторон, полученные из сценария работы, который описывает определенный вариант использования. Сценарий работы был показан на схеме PFD на предыдущем слайде. Автоматизированные инструменты необходимы для поддержки просмотра информации различными способами в соответствии с требованиями клиента. Этап 1 - Разработка концепции системы и требований заинтересованных сторон :3
- 22. Этап 2 – Определение границ системы и ее контекста В рамках этого этапа выполняется разработка контекстной диаграммы для элемента, соответствующего системе в целом, на которой определяются все внешние сущности, которые должны взаимодействовать с системой и требуемые внешние интерфейсы. Эти внешние интерфейсы должны быть определены до начала этапов 3-7.
- 23. Этап 3 – Определение элементов системы На этом этапе осуществляется определение физических характеристик системного элемента, затем определяются соответствующие производные системные требования, после чего производится его декомпозиция на составные части (на один уровень вниз по иерархии), а также определение предварительных физических характеристик для каждого подчиненного элемента. Первичный “ элемент системы ”, для которого формируются требования в течение текущего цикла проектирования Всегда идите на один уровень ниже в иерархии и определяйте кандидатов в дочерние “ элементы системы”. В течение следующего цикла каждый дочерний элемент становится основным, и этот процесс повторяется
- 24. Структура элемента системы (составные части на один уровень вниз по иерархии) определяется для того, чтобы привязать функции и требования к составным частям. Эта Cradle схема также известна как Диаграмма физической архитектуры (PAD). Этап 3 – Определение элементов системы :2
- 25. Этап 4 – Определение функций и поведения системы На данном этапе определяются системные функции и их входы и выходы, которые удовлетворяют функциональным требованиям для системного элемента, выявленных на предыдущем цикле проектирования. Эти функции, собранные вместе, описывают желаемое поведение, которым должна обладать система. На 5 этапе, функции/интерфейсы должны быть распределены по конкретным элементам системы (т.е. по тем, которые должны выполнять эти функции). Функция 3 Функция 2 AND Данные Функция 4 Функц-ое системное требование Данные Подфункция функции 4 Подфункция функции 4 Функц- ое системное требование удовлетворяет удовлетворяет производные Функц-ое системное требование
- 26. Расширенная блок-схема функций (Functional Flow Block Diagram, eFFBD) описывает желаемое поведение, которым должна обладать система. Эта Cradle схема также известна как Диаграмма поведения. Она используется для определения системных функций, из которых получены функциональные требования. Этап 4 – Определение функций и поведения системы :2
- 27. Следующая таблица трассируемости Cradle показывает функциональные требования, полученные из функционального поведения системы, показанного на схеме eFFBD, представленной на предыдущем слайде. Этап 4 – Определение функций и поведения системы :3
- 28. Этап 5 – Привязка функций и интерфейсов к элементам системы На этом этапе функции и соответствующие входы/выходы (определенные на этапе 4) назначаются различным подсистемам и интерфейсам. 1. Распределение функций присваивает желаемое поведение различным элементам системы. SystemElement SystemElement System INTERFACE Derived Nonfunctional System Requirements Derived FunctionalSystem Requirements Derived InterfaceSystem Requirements allocate satisfy satisfy allocate satisfy Data ANDFunction1 Function2 Function3 Function4 Data satisfy
- 29. Этап 5 – Привязка функций и интерфейсов к элементам системы :2 2. На основе входа-выхода, произведенного и использованного функциями, выделяемыми системным элементам, определяются возможные физические интерфейсы между элементами системы. Производные не функциональные системные требования Производные требования к интерфейсам
- 30. 3. Поскольку у каждой привязанной функции и привязанного интерфейса есть ссылки трассируемости к удовлетворяемым требованиям, эти требования косвенно привязываются элементам системы и интерфейсам. Этап 5 – Привязка функций и интерфейсов к элементам системы :3 Функция 1 Функция 2 Система Элемент системы Элемент системы Удовл. Удовлетв. Данные AND Функция 3 Данные Удовл. Удовл. Производные интерфейсные системные требования Производные не функц-ые системные требования Производные не функц-ые системные требования Привязка Привязка Функция 4 ИНТЕРФЕЙС
- 31. Следующая таблица трассируемости Cradle показывает функциональные и нефункциональные требования, привязанные к элементам системы. (например, элемент оборудования в Cradle). Этап 5 – Привязка функций и интерфейсов к элементам системы :4
- 32. Следующая таблица трассируемости Cradle показывает требования к интерфейсу, привязанные к интерфейсам Определения данных (DD), показанные на схеме физической архитектуры (PAD). Этап 5 – Привязка функций и интерфейсов к элементам системы :5
- 33. Этап 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
- 34. Присвойте время (продолжительность, и дополнительно настраиваемое время начала) к Функциям, и выполните их в динамическом режиме. Для проверки: функции выполняются в упорядоченной последовательности желаемого времени. Модельное время (Дни/Часы: Минуты: Секунды) Выполните анализ временной анализ определенного поведения (например, функциональных моделей)
- 35. Загрузите функциональные модели Cradle в Excel для Анализа Временной шкалы
- 36. Лист настроек Временной шкалы выводит список функций и времени, скачанных с Cradle Эти значения (фиксированное время начала, продолжительность, и фиксированное время окончания) считываются из функции спецификации в базе данных Cradle, связанной с экспортом моделей Маркер декомпозиции считывается из диаграммы группы атрибутов в базе данных Cradle. Он устанавливается на 1 в базе данных, чтобы показать, что декомпозиция функций включена в анализ.
- 37. Результаты моделирования выводятся на “Листе результатов Временной шкалы” Вычисленное время моделирования (функциональный запуск и время окончания) Проверьте функции, выполненные в желаемом порядке с корректным входом-выходом
- 38. Этап 7 – Генерация документации для системы и элементов системы Будь то рецензирование, утверждение, ведение документации, обучение или другие цели; подготовка документации является важной и часто трудоемкой задачей для проекта. Возможность Cradle составлять отчеты и документы Word автоматизированным и специализированным способом, поддерживает все потребности проекта по генерации документов, при этом экономя время и обеспечивая согласованность с форматами и стандартами документации. Reference DocumentReference Document System Performance Requirement Performance Requirement Constraining RequirementConstraining Requirement Cradle ISSUE Verification SBS Trade Study Mission 1 Mission 2 Pre-Launch Launch On-orbit Pre-Launch Launch On-orbit Pre-Launch Launch On-orbit Operation Scenario #3Pre-Launch Launch On-orbit Operational Scenario #1 Pre-Launch Launch On-orbit -Point Camera Take picture Operational Scenario #2 Store picture Mission 1 Mission 2 Pre-Launch Launch On-orbit Pre-Launch Launch On-orbit Pre-Launch Launch On-orbit Operation Scenario #3Pre-Launch Launch On-orbit Operational Scenario #1 Pre-Launch Launch On-orbit -Point Camera Take picture Operational Scenario #2 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 Reference DocumentReference Document System Performance Requirement Performance Requirement Constraining RequirementConstraining Requirement Cradle ISSUE Verification SBS Trade Study Mission 1 Mission 2 Pre-Launch Launch On-orbit Pre-Launch Launch On-orbit Pre-Launch Launch On-orbit Operation Scenario #3Pre-Launch Launch On-orbit Operational Scenario #1 Pre-Launch Launch On-orbit -Point Camera Take picture Operational Scenario #2 Store picture Mission 1 Mission 2 Pre-Launch Launch On-orbit Pre-Launch Launch On-orbit Pre-Launch Launch On-orbit Operation Scenario #3Pre-Launch Launch On-orbit Operational Scenario #1 Pre-Launch Launch On-orbit -Point Camera Take picture Operational Scenario #2 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 Reference DocumentReference Document System Performance Requirement Performance Requirement Constraining RequirementConstraining Requirement Cradle ISSUE Verification SBS Trade Study Mission 1 Mission 2 Pre-Launch Launch On-orbit Pre-Launch Launch On-orbit Pre-Launch Launch On-orbit Operation Scenario #3Pre-Launch Launch On-orbit Operational Scenario #1 Pre-Launch Launch On-orbit -Point Camera Take picture Operational Scenario #2 Store picture Mission 1 Mission 2 Pre-Launch Launch On-orbit Pre-Launch Launch On-orbit Pre-Launch Launch On-orbit Operation Scenario #3Pre-Launch Launch On-orbit Operational Scenario #1 Pre-Launch Launch On-orbit -Point Camera Take picture Operational Scenario #2 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 Reference DocumentReference Document System Performance Requirement Performance Requirement Constraining RequirementConstraining Requirement Cradle ISSUE Verification SBS Trade Study Mission 1 Mission 2 Pre-Launch Launch On-orbit Pre-Launch Launch On-orbit Pre-Launch Launch On-orbit Operation Scenario #3Pre-Launch Launch On-orbit Operational Scenario #1 Pre-Launch Launch On-orbit -Point Camera Take picture Operational Scenario #2 Store picture Mission 1 Mission 2 Pre-Launch Launch On-orbit Pre-Launch Launch On-orbit Pre-Launch Launch On-orbit Operation Scenario #3Pre-Launch Launch On-orbit Operational Scenario #1 Pre-Launch Launch On-orbit -Point Camera Take picture Operational Scenario #2 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 Хранилище данных Cradle
- 39. Этап 8 – Трассируемость системной верификациии валидации (V&V) Зафиксируйте статус каждой задачи по верификации и валидации в базе данных с трассировкой обратно к затрагиваемым требованиям и сценариям работы системы. • Трассируемость верификации. Цель процесса верификации заключается в подтверждении, что системой выполняются указанные проектные требования (например, системные требования). • Трассируемость валидации. Целью данного процесса валидации является предоставление объективных доказательств, что услуги, которые предоставляются системой при использовании в соответствии с требованиями заказчиков, реализуют поставленные цели в соответствующем рабочем окружении.
- 40. SysML– это новый язык моделирования,который может использоваться для поддержкиMBSE Язык моделирования систем (SysML) был разработан Консорциумом по технологии управления объектами (OMG) наряду с другими представителями данной отрасли. Существует девять SysML диаграмм, используемых для описания следующих областей системы: •Структура •Поведение •Требования •Параметрические ограничения •Пакеты Примеры таких диаграмм, представлены на следующих слайдах
- 41. Cradle SysML диаграмма вариантов использования (uc) и сценарии работы Диаграмма вариантов использования отображает набор вариантов использования (цели для подсистемы), а также действующих лиц/заинтересованные стороны, которые задействованы в этих вариантах использования. Чтобы понять вариант использования, мы "рассказываем истории" (т.е., создаем один или несколько сценариев работы для каждого варианта использования). Эти истории описывают, как успешно достигнуть цели/миссии, и как справиться с любыми ошибками/проблемами, которые могут возникнуть на пути. Для создания этих сценариев используется Диаграмма задач (см. следующий слайд).
- 42. Cradle SysML диаграмма вариантов использования (uc) и сценарии работы :2 Диаграмма задач используется для создания сценариев работы,связанных перекрестными ссылками с вариантом использования, который описывает сценарий.
- 43. Cradle SysML диаграмма определения блока (bdd) – Структура системы bdd диаграмма показывает структуру предлагаемой системы (т. е. составных частей). Блоки - основной структурный элемент, используемый для моделирования структуры системы. Блок может быть двух типов: тип 'вещь' (например, система, свет, доклад, организация, человек и т. д.), и тип ‘блок-ресурсы' – т.е. потоковые ‘вещи’, такие как материя, энергия или данные. Обратите внимание, каким образом некоторые из составных частей показывают компоненты нижнего уровня.
- 44. Cradle SysML диаграмма определения внутреннего Блока (ibd) Диаграмма внутреннего блока (ibd) используется для определения как части указанных блоков должны соединяться между собой и как эти части соединяются со внешними сущностями. Как они отображают информацию по интерфейсу.
- 45. Диаграмма задач используется для моделирования поведения ‘вещи' или ‘процесса'. Поведение (представленное на Диаграмма задач) показывает трансформацию входов в выходы посредством регулируемой последовательности действий в хронологическом порядке. Cradle SysML диаграмма задач (act)
- 46. Диаграмма конечных автоматов используется в SysML для описания зависящего от состояния поведения блока в течение всего жизненного цикла, с точки зрения его состояний и переходов между ними. Cradle SysML диаграмма конечных автоматов (stm)
- 47. Схема последовательности (sd) используется для представления взаимодействия элементов структуры (частей) какого-либо блока, в виде последовательности обмена сообщениями. Взаимодействие может быть между системой и ее средой или между компонентами системы на любом уровне системной иерархии. Cradle SysML схема последовательности (sd)
- 48. Модели параметров изображают сеть уравнений, которые ограничивают свойства блоков Свойства системы связаны с параметрами аналитических уравнений (например, масса механизма связана с ‘m’ в уравнении F=m x a), В примере Диаграммы параметров, переменные состояния системы связаны с параметрами уравнений, используемых для анализа системных ограничений. Таким образом модели параметров помогают выявить свойства системы, которые имеют решающее значение для удовлетворения потребностей. Cradle SysML диаграмма параметров (par)
- 49. Cradle SysML диаграмма пакетов (pkg) Диаграмма пакетов разработана для того, чтобы группировать элементы модели, диаграммы и другие пакеты. Поскольку пакет может содержать в себе другой пакет, можно определить иерархию пакетов, чтобы сгруппировать/организовать диаграммы и элементы моделирования.
- 50. Cradle SysML таблица требований Требования отображаются в 'табличной форме', при помощи генератора вложенного табличного представления Cradle.
- 51. Является ли Системное проектирование, основанное на моделях (MBSE) чем-то новым? Нет. MBSE методы и приемы самостоятельно практикуют многие хорошие инженеры и аналитики на протяжении многих лет. Процесс MBSE, представленный в этой презентации, описывает Общее представление о соединении информации в единое целое. Основная проблема заключается в том, что управление проектом направлено на ‘отчетные документы’ вместо создания проектной модели данных, которая может использоваться для поддержания анализа, сквозной трассируемости, и автоматической генерации отчетных документов из модели данных. • Проектная модель данных обычно состоит из сущностей, атрибутов, отношений и диаграмм, которые определяют архитектуру системы. • Помните, что диаграмма (графическая модель) передает информацию лучше тысячи слов. Эти схемы помогают связывать идеи/концепции между персоналом проекта и клиентом. • Новым же является язык моделирования SysML. Он должен помочь с решением вопросов коммуникации, путем стандартного способа описания архитектуры систем. Если у вас есть вопросы по MBSE процессам, свяжитесь со мной по электронной почте loyd.baker@threesl.com Заключение