IntroToRTOSandOSEK Module1

Electronics & Safety
Real-Time Operating Systems
Introduction to
OSEK/VDX
Course #25516
IntroToRTOSandOSEK_Module1.ppt;1 31 March, 2006
and
Software Forward Engineering Delphi Electronics & Safety
Copyright 2003-2006 Delphi Technologies, Inc. All rights reserved. Introduction to RTOS / OSEK Module 1
-1Delphi Software Global College
Delphi Business Proprietary
How to View the Notes Pages
To view the Notes that accompany this presentation:

Right-click and select Save Target As to save this as a PowerPoint presentation, then open the PowerPoint presentation. Click View , then Notes Page from the menu bar. The Notes Page view will be displayed. If necessary, use the scroll bars to scroll to the bottom of the page where the notes are located.
Introduction to RTOS / OSEK Module 1
Delphi Absolutes of Excellence

THE DELPHI AB S O LUTE S
of
EX CELLEN CE
Focus:
Your Customer
Control:
Customer Feedback
Performance Goal:
Do It Right The First Time, Every Time
People:
Caring
Method:
Innovation & Continuous Improvement
Style:
Teamwork
Reward:
Recognition & Security
Class Overview
Description
This course is an introduction and/or refresher for engineers in the Software competency. The course will cover real-time operating systems concepts and the differences between an RTOS and a cyclical executive. The course will also provide an overview of the OSEK/VDX standard for automotive real-time operating systems and discuss issues involved in using OSEK. Finally, the class will cover current RTOS and OSEK related activities at Delphi. The purpose of this course is to provide a basic introduction to real-time operating systems, and to OSEK/VDX - a set of standards for real-time operating systems designed for use in automotive systems.
Audience
This course is intended for Software or Systems Engineers needing an introduction to RTOS concepts or an overview of the OSEK/VDX operating system standards.
Class Objectives
Upon completion of this training, you should be able to:

Understand the difference between cyclic executives and preemptive multitasking operating systems.
Be familiar with RTOS concepts such as tasks ISRs priorities scheduling synchronization
Understand the basic concepts behind the OSEK/VDX standards. Know about how using an RTOS affects some system design issues.
Be aware of RTOS- and OSEK-related activities at Delphi, and know where to find more information.
Course Outline
Module 1
Class Information & Introductions Introduction to Real-Time Operating Systems Real-Time Operating System Concepts
Module 2
Overview of OSEK/VDX The OSEK/VDX Project OSEK OS OSEK OIL OSEK COM OSEK NM
Module 3
RTOS System Architecture Issues RTOS and OSEK Activities at Delphi Summary
Refer to the Glossary at the end of Module 3 of this training material for definitions of acronyms, abbreviations and other terms used. Most can also be found in the on-line dictionary
Course Outline
Class
Information & Introductions Introduction to Real-Time Operating Systems Real-Time Operating System Concepts Overview of OSEK/VDX
The OSEK/VDX Project OSEK OS OSEK OIL OSEK COM OSEK NM
RTOS
System Architecture Issues RTOS and OSEK Activities at Delphi Summary
Section 1
Introduction to Real-Time Operating Systems
What is an Operating System?
Software that provides an intermediate layer between an application and the target hardware Provides a layer of abstraction between the application software and the computer hardware Operating System Responsibilities:
Manage and allocate computer resources (CPU, memory, devices, etc.) Control execution of application program(s) and operation of I/O devices Utilize the computer hardware in an efficient manner
Examples:
Time-Sharing / Single-User: OS/360 MVS MS-DOS MS-Windows Max OS-X UNIX LINUX VAX/VMS
Real-Time: ITRON LynxOS OS-9 QNX VxWorks VTRX MicroC/OS-II OSEK/VDX
What is a Real-Time Operating System?
A Real-Time Operating System (RTOS) differs from a useroriented (time-sharing) RTOS:

Criteria Capacity Time Sharing System High-throughput; efficient use of system resources Real-Time Systems The ability of system tasks to meet all deadlines, even at high levels of resource usage (schedulability) Predictably fast response to urgent events; known worstcase response time to events (latency) When the system is overloaded by events and cannot meet all deadlines, meeting selected critical deadlines can still be guaranteed (stability)
Responsiveness
Fast average response times
Overload
Fairness - equitable sharing of overloaded resources
- 10 Delphi Software Global College
Conceptual Model for Real-Time Systems
A Real-time System must provide a response to a given input, and must do it before a specified deadline
Event Response Deadline
Function
Latency
Processing Time
Maximum Response Time
time
Simple Cyclic Scheduling

