Advanced Laboratory on Embedded Systems S.r.l.

Alberto Ferrari – Research Scientist<strong>Advanced</strong> <strong>Laboratory</strong> on Embedded Systems S.r.l.A Research and Innovation Company7/9/2012Alberto Ferrari - ALES S.r.l.

Outline Application landscape and complexity Mapping applications to execution platforms— Satisfying Safety and real-time requirements Response Time Analysis— WCE vs Test based Performance prediction is really hard … What are the alternatives ?— Predictable architectures— Probabilistic real-time analysis— Statistical Model Checking Conclusions7/9/2012 Alberto Ferrari - ALES S.r.l. 2

UTC TODAY2009 Revenue - $53 billionHamiltonSundstrandSikorskyCarrieraerospace systemsPratt & WhitneyUTC Fire& SecuritySikorskyHamiltonSundstrandOtisOtisbuilding systemsUTC Fire& SecurityPratt &WhitneyCarrierpower solutionsUTC Power7/9/2012Alberto Ferrari – ALES S.r.l.3

OTIS Elevators3. JIS:GeN2-JIS2. ANSI:Gen2/GEM1. EN: GeN2-CxRemote monitoring and control7/9/2012Alberto Ferrari – ALES S.r.l.4

PressureInert Gas Fire SuppressionEmbedded systems modeling for fast verification,function reuse & reduced risksControl Panel:Control logic,communicationsSensorsGasdischargenozzleInflow determined bymass flow, temperatureand gas concentrationO 2 concentration distributionVentOverpressuretime traceODE for cylinder/nozzledensity and temperatureGas cylinderModeling capabilityenables analysis anddesign of better firesuppression systemsTemperature distributionSpace to be protected andcomponents of fire suppression systemModeling enables analysis, decision support and designof robust control for fire suppression systemWithoutoverpressure controlWithoverpressure controlSafepressurelimit0 10 20 30 40 50 60 70Time (sec)Outcome – better and safer fire suppressionImplementation with minimal change in hardware7/9/2012Alberto Ferrari – ALES S.r.l.5

Energy, Comfort, Security Needs in Buildings are EvolvingUTC presence in buildings creates opportunities and research challengesCustomer-focused solutionsEnabled by integrated systemsCarbon-neutral buildings by 2030Buildings must be 4X-5X moreenergy efficient7/9/2012Threats becoming more complex98% false alarmsAlberto Ferrari – ALES S.r.l.6

AEROSPACE SYSTEM EVOLUTION7/9/2012Alberto Ferrari – ALES S.r.l.7

MORE ELECTRIC AIRCRAFT7/9/2012Alberto Ferrari – ALES S.r.l.8

Design and Verification ProcessesV & VSystem requirementsSystemValidationSystem partitioningNetwork requirementsspecificationSystem DesignNetwork and Sub-System specificationSub-SystemVerificationNetworkIntegration7/9/2012Network selectionand configurationPartitioningSub-System DesignComponentspecificationComponentimplementationALES S.r.l.ComponentVerificationSub-Systemintegration9

Cyber Physical Systems – Abstracting TimeControl DomainElectrical Domainuntimed/DTtimedExecution platform (untimed)Infinite resources never failing…7/9/2012 Alberto Ferrari - ALES S.r.l. 10

Introducing Non Ideal Execution Platform…Control DomainElectrical DomainPerformance constraints (latency, safety)RTOS RTOS RTOS RTOS RTOSuntimed/DT7/9/2012 Alberto Ferrari - ALES S.r.l.timedtimed… adding time… adding failure modes- Impact on control function- HW/SW performance- Identify bottlenecks- Buffer size- Bandwidth capacity- End-to-end delay- Reconfigurations11

Real-time and Safety Analysis Mapping functional network to theplatform:— Allocation: static vs dynamic— Scheduling: static vs dynamic Design and verification:— Safety constraints (design)• Robustness to faults (10 -7 -10 -11 )– Automotive: ISO26262– Avionics: ARP4761, DO178C– Building Automation: IEC61508, ISO22201,EN 81-1/A1— Real-time constraints (verify)• Latency• Response time• Resource usageAssuming that the correct behavior isimplemented …VerificationFunctionalRequirementsFunctionalDescriptionFunction/PlatformMappingSynthesisVerificationNonFunctionalRequirementsPlatformDescriptionVerificationVerificationPlatformAbstraction PlatformAbstraction7/9/2012 Alberto Ferrari - ALES S.r.l.12

