Towards Efficient Use of Shared Communication Media in the Timed Model

Guido Menkhaus, Michael Holzmann, Sebastian Fischmeister, Claudiu FarcasComputer Science Department, University of Salzburg, Austria

{firstname. lastname}@cs.uni-salzburg.at

Abstract

Embedded computers are increasingly tighter integratedwith each other forming distributed embedded systems thatinteract through a shared communication medium. Oftenthese embedded systems perform services for safety-criticaloperations that require deterministic computation and pre-dictable communication. However, since these systems areembedded, they must cope with limited resources. One fun-damental challenge is to make efficient use of the sharedcommunication medium, especially in the timed model, inwhich communication tends to cumulate at the end of har-monic periods of tasks.

In this article, we present an approach that uses Micro-tasks for splitting computation and communication into sev-eral sequentially executed steps to allow for better balancedload on the communication medium in the timed model.We discuss the approach and describe its implementationin OSEK/Works with TTCAN.

1. Introduction

Most modern control applications are implemented insoftware. It is therefore necessary to understand the dif-ferent role of time from the perspective of software andcontrol engineering [20]. The control engineering perspec-tive is that processes evolve in continuous real-time, delaysare small and jitter is negligible. From the perspective ofsoftware engineering, a set of tasks needs to be scheduledand time evolves discontinuously, since time elapses for atask only when it is active and running. Each task has a re-lease time, a hard deadline and a worst-case execution time(WCET). Often, the deadline of a task equals the respec-tive period of the task.

Jitter is defined astime-related, abrupt, spurious varia-tions in the duration of any specified related interval[1].Start jitter of a task is the time variation around the periodof a task reading its inputs. Completion jitter of a task is thetime variation around the period of a task completion pointwhen updating its outputs. Start and completion jitter maylead to vacant sampling and sample rejection [23]. Sam-ple rejection means that an input value of a task is obtained

more than once between two consecutive release times ofthe task. Vacant sampling means that a new input value to atask is not available between two consecutive releases of atask and that an obsolete value is repeatedly used. Start andcompletion jitter of a task is due to the non-synchronicityof two data-dependent tasks. Apart from sample rejectionand vacant sampling, severe jitter can degrade system per-formance [7].

The effects of start and completion jitter of a task are di-minished by introducing the logical execution time (LET)of a task in the timed model [2][3][13]. In the timed model,the start of the LET marks the point in time when the in-put values are read. The end of the LET marks the point intime when the results of the computation of a task becomeavailable to other tasks or actuators. Even if the output of atask becomes available before the end of the LET, the out-put values will not be released prior to the expiration of theLET. The LET of a task is always greater or equal than thesum of the WCET and the worst-case communication time(WCCT); the WCCT is greater than zero in case values needto be transmitted to a different computational node in a dis-tributed application. The concept of LET allows for precisesynchronization of tasks for central and distributed applica-tions. However, it disregards code efficiency and system re-activity, which results in unnecessary actuator updates andcommunication delays. In a distributed hard real-time appli-cation in which time-triggered and cyclicly executed taskson different computational nodes need to exchange valuesover a network, applying the timed model leads to unbal-anced network load [18]. The timed computation model de-fines the communication activities for each task to occur atthe end of the LET. Since the periods of all tasks of an ap-plication start simultaneously at the beginning of the hyperperiod, there is a peak in computation (higher CPU load)at the beginning of the hyper period, whereas communica-tion (network traffic) dominates at the end of the period.

In this article, we present an approach for balanced net-work load for the timed model. To balance the CPU andthe network load and to distribute it equally over the hy-per period, we introduce Micro-tasks. Micro-tasks define asequence of executing tasks. They allow for communicat-ing task results over a network regardless of the fact thatfrom a semantic point of view outputs are only available atthe end of the LET of a task. Micro-tasks split the com-

putation of a task into a set of Micro-tasks and executeactuator updates intertwined with the invocation of thoseMicro-tasks [8] thereby allowing for the fine grained controlof software tasks and their distributed interaction. We dis-cuss an infrastructure for distributed hard real-time applica-tions that bases on the Timing Definition Language (TDL)in which the computation of tasks and the communicationof messages is controlled by a virtual machine.

The remainder of the article is structured as follows:Section 2 gives a short overview of concepts of the timedmodel. Related work is discussed in Section 3. Commu-nication and efficient computation with Micro-tasks is in-troduced in Section 4. An overview over the TDL infras-tructure for distributed real-time applications is given inSection 5. Section 6 presents the implementation of theTDL virtual execution environment on OSEK/Works andthe TDL communication system is discussed in Section 7.Section 8 presents results and the article closes with a con-clusion in Section 9.

2. Short Overview of Concepts for the Imple-mentation of the Timed Model

The concept of languages representing the timed modelbases on time-triggered cyclic computation and communi-cation. The LET describes the timing behavior of a task.It denotes the invocation period, i.e. its relative releasetime and the deadline of a task. According to a schedulingscheme, the task starts after it has been released at the be-ginning of the LET and is active afterwards and completesits execution before the LET has elapsed. A communicationschedule defines when the communication system transfersvalues from one computational node to another and whenthe next transmission will take place.

Timing Definition Language.The Timing Definition Lan-guage (TDL) is a software description language intendedfor timed computation. TDL allows for defining the timingbehavior of a set of task [22]. It separates the timing con-straints of an applications from the functional implementa-tion, which must be provided separately, for example, usingan imperative programming language such as C.

