1. SAFETY And SECURITY IN AVIONICS
EDF Workshop
November
Clamart France
SAFETY And SECURITY IN AVIONICS
Rupert Reiger 
Michael Paulitsch
Kevin Müller
SESAMO / EADS use case

2. Simplified V-Model SRA SISC SESAMO Building Blocks FHA and
PSSA
SSA
SISC Security Informed Safety Case
SRA
PSRA
SISC
Partitioning
Information Flow Control
Decentralized Label Model
FHA Functional Hazard Analysis
PSSA Preliminary System Safety Assessment
SSA System Safety Assessment
SRA Security Risk Analysis
PSRA Preliminary System Security Risk Assessment
SRA System Security Risk Assessment
SESAMO Building Blocks
and
Analysis Techniques
for
Safety & Security
and for
added Security
SESAMO / EADS use case

3. specifications validation design IMA & partitions replication
Safety: (Formal) Methods for dependable Systems, Process and V-Model Fault-prevention removal diagnosis / monitoring isolation tolerance
SW diagnosis
instrumentalization
& monitoring
code
standards:
design process: ARP4754
assessment process: ARP4761
DO-178C
formal requirements
safety cases
safety concept
safety plan
safety
case
specifications
validation
UML RT profile
components / contracts
design
IMA &
partitions
from symptoms
SW diagnosis
& monitoring
to failures
to faults
to errors
model checking
state machines
linear temporal logic (LCL)
computation tree logic (CTL)
bottom up FMEA
top down fault trees FT
replication
integration
communicability analysis
influence chains
network / real time calculus
proved max latency
coding
unit test
model feedback
schedulability analysis
duration calculus (DC)
interval duration logic (IDL)
static analysis / abstract interpretation (AI)
FP precision analysis
range checking
SESAMO / EADS use case
RTE analysis (environment)
WCET analysis
WCET feedback

4. run-time principal Testing
Security: (Formal) Methods for dependable Systems and V-Model Security by enforcing isolation monitoring
security run-time test
code labeling of all
variables, arguments,
DLM
procedures
standards: CC
ED-202 / 203 / 204
Security concept
security
informed
safety
case
Security plan
specifications
validation
run-time principal Testing
safety and security
& label checking
DLM
design
IMA &
partitions &
firewall
top down attack trees AT
integration
coding
static analysis for security
DLM (Decentralized Labels Model)
static label checking
unit test
Decentralized Robustness (2006)
Complete, Safe Information Flow with Decentralized Labels (1998) / Andrew C. Myers, Barbara Liskov - MIT Laboratory for Computer Science
Language-Based Information-Flow Security (2003) / Andrei Sabelfeld and Andrew C. Myers
Decentralized Robustness – Security (2006) / Stephen Chong, Andrew C. Myers - Department of Computer Science, Cornell University
Robustness links confidentiality and integrity properties of a computing system and has been identified as a useful property for characterizing and enforcing security

5. mapping on the standards
SESAMO Safety and Security V-Models enrolled to show Process Tracks Interactions
SESAMO Building Blocks for
Safety & Security
and for
added Security
Use Case: Why safety? Why security?
IMA Use Case
safety track
Security track
Partitioning
Information Flow Control
Partitioning Concept
tracks meet at
architecture
Partitioning & gateway  Security architectural standard MILS
Partitioning  IMA Safety architectural Standard ARINC653
decentralized Label Model
DLM  Security code labeling
Safety  Security  Architecture
Safety Process Standards
Security Process Standards
Safety & Security Levels
Avionics: Standards Safety  ARP4754A  ARP4761  DO-178B/C
Avionics  Standards Security  CC  ED-202
mapping on the standards
all is
about
to end
at the
product
we want
tracks meet at
process
Security: CC: EAL PP ST TOE
Safety: ARP4754A, ARP4761: HA FHA PSSA FTA SSA FMEA
Security: ED-202: RA Avionics Risk Analysis
Back to Safety: Safety Case Form
Safety  Security  Process
CC  ED-202
Safety Case not explicit but implicit in DO-178B/C
Tracks meet at
process
security-informed Safety Cases
Security informed Safety Case
DO-178B/C
ED-202
SESAMO / EADS use case

6. The use case: Why safety?
Best to cite the relevant standard: RTCA/DO-178B/C
SESAMO / EADS use case

