Software-Qualifikation des Luftfahrtriebwerks TP400Dipl.-Ing. Ralf Homburg, System-Validerungsingenieur, Ass. Projektltg MTU Aero Engines AG, München
Vortrag im Rahmen des Q-Event `08 Donnerstag, 4. September 2008 Hotel Astoria, Luzern (CH)
1. Reglerentwicklung bei MTU: Ein kurzer Aufriss der Historie
2. Software Zulassung: SOI Prozess (nach RTCA - DO 178B)
3. Triebwerk TP400: Kurzüberblick und das CMS Regelsystem
4 Erstellung der TP400 Triebwerks-Regler Software
Vortragsübersicht
4. September 2008 Software-Qualifikation des Luftfahrtriebwerks TP400 (R. Homburg, MTU Aero Engines AG, München) 2Allgemeine Programmsituation
4. Erstellung der TP400 Triebwerks Regler Software
5. Validierung der TP400 Regler Software: generelle Testverfahren
6. TP400 SW Qualifikation: EASA Behördenprozess, Fehler Tracking mit PRs
7. Zusammenfassung & Schlussbemerkung
MTU is the Leading European Company for Military Engine Controls & Monitoring
��200��200
��400 �����1�143 � 0 ������
��400 �����1�143 � 0 ������
���390�
����
�150�700 �
0 ������
���390�
����
�150�700 �
0 ������
MTU Triebwerksregler: Historische Entwicklung vom RB199 bis zur MTR390 ECMU
EPMU = engine protection and monitoring unit
4. September 2008 Software-Qualifikation des Luftfahrtriebwerks TP400 (R. Homburg, MTU Aero Engines AG, München) 3
(x / y) Units in order book / delivered until 2/2008 EPMU = engine protection and monitoring unit(*) plus 150 – 700 for enhanced version Units MTR390E depending on orders to be received
1970 1980 1990 2000 2010
��199 ���� 2000
��200 �������400
������
��199 ����
������
��199 ����
��199 ���� 2020��200
����
���390� ����
��199
���� 2000 �
2020
�893 � 683 ������
��199
���� 2000 �
2020
�893 � 683 ������
��200
���� � �����
�1�361 � 502
������
��200
���� � �����
�1�361 � 502
������
EJ200 SW
TP400 SW *
Factor: TP400 / EJ200
Number of SW - Functions 1240 2415 1.9No of Lines of Code 62.000 142.000 2.3SW supported Input/Output Signals (sensors, actuators, bus systems) 100 1200 12
(*) SW for ECU + EPMUECU = Engine Control Unit
(HW produced by Hispan-Suiza not by MTU)
EJ200 DECMU(HW + SW)
TP400 EPMU SW + HW development
2) Electronic EquipmentDevelopment, Series
Production, MRO
1) System Design and Validation &Accessories
Development
Engine Controls Department: 4 main cornerstones
4. September 2008 Software-Qualifikation des Luftfahrtriebwerks TP400 (R. Homburg, MTU Aero Engines AG, München) 4
Technology projects (MEE)
Actuators: e.g. TP400 VSV
SW development and qualification (e.g. ECU
AS SW for TP400)
3) Embedded Software Development 4) Test Systems
Development, Production and MRO of
Engine Control and Monitoring Systems
System Design and Validation
Definition, design, development and certification of safety critical control and monitoring systems
Participation in definition of specifications for control system components like control
it t t d ECUEPMU
WARNINGS
CAUTIONS
ADVISORIES
ASSOCIATED
PROCEDURES
STATUS
INFO
AIRCRAFT
4. September 2008 Software-Qualifikation des Luftfahrtriebwerks TP400 (R. Homburg, MTU Aero Engines AG, München) 5
units, sensors, actuators and ground support systems
Integration, test and validation of all control systems on dry rigs, wet rigs and engine test beds
Support of engine flight test and product support for the complete control system
Nacelle area - left view
HBVAUsECU
FMU
VSVA
PCM
ECU
PCM HBVAUs VSVA FMU
1. Reglerentwicklung bei MTU: Ein kurzer Aufriss der Historie
2. Software Zulassung: SOI Prozess (nach RTCA - DO 178B)
3. Triebwerk TP400: Kurzüberblick und das CMS Regelsystem
4 Erstellung der TP400 Triebwerks-Regler Software
Vortragsübersicht
4. September 2008 Software-Qualifikation des Luftfahrtriebwerks TP400 (R. Homburg, MTU Aero Engines AG, München) 6Allgemeine Programmsituation
4. Erstellung der TP400 Triebwerks Regler Software
5. Validierung der TP400 Regler Software: generelle Testverfahren
6. TP400 SW Qualifikation: EASA Behördenprozess, Fehler Tracking mit PRs
7. Zusammenfassung & Schlussbemerkung
SW Qualification Engine Certification
What is Software in aerospace world• documentation ( SRS, Design Documentation, Source Code, Test Procedures /Results)• evidence that its exists ( Verification Reviews)
• evidence that it functions ( Review evidence, Analysis and Test evidence)
What is SW Qualification • Compliance with defined processes (e.g. RTCA DO178B), the required reviews, documents and
verification evidence.
4. September 2008 Software-Qualifikation des Luftfahrtriebwerks TP400 (R. Homburg, MTU Aero Engines AG, München) 7
• N.B. SW test does not guarantee 100% error free code - adherence to process steps should ensure that the number of errors introduced is as low as humanely possible i.e. adherence to the process and evidence that it has been applied properly is the only means to obtain a SW baseline for engine certification. (exception can be claimed via heritage).
What does Certification cover • SW alone is not Certifiable !!!
• SW qualification baseline should form part of the Engine Certification baseline. i.e. the SW to be flown shall be qualified and shall be part of the engine standard used during Certification testing.
EASA SW qualificiation process – Main stages to pass
EASA SW Qualification Process is based on RTCA DO 178 B “ Software Considerations for Airborne Systems and Equipment Certification”
EASA SW Qualification Process involves 4 formal reviews (Stage of Involvement) to ensure compliance with the SW Qualification process.
• SOI#1 – Planning Review
EASA SW qualificiation process
4. September 2008 Software-Qualifikation des Luftfahrtriebwerks TP400 (R. Homburg, MTU Aero Engines AG, München) 8
• SOI#2 – Development Review• SOI#3 – Verification Review• SOI#4 – Final Review
For each SOI the review documentation has to be provided ca. 4 weeks in advance and each review takes some 2 – 3 days using live data and examples to demonstrate compliance.
Completion of review and hence qualification is only granted when all findings are resolved. Min 2 weeks after review.
1 2 3 4 5 6 7 8 9 10 11 12-16
Typical timescales for SW qualification
definition of Requirements SW qualification. incl. SOI –Review cycleSW implementation & coding
System Freeze
T0
Software Freeze
T1
Data Freeze
T2
SRS delivery
T3
SW enginerelease
T5
SW qualified for Flight
T6
SW Iron Bird delivery
T4
min 5 – up to 9 Months min 2 -
SW qualification on EASA SOI process: a long path to follow on a maturing SW baseline
4. September 2008 Software-Qualifikation des Luftfahrtriebwerks TP400 (R. Homburg, MTU Aero Engines AG, München) 9
SOI#3SOI#2 SOI#4
min 5 up to 9 Months min 2 up to 6 Months
Milestone explanation:
• T0: system Freeze: freeze of system requirements
• T1: Software Freeze: detailed requirements allowing to start SW design, logic fixed
• T2: Data Freeze: constants and data fields defined
• T3: SW requirements spec is available, SW build generation starts
• T4: Delivery of SW code for engineering purpose (Rig Tests, Iron Bird tests)
• T5: Delivery of pre-qualified SW for engine test
• T6: Delivery of qualified SW for Flight use (after SOI process closure)
Documentation Required for SOI Example of check matrix
e.g. Step 1: Documents prepared for planning review
D t ccep
ted
evie
w
eliv
erab
le
vaila
ble
for
spec
tion
R k
SW Documentation required for SOI process
4. September 2008 Software-Qualifikation des Luftfahrtriebwerks TP400 (R. Homburg, MTU Aero Engines AG, München) 10
Document Ac Re De Av in RemarkPlan for SW Aspects of Certification (ECU AS) X X Issue 3 provided (June 2008)Plan for SW Aspects of Certification (EPMU SW) X X Issue 3 provided (June 2008)Software Development Plan (SDP) X X Issue 2 provided (June 2008)Software Verification Plan (SVP) X X Issue 2 provided (June 2008)Software Configuration Management Plan (SCMP) X X covered by company process + SDPSoftware Quality Assurance Plan (SQAP) X X Issue 2 provided (April 2007)
1. Reglerentwicklung bei MTU: Ein kurzer Aufriss der Historie
2. Software Zulassung: SOI Prozess (nach RTCA - DO 178B)
3. Triebwerk TP400: Kurzüberblick und das CMS Regelsystem
4 Erstellung der TP400 Triebwerks-Regler Software
Vortragsübersicht
4. September 2008 Software-Qualifikation des Luftfahrtriebwerks TP400 (R. Homburg, MTU Aero Engines AG, München) 11Allgemeine Programmsituation
4. Erstellung der TP400 Triebwerks Regler Software
5. Validierung der TP400 Regler Software: generelle Testverfahren
6. TP400 SW Qualifikation: EASA Behördenprozess, Fehler Tracking mit PRs
7. Zusammenfassung & Schlussbemerkung
TP400 – Governmental and Industrial Organization
A400M Military transport aircraft
EPI – Europrop
AMSL
TP400 Propeller engine for A400M
RFHS Propeller
4. September 2008 Software-Qualifikation des Luftfahrtriebwerks TP400 (R. Homburg, MTU Aero Engines AG, München) 12
• EPI (Engine) and RFHS (Propeller) are subcontractors from EADS CASA / AMSL
Prop engineEPI: TP400
EPI EuropropTP 400 engine
RR SNMTU ITP
HSMTU RR*
CMS (Control and Monitoring SW)
*only Sensor HW, no
System WS
- ECU / - EPMU SW- EPMU HW- Fuel acc.- Sys Rquts.
- ECU HW+OS SW- Fuel Sys HW
TP400 engine – side view with major CMS relevant components
TP400 propeller engine
ECU (FADEC) controller
- measures all relevant turbo machinery pressures and temperatures + propeller pitch and speed
- commands required fuel flow and controls all spools speeds
4. September 2008 Software-Qualifikation des Luftfahrtriebwerks TP400 (R. Homburg, MTU Aero Engines AG, München) 13
For information only
HBCUs ECU(FADEC)
FMU VSVAPCM(RFHS)
AuxiliaryFeatherPump
(RFHS)
and propeller speed incl pitch blade angle
- FADEC (ECU) controls pilot commanded thrust, main interface to all A/C systems
- EPMU protect engine + prop (overspeed) and secures safe aircraft operation (thrust) (*)
EPMU [within upper pylon compartement]
1. Reglerentwicklung bei MTU: Ein kurzer Aufriss der Historie
2. Software Zulassung: SOI Prozess (nach RTCA - DO 178B)
3. Triebwerk TP400: Kurzüberblick und das CMS Regelsystem
4 Erstellung der TP400 Triebwerks-Regler Software
Vortragsübersicht
4. September 2008 Software-Qualifikation des Luftfahrtriebwerks TP400 (R. Homburg, MTU Aero Engines AG, München) 14Allgemeine Programmsituation
4. Erstellung der TP400 Triebwerks Regler Software
5. Validierung der TP400 Regler Software: generelle Testverfahren
6. TP400 SW Qualifikation: EASA Behördenprozess, Fehler Tracking mit PRs
7. Zusammenfassung & Schlussbemerkung
Typical SW Development in “V” process shape from Top level stakeholder requirements down to SW and upwards
PCMSyDDCMSyTRD
Propeller& Engine
´Stakeholder requirements
AMSL CustomerStakeholder
Requirements Exhibits A9
SystemRequirements/
Derived SafetyRequirements
Compliance to Top Level Stakeholder RequirementsRequirements
System Integration Testing
Engine TestIRON BIRD
Test
S IT T t
Aircraft TestFTB,
A400M flight testAircraft & Propeller
Requirements
Aircraft certification level
Engine certification level
Compliance to Aircraft Stakeholder Requirements
4. September 2008 Software-Qualifikation des Luftfahrtriebwerks TP400 (R. Homburg, MTU Aero Engines AG, München) 15
1. A400M aircraft requires a certified engine and propeller (separate certifications)2. Engine CERT requires qualified CMS (Control and monitoring) System3. CMS Qualification requires a flight qualified control SW (for civil regulations: EASA SOI process)
Requirements/Design
Description
Requirements(EquipmentBudgets)
SRS SW Requirements
spec
HW Requirements (EPMU, ECU,
Sensors,…)
SW Design
SAT TestsSW acceptance tests
Low-Level SW testsHW Design HSI testUnit test
SDDLow Level SCs
SyIT TestsSW qualification level
Requirements flow-down
Validation & Test evidence flow -
upwards
MTU Software Development Process: two ways from SW Design to Coding
SDE Konstanten
Name Wert Einheit Datentyp Beschreibung Vorkomma Nachkomma hartTRUE 1 BOOL True 1 0 1FALSE 0 BOOL False 1 0 0CYCLE_TIME 0.05 s ES ZyklendauerEPS_ES 0.0000000000022204 ESNEG_EPS_ES -0.0000000000022204 ESType specific limitsinf 65536 ESMAX_VAL_ES 10000000000000000000000000000000000000 ESMAX_VAL_EI 16383 EIMAX_VAL_ELI 1073741823 ELIMAX_EUI_SHIFT 15 EUIMAX_VAL_EUI 32767 EUIMAX_EULI_SHIFT 31 EULIMAX_VAL_EULI 2147484000000000 EULIMAX_VAL_BOOL 1 BOOLMIN_VAL_ES -10000000000000000000000000000000000000 ESMIN_VAL_EI -16383 EIMIN_VAL_ELI -1073741823 ELIMIN_VAL_EUI 0 EUIMIN_VAL_EULI 0 EULIMINVAL BOOL 0 BOOL
Genauigkeit M
Data Object DatabaseSoftware Design
LibrariesSpecification
SoftwareDesign
Manual code Automated code from MatLAB
Simulink
4. September 2008 Software-Qualifikation des Luftfahrtriebwerks TP400 (R. Homburg, MTU Aero Engines AG, München) 16
No difference between both approaches regarding programming standards• Minor relaxations for AutoCode (e.g. regarding maintainability of code)Results from both branches undergo the same verification steps, based on the same rules
No formal qualification of the AutoCoding tool
MIN_VAL_BOOL 0 BOOLMAX_VAL_WORD 65535 WORDMIN_VAL_WORD 0 WORDMAX_WORD_SHIFT 15 WORDType specific basic values
SourceCode
SourceCode
SourceCodeSource
Code
SourceCode
SourceCode
IntegrationCompilation
Linking
1. Reglerentwicklung bei MTU: Ein kurzer Aufriss der Historie
2. Software Zulassung: SOI Prozess (nach RTCA - DO 178B)
3. Triebwerk TP400: Kurzüberblick und das CMS Regelsystem
4 Erstellung der TP400 Triebwerks-Regler Software
Vortragsübersicht
4. September 2008 Software-Qualifikation des Luftfahrtriebwerks TP400 (R. Homburg, MTU Aero Engines AG, München) 17Allgemeine Programmsituation
4. Erstellung der TP400 Triebwerks Regler Software
5. Validierung der TP400 Regler Software: generelle Testverfahren
6. TP400 SW Qualifikation: EASA Behördenprozess, Fehler Tracking mit PRs
7. Zusammenfassung & Schlussbemerkung
Basic test system set-up (encapsulated in blue) Dry Rig Add. mechanical components (encapsulated in red) Wet Rig
Testsystem ECU
Control Station DMSU Download, Monitoring an Set-Up Unit
Dry Rig Test system
MTU Software Development Process: Software acceptance Testing (SAT)
4. September 2008 Software-Qualifikation des Luftfahrtriebwerks TP400 (R. Homburg, MTU Aero Engines AG, München) 18
yTP400 powerplant
simulation incl. simulation of A/C
interfaces EPMU
Wet Rig AccessoriesVSVA, FMU, Fuel Pump, Fuel Filter, FCOC, PMA
Wet Rig specific
TP400-D6 CMS Dry Rig for - SW acceptance testing [SAT]- System integration testing [SyIT
Test-system
DMSU
Loads
TP400-D6 CMS Testsystem
4. September 2008 Software-Qualifikation des Luftfahrtriebwerks TP400 (R. Homburg, MTU Aero Engines AG, München) 19
Control Station (right)DMSU Monitor (left)ECU /
EPMU power supplies
breakout panelsincl. I/O interfaces
simulation computer
AFDX computer
Data visualization Testsystem (automatic script)
Testsystem / monitor for automatic test scripts
List of test scripts
Number of test script failures
4. September 2008 Software-Qualifikation des Luftfahrtriebwerks TP400 (R. Homburg, MTU Aero Engines AG, München) 20
Test Case 10 of actual script
TP400-D6 CMS Wet Rig Set-Up
VSVA
Gearbox
FCOC
4. September 2008 Software-Qualifikation des Luftfahrtriebwerks TP400 (R. Homburg, MTU Aero Engines AG, München) 21
Combustion chamber simulator
MFPFMU
VSVA loading device
1. Reglerentwicklung bei MTU: Ein kurzer Aufriss der Historie
2. Software Zulassung: SOI Prozess (nach RTCA - DO 178B)
3. Triebwerk TP400: Kurzüberblick und das CMS Regelsystem
4 Erstellung der TP400 Triebwerks-Regler Software
Vortragsübersicht
4. September 2008 Software-Qualifikation des Luftfahrtriebwerks TP400 (R. Homburg, MTU Aero Engines AG, München) 22Allgemeine Programmsituation
4. Erstellung der TP400 Triebwerks Regler Software
5. Validierung der TP400 Regler Software: generelle Testverfahren
6. TP400 SW Qualifikation: EASA Behördenprozess, Fehler Tracking mit PRs
7. Zusammenfassung & Schlussbemerkung
Staged SW development and testing appropriate mean to follow SOI and functional evolution in parallel
ON
FFS 1.0only IB
FFS 1.1 Release for IRON BIRD
FFS 1.2for IB/ ETP
FFS 1.x Flight rel.
Limited FFS Fcts FFS1.2 baselineFFS Functionality• Generic Function (I/Os, A/C buses, El. power
SW Build x
SW Build y
SAME SOFTWARE
SW Version
SW Buildincl. Reviews
of SOI process
FFS1.1 Baselinel P h
4. September 2008 Software-Qualifikation des Luftfahrtriebwerks TP400 (R. Homburg, MTU Aero Engines AG, München) 23
FUN
CTI
OTE
ST
SAT
SyIT
ETP version
MVT
Limited FFS FctsAllowing first
Integration tests at IRON BIRD
FFS1.2 baseline+ flight Critical PRs from
Iron BIrd+ PRs from engine tests
MVTI/O Tests
No
No
Yes
Yes
Yes
No
( psupply)• Basic Function • Starting Auto, Manual• Power management• Protection + Propeller
YesYes Yes
Yesonly EPRs Partially SyIT Test
YesNo No
NoNo No YesAircraft version
Yes
+ latest Prop. changes+ Engine Performance updates (Data tables)+ PRs assigned
Problem report trackingBasis for SW change packages, evolution towards final SW
22 22 25 28 36 28 28 28 28 28 28 28 28 3114 16 17
13 13 13 13 1643 44 57 4627 27
56 56 39 51 51 51 51
51 5151 51
54 54
66 68 69 85 93 107 107
156
163191
211 218
0 0
0 0 0
33 3333 33
33
33
37
40 40
14 14
51
386387
351
232
117 117
161 168 161
210 218232
284
318
0
50
100
150
200
250
300
350
400
450
30/0
8
06/0
9
13/0
9
20/0
9
27/0
9
04/1
0
11/1
0
18/1
0
25/1
0
31/1
0
08/1
1
19/1
1
29/1
1
06/1
2
RFHS
MTU
HS
Iron Bird
A9 delta
Incorporation policy defined (including
Incorporation policy defined
300 100%
Problem report evolutionHuge number of raised Problem reports raised (from System, SW team, ETP, Customer)Raised PRs must be assigned to a solution responsible quickly (otherwise no implementation for next SW batch possibly)SyPR must be classified within an implementation policy (acc. to prio + impact) see graph 3
System Problem reports [SyPRs] tracking / statistics within project
4. September 2008 Software-Qualifikation des Luftfahrtriebwerks TP400 (R. Homburg, MTU Aero Engines AG, München) 24
261
73
3121
0
50
100
150
200
250
Specification error TBD New requirement Implementationerror
0%
10%
20%
30%
40%
50%
60%
70%
80%
90% Split of PRs on impact / effectmore than 65% of SyPRs are “system specification” Problems Most found by documentation review and not test.approx 25% SyPRs raised, trigger either arequirements change or cause a new requirementtypically only around 5-10 % errors are SW / Implementation errors
Requtschange
Assignment of PRs to SW (Incorporation policy)assessment if PRs requires SW correction, to sort out not SW relevant items (HW, Testsystem,..)SW relevant PRs need to be assigned clearly to SW incorporation package (acc. to prio, impact)Carefully balance urgent needs with solution maturity
Incorporation policy of open PRs to SW baselines
0
50
100
150
200
250
FFS1.1 FFS1.2 FFS1.x PostEngCERT
not SWrelated
PRs assigned
12
3
Problem reporting system tool MANTISPR Quality is not for free requires additional responsible personnel
Complete/ Incomplete PR's
15
2
6
1
6
1
14
3
0
2
4
6
8
10
12
14
16
MTU RR HS RFHS
PRs incomplete
19%
14%
19%
74%
100%
0% 20% 40% 60% 80% 100%
MTU
RR
HS
RFHS
EPICompany A
Company B
Company C
Company D
Company E
Other companies
Snapshot / Sample on PR‘s quality statistics from MANTIS: action Solution Responsible to fill out mandatory fields (*)
4. September 2008 Software-Qualifikation des Luftfahrtriebwerks TP400 (R. Homburg, MTU Aero Engines AG, München) 25
* Mandatory fields analyzed: “Affected function” - “Technical impact of problem” - “Released baselines/versions affected” - “Action required …” - “PR classification” - “Root cause”
• Problem reports raised in MANTIS PR tracking system are often filled inaccurate / incomplete (missing assignments, free text fields,) adapt tool, process description
• High PR quality is mandatory to achieve efficient SW change packages train people• In large SW projects (e.g. Tp400) a PR quality responsible + regular PR review and
implementation policy board is required in order to:• chase system / Sw team to keep PR data base consistent and up to date• ensure quick start of solution definition for reported PRs • efficiently prioritize SW packages (add. customer needs min changes for SOI
process) • accelerate SW maturity and allow control of a stable baseline for SOI process
1. Reglerentwicklung bei MTU: Ein kurzer Aufriss der Historie
2. Software Zulassung: SOI Prozess (nach RTCA - DO 178B)
3. Triebwerk TP400: Kurzüberblick und das CMS Regelsystem
4 Erstellung der TP400 Triebwerks-Regler Software
Vortragsübersicht
4. September 2008 Software-Qualifikation des Luftfahrtriebwerks TP400 (R. Homburg, MTU Aero Engines AG, München) 26Allgemeine Programmsituation
4. Erstellung der TP400 Triebwerks Regler Software
5. Validierung der TP400 Regler Software: generelle Testverfahren
6. TP400 SW Qualifikation: EASA Behördenprozess, Fehler Tracking mit PRs
7. Zusammenfassung & Schlussbemerkung
Zusammenfassung (1/2): SOI Prozess
Für die Qualifikation flugsicherkeitskritischer Software (DAL Class A) muß auf Basis der RTCA Richtlinien (nach RTCA DO-178B) ein formaler Qualifikationsnachweis geführt werden
Dieser sog. SOI Prozess ist von der europäischen Flugsicherheitsbehörde EASA formaldurch entsprechende SOI Reviews nachzuweisen
in Absprache mit EASA können auch SOI Reviews auch mit reduzierten Umfang bzw. zusammengefasst durchgeführt werden (Bei ergänzenden Qualifikationen), jedoch mit dem erhöhten Risiko (z.B. müssen unvollst. / fehlende Inhalt im Rahmen der Vorbereitung zum nächsten Review vollständig nachgeliefert werden)
4. September 2008 Software-Qualifikation des Luftfahrtriebwerks TP400 (R. Homburg, MTU Aero Engines AG, München) 27
g g )
Bestehen des SOI#4 Reviews (erfolgreicher Abschluß aller notw. SW Validierungstests inkl. Berichte) ist Voraussetzung für eine Flugfreigabe sicherheitskritischer Software (DAL A)
Der SOI Prozess ist ein streng gegliederter, mehrstufiger behördlicher begleiteter Prozess, der Prozess, der alleine jedoch keine Garantie für die Qualität der SW nur ein Nachweis einer prozesskonformen Entwicklung.
im Rahmen der Vorbereitung der SOI Reviews werden viele Spezifikations-Fehler gefunden / korrigiert
durchgängig nachweisbare Transparenz von Top Level System Requirements bis SW Code (Traceability) + verknüpfter Nachweis erfolgreicher Validierung fördern frühe Entdeckung von Fehlern
Verantwortung / Haftung verbleibt auch nach EASA Qualifikation beim SW Hersteller
Zusammenfassung (2/2): Eignung/ Notwendigkeit der Testverfahren
am konkret gezeigten Beispiel der TP400 Regler-SW Entwicklung und Qualifikation wird deutlich, wie aufwendig und inkrementell sich SW Entwicklung in einem multinationalem Umfeld darstellt, insbesondere mit verteilten Verantwortlichkeiten bei den HL Requirements
Von Software- und Systemtests bis hin zur Flugzeugsimulation oder Prüfstandstests werden Fehler gefunden und müssen in die laufende SW Qualifikation eingephased werden.
die Mehrzahl gefundener Fehler sind Spezifikationsfehler, die im Rahmen von Problem reportsberichtet werden (z.B. SOI Review, Triebwerk oder Iron BIRD tests) und nicht im Rahmen der klassischen, automatisierten low-level SW Tests (UT, HSI) detektiert wurden
Low level SW tests (Unit test und HSI tests) sind unverändert notwendig da Fehlfunktionen
4. September 2008 Software-Qualifikation des Luftfahrtriebwerks TP400 (R. Homburg, MTU Aero Engines AG, München) 28
Low level SW tests (Unit test und HSI tests) sind unverändert notwendig, da Fehlfunktionen schwerwiegende Auswirkungen auf die gesamte SW Verhalten haben jedoch finden diese relativ wenig Fehler und haben in beschriebenen Umfeld nur einen kleinen Korrekturanteil
SW acceptance test (SAT) stellen durch ihren vollständigen Automatisierungsgrad (100% Scripts) vor allem durch „regressional“ tests die grundlegende Funktionalität der SW sicher wichtig vor allem für sie „Auto-Coding“ Teile der SW und bei hoher Änderungsdichte / Korrekturen
System Integration Tests (teil-automatisiert/ manuell am Dry/ Wet Rig) sind vor allem zur Prüfung neuer SW Funktionen und zum gezieltem Nachweis der erfolgreichen Korrektur von Fehlern zielführend, jedoch mit erhöhtem Aufwand verbunden
Iron Bird / Triebwerks-Tests sind für eine System Validierung unverzichtbar, da hier die SW mit den realen Flugzeugsystemen bzw. Triebwerks-Hardware die tatsächliche Eignung nachweisen muß
Backup Material
4. September 2008 Software-Qualifikation des Luftfahrtriebwerks TP400 (R. Homburg, MTU Aero Engines AG, München) 29Allgemeine Programmsituation
MTU Software Development Process: Verification Testing Activity
• Software verification testing activity mainly comprises of three types of tests:• Unit testing (low level testing)• Hardware / Software Integration Testing (HSI instrumented + SW integration
testing) • Software Acceptance Testing (HSI not instrumented
Verification Testing Activity
4. September 2008 Software-Qualifikation des Luftfahrtriebwerks TP400 (R. Homburg, MTU Aero Engines AG, München) 30
• System verification testing (on system level)• System integration test
• Methods• Requirements based testing• Requirements coverage analysis• Structural coverage analysis
Development of flight safety critical software forcontrol and monitoring unitsOperating System and Application Software for on board systems
Preperation of Software Requirement Specifications compatible with system neeeds
Definition, design and implementation of software
Embedded Software Development
9 May 2008 TK Presentation 31
Integration, testing, verification and qualification of software
Performance of reviews and analysis runs to support softwarecertification
Certification of software based on international standards
IPC
FBS
PGB
PT25T3
EGT1
IPTBS1
Acc #3
Acc #1
TRQ_L
Acc #2
HPC CC HPT HS TECIPT
TURBOT1
#NLNI
IPTBS2IMCIPTBS3
5.2.10 SENSOR LOCATION
4. September 2008 Software-Qualifikation des Luftfahrtriebwerks TP400 (R. Homburg, MTU Aero Engines AG, München) 32
IPC
AGB
EGT2
BB
NH
HPC CC HPT HS LPT TECTURBOT2A
IPT
WFM
#NL
TURBOT2B
#NI
IPTBS3
TRQ_R
EGT
The TP400 Control & Monitoring System (CMS)
TP400 Control & Monitoring System (CMS) is mainly composed of an ECU and an EPMU. The ECU and the EPMU are located in different zone of the Engine.
ECU (FADEC) provides• the Engine, Propeller & Nacelle control functions,• the digital communication function with the A/C
4. September 2008 Software-Qualifikation des Luftfahrtriebwerks TP400 (R. Homburg, MTU Aero Engines AG, München) 33
(AFDX & ARINC).
EPMU provides • all protection functions• vibration monitoring functions
some monitoring functions are shared between ECU and EPMU• Electrical Power Management Functions are supported by CMS, and are
implemented into the EPMU.
Difficult shares of responsibilities within TP400 Engine Control System SW (AS) –split between 2 partners
ECU (including Operational Software): Hispano Suiza / BAE SystemsHispano Suiza / BAE Systems• Specification of AS/OS Interface in ECU and AS IRD
to be agreed by MTU• Development, Integration & Verification of ECU (including OS)
Including provision of OS/AS Interface in accordance with ECU and AS IRDApplication Software stub used for OS integration & verification
ECU Application Software: MTUMTU• Specification and Design of ECU Application Software
4. September 2008 Software-Qualifikation des Luftfahrtriebwerks TP400 (R. Homburg, MTU Aero Engines AG, München) 34
Specification and Design of ECU Application SoftwareCompliant with ECU and AS IRD
• Development, Integration into ECU / with OS & Verification of ECU Application SoftwareIncluding verification of conformance with OS/AS interface
ECU Operational Software
ECU Application Software
OS / AS Interface *)
*) function calls + memory mapped data
MTU responsibility
HS/BAE Systems responsibility1.
2.
What are the objectives of EASA SOIs?
SOI#1 – Planning Review (Summarised)• To assess the interfaces with the system, hardware and safety processes.• To review the system architecture; to assess the assigned software levels
• To assess the applicant’s plans and standards in relationship to identified software level, safety features, and safety-related software requirements.
• To ensure that plans and standards meet objectives in DO-178B and will comply with other applicable software policy and guidance
4. September 2008 Software-Qualifikation des Luftfahrtriebwerks TP400 (R. Homburg, MTU Aero Engines AG, München) 35
software policy and guidance.
SOI#2 – Development Review (Summarised)• Assess effective implementation of applicant’s plans and standards through examination of software
life cycle data.
• Assure that software life cycle data meets DO-178B objectives.
What are the objectives of EASA SOIs?
SOI#3 – Verification Review (Summarised)• Assess effective implementation of the applicant’s verification plans and procedures.• Ensure that the software requirements have been verified.
• Ensure that the verification activity satisfied the coverage requirements of DO-178B.
SOI#4 – Final Review (Summarised)• Determine if final compliance to all of the DO-178B objectives has been achieved and all open items
4. September 2008 Software-Qualifikation des Luftfahrtriebwerks TP400 (R. Homburg, MTU Aero Engines AG, München) 36
addressed/dispositioned.
• Assess the Software Configuration Index, Software Life Cycle Environment Configuration Index, Software Accomplishment Summary, and any other documents not previously reviewed.
Development in a multi-national environment - Organisational of main SW related issues
HS: Hispano Suiza
EPI: Europrop International
MTU: AeroEngines
TP400 CMS repsonsibilities
CMS Task / Theme TP400 CMS repsonsibilities
TP400 EPMU
Interface to Customer (Airbus) EPI/MTU EPI/MTU
4. September 2008 Software-Qualifikation des Luftfahrtriebwerks TP400 (R. Homburg, MTU Aero Engines AG, München) 37
High Level Documents (System) MTU/HS MTU
Software Requirement Specification (SRS)
MTU MTU
Traceability in DOORS MTU MTU
Problem Report / Configuration Management
MTU MTU
Hardware Entwicklung HS / MTU MTU
Certification EPI EPI
Sys Req V V SW
ReqSW DD
SW Code
UT
V V V V V V
V V
Commission
Test
RTCA – 178B Requirements chain
4. September 2008 Software-Qualifikation des Luftfahrtriebwerks TP400 (R. Homburg, MTU Aero Engines AG, München) 38
SyIT P
SAT P
HSI P
P V V
V V
V V
V V
Test
Test
Test
CMS - TP 400
TP400 simplified Requirements Documentation Treesophisticated tree complicates traceability and requirements validation
A9 Chapters
PCMSyRD
PCMFID
CMSyTRD
PCMSyDD
GERD
ABD 100, CRI, CSE
4. September 2008 Software-Qualifikation des Luftfahrtriebwerks TP400 (R. Homburg, MTU Aero Engines AG, München) 39
SRSEPMU-P
SRSEPMU-M
SRSECU AS
ARINC ICDCAN ICD
CS Req Doc
SRS EPMU SUSW + ML SSRD EPMUSSRD
AccessoriesSSRD ECU
EPVS Req Doc AS Req Doc
ECU Elec.DD
EPMU Elec.DD
MTU Software Development Process: Unit Testing (UT)• Performed on representative target hardware
• Used for structural coverage analysis• Including object code coverage (Level A only)
• Mainly used for verification of Low Level Requirements
4. September 2008 Software-Qualifikation des Luftfahrtriebwerks TP400 (R. Homburg, MTU Aero Engines AG, München) 40
RepresentativeTarget (Computer)Hardwaree.g. Evaluation Board
Computer Network
TargetProzessor
Ethernet, PCI, ...
MTU Software Development Process: Hardware/Software Integration (HSI) Testing
• Performed on open box arrangement with emulation system connected within a closed loop simulation (Hardware In the Loop)
• Mainly used for verification of High and Low Level Requirements involving the real target hardware e.g. timing, synchronisation, etc.
4. September 2008 Software-Qualifikation des Luftfahrtriebwerks TP400 (R. Homburg, MTU Aero Engines AG, München) 41
ModifiedTargetHardware
Hardware in the LoopSimulation Emulator
Control Station
Inputs
OutputsProbe
Trace
Control InputsMeasure Outputs Control Emulator
Test Interface
TestsystemTP400 powerplant simulation incl.
simulation of A/C interfaces
ECU
TP400-D6 CMS Dry Rig - Connection of signals
4. September 2008 Software-Qualifikation des Luftfahrtriebwerks TP400 (R. Homburg, MTU Aero Engines AG, München) 42
ECUor
EPMU
Signal acquisition
or generation
Possibility for signal
interruption via test script
Removable bridges for
manual signal
manipulation
sensor or actuator signal
Requirement example : Simple steady state requirement
Parameter read-out via DMSU
Parameter adjustment via Testsystem
4. September 2008 Software-Qualifikation des Luftfahrtriebwerks TP400 (R. Homburg, MTU Aero Engines AG, München) 43
No time dependence --> steady state test sufficient
Input signal (NH_R) directly settable by adjusting respective Testsystem output
NH_R * NH_G_DCS + NH_OF_DCS = NH_CD
Example for an automatic test script / result of a steady state test
Adjustment of Testsystem parameter with subsequent stabilisation
Verification of parameter (combined read-out and comparison against limits)
Automatic test script (extract)
##### Test Case 1 #####
### Adjustment of parameterpara.set("ECU_NH_L1_RPM_R", 631.8, "Hz")tp400util.delay(0.5)
4. September 2008 Software-Qualifikation des Luftfahrtriebwerks TP400 (R. Homburg, MTU Aero Engines AG, München) 44
Actual values of parameter
Limits
comparison against limits)
Note : If the actual value of a parameter is outside the specified limits, an error counter will be increased. The final status of the error counter must be 0 for a successful test.
### Verification of parameterpara.verify("TC1", "ECU", "L1", "CC", "NH_FREQ_R", "Hz", 621.8, 641.8)para.verify("TC1", "ECU", "L1", "CC", "NH_CD", "rpm", 885.99, 913.99)
Respective result file (extract)
##### TEST CASE 1ECU_NH_L1_RPM_R (SIM) set to 631.8 Hzverify ECU_L1_CC NH_FREQ_R 631.86 Hz [621.8,641.8] Hzverify ECU_L1_CC NH_CD 900.00 rpm [885.99,913.99] rpm
Requirement example : Dynamic requirement
Integrator
4. September 2008 Software-Qualifikation des Luftfahrtriebwerks TP400 (R. Homburg, MTU Aero Engines AG, München) 45
Time dependence due to usage of integrator --> dynamic test with data recording necessarySome input signal (MMV_POS_DEM) are derived from the output of preceding requirements (i. e. inputs not easily settable by adjusting Testsystem output)
Examle for a result file obtained during a dynamic test
Modification of parameter value to trigger the start of the integration
4. September 2008 Software-Qualifikation des Luftfahrtriebwerks TP400 (R. Homburg, MTU Aero Engines AG, München) 46
Integrator output
Determination of expected values for the verification of parameters
ECU/EPMU I/O
• Excel (simple calculation incl. usage of conversion tables, i. e. Ohm -> Celcius)ECU/EPMU CBIT
• Manually acc. to requirement (e. g. out-of-range value shall set range check failure)EPMU Protection
• Manually acc. to requirement (e. g. speed value above overspeed threshold shall set overspeed flag)
4. September 2008 Software-Qualifikation des Luftfahrtriebwerks TP400 (R. Homburg, MTU Aero Engines AG, München) 47
overspeed flag)ECU TPC/EPC• Dynamic tests : manually acc. to requirement (e. g. ramp-up of integrator output)
• Steady state checks : Matlab Simulink model. Transfer test vectors into Matlab/Simulink model. Read-back of results of calculation within Matlab/Simulink (see separate graphic)
Determination of expected values for the verification of parameters (cont.)
Matlab Simulink Model
of
ECU/EPMU
Step 3 : Transfer test vectors to M/S Model
Step 5 : Extract results from M/S Model
Step 4 : Initiatition of calculation
4. September 2008 Software-Qualifikation des Luftfahrtriebwerks TP400 (R. Homburg, MTU Aero Engines AG, München) 48
Definition of test vectors within Excel
NL = 80%T2 = 300 K
NHNAX_CS = 100%etc.
NL = 80 % NLC = 82%
T2_V = 300 Ketc.
Step 1 : Definition of test cases in Excel
Step 2 : Write test vectors to a file
Step 6 : Read results into Excel file
Step 7 : Generate Python Test Script
Python TestScripts
Final step 8 : Test run at Testsystem with real ECU hardware using the same test vectors as for calc.