В рабочем процессе, где код сгенерирован от 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 автоматически вставляется в отчет Model Advisor, Описание Разработки системы и отчет Simulink Code Inspector. Также возможно использовать Simulink API, чтобы получить доступ к Контрольной сумме MD5 и вставить его в отчет Simulink Test или для использования в других отчетах, которые могут быть сгенерированы во время симуляций с помощью других методов, таких как Генератор отчетов или скрипты MATLAB. Номер версии модели и в последний раз сохраненная дата также доступна в отчетах, и эти данные автоматически обновляются каждый раз, когда модель сохранена. Номер версии модели и в последний раз сохраненные даты не затронуты внешне загруженными данными, так, чтобы был то, почему Контрольная сумма MD5 требуется, чтобы проверять полную непротиворечивость представления в оперативной памяти. Описание Разработки системы действительно документирует переменные рабочей области, которые используются моделью в то время, когда отчет сгенерирован.
Расчет контрольной суммы модели является зависимым платформы.
Рисунок 1: типовой кодекс и разработка исходного кода и верификация
