Real-Time Systems

Reny Sebastian, SEG, ER&DCI, TVM

Real-Time Systems

Sessions

1. Introduction to Real-Time Concepts.

2. Real-Time Operating Systems.

3. Case Study.

Real-Time Systems

Introduction to Real-Time Concepts.

Session 1

Real-Time Systems

Real-Time System

• DefinitionA real-time system (defined by IEEE) is a system

whose correctness includes its response time as well as its functional correctness.

In other words, in a real-time system, it not only matters that the answers are correct, but it matters when the answers are produced.

A Late Answer is a Wrong Answer!

Real-Time Systems

Real-Time Systems - Categories

1. Hard Real-Time Systems

2. Soft Real-Time Systems

Real-Time Systems

Hard Real-Time Systems

• Hard real-time means that the system (i.e., the entire system including OS, middleware, application, HW, communications, etc.) must be designed to GUARANTEE that response requirements are met.

• Hard Real-Time doesn’t mean fast execution.

Real-Time Systems

Examples

• Electronic Engines

• Automotive and Flight Control Systems

• Medical Systems

• Industrial Control Systems

• Robotics

Real-Time Systems

Soft-Real Time Systems

Soft real-time is exactly the same as hard real-time in its infrastructure requirements, but it is not necessary for system success that EVERY time constraint be met.

Real-Time Systems

Example

• Telecommunication Systems

• Internet Video

• ATM

Real-Time Systems

The Real-Time Spectrum

Real-Time Systems

Real-Time Design Issues• How many things are under control?

• How “hard” are the timing constraints?

• Will there be user interaction?

• What is the mix of synchronous vs. asynchronous threads of control?

Real-Time Systems

Real-Time Design Approaches

• There are two primary techniques used in real-time designs

- Super- loops

One program running

-Multitasking

Many programs running, taking turns

Real-Time Systems

Super-Loops

• Also called Foreground/Background Systems

• There is a background loop that is always running anytime an ISR isn’t executing

• The CPU is always busy

• Can be taken to the extreme of an idle loop and all of the work being done in the ISRs

Real-Time Systems

Super-Loop

ISR

ISRISR

Background Foreground

Time

Real-Time Systems

Multi-Tasking Operation

• With multi- tasking, multiple tasks or threads compete for the CPU based on a scheduling policy

• This scheduling policy is implemented in the Kernel

• The tasks give up the CPU:-Voluntarily: cooperative multi- tasking Developer determined via system call- Involuntarily: preemptive multi- tasking

Process scheduling algorithm

Real-Time Systems

Multi-Tasking

Real-Time Systems

Session 2

Real-Time Operating Systems

Real-Time Systems

What Is An RTOS?

• A Real- Time Operating System is software that allows a program to:

– Communicate with peripherals and other tasks

– React in a deterministic way to external events

– Share the CPU and resources in a rigidly

established manner between competing threads

of execution

Real-Time Systems

Commercial RTOSs

• VxWorks • pSOS System• QNX• Nucleus• Windows CE• MircoC/OS-II

Real-Time Systems

Commercial RTOS Shortcomings

• Can be very expen$ive

• High, per- seat costs

• Royalties

• Access to source

Real-Time Systems

Free RTOSs

• Embedded Linux• Real-Time Linux• RTAI• RTEMS• eCOS

Real-Time Systems

Multi-Tasking Revisited• Multitasking is the process of scheduling and switching the

CPU between several tasks

• Maximizes the utilization of the CPU

• Facilitates modular construction of applications

• Simplifies the design of application programs

Real-Time Systems

Task

• A task (thread) is a simple program that thinks it has the CPU all to itself.

• A Real-Time application consists of several tasks executing concurrently.

• Each task is assigned a priority, its own set of CPU

registers, and its own stack area.

Real-Time Systems

Task States

Waiting

Dormant Ready Running ISR

Real-Time Systems

Context Switch• Occurs when a Multi-Tasking kernel decides to run a

different task.

• Steps involved in a context switch1.Save current task’s context(CPU registers) in the

current tasks context storage area(it’s stack)2.Restore the new task’s context from it’s storage

area(it’s stack).3.Resume execution of the new task’s code.

Real-Time Systems

Multiple Tasks

Task Control Block Task Control Block Task Control Block

CPU Registers

Status

SP

Priority

Status

SP

Priority

Status

SP

Priority

SP

TASK 1 TASK 2 TASK n

CPU

MEMORY

Stack Stack Stack

Real-Time Systems

Kernel

• Definition

Kernel is the part of the multi-tasking system responsible for the management of tasks and communication between tasks.

• Services

- Context switching

- Inter task communication services(Semaphore management, mail boxes, queues, time delays, etc.)

Real-Time Systems

Scheduler

• Scheduler is the part of the kernel responsible for determining which task will run next

• Most real-time kernels are priority based

• Each task is assigned a priority based on its importance

• The priority of each task is application specific

• Control is always given to the highest priority task ready to run.

Real-Time Systems

Kernel

There are two types of priority based kernels

