Следующая таблица содержит сводные данные целей процесса разработки программного обеспечения из DO-178C и DO-331, включая цель, применимые справочные разделы и уровни программного обеспечения, применимые к цели. Таблица также описывает доступные инструменты Модельно-ориентированное проектирование для достижения целей.
Таблица A-2: Процесс разработки программного обеспечения
| Цель | Справочные разделы | Деятельность Справочные разделы | Уровни программного обеспечения | Доступные продукты для Модельно-ориентированного проектирования | |
|---|---|---|---|---|---|
| 1 | Разрабатываются требования высокого уровня. | MB.5.1.1.a | MB.5.1.2.a MB.5.1.2.b MB.5.1.2.c MB.5.1.2.d MB.5.1.2.e MB.5.1.2.f MB.5.1.2.g MB.5.1.2.j MB.5.1.2.k MB.5.1.2.l 5.5a | A, B, C, D | Simulink®, Stateflow® |
| 2 | Производные требования высокого уровня определяются и предоставляются системным процессам, включая процесс оценки безопасности системы. | MB.5.1.1.b | MB.5.1.2.h MB.5.1.2.i MB.5.1.2.k | A, B, C, D | Simulink, Stateflow |
| 3 | Разработана программная архитектура. | MB.5.2.1.a | MB.5.2.2.a MB.5.2.2.d MB.5.2.2.h | A, B, C, D | Simulink, Stateflow |
| 4 | Разработаны низкоуровневые требования. | MB.5.2.1.a | MB.5.2.2.a MB.5.2.2.e MB.5.2.2.f MB.5.2.2.g MB.5.2.2.h MB.5.2.3.a MB.5.2.3.b 5.2.4.a 5.2.4.b 5.2.4.c MB.5.5 5.5b | A, B, C | Simulink, Stateflow |
| 5 | Производные низкоуровневые требования определяются и предоставляются системным процессам, включая процесс оценки безопасности системы. | MB.5.2.1.b | MB.5.2.2.b MB.5.2.2.c MB.5.2.2.h | A, B, C | Simulink, Stateflow |
| 6 | Разработан исходный код. | 5.3.1.a | 5.3.2.a 5.3.2.b 5.3.2.c 5.3.2.d MB.5.5 5.5.c | A, B, C | Simulink Coder™, Embedded Coder® |
| 7 | Исполняемые объектные коды и элемента данных параметра, если таковые имеются, создаются и загружаются на целевой компьютер. | 5.4.1.a | 5.4.2.a 5.4.2.b 5.4.2.c 5.4.2.d 5.4.3.e 5.4.3.f | A, B, C, D | Embedded Coder - режим PIL |
| МБ 8 | Определяются элементы модели спецификации, которые не способствуют реализации или реализации каких-либо требований высокого уровня. | MB.5.1.1.c | MB.5.1.2.k | A, B, C, D | Simulink, Stateflow |
| МБ 9 | Модели проекта, которые не способствуют реализации или реализации какой-либо программной архитектуры, идентифицируются. | MB.5.2.1.c | MB.5.2.2.h | A, B, C, D | Simulink, Stateflow |
| МБ 10 | Определяются элементы Design Model, которые не способствуют реализации или реализации каких-либо низкоуровневых требований. | MB.5.2.1.c | MB.5.2.2.h | A, B, C | Simulink, Stateflow |
В следующих разделах более подробно описываются потенциальные влияния для каждого процесса разработки программного обеспечения при использовании Модельно-ориентированное проектирование, если применимо, по сравнению с традиционной разработкой.
Если модели определены как Модели Спецификации, как описано в DO-331 Section MB.1.6.2, то Simulink и Stateflow могут использоваться, чтобы разработать требования к программному обеспечению высокого уровня. Компоненты этих моделей, такие как блоки Simulink или объекты Stateflow, затем будут прослеживаться до применимых требований к уровню системы, которые разрабатываются в соответствии с ARP4754A [7]. Модели должны разрабатываться в соответствии со стандартами моделирования, определенными в процессе планирования.
Если модели определены как Модели Спецификации, как описано в DO-331 Section MB.1.6.2, любые компоненты Simulink или Stateflow, которые не соответствуют системным требованиям, будут идентифицированы как производные требования. Эти производные требования будут предоставляться в рамках процесса оценки безопасности.
Когда модели получают как Модели проекта, как описано в DO-331 Section MB.1.6.2, архитектура отдельных модулей программного обеспечения может быть определена моделями Simulink и Stateflow, включая секвенирование и взаимодействие различных элементов в моделях. Если модель-ссылка возможность используется, анализатор зависимостей может использоваться для документирования архитектуры программных модулей, которые интегрированы с помощью этой возможности.
Архитектура более высокого уровня того, как Модельно-ориентированное проектирование сгенерированного кода интерфейсы к другому коду в системе, должна определяться отдельно. Это может включать в себя интерфейс к операционной системе в реальном времени (RTOS), последовательность вызовов для кода, сгенерированного из Модельно-ориентированное Проектирование, и интерфейс данных к другим модулям кода.
Если модели определены как Модели проекта, как описано в DO-331 Section MB.1.6.2, то Simulink и Stateflow могут использоваться для разработки требований к низкоуровневому программному обеспечению. Компоненты этих моделей затем будут соответствовать применимым требованиям к программному обеспечению высокого уровня. Модели должны разрабатываться в соответствии со стандартами моделирования, определенными в процессе планирования.
Если модели определены как Модели проекта, как описано в DO-331 Section MB.1.6.2, то любые компоненты Simulink или Stateflow, которые не соответствуют требованиям к программному обеспечению высокого уровня, будут идентифицированы как производные требования. Эти производные требования будут предоставляться в рамках процесса оценки безопасности.
Embedded Coder и Simulink Coder могут использоваться, чтобы сгенерировать исходный код из модели. Исходный код может проследить до компонентов модели с помощью опций комментария. Исходный код может быть сгенерирован в соответствии с MISRA® Стандарты AC AGC: 2007, за некоторыми исключениями, путем соблюдения стандартов моделирования.
Сгенерированный исходный код может быть скомпилирован, связан, и исполняемый объектный код автоматически загружен на целевой процессор или DSP с помощью возможности PIL Mode Embedded Coder. Если используются элементы данных о параметрах, файлы элементов данных о параметрах должны быть сгенерированы и загружены в DSP целевого процессора.
В качестве альтернативы сгенерированный исходный код может быть скомпилирован и связан с помощью стандартных компиляторов и линкеров. Файл make, который использует компилятор, может быть сгенерирован Embedded Coder или разработан вручную. Затем исполняемый объектный код загружается на целевой компьютер.
Simulink содержит как виртуальные блоки, так и невиртуальные блоки, как описано в документации. В целом реализация определяется невиртуальными блоками, а не виртуальными блоками. Примеры виртуальных блоков включают блоки DOC, подсистемы, используемые для группирования блоков вместе в модели, и некоторые соединения внутри виртуальных подсистем, такие как входные или выходные порты. Стандарты моделирования для проекта должны определять эти типы виртуальных блоков как не способствующие реализации.
Simulink содержит как виртуальные блоки, так и невиртуальные блоки, как описано в документации. В целом реализация определяется невиртуальными блоками, а не виртуальными блоками. Примеры виртуальных блоков включают блоки DOC, подсистемы, используемые для группирования блоков вместе в модели, и некоторые соединения внутри виртуальных подсистем, такие как входные или выходные порты. Стандарты моделирования для проекта должны определять эти типы виртуальных блоков как не способствующие реализации. Обратите внимание, что некоторые виртуальные блоки, такие как Mux/Demux или Goto/From, определяют потоки данных для программной архитектуры.
Simulink содержит как виртуальные блоки, так и невиртуальные блоки, как описано в документации. В целом реализация определяется невиртуальными блоками, а не виртуальными блоками. Примеры виртуальных блоков включают блоки DOC, подсистемы, используемые для группирования блоков вместе в модели, и некоторые соединения внутри виртуальных подсистем, такие как входные или выходные порты. Стандарты моделирования для проекта должны определять эти типы виртуальных блоков как не способствующие реализации. Обратите внимание, что некоторые виртуальные блоки, такие как Mux/Demux или Goto/From, определяют потоки данных для программной архитектуры.
