Approach to Systematic Test Signal Definition forOperation Scenarios of Aircraft Systems

1st Dennis HilligInstitute of Aircraft Systems Engineering

Hamburg University of Technology (TUHH)Hamburg, Germany

Dennis.Hillig@tuhh.de

2nd Frank ThieleckeInstitute of Aircraft Systems Engineering

Hamburg University of Technology (TUHH)Hamburg, Germany

Frank.Thielecke@tuhh.de

Abstract—With rapidly increasing levels of automation, mod-ern aircraft systems become increasingly complex. The designedsolutions typically achieve multiple functions by using a highlyintegrated mix of hardware and software components. Withregard to automation, particularly the number of softwarecomponents increases.For verification and validation activities, such as testing, thisintensifies the challenge to define all relevant scenarios to test asystem’s functionalities and particularly its robustness in the caseof unusual, but realistic situations. Hidden failure cases might bemissed. Additionally, it becomes infeasible to systematically definethe test vectors to study a systems behavior thoroughly due to theimmense test space. As a consequence, testing gets more work-and time-intensive.This paper presents a stepwise model-based method to define andrefine the stimulating part of the test scenarios in a systematic andmodular manner to approach this challenge. The aim is to workout diverse and relevant operational scenarios to validate systemfunctions and to set up realistic test vectors for these scenarios.The paper further focuses on the aim to facilitate automation andre-usability of scenario and functional signal elements to enablecontinuous testing at different stages of the development process.Concepts of a developed prototype are outlined as well. Finally,the current state of the method is discussed and an overview ofthe way forward is given.

Index Terms—scenario testing, aircraft systems, test design

I. INTRODUCTION

In recent years new digital and smart embedded systemsolutions emerged at a very rapid pace. Such solutions areincreasingly used to optimize novel aerospace systems, whichintegrate mechanical, mechatronical and software components,through automation. However, the more capabilities and func-tions these integrated intelligent solutions implement, the moreapparent the need becomes for new verification and validation(V&V) methods, that can handle the complexity. In particularfor safety-critical systems this is crucial. In that context,classical approaches for the examination of system’s integratedfunctions and safety, which rely significantly on manual testingand expertise, are a limiting factor to new developments.Testing in general is the mainly used V&V method. Scenario-based testing more specifically is one technique to assessthe operational, functional behavior at system and overallaircraft level. Scenario-like analyses of technical systems arealso commonly used for demonstrations of functionality inan operational context. Yet, two main challenges can be

identified, when the system complexity rises. Firstly, it be-comes difficult to find the relevant scenarios or operationalconditions. Secondly, the implementation of the realistic testvectors complicates significantly.In order to approach this challenge for aircraft systems, a me-thodical procedure for a structured and model-based scenariodefinition was developed at the Institute of Aircraft SystemsEngineering of the Hamburg University of Technology. Itis intended to cope with the system’s complexity throughthe main ideas of modularisation and hierarchical refinement.The contribution is embedded into the activities to develop aseamless avionics tool chain (s. [1]).The aim of the developed method is clarified with an exampleuse case of an air conditioning system in the following. Figure1 shows an overview of the system under test (SUT) andsome interfacing elements, such as the aircraft’s environmentconditions, cabin loads and cockpit commands from the over-head panel. The system is modeled in an open-loop mannerw.r.t. the interfacing elements. The actions of these interfacingelements should be explicitly integrated in the scenario def-inition. Given that the physical system was designed with arepresentation as a physical model, and the control and monitor(C&M) functions (e.g. pressure control) were designed andimplemented, the scenario-based test has the following twoobjectives: On one hand, the system hardware design should beverified, e.g. in terms of sizing and functionality. On the otherhand, the software functions should be validated under realisticoperational scenario conditions. To achieve that, realistic inputsignals or models of the interfacing elements are needed for agiven set of scenarios, which also have to be identified. Thistask is not trivial, particularly as interfaces include numerouscontinuous signals.The presented definition process should further facilitate au-tomation and reuse at different stages of the development.With regard to the latter, system component models couldbe replaced by real hardware, for example, and the scenariosshould still be applicable with minimal necessary adaptions.A prototype editor for the presented mission scenario andstimulating test signal definition was developed using Mat-lab/Simulink. Applied concepts are integrated in the followingexplanations. Specified information can also be captured as an.xml exchange document.