7. The use case: Why security?
Which part is concerned:
the production of planes
the plane
air traffic
Security is:
Secrecy / Confidentiality
Not exposing data to an unauthorized entity, no espionage
Authenticity
Clear authenticity of the sender, no spoofing (e.g. an address)
Integrity
Detect stream modifications, no tampering (manipulating, modifying)
Availability
System always available and running and always access to data, no disturbance or killing of a running process ! ! !
SESAMO / EADS use case

8. The use case: Why security?
ARINC REPORT 811
COMMERCIAL AIRCRAFT INFORMATION SECURITY CONCEPTS OF OPERATION AND PROCESS FRAMEWORK
“closed,”
“private,” and
“public”
characteristics of the domains
unproblematic
communication direction
risky direction
risky direction
SESAMO / EADS use case

9. Attacks to consider: Attacks
in S/W or data of A/C Environment  application executes malicious code
in S/W or data of A/L environment  resident S/W executes malicious code
in S/W or data of maintenance environment
in S/W or data of supplier environment
on Aircraft – Unauthorized insertion of media in media reader
during transport of S/W or data by logical communication means (wired and wireless) - remote command execution
on Aircraft via the wireless communications means by direct access to A/C interface system
of mobile/portable equipment in Airbus Environment
of mobile/portable equipment in A/L environment
of mobile/portable equipment in maintenance environment
in mobile/portable equipment supplier Environment
during transport of mobile equipment
on Aircraft – unauthorized connection of mobile equipment in A/C Plugs
SESAMO / EADS use case

10. The use case: Why security?
Best to cite the relevant standard: L’Organisation Européenne pour l’Equipement de l’Aviation Civile EUROCAE ED-202: THREAT CONDITION SAFETY IMPACT CLASSIFICATION
SESAMO / EADS use case

11. Real time & safety & security regarding architectures & processes
Trade offs
Conflicts
&
security
time
real
SESAMO / EADS use case

12. Real time & safety & security regarding architectures & processes
Just examples:
Safety  Real-Time: By replication or by partitioning e.g. leading to task swapping and restoring efforts, safety can be opposing real-time
Safety  Security: Every security related code added to a save system e.g. code for cryptifying or the code of a firewall between partitions has to be certified additionally to the level of this safe system, e.g. to DO-178C level A
Security  Real-Time: Every security related code added to an embedded real-time system can not destroy the real-time capabilities of the system, especially, it must fit into the scheduling policy of the system. If demanded, it must be deterministic.
SESAMO / EADS use case

13. What is specific to Avionics? The IMA use case
What is Integrated Modular Avionics ?
virtualization
SESAMO / EADS use case

14. Partitioning  IMA & Safety
boundary
different
safety levels
What is Integrated Modular Avionics ?
separation
kernel
(Separation)
© SYSGO
SESAMO / EADS use case

15. Partitioning  IMA & Safety
No partition can:
Contaminate another’s code, I/O, or data storage areas (Space Partitioning)
Consume shared processor resources to the exclusion of any other partition (Time Partitioning)
Consume I/O resources to the exclusion of any other partition (I/O space and time partitioning)
Cause adverse effects to any other partition as a result of a hardware failure unique to that partition
SESAMO / EADS use case

16. Partitioning  IMA & Safety
Time partitioning:
Major Time frames are scheduled strongly cyclic = round-robin with exact times
Major Time frames contain the Minor Time Frames = Partitions in a predefined scheduling policy = strongly cyclic = round-robin with exact times
Between partitions no synchronized communication nor any other (mutual) impact of timing or of any kind is possible
Inside a partition there is priority-preemptive scheduling of multiple tasks
Only one task or multiple tasks all with the same priority so with no preemption in a partition is deterministic
Minor
Time Frame
Major Time Frame …
SESAMO / EADS use case

17. The IMA use case: A380
Latency from one process writing to another process reading
from writing of process A
To reading of process B
 Albert Benveniste INRIA-IRISA / EU-project COMBEST
SESAMO / EADS use case

18. Partitioning  timing adding security code changes the system
IMA / AFDX process diagram of an end2end simulation also simulation of latencies/  SYMTA VISION
SESAMO / EADS use case

19. can be allowed is never allowed
exchange of components with a changing WCET
or a changed I/O
what happens ?
can be allowed
Prozesszustands- und Wirkkettendiagramm
 INCHRON