The most important programming abstractions of TDLare modules, modes, tasks, and ports: A module declares aset of modes. A mode defines a set of task, actuator, andmode switch invocations that are executed periodically andconcurrently. A TDL module can only be in one mode at atime, but can change from one mode to another at the endof a mode period. A TDL mode specifies the period, i.e.,the length of one computation cycle. A task period is de-termined with respect to the execution period of the modeto which the task is assigned (by dividing the period of themode by the task frequency). A task has a set of input ports,output ports and a set of drivers reading and writing datafrom and to the ports. Ports are logical points of intercon-nection between tasks, modes, and modules. Drivers copy

values between task input and output ports, read sensors,and update actuator. Mode drivers read sensors and updatemode ports, which are a subset of the task output ports.

The communication subsystem ensures the timely trans-mission of values from one computational node to another.In a distributed application, in which a task on one compu-tational node transmits its results to remote tasks, tasks out-put ports are logically distributed across the communicatingnodes.

Virtual Machine for Task Monitoring.A task, to comply tothe LET, is dispatched and monitored by a virtual machine,the E-machine [12]. The E-machine supervises the timingbehavior of a set of tasks and ensures their timing con-sistency and their communication requirements. In a dis-tributed environment, the communication requirements andthe local design of timing definitions of the tasks may raiseglobal design restrictions (scheduling restrictions) that needto be resolved and synchronized with the global communi-cation schedule of all nodes.

The E-machine executes platform-independent E-codeand calls platform-dependent application code. The appli-cation code is responsible for logical correctness and theE-code ensures timing consistency. The E-code consists ofa small set of instructions for basic control flow and pro-cessing, that allows for synchronous calls of input and out-put port drivers, task and actuator scheduling and initializ-ing the execution of a set of E-code instructions at somepoint in time in the future. A task, violating its timing prop-erties, causes a run-time exception that is handled by an ex-ception handler.

Autonomous Communication System for Value Transmis-sion. The communication system of TDL supplies a datacommunication system that allows for transmitting valuesfrom task output ports of a TDL program to input ports ofa task running on a different computational node. It uses atime-triggered communication subsystem to transmit data.It works autonomously: sending and receiving of messageshappens without any interaction from the application pro-gram [18].

Synchronization.Time-triggered computation and commu-nication, when distributed on several computational nodes,requires a synchronized time base among the participatingnodes. The common time base is a precondition for syn-chronization of data-dependent tasks and for using a time-division multiple access (TDMA) bus arbitration scheme.In TDMA, a node accesses a single transmission channelwithout interference from other nodes. Usually, it is imple-mented by communicating nodes allocating predeterminedtime slots on the channel.

Determinism for Value and Time Predictability.The intro-duction of the E-machine ensures compliance to the LET,which allows precise synchronization of tasks for local anddistributed applications. Assuming clock synchronizationof the participating computational nodes, this leads to valueand time deterministic distributed systems. Determinism is

a desirable property for software systems that control physi-cal systems that are ruled by deterministic physical laws [9].In a deterministic system, an external observer can consis-tently predict the future behavior of the system. A systemsis said to be value deterministic, if the same sequence ofinputs produces the same sequence of outputs. If the sys-tem produces for the same sequence of inputs the same se-quence of outputs at always the same time, then it will bevalue and time deterministic.

Timed Model for Determinism.In distributed applications,in which values from task output ports are transmitted overthe communication medium to input ports of tasks on differ-ent computational nodes, the LET is composed of the logi-cal computation time (LCT) of a task and the logical trans-mission time (LTT) of the task’s output values (see Fig-ure 1). The LCT specifies a fixed time interval in which the

Logical execution time (LET)

Relative Deadline

TransmissionSlot

TransmissionSlot

Results availableto local and non−localoutput ports

� �� �� �

� �� �� �

� �� �� �

� �� �� �

� �� �� �

� �� �� �

���

���

� � � �� � � �� � � �

���

Logical transmission time (LTT)

Completion

Resume Complete

Time

Release

Logical computation time (LCT)

Start

Reading input ports

Suspend

Logical completion

Figure 1. Implementation of computation andcommunication of a task in LET.

task is active. The task starts after it has been released, maybe preempted, but resumes and always completes its exe-cution before the LCT has elapsed. This LCT remains thesame for e.g. different platforms or for different task im-plementations. Then, the LCT ensures that a set of tasks ex-hibits invariant timing behavior. The underlying assumptionis that the set of tasks is schedulable, this means that thereis enough time available within the interval to execute eachtask of the set.

The length of the LET determines the length of the LTT.The real-time system designer specifies the LET and mightneed to reconcile it with the (1) LTT specifications of alltasks in the system and (2) the worst case communicationtime of the communication medium.

3. Related Work

Approaches to computation and communication in dis-tributed real-time systems can broadly be divided into twocategories. Time-triggered systems use a global time basefor controlling the release time and the deadlines of tasksand the sending and receiving of messages. Event-triggered

systems release a task after the registration of an event thatactivates the task. A message will be sent immediately if thecommunication media is free. If the media is occupied, thetransmission will be delayed until the media is free.

