Функциональное моделирование в разработке встраиваемых систем: стратегии и инструменты

Функциональное моделирование в разработке встраиваемых систем: стратегии и инструменты

Встроенные системы являются бесшумными рабочими лошадками современной технологии. От антиблокировочной тормозной системы в вашем автомобиле до инсулиновой помпы, управляющей глюкозой крови диабетического пациента, эти специализированные вычислительные устройства выполняют специализированные функции в более крупных системах. Разработка таких систем является дорогостоящим делом: одна ошибка в автомобильном прошивочном устройстве может привести к дорогостоящим отзывам, а логическая ошибка в кардиостимуляторе может быть опасной для жизни. Для создания надежных, эффективных и поддерживающих встроенных систем инженерам нужен дисциплинированный подход к проектированию. Функциональное моделирование является краеугольным камнем этой дисциплины. Создавая абстрактные представления о поведении системы перед выполнением аппаратных или программных средств, команды могут проверять требования, улавливать недостатки проектирования на ранней стадии и выравнивать межфункциональные заинтересованные стороны. Эта статья предоставляет всеобъемлющее практическое руководство по функциональному моделированию во встроенных системах - охватывая основные концепции, проверенные стратегии, основные инструменты, реальные преимущества и лучшие практики для интеграции моделирования в рабочий процесс разработки.

Что такое функциональное моделирование?

Функциональное моделирование - это практика описания того, что делает система, не предписывая , как она это делает. , она фокусируется на захвате предполагаемого поведения системы, потоков данных, переходов состояний и взаимодействий с внешними объектами. Этот уровень абстракции позволяет инженерам рассуждать о правильности, полноте и согласованности требований, прежде чем погружаться в аппаратные схемы или исходный код.

В встраиваемых системах функциональные модели обычно принимают одну из нескольких форм:

Важно отметить, что функциональное моделирование отличается от физического моделирования. Физическое моделирование захватывает нефункциональные аспекты, такие как время, потребление энергии, использование памяти и аппаратных интерфейсов. Хотя оба они ценны, функциональное моделирование отвечает на вопрос: «Делает ли наш системный дизайн правильные вещи?» Физическое моделирование отвечает: «Может ли он сделать это в рамках реальных ограничений?» Хорошо продуманный процесс встроенной разработки использует оба, но функциональное моделирование часто является первым шагом, потому что мало стоит изменить диаграмму по сравнению с повторным вращением печатной платы или переписыванием тысяч строк кода C.

Стратегии эффективного функционального моделирования

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

Начнем с требований

Каждая функциональная модель должна следовать четко определенному требованию. Перед тем, как нарисовать одну коробку или стрелку, соберите и расставьте приоритеты функциональных требований (что должна делать система) и нефункциональных требований (производительность, безопасность, безопасность). Используйте инструмент управления требованиями (например, IBM DOORS, Jama или даже структурированную электронную таблицу) для поддержания прослеживаемости. Например, если требование гласит: «Система должна обнаруживать состояние дверного угла в пределах 100 мс», ваша функциональная модель должна включать состояние, в котором дверь открыта, переход, вызванный датчиком двери, и механизм таймера или события для обеспечения соблюдения предела в 100 мс. Без этой связи модель рискует быть неполной.

Иерархическая декомпозиция

Сложные системы легче понять, когда они разбиты на управляемые части. Функциональное разложение включает разделение функции верхнего уровня (например, «Управление блоком управления двигателем») на подфункции («Читать данные датчика», «Вычислить время впрыска топлива», «Отправить команды приведения в действие»). Каждая подфункция может быть дополнительно разложена до уровня, где поведение достаточно просто для моделирования в одной машине состояния или диаграмме активности. Этот иерархический подход также поддерживает модульную разработку: различные команды могут работать над отдельными моделями низкого уровня и интегрировать их позже с использованием четко определенных интерфейсов.

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

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

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

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

Итерировать и усовершенствовать