is never allowed
SESAMO / EADS use case

20. Partitioning  timing adding security code changes the system
Response time is not simulated but calculated  INCHRON
SESAMO / EADS use case

21. Partitioning  IMA & Safety
boundary
different
safety levels
What is Integrated Modular Avionics ?
Applications with different levels of safety on one platform.
(Separation)
© SYSGO
SESAMO / EADS use case

22. Partitioning  MILS & Security
What is Multiple Independent Levels of Security ?
different
security
levels
gateway
gateway
Partitioning:
we use the same architecture principle here for
safety and security
Applications with different levels of security on one platform.
© SYSGO
Large overlap between security and safety approach (time and space partitioning; cyclic scheduling)
Security certification easier to achieve with separation-micro-kernel
SYSGO PikeOS supports security and safety
SESAMO / EADS use case

23. Partitioning  MILS & SECURITY
MILS – Multiple Independent Levels of Security
Architecture processing data of different security domains concurrently
High-assurance security architecture based on the concepts of
separation (time partitioning and spatial partitioning) and
controlled information flow
Has to be NEAT  Non bypassable, Evaluable, Always invoked, and Tamperproof
SESAMO / EADS use case

24. Use case: Focus on Gateway
Ensures secure information flow
The architecture follows the approach of IMA and MILS
The separation kernel implements strict separation of processing resources (uses PikeOS)
SESAMO / EADS use case

25. Use case: Focus on Gateway
SESAMO / EADS use case

26. Safety  Security  Architecture
Safety is related to the system volume containing faults
Security is related to the system surface offering attack surface
Having safety: Adding security related code increases:
The volume containing potential faults so diminishing safety
The attack-surface so reducing the added security effect
SESAMO / EADS use case

27. Safety  Security  Architecture
security perimeter
safety is concerned
with faulty coding here
attack vector,
security is concerned
with an attack here
and in the following
with faulty coding here, so
security is affecting safety
SESAMO / EADS use case

28. Safety  Security  Architecture
must also be safe
so this adds additional efforts
to the safety process
must be safe
added security related code
e.g. gateway
to protect
security perimeter
but what protects the
added security related code?
must be self protective!
otherwise we get a series
of adding security code,
which again must be
safe and made secure,
so this adds additional efforts
to the security process
e.g. to the security target ff
SESAMO / EADS use case

29. Safety  Security  Architecture
Adding security code:
Adds efforts to the safety process
Adds efforts to the security process
The processes interleave at the architecture
There are alternations between the processes
How to do that is a challenge
SESAMO / EADS use case

30. Avionics  Standards Safety & Security
ASSESSMENT
PROCESS
DESIGN
AWS
Assessment
EUROCAE
ED-202
Airworthiness Security Process Specification
(the “What”)
ED-203
Airworthiness Security Methods and Considerations
(the “How”)
ED-204
Continuing Airworthiness Guidance for Information System and Data Network
Requirement
Management
System Design
SAE
ARP4754
Aerospace Recommended Practice /
Guidelines for processes used to develop civil aircraft and systems
ED 79
Guidelines for Development of Civil Aircraft and Systems
IMA System
ED-124
Integrated Modular Avionics (IMA) Development, Guidance and Certification Consideration
RTCA/DO-297
Integrated Modular Avionics (IMA) Development Guidance and Certification Considerations
Safety
ARP4761
Guidelines and Methods for conducting the Safety Assessment
Process on civil airborne Systems and Equipment
SYSTEM
Security
Evaluation CC
Common Criteria for Information Technology Security Evaluation
Software
Development
Hardware
ED-80
Design Assurance Guidance for Airborne Electronic Hardware
RTCA/DO-254
Design Assurance Guidance
for airborne electronic Hardware
Life-Cycle
ED-12B/C
Software considerations in airborne systems and equipment certification
RTCA/DO-178B/C
Software Considerations in airborne
Systems and Equipment Certification
Verification
ED-12B
Software considerations in airborne systems and
equipment certification
ITEM
SAFETY
SECURITY
ARCHITECTURE
IMA incl. Partitioning & Communication
ARINC 653
Avionics Application Software
standard Interface
&
Partitions
Conformity Test Specification
MILS
Multiple Independent Levels of Security
Is an architecture but has to be a future standard
SYSTEM
Is an architecture bur has to be a future standard
ITEM
Avionics  Standards Safety & Security
SESAMO / EADS use case

