Software-Qualifikation des Luftfahrtriebwerks TP400 · 4. September 2008 Software-Qualifikation des Luftfahrtriebwerks TP400 (R. Homburg, MTU Aero Engines AG, München) 15 1. A400M

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


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


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





Vortragsübersicht






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.


• 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


• 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


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


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)





Vortragsübersicht






TP400 – Governmental and Industrial Organization

A400M Military transport aircraft

EPI – Europrop

AMSL

TP400 Propeller engine for A400M

RFHS Propeller


• 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


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]





Vortragsübersicht






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


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


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





Vortragsübersicht






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)


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


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


Test Case 10 of actual script

TP400-D6 CMS Wet Rig Set-Up

VSVA

Gearbox

FCOC


Combustion chamber simulator

MFPFMU

VSVA loading device





Vortragsübersicht






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


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


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 (*)


* 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





Vortragsübersicht






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)


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


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


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


• 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


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


(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


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


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


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


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


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


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


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.


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


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


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)


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


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


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)


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


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.