Процесс проекта оборудования

Следующая таблица содержит сводные данные из оборудования проекта целей DO-254. Таблица также описывает доступные инструменты Модельно-ориентированное проектирование для достижения целей.

Таблица A-2: Цели процесса проекта оборудования

 ЦельСправочные разделыУровни обеспеченияДоступные продукты для Модельно-ориентированного проектирования
1Требования определяются, определяются и документируются5.1.1(1)A, B, C, D Simulink® Requirements™
2Произведенные производные требования возвращаются к соответствующему процессу. 5.1.1(2)A, B, C, D Simulink Requirements
3Пропуски и ошибки требований предоставляются соответствующему процессу разрешения. 5.1.1(3)A, B, C, D Simulink Requirements
4Концептуальный проект аппаратных элементов разработан и соответствует его требованиям.5.2.1(1)A, BSimulink, Stateflow®, Fixed-Point Designer™, Simulink Report Generator™, Simulink Requirements
5Произведенные производные требования направляются обратно на захват требований или другой соответствующий процесс.5.2.1(2)A, BSimulink, Stateflow, Fixed-Point Designer, Simulink Report Generator, Simulink Requirements
6Пропуски и ошибки требований предоставляются соответствующему процессу разрешения.5.2.1(3)A, BSimulink, Stateflow, Simulink Coverage™
7Рабочий проект разработан на основе требований к аппаратным элементам и данных концептуального проекта.5.3.1(1)A, B, C, D HDL Coder™
8Производные требования возвращаются к концептуальному проекту или другому соответствующему процессу.5.3.1(2)A, B, C, D HDL Coder
9Пропуски и ошибки требований предоставляются соответствующему процессу разрешения.5.3.1(3)A, B, C, DHDL Coder, HDL- Verifier™
10Создаётся оборудование, который реализует рабочий проект оборудования с помощью демонстрационных производственных процессов.5.4.1(1)A, B, C, DНе применяется
11Реализация, сборка и установка оборудования элемента данных завершены5.4.1(2)A, B, C, DНе применяется
12Производные требования возвращаются к рабочему проекту или другому соответствующему процессу.5.4.1(3)A, B, C, DНе применяется
13Пропуски и ошибки требований предоставляются соответствующему процессу разрешения.5.4.1(4)A, B, C, DНе применяется
14Установлена базовая структура, которая включает все проектные и производственные данные, необходимые для поддержки последовательной репликации аппаратного элемента.5.5.1(1)A, B, C, DНе применяется
15Выявляются и документируются производственные требования, связанные с безопасностью, и устанавливается производственный контроль.5.5.1(2)A, B, C, DНе применяется
16Производные требования направляются обратно на реализацию или другой соответствующий процесс.5.5.1(3)A, B, C, DНе применяется
17Ошибки и упущения предоставляются соответствующему процессу разрешения.5.5.1(4)A, B, C, DНе применяется

В следующих разделах описываются потенциальные влияния для каждой цели при использовании основанного на модели проекта, если применимо, по сравнению с традиционной разработкой.

5.1.1 (1) Требования к ─ идентифицируются, определяются и документируются

Для разработки требований к оборудованию можно использовать Simulink Requirements. Компоненты требований в Simulink Requirements соответствуют соответствующим требованиям уровня системы, которые разрабатываются в соответствии с ARP4754. Можно использовать Simulink Requirements, чтобы проследить требования к компонентам модели, которые их реализуют.

Можно использовать Simulink Requirements, чтобы сгенерировать отчет Requirements, который обеспечивает требования в PDF, HTML или Microsoft® Форматы слов.

5.1.1 (2) ─ Произведенные производные требования возвращаются к соответствующему процессу

При использовании Simulink Requirements для определения аппаратных требований необходимо использовать ключевые слова или пользовательские атрибуты в наборе требований, чтобы определить любые компоненты требований, которые не соответствуют системным требованиям. Затем они предоставляются системному процессу.

5.1.1 (3) ─ пропуски и ошибки требований предоставляются соответствующему процессу для разрешения

При использовании Simulink Requirements для определения аппаратных требований проверка набора требований может выявить пропуски или ошибки в системных требованиях. Они предоставляются системному процессу для разрешения.

5.2.1 (1) ─ Концептуальный проект аппаратного элемента разработан и соответствует его требованиям

При использовании моделей для определения концептуального проекта можно разработать концептуальный проект с помощью Simulink, Fixed-Point Designer и Stateflow. Можно использовать Simulink Requirements, чтобы проследить компоненты в этих моделях до соответствующих аппаратных требований. Необходимо разрабатывать модели в соответствии со стандартами моделирования, определенными в процессе планирования.

Можно использовать Simulink Report Generator, чтобы сгенерировать отчет Разработка Системы Description, который предоставляет проект в PDF, HTML, Microsoft Word или PowerPoint® форматы.

5.2.1 (2) ─ Произведенные производные требования возвращаются к захвату требований или другому соответствующему процессу

При использовании моделей для определения концептуального проекта необходимо идентифицировать как производные требования любые компоненты Simulink или Stateflow, которые не соответствуют аппаратным требованиям. Они предоставляются в процессе аппаратных требований для оценки.

5.2.1 (3) ─ Пропуски и ошибки требования предоставляются соответствующему процессу для разрешения

При использовании моделей для определения концептуального проекта симуляция и анализ покрытия модели Simulink и Stateflow могут выявить пропуски или ошибки в требованиях к оборудованию. Они предоставляются в процессе аппаратных требований для разрешения.

5.3.1 (1) ─ Рабочий проект разработан на основе требований к аппаратным элементам и данных концептуального проекта

При использовании моделей Simulink и Stateflow для определения концептуального проекта можно использовать HDL Coder для разработки детального проекта. HDL Coder может предоставить отчет, в котором детальный проект прослеживается до концептуального проекта.

5.3.1 (2) ─ Полученные производные требования возвращаются к концептуальному проекту или другому соответствующему процессу

Вы должны идентифицировать, как производные требования, любой HDL-код, который не прослеживается до модели. Они предоставляются в процессе концептуального проекта.

5.3.1 (3) ─ Пропуски и ошибки требования предоставляются соответствующему процессу для разрешения

Совместное моделирование с использованием HDL Verifier может выявить пропуски или ошибки в концептуальном проекте. Они предоставляются в процессе концептуального проекта.

5.4.1 (1) ─ Создаётся оборудование, который реализует рабочий проект оборудования с использованием демонстрационных производственных процессов

То же, что и для традиционных проектов.

5.4.1 (2) ─ Реализация, сборка и установка Данных пункта Оборудования завершена

То же, что и для традиционных проектов.

5.4.1 (3) ─ Производные требования возвращаются к рабочему проекту или другому соответствующему процессу

То же, что и для традиционных проектов.

5.4.1 (4) ─ пропуски и ошибки требований предоставляются соответствующему процессу для разрешения

То же, что и для традиционных проектов.

5.5.1 (1) ─ Устанавливается базовый уровень, включающий все проектные и производственные данные, необходимые для поддержки последовательной репликации аппаратного элемента

То же, что и для традиционных проектов.

5.5.1 (2) ─ Требования к изготовлению, связанные с безопасностью, определены и документированы, и установлен производственный контроль

То же, что и для традиционных проектов.

5.5.1 (3) ─ Производные требования возвращаются к реализации или другому соответствующему процессу

То же, что и для традиционных проектов.

5.5.1 (4) ─ пропуски и ошибки требований предоставляются соответствующему процессу для разрешения

То же, что и для традиционных проектов.