Real-time HOOD. Analysis and Design of Embedded Systems and OO* Object-oriented Programming Jan Bendtsen Automation and Control

Size: px

Start display at page:

Download "Real-time HOOD. Analysis and Design of Embedded Systems and OO* Object-oriented Programming Jan Bendtsen Automation and Control"

Stella Holt
5 years ago
Views:

1 Real-time HOOD Analysis and Design of Embedded Systems and OO* Object-oriented Programming Jan Bendtsen Automation and Control

2 Structure (slightly modified) OO & UML Java basics Java Polym. Java Events Java Threads Networking RT HOOD Scheduling RT paradigms IPC IPC RT kernels Threads Scheduling Scheduling Scheduling

3 Lecture Outline A quick intro (recap?) of real-time systems Overview of RT-HOOD Design phases Types of processes Logical and physical architecture Schedulability and Dependability Case study

4 Realtime systems A realtime system is a system designed to map realtime sequences of events to real-time sequences of events. Design of a real-time system involves specifying appropriate response to inputs presented to the system as a real-time sequence. The real-time system should produce an associated real-time sequence according to specifications.

5 RT and non-rt systems d 1, d 2, d 3, d 4,... Non-real-time System r 1, r 2, r 3, r 4,... d 1, d 2,d 3, d 4,... Real-time System r 1, r 2, r 3, r 4,... t 1, t 2,t 3, t 4,... t t' 1,t' 2,t' 3, t' 4,... t

6 Process and Control Most (if not all) engineering systems can be divided into process and control subsystems Not just limited to control engineering! car engine and wheels telephone users communication channels distributed DB systems trains in Jutland etc. main computer in car up with SW in mobile phone network controller DB query and presentation software Signals, track controls and timetable

7 Process and Control Interaction (commands and responses) Process Real-time System Control Real-time System Requirements (value and timing)

8 Examples of RT requirements Control theory determines that control signals must be submitted to (physical) ABS breaking systems 1000 times every second. The user determines that at normal writing speed the processing and echoing of characters in his word processor should not be more than 5 characters behind. Users demand that the mean service time at should be below 1 min. for hits.

9 Safety and Reliability A safety and reliability model refers to the structures and policies in place to ensure Safety Freedom from accidents or losses Reliability High mean time between failures Fault tolerance Note that safety and fault tolerance always require some level of redundancy

10 Periodic execution of Tasks Specify time properties: start period cost Deadline (relative)

11 Periodic execution of parallel Tasks samplethread controlthread robothand 3:00:00.0 3:00:01.0

12 Time characterization of Tasks A sub-action (or job) is a piece of work to be performed by our real-time system. Basically, some lines of code will be executed. A job is said to be preemptible if the scheduler is allowed to suspend its execution prior to completion and then resume whenever necessary. We say that the job is preemptied. Jobs where preemption is not allowed are said to be non-preemptible. Tasks are sequences of jobs (a j ), j = 1,...,m

13 Running sub-action (job) Running Not running r S C d Time Start Deadline Completion Ready Preemption

14 Timing instants Ready time: r is the instant in time so that the job can begin executing after r and not before. Computation time: c is the duration of the job assuming it occupies the processor totally. Starting time: S is the instant where the first instruction associated with a j is executed. Completion time: C is the instant where the last instuction associated with a j has just ended. Deadline: d is the instant before which the job has to finish in order to meet real-time requirements.

15 Periodic and Aperiodic Tasks T 1 T 2 T 3 T 4 r 0 r 1 r 2 r 3 r 4 T 1 T 2 T 3 T 4 T 5 T 6 T 7 r 0 r 1 r 2 r 3 r 4 r 5 r 6 r 7 Wake-up question: Definition of interarrival time T j?

16 Realtime definitions A task is periodic with a period T if for every j we have T j = T If deadlines are less than or equal to periods we say that the task is hard realtime If deadlines are higher than periods but finite we say that the task is realtime If deadlines are defined on a mean value basis we say that the task is soft realtime If there are no deadlines at all the task is non-realtime

17 Active Objects Active object = Thread Active objects organize passive objects via composition GPS receiver Text display Orbit Database Queue Graphic display

18 Task Diagrams A task diagram is a class diagram that shows only model elements related to the concurrency model Active objects Semaphore objects Message and data queues Constraints and tagged values Interfaces may be used as necessary

19 Example of Task Diagram

20 Elements of Task Diagrams Mutex semaphore Message queue Active objects (threads) CmdQueue:Queue RobotArmTask MonitoringTask MovingTask {period = 10 priority = 3 worst case exec time = 5 deadline = 10} Schedulability properties

21 Overview of RT-HOOD A design methodology for real-time systems Real-time design requires An exact requirement specification Task hierarchy Timeliness has to be addressed throughout the design phases Not commonly addressed in OO*; hence RT- HOOD

22 Phases in RT-HOOD Requirements Definition an authoritative specification of the system s required functional and non-functional behaviour Architectural Design a top-level description of the proposed system Detailed Design the complete system design is specified. Implementation the system is implemented Testing the operation of the system is tested, and it is checked that timing constraints etc. are satisfied

