Research challenges and opportunities in the scope of complex systems development

Keynote at SoftNet 2014, Nice,

Philipp Helle, Group Innovations Content

1. Introduction

2. Motivation

3. Typical systems development process

4. Research challenges and opportunities

• Formal requirements • Model-based specification • Architecture optimization • Formal verification • Virtual verification • Model-based testing

5. Conclusion

2 …at a glance

3 Key figures

• Over 800 Researchers, Scientists, Engineers worldwide

• 20 sites around the world

• Located in 12 countries

• More than 100 new patent applications every year

Airbus Group Innovations

4 Airbus Group Management structure

Airbus Group Innovations is part of Chief Technical Officer Organization

Denis Ranque Chairman of the Board of Directors (BoD) Chief Executive Officer (CEO)

Chief Financial Chief Strategy & Chief Technical CEO Airbus Group Chief Human Officer Marketing Officer Officer Inc. Resources Officer

HaraldHarald Wilhelm Wilhelm MarwanMarwan Lahoud Lahoud JeanJean J. J. Botti Botti Allan McArtor Thierry Baril

Airbus

Fabrice Brégier (CEO) (CEO) Bernhard Gerwert (CEO)

5 Where we operate?

Airbus Group Innovations all over the world

*

*

* under development

6 We optimize networking synergy to get innovations Main partnerships

IISc IIT Kanpur IIT Kharagpur

7 Motivation Airbus Group

Trend: Growing Complexity of Systems

8 Motivation Airbus Group

How can we develop systems that have to fulfill a large number of often opposing requirements?

Costs? Required Functions Weight? Safety? addressed?

Timing? Security?

Flexibility? ...

Maintenance? Production? Power Consumption?

9 Motivation Airbus Group

Source: http://newsbytes.ph/2014/08/11/blog-jollibee-chickensad-an-it-management-case-study/

10 Airbus Group Motivation

EIS: 2007 11B€

EIS: 2011 15B$

Source: http://business.financialpost.com/2011/11/15/bombardiers-bid-to-avoid-boeings-mistakes/

11 Airbus Group Motivation

First Flight: 1963 First Flight: 1987 Expected life: 2020 Expected life: ???

Source: http://en.wikipedia.org/wiki/Transall_C-160 First Flight: 1974 http://en.wikipedia.org/wiki/Panavia_Tornado http://en.wikipedia.org/wiki/Airbus_A320_family 12 Expected life: 2019 Typical system development process

Development process

Requirements Systems DevelopmentSystems Process DevelopmentVirtual Tests Specification Process Integration Test

Design Component Test

Supplier responsibility Component Implementation

13 Typical system development process

Development process

Requirements Systems Virtual Formal Development requirements verificationSystems Process DevelopmentVirtual Tests Specification Process Integration Test Model-based specification Model-based Formal Testing verification Design Component Test Architecture optimization

Supplier responsibility Component Implementation

14 Formal requirements

What we see today: - Natural language requirement still dominate the system requirements definition - Working formal specification approaches exist But: - Increasing systems complexity make it increasingly impossible to communicate the system definition using text alone (inconsistencies, gaps, contradictions,…) - Formal languages not alluring to system engineers Open challenges: - Make model-based approaches and formal specification more usable for system engineers (structured text, boilerplates, domain-specific formal languages for writing requirements, tool supported formalization)

15 Model-based specification

Requirements analysis Specification modelling Model usage

Traceability description Structure description Test scenarios

Textual requirements Hierarchy and context Behaviour description Integrated simulation description

On

POST evPowerOn Off

evPOST_finished evPowerOff Normal_mode

States & Modes Algorithm description Document generation Functions description

Traceability for coverage and impact analysis

16 Model-based specification

What we see today: - Model-based approaches for modelling functional requirements, - Document generation and model execution for specification validation is possible But: - Non-functional requirements (and other process requirements, e.g. installation) are often still in natural language - Very slow uptake in industrial practice - Tools are not adapted to systems engineer needs (many tools started in the SW domain) Open challenges: - Increase usability for system engineers, focus on the way they used to express the specification

17 Architecture optimization

Common “Needs” Model

Architectural

Constraints

Technical Options Optimization Goals

Component Optimization Libraries Code

Architecture Solution Model