31. Avionics Process Standards  Levels
DO-178B/C uses “Software Levels”
for evidence of correctness
ARP 4754 / ED 79 / DO-254 use similar
Design Assurance Levels “DAL”  “SL”
Common Criteria uses
Evaluation Assurance Levels “EAL”
ED-202/ED-203/ED-204 use similar levels to EALs
Criticality
Confidence / Assurance
SESAMO / EADS use case

32. Safety  Avionics Standards
Assurance in Aerospace – A Long Tradition of Safety Civil Certification Standards (Large Airplane)
SESAMO / EADS use case

33. Safety: ARP4754A  DO-178B/C
SAE ARP4754A
SESAMO / EADS use case

34. Safety / Design: SAE ARP4754A SESAMO / EADS use case A/C Safety
Functional Hazard Analysis
Preliminary System Safety Assessment
Fault Tree Analysis
Common Cause Analysis
Preliminary Aircraft Safety Assessment
Common Mode Analysis
Failure Modes and Effect Analysis / Summary
System Safety Assessment
A/C Safety
Assessment
SAE ARP4754A
DO-178B/C
SESAMO / EADS use case

35. Safety / Assessment: SAE ARP4761 FTA FMEA SESAMO / EADS use case
top down
bottom up
FMEA
Safety / Assessment:
SESAMO / EADS use case
SAE ARP4761

36. FHA PSSA SSA
SAE ARP4761
SAE ARP4761
SESAMO / EADS use case

37. FHA PSSA FTA SSA FMEA
SAE ARP4761
SESAMO / EADS use case

38. Security  Standard: Common Criteria relationship: EAL PP ST TOE
for Information Technology
Security Evaluation Part 1:
EAL Evaluation Assurance Level
TOE Target of Evaluation
set of software, firmware and/or hardware
PP Protection Profile
implementation-independent statement of security needs for a TOE type
ST Security Target
implementation-dependent statement of security needs for a specific identified TOE
SPD Security Problem Definition
OSP Organizational Security Policy
SFR Security Functional Requirement
SAR Security Assurance Requirement CC
SESAMO / EADS use case

39. Security  Avionics Standards  ED-202
Assurance guides the level of testing and verification activities
ED-202
SESAMO / EADS use case

40. Avionics  Standards Security ED-202 Addressing the Security Risk
The security level is the combined effect of the strength of mechanism and the implementation assurance.
reduces
risk
Counter Measure Security
Level Classification
ED-202
Risk Matrix
SESAMO / EADS use case

41. Safety  Security  Processes wording and make the processes similar …
EUROCAE ED-202
Assessment
Risk
SAE ARP4754A as cited in ED 202
Assessment
Hazard 
SESAMO / EADS use case

42. Back to Safety: Safety Case Form and Standards
About the DO-178B/C:
ARP4754A uses “DAL”  evidence of correctness
DO-178 uses “Level”  assurance of low failure rates (10-9 f/h,10-7 f/h, …)
Don’t mix that up!!! But:
Must map DAL  Level … both directions
The available evidence of correctness points to flawed requirements as the main source of defects in software development, and to the transition between system requirements developed under ARP 4754A and software requirement under DO-178B/C as a particular vulnerability
Hence improved and mechanically supported methods of requirements analysis are urgently needed
Integrating these topics into a putative DO-178D in a way that supports rational analysis will be greatly assisted if the safety case implicit in DO-178B is made explicit (in particular, the argument how the objectives support the claims)
SESAMO / EADS use case
John Rushby, EMSOFT’11, October 9–14, 2011, Taipei, Taiwan.

43. Back to Safety: Safety Case Form
built on
Evidence  Argument  Claim
A safety case is
“the most explicit”
formulation of the problem
safety case is implicit in DO-178B/C
make safety case explicit in a DO-178D
in particular how the objectives
support the claims
SESAMO / EADS use case
A Methodology for Safety Case Development
Peter Bishop, Robin Bloomfield - Adelard, London, UK

44. Back to Safety: Safety Case Form and Standards
Goal Structuring Notation (GSN)
SESAMO / EADS use case
Tim Kelly, Iain Bate, John McDermid, Alan Burns University of York, UK