The time-triggered protocol (TTP) is a communicationprotocol for fault-tolerant distributed hard real-time sys-tems [16]. It provides time-triggered transmission of mes-sages, distributed clock-synchronization, and a membershipservice. The communication on the bus is done with staticand periodic TDMA rounds. Every message that is sentfrom any node has to be specified and an automatic sched-uler generates a bus schedule matching the specifications.Implemented as message descriptor list, the schedule spec-ifies exactly when a node has to send a certain message andwhen messages from the other nodes have to be received.The task descriptor list describes the cyclic scheduling ofapplication tasks. This list specifies the instances of time ofstarting and stopping tasks. This system guarantees valueand time determinism on a global level, however on a sin-gle computational node, time determinism and value deter-minism cannot be guaranteed, since tasks are not executedaccording to the timed model and values are not communi-cated at predefined instances of time between locally exe-cuted tasks.

Event-triggered communication must provide collisiondetection and resolution or avoidance techniques. CAN usesa bit arbitration for collision avoidance [5]. Bitwise arbi-tration allows for determining the priority of each messagesent. Messages with a higher priority continue to send whilenodes with low priority messages delay their transmission.Bitwise arbitration causes non-deterministic transmissiondelays.

DaVinci supports the control engineer to develop ap-plications for distributed platforms [24]. It provides twotools which separate the design of functional componentsfrom the integration of those components to a specific,possibly distributed platform. The runtime behavior of aDaVinci application depends on the prioritization of tasksand bus messages. The unrestricted way of using, for ex-ample, semaphores or other resources may lead to phenom-ena such as priority inversion, where determinism cannot beguaranteed.

In this article, we present the TDL system for time-triggered computation and efficient communication thataims at value and time determinism of a hard real-time ap-plication on each computational node and among all dis-tributed nodes.

4. Intertwined Communication and Compu-tation with Micro-tasks

In [18], the authors suggest to split the LET into an LCTand an LTT. In this model, the results of the task are passedto the communication subsystem for transmission on theshared communication medium at the end of the LCT. Thus,communication tends to accumulate at the end of harmonic

task periods and the hyperperiod of each modules. If sev-eral modules have the same mode period, then the sharedcommunication medium will be congested at certain times.

Figure 2 shows an example of a situation in which com-munication piles up. TaskT1 and T2 share the same fre-quency and the same mode period. TaskT1 communicatestwo messages and TaskT2 communicates one message.Both tasks send the their messages after the LCT and be-fore the LET expires. However, since the communicationmedium is shared, the remaining time of the LET is insuf-ficient to transmit all messages and the bus scheduler mighttry to resolve this conflict by reducing the LCT of one of thetasks. This however, might entail other conflicts or contra-dict with system requirements.

���

���

���

���

���

���

T1

Bus

T2

TimeComm. cycle =LETT1 = LETT2

LCTT1

LCTT2

Figure 2. Communication cumulates at theend of the period and decreases the availableLCT of Task T1 and Task T2.

To provide more flexibility for the bus scheduler, wesplit taskT1 into a sequence of Micro-tasks. Each Micro-task computes results and if no succeeding Micro-task up-dates this results subsequently in the same period, the valuewill be passed to the communication system and thus thebus scheduler will be enabled to schedule the transmissionof this value even before the LCT of the parent task haselapsed.

Figure 3 shows an example of intertwined computationof Micro-tasks and communication of their results. In con-trast to the previous example, TaskT1 is now split into threeMicro-tasks:mt1, mt2, mt3. Each Micro-task computes re-sults, but only the results of Micro-taskmt1 andmt2 mustbe transmitted over the bus. The bus scheduler is able toschedule the transmission of the results of Micro-taskmt1andmt2 immediately after their completion. As Figure 3shows, in total TaskT1 has a larger LCT than in Figure 2(LCTT1 =

∑i LETmti), since communication is inter-

twined with computation.

4.1. Micro-tasks in TDL

Listing 1 implements the TDL program for the exam-ple of Figure 3 (T2 omitted). The syntax and semanticsof Micro-tasks are similar to the declaration of tasks (for

���

���

���

���

���

���

T1

Bus

T2

TimeComm. cycle =LETT1 = LETT2

mt1 mt2 mt3

LCTT2

LCTmt3LCTmt2LCTmt1

Figure 3. Single values are computed usingMicro-tasks and are sent prior to the end ofthe LCT of Task T1.

full description of the syntax and semantic of Micro-tasks,see [8]).

task mt1 [ WCET= 100 ms] {i npu t int i ;output int o ;uses f1 ( i , o ) ;

}task mt2 [ WCET= 200 ms] {

i npu t int i ;output int o ;uses f2 ( i , o ) ;

}task mt3 [ WCET= 50 ms] {

i npu t int i , s ;output int o ;uses f3 ( i , s , o ) ;

}task T1 {

i npu t int i ;output int o1 , o2 ;s t a t e int s ;

[ LET = 200 ms] mt1 {i := this . i } ;this . o1 = mt1 . o ;[ LET = 300 ms] i f g2 ( ) then mt2 {i := mt1 . o } ;this . o2 = mt2 . o ;[ LET = 100 ms] mt3 {i := this . i , s := this . s } ;this . s = mt3 . o ;

}s t a r t mode main [1000 ms] {

task[ 1 ] T1 {i := s1 } ;. . . .

}

Listing 1: Example TDL snipplet for Figure 3.

Task T1 comprises three Micro-tasks. First, it releasesmt1 that has to finish its execution within the next 200 mil-liseconds (LET = 200 ms and WCET = 100ms). Micro-taskmt1 computes the outputo1 of TaskT1 as the assignmentshows in the declaration of taskT1. Micro-taskmt2 exe-cutes, if the guardg2 evaluates to true. If it executes, it willfinish within the next 300 milliseconds as specified in itsLET. Micro-taskmt2 computes the output valueo2 of taskT1. Finally taskT3 computes the new value for the statevariables.

