Следующая таблица содержит сводные данные целей процесса разработки программного обеспечения от DO - 178C и DO-331, включая объективные, применимые ссылочные разделы и программные уровни, применимые к цели. Таблица также описывает доступные инструменты Model-Based Design для удовлетворения целям.
Таблица 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 Мбит 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 Мбит 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 | Идентифицированы элементы Модели проекта, которые не способствуют реализации или реализации никаких низкоуровневых требований. | 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[10]. Модели должны быть разработаны в соответствии со стандартами моделирования, заданными во время процесса планирования.
Если модели заданы как Модели Спецификации, как описано в Разделе 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, которые не прослеживают до высокоуровневых требований к программному обеспечению, были бы идентифицированы как выведенные требования. Эти выведенные требования были бы предоставлены процессу оценки безопасности.
Embedded Coder и Simulink Coder могут использоваться, чтобы сгенерировать исходный код из модели. Исходный код может проследить до компонентов модели при помощи комментария опций. Исходный код может быть сгенерирован в соответствии с MISRA® AC AGC: 2 007 стандартов, за некоторыми исключениями, путем соблюдения моделирования стандартов.
Сгенерированный исходный код может быть скомпилирован, соединен, и исполняемый объектный код, автоматически загруженный на целевой процессор или DSP с помощью возможности Режима PIL Embedded Coder. Если элементы данных параметра используются, файлы элемента данных параметра должны быть сгенерированы и загружены на DSP целевого процессора.
В качестве альтернативы сгенерированный исходный код может быть скомпилирован и соединил использующие стандартные компиляторы и компоновщиков. Make-файл, что использование компилятора может быть сгенерировано Embedded Coder или разработано вручную. Исполняемый объектный код затем загружается на целевой компьютер.
Simulink содержит и виртуальные блоки и невиртуальные блоки, как описано в документации. В общем случае реализация задана невиртуальными блоками, не виртуальными блоками. Примеры виртуальных блоков включают блоки DOC, подсистемы раньше собирали в группу блоки в модели и некоторые связи в виртуальных подсистемах, таких как импорт или выходные порты. Стандарты моделирования для проекта должны задать эти типы виртуальных блоков как не способствующий реализации.
Simulink содержит и виртуальные блоки и невиртуальные блоки, как описано в документации. В общем случае реализация задана невиртуальными блоками, не виртуальными блоками. Примеры виртуальных блоков включают блоки DOC, подсистемы раньше собирали в группу блоки в модели и некоторые связи в виртуальных подсистемах, таких как импорт или выходные порты. Стандарты моделирования для проекта должны задать эти типы виртуальных блоков как не способствующий реализации. Обратите внимание на то, что некоторые виртуальные блоки, такие как Мультиплексор/Демультиплексор или Goto/From, действительно задают потоки данных для программной архитектуры.
Simulink содержит и виртуальные блоки и невиртуальные блоки, как описано в документации. В общем случае реализация задана невиртуальными блоками, не виртуальными блоками. Примеры виртуальных блоков включают блоки DOC, подсистемы раньше собирали в группу блоки в модели и некоторые связи в виртуальных подсистемах, таких как импорт или выходные порты. Стандарты моделирования для проекта должны задать эти типы виртуальных блоков как не способствующий реализации. Обратите внимание на то, что некоторые виртуальные блоки, такие как Мультиплексор/Демультиплексор или Goto/From, действительно задают потоки данных для программной архитектуры.
