model-based design of the communication system in an

Model-Based Design of the Communication System in an Integrated Architecture

R. Obermaisser and B. HuberVienna University of Technology, Austriaemail:{ro,huberb}@vmars.tuwien.ac.at

Abstract

The DECOS integrated architecture supports the sharingof a single time-triggered network for multiple applicationsubsystems. As its communication infrastructure each ap-plication subsystem possesses a virtual network with guar-anteed temporal properties, which is realized on top of thephysical time-triggered network. This paper presents a so-lution for the model-based design of virtual networks in or-der to reduce development time and avoid design faults. Agraphical modeling tool enables system engineers to createa virtual network model that captures all relevant proper-ties for instantiating virtual networks in a specific applica-tion. The virtual network model forms the input to a codegenerator, the output of which can be deployed on the targetsystem together with the application code. The developmentprocess is exemplified in an automotive example, which ex-ploits virtual networks for application subsystems derivedfrom present-day automotive architectures.

1 Introduction

Integrated system architectures for embedded computersystems enable an efficient use of the available systemresources, because they permit the sharing of networksand node computers among multiple application subsys-tems. Integrated Modular Avionics (IMA) [1], Automo-tive Open System Architecture (AUTOSAR) [2], and thecross-domain Dependable Embedded Components and Sys-tems (DECOS) architecture [3] are examples of integratedsystem architectures.

In this paper, we focus on the DECOS integrated archi-tecture, which builds on top of a time-triggered networkthat is shared among the different application subsystemsvia so-called virtual networks. Each virtual network ex-ploits a statically defined part of the slots in the Time Divi-sion Multiple Access (TDMA) scheme of the time-triggerednetwork in order to provide a communication infrastructurewith guaranteed temporal properties for a particular appli-cation subsystem.

When building a system using the DECOS architecture,the construction of the virtual networks is one of the most

important design activities. The definition of the temporalproperties (e.g., bandwidth, latencies) can have a consider-able impact on the temporal behavior of an application sub-system. In addition, the virtual networks must be matchedwith the properties of the application subsystems, e.g., bydefining the communication topology or the interface datastructures between the application and the virtual network.Finally, the mapping of the virtual networks to the under-lying time-triggered network requires to solve a schedulingproblem. The slots in the TDMA scheme must be allocatedto the virtual networks, while satisfying the temporal prop-erties of the application (e.g., maximum message delays)and the resource constraints of the time-triggered network(e.g., limited message size of a single node).

It is obvious that the ad hoc construction of virtual net-works would be a laborious and error prone task. For thispurpose, we have devised a model-based development pro-cess for virtual networks in the DECOS architecture. Wehave defined a meta-model that guides designers in thespecification of virtual networks. A domain-specific toolbased on the Generic Modeling Environment (GME) [4]permits to instantiate the meta-model and to specify virtualnetworks for any specific application. Out of the resultingvirtual network model, a model transformator automaticallysynthesizes executable code, which implements the virtualnetworks when deployed on the target system based on theTime-Triggered Protocol (TTP) [5].

The paper is structured as follows. After a shortoverview of the integrated DECOS architecture in Sec-tion 2, virtual networks on top of a time-triggered physi-cal network will be described in Section 3. In particular,the implementation of virtual networks via multi-processornodes will be discussed. Section 4 is devoted to a modelthat provides all relevant information for the parameteri-zation of virtual networks for any specific application. InSection 5, we present how this virtual network specificationmodel forms the input to a scheduling tool that constructs atime-triggered communication schedule. In addition, a codegenerator automatically produces executable code for themulti-processor nodes. The exploitation of the presentedtool chain in an exemplary automotive application is the fo-cus of Section 6.

1

Node Computer 0

Slot 3Slot 2Slot 1Slot 0Slot 3Slot 2Slot 1

Physical Network

Job 1.1

Slot 0Mapping to

Underlying Time-Triggered Network

Appl. ComputerJob 1.1

Ethernet DriverVN Middleware

Appl. Computer


Basic Connector UnitTT Ethernet (100 Mbps)

Node Computer 1Appl. Computer


Appl. Computer





Appl. Computer





Appl. Computer



Job 1.2 Job 1.3

Physical Network

Job 2.1 Job 2.2 Job 2.3

Physical Network

Job 4.1 Job 4.2 Job 4.3

Physical Network

Job 3.1 Job 3.2 Job 3.3

Physical Network

Job 6.1 Job 6.2 Job 6.3

Physical Network

Job 5.1 Job 5.2 Job 5.3

Physical Network

Job 8.1 Job 8.2 Job 8.3

Physical Network

Job 7.1 Job 7.2 Job 7.3

Job 2.1Job 3.1 Job 5.1 Job 6.1Job 8.1 Job 1.2 Job 2.2Job 4.1 Job 5.2 Job 6.2Job 7.1

Job 1.3 Job 3.2Job 4.2 Job 5.3 Job 7.2Job 8.2 Job 2.3 Job 3.3Job 4.3 Job 6.3 Job 7.3Job 8.3

Physical Network with TDMA Scheme

Figure 1. Integration of Virtual Networks on a Time-Triggered Network

2 DECOS Architecture

The DECOS architecture [3] offers a framework forthe development of distributed embedded real-time systemsintegrating multiple application subsystems with differentlevels of criticality and different requirements concerningthe underlying platform. The DECOS architecture aims atoffering to system designers generic architectural services,which provide a validated stable baseline for the develop-ment of applications.

For the provision of application services at the controlledobject interface, the services of a real-time computer sys-tem are divided into a set of nearly-independent DistributedApplication Subsystems (DASs). Each DAS is further de-composed into smaller units calledjobs. A job is the basicunit of work and exploits avirtual network[6] in order toexchange messages with other jobs and to work towards acommon goal. Avirtual networkis the encapsulated com-munication system of a DAS. All communication activitiesof a virtual network are private to the DAS, i.e., transmis-sions and receptions of messages can only occur by jobs ofthe DAS unless a message is explicitly exported or importedby a gateway.

3 Virtual Networks