4.2. E-code Generation

The TDL compiler compiles the TDL program into E-code. To provide more flexibility for the bus scheduling,the output values are transmitted to the communication sub-system as they are no longer modified for the remaining ofthe LET of the parent task. This increases the time interval(LTT) in which the values may be transmitted by the com-munication system and thus increases the number of possi-bilities for the bus scheduler to find a schedulable solution.

Listing 2 shows the resulting E-code for Listing 1. Themost important E-code instruction are thecall, schedule,future, andreturn instruction: Thecall instruction syn-chronously executes drivers of a task. Theschedule instruc-tion releases a task to be activated by the dispatcher of theoperating system. Thefuture instruction initiates the exe-cution of a block E-code instructions at some time in the fu-ture and thereturn instruction finishes the execution of theblock of E-code of the current label. The E-code starts withthe instruction at labelL0. In the first two instructions, theE-machine calls the drivers for reading input values into theinput ports of taskT1 and Micro-taskmt1. Then, taskmt1andT1 are scheduled. Execution of the E-code is then con-tinued at Label L1 after 200 ms, indicated by the future in-struction. As the output valueo1 of TaskT1 does not changeafter the output value of Micro-taskmt1 has been assigned,the value is passed to the communication system after 200milliseconds calling drivernw1. The same is done for theoutput valueo2 of TaskT1, analogous to the E-code instruc-tion at Label L0.

L0 : c a l l d [ T1 ]c a l l d [ mt1 ]schedu le mt1schedu le T1f u tu re 200000 , L1re turn

L1 : c a l l d [ nw1 ]c a l l d [ mt2 ]schedu le mt2f u tu re 300000 , L2re turn

L2 : c a l l d [ nw2 ]c a l l d [ mt3 ]schedu le mt3f u tu re 100000 , L0re turn

Listing 2: The E-code for the TDL program in Listing 1.

5. Overview of TDL for OSEK and TTCAN

In the following, we present a prototype implementationof the TDL infrastructure for distributed hard real-time ap-plications. Figure 4 provides an overview. The TDL runtimepart of the infrastructure consists of TDL-Exec and TDL-Comm: TDL-Exec implements the E-machine and TDL-Comm is a communication system that allows for transmit-ting values from task output ports of a TDL program to in-put ports of a task running on a different node. TDL-Exec

and TDL-Comm are implemented on OSEK with sTTCANas communication system.

E−codeOIL

TDL program

Platform (OSEK/VDX)

Sensor Environment Actuator

source codeApplication

Applicationobject code

TDL−Commread

callsexecutes

Online

Offline

callscalls

runs on

Actuator

callscalls

provides provides

acts on

calls calls

collects

data

compiles into

calls

compiles into

Applicationwrapperobject code

Driver code Driver code

TDL−CommwriteTDL−Comm (sTTCAN)

TDL−Exec (E−Machine)

Environment

Figure 4. TDL infrastructure for distributedreal-time applications.

OSEK/VDX started as a joint project of the automotiveindustry becoming an open standard for real-time softwarecontrol systems. Current specifications are limited to singleprocessor systems, with support for distribution via specificcommunication interfaces such as CAN. The operating sys-tem is designed to be modular and configurable to support awide range of embedded platforms with small memory foot-prints targeting low-end microprocessors/micro-controllers.The operating system does not support dynamic generationof system objects, such as tasks, services, or resources.

The configuration of tasks and their properties, such aspriority, stack space, preemption flag, and alarms and re-sources are statically defined at compile time in a specificconfiguration file using the OSEK Implementation Lan-guage (OIL). During runtime, the number of tasks and theirproperties described in the OIL file cannot change. EachOSEK task has a statically defined priority that is used bythe OS dispatcher to decide which task to run. OSEK taskscan have one of two types: basic and extended. The maindifference between them is resource access. Any basic taskcan either be in the ready, running, or suspended state. Ex-tended tasks may have the additional state of waiting for aresource. In addition to task priorities, the timing aspectsof tasks can be controlled with alarms based on user de-fined counters. The counters are all derived from the sys-tem counter or some external timer interrupt. The alarmscan be setup to activate new instances of tasks just once orin a cyclical fashion.

6. TDL-Exec for OSEK

The TDL execution environment (TDL-Exec) consists ofthe E-machine. It must exhibit the same properties in all im-plementations no matter the underlying real-time operatingsystem. The current implementation is based on standard

Cycle period

Task 2 period

Task 2

Task 3

ActivateTask

Release T1, T2, T3

Task 1

IDLE Task

High

Prio

Low

Prio

ActivateTask

Release T3

ActivateTask

Release T2

ActivateTask

Release T3

E-Machine Highest

Prio

Task 3 period

Task 1 period

Legend

Loopback

Zero Logical Time

Suspended Task

Ready Task

Running Task

Task Termination

OSEK Alarm

Task Deadline

Release task

Timed preemption

Figure 5. Rate Monotonic scheduling with OSEK

ANSI C-code, making it highly portable to most embed-ded platforms. Since each operating system has differentways to implement basic concepts such as threads, tasks,delays or alarms, all of these OS dependent aspects are sep-arated from the application code and the implementation ofthe E-machine for easier maintenance and portability.

