Следующая таблица содержит сводку целей процесса планирования из DO-178C, включая цель, применимые ссылочные разделы и уровни программного обеспечения, применимые к цели. В таблице также описывается потенциальное влияние на процесс при использовании конструирования на основе модели.
Таблица A-1: Процесс планирования программного обеспечения
| Цель | Справочные разделы | Деятельность Справочные разделы | Уровни программного обеспечения | Влияние процесса проектирования на основе модели | |
|---|---|---|---|---|---|
| 1 | Определяются операции процессов жизненного цикла программного обеспечения. | 4.1.a | 4.2.a 4.2.c 4.2.d 4.2.e 4.2.g 4.2.i 4.2.l 4.3.c | A, B, C, D | Необходимо включить конструирование на основе модели в процесс разработки. |
| 2 | Определяется жизненный цикл (ы) программного обеспечения, включая взаимосвязи между процессами, их последовательность, механизмы обратной связи и критерии перехода. | 4.1.b | 4.2.i 4.3.b | A, B, C | Должен включать переход на основе модели и отношения последовательности. |
| 3 | Выбрана и определена среда жизненного цикла программного обеспечения. | 4.1.c | 4.4.1 4.4.2.a 4.4.2.b 4.4.2.c 4.4.3 | A, B, C | Необходимо включить инструменты конструирования на основе модели в процессы жизненного цикла. |
| 4 | Рассматриваются дополнительные соображения. | 4.1.d | 4.2.f 4.2.h 4.2.i 4.2.j 4.2.k | A, B, C, D | Если применимо к квалификации проекта и инструмента, необходимо рассмотреть все элементы проверки сертификации EASA и документы о выпуске FAA. Продукт DO Qualification Kit доступен для квалификации инструмента. |
| 5 | Определены стандарты разработки программного обеспечения. | 4.1.e | 4.2.b 4.2.g 4.5 | A, B, C | В качестве части стандартов разработки необходимо включить стандарты моделирования. |
| 6 | Планы программного обеспечения соответствуют DO-178C. | 4.1.f | 4.3.a 4.6 | A, B, C | Никакого воздействия |
| 7 | Разработка и пересмотр планов программного обеспечения координируются. | 4.1.g | 4.2.g 4.6 | A, B, C | Никакого воздействия |
В следующих разделах более подробно описываются потенциальные последствия для каждой цели процесса планирования при использовании проекта на основе модели, если применимо, по сравнению с традиционной разработкой.
Проект на основе модели должен быть определен как одно из действий в процессе разработки программного обеспечения, что означает, что применимо дополнение DO-331 к DO-178C и DO-278A [4]. Модели могут быть определены как Модели спецификации (Specification Models) или Модели конструкции (Design Models), как описано в разделе DO-331 MB.1.6.2. Определение модели должно учитываться в процессе планирования. DO-331 В разделе MB.1.6.3 приведены некоторые примеры использования моделей спецификации и проектирования. Как показано в примерах, ответственность за разработку требований к модели и самих моделей может лежать на системах или программных областях. В любом случае и требования к модели, и сами модели подпадают под руководство DO-331. Обязанности должны быть определены в процессе планирования. Процесс планирования должен также определять, как использовать моделирование модели и анализ модели как часть процессов проверки.
Если для сертификационного кредита должны использоваться инструменты формальных методов, например Polyspace ® Code Prover™, то DO-333, формальные методы дополняют DO-178C и DO-278A [6] становятся применимыми. Процесс планирования должен определять, как использовать формальный анализ как часть процессов проверки.
За одним возможным исключением, в модуле Model-Based Design не используется объектно-ориентированная технология. Возможное исключение позволяет Embedded Coder ® дополнительно генерировать инкапсулированный код C++. В этом случае интерфейс кода использует классы и методы. Таким образом, DO-332, объектно-ориентированная технология и связанные с ней методы дополняют DO-178C и DO-278A [5], становятся применимыми. В этом случае процесс планирования должен определять способы разработки и проверки этой объектно-ориентированной технологии.
Управление изменениями и управление конфигурацией моделей в процессе планирования.
Необходимо определить жизненный цикл (ы) программного обеспечения, включая взаимосвязи между процессами, их последовательность, механизмы обратной связи и критерии перехода. При начале конструирования на основе модели его также необходимо определить. На этом этапе разрабатываются, конфигурируются и утверждаются требования более высокого уровня (системные требования или требования к программному обеспечению высокого уровня ).
При создании кода необходимо определить код. На этом этапе модели были разработаны, сконфигурированы и утверждены. Шаги для утверждения моделей как полных и правильных должны быть определены и могут включать модель:
Обзоры
Имитационное тестирование
Статический анализ
Динамический анализ
Необходимо определить инструменты конструирования на основе модели, используемые в процессах разработки и проверки. Инструменты могут включать MATLAB®, Simulink®, Stateflow®, MATLAB Coder™, Симулинка Кодера, Вложенного Кодера, Симулинка Коуда Inspector™, Поликосмическая Ошибка Finder™, Поликосмический Искатель Ошибки Server™, Программа автоматического доказательства Полиспейса Коуда, Полиспейс Коуд Провер Сервер, Simulink Check™, Simulink Coverage™, Симулинк Дезигн Verifier™, Simulink Test™ и Симулинк Репорт Generator™.
Если какие-либо инструменты конструирования на основе модели квалифицируются как инструменты Критерии 1, Критерии 2 или Критерии 3, как описано в DO-178C Разделе 12.2.2, каждый из инструментов, подлежащих квалификации, должен быть определен, а действия по квалификации инструментов должны быть определены как описано в разделе DO-330, Вопросы квалификации программных средств [3]. Комплект DO Qualification Kit может использоваться для проверки инструментов MathWorks ®.
Независимо от того, используются ли спецификации или режимы проектирования (см. раздел «Операции по процессам жизненного цикла программного обеспечения определены»), стандарты моделирования должны быть установлены в соответствии с требованиями стандартов. Документация Simulink содержит рекомендации по моделированию, которые можно использовать в качестве отправной точки при разработке стандартов моделирования для конкретных проектов. Соответствие стандартам должно проверяться с помощью инструментов и/или человеческих обзоров. Существуют проверки Model Advisor для проверки соответствия рекомендациям по моделированию, приведенным в документации Simulink.
Для инструмента Embedded Coder можно использовать стандарты кодирования MISRA ® AC AGC: 2007. Некоторые конструкции в сгенерированном коде, такие как соглашения об именовании, могут управляться пользователями в соответствии с конкретными стандартами кодирования клиента. Соответствие стандартам должно проверяться с помощью инструментов и/или человеческих обзоров. Polyspace Bug Finder и Polyspace Bug Finder Server предоставляют возможность проверки правил MISRA AC AGC: 2007.
Должен быть разработан План по программным аспектам сертификации (PSAC), такой же, как и для традиционных программ разработки.
План по программным аспектам сертификации (PSAC) должен быть настроен под контролем изменений и утвержден соответствующими сертификационными органами в рамках программы, как в традиционном процессе разработки.