Создание проекта DO-178C/DO-331

Проект DO-178C - это шаблон для управления процессом разработки программного обеспечения для DO-178C/DO-331 с помощью инструментов MathWorks ®. Для использования структуры этого проекта при запуске новой программы можно создать проект на основе этого шаблона .

Чтобы создать DO-178 проект с помощью шаблона проекта, выполните следующие действия.

На главном экране MATLAB щелкните Simulink, чтобы открыть начальную страницу Simulink ®.
На вкладке «Создать» разверните опцию «Набор квалификаций DO», наведите курсор на изображение DO-178C Project и выберите «Создать проект».
В диалоговом окне «Создание проекта» введите DO178C_demo в качестве имени проекта и выберите расположение файла, в котором требуется сохранить проект. Нажмите кнопку ОК.

Simulink генерирует и открывает новый проект. Проект предварительно заполнен:

Ярлыки проекта
Шаблоны документов планирования
Рекомендуемые стандарты моделирования и кодирования
Создание ограничений в виде библиотек, шаблонов моделей, конфигураций моделей и проверок
Оснащение для автоматизации жизненно важных задач разработки и проверки
Jenkins™ структура, которая использует непрерывную интеграцию для полной автоматизации выполнения операций проверки программного обеспечения.

Теперь в проект можно добавить содержимое:

Дополнительные сведения об использовании проектов см. в разделе Управление проектами (Simulink).

Изучение быстрых ссылок на проекты

Ярлыки проекта в обеспечивают простой способ выполнения общих задач в проекте. В DO-178C шаблоне проекта встроенные ярлыки включают:

Добавить новую модель (Add New Model) - создание модели, которая автоматически добавляется в DO_03_Design папка проекта. Дополнительные сведения см. в разделе Добавление конструкторской модели в DO-178 проект.
Задать конфигурацию помощника по модели по умолчанию - указывает do178Checks.json в качестве файла конфигурации по умолчанию Model Advisor. Этот файл конфигурации поставляется с DO-178C шаблоном проекта. Дополнительные сведения см. в разделе Использование редактора конфигурации Model Advisor для создания пользовательской конфигурации Model Advisor (Simulink Check).
Восстановить конфигурацию помощника по модели по умолчанию - очистить параметр, который обозначает do178Checks.json в качестве конфигурации по умолчанию Model Advisor. Model Advisor восстанавливает конфигурацию Model Advisor, используя стандартную конфигурацию, определенную системным администратором.

Обзор папок проекта

В DO-178C папках проекта содержатся данные, используемые в рабочем процессе конструирования на основе модели. Используйте следующую таблицу, чтобы лучше понять предварительно заполненное содержимое в:

Новый пустой проект, созданный с помощью шаблона проекта
Пример управления полетом вертолета: пример конструкции на основе модели для DO-178C и DO-331 после выполнения примера runDemo.mlx live script и задание непрерывной интеграции Дженкинса.

Примечание

Папки проекта в примере заполняются данными, моделями и т.д., которые используются для проектирования системы управления полетом вертолета. В то время как иерархия папок и высокоуровневое концептуальное содержимое совпадают с содержимым шаблона проекта, эти папки заполняются дополнительными данными.

