Следующая таблица содержит сводные данные целей процесса планирования от 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) должен быть сконфигурирован при контроле изменений и утвержден применимыми сертифицирующими органами как часть программы, как в традиционном процессе разработки.