Функциональное моделирование не является одноразовым действием. Ранние модели представляют собой грубые приближения, которые будут уточнены по мере углубления понимания. Используйте легкие циклы обзора - еженедельные пройденные модели с командой разработчиков, экспертами по доменам и инженерами-испытателями. Во время этих обзоров ищите несоответствия, недостающие состояния, неполные переходы и логику, которая не соответствует требованиям. Уточните модель, обновите матрицу прослеживаемости и повторно проверьте первоначальные требования.

Распространенной проблемой является чрезмерное моделирование: попытка захватить каждый возможный крайний случай на первом проходе. Вместо этого начните с «счастливого пути» (нормальный режим работы), а затем постепенно добавьте обработку ошибок, условия неисправности и альтернативные потоки. Этот итеративный подход поддерживает управляемость модели и гарантирует, что критическое поведение проверяется на ранней стадии.

Сохраняйте прослеживаемость

Функциональная модель полезна только в том случае, если вы можете доказать, что она удовлетворяет всем требованиям. Установить цепочку прослеживаемости от каждого требования к одному или нескольким элементам модели (например, состояние, переход, деятельность). Многие инструменты моделирования (например, Enterprise Architect, IBM Rational Rhapsody) поддерживают автоматические ссылки прослеживаемости. Кроме того, элементы модели ссылок для тестовых случаев. При изменении требования вы можете сразу определить, какие части модели (и какие наборы тестов) нуждаются в обновлении. Без прослеживаемости легко вводить пробелы или несоответствия по мере развития системы.

Инструменты для функционального моделирования

Выбор правильного инструмента зависит от размера команды, домена, бюджета и потребностей интеграции. Ниже приведены наиболее широко используемые среды функционального моделирования при разработке встроенных систем. Каждый инструмент превосходит в определенной области, и многие из них могут быть объединены в цепочке инструментов.

Simulink (MathWorks)

Simulink является фактическим стандартом для проектирования на основе моделей в автомобильной, аэрокосмической и промышленной автоматизации. Он обеспечивает графическую среду блок-диаграммы, в которой вы моделируете системы непрерывного и дискретного времени, включая алгоритмы управления, обработку сигналов и машины состояния (через Stateflow). Модели Simulink являются исполняемыми: вы можете имитировать поведение, генерировать код (встроенный код) и проверять на соответствие требованиям. Его обширная библиотека блоков для конкретной области (например, для связи CAN, управления двигателем) делает его идеальным для встроенного программного обеспечения производственного класса. Однако Simulink лучше всего подходит для систем, которые могут быть выражены как блок-схемы; это менее естественно для моделирования чисто программного обеспечения-архитектуры.

Enterprise Architect (Спаркс Системс)

Enterprise Architect - это универсальная платформа моделирования, которая поддерживает UML, SysML, BPMN и многие другие обозначения. Она превосходит в управлении требованиями, отслеживаемости моделей и совместной работе (репозитории, контролируемые версией, безопасность на основе ролей). Для встроенных систем вы можете моделировать как функциональные, так и структурные представления, требования к ссылкам на государственные машины и генерировать документацию. Его интерфейс сценариев позволяет интегрироваться с другими инструментами (например, JIRA, DOORS). Enterprise Architect особенно силен для крупномасштабных систем, где отслеживаемость и согласованность между командами имеют решающее значение. Стоимость умеренная по сравнению с инструментами IBM.

IBM Rational Rhapsody

Rhapsody - это среда разработки, ориентированная на модели, предназначенная для встроенных систем и систем реального времени. Она поддерживает SysML и UML и обеспечивает автоматическое генерирование кода (C, C++, Java и Ada). Сила Rhapsody заключается в ее способности проверять модели с помощью моделирования и исполнения и генерировать готовый к производству код, который соответствует ограничениям реального времени. Она интегрируется с собственными инструментами управления требованиями IBM (DOORS) и управления изменениями. Rhapsody обычно используется в критически важных для безопасности приложениях (автомобильный ISO 26262, авионика DO-178C), поскольку она поддерживает формальную проверку и прослеживаемость на уровне модели.

