Mixed Criticality in Safety-Critical Systems · 2019. 7. 16. · Worst-case execution time function C i(1); i(2);::: A high criticality task may be subject to pessimistic static analysis

Mixed Criticality in Safety-Critical Systems

Prof. Dr. Jian-Jia Chen

LS 12, TU Dortmund

18, July, 2016

Prof. Dr. Jian-Jia Chen (LS 12, TU Dortmund) 1 / 25

Motivation

• today’s embeddedsystems use complexnetworks

• hundreds offunctions

• thousands of tasks• 50+ ECUs

(electronic controlunits)

• networked control• many suppliers• heterogeneous

• networks are anefficient platform forsystems integration


Example: Mercedes-Benz E-Class

source: T. Bone, Daimler


Safety Challenge

• Embedded systems are increasingly used to• implement advanced system features• improve safety

• In such cases, the embedded system inherits the safety anddependability requirements of the system function

• safety related embedded systems

• Such functions are no longer simple• They are often distributed

• Example: automotive electronics• brake system• camera-based object recognition and tracking


Safety Standards

• The design of safety-related systems is driven by safetystandards

• Safety standards contain• rules and regulations for all design system• recommended guidelines for the development process

• Safety standards cover all stages of the development process• specification• design• implementation• test• maintenance

• Objective of safety related design• avoid unacceptable risk• assure functional safety


Functional Safety

• Safety: Freedom from unacceptable risk of physical injury orof damage to the health of people

• Functional safety: refers to the safety of system functions• A safe system can handle faults without causing severe

functional failures

• Risk:• frequency of hazardous events• severity of hazardous events


Embedded Systems Functional Failures

• Embedded system (ES) functional failures are not necessarilycatastrophic

• Effect depends on the importance of the failing function forthe overall system

• function criticality

• Criticality depends on the overall system functionality• fail safe (ES is not critical but important for quality):

if the ES function fails there is a safe function backup or a safesystem state that avoids severe consequences (mechanicalsteering, hydraulic brake, emergency stop)

• fail operational (ES function is critical, but possibly only needsa specific function):the function continues based on system redundancy or turns toan error mode with reduced functionality (gracefuldegradation)


Safety and Time Criticality

Many safety critical systems have hard deadlines


Embedded System Functional Failures and Timing

• ES functions have different criticality• depending on the overall system

• where timing is specified, it becomes part of the functioncriticality

• ES timing failures are ES functional failures

• switching to error modes is time critical• switching needs hard deadlines to guarantee overall system

function


IEC 61508 - Overview

• Functional Safety of Electrical/Electronic/ProgrammableElectronic Safety-related Systems

• basic functional safety standard applicable to industry• generic standard for safety-related systems

• Metric: “Safety Integrity Level” - SIL• defines four degrees of safety: from 1 (lowest) to 4 (highest)• specification of maximum failure rates for each level


Merging Functions with Different Criticality Levels

• Integration on one platform leads to systems with applicationsof different safety requirements

• strict separation too expensive• mixed (safety) criticality systems

• Mutual dependency via platform and sensors/actuatorsrequires safety concept and qualification/certification for allfunctions

• Safety is highly relevant aspect in embedded systemsintegration

• Sharing resources is hard to avoide in cost efficient systems• shared (open) network• shared on-chip network, shared memories, etc.

• Is it possible to integrate several subsystems and avoidinterference?

• This would be important for mixed criticality systems:non-critical parts are less verified and not designed for worstcase

• It would reduce verification/certification/integration cost


Mixed Criticality Task Scheduling

Given a task τi , with

• criticality level Li (Let’s assume that the higher number is morecritical)

• Defense avionics: 2 (3) criticalities, says safety-critical;mission-critical; non-critical

• Civilian aviation (DO-178B): 5 criticalities, says catastrophic;hazardous; major; minor; no effect

• Automotive systems (ISO 26262): 4 criticalities

• Worst-case execution time function Ci (1),Ci (2), . . .

• A high criticality task may be subject to pessimistic staticanalysis

• A medium criticality task may be subject to worst-casemeasurement, plus a safety margin

• A low criticality task may be assessed by simple limitedmeasurement (worst seen in a small number of runs)

• We can assume that Ci (j) ≥ Ci (j + 1)


Mixed Criticality Task Scheduling (cont.)

Let’s consider how to verify the schedulability by using theknowledge we learned in the course.

• Consider a set T of periodic tasks with implicit deadlines

• Consider two criticality levels:• HI: high criticality (Ci (2) will be considered)• LO: low criticality (Ci (1) will be considered)

• A task τi is either specified as a HI task (Li = 2) or a LO task(Li = 1)

• Let HI be the set of HI tasks• Let LO be the set of LO tasks

• When the system is in HI, all the HI tasks should be feasiblyscheduled by considering that Ci (2) is the WCET.

• When the system is in LO, all the tasks should be feasiblyscheduled by considering that Ci (1) is the WCET.


Criticality Monotonic

• All HI tasks have priorities higher than all LO tasks• Rate monotonic within each class

• All HI tasks τi ∈ HI use Ci (2)

• All LO tasks τi ∈ LO use Ci (1)

What’s the schedulability condition for such a mixed-criticalityscheduling?

∃t ≤ Ti Ci (Li ) +∑

τj∈hp(τi )

⌈t

Tj

⌉Cj(Lj) ≤ t ∀τi

where hp(τi ) is the set of tasks with higher priority than τi .

Quiz: Is Criticality Monotonic the best strategy?


Intermingled Priorities

Priorities of HI and LO are intermingled

