Следующая таблица содержит сводные данные целей процесса планирования из 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], применимо. Модели могут быть определены как Модели Спецификации или Моделей проекта, как описано в DO-331 Section MB.1.6.2. Определение модели должно рассматриваться в процессе планирования. DO-331 разделе MB.1.6.3 приведены некоторые примеры того, как могут использоваться спецификации и Модели проекта. Как показано на примерах, ответственность за разработку требований к модели и самих моделей может лежать на системах или программных областях. В любом случае под руководством DO-331 попадают как требования модели, так и сами модели. Обязанности должны быть определены в процессе планирования. Процесс планирования должен также идентифицировать, как использовать симуляцию модели и анализ модели в рамках процессов верификации.
Если инструменты формальных методов, например Polyspace® Code Prover™ должны использоваться для сертификационного кредита, затем DO-333, Формальные методы дополнения к DO-178C и DO-278A [6] становится применимым. Процесс планирования должен определять, как использовать формальный анализ как часть процессов проверки.
За одним возможным исключением, Модельно-ориентированное Проектирование не использует объектно-ориентированный метод. Возможное исключение позволяет Embedded Coder® чтобы опционально сгенерировать инкапсулированный код C++. В этом случае интерфейс кода использует классы и методы. Поэтому DO-332, Объектно-ориентированный метод и сопутствующие методы Дополнения к DO-178C и DO-278A [5], становятся применимыми. В этом случае процесс планирования должен определить, как разработать и проверить этот объектно-ориентированный метод.
Управление изменениями и управление строением моделей в процессе планирования.
Необходимо определить жизненный цикл программного обеспечения, включая взаимосвязи между процессами, их секвенирование, механизмы обратной связи и критерии перехода. Когда Модельно-ориентированное проектирование начинается, это также должно быть определено. На данном этапе разрабатываются, конфигурируются и утверждаются требования более высокого уровня (системные требования или требования к программному обеспечению высокого уровня ).
Когда код сгенерирован, код должен быть определен. Этот этап, когда модели были разработаны, сконфигурированы и утверждены. Шаги для утверждения моделей как полных и правильных должны быть определены и могут включать модель:
Обзоры
Область проверки
Статический анализ
Динамический анализ
Модельно-ориентированным проектированием определить инструменты, используемые в процессах разработки и верификации. Инструменты могут включать 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™.
Если какие-либо основанные на модели инструменты проектирования квалифицированы как инструменты критериев 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) должен быть сконфигурирован под контролем изменений и утвержден применимыми сертифицирующими органами как часть программы, как в традиционном процессе разработки.
