Robust Partitioning for Reliable RealTime Systems

1
Robust Partitioning for Reliable Real-Time
Systems Reinhard Seyer, Christian Siemers, Rainer
Falsett, Klaus Ecker Harald Richter
2

• Why do we need RP ????
• Mechatronic systems gt high reliability
• ( especially in the context of time).
• Stronger hard real-time requirements regard the
• - robustness against software failures
• - Interdependencies of erroneous tasks to
  others.

3
Real time systems

• Correctness of the systems depends on
• logical result of the computation
• on the time at which the result is produced

4
Real time systems (contd..)

• Predictability With certain assumptions about
  workload and failures, show at design time that
  the timing constraints of the appln will be met.
• Reliability Perform the stated function under
  given conditions at (for) the stated time (period
  of time).
• XX Contradictory Issue XX
• Flexibility Ease with which components can be
  modified when such constraints are not met.

5
1.Introduction

• Event Triggered Real time systems
• Partitioning of ISRs
• 2 types
• First (Imprecise)
• Result imprecise reaction (value).
• Second Timer
• Triggers exceptional use of imprecise value.
• Integrated Timer ? specific timing info
• triggering of specified activities.

6
1.Introduction (contd..)

• All tasks defined with logical and temporal
  behavior.
• H/w Addtnl. Component ? temp. behavior.
• Time supervision H/w unit ?
• Avoids conflicts from malfunction wrt. Time
  inside the node.

7
Contents

• 2. Key elements of Robust Partitioning
• 2.1.System Model
• 2.2.Intention of RP
• 2.3.Memory Protection
• 3.Time Supervision
• 3.1. Time Supervision inside RP
• 3.2. Consequences of RP for System Design
• 4.Development Methodology.
• 5.Summary Outlook.

8
2.Key elements of RP

• Transparent development process
• Clear specs. ?Structured partitioning of
  functions ? H/w S/w modules ?Reduced
  Inter-dependencies.
• XX CONFLICT XX
• A vehicle ? over 40 ECUs (Embedded Electronic
  Units).
• Inspite of Reliable tests for Reliability
• Practically ? Hidden errors slip through.

9
2.1. System Model

• Dist., realtime system Physical S/w.
• Highest abstraction level ?whole application
  software system (collection of units).
• A unit ? Logically separate part of real-time
  system, such as a hardware component.
• Each unit ? A set of tasks to be executed with a
  known period or maximum frequency precedence
  constraints between them.

10
2.2. Intention of RP

• Regain simplicity more reliable systems
• 2 functions
• comprehensive memory protection.
• monitor real-time behavior to guarantee
• conformance to specification.
• Ist goal Tight working Limitations
• IInd goal avoid ve impact of modern Comp.
  Arch. viz., caches et al.,
• ? supervision concept.

11
2.3.Memory Protection.

• Normal MMU/MPU
• Coarse-gain Segmentation of memory.
• Block structure
• - too large (4/8/16k)
• Protection function
• ? tables accessible at runtime
• OS maintains it and is vulnerable.

• RP? MMU/MPU
• Fine grain Segmentation of memory.
• Not Mentioned. ?
• RP ?separate mem. for table (EEPROM/flash )
• Gen. at compile time.
• Stored in non-volatile.
• Not vulnerable to EMI, bit errors.

12
2.3.Memory Protection.(contd.)

• Protection tables ?
• Small no. of entries
• When addressing absent addresses Table is
  reloaded ? almost impossible to estimate delay of
  computation process in advance.

• Hidden from execution OS.
• Table fixed Altered only offline (not at
  runtime)
• RP-concept ? Table covers all partitioned
  segments in 1 page.
• gt No delay.
• __Disadvantage__
• RP limited to compile
• Time defined systems.

13
2.3.Memory Protection(contd.)

• Embedded system memory split into
• Instruction memory in ROM
• data and stack memory RAM (viz. Figure 1).
• (most important part of the memory to be
  protected)
• Protection of write accesses has highest priority
  in RAM-space.
• ?Violations detected automatically
• ?Reduction of debugging and testing times
• ?Faster prototyping generating more reliable
  result.

14
2.3.Memory Protection(contd.)

• Fragmentation of data area
• Table - fixed number of entries.
• Split data area - scratch pad, module memory,
  variables data exchange areas others.

15
2.3.Memory Protection (contd.)
16
2.3.Memory Protection (contd.)

• Protection unit must control access to
• ?All addresses,data instructions
• Integrate this unit as close as possible to the
  CPU kernel,
• Protection will be part of the execution
  pipeline.
• Cannot be placed outside a processor chip
• ? cannot be added to off the shelf processors
• __ve Testing Simulating would be complicated.

17
3.Time Supervision

• Monitor the execution times of the program
  modules.
• Watchdogs time ctrl concept in h/w.
• execution time measured n compared continuously
  against predefined max. value or task-specific
  deadline.
• IF Module finishes before run out time
• then nothing happens
• Else
• module is stopped ctrl returns to OS.
• Like Mem. Protection time ctrl sys cannot be
  corrupted / skipped.

18
3.Time Supervision.(contd.)

• Another column - added to protection table.
• Represents Actual run-time of modules
• Compared with deadlines on violation NMI .

19
3.Time Supervision.(contd.)

• 2 timers for each module
• Ist? stops execn. At specified time lt deadline.
• IInd?emergency prog. Invoked ?(imprecise result)
  lt deadline .
• 2nd Timer ctrls duration of emergency program.
• Incase of interrupt
• Measurement of exec. Time is preempted and
  resumed when interrupt completed.

20
3.2.Consequences of RP for system design

• Enhance reliability partitioning system
  resources simplifying design concept.
• System Resources ? mostly scarce.
• Hard real-time ? computational times wrt WCET
• Soft real-time ? computational times wrt ECET
• Speedup capabilities of cache ? useless (in hard
  real time or contradict determinism)
• Use it only in the normal operation.

21
4.Development Methodology.
22
4.Development Methodology.

• Impact of RP ? task Classification WCET/ECET
  analysis.
• Influence structure of future s/w programs.
• Linker ? generates memory boundaries
• with approp. Interface create a file
• with all req. info for mem. Protection unit
  inside RP.
• Ist program ? addressing all reqts.
• IInd emergency program ? shorter address only
  essential reqts.
• Advantage speedup of debugging phase
• Reduction of hidden errors.

23
5.Summary Outlook

• Less effort for ? testing and debugging
• Automatic error revelation
• Detection of hidden errors
• Controlled liability
• Combination of cache and reliability
• Support of software maintenance by error fixing
  in the field
• Increase of stability by control of error
  progression
• Improvement on resource usage (ECET vs WCET).