The TDL toolchain may use model-based developmenttools such as Simulink [17] to produce application sourcecode and the corresponding TDL program [21]. The TDLcompiler compiles the TDL program into E-code and appli-cation wrapper code that is used to build the final real-timeapplication conforming with the timed model. In the case ofthe OSEK platform, an additional OIL configuration file isgenerated and linked with the E-code, the wrappers, the ap-plication code, the E-machine and OSEK libraries produc-ing the final executable that is executed on the target plat-form. As the OSEK OS does not provide any facilities forsupporting a filesystem or dynamic loading of user code,the E-code is expressed as a static C data structure that islinked with the functional code and compiled in in the fi-nal application. The task wrappers represent OSEK tasks.The OSEK tasks that encapsulate the application code arereleased by the E-machine according to the correspondingE-code instructions, this means in a time-triggered way. TheE-code sequence of instructions actually encodes the ap-plication’s reactive behavior and performs the lock-free re-source sharing (such as sensors or actuators) among differ-ent logically concurrent tasks.

6.1. Task scheduling with the OSEK E-machine

The E-machine mediates between soft (logical) time andreal (physical) time and releases the tasks of the application.It monitors the released tasks, their deadlines and their com-munication requirements and constraints imposed by TDL-Comm.

The OSEK internal scheduler supports plain static prior-ity based scheduling. To implement a different scheduling

policy such as EDF or RM [6], OSEK provides the chain-ing tasks feature. Chaining tasks are used in the OSEK E-machine to complement the scheduling scheme of OSEK.The E-machine selects the next active task according to thecurrent scheduling policy, such as EDF. However, depend-ing on the implementation of the OSEK chaining tasks fea-ture and the underlying OSEK task scheduler/dispatcher thefunctionality may not be available under all OSEK OS vari-ants.

6.2. E-machine Implementation under OSEK

The E-codeschedule instruction releases a task by tog-gling its release flag and turning it into the ready state. Af-ter a sequence ofschedule instructions follows the E-codefuture instruction that initiates the execution of a sequenceof E-code after a specific amount of time has elapsed. De-pending on the CPU speed of the target platform and theOSEK OS variant the clock resolution may not be up to mi-croseconds, but instead to hundreds of microseconds or acouple of milliseconds. On the sample platform (KANISboard with MPC555 CPU), the clock accuracy was deter-mined to be around500µs. For lower time intervals theclock drifting effect corrupts the overall behavior of the ap-plication. Thereturn instruction ends the interpretation ofthe current E-code block. The E-machine keeps track of allfuture instructions parameters: future time and future E-code instruction pointer, planning the activity for the nextcycles.

During the future time interval the released tasks are runby the E-machine scheduler according to its scheduling pol-icy. Since the E-machine is a task itself, the E-machine istriggered (1) by an OSEK alarm in a cyclic fashion withtime intervals equal to the last future time (from the lastE-codefuture instruction after a sequence ofschedule in-structions) and (2) by application tasks after finishing theircomputation. This loop-back mechanism (the E-machine istriggered by application tasks, that it itself releases) that re-

turns control from the application tasks to the E-machinebefore the future time has elapsed, allows running one taskat a time. Preempting a task is only necessary for schedul-ing a new task, instead of periodically preempting tasks witha certain frequency as many RTOS do [10]. The loop-backmechanism improves the compactness of CPU time alloca-tion for application tasks and generally provides less CPUload and allows for better utilization of the remaining CPUtime for non real-time tasks, such as diagnostic activities.

Approaches using static non-preemptive scheduling withno context switches (except for interrupt handling and otherOS critical activities) can schedule only specific sets oftasks [6]. Our approach is more flexible with respect to theset of tasks since the mechanism of our scheduling greatlyreduces the number of context switches required. Imple-menting an optimal scheduler such as EDF or RM, the CPUutilization level can be computed in advance for any givenset of tasks and in dynamic systems this may be a decisiveaspect for dynamically loading additional functionality onthe system. In our approach the benefit comes from the re-duced number of context switches (that is not negligible onlow-end micro-controllers running high frequency tasks).

Figure 5 describes the Rate Monotonic scheduling policyimplemented with OSEK. Each task has a priority propor-tional to its frequency: a higher frequency task has a higherpriority and a task with low frequency has a lower priority.A task is released by the E-machine via ActiveTask func-tion and the OSEK scheduler selects the active task withthe highest priority to run. A higher priority task preemptsa lower priority task until it finishes its computation. If atasks communicates with another task on a different com-putational node, the task completes its execution by loop-ing back to the E-machine to perform communication re-lated functions.

6.3. Scheduling Micro-Tasks

From the E-machine point of view the Micro-tasks areregarded as regular tasks. The E-code contains the actualinstructions to release the Micro-tasks at the right momentsand to run the drivers when needed. The main difference isthat the E-machine will be triggered more often than in thecase of regular tasks (equal to the number of Micro-tasksa regular task is composed of). The performance impact ofthis side-effect is acceptable and is backed up by the ad-ditional flexibility in implementing arbitrary computation /communication workloads.

7. TDL-Comm on top of sTTCAN for OSEK

The TDL infrastructure accommodates the TDL Com-munication Subsystem (TDL-Comm) for distributed appli-cations. TDL-Comm implements a distributed shared vari-able space in which TDL ports are shared among severalcomputational nodes. TDL-Exec accesses shared TDL pub-lic ports via the TDL-Comm interface.