Fig. 1. Example usecase: Air conditioning system.

The paper firstly presents the fundamentals of scenario-basedtesting and the applied mission-based scenario approach.Subsequently the developed scenario definition process isoutlined. This includes an initial methodical overview as wellas the different fundamental steps being scenario specification,system and environment definition and signal and componentimplementation. Finally, a short conclusion is given and thefuture work is described.

II. FUNDAMENTALS

A. Scenario Testing

The classical scenario test approach can be categorizedas a specification-based test design technique (s. [2]). Asequivalently called ”black-box testing” this means that require-ments, specifications or (interface) models etc. are used toderive test cases without knowledge of the internal structureof the tested system [2]. In that respect scenario testingfocuses on sequences of interactions with interfacing systemsor components. In software testing literature, also user-centricuse cases are utilized equivalently to scenarios [3]. Otherspecification-based testing methods contrarily mainly rely onthe systems input-output space for specification verificatione.g. by identifying possible input combinations or partitionswith equivalent behavior. Therefore, scenario testing is moresuitable to assess systems long-running (end-to-end) behaviorin a realistic operational situation. This story-like characterconsequently attains motivational and meaningful context (s.[4]) to discover hidden failures and their possible effects.Models, e.g. formulated in formalisms like state charts orsequence diagrams, are commonly used to describe the pos-sible interaction sequences. The typical scenario definitionprocedure from [2], towards which this work is oriented, canbe reduced to the following two steps:

1) Definition of one main scenario, that describes thenominal sequence of actions

2) Derivation of alternative scenarios based on the givenmain scenario.

The latter can be diverse, as it includes foreseen operationaloptions, exceptions and intended or unintended incorrect en-

tries. Therefore, these scenarios are often further classified e.g.as positive or negative w.r.t. whether the goal of the interactionis expected to be achieved or not. A trivial aircraft example:If the aircraft is on ground, it should not be possible to retractthe landing gear.As outlined here, scenario testing has the potential to assuresafer and more robust system-functions through the diversityof realistic scenarios. Particularly automation functions couldbe validated early. However, it is also clear that a systematictest of the complete input-output space is not the goal. Ascenario targets one specific, but complex set of operationsand exploring all possible parameter variations would blowup the number of test cases. Other approaches to black-boxtesting probably perform better in this respect. Moreover, asa black-box testing technique, coverage of all internal systemstates is also not the primary intend where a structure-basedtechnique may be more suitable.

B. Mission-Based Scenario Approach

As aircraft systems are typically integrated subsystems ofthe overall vehicle, the functional behavior is typically orientedtowards the flight mission. For that reason, an operationalscenario-based test approach was developed in [5], whichmodels the flight mission in a state-chart as a sequence offundamental phases, that are represented as atomic statesalong a scenario path. The major aim is to support theoverall system integration tests to observe coupling effectsbetween involved components and software functions. Thecurrent application focuses on the use for simulation-basedpre-design investigations but the principal transferability tofinal integration testing is desired. Therefore, the approachintends to complement requirements-based test activities byexploring the operational overall system behavior to uncoverundesired effects, with a particular desire to find interactionsbetween ATA chapters.The virtual test architecture from [5] foresees the partition ofstimulating ’test cases’ though the scenario state-chart and theevaluation, which is done by observing agent modules runningin parallel. These modules could check arbitrary functionalbehavior or performance of the system. With this approachit is possible to realistically set up operational tests, whichenable assessment the overall system’s functional behaviorduring complete flight missions. As the integrated systemis investigated, multiple functional specification aspects andoperational sequences can be observed in an simultaneousmanner.The scenario concept presented in [5] and [6] uses multi-signal segments in time-series format from a segment library tocreate continuous signal profiles for each phase. Test signalsset up for each phase separately are thereby composed to acomplete test vector representing the flight mission scenario.To cover multiple scenarios, the concept allows branching ofthe scenario paths. The time-continuous signal profiles definedwithin the phase are complemented by parallel events that aretriggered at discrete test points during a phase. The eventscould for example represent cockpit commands and can trigger

