UPM Diseño de sistemas de tiempo real

(1)

UPM

Diseño de sistemas

de tiempo real

Juan Antonio de la Puente

DIT/UPM

(2)

Objetivos

 

Repasaremos algunos conceptos de ingeniería de

software y su aplicación a sistemas de tiempo real

 

Nos centraremos en conceptos relacionados con el diseño

de sistemas de tiempo real mediante objetos

(3)

Aspectos de un sistema

 

Funcionalidad

– 

relación entre entradas y salidas

– 

no se considera concurrencia, sincronización, tiempo real

– 

tampoco fiabilidad ni seguridad

 

Arquitectura

– 

componentes definidos por sus interfaces

» 

interfaz que proporciona (provided interface)

» 

interfaz que necesita (required interface)

 

Concurrencia y tiempo real

– 

hebras, sincronización

– 

planificación y análisis temporal

(4)

Ejemplo de modelo funcional

PID

r

y u

€

e(t) =r(t) − y(t)

u(t) =K

_P

e(t) + K

_I

e(s)ds + K

_D

de(t)

dt

0 t

∫

⎛

⎝

⎜

⎞

⎠

⎟

e = r − y

u = K

_P

e +

K

I

h

2 (e + x) +

K

_P

h

(e − x)

⎛

⎝

⎜

⎞

⎠

⎟

x = e

Modelo continuo

Modelo discreto

•  ejecutar cada h

(período)

(5)

Diseño arquitectónico

 

En una primera etapa se modela un sistema como un

conjunto de componentes

 

Cada componente se define por sus interfaces

– 

una interfaz se define como un conjunto de operaciones o

métodos

– 

Provided interface (PI): operaciones que otros componentes

pueden efectuar con el componente

– 

Required interface (RI): operaciones de otros componentes que el

componente necesita invocar

(6)

Componentes e interfaces

 

Una interfaz es una lista de operaciones parametrizadas

 

Un componente puede tener varias interfaces PI o RI

A

PI RI RI

B

PI

C

PI

(7)

Componentes y funcionalidad

Temperature_controller

control

_PID

set_reference get_variable

(8)

Concurrencia y tiempo real

Temperature_controller

control

periodic T = 0.100 D = 0.040

(9)

Componentes de bajo nivel

 

Representan objetos que se pueden implementar

directamente en términos de la plataforma de ejecución

– 

hebras periódicas y esporádicas, objetos de datos, etc.

 

Estructura básica:

THREAD OPCS RI component C OBCS Archetype

(10)

Arquetipos

 

Abstracciones comunes en sistemas de tiempo real

 

Tareas periódicas y esporádicas

– 

componentes

cíclicos

y

esporádicos

 

Datos compartidos por varias tareas

– 

componentes

protegidos

 

Abstracción de datos

(11)

Componentes cíclicos

 

Ejecutan una actividad a intervalos regulares

– 

atributos: período, plazo

 

No tienen OBCS

– 

excepto con ATC

 

No tienen interfaz PI

– 

excepto operaciones de ATC

» 

transferencia asíncrona de control

– 

pero pueden tener RI

Temperature_Sensor

C

(12)

Componentes esporádicos

 

Ejecutan una actividad cuando ocurre un suceso externo o

interno

» 

suceso detectado por programa o por interrupción

» 

atributos: separación mínima, plazo

– 

Su interfaz consiste en una única operación (<<start>>)

» 

invocada por el objeto que detecta el suceso de activación

– 

La sincronización se realiza en el OBCS

– 

También pueden ofrecer operaciones de ATC

Level_Sensor

S

_{report_state}

<<start>>

(13)

Componentes protegidos

 

No tienen flujo de ejecución propio (THREAD), pero

pueden controlar cuándo se ejecutan sus operaciones

– 

abstracción de datos compartidos

– 

operaciones en exclusión mutua (OBCS)

– 

restricciones de sincronización adicionales

State

Pr

(14)

Componentes pasivos

 

No tienen flujo de ejecución propio (THREAD) ni control

sobre cuándo se ejecutan sus operaciones (OBCS)

– 

abstracción de datos y operaciones

– 

las operaciones se ejecutan cuando se invocan

 

Sólo se puede invocar sus operaciones desde un único

objeto activo o protegido

– 

para evitar el acceso concurrente a los datos

Display

Pa

(15)

Proceso de desarrollo en “V”

análisis de requisitos diseño arquitectónico diseño detallado realización pruebas de unidades pruebas de integración pruebas de sistema tiempo ab str ac ci ó n

(16)

Inconvenientes

 

Muy rígido

– 

difícil modificar el sistema si es necesario

 

Las pruebas se hacen al final

– 

es costoso corregir los fallos

 

Mejor un proceso iterativo

– 