Period (Max.) 5 ms 10 ms 14 ms Processing Time 1.0 ms 1.2 ms 1.8 ms void main(void) { Initialize(); for (;;) { Function1(); Function2(); Function3(); DelayUntilNextCycle(); } }
Function Function1 Function2 Function3
0 ms
Source: LiveDevices Inc.
5 ms
10 ms
15 ms
Calculating Processor Utilization
Ideal:
Ideally, the processor utilization of a periodic function can be calculated by dividing its processing time by its period. Example: If Function1 take 1 millisecond to execute, and runs every 5 milliseconds, it consumes 20% of the processor throughput.
Actual:
Simple cyclic scheduling may require that some tasks be run more frequently than would otherwise be necessary, in order to keep the scheduler simple. Those tasks therefore consume more throughput than the ideal case.
Function Function1 Function2 Function3 Total:
Processing Time 1.0 ms 1.2 ms 1.8 ms
Period (Max.) 5 ms 10 ms 14 ms
Utilization (Ideal) 20% 12% 13% 45%
Period (Actual) 5 ms 5 ms 5 ms
Utilization (Actual) 20% 24% 36% 80%
Cyclic Scheduler Overhead

Period (Max.) 5 ms 10 ms 14 ms Processing Time 1.0 ms 1.2 ms 1.8 ms
Function Function1 Function2 Function3
Function2 executed more often than required; uses 24% of throughput, instead of 12%. Function3 executed more often than required; uses 36% of throughput, instead of 13%. Overall, the system uses 80% of the throughput. Adding more functionality or an interrupt that uses 1.0 ms processing time makes the system fully loaded. (Even if interrupts are more than 5 ms apart.)
0 ms
5 ms
10 ms
15 ms
Major/Minor Loop Cyclic Scheduling

Period (Max.) 10 ms (min.) 5 ms 10 ms Processing Time 0.5 ms 1.0 ms 1.2 ms void main(void) { int cycle; Initialize(); for (cycle = 0; ; cycle++) { Function1(); Function2(); if (0 == (cycle & 0x1)) { Function3(); } DelayUntilNextCycle(); } }
Function Interrupt 1 Function1 Function2
Function3

14 ms
1.8 ms
Design: 10 ms major cycle, containing 5 ms minor cycles Function1 and Function2 run every minor cycle; Function3 runs every major cycle Time must be allocated for Interrupt 1 in every minor cycle (even though it will used less than half the time). Throughput: Better, but Function3 is still executed more often than required; it uses 18% of throughput, instead of 13%.
0 ms
5 ms
10 ms
15 ms
Cyclic Scheduling: Adding a Function

Period (Max.) 10 ms (min.) 5 ms 10 ms 14 ms 20 ms Processing Time 0.5 ms 1.0 ms 0.8 ms 1.2 ms 6.0 ms
Function Interrupt 1 Function1 Function2 Function3 Function4
Change:
Function2 reduced to 0.8 ms Function3 reduced to 1.2 ms New Function4 added.
There is sufficient throughput available, but Function4 must be artificially partitioned to make it fit.
0 ms
5 ms
10 ms
15 ms
Cyclic Scheduling: Observations
Advantages:
Simple in concept Predictable behaviour Minimal processing overhead
Disadvantages:
Design complicated by timing behaviour Inflexible Maintenance can be difficult Processor time is not used efficiently
Alternative: Preemptive Multi-tasking RTOS

Improved CPU utilization Timing behaviour more complex (but handled by the RTOS) Separates functional design from temporal design Increased overhead for RTOS kernel
Preemptive Scheduling: Concept
Functions are allocated to tasks Tasks are assigned priorities
Based on the urgency of each tasks functions
RTOS manages task execution

The RTOS always runs the highest priority ready-to-run task The RTOS preempts a lower priority task to run a higher priority task The lower priority task is suspended until the higher priority task finishes The lower priority task is resumed when no higher priority task is ready to run.
priority
higher priority task activated
lower priority task resumed
time
Cyclic vs. Preemptive Scheduling
0 ms
5 ms
10 ms
15 ms
ISR1 Task1 Task2 Task3 Task4 (Idle)
priority
0 ms
5 ms
10 ms
15 ms
Why Use a Real-Time Operating System?
Maximizes CPU utilization Provides well-defined functionality and behavior Encapsulates scheduling independent of the application
Allows time-dependent aspects to be separated from functional aspects
Hides implementation issues from application developers

Hardware Software
Simplifies software system design Operating system becomes the interface (API), not the hardware Supports potential code generation Provides capability for software reuse / portability
Preemptive RTOS Challenges
RTOS kernel adds processing overhead

For switching between tasks Some code space is required for the RTOS code
Preemption requires additional stack space