Modelica (OpenModelica, Димола)

Modelica - это язык с открытым исходным кодом, основанный на уравнениях для моделирования сложных физических систем - например, тепловой динамики, электрических цепей, гидравлических систем и механики нескольких тел. В отличие от парадигмы блок-диаграммы Simulink, Modelica использует акаузальное моделирование: вы соединяете компоненты по их физическим портам (например, поток тепла, напряжение) и инструмент решает полученные уравнения. Это делает Modelica идеальной для систем, где тесно связанные физические явления взаимодействуют с логикой управления. Функциональные модели в Modelica часто используются на ранних этапах проектирования для моделирования поведения на системном уровне до существования аппаратных прототипов. Основная коммерческая реализация - Dymola (Dassault Systèmes), в то время как OpenModelica является бесплатной альтернативой.

MagicDraw (Системы Дассо)

MagicDraw (теперь часть Cameo Systems Modeler) - это платформа моделирования с глубокой поддержкой SysML и UML. Она часто используется для системной инженерии в аэрокосмической, оборонной и автомобильной промышленности. Сила MagicDraw - это его способность управлять сложными отношениями между функциональными, структурными и параметрическими моделями в одном хранилище. Она интегрируется с инструментами моделирования (например, Simulink, Modelica) через интерфейсы ко-симуляции. Для функционального моделирования вы можете создавать диаграммы активности, диаграммы последовательностей и диаграммы машин состояния, которые подаются в исполняемые спецификации. MagicDraw также поддерживает импорт требований из инструментов, соответствующих ReqIF, что позволяет легко отслеживать требования к элементам модели.

Другие известные инструменты

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

Принятие функционального моделирования дает измеримые улучшения в качестве, стоимости и времени выхода на рынок. Ниже приведены ключевые преимущества, иллюстрируемые конкретными результатами.

Раннее выявление недостатков дизайна

Моделируя поведение системы до того, как будет построено какое-либо оборудование или написан код, инженеры могут моделировать и анализировать логику. Например, инженер-автомобиль может запустить модель системы управления аккумулятором Simulink, чтобы увидеть, как она реагирует на условия перетока. Если государственная машина вступает в неожиданный тупик или не переходит в безопасное состояние, дефект фиксируется на уровне модели - фиксация диаграммы или параметра занимает минуты, тогда как исправление прошивки на физическом ECU потребует полного цикла регрессионного тестирования. Данные отрасли показывают, что найти дефект на этапе моделирования может быть в 100 раз дешевле, чем найти его после выпуска продукции.

Улучшение коммуникации между междисциплинарными командами

Встроенные системы включают инженеров-аппаратистов, инженеров-программистов, инженеров-контроллеров, системных архитекторов и экспертов в области (например, специалиста по торможению). Функциональные модели служат единственным источником истины, который может понять каждый - нет необходимости читать 200 страниц текста требований. Диаграмма определения блока SysML, показывающая функции высокого уровня медицинского инфузионного насоса, сразу же понятна как клиническому эксперту, так и разработчику FPGA. Это общее понимание уменьшает неверные интерпретации и предотвращает ошибки проектирования на основе силоса.

Экономия времени и затрат

Функциональное моделирование уменьшает переделку. При изменении требований (и они всегда меняются), обновление модели и регенерация кода или тестовых случаев происходит гораздо быстрее, чем ручное редактирование нескольких артефактов реализации. В одном тематическом исследовании от автомобильной промышленности поставщик уровня 1 сократил исправления ошибок программного обеспечения на 60% после принятия дизайна на основе модели с Simulink и Stateflow. Первоначальные инвестиции в моделирование окупаются за счет сокращения этапов интеграции и тестирования, особенно в сложных критически важных для безопасности проектах.

Лучшая документация для обслуживания и соблюдения