alternative phase transitions of the scenario path. This enablesthe modeling of events such as an emergency during cruise andresulting alternative flight phases, such as emergency landingand evacuation.In [5] and [6] the outlined concept was successfully demon-strated at a multi-functional fuel-cell system, which includedcontrol and automation functions. However, the complex sce-nario state-chart has to be created manually and is hardlyreusable. The presented method in this paper also applies thesame mission-based scenario approach. With the foundationsfrom [5], the method tries to offer a more structured, modularand reusable process for the definition of the stimulatingscenario state-chart, that can be automated further.

C. Related Work

1) Testing using Scenario-Based System Specifications:Several works in the recent past adressed the model-basedspecification of system behavior in the form of scenarios andthe test activities on the basis of this specification. To clarifythe distinction in the light of scenario-based testing, someworks in that field are discussed in the following.For the specification of reactive system behavior, messagesequence diagrams are often used in literature on softwareengineering to visually define wanted and unwanted systemscenarios. This particularly applies in the context of testing.One example is the standardized test specification languageTTCN-3 [17] with primary applications for communicationsystems, which allows the formulation of test cases in theform of sequence diagrams. It is pointed out in [9], thatthe formalism has the advantage to focus on inter-objectcommunication scenarios without having to specify the objectsinternal behaviors. Moreover, extensions such as live sequencecharts (LSC) [12] exist, which allow the precise definitionof system specifications with different modalities, e.g. whatmust and what may happen. Such sequence charts are alsoextended in research to describe time constraints (s. [11]) orgenerally visualize temporal properties such as linear temporallogic (LTL) formulas (s. [13]).The work in [10] further demonstrates a way how automatictest generation can be achieved with modal scenario speci-fications. The approach allows the specification of multiplesequence charts for the system functions that can be activein parallel, if an initial sequence of the respective scenariooccurs. Due to the granularity of scenario definitions, themethod seems quite scalable. Moreover, a coverage criteriumwas developed to minimize redundant scenario combinationsand thus the amount of test cases.However, the scenario approach of this work is principallydifferent. As mentioned in the previous section it shouldcomplement the test activities on the basis of specified require-ments. Instead of using a specification model of the systemthe presented approach models the stimulating environmentin an operational context on aircraft level. Expectations onsystem’s behavior are not modeled in the current scenariostate-chart and must be evaluated in parallel observationmodules or manually in post processing. Reactive behavior

(and timeouts) may be used to model environment reactionson system outputs. The presented approach is understood tobe more explorative and investigative in the sense to moveaway from the scenarios that are explicitly defined through thespecification. It should be emphasized that running scenario-based specification models in parallel to observe requiredfunctional behavior is possible and intended but exceeds thescope of this paper.

2) Automotive Street Scenarios: In the context of the vali-dation of highly automated driving functions in the automotivesector, the works in the context of the PEGASUS researchproject [15] follow a similar operational scenario philosophyas presented in this paper. Street scenarios, defined in a stan-dardized and structured format [14], include static content ofthe street situation and dynamic elements such as moving carsor pedestrians. The concept allows to execute the scenariosat simulation as well as real world level. Scenarios can alsobe to remodeled from real operation for further investigation.Nevertheless, a difference for the application in the aircraftdomain is the diversity and number of systems in comparisonto the variety of traffic situation in the automotive sector.

3) Signal Segments in Testing: In [16] a segment-basedapproach is presented to generate complex signal inputs witha low number of parameters for each segment. This principleis similar to the definition of signal functions in the context ofthis work. However, the work in [16] conducts a structural testof automotive Simulink models using a search-based algorithmand does not predefine operational scenarios.

III. SCENARIO DEFINITION PROCESS

The developed definition process pursues three basic incen-tives following the modularization and hierarchy principles:

1) Easy set up and management of complex scenario testsmakes them less error prone and more complete forincreasingly complex systems.

2) Give context and improve automated analysis and doc-umentation by association of signal segments with spe-cific scenario story elements or actions of the SUT andits interfacing environment elements.