Addressing Safety: Industrial practiceHighly process oriented governed by standards(ISO26262, ARP4761)Mainly based on manual flows/analysisSafety requirements processed since the initialphases of the designVerification based on tests and simulationmethodsModel based methods recently accepted bystandards (DOC178C)7/9/2012 Alberto Ferrari - ALES S.r.l.13

Fault Tolerant Scheduling design flowPlantFaultBehaviorSensActSensSensActAbstractinput CoarseCTRL ArbiterBestAbstractOutFineCTRLIteratorAllocateScheduleMappingECU0CH0ECU1CH1ECU2OptimizeECU0 SensCH0ECU1 SensCH1ECU2 SensECU0CH0ECU1CH1SensSensCoarseCTRLInput CoarseCTRL ArbiterBest OutputInput FineCTRL ArbiterBest OutputCoarseCTRLInput CoarseCTRL ArbiterBest OutputActActActRefineCourtesy from Claudio PinelloSens Input FineCTRLArbiterBest Output ActSensInput CoarseCTRLArbiterBest OutputSensCoarseCTRLECU2Sens Input FineCTRL ArbiterBest OutputAct7/9/2012 Alberto Ferrari - ALES S.r.l. 14Act

Distribution of timeAnalysis vs MeasurementsBestmeasurementsWorstmeasurementsBest casepredictabilityWorst casepredictabilityLowerboundBestcaseWorstcaseUpperboundtime Experiment/Simulation is not exhaustive:— Partial sampling yields too optimistic behavior Analysis is complex, almost impractical— Simplified analysis yields too pessimistic resultsArchitectural elements with dynamic (non linear) behavior— State based information7/9/2012 Alberto Ferrari - ALES S.r.l. 15

Response Time Analysis Use abstract model to compute the communicationtime and the execution time of software— Best case - everything goes right: no cache miss, neededresources free, no conflict to access the media— Worst case - everything goes bad: e.g. empty cache, neededresources are busy, media busy with other communications Timing Accident: event causing additional delay Timing Penalties: associated delay Unfortunately modern execution platforms are verydifficult to abstract to keep the problem solvable and atthe same time to achieve good prediction results— Timing accident are complex and dynamic— Timing penalties have big range7/9/2012 Alberto Ferrari - ALES S.r.l.16

Distribution of timePredictability of modern architectures…BestmeasurementsWorstmeasurementsBest casepredictabilityWorst casepredictabilityx10-x100LowerboundBestcaseWorstcaseUpperboundtime Experiment/Simulation is not exhaustive— Risk of missing worse cases Analysis based on simplified models yields toopessimistic results (x10-x100)— Design solution is not cost effective7/9/2012 Alberto Ferrari - ALES S.r.l. 17

Looking for alternative approaches Predictable architectures— Remove/Reduce sources of indetermination. E.g.• Time Trigger Architecture: still need WCE to fit executions into slots— Enable formal analysis— Not always cost efficient— Long term solution Probabilistic analysis— Accept sources of indetermination of current architectures— “Gray-box” analysis (partial understanding of the architecturalcomponents)— Statistical description of the overall system— e.g. probabilistic real-time (hard deadlines met with probability of 10 -6 ,10 -12 ) Statistical Model Checking— Prove with given confidence the satisfaction of a timing property— Bound the number of simulation runs7/9/2012 Alberto Ferrari - ALES S.r.l. 18

Predictable Architectures Communication:— Time trigger architecture• The time uncertainty is reduced to the computation in a time slot Computation:— Architecture with Reduced Timing Accident• ISA with timing extension• Time interleaved (lately used on peripheral Cores)• Program Managed Temporary Memory– Caches, buffers, RAM and related controllers are fully under software control• Predictable DRAM Controllers (Predator, AMC)• Example: PRET: Berkeley Predictable Architecture Adding temporal semantics to the computational model— PTIDES: Programming Temporally Integrated DistributedEmbedded Systems• Uses actor-oriented design• Based on Discrete-Event(DE) model of computation7/9/2012 Alberto Ferrari - ALES S.r.l. 19

Probabilistic Real-Time Probabilistic Hard Real-Time Systems— Deadlines must be met, but it is likely to accept adeadline miss (probabilities of the order of 10 -6 -10 -12 )— It is just another failure event of the system Two approaches:— Gray-box and Statistical Analysis:• “…the effects are understood in principle, but can not becaptured analytically without very pessimistic simplificationsand a cycle true simulation of all possible program paths with allpotential input data combinations is inhibited by the complexityof the problem.”• Probabilistic description of the system behavior (WCET)— Randomized Architectures• The execution platform behaves randomly !7/9/2012 Alberto Ferrari - ALES S.r.l. 20