output 1 «block,VaryingPart» power:int output 1 «block» power:int DMS_Expanded.DoorClosedSensor @ Door 2_147:DoorClosedSensor DMS_Expanded.DoorLockedSensor @ Door 2_150:DoorLockedSensor

Link_72068 Link_72066 1 «block,VaryingPart» DMS_Expanded.RDC @ Door 2_155:RDC control Link_72049 power:int weight:float=0.138 Link_72070 1 «block,VaryingPart» analog:int DMS_Expanded.DoorLatchActuator @ Door 2_153:DoorLatchActuator device Opera tio ns Link_72071 control 1 «block,VaryingPart» power:int DMS_Expanded.DoorLockActuator @ Door 2_154:DoorLockActuator network power:int output 1 «block» power:int DMS_Expanded.DoorLockedSensor @ Door 4_174:DoorLockedSensor

output 1 «block,VaryingPart» power:int DMS_Expanded.DoorClosedSensor @ Door 4_171:DoorClosedSensor Link_90086

control 1 «block,VaryingPart» power:int Link_90084 DMS_Expanded.DoorLatchActuator @ Door 4_177:DoorLatchActuator 1 «block,VaryingPart» Link_90088 DMS_Expanded.RDC @ Door 4_179:RDC power:int Link_90049 device latency:float=50.0 power:float=15.0 Link_90089 Opera tio ns

network

control power:int 1 «block,VaryingPart» control 1 «block,VaryingPart» power:int DMS_Expanded.DoorLockActuator @ Door 6_226:DoorLockActuator DMS_Expanded.DoorLockActuator @ Door 4_178:DoorLockActuator

output 1 «block» power:int Link_110104 Link_110107 DMS_Expanded.DoorLockedSensor @ Door 6_222:DoorLockedSensor

device 1 «block,VaryingPart» power:int DMS_Expanded.RDC @ Door 6_229:RDC network

Link_110103 Link_110106 control 1 «block,VaryingPart» power:int DMS_Expanded.DoorLatchActuator @ Door 6_225:DoorLatchActuator

output 1 «block,VaryingPart» power:int DMS_Expanded.DoorClosedSensor @ Door 6_220:DoorClosedSensor

Link_110049 power:int 1 «block,VaryingPart» Link_44049 Link_41049 DMS_Expanded.Switch @ Switch Bay 1_113:Switch

network[NumOfPorts]

control 1 «block,VaryingPart» power:int DMS_Expanded.DoorLatchActuator @ Door 1_141:DoorLatchActuator

network 1 «block,VaryingPart» power:int DMS_Expanded.Controller @ Avionics Bay_105:Controller Link_40044 control Link_65062 Link_65061 network 1 «block,VaryingPart» power:int 1 «block,VaryingPart» DMS_Expanded.Controller @ Avionics Bay_102:Controller DMS_Expanded.DoorLockActuator @ Door 1_142:DoorLockActuator power:int

output 1 «block» power:int 1 «block,VaryingPart» power:int device 1 «block,VaryingPart» power:int DMS_Expanded.DoorLockedSensor @ Door 5_210:DoorLockedSensor DMS_Expanded.Switch @ Switch Bay 1_108:Switch DMS_Expanded.RDC @ Door 1_145:RDC network[NumOfPorts] network Link_65044 output output 1 «block,VaryingPart» power:int Link_100093 Link_100044 Link_65059 1 «block» power:int DMS_Expanded.DoorClosedSensor @ Door 5_207:DoorClosedSensor Link_100095 Link_65058 DMS_Expanded.DoorLockedSensor @ Door 1_138:DoorLockedSensor

output device 1 «block,VaryingPart» power:int control 1 «block,VaryingPart» power:int 1 «block,VaryingPart» power:int DMS_Expanded.RDC @ Door 5_216:RDC Link_81044 DMS_Expanded.DoorLockActuator @ Door 3_166:DoorLockActuator DMS_Expanded.DoorClosedSensor @ Door 1_136:DoorClosedSensor

network

Link_100098 control power:int Link_100097 1 «block,VaryingPart» Link_81080 DMS_Expanded.DoorLockActuator @ Door 5_214:DoorLockActuator

output control 1 «block,VaryingPart» power:int 1 «block» power:int Link_81077 device 1 «block,VaryingPart» power:int DMS_Expanded.DoorLatchActuator @ Door 5_213:DoorLatchActuator DMS_Expanded.DoorLockedSensor @ Door 3_162:DoorLockedSensor DMS_Expanded.RDC @ Door 3_167:RDC network