Can be reduced by optimization
Critical sections
Task synchronization and data coherency must be addressed If tasks share data, there is the possibility of incorrect data
Timing behavior is complex

Preemption must be accounted for Tasks can start or be preempted at arbitrary times Low-priority tasks may never get to execute (starvation)
Course Outline
Class
Information & Introductions Introduction to Real-Time Operating Systems Real-Time Operating System Concepts Overview of OSEK/VDX
The OSEK/VDX Project OSEK OS OSEK OIL OSEK COM OSEK NM
RTOS
System Architecture Issues RTOS and OSEK Activities at Delphi Summary
Section 2
Real-Time Operating System Concepts
Tasks
A task is the basic unit of execution in an RTOS

Each task thinks it has the CPU all to itself The RTOS implements multi-tasking, allowing tasks to share the CPU
A tasks context is how the RTOS perceives a task A context switch occurs when the RTOS decides to run a different task A Task Control Block (TCB) is a data structure used by the RTOS to manage each task The TCB stores a tasks context, and may contain
program counter status register stack pointer CPU registers task data
Task States
The RTOS provides a state machine for each task

Each task can be in only one state at a time Only one task can be in the running state at a given time The RTOS saves and restores task context in conjunction with task state transitions
wait
running
terminate
waiting
preempt
start/ resume
suspended
release ready
activate
All tasks are initially in the suspended state.
The state machine used depends on the RTOS

Preemptive Scheduling
Two Schemes for Scheduling:

Non-preemptive
Once the processor is given to a task, that task cannot be preempted by another task (even if it has higher priority), until the running task relinquishes the processor itself
Preemptive
If a new task with a priority higher than the currently executing task becomes ready to run, then the operating system will preempt the current task and switch to the higher priority task
Task-to-Task Context Switch
Task-to-Task Context Switch:

Occurs when
a higher-priority task preempts the current task, or a lower-priority task resumes after having been preempted
Handled by the RTOS

Save the context of the currently running task Initialize or restore that context of the new running task Accomplish this such that the context switch is transparent to the tasks involved

(Illustration Step 1 of 9)
CPU
SP PC MSR R0 R1 R2 R3
A simple conceptual CPU:

Stack Pointer (SP) Program Counter (PC) Machine Status Register (MSR) Four General-Purpose Registers (R0, R1, R2, R3)

Task1 Stack
CPU
Func1B Data
Func1A Data
. . .
Task1 TCB SP
. . .
Func1B Code
Task 1, the Currently Running Task

SP points to function data on tasks stack PC points to current instruction of tasks code

Task1 Stack Task2 Stack
CPU
R3 R2 R1 R0 PC MSR Func2C Data
Func1B Data
Func2B Data Func2A Data
Func1A Data
. . .
Task1 TCB SP
. . .
Task2 TCB SP
. . .
Func1B Code
. . .
Func2C Code
Task 2, the Highest-Priority Task

Previously suspended SP in TCB points to function data on tasks stack When some event makes Task 2 ready, the RTOS will perform a context switch

CPU
PC MSR Func1B Data SP PC MSR R0 R1 R2 R3
Func1A Data
. . .
Task1 TCB SP RTOS Code
. . .
Task2 TCB SP
. . .
Func1B Code
. . .
Func2C Code
The
PC and MSR state are saved on Task1s stack

Equivalent to start of interrupt processing
The RTOS takes control


R3 R2 R1 R0 PC MSR Func1B Data
CPU
Func1A Data
. . .
. . .
Task2 TCB SP
. . .
Func1B Code
. . .
Func2C Code
The RTOS saves the general-purpose registers on Task1s stack

CPU
Func1A Data
. . .
. . .
Task2 TCB SP
. . .
Func1B Code
. . .
Func2C Code
The RTOS saves the stack pointer (SP) in Task1s TCB All of Task1s context is now saved

CPU
Func1A Data
. . .
. . .
Task2 TCB SP
. . .
Func1B Code
. . .
Func2C Code
The RTOS sets the stack pointer (SP) to the value previously stored in Task2s TCB

CPU
Func1A Data
. . .
. . .
Task2 TCB SP
. . .
Func1B Code
. . .
Func2C Code
The RTOS pops the general-purpose register values from Task2s stack

CPU
Func1A Data
. . .
. . .
Task2 TCB SP
. . .
Func1B Code
. . .
Func2C Code
The RTOS executes a RETURN-FROM-ISR (Interrupt Service Routine) operation
The PC and MSR values are popped off Task2s stack
Task2 is now the current running task, and takes picking up where it was when it got suspended
control
Preemption and Reentrant Code
Since a task can be preempted at any time, task code must be reentrant. Reentrant code is code designed to maintain data integrity even though the code can be interrupted at any point, and a parallel instance of code may be invoked. To be reentrant, code must
Use any shared variables in an atomic or protected way Access hardware resources in an atomic way Not call any non-reentrant functions
The concept of reentrant code is covered in detail in

