real-time embedded systems 1 & ada · 2017. 4. 28. · parallel processing (tasks, synchronous...
TRANSCRIPT
1
REAL-TIME EMBEDDED SYSTEMS & ADAMILOS PANIC, APRIL 2017
SENIOR SOFTWARE DEVELOPER, ENDAVA BELGRADE
PHD CANDIDATE, UNIVERSITAT POLITECNICA DE CATALUNYA
2
2
EMBEDDED SYSTEMS
© atomtracker.tk, 2017
33
3
>USD 62 BILLION BY 2023
~5.3% ANNUAL GROWTH RATE
~12% FOR AUTOMOTIVE ELECTRONICS
EUROPE EMBEDDED MARKET SIZE (USD BILLION)
EMBEDDED SYSTEMS MARKET
© Global Markets Research, 2016
Est. GDP of Serbia 2016
44
4
REAL-TIME SYSTEMS
COMPUTERS, I/O DEVICES + SOFTWARE TIMELINESS TIMING CONSTRAINTS
Intensive interaction with external
environment
Time-dependent variations in the state
of the external environment
Need to keep control over all individual
parts of the external environment and to
react to changes
Reactivity
Accuracy
Duration
Completion
Responsiveness
Operational correctness does not solely depend on the logical
result but also on the time at which the result is produced
The computed response has an application-specific utility
function
Correctness is defined in the value domain and in the time
domain
A logically-correct response produced later than due may be as
bad as a wrong response
© Prof. Tullio Vardanega, University of Padova
55
5
APPLICATION REQUIREMENTS
RELIABILITY SAFETY-CRITICAL SYSTEMS MISSION-CRITICAL SYSTEMS
Measured in terms of maximum
acceptable probability of failure
Typically in the range 10-10 to 10-5 per
unit of life/service time
E.g. Airbus A-320: 10-10 probability of
failure per hour of flight
One failure in 1010 hours of flight (about
11.5 million years!)
E.g., satellite system: between 10-6 and
10-7 probability of failure per hour of
operation
One failure in 107 hours of operation
(about 11,306 years!)
© Prof. Tullio Vardanega, University of Padova
6
KEY CHARACTERISTICS
Dependable (proven)
Complexity
• Algorithmic, mostly because of the need to apply
discrete control over analog and continuous
physical phenomena
• Development, mostly owing to more demanding
verification and validation processes
Heterogeneity of components and of processing
activities
Extreme variability in size and scope
REAL-TIME SYSTEMS ARE
Temporal predictability
• Need for static (off-line) verification of correct
temporal behavior
• Not easy at all
Response to events triggered by the external
environment as well as by the passing of time
• Double nature: event-driven and clock- (or time-)
driven
Continuity of operation
Software architecture is inherently concurrent
REAL-TIME SYSTEMS MUST HAVE
© Prof. Tullio Vardanega, University of Padova
77
7
MEETING REAL-TIME REQUIREMENTS
IT IS NOT SUFFICIENT TO MINIMIZE THE AVERAGE RESPONSE TIME OF APPLICATION TASKS
"REAL-TIME COMPUTING IS NOT EQUIVALENT TO FAST COMPUTING“ [STANKOVIC, 88]
SYSTEM-LEVEL PREDICTABILITYGiven a set of demanding real-time requirements and an
implementation based on fast HW and SW, how can one show that
those requirements are met?
• Surely not only via testing and simulation
• Maiden flight of space shuttle, 12 April 1981: 1/67 probability that a
transient overload occurs during initialization; and it actually did!
© Prof. Tullio Vardanega, University of Padova
88
8
TIMING ANALYSIS (TA)
TIMELINESS GUARANTEESWorst-case execution time (WCET)
Best-case execution time (BCET)
TIMING ANALYSIS INPUTSA software controlling some process
A hardware platform executing software
Required reaction time of that software
© Casse, Sainrat 2010
99
9
Average case improving features
Caches, pipelines, branch prediction, speculation
Worst case trustworthy, but pessimistic
EXECUTION TIME VARIES A LOTARCHITECTURES ARE MORE COMPLEX
BCET VS. WCET
© Casse, Sainrat 2010
MPC755: x = a + b
© Wilhelm et. al. 2009
10
WCET
For any input data and all initial logical states
• So that all execution paths are covered
For any hardware state
• So that worst-case conditions are in effect
WCET COMPUTATION
Static
• Abstract model of the HW and of the program
Measurement-based
• On the real HW or a cycle-accurate simulator
• The high-watermark value can be ≤ WCET
Hybrid
TIMING ANALYSIS TYPES
© Mezzeti, 2014
11
WCET (CONTD.)
Worst-case input covering all executions of a real
program is intractable in practice
Worst-case initial state is difficult to determine with
modern HW
TRIGGERING THE WCET BY TEST IS DIFFICULT
A WCET estimate or bound are key to predictability
• Must be safe to be an upper bound to all possible
executions
• Must be tight to avoid costly over-dimensioning
EXACT WCET NOT GENERALLY COMPUTABLE
1212
12
STATIC TIMING ANALYSIS IN DETAIL
© Wilhelm et. al. 2009
1313
13
When local worst case does not always lead to global worst case
When timing anomalies occur due to complex hardware
architectures (e.g., out-of-order pipelines)
Even improper design choices (e.g., cache replacement policies)
Counter-intuitive timing behavior
Faster execution of a single instruction causes long-term negative
effects
Very difficult to account for in static analysis
CAN WE ALWAYS TRUST HW MODELING?
HOW MUCH OVERESTIMATION DO WE INCUR?
• INCLUSION OF INFEASIBLE PATHS
• OVERESTIMATION INTRINSIC IN ABSTRACT STATE COMPUTATION
WEAKNESSES OF USER ANNOTATIONS
• LABOR INTENSIVE AND ERROR PRONE
SAFENESS IS AT RISK
OPEN ISSUES
14
A GLIMPSE INTO THE FUTURE OF TA
STATIC DETERMINISTIC TIMING ANALYSIS (SDTA)
Cost effective approach
Based on extreme value theory
Not fully mature
Worst-case path coverage
Best fit: Arbitrary complex systems with proper
HW support
MEASUREMENT-BASED PROBABILISTIC TIMING ANALYSIS (MBPTA)
Well established and trusted
Based on sound mathematical abstractions
Likely to introduce pessimism
Risk of inaccurate timing models or annotations
Best fit: Simple HW and simple SW
15
TRENDS IN CRITICAL REAL-TIME INDUSTRY
Systems become more complex
Autonomous drive, collision avoidance, etc.
Need more computing power
E.g. 4x faster collision avoidance UAV flying indoors
ADD NEW FUNCTIONALITY
Industry wants incremental verification
Enabled by using robust partitioning among applications
CONTAIN VERIFICATION COST
16
16
WHAT MANY-CORES HAVE TO OFFER?
CO-HOSTING SEVERAL APPLICATIONS
Better performance per watt
Simple core design
IMPROVE PERFORMANCE WITH THREAD LEVEL PARALLELISM (TLP)
Tilera TILEPro64 Kalray MPPA Intel SCC
1717
17
MANY-CORES ARE NOT A SILVER BULLET!
TRANSITION TO MANY-CORES IS NOT EASY
REAL-TIME INDUSTRY IS STILL LEARNING HOW TO EXPLOIT THEMHarder to analyze w.r.t. single cores
Inter-task interference
Techniques developed for single-core do not work
M. Fernandez et. al. @EMSOFT 2012
1818
18
WHAT’S WRONG WITH MULTICORES
ACCESSES TO SHARED RESOURCESWHAT ABOUT PARALLEL APPLICATIONS?
SO FAR WAY TO GO TIME COMPOSABILITY
Network on chip, shared caches, memory, I/O, etc.
Inter-task interference
Critical sections
Barriers
Synchronization primitives
WCET estimates must hold for anyworkload
Increases pessimism
M1
M2
M3
M4
1919
19
COMPOSITIONALITY
SYSTEMS ARE BUILT FROM BUILDING BLOCKS CAN WE ANALYZE IT IN PIECES? ISSUES
Software components
Hardware subsystems
Reduce complexity of the analyses
Reduce margin between WCET estimate and real WCET
Decomposition of the system
Combining the results of partial analyses
r1
r2r4
r5
r3 r6
SWC1 SWC2 SWC3
r7
20
COMPOSITIONAL ANALYSIS
WCET estimation must consider the worst system
integration
TA CONSIDERS ALL POSSIBLE INTERACTION
The rest is considered at system integration as ∆
TA CONSIDERS ONLY SOME INTERFERENCE
0
5
10
Isolation A + B A + C A + D
WC
ET
Ap
p A
0
5
10
Isolation A + B A + C A + D
WC
ET
Ap
p A
WCETintegration = WCETanalysis _isolation WCETintegration = WCETanalysis _isolation + ∆
21
21
TIME PREDICTABLE HARDWARE
21 43
GRP1
M1
M3
M2
M4
21 43
GRP2
21 43 21 43
GRP3 GRP4
5
3
3
4
2
1
2
1
2
1
2
1
6
4
3
4
M1
M2
M3
M4
GRP1 GRP2
GRP3 GRP4
2222
22
M. Panic et al. @EMSOFT 2014
WCET IMPROVEMENT
MANY-CORES IN AVIONICS
0
0.5
1
1.5
Single-core 4-core Intra-Inter
4-core intra(parMERASA)
WC
ET
Slo
wd
ow
n
3DPP
Timing Analysis System Integration
0
0.5
1
1.5
Single-core 4-core Intra-Inter
4-core intra(parMERASA)
Stereo Navigation
Timing Analysis System Integration
+30% +40%-40%
(x1.7)-75%
(x3.8)
2323
23
Hierarchical libraries and other facilities that support large-scale
software development.
Strong compile-time type checking.
Safe object-oriented programming facilities.
Language-level support for concurrent programming.
A coherent approach to real-time systems development.
High-performance implementations.
Well-defined subsetting mechanisms, and in particular the SPARK
subset for formal verification.
FIRST STANDARDIZED OBJECT-ORIENTED LANGUAGE
ISO/IEC 8652:2012 CURRENT STANDARD
ORIGINALLY TARGETING REAL-TIME AND EMBEDDED SYSTEMS
WIDE-SPREAD IN SAFETY-CRITICAL SYSTEMS
STRONG SIDES
ADA
2424
24
USE CASES OF ADA
SAFETY-CRITICAL SYSTEMSAvionics and air-traffic control
• Fly-by-wire on Boeing 777
• Honeywell Air Transport System
Space rockets
• Ariane 4 and 5
Train signaling systems
• TGV in France
• Metro in Paris, London, Hong Kong, etc.
2525
25
ADA FEATURES
LANGUAGE FEATURES RUNTIME CHECKS MEMORY MANAGEMENT
Strong typing
Modularity mechanisms (packages)
Parallel processing (tasks, synchronous
message passing, protected objects,
and nondeterministic select statements),
Exception handling
Generics.
Object-oriented programming (ADA95)
Pragmas
Access to unallocated memory
Buffer overflow errors
Range violations
Off-by-one errors
Array access errors
Other detectable bugs
Dynamic
Type safe
No generic or pointers without type
Allocation/deallocation through declared
access types
Semantically supports garbage
collection, though it’s usually not
implemented
26
26
RAVENSCAR
ENFORCED BY MEANS OF A CONFIGURATION PRAGMA
Equivalent to a set of Ada restrictions plus three additional configuration pragmas
pragma Task_Dispatching_Policy (FIFO_Within_Priorities);
pragma Locking_Policy (Ceiling_Locking);
pragma Detect_Blocking;
PRAGMA PROFILE (RAVENSCAR);
2727
27
RAVENSCAR RESTRICTIONS
28
Thank you for your attention!
+381 11 440 79 84
MILOS PANIC
SENIOR SOFTWARE DEVELOPER