Probabilistic Real-Time Analysis Approach of Bernat et.al. 2002 “WCET Analysis of Probabilistic Hard Real-Time Systems” Derive Execution Time Profile (ETP) associated to smaller units of aprogram— By measurement (on real processors) or by simulation— By analytical methods Statistical combination of ETP (composition rules and calculationprocedure)— For Independent ETP: assuming independency between execution of two units ofprogram)— For Dependent ETP: assuming that it is possible to calculate a Joint Execution Profile (JEP)— For Unknown (dependency) ETP: assuming a worst JEP Problems/Doubts:— How to accurately calculate ETP?— How to accurately calculate JEP?• Dramatically more complex (experiment set grows quadratic)[RTSS02_probabilistic_hard.pdf “WCET Analysis of Probabilistic Hard Real-Time Systems”][YCS-2003-353.pdf “pWCET: a Tool for Probabilistic Worst-CaseExecution Time Analysis of Real-Time Systems”]7/9/2012 Alberto Ferrari - ALES S.r.l. 21

Randomized HW/SW Architectures Move towards a truly randomized architectures— Opposite direction of predictable (deterministic) HW/SW architectures— Break any dependency on code execution history (typical in caches, butnot only there!)— Probabilistic analysis suffers dependencies (i.e. it is much simpler to relyon statistical independence) Example with caches:— Randomized replacement policy (select random a replacement victim)— Traditional replacement (LRU) depends on execution history• probabilistic execution time analysis suffer of systemic cache misses (probabilisticanalysis relies on statistical independence) Problems/Doubts— How to achieve true randomization ?— Is this still cost effective ?— A reduced complexity architecture could achieve better meanperformance and B/WCET bounds ?[ecrts09.pdf “Using Randomized Caches in Probabilistic Real-Time Systems”]7/9/2012 [ACM-probabilistic_rt.pdf Alberto “PROARTIS: Ferrari - ALES S.r.l. Probabilistically Analysable Real-Time Systems”] 22

Statistical model checkingApplication scenario Executable model of a system with random components Property Φ verified or falsified by the model in a known and finite timeStatistical Model checking (SMC) Estimation of the probability p ̂ of satisfaction of property Φ Statistical method -> estimation characterized by confidence (1- δ), errorprobability (ԑ):Pr(|p ̂−p| 1−δ— Chernoff-Hoeffding bound to determine the number of independent samplesm > 4 ε 2 ln⁡ 2δApplication Performance of a CAN network— Random components: clock drift, tolerance and aging of electrical components Property Φ: transmission of a packet without errors— p ̂ is the probability of correct transmission (1−p ̂=PER)— 1 transmitted packet == 1 statistical sample7/9/2012 Alberto Ferrari - ALES S.r.l.23

# nodeStatistical Model CheckingPerformance in critical scenariosClusters of nodes Scenario: 32 nodes, distance between the clusters 4 m, distance betweennodes [0.4, 2] m, clock drift of CAN controller ~N(0,150 ppm) SMC: 50000 samples → confidence interval: 0.01, error probability: 0.015 Theoretical limit: 1 Mbit/s → 40 m (analytic model)312927252321191715131197531Packet error probability estimationReference: “Message priority inversion on a CAN bus”, Texas Instruments IncorporatedSimulated model:Analysis of critical scenarios not captured by the analytic model0.00% 0.50% 1.00% 1.50% 2.00% 2.50% 3.00%Packet error rate [%]Not negligible packet error rate at the theoretical length!7/9/2012 Alberto Ferrari - ALES S.r.l. 24

ProsStatistical Model CheckingPros & Cons—Scale fairly reasonably with the system size(simulation based)Cons—Scale pretty badly with confidence level• 99% -> 50K run!7/9/2012 Alberto Ferrari - ALES S.r.l. 25

Conclusions Several challenges in the design and verification of cyberphysicalsystems— Safety constraints are becoming stronger and their satisfactionrequires substantial manual design and verification effort• There are few approaches to design under these constraints, but still notmature enough for industrial deployment— Real-time Performance analysis for modern architecture is hard• Different approaches have been proposed, none is really ready for primetime— Combined approach for safety and real-time design/verificationstill far from becoming real Multi-processors Distributed Architecture are becomingreality also in embedded systems— Increase WECT bounds (apparently)— Solutions to cost optimize these architectures are not yetavailable on industrial scale7/9/2012 Alberto Ferrari - ALES S.r.l. 26

AcknowledgmentsChristian NastasiAlessandro UlisseMassimiliano D’Angelo7/9/2012 Alberto Ferrari - ALES S.r.l. 27