• When analysing HI tasks, HI tasks use Ci (2), but LO tasksuse Ci (1)

• At run-time, tasks τi in LO must be prevented from executingfor more than Ci (1)

• When analysing LO tasks, all tasks use Ci (LO).

• Disadvantage: execution times must be monitored

Let’s first assume hp(τi ) is given. What’s the schedulabilitycondition for such a mixed-criticality scheduling?

∃t ≤ Ti Ci (Li ) +∑

τj∈hp(τi )

⌈t

Tj

⌉Cj(min{Lj , Li}) ≤ t ∀τi


Deciding Priority Levels

Use Audsley’s algorithm (assume N tasks)

• Let LO have ` tasks and HI have h tasks

• Order all HI tasks by rate monotonic (1,h)

• Order all LO tasks by rate monotonic (1,`)

• Start at lowest priority (N)• Is LO(`) (lowest priority task in LO) schedulable at priority

level N? yes: ` := `− 1, and τ` is removed from LO• If no, is HI(h) (lowest priority task in HI) schedulable at

priority level N? yes h := h − 1, and τh is removed from HI• If no, → system unschedulable

• Repeat for N-1 etc.• Max 2N − 1 tests


Further Readings for References

• Alexandre Esper, Geoffrey Nelissen, Vincent Nelis, Eduardo Tovar: Howrealistic is the mixed-criticality real-time system model? RTNS 2015:139-148

• Sanjoy K. Baruah, Vincenzo Bonifaci, Gianlorenzo D’Angelo, Haohan Li,Alberto Marchetti-Spaccamela, Suzanne van der Ster, Leen Stougie:Preemptive Uniprocessor Scheduling of Mixed-Criticality Sporadic TaskSystems. J. ACM 62(2): 14 (2015)

• Georg von der Brggen, Kuan-Hsun Chen, Wen-Hung Huang and Jian-JiaChen: Systems with Dynamic Real-Time Guarantees in Uncertain andFaulty Execution Environments, in RTSS 2016


Uncertain and Faulty Execution Environments

• Uncertain / faulty behaviour imposed by physical environment

• Execution time of task instance enlarged, e.g. recoveryprocess after fault detection

• Abnormal mode: CAi > CN

i

• Assumption: faults happen rarely

• ⇒ Using CAi for scheduling analysis may be a huge over

estimation

• But: only possibility if all tasks are safety critical


Aborting Tasks

• Reality: not all tasks are safety critical ⇒ Deadline Miss(DM)) not that critical

• In theory and practical systems : abortion ”not so important”tasks Tsoft in abnormal mode

• ⇒ guarantees response time of more important tasks Thard

• Results of τi ∈ Tsoft may still be useful, even if they are a bitlate ⇒ aborting may not be such a good idea


Problems

• τi ∈ Thard must always meet the deadline

• We do not know when faults occur ⇒ only one priorityordering

• Aborting only works if all tasks in Tsoft have lower prioritythen the tasks in Thard

• τi ∈ Tsoft should still have good response time in normalmode ⇒ τi ∈ Tsoft should still meet there hard deadlines

• τi ∈ Tsoft should have bounded tardiness in abnormal mode


Sufficient Test

• TDA for all tasks in normal mode (TDA)

• TDA for all τi ∈ Thard in abnormal mode (TDA)• τi ∈ Tsoft with higher priority then the current task have to

be considered

• Bounded tardiness τi ∈ Tsoft ⇒ UAsum ≤ 1

Observation: as CAi > CN

i the schedulability test for τi ∈ Thard

only has to be checked in abnormal mode


RM is Not Optimal

• Rate Monotonic: Order according to the period

Normal mode:τ1 ∈ Tsoft = (2, 2 + ε, 6, 6)

-1 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

τ2 ∈ Thard = (6, 8, 14, 14)

Abnormal mode:τ1 ∈ Tsoft = (2, 2 + ε, 6, 6)

-1 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

τ2 ∈ Thard = (6, 8, 14, 14)

DM

Exchanging priority of τ1 and τ2:

• τ2 will meet its deadline• UA = 8

14 + 2+ε6 ≈ 0.58 + 0.34 = 0.92 < 1

⇒ bounded tardiness for τ1


SLPO is Not Optimal

• Service Level Priority Ordering: Order according to priority inabnormal mode

Normal mode:τ1 ∈ Thard = (6, 6 + ε, 12, 12)

-1 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

τ2 ∈ Tsoft = (2, 2 + ε, 6, 6)

DM

Switching priority:τ2 ∈ Tsoft = (2, 2 + ε, 6, 6)

τ1 ∈ Thard = (6, 6 + ε, 12, 12)

-1 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Abnormal mode:τ2 ∈ Tsoft = (2, 2 + ε, 6, 6)

τ1 ∈ Thard = (6, 6 + ε, 12, 12)

-1 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15


τi ∈ Thard can be Ordered in DM Order

τ1 ∈ Thard

τ2 ∈ Tsoft

-1 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

τ3 ∈ Thard

τ1 ∈ Thard

τ2 ∈ Tsoft

-1 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

τ3 ∈ Thard

τ1 ∈ Thard

-1 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

τ2 ∈ Tsoft

τ3 ∈ Thard


Acknowledgment

The above slides are based on the slides provided from Prof. RolfErnst, Prof. Sanjoy Baruah, and Prof. Alan Burns.


Documents

Mixed Criticality in Safety-Critical Systems · 2019. 7. 16. · Worst-case execution time function C i(1); i(2);::: A high criticality task may be subject to pessimistic static analysis