В первых двух частях туториала мы рассматривали построение архитектуры системы и проектирование на системном уровне и заодно посмотрели на System Composer. Сама по себе архитектура системы — это отлично, но надо сделать так чтобы она была связана с разработанной системой. Отсутствие такой связи в традиционных инструментах использующих SysML или UML, кстати, и послужила причиной создания System Composer. Дело в том, что многие компании уже используют для разработки парадигму Модельно-ориентированного проектирования (МОП), и им приходилось использовать сторонние инструменты для системной инженерии, что было неудобно. System Composer был создан чтобы устранить этот разрыв. В этой заключительной части туториала я покажу как использовать System Composer совместно с тулчейном MathWorks для Модельно-ориентированного проектирования.

Привязка архитектуры к требованиям

Для начала определим, что такое требования. Требования — это то, что должна делать система. Их отличия от технического задания заключаются в том, что требования — это описание функционирования системы. В 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 для тщательного анализа проектных решений позволяет получить понимание природы компонентов и обнаружить потенциальные бутылочные горлышке в системе, которые иначе обнаружились бы на поздних стадиях разработки. Для анализа могут применяться различные методы — от анализа потока данных, до численной аналитики.

И, как видите, проектировать на системном уровне — это совсем не страшно, и инструменты, поддерживающие системное проектирование, помогают вам в этом.

Хотите узнать больше? Мы проводили вводный вебинар по системной инженерии, и в рамках этого вебинара я как раз и показывал этот туториал. А мой коллега Михаил Песельник рассказывал зачем системная инженерия нужна вообще. Сам вебинар находится вот тут.