45. Back to Safety: Safety Case Form and Standards
Goal Structuring Notation (GSN)
SESAMO / EADS use case
Tim Kelly, Iain Bate, John McDermid, Alan Burns, University of York, UK

46. The Step: Security Informed Safety Case
Adelard LLP
Robert Stroud
Robin Bloomfield
Kateryna Netkachova
SESAMO / EADS use case

47. Types of cases
Making a safety case a for special subjects explicitly informed safety case
As showing information about compliance with standards
Can be further informed by whatsoever further principles
Can show a back mapping of the security informed safety case on the safety and security standards as shown in slide 5
Mapping on safety standards can be done on
Functional Hazard Analysis ff, in detail on
Fault tree analysis
Failure Modes and Effect Analysis
SESAMO / EADS use case
Robin Bloomfield, Kateryna Netkachova, Robert Stroud

48. Safety / Design: SAE ARP4754A SESAMO / EADS use case A/C Safety
Functional Hazard Analysis
Preliminary System Safety Assessment
Fault Tree Analysis
Common Cause Analysis
Preliminary Aircraft Safety Assessment
Common Mode Analysis
Failure Modes and Effect Analysis / Summary
System Safety Assessment
A/C Safety
Assessment
SAE ARP4754A
DO-178B/C
SESAMO / EADS use case

49. Back to Safety: Safety Case / GSN and Standards
safety case is implicit in DO-178B/C
make safety case explicit in a DO-178D
in particular how the objectives
support the claims
SESAMO / EADS use case
M. Waßmuth et al EADS IW S&D4RCES ’11, 09

50. Introduction to the methodology
Claims Argument Evidence (CAE)
The behaviour of the device or service
The process and procedures (how hard we have tried)
Compliance with standards and regulations
Changes to consider:
• Change the (top level) claims, if any
• Augment the arguments?
• Change how we deal with evidence?
SESAMO / EADS use case
Robin Bloomfield, Kateryna Netkachova, Robert Stroud

51. Outline of Safety Case structure
Overall approach
Top claim
Split into sub-claims
Structure of argumentation
SESAMO / EADS use case
Robin Bloomfield, Kateryna Netkachova, Robert Stroud

52. Justifying structure Work to be done applying tables
SESAMO / EADS use case
Robin Bloomfield, Kateryna Netkachova, Robert Stroud

53. Security Informed Safety Case
GSN notation no problem
Security Informed Safety Case
Security consideration
Impact on the Case Structure
Some interesting observations
Safety Case:
we use the same process principle here for
safety and security
Supply chain integrity.
Malicious events post deployment.
Design changes to address user interactions, training, configuration, vulnerabilities. Additional functional requirements that implement security controls.
Possible exploitation of the device/service
to attack itself or others.
SESAMO / EADS use case
Robin Bloomfield, Kateryna Netkachova, Robert Stroud

54. Danmarks Tekniske Universitet Compute Prof. Flemming Nielson
DLM (Decentralized Labels Model)
Rules for static checking
Rules for dynamic checking
Use Decentralized Labels for Secure Information Flow between partitions
Partitioning:
we use the same architecture principle here for
safety and security
Decentralized Robustness (2006)
Complete, Safe Information Flow with Decentralized Labels (1998) / Andrew C. Myers, Barbara Liskov - MIT Laboratory for Computer Science
Language-Based Information-Flow Security (2003) / Andrei Sabelfeld and Andrew C. Myers
Decentralized Robustness – Security (2006) / Stephen Chong, Andrew C. Myers - Department of Computer Science, Cornell University
Robustness links confidentiality and integrity properties of a computing system and has been identified as a useful property for characterizing and enforcing security
SESAMO / EADS use case

55. Danmarks Tekniske Universitet Compute Prof. Flemming Nielson
Suppose we have a multi partitioned multi criticality system comprising DO-178C level A to level C from the safety side and a multiple independent levels of security system comprising Common Criteria security levels EAL 7 to EAL 5 respectively. These security levels can be represented as principals in the system, where the secret or EAL 7 principal can act for the classified or EAL 6 principal, and the classified or EAL 6 principal can act for the unclassified or EAL 5 principal in any way from higher to lower secrecy. This “act for” relationship is building a hierarchy.
When a superior owner in the hierarchy states that a flow must not occur, this flow is removed from the reader sets of all inferior owners. However, if a superior owner does not try to prevent a flow, inferior owners may still prevent it. Thus, the inferior owner’s policy must be equal or more restrictive as the superior owner’s policy.
The user can further assign security classes to other principals in the system by allowing them to act for one of these principals; he correspondingly marks each data item as readable by the appropriate security level principal.
That makes decentralized labeling a useful model for a multi critical partitioned system for ensuring security for inter-partition communication. But it does make decentralized labeling senseless for intra-partition communication for the same security label, and a partition has to be certified to exactly one, would allow the same readers implicitly and when expanding the label to all the allowed (o,r) flows inside a partition to the same readers explicitly. But that is no problem, since that is the idea of a partition.
An expansion of a label L = {o1: r1, r2; o2: r2, r3; ...; om: rn, ...} finally is: here with a principal “act for” partitions hierarchy all variables in a partition having the same label
Where I is a label’s component “om: rn, ...”, R is the readers expansion function, X is the label interpretation function. Intuitively a flow (o,r) is implied by a label L if every owner who can act for o permits the flow, either explicitly, by allowing r to read it, or implicitly, by allowing some principal that r can act for to read it.
EAL 7
implicitly allowed by reader constraint:
EAL 6
EAL 6
EAL 5
EAL 5
implicitly allowed by owner constraint:
EAL 4
EAL 3
EAL 3
expanded label:
EAL 2
EAL 1
EAL 1
SESAMO / EADS use case

56. The final Solution of a partitioned System is the Scheduling Policy:
To implement the IMA methodology for modelling and configuring an IMA platform especially the IMA fundamental principle of partitioning
includes the design of the security building block partitioning itself and, based on that partitioning
includes the firewall for inter-partition communication and
the distributed labelling for inter-partition communication
both being the implementation of inter-partition flow control
An integrated approach of modelling guarantees consistency, which is the main driving factor and the main reasoning, since
"For-security-reasons-added-code" (e.g. to encrypt, or a firewall, simply all code added) has to be save and must be certified to the safety-level defined.
If an inter-partition firewall is in the communication pass to a high-safety-level partition, the firewall has to run in an other partition with minimum that safety level
In that other partition, all processes including the firewall have to be certified to that safety level to a minimum
For IMA an operating real time scheduling policy, e.g. keeping all the specified point-to-point latencies, is the solution
Since security must not but can destroy that, urging to again start at the very beginning, security has to be done before safety including:
getting a working IMA scheduling policy, leading to
safety-certifying the system including security related code
If that cannot be done in one throw, several iterations might be necessary, but always doing security before safety.
SESAMO / EADS use case

57. Use case: Focus on Gateway
design process
S/W safety
architecture
design processes
S/W security
assessment process
Use case: Focus on Gateway CC
Common Criteria
EAL (Evaluation Assurance Level)
PP (Protection Profile)
ST (Security Target)
TOE (Target of Evaluation)
SAE
ARP 4754
Aerospace Recommended Practice /
Guidelines for processes FTA / FMEA
Security Design/Assessment
Security Target
EUROCAE ED 202/3/4
Security Level Classifications 
Relative Security Levels 
Effectiveness = reduction in likelihood 
DO-178C
Software Development
Process
accomplishment summary = Safety Case
PikeOS
Separation Kernel
Partitions / IMA / MILS
Gateway
SAE
ARP 4761
Aerospace Recommended Practice /
Guidelines and Methods for conducting the Safety Assessment
FTA / FMEA
ARINC REPORT 811
Security Informed
Safety Case
ARINC 653
IMA
Avionics Application Software
standard Interface
& Partitions
Multiple Independent Levels of Security
MILS
high-assurance security architecture based on Partitions and controlled information flow
SESAMO / EADS use case

58. Partners EADS SYSGO Adelard City University London
Use case provider, investigations, IMA / MILS / gateway
SYSGO
Support on use case, investigations, IMA / MILS / gateway
Adelard
Security-informed safety cases
City University London
Security-informed safety case
Diversity building blocks
Danish Technical University
information flow control using DLM (Decentralized Label Model) - just started an
alternative
SESAMO / EADS use case

59. SAFETY AND SECURITY IN AVIONICS
Thank You
Any Questions?
SESAMO / EADS use case