Link_81075 Link_81079 control 1 «block,VaryingPart» power:int DMS_Expanded.DoorLatchActuator @ Door 3_165:DoorLatchActuator

output 1 «block,VaryingPart» power:int DMS_Expanded.DoorClosedSensor @ Door 3_159:DoorClosedSensor

18 Architecture optimization

What we see today: - Proof-of-concept demonstrator for system architecture optimization approach - Isolated optimisation (cable routing, task allocation,…) But: - Focus on standard metrics (weight, cost, …) - Does not consider dynamic behaviour - Limited to linear problems Open challenges: - Consider more metrics during optimization - Measurement of hard-to-measure metrics (security, maintainability, flexibility,…) - Efficient algorithms for non-linear optimization problems

19 Formal verification

http://embsys.technikum-wien.at/projects/decs/verification/formalmethods.php http://babelfish.arc.nasa.gov/trac/jpf/iki/intro/testing_vs_model_checking

http://www.cs.aau.dk/~adavid/publications/2120 -tutorial.pdf Formal verification

What we see today: - Usable industrial strength model checkers are available (UPPAAL, CBMC, SPIN) But: - Available model checkers usually work on a proprietary language (UPPAAL) or heavily restrict the usage of standard modelling languages (STSTest) - Model checkers either work on code (CBMC) or on a model not on models that include code - Scalability is still an issue - Formal verification hardly used in industrial systems engineering Open challenges: - Easy to use model checkers that work on large-scale system models which include code for model execution (see MBS) integrated into existing tool chains - Making sure that an implemented component behaves according to the checked model

21 Virtual verification Visualisation in DMU (e.g. Catia)

monitor_temperature_sensors_immersion

ts1_lwt_not_immersed ts2_rwt_not_immersed

chImmersion_conditi chImmersion_conditi on_ts1_lwt[me->imm on_ts2_rwt[me->imm ersion_condition_ts1 ersion_condition_ts2 _lwt == TRUE] chImmersion_condition_ts _rwt == TRUE] chImmersion_condition_ts2 1_lwt[me->immersion_con _rwt[me->immersion_condit dition_ts1_lwt == FALSE] ion_ts2_rwt == FALSE] Heterogeneous

ts1_lwt_immersion_observed ts2_rwt_immersion_observed

tm(CTTSI) tm(CTTSI) Simulator

ts1_lwt_immersion_confirmed chImmersion_condit ts2_rwt_immersion_confirmed chImmersion_conditi ion_ts1_lwt[me->im on_ts2_rwt[me->imm mersion_condition_t ersion_condition_ts2_ s1_lwt == FALSE] rwt == FALSE]

Control behaviour Electrical behaviour (e.g. Rhapsody) (e.g. Dymola)

Mechanical behaviour (e.g. SimPack)

22 Virtual verification

What we see today: - Simulation is a standard mean for virtual verification - FMI as emerging standard for simulation exchange But: - Multi-domain simulation are often pressed into a single tool - Co-simulation often not easy to use Open challenges: - Simulation environment that allow choosing the best tool for the job - Seamless integration of simulations coming from different tools

23 Model-based testing

AS IS TO BE

Development Development Test Test

time time Delivery date Delivery date

24 Model-based testing

Where we are today: - Model-based testing has been proven as an effective technique for testing (see e.g. ARTEMIS MBAT project) and commercial tools are available But: - MBT typically generates a large number of test cases based on exhaustive search - Expert knowledge is not taken into account in order to optimize the generated test suite include all relevant and realistic test cases Open challenges: - Integration of testing and development activities - Reuse of artefacts from the development phase in the testing phase - Optimisation of test suites from different sources - Identification of the most critical test cases in a test suite

25 Conclusion

• Many open challenges for complex systems development • Main obstacle for adaptation of new methods and tools is usability for engineers • Integration into existing workflows and tool environments is important

• However, it is crucial for ensure research questions are solved in realistic context • Scalability and usability considerations should be part of the problem definition from the beginning • Make sure that end users are involved from the beginning • Any new solution should be able to communicate its practical relevance, expected acceptance of end users, and perspectives for mid- and long-term applications

26 Questions?

Airbus Group Innovations

Philipp Helle [email protected]

27