SEng 5831: Software Development for Real-Time Systems

1. SEng 5831:Software Development for Real-Time Systems

2. Introduction to SEng 5831 • Instructors & TA • What are embedded systems? What is different? • Course structure and topics • Materials, assignments, grades • Class introductions and interests

3. Contact Information Steve Vestal stevevestal@comcast.net Ph.D. Computer Science, University of Washington Adventium Labs Amy Larson larson@cs.umn.edu Ph.D. Computer Science, University of Minnesota Adjunct Faculty, UMSEC Anu Uduwage, TA uduwage@cs.umn.edu 612-293-6288 Ph.D. Student, Computer Science Class web site: http://www-users.cselabs.umn.edu/classes/Spring-2011/seng5831/

4. What is an Embedded System? “A special-purpose computer system usually built into a larger device. An embedded system is required to meet very different requirements than a general-purpose personal computer.” (Wikipedia) “A specialized computer system that is part of a larger system or machine.” (Webopedia) “Devices used to control, monitor or assist the operation of equipment, machinery or plant. "Embedded" reflects the fact that they are an integral part of the system.” (IEEE Y2K Policy Site)

5. How is Embedded Computing Different? • User interacts with the product, not the computer • Computer interacts with the product, not the user • Different hosted application disciplines & domains, e.g. • Mechanical, chemical, control engineering …. • Aerospace, automotive, medical, industrial process, … • Explicit (and sometimes stringent) timing requirements • Explicit (and sometimes stringent) safety/dependability requirements • Physical and environmental constraints • Recurring costs dominate Non-Recurring Engineering (NRE) costs • Different development environments, tools, practices • Software/hardware computer system co-development

6. General Course Comments • An introduction to multiple topics, not an in-depth study of one • 3 topics, ~ 5 lectures each • enable you to locate and use resources • Synergize with core MSSE courses • Survey of what is novel • Adapt to students’ background, interests and goals • choice of projects

7. Three Sections • Real-time allocation and scheduling (Steve) • Embedded practice & experience (Amy) • Safety and dependability (Steve)

8. Section 1Real-Time Allocation & Scheduling • Real-time task models (timing requirements) • Uniprocessor scheduling algorithms • Non-preemptive • Preemptive (priority-driven) • Uniprocessor schedulability analysis algorithms • Worst Case Execution Times (WCET) • Distributed and multi-processor systems • Timed finite state machines

9. Section 2Practice & Experience Lectures and Hands-On Experience • Low-level hardware control & IO • Timers, threads, interrupts • Design & implementation of models • Basic motor & PID control • Cross-development & debugging

10. Section 3Safety & Dependability • System safety concepts • Fault-tolerance and reliability • Design assurance & certification

11. Class Time • Class is 2:00 to 4:45pm • Break schedule? • Some classes will use part for group work

12. Assignments & Gradesfor Sections 1 & 3 Reading assignments to be completed before each class A simple homework per class, due the beginning of the next class • 20% of grade • 1 lowest grade per section will be thrown out One or two mini-projects for each of the three topic areas • 80% of grade • Menu of projects, e.g. • Program a simple scheduler or analyzer • Program a motor controller • Program a robot • Develop & analyze a model using a free tool • Presentation or report on an accident, standard, etc. • Student proposals welcome but must be pre-approved Discussion sessions in class

13. Course Materials Real-Time Systems by Jane W. S. Liu Safeware: System Safety and Computers by Nancy G. Leveson Online texts (available through UMN library web site) Industry standards and handbooks (will post on class web site) Publications and technical reports (will post on class web site) Homework and project assignments (will post on class web site) Class web site: http://www-users.cselabs.umn.edu/classes/Spring-2011/seng5831/index.php

14. Student introductions & background, e.g. • Related experience and/or goals • Special interests • Curious fact • …

15. Section 1:Real-Time Allocation & Scheduling Real-time task models (timing requirements) Uniprocessor scheduling algorithms Non-preemptive Preemptive (priority-driven) Uniprocessor schedulability analysis algorithms Worst Case Execution Times (WCET) Distributed and multi-processor systems Timed finite state machines

16. Part 1.1Workload ModelsTiming Requirements