• Non-Preemptive Kernel

• Preemptive Kernel

Real-Time Systems

Non-Preemptive Kernel• Require that each task does something to explicitly give up

the control of the CPU

• Also called cooperative multitasking

• ISR always returns to the interrupted task

• Advantages

- Low interrupt latency

- It can use Non-Reentrant functions

• Disadvantages

- Responsiveness is very law

• Very few kernels are non-preemptive

Real-Time Systems

Non-Preemptive KernelLow Priority Task

ISR

ISR makes the higher priority task ready

High Priority Task

Low-priority task relinquishes the CPU

Time

Real-Time Systems

Preemptive Kernel

• It is used when system responsiveness is important.

• High priority task ready to run is always given control of the CPU

• Most real-time kernels are preemptive.

• Application code using a preemptive kernel should not use non-reentrant functions or an appropriate mutual exclusion method should be applied to prevent data corruption.

Real-Time Systems

Preemptive Kernel

Low Priority Task

ISR

High Priority Task

ISR makes high priority task ready

Time

Real-Time Systems

Reentrancy

• A reentrant function can be interrupted at any time and resumed at a later time without loss of data.

• It either uses local variables or protects data

when global variables are used.

• It can be used by more than one task without fear of data corruption.

Real-Time Systems

Mutual Exclusion

• Mutual Exclusion is used to ensure the exclusive access to a shared resource without data corruption.

• Common Methods are

– Disabling interrupts

– Disabling scheduling

– Using Semaphores

Real-Time Systems

• Common Inter task Communication methods are

1. Message Queues

2. Mail Boxes

3. Semaphores

Intertask Communication

Real-Time Systems

Session 3

Case Study TETRA Mobile

Real-Time Systems

Tetra Air Interface • Tetra Systems use TDMA protocol.

• TDMA defines time slots of duration 14.167 ms

• A TDMA Frame contains 4 time slots

• Each time slot is a physical channel which may be used for signaling or traffic.

• There is an offset of two time slots between uplink and downlink slots.

Real-Time Systems

TDMA Structure

Real-Time Systems

What is the real-time requirement?

1 2 3 4 1 2

3 4 1 2 3 4

Offset of 2 slots

Total Processing Time (15.11 ms)

8.46 ms for uC 6.65 ms for DSP

Real-Time Systems

Hardware Architecture

• Texas TMS320VC5472 (Orion Processor) Processor

• External RAM 8 MB SDRAM

• Flash Memory 8 MB

Real-Time Systems

Orion Processor

Integrates

• A DSP subsystem based on the TMS320C54x architecture

and a

• RISC microcontroller subsystem based on the AR7TDMI core.

Real-Time Systems

DSP Subsystem

Includes

• TMS320C54X DSP Core

• 74K X 16 Bit internal SRAM

• ARM Port Interface

• Two multi channel buffered serial ports(McBSPs)

• Timer

• DMA

• Programmable wait-state generator

• External Memory Interface

Real-Time Systems

MCU Subsystem

• ARM7TDMI Core

• Memory interface for external SRAM, Flash, ROM and SDRAM.

• On-chip 16K-byte zero wait-state SRAM.

• General purpose I/Os (GPIOS), including support for an 8x8 keyboard.

• Three Timers(Two generic, one watchdog)

• Two UARTs

• Interrupt Handler Subsystem

Real-Time Systems

Orion

DSP Subsystem

API Interface

ARM7TDMI TMS320C54xAPI

MemoryAPI

Interface

Real-Time Systems

Software Architecture

The software is split up into five major components

• DSP• MMI (Man Machine Interface)• PEI (Peripheral Equipment Interface)• Protocol Stack• RTOS (uC/OS-II)

Real-Time Systems

Software Architecture

DSPFPGAUSER

I/FHW

STACK

MMI

OS

Orion

ARM

V+D

DMO

PEI

Real-Time Systems

ARM Software Architecture

uC-OS

OS

HARDWARE

DMO + V&D Stacks

MMI PEI

Real-Time Systems

uC/OS-II

uC/OS-II is a real-time operating system developed by

Jean J. Labrosse.

Characteristics

• Preemptive

• Multi-tasking

• Romable

• Scalable

Real-Time Systems

uCOS-II

• Maximum number of Tasks is 64

• Task priority levels can be 4 –56

• Task priority should be unique.

• Supports fixed block memory management.

• Supports Inter task communication methods

such as Message Queues, Mail Boxes etc.

Real-Time Systems

An Example using uC/OS-II

Eg: A producer - Consumer Scenario. void Sender(void *arg)

{void *mPtr; char err;

for(;;) /*for ever */ {

mPtr = OSMemGet(AMemPool, &err);/* do some processing here.. And put the result in

the buffer mPtr */err = OSQPost(AQueue, mPtr); /* post it to the

receiver task */OSTimeDly(2); /* wait for 2 ticks. It gives an

opportunity to execute the receiver task */ } }

Real-Time Systems

