Prozessbeschreibung

PB-EN-31
Process description Seite 1 von 34
Page 1 of 34
Ausgabe
Hardware Entwicklungs-Prozess-Abläufe 1, 04.09.2009
Issue
Ausgabe
Hardware Development-Process-Workflows 9, 07.12.2022
Issue

Inhaltsverzeichnis Seite Table of Contents Page

1 Prozesssteckbrief 3 1 Process Summary 3

2 Hardware Entwicklungs-Prozess-Abläufe 5 2 Hardware Development-Process-Workflows 5
2.1 Hardware Design Life Cycle Prozesse 5 2.1 Hardware Design Life Cycle Processes 5
2.2 Transitions Kriterien zwischen Prozessen 8 2.2 Transition Criteria between Processes 8
2.3 Rollen im Hardware Design Life Cycle 9 2.3 Roles of the Hardware Design Life Cycle 9
2.4 Aufbau der Prozessbeschreibung 9 2.4 Structure of the process description 9
2.4.1 COTS Management 10 2.4.1 COTS Management 10
2.4.2 Security Management & Development 11 2.4.2 Security Management & Development 11
2.5 Begriffsdefinition 12 2.5 Definition of Terms 12
3 Prozessflussdiagramm des Hardware Life Cycle 12 3 Process Flow of Hardware Life Cycle 12
3.1 Prozessflussdiagramm für den Implementer 12 3.1 Workflow Diagram for the Implementer 12
3.2 Prozessflussdiagramm für den Verifier 14 3.2 Workflow Diagram for the Verifier 14
3.3 Prozessflussdiagramm für den CM 15 3.3 Workflow Diagram for the CM 15
3.4 Prozessflussdiagramm für die PA 16 3.4 Workflow Diagram for the PA 16
3.5 Angewendete Werkzeuge 17 3.5 Utilized Tools 17
4 Prozessabläufe im Hardware Design Life Cycle 18 4 Process flow of Hardware Design Life Cycle 18
4.1 Hardware Planungs Prozess 18 4.1 Hardware Planning Process 18
4.2 Hardware Design Prozesse 19 4.2 Hardware Design Processes 19
4.2.1 Requirements Capture Prozess 19 4.2.1 Requirements Capture Process 19
4.2.2 Conceptual Design Prozess 20 4.2.2 Conceptual Design Process 20
4.2.3 Detailed Design Prozess 21 4.2.3 Detailed Design Process 21
4.2.4 Prototype Development 22 4.2.4 Prototype Development 22
4.2.5 Production Transition Prozess 23 4.2.5 Production Transition Process 23
4.3 Unterstützende Prozesse 24 4.3 Supporting Processes 24
4.3.1 Validation and Verification Prozess 24 4.3.1 Validation and Verification Process 24
4.3.1.1 Validation of Requirements Capture 25 4.3.1.1 Validation of Requirements Capture 25
4.3.1.2 Validation and Verification of Conceptual 4.3.1.2 Validation and Verification of Conceptual
Design 26 Design 26
4.3.1.3 Validation and Verification of Detailed Design 26 4.3.1.3 Validation and Verification of Detailed Design 26
4.3.1.4 Verification of Prototype Development 27 4.3.1.4 Verification of Prototype Development 27
4.3.1.5 Verification of Production Transition 27 4.3.1.5 Verification of Production Transition 27
4.3.2 Configuration Management Prozess 28 4.3.2 Configuration Management Process 28
4.3.3 Process Assurance 29 4.3.3 Process Assurance 29
4.3.4 Certification Liaison Prozess 30 4.3.4 Certification Liaison Process 30
5 Mitgeltende Unterlagen 32 5 Associated Documents 32
6 Änderungsverzeichnis 33 6 Record of Revision 33
 Hardware Entwicklungs-Prozess-Abläufe
PB-EN-31
Seite 2 von 34
Hardware Development-Process-Workflows Page 2 of 34
Ausgabe
9, 07.12.2022
Issue
Signed by:Andrew Siems - SIG Signed by:Eckhard Roeske - SIG
Signed at:2022-12-14 14:33:42 +01:00 Signed at:2022-12-14 17:33:34 +01:00
Reason:I am the Author Reason:I approve this document

Erstellt: Geprüft:
Prepared: Checked:
Andrew SIEMS Eckhard ROESKE
Engineering
Signed by:AndrewSupport
Siems - SIG Engineering
Signed at:2022-12-15 09:00:29 +01:00
Reason:Formal Approval (DPM)

Freigegeben:
Approved:
Andrew SIEMS
Engineering Support
 Hardware Entwicklungs-Prozess-Abläufe
PB-EN-31
Seite 3 von 34
Hardware Development-Process-Workflows Page 3 of 34
Ausgabe
9, 07.12.2022
Issue

1 Prozesssteckbrief 1 Process Summary

Prozessinput Prozessinhalt Prozessoutput

Process input Process content Process output

 SoW, Spezifikation auf
System / Equipment Le-
vel
 Normen/Standards:1
DO-254, CRIs, IPs,
CS, FARs, JARs,
ABD0100, PB-EN-60,
PB-EN-61, PB-EN-62,
PB-EN-30, PV-EN-63,
PV-EN-02, COTS-MP,
SMDP
Dieses Dokument beschreibt die Funktionen und Ab-  Hardware Design Life
läufe bei der Entwicklung von Hardwareprodukten (inkl. Cycle Data gemäß
der Complex Components) bestehend aus Hardware DO-254, ABD0100,
Design Life Cycle Data und der Hardware im Bereich COTS-MP, SMDP
Airbus BUX Engineering.  Hardware
 Review-Reports
gemäß ABD0100/
PB-EN-60

 SoW, Specification on
System / Equipment
Level
 Normen/Standards:1
DO-254, CRIs, IPs,
CS, FARs, JARs,
ABD0100, PB-EN-60,
PB-EN-61, PB-EN-62,
PB-EN-30, PV-EN-63,
PV-EN-02, COTS-MP,
SMDP
This document describes the functions and processes in  Hardware Life Cycle
order to develop hardware products (incl. complex com- Data according to
ponents) consisting of Hardware Design Life Cycle Data DO-254, ABD0100,
and the hardware item within Airbus BUX Engineering. COTS-MP, SMDP
 Hardware item
 Review Reports ac-
cording to ABD0100 /
PB-EN-60

1 Über das projektspezifische SoW können noch zusätzliche Normen und Standards definiert sein (z.B. DO-160).
Project specific SoW may define additional norms and standards being applicable (e.g. DO-160).
 Hardware Entwicklungs-Prozess-Abläufe
PB-EN-31
Seite 4 von 34
Hardware Development-Process-Workflows Page 4 of 34
Ausgabe
9, 07.12.2022
Issue

Lieferanten des Geltungsbereich  Engineering Kunden des

Prozesses Applicability Prozesses
 Engineering
Suppliers of the Customers of the
process process
 interne Fachbereiche Interessens-  Prozesseigner  interne Fachbereiche
 externe Fachbereiche Gruppen  Prozessbeteiligte  externe Fachbereiche
 externer Kunde  externer Kunde

 internal Departments Stakeholders  Process Owner  internal Departments

 external Departments  Process Operator  external Departments
 external Customer  external Customer

Prozesseigner  Leiter Engineering

Process Owner  Head of Engineering

Für Begriffe und Abkürzungen siehe Abkürzungsverzeichnis.

For terms and abbreviations see list of abbreviations.

Der Begriff Process Assurance (PA), der im Zusammenhang mit den Hardware-Life-Cycle Prozessen verwandt wird,
wird analog zum Begriff Quality Assurance (QA) genutzt.
The term Process Assurance (PA) that is used within the context of hardware life cycle processes is used in analogy
with the term Quality Assurance (QA).
 Hardware Entwicklungs-Prozess-Abläufe
Hardware Development-Process-Workflows
2 Hardware Entwicklungs-Prozess-Abläufe
Der in dieser Prozessbeschreibung dokumentierte
Hardware Design Life Cycle basiert auf der ABD0100
und der DO-254 und ist gültig für die Entwicklung der
Hardwareprodukte mit Hardware Design Assurance
Level B bis E.
2.1 Hardware Design Life Cycle Prozesse
Hardware Planungs Prozess
Der Hardware Planungs-Prozess definiert und koordi-
niert die Aktivitäten des Hardware Designs und der un-
terstützenden Prozesses eines Projektes.
Hardware Design Prozesse
Die Hardware Design Prozesse generieren die Design
Daten und die resultierende Hardware. Die Hardware
Design Prozesse bestehen aus den folgenden Sub-
Prozessen:
 Requirements Capture Prozess (4.2.1)
 Conceptual Design Prozess (4.2.2)
 Detailed Design Prozess (4.2.3)
 Protototype Development (4.2.4)
 Production Transition Prozess (4.2.5)
Unterstützende Prozesse
Die unterstützenden Prozesse produzieren die
Hardware Design Life Cycle Daten, die die Korrektheit
und die Kontrolle des Hardware Design Life Cycles
und seiner Outputs sicherstellen. Die unterstützenden
Prozesse werden parallel zum Planungs- und zu den
Design Prozessen ausgeführt.
Folgende unterstützenden Prozesse sind definiert:
 Validation and Verification Prozess (4.3.1)
 Configuration Management Prozess (4.3.2)
 Process Assurance (4.3.3)
 Certification Liaision Prozess (4.3.4)
Die folgende Abbildung zeigt eine Übersicht über die
Hardware Design Life Cycle Prozesse und der inte-
grierten Dokumentation. Die roten Nummern geben
das Referenzkapitel zur DO-254 an, welches den Pro-
zess- respektive den Dokumenteninhalt beschreibt.
PB-EN-31
Seite 5 von 34
Page 5 of 34
Ausgabe
9, 07.12.2022
Issue
2 Hardware Development-Process-Workflows
This process description documents the hardware de-
sign life cycle based on the ABD0100 and the DO-254
and is valid for development of hardware products with
hardware design assurance level B to E.
2.1 Hardware Design Life Cycle Processes
Hardware Planning Process
The hardware Planning process defines and coordi-
nates the activities of the hardware design and support-
ing processes for a project.
Hardware Design Processes
The hardware design processes generate the design
data and resultant hardware item.
The hardware design processes consist of the following
sub processes:
 Requirements Capture Process (4.2.1)
 Conceptual Design Process (4.2.2)
 Detailed Design Process (4.2.3)
 Prototype Development (4.2.4)
 Production Transition Process (4.2.5)
Supporting Processes
The supporting processes produce the hardware design
life cycle data that assures the correctness and control
of the hardware design life cycle and its outputs. The
supporting processes are performed concurrently with
the planning and design processes.
Following supporting processes are defined:
 Validation and Verification Process (4.3.1)
 Configuration Management Process (4.3.2)
 Process Assurance (4.3.3)
 Certification Liaison Process (4.3.4)
The following figure depicts an overview of the hard-
ware design life cycle processes and their associated
data. The red numbers indicate the reference chapter of
DO-254 where the process respective data content is
described.
 Hardware Entwicklungs-Prozess-Abläufe
PB-EN-31
Seite 6 von 34
Hardware Development-Process-Workflows Page 6 of 34
Ausgabe
9, 07.12.2022
Issue

System Life Cycle

Processes
5.0
Hardware Design Processes
6.0, 7.0
8.0, 9.0
Supporting Processes

Figure 1: Overview Hardware Design Life Cycle Processes and Data

 Hardware Entwicklungs-Prozess-Abläufe
Hardware Development-Process-Workflows
COTS Management Prozess
Im Falle der Verwendung von COTS (Commercial of
the Shelf) Produkten kommt der COTS Management
Prozess zur Anwendung.
Der COTS Management Prozess definiert den Life
Cycle Prozess und die Daten für das COTS Manage-
ment über den kompletten A/C Lebenszyklus. Das be-
inhaltet die COTS Verifikation, Bewertung und Aus-
wahl, Sicherheit, Beschaffung, Integration und Konfi-
gurations-Management, Wartung und Support, orga-
nisatorische Verantwortlichkeiten nebst Berechtigun-
gen, Risiko Management und die Identifikation von Ar-
tefakten zur Unterstützung des COTS Management.
Der COTS Management Prozess ist im COTS Ma-
nagement Plan (COTS-MP) beschrieben und gilt nur
für Software und Firmware (HDL) Code) embedded
COTS, integrierte COTS Anteile und die zugehörigen
Entwicklungs-Tools. Reine Hardware Komponenten
wie Widerstände oder Prozessoren, ASIC, FPGA und
andere elektronisch programmierbare Hardware, die
nicht als Firmware anzusehen ist, wird in diesem Pro-
zess nicht betrachtet. Zum Beispiel existieren keine
rechtlich relevanten Gesichtspunkten und Punkte zur
Datensicherheit, die nur eine marginale Bedrohung
darstellen.
Anmerkung: Für reine Hardwarekomponenten gilt die PV-
EN-02 bezüglich der Komponentenfreigabe und
Obsoleszenz Betrachtungen bzw. der jeweils gültige
Electronic Components Management Plan (ECMP).
Der COTS-MP gilt dann zusätzlich zu diesem Doku-
ment.
Security Management & Development Prozess
Der Security Management und Development Prozess
kommt in dem Falle zur Anwendung, in dem das
projekt- / produkt-spezifische Statement of Work
(SoW) die Verwendung der Security Assurance
Requirements (SAR) vorschreibt.
Der Security Management und Development Prozess
definiert den Life Cycle Prozess und die sogenannten
Projekt Assets für ein Security Management über den
kompletten A/C Lebenszyklus, um das Produkt ent-
sprechend des geforderten Security Assurance Level
(SAL) zu entwickeln. Das beinhaltet:
PB-EN-31
Seite 7 von 34
Page 7 of 34
Ausgabe
9, 07.12.2022
Issue
COTS Management Process
In the case of COTS (Commercial of the Shelf) product
usage the COTS management process becomes appli-
cable.
The COTS management process defines the process
life cycle and data for COTS management during the
A/C life cycle. That includes COTS verification, evalua-
tion and selection, security, acquisition, integration and
configuration management, maintenance and support,
organizational responsibilities, accountability and au-
thority, risk management and identification of artefacts
to support COTS management.
The COTS management process is described in the
COTS Management Plan (COTS-MP), applicable for all
software and firmware (HDL Code) embedded COTS,
integrated COTS devices and their development tools,
only. Pure hardware components like resistors or pro-
cessors, ASIC, FPGA and other electronically program-
mable hardware, that are not considered as firmware,
are out of scope of this process. For instance, they have
no legal issues and security issues with marginal threat
level in the security world.
Note: For pure hardware components consider the PV-EN-02
for component release and notification of obsolescence re-
spective the applicable Equipment Component Management
Plan (ECMP).
The COTS-MP shall be considered in addition to this
document.
Security Management & Development Process
In case of the project / product specific Statement of
Work (SoW) declares the application of Security Assur-
ance Requirements (SAR), the Security management
and development process becomes applicable.
The Security management and development process
defines the process life cycle and project assets for se-
curity management during the A/C life cycle in order to
develop the product with the Security Assurance Level
(SAL) required, including:
 Hardware Entwicklungs-Prozess-Abläufe
Hardware Development-Process-Workflows
 eine Beschreibung der Security Organisation auf
Unternehmensbereichs- und Projektlevel
 eine Beschreibung der Security Infrastruktur auf
Unternehmensbereichs- und Projektlevel
 eine Liste der Security Projekt Assets des Produk-
tes; inkl. Spezifikation, Designs & Implementie-
rung, Verifikation, Validierung und Evaluierungsda-
ten, Leitlinien und deren Verfügbarkeit zu den Re-
view
 eine Development Tool Analyse; inkl. des Konfigu-
rationsmanagements
 eine COTS Analyse
 eine Definition des Life Cycle Models; inkl. einer
Konformitätserklärung, wie Security berücksichtigt
wird, um konform zu dem für das Produkt geforder-
ten SAL zu sein
 Gesetzes- und Regulierungsinformation
 Security Vulnerability Analyse; inkl. Security
Kontrollprozeduren
Der Security Management und Development Prozess
ist im Security Management und Development Plan
(SMDP) beschrieben.
Der SMDP gilt zusätzlich zu diesem Dokument.
Exportkontrolle Prozess
Im Fall von Exportvorhaben wie
 Voranfragen, Angebotsanforderungen
 Kooperations- oder Lizenzvorhaben
 Ausfuhr/Verbringung von Daten
im Sinne der PB-IM-06, ist der Projektleiter vorab zu
informieren und der Prozess der Exportkontrolle
gemäß PB-IM-06 zu berücksichtigen.
2.2 Transitions-Kriterien zwischen Prozessen
Jeder Hardware Design Life Cycle Prozess führt Akti-
vitäten auf Inputs aus, um einen Output zu produzie-
ren.
Transitions-Kriterien werden verwendet, um zu
beschreiben, ob in einen Prozess eingetreten oder
wieder eingetreten respektive ob ein Prozess
abgeschlossen werden kann.
Die Transitions-Kriterien für den Prozess-Einstieg o-
der -Wiedereinstieg sind erfüllt, wenn die Verfügbar-
keit der genehmigten und autorisierten Prozess-Inputs
besteht.
PB-EN-31
Seite 8 von 34
Page 8 of 34
Ausgabe
9, 07.12.2022
Issue
 a description of the security organization at corpo-