Federated system architectures employ multiple dis-tributed computer systems (also called clusters) for the re-alization of the application subsystems. For example, inthe automotive domain federated system architectures withseparate clusters for the car’s comfort domain, powertraindomain, and multimedia domain are prevalent today [7].Each cluster possesses a corresponding physical network(e.g., CAN [8]) and node computers that exclusively servea particular application subsystem. The latter design deci-sion has become known as the “1-Function – 1-ElectronicControl Unit (ECU) principle” [9, 10].

In the DECOS architecture, we support the coexistenceof multiple DASs on a shared distributed computer system,which possesses a single time-triggered physical network.

The DASs must thus share the physical network. For thispurpose, we realize so-calledvirtual networksas overlaynetworks.

Overlay networks based on a time-triggered communi-cation protocol are a solution for integrating different com-munication protocols by layering them on top of a time-triggered communication service. In the DECOS archi-tecture, both software and hardware mechanisms are inplace in order to construct virtual networks and ensurefor each virtual network predefined temporal properties(e.g., guaranteed bandwidths and latencies). The hardwaremechanisms comprise multi-processor nodes with physicalseparation of safety-critical and non safety-critical DASs.The software mechanisms include middleware for layeringevent-triggered and time-triggered virtual networks on topof a time-triggered protocol.

3.1 Virtual Networks on top of a Time-Triggered Network

The use of a time-triggered physical network fits to therequirements of safety-critical applications [11] that are theprimary target domain of the DECOS architecture. In atime-triggered physical network, each node computer hasa sending slot in the TDMA scheme that periodically recurswith the duration of the TDMA round. A node broadcasts amessage during its own slot, while receiving messages dur-ing the slots belonging to the other nodes of the cluster. Forthe construction of virtual networks, we reserve at designtime a part of a node’s slot for each virtual network a nodesends messages into. Figure 1 depicts such a subdivisionof TDMA slots. A federated system with six clusters ismapped onto an integrated system comprising a single clus-ter only. While each node in the federated system executesa single job, node computers in the integrated system canhost multiple jobs. Each of the statically defined parts of anode’s slot can be used by a job executing within the nodecomputer to send messages via the virtual network to otherjobs of the DAS.

While the physical network is always time-triggered, vir-

2

Port Port

Time-Triggered Protocol

Virtual Network Middleware

Job

Appl.specific Virtual Network Config. Module

Generic Virtual Network Middleware Module

TDMA-controlled Ethernet Driver

Job

TDMA-controlled Ethernet Driver

Generic Time-Triggered Protocol Implementation

Appl.specific Message Descriptor List

Application Computer(Safety-Critical)

TDMA-controlledEthernet (100 Mbps)

Basic Connector Unit: Interface to Physical

TT Network

Application Computer(Non Safety-Critical)

Figure 2. Integrated Node Computer

tual networks support both the time-triggered and event-triggered control paradigms due to their respective advan-tages [12]:

• Time-Triggered Virtual Networks. A time-triggeredvirtual network supports periodic transmissions ofstate messages at a priori specified global points intime. For each sender job, the time-triggered virtualnetwork keeps a memory element located at the senderconsistent with corresponding memory elements lo-cated at the receivers. The time-triggered virtual net-work thus realizes a set of shared variables, where eachshared variable is written by a single job and read byone or more jobs. Consistency of the values at thereceivers with the value at the sender is establishedwithin a known delay at a priori specified points intime.

In a time-triggered virtual network, a job at a particularnode overwrites its memory element. Via the node’sTDMA slot, the contents of the memory element arebroadcast at a statically specified send instant after thevalue of the memory element has been sampled. Thisoperational principle is also denoted as a temporal fire-wall [13], because its static control structure avoidscontrol flow between jobs. Thereby, a temporal fire-wall not only limits control error propagation, but alsosimplifies a timing analysis.

• Event-Triggered Virtual Networks. An event-triggered virtual network supports on-demand trans-mission requests from jobs at a priori unknown pointsin time. The event-triggered message transmissionrequests are sampled via the time-triggered network,thus starting the transmission after the next occurrenceof the node’s slot in the TDMA scheme. For eachjob in a node, outgoing messages are buffered in mes-sage queues until the respective node’s slot occurs inthe TDMA scheme. The queuing of messages han-dles bursts during which the bandwidth consumptionof outgoing messages exceeds the bandwidth that isavailable via the node’s slot.

3.2 Implementation of Virtual Networksat the Node-Level

For the realization of virtual networks at the node-level,we have implemented multi-processor nodes as depicted inFigure 2. Such a node contains three single board comput-ers denoted as the safety-critical application computer, thenon safety-critical application computer, and the basic con-nector unit.

The basic connector unitestablishes the node’s con-nection to the physical network by executing the Time-Triggered Protocol (TTP) [5]. The basic connector unitsends and receives messages at a priori known global pointsin time, which are specified by a static data structure definedat design time (called themessage descriptor list). The ac-tivities of the basic connector unit include the forwarding ofmessages received from the TTP network to the applicationcomputers, as well as the accepting of messages from theapplication computers to be forwarded to the TTP network.A TDMA-controlled Ethernet network with a bandwidth of100 Mbps enables these message exchanges between the ba-sic connector unit and the application computers.

The two application computers host the application soft-ware (i.e., the jobs of the different DASs) and middlewarefor the construction of virtual networks. In order to facil-itate modular certification [14], each application computeris dedicated to the execution of jobs of a particular criti-cality level. The safety-critical application computer (alsodenoted as safety-critical subsystem) hosts jobs of thoseDASs, which exhibit critical failure modes (e.g., classes Aand B according to [15]). All other jobs are allocated to thenon safety-critical application computer (i.e., non safety-critical subsystem of the overall system).

The reason for physically separating these two critical-ity levels via dedicated application computers is the re-quirement of effective architecture-supported error contain-ment between safety-critical and non safety-critical DASs(e.g., comfort DAS and steer-by-wire DAS in a car). Ina mixed-criticality system that shares nodes among safety-critical and non safety-critical jobs, a job of a non safety-critical DAS must not be able to cause a failure of a jobfrom a safety-critical DAS. Otherwise, the criticality levelof all jobs would be elevated to safety-critical.

3

3.2.1 Basic Connector Unit

The basic connector unit has been implemented with theTTP MPC855 single-board computer [16]. This singleboard computer is equipped with an MPC855 PowerPCfrom Freescale clocked with 80 MHz and provides a C2(AS8202) communication controller for TTP [17]. The C2communication controller provides a generic implementa-tion of TTP, which is parameterized with a message de-scriptor list that defines the global points in time at whichmessages are sent and received. The automatic generationof the message descriptor list in order to configure the ba-sic connector unit to a specific application will be discussedin Section 5. Tools derive the message descriptor list outof a model that formally defines the virtual networks of aDECOS cluster.

3.2.2 Application Computer

Each application computer is implemented on a Soekrisnet4521 embedded computer from Soekris Engineering1,which is based on a 133 MHz 486 class ElanSC520 pro-cessor from AMD. We deploy on all application computersthe real-time Linux variant LXRT/RTAI [18] extended by atime-triggered scheduler [19] as the operating system andexecution platform.

LXRT/RTAI tasks are used both for executing the jobscontaining the application code, as well as for the so-calledvirtual network middlewarethat establishes the ports usedby the jobs to access the virtual networks. The ports com-prise message buffers with outgoing (i.e., to be sent on thevirtual network) and incoming (i.e., received from the vir-tual network) messages. The realization of these messagebuffers depends on the employed control paradigm. For atime-triggered virtual network, the ports contain memoryelements with state messages that are overwritten whenevera more recent version arrives (port is calledstate port). Foran event-triggered virtual network, message queues supportexactly-once processing of messages with event informa-tion. In this case, the port is denoted as anevent port.

State Message with Port-Specific SegmentsState Variable

State PortState Variable

State PortState Variable

Event PortQueue

Event PortQueue

State Variable Packets Packets

fragmentationtransfer is consuming

1:1 copynon consuming

Forwarding of Message to Basic Connector Unit

Virtual Network Middleware

Figure 3. State Message with Port-SpecificSegments

The application computer periodically sends a state mes-sage to the basic connector unit for the dissemination on thetime-triggered physical network. At design time each port

1www.soekris.com

is assigned a port-specific segment within this state mes-sage (see Figure 3). For a state port, the virtual networkmiddleware simply copies the contents of the state vari-able stored at the port into the corresponding segment ofthe state message. For an event port, however, the virtualnetwork middleware needs to perform a conversion of con-trol paradigms. For this purpose, the virtual network mid-dleware performs a fragmentation of outgoing messages atevent ports into packets that fit into the segment of the statemessage.

In order to facilitate the adaptation of virtual network indifferent applications, the virtual network middleware con-sists of a generic part and an application-specific part. Thefirst part is ageneric virtual network middleware modulethat implements the algorithms for message fragmentation,routing, buffer management, error detection and recovery.The second part is anapplication-specific virtual networkconfiguration modulethat provides the algorithms withinthe generic virtual network middleware module with suf-ficient information to perform an instantiation for a particu-lar application. For example, the application-specific virtualnetwork configuration module defines which ports need tobe created and captures the addresses of the segments in thestate messages (cf. Figure 3).

Consequently, the virtual network middleware is genericin the sense that it can be parameterized to specific appli-cation requirements (e.g., number and types of ports). Amodel that captures all relevant information of this param-eterization on a high level of abstraction, as well as toolsfor the automatic generation of the application-specific vir-tual network configuration module will be presented in thefollowing sections.

4 Virtual Network Specification

The virtual network specification allows the developerto define the communication infrastructure of the integratedsystem on a high-level of abstraction that abstracts fromthe implementation details of the virtual network services.The virtual network specification structures the overall sys-tem into DASs, each consisting of jobs interconnected by arespective virtual network. The virtual network specifica-tion captures the requirements of the ports accessed by thejobs (e.g., handling of either event or state information), thecommunication topology (e.g., broadcast, multicast, point-to-point), and the temporal properties (i.e., latency, band-width). In addition, the virtual network specification definesthe physical location of ports by specifying for each job therespective node computer.

We start with the identification of relevant propertiesfrom two different view-points, namely from the point ofview of logical and physical system structuring. Subse-quently, these properties are formalized in a meta-model,which forms the basis for the tool-supported developmentof systems based on the DECOS architecture.

4

4.1 Logical VN Structuring

A virtual network interconnects the jobs of a DAS andprovides to each job a message-based interface consistingof one or moreports. A virtual network can be tailoredto the requirements of a specific application through theparameterization of the generic virtual network frameworkdescribed in Section 3. These application-specific require-ments comprise the following three parts:

• Port requirements. Depending on the informationsemantics [20, p. 31] of exchanged messages, mes-sages are classified into state messages and eventmessages. The virtual network specification takesthis message type into account by providing eventports (i.e., queues) for event messages and state ports(i.e., memory with update-in-place) for state messages.The specification of the port requirements includes in-formation concerning the queue length in case of eventport and the maximum length of messages transferredat the port. In addition, the data direction of each portis defined by distinguishing between input ports for thereception of messages from a virtual network and out-put ports for the transmission of a job’s messages.

• Communication topology. For each output port, thevirtual network specification lists the community ofjobs that receive the messages sent via the output port.Thereby, the virtual network specification controls thecommunication topology of the virtual network.

• Temporal requirements. The virtual network specifi-cation associates each virtual network with guaranteedtemporal properties, namely bandwidth requirements,and latency requirements.

4.2 Physical VN Structuring

In order to parameterize the virtual network service, thevirtual network specification must also support the cap-turing of the physical structuring. The allocation of jobsto node computers determines the physical location of theports provided by the physical network service, thereby re-quiring computational resources at the individual node com-puter (e.g., memory for queues of event ports, CPU time forthe virtual network middleware). In addition, the allocationof jobs to node computers affects the generation of the time-triggered communication schedule. The TDMA slot of anode computer must provide sufficient space for the trans-port of the messages from all output ports allocated to thenode computer, while satisfying the specified latency andbandwidth guarantees.

The modeling of the physical structuring, i.e., the alloca-tion of jobs and ports to node computers, is constrained bythe following requirements:

Figure 4. Simplified MetaGME Representa-tion of the VN Meta-Model

• Dependability requirements. Replicated jobs mustbe assigned to partitions of independent fault-containment regions [21].

• Resource constraints of nodes.The required compu-tational resources of the jobs allocated to a node com-puter must not exceed the available computational re-sources (e.g., CPU, memory) of the node.

• Resource constraints of physical time-triggerednetwork. The resources of the time-triggered physi-cal network constrain the number of virtual networksthat can be supported simultaneously and the temporalperformance of these virtual networks.

4.3 Virtual Network Meta-Model

For the model-based development process we have se-lected GME [22] for capturing virtual network specifica-tions. GME is a configurable, graphical framework forcreating domain-specific modeling environments, which isparameterized by a meta-model that contains all syntactic,semantic, and presentation information of the targeted do-main. A meta-model is a formal description of a particu-lar modeling environment and thus specifies the modelinglanguage, i.e., it describes the entities, its attributes, the re-lationships, and constraints of the resulting modeling en-vironment. The meta-model itself is formally specified us-ing MetaGME. We have exploited the basic MetaGME con-structsAtom, Model, Reference, Containment, andConnec-tion [4] for the specification of the virtual network meta-model. A simplified representation is depicted in Figure 4and explained in the following.

4.3.1 Modeling of Virtual Networks.

The root object of the virtual network specification isformed by the Clusterobject, which represents an integratedDECOS cluster. A Clustercontains further model objectsfor capturing the physical structuring of the DECOS clusterinto Nodes, for capturing the logical structuring into DASs,

5

and for specifying virtual networks (VNobject). A VNserves as the encapsulated communication system of a DAS.For each VNthe attributes description, criticality, type, andparadigm have to be specified.

4.3.2 Modeling of Logical VN Structuring

For each DAS integrated on the cluster, a DASmodel ob-ject capturing the jobs and their communication require-ments has to be specified. A DAScontains all jobs realizingthe service of the DAS, their ports, and the specification ofmessages that are disseminated over the associated virtualnetwork. The DASexploits a containment relationship toVNRef, which serves as a reference to a particular VNcon-tained in the Clustermodel.

Modeling of Port Requirements A link (expressed byLink and BCLink, respectively) groups a set of ports ofa job that belong to the same virtual network. Dependingon their data direction, we distinguish between input andoutput ports (InputPortand OutputPort, respectively). Bothtypes of port objects contain attributes for the specifica-tion of the paradigm (i.e., event-triggered or time-triggered)of the port and the length of an optional message queue.Each port is associated with exactly one Message, whichcomprises attributes for characterizing the size of the mes-sage (msglen), its physical location in the communicationcontroller (cniAddr), and configuration information for thepacket service realized in the virtual network middleware(reintOffset).

Modeling the Communication Topology Based on thecommunication topology we distinguish two types of links,namely Linkand BCLink. With the general type Link, afree specification of the communication topology (i.e. eitherpoint–to–point, multicast, or broadcast) is possible by inter-connecting the output port of one job to the input port ofone or multiple other jobs of the same DAS via a Message.By the use of BCLink, broadcast topology is implicitlyassumed, i.e., for modeling broadcast communication it issufficient to model the OutputPortsand the correspondingMessagesof each BCLink. For all BC Links associatedwith the same virtual network, the input ports for the re-ception of all broadcast messages are implicitly availablewithout the requirement of creating and connecting them tomessages. This way, the complexity of the resulting virtualnetwork specification as well as the workload required forspecifying broadcast communication topologies is signifi-cantly reduced.

Modeling of Temporal Requirements In addition to theattributes concerning the port requirements, a Messagecomprises attributes for the specification of its temporal re-quirements, namely period and latency. The bandwidth re-quirement of an entire virtual network can be calculated out

of the msglen attribute and the respective period of all mes-sages disseminated on the virtual network.

4.3.3 Modeling of Physical VN Structuring

The parametrization of the virtual network middleware ex-ploits information on the physical structuring of the DECOScluster. In order to cope with dependability requirements, ithas to be ensured that replicated jobs are assigned to differ-ent nodes, which form independent fault-containment re-gions [21]. Additionally, the assignment of jobs is alsodriven by the available computational resources of a node,and the maximum bandwidth of the physical time-triggerednetwork that is assigned to (or supported by) the communi-cation controller of a particular node. The Nodeobjects andits constituting AppComputerscapture the structuring of theDECOS cluster into nodes, each containing separate appli-cation computers for safety-critical and non safety-criticalapplication subsystems. The distribution of jobs is mod-eled by associating the jobs of each DASto exactly oneAppComputer.

5 Code Generation and Deployment

The purpose of the code generation and tool-supporteddeployment is the construction of configuration data struc-tures, which can be linked to the virtual network middle-ware in order to adapt it to a specific application. A secondgoal is the generation of a time-triggered communicationschedule that meets all temporal constraints as specified inthe virtual network model. This is realized by the tool-chaindepicted in Figure 5, whose constituting parts are explainedin the following.

VN Specification Capturing

(Domain-Specific Modeling Environment)

Virtual NetworkSpecification

(XML)

TT Comm. Sche-dule Generation

(TTP-Plan)

Message Descriptor List(C-Code, Binary)

VN Middleware Parameterization

(VN Configurator)

App.specific VN Config. Module

(C-Code)

InterchangeFormat

Figure 5. Tool-Chain

5.1 Capturing of VN Specification

For the automated generation of configuration data struc-tures the specification of virtual networks according to themeta-model has to be captured. For this purpose we havedeveloped a graphical, domain-specific modeling environ-ment based on GME. For capturing virtual network specifi-cations, we have parameterized GME with the virtual net-work meta-model. The resultant graphical modeling envi-ronment is depicted in Figure 6.

6

Figure 6. Graphical Domain-Specific Model-ing Environment

5.1.1 Compliance to the Meta-Model

The GME-based modeling environment provides severalmeans for ensuring the correctness of the model, i.e., itscompliance to the meta-model:

Pre-Selection of Parts: The part browser (cf. Figure 6 B)contains all model entities that can be used in the model ed-itor (cf. Figure 6 A) for the currently opened model. Thisway, it is ensured that containment relationships are not vi-olated by the user.

Validity of Associations: All associations between modelobjects are checked for their compliance to the meta-modelat the moment they are created. Any violations like anincorrect type of source or destination object (e.g., in anassociation between Job and Link) or improper multiplici-ties (e.g., a Messageis always associated with exactly oneOutputPort) are prevented by the editor and instantaneouslyreported to the user via the console window (cf. Figure 6 C).

Evaluation of Constraints: GME also permits the spec-ification of constraints based on Object Constraint Lan-guage (OCL), which exceed the expressiveness of the built-in MetaGME constraints. OCL is a formal language orig-inally developed for describing expressions on UML mod-els. OCL can be used to specify invariants that must holdfor the modeled system during the whole lifetime or in par-ticular states. In the virtual network meta-model OCL con-straints are utilized to ensure the uniqueness of particularattributes (like the id attribute of AppComputerand Node

objects) or the containment of messages within a single vir-tual network, i.e., that all links by which a particular mes-sage is sent or received are associated with the same virtualnetwork.

5.1.2 Interchange Format

The specification of the virtual networks is utilized on onehand to generate configuration data for the virtual networkmiddleware and on the other hand to generated the time-triggered communication schedule, which is realized bytwo distinct tools. Therefore, we have specified an inter-change format using Extensible Markup Language (XML)that serves as input for both tools. A graphical represen-tation of the XSD-schema that defines the syntax of validXML representations of virtual network specifications is il-lustrated in Figure 7.

VNConfig

Job

1 … njobName

subsystem

component

description

xs:string

xs:int

xs:int

xs:string

Link

1 … nlinkName

vnName

xs:string

xs:IDREF

Port

1 … nparadigm

dir

q_len

controlParadigm

dirType

xs:string

VN

1 … n

vnName

paradigm

description

criticality

type

xs:ID

controlParadigm

xs:string

criticality

vnType

Message

msgName

reintOffset

cniAddr

msg_len

xs:string

xs:int

xs:int

xs:int

period xs:int

latency xs:int

Figure 7. XSD Schema of Interchange Format

For the automatic generation of an XML file out of thegraphical virtual network specification we have developeda so-called GME model interpreter, which is integrated inthe graphical modeling environment (see Figure 6 D). Themodel interpreter is a Visual C++ based application thatutilizes the class hierarchy of the Builder Object Network(BON) [4] in order to access all modeling entities definedin the meta-model. The model interpreter traversers all en-tities of a particular virtual network specification and pro-duces the analogous XML elements for each entity.

5.2 Generation of Comm. Schedule

The generation of a time-triggered communicationschedule is required in order to configure the physical net-work for a specific application. For this purpose, we use thecommercially available tool TTP-Plan [23] with additionalimport and export filters. TTP-Plan is a scheduling tool thatcomputes at design time a time-triggered message scheduleout of a formal definition of messages with correspondingtemporal requirements (i.e., periods, latencies). The prob-lem of computing a feasible message schedule can be seenas the search for a correct solution in a search tree. A cor-rect solution needs to allocate all messages to the TDMAslots of the different rounds within the cluster cycle, while

7

both satisfying the temporal properties of the messages andconsidering constraints of the protocol implementation. Forexample, a schedule for the C2 TTP communication con-troller [17] must ensure that a frame broadcast within aspecific TDMA slot by a node does not contain more than240 bytes of data. Also, the available Communication Net-work Interface (CNI) memory of the C2 TTP communica-tion controller limits the number and length of messagesthat can be sent or received by a node.

The input for TTP-Plan is the virtual network specifi-cation in XML format. Using an import filter, TTP-Planacquires the definition of the nodes, the messages, and theassociations between nodes and messages.

The output of TTP-Plan is a message descriptor list,which can be loaded into the basic connector units thathave been described in Section 3.2.1. Thereby, the TDMAscheme of the physical network is configured according tothe application-specific requirements expressed in the vir-tual network specification. A second output of TTP-Plan arememory addresses in the CNI that denote where messagesare stored in the Dual Ported RAM (DPRAM) at the inter-face to the C2-TTP communication controller. The virtualnetwork middleware requires knowledge concerning theseaddresses for the establishment of the ports. For this pur-pose, the XML file with the virtual network specification isextended with these memory addresses trough the use of anoutput filter in TTP-Plan. This extension provides specificvalues for the attributecniAddr of elementmessage inthe virtual network specification (see Subsection 5.1)

5.3 Parameterization of VN Middleware

The virtual network configuratoris a tool based onXMLBeans2 that generates code for the parameterizationof the virtual network middleware. The output of thevirtual network configurator is C code compiling to theapplication-specific virtual network configuration module.When this software module is linked to the generic virtualnetwork middleware module, it results in a fully functionalvirtual network middleware for a specific application. Theinput of the virtual network configurator is the virtual net-work specification in XML format as described previously.

In the following we will explain the data structures usedfor the parameterization of the virtual network middleware,as well as their generation using the information containedin the virtual network specification. For each virtual net-work, developers can control the communication topology,the temporal properties (bandwidth and transmission laten-cies), the size of message buffers (message size and queuelengths), and the replication strategy (message transmissionredundantly on two channels or only on a single channel).

2xmlbeans.apache.org

5.3.1 Network Configuration Data Structure

The network configuration data structure encapsulates theconfiguration parameters for a particular virtual network.The complete configuration informationnw of the virtualnetwork service consists of one or more instances of thisdata structure. Each instance corresponds to an element oftype VN in the virtual network specification:

enum nw_paradigm { tt, et };

typedef struct nw_struct { char *name; enum nw_paradigm paradigm; int number_of_links; t_link *link[MAX_LINKS_PER_NW];} t_vn;

extern t_nw nw[];

The first element of the network structure is the name ofthe virtual network. The second element denotes the virtualnetwork’s control paradigm, which is either time-triggeredor event-triggered. The last entry of the network structureis an array of references to the links provided by the virtualnetwork. A link consists of a set of ports provided to a par-ticular job. Each job that sends or receives messages via avirtual network must possess a respective link that is refer-enced in the virtual network configuration data structure.

5.3.2 Link Configuration Data Structure

The link configuration data structure captures informationabout a job’s link to a particular virtual network. Thisdata structure is constructed from the element Linkinthe virtual network specification. After a reference to ajob configuration data structure, the elementsnode andsubsystem denote the physical location of the link withinthe DECOS cluster. node is the numerical identifica-tion of the node hosting the link and the respective job.subsystem discriminates between the links of the safety-critical (subsystem = 0 ) and non safety-critical nodesubsystems (subsystem = 1 ). In addition, the link con-figuration data structure contains an array of the ports pro-vided via the link.

typedef struct link_struct { t_job *job; // the job the link belongs to unsigned short node; // location of link (node) unsigned short subsystem; // location of link (subsys.) int number_of_ports; // number of ports in the link t_port port[]; // port config. data structures} t_link;

5.3.3 Port Configuration Data Structure

A port is a message interface, where the term message de-notes a category of frames that are intended for the ex-change through the communication system and character-ized by common syntactic, temporal and semantic proper-ties. The port configuration data structure captures the rele-vant properties of a port with respect to the virtual network

8

service. Each instance of the port configuration data struc-ture belongs to corresponding elements of type PortandMessagein the virtual network specification.

enum direction { in, out };

typedef struct port_struct { unsigned char q_len; // ==1 for TT comm., >=1 for ET unsigned char msg_len; // max. msg length in bytes enum direction dir; // data direction enum vn_paradigm paradigm; // ET or TT gt64 d_acc; // temporal accuracy interval t_msg_descr *msg; // message descriptor struct vn_struct *nw; // the network the port belongs to} t_port;

A port is associated with a message buffer that can storea maximum number ofq len messages, each having a sizebetween 0 andmsg len bytes. In case of an input port (el-ementdir is equal toin ), the messages buffer stores mes-sages that have been received via the virtual network andare waiting to be fetched by the job. For an output port (de-noted by the valueout of dir ), the message buffer storesmessages passed to the communication system by the appli-cation for transmission via the virtual network.

The element paradigm discriminates between event andstate ports. State ports serve messages with state infor-mation. The message buffer stores exactly one messageinstance (i.e.,q len is 1) that is overwritten whenever anew instance of the message arrives (i.e., update-in-place).Event ports support messages with event information andpossess a buffer storing more than one message instance(i.e., q len > 1). For a state port, the elementd acc de-notes the length of the temporal accuracy interval [20]. Thelength of the temporal accuracy interval is the admissibledelay between the observation of a real-time entity and theuse of the real-time image.

typedef struct msg_descr_struct { unsigned int id; t_job *job; t_vn_descr *nw; cni_dta cni;} t_msg_descr;

// CNI memory area dedicated to a state message // which is updated atomically during a particular slot typedef struct cni_dta_struct { unsigned short node; unsigned short subsystem; // 0 == SC, 1 == NSC unsigned int reintegr_offset; unsigned int data_offset; // CNI address (relative) unsigned int len; // length of data written unsigned long update_offset; // update instant relative to } cni_dta; // TDMA-rnd. start

The next element of the port configuration data struc-ture is a reference to a message descriptor. In ad-dition to a unique message identification and refer-ences to job and network descriptors, the message de-scriptor provides information for mapping the messageto the underlying time-triggered communication service.CNI.node and CNI.subsystem identify a slot in theunderlying time-triggered communication schedule, whichis provided by the basic connector unit of the node.CNI.reintegr offset is a relative address within thestate message broadcast via the subsystem slot and pointsto a state variable used during reintegration and startup.This state variable enables a reintegrating node to regain

Figure 8. Automotive Example

frame synchronization in event-triggered virtual networks.CNI.data offset denotes the location of the data byteswithin the state message broadcast via the subsystem slot.The number of data bytes available for the transmissionof the message isCNI.len . CNI.update offset de-notes the length of the time interval between the point intime of the TDMA round start and the point in time at whichthe memory element at the BCU interface is updated withthe state information from the subsystem slot.

The last element of the port configuration data structureis a reference to the network configuration data structure towhich the port belongs to.

6 Exemplary Application

In order to demonstrate the configuration of the virtualnetworks in the prototype implementation, we have mod-eled an exemplary system containing both safety-criticaland non safety-critical DASs. The exemplary system is asimplified automotive example in order to improve under-standability and demonstrate the capabilities of the virtualnetworks. In the scope of the prototype implementation, wehave performed the configuration of the virtual networks forthis example, i.e., we have not implemented the correspond-ing application functionality (e.g., application code withinthe jobs, specific sensors and actuators).

The exemplary system, which contains a total numberof 5 DASs, is depicted in Figure 8. The system possessesone safety-critical DAS (drive-by-wire DAS) and four nonsafety-critical ones (comfort DAS, lights DAS, diagnosticDAS, and navigation DAS).

9

Figure 8 also shows the allocation of the jobs to thefive nodes of the prototype cluster. Each node providestwo application computers, namely a safety-critical and nonsafety-critical application computer. The jobs of the drive-by-wire DAS are allocated to the safety-critical applicationcomputers, while the non safety-critical application com-puters host the jobs of the other four DASs.

The drive-by-wire DAS is responsible for steer- andbrake-by-wire functionality. The communication infras-tructure of the drive-by-wire DAS is a time-triggered virtualnetwork due to the respective benefits such as improved pre-dictability, determinism, and fault isolation [24].

The comfort DAS comprises the body electronics of thepassenger compartment. The functionality of this DASincludes the control of the doors (e.g., mirrors, windowlifters), the sliding roof, the trunk lid, the climate control,and the lighting of the passenger compartment. The comfortDAS uses an event-triggered virtual network as its commu-nication infrastructure.

The lights DAS controls the indicator lights, the rearlights of the car, as well as the position of the adaptive for-ward lighting. In analogy to the comfort DAS, the messageexchanges of the lights DAS are also handled by an event-triggered virtual network.

In order to support online diagnosis (e.g., as proposedin [25]), an event-triggered virtual network dedicated to theexchange of diagnostic message is available. The corre-sponding diagnostic DAS is responsible for the analysis ofdiagnostic message, e.g., by by computing a trust level foreach node, that acts as the foundation for the decision of themaintenance engineer on the question whether to perform areplacement.

The communication infrastructure of the navigationDAS is a time-triggered virtual network, because the GPSreceiver performs periodic exchanges of messages with po-sitional information and the external GPS time.

6.1 Specification of Virtual Networks

The first step for the model-based design of virtual net-works is the formal representation of the virtual networkspecification. On the basis of the introduced exemplary au-tomotive application, we describe the exploitation of thegraphical modeling environment for capturing the virtualnetwork specification.

The modeling process starts with the specification of thenodes of the cluster, the DASs and their networks (illus-trated in Figure 9(a)).

In the following, we focus on the drive–by–wire DAS toexplain the details of the virtual network specification. Bythe parametrization, the virtual networks are tailored to therequirements of a specific application. These application-specific requirements (i.e. port requirements, communica-tion topology, and temporal requirements) are captured bythe DAS-specific part of the virtual network model. An

(a) Cluster Specification

(b) Drive–by–Wire DAS Specification

(c) Job to Node Assignment

Figure 9. Model of Exemplary Automotive Ap-plication

excerpt of an exemplary specification of the communica-tion topology can be seen in Figure 9(b). The depictedspecification represents three jobs of the drive–by–wireDAS, namelyjob0 bywire, job4 bywire, andjob12 bywire.job0 bywire and job4 bywire use a broadcast link towardsthe virtual networkvn bywire. With these broadcast links itis implicitly expressed that those jobs receive all messagesdisseminated on the virtual network. On the other hand,job12 bywire accesses the virtual network via a genericlink, i.e., all messages that have to be received by this jobare explicitly modeled.

Besides the communication topology, port requirementsand temporal requirements have to be specified in the DAS-specific part of the virtual network model. For each port, itsdirection, queue length, and paradigm is specified. For in-stanceLink0 VN BYWIREcomprises a time-triggered out-put port with a queue size of one (i.e. no queuing for time-triggered messages). The port characteristics are specifiedby the attributes of the port atom object within each link.In order to model the temporal requirements of the virtualnetwork, for each message the attributes period and latencyhave to be specified. For example all messages dissemi-nated over the virtual networkvn bywire have a specifiedperiod of 10 ms, which is identified in [26] as suitable for

10

by–wire applications.For the generation of the configuration data structures

of the virtual network middleware, the physical allocationof jobs to nodes is important. Figure 9(c) shows the assign-ment of jobs of the drive–by–wire DAS to the safety-criticalapplication computer of a particular node.

By the invocation of the model-interpreter, the resultingvirtual network specification is automatically transformedinto the XML interchange format for further processing.

6.2 Schedule Generation

With the information contained in the exemplary virtualnetwork specification, the scheduling tool TTP-Plan com-putes a time-triggered communication schedule. Each out-put port results in a frame that needs to be scheduled byTTP-Plan. For a state port, this frame has the size and pe-riod exactly as specified in the virtual network specification.For an event port, the frame’s period is equal to the dura-tion of a TDMA round, while the frame size depends onthe required bandwidth (event port bandwidth= number ofbytes in frame/ TDMA round duration). The duration ofthe TDMA round is determined by the specified maximummessage transmission latencies. In the automotive exam-ple, the messages of the by-wire DAS exhibit the shortestmessage periods (10 ms), thus determining the duration of aTDMA round in the resulting communication schedule.

After all frames have been identified, TTP-Plan com-bines all frames of a node into a single time-triggered TTP-message with multiple data segments. TTP-Plan, then, gen-erates the message descriptor list to be flashed into the C2communication controller. In addition, this process yieldsthe memory addresses of the messages in the CNI mem-ory, which allows to extend the virtual network specifica-tion with this information (attributecniAddr of elementmessage ).

6.3 Automatic Generation of Configura-tion Data Structures

From the virtual network specification in XML format,the virtual network configurator automatically generatescode for the virtual network configuration module. The re-spective C data structures, which have been introduced inSubsection 5.3, will be exemplified in the following using aselected link of the by-wire DAS.

t_link Link8_VN_BYWIRE = { job:&job8_bywire, node:4, subsystem:1, number_of_ports:10, port:{ {q_len:1, msg_len:4, dir:in, paradigm:tt, msg:&msg0_bywire}, {q_len:1, msg_len:4, dir:in, paradigm:tt, msg:&msg1_bywire}, […] }};

The exemplary code given in the listing above, describesa link calledLink8 VN BYWIRE. The first element in thedata structure identifies the job to which this link belongsto (job8 bywire in the particular case). Afterwards, the

physical location of the link is described (i.e., safety-criticalsubsystem on node 4). The exemplary listing defines twoinput ports, each comprising a buffer holding a single mes-sage with a length of four bytes. The last element in the portconfiguration data structure denotes the message the port isassociated with. This element is a reference to a messagedescriptor. An exemplary message descriptor is shown inthe following listing.

t_msg_descr msg8_bywire = {0,&job8_bywire, cni_dta:{4,1,0x0300,0x01F0,4,0), &vn_bywire};

The message descriptor starts with a unique messageidentification and a back reference to the job that is respon-sible for generating the message. In addition, the elementcni dta in the message descriptor provides informationfor mapping the message to the underlying time-triggerednetwork (e.g., offset of data in CNI). The last element inthe message descriptor is a reference to the virtual networkdescriptor, which specifies the virtual network to which themessage belongs.

t_vn vn[] = {[…]{ name:"vn_bywire",paradigm:tt,number_of_links:10, link:{ &Link0_VN_BYWIRE, &Link1_VN_BYWIRE, […] }},[…]}

The remaining configuration code contains an array ofvirtual network configuration data structures. Each of theconfiguration data structures describes a specific virtual net-work, e.g., by specifying the control paradigm (eitheret ortt ) and providing a list of references to all links providedby the virtual network.

7 Conclusion

This paper provides a solution for the tool-supported im-plementation of an integrated time-triggered computer sys-tem according to a two-level development methodology.Following a divide-and-conquer strategy the problem ofdesigning an integrated embedded computer system is ad-dressed at two distinct levels: system-level and component-level. At thesystem-level, the overall system is divided intoDASs each consisting of a set jobs that are interconnectedby a virtual network. In contrast to the system-level, thecomponent-leveldeals with the implementation of individ-ual jobs. In the implementation of a job, developers canuse the previously defined ports as a baseline in order toexchange messages with the other jobs of the DAS.

The realization of the virtual networks occurs throughthe so-calledvirtual network middleware, which is de-ployed within each node computer of the integrated com-puter system. The virtual network middleware provides

11

a generic solution for implementing for each DAS a pri-vate communication channel on top of an underlying time-triggered physical network. The virtual network middle-ware is generic, because it can be configured to the require-ments of individual applications. As part of this configura-tion, the ports forming the interface between the jobs andthe virtual networks are defined and the respective tempo-ral properties (e.g., latencies, bandwidths) for the messagesexchanged via the ports are captured.

To support system engineers in the design activities at thesystem-level, we have devised a meta-model for the spec-ification of virtual networks and realized a graphical toolthat assists in the instantiation of the meta-model. This toolproduces a formal specification of a system’s virtual net-works, which can be used as an input for further configura-tion tools supporting the automatic generation of a suitabletime-triggered message schedule and the parameterizationof the generic virtual network middleware.

Using the presented tools, a system engineer can modelvirtual networks on a high level of abstraction, while au-tomating the creation of a time-triggered communicationschedule and the generation of configuration structures inthe respective implementation language (e.g., C).

A major benefit of the presented solution is the re-duced development time of an integrated embedded systemby automating sub-tasks in the design at the system-level.Thereby, we facilitate the meeting of requirements concern-ing shortening time to market. Furthermore, the modelingof the communication infrastructure of an integrated com-puter system hides unnecessary details (e.g., consistencyof the configuration data structures on different nodes),thereby the mental effort for system engineers is reducedand design faults are tackled.

Acknowledgments

This work has been supported in part by the EuropeanIST project ARTIST2 under project No. IST-004527 andthe European IST project DECOS under project No. IST-511764.

References

[1] Aeronautical Radio, Inc., 2551 Riva Road, Annapo-lis, Maryland 21401.ARINC Specification 651: De-sign Guide for Integrated Modular Avionics, Novem-ber 1991.

[2] H. Heinecke et al. AUTomotive Open System AR-chitecture - An Industry-Wide Initiative to Man-age the Complexity of Emerging Automotive E/E-Architectures. InProc. of the Convergence Inter-national Congress & Exposition On TransportationElectronics. SAE, October 2004. 2004-21-0042.

[3] R. Obermaisser, P. Peti, B. Huber, and C. El Sal-loum. DECOS: An integrated time-triggered architec-ture.e&i journal (journal of the Austrian professionalinstitution for electrical and information engineering),March 2006.

[4] Institute for Software Integrated Systems, VanderbiltUniversity. GME 5 – User’s Manual, Version 5.0,2005.

[5] H. Kopetz and G. Gr̈unsteidl. TTP – A protocol forfault-tolerant real-time systems.Computer, 27(1):14–23, January 1994.

[6] Roman Obermaisser and Philipp Peti. Virtual Net-works in an Integrated Time-Triggered Architecture.In Proc. of IEEE International Workshop on Object-Oriented Real-Time Dependable Systems, Jan. 2005.

[7] G. Leen and D. Heffernan. Expanding automotiveelectronic systems.Computer, 35(1):88–93, January2002.

[8] Robert Bosch Gmbh, Stuttgart, Germany.CAN Speci-fication, Version 2.0, 1991.

[9] B. Bouyssounouse and J. Sifakis, editors.EmbeddedSystems Design. Springer Verlag, 2005.

[10] P. Giusto et al. Automotive virtual integration plat-forms: why’s, what’s, and how’s. InProc. of theIEEE International Conference on Computer Design:VLSI in Computers and Processors, pages 370–378,September 2002.

[11] J. Rushby. Bus architectures for safety-critical embed-ded systems. InProc. of the 1st Workshop on Embed-ded Software, October 2001.

[12] R. Obermaisser.Event-Triggered and Time-TriggeredControl Paradigms – An Integrated Architecture.Real-Time Systems Series. Kluwer Academic Pub-lishers, November 2004.

[13] H. Kopetz and R. Nossal. Temporal firewalls in largedistributed real-time systems.Proc. of the 6th IEEEWorkshop on Future Trends of Distributed ComputingSystems, 1997.

[14] J. Rushby. Modular certification. Technical report,SRI International, September 2001.

[15] Radio Technical Commission for Aeronautics, Inc.(RTCA), Washington, DC.DO-178B: Software Con-siderations in Airborne Systems and Equipment Certi-fication, December 1992.

[16] TTTech Computertechnik AG.TTP Monitoring Node– A TTP Development Board for the Time-TriggeredArchitecture, March 2002.

12

[17] TTTech Computertechnik AG. TTP/C ControllerC2 Controller-Host Interface Description Document,Protocol Version 2.1, November 2002.

[18] D. Beal et al. RTAI: Real-Time Application Interface.Linux Journal, April 2000.

[19] B. Huber, P. Peti, R. Obermaisser, and C. El Salloum.Using RTAI/LXRT for partitioning in a prototype im-plementation of the DECOS architecture. InProc. ofthe Third International Workshop on Intelligent Solu-tions in Embedded Systems, May 2005.

[20] H. Kopetz. Real-Time Systems, Design Principlesfor Distributed Embedded Applications. Kluwer Aca-demic Publishers, Boston, Dordrecht, London, 1997.

[21] R. Obermaisser and P. Peti. A fault hypothesis for inte-grated architectures. InProc. of the 4th InternationalWorkshop on Intelligent Solutions in Embedded Sys-tems, June 2006.

[22] A. Ledeczi et al. The Generic Modeling Environment.In Proc. of Workshop on Intelligent Signal Processing,May 2001.

[23] TTTech Computertechnik AG.TTPPlan The ClusterDesign Tool for the Time-Triggered Protocol TTP/C,April 2002.

[24] J. Rushby. A comparison of bus architectures forsafety-critical embedded systems. Technical report,SRI International, 2001.

[25] P. Peti and R. Obermaisser. A diagnostic frame-work for integrated time-triggered architectures. InProc. of the 9th IEEE International Symposiumon Object-oriented Real-time distributed Computing,April 2006.

[26] C. Wilwert, Y. Song, F. Simonot-Lion, and T. Clment.Evaluating quality of service and behavioral reliabil-ity of steer-by-wire systems. InProc. of 9th IEEEInternational Conference on Emerging Technologiesand Factory Automation, September 2003.

13

model-based design of the communication system in an

Documents