В следующей таблице содержится сводная информация о задачах процесса разработки программного обеспечения из 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™, встроенный кодер ® |
| 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 | Встроенный кодер - режим 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 | Определены элементы проектной модели, которые не способствуют реализации или реализации каких-либо низкоуровневых требований. | MB.5.2.1.c | MB.5.2.2.h | A, B, C | Simulink, Stateflow |
В следующих разделах более подробно описываются потенциальные последствия для каждой цели процесса разработки программного обеспечения при использовании модели на основе проектирования, если применимо, по сравнению с традиционной разработкой.
Если модели определены как модели спецификаций, как описано в разделе DO-331 MB.1.6.2, то Simulink и Stateflow могут использоваться для разработки высокоуровневых требований к программному обеспечению. Компоненты в этих моделях, такие как блоки Simulink или объекты Stateflow, затем отслеживаются в соответствии с применимыми требованиями системного уровня, разработанными в соответствии с ARP4754A [7]. Модели должны разрабатываться в соответствии со стандартами моделирования, определенными в процессе планирования.
Если модели определены как модели спецификаций, как описано в разделе DO-331 MB.1.6.2, любые компоненты Simulink или Stateflow, которые не соответствуют требованиям системы, будут идентифицированы как производные требования. Эти вытекающие требования будут включены в процесс оценки безопасности.
Когда модели получаются как модели конструкции, как описано в разделе DO-331 MB.1.6.2, архитектура отдельных программных модулей может быть определена моделями Simulink и Stateflow, включая последовательность и сопряжение различных элементов в моделях. Если используется ссылочная возможность модели, то анализатор зависимостей может использоваться для документирования архитектуры программных модулей, интегрированных с помощью этой возможности.
Архитектура более высокого уровня, определяющая, каким образом проект на основе модели создает интерфейсы кода с другим кодом в системе, должна быть определена отдельно. Это может включать в себя интерфейс с операционной системой реального времени (RTOS), вызывающую последовательность для кода, сгенерированного из конструкции на основе модели, и интерфейс данных с другими модулями кода.
Если модели определены как конструкторские модели, как описано в разделе DO-331 MB.1.6.2, то Simulink и Stateflow могут использоваться для разработки низкоуровневых требований к программному обеспечению. Затем компоненты в этих моделях будут отслеживаться в соответствии с требованиями к программному обеспечению высокого уровня. Модели должны разрабатываться в соответствии со стандартами моделирования, определенными в процессе планирования.
Если модели определены как конструкторские модели, как описано в разделе DO-331 MB.1.6.2, то любые компоненты Simulink или Stateflow, которые не соответствуют требованиям к высокоуровневому программному обеспечению, будут идентифицированы как производные требования. Эти вытекающие требования будут включены в процесс оценки безопасности.
Встроенный кодер и кодер Simulink можно использовать для создания исходного кода из модели. Исходный код может отслеживать компоненты модели с помощью опций комментирования. Исходный код может быть создан в соответствии со стандартами MISRA ® AC AGC: 2007, за некоторыми исключениями, путем соблюдения стандартов моделирования.
Сгенерированный исходный код может быть скомпилирован, связан и исполняемый объектный код автоматически загружен в целевой процессор или DSP с помощью функции режима PIL встроенного кодера. Если используются элементы данных параметров, файлы элементов данных параметров должны быть сгенерированы и загружены в целевой процессор DSP.
Кроме того, сгенерированный исходный код может быть скомпилирован и связан с помощью стандартных компиляторов и линкеров. Файл make, используемый компилятором, может быть создан Embedded Coder или разработан вручную. Затем исполняемый объектный код загружается на целевой компьютер.
Simulink содержит как виртуальные, так и невиртуальные блоки, как описано в документации. В общем, реализация определяется не виртуальными, а не виртуальными блоками. Примеры виртуальных блоков включают блоки DOC, подсистемы, используемые для группирования блоков в модели, и некоторые соединения внутри виртуальных подсистем, такие как входы или выходы. Стандарты моделирования для проекта должны определять эти типы виртуальных блоков как не способствующие внедрению.
Simulink содержит как виртуальные, так и невиртуальные блоки, как описано в документации. В общем, реализация определяется не виртуальными, а не виртуальными блоками. Примеры виртуальных блоков включают блоки DOC, подсистемы, используемые для группирования блоков в модели, и некоторые соединения внутри виртуальных подсистем, такие как входы или выходы. Стандарты моделирования для проекта должны определять эти типы виртуальных блоков как не способствующие внедрению. Следует отметить, что некоторые виртуальные блоки, такие как Mux/Demux или Goto/From, определяют потоки данных для архитектуры программного обеспечения.
Simulink содержит как виртуальные, так и невиртуальные блоки, как описано в документации. В общем, реализация определяется не виртуальными, а не виртуальными блоками. Примеры виртуальных блоков включают блоки DOC, подсистемы, используемые для группирования блоков в модели, и некоторые соединения внутри виртуальных подсистем, такие как входы или выходы. Стандарты моделирования для проекта должны определять эти типы виртуальных блоков как не способствующие внедрению. Следует отметить, что некоторые виртуальные блоки, такие как Mux/Demux или Goto/From, определяют потоки данных для архитектуры программного обеспечения.