23 Commitments Requirements Functional and non-functional behaviors Obligations Requirements that lower levels must satisfy Commitments System design properties that the designers cannot change Constraints What can be done by the underlying system Execution environment Hardware and software components

24 Logical and physical architecture Requirements Definition Logical Architecture Design Physical Architecture Definition Detailed Definition Implementation Testing Logical architecture Involves commitments that are independent of constraints Is primarily aimed at satisfying requirements Physical architecture Addresses timing constraints, schedulaibility etc. Involves rough estimates of execution times, resource management etc.

25 Logical Architecture Design Outlines the system Rich Image Provides an overview of external devices etc. Gives a first view of signals, data etc. going in and out of the system

26 NB! The timing of Active objects cannot be analyzed! They may thus not be visible from the terminals of the complete system Logical Architecture Design Passive have no control over when they are used (data objects) Active may control when their operations are invoked (standard objects) Protected Like Active, but do not spontaneously invoke operations in other objects (e.g. synchronized) Cyclic Periodic activities that must be carried out immediately at certain intervals, e.g. Control computations (threads) Sporadic Activities that happen every once in a while, e.g. Events or sampling

27 Physical Architecture Design Consists of the following stages: Object allocation Network scheduling Processor scheduling Dependability Heavily dependent on the given application (hardware/ software platform, communication requirements etc.) Assign a criticality level to all Cyclic and Sporadic objects (e.g., safety critical, mission critical, background); Passive and Protected objects should be assigned the criticality level of their users

28 HRT-HOOD objects T Object name Provided operations Object Internals Used objects

29 HRT-HOOD objects Classify all objects into Passive, Protected etc. Establish Real-Time attributes: Deadlines, worst-case execution times, budget execution times, periods (Cyclic objects), minimum arrival times (Sporadic objects), importance (hard RT vs. soft RT threads) Design Use and Include relationships: RT-HOOD only allows certain types of object to use other types (see Burns & Wellings) Decompose operations

30 Case study: Mine Drainage Log Operator Carbon monoxide sensor Methane sensor Airflow sensor Pump control system Pump Water flow sensor High level sensor Sump Low level sensor

31 Case study: Mine Drainage Water flow sensor Motor setpoint Pump motor High level sensor Pump control system CO sensor CH4 sensor Low level sensor Interrupts Standard readings Airflow sensor

32 Functional requirements Pump operation turn off when the sump is empty, turn on when the sump is full or when commanded by the operator; operation is only allowed if the methane level is below a certain threshold Environment monitoring CH4 and CO contents and air flow must be monitored at all times, and alarms generated if the gas levels become critical Operator The operator should be informed of all events, as well as control the overall functions System monitoring The system must keep logs of all events in a DB. It must be possible to retrieve the logs upon request

33 Non-functional requirements Monitoring periods: all sensors supply readings every 60 s. The high and low level sensors are event-driven; the system must react within 20 s. Shut-down deadline if the methane level becomes critical, the system must shut down within a stricter deadline Operator information deadline - if the CH4 or CO level becomes critical, the operator must be informed within 1 s., within 2 s. in case of a critically low airflow reading and within 3 s. in case of an operation malfunction

34 Tasks CH4 sensor Periodic Arriv. 5 s Deadline 1 s CO sensor Periodic Arriv. 60 s Deadline 1 s Water flow s. Periodic Arriv. 60 s Deadline 3 s Airflow sensorperiodic Arriv. 60 s Deadline 2 s HLW handler Sporadic Arriv. 100 s Deadline 20 s

35 Logical Architecture A Pump Ctrl (data flow) A Env Monitor Pump not safe (interrupt) not_safe safe status_request set_pump Command CH4 status Status readings Alarm reason check_safety Status readings Alarm reason A Data logger A Oprt Console alarm CO_log CH4_log high_low_wl_log water_l_log motor_log

36 Hierarchical Decomposition of Pump Ctrl (not complete) A not_safe safe status_request set_pump Pump Ctrl high_sensor low_sensor A HLW sensor Pump status Alarm reason C Water flow sensor Pr Motor CH4 status Status not_safe safe status_request set_pump Alarm reason

37 Physical Architecture Only one computer => The physical and logical architectures are largely identical Threads CH4 sensor Periodic Arriv. 5 s Deadline 1 s CO sensor Periodic Arriv. 60 s Deadline 1 s Water flow s. Periodic Arriv. 60 s Deadline 3 s Airflow sensorperiodic Arriv. 60 s Deadline 2 s HLW handler Sporadic Arriv. 100 s Deadline 20 s Scheduling and execution time analysis the subject of the last four lectures

Goal. A mine pump example. System diagram. Realtime Systems SMD138. Lecture 12: Real-time system design Burns/Wellings ch 17 + ch 2

Goal. A mine pump example. System diagram. Realtime Systems SMD138. Lecture 12: Real-time system design Burns/Wellings ch 17 + ch 2 Realtime Systems SMD138 Lecture 12: Real-time system design Burns/Wellings ch 17 + ch 2 1 Goal To put the topics of previous lectures into a context To show how how the overall design of a real-time system