rate and project levels
 a description of the security infrastructure at corpo-
rate and project levels
 a list of all security project assets of the product; incl.
specification, design & implementation, verification,
validation and evaluation data, guidance documents
and its availability for reviews
 a development tool analysis; incl. configuration man-
agement
 a COTS analysis
 a definition of the life-cycle model; incl. a conform-
ance claims rationale how to take the security into
account in order being compliant with the required
SAL for the product
 laws and regulation information,
 Security Vulnerability Analysis; incl. security survey
procedure
The Security management and development process is
described in the Security Management and Develop-
ment Plan (SMDP).
The SMDP shall be considered in addition to this docu-
ment.
Export control process
In case of exporting plans like
 advance inquiries, quotation requests
 cooperation- or licensing projects
 export/ transfer of data
in meaning of PB-IM-06, the project leader should be
informed previously and the export control process
should be taken into account according to PB-IM-06.
2.2 Transition Criteria between Processes
Each hardware design life cycle process performs ac-
tivities on inputs to produce outputs.
Transition criteria are used to determine whether a pro-
cess may be entered or re-entered respective may be
completed.
The transition criteria for the entering or re-entering of a
process are satisfied if the approved and authorized
process-inputs are available.
 Hardware Entwicklungs-Prozess-Abläufe
Hardware Development-Process-Workflows
Der Input eines Prozesses braucht dabei nicht voll-
ständig zu sein bevor der Prozess initiiert werden
kann, wenn die für diesen Prozess eingeführten Tran-
sitions-Kriterien erfüllt sind.
Wenn ein Prozess auf unvollständigen Input agiert,
muss für nachträglichen Input des Prozesses eine
Prüfung erfolgen, um zu bestimmen, ob vorheriger
Output des Prozesses weiterhin gültig ist.
Die Transitions-Kriterien für den Prozessabschluss
sind erfüllt, wenn die Zielsetzungen des Prozesses
und die damit verbundenen Zielsetzungen der unter-
stützenden Prozesse erfüllt sind. Die Bestätigung er-
folgt durch den erfolgreichen Abschluss des zugehöri-
gen Reviews / Quality Gates im Status „grün“ oder
„gelb“ gemäß QG Ampelsteuerung der PB-EN-60.
Anmerkung: Die Transitions-Kriterien sind für jeden Design
Life Cycle Prozess detailliert im Kapitel 4 aufgeführt.
2.3 Rollen im Hardware Design Life Cycle
Die Aufgaben und Ziele der oben aufgeführten Pro-
zesse werden den folgenden vier Rollen zugeordnet:
 Implementer
 Verifier
 Configuration Manager (CM)
 Process Assurance (PA, durch PQR)
(Der Begriff Process Assurance (PA), der im Zusam-
menhang mit den Hardware-Design-Life-Cycle-Pro-
zessen verwandt wird, wird analog zum Begriff Quality
Assurance (QA) genutzt. In diesem Zusammenhang
werden die Aktivitäten zur PA durch die Product Qua-
lity Responsible ausgeführt.)
Die Rolleninhaber sind für die Erreichung der zugeord-
neten Ziele verantwortlich. Die Rollen sind im Detail in
der PB-EN-60 beschrieben.
2.4 Aufbau der Prozessbeschreibung
Für jede Rolle ist ein eigener Prozessablauf beschrie-
ben, der die jeweiligen Zusammenhänge zwischen
den Inputs / Outputs und den Aktivitäten pro Prozess-
schritt darstellt; wobei die Beschreibung der Aktivitä-
ten lediglich eine Übersicht umfasst. Der volle Umfang
der Aktivitäten ist den angegebenen Referenzen zu
entnehmen.
Des Weiteren hängen die tatsächlich durchzuführen-
den Aktivitäten und die zu generierenden Outputs
maßgeblich vom anzuwendenden Hardware Design
PB-EN-31
Seite 9 von 34
Page 9 of 34
Ausgabe
9, 07.12.2022
Issue
Considering that the input to a process need not be
complete before that process can be initiated, if the tran-
sition criteria established for the process are satisfied.
If a process acts on partial inputs, subsequent inputs to
the process have to be examined to determine that the
previous outputs of the process are still valid.
The transition criteria for the process completion are
satisfied if the objectives of this process and the objec-
tives of the integral processes associated with it are
completed and satisfied, too. The compliance is shown
by successfully completion of the related review / quality
gate in status “green” or “amber” according to QG traffic
light control of PB-EN-60.
Note: The transition criteria’s for each design life cycle
process are listed in detail in chapter 4
2.3 Roles of the Hardware Design Life Cycle
The activities and objectives of the processes specified
above are assigned to the following four roles:
 Implementer
 Verifier
 Configuration manager (CM)
 Process Assurance (PA, by PQR)
(The term Process Assurance (PA) that is used within
the context of hardware design life cycle processes is
used in analogy with the term Quality Assurance (QA).
In this context the activities for PA are performed by the
Product Quality Responsible.)
The role holders are responsible for attainability of their
purposes. The roles are described in detail in PB-EN-
60.
2.4 Structure of the process description
For each role its own workflow is described, that repre-
sents the respective coherences between the inputs/
outputs and the activities per process step; considering
that the description of the activities comprises just an
overview. The details of all activities are described in
the given references.
Further the actual activities to be performed and outputs
to be generated depend on the applicable Hardware
Design Assurance Level. This dependencies can be
 Hardware Entwicklungs-Prozess-Abläufe
Hardware Development-Process-Workflows
Assurance Level ab. Diese Abhängigkeit ist den refe-
renzierten Normen & Standards, den Input Data res-
pektive der der Workflow Spalte „Applicability by HW
Design Assurance Level“ unter Berücksichtigung der
Präzedenz zu entnehmen. Dabei übersteuert das je-
weils speziellere Dokument das Allgemeinere, wobei
davon auszugehen ist, dass die spezielleren Vorga-
ben keinen direkten Widerspruch zu den allgemeine-
ren darstellen. Letztendlich gilt für ein spezifisches
Projekt die Prozessdefinition in den anzuwendenden
Hardware Plänen und Standards.
Folgende Hierarchisierung vom Speziellen zum Allge-
meinen gilt:
1. Projektspezifische Prozessdefinition (Hardware
Pläne und Standards)
2. Buxtehude interne allgemeine Prozessdefinition
(PBs, Templates)
3. Spezifikationen (SoW, Spezifikation auf
Equipment Level)
4. Airbus Direktiven (ABD0100)
5. Internationale Standards (DO-254, CRIs, etc.)
Alle vier Workflows sind in den Kapiteln 3.1 bis 3.4 dar-
gestellt und werden in den nachstehenden Kapiteln
vertieft behandelt. Die einzelnen Prozessabläufe sind
über die Prozessschrittnummern respektive den Qua-
lity Gates / Reviews synchronisiert.
Die Synchronisation zum Equipment Entwicklungs-
Prozess-Ablauf gemäß PB-EN-30, ist aus Gründen
der Redundanzvermeidung nur im Prozessflussdia-
gramm für den Implementer integriert.
Die Prozessfluss-Synchronisationen erfolgen jeweils
über die Prozessschrittnummern.
Die in der Spalte „Applicability by HW Design
Assurance Level“ mit „*“ gekennzeichneten Angaben
können projektspezifisch angepasst werden, falls die
Erstellung dieser Daten als nicht erforderlich
angesehen wird.
2.4.1 COTS Management
Der COTS Management Plan (COTS-MP) berücksich-
tig bereits alle Aspekte des COTS Management Pro-
zesses im Sinne von Normen & Standards, Eingangs-
daten, Prozessschritte, Aktivitäten, Ausgangsdaten,
DAL Abhängigkeit und Tools. Um Redundanzen zu
vermeiden, finden diese keine erneute Abbildung in
der Prozessbeschreibung dieses Dokumentes. Ledig-
PB-EN-31
Seite 10 von 34
Page 10 of 34
Ausgabe
9, 07.12.2022
Issue
found in the referenced norms & standards, input data
respective the workflow column „Applicability by HW
Design Assurance Level“ considering the precedence in
the meaning, that the more specific document overrules
the general.
Thereby, it shall be taken into account that the more
specific rules do not conflict with the general ones. Fi-
nally, the process definition of applicable hardware
plans and standards applies for a specific project.
The following hierarchical structure, from specific to
general, applies:
1. Project specific process definition (hardware plans
and standards)
2. Buxtehude internal general process definition
(PBs, templates)
3. Specifications (SoW, specification on equipment
level)
4. Airbus directives (ABD0100)
5. International standards (DO-254, CRIs, etc.)
All four workflows are represented in the chapters 3.1 to
3.4 and are dependently discussed in the following
chapters. The single workflows are synchronized by
process step numbers respectively by the quality gates/
reviews.
The synchronization with Equipment-Process-Workflow
according to PB-EN-30, is only integrated into the work-
flow diagram for the implementer due to avoidance of
redundancy.
In any cases the workflows are synchronized by pro-
cess step numbers.
Values marked by “*” within the column “Applicability by
HW Design Assurance Level” may project specifically
adapted in case the generation of these data is judged
to be not applicable.
2.4.1 COTS Management
Since, the COTS Management Plan (COTS-MP) al-
ready considers all aspects of the COTS management
process in terms of norm & standards, input data, pro-
cess steps, activities, output data, DAL application and
tools they are not duplicated into the process descrip-
tion of this document to avoid redundancies.Just the
way of application of the COTS-MP is addressed in the
hardware planning process (see process step (1) of
 Hardware Entwicklungs-Prozess-Abläufe
Hardware Development-Process-Workflows
lich das Vorgehen zur Anwendung / Gültigkeitserklä-
rung des COTS-MP ist im Hardware Planungs-Pro-
zess adressiert (siehe Prozessschritt (1) des Prozess-
flussdiagramm für den Implementer, Kapitel 3.1).
Um dennoch die Anwendung des COTS-MP kenntlich
zu machen, ist dieser in den „Input Data“ aller betroffe-
nen Prozessschritte eines jeden Prozessflussdia-
grams aufgeführt.
2.4.2 Security Management & Development
Der Security Management und Development Plan
(SMDP) berücksichtig bereits alle Aspekte des
Security Management und Development Prozesses im
Sinne von Normen & Standards, Eingangsdaten, Pro-
zessschritte, Aktivitäten, Ausgangsdaten, Security As-
surance Level (SAL) Abhängigkeit und Tools. Um Re-
dundanzen zu vermeiden, finden diese keine erneute
Abbildung in der Prozessbeschreibung dieses Doku-
mentes. Lediglich das Vorgehen zur Anwendung / Gül-
tigkeitserklärung des SMDP ist im Hardware Pla-
nungs-Prozess adressiert (siehe Prozessschritt (1)
des Prozessflussdiagramm für den Implementer, Ka-
pitel 3.1).
Um dennoch die Anwendung des SMDP kenntlich zu
machen, ist dieser in den „Input Data“ aller betroffenen
Prozessschritte eines jeden Prozessflussdiagrams
aufgeführt.
PB-EN-31
Seite 11 von 34
Page 11 of 34
Ausgabe
9, 07.12.2022
Issue
Workflow Diagram for the Implementer, chapter 3.1).
Nevertheless, in order to indicate the application of the
COTS-MP, it is listed as “Input Data” for every applica-
ble process step of any workflow diagram.
2.4.2 Security Management & Development
Since, the Security Management and Development
Plan (SMDP) already considers all aspects of the Secu-
rity management and development process in terms of
norm & standards, input data, process steps, activities,
output data, Security Assurance Level (SAL) application
and tools they are not duplicated into the process de-
scription of this document to avoid redundancies. Just
the way of application of the SMDP is addressed in the
hardware planning process (see process step (1) of
Workflow Diagram for the Implementer, chapter 3.1).
Nevertheless, in order to indicate the application of the
SMDP, it is listed as “Input Data” for every applicable
process step of any workflow diagram.
 Hardware Entwicklungs-Prozess-Abläufe
PB-EN-31
Seite 12 von 34
Hardware Development-Process-Workflows Page 12 of 34
Ausgabe
9, 07.12.2022
Issue

3 Prozessflussdiagramm des Hardware Life Cycle 3 Process Flow of Hardware Life Cycle

3.1 Prozessflussdiagramm für den Implementer 3.1 Workflow Diagram for the Implementer

2.5 Begriffsdefinition 2.5 Definition of Terms

1. Traceable Requirements 1. Traceable Requirements

a. Copied Requirements
Anforderungen, die direkt auf höher gelagerte
Anforderungen zurückverfolgt werden können
und von diesen (nahezu vollständig) kopiert
wurden.
b. Refined Requirement
Anforderungen, die direkt auf höher gelagerte
Anforderungen zurückverfolgt werden können
und teilweise verändert, verfeinert oder zur
Abdeckung von Teilaspekten der
referenzierten, höher gelagerten Anforderung
dienen.
2. Derived Requirements
Anforderungen, die nicht direkt zu höher gelager-
ten Anforderungen zurückverfolgt werden kön-
nen, sondern auf Grund von Design-oder Umset-
zungs- Entscheidungen , wie die Wahl der Archi-
tektur, der Technologie, die grundsätzliche und
zusätzliche Funktionalität, die Umgebungsbedin-
gungen, die Leistung oder sicherheitsbezogenen
Abschätzungen eingeführt werden.
a. Copied Requirements
Requirements, directly traceable to require-
ments from higher level requirements that are
(nearly completely) copied from these.
b. Refined Requirements
Requirements directly traceable to require-
ments from higher level requirements that are
partly modified, refined or serve to satisfy partial
aspects of those higher level requirements they
refer to.
2. Derived Requirement
Requirements not directly traceable to to require-
ments from higher level requirements that have
been introduced due to design- or implementation
decisions that are imposed by the architecture,
choice of technology, basic and additional func-
tionality, environmental conditions, performance or
safety related assessments.
 Hardware Entwicklungs-Prozess-Abläufe
PB-EN-31
Seite 13 von 34
Hardware Development-Process-Workflows Page 13 of 34
Ausgabe
9, 07.12.2022
Issue

Applicability by
No. Norms & Standards Input Data Process Steps Activities HW D esign Output Data Tool
Assurance Level
HARDWARE WORKFLOW - PLANNING PROCESS (Design)
Specifications: SoW/Spec. on System level / PB-EN-30 (1) Planning Process (DO-254: 4.0):
SES Means of Compliance and Planning (DO-254: 9.1)
Electronic Parts Requirements (ABD 0100) B, C, D, E - PHAC
Plans: ECMP, COTS-MP, SMDP
Planning Process - Produce Plan for Hardware Aspects of Certification (PHAC)
Standards: --
for revi ew and agreement by certification authority
DO-254 Templates: - Produce Hardware Design Plan (part of PHAC)
2.0,4.0,9.0,10.1.1, 10.1.2, 10.2.1, PHAC (ETemp-067), - Define applicabili ty of Electronic Component Management Plan (ECMP)
10.2.2,10.2.3, 10.2.4, 11.0, App. A HRS (ETemp-065), - Define applicabili ty of COTS-MP (in Case of COTS usage)
HDS (ETemp-063), - Define applicabili ty for SM DP (in case of availability of Security Assurance Requi rements (SAR))
CRI’s, FARs, JARs - Produce Hardware Requirements Standards (HRS) CHT,
Data: -- B, C*, D*, E* - HRS
(1) M/PR (CEH) - Produce Hardware Design Standards (HDS)
Quality Gate/Review: PB-EN-30 (1) Note: - HDS CMT,
ABD0100.2.11
ABD0100 M/PR (ETemp-101) In case of COTS usage consider the explanation in chapter 2.1 and 2.4.1 DOT
PR (Ch. 5.2)
In case of Applicabi lity of SMDP in accordance with SoW consider the expl anation in chapter 2.1 and 2.4.2
PB-EN-30, PB-EN-60, PB-EN-61,
Complex Compon ents Planning Process (ABD0100.2.11-4.3, 5.2): B, C, D, E - input for PHAC
PB-EN-62, PV-EN-02
NO GO - Produce contributi on for Plan for Hardware Aspects of Certification related to Complex Components
- Produce Hardware Requirements Standards (HRS) for C om plex Com ponents
NO GO - Produce Hardware Design Standards (HDS) for C omplex Components
B, C*, D*, E* - HRS
Note: The performance of a M/PR is only done for Complex Components, in all other case the revi ew activities are - HDS
covered by PB-EN-30 to merge equipment and hardware development data wherever possible.

HARDWARE WORKFLOW - DESIGN Capture

Requirements PROCESS (DO-254: 5.1):
DO-254 - Produce Hardware Requirements Data (HRD)
Specifications: SoW/Spec. on System level / PB-EN-30 (2.3)
5.1, 10.3.1, App. A to identify, define and document the hardware requirements including B, C, D, E - HRD
SES requirements from preliminary safety assessment and derived requirements CHT,
CRI’s, FARs, JARs Plans: PHAC, ECMP, COTS-MP, SMDP
ABD0100 CMT,
(2) Standards: HRS Requirements Capture DOT,
Templates: HRD (ETemp-425) RMT
PB-EN-30, PB-EN-60, PB-EN-61, PB- Data: --
EN-62, PV-EN-02 Quality Gate/Review:--
DO-254 Specifications: SoW/Spec. on System level / Conceptual Design (DO-254: 5.2):
5.2,10.3.1, 10.3.2.1, App. A SES Conceptual Design - Produce Hardware Requirements Data (HRD) B, C, D, E - HRD
Plans: PHAC, ECMP, COTS-MP, SMDP to include derived requirements resulting from conceptual design activities - IFDs
CRI’s, FARs, JARs Standards: HRS, HDS - Produce Interface Document (IFD) to include Hardware/Software Interface Data
Templates: HRD (ETemp-425), CHT,
- Produce Hardware Design Data (HDD) to include Conceptual Design Data
ABD0100 IFD (ETemp-446), PB-EN-30 (2.3) B, C*, D*, E* - HDD CMT,
(3) NO GO DOT,
HDD (ETemp-532/12) CR (EQ)
PB-EN-30, PB-EN-60, PB-EN-61, Data: -- MOT,
PB-EN-62, PV-EN-02 Quality Gate/Review:-- RMT
Complex Components Design Process (ABD0100): B, C, D, E - HRD
PB-EN-30 (2.3) - Produce Hardware Requireme nts Data (HRD) for Complex Com ponents
NO GO
PDR
DO-254 Specifications: SES Detailed Design (DO-254: 5.3):
5.3,10.3.1, 10.3.2.2, App. A Plans: PHAC, ECMP, COTS-MP, SMDP - Produce Hardware Requirements Data (HRD) B, C, D, E - HRD
Standards: HRS, HDS PB-EN-30 (3) to include derived requirements resulting from detailed design activities - HDD
CRI’s, FARs, JARs Templates: - Produce Hardware Design Data (HDD) to include Detailed Design Data
HRD (ETemp-425), TCR (EQ)
PB-EN-30 (4.1)
ABD0100 HDD (ETemp-532), Electronic Parts Requirements (ABD 0100)
ECMR (Etemp-731), - Produce ECMP application data (part of HDD) not limited to
PB-EN-30, PB-EN-60, PB-EN-61, IFD (ETemp-446) Detailed Design • component quality level/or criteria
PB-EN-62, PV-EN-02 Data: HRD, IFDs, Conceptual Design Data • component derating rules and values
Quality Gate/Review: • new component qualification program and summary report
DR (PCB) (ETemp-014), - Produce Component temperature range selection (part of HDD)
CCRR (ETemp-102)
R&DR (ETemp-449) CHT,
DR (PCB) CCRR (CEH) CMT,
PB-EN-60 PB-EN-60 Complex Components Design Process (ABD0100): B, C, D, E - HRD DOT,
(4)
- Produce Produce Hardware Requirements Data (HRD) for Complex Components - HDD EDT,
to include derived requirements resulting from detailed design activities - ECMR MOT,
NO GO - IFD RMT
- Produce Hardware Design Data (HDD) for Complex Components
NO GO
- Produce Electronic Component Management Report (ECMR)
PB-EN-30 (4.1)
- Produce Interface Document (IFD) for Complex Components
DR (EQ) NO GO

Note: The performance of a CCRR and a R&DR is only done for Complex Components only.

R&DR
PB-EN-30 (4.1)
ABD0100.2.11
DDR (Ch. 5.3)