Example - Continued void Receiver(void *arg) {

void *mPtr; char err; for(;;) /*for ever */

{/* process the received message */mPtr = OSQPend(AQueue, 0, &err);

/* deallocate the memory after use */err = OSMemPut(AMemPool , mPtr);

} }

Real-Time Systems

Example - Continued

OS_MEM * AMemPool; OS_STK stack1[64], stack2[64]; void main() {

OSInit() /* Initilize the Kernel *//* Create memory pool */

AMemPool = OSMemPoolCreate(..); /* arguments omitted *//* Create message queue */ AQueue = OSQCreate(..); /* arguments omitted */ /* Create tasks */ OSCreateTask(Sender, 0, &stack1[0], 5 ); /* higher priority

*/ OSCreateTask(Receiver, 0, &stack1[0], 6);

OSStart(); /* start Multi tasking */ }

Real-Time Systems

SDL

• Specification and Description Language(SDL) is

the best suited language for developing

telecommunication Protocols.

• It is a graphical language.

• It uses a state machine approach for developing applications

Real-Time Systems

Telelogic Tau SDL Suit• A graphical Tool Set for SDL Development

• Tools for Simulating the system under development.

• Automatic Code generation is supported

using CAdvanced SDL to C compiler.

Real-Time Systems

Structure of a Telelogic SDL Application

Having three parts

• The SDL system.

• The physical environment of the system.

• The environment functions, where you connect the SDL system with the environment of the the system.

Real-Time Systems

Structure of a Telelogic SDL Application

Real-Time Systems

Telelogic Tau RTOS Integration

• C Advanced SDL to C compiler is designed to run on different platforms.

• Portablility is achieved by representing platform dependent concepts by C macros that can be expanded appropriately for each environment.

• Platforms which are fully supported by Telelogic Tau.1. OSE Delta2. VxWorks and Tornado3. pSOS4. Win325. Solaris 2.6

Real-Time Systems

Integration Models

Two different run time models

• Light Integration

• Tight Integration

Further divided into two models.

- Standard Model

- Instance-Set Model.

All models use the same generated code.

Real-Time Systems

Light Integration

• Simplest of all the models.• Minimum integration with the operating system is

required.• The Complete SDL system runs as a single OS

task.• Scheduling of SDL processes is handled by the

standard kernel.• Worst case scheduling latency is the duration of

the longest transition

Real-Time Systems

Light Integration

Real-Time Systems

Tight Integration

• The generated code interacts directly with the underlying operating system when creating processes, sending signals, etc.

• The SDL processes run as separate OS tasks

• Scheduling is handled by the OS and is normally time-sliced, priority based and preemptive.

• Communication takes place using the inter-process communications mechanisms offered by the OS, normally message queues.

• There are no environment functions

Real-Time Systems

Tight Integration

• In the standard model of the Tight integration each SDL process is implemented as OS task.

• The the Instance Set Model of the Tight integration each SDL process INSTANCE is implemented as OS task.

Real-Time Systems

Tight Integration

Real-Time Systems

SDL KernelThe main function of a Telelogic Application is defined in the kernel (sctsdl.c)

void main( void ){

xMainInit(); Code from #MAINxMainLoop();

}

void xMainInit( void ){

xInitEnv(); /* environment function */Init of internal structures

}

Real-Time Systems

Main Loop• void xMainLoop (void)

{while (1){

xInEnv(...)if (a timer has expired)

send the corresponding timer signalelse if (a process can execute a transition){

remove the signal from the input portset up Sender in the process to Sender of

the signalcall the PAD function for the process

}}

}

Real-Time Systems

Main Loop for RTOS Integration• void xMainLoop (void)

{while (1){

xInEnv(...)if (a timer has expired)

send the corresponding timer signalelse if (a process can execute a transition){

remove the signal from the input portset up Sender in the process to Sender of the signalcall the PAD function for the process

}else { relinquish control to a lower

priority task which is waiting for the CPU}

}

}

Added for RTOS Integration

Real-Time Systems

SDL Kernel

‘sctos.c’ contains Operating System specific functions

Those function should be modified to suite the selected RTOS

Examples:

• xAlloc() - Used by the SDL system to allocated memory for Process Instances, Signals etc.

- Standard implementation calls C Library function

calloc()

• xClock() - Used by the SDL System to get the current time.

- Implementation is different for different platforms

Real-Time Systems

Task Level Design

Tasks ISRs in the order of task priority

• API_Isr (ISR)

• ProtocolStack (Task)

• MMI (Task)

• PEI (Task)

Real-Time Systems

Message Queues

• Message Queues are used for inter task communication

• Message Queues used are

PS_PDU_Queue (Protocol Stack Input)

MMI_PDU_Queue (MMI task Input)

PEI_PDU_Queue (PEI task Input)

Real-Time Systems

Working

API Memory

API_Isr

Protocol Stack

MMI

PEI PS_PDU_Queue

PEI_PDU_Queue

MMI_PDU_Queue

Queue Write

Queue Read

API write and Interrupt

API Interrupt

Real-Time Systems