3) Maximize the reuse of scenario tests and its elements toreduce effort and make tests more comparable.

The concrete concepts are discussed in the following.

A. Methodical Process Overview

The developed procedure is structured into 5 fundamentalsteps. An overview of these methodical steps for the scenariodefinition is depicted in Fig. 2. The steps can be grouped intothree types of activities: Scenario specification, system andenvironment definition as well as signal assignment.The first abstracts from the concrete system interface or signalsand tries to identify all relevant mission scenarios and theirlogical sequence of phases and events. At the end of thisactivity, the structural definition of the state chart is completeand specified up to its basic phase elements and a graphicalrepresentation can be produced (e.g. in Matlab/Simulink State-flow). Furthermore, different scenario test cases can now be

Fig. 2. Methodical steps in the scenario definition process.

derived on the basis of the transition paths through the state-chart. However, as the basic phase states are still empty andno interface signals are defined yet, the test cases cannot beapplied.The second activity defines the concrete SUT interface and itsenvironment elements. When finished, all interface signals forthe system under test are registered and grouped accordingto potential environmental elements. These elements can berepresented as parallel states within a compound phase state.The scenario test cases defined at this stage could be executed,but do not exercise the scenarios correctly, as no signal profilesare defined yet.The third and final activity assigns concrete signal profilesto the defined signals. For each phase and each environmentelement, sequences of signal segment models can be assigned.For re-usability, these models could be linked from a library asparameterized elements. In such way generic signal segments,such as a ramp or set functions can be applied, as well as veryspecific profiles such as the pressure sensor signal includingnoise during an depressurization event.Following the signal assignment the scenario definition pro-

cess is completed. Enough information is gathered to createexecutable scenario test cases. Due to the generic setup, anexport to arbitrary test languages is principally possible. Theimplemented prototype realizes executable test cases as statecharts in Matlab/Simulink Stateflow and the use with SimulinkTest is foreseen. Furthermore the export to the state machinenotation SCXML [7] was tested, which is currently furtherextended as a generic exchangeable test language in a researchproject.A more detailed description for the concepts in each step ispresented in the following.

B. Scenario Specification Layer

The scenario specification layer has the intention to identifyand structure all relevant operational scenario conditions byperforming the two steps Scenario registration and Definitionof the scenario statechart.

1) Scenario Registration (AC/System-level):In this initial step, the scenarios are registered by a tex-tual definition and classified. The primary classification is towhether a scenario represents a nominal sequence of eventsor an alternative one. Further classification of the latter e.g. as

positive, exception, negative and misuse with context to systemand aircraft functions still need to be worked out. Optionallya classification for expected frequency of occurrence or linksto requirement elements can be inserted. Such additionalinformation should later be used for test case prioritisationand filtering.For the mission-based scenario approach, two different cate-gories of scenarios were identified:

• Aircraft mission scenarios• System operational scenarios

The first includes scenarios such as nominal and alternativeflight phases (e.g. loiter in approach) or emergency descent.The latter focuses on the system functions and exploits differ-ent system operations or configurations and internal or externalfailures.

2) Stepwise Definition of the Scenario State-Chart:As a second step, each scenario is setup in one integratedstate chart structure. Scenarios are implemented by sequencesof phase states or event triggers, that could occur duringselected phases or phase groups (e.g. in flight) at defined testpoints, or combinations. Firstly one flight-mission phase pathis defined for the main nominal scenario. This scenario shouldequivalently represent the nominal system operation. Subse-quently the alternative scenarios can be defined by branchingthe nominal scenario at a selected phase and proceeding withalternative mission phases and by defining parallel triggerevents that mark the start of the scenario. Phase end conditionscould be defined textually for the transition between thephase states, which then have to be refined by state chartvariables later. Scenarios can partially share a scenario phasepath and end by final phases or explicitly branching intoother scenario paths (e.g. alternative flight mission with thesame landing procedure). An implemented example for thedeveloped prototype is depicted in Figure 3 - 5. As shown inFigure 4, a scenario path, such as the nominal flight missionin the given example, can be constructed with regard to thetaken transition path. Alternatively, as depicted in 5 for theemergency case, a tabular view of the state path could beused. The second figure shows, how the alternative scenariois constructed by branching out of the nominal one. Thisstructure-based editing can be further complemented by ahierarchical tree view for all existing states, given on theleft side of the figures. In addition to this structural editionof scenarios, the illustrated conceptual prototype realizes agraphical state machine view in Matlab/Simulink Stateflow.As both perspectives are transferable, a graphical state chart asdepicted in Figure 3 can be set up easily by this hybrid editingthat combines graphical and structural information. Parallelevents can implement