Папка > Имя подпапки	Папки в шаблоне проекта	Папки после выполнения примера или задания по построению Jenkins CI
`continuous_integeration`	Артефакты непрерывной интеграции Дженкинса
> `help`	Инструкции по использованию непрерывной интеграции Дженкинса в проекте DO-178C.
> `job`	Источники MATLAB для структуры Дженкинса CI. В этой папке: `DODemoTasks.m` - класс MATLAB, описывающий задание построения Дженкинса на основе операций конструирования на основе модели в проекте DO-178C. `JenkinsJob.m` - абстрактный класс, который является основой для разработки работы по построению Дженкинса, как `DODemoTasks` `JenkinsReport.m` - класс MATLAB, генерирующий XML-отчеты из задания построения Дженкинса. `runJob.m` - функция MATLAB, которая является точкой входа для запуска задания сборки Дженкинса.
> `reports`	Эта подпапка пуста при создании.	Отчеты о результатах, отформатированные плагином Jenkins Summary Display. Результаты включают в себя: Сводка построения - общие результаты для каждой задачи задания построения Дженкинса. Сводка результатов проверки - результаты для отдельных итераций задач проверки с детализированными результатами в табличном формате
`DO_01_Planning`	Контрольные списки и артефакты планирования.
> `checklists`	Контрольные списки для проверки требований, моделей, кода, тестовых примеров, результатов тестов и данных трассировки.
> `plans`	Артефакты планирования программного обеспечения. Вложенные папки включают в себя: `MB_11_01_PSAC` - содержит артефакт План по программным аспектам сертификации (PSAC) `MB_11_02_SDP` - содержит артефакт План разработки программного обеспечения (SDP) `MB_11_03_SVP` - содержит план проверки программного обеспечения (SVP) с артефактом `MB_11_04_SCMP` - содержит артефакт План управления конфигурацией программного обеспечения (SCMP) `MB_11_05_SQAP` - содержит артефакт План по программным аспектам сертификации (PSAC)
> `standards`	Артефакты стандартов программного обеспечения. Вложенные папки включают в себя: `MB_11_06_SRS` - содержит артефакт Стандарты требований к программному обеспечению (SRS) `MB_11_07_SDS` - содержит артефакт Стандарты проектирования программного обеспечения (SDS) `MB_11_08_SCS` - содержит артефакт Стандарты кода программного обеспечения (SCS) `MB_11_23_SMS` - содержит артефакт Стандарты модели программного обеспечения (SMS)
`DO_02_Requirements`	Данные требований.
> `specification`	Эта подпапка пуста при создании. Хранит Ваши высокоуровневые и производные требования (`.slreqx`) и данные прослеживаемости (`.slmx`).	Документы и данные трассировки для системных требований и требований к программному обеспечению высокого уровня. Требования были разработаны с помощью редактора требований и доступны в следующих наборах требований: (Системные требования) `SR.slreqx` (высокие требования) `HLR.slreqx` Эта подпапка также содержит `HLR.slmx` файл, в котором хранятся данные трассировки между высокоуровневыми требованиями к программному обеспечению и соответствующими требованиями к системе. `documents` подпапка содержит отчеты о системных требованиях и требованиях к программному обеспечению высокого уровня. Эти отчеты генерируются из `SR.slreqx` и `HLR.slreqx` около `taskGenReqReport()` в работе по строительству Дженкинса.
> `verification_results`	Эта подпапка пуста при создании. Хранит контрольные списки, соответствующие действиям по проверке высокоуровневых требований к программному обеспечению и производным требованиям.	Хранит контрольные списки, соответствующие действиям по проверке высокоуровневых требований к программному обеспечению и производным требованиям.
`DO_03_Design`	Данные жизненного цикла для моделей конструкции.
> `common`	Общие конструкции конструкции и применимые артефакты проверки. Вложенные папки включают в себя: `specification` - содержит общие блоки и данные. В этой папке: `block_libraries` содержит пользовательские библиотеки блоков (`.slx`) и их данные прослеживаемости (`.slmx`). `data` содержит словари общих данных (`.sldd`/`.m`) используется несколькими моделями конструкции. `data_types` содержит определяемые пользователем типы данных, включая перечисления, шины и псевдонимы (`.sldd`/`.m`). `test_cases` - Сохраняет тестовые примеры и процедуры для выборочных библиотечных блоков. Эта подпапка пуста при создании. `verification_results` - Эта подпапка, пустая при создании, сохраняет следующие результаты проверки на основе модели: `design_stand_checks` `model_coverages` `model_metrics` `model_reviews` `simulation_results`
> `<model>`	Неприменимо	Существует пять папок модели, каждая из которых является производной от `sample_model` шаблон папки. Эти модели представляют низкоуровневые требования к программному обеспечению, которые отслеживаются в соответствии с высокоуровневыми требованиями к программному обеспечению, зафиксированными в `DO_02_Requirements`\`specification`\`HLR.slreqx`. Архитектура программного обеспечения обычно определяется способом организации проекта. При проектировании на основе моделей архитектура программного обеспечения определяется иерархией моделей проекта на основе естественной группировки высокоуровневых требований к программному обеспечению. В данном примере конструкция подразделяется на несколько моделей для удовлетворения различных требований в `HLR.slreqx`. В иерархии моделей конструкции модели конструкции включают в себя: `Flight_Control` - модель верхнего уровня с возможностью многократного использования, реализующая общую стратегию управления; `Actuator_Control` - Модель нижнего уровня, не допускающая многократного использования `AHRS_Voter` - Модель нижнего уровня, не допускающая многократного использования `InnerLoop_Control` - Модель нижнего уровня, не допускающая многократного использования `OuterLoop_Control` - Модель нижнего уровня, не допускающая многократного использования
> `<model>`> `specification`	Неприменимо	Специфичные для модели `.slx` файл модели и `.slmx` файл, в котором хранятся данные трассировки между моделью и соответствующими требованиями к программному обеспечению высокого уровня. `data` вложенная папка содержит словарь данных Simulink, который назван в честь модели, с префиксом `DD`, для хранения данных, специфичных для модели. Поскольку `Actuator_Control` многократно используется, имеется дополнительный скрипт MATLAB ®, который назван в честь модели с префиксом `localDD_`. Этот сценарий содержит данные модели, специфичные для экземпляра. `documents` во вложенной папке хранится описание конструкции модели.
> `<model>`> `test_cases`	Неприменимо	Примечание В этом примере тестовые примеры создаются только для модели. `AHRS_Voter`. `HLR` во вложенной папке хранятся тестовые примеры, разработанные для проверки модели на соответствие требованиям высокого уровня. В этой папке создается файл Test™ Simulink для управления высокоуровневыми тестовыми случаями. Этот тестовый файл имеет имя модели, за которым следует `_REQ_Based_Test`. В этом тематическом исследовании существует три высокоуровневых тестовых случая для модели `AHRS_Voter`. Эти тестовые примеры, доступные в `AHRS_Voter\test_cases\HLR\AHRS_Voter_REQ_Based_Test.mldatx`, использовать внешне хранящиеся тестовые жгуты `HRS_Voter_Harness_HLR_11.slx`, `AHRS_Voter_Harness_HLR_12.slx`, и `HRS_Voter_Harness_HLR_13.slx` проверить `AHRS_Voter` против требований `HLR_11`, `HLR_12`, и `HLR_13`соответственно. `HLR` подпапка также содержит `AHRS_Voter_REQ_Based_Test.slmx` , в котором хранятся данные трассировки между тестовыми случаями и высокоуровневыми требованиями к программному обеспечению, которые они разрабатывают для проверки. `LLR` подпапка содержит низкоуровневые результаты генерации тестов и отчет для модели `AHRS_Voter`, включая тестовый файл и тестовый жгут. Сгенерированные низкоуровневые тестовые примеры, доступные в `AHRS_Voter\test_cases\LLR\AHRS_Voter_SLDV_Based_Test.mldatx`, использовать внешний тестовый жгут `AHRS_Voter_Harness_SLDV.slx`. Тестовые примеры, которые используются для достижения целей, не достигнутых в его высокоуровневом тестовом покрытии, генерируются на основе модели `taskGenLowLevelTests` в работе по строительству Дженкинса.
> `<model>`> `verification_results`	Неприменимо	Примечание В этом примере результаты проверки создаются только для модели. `AHRS_Voter`. `simulation_results`\`HLR` вложенная папка содержит высокоуровневые результаты моделирования и отчет для модели. Эти результаты моделирования создаются с помощью тестовых примеров для проверки требований низкого уровня (реализованных в модели) на соответствие требованиям высокого уровня. Результаты генерируются `taskVerifyModel2Reqs()` в работе по строительству Дженкинса. `model_coverages`\`HLR` подпапка содержит результаты покрытия модели высокого уровня и отчет для модели. Эти результаты покрытия собираются в тестовых случаях, которые проверяют требования низкого уровня (реализованные с помощью модели) на соответствие требованиям высокого уровня. Результаты покрытия модели генерируются `taskVerifyModel2Reqs()` в работе по строительству Дженкинса. `design_error_detections()` вложенная папка содержит отчет об обнаружении ошибок конструкции для модели `AHRS_Voter`. Этот отчет является результатом использования Simulink Design Verifier™ для анализа модели на предмет потенциальных ошибок во время выполнения и неработоспособности логики. генерируются `taskDetectDesignErrs()` в работе по строительству Дженкинса. `design_standard_checks` вложенная папка содержит стандартный отчет о соответствии модели. Этот отчет является результатом проверки модели по проверкам Model Advisor, указанным в файле конфигурации Model Advisor. `tools\checks\do178Checks.json`. Отчет генерируется `taskCheckModelStds()` в работе по строительству Дженкинса.
`DO_04_Code`	Данные жизненного цикла для созданного кода.
> `specification`	Сохраняет созданный код. Эта подпапка пуста при создании.	Сгенерированный исходный код для каждой модели. Код генерируется `taskGenSrcCode()` в работе по строительству Дженкинса. Примечание Код модели верхнего уровня находится в `Flight_Control_ert_rtw`. Код для каждой модели нижнего уровня находится в `slprj\ert` с общим кодом.
> `verification_results`	Эта папка пуста при создании.	Результаты проверки исходного и исполняемого объектного кода.
> `verification_results`> `code_reviews`	Сохраняет отчеты по проверке кода для созданного кода. Эта подпапка пуста при создании.	Отчеты по проверке кода для сгенерированного кода из каждой модели являются результатом использования Simulink Code Inspector™ для проверки исходного кода. Отчет генерируется `taskGenSrcCode()` в работе по строительству Дженкинса.
> `verification_results`> `eoc_test_results`	Сохраняет результаты высокоуровневого/низкоуровневого тестирования ПО в цикле и отчет о сгенерированном коде. Эта подпапка пуста при создании.	`eoc_test_results`\`<model>`\`host`\`HLR`\`instrumented` подпапка содержит высокоуровневые результаты тестирования программного обеспечения в цикле и отчет о сгенерированном коде для модели. Они являются результатом выполнения тестов, которые проверяют низкоуровневые требования (реализованные с помощью модели) на соответствие высокоуровневым требованиям в режиме программного обеспечения в цикле. Эти результаты испытаний генерируются `taskVerifyObjCode2Reqs()` в работе по строительству Дженкинса. `eoc_test_results`\`<model>`\`host`\`LLR`\`instrumented` подпапка содержит низкоуровневые результаты тестирования программного обеспечения в цикле и отчет о сгенерированном коде для модели. Они являются результатом выполнения тестовых примеров, которые получены из модели и дополняют ее высокоуровневый тестовый охват в режиме программного обеспечения в цикле. Эти результаты испытаний генерируются `taskVerifyObjCode2LowLevelTests()` в работе по строительству Дженкинса.
> `verification_results`> `code_coverages`	Сохраняет отчет о покрытии кода созданного кода. Эта подпапка пуста при создании.	Отчет о совокупном покрытии кода сгенерированным кодом для каждой модели. Этот отчет составлен на основе объединения результатов покрытия кода как высокого, так и низкого уровня. Отчет генерируется `taskMergeCodeCoverage()` в работе по строительству Дженкинса. `code_coverages`\`<model>`\`host`\`HLR` подпапка содержит результаты покрытия кода высокого уровня и отчет о сгенерированном коде. Эти результаты покрытия собираются из запущенных тестовых примеров, которые проверяют требования низкого уровня (реализованные с помощью модели) на соответствие требованиям высокого уровня в режиме «программное обеспечение в петле». Эти результаты испытаний генерируются `taskVerifyObjCode2Reqs()` в работе по строительству Дженкинса. `code_coverages`\`<model>`\`host`\`LLR` подпапка содержит низкоуровневые результаты покрытия кода и отчет о сгенерированном коде для каждой модели. Эти результаты покрытия собираются из запущенных тестовых случаев, которые получены из модели, чтобы дополнить ее высокоуровневый тестовый охват в режиме программного обеспечения в цикле. Эти результаты испытаний генерируются `taskVerifyObjCode2LowLevelTests()` в работе по строительству Дженкинса.
> `verification_results`> `coding_error_detections`	Сохраняет отчеты об анализе Finder™ ошибок Polyspace ®. Эта подпапка пуста при создании.	Отчеты об анализе Polyspace Bug Finder генерируются `detectCodingErrs()`.
> `verification_results`> `code_proving`	Сохраняет отчет о проверке созданного кода Prover™ Polyspace Code. Эта подпапка пуста при создании.	Этот отчет является результатом использования Polyspace Code Prover для проверки исходного кода `Flight_Control` и его модели более низкого уровня против потенциальных дефектов программного обеспечения. Отчеты генерируются `taskProveCodeQuality()` в работе по строительству Дженкинса.
> `verification_results`> `code_standard_checks`	Сохраняет стандартный отчет о соответствии кода сгенерированному коду. Эта подпапка пуста при создании.	Отчет создается путем проверки исходного кода каждой модели на соответствие правилам кодирования Polyspace Bug Finder, включенным с помощью `tools\checks\MISRA_C_2012_ACG`. Эти отчеты генерируются `taskCheckCodeStds()` в работе по строительству Дженкинса.
> `verification_results`> `code_metrics`	Сохраняет отчеты о метриках кода Polyspace. Эта подпапка пуста при создании.	Отчеты о метриках кода Polyspace генерируются `computeCodeMetrics()`.
`DO_05_Artifacts`	Сохраняет данные жизненного цикла и артефакты, которые не создаются с помощью инструментов MathWorks. Пользователь несет ответственность за создание следующих артефактов: `MB_11_15_SECI` - индекс конфигурации среды жизненного цикла (SEC) артефакта. `MB_11_16_SCI` - индекс конфигурации программного обеспечения артефакта (SCI). `MB_11_17_PR` - Отчеты о проблемах артефакта (PR). `MB_11_18_SCMR` - артефакт Записи управления конфигурацией программного обеспечения (SCMR). `MB_11_19_SQAR` - артефакт Записи обеспечения качества программного обеспечения (SQAR). `MB_11_20_SAS` - Краткое описание выполнения программного обеспечения артефакта (SAS). `MB_11_22_PDIF` - сохранить файл данных параметров (PDIF).
`DO_06_Tool Qualification`	Содержит данные жизненного цикла квалификации инструмента. Специальные вложенные папки, соответствующие продуктам MathWorks, поддерживаемым комплектом DO Qualification Kit, включая: PolyspaceBugFinder PolyspaceCodeProver SimulinkCheck SimulinkCodeInspector SimulinkCoverage SimulinkDesignVerifier SimulinkModelComparison SimulinkReportGenerator SimulinkRequirements SimulinkTest
`help`	Инструкции по использованию DO-178C шаблона проекта, описание папок/подпапок проекта и советы по интерфейсу управления требованиями Simulink Requirements™.
`tools`	Инструменты и конфигурации, необходимые для проекта. Вложенные папки включают в себя: `checks` - Содержит файлы конфигурации для проверок Model Advisor и стандартных проверок Polyspace Coding, предназначенных для дополнения стандартов модели программного обеспечения (SMS) и стандартов кода программного обеспечения (SCS), предусмотренных в проекте, соответственно. `compatible_blocks` - хранит библиотеку блоков, содержащую все примитивные блоки, совместимые с Simulink Code Inspector. Служит в качестве ограничений проектирования программного обеспечения. `templates` - хранит шаблоны и конфигурации для создания моделей. Вложенные папки включают в себя: `model_configurations` - содержит конфигурации базовой модели, соответствующие артефакту стандартов модели программного обеспечения. `model_templates` - содержит шаблон модели, соответствующий артефакту стандартов модели программного обеспечения. `utilities` - Служебные функции, которые можно использовать для выполнения основных задач разработки и проверки. Вложенные папки включают в себя: `code_generation` - используется для генерации кода и извлечения информации о файле жизненно важного кода. `modeling` - используется для извлечения информации о жизненно важных моделях и блоках библиотеки. `project_management` - используется для управления проектом. В этой папке: `shutdown` содержит ярлык проекта, выполняющий задачи очистки и восстановления при завершении проекта. `startup` содержит ярлык проекта, который выполняет задачи регистрации и настройки при запуске проекта. `report_generation` - используется для создания отчетов по описанию проекта системы и отчетов по требованиям. `requirements_management` - используется для настройки параметров интерфейса управления требованиями Simulink Coverage™ (RMI). `verification` - используется для проверки моделей и кода. В этой папке: `dynamic_testing` содержит служебные функции, которые проверяют модели и код с помощью динамических методологий тестирования. `static_analysis` содержит служебные функции, которые проверяют модели и код с помощью статических анализов и проверок.
`work`	Рабочая папка по умолчанию, содержащая разрабатываемые работы и промежуточные результаты проверки. `cache` подпапка содержит артефакты построения модели, используемые для моделирования, и промежуточные артефакты, созданные в результате выполнения действий проверки.	Включает в себя `demo` подпапка, содержащая сценарий MATLAB live `runDemo.mlx`. Этот сценарий можно выполнить, выбрав Вариант на вкладке Ярлыки проекта.

Документация