Avionics

Transcription

Avionics

Communication in avionics
Jean-Luc Scharbarg
Université de Toulouse - IRIT/ENSEEIHT/INPT
[email protected]
November 2014
Jean-Luc Scharbarg Université de Toulouse - IRIT/ENSEEIHT/INPT
[email protected]
in avionics
November 2014
1 / 72
Summary
1
Avionics context
2
Classical avionics and the ARINC 429
3
Integrated Modular Avionics (IMA)
4
ARINC 664: Avionics Full DupleX switched Ethernet (AFDX)
5
Worst-case end-to-end delay for AFDX
6
Network calculus for certification of AFDX
7
Trajectory approach for AFDX
8
Interconnection of the AFDX with other technologies
9
Some open issues
[email protected]
in avionics
November 2014
2 / 72
Summary
1
Avionics context
2
3
4
5
6
7
8
9
Some open issues
[email protected]
in avionics
November 2014
3 / 72
Embedded network context
The need for dedicated buses and networks
I
I
I
I
I
Deterministic communications (latency, jitter, . . .)
Periodic and also aperiodic data
Many short data
Temporal synchronization of distributed tasks
Integrity and availability
Buses and networks designed for specific systems
I
Civilian aircraft
F
F
I
Military aircraft
F
F
I
I
I
A distributed architecture without any centralized control
ARINC 429, ARINC 629, ARINC 664
A distributed architecture with centralized control
MIL Std 1553 B, . . .
Space platforms: on-board datalinks, spacewire, 1553, TTEthernet, . . .
Automotive systems: CAN, MOST, LIN, Flexray, . . .
Fieldbuses: Profibus, Interbus, . . .
[email protected]
in avionics
November 2014
4 / 72
Civilian aircraft communications
Avionics
A340
A/C Ops & CABIN
ARINC 429 - 664
IFE
ARINC 429- Ethernet
………
HF/VHF/SATCOM
Platform (s)
Connectivity
AIRLINE
Ground Information System (Airlines, Airbus,…)
[email protected]
in avionics
November 2014
5 / 72
Civilian aicraft communications
The Air/ground communications
I
I
They provide several means for the communication between aircraft and
ground stations for navigation and control: HF, VHF, SATCOM, . . .
ATC: Air Traffic Control, AOC: Airline Operational Communications,
...
The Airline passenger communications
I
I
Part of In-Flight Entertainment (IFE), it includes communications
(telephony, e- mail, . . .), information (news, weather, web content . . .),
and interactive services (video games, shopping/e-commerce, surfing
the web)
Based on Commercial off-the-shelf (COTS) technologies
The Cabin Communications
I
Based on Ethernet technology open to operational functions
(maintenance, . . .)
The Avionics Communications
I
I
They represent all the information exchanged between the avionics
equipment and systems used to the control of the aircraft
Based on aeronautical technologies: ARINC 429, AFDX, . . .
[email protected]
in avionics
November 2014
6 / 72
Avionics systems characteristics
Avionics: electronic systems installed in an aircraft
I
I
Calculators and their software, sensors and actuators
Communication links between these elements
Example of avionic systems: autopilot, navigation, flight control, . . .
Constraints on the avionics systems
I
I
I
I
Volume and weight limitations
Correct behavior in severe conditions: heat, vibrations, electromagnetic
interferences, . . .
Safety level required, depending on the system (ARP 4754):
catastrophic (failure = loss of the aircraft), hazardous, major, minor,
no effect
Segregation between critical functions
Aeronautical Radio INCorporated (ARINC): leadership in the
development of specifications and standards for avionics equipment
Airlines Electronic Engineering Committee (AEEC): development and
maintenance of specifications and standards (airlines, governments,
ARINC)
ADN: Aircraft Data Network
[email protected]
in avionics
November 2014
7 / 72
Avionics systems evolution
In the 1950’s
I
I
Very simple standalone systems
One single calculator for the execution of all the functions
In the 1960’s
I
I
The beginning of modern avionics
Replacement of analog devices by their digital equivalent
Since then
I
I
I
Huge increase in the complexity of avionics
More and more digital equipments for existing or new functions
New needs inherent to the evolution of civil aviation or better answers
to existing problems (e.g. fly-by-wire command system)
Increase in the number of embedded systems and functions ⇒
increase in communication needs
Integrated Modular Avionics (IMA) in the 1990’s: better sharing of
execution and communication resources
I
I
First implementation of IMA for the Boeing 777, based on the ARINC
629 multiplexed data bus
IMA in the Airbus A380, based on the ARINC 664 (switched Ethernet)
[email protected]
in avionics
November 2014
8 / 72
Summary
1
Avionics context
2
3
4
5
6
7
8
9
Some open issues
[email protected]
in avionics
November 2014
9 / 72
Classical avionics architecture (up to A340)
Each equipment (LRU) dedicated to a system function (braking,
flight computers, . . .): sensors, actuators, calculators . . .
natural segregation between the equipments
[email protected]
in avionics
November 2014
10 / 72
Data transmission in classical avionics
A network of equipments
F1
F2
F3
G1
G2
Each data is transmitted from its source to every equipment that
needs the data
One dedicated line for each data
Repetitive transmission of the data on each line
Each line: a mono-emitter ARINC 429 data bus
Each data individually identified by a label
Low bit rate: 12 Kbits/s to 100 Kbits/s
At most 20 receivers per line
[email protected]
in avionics
November 2014
11 / 72
The ARINC 429 main characteristics
Unidirectional data bus standard
Transmission of messages over two twisted pairs
The ARINC 429 data word
P SSM
32
I
I
I
DATA
29
F
F
1
Binary Coded Decimal (BCD)
Two’s complement binary notation (BNR)
...
SDI (Source Destination Identifier): different possibilities
F
F
I
LABEL
8
P (parity bit): so that there is an odd number of “1” in the 32-bit word
SSM (Sign/Status Matrix): contains equipment condition, operational
mode or validity of data contents, depending on the format of the data
DATA: the data, with a number of different formats
F
I
SDI
11
Identification of the receiver for which the data is destined
Identification of the source of the transmission if the label can be sent
on different data buses
LABEL: identification of the data and its associated parameters
[email protected]
in avionics
November 2014
12 / 72
Classic avionics evolution
A310 (1983)
A320 (1988)
A340 (1993)
Avionic Volume
745 litres
760 litres
830 litres
A380 (2005)
Number of equipment
77
102
115
147
Embedding Software
4 Mo
10 Mo
20 Mo
100 Mo
Number of ARINC 429
136
253
368
1000 (AFDX)
Computing Power
60 Mips
160 Mips
250 Mips
90% of the avionic
Avionic repartition
[email protected]
in avionics
November 2014
13 / 72
Summary
1
Avionics context
2
3
4
5
6
7
8
9
Some open issues
[email protected]
in avionics
November 2014
14 / 72
IMA architecture (ARINC 651)
Backplane databus
APEX
APEX
APEX
Function 3
Function 2
APEX
Function 1
Function 3
Function 1
Function 1
Function 2
LRM I/O
LRM Core
LRM Core
...
Function 1
LRM Gateway
Rack 1
Aircraft data bus
ARINC 429
Equipment
(function 1)
Equipment
(function 2)
API
API
Function 1
Function 3
LRU
ARINC 429 Equipment
(function 3)
LRU
[email protected]
in avionics
November 2014
15 / 72
IMA characteristics
Hardware components
I
LRM (Line Replaceable modules): resources in common cabinets
F
F
F
I
I
Core modules for the execution of the applications
Input/output modules for communications with non-IMA equipments
Gateway modules for communications between cabinets
LRU (Line Replaceable Unit): existing non-IMA equipments
Backplane databus: ARINC 659
Sharing of execution resources
I
I
An avionics subsystem: a partition with an assigned time window to
execute its application on a shared module
Guarantee isolation between subsystems ⇒ robust partitioning concept
F
F
I
Communications between partitions via ports (APEX: APplication
EXecutive)
F
F
I
Spatial isolation: limitation and protection of the address space of each
partition, e.g. by a MMU
Temporal isolation: static allocation of a time slice for the execution of
each partition, based on WCET
Sampling ports: only the last value of data is stored
Queueing ports: all the values of data are stored
Logical channel: multicast link between ports, independent of the
communication technology
[email protected]
in avionics
November 2014
16 / 72
Summary
1
Avionics context
2
3
4
5
6
7
8
9
Some open issues
[email protected]
in avionics
November 2014
17 / 72
The reasons for the AFDX
ARINC 429 is no more sufficient: too many buses are needed
ARINC 629 is too expensive
Why Ethernet technology ?
I
I
I
I
High throughput offered to the connected units (100 Mbits/s)
High connectivity offered by the network structure
A mature industrial standard
Low connection cost
But Ethernet CSMA/CD is not deterministic
I
I
Potential collision on the physical medium
Binary Exponential Back off retransmission algorithm
The solution adopted for ARINC 664
I
I
switched Ethernet technology: units directly connected by
point-to-point links to Ethernet switches ⇒ possible collision domain =
single link between two elements
Full duplex links ⇒ no more collisions
The problem is shifted to the switch level
[email protected]
in avionics
November 2014
18 / 72
AFDX general architecture
Avionics Computer System
Controllers
Sensors
Avionics
Suvsystem
End
System
Actuators
AFDX
Interconnect
Controllers
Sensors
End
System
Avionics
Suvsystem
End
System
Gateway
Internet
Actuators
Avionics Subsystem: Flight control computer, Global Positioning
System, tire pressure monitoring system, . . .
End System: interface between the Avionics Subsystems and the
AFDX, guarantees a secure and reliable data interchange
AFDX Interconnect: network of switches with full duplex links
Gateway: communication path between the Avionics Subsystems and
the external IP network ⇒ data loading, logging
[email protected]
in avionics
November 2014
19 / 72
Full duplex switched Ethernet example
Switch
Forwarding Table
I/O Processing Unit
Memory Bus
Rx
Buffer
Tx
Buffer
Rx
Buffer
Tx
Buffer
Rx
Buffer
Tx
Buffer
Full Duplex
Links
End
System
End
System
End
System
Autopilot
Heads−up
Display
Other
system
[email protected]
in avionics
Avionics
Subsystems
November 2014
20 / 72
Full duplex switched Ethernet is not deterministic
Temporary congestion on an output port
I
I
Increase of the waiting delay of frames in the Tx buffer
Frame loss by overflow of the Tx buffer
An illustrative example
f1
f2
f3
f4
f5
f6
f7
f8
f9
f10
I
I
Switch
f1,f2,f3,f4,f5,f6,f7,f8,f9,f10
Five frames at the same time ⇒ one frame waits until the transmission
of the four other ones
More than five frames at the same time ⇒ at least one frame is lost
Addition of dedicated mechanisms to classical full duplex switched
Ethernet in order to guarantee the determinism of an AFDX network
[email protected]
in avionics
November 2014
21 / 72
The AFDX key characteristics
Static full duplex Switched Ethernet: no CSMA/CD, no spanning
tree, static 802.1D tables
One FIFO buffer per output port
Traffic characterization based on the Virtual Link (VL) concept
I
I
I
I
Static definition of the flows which enter the network
Multicast path with deterministic routing
Mono transmitter assumption
Sporadic flows (BAG : Bandwidth Allocation Gap)
F
F
I
I
Minimum (Smin ) and maximum (Smax ) frame lengths for each VL
BAG and Smax define the maximum bandwidth allocated to a VL
F
I
Discrete values: 1, 2, 4, 8, 16, 32, 64, 128 ms
Traffic shaping on each emitting end system
Example: BAG = 16 ms and Smax = 128 bytes ⇒ 64000 bits/s
Scheduling of VLs on end systems ⇒ (bounded) jitter
e1
e2
e3
e4
v6,v8
v6,v8,v9
S1
v7,v9
vx,v1
S3
S2
v6,v7
vx,v2
e5
v2,v3
v6,v8,v9
vx,v6,v7
S4
v5
v2,v5
e7
e8
e9
v1,v3
v1,v3,v4
S5
v4
[email protected]
in avionics
e6
e10
November 2014
22 / 72
AFDX VL integration
APEX
port 2
APEX
port 1
UDP1
IP10
UDP2
IP10
part1
MAC3
APEX
port 1
MAC1
UDP1
IP20
APEX APEX
port 2 port 3
UDP2
IP20
UDP3
IP20
part2
source APEX port
source UDP port +
source IP address
source MAC address
MAC2
end system 1
dest MAC address
end system 2
MAC1
MAC3
part1
UDP1
IP1
APEX
port 1
part2
UDP2
IP3
UDP1
IP3
APEX
port 2
APEX
port 1
UDP2
IP3
UDP3
IP1
APEX APEX
port 2 port 3
end system 3
MAC3
dest UDP port +
dest IP address
dest APEX port
MAC2
part2
part1
UDP1
IP2
APEX
port 1
UDP2
IP3
APEX
port 2
[email protected]
in avionics
UDP1
IP3
APEX
port 1
UDP2
IP2
APEX
port 2
November 2014
23 / 72
The redundancy management in the AFDX
Frames transmitted on two independent networks
Per Virtual Link
End System
Transmit
A Network
Per Virtual Link
End System
Receive
B Network
Identification of replicas via a sequence number
Ethernet Header
IP Header
14 bytes
20 bytes
UDP Header
Avionics Subsystem messages
Sequence
number
FCS
8 bytes
17..1472 bytes
1 byte
4 bytes
UDP Header and payload
IP Header and payload
Ethernet frame
Elimination of the second received frame
Integrity Checking
A Network
Detect and eliminate
invalid frames
Integrity Checking
B Network
Redundancy
Management
Eliminate
invalid frames
Detect and eliminate
invalid frames
[email protected]
in avionics
November 2014
24 / 72
The packet regulation of Virtual Links
Virtual Link 100
Regulator
BAG = 16
Virtual Link 200
Regulator
BAG = 32
Select frames
for transmission
Replicate
Ethernet frames
Virtual Link
Scheduler
Redundancy
Management
Physical
Link
Physical
Link
Virtual Link 300
Regulator
BAG = 4
Regulator input
1
2
3
BAG
1
BAG
2
BAG
Regulator output
4
1
BAG
3
BAG
4
BAG
2
BAG
1
3
BAG
2
BAG
4
BAG
3
BAG
[email protected]
in avionics
4
BAG
November 2014
25 / 72
The AFDX transmit protocol stack
End System Tx Packets
AFDX services
Message written to AFDX port
Message
UDP
transport layer
UDP header
UDP header
Message
IP fragmentation
IP hdr
IP hdr
One or more packets as
a result of IP fragmentation
IP network layer
Add IP checksum
Add Ethernet header
Eth hdr
VL schedulor
(regulator)
Link level
(Virtual Links)
Redundancy
management
network A
network B
source address = netA
transmit frame
with FCS
Eth hdr
seq #
source address = netB
transmit frame
with FCS
[email protected]
in avionics
November 2014
26 / 72
The AFDX receive protocol stack
End System Rx Packets
Eth hdr
FCS
errors
Rx Controller
Eth hdr
seq #
errors
Integrity Check
Link level
(Virtual Links)
drop packet
Redundancy
management
IP hdr
errors
yes
IP network layer
no
Packet
complete?
yes
IP chechsum
ICMP
IP fragmentation
yes
direct mapping
only if no IP
fragmentation
UDP header
UDP
transport layer
AFDX port services
Message
DEMUX
Message
AFDX Rx port queue
[email protected]
in avionics
November 2014
27 / 72
An industrial AFDX configuration
[email protected]
in avionics
November 2014
28 / 72
2 redundant networks, 9 switches per network, 24 ports per switch,
123 end systems
984 VLs, 6412 paths
100 Mbits data rate
BAG and maximum frame length
Bag
(ms)
2
4
8
16
32
64
128
Number
of VL
20
40
78
142
229
220
255
Smax
(bytes)
0-150
151-300
301-600
601-900
901-1200
1201-1500
> 1500
Number
of VL
561
202
114
57
12
35
3
[email protected]
in avionics
November 2014
29 / 72
Length of VL paths
Number of crossed switches
1
2
3
4
Number of paths
1797
2787
1537
291
Load of the links
70
Number of links
60
number of link
50
40
30
20
10
0
0
0.05
0.1
0.15
output link load
0.2
0.25
0.3
[email protected]
in avionics
November 2014
30 / 72
Summary
1
Avionics context
2
3
4
5
6
7
8
9
Some open issues
[email protected]
in avionics
November 2014
31 / 72
End-to-end delay on an AFDX network
Three parts in the delay
I
I
I
Transmission times on links (known): link bandwidth, frame size
Switching latency (known)
Waiting time in FIFO queues (unknown)
mi1
mi2
mi3
mi4
v1
v2
v3
v4
v1 ,v2
v1 ,v3,v4,v5
v2
mi6
mi7
v3,v4
mi5
v5
Best-case delay: no waiting time in FIFO queues
Worst-case delay: maximum overall waiting time in FIFO queues
Distribution of the delay: distribution of the waiting time in FIFO
queues
[email protected]
in avionics
November 2014
32 / 72
computed upper bound
real maximum delay
observed distribution
of the delay
maximum observed delay
minimum delay
probability
Characterisation of the end-to-end delay of a flow
end−to−end delay
pessimism of the
computed upper bound
Best-case delay
I
Most of the time easy to obtain
Worst-case delay
I
I
I
Most of the time difficult to obtain
Mandatory to guarantee that the deadlines are met
Certification for the A380: network calculus ⇒ sure upper bound
Distribution of the delay
I
Shows the real behaviour of the network
Jean-Luc Scharbarg
[email protected]
in avionics
I Université de Toulouse - IRIT/ENSEEIHT/INPT
November 2014
33 / 72
Worst-case end-to-end delay of a flow
es1
es2
v1,v2
s1
v3,v4
es3
v1
v2
v3
v4
v5
v6
v7
BAG (vi )
4 ms
4 ms
4 ms
4 ms
4 ms
4 ms
4 ms
v1,v2,v3,v4
v1,v3,v5,v6,v7
s2
v5,v6,v7
smin (vi )
625 bytes
625 bytes
750 bytes
500 bytes
625 bytes
500 bytes
625 bytes
v2,v4
smax (vi )
625 bytes
625 bytes
750 bytes
500 bytes
625 bytes
500 bytes
625 bytes
es4
es5
Tx
50 µs
50 µs
60 µs
40 µs
50 µs
40 µs
50 µs
Worst-case delay of v1 ⇒ identifie a worst-case scenario for v1
[email protected]
in avionics
November 2014
34 / 72
Arbitrary scenario for v1
v1,v2
es1
es2
0
50
3
s2
200
250
300
350
es4
es5
400
450
t
1
4
s1
es3
150
v2,v4
1 6
2
es1
es2
100
45
v1,v3,v5,v6,v7
s2
v5,v6,v7
es3
3 72
v1,v2,v3,v4
s1
v3,v4
3
7
2
7
4
1
6
5
3
5
6
1
End-to-end delay for v1 : 170 µs
[email protected]
in avionics
November 2014
35 / 72
Maximizing the delay in source end system
v1,v2
es1
es2
0
50
100
45
150
s2
250
300
350
es4
es5
400
450
t
1
4
s1
es3
200
2
3
v2,v4
1,2 6
es1
es2
v1,v3,v5,v6,v7
s2
v5,v6,v7
es3
3 7
v1,v2,v3,v4
s1
v3,v4
3
7
4
7
2
1
6
5
3
5
6
1
[email protected]
in avionics
November 2014
36 / 72
Critical instant in switch output ports: one candidate
v1,v2
es1
es2
v1,v2,v3,v4
s1
v5,v6,v7
es3
0
50
100
es2
s1
es3
s2
es4
es5
150
v2,v4
200
250
300
350
400
450
t
5,6,7
1,2,3,4
es1
v1,v3,v5,v6,v7
s2
v3,v4
2
1
3
4
2
3
4
7
1
5
3
6
7
5
6
1
[email protected]
in avionics
November 2014
37 / 72
Critical instant in switch output ports: another candidate
v1,v2
es1
es2
v1,v2,v3,v4
s1
v5,v6,v7
es3
0
50
100
es2
s1
es3
s2
es4
es5
150
200
v2,v4
250
300
350
400
450
t
5,6,7
1,2,3,4
es1
v1,v3,v5,v6,v7
s2
v3,v4
2
1
4
3
4
2
3
7
1
5
6
7
3
5
6
1
[email protected]
in avionics
November 2014
38 / 72
Are candidate scenarios comparable
Difference between the candidate scenarios: transmission order of the
frames
Impact of a frame f 0 on the worst-case delay
I
I
Transmission time of f 0 (depends on the number of bytes of the
frame): a higher transmission time can lead to a higher impact on one
output port
Number of output ports shared with the frame under study
Worst-case scenario for the presented example
I
frames are sorted, first by decreasing size, then by increasing number of
shared output ports
In some cases it does not lead to the worst-case scenario (next slide
configuration)
[email protected]
in avionics
November 2014
39 / 72
Critical instant in switch output ports: one candidate
v1,v2
es1
es2
v1,v2,v3,v4
s1
v5,v6
es3
0
50
100
150
1,2,3,4
es1
es2
s1
v1,v3,v5,v6
es4
es5
s2
v3,v4
v2,v4
200
250
300
350
400
450
t
5,6
2
1
3
4
2
3
4
1
es3
5
s2
3
6
5
6
1
[email protected]
in avionics
November 2014
40 / 72
Critical instant in switch output ports: another candidate
v1,v2
es1
es2
v1,v2,v3,v4
s1
v5,v6
es3
0
50
100
es2
s1
es3
s2
es4
es5
150
v2,v4
200
250
300
350
400
450
t
5,6
1,2,3,4
es1
v1,v3,v5,v6
s2
v3,v4
2
1
4
3
4
2
3
1
5
6
3
5
6
1
[email protected]
in avionics
November 2014
41 / 72
Exhaustive search for the worst-case delay
Build all possible sequences and simulate
i1
i2
i3
i1
i2
i3
v2
i1
v4
v5
v6
i2
i3
o
or
o
v2
v4
v5
v1, v2, v3,
v4, v5, v6
v5, v6
v1
v3
o
or
o
v1, v2
v3, v4
i1
i2
i3
v5 v3
v2
v5 v3
v2
v4
v6
v6
v1
v4
v1
v1
i2
v6
i3
v5 v2
v4
v5 v2
v4
v3
v6
v6
v3
v1
v1
v2
v1
v3
v4
v6
o
or
o
i1
v3
v1 under study
8 candidate scenarios
o
o
or
o
v2
v4
v6
v5
v3
v2
v6
v3
v2
v6
v4
v5 v1
v5
v4
v1
v1
v3
v5
v2
v4
v6
v3
v5 v1
v2
v4
v6
v5 v3
v1
Two implementations: ad hoc tool in Java, Uppaal
Remaining combinatorial explosion issue
[email protected]
in avionics
November 2014
42 / 72
Summary
1
Avionics context
2
3
4
5
6
7
8
9
Some open issues
[email protected]
in avionics
November 2014
43 / 72
The certification of the AFDX
The need for control of maximum transmission delay: bounded
latency
I
I
I
Description of the network physical architecture
Specification and placement of VLs on this architecture
Evaluation of maximum transmission delay
F
Worst case upper bounds needed for certification
The proof of determinism relies on network calculus assumptions
I
The AFDX network is compliant
F
F
I
Traffic assumptions ⇒ arrival curves
Switch characteristics ⇒ service curves
Theoretical results available ⇒ delay bound for each component
Summary of the approach
I
I
I
Traffic modeling: arrival curves
Component modeling: service curves
Upper bound computation: application of network calculus theorems
An industrial tool has been developed: ConfGen
Used to certify the AFDX network of the A380
[email protected]
in avionics
November 2014
44 / 72
Network calculus: Modeling of the input traffic
Definition of a traffic envelope R ∗ of the traffic function R
∀s ≤ t, R(t) − R(s) ≤ R ∗ (t − s)
A traffic envelope can be defined for each VL
bits
R*(t)
R(t)
111
000
BAG
11
00
BAG
111
000
11
00
time
BAG
Traffic envelope of a VL
R ∗ (t) = γ Smax ,Smax = Smax +
BAG
Smax
×t
BAG
[email protected]
in avionics
November 2014
45 / 72
Network calculus: modeling of the architectural elements
Use of standard elementary building blocks
I
I
I
Multiplexers
Demultiplexers
Buffers
Modeling of an AFDX switch
Input buffer 1
Input buffer 2
MUX
Bounded
delay
8 us
MUX
...
...
Bounded
delay
8 us
Input buffer n
Input ports
MUX
Frame filtering
Switching
Output ports
Service curve βR,T of an output port: technological delay T and rate
of the output link R
β100,16 (t) = max (0, 100 × (t − 16))
[email protected]
in avionics
November 2014
46 / 72
Network calculus: end to end delay calculus
Based on network calculus theorems
I
Upper bound on the delay d in one node
bits
R*(t)
B(t)
d
time
∗
∀t, d(t) ≤ h(R , β)
∗
h(R , β) = sup (inf {d ≥ 0 : R ∗ (t) ≤ β(t + d)})
t≥0
Overall arrival curve at an output port = sum of the arrival curves of
the competing flows
Output curve ⇒ integrate the jitter (upper bound on the delay in the
node)
Data-flow delay calculus: the arrival curves of flows are propagated
[email protected]
in avionics
November 2014
47 / 72
Network calculus: illustration on a sample example
e1
e2
e3
e4
v1
S1
v2
v3
v1,v2
v1,v3,v4,v5
S3
S2
v3,v4
e5
v4
v2
v5
e6
e7
All the VLs have the same BAG (4000 µs) and Smax (4000 bits)
Arrival curve of each VL in its first switch
bits
R*(t) =
4000
1,4000
r=1
time
Cumulative arrival curve in switches S1 and S2
γ1,4000 + γ1,4000 = γ2,8000
[email protected]
in avionics
November 2014
48 / 72
Upper bound on the delay of v 1, v 2, v 3 and v 4 in their first crossed
switch: 96 µs
I
I
I
Technological latency: 16 µs
Maximum waiting time in the output buffer: 40 µs
Transmission time: 40 µs
bits
R*(t) =
2,8000
B
8000
100,16
96 us
time
Output curve of v 1, v 2, v 3 and v 4 after their first crossed switch
bits
R*(t) =
1,4040
4040
−40
0
time
[email protected]
in avionics
November 2014
49 / 72
Cumulative arrival curve in the upper output port of switch S3
γ1,4040 + γ1,4040 + γ1,4040 + γ1,4000 = γ4,16120
Upper bound on the delay of v 1, v 3, v 4 and v 5 in S3: 177.2 µs
Cumulative arrival curve in the lower output port of switch S3
γ1,4040
Upper bound on the delay of v 2 in S3: 56.4 µs
Upper bound on the end-to-end delay of v 1, v 3 and v 4
40 + 96 + 177.2 = 313.2 µs
Upper bound on the end-to-end delay of v 2
40 + 96 + 56.4 = 192.4 µs
Upper bound on the end-to-end delay of v 5
40 + 177.2 = 217.2 µs
[email protected]
in avionics
November 2014
50 / 72
Network calculus: flow serialization
Two frames cannot arrive simultaneously from the same link
I
I
I
I
Let’s consider the upper output port of switch S3
The VLs v 3 and v 4 arrive from the same link
The maximum burst from this link is the maximum frame size among
v 3 and v 4
The second frame is received at the rate of the link
Optimized cumulative arrival curve from the link shared by v 3 and v 4
I
Reduction of the burst
bits
Rlink
1,4040
8080
4040
0
I
time
The upper bounds on the end to end delays of v 1, v 3, v 4 and v 5 are
reduced
F
F
273.6 µs for v 1, v 3 and v 4
177.6 µs for v 5
[email protected]
in avionics
November 2014
51 / 72
Summary
1
Avionics context
2
3
4
5
6
7
8
9
Some open issues
[email protected]
in avionics
November 2014
52 / 72
The Trajectory approach: Where does it come from
Worst-case response time of tasks in a distributed system
I
I
Set of computing nodes interconnected by links
One periodic task Fi
F
F
F
F
F
A period Ti and a release jitter Ji
A static path Pi
Bounded Execution time Cih on each node h of the path
Bounded transmission delay on the links (between lmin and lmax )
The path never crosses twice the path of another task
τ1
1
τ2
4
2
3
6
5
7
9
τ3
8
10
[email protected]
in avionics
November 2014
53 / 72
The trajectory approach and the AFDX
τi
Ti = BAG
Ci = smax
R
node 1
Le1 →S1
e1
b
node 2
LS1 →S2
b
S1
R
node 3
b
S2
R
e2
R
VL vi :
BAG
smax
switching
delay
(16µs)
switching
delay
(16µs)
Each flow in the network is upper-bounded
The routing of flows is statically defined
No packets are lost
[email protected]
in avionics
November 2014
54 / 72
The trajectory approach: illustration on a sample example
v1
es1
es2
es3
es4
es3 3=f(es3)
v1,v2
S1
v2
v3
S2
v1,v3,v4,v5
S3
v5
v3,v4
v2
es6
es7
es5
v4
3=p(es3)
S2
3=p(S2)
S3
0
40
80
120
160
200
240
280
320
360
40 + 16 + 40 + 16 + 40 = 152
= C3e3 + L + C3S2 + L + C3S3
X
= C3 +
max {Cjh } + (| P3 | −1) × L
h∈P3 ,h6=last3
j∈sp3 ∪{3}
One frame of v3 alone on its trajectory
Transmission time on one link: 40 µs
Switching latency: 16 µs
[email protected]
in avionics
November 2014
55 / 72
v1
es1
es2
S1
v2
es3
es4
es3 3=f(es3)
v3
S2
v1,v3,v4,v5
v1,v2
S3
v3,v4
v5
v2
es6
es7
es5
v4
4=f(S2) 3=p(es3)
S2
4=f(S3)
S3
0
40
80
120
3=p(S2)
160
200
240
280
320
360
40 + 16 + 40 + 40 + 16 + 40 − (56 − 30) = 152
S2
S2
−
a
= C3e3 + L + C4S2 + C3S2 + L + C3S3 − ap(e
f (S2 )
3)
X
X
h
=
Cj +
max {Cj } + (| P3 | −1) × L − ∆S2
j∈sp3 ∪{3}
h∈P3 ,h6=last3
j∈sp3 ∪{3}
Add a frame from v4
Substract the quantity which is counted twice
[email protected]
in avionics
November 2014
56 / 72
es1
es2
es3
es4
es3 3=f(es3)
v1
S1
v2
v3
S2
v1,v3,v4,v5
v1,v2
S3
v3,v4
v5
v2
es6
es7
es5
v4
4=f(S2) 3=p(es3)
S2
S3
0
1=f(S3)
5
4=p(S2)
3
40
80
120
160
200
240
280
320
360
40 + 16 + 40 + 40 + 16 + 80 + 40 − (56 − 30) − (86 − 20) = 180
= C3e3 + C4S2 + C3S2 + C1S3 + C5S3 + C3S3 + (3 − 1) × L − (∆S2 + ∆S3 )
X
X
=
Cj +
max {Cjh } + (| P3 | −1) × L
j∈sp3 ∪{3}
−
X
h∈P3 ,h6=last3
j∈sp3 ∪{3}
∆h
h∈P3 ,h6=first3
Add frames from v1 and v5
[email protected]
in avionics
November 2014
57 / 72
v1
es1
es2
es3
es4
es3 3=f(es3)
v3
S2
v1,v3,v4,v5
v1,v2
S1
v2
S3
v3,v4
v5
v2
es6
es7
es5
v4
4=f(S2) 3=p(es3)
S2
4=p(S2) 1=f(S3)
S3
0
40
80
120
160
5
200
3
240
280
320
360
40 + 16 + 40 + 40 + 16 + 80 + 40 = 180
= C3e3 + C4S2 + C3S2 + C1S3 + C5S3 + C3S3 + (3 − 1) × L
X
X
=
Cj +
max {Cjh } + (| P3 | −1) × L
j∈sp3 ∪{3}
h∈P3 ,h6=last3
j∈sp3 ∪{3}
Worst-case assumption: ∆h = 0 for all the nodes
[email protected]
in avionics
November 2014
58 / 72
The trajectory approach: worst-case delay computation
Sporadic flows ⇒ more than one frame per flow
=
X
j∈sp3 ∪{3}
+
t + A3,j
1+
Cj +
Tj
X
max {Cjh } + (| P3 | −1) × L
h∈P3 ,h6=last3
j∈sp3 ∪{3}
Upper bound on the number of frames per flow obtained thanks to
first
first
first3,j
A3,j = Smax3j,3 − Sminjj,3 − M3
f(h−1) frame sequence
h−1
frame sequence
Jj
j,i
Sfirst
max j
first j
t
first j,i
j,i
afirst
f i = t+ S max i
first i,j
Mi
h=first j,i
fi
first
+ Smaxj3,j
t + A i,j
fi
t
j,i
Sfirst
min j
t
earliest generation time
latest generation time
[email protected]
in avionics
November 2014
59 / 72
The trajectory approach: worst-case delay computation
Worst-case traversal time for a frame from v3
I
I
I
I
The frame is generated by es3 at time t
S3
It leaves S3 at time W3,t
S3
It arrives at its destination at time W3,t
+ C3
S3
Worst-case traversal time: maximum value of W3,t
+ C3 − t for any t
(µs)
800
t 7→ t
600
S3
W3,t
+ C3
400
272
S3
R3 = max W3,t
+ C3 − t = 272 µs
200
0
0
1000
2000
3000
4000
t (µs)
[email protected]
in avionics
November 2014
60 / 72
The trajectory approach: flow serialization
es1
es2
3
S2
v1,v2
v1,v3,v4,v5
S3
v2
v3
S2
v3,v4
v5
es6
es7
es5
v4
4
1
S3
0
S1
v2
es3
es4
5
es5
v1
40
80
3
5
4
120
160
200
240
280
320
360
One frame of v5 on its trajectory
Assumption: ∆S3 = 0 ⇒ a1S3 = a3S3 = a4S3 = a5S3
Pessimistic because a3S3 and a4S3 are different
Here, ∆S3 > 40µs
[email protected]
in avionics
November 2014
61 / 72
The trajectory approach: identification of serialized frames
Input ports
AFDX switch
Output port
switching and
FIFO scheduling
p
IP0
m
IP1
IP2
f(h)
IP3
Delta h
OP
f(h)
Theta
p
[email protected]
in avionics
...
November 2014
62 / 72
Pessimism of the upper bounds
Sure upper bound of the
exact worst−case delay
Exact worst−case delay
Sure lower bound of the
exact worst−case delay
Principle of the evaluation
Exact pessimism
end−to−end delay
Upper bound of the pessimism
An unfavorable scenario
The trajectory approach
Upper bound on the pessimism of the trajectory approach on an
industrial configuration
I
I
Between 0 % and 33 %
On average 6.5 %
Upper bound on the pessimism of the network calculus approach on
an industrial configuration
I
I
Between 0.8 % and 63 %
On average 13.5 %
[email protected]
in avionics
November 2014
63 / 72
Summary
1
Avionics context
2
3
4
5
6
7
8
9
Some open issues
[email protected]
in avionics
November 2014
64 / 72
Interconnection with fieldbuses
System A
supplier xx
Node
Node
supplier xx
...
Node
IMA
LRU
LRU
AFDX
world
CAN bus
Node
Node
...
SWITCH
Node
SWITCH
IMA
CAN bus
System B
LRU
LRU
Low-cost or low power equipments don’t speak AFDX
Existing solution and supplier does not want to modify it
[email protected]
in avionics
November 2014
65 / 72
Open world interconnection
Open world
Avionics
server
IFE
Ethernet network
1111
0000
0000
1111
0000
1111
SCI
0000
1111
switch
LRU
CAN CPIOM
LRU
switch
switch
LRU
CPIOM
CAN
LRU
CAN
A429
LRU
LRU
Avionics world
[email protected]
in avionics
November 2014
66 / 72
Summary
1
Avionics context
2
3
4
5
6
7
8
9
Some open issues
[email protected]
in avionics
November 2014
67 / 72
Integration of the scheduling of flows
No global clock in an AFDX network: clocks of end systems are
independant
Each end system schedules the VLs that it generates: local
synchronisation with the clock of the end system
mi1
v1
v1,v2
C1
mi2
v1,v2,v3,v4
v2
v3
v3,v4
v1
v2
mi1
v4
v3
v4
mi2
mi1 and mi2 don’t have a common clock
The work which is being done
I
Integration of the scheduling of flows by end systems, assuming only
periodic flows (⇒ offsets)
F
F
F
Network calculus: results show a significant improvement [ETFA’10]
Trajectory approach: same as network calculus (to be validated)
Model checking: results show a significant improvement
[SIES’11,ETFA’12]
[email protected]
in avionics
November 2014
68 / 72
Heterogeneous flows on a heterogeneous network
architecture
AFDX network is under-used
Two ideas for a better use of the network
I
Assign priorities to avionics flows in order to favour flows with higher
worst-case delays
F
F
I
Needs a worst-case delay analysis that copes with priorities efficiently
Needs a priority assignment algorithm (Audsley algorithm?)
Share the network between avionics and non avionics flows
F
F
Needs a worst-case delay analysis that copes with traffic classes
efficiently
Needs a clear segregation between flows
AFDX is interconnected with other communication technologies (e.g.
CAN) through gateways
I
I
Gateway design
End-to-end delay analysis with heterogeneous network features
[email protected]
in avionics
November 2014
69 / 72
Probabilistic analysis
Up to now, certification process based on guaranteed delay upper
bound
Worst-case delay scenario: very rare event
Leads to over-dimensionning of the network
Do we really need a guaranteed upper bound?
I
Is it ok if the probability to exceed the deadline is 10−12 ?
Avionics functions designed to behave correctly even if some (rare)
frames are lost ⇒ computing a probabilistic upper bound makes sense
A preliminary study based on probabilistic network calculus (Vojnovic
framework)
I
I
I
I
Flows have to be independant
True at the input end system level
No more true after one switch
Solution: agregate the switches, but the proabilistic feature is partly
lost
Open problem: can we apply Extreme Value Theory?
Probabilistic analysis is needed if wireless technologies are integrated
in avionics network architecture
[email protected]
in avionics
November 2014
70 / 72
References
[ETFA’12] Muhammad Adnan, Jean-Luc Scharbarg, Jérôme Ermont, Christian Fraboul. An
imroved timed automata approach for computing exact worst-case delays of AFDX sporadic
flows. ETFA’2012, Krakow, september 2012.
[ECRTS’12] Henri Bauer, Jean-Luc Scharbarg, Christian Fraboul: Worst-case backlog evaluation
of avionics switched Ethernet networks with trajectory approach. ECRTS’2012, Pisa, july 2012.
[SIES’12] Xiaoting Li, Jean-Luc Scharbarg, Christian Fraboul: Worst-case delay analysis on a
real-time heterogeneous network. SIES’2012, Karlsruhe, june 2012
[WiPRTAS’12]Xiaoting Li, Jean-Luc Scharbarg, Christian Fraboul: Applying trajectory approach
for the worst-case delay analysis of a heterogeneous real time network. WiP session of
RTAS’2012, Beijin, april 2012.
[RTSJ’12] Henri Bauer, Jean-Luc Scharbarg, Christian Fraboul: Applying trajectory approach
with static priority queueing for improving the use of available AFDX resources. Real Time
Systems Journal, vol. 48, no 1, p. 101–133, january 2012.
[SIES’11] Muhammad Adnan, Jean-Luc Scharbarg, Christian Fraboul: Minimizing the search
space for computing exact worst-case delays of AFDX periodic flows. SIES’2011, Vasteras, june
2011.
[TII’10] Henri Bauer, Jean-Luc Scharbarg, Christian Fraboul: Improving the worst-case delay
analysis of an AFDX network using an optimized trajectory approach. IEEE transactions on
industrial informatics, vol. 6, no 4, p. 521–533, november 2010.
[ETFA’10] Xiaoting Li, Jean-Luc Scharbarg, Christian Fraboul: Improving end-to-end delay
upper bounds on an AFDX network by integrating offsets in worst-case analysis. ETFA’2010,
Bilbao, september 2010.
[ECRTS’06] Hussein Charara, Jean-Luc Scharbarg, Jérôme Ermont, Christian Fraboul. Methods
for bounding end-to-end delays on an AFDX network. ECRTS’2006, p. 193–202, Dresden, July
2006.
[email protected]
in avionics
November 2014
71 / 72
Thank you for your attention
[email protected]
in avionics
November 2014
72 / 72

Avionics

Transcription

Similar documents

Product Configuration for CAN, ARINC 429 and AFDX

Refurbishing a Beaver or Turbo-Beaver?

FAST Future Architecture System Test

1979 Piper Aerostar 600A

Edgar Fouches Military Documents

Slides

IMA2G

The AFDX - MIL-STD

PDF (Author`s version) - OATAO (Open Archive Toulouse Archive

an article - J`s Broken Aero