• initial trigger for scenario paths, e.g. emergency,• trigger for usual phase-internal operations without effect

on transitions (e.g. different cabin loads),• trigger for failures (e.g. cabin smoke / fan failure) or• combinations.

Fig. 3. Exemplary scenario state chart (in orientation to [5]).

They occur at discrete test points during the phases. In thecurrent concept and in orientation to [5], test points applyfor phases that have a fixed minimum execution time defined(e.g. cruise time). By defining an integer sampling number foreach phase, the given time frame is partitioned in as manyparts, where each partitions beginning marks a test point. Thedefined sampling number therefore has a significant effect onthe resulting count of test cases.Several parallel events could occur in sequence for one sce-nario when suitable transition conditions are defined (e.g.failure followed by a corrective cockpit action after a definedtime). However, it needs to be taken care that transitions toother phases in between these events do not happen.A method still needs to be worked out how to consistentlydefine different scenarios, that are triggered subsequently.Based on the defined scenario state chart, scenario test casescan by identified by traversing along the path and takinginto account the parallel events. An algorithm for automaticpath identification and subsequent test case generation waspresented in [6] for scenario state charts in the format thatwas adopted from [5]. The test cases end at final phase states

Fig. 4. Exemplary tabular transition path for a nominal flight scenario.

Fig. 5. Exemplary tabular state path for an emergency flight scenario.

or when the path loops. They are executable either by suitablecontrol mechanisms to enable specific paths for the holisticstate chart or by extracting unbranched scenario paths. Thefirst option was demonstrated in [5].

C. System and Environment Definition Layer

The activities described in the section aim to define struc-tured objects in the environment of the system under test. Thisshould enable a more straight forward and reusable definition

of the signal profiles that are applied to the SUT interfaces foreach scenario phase.

1) System Under Test (SUT) Interface Definition:Before defining the environmental elements, the actual inter-face of the system under test has to be defined, which shouldbe used for the scenario test. This predominantly includesthe declaration of the SUTs’ input and output signals bydefining signal name, data-type, initial value for inputs andunits. Moreover, special inputs, such as fault trigger for systemmodel components, can be defined that may be needed to reach

certain scenarios. To be able to reuse the test scenarios atdifferent designed stages, all signals are symbolic variablesand abstract from real transmission mechanisms. If morerealistic transmission are needed, e.g. for hardware in the loop(HITL) integration, specific drivers need to be set up outsideof the test definition process or manually integrated into theSUT model. These drivers could be defined on a target testsystem, such as dSPACE Scalexio, TechSAT ADS2 or Vectortest hardware, which provides the hardware interface e.g. tosend signals as CAN messages to real control modules in aHITL test.The interface information could be loaded from an interfacedocument file, that may be available from a model-baseddevelopment process.

2) Environment Component Definition:As a second step, the definition and categorization of environ-mental elements is carried out. Each previously defined SUTinterface signal can subsequently be assigned to one interfaceelement. Furthermore, it is intended to allow the definition ofsignal groups within environmental elements, if it is desired todefine a single maneuver or action in the environment that actson several signals. One example could be the use of two re-dundant sensors or protocol-based signal groups. Based on thegiven signal classification, parallel compound state processesfor every environmental element are inserted into each of thescenario phases of the state chart structure. Similarly, singlesignals or signal groups form parallel processes within thesecompound states. In that way, sequences of actions or signalprofiles could be assigned completely separate for each signalor signal group of each environmental element within eachflight phase. An example is visualized on the left side of Figure6, which includes the environmental elements Cabin Loads,Environment, Flight Management and OVHD, that containsthe signal Temp Demand.In the case that it is desired to include single mathematicalcalculation models that apply continuously during the com-plete mission irrespective of any scenario, a parallel processto the scenario state chart is foreseen. For instance this couldbe models that calculate the atmospheric pressure based ona height profile that results from the scenario path. It shouldbe mentioned that in principal, these models could also beset up outside of the state chart. The parallel calculationmodel process can be structured with the same environmentcomponent definition as for the phases. However, assignedsignals and signal groups are then excluded from the phases.The modular setup as described prepares a structured andrealistic signal assignment and facilitate re-usability throughcomponent libraries. Moreover, it creates context for reportingand analysis.