ISRs, Concept of Volatile Keyword & Reentrant Functions in Embedded System Software
(http://software.delcoelect.com/STP/classes/EmbeddedC/Interrupts and Reentrant_Functions.ppt)
Task Synchronization
A resource is any entity that is used by a task

I/O device Register RAM variable
A shared resource is a resource that may be used by more than one task
For shared resources, task synchronization is required to prevent potential corruption of data
Techniques for task synchronization are discussed in detail later

Schedulability Analysis
Period 5 ms (min) 10 ms (min) n+1 R 3 ms = Ci + i 6 ms 14 ms 14 ms
Task / Interrupt ISR1 ISR2 Task1 Task2 Task3 Task4
k hp(i) 6.0 ms
T
Processing Time 0.2 ms 0.5 ms 0.5 ms 0.6 ms 1.4 ms
Deadline -----
Rin
k
Ck
3 ms 6 ms
14 ms 14 ms
Response < Deadline

ISR1 ISR2 Task1 Task2 Task3 Task4 (Idle)
0 ms
5 ms
10 ms
15 ms
Accounting for RTOS Overheads
RTOS Task/ISR Context Switch Times

Task overhead / Interrupt to Period Deadline Add system scheduling Processing Time ISR1 be taken into 5 ms (min) 0.2 ms -- Must account when analyzing schedulability ISR2 10 ms (min) -- Schedulability analysis tools need to0.5 bems calibrated Task1 3 ms 0.5 ms 3 ms for RTOS overheads Task2 6 ms 0.6 ms 6 ms on the target processor Task3 Task4 14 ms 14 ms 1.4 ms 4.0 ms 14 ms 14 ms
Response
ISR1 ISR2 Task1 Task2 Task3 Task4 (Idle)
Deadline Response
0 ms
5 ms
10 ms
15 ms
End of Module 1
Revision History
By M. Malone Description
Revision & Date 1 31-MAR-06
Derived from revision 9 of the original training, now split into 3 modules.

IntroToRTOSandOSEK Module1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

IntroToRTOSandOSEK Module1

Uploaded by

Copyright:

Available Formats

Electronics & Safety

Real-Time Operating Systems

Software Forward Engineering Delphi Electronics & Safety

-1Delphi Software Global College

Delphi Business Proprietary

Electronics & Safety

How to View the Notes Pages

To view the Notes that accompany this presentation:

Delphi Business Proprietary

Introduction to RTOS / OSEK Module 1

-2Delphi Software Global College

Electronics & Safety

Delphi Absolutes of Excellence

Delphi Business Proprietary

Introduction to RTOS / OSEK Module 1

Electronics & Safety

Delphi Business Proprietary

Introduction to RTOS / OSEK Module 1

-4Delphi Software Global College

Electronics & Safety

Upon completion of this training, you should be able to:

Delphi Business Proprietary

Introduction to RTOS / OSEK Module 1

-5Delphi Software Global College

Electronics & Safety

Delphi Business Proprietary

Introduction to RTOS / OSEK Module 1

-6Delphi Software Global College

Electronics & Safety

System Architecture Issues RTOS and OSEK Activities at Delphi Summary

Delphi Business Proprietary

Introduction to RTOS / OSEK Module 1

-7Delphi Software Global College

Electronics & Safety

Introduction to Real-Time Operating Systems

Delphi Business Proprietary

Introduction to RTOS / OSEK Module 1

-8Delphi Software Global College

Electronics & Safety

What is an Operating System?

Delphi Business Proprietary

Introduction to RTOS / OSEK Module 1

-9Delphi Software Global College

Electronics & Safety

What is a Real-Time Operating System?

A Real-Time Operating System (RTOS) differs from a useroriented (time-sharing) RTOS:

Fast average response times

Fairness - equitable sharing of overloaded resources

Delphi Business Proprietary

Introduction to RTOS / OSEK Module 1

- 10 Delphi Software Global College

Electronics & Safety

Conceptual Model for Real-Time Systems

Maximum Response Time

Delphi Business Proprietary

Electronics & Safety

Simple Cyclic Scheduling

Function Function1 Function2 Function3

- 12 Delphi Software Global College

Delphi Business Proprietary

Electronics & Safety

Calculating Processor Utilization

Function Function1 Function2 Function3 Total: