Аппаратный процесс проектирования

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

Таблица 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, B Simulink, Stateflow®, Fixed-Point Designer™, Simulink Report Generator™, Simulink Requirements
5Выведенные произведенные требования возвращены к сбору требований или другому соответствующему процессу.5.2.1(2)A, B Simulink, Stateflow, Fixed-Point Designer, Simulink Report Generator, Simulink Requirements
6Пропуск требования и ошибки предоставляются соответствующему процессу для разрешения.5.2.1(3)A, B Simulink, 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, чтобы сгенерировать отчет Требований, который обеспечивает требования в PDF, HTML или Microsoft® форматы Word.

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

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

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

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

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

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

Можно использовать Simulink Report Generator, чтобы сгенерировать отчет Описания Разработки системы, который предоставляет проект в 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) ─ пропуск требования и ошибки предоставляются соответствующему процессу для разрешения

Co-симуляция с помощью 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) ─ пропуск требования и ошибки предоставляются соответствующему процессу для разрешения

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