D. Signal and Component Implementation Layer

Having defined the hierarchical structure of scenario phasesand groups of signals as environmental elements in the pre-vious steps, the concrete signal profiles are set up in this laststep. For each phase state, the information gathered beforeincludes the phase name, scenarios that include the phase,

applicable parallel events and it’s trigger for each scenarioand the environmental component structure.Based on this, sequences of signal functions and segments arenow assigned to the signal variables as defined in the previousstep. Following the objective of re-usability, a library conceptfor parameterizable signal functions is used. Two fundamentalfunction types are foreseen:

• (Atomic) basic functions, that have a representation forthe test system the scenario is intended to run on.

• Higher level functions, that are state chart compoundscontaining basic functions, states and transitions.

The atomic function library should be fixed while higherlevel functions for component models can be defined indi-vidually as needed. The library concept makes it easier toset up realistic scenarios by having (signal-based) interfacecomponent models with parameters such as sensors includingnoise, different atmosphere models etc. When assigning thelibrary elements to the scenario the function symbols haveto be mapped to the scenario signals. The sequence of libraryelements for each signal is defined by an unbranched transitionpath where a transition is taken after predefined times orarbitrary expressions. The use of common atomic functionsat lowest level enables the translation of the test scenarios toother test scripting languages (e.g. SCXML [7] in its extendedform or proprietary solutions). The assignment of parallelcalculation models is done in the same fashion as for thephase signals. An example for the definition of sequentiallinked basic functions is depicted in Figure 6 for a temperaturedemand signal set from the flight deck during cruise phase.The functional elements, which are all set functions in theexample, are defined and parameterized in a tabular form. Thedepicted sequence of linked states, which creates the signalshown on the right side, can then be automatically generated.To complete the signal assignment, phase end conditions needto be defined to trigger the transition to the next phase.These could be already specified textually during the scenariodefinition steps e.g. cruise time and emergency trigger event orcan be individually defined according to the assigned profile(e.g. speed≤0). For continuous signals care has to be taken,that the steadiness is fulfilled when transitioning between thephases. Useful mechanisms will still need to be worked out.

IV. CONCLUSION AND FUTURE WORK

In this paper, a structured procedure was presented tocollectively define flight mission-based scenarios in a state-chart formalism and refine them to create realistic signals fortest stimulation. The aim is the verification and validation ofintegrated aircraft systems in an operational context. Due to themostly generic and modular approach, the complex scenariodefinition can partitioned into small manageable parts. Hence,the method would speed up the process and be reusable atdifferent stages of the system design. The definition of systemscenarios in the first step is as far as possible abstracted fromthe concrete system implementations and can be set up inde-pendently, early in the process. The approach of hierarchicalobjects for signal groupings in the further modeling achieves a

Fig. 6. Component-embedded sequence of basic functions (left) and resulting signal (right).

highly reusable structure, which could be adapted easily withregard to design changes. Finally, with the concept of basicatomic signal functions as library elements, independence fromtest automation systems can be reached, given that suitableconversion mechanisms exist. However, the concept is yet tobe applied in a complete system test campaign.In future works, it still needs to be investigated, if thescenario definition based on paths and parallel events ismature enough to handle very large and complex systems orif further mechanisms need to be developed. The procedurewas implemented as a prototype in Matlab/Simulink usingmixed hybrid graphical and structured editing, which was alsopresented in this paper.Another open topic is the automatic evaluation of test runs. Aspointed out in the presentation of the mission-based scenarioapproach, the defined scenario state-chart represents only thestimulation part for the test execution. Therefore the definitionof parallel observer logics for evaluation is a major point tobe addressed. The evaluations could include specified systemfunctional or performance requirements.Moreover, open parameter definitions shall enable the system-atic exploration of specific scenarios. The transfer of resultingsystem states over repetitive scenario runs is also consideredin that context, e.g. to assess wear effects. In that context, theremodeling of realistic scenarios from operational data andinvestigation of parameter variations is could be addressed.The integration of operational recordings of signals from realoperations will also be worked out for this purpose. Thisshould expand the segment-based approach that was alreadydemonstrated in [8].Finally, due to intend for automatic test execution the exportto common test automation engines should be investigated.

