www.thalesgroup.com
Early Validation of IMA
Model-Based Safety Approach for Early Validation of
integrated and modular avionics architectures
2 /2 / Plan
� Safety problematic of integrated and shared resourc es
� Modeling for Safety assessment in early validation
� Conclusion
3 /3 / Shared Resources Safety problematic
What is a shared resource system ?
� Platforms or communication network hostingseveral A/C functions
� Integrated Modular Avionics …
� Before : 1 aircraft function = 1 computer
� Now : x functions = 1 computer thanks to partitioning
� A664 network : multiplexed communication busses
� Before : ARINC 429 busses : 1 transmitter => x subscribers
� Now : 1 network : x transmitters => x subscribers
� Dedicated safety mechanisms� IMA partitioning = segregation of the avionics applications
� To allow partition faults to be contained (better robustness to faults and availability)
� To embed functions of different Development Assurance Level
� To allow systems to be developed, tested and certified separately (incremental certification)
� A664 network = deterministic routing through “Virtual Links (VL)”
� Redundancy of VL routes and Traffic Integrity (vs. corruption, babbling, etc.)
4 /4 / Shared Resources Safety problematic
Which Safety objectives ?
� “Resources” problematic : complex architecture� design constraints for allocation of applications to hardware module(s) leading to :
� shared hardware hosting different functions with different severities
� potential dependencies between functions hosted by different hardware modules
>
F1
Processing Module #1
F1'
Hardware
Function
Application
F1'’
Processing Module#2 Processing Module #3
F1'F1'’
F2
F3
F4
F3F4
F2
Dependencies between functions
Allocation Hardware Function
Functional
architecture
Physical
architecture
5 /5 / Shared Resources Safety problematic
� Safety assessment is completed at the end of the V& V cycle� Due to modular and incremental design :
� Embedded functions may not be known at the beginning of the system design
� As one resource hosts several aircraft functions :
� Systems’ Functional Hazard Analysis (FHA) may not covered all resource failures
� Need of assessment of effects of cumulative functional failures at Aircraft level
>
Processing Module #1
Hardware
Function
Application
Processing Module#2 Processing Module #3
F1'F1'’
F2
F3
F4
F2 loss
F3 loss
F1 loss
Module #3 failure
F2 loss
F3 loss
FHA
FHA
Physical
architecture
Allocation Hardware Function
F1
F1'
F1'’
F3F4
F2
Dependencies between functions
Functional
architecture
6 /6 / Plan
� Safety problematic of integrated and shared resourc es
� Modeling for Safety assessment in early validation
� Conclusion
7 /7 / Towards Model-Based Safety Approach
Proven approach and tool
� Tool based on Altarica language (formalized by the La BRI)
� Altarica Dataflow variant
� Safety workbench
� Qualified and used on past civil certified programs
� Specific HMI provided by the tool
� Reusable libraries of nodes, failure rates database
� Syntax & coherence control of the code
� Interactive step-by-step simulation
8 /8 / Towards Model-Based Safety Approach
Model exploitation
� Definition of FHA events or other observers for saf ety-critical functions
� Step by step simulation
� Computation of Fault-Trees or Sequences for Failure Conditions
� Generation of “system FMEA” (single failures assessme nt)
H/W resources model & embedded functions
Expected observations of :- Impact on Failure Conditions- Cockpit effects (crew alerting, …)
Cockpit display
ALT DISAGREEATT DISAGREESPD DISAGREE
Hardware Architecture
Pattern level 1 level 2 level 3 ABS_component HW_component Function's pattern
FlightWarning Channel_A IOx channel_IO11
FlightWarning Channel_A network_IOxtoProc SWUA1
FlightWarning Channel_A IOy channel_IO12
FlightWarning Channel_A network_IOytoProc SWUA2,SWUA1
FlightWarning Channel_A network_oppIOxtoProc SWUA1
FlightWarning Channel_A network_oppIOytoProc SWUA2,SWUA1
FlightWarning Channel_A Processing channel_Proc1
FlightWarning Channel_B IOx channel_IO21
FlightWarning Channel_B network_IOxtoProc SWUA1
FlightWarning Channel_B IOy channel_IO22
FlightWarning Channel_B network_IOytoProc SWUA2,SWUA1
FlightWarning Channel_B network_oppIOxtoProc SWUA1
FlightWarning Channel_B network_oppIOytoProc SWUA2,SWUA1
FlightWarning Channel_B Processing channel_Proc3
Dual_Active_Standby
Function architecture
Network B(SWM2x)
Network A(SWM1x)
SWM21 SWM22
IMA 1(CPIOM11, CPIOM21)
SWM11 SWM12
IMA 2(CPIOM12, CPIOM22)
FHA FCs
LRUquantitative
objectives
products(MSS('OBS_1channel_loss.FC.true')) = {'IMA.Elec_alim.DC1_loss'}{'IMA.Elec_alim.EMER1_loss'}{'IMA.PSU_PRIM11.loss_PS1'}{'IMA.PSU_PRIM11.loss_PS2'}{'IMA.channel_IO11.CPU_IOMxy.loss'}{'IMA.channel_IO11.ES.loss'}{'IMA.channel_IO11.PSU_Sec.loss'}{'IMA.channel_Proc1.CPU.loss'}
9 /9 / How is built the IMA model ?
3 views in the overall model :
� Functional architecture model
� Physical architecture model
� FHA (Functional Hazard Analysis) model
11 /11 / Objectives of IMA safety modeling
Two main objectives
� Identify weaknesses of proposed IMA architecture(s)
� Determine an optimal allocation :
� For the logical internal architecture of each function
� Choice of an fault-tolerant functional architecture (e.g. COM/MON, etc.)
� Depending on function’s FHA and safety performances of the physical architecture
� Specify quantitative requirements for the physical architecture
� Probability of failure occurrence for essential components
� Taking into account potential redundancies or monitoring at IMA physical level
� Depending on safety objectives associated to one channel
� For the allocation of functions to Hardware resources
� Taking into account each function’s logical architecture (e.g. COM/MON split on 2 IMA channels) and the number of IMA channels
� Depending on comprehensive A/C FHA taking into account potential functional combinations
� Problematic = 3 interdependent axes of architecture optimization
12 /12 /
ArchitecturesIntegrity criteria :Comparison, voters
Availability criteria :Redundancy or backup
Simplex
Duplex
COM/MONDualactive-activeactive-standby
TriplexTriplex-AND
voterTriplex-ORed3 active2 active -1 standby1 active -2 standby
Quadruplex
- Dual COM/MON (4 channels)- Quad COM/MON (8 channels)
A
A
B
A
B
C
A
B
C
D
Safety architectural patterns
13 /13 / Patterns associated to IMA model
Pattern modeling
� Breakdown :
� Internal components :
� Input / Output module(s)
� Processing module(s)
� Communication nodes between IO and processingmodules representing Virtual Link paths throughthe Avionics Data Network
� External Interfaces if relevant
� External Input(s) / Outputs(s)
14 /14 / Example of Altarica codeAltarica code for a basic node
Tabular description
State Automata
Altarica code
node Processing
flow
icone : [1, 3] : out ;
input : {ok,invalid,corrupted} : in ;
output : {ok,invalid,corrupted} : out ;
state
STATE : {SAFE,ERR,LOST} ;
event
loss, uef ;
init
STATE := SAFE ;
trans
STATE = SAFE |- uef -> STATE:=ERR;
STATE != LOST |- loss -> STATE:=LOST;
assert
output = (case{STATE = LOST : invalid,
STATE=ERR : corrupted,
else input)}; // component operative
icone = (case{STATE = LOST : 3,
STATE = ERR : 2,
else 1});
State(s) Domain / Type Initial value
STATE {SAFE,ERR,LOST} SAFE
Event(s) Guard New affectation Law
loss STATE != LOST STATE != LOST exponential(λloss)
error STATE = SAFE STATE = SAFE exponential(λuef)
Flow(s) Domain / Type Direction
input {ok,invalid,corrupted} in
output {ok,invalid,corrupted} out
output(s) Case(s) Value
STATE = SAFE and input = ok ok
STATE = SAFE and input = invalid invalid
STATE = SAFE and input = corrupted corrupted
STATE = LOST invalid
STATE = ERR corrupted
Assertion(s)
Transition(s)
output
15 /15 / IMA Failures propagation
Allocations physical items <-> functional items
� From the “physical” view to the “functional” view
Function #2
Failure Condition
Item F1' Item F1'’
Item F2
Function #1
Component C1
Physical architecture
Item P2
Item P1
Item P3
Dirac(0)
Virtual Status
Component C2
Functional architecture
FHA
Item F1' Item F1'’
Item F2
System
level
Allocation_ItemC2
Allocation_ItemP3
Strong synchronization
Failure Condition
17 /17 / Assessment with Safety Patterns
1st step of IMA architectures Safety assessment
� Definition of Generic Safety objectives for targete d Patterns
� Benchmark of proposed IMA architectures vs. generic objectives
Integrity
MIN
MAJ
HAZ
CAT
18 /18 / Assessment with IMA full functional scope
2nd step of IMA architectures Safety assessment
� Definition of FHA
� Choice of best-suited pattern(s) for the function
� Depending on safety performances computed for each pattern
� Integration of each function in the overall model
� Dependencies with other functions if any
� FHA Failure Conditions (and in combination with other functions)
� Allocation(s) functional items to physical modules
� Assessment of targeted allocations vs. IMA architec tures
19 /19 / Plan
� Safety problematic of integrated and shared resourc es
� Modeling for Safety assessment in early validation
� Conclusion
20 /20 / Conclusion
Conclusion
� Model-Based approach� Improves modularity & reusability of safety analyses
� Supports complex, dynamic systems or large systems safety analyses
� Model handles common modes or cascading failures better than a static analysis
� Summary of the work
� Early Validation of different physical and functional architectures
� Use of safety architectural patterns helps to homogenize design of embedded functions
� Ease quick safety assessment through modular & incremental aspects
� Each view of the model may be refined during the V&V cycle
� The model may be iteratively extended to include new functions
21 /21 / Conclusion
Perspectives
� Model validation
� Validation of the allocation {functional item <-> hardware item} correctness
� Results completeness
� if an architecture is assessed Not OK vs. safety objectives :
� How to be sure that any other allocation will not be compliant ?
� if an architecture is assessed OK vs. safety objectives :
� How to be sure that all possible allocations are covered ?
� Results optimization
� How to determine an optimal allocation {functional item <-> hardware item} ?
� Reducing the required number of IMA hardware modules
� Taking into account additional allocation constraints specified in the functional view (independence, co-location, etc.)