Следующая таблица содержит сводные данные целей процесса планирования от 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 | Должен включать инструменты Model-Based Design в процессы жизненного цикла. |
| 4 | Обращены дополнительные факторы. | 4.1.d | 4.2.f 4.2.h 4.2.i 4.2.j 4.2.k | A, B, C, D | Если применимо к проекту и квалификации инструмента, должен обратиться к любым Элементам Анализа Сертификации EASA, и ФАА Выпускают Газеты. Продукт 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[3], применим. Модели могут быть заданы как Модели Спецификации или Модели проекта, как описано в Разделе DO-331 MB.1.6.2. Определение модели должно быть обращено в процессе планирования. Раздел DO-331 MB.1.6.3 дает некоторые примеры того, как Спецификация и Модели проекта могут использоваться. Как показано в примерах, ответственность за разработку требований модели и самих моделей, может быть в областях программного обеспечения или системах. В любом случае и требования модели и сами модели, подпадают под руководство DO-331. Ответственность должна быть идентифицирована в процессе планирования. Процесс планирования должен также идентифицировать, как использовать симуляцию модели и анализ модели как часть процессов проверки.
Если инструменты формальных методов, например, Polyspace® Code Prover™, должны использоваться в кредите сертификации, то DO-333, Дополнение Формальных методов к DO - 178C и DO - 278A[5] становятся применимыми. Процесс планирования должен идентифицировать, как использовать формальный анализ в качестве части процессов проверки.
За одним возможным исключением Модельно-ориентированное проектирование не использует объектно-ориентированный метод. Возможное исключение позволяет Embedded Coder® опционально генерировать инкапсулировавший код C++. В этом случае интерфейс кода использует классы и методы. Поэтому DO-332, Объектно-ориентированный метод и Связанное Дополнение Методов к DO - 178C и DO - 278A[4], становится применимым. В этом случае процесс планирования должен идентифицировать, как разработать и проверить этот объектно-ориентированный метод.
Обратитесь к контролю изменений и управлению конфигурацией моделей во время процесса планирования.
Жизненный цикл (циклы) программного обеспечения, включая взаимосвязи между процессами, их секвенированием, механизмами обратной связи, и критериями перехода, должен быть задан. Когда Модельно-ориентированное проектирование начинается, оно должно также быть задано. Этот этап - когда высокоуровневые требования (или системные требования или высокоуровневые требования к программному обеспечению) разработаны, сконфигурированы и утверждены.
Когда код сгенерирован, код должен быть задан. Этот этап - когда модели были разработаны, сконфигурированы и утверждены. Шаги, чтобы утвердить модели как завершенные и правильные должны быть заданы и могут включать модель:
Отзывы
Тестирование симуляции
Статический анализ
Динамический анализ
Должны быть заданы инструменты Модельно-ориентированного проектирования, используемые в процессах разработки и процессах проверки. Инструменты могут включать MATLAB®, Simulink®, Stateflow®, MATLAB Coder™, Simulink Coder, Embedded Coder, Simulink Code Inspector™, Polyspace Bug Finder™, Polyspace Bug Finder Server™, Polyspace Code Prover, Polyspace Code Prover Server, Simulink Check™, Simulink Coverage™, Simulink Design Verifier™, Simulink Test™ и Simulink Report Generator™.
Если какие-либо инструменты Model-Based Design квалифицированы как Критерии 1, Критерии 2 или Критерии 3 инструмента, как описано в DO - 178C Раздел 12.2.2, каждый из инструментов, которые будут квалифицированы, должен быть идентифицирован, и действия квалификации инструмента должны быть заданы как описано в DO-330, Факторы Проверки Программного инструмента [2]. DO Qualification Kit может использоваться в проверке инструментов верификации MathWorks®.
Или Технические требования или Режимы проектирования используются (см., что Действия Процессов Жизненного цикла программного обеспечения Заданы), моделирование стандартов должно существовать, чтобы удовлетворить целям стандартов требований. Документация Simulink содержит Руководства по моделированию, которые могут использоваться в качестве начальной точки для разработки специфичных для проекта стандартов моделирования. Податливость к стандартам должна быть проверена с помощью инструментов и/или человеческих отзывов. Существуют проверки Model Advisor, чтобы проверить податливость с Руководствами по моделированию, предоставленными в документации Simulink.
Для инструмента Embedded Coder, MISRA® AC AGC: могут использоваться 2 007 стандартов кодирования [6]. Некоторыми построениями в сгенерированном коде, такими как соглашения о присвоении имен, могут управлять пользователи, чтобы соответствовать определенному клиенту, кодирующему стандарты. Податливость к стандартам должна быть проверена через инструменты и/или человеческие отзывы. Polyspace Bug Finder и Polyspace Bug Finder Server предусматривают возможность проверять AGC AC MISRA: 2 007 правил.
План относительно Аспектов программного обеспечения Сертификации (PSAC) должен быть разработан, то же самое что касается традиционных программ разработки.
План относительно Аспектов программного обеспечения Сертификации (PSAC) должен быть сконфигурирован при контроле изменений и утвержден применимыми сертифицирующими органами как часть программы, как в традиционном процессе разработки.