ACKNOWLEDGMENT

I would like to thank Martin Halle, Hauke Hober and theanonymous reviewers of the AvioSE’20 for valuable commentson the draft version. The presented results are part of the work

in the research project AGILE-VT (contract code: 20X1730J),which is supported by the Federal Ministry of EconomicAffairs and Energy in the national LuFo V-3 program.

REFERENCES

[1] M.Halle and F.Thielecke, ”Tool Chain for Avionics Design, Develop-ment, Integration and Test”, 1st Workshop on Avionics Systems andSoftware Engineering (AVIOSE’19), Stuttgart, Germany.

[2] ISO/IEC/IEEE International Standard 29119-4:2015 - Software andsystems engineering – Software testing – Part 4: Test techniques.

[3] Everett, Gerald D.; McLeod, Raymond: ”Software testing. Testing acrossthe entire software development life cycle.” Hoboken, New Jersey: IEEEPress Wiley-Interscience a John Wiley & Sons Inc. Publication, 2007.

[4] Cem Kaner (2003): ”An Introduction to Scenario Testing.” In: SoftwareTesting & Quality Engineering (STQE).

[5] Dipl.-Ing. J.Grymlas (2017): ”Systemautomatisierung fur den multifunk-tionalen Betrieb von Brennstoffzellen in Verkehrsflugzeugen”, PHDThe-sis, Hamburg University of Technology, Shaker Verlag, 2017.

[6] J. Grymlas, and F. Thielecke, ”Virtual Integration and Testing ofMultifunctional Fuel Cell Systems in Commercial Aircraft,” SAE Int. J.Aerosp. 6(2):2013, doi:10.4271/2013-01-2281.

[7] World Wide Web Consortium (W3C). (2015) State chart XML(SCXML): State machine notation for control abstraction. [Online].Available: https://www.w3.org/TR/scxml/.

[8] J. Grymlas, et al., ”Scenario-based testing of multifunctional fuel cellsystems using the virtual integration platform VIPER”, in InternationalConference on Fundamentals and Developement of Fuel Cells (FDFC),Toulouse, 2015.

[9] Harel, D. et al. (2012): ”Multi-modal scenarios revisited: A net-basedrepresentation.” In: Theoretical Computer Science 429, S. 118-127.

[10] La Panzica Manna, Valerio et al. (2015): ”Synthesizing tests for com-binatorial coverage of modal scenario specifications.”, MODELS 2015.

[11] Harel, D. and Marelly, R. (2003): ”Playing with time: on the specifica-tion and execution of time-enriched LSCs.”, MASCOTS 2002.

[12] Damm, W. and Harel, D. (2001): ”LSCs: Breathing Life into MessageSequence Charts.”, In: Formal Methods in System Design 19 (1), S.45-80.

[13] Autili, M. et al. (2007): ”Graphical scenarios for specifying temporalproperties: an automated approach.”, In: Autom Softw Eng 14 (3), S.293-340.

[14] ASAM e. V. (2020): ASAM OpenSCENARIO.Online: https://www.asam.net/standards/detail/openscenario/

[15] German Aerospace Center, DLR (2020): Pegasus Research Project.Online: https://www.pegasusprojekt.de/en/home

[16] Windisch, Andreas (2011): ”Suchbasierter Strukturtest fur SimulinkModelle”, PHDThesis, Berlin Institute of Technology, 2011.

[17] ETSI (2020): Testing and Test Control Notation Version 3 (TTCN-3).Online: http://www.ttcn-3.org/