17. What is a Real-Time System? A real-time system has quantified timing requirements of sufficient importance that failure to meet them is a run-time error.

18. What is a “Workload Model?” A mathematical class of scheduling problems (service times needed by jobs/tasks, release times and deadlines, order constraints, …). A software architecture pattern or style useful for a particular class or domain of applications. (Communication is as important as computation; both can be modeled as software tasks executed by hardware resources.)

19. period T compute time C timeline The Periodic Task Model • A periodic task is a sequence of jobs (aka task instances) that are released (aka dispatched) at periodic times 0, T, 2T, 3T, 4T, … • Each task may require up to C units of compute or service time from a processor before completing. • C is an upper bound on individual job execution times • C is often also called the Worst Case Execution Time (WCET) • Job i dispatched at time i*T must complete before time (i+1)*T. This is called the implicit deadline.

20. A Periodic Task Set A uniprocessor task set or workload is a set of periodic tasks that share the same processor: {(T1, C1), (T2, C2), (T3, C3) … } An example of the first few time units of a timeline for {(T1=3,C1 =½), (T2 =2, C2=½), (T3=1, C3=¼) … } if every task had its own processor: … Task 1 Task 2 Task 3 time

21. A Periodic Task Set Schedule Task set: {(T1=3,C1 =½), (T2 =2, C2=½), (T3=1, C3=¼) … } The first few time units of a possible timeline schedule if all tasks had to execute on the same processor: … time For every task there is a sequence of jobs where job i executes between time i*T and time (i+1)*T.

22. Periodic Task Generalizations period T compute time C timeline R D • The following additional parameters are sometimes added: • Release time R. Job i is not allowed to start earlier than i*T+R. • Deadline D. Job i must complete no later than i*T+D. • Note that if D > T+R then more than one job may be active for the same task at the same time. • These complicate scheduling and analysis and will be deferred for now.

23. Other Generalizations • Aperiodic tasks • tasks are dispatched by an event • unlimited arrivals invalidate classic periodic results • Inter-task events invalidate independence • Sporadic tasks • repetitive with a minimum inter-arrival interval • Inter-task events invalidate independence • Sequences, trees, DAGs of tasks • job released after predecessor completes • dependencies invalidate classic periodic results

24. Other Models • Timed automata • State machines with timers and constraints • Restricted publish/subscribe • Static to fix workload configurations

25. Domains Using Varying Task Models • Periodic feed-back control* • Human/Machine Interface (HMI) • Bulk Data Transfer • Clock Synchronization • Signal/Image Processing • Audio/Video • Real-Time Data Bases *We’ll look at this one in a bit more detail next.

26. Classical Feed-Back Control A/D Real-Time Control Computer Plant D/A • Motivate periodic tasking model • Give a feel for multi-disciplinary flavor

27. Feed-Back Control Computation u is input vector y is output vector x is internal state vector T is period L is latency A chemical (or mechanical or aeronautical) engineer trained in control theory will specify the function F. Software is often automatically generated from their mathematical specifications.

28. Linear Control Functions F Continuous (needs run-time integration) Discrete (note zero compute time!) Lots of mathematical theory and analyses exist for linear models to verify stability and analyze control performance.

29. Single Rate Periodic Tasking Internal update to state x takes effect here period T compute time C timeline Sample u Output y Sample u Output y

30. a0 a0 Feed-Back Control A feed-back control block diagram (A type of data flow diagram)

31. a0 a0 Continuous versus Sampled Data Feed-back control theory was originally developed in the continuous time domain (classical physics). Block diagrams model both the controller and the plant. Controllers were implemented using analogue circuits (e.g. op amps). Sampled data theory (e.g. Z-transforms) was developed when control algorithms were converted to software and implemented as periodic tasks that did sampling and output at discrete points in time.

32. Breaking Loops at State Updates a0 a0 Compute using previous state Update state used in next periodic computation

33. Multi-Rate Control Control engineers can select different rates for different outputs and loops within a control algorithm specification. The overall computation is broken into multiple tasks that perform subsets of the computations at different rates, performing different state updates and outputs at different rates. It is easiest for the control engineer to specify a single very high sampling rate. Selection of periods is often driven by push-back from the embedded computing limitations. This is a multi-disciplinary trade-off.

34. Hierarchical Control outer loop higher level lower rate supervisory Controller X . . . Controller B inner loop lower level high rate Controller A physical environment

35. sample sample sample output output output Multi-Rate Periodic Tasking high & low rate state update takes effect here high rate state update takes effect here sample output

36. Oversampling and Undersampling

37. Implementation Idioms • Shared state in shared memory • Distributed state with message passing

38. Selecting Workload Models Workload models very from domain to domain. These are often based on something you can find in the literature. Reference architectures are usually specific to a particular product line and organization (hopefully explicitly developed and managed to facilitate portability, upgradeability, verifiabililty, …) A product architecture may include applications developed using differing workload models, which complicates scheduling and verification. There are solutions to some combinations in the literature. The architecture styles and reference architectures usually represent a trade-off between functional, timing, and fault-tolerance models. For example, it is common to find applications shoe-horned into a periodic task model (e.g. structured as polling rather than event-driven) because they must be hosted on the same processor with applications that require that model. Make sure you have a clear workload model!

39. Process Issues • Parameters of the workload are often derived requirements specified by application engineers, e.g. • Periods are selected by control engineers based on customer requirements for robustness, overshoot, handling qualities, … • WCET depends on the algorithms and detailed coding decisions. • Parameters may be subject to uncertainty or variability, e.g. • WCET before code is available • WCET after code is available • The development process should include activities to manage these trade-offs and uncertainties, e.g. • Define preliminary resource budgets and schedulability models early in the development process (when the architecture is defined), incrementally upgrade to track the development.

40. Allocation and Scheduling Scheduling determines which job a resource is servicing at any given instant of time. Allocation means determining which resource in a multi-resource system is servicing a particular task or job. Scheduling determines when a job or task is executing. Allocation determines where a job or task is executing.

41. Allocation and Scheduling Allocation and Scheduling are often performed as separate phases in multi-resource systems. • A task is allocated to a resource that will service all jobs (all invocations) for that task. • Uni-processor scheduling is then done (mostly) independently for the separate resources. There are integrated algorithms that can pick different resources for different jobs of a task, or even switch a job from one resource to another in mid-execution. Routing in a network is a form of allocation. Allocation is also sometimes called binding or assignment.

42. Allocation & Scheduling is a SW+HW Issue Typical scheduling problem includes: • A set of tasks (repetitive jobs) and their timing properties and requirements (software). • A set of resources/processors/servers to perform the work of the tasks (hardware). • WCET values depend on the hardware; they cannot be determined from software tasks alone. Developer activities include: • Verifying the workload model matches the implementation (e.g. WCET, overheads) • Producing a schedule (defining a scheduling algorithm) • Verifying tht the resulting schedule satisfies the timing requirements (schedulability analysis & testing).

43. Reading Assignment for 28 JanIn Real-Time Systems by Liu Chapter 2 (8 pages) Chapter 3 3.1-3.3 (8 pages) skip 3.4 & 3.5 (precedence constraints) skip 3.7 & 3.8 (preemptivity, hierarchical scheduling) 3.9 (summary) Skip chapter 4 (overview of scheduling methods) Chapter 5 5.1-5.4 (cyclic scheduling, 8 pages) Skip 5.5-5.10 (extensions, summary) Chapter 6 6.1-6.2 (introduction to preemptive scheduling, 9 pages) Skip 6.3 (EDF scheduling) 6.4-6.5 (PFP schedulability analysis, 11 pages)

44. Homework Assignment for 28 Jan Product a schedule for a simple periodic task set. Homework number 1 write-up is on the class web site. Due by start of class Friday 28 January 2011.

45. Select a Real-Time Project(complete project by 19 Feb 2011) • Implement a deadline-monotonic priority assignment algorithm and a preemptive fixed priority response time analysis algorithm. Run on a few example workloads. UI not relevant. Write-up is on the web site. • Implement a non-preemptive cyclic scheduling algorithm. Run on a few example workloads. UI not relevant. You may assume harmonic periods. Write-up is on the web site. • Download & apply a ROTS schedulability analysis tool to an example problem (not one of the included examples). Write-up is on the web site. • http://mast.unican.es/ • http://beru.univ-brest.fr/~singhoff/cheddar/ • Student proposal