В рабочем процессе, где код генерируется из Simulink® и Stateflow® модели, модели рассматриваются как низкоуровневые требования к программному обеспечению и архитектуре, как определено в DO-178C. Фактическими низкоуровневыми требованиями являются скомпилированная модель в памяти, интерпретированная движком Simulink на основе входов из файла модели, а также любых файлов данных, таких как MATLAB® или MAT-файлы, которые загружают данные в Рабочие пространства MATLAB или рабочие пространства модели. См. фигуру 3. Сам файл модели не представляет низкоуровневые требования, потому что семантика модели не полностью включена в этот файл. Семантика модели не завершена, пока файл модели не загружен в память, и механизм Simulink не скомпилировал модель. Некоторые семантики модели, которые определяются во время компиляции, но не включены в файл модели, для модели состоят из:
Распространенные шаги расчета
Распространенные типы данных
Переданные сигнальные Размерности
Распространенные типы сигналов
Блок Порядка выполнения
Описание Разработки системы, которое создается с помощью Simulink Report Generator™, предоставляет документ, который детализирует скомпилированное для симуляции в представлении памяти модели. Это обеспечивает документацию низкоуровневых требований к программному обеспечению, как определено в DO-178C глоссарии [1]:
Низкоуровневые требования - Требования к программному обеспечению, разработанные на основе требований высокого уровня, производных требований и проекта ограничений, из которых исходный код может быть непосредственно реализован без дополнительной информации.
Компиляция для симуляции и компиляция для генерации кода являются двумя различными компиляциями и приводят к двум слегка разным представлениям в памяти. Simulink Test™, Покрытие модели, Simulink Code Inspector™, Model Advisor и Генератор отчетов только компилируются для симуляции. Embedded Coder® и Покрытие Кода компилируются для генерации кода, которая включает в себя всю компиляцию для информации о симуляции плюс следующую дополнительную информацию.
Оптимизации модели, которые применяются только для генерации кода
Проверка непротиворечивости классов памяти в сгенерированном коде
Поскольку операции верификации модели и кода могут происходить в разное время или на разных компьютерах, необходимо проверить согласованность представлений модели в памяти. Для проверки MD5 согласованности используется расчет контрольной суммы. Контрольная сумма MD5 вычисляется на основе представления в памяти и включает данные, которые были загружены в рабочую область из внешних файлов, используемых моделью. Настраиваемые параметры не включены в MD5 контрольную сумму. Значение MD5 Checksum автоматически вставляется в отчет Model Advisor, Описание разработки системы и отчет Simulink Code Inspector. Также можно использовать Simulink API для доступа к MD5 Checksum и вставки его в отчет Simulink Test или для использования в других отчетах, которые могут быть сгенерированы во время симуляций с помощью других методов, таких как Генератор отчетов или скриптов MATLAB. Номер версии модели и последняя сохраненная дата также доступны в отчетах, и эти данные автоматически обновляются каждый раз, когда модель сохранена. На номер версии модели и последние сохраненные даты внешне не влияют данные, поэтому MD5 Checksum требуется для проверки полной непротиворечивости представления в памяти. Описание Разработки системы задокументирует переменные рабочей области, которые используются моделью во время создания отчета.
Примечание
Модель checksum расчета зависит от платформы.
Фигура 1: Разработка и верификация модели и исходного кода