Функциональные модели выпускают спецификации самодокументации. Ссылки отслеживания показывают, какие карты требований к какому состоянию или переходу. Эта документация бесценна для последующего обслуживания - новые инженеры могут понять логику системы, считывая государственную машину вместо того, чтобы прочесывать исходный код. Для регулируемых отраслей (медицинский ISO 13485, автомобильный ISO 26262, авионика DO-178C) документация на основе моделей часто требуется для сертификации. Такие инструменты, как SCADE и Rhapsody, генерируют готовые к соблюдению артефакты непосредственно из модели.

Улучшенная надежность системы

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

Лучшие практики интеграции функционального моделирования в развитие

Чтобы получить максимальную отдачу от функционального моделирования, рассматривайте его как неотъемлемую часть процесса разработки, а не как дополнительное дополнение. Вот лучшие практики, полученные в результате успешных внедрений в различных отраслях.

Модель перед кодом

Предоставьте, чтобы каждая новая функция или запрос на изменение сначала были учтены в качестве функциональной модели и рассмотрены командой. Это создает культуру «модель-первая», в которой дизайнерские решения проверяются до дорогостоящей интеграции.

Автоматизация генерации кода, где это возможно

Ручное кодирование из моделей вводит ошибки перевода и побеждает цель абстракции. Если ваша цепочка инструментов поддерживает его, генерируйте производственный код (C, C++ и т. Д.) из проверенной модели. Но имейте в виду: генерируемый код должен быть все еще проверен и проверен, и вы должны убедиться, что генератор кода соответствует вашему уровню безопасности (например, сертификация TUV SUD для встроенного кодера).

Используйте контроль версий для моделей

Модели развиваются так же, как и код. Храните их в репозитории, контролируемой версией (Git, SVN) и используйте стратегии ветвления для управления параллельной разработкой. Большинство инструментов моделирования имеют встроенную поддержку сравнения и слияния моделей. Относитесь к изменениям модели с той же строгостью, что и к изменениям кода - требуйте экспертных обзоров для всех модификаций.

Интегрированное моделирование с тестированием

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

Проблемы и как их преодолеть

Для преодоления этого, начните с пилотного проекта — выберите небольшую, хорошо понятую подсистему, продемонстрируйте экономию времени от раннего обнаружения дефектов и позвольте результатам говорить сами за себя. Еще одна проблема — моделирование сложного поведения в реальном времени (наведение времени, планирование, обработка прерываний). В таких случаях сочетайте функциональные модели с физическими моделями или используйте инструменты, которые поддерживают моделирование в реальном времени (например, Simulink Real-Time). Наконец, убедитесь, что все заинтересованные стороны (включая менеджеров) покупают модельный подход; они должны понимать, что первоначальное моделирование усилия является инвестицией, которая окупается во время интеграции и обслуживания.

Заключение

Функциональное моделирование больше не является роскошью в разработке встроенных систем - это необходимость в предоставлении безопасных, надежных и экономически эффективных продуктов. Начиная с четких требований, используя иерархическое разложение, принимая стандартизированные языки, такие как SysML, и используя мощные инструменты, такие как Simulink, Enterprise Architect или Rhapsody, инженерные команды могут рано улавливать дефекты, улучшать сотрудничество и ускорять время выхода на рынок. Преимущества - раннее обнаружение дефектов, экономия затрат, лучшая документация и повышенная надежность - хорошо документированы в секторах от автомобильных до медицинских устройств. Чтобы добиться успеха, рассматривайте моделирование как неотъемлемую часть вашего рабочего процесса, автоматизируйте генерацию кода и тестирование и культивируйте культуру, где встроенные системы становятся все более сложными, команды, которые осваивают функциональное моделирование, будут теми, кто остается впереди кривой.

Для дальнейшего чтения изучите спецификацию SysML от OMG , страницу продукта Simulink и практическое руководство по встроенной разработке на основе модели от IBM .