NO GO
DO-254 Specifications: SES NO GO Detailed Design (DO-254: 5.3): B, C, D, E - HDD
5.3,5.4,10.3.2.2,10.9, App. A Plans: PHAC, ECMP, COTS-MP, SMDP PB-EN-30 (4.2) - Produce Hardware Design Data (HDD) to include :
Standards: HDS • updates for Detailed Design Data
CRI’s, FARs, JARs Templates: ECN (via „Buddy“), • Top-Level Drawings
HDD (ETemp-532), Prototype Development • Assembly Drawings
ABD0100 HAS (ETemp-061) • Installation Drawings
Data: HRD, HDD
PB-EN-30, PB-EN-60, PB-EN-61, Quality Gate/Review: Electronic Parts Requirements (ABD 0100)
PB-EN-62, PV-EN-02 PtR (PCB (ETemp-015), - Produce Component temperature range selection (part of HDD)
CCITR (ETemp-103), PtR (PCB)
RDR (PCB)(ETemp-016), PB-EN-60
VR (ETemp-104) CCITR Implementation (DO-254: 5.4):
(CEH) Prototype Development:
- Produce input for manufacturing documents („Bauunterlage“ (BU) administered via ECN) B, C, D, E - ECN for BU
PB-EN-60 - Hw Prototype
PB-EN-30 (4.2) - Produce hardware prototype based on Hardware Design Data using representative CHT,
manufacturing processes CMT,
PtR (EQ)
DOT,
(5) EDT,
MOT,
RMT
RDR (PCB) B, C, D, E - HDD
PB-EN-60 Complex Components Design Process (ABD0100):
Prototype Development: - HAS (for CC)
- Produce Hardware Design Data (HDD) for Complex Components
to include Top-Level Drawings
PB-EN-30 (4.2)
- Produce Complex Component device
RDR (EQ) - Produce input for Hardware Accomplishment Summary for Complex Components (HAS)
Note:
The performance of a CCITR and a VR is done for Comp lex Components only.

VR Due to t he fact that for the performance of VR the avaialability of the HAS is required for the scope of
PB-EN-30 (4.2) Complex Components, the documen t shall included just such data, while remaining t opics are filled in for
ABD0100.2.11
CDR (Ch. 5.4) the provision o f the complet e HAS required for the performance of the FFAR

NO GO
NO GO
PB-EN-30 (5)
DO-254 Specifications: SES Production Transition (DO-254: 5.5): B, C, D, E - HDD
5.4,5.5,5.7,10.3.2.2,10.9, App. A Plans: PHAC, ECMP, COTS-MP, SMDP - Produce Hardware Design Data (HDD) to include updates on Top-Level Drawings - ECN for BU (for CC)
Standards: HDS Production Transition - Produce input for manufacturing documents („Bauunterlage“ (BU) administered via ECN) - CC manufactured based
CRI’s, FARs, JARs Templates: ECN (via „Buddy“), on BU
HDD (ETemp-532), Implementation (DO-254: 5.4):
ABD0100 Data: HDD CHT,
Series Production (DO-254: 5.7): CMT,
Quality Gate/Review: - Produce hardware item based on manufacturing documents (done by series production)
PB-EN-30, PB-EN-60, PB-EN-61, CCDITR (ETemp-105) DOT,
(6) PB-EN-30 (6) CCDITR (CEH)
PB-EN-62, PV-EN-02 EDT,
PB-EN-60 MOT,
QR (EQ) B, C, D, E - ECN for BU
Complex Components Design Process (ABD0100):
- Hw item manufactured RMT
Production Transition:
NO GO - Produce input for manufacturing documents related to Complex Components based on BU
NO GO („Bauunterlage“ (BU) administered via ECN)
- Produce Complex Component device (done by series production)
Note: The performance of a CCDITR is done for Com plex Componen ts only.
END OF DESIGN PROCESS
HARDWARE WORKFLOW CERTIFICATION LIAISON PROCESS (Design)
Data: Complete Production Transition (DO-254: 5.5): B, C, D, E - HAS
DO-254 Quality Gate/Review: -- - Produce Hardware Design Data (HDD) to include updates on Top-Level Drawings - HDD
5.4,5.5,9.0,10.3,10.9, App. A Specifications: SES
Plans: PHAC, ECMP, COTS-MP, SMDP CHT,
CRI’s, FARs, JARs Standards: HDS CMT,
(7) Templates: HAS (ETemp 061), DOT,
Complex Components Design Process (ABD0100):
ABD0100 HDD (ETemp-532) PB-EN-30 (7) EDT,
NO GO Production Transition:
Data: Complete Hardware Life Cycle Data MOT,
LUAR - Produce Hardware Design Data (HDD) for Complex Components
PB-EN-30, PB-EN-60, PB-EN-61, Quality Gate/Review: RMT
to include Top-Level Drawings
PB-EN-62, PV-EN-02 -- - Produce input for Hardware Accomplishment Summary for Complex Components (HAS)

Data: Complete
DO-254 Quality Gate/Review: -- Compliance Substanciation (DO-254: 9.2) B, C, D, E - HAS
5.4,5.5,9.0,10.3,10.9, App. A Specifications: SES - Produce Hardware Accomplishment Summary - HDD
Plans: PHAC, ECMP, COTS-MP, SMDP - Produce Hardware Design Data (HDD) to include updates for Top-Level Drawings CHT,
CRI’s, FARs, JARs Standards: HDS CMT,
(8) Templates: HAS (ETemp 061), PB-EN-30 (8) DOT,
ABD0100 HDD (ETemp-532) NO GO EDT,
FFAR Complex Components Certification Liaison Process (ABD0100): MOT,
Data: Complete Hardware Life Cycle Data
PB-EN-30, PB-EN-60, PB-EN-61, Quality Gate/Review: - Produce input for Hardware Accomplishment Summary for Complex Components (HAS) RMT
PB-EN-62, PV-EN-02 -- - Produce Hardware Design Data (HDD) for Complex Components
to include update for Top-Level Drawings for Complex Components

Data: Complete Compliance Substanciation (DO-254: 9.2 ) B, C, D, E - HAS

DO-254
Quality Gate/Review: -- - Produce Hardware Accomplishment Summary - HDD
5.4,5.5,9.0,10.3,10.9, App. A
Specifications: SES - Produce Hardware Design Data (HDD) to include updates for Top-Level Drawings CHT,
Plans: PHAC, ECMP, COTS-MP, SMDP CMT,
CRI’s, FARs, JARs PB-EN-30 (9)
Standards: HDS NO GO DOT,
(9)
Templates: HAS (ETemp 061), CFAR EDT,
ABD0100 Complex Components Certification Liaison Process (ABD0100):
HDD (ETemp-532) MOT,
Data: Complete Hardware Life Cycle Data - Produce input for Hardware Accomplishment Summary for Complex Components (HAS) RMT
PB-EN-30, PB-EN-60, PB-EN-61, - Produce Hardware Design Data (HDD) for Complex Components
Quality Gate/Review:
PB-EN-62, PV-EN-02 to include update for Top-Level Drawings for Complex Components
--
END OF CERTIFICATION LIAISON PROCESS
 Hardware Entwicklungs-Prozess-Abläufe
PB-EN-31
Seite 14 von 34
Hardware Development-Process-Workflows Page 14 of 34
Ausgabe
9, 07.12.2022
Issue

3.2 Prozessflussdiagramm für den Verifier 3.2 Workflow Diagram for the Verifier
Applicability by
No. Norms & St andards Input Data Process St eps Act ivities HW Design Output Dat a Tool
Assurance Level
HARDWARE WO RKFLOW - PLANNING PROCE SS (Validation and Verification)
Specificat ions: SoW/Spec. on Syst em level / PB-EN-30 (1) Plann ing Process (DO-254: 4.0): B, C, D*, E* - Produ ct Ser vice Expe rience
SE S - Produ ce H ardw are Val ida tion a nd Verification Plan (HVVP) Data (par t of HVVP)
Plans: ECMP, COTS-MP, SMDP - Produ ce Validation and Veri fication Standar ds (par t of HVVP)
B, C, D, E - HVVP
St andards: -- Planning P rocess - Produ ce/Collect Pr oduct Service Experience Data (par t of HVVP)
DO-254 Templates:
2.0,4.0,10.1.3, 10.1.4, 10.2.3, 11.0, App. HVVP (ETemp-424) B, C*, D*, E* - Har dwar e Verificati on
A, App. B Data: -- Standar ds (par t of HVVP)
Quality Gate/Review: CHT,
CRI’s, FARs, JARs M/PR (ETemp-101) B, C, D*, E* - Produ ct Ser vice Expe rience CMT,
(1) M/PR (CEH) Co mp lex Co mp on ent s Plann ing Process (AB D0100):
PB-EN-30 (1) Data DOT
AB D0100.2.11 - Produ ce contr ibution for Har dwar e Vali dation and Ver ification Plan r ela ted to Complex Compo nents
ABD0100 PR including data for Validation and Ver ification Standards
(Ch. 5.2)
- Produ ce/Collect Pr oduct Service Experience Data (adr essed in HVVP) B, C, D, E - HVVP
PB-EN-30, PB-EN-60, PB-EN-61,
PB-EN-62, PV-EN-02
NO GO
NO GO B, C*, D*, E* - Har dwar e Verificati on
Standar ds (par t of HVVP)

HARDWA RE WO RK FLOW – VA LIDATI ON AND VE RI FI CA TION PROCESS

DO-254 Specificat ions: SoW/Spec. on Syst em level / Validation Process (DO-254: 6.1):
6.1, 6.3, 10.4.1,10.4.2,10.4.3, App. A SE S - Produce review and analysis procedures f or validation of hardware requirements B, C, D, E - HVVCP
CRI’s, FARs, JARs Plans: HVVP, ECMP, COTS-MP, SMDP (part of HVVCP) - HVVR
Validation of CHT,
ABD0100 St andards: -- - Produce review and analysis result s from validation of hardware requirements
Requirements Capture CMT,
(2) Templates: HVVCP (ETemp-541), generated during requirments capture (part of HVVR) DOT,
PB-EN-30, PB-EN-60, PB-EN-61, PB- HVVR (ETemp-543) - Produce traceability dat a between equipment requirements and hardware RMT
EN-62, PV-EN-02 Data: HRD requirement s (part of HVVR)
Quality Gate/Review:--

DO-254 Specificat ions: SoW/Spec. on Syst em level / Validation and Verification Validation Process (DO-254: 6.1):
6.1, 6.2, 6.3, 10.4.1,10.4.2,10.4.3, App. SE S of - Produce review and analysis result s from validation of hardware requirements B, C, D, E - HVVCP
A Plans: HVVP, ECMP, COTS-MP, SMDP Conceptual Design generated during conceptual design (part of HVVR) - RCS
CRI’s, FARs, JARs St andards: -- - Produce traceability dat a between requirements and review and analysis procedures - HVVR
ABD0100 Templates: HVVCP (ETemp-541), and review and analysis results (part of HVVR) CHT,
HVVR (ETemp-543)
PB-EN-30 (2.3) CMT,
(3) PB-EN-30, PB-EN-60, PB-EN-61, PB- Data: HRD, HDD, IFDs NO GO Verification Process (DO-254: 6.2):
CR (EQ) DOT,
EN-62, PV-EN-02 Quality Gate/Review:-- - Produce review and analysis procedures f or verifcat ion of conceptual design data RMT
(part of HVVCP)
- Produce review and analysis result s from verifcation of concept ual design data
PB-EN-30 (2.3) (part of HVVR)
NO GO
PDR

DO-254 Specificat ions: SES Validation Process (DO-254: 6.1):

6.1, 6.2, 6.3, 10.4.1,10.4.2,10.4.3, Plans: HVVP, ECMP, COTS-MP, SMDP - Produce review and analysis result s from validation of hardware requirements B, C, D, E - HVVCP
10.4.4, 10.5, App. A St andards: HRS, HDS PB-EN-30 (3) generated during detailed design (part of HVVR) - RCS
CRI’s, FARs, JARs Templates: HVVCP (ETemp-541), TCR (EQ) - Produce review and analysis result s from validation of test procedures (part of HVVR) - HVVR
ABD0100 HVVR (ETemp-543)
Data: HRD, HDD, IFDs
PB-EN-30, PB-EN-60, PB-EN-61, PB- Quality Gate/Review: Verification Process (DO-254: 6.2):
EN-62, PV-EN-02 DR (PCB) (ETemp-014), Validation and Verification - Produce review and analysis procedures f or verifcat ion of det ailed design dat a
CCRR (ETemp-102) of (part of HVVCP)
R&DR (ETemp-449) Detailed Design - Produce test procedures (part of HVVCP)
- Produce review and analysis procedures f or validation of test procedures (part of HVVCP)
- Produce review and analysis result s from verifcation of detailed design data
(part of HVVR)
CHT,
DR (PCB) CCRR (CEH) - Produce traceability dat a between requirements and detailed design data (part of HVVR)
CMT,
(4) PB-EN-60 PB-EN-60 - Produce traceability dat a between requirements and test procedures (part of HVVR)
DOT,
- Produce accept ance test criteria
RMT
(as a contribution to ATS produced in the scope of t he PB-EN-30)
NO GO
NO GO
PB-EN-30 (4.1)
DR (EQ)
NO GO

R&DR
PB-EN-30 (4.1)
AB D0100.2.11
DDR (Ch. 5.3)

DO-254 Specificat ions: SES NO GO Verification Process (DO-254: 6.2): B, C, D, E - RCS

6.1, 6.2, 6.3, 10.4.1,10.4.3, 10.4.5, App. Plans: HVVP, ECMP, COTS-MP, SMDP NO GO - Produce test result s (part of HVVR) - HVVR
A St andards: -- - Produce traceability dat a between detailed design data and implementat ion of prototype - input to HA S
CRI’s, FARs, JARs Templates:HVVR (ETemp-543) Verification of (part of HVVR) (relat ed to CC)
ABD0100 Data: HDD Prot otype Development - Produce traceability dat a between requirements, detailed design data, verificat ion procedures
Quality Gate/Review: and verif ication result s (part of HVVR)
PB-EN-30, PB-EN-60, PB-EN-61, PB- Pt R (PCB (ETemp-015), - Produce input to t he Hardware Accomplishment Summary (HAS) showing compliance of the
EN-62, PV-EN-02 CCITR (ETemp-103), validation and verif ication process activities to the PHAC and t he HVVP relat ed to
CCITR complex component s
RDR (PCB)(ETemp-016), Pt R (PCB)
(CEH)
VR (ETemp-104) PB-EN-60
PB-EN-60

PB-EN-30 (4.2)
CHT,
Pt R (EQ) CMT,
(5) DOT,
RMT

RDR (PCB)
PB-EN-60

PB-EN-30 (4.2)
RDR (EQ)

VR
PB-EN-30 (4.2)
AB D0100.2.11
CDR (Ch. 5.4)

DO-254 Specificat ions: SE S NO GO B, C, D, E - RCS

NO GO
6.2, 6.3, 10.4.1,10.4.3, 10.4.5, App. A Plans: HVVP, ECMP, COTS-MP, SMDP Verification Process (DO-254: 6.2): - HVVR
CRI’s, FARs, JARs St andards: -- - Produce test result s (part of HVVR)
Verification of
ABD0100 Templates: HVVR (ETemp-543) - Produce traceability analysis (part of HVVR)
Product ion Transition
Data: complete Hardware Life Cycle Data - Produce verifcation coverage analysis (part of HVVR)
PB-EN-30, PB-EN-60, PB-EN-61, PB- Quality Gate/Review:
EN-62, PV-EN-02 CCDI TR (ETemp-105) CHT,
CMT,
(6) PB-EN-30 (6) CCDI TR (CEH) DOT,
PB-EN-60 RMT
QR (EQ)

NO GO
NO GO

END OF V ALIDATION AND V ERIFICATIO N PROCESS

HARDWARE WO RK FLOW CERTIFICATIO N LIA ISON P ROCESS (Validation and Verification)
Specificat ions: SE S Compliance Substanciation (DO-254: 9.2): B, C, D, E - RCS
Plans: HVVP, ECMP, COTS-MP, SMDP Certification Liai son Pr ocess (ABD0100): - HVVR
DO-254 St andards: -- - Produce validation and verification result s for resolution of any issues raised during - input to HAS
6.1, 6.2, 6.3, 9.2, 10.4.1,10.4.2, 10.4.3, Templates: HVVR (ETemp-543) certification activities (part of HVVR)
10.4.4, 10.4.5, App. A Data: complete Hardware Life Cycle Data - Produce input to t he Hardware Accomplishment Summary (HAS) showing compliance of the CHT,
CRI’s, FARs, JARs Quality Gate/Review: validation and verif ication process activities to the PHAC and t he HVVP CMT,
(7)
AB D0100 -- DOT,
RMT
PB-EN-30 (7)
PB-EN-30, PB-EN-60, PB-EN-61, PB- NO GO
EN-62, PV-EN-02 LUA R

Specificat ions: SE S Compliance Substanciation (DO-254: 9.2): B, C, D, E - RCS

Plans: HVVP, ECMP, COTS-MP, SMDP Certification Liai son Pr ocess (ABD0100): - HVVR
DO-254
St andards: -- - Produce validation and verification result s for resolution of any issues raised during - input to HAS
6.1, 6.2, 6.3, 9.2, 10.4.1,10.4.2, 10.4.3,
Templates: HVVR (ETemp-543) certification activities (part of HVVR)
10.4.4, 10.4.5, App. A CHT,
Data: complete Hardware Life Cycle Data - Produce input to t he Hardware Accomplishment Summary (HAS) showing compliance of the
CRI’s, FARs, JARs CMT,
(8) Quality Gate/Review: validation and verif ication process activities to the PHAC and t he HVVP
AB D0100 DOT,
-- PB-EN-30 (8) NO GO RMT
PB-EN-30, PB-EN-60, PB-EN-61, PB- FFAR
EN-62, PV-EN-02

Specificat ions: SE S Compliance Substanciation (DO-254: 9.2): B, C, D, E - RCS

DO-254 Plans: HVVP, ECMP, COTS-MP, SMDP Certification Liai son Pr ocess (ABD0100): - HVVR
6.1, 6.2, 6.3, 9.2, 10.4.1,10.4.2, 10.4.3, St andards: -- - Produce validation and verification result s for resolution of any issues raised during - input to HAS
10.4.4, 10.4.5, App. A Templates: HVVR (ETemp-543) certification activities (part of HVVR) CHT,
CRI’s, FARs, JARs Data: complete Hardware Life Cycle Data PB-EN-30 (9) - Produce input to t he Hardware Accomplishment Summary (HAS) showing compliance of the CMT,
(9) Quality Gate/Review: NO GO
AB D0100 validation and verif ication process activities to the PHAC and t he HVVP DOT,
-- CFAR
RMT
PB-EN-30, PB-EN-60, PB-EN-61, PB-
EN-62, PV-EN-02

END OF CE RTIFI CATION LI AIS ON PROCES S

 Hardware Entwicklungs-Prozess-Abläufe
PB-EN-31
Seite 15 von 34
Hardware Development-Process-Workflows Page 15 of 34
Ausgabe
9, 07.12.2022
Issue

3.3 Prozessflussdiagramm für den CM 3.3 Workflow Diagram for the CM

Appli cability by
No. Norms & St andards Input Data Process St eps Act ivities HW Design Output Dat a Tool
Assurance Level
HARDWA RE WO RK FLOW - PLANNING PROCE SS (Configuration Management)
Specificat ions: SoW/Spec. on Syst em level / PB-EN-30 (1) Plann ing Process (DO-254: 4.0):
SE S - Pr oduce Hardware Configur ation Management Plan (HCMP) B, C, D, E - HC MP
- Produ ce H ardw are Ar chi ve Standards (par t of HCM P) - HC MR
Plans: ECMP, COTS-MP, SMDP
- PR summar y
St andards: -- Planning P rocess
Co nf iguratio n Man agem ent Process (DO -254: 7.0): - HC I
DO-254 Templates: - Perform CM activities on the outputs of the Pl anning Process - Har dwar e Archi ve
4.0, 7.0, 10.1.5, 10.7, 11.0, App. A HCMR (ETemp-512), - Pr oduce Problem Repor t Summary Standar ds (par t of HCM P)
HCMP (ETemp-062), - Record CM acti vi ties in HCMR
CRI’s, FARs, JARs HCI (Et emp-427) - Pr oduce HCI
Configuration Cont rol CHT,
Data: Outputs of Planning P rocess on Outputs of CMT,
(1)
AB D0100 Quality Gate/Review: Planning P rocess DOT
M/PR (ETemp-101)

PB-EN-30, PB-EN-60, PB-EN-61,

PB-EN-62, PV-EN-02
M/PR (CEH)
PB-EN-30 (1)
ABD0100.2.11
PR (Ch. 5.2)
NO GO
NO GO
HARDWA RE WO RKFLOW – CONFIGURATION MANAG EMENT PROCESS
DO-254 Specificat ions: SoW/Spec. on Syst em level / Co nf igu ratio n Man agem ent Process (DO -254: 7.0):
7.0, 10.7, 11.0, App. A SE S - Perform CM activities on the outputs of the Requirements Capture B, C, D, E - HC MR
CRI’s, FARs, JARs Plans: HCMP, ECMP, COTS-MP, SMDP Configuration Cont rol - Pr oduce Problem Repor t Summary - PR s ummar y
- Record CM ac ti vi ties in HCMR CHT,
AB D0100 St andards: -- on Outputs of
CMT,
(2) Templates: Requirements Capture
DOT,
PB-EN-30, PB-EN-60, PB-EN-61, PB- HCMR (ETemp-512)
RMT
EN-62, PV-EN-02 Data: Outputs of Requirements Capture
Quality Gate/Review:--

DO-254 Specificat ions: SoW/Spec. on Syst em level / Configuration Cont rol Co nf igu ratio n Man agem ent Process (DO -254: 7.0):
7.0, 10.7, 11.0, App. A SE S on Outputs of - Perform CM activities on the outputs of the Conceptual Design B, C, D, E - HC MR
CRI’s, FARs, JARs Plans: HCMP, ECMP, COTS-MP, SMDP - Pr oduce Problem Repor t Summary - PR s ummar y
Conceptual Design
AB D0100 St andards: -- - Record CM ac ti vi ties in HCMR - HC I
- Pr oduce HCI
Templates:
CHT,
PB-EN-30, PB-EN-60, PB-EN-61, PB- HCMR (ETemp-512), PB-EN-30 (2.3)
NO GO CMT,
(3) EN-62, PV-EN-02 HCI (Et emp-427)
CR (EQ) DOT,
Data: Outputs of Conceptual Design
RMT
Quality Gate/Review:--

PB-EN-30 (2.3)
NO GO
PDR

DO-254 Specificat ions: SE S Co nf igu ratio n Man agem ent Process (DO -254: 7.0):
7.0, 10.7, 11.0, App. A Plans: HCMP, ECMP, COTS-MP, SMDP - Perform CM activities on the outputs of the Detailed Design B, C, D, E - HC MR
- Pr oduce Problem Repor t Summary - PR s ummar y
CRI’s, FARs, JARs St andards: --
- Record CM ac ti vi ties in HCMR - HC I
AB D0100 Templates:
PB-EN-30 (3) - Pr oduce HCI
HCMR (ETemp-512),
PB-EN-30, PB-EN-60, PB-EN-61, PB- HCI (Et emp-427) TCR (EQ)
EN-62, PV-EN-02 Data: Output of Det ailed Design
Quality Gate/Review:
DR (PCB) (ETemp-014),
CCRR (ETemp-102) Configuration Cont rol
R&DR (ETemp-449) on Outputs of
Detailed Design

CHT,
CMT,
(4) DOT,
DR (PCB) CCRR (CEH)
RMT
PB-EN-60 PB-EN-60

NO GO
NO GO
PB-EN-30 (4.1)
DR (EQ) NO GO

R&DR
PB-EN-30 (4.1)
AB D0100.2.11
DDR (Ch. 5.3)

DO-254 Specificat ions: SE S NO GO Co nf igu ratio n Man agem ent Process (DO -254: 7.0):
NO GO - Perform CM activities on the outputs of the Prototype Development B, C, D, E - HC MR
7.0, 10.7, 11.0, App. A Plans: HCMP, ECMP, COTS-MP, SMDP - PR s ummar y
- Pr oduce Problem Repor t Summary
CRI’s, FARs, JARs St andards: -- Configuration Cont rol - Record CM ac ti vi ties in HCMR - HC I
AB D0100 Templates: on Outputs of - Pr oduce HCI - i nput to HAS
HCMR (ETemp-512), Prot otype Development - Pr oduce input to the Hardwar e Accompl ishment Summary (HAS) showing compli ance of the (re lated to CC)
PB-EN-30, PB-EN-60, PB-EN-61, PB- HCI (Et emp-427) configur ati on management pr oc ess activiti es to the PHAC and the HCMP and prov iding data on hardware
EN-62, PV-EN-02 Data: Outputs of Prototype Development identification and change history related to compl ex components
Quality Gate/Review: CCITR
Pt R (PCB)
Pt R (PCB) (ETemp-015), (CEH)
PB-EN-60
CCITR (ETemp-103), PB-EN-60
RDR (PCB) (ETemp-016),
VR (ETemp-104) PB-EN-30 (4.2)
Pt R (EQ) CHT,
CMT,
(5) DOT,
RDR (PCB) RMT
PB-EN-60

PB-EN-30 (4.2)
RDR (EQ)

VR
PB-EN-30 (4.2)
ABD0100.2.11
CDR (Ch. 5.4)
NO GO
NO GO
DO-254 Specificat ions: SE S Co nf igu ratio n Man agem ent Process (DO -254: 7.0):
7.0, 10.7, 11.0, App. A Plans: HCMP, ECMP, COTS-MP, SMDP Configuration Cont rol B, C, D, E - HC I
- Perform CM activities on the outputs of the Production Transition
CRI’s, FARs, JARs St andards: -- on Outputs of - Pr oduce Problem Repor t Summary - HC MR
Product ion Transition - Record CM ac ti vi ties in HCMR - PR s ummar y
AB D0100 Templates:
- Pr oduce HCI
HCMR (ETemp-512),
PB-EN-30, PB-EN-60, PB-EN-61, PB- HCI (Et emp-427)
EN-62, PV-EN-02 Data: Outputs of Product ion Transition
Quality Gate/Review: CHT,
CCDI TR (ETemp-105) PB-EN-30 (6) CCDI TR (CEH) CMT,
(6) PB-EN-60
QR (EQ) DOT,
RMT

NO GO
NO GO

END OF CONFIG URATI ON MA NAGEMENT P RO CE SS

HARDWA RE WO RKFLOW CERTIFICATIO N LIAISON PROCESS (Configuration Management)
Specificat ions: SE S Co nf igu ratio n Man agem ent Process (DO-254: 7.0):
Plans: HCMP, ECMP, COTS-MP, SMDP - Perform CM activi ties on the outputs of Certi fication Li aison activities B, C, D, E - HC I
DO-254 - Pr oduce Problem Repor t Summary - HC MR
St andards: --
7.0, 10.7, 11.0, App. A - Record CM activities in HCMR - PR summar y
Templates: CHT,
CRI’s, FARs, JARs - Pr oduce HCI - i nput to HAS
HCMR (ETemp-512), PB-EN-30 (7) CMT,
(7) ABD0100 NO GO - Pr oduce input to the Hardwar e Accompl ishment Summary (HAS) showing compli ance of the
HCI (Et emp-427) configur ation management pr ocess activiti es to the PHAC and the HCMP and providing data on hardware DOT,
LUAR
Data: Complete Hw Design Life Cycle Data identi fication and change history RMT
PB-EN-30, PB-EN-60, PB-EN-61, PB-
Quality Gate/Review:
EN-62, PV-EN-02
--

Specificat ions: SES Co nf igu ratio n Man agem ent Process (DO-254: 7.0):
Plans: HCMP, ECMP, COTS-MP, SMDP - Perform CM activi ties on the outputs of Certi fication Li aison activities B, C, D, E - HC I
DO-254 - Pr oduce Problem Repor t Summary - HC MR
St andards: --
7.0, 10.7, 11.0, App. A - Record CM activities in HCMR - PR summar y
Templates: CHT,
CRI’s, FARs, JARs - Pr oduce HCI - i nput to HAS
HCMR (ETemp-512), - Pr oduce input to the Hardwar e Accompl ishment Summary (HAS) showing compli ance of the CMT,
(8) ABD0100 PB-EN-30 (8)
HCI (Et emp-427) NO GO configur ation management pr ocess activiti es to the PHAC and the HCMP and providing data on hardware DOT,
Data: Complete Hw Design Life Cycle Data FFAR identi fication and change history RMT
PB-EN-30, PB-EN-60, PB-EN-61, PB-
Quality Gate/Review:
EN-62, PV-EN-02
--

Specificat ions: SE S Co nf igu ratio n Man agem ent Process (DO-254: 7.0):
Plans: HCMP, ECMP, COTS-MP, SMDP - Perform CM activi ties on the outputs of Certi fication Li aison activities B, C, D, E - HC I
DO-254 - Pr oduce Problem Repor t Summary - HC MR
St andards: --
7.0, 10.7, 11.0, App. A - Record CM activities in HCMR - PR summar y
Templates: CHT,
CRI’s, FARs, JARs PB-EN-30 (9) - Pr oduce HCI - i nput to HAS
HCMR (ETemp-512), NO GO - Pr oduce input to the Hardwar e Accompl ishment Summary (HAS) showing compli ance of the
CMT,
(9) ABD0100
HCI (Et emp-427) CFAR configur ation management pr ocess activiti es to the PHAC and the HCMP and providing data on hardware DOT,
Data: Complete Hw Design Life Cycle Data identi fication and change history RMT
PB-EN-30, PB-EN-60, PB-EN-61, PB-
Quality Gate/Review:
EN-62, PV-EN-02
--

END OF CERTIFI CATION LI AIS ON PROCES S

 Hardware Entwicklungs-Prozess-Abläufe
PB-EN-31
Seite 16 von 34
Hardware Development-Process-Workflows Page 16 of 34
Ausgabe
9, 07.12.2022
Issue

3.4 Prozessflussdiagramm für die PA 3.4 Workflow Diagram for the PA

Applicability by
No. Norms & Stand ards Input Data Process St ep s Act ivities HW Design Output Dat a Tool
As suranc e Level
HARDWA RE WO RK FLOW - PLANNING PROCE SS (Process Assurance)
Sp ecifications: So W/Spec. on Syst em level / PB-EN-30 (1) Process Assu ran ce (DO-254: 8.0): B, C, D, E - HPAP
SES PQR: - Pr oduce Hardware Process Assurance Plan (HPAP) - HPAR
Plans: ECMP, COTS-MP, SMDP - Inspection of plans r egarding availability - M/PR R eport
St andards: -- - Record findings from inspec tions
Planning P ro cess - Record findings from methology/plans review within M/PR quality gate sheet
DO-25 4 Templates:
4.0, 8.0, 10.1.6, 10.8, 11.0, Ap p. A HPAR (ETe mp-51 2),
HPAP (ETemp-064)
CRI’s, FARs, JARs Data: Outpu ts o f Pla nnin g P rocess
Proce ss Assurance on CHT,
Quality Ga te/Review:
(1) Planning P ro cess CMT,
AB D0100 M/PR (ETemp-101)
DOT

PB-EN-30, PB-EN-60, PB-EN-61,

PB-EN-62, PV-EN-02 M/PR (CEH)
PB-EN-30 (1)
ABD0100.2.11
PR (Ch. 5.2)
NO GO
NO GO
HARDWA RE WO RK FLOW – PROCESS A SSURANCE
DO-25 4 Sp ecifications: So W/Spec. on Syst em level / Process Assu ran ce (DO-254: 8.0):
8.0, 10.8, 11.0, App. A SES PQR: - Inspection of outputs of Requirements Capture regarding availability B, C, D, E - HPAR
CRI’s, FARs, JARs Plans: HPAP, ECMP, COTS-MP, SMDP - Record findings from inspec tions
Process Assu rance on CHT,
AB D0100 St andards: --
Requirements Capture CMT,
(2) Templates:
DOT,
PB-EN-30, PB-EN-60, PB-EN-61, PB- HPAR (ETe mp-51 2)
RMT
EN-62, PV-EN-02 Data: Outpu ts o f Requirements Capture
Quality Ga te/Review:--

DO-25 4 Sp ecifications: So W/Spec. on Syst em level / Proce ss Assurance Process Assu ran ce (DO-254: 8.0):
8.0, 10.8, 11.0, App. A SES On PQR: - Inspection of outputs of Conceptual Design regar ding availability B, C, D, E - HPAR
CRI’s, FARs, JARs Plans: HPAP, ECMP, COTS-MP, SMDP Conceptual Design - Record findings from inspec tions
AB D0100 St andards: --
Templates:
CHT,
PB-EN-30, PB-EN-60, PB-EN-61, PB- HPAR (ETe mp-51 2)Data: Ou tputs o f
PB-EN-30 (2.3) CMT,
(3) EN-62, PV-EN-02 Conceptua l Design NO GO
CR (EQ) DOT,
Quality Ga te/Review:--
RMT

PB-EN-30 (2.3)
NO GO
PDR

DO-25 4 Sp ecificatio ns: SE S Process Assu ran ce (DO-254: 8.0):

8.0, 10.8, 11.0, App. A Plans: HPAP, ECMP, COTS-MP, SMDP PQR: - Inspection of outputs of Detailed Design regarding av ailability B, C, D, E - HPAR
PB-EN-30 (3)
CRI’s, FARs, JARs St andards: -- - Record findings from inspec tions - DR Repo rt
AB D0100 Templates: TCR (EQ) - Record findings from Design Rev iew within DR (PCB) quality gate sheet - CCRR Report
- Record findings from Complex Components Requirements Review within CCRR quality gate s heet - R&DR Repo rt
HPAR (ETemp-51 2) - Record findings from Requirements & Design Review within R&DR quality gate sheet
PB-EN-30, PB-EN-60, PB-EN-61, PB- Data: Outpu ts of Det ailed Design
EN-62, PV-EN-02 Qu ality Gate/Review:
DR (PCB) (ETemp-014),
CCRR (ETemp-102) Process Assurance
R&DR (ETe mp-449) on
Deta ile d Design

CHT,
CMT,
(4) DR (PCB) CCRR (CEH) DOT,
PB-EN-60 PB-EN-60 RMT

NO GO
NO GO
PB-EN-30 (4.1)
DR (EQ) NO GO

R&DR
PB-EN-30 (4.1)
AB D01 00.2.11
DDR (Ch. 5.3)

NO GO Process Assu ran ce (DO-254: 8.0): B, C, D, E - HPAR

DO-25 4 Sp ecifications: SE S
8.0, 10.8, 11.0, App. A Plans: HPAP, ECMP, COTS-MP, SMDP NO GO PQR: - Inspection of outputs of Prototype Development r egarding availability - Pt R Re port
- Record findings from inspec tions - RDR Report
CRI’s, FARs, JARs St andards: -- - Record findings from Prototype Rev iew within PtR (PCB) quality gate sheet
Process Assu rance on - CCITR Report
AB D0100 Templates: - Record findings from Complex Components Implementation Tes t Review within CCIT R quality gate sheet
Prototype Development - VR Report
HPAR (ETe mp-51 2) - Record findings from Re-Design Review within RDR (PCB) quality gate sheet
PB-EN-30, PB-EN-60, PB-EN-61, PB- Data: Ou tputs of Prototype De velopment - Record findings from Verification Review within VR quality gate sheet - inp ut to HA S
EN-62, PV-EN-02 Quality Ga te/Review: - Pr oduce input to the Hardware Accomplishment Summary (HAS) showing c ompliance of the (relat ed to CC)
CCITR process assurance activ ities to the PHAC and the HPAP related to complex components
Pt R (PCB) (ETemp-015), Pt R (PCB)
CCITR (ETemp-103), (CEH)
PB-EN-60
RDR (PCB) (ETe mp-016), PB-EN-60
VR (Et emp-104)
PB-EN-30 (4.2)
Pt R (EQ) CHT,
CMT,
(5) DOT,
RDR (PCB) RMT
PB-EN-60

PB-EN-30 (4.2)
RDR (EQ)

VR
PB-EN-30 (4.2)
ABD0100.2.11
CDR (Ch. 5.4)

NO GO
NO GO
DO-25 4 Sp ecifications: SE S Process Assu ran ce (DO-254: 8.0): B, C, D, E - HPAR
8.0, 10.8, 11.0, App. A Plans: HPAP, ECMP, COTS-MP, SMDP Proce ss Assurance on PQR: - Inspection of outputs of Production Trans ition regarding av ailability - CCDITR Report
CRI’s, FARs, JARs St andards: -- Prod uctio n Tran sition - Record findings from inspec tions
AB D0100 Templates: - Record findings from Complex Components Device Integration Test Review within
HPAR (ETe mp-51 2) CCDIR quality gate sheet
PB-EN-30, PB-EN-60, PB-EN-61, PB- Data: Ou tputs of Production Tra nsition
EN-62, PV-EN-02 Quality Ga te/Review:
CHT,
CCDITR (ETe mp-105) PB-EN-30 (6) CCDI TR (CEH)
CMT,
(6) PB-EN-60
QR (EQ) DOT,
RMT
NO GO
NO GO

END OF PROCESS ASS URANCE

HARDWARE WO RKFLOW CERTIFICATIO N LIAISON PROCESS (Process Assu rance)
Sp ecificatio ns: SES Process Assu ran ce (DO-254: 8.0): B, C, D, E - HPAR
Pla ns: HPAP, ECMP, COTS-MP, SMDP PQR: - Inspection of complete set of hardware life cyc le data regarding av ailability - input to HA S
DO-254 St andards: -- - Record findings from inspec tions
8.0, 9.0, 10.8, 11.0, App. A Templa tes: - Pr oduce input to the Hardware Accomplishment Summary (HAS) showing c ompliance of the
process assurance activ ities to the PHAC and the HPAP CHT,
CRI’s, FARs, JARs HPAR (ETemp-512) CMT,
(7) ABD01 00 Data: Comple te Hardware Life Cycle Data
PB-EN-30 (7) DOT,
Qu ality Gate/Review: NO GO RMT
PB-EN-30, PB-EN-60, PB-EN-61, PB- -- LUAR
EN-62, PV-EN-02

Sp ecificatio ns: SES Process Assu ran ce (DO-254: 8.0): B, C, D, E - HPAR

Pla ns: HPAP, ECMP, COTS-MP, SMDP PQR: - Inspection of complete set of hardware life cyc le data regarding av ailability - input to HA S
DO-254 St andards: -- - Record findings from inspec tions
8.0, 9.0, 10.8, 11.0, App. A Templa tes: - Pr oduce input to the Hardware Accomplishment Summary (HAS) showing c ompliance of the
process assurance activ ities to the PHAC and the HPAP CHT,
CRI’s, FARs, JARs HPAR (ETemp-512) CMT,
(8) ABD01 00 Data: Comple te Hardware Life Cycle Data DOT,
PB-EN-30 (8)
Qu ality Gate/Review: NO GO RMT
PB-EN-30, PB-EN-60, PB-EN-61, PB- -- FFAR
EN-62, PV-EN-02

Sp ecificatio ns: SES Process Assu ran ce (DO-254: 8.0): B, C, D, E - HPAR

Pla ns: HPAP, ECMP, COTS-MP, SMDP PQR: - Inspection of complete set of hardware life cyc le data regarding av ailability - input to HA S
DO-254 - Record findings from inspec tions
St andards: --
8.0, 9.0, 10.8, 11.0, App. A - Pr oduce input to the Hardware Accomplishment Summary (HAS) showing c ompliance of the
CHT,
Templa tes: process assurance activ ities to the PHAC and the HPAP
CRI’s, FARs, JARs PB-EN-30 (9) CMT,
HPAR (ETemp-512) NO GO
(9) ABD01 00 DOT,
Data: Comple te Hardware Life Cycle Data CFAR
Qu ality Gate/Review: RMT
PB-EN-30, PB-EN-60, PB-EN-61, PB-
--
EN-62, PV-EN-02

END OF CERTIFICA TION LI AISON PROCESS

 Hardware Entwicklungs-Prozess-Abläufe
PB-EN-31
Seite 17 von 34
Hardware Development-Process-Workflows Page 17 of 34
Ausgabe
9, 07.12.2022
Issue

3.5 Angewendete Werkzeuge 3.5 Utilized Tools

Tool Description Abrev. Usage Actual Tool Distributor

Modelling Tool MOT - Generation of SABER Model PSpice Cadence

Requirements RMT - Requirements management DOORS IBM/Telelogic

management tool
Configuration CMT - Configuration management Buddy Proprietary
management tool (hardware life cycle data)
- Configuration management ClearCase IBM
(data related to firmware for
complex components)
Change management CHT - Problem reporting ClearQuest IBM
tool - Quality gate management
Documentation tool DOT - Documentation MS Word Microsoft
MS Visio Microsoft
MS Excel Microsoft
MS Power Point Microsoft
Adobe Acrobat Adobe
Docs Google
Sheets Google
Slides Google
Electronics design tool EDT - Layout design Expedition Mentor
- Schematics design
- Firmware design <project specific> <project specific>
 Hardware Entwicklungs-Prozess-Abläufe
Hardware Development-Process-Workflows
4 Prozessabläufe im Hardware Design Life Cycle
Der Hardware Design Life Cycle Prozess definiert und
koordiniert die Aufgaben des Planungsprozesses und
der Entwicklungsprozesse. Die Prozesse können auf-
grund von inkrementeller Entwicklung und in Abhän-
gigkeit von Transitions-Kriterien und den Ergebnissen
der Reviews iterative durchlaufen werden. Die Pro-
zesse, inklusive der Sub-Prozesse, werden parallel
durch die unterstützenden Prozesse begleitet.
4.1 Hardware Planungs Prozess
Das Ziel des Hardware Planungs Prozesses ist die
Definition der Vorgehensweise und der Hilfsmittel, die
dazu beitragen die funktionalen und Lufttüchtigkeits-
relevanten Anforderungen in die Hardware einzubrin-
gen.
Im Hardware Planungs Prozess werden die benötig-
ten Hardware Pläne erstellt und die entsprechenden
Standards ausgewählt und definiert. Die Hardware
Entwicklungs- und Verifikations –Umgebungen wer-
den ausgewählt oder definiert und es wird der Zertifi-
zierungs-Behörde angezeigt, wie der Nachweis zur
Übereinstimmung mit den Zielen der Entwicklungs-
Absicherung erbracht wird.
Anmerkung:
Soweit möglich sollen die Pläne und Standards, die die
Hardware Entwicklungs-Prozesse und die zugehörige
Equipment Entwicklung (siehe PB-EN-30) beschreiben,
zusammengeführt werden.
Rollen, Inputs/Outputs und Aktivitäten
Die grundsätzlichen Rollen und Zuständigkeiten sind
in Kapitel 2.3 definiert.
Die prozessschritt-spezifischen Inputs/Outputs und
Aktivitäten sind im Prozessschritt (1) des Prozess-
flussdiagramms für den Implementer aus Kapitel 3.1
definiert.
Transitions-Kriterien
Die Bedingungen, um in den Hardware Planungs Pro-
zess einzutreten, sind die Verfügbarkeit der geneh-
migten und autorisierten Prozess-Inputs, wie im Pro-
zessflussdiagramm des Kapitels 3.1 aufgeführt.
Der Hardware Planungs Prozess ist vollständig durch-
geführt, wenn die Zielsetzungen erreicht und durch
das Methodology/Plans Review (M/PR) im Falle von
PB-EN-31
Seite 18 von 34
Page 18 of 34
Ausgabe
9, 07.12.2022
Issue
4 Process flow of Hardware Design Life Cycle
The hardware design life cycle process defines and co-
ordinates the activities of the planning process and the
design processes. The processes may be iterative due
to incremental development depending upon the transi-
tion criteria and the result of reviews. These processes
inclusive sub-processes are accompanied by the sup-
porting processes in parallel.
4.1 Hardware Planning Process
The objective of the hardware planning process is to de-
fine the means and tools by which the functional and
airworthiness requirements are converted into a hard-
ware item.
Within the hardware planning process the needed hard-
ware plans are produced and the related standards are
selected and defined. The hardware development and
verification environments are selected or defined and
the means of compliance of the hardware design assur-
ance objectives are proposed to the certification author-
ity.
Note:
Plans and standards defining hardware design life cycle
processes and the related equipment design (see PB-EN-30)
shall be merged, wherever possible.
Roles, Inputs/Outputs and Activities
The fundamental roles and competencies are defined in
chapter 2.3.
The process-step specific inputs/outputs and activities
are defined in the process step (1) of workflow diagram
for the implementer in chapter 3.1.
Transition Criteria
The conditions to enter the hardware planning process
are the availability of approved and authorized process
inputs listed in workflow diagrams of chapter 3.1.
The hardware planning process is complete when its
objectives are satisfied approved by the performance of
the Methodology/Plans Review (M/PR) in case of Com-
plex Components and Plans Review (PR) in status
 Hardware Entwicklungs-Prozess-Abläufe
Hardware Development-Process-Workflows
Complex Components und das Plans Review (PR) je-
weils im Status „grün“ oder „gelb“ gemäß QG Ampel-
steuerung der PB-EN-60 genehmigt worden sind.
Anmerkung: Die Hardware-Pläne und Standards sol-
len vor dem Starten der Hardware Entwicklungs-Akti-
vitäten erstellt werden. Einige Hardware Design Life
Cycle Prozesse können vor Beendigung des Hard-
ware Planungs-Prozesses beginnen, wenn die Pläne
und Standards für die spezifischen Prozessaufgaben
genehmigt und autorisiert sind.
4.2 Hardware Design Prozesse
Die Hardware Design Prozesse bestehen aus den fol-
genden Sub-Prozessen:
 Requirements Capture Prozess
 Conceptual Design Prozess
 Detailed Design Prozess
 Protottype Development
 Production Transition Prozess
Die Hardware Design Aktivitäten werde gemäß dem
Plan for Hardware Aspects of Certification (incl.
Hardware Design Plan) (PHAC) durchgeführt.
4.2.1 Requirements Capture Prozess
Das Ziel des Requirements Capture Prozesses ist die
Identifikation und Aufzeichnung der Anforderungen an
die Hardware. Das schließt alle Arten von Anforderun-
gen gemäß der Begriffsdefinition gemäß Kapitel 2.5
ein. Derived Requirements werden an den jeweiligen
Prozess zur Beurteilung respektive Lösung von offe-
nen Punkten zurückgekoppelt.
Der Prozess kann iterativ ausgeführt werden, da zu-
sätzliche Anforderungen während der Design Aktivitä-
ten bekannt werden können.
Die Anforderungen an die Hardware werden in den
Hardware Requirements Data (HRD) unter Beachtung
der Hardware Requirements Standards (HRS) doku-
mentiert.
PB-EN-31
Seite 19 von 34
Page 19 of 34
Ausgabe
9, 07.12.2022
Issue
“green” or “amber” each according to QG traffic light
control of PB-EN-60.
Note: The hardware plans shall be developed prior to
entering any hardware development activities. Some
hardware design life cycle processes may begin before
completion of the hardware planning process if the
plans and standards for the specific process activity are
approved and authorized.
4.2 Hardware Design Processes
The hardware design processes consist of the following
sub processes:
 Requirements Capture Process
 Conceptual Design Process
 Detailed Design Process
 Prototype Development
 Production Transition Process
Hardware Design activities are performed in accord-
ance with Plan for Hardware Aspects of Certification
(incl. Hardware Design Plan) (PHAC).
4.2.1 Requirements Capture Process
The objective of the requirements capture process is to
identify and record the requirements for the hardware
item. This includes all kinds of requirements in accord-
ance with the definition of terms in chapter 2.5. Derived
requirements are fed back to the appropriate process for
assessment respective resolution of open points.
The process may be performed iteratively since addi-
tional requirements may become known during design.
The requirements for the hardware are documented
within the Hardware Requirements Data (HRD) follow-
ing the Hardware Requirements Standards (HRS).
 Hardware Entwicklungs-Prozess-Abläufe
Hardware Development-Process-Workflows
Rollen, Inputs/Outputs und Aktivitäten
Die grundsätzlichen Rollen und Zuständigkeiten sind
in Kapitel 2.3 definiert.
Die prozessschritt-spezifischen Inputs/Outputs und
Aktivitäten sind im Prozessschritt (2) des Prozess-
flussdiagramms für den Implementer aus Kapitel 3.1
definiert.
Transitions-Kriterien
Die Bedingungen, um in den Requirements Capture
Prozess einzutreten, sind die Verfügbarkeit der ge-
nehmigten und autorisierten Prozess-Inputs, wie im
Prozessflussdiagramm des Kapitels 3.1 aufgeführt.
Der Requirements Capture Prozess ist komplett, wenn
seine Zielsetzungen und die damit verbundenen Ziel-
setzungen der unterstützenden Prozesse erfüllt sind.
4.2.2 Conceptual Design Prozess
Das Ziel des Conceptual Design Prozess ist die Erstel-
lung eines high-level Design Konzeptes. Dieses Kon-
zept soll dazu genutzt werden, zu untersuchen, ob
eine resultierende Umsetzung dazu geeignet ist, die
gegebenen Anforderungen zu erfüllen.
Dies wird dadurch erreicht, dass Daten wie funktionale
Block-Diagramme, Design- und Architektur- Beschrei-
bungen, Schaltpläne oder Skizzen erstellt werden.
Das high-level Design Konzept wird in Übereinstim-
mung mit den gegebenen Anforderungen entwickelt.
Dabei dient das interne Concept Review (CR) zur Be-
gutachtung und Auswahl des geeigneten Design Kon-
zeptes.
Das high-level Design Konzept wird in den Hardware
Design Data (HDD) unter Beachtung der Hardware
Design Standards (HDS) dokumentiert.
Rollen, Inputs/Outputs und Aktivitäten
Die grundsätzlichen Rollen und Zuständigkeiten sind
in Kapitel 2.3 definiert.
Die prozessschritt-spezifischen Inputs/Outputs und
Aktivitäten sind im Prozessschritt (3) des Prozess-
flussdiagramms für den Implementer aus Kapitel 3.1
definiert.
Transitions-Kriterien
Die Bedingungen, um in den Conceptual Design Pro-
zess einzutreten, sind die Verfügbarkeit der geneh-
migten und autorisierten Prozess-Inputs, wie im Pro-
zessflussdiagramm des Kapitels 3.1 aufgeführt.
PB-EN-31
Seite 20 von 34
Page 20 of 34
Ausgabe
9, 07.12.2022
Issue
Roles, Inputs/Outputs and Activities
The fundamental roles and competencies are defined in
chapter 2.3.
The process-step specific inputs/outputs and activities
are defined in the process step (2) of workflow diagram
for the implementer in chapter 3.1.
Transition Criteria
The conditions to enter the requirements capture pro-
cess are the availability of approved and authorized pro-
cess inputs listed in workflow diagrams of chapter 3.1.
The requirements capture process is complete when its
objectives and the objectives of the related supporting
processes are satisfied.
4.2.2 Conceptual Design Process
The objective of the conceptual design process is to pro-
duce a high-level design concept that may be assessed
to determine the potential for the resulting design imple-
mentation to meet the requirements.
This is accomplished by generating such data as, func-
tional block diagrams, design and architecture descrip-
tions, circuit card assembly outlines or sketches.
The high–level design concept is developed consistent
with the given requirements.
The internal Concept Review (CR) serves the purpose
to inspect and select the appropriate design concept.
The high-level design concept is documented within the
Hardware Design Data (HDD) following the Hardware
Design Standards (HDS).
Roles, Inputs/Outputs and Activities
The fundamental roles and competencies are defined in
chapter 2.3.
The process-step specific inputs/outputs and activities
are defined in the process step (3) of workflow diagram
for the implementer in chapter 3.1.
Transition Criteria
The conditions to enter the conceptual design process
are the availability of approved and authorized process
inputs listed in workflow diagrams of chapter 3.1.
 Hardware Entwicklungs-Prozess-Abläufe
Hardware Development-Process-Workflows
Der Conceptual Design Prozess ist vollständig
durchgeführt, wenn die Zielsetzungen erreicht, die
Zielsetzung der zugehörigen unterstützenden
Prozesse erfüllt und durch das Preliminary Design
Review (PDR) im Status „grün“ oder „gelb“ gemäß QG
Ampelsteuerung der PB-EN-60 genehmigt worden
sind.
4.2.3 Detailed Design Prozess
Das Ziel des Detailed Design Prozesses ist es, die de-
taillierten Design Daten (gem. DO-254 Kapitel
10.3.2.2) auf Basis der Anforderungen und des high-
level Design Konzeptes zu erstellen.
Das interne Design Review (PCB) (DR(PCB)) bzw.
das Complex Components Requirements Review
(CCRR) im Falle von Complex Components dienen
zur Begutachtung und Abstimmung des Designs mit
den internen Abteilungen (Produktions Überleitung,
Produktion, Repairstation, und Einkauf).
Derived Requirements, Fehler oder Nicht-Umsetzun-
gen von Anforderungen werden an den jeweiligen Pro-
zessen zur Beurteilung respektive Lösung von offenen
Punkten zurückgekoppelt.
Die detaillierten Design Daten werden in den Hard-
ware Design Data (HDD) unter Beachtung der Hard-
ware Design Standards (HDS) zusammengefasst und
dokumentiert. Die korrekte Umsetzung der Vorgaben
zum Electronic Component Management werden im
Electronic Component Management Report (ECMR)
dargestellt.
Rollen, Inputs/Outputs und Aktivitäten
Die grundsätzlichen Rollen und Zuständigkeiten sind
in Kapitel 2.3 definiert.
Die prozessschritt-spezifischen Inputs/Outputs und
Aktivitäten sind im Prozessschritt (4) des Prozess-
flussdiagramms für den Implementer aus Kapitel 3.1
definiert.
Transitions-Kriterien
Die Bedingungen, um in den Detailed Design Prozess
einzutreten, sind die Verfügbarkeit der genehmigten
und autorisierten Prozess-Inputs, wie im Prozessfluss-
diagramm des Kapitels 3.1 aufgeführt.
Der Detailed Design Prozess ist vollständig durchge-
führt, wenn die Zielsetzungen erreicht, die Zielsetzung
der zugehörigen unterstützenden Prozesse erfüllt und
durch das Requirements & Design Review (R&DR) im
PB-EN-31
Seite 21 von 34
Page 21 of 34
Ausgabe
9, 07.12.2022
Issue
The conceptual design process is complete when its ob-
jectives and the objectives of the supporting processes
associated with it are satisfied approved by the perfor-
mance of Preliminary Design Review (PDR) in status
“green” or “amber” according to QG traffic light control
of PB-EN-60.
4.2.3 Detailed Design Process
The objective of the detailed design process is to gen-
erate the detailed design data (in accordance with DO-
254 chapter 10.3.2.2) based on the requirements and
the high-level design concept.
The internal Design Review (PCB) (DR (PCB)) respec-
tive Complex Components Requirements Review
(CCRR) in case of Complex Components serve the pur-
pose to inspect and agree on the design with the internal
departments (Production transfer, production, repair
station and procurement).
Derived requirements, requirement omissions or errors
are fed back to the appropriate process for assessment
respective resolution of open points.
The detailed design data are collected and documented
within the Hardware Design Data (HDD) following the
Hardware Design Standards (HDS).
The correct application of the guidelines for Electronic
Component Management are demonstrated in the Elec-
tronic Component Management Report (ECMR).
Roles, Inputs/Outputs and Activities
The fundamental roles and competencies are defined in
chapter 2.3.
The process-step specific inputs/outputs and activities
are defined in the process step (4) of workflow diagram
for the implementer in chapter 3.1.
Transition Criteria
The conditions to enter the detailed design process are
the availability of approved and authorized process in-
puts listed in workflow diagrams of chapter 3.1.
The detailed design process is complete when its objec-
tives and the objectives of the supporting processes as-
sociated with it are satisfied approved by the perfor-
mance of the Requirements & Design Review (R&DR)
 Hardware Entwicklungs-Prozess-Abläufe
Hardware Development-Process-Workflows
Falle von Complex Components und das Design Re-
view (EQ) (DR(EQ)) sowie das Detailed Design Re-
view (DDR) jeweils im Status „grün“ oder „gelb“ gemäß
QG Ampelsteuerung der PB-EN-60 genehmigt wor-
den sind.
4.2.4 Prototype Development
Das Ziel des Prototype Development ist es, auf Basis
der detaillierten Design Daten und unter Anwendung
repräsentativer Herstellungs-Prozesse die Hardware
(Prototype) zu produzieren, die zur Durchführung der
Test Aktivitäten genutzt wird. Zu diesem Zweck wird
die Engineering Change Note (ECN) zur Steuerung
der zu generierenden Bauunterlage (BU) erstellt, so
dass die Hardware unter Nutzung der Ressourcen, die
für die Produktion der Hardware vorgesehen sind er-
stellt werden kann.
Falls bei der Begutachtung des Protottyps im Rahmen
des Prototype Review (PtR) beziehungsweise des
Complex Components Implementation Test Reviews
(CCITR) die Notwendigkeit eines Re-Designs festge-
stellt wird, wird dieses vorgenommen und im Rahmen
eines Re-Design Reviews (RDR) überprüft. Auf Basis
des überarbeiteten Designs wird ein geänderter Pro-
totyp produziert, der dann seinerseits erneut einem
PtR unterzogen wird.
Dieser iterative Prozess kann evtl. mehrfach durchge-
führt werden, bis eine Abnahme des Prototyps erfolgt.
Derived Requirements, Fehler oder Nicht-Umsetzun-
gen von Anforderungen werden an den jeweiligen Pro-
zessen zur Beurteilung respektive Lösung von offenen
Punkten zurückgekoppelt.
Anmerkung:
Das Prototype Development stellt den „Implementation
Prozess“ im Sinne der DO-254 dar.
Rollen, Inputs/Outputs und Aktivitäten
Die grundsätzlichen Rollen und Zuständigkeiten sind
in Kapitel 2.3 definiert.
Die prozessschritt-spezifischen Inputs/Outputs und
Aktivitäten sind im Prozessschritt (5) des Prozess-
flussdiagramms für den Implementer aus Kapitel 3.1
definiert.
PB-EN-31
Seite 22 von 34
Page 22 of 34
Ausgabe
9, 07.12.2022
Issue
in case of Complex Components and the Design Re-
view (EQ) (DR(EQ)) as well as the Detailed Design Re-
view (DDR) in status “green” or “amber” each according
to QG traffic light control of PB-EN-60.
4.2.4 Prototype Development
The objective of the prototype development is to pro-
duce a hardware item (prototype) that is an input to the
testing activities, which implements the hardware de-
tailed design using representative manufacturing pro-
cesses. For that purpose an Engineering Change Note
(ECN) is produced to administer the manufacturing doc-
uments (BU) that needs to be generated. By this the
hardware item can be produced by those resources in-
tended for the production product.
In case the inspection of the prototype in the frame of
the Prototype Review (PtR) respective Complex Com-
ponents Implementation Test Review (CCITR) identifies
the need for a re-design, this is executed and checked
during the Re-Design Review (RDR). Based on the re-
worked design a changed prototype is produced, that
then undergoes a new PtR.
This iterative process might be performed various times
until an acceptance is reached.
Derived requirements, requirement omissions or errors
are fed back to the appropriate process for assessment
respective resolution of open points.
Note:
The Prototype Development represents the „Implementation
Process“ in terms of DO-254
Roles, Inputs/Outputs and Activities
The fundamental roles and competencies are defined in
chapter 2.3.
The process-step specific inputs/outputs and activities
are defined in the process step (5) of workflow diagram
for the implementer in chapter 3.1.
 Hardware Entwicklungs-Prozess-Abläufe
Hardware Development-Process-Workflows
Transitions-Kriterien
Die Bedingungen, um in das Prototype Development
einzutreten, sind die Verfügbarkeit der genehmigten
und autorisierten Prozess-Inputs, wie im Prozessfluss-
diagramm des Kapitels 3.1.
Das Prototype Development ist vollständig durchge-
führt, wenn die Zielsetzungen erreicht, die Zielsetzung
der zugehörigen unterstützenden Prozesse erfüllt und
durch das Verification Review (VR) im Falle von Com-
plex Components und das Critical Design Review
(CDR) jeweils im Status „grün“ oder „gelb“ gemäß QG
Ampelsteuerung der PB-EN-60 genehmigt worden
sind.
4.2.5 Production Transition Prozess
Das Ziel des Production Transition Prozesses ist es,
einen Datensatz zu erzeugen, der alle Design- und
Herstellungsdaten, die benötigt werden, um eine ein-
heitliche Reproduktion der Hardware zu gewährleis-
ten, sowie die sicherheitsrelevanten Herstellungs-An-
forderungen enthält, so dass eine Überleitung an die
Serienfertigung erfolgen kann.
Diese Daten sind in der Bauunterlage (BU) enthalten.
Derived Requirements, Fehler oder Nicht-Umsetzun-
gen von Anforderungen werden an den jeweiligen Pro-
zessen zur Beurteilung respektive Lösung von offenen
Punkten zurückgekoppelt.
Mit dem Bestehen aller Transitions-Kriterien wird der
Prozess der Serienbetreuung betreten.
(siehe PB-EN-50).
Rollen, Inputs/Outputs und Aktivitäten
Die grundsätzlichen Rollen und Zuständigkeiten sind
in Kapitel 2.3 definiert.
Die prozessschritt-spezifischen Inputs/Outputs und
Aktivitäten sind im Prozessschritt (6) des Prozess-
flussdiagramms für den Implementer aus Kapitel 3.1
definiert.
Transitions-Kriterien
Die Bedingungen, um in den Production Transition
Prozess einzutreten, sind die Verfügbarkeit der ge-
nehmigten und autorisierten Prozess-Inputs, wie im
Prozessflussdiagramm des Kapitels 3.1 aufgeführt.
Der Production Transition Prozess ist vollständig
durchgeführt, wenn die Zielsetzungen erreicht, die
Zielsetzung der zugehörigen unterstützenden
Prozesse erfüllt und durch das Complex Components
PB-EN-31
Seite 23 von 34
Page 23 of 34
Ausgabe
9, 07.12.2022
Issue
Transition Criteria
The conditions to enter the prototype development are
the availability of approved and authorized process in-
puts listed in workflow diagrams of chapter 3.1.
The prototype development is complete when its objec-
tives and the objectives of the supporting processes as-
sociated with it are satisfied approved by the perfor-
mance of the Verification Review (VR) in case of Com-
plex Components and the Critical Design Review (CDR)
in status “green” or “amber” each according to QG traffic
light control of PB-EN-60.
4.2.5 Production Transition Process
The objective of the production transition process is to
establish a baseline that includes all design and manu-
facturing data needed to support the consistent replica-
tion of the hardware item and that identifies the manu-
facturing requirements related to safety, to make a tran-
sition to production possible.
These data are represented within the manufacturing
document (BU).
Derived requirements, requirement omissions or errors
are fed back to the appropriate process for assessment
respective resolution of open points.
As soon as all transition criteria have been satisfied, the
series support process is entered.
(see PB-EN-50).
Roles, Inputs/Outputs and Activities
The fundamental roles and competencies are defined in
chapter 2.3.
The process-step specific inputs/outputs and activities
are defined in the process step (6) of workflow diagram
for the implementer in chapter 3.1.
Transition Criteria
The conditions to enter the production transition process
are the availability of approved and authorized process
inputs listed in workflow diagrams of chapter 3.1.
The production transition process is complete when its
objectives and the objectives of the supporting pro-
cesses associated with it are satisfied approved by the
 Hardware Entwicklungs-Prozess-Abläufe
Hardware Development-Process-Workflows
Device Integration Test Review (CCDITR) im Falle
von Complex Components und das Qualification
Review (QQ) im Status „grün“ oder „gelb“ gemäß QG
Ampelsteuerung der PB-EN-60 genehmigt worden ist.
4.3 Unterstützende Prozesse
Folgende unterstützende Prozesse sind definiert:
 Validation and Verification Process(4.3.1)
 Configuration Management Process (4.3.2)
 Process Assurance (4.3.3)
 Certification Liaison Process (4.3.4)
4.3.1 Validation and Verification Prozess
Das Ziel des Validation and Verification Prozess ist es,
sicher zu stellen, dass alle Anforderungen an die
Hardware korrekt und vollständig in Bezug auf die vor-
gegebenen Anforderungen auf System und
Equipment Ebene sind (Validation), und dass die Um-
setzung der Hardware alle Anforderungen erfüllt (Ve-
rifcation).
Der Validation and Verification Prozess beinhaltet da-
bei folgende Prozessschritte:
 Validation of Requirements Capture (4.3.1.1)
 Validation and Verification of Conceptual Design
(4.3.1.2)
 Validation and Verification of Detailed Design
(4.3.1.3)
 Verification of Pototype Development (4.3.1.4)
 Verification of Production Transition (4.3.1.5)
Im Zuge der Aktivitäten zum Validation and
Verification Prozesses werden die Hardware
spezifischen Anforderungen zur Functional
Robustness gemäß ABD0100 berücksichtigt und
damit die zugehörigen Zielsetzungen der PB-EN-30
unterstützt.
Außerdem erfolgt eine Unterstützung der Aktivitäten
zur Definition des Testkonzeptes, die in der PB-EN-30
beschrieben sind. Zur Synchronisation mit diesem
Prozess ist im Prozessschritt (4) der rollenspezifi-
schen Prozessflussdiagramme der Kapitel 3.1 bis 3.4
das Test Concept Review (TCR(EQ)) mit aufgeführt.
PB-EN-31
Seite 24 von 34
Page 24 of 34
Ausgabe
9, 07.12.2022
Issue
performance of the Complex Components Integration
Test Review (CCDITR) in case of Complex Compo-
nents and the Qualification Review (QQ) in status
“green” or “amber” according to QG traffic light control
of PB-EN-60.
4.3 Supporting Processes
The following supporting processes are defined:
 Validation and Verification (4.3.1)
 Configuration Management Process (4.3.2)
 Process Assurance (4.3.3)
 Certification Liaison Process (4.3.4)
4.3.1 Validation and Verification Process
The objective of the validation and verifcation process is
to ensure that all hardware requirements are correct and
complete with respect to the given requirements on sys-
tem and equipment level (Validation), and that the hard-
ware item implementation meets all of the hardware re-
quirements (Verification).
The validation and verification process includes follow-
ing process steps:
 Validation of Requirements Capture (4.3.1.2)
 Validation and Verification of Conceptual Design
(4.3.1.2)
 Validation and Verification of Detailed Design
(4.3.1.3)
 Verification of Prototype Development (4.3.1.4)
 Verification of Production Transition (4.3.1.5)
In the frame of validation and verification process the
hardware specific requirements related to functional
robustness according to ABD0100 are taken into
account supporting the respective objectives from
PB-EN-30.
In addition to that support is provided for the activities
on the definition of the test concept, as described in PB-
EN-30. To synchronize with that process, the Test Con-
cept Review (TCR(EQ)) is shown in process step (4)
within the role specific workflow diagrams given in chap-
ter 3.1 to 3.4.
 Hardware Entwicklungs-Prozess-Abläufe
Hardware Development-Process-Workflows
Die Ergebnisse des Validation and Verification Pro-
zesses werden dokumentiert und festgestellte offene
Punkte und Fehler werden an den jeweiligen Prozess
zur Lösung zurückgegeben.
Die Aktivitäten zum Validation and Verification Pro-
zess werde gemäß dem Harware Validation and Veri-
fication Plan (HVVP) durchgeführt.
Rollen, Inputs/Outputs und Aktivitäten
Die grundsätzlichen Rollen und Zuständigkeiten sind
in Kapitel 2.3 definiert.
Die prozessschritt-spezifischen Inputs/Outputs und
Aktivitäten sind in den Prozessschritten (2-6) des Pro-
zessflussdiagramms für den Verifier aus Kapitel 3.2
definiert.
Transitions-Kriterien
Die Bedingungen, um in den Validation and Verifica-
tion Prozess einzutreten, sind die Verfügbarkeit der
genehmigten und autorisierten Prozess-Inputs, wie im
Prozessflussdiagramm des Kapitels 3.2 aufgeführt.
Der Validation and Verification Prozess ist vollständig
durchgeführt, wenn seine Zielsetzungen erreicht, die
Zielsetzung der zugehörigen unterstützenden Pro-
zesse erfüllt und durch die Reviews, abgebildet im
Prozessflussdiagram des Verifiers in Kapitel 3.2 im
Status „grün“ oder „gelb“ gemäß QG Ampelsteuerung
der PB-EN-60 genehmigt worden sind.
4.3.1.1 Validation of Requirements Capture
Das Ziel der Validation of Requirements Capture ist
es, sicher zu stellen, dass die Anforderungen, die die
Basis für die anschließende Verifikation bilden, korrekt
und vollständig sind und dass derived und refined Re-
quirements bezüglich ihres Einflusses auf Sicherheits-
aspekte untersucht werden.
Zu diesem Zweck werden zunächst die Anforderun-
gen identifiziert, die einer Validierung bedürfen und
entsprechende Validierungsprozeduren definiert und
innerhalb der Hardware Validation and Verification
Cases and Procedures (HVVCP) dokumentiert. Da-
rauf aufbauend werden diese Prozeduren auf den
identifizierten Anforderungen ausgeführt und die Er-
gebnisse in den Hardware Validation and Verification
Results (HVVR) dokumentiert.
PB-EN-31
Seite 25 von 34
Page 25 of 34
Ausgabe
9, 07.12.2022
Issue
Results from the validation and verification process are
documented and found omissions and errors are trans-
ferred to the right process for correction.
The activities related to the validation and verification
process are performed in accordance with the Hard-
ware validation and Verification Plan (HVVP).
Roles, Inputs/Outputs and Activities
The fundamental roles and competencies are defined in
chapter 2.3.
The process-step specific inputs/outputs and activities
are defined in the process step (2-6) of workflow dia-
gram for the verifier in chapter 3.2.
Transition Criteria
The conditions to enter the validation and verification
process are the availability of process inputs listed in
workflow diagrams of chapter 3.2.
The validation and verification process is complete
when its objectives and the objectives of the supporting
processes associated with it are satisfied approved by
the performance of the associated reviews as shown in
the workflow diagram of the verifier in chapter 3.2, in
status “green” or “amber” according to QG traffic light
control of PB-EN-60.
4.3.1.1 Validation of Requirements Capture
The objective of validation of requirements capture is to
assure that the requirements against which the hard-
ware item is to be verified are correct and complete and
that derived and refined requirements are evaluated for
impact on safety.
For that purpose requirements that need to be validated
are first identified and respective validation procedures
are defined and documented within the Hardware Vali-
dation and Verification Cases and Procedures
(HVVCP). Based on that procedures are executed on
the requirements and results are documented within the
Hardware Validation and Verification Results (HVVR).
 Hardware Entwicklungs-Prozess-Abläufe
Hardware Development-Process-Workflows
Für traceable Requirements wird geprüft, in wie weit
sie auf die höher gelagerte Anforderungen bezüglich
der dokumentierten Beziehung und einer inhaltlichen
Übereinstimmung mit diesen Anforderungen zurück-
verfolgt werden können.
4.3.1.2 Validation and Verification of Conceptual
Design
Das Ziel der Validation and Verification of Conceptual
Design ist es, sicher zu stellen, dass das erstellte high-
level Design Konzept geeignet ist, festzustellen, ob die
resultierende Umsetzung die Anforderungen erfüllen
können wird und dass dieses Design Konzept in Über-
einstimmung mit den Anforderungen aufgestellt
wurde.
Zu diesem Zweck werden zunächst Review und Ana-
lyse Prozeduren als Teil der HVVCP erzeugt, die an-
schließend auf die Conceptual Design Data angewen-
det und deren Ergebnisse in den HVVR dokumentiert
werden.
Anforderungen, die aus den Aktivitäten zum Concep-
tual Design resultieren, werden einer Validierung un-
terzogen wie bereits in Kapitel 4.3.1.1 beschrieben.
4.3.1.3 Validation and Verification of Detailed
Design
Das Ziel der Validation and Verification of Detailed De-
sign ist es, sicher zu stellen, dass die erzeugten de-
taillierten Design Daten die Anforderungen erfüllen.
Zu diesem Zweck werden zunächst Review und Ana-
lyse Prozeduren erzeugt und innerhalb der HVVCP
dokumentiert, die anschließend auf die detaillierten
Design Daten angewendet und deren Ergebnisse in
den HVVR dokumentiert werden.
Zusätzlich werden in diesem Prozessschritt die Test-
prozeduren zur Verifikation der Hardwareumsetzung
erzeugt. Für diese Testprozeduren werden ebenfalls
Review und Analyse Prozeduren erzeugt. Testproze-
duren sowie Review und Analyseprozeduren werden
in den HVVCP dokumentiert, die Review und Analyse
Prozeduren auf den Testprozeduren ausgeführt und
die zugehörigen Ergebnisse in den HVVR dokumen-
tiert.
Dabei wird das Ziel verfolgt, zu verifizieren, dass die
Testprozeduren geeignet sind, die Erfüllung der Anfor-
derungen durch die Hardwareumsetzung tatsächlich
nachzuweisen.
PB-EN-31
Seite 26 von 34
Page 26 of 34
Ausgabe
9, 07.12.2022
Issue
With respect to traceable requirements it is checked
whether traceability to higher level requirements is given
in terms of general documented relation and a contex-
tual compliance to these requirements.
4.3.1.2 Validation and Verification of Conceptual
Design
The objective of validation and verification of conceptual
design is to assure that the produced high-level design
concept is adequate to determine the potential for the
resulting design implementation to meet the require-
ments and that the design concept has been set up in
compliance with the requirements.
For that purpose first review and analysis procedures
are set up as part of the HVVCP that are then performed
on the conceptual design data. Results are documented
within the HVVR.
Requirements resulting from the activities performed in
the scope of conceptual design undergo a validation as
described in chapter 4.3.1.1.
4.3.1.3 Validation and Verification of Detailed
Design
The objective of validation and verification of detailed
design is to assure that the generated detailed design
data satisfy the requirements.
For that purpose first review and analysis procedures
are set up within the HVVCP that are then performed on
the detailed design data. Results are documented within
the HVVR.
In addition to that during this process step test proce-
dures for the verification of the hardware item are gen-
erated. For these test procedures review and analysis
procedures are set up. Test procedures as well as re-
view and analysis procedures are documented within
the HVVCP, review and analysis procedures are exe-
cuted on the test procedures and results are docu-
mented within the HVVR.
The goal of this is to determine whether the test proce-
dures are adequate to actually prove the correct require-
ments implementation within the hardware item.
 Hardware Entwicklungs-Prozess-Abläufe
Hardware Development-Process-Workflows
Daneben werden die Kriterien für den Acceptance
Test definiert.
Außerdem werden Nachweise für die Traceability zwi-
schen Anforderungen und detailed Design Daten so-
wie zwischen Anforderungen und den Testprozeduren
erzeugt. Dies wird ebenfalls als Teil der HVVR doku-
mentiert
Anforderungen, die aus den Aktivitäten zum Detailed
Design resultieren, werden einer Validierung unterzo-
gen wie bereits in Kapitel 4.3.1.1 beschrieben.
4.3.1.4 Verification of Prototype Development
Das Ziel der Validation and Verification of Prototype
Development ist es, den Nachweis zu erbringen, dass
die Umsetzung der Hardware die Anforderungen er-
füllt.
Zu diesem Zweck wird die Hardware (Prototype) an
Hand der Testprozeduren getestet und die Ergebnisse
analysiert und bewertet.
Es wird der Nachweis zur Traceability zwischen detail-
lierten Design Daten und der Hardware Umsetzung,
so wie eine Gesamtzusammenfassung der Traceabi-
lity beginnend bei den Anforderungen, über die detail-
lierten Design Daten und die Verifikationsprozeduren
bis hin zu den Verifikationsergebnissen erzeugt.
Alle erzeugten Verifikations Ergebnisse werden zu
den HVVR hinzugefügt.
4.3.1.5 Verification of Production Transition
Das Ziel der Verification of Production Transition ist
es, sicher zu stellen, dass die auf Basis der Bauunter-
lage produziert Hardware die Anforderungen erfüllt.
Zu diesem Zweck wird Hardware an Hand der Test-
prozeduren getestet.
Außerdem wird in diesem Prozessschritt eine Analyse
zur Traceability und zur vollständigen Abdeckung
durch die Verification durchgeführt und nachgewie-
sen. Sowohl die Testergebnisse als auch die Analysis
zur Traceability wird Bestandteil der HVVR.
Anmerkung:
Gemäß 21.A.33(b)(c) und AMC 21.A.33 muss vor
Durchführung eines jeden Compliance Test festge-
stellt werden, dass der Prüfling und die Prüfumgebung
für eine bestimmte Prüfung geeignet sind. Die Konfor-
mitätsprüfung des Prüflings & Prüfumgebung wird
PB-EN-31
Seite 27 von 34
Page 27 of 34
Ausgabe
9, 07.12.2022
Issue
Besides that acceptance test criteria are produced.
Additionally evidence is generated to show the tracea-
bility between requirements and detailed design as well
as the traceability between requirements and test pro-
cedures. This is also documented as part of the HVVR.
Requirements resulting from the activities performed in
the scope of detailed design undergo a validation as de-
scribed in chapter 4.3.1.1.
4.3.1.4 Verification of Prototype Development
The objective of validation and verification of prototype
development is to provide evidence that the hardware
implementation meets the requirements.
For that purpose the hardware item (prototype) is tested
in accordance with the test procedures and test results
are analyses and evaluated.
A prove for traceability between detailed design data
and hardware implementation is produces as well as a
complete overview of traceability starting from require-
ments via detailed design data and verification proce-
dures ending up with verification results.
Any Verification results are added to the HVVR.
4.3.1.5 Verification of Production Transition
The objective of verification of production transition is to
assure that the hardware item produced on the basis of
the manufacturing document meets the requirements.
For that purpose hardware item is tested in accordance
with the test procedures.
In addition to that during this process step an analysis
on traceability and complete coverage by verification is
performed and documented.
Test results as well as the analysis on traceability will
become part of the HVVR.
Note:
As per 21.A.33(b)(c) and AMC 21.A.33, before any
compliance test is undertaken it shall be determined as
a precondition that the test specimen and the test envi-
ronment are adequate for a particular test. The conform-
ity inspection of the test specimen & test environment is
performed and the result as a statement of conformity
 Hardware Entwicklungs-Prozess-Abläufe
Hardware Development-Process-Workflows
durchgeführt und das Ergebnis als Konformitätserklä-
rung dokumentiert im ‚Berichts Konformitätserklärung
für Prüfling / Umgebung (RCS)‘.
4.3.2 Configuration Management Prozess
Das Ziel des Configuration Management Prozesses ist
die Konfigurationskontrolle der Hardware Life Cycle
Daten über den kompletten Hardware Life Cycle, um
damit sicher zu stellen, dass Konfigurationsdaten ein-
deutig identifiziert und dokumentiert sind, eine durch-
gängige und akkurate Reproduzierbarkeit der Daten
gewährleistet ist und eine kontrolliert Methode zur
Identifikation und Nachverfolgung von Änderungen an
Konfigurationsdaten vorhanden ist.
Zu diesem Zweck werden folgende Aktivitäten durch-
geführt:
 Unique Identification of Configuration items
 Baselining
 Problem Identification, Tracking and Reporting
 Change Control
 Release, Archive and Retrieval
Die CM Aktivitäten werden gemäß den Vorgaben des
Hardware Configuration Management Plan (HCMP)
durchgeführt. Die Ergebnisse des CM sowie die Ein-
haltung der CM Aktivitäten gemäß HCMP werden im
Hardware Configuration Management Record
(HCMR) dokumentiert.
Rollen, Inputs/Outputs und Aktivitäten
Die grundsätzlichen Rollen und Zuständigkeiten sind
in Kapitel 2.3 definiert.
Die prozessschritt-spezifischen Inputs/Outputs und
Aktivitäten sind in den Prozessschritten (1-9) des Pro-
zessflussdiagramms für den Configuration Manager
aus Kapitel 3.3 definiert.
Transitions-Kriterien
Die Bedingungen, um in den Configuration Manage-
ment Prozess einzutreten, sind die Verfügbarkeit der
genehmigten und autorisierten Prozess-Inputs, wie im
Prozessflussdiagramm des Kapitels 3.3 aufgeführt.
Der Configuration Management Prozess ist vollstän-
dig durchgeführt, wenn seine Zielsetzungen erreicht,
die Zielsetzung der zugehörigen unterstützenden Pro-
zesse erfüllt und durch die Reviews, abgebildet im
Prozessflussdiagram des Configuration Managers in
PB-EN-31
Seite 28 von 34
Page 28 of 34
Ausgabe
9, 07.12.2022
Issue
documented within the ‘Report Conformity Statement
for Test Specimen / Environment (RCS)’.
4.3.2 Configuration Management Process
The objective of configuration management process is
the configuration control of hardware life cycle data
throughout the complete hardware life cycle to assure
that configuration items are uniquely identified and doc-
umented, a consistent and accurate replication of data
is ensured and a controlled method of identifying and
tracking modification to configuration items is provided.
For that purpose following activities are performed:
 Unique identification of configuration items
 Baselining
 Problem Identification, Tracking and Reporting
 Change Control
 Release, Archive and Retrieval
CM activities are performed in accordance with the
Hardware configuration Management Plan (HCMP). CM
activity results and the compliance of CM activities with
the HCMP are documented within the Hardware Config-
uration Management Record (HCMR).
Roles, Inputs/Outputs and Activities
The fundamental roles and competencies are defined in
chapter 2.3.
The process-step specific inputs/outputs and activities
are defined in the process steps (1-9) of workflow
diagram for the configuration manager in chapter 3.3.
Transition Criteria
The conditions to enter the configuration management
process are the availability of approved and authorized
process inputs listed in workflow diagrams of chapter
3.3.
The configuration management process is complete
when its objectives and the objectives of the supporting
processes associated with it are satisfied approved by
the performance of the associated reviews as shown in
the workflow diagram of the configuration manager in
 Hardware Entwicklungs-Prozess-Abläufe
Hardware Development-Process-Workflows
Kapitel 3.3 im Status „grün“ oder „gelb“ gemäß QG
Ampelsteuerung der PB-EN-60 genehmigt worden
sind.
4.3.3 Process Assurance
Das Ziel der Process Assurance ist es, sicher zu stel-
len, dass die Ziele der Hardware Design Life Cycle
Prozesse erreicht werden, und dass die Aktivitäten,
wie in den Plänen beschrieben, abgeschlossen oder
Abweichungen identifiziert, dokumentiert und adres-
siert wurden. Im Einzelnen führen die Aktivitäten dazu,
dass die Ausführung der Life Cycle Prozesse in Über-
einstimmung mit den abgestimmten Plänen erfolgt, die
erzeugten Hardware Design Life Cycle Daten diesen
Plänen entsprechen, und dass die Hardware auf Basis
der zugehörigen Life Cycle Data erzeugt wird.
Die Process Assurance Aktivitäten werde gemäß dem
Hardware Process Assurance Plan (HPAP) durchge-
führt. Die Ergebnisse der Process Assurance Aktivitä-
ten sowie ihre Einhaltung gemäß HPAP werden im
Hardware Process Assurance Record (HPAR) doku-
mentiert.
Zentraler Bestandteil der Process Assurance Aktivitä-
ten ist die Durchführung von Quality Gates wie in den
Prozessflussdiagrammen der Kapitel 3.1 bis 3.4 auf-
geführt. Die Quality Gates begleiten den gesamten
Hardware Design Life Cycle und dienen dazu, die Er-
reichung der Zielsetzung der Process Assurance zu
überprüfen und zu dokumentieren. Diese Quality Ga-
tes schließen die zugehörige Prozessphase ab und
genehmigen damit den Eintritt in die jeweils folgende.
Dabei unterscheiden sich die Quality Gates in solche
die eindeutig dem Hardware Entwicklungsprozess zu-
geordnet sind und solche die im Rahmen der
Equipment Entwicklung gemäß PB-EN-30 durchge-
führt werden und die Aspekte zur Hardwareentwick-
lung mit abdecken.
Im Zuge der Entwicklung von Complex Components
sind spezielle zusätzliche Quality Gates gemäß
ABD0100.2.11 Kapitel 5 vorgesehen.
Rollen, Inputs/Outputs und Aktivitäten
Die grundsätzlichen Rollen und Zuständigkeiten sind
in Kapitel 2.3 definiert.
Die prozess-spezifischen Inputs/Outputs und Aktivitä-
ten sind in den Prozessschritten (1-9) des Prozess-
flussdiagramms für die Process Assurance aus Kapi-
tel 3.4 definiert.
PB-EN-31
Seite 29 von 34
Page 29 of 34
Ausgabe
9, 07.12.2022
Issue
chapter 3.3, in status “green” or “amber” according to
QG traffic light control of PB-EN-60.
4.3.3 Process Assurance
The objective of process assurance is to ensure that the
hardware design life cycle objectives are met and that
activities have been completed as outlined in the plans
or deviations have been identified, documented and ad-
dressed. In particular the activities lead to the fact that
life cycle processes comply with the approved plans, the
produced hardware design life cycle data complies with
the plans and that the hardware item is built to comply
with the associated life cycle data.
Process assurance activities are performed in accord-
ance with the Hardware Process Assurance Plan
(HPAP). Process assurance activity results and their
compliance to the HPAP are documented within the
Hardware Process Assurance Record (HPAR).
Central part of process assurance activities is the per-
formance of quality gates as shown in the workflow dia-
grams of chapter 3.1 to chapter 3.4. The quality gates
go along with the complete hardware design life cycle
and serve to evaluate and document the degree of
achievement for process assurance objectives. These
quality gates terminate the related process phase and
grant access for the phase to follow.The quality gates
are distinguished to those uniquely allocated to the
hardware development process and those that are per-
formed in the frame of the equipment development pro-
cess according to PB-EN-30 covering the aspects re-
lated to hardware development.
With relation to complex components development spe-
cial additional quality gates are foreseen in accordance
with ABD0100.2.11 chapter 5.
Roles, Inputs/Outputs and Activities
The fundamental roles and competencies are defined in
chapter 2.3.
The process-step specific inputs/outputs and activities
are defined in the process step (1-9) of workflow
diagram for the process assurance in chapter 3.4.
 Hardware Entwicklungs-Prozess-Abläufe
Hardware Development-Process-Workflows
Transitions-Kriterien
Die Bedingungen, um in den Process Assurance Pro-
zess einzutreten, sind die Verfügbarkeit der geneh-
migten und autorisierten Prozess-Inputs, wie im Pro-
zessflussdiagramm des Kapitels 3.4 aufgeführt.
Der Process Assurance Prozess ist vollständig durch-
geführt, wenn seine Zielsetzungen erreicht, die Ziel-
setzung der zugehörigen unterstützenden Prozesse
erfüllt und durch die Reviews, abgebildet im Prozess-
flussdiagram der Process Assurance in Kapitel 3.4 im
Status „grün“ oder „gelb“ gemäß QG Ampelsteuerung
der PB-EN-60 genehmigt worden sind.
4.3.4 Certification Liaison Prozess
Das Ziel des Certification Liaison Prozesses ist es, die
Kommunikation und die Abstimmung mit den zustän-
digen Zulassungsdienststellen während des gesam-
ten Hardware Design Life Cycle im Rahmen der Zu-
lassungsaktivitäten zu unterstützen.
Anmerkung: Zuständige Zulassungsdienststellen kön-
nen beispielsweise eine Behörde, wie die EASA, oder
auch EASA zugelassene Design Organisationen sein.
Zu diesem Zweck erfolgt ein direkter Austausch mit
dem entsprechenden Prozessschritt aus dem
Equipment Entwicklung Prozess gemäß PB-EN-30, in
dem die zertifizierungsrelevanten Daten gesammelt
und zur Überstellung an die zuständigen Zulassungs-
dienststellen vorbereitet werden.
Zum Beginn des Certification Liaison Prozess wird der
Plan for Hardware Aspects of Certification (PHAC) er-
stellt und den zuständigen Zulassungsdienststellen
zum Review überstellt. Er bildet die Basis für die Dar-
stellung der geplanten Aktivitäten zur Erreichung der
Übereinstimmung mit den Zertifizierungsanforderun-
gen und ist mit den zuständigen Zulassungsdienststel-
len abzustimmen.
Zum Abschluss der Hardware Design Aktivitäten wird
eine Zusammenfassung im Hardware Accomplish-
ment Summary (HAS) erstellt. Dieses Dokument ent-
hält eine Darstellung der ausgeführten Prozesse, der
produzierten Outputs und des Status der erzeugten
Hardware.
PB-EN-31
Seite 30 von 34
Page 30 of 34
Ausgabe
9, 07.12.2022
Issue
Transition Criteria
The conditions to enter the process assurance process
are the availability of process inputs listed in workflow
diagrams of chapter 3.4.
The process assurance process is complete when its
objectives and the objectives of the supporting pro-
cesses associated with it are satisfied approved by the
performance of the associated reviews as shown in the
workflow diagram of the configuration manager in chap-
ter 3.4, in status “green” or “amber” according to QG
traffic light control of PB-EN-60.
4.3.4 Certification Liaison Process
The objective of the certification liaison process is to sup-
port communication and understanding with the compe-
tent certification authorities throughout the complete hard-
ware design life cycle in the scope of certification activi-
ties.
Note: For instance, competent certification authorities
might be either an agency like the EASA or an EASA ap-
proved Design Organization.
For that purpose there is a direct exchange with the re-
spective process step from the equipment development
process according to PB-EN-30 that serves to collect and
prepare the data relevant for certification purpose for fur-
ther provision to competent certification authorities.
At the start of certification liaison process the Plan for
Hardware Aspects of Certification (PHAC) is generated
and provided to the competent certification authorities for
review. The PHAC is the basic document to line out the
planned activities to be performed to reach compliance
with the certification basis and needs to be agreed with
the competent certification authorities.
At completion of hardware design activities a summary is
generated within the Hardware Accomplishment Sum-
mary (HAS). This document contains a lineout of pro-
cesses performed, outputs produces and a status for the
generated hardware item.
 Hardware Entwicklungs-Prozess-Abläufe
PB-EN-31
Seite 31 von 34
Hardware Development-Process-Workflows Page 31 of 34
Ausgabe
9, 07.12.2022
Issue

Rollen, Inputs/Outputs und Aktivitäten Roles, Inputs/Outputs and Activities

Die grundsätzlichen Rollen und Zuständigkeiten sind
in Kapitel 2.3 definiert.
Die prozessschritt-spezifischen Inputs/Outputs und
Aktivitäten sind in den Prozessschritten (1, 7-9) des
der betreffenden Prozessflussdiagramme in den Kapi-
teln 3.1 bis 3.4 definiert.
The fundamental roles and competencies are defined in
chapter 2.3.
The process-step specific inputs/outputs and activities are
defined in the process steps (1, 7-9) of the respective
workflow diagrams in chapters 3.1 to 3.4.

Transitions-Kriterien Transition Criteria

Die Bedingungen, um in den Certification Liaison Pro-
zess einzutreten, sind die Verfügbarkeit der geneh-
migten und autorisierten Prozess-Inputs, wie in den
Prozessflussdiagrammen in Kapitel 3.1 bis 3.4 aufge-
führt.
Der Certification Liaison Prozess ist vollständig durch-
geführt, wenn seine Zielsetzungen erreicht, die Ziel-
setzung der zugehörigen unterstützenden Prozesse
erfüllt und durch die Reviews, abgebildet in den Pro-
zessflussdiagrammen in Kapitel 3.1 bis 3.4 im Status
„grün“ oder „gelb“ gemäß QG Ampelsteuerung der
PB-EN-60 genehmigt worden sind.
The conditions to enter the certification liaison process are
the availability of approved and authorized process inputs
listed in workflow diagrams of chapters 3.1 to 3.4.
The certification liaison process is complete when its ob-
jectives and the objectives of the supporting processes as-
sociated with it are satisfied approved by the performance
of the associated reviews as shown in the workflow dia-
grams of the chapters 3.1 to 3.4 in status “green” or “am-
ber” according to QG traffic light control of PB-EN-60.
 Hardware Entwicklungs-Prozess-Abläufe
PB-EN-31
Seite 32 von 34
Hardware Development-Process-Workflows Page 32 of 34
Ausgabe
9, 07.12.2022
Issue

5 Mitgeltende Unterlagen 5 Associated Documents

Die nachfolgenden Dokumente gelten jeweils in der ak- The following documents apply in the current form.
tuellen Form.

ABD0100 Equipment- Design General Re- ABD0100 Equipment- Design General

quirements For Suppliers Requirements For Suppliers

DO-160 Environmental Conditions and Test DO-160 Environmental Conditions and Test
Procedures for Airborne Equipment Procedures for Airborne Equipment

DO-254 Design assurance guidance for DO-254 Design assurance guidance for
airborne electronic hardware airborne electronic hardware

PB-EN-30 Equipment Entwicklungs-Prozess- PB-EN-30 Equipment Development-Process-

Abläufe Workflows
PB-EN-50 Serienüberleitung / Serien Betreuung PB-EN-50 Production Transfer / Series Support

PB-EN-60 Qualitätsmanagement PB-EN-60 Quality Management

im AIRBUS BUX Engineering at AIRBUS BUX Engineering

PB-EN-61 Partnummerndefinition PB-EN-61 Partnumber definition

PB-EN-62 Prozess zur Organisation der PB-EN-62 Process for Organization of

Entwicklungsdokumente Engineering Documentation

PB-IM-06 Exportkontrolle am Standort Buxtehude PB-IM-06 Export control at Buxtehude site

PV-EN-63 Verbesserungsprozess PV-EN-63 Improvement Process

PV-EN-02 Bauteilfreigabe und PV-EN-02 Component Release and Notification of

Bauteilabkündigung Obsolescence

TBCKE- COTS Management Plan (COTS-MP) TBCKE- COTS Management Plan (COTS-MP)
5921/12 5921/12

ECYE- Security Management and ECYE- Security Management and

6133/13 Development Plan (SMDP) 6133/13 Development Plan (SMDP)

ECYE- Electronic Components Management ECYE- Electronic Components Management

6165/13 Plan (ECMP) 6165/13 Plan (ECMP)

EASA Part 21 Airworthiness and Environmental EASA Part 21 Airworthiness and Environmental
Certification Certification
 Hardware Entwicklungs-Prozess-Abläufe
PB-EN-31
Seite 33 von 34
Hardware Development-Process-Workflows Page 33 of 34
Ausgabe
9, 07.12.2022
Issue

6 Änderungsverzeichnis 6 Record of Revision

Ausgabe / Issue Datum / Date Änderungsgrund / Reason for Revision

5 15.12.2014 Anpassung Unterschriftenseite
Anpassung 1.Verfahrenssteckbrief
Anpassung 3.1 (5) in Graphik, Kästchen blau PtR(EQ) in Kästchen weiss
PB-EN-30 (4.2) verschoben
Kapitel 6 neu
Anpassung komplett an KPB-EN-31

Revision of signature page

Revision of 1.Procedure summary
Revision of 3.1 (5) in graphic, box blue PtR(EQ) moved into box white
PB-EN-30 (4.2)
Chapter 6 new
Revision of all according to KPB-EN-31

6 21.12.2015 Anpassung an PB-IM-01 (Prozesssteckbrief)

Entfall der PQA Unterschrift auf den Dokumenten (Kapitel 3.4)
Detaillierung der zuständigen Zulassungsdienststellen (Kapitel 4.3.4)

Update according PB-IM-01 (Process summary)

Removal of PQA signature on documents (chapter 3.4)
Detailing of competent certification authorities (chapter 4.3.4)

7 29.10.2018 Anpassung Unterschriftenseite

Kapitel 2.1 Exportkontrolle Prozess eingefügt
Kapitel 5 PB-IM-06 referenziert

Revision of signature page

Chapter 2.1 Export control process added
Chapter 5 PB-IM-06 referenced

8 09.07.2021 diverse Seiten: redaktionelle Änderungen;

diverse Seiten: Schreibfehler korrigiert;
Signatur Seite: Anpassungen durchgeführt;
Kapitel 2.3, 3. PQA ersetzt durch PQR (Product Quality Responsible);
Kapitel 2.3, 3.4 DQA Rolle entfernt;
Kapitel 3. Referenzen generalisiert wegen Einführung ABD0100g2;
Kapitel 3.2 PCS eingeführt wegen Konformität zu
4.3.1.5 EU Part 21 Requirement 21.A.33(b)(c);
Kapitel 3.5 Tools hinzugefügt;
Kapitel 5. Referenz hinzugefügt.

specific pages editorial changes;

specific pages typos corrected;
signature page adaptations done;
chapter 2.3, 3. PQA replaced by PQR (Product Quality Responsible);
chapter 2.3, 3.4 DQA role removed;
chapter 3. References generalized due to introduction ABD0100g2;
 Hardware Entwicklungs-Prozess-Abläufe
PB-EN-31
Seite 34 von 34
Hardware Development-Process-Workflows Page 34 of 34
Ausgabe
9, 07.12.2022
Issue

chapter 3.2 PCS introduced due to conformity to

4.3.1.5 EU Part21 Requirement 21.A.33(b)(c);
chapter 3.5 Tools added;
chapter 5. Reference added.

9 07.12.2022 Kapitel 3.1

4.2.3 Ergänzung des ECMR

Chapter 3.1
4.2.3. Insert of ECMR