exponenta event banner

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

В следующей таблице содержится сводная информация о задачах проектирования оборудования из DO-254. В таблице также описаны доступные инструменты конструирования на основе модели для достижения поставленных целей.

Таблица A-2: Задачи процесса проектирования аппаратных средств

 ЦельСправочные разделыУровни гарантииДоступные продукты для конструирования на основе моделей
1Определение, определение и документирование требований5.1.1(1)A, B, C, D Simulink ® Requirements™
2Полученные потребности возвращаются в соответствующий процесс. 5.1.1(2)A, B, C, D Требования к симуляторам
3Пропуски и ошибки требований предусмотрены для соответствующего процесса разрешения. 5.1.1(3)A, B, C, D Требования к симуляторам
4Концептуальный проект изделия разработан и соответствует его требованиям.5.2.1(1)A, BSimulink, Stateflow ®, Designer™ с фиксированной точкой, отчет Simulink Generator™, требования к Simulink
5Полученные потребности возвращаются к улавливанию потребностей или другому соответствующему процессу.5.2.1(2)A, BSimulink, Stateflow, конструктор фиксированных точек, генератор отчетов Simulink, требования к Simulink
6Пропуски и ошибки требований предусмотрены для соответствующего процесса разрешения.5.2.1(3)A, BSimulink, Stateflow, Simulink Coverage™
7Детальный проект разработан на основе требований к аппаратным средствам и концептуальных проектных данных.5.3.1(1)A, B, C, D Coder™ ЛПВП
8Производные требования возвращаются в концептуальный проект или другой соответствующий процесс.5.3.1(2)A, B, C, D Кодер HDL
9Пропуски и ошибки требований предусмотрены для соответствующего процесса разрешения.5.3.1(3)A, B, C, DКодер ЛПВП, ЛПВП 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) ─ Концептуальное проектирование оборудования разработано и соответствует его требованиям

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

Генератор отчетов Simulink можно использовать для создания отчета «Описание системного проекта», который предоставляет проект в форматах PDF, HTML, Microsoft Word или PowerPoint ® .

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

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

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

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

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

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

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

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