27
Research challenges and opportunities in the scope of complex systems development Keynote at SoftNet 2014, Nice, France Philipp Helle, Airbus Group Innovations
Research challenges and opportunities in the
scope of complex systems development
Keynote at SoftNet 2014, Nice, France
Philipp Helle, Airbus 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
3
…at a glance
Airbus Group Innovations
Key figures
4
• Over 800 Researchers, Scientists, Engineers worldwide
• 20 sites around the world
• Located in 12 countries
• More than 100 new patent applications every year
5
Airbus Group Management structure
Thierry Baril
Chief Human Resources Officer
Allan McArtor
CEO Airbus Group Inc.
Jean J. Botti
Chief Technical Officer
Marwan Lahoud
Chief Strategy & Marketing Officer
Harald Wilhelm
Chief Financial Officer
Chairman of the Board of Directors (BoD) Denis Ranque
Tom Enders Chief Executive Officer (CEO)
Guillaume Faury (CEO) Bernhard Gerwert (CEO)
Airbus Defence and Space
Fabrice Brégier (CEO)
Airbus Helicopters Airbus
Jean J. Botti Marwan Lahoud Harald Wilhelm
Airbus Group Innovations is part of
Chief Technical Officer Organization
Airbus Group Innovations all over the world
*
* under development
*
6
Where we operate?
We optimize networking synergy to get innovations
7
Main partnerships
IISc
IIT Kanpur
IIT Kharagpur
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?
Required Functions
addressed?
Flexibility?
Weight? Costs?
Maintenance? Production?
Power Consumption?
Safety?
Security?
...
Timing?
9
Motivation Airbus Group
10
Source:
http://newsbytes.ph/2014/08/11/blog-jollibee-chickensad-an-it-management-case-study/
Airbus Group Motivation
11
EIS: 2007
11B€
EIS: 2011
15B$
Source:
http://business.financialpost.com/2011/11/15/bombardiers-bid-to-avoid-boeings-mistakes/
Airbus Group Motivation
12
First Flight: 1963
Expected life: 2020
First Flight: 1974
Expected life: 2019
First Flight: 1987
Expected life: ???
Source:
http://en.wikipedia.org/wiki/Transall_C-160
http://en.wikipedia.org/wiki/Panavia_Tornado
http://en.wikipedia.org/wiki/Airbus_A320_family
Systems
Development
Process
Systems
Development
Process
Typical system development process
Development process
Component
Implementation
Requirements
Specification Integration Test
Supplier responsibility
Design Component Test
Virtual Tests
13
Systems
Development
Process
Systems
Development
Process
Typical system development process
Development process
Component
Implementation
Requirements
Specification Integration Test
Supplier responsibility
Design Component Test
Virtual Tests
Formal
requirements
Model-based
specification
Architecture
optimization
Model-based
Testing Formal
verification
Virtual
verification
14
Formal requirements
15
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)
Model-based specification
Specification modelling Model usage Requirements analysis
Textual requirements
Test scenarios
Integrated simulation
Structure description
Algorithm description
Behaviour description Hierarchy and context
description
Traceability description
OffevPowerOn
On
POST
Normal_mode
evPOST_finished
evPowerOn
evPowerOffevPOST_finished
evPowerOff
States & Modes
Functions description
Traceability for coverage and impact analysis
Document generation
16
Model-based specification
17
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
Architecture optimization
18
Common “Needs” Model
Architectural
Constraints
Optimization Goals
Architecture Solution Model
DMS_Expanded.DoorLatchActuator @ Door 6_225:DoorLatchActuator
1 «block,VaryingPart» power:intcontrol
DMS_Expanded.RDC @ Door 6_229:RDC
1 «block,VaryingPart» power:intdevice
network
Link_110106Link_110106
DMS_Expanded.DoorLockActuator @ Door 3_166:DoorLockActuator
1 «block,VaryingPart» power:intcontrol
DMS_Expanded.Controller @ Avionics Bay_105:Controller
1 «block,VaryingPart» power:intnetwork
Link_81080
DMS_Expanded.RDC @ Door 3_167:RDC
1 «block,VaryingPart» power:intdevice
network
Link_81080
DMS_Expanded.Switch @ Switch Bay 1_113:Switch
1 «block,VaryingPart» power:int
network[NumOfPorts]
Link_41049
Link_110049
Link_41049
Link_110049
DMS_Expanded.DoorClosedSensor @ Door 4_171:DoorClosedSensor
1 «block,VaryingPart» power:intoutput
DMS_Expanded.DoorLockedSensor @ Door 1_138:DoorLockedSensor
1 «block» power:intoutput
DMS_Expanded.DoorLockedSensor @ Door 4_174:DoorLockedSensor
1 «block» power:intoutput
DMS_Expanded.DoorLockActuator @ Door 1_142:DoorLockActuator
1 «block,VaryingPart»
power:int
control
DMS_Expanded.DoorLatchActuator @ Door 4_177:DoorLatchActuator
1 «block,VaryingPart» power:intcontrol
DMS_Expanded.DoorClosedSensor @ Door 2_147:DoorClosedSensor
1 «block,VaryingPart» power:intoutput
DMS_Expanded.DoorLockActuator @ Door 4_178:DoorLockActuator
1 «block,VaryingPart» power:intcontrol
DMS_Expanded.DoorLatchActuator @ Door 2_153:DoorLatchActuator
1 «block,VaryingPart» power:int
control
Link_90084
DMS_Expanded.RDC @ Door 4_179:RDC
1 «block,VaryingPart»
latency:float=50.0
power:float=15.0 Opera tio ns
power:intdevice
network
Link_90086
Link_90088
Link_90049
Link_90089
Link_90084
Link_90086
Link_90088
Link_90049
Link_90089
DMS_Expanded.RDC @ Door 2_155:RDC
1 «block,VaryingPart»
weight:float=0.138
analog:int
Opera tio ns
power:int
device
network
Link_72070Link_72049
Link_72066
Link_72070Link_72049
Link_72066
DMS_Expanded.DoorClosedSensor @ Door 5_207:DoorClosedSensor
1 «block,VaryingPart» power:intoutput
Link_81077
DMS_Expanded.DoorLockedSensor @ Door 3_162:DoorLockedSensor
1 «block» power:intoutput Link_81077
DMS_Expanded.DoorLockedSensor @ Door 5_210:DoorLockedSensor
1 «block» power:intoutput
DMS_Expanded.Switch @ Switch Bay 1_108:Switch
1 «block,VaryingPart» power:int
network[NumOfPorts]
Link_44049
Link_81044
Link_44049
Link_81044
DMS_Expanded.DoorLatchActuator @ Door 5_213:DoorLatchActuator
1 «block,VaryingPart» power:intcontrol
DMS_Expanded.DoorLatchActuator @ Door 1_141:DoorLatchActuator
1 «block,VaryingPart» power:intcontrol
DMS_Expanded.DoorLockActuator @ Door 5_214:DoorLockActuator
1 «block,VaryingPart» power:intcontrol
DMS_Expanded.DoorLockedSensor @ Door 2_150:DoorLockedSensor
1 «block» power:intoutput
Link_72068Link_72068
Link_100097
DMS_Expanded.RDC @ Door 5_216:RDC
1 «block,VaryingPart» power:intdevice
network
Link_100098
Link_100095Link_100093 Link_100044
Link_100097Link_100098
Link_100095Link_100093 Link_100044
Link_81075
DMS_Expanded.DoorClosedSensor @ Door 3_159:DoorClosedSensor
1 «block,VaryingPart» power:intoutput
Link_81075
Link_110103
DMS_Expanded.DoorClosedSensor @ Door 6_220:DoorClosedSensor
1 «block,VaryingPart» power:intoutput
Link_110103
DMS_Expanded.DoorLockActuator @ Door 2_154:DoorLockActuator
1 «block,VaryingPart» power:intcontrolLink_72071Link_72071
DMS_Expanded.DoorLatchActuator @ Door 3_165:DoorLatchActuator
1 «block,VaryingPart» power:intcontrolLink_81079Link_81079
DMS_Expanded.RDC @ Door 1_145:RDC
1 «block,VaryingPart» power:intdevice
network
Link_65062
Link_65059
Link_65061
Link_65044
Link_65062
Link_65059
Link_65061
Link_65044
Link_110104
DMS_Expanded.DoorLockedSensor @ Door 6_222:DoorLockedSensor
1 «block» power:intoutput Link_110104
Link_40044
DMS_Expanded.Controller @ Avionics Bay_102:Controller
1 «block,VaryingPart» power:intnetwork Link_40044
DMS_Expanded.DoorLockActuator @ Door 6_226:DoorLockActuator
1 «block,VaryingPart» power:intcontrol
Link_110107Link_110107
DMS_Expanded.DoorClosedSensor @ Door 1_136:DoorClosedSensor
1 «block,VaryingPart» power:intoutput
Link_65058Link_65058
Component
Libraries
Technical Options
Optimization
Code
Architecture optimization
19
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
Formal verification
20
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/21-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
22
Control behaviour
(e.g. Rhapsody)
Mechanical behaviour
(e.g. SimPack)
Electrical behaviour
(e.g. Dymola)
monitor_temperature_sensors_immersion
ts1_lwt_not_immersed
ts1_lwt_immers ion_confirmed chImmersion_condit
ion_ts1_lwt[me->im
mersion_condition_t
s1_lwt == FALSE]
ts1_lwt_immers ion_observed
chImmersion_conditi
on_ts1_lwt[me->imm
ersion_condition_ts1
_lwt == TRUE] chImmersion_condition_ts
1_lwt [me->immersion_con
dition_ts1_lwt == FALSE]
tm(CTTSI)
ts2_rwt_not_immersed
ts2_rwt_immers ion_confirmed chImmersion_conditi
on_ts2_rwt[me->imm
ersion_condition_ts2_
rwt == FALSE]
ts2_rwt_immers ion_observed
chImmersion_conditi
on_ts2_rwt[me->imm
ersion_condition_ts2
_rwt == TRUE]chImmersion_condition_ts2
_rwt[me->immersion_condit
ion_ts2_rwt == FALSE]
tm(CTTSI)
chImmersion_condit
ion_ts1_lwt[me->im
mersion_condition_t
s1_lwt == FALSE]
chImmersion_conditi
on_ts1_lwt[me->imm
ersion_condition_ts1
_lwt == TRUE] chImmersion_condition_ts
1_lwt [me->immersion_con
dition_ts1_lwt == FALSE]
tm(CTTSI)
chImmersion_conditi
on_ts2_rwt[me->imm
ersion_condition_ts2_
rwt == FALSE]
chImmersion_conditi
on_ts2_rwt[me->imm
ersion_condition_ts2
_rwt == TRUE]chImmersion_condition_ts2
_rwt[me->immersion_condit
ion_ts2_rwt == FALSE]
tm(CTTSI)
Visualisation in DMU
(e.g. Catia)
Heterogeneous
Simulator
Virtual verification
23
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
Model-based testing
24
Development Test
time Delivery date
time Delivery date
Development
Test
AS IS TO BE
Model-based testing
25
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
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