TDL-Comm builds on a time-triggered communicationsubsystem. The time-triggered communication subsystemof each network node processes all communication activ-ities. TDL-Comm accesses the communication network in-terface of the node’s local network controller which con-tains all messages received or sent by the network con-troller. It copies data between this communication networkinterface and the TDL-Comm interface in order to makethem accessible to TDL-Exec.

7.1. TDL-Comm Interfaces

TDL-Comm exposes three interfaces to the TDL-Execof a computational node:

• Comm Interface.The Comm Interface contains thedata shared among the nodes. The data is representedby means of TDL ports. TDL tasks of TDL-Exec ac-cess the shared ports within the Comm Interface usingport specific drivers. The drivers copy values of outputports of a task to the input ports of the Comm inter-face, which forwards them to the communication net-work interface. The Comm Interface has a set of out-put ports, whose values are destined for input ports oftasks, which are then retrieved via tasks drivers.

• FT InterfaceThe FT interface contains information re-garding the status of replication and fault tolerant com-munication.

• Native Interface.The native interface contains sup-ports, for example, access to platform specific services,such as the error counters of a CAN controller, etc.

7.2. TDL-Comm toolchain.

TDL-Comm consists of an offline and an online part. Theruntime behavior of the TDL-Comm online part is defineda priori (before runtime) by the offline part (TDL-Commscheduler).

Offline. The offline part analyzes the distributed applica-tion and generates the communication schedule. The TDL-Comm compiler scans all TDL modules and a module usingresources (sensors, actuators, or ports) of a different mod-ule located on a remote node indicates that communicationis required. The use of resources of a different module is in-dicated by the import relation between TDL modules. Themapping of TDL modules (parts of functionality) to com-putational nodes is defined in a dedicated configuration filewhich is read by the TDL-Comm compiler.

The communication requirements are the basis for cre-ating a global bus schedule. After generation of the globalbus schedule, the TDL-Comm compiler generates a staticcommunication schedule list for each computational node,which defines the behavior of the TDL-Comm online partduring runtime.

Online. The TDL-Comm online part processes the a pri-ori defined static communication schedule list. The commu-nication schedule list defines activities which are synchro-nized with the timing of TDL-Exec and which are cycli-cally repeated in synchronization with the TDL mode pe-riod. The activities are sending and receiving of messagesor the preparation of messages for transmission dependingon the underlying communication subsystem. Other activi-ties are copying data between the TDL Comm interface andthe communication subsystem, marshaling TDL ports intodata frames of the communication subsystem, voting faulttolerant values and updating the status fields within the FTinterface.

7.3. Software TTCAN Implementation for OSEK

The TDL-Comm implementation uses a standard physi-cal CAN link [5] and bases its concepts on TTCAN [11].TTCAN extends the CAN protocol by providing time-triggered communication via the standard physical CANlink [5]. TDL-Comm is based on a proprietary implemen-tation of TTCAN in software which we call sTTCAN. Thisimplementation was required because of the lack of avail-ability of a production TTCAN controller chip and toolchain support on the one hand and because of the greaterflexibility to adopt the protocol to TDL specific needs onthe other hand.

7.3.1. Clock SynchronizationTime-triggered communi-cation requires a globally synchronized time base that needsto be established among the participating nodes [15]. Thesynchronized local clocks of the nodes enable the participat-ing nodes to access the bus via TDMA arbitration scheme.Each node has certain instances (time slots) assigned inwhich it has exclusive access to the communication mediumthus avoiding collisions and allowing for predictable jitter-free communication.

The synchronization of the local clocks of the nodesis accomplished using a master-slave clock synchroniza-tion scheme based on the TTP/A fireworks protocol [14].One of the nodes act as clock synchronization master cycli-cally broadcasting a synchronization message (sync frame)which is used by the other nodes (slaves) to synchronizetheir clocks to the clock of the master. On reception of thesync frame of the master, the slaves generate a time stampwith their local clock. Each sync frame contains a timestamp of the masters clock at the time of sending the syncframe. The slaves calculate the current deviation of theirclocks from the master clock subtracting the time stamp re-ceived within the sync frame from the time stamp gener-ated with their own clock. This deviation is compensatedwithin the current synchronization period (until the nextsync frame is received) by adjusting the speed of the lo-cal clock.

Time stamping is done using the time stamping featureof the MPC555 CAN controller. It automatically generates

a time stamp on reception of a message, i.e., at the instantof detection of the start of frame symbol on the bus. Thusit is possible to do time stamping at the slave nodes withoutthe use of interrupts. Using interrupts would cause indeter-minism, because of possible preemption of the TDL-Exec,and furthermore executing interrupt service routines to gen-erate time stamps is not accurate because of jitter.

7.3.2. Software TTCAN Synchronizing the OSEK sys-tem timers of the computational nodes enables a softwareimplementation of a time-triggered communication proto-col via the standard CAN bus entirely under OSEK. Thecommunication schedule list is locally stored at each node.For each slot there is an entry in the communication sched-ule list denoting the point in time a slot starts, the activity(send or receive), the length of the slot, and the number ofthe message it has to send or to receive within this slot.

The communication pattern is recurring cyclically, thelength of the cycle is synchronized to the TDL mode pe-riod. The sync frame sent by the clock master denotes thestart of a new communication round. On its reception allnodes start processing their static communication schedulelist from the beginning. Transmitting messages usually doesnot require CPU interaction if a time-triggered communica-tion subsystem is used, because it usually has its own au-tonomous controller. However, the sTTCAN implementa-tion needs CPU interaction to trigger the sending of mes-sages.

