В первых двух частях туториала мы рассматривали построение архитектуры системы и проектирование на системном уровне и заодно посмотрели на System Composer. Сама по себе архитектура системы — это отлично, но надо сделать так, чтобы она была связана с разработанной системой. Отсутствие такой связи в традиционных инструментах использующих SysML или UML, кстати, и послужила причиной создания System Composer. Дело в том, что многие компании уже используют для разработки парадигму модельно-ориентированного проектирования (МОП), и им приходилось использовать сторонние инструменты для системной инженерии, что было неудобно. System Composer был создан, чтобы устранить этот разрыв. В этой заключительной части туториала я покажу, как использовать System Composer совместно с тулчейном MathWorks для модельно-ориентированного проектирования.
Для начала определим, что такое требования. Требования – это то, что должна делать система. Их отличие от технического задания заключается в том, что требования — это описание функционирования системы. В MATLAB/Simulink есть инструмент управления требованиями Simulink Requirements. Он позволяет как импортировать требования из внешних систем, таких как IBM DOORS, так и писать их в собственном редакторе Requirements Editor. Сами требования хранятся в специальных файлах с расширением *.slreqx. Создадим требования и сохраним их в файле AccessControl.slreqx. Сами требования мы сформулируем из рассуждений из первой части:
Эти требования были созданы в Requirements Editor, инструменте создания требований, входящем в Simulink Requirements и сохранены в файл. Если открыть этот файл в самой модели с помощью Requirements Perspective, то мы увидим следующее:
Для того чтобы привязать требование к элементу архитектуры, достаточно перенести требование на желаемый элемент архитектуры с помощью мыши.
А что делать, если требования поменялись, как это часто бывает на ранних стадиях проектирования? Как проанализировать их влияние на нашу архитектуру? К счастью, Simulink Requirements позволяет отслеживать изменения требований и помечает те элементы архитектуры, которые были затронуты данными изменениями:
Чтобы проанализировать покрытие архитектуры требованиями, на вкладке Requirements надо выбрать Share, а затем Generate Traceability Matrix. Будет создана матрица трассируемости, которая графически отображает связи требований и элементов. Эта матрица представляет собой таблицу, столбцами которой являются элементы архитектуры или модели, строками — сами требования, а ячейки содержат графические пометки о связи между требованиями и элементами.
А если нажать на кнопку Highlight Missing Links, то непокрытые элементы в матрице будут подсвечены желтым:
Анализ полноты покрытия требованиями и их прослеживаемости – это очень важный процесс, если вы создаете систему, критическую к безопасности, неважно, для самолета, автомобиля или ядерного реактора. Для таких систем не должно быть непокрытых требованиями элементов! Если вам интересно, как разрабатываются эти системы и как они разрабатываются в парадигме МОП — пишите в комментариях, так как тема очень обширная и долгая и выходит за рамки туториала.
Так как System Composer — это часть тулчейна MathWorks, то мы можем анализировать свойства архитектуры, делать отчеты и прочее. Проведение анализа архитектуры позволяет подсчитать количество рабочих часов, необходимых для реализации системы, минимальные массогабаритные показатели, TDP и так далее. А если проводить анализ систематически, а не разово, то мы сможем видеть динамику развития нашей системы, а также находить проблемные места.
Допустим, для нашего СКУД мы хотим подсчитать количество рабочих часов. У всех компонентов есть общее свойство Workload, и, очевидно, нам надо просуммировать значения этих свойств. Для этого давайте создадим инстанс архитектуры для анализа, нажав на Analysis Model, а затем выберем для анализа GenericComponent:
Затем нажмем кнопку Instantiate и получим такой результат:
Здесь мы можем назначить значения свойства Workload каждому элементу и нажать кнопку Update, чтобы обновить эти значения в самой архитектуре. А можем и не нажимать, ведь инстанс существует отдельно от архитектуры, и мы можем поиграться с значениями свойств, чтобы найти компромиссы проекта или найти оптимальные значения свойств. Сам анализ выполняется отдельной функцией, созданной на языке MATLAB. Вот, например код для нашей «аналитической» функции:
После того как функция была создана, надо кликнуть на Analyze и выбрать ее в меню Select Function. Теперь при нажатии кнопки Analyze будет происходить суммирование значения свойства Workload:
Это был крайне простой пример анализа архитектуры и в реальных, боевых задачах для анализа применяется весь спектр аналитических возможностей MATLAB, таких как подгонка кривых, регрессионный анализ и т.д.
Главное тут – это то, что мы можем и должны проводить систематический анализ нашей архитектуры, чтобы развивать проект.
И, наконец, System Composer – это не отдельный инструмент, который существует отдельно от Simulink. После определения архитектуры каждый ее компонент может быть привязан к модели Simulink, при этом можно выбрать как существующую модель, так и создать модель автоматически! Это позволяет запускать симуляции и исследовать поведенческие характеристики системы прямо в System Composer.
Самое главное, что если модель создается из компонента, в модели автоматически генерируются входные и выходные порт с нужными интерфейсами. Это очень важная мелочь, так как интеграция компонентов как правило тормозит из-за несогласованности интерфейсов компонентов, а готовые интерфейсы снимают данную проблему. Каждую сгенерированную модель можно отдать конкретному исполнителю и быть спокойным, что потом она встроится в архитектуру.
На протяжении трех статей я показывал основные приемы проектирования на системном уровне. Самое время подвести итоги.
Проектирование на системном уровне требует достаточно подробного анализа задачи и требует интуитивно понятных инструментов. System Composer является простым в освоении инструментом и использует все преимущества методологии модельно-ориентированного проектирования для создания и анализа архитектур систем, а также аналитические возможности MATLAB.
Применение System Composer для тщательного анализа проектных решений позволяет получить понимание природы компонентов и обнаружить потенциальные бутылочные горлышки в системе, которые иначе обнаружились бы на поздних стадиях разработки. Для анализа могут применяться различные методы — от анализа потока данных, до численной аналитики.
И, как видите, проектировать на системном уровне — это совсем не страшно, и инструменты, поддерживающие системное проектирование, помогают вам в этом.
Хотите узнать больше? Мы проводили вводный вебинар по системной инженерии, и в рамках этого вебинара я как раз и показывал этот туториал. А мой коллега Михаил Песельник рассказывал зачем системная инженерия нужна вообще. Сам вебинар находится вот тут.
Привязка архитектуры к требованиям
Для начала определим, что такое требования. Требования – это то, что должна делать система. Их отличие от технического задания заключается в том, что требования — это описание функционирования системы. В MATLAB/Simulink есть инструмент управления требованиями Simulink Requirements. Он позволяет как импортировать требования из внешних систем, таких как IBM DOORS, так и писать их в собственном редакторе Requirements Editor. Сами требования хранятся в специальных файлах с расширением *.slreqx. Создадим требования и сохраним их в файле AccessControl.slreqx. Сами требования мы сформулируем из рассуждений из первой части:
- Должно быть обеспечено чтение RFID-метки
- Данные извлеченные из RFID-метки должны быть переданы во внешнюю базу данных
- На основе ответа базы данных вырабатывается запрет или разрешение доступа
- Пользователь должен быть извещен о статусе доступа
- Замок разблокируется на основе статуса доступа
Эти требования были созданы в Requirements Editor, инструменте создания требований, входящем в Simulink Requirements и сохранены в файл. Если открыть этот файл в самой модели с помощью Requirements Perspective, то мы увидим следующее:
Для того чтобы привязать требование к элементу архитектуры, достаточно перенести требование на желаемый элемент архитектуры с помощью мыши.
А что делать, если требования поменялись, как это часто бывает на ранних стадиях проектирования? Как проанализировать их влияние на нашу архитектуру? К счастью, Simulink Requirements позволяет отслеживать изменения требований и помечает те элементы архитектуры, которые были затронуты данными изменениями:
Чтобы проанализировать покрытие архитектуры требованиями, на вкладке Requirements надо выбрать Share, а затем Generate Traceability Matrix. Будет создана матрица трассируемости, которая графически отображает связи требований и элементов. Эта матрица представляет собой таблицу, столбцами которой являются элементы архитектуры или модели, строками — сами требования, а ячейки содержат графические пометки о связи между требованиями и элементами.
А если нажать на кнопку Highlight Missing Links, то непокрытые элементы в матрице будут подсвечены желтым:
Анализ полноты покрытия требованиями и их прослеживаемости – это очень важный процесс, если вы создаете систему, критическую к безопасности, неважно, для самолета, автомобиля или ядерного реактора. Для таких систем не должно быть непокрытых требованиями элементов! Если вам интересно, как разрабатываются эти системы и как они разрабатываются в парадигме МОП — пишите в комментариях, так как тема очень обширная и долгая и выходит за рамки туториала.
Аналитика архитектуры в MATLAB
Так как System Composer — это часть тулчейна MathWorks, то мы можем анализировать свойства архитектуры, делать отчеты и прочее. Проведение анализа архитектуры позволяет подсчитать количество рабочих часов, необходимых для реализации системы, минимальные массогабаритные показатели, TDP и так далее. А если проводить анализ систематически, а не разово, то мы сможем видеть динамику развития нашей системы, а также находить проблемные места.
Допустим, для нашего СКУД мы хотим подсчитать количество рабочих часов. У всех компонентов есть общее свойство Workload, и, очевидно, нам надо просуммировать значения этих свойств. Для этого давайте создадим инстанс архитектуры для анализа, нажав на Analysis Model, а затем выберем для анализа GenericComponent:
Затем нажмем кнопку Instantiate и получим такой результат:
Здесь мы можем назначить значения свойства Workload каждому элементу и нажать кнопку Update, чтобы обновить эти значения в самой архитектуре. А можем и не нажимать, ведь инстанс существует отдельно от архитектуры, и мы можем поиграться с значениями свойств, чтобы найти компромиссы проекта или найти оптимальные значения свойств. Сам анализ выполняется отдельной функцией, созданной на языке MATLAB. Вот, например код для нашей «аналитической» функции:
function AccessControl_simple_analytics(instance,varargin)
if instance.isComponent()
workload = 0;
for child=instance.Components
child_workload = child.getValue("GenericComponent.Workload");
workload = workload + child_workload;
end
instance.setValue("GenericComponent.Workload",workload);
end
end
После того как функция была создана, надо кликнуть на Analyze и выбрать ее в меню Select Function. Теперь при нажатии кнопки Analyze будет происходить суммирование значения свойства Workload:
Это был крайне простой пример анализа архитектуры и в реальных, боевых задачах для анализа применяется весь спектр аналитических возможностей MATLAB, таких как подгонка кривых, регрессионный анализ и т.д.
Главное тут – это то, что мы можем и должны проводить систематический анализ нашей архитектуры, чтобы развивать проект.
Связь компонентов и их реализации
И, наконец, System Composer – это не отдельный инструмент, который существует отдельно от Simulink. После определения архитектуры каждый ее компонент может быть привязан к модели Simulink, при этом можно выбрать как существующую модель, так и создать модель автоматически! Это позволяет запускать симуляции и исследовать поведенческие характеристики системы прямо в System Composer.
Самое главное, что если модель создается из компонента, в модели автоматически генерируются входные и выходные порт с нужными интерфейсами. Это очень важная мелочь, так как интеграция компонентов как правило тормозит из-за несогласованности интерфейсов компонентов, а готовые интерфейсы снимают данную проблему. Каждую сгенерированную модель можно отдать конкретному исполнителю и быть спокойным, что потом она встроится в архитектуру.
Выводы
На протяжении трех статей я показывал основные приемы проектирования на системном уровне. Самое время подвести итоги.
Проектирование на системном уровне требует достаточно подробного анализа задачи и требует интуитивно понятных инструментов. System Composer является простым в освоении инструментом и использует все преимущества методологии модельно-ориентированного проектирования для создания и анализа архитектур систем, а также аналитические возможности MATLAB.
Применение System Composer для тщательного анализа проектных решений позволяет получить понимание природы компонентов и обнаружить потенциальные бутылочные горлышки в системе, которые иначе обнаружились бы на поздних стадиях разработки. Для анализа могут применяться различные методы — от анализа потока данных, до численной аналитики.
И, как видите, проектировать на системном уровне — это совсем не страшно, и инструменты, поддерживающие системное проектирование, помогают вам в этом.
Хотите узнать больше? Мы проводили вводный вебинар по системной инженерии, и в рамках этого вебинара я как раз и показывал этот туториал. А мой коллега Михаил Песельник рассказывал зачем системная инженерия нужна вообще. Сам вебинар находится вот тут.