comprobaciones en todos los modelos

(17)

Model-driven engineering

 

Specify systems in a

platform-independent

manner (PIM)

 

Specify execution

platforms

 

Transform PIM into

platform-specific model

(PSM)

 

The transformation must

realize PIM functionalities

within the bounds of the

platform specification

PIM

PSM

Transformation

(18)

Process vision

FUNCTIONAL

VIEW

A B C + move() : int GNC POS

INTERFACE VIEW

PIVOT

RCM

GNC POS GNC POS

(19)

Basic patterns

 

Cyclic component

 

Sporadic component

 

Protected data component

 

Passive component

(20)

Cyclic component

 

Clock-activated activity with fixed rate

 

Attributes

– 

Period

– 

Deadline

– 

Worst-case execution time

 

The most basic cyclic code pattern does not need

the synchronization agent

– 

The system clock delivers the activation event

(21)

Cyclic component (basic)

operations (OPCS) thread

cyclic component

RI cyclic operation

(22)

Cyclic thread (spec)

task type Cyclic_Thread

(Thread_Priority : Priority; Period : Positive) is pragma Priority(Thread_Priority); end Cyclic_Thread; cannot be Time_Span! ms

(23)

Cyclic thread (body)

task body Cyclic_Thread is

Next_Time : Time := <Start_Time>; -- taken at elaboration time --+ higher in the system

--+ hierarchy begin

loop

delay until Next_Time; -- so that all tasks start at T0

OPCS.Cyclic_Operation; -- fixed and parameterless

Next_Time := Next_Time + Milliseconds(Period);

end loop;

(24)

Sporadic component

 

Activated by a software-mediated event

– 

Signaled by software or hardware interrupts

 

Attributes

– 

Minimum inter-arrival time

– 

Deadline

– 

Worst-case execution time

 

The synchronization agent of the target

component is used to signal the activation event

(25)

Sporadic component

control agent (OBCS) operations (OPCS) thread

sporadic component

signal RI wait sporadic operation PI

(26)

Sporadic component (spec)

protected type OBCS(Ceiling : Priority) is pragma Priority(Ceiling);

procedure Signal;

entry Wait; private

Occurred : Boolean := False;

end OBCS;

task type Sporadic_Thread(Thread_Priority : Priority) is pragma Priority(Thread_Priority);

end Sporadic_Thread;

A sporadic thread is activated by calling the Signal operation

(27)

Sporadic thread (body)

task body Sporadic_Thread is

Next_Time : Time := <Start_Time>; begin

delay until Next_Time; -- so that all tasks start at T0

loop

OBCS.Wait;

OPCS.Sporadic_Operation;

-- may take parameters if they were delivered by Signal --+ and retrieved by Wait

end loop;

(28)

Sporadic control agent (body)

protected body OBCS is procedure Signal is begin

Occurred := True; end Signal;

entry Wait when Occurred is begin

Occurred := False; end Wait;

(29)

Other basic patterns

 

Protected component

– 

No thread, only synchronization and operations

– 

Straightforward direct implementation with protected

object

 

Passive component

– 

Purely functional behavior, neither thread nor

synchronization

– 

Straightforward direct implementation with functional

package

(30)

Temporal properties

 

Basic patterns only guarantee

periodic

or

sporadic

activation

 

They can be augmented to guarantee additional temporal

properties at run time

– 

Minimum inter-arrival time

for sporadic events

– 

Deadline

for all types of thread

(31)

Minimum inter-arrival time

 

Violations of the specified separation interval may cause

increased interference on lower priority tasks

 

Approach: prevent sporadic thread from being activated

earlier than stipulated

– 

Compute earliest (absolute) allowable activation time

(32)

Sporadic thread with minimum

separation (spec)

task type Sporadic_Thread

(Thread_Priority : Priority;

Separation : Positive) is

pragma Priority(Thread_Priority); end Sporadic_Thread;

Minimum inter-arrival time ms

(33)

Sporadic thread (body)

task body Sporadic_Thread is Release_Time : Time;

Next_Release : Time := <Start_Time>; begin

loop

delay until Next_Release;

OBCS.Wait;

Release_Time := Clock;

OPCS.Sporadic_Operation;

Next_Release := Release_Time + Milliseconds(Separation);

end loop;

(34)

Comments

 

May incur some temporal drift as the clock is read

after task release

– 

Hence preemption may hit just after the release but

before reading the clock

– 

The net effect is a larger

separation than required

 

It is better to read the clock at the place and time

the task is released

– 

Within the synchronization agent

» 

Which is protected and thus less exposed to general

interference

(35)

Minimum inter-arrival time

– alternate pattern

Next_Release : Time := <Start_Time>; begin

loop

delay until Next_Release;

OBCS.Wait(Release_Time); OPCS.Sporadic_Operation;

Next_Release := Release_Time + Milliseconds(Separation);

(36)

Recording release time (1)

protected type OBCS(Ceiling : Priority) is pragma Priority(Ceiling);

procedure Signal;

entry Wait(Release_Time : out Time); private

Occurred : Boolean := False; end OBCS;

(37)

Recording release time (2)

protected body OBCS is procedure Signal is begin

Occurred := True; end Signal;

entry Wait(Release_Time : out Time) when Occurred is begin

Release_Time := Clock;

Occurred := False; end Wait;

(38)

Deadline overruns

 

Deadline overruns in a task may occur as a result of

– 

Higher priority tasks executing more often than expected

» 

Prevented with inter-arrival time enforcement

– 

Execution time of the same or higher priority tasks longer than

stipulated

» 

Programming errors

 

Bounding assertions violated by functional code

(39)

Detection of deadline overruns

 

Deadline overruns can be detected at run time

with the help of timing events

– 

A mechanism for requiring some application-level

action to be executed at a given time

– 

Timing events can only exist at library level under the

Ravenscar Profile

» 

Statically allocated

 

A minor optimization may be possible for periodic

tasks

(40)

Cyclic thread with deadline

overrun detection (spec)

(Thread_Priority : Priority; Period : Positive;

Deadline : Positive) is

pragma Priority(Thread_Priority); end Cyclic_Thread;

(41)

Thread body

Deadline_Overrun : Timing_Event; -- static, local per component

Next_Time : Time := <Start_Time>; Canceled : Boolean := False;

begin loop

delay until Next_Time;

Set_Handler(Deadline_Overrun,

Next_Time + Milliseconds(Deadline),

Deadline_Overrun_Handler); -- application-specific

OPCS.Cyclic_Operation;

Cancel_Handler(Deadline_Overrun, Canceled);

Next_Time := Next_Time + Milliseconds(Period); end loop;

(42)

Thread body (streamlined)

Next_Time : Time := <Start_Time>; Canceled : Boolean := False;

begin loop

-- setting again cancels any previous event

Set_Handler(Deadline_Overrun,

Next_Time + Milliseconds(Deadline),

Deadline_Overrun_Handler); -- application-specific

delay until Next_Time; OPCS.Cyclic_Operation;

(43)

Sporadic thread with deadline

overrun detection (spec)

task type Sporadic_Thread

(Thread_Priority : Priority; Separation : Positive;

Deadline : Positive) is

pragma Priority(Thread_Priority); end Sporadic_Thread;

(44)

Thread body

Next_Release : Time := <Start_Time>; Canceled : Boolean := False;

begin loop

delay until Next_Release; OBCS.Wait(Release_Time); Set_Handler(Deadline_Overrun, Release_Time + Milliseconds(Deadline), Deadline_Overrun_Handler); -- application-specific OPCS.Sporadic_Operation; Cancel_Handler(Deadline_Overrun, Canceled);

Next_Release := Release_Time + Milliseconds(Separation); Can’t streamline as the

UPM Diseño de sistemas de tiempo real

Diseño de sistemas

de tiempo real

Juan Antonio de la Puente

DIT/UPM

Objetivos



Repasaremos algunos conceptos de ingeniería de

software y su aplicación a sistemas de tiempo real



Nos centraremos en conceptos relacionados con el diseño

de sistemas de tiempo real mediante objetos

Aspectos de un sistema



Funcionalidad

–

relación entre entradas y salidas

–

no se considera concurrencia, sincronización, tiempo real

–

tampoco fiabilidad ni seguridad



Arquitectura

–

componentes definidos por sus interfaces

»

interfaz que proporciona (provided interface)

»

interfaz que necesita (required interface)



Concurrencia y tiempo real

–

hebras, sincronización

–

planificación y análisis temporal

Ejemplo de modelo funcional

PID

€

e(t) =r(t) − y(t)

u(t) =K

e(t) + K

e(s)ds + K

de(t)

dt

∫

⎛

⎝

⎜

⎞

⎠

⎟

e = r − y

u = K

e +

K

h

2

(e + x) +

K

h

(e − x)

⎛

⎝

⎜

⎞

⎠

⎟

x = e

Modelo continuo

Modelo discreto

• ejecutar cada h

(período)

Diseño arquitectónico



En una primera etapa se modela un sistema como un

conjunto de componentes



Cada componente se define por sus interfaces

–

una interfaz se define como un conjunto de operaciones o

 

 

 

– 

– 

– 

 

– 

» 

» 

 

– 

– 

•  ejecutar cada h

 

 

– 

– 

– 

_PID

 

– 

 

 

 

– 

 

– 

 

 

– 

 

– 

 

– 

» 

– 

 

» 

» 