Sending of messages is done setting-up OSEK alarmssuccessively for each send entry in the communicationschedule list. If the alarm fires, the alarm callback routinetriggers the CAN controller to send the appropriate messagedenoted in the actual entry of the communication schedulelist. Then, the next alarm is set-up according to the instancedenoted in the next entry of the communication schedulelist. This is repeated until the end of the list is reached. Withthe beginning of the next communication round processingstarts anew from the beginning of the list.

Receiving of messages does not need CPU interaction.If a message is received which is intended for the node itis automatically stored in one of the 16 buffers of the CANcontroller.

7.3.3. TDL-Comm with Micro-task Support In the caseof the prototype implementation on top of sTTCAN theTDL-Comm Interface is represented by the 16 messagebuffers of the CAN controller. Each of the 16 messagebuffers can hold one message. The prototype implementa-tion of TDL-Comm consists of a set of specific TDL driverswhich directly access the data within the CAN buffers andcopy them to a group of dedicated TDL ports representingthe TDL-Comm interface. The communication schedule listdetermines the number of the buffer entry (message buffer)an activity has to be carried out on at a specific point in time(see Table 1). The beginning of an activity, i.e., the start ofa time slot is denoted inms (Start Time) relative to the startof the round, the number of the buffer entry is denoted as the

(a) The setup. (b) Congestion at the end of the period. (c) Balanced load (Micro-tasks).

Figure 6. TDL infrastructure setup using Micro-tasks to balance network load in the timed model.

number of the corresponding message buffer and the lengthof the time slot is denoted as length of the message to betransmitted within. The timing denoted within the list, i.e.,the start time of a slot is converted into OSEK system timerticks (MT ) in order to set up the corresponding alarms (re-fer to section 7.3.2).

Pos. Start Time #Buffer Length1 2 1 42 15 2 2

Table 1. Communication schedule.

The scheduling list presented in the table 1 defines thecommunication schedule for one node that executes two ac-tivities within each communication round. The first entry ofthe list indicates that during the time slot beginning atms2relative from the start of the round it has to send a four bytemessage which is stored in buffer number one. The secondentry indicates the transmission of a two byte message dur-ing the time slot beginning atms15 stored in buffer num-ber two. The timing of the communication subsystem andthe E-machine rely both on the local OSEK system timerand on the fact that the OSEK system timers of all involvednodes are synchronized.

Regarding Micro-tasks, access to the TDL-Comm iscompletely transparent to the TDL-Exec. Both, ordinaryTDL tasks as well as Micro-tasks access public ports withinthe TDL-Comm interface via dedicated drivers. To commu-nicate a value to a remote node, TDL-Exec executes a spe-cific driver which is declared in the E-code resulting from aTDL program running on the local node. The driver copiesthe output value from the output port of a task or a Micro-task to the TDL-Comm Interface. At the receiving node, adedicated driver, declared in the E-code of the TDL programrunning at this node, fetches the received value from thebuffer of the CAN controller it was received in and copiesit to the input port of the receiving task or Micro-task.

From the point of view of TDL-Comm the treatment of

the TDL-Comm interface ports accessed by ordinary TDLtasks and the treatment of the ports accessed by Micro-tasksis different regarding timing aspects. In the case of the for-mer the instances at which the ports within the interface areupdated are determined by the LCT restrictions imposed onthe timing of communicating tasks by the schedule of thebus. In the case of the latter they are determined by the in-stances defined in the Micro-task code at which the driversaccessing the TDL-Comm interface are invoked.

Because of the explicit definition of the timing of ac-tivities within the LET, the Micro-task approach allows forcommunication of values at the beginning of the LET andthus for utmost flexibility regarding the bus scheduling.

8. Results

Our target platform is the Motorola MPC555, a microcontroller commonly used for automotive applications [19].The target board is the KANIS OAK EMUF [4], whichfeatures integrated physical layer drivers for CAN and en-hances the I/O palette offered by the controller with an addi-tional Ethernet link. Each computational node of the exam-ple distributed TDL application is a KANIS OAK EMUFboard. The nodes in this example are interconnected via aCAN bus link (see Figure 6(a)).

We present the results of the examples introduced insection 4: Task execution with communication at the endof their period and Micro-task implementation with inter-twined communication during the LET of the parent task.Figure 6(b) and 6(c) present images of an oscilloscopeshowing the task dispatching, the E-machine activities, andthe network frames. Each image of the oscilloscope showsfour different signals: The analog line A1 (uppermost sig-nal) is connected to the CAN bus signal and displays net-work frames (e.g., sync frame and data frame). Each roundstarts with the sync frame on the CAN bus. The cycle lengthof the application is 20ms and is delimited in the oscillo-scope images by the two vertical dashed lines (cursors). Thedigital input signals 8, 9, and 10 (three lowermost signals)are connected to digital outputs of the board and display thestates of tasks and the E-machine task. A high signal means

that a task is running and a low signal denotes a task that isstopped or suspended.

Figure 6(b) shows the behavior of the implementationwithout Micro-tasks. After start of the period by the syncframe (right next to the cursor line), the E-machine task be-comes active (peak on oscilloscope at input line 10) releas-ing tasksT1 andT2. T1 is scheduled immediately (oscillo-scope at input line 8 changes to high) after the E-machinetask has terminated. After taskT1 has completed its com-putation, the E-machine task is resumed by the chain-taskloopback (peak at input line 10). It invokes the communica-tion driver for taskT1 and schedules taskT2 (input line 9)for execution. WhileT2 executes, the CAN controller com-municates the results ofT1 in two slots. After taskT2 hasfinished its computation (input line 9 changes back to low)its result is communicated via the CAN bus in the last slotbefore the next round starts.

Figure 6(c) presents the behavior of the implementationusing Micro-tasks. At the start of the period, the E-machinetask (peak at input line 10) releases tasksT1 andT2. TaskT1 consists of three Micro-tasksmt1, mt2, andmt3. Micro-taskmt1 starts (input line 8 changes to high) immediatelyafter the E-machine task has finished. Micro-taskmt1 fin-ishes its computation (input line 8 changes to low) andtriggers the E-machine task, which invokes the drivers thatcopy the result ofmt1 to the communication system. Thenit schedules Micro-taskmt2 (input line 8 changes to highagain). Concurrently with the execution ofmt2, the result ofmt1 is transmitted via the CAN bus (network frame on in-put line A1). Analogous the result ofmt2 is communicatedwhile mt3 executes. After its completion the E-machineschedules taskT2 (input line 9 changes to high). The re-sult of T2 are communicated over the bus after completionof its computation (input line 9 changes to low).

9. Conclusion

In distributed hard real-time systems, deterministic andefficient usage of shared communication media is of greatimportance. The timed computation model for real-timesystems implements value and time determinism. However,it favors value and time determinism over time efficiency. Inthis paper, we presented Micro-tasks for intertwined com-putation and communication. Micro-tasks allow for effi-cient and balanced load on the communication medium,providing the bus scheduler with more flexibility with re-spect to the time interval in which data can be transmitted.

We described the TDL infrastructure for distributedreal-time applications presenting TDL-Exec and TDL-Comm. TDL-Exec provides the E-machine that dis-patches and monitors the execution of tasks in real-time.TDL-Comm accommodates a communication systemfor real-time data transmission. We discussed the execu-tion of Micro-tasks in the TDL infrastructure and presentedan implementation for OSEK/Works and sTTCAN.

As future work, we will explore how to use Micro-tasksto impose certain communication patterns on the bus suchas predefined communication gaps.

References

[1] The new IEEE standard dictionary of electrical and electron-ics terms, IEEE standard, 1992.

[2] R. Alur and D.L.Dill. A Theory of Timed Automata.Theo-retical Computer Science, 126:183 – 235, 1994.

[3] R. Alur, L. Fix, and T. Henzinger. Event-clock automata: adeterminizable class of timed automata.Theor. Comput. Sci.,211(1-2):253–273, 1999.

[4] W. Bals. Hardware Manual OAKEMUF. Ing. Buro W. Ka-nis GmbH, Bruckenweg 2, D-82327 Tutzing, 2002.

[5] Bosch.CAN Specification, Version 2. Robert Bosch GmbH,1991.

[6] G. Buttazzo.Hard Real-Time Computing Systems. KluwerAcademic Publishers, 2000.

[7] D.-J. Chen and M. Sanfridson. Introduction to DistributedSystems for Real-Time Control. Technical Report TRITAMMK 1998:22, Department of MD, KTH, Sweden, 2000.

[8] S. Fischmeister and G. Menkhaus. Task Sequencing for Op-timizing the Computation Cycle in a Timed ComputationModel. In23rd DASC’04. IEEE Press, 2004.

[9] G. Franklin, D. Powell, and M. Workman.Digital Control ofDynamic Systems. Prentice Hall, 1997.

[10] FSMLab.Real-Time Linux, 2004.[11] T. Fuhrer, B. Muller, W. Dieterle, F. Hartwich, R. Hugel, and

M. Walther. Time Triggered Communications on CAN. InProceedings 7th International CAN Conference, 2000.

[12] T. A. Henzinger and C. Kirsch. The embedded machine: Pre-dictable, portable real-time code. InPLDI, 2002.

[13] C. Kirsch. Principles of Real-Time Programming.SpringerLNCS, 2491, 2002.

[14] H. Kopetz. TTP/A The fireworks protocol. InSAE Interna-tional Congress and Exposition, 1995.

[15] H. Kopetz. Real-time Systems: Design Principles for Dis-tributed Embedded Applications. Kluwer, 1997.

[16] H. Kopetz. The time-triggered model of computation.RTSS98, 1998.

[17] MathWorks, www.mathworks.com.Simulink.[18] G. Menkhaus, M. Holzmann, and S. Fischmeister. Time-

triggered Communication for Distributed Control Applica-tions in a Timed Computation Model. In23rd DASC’04.IEEE Press, 2004.

[19] Motorola. MPC555/556 User’s Manual, 2000.[20] J. Sifakis. Modeling Real-Time Systems-Challenges and

Work Directions. InEMSOFT, pages 373–389. Springer-Verlag, 2001.

[21] G. Stieglbauer and W. Pree. Visual and Interactive Develop-ment of Hard Real Time Code. InASWSD’04, 2004.

[22] J. Templ. TDL Specification and Report. Technical report,Computer Science, University of Salzburg, 2004.

[23] M. Torngren. Fundamentals of Implementing Real-TimeControl Applications in Distributed Computer Systems.Real-Time Systems, 14(3):219 – 250, 1998.

[24] M. Wernicke. New Design Methodology from Vector sim-plifies the Development of Distributed Systems.Vector In-formatik Press Release, 2003.