Rapid Prototyping of Automotive Communication Protocols

Barry OrsquoRourke Cadence Design Systems Inc Methodology Services Group

Livingston Scotland UK orourkecadencecom

Thilo Demmeler Bayerische Motoren Werke AG

Technology Office Palo Alto CA 94301 USA ThiloDemmeler bmw de

Abstract

Modern automotive applications such as X-by- Wire are implemented over distributed architectures that include several electronic control units (ECUs) communicating via one or more communication protocols such as CAN (Con- troller Area Network) and 7TP (Time Triggered Protocol) over network broadcast buses In these scenarios of in- creasing complexity it is paramount for the designer to try different implementations quickly in terms of SW distribu- tion and communication protocols so as to satisfy the re- quirements of cost real time and safety In this paper we present a novel way of rapidly prototyping communication protocols that ure typical of the automotive domain An implementation of the key- enabler of the rapid-prototyping framework the Universal Communication model (UCM) is described

1 Introduction

Automotive applications such as X-By- Wire for steering and braking [5] [6] have introduced a new dimension in the tra- ditional design scenarios that is their distributed nature - they are implemented by a network of (a subset of) ECUs that are located in the car chassis and communicate via broadcast network buses Different kinds of communication protocols with their own specific strengths have been intro- duced in the past for example CAN [ l ] or ByteFlight [ 2 ] Other protocols such as TTP [3] [4] are going to be intro- duced with the goal of providing more dependable and fault tolerant networks enabling the step towards X-by-Wire technologies The objective of the automotive system designer is to dis- tribute the different application functions onto the different

Paolo Giusto Cadence Design Systems Inc

Systems and Functional Verification Group San Jose CA 95 103 USA

giusto cadencecom

Steve Wisniewski Cadence Design Systems Inc Methodology Services Group

Livingston Scotland UK s tevew cadence com

ECUs (in the X-by-Wire scenarios the designer is dealing with a pool of such functions [17]) The goal is to find the optimal trade-off between function distribution and com- munication performance over the bus while satisfying the real-time requirements with a feasible low-cost and safe implementation In fact while a certain function distribution may optimize the ECUsrsquo loads (potentially reducing the number of required ECUs) i t can increase the communica- tion time because the modules that implement the functions are run on different ECUs In fact a message sent from one module to the other ones needs to be broadcast (through the network bus) from one ECU to a set of other ECUs onto which the receiving modules are running while in the for- mer distribution the communication was purely SW to SW on the same ECU The reduction of the production costs is only possible via a low cost design process that validates design choices (aimed to find the near-to-optimal distribution) In the typical automotive development process a solution is validated tested and then calibrated directly in the car The results are very accurate however the turnaround time is too long - the validation can only be done when the prototype is ready A methodology and integrated tool set for rapid prototyping of systems via programmable boards from high level speci- fications has been proposed in the past [16] The design flow starts at the specification level The designer enters the high level specification of the functionality and assigns HW or SW implementations to abstract behaviors The prototype for the system is then quickly generated via synthesis Run- ning HW and SW concurrently on the board validates the solution The disadvantage of this proposal is that the sup- ported design style is top-down only Intellectual Property (IP) import mechanisms [ l l ] are signers cannot reuse existing IPrsquos

not available hence de-

64 1074-600501 S 1000 0 200 1 IEEE

Current automated software design tools such as Ascet-SD [12] help to optimize the SW scheduling on a single ECU only but do not provide support for performance modeling of distributed applications at the virtual level The design exploration of the distributed system is only possible later in the design flow The solution found is obviously sub- optimal overly conservative and therefore more expensive We use the Virtual Component CO-Design (VCC) environ- ment [ 113 to model the entire distributed system (ECUs pool of functions and communication protocols) at a level of abstraction that provides acceptable accuracy in the re- sults while allowing quick turnaround time therefore pro- viding an alternative solution to the existing per-ECU tooVmethodologies With our solution we support two methodologies

virtual rapid prototyping of not yet available commu- nication protocols over a broadcast bus (time-triggered event-driven mixed) modeled with the Universal Communication Model (UCM) [ 141 the key-enabler to performance modeling of such protocols virtual and physical prototyping of applications with off-the-shelf protocols

In this paper we focus on the first methodology Virtual rapid prototyping of applications is described in [ 14][8] Once the assessment is made at the virtual level physical prototyping can take place with off-the-shelf implementa- tions of the communication protocol models that were used at the virtual levcl Physical prototyping allows one to work at close-to-real time speed at the price of doing so with off- the-shelf existing communication protocols only The auto- mation of such a flow is left for future developments The successful deployment of the flowmethodology depends upon the development of automotive specific libraries such as event [ 151 and time-triggered communication protocol models [ 141 This paper is organized as follows Section 2 describes our concept of virtual integration platform Section 3 describes the UCM Section 4 describes an efficient implementation of the UCM within the VCC environment Section 5 de- scribes a use model for rapid prototyping of communication protocols Section 6 concludes the paper with some prelimi- nary results and ideas for future development

2 A virtual integration platform for rapid prototyping of automotive systems

The development process in the automotive domain starts with the analysis phase where a functional network is de- veloped and proceeds to the specification phase where algorithms for the functional components are defined The system design phase determines the distribution of the functionality onto an architectural network In the next

phase a composition of functional components is imple- mented onto the target hardware and finally the system is calibrated in the car [ 101 The proposed virtual integration platform is built within the Virtual Component CO-Design (VCC) tool set as shown in Figure 1 The basic concept [ 131 is to have a behavioral model of the system that runs in zero time (software execu- tion time and communication delays) which is separated and independent from an architectural model that represents an implementation variant By mapping the imported ASCET-SD modules onto the architectural computational components (CPUs Asia) and the zero-time communica- tions onto communication protocol models a specific sys- tem partitioning is chosen This can be also termed as a de- sign refinement step where the zero-time abstract communi- cations are refined in terms of real communication protocols and the abstract behaviors are assigned a real HW or SW implementation The zero-time models and communications are automatically annotated by VCC with performance models that include close-to-real software execution time and communication delays (virtual prototype) Thus a step that in previous methodologies requires costly manual inter- vention is totally automated After performance simulations provide confidence in the chosen refinemenVpartitioning VCC exports the model running on each ECU back to As- cet-SD This can then be used to automatically generate the software for each ECU and hence produce physical proto- type of the whole system

_ll-

Figure 1 The VCC Virtual Integration Platform

3 The Universal Communication Model

This section will describe briefly the UCM (for more details the interested reader is referred to [ 141) The key idea of the UCM is to provide an open framework for modeling the performance of two basic automotive communication protocols (time-triggered event-driven) and the performance of protocols that are not yet available

The UCM is used in a refinement process At the beginning of the exploration stage the designer starts with the UCM configured to run in a pure event-driven mode - less expen- sive than the time-triggered case The refinement to the dif- ferent kinds of protocols (existing ones or not) is done step by step by changing the UCM parameters Once the UCM settings match a specific protocol we expect accurate per- formance results to be obtained that allow qualitative as- sessments at least for the system running properly under no fault conditions Although VCC provides such a capability we do not model the delays of HWSW interrupts (ie pulses coming from the crankshaft) In fact they are negli- gible with respect to the overall system performance domi- nated by the latencies of framesrsquo sent over the bus - in the UCM a frame is a set of messages the message exchange modeled with VCC behavioral memories (BM)[ 141 Hence we have focused on the communications that involve BMrsquos The mapping of the zero-time BM accesses (reads and writes) onto communication patterns (that model different communication delays providing the performance model of the communication itself) is performed automatically by VCC In fact depending on the VCC mapping of Ascet-SD modules onto architectural resources [SI[ 141 the same functional data

UCM IO Port

Figure 2 The VCC ECU model exchange in the behavior may take different communication delays depending whether the modules are mapped to dif- ferent ECUs or to the same one In the latter case the com- munication would be purely SW to SW on the same ECU In the former case a bus is involved and therefore the mod- eled delay must be different These and other issues with proposed solutions are discussed in detail in [ 141

4 Implementation of the UCM

The implementation of the UCM has been divided in two subsequent phases In the first one (completed) we support

Event driven (asynchronous) protocols

Execution of at least two different threads at any time eg one thread for an applicationhost and one for a bus controllerhus arbiter

Broadcast communications

Assignment of priorities to each and every telegramrsquo

Telegram arbitration that gives access to the highest priority telegram available across all system nodes - the performance model associated with this arbitration is linear multiple of the number of nodes in the system times some user-specified value

We enable each system node to read the state of the bus (busy or free [14]) In the second phase we are planning to support

Time-triggered (synchronous) protocols

Bus redundancy (two similar or different buses con- nected to each ECU)

Error injection to allow simulation of real-life faulty scenarios

Slots with transmission of one or more frames

Modeling of functionality and performance associated with the addition of frame overhead properties eg CRCrsquos

Enhanced arbitration schemes and protocols

User-specified inter-frame gaps

A Communications Matrix to allow users to specify telegram priorities message t o telegram assignments message to frame assignments frame to slot assign- ments and Slot Sizes

Start-up andor initialization modes

We will also enable the user to specify where the bus- related functionality is performed (the CPU or the Bus Controller) by means of parameters

The UCM is implemented using VCCrsquos architectural serv- ices When modeling a network system these services ef- fectively form a function stack where each layer models the delay added to the transmission time of a frame without implementing the real communication protocol Figure 2 illustrates a model of an ECU in VCC Figure 3 shows the functional components of the service stack as they would be used in the transmission of data from an application running on one ECU to an application running on some other ECU

e The Device Driver layer is a software service that per- forms most of the tasks involved with message and frame assembly It runs on the RTOS on the CPU and

Unless specified differently the term frame is used for the generic data sent over the bus rsquo A telegram is a set o f messages in the CAN protocol

66

is subject to the delays caused by task switching the number of instructions required etc

The Bus Controller hardware service consists of two other services a Bus Master that drives data onto the bus when the ECU is transmitting and a Bus Slave that listens to the data on the bus and passes on frames that are addressed to the ECU on which it resides The Bus Master also contains the functionality to complete the packing of frames and queuing of the packets for transmission over the Bus service

The UCM Bus service provides delay information for the actual transmission of data through the communi- cation medium It also runs the actual protocol for the bus which communicates to the Bus Controllers whether the bus is busy which time slot is currently being broadcast etc Most importantly it performs all global bus arbitration functions for the event-driven configuration

Behavior FCFS FCFS

Write Master Bus

Arbiter Adapter

BM Write BM Read

ECU ECU Device Device Driver Driver

I t v

FCFS Bus Ctrl

Slave Adapter Memory

Figure 3 The service stack

I + 1 Arb Delay 4 Grant

Send Return

b

Done

Release

The actual protocol is spread out over the bus controller (activation policy) and the bus arbiter (communication cy- cle) This allows to separate the activation policy of each frame (event-driven or time triggered) from the actual communication cycle (static vs dynamic)[ 141 therefore providing the framework for the exploration of new com- munication protocols

Snoop Delay

Write

Zero Delay [

Control1er

L

UCM UCM UCM Master Bus State Slave Controller Adapter Arbiter Machine Adapter Memory r] Bus

Figure 4 ECU local communication

I b Arb RequesL Request

I Delay Return

Grant OK

Snoop Delay

Write

Done

Send

4 I Frame

Bus bps

State

Delav

+

Zero Delay

Figure 5 inter ECU communication

Figures 4 and 5 show the message sequence charts (MSC) of the sequence of events being passed between the func- tional components of the VCC service stack along with the modeled delays The first MSC represents the thread of execution from the mapped behavior to the bus controller local memory In the second MSC the broadcast communi- cation is shown

67

5 Use model for rapid prototyping of communication protocols configuration and operation of the UCM

APP

The user can specify the number of different frames that each ECU sends on the bus via an array of frame data-types that define all the properties required for the UCM For example an ECU sends two frames The first one is a Slot frame which is sent once every communication cycle [ 141 at an offset of 1 millisecond and consists of two BMrsquos with a packaging overhead of 8 bits The second frame is a single BM Telegram triggered every time the BM is written The frame has an overhead of 24 bits and priority 2 The user can specify the bus arbiter parameters as well For example a particular system transmits at 1 Mbps and the communi- cation cycle repeats every half-second There is a single static part of 100 ms starting at the beginning of the cycle and a dynamic part of 400 milliseconds (arbitration) The minimum time allowed between transmitted frames is 02 milliseconds and the Arbitration Factor value defines a linear relationship between the number of nodes racing for control of the bus and how long the arbitration phase of a telegram communication lasts for

I I I I

I I I I APP Send v

Mem Bus Ctrl Master v

Receive

C v E-) Bus Ctrl Mem n W Slave + E

Figure 6 STTF

The operation of the UCM is driven by two sets of entities that are independent of each other The behavioral models of the applications running on the various ECUs of the net- work interact with the UCM when they write to a BM This causes either a register transfer taking negligible time if the recipient of the message is mapped to the same ECU or a bus transfer which calls the service stack which implements the communication A BM write operation however only causes the services required to store the required data into the ECUrsquos local memory (Fig 3) The initiation of the ac- tual bus communication is triggered by the bus controller service resident on the bus itself asynchronously from the application behavior The bus controller attempts to send messages from its local memory depending on which mode

of operation the bus arbiter is currently in The three modes of operation are

Static Time Triggered Frames (STTF) are sent when the global bus time dictates that it is time for the mes- sage to use the allotted slot The queue size should never be greater than one since the transmission period should be exactly equal to the production and con- sumption period both instantaneously and on average (Figure 6) No arbitration is needed

Dynamic Periodic Frames (DPF) are queued at regular intervals Time comes from the global state but each ECU has locally programmed triggers for its messages Once the telegram has been queued it must wait until it wins control of the bus before the bus controller can actually send it to the recipient (Figure 7) Arbitration is required

Dynamic A-periodic Frames (DAF) are queued as soon as the application invokes the behavioral write This functionality is facilitated by an interrupt register on the bus controller that the Device Driver service writes to as the message data is transferred into local memory The bus controller detects this register write and imme- diately queues the message for transmission (Figure 8) This mode requires arbitration

- - - - - - - - - I

(Time - Offset) --- Global modPeriod=O I Time

I rsquo - - - - - - - - - 1

Receiv

Mem Bus Ctrl Mem Slave

----- Arbitration

Won

Figure 7 DPF

Receive I Mem Bus Ctrl Bus Ctrl Mem

Master Slave

----- Arbitration

Won

Figure 8 DAF

68

6 Preliminary results and future work

The UCM provides a high grade of automation for rapidly prototyping of distributed communication protocols Our ideas although focused to the automotive domain can be easily adapted to other distributed applications where the assessment of the communication protocol in the early stages of the design is key The implementation of UCM has just ended the first phase Thus we only have some preliminary results We ran a simulation of a Drive by Wire imported design in VCC on an NT workstation with 512Mb of RAM and a Pentium 3 processor The design has 4 ECUs one CAN bus and 100 mapped behaviors To simulate 1 minute of real time the elapsed time was about 5 hours at the rate of 2K framedsec (88 bytes each) The results are encouraging since such simulations can be run over night For the future we plan to continue with the second phase Besides specific bus protocol features can be implemented in VCC by either refining the architectural service models where for example failure states could easily be imple- mented or by importing specific bus protocol models eg from silicon suppliers

7 Acknowledgements

The authors would like to thank Randy Janka and Lucian0 Lavagno from Cadence Design Systems for reviewing the paper Peter Schiele Juergen Ehret and Dr Max Fuchs from BMW Rainer Moser from ETAS Hedley Simmons and Claudio Zizzo from Cadence Methodology Services in Scotland Grant Martin Sherry Solden Aaron Beverly and the whole worldwide Cadence VCC team for the definition of the methodology its implementation and the valuable discussions

References Robert Bosch CAN Specification Version 20 Technical Report IS0 11898 Robert Bosch GmbH 1991 ByteFlight homepage httuNwwwbvteflightcom

TTP Forum =PC specification V05 httpNwwwttpforumor~ 1998 H Kopetz R Hexel A Kruger D Millinger R Nossal A Steininger C Temple T Fuhrer R Pallierer and M Krug A prototype implementation of a ttpc controller Proceed- ings of SAE Congress and Exhibition Feb 1997 E Dilger LA Johansson H Kopetz M Krug P Lidin G McCall P Mortara B Muller Towards An Architecture For Safety Related Fault Tolerant Systems In Vehicles ERSEL - European Conference on Safety and Reliability

E Dilger T Fuhrer B Muller S Poledna T Thurner X- By-Wire Design of Distributed Fault Tolerant and Safety Critical Applications in Modern Vehicles VDI - Verein Deutscher Ingenieure P Schiele Transition Methodology from Specifications to a Network of ECUs Exemplarily with Ascet-SD and VCC SAE Technical Paper Series Nr 2000-01-0720 2000 Translating Models of Computation for Design Exploration of Real-Time Distributed Automotive Applications - White Paper - 200 1

S Edwards L Lavagno E Lee A Sangiovanni- Vincentelli Design of Embedded Systems Formal Methods Validation and Synthesis Proceedings of the IEEE vol 85 (n3) - March 1997 p366-290 Vector Informatik Calibration of Electronic Control Units via CAN httpNwwwvectorinformatikdeenplis~uroductsindexhtml Canape 2000 Cadence Inc Virtual Component Codesign Product Docu- mentation Cadence Inc 1998 ETAS GmbH Whitepaper Ascet-SD- ETAS GmbH 1998 L Lavagno A Sangiovanni-Vincentelli and E Sentovich Models of Computation for Embedded System Design 1998 NATO ASI Proceedings on System Synthesis I1 Ciocco 1998

[14] T Demmeler P Giusto A Universal Communication Model for an Automotive System Integration Platform DATE 2001

[ IS] 1 Gutkin P Giusto J Ehret Modelling the CAN bus within the VCC environment Proceedings of the International Con- ference on Parallel and Distributed Processing Techniques and Applications 1999

[ 161 S Cardelli P Giusto M Chiodo A Jurecska L Lavagno and A Sangiovanni-Vincentelli Rapid-prototyping of em- bedded systems via re-programmable devices Proceedings of the International Workshop on Rapid Systems Prototyping 1996

1171 Chris Edwards Car makers plan to spread software around vehicles httpwwweIectronicstimzscom March 20 2001

69

The UCM is used in a refinement process At the beginning of the exploration stage the designer starts with the UCM configured to run in a pure event-driven mode - less expen- sive than the time-triggered case The refinement to the dif- ferent kinds of protocols (existing ones or not) is done step by step by changing the UCM parameters Once the UCM settings match a specific protocol we expect accurate per- formance results to be obtained that allow qualitative as- sessments at least for the system running properly under no fault conditions Although VCC provides such a capability we do not model the delays of HWSW interrupts (ie pulses coming from the crankshaft) In fact they are negli- gible with respect to the overall system performance domi- nated by the latencies of framesrsquo sent over the bus - in the UCM a frame is a set of messages the message exchange modeled with VCC behavioral memories (BM)[ 141 Hence we have focused on the communications that involve BMrsquos The mapping of the zero-time BM accesses (reads and writes) onto communication patterns (that model different communication delays providing the performance model of the communication itself) is performed automatically by VCC In fact depending on the VCC mapping of Ascet-SD modules onto architectural resources [SI[ 141 the same functional data

UCM IO Port

Figure 2 The VCC ECU model exchange in the behavior may take different communication delays depending whether the modules are mapped to dif- ferent ECUs or to the same one In the latter case the com- munication would be purely SW to SW on the same ECU In the former case a bus is involved and therefore the mod- eled delay must be different These and other issues with proposed solutions are discussed in detail in [ 141

4 Implementation of the UCM

The implementation of the UCM has been divided in two subsequent phases In the first one (completed) we support

Event driven (asynchronous) protocols

Execution of at least two different threads at any time eg one thread for an applicationhost and one for a bus controllerhus arbiter

Broadcast communications

Assignment of priorities to each and every telegramrsquo

Telegram arbitration that gives access to the highest priority telegram available across all system nodes - the performance model associated with this arbitration is linear multiple of the number of nodes in the system times some user-specified value

We enable each system node to read the state of the bus (busy or free [14]) In the second phase we are planning to support

Time-triggered (synchronous) protocols

Bus redundancy (two similar or different buses con- nected to each ECU)

Error injection to allow simulation of real-life faulty scenarios

Slots with transmission of one or more frames

Modeling of functionality and performance associated with the addition of frame overhead properties eg CRCrsquos

Enhanced arbitration schemes and protocols

User-specified inter-frame gaps

A Communications Matrix to allow users to specify telegram priorities message t o telegram assignments message to frame assignments frame to slot assign- ments and Slot Sizes

Start-up andor initialization modes

We will also enable the user to specify where the bus- related functionality is performed (the CPU or the Bus Controller) by means of parameters

The UCM is implemented using VCCrsquos architectural serv- ices When modeling a network system these services ef- fectively form a function stack where each layer models the delay added to the transmission time of a frame without implementing the real communication protocol Figure 2 illustrates a model of an ECU in VCC Figure 3 shows the functional components of the service stack as they would be used in the transmission of data from an application running on one ECU to an application running on some other ECU

e The Device Driver layer is a software service that per- forms most of the tasks involved with message and frame assembly It runs on the RTOS on the CPU and

Unless specified differently the term frame is used for the generic data sent over the bus rsquo A telegram is a set o f messages in the CAN protocol

66

is subject to the delays caused by task switching the number of instructions required etc

The Bus Controller hardware service consists of two other services a Bus Master that drives data onto the bus when the ECU is transmitting and a Bus Slave that listens to the data on the bus and passes on frames that are addressed to the ECU on which it resides The Bus Master also contains the functionality to complete the packing of frames and queuing of the packets for transmission over the Bus service

The UCM Bus service provides delay information for the actual transmission of data through the communi- cation medium It also runs the actual protocol for the bus which communicates to the Bus Controllers whether the bus is busy which time slot is currently being broadcast etc Most importantly it performs all global bus arbitration functions for the event-driven configuration

Behavior FCFS FCFS

Write Master Bus

Arbiter Adapter

BM Write BM Read

ECU ECU Device Device Driver Driver

I t v

FCFS Bus Ctrl

Slave Adapter Memory

Figure 3 The service stack

I + 1 Arb Delay 4 Grant

Send Return

b

Done

Release

The actual protocol is spread out over the bus controller (activation policy) and the bus arbiter (communication cy- cle) This allows to separate the activation policy of each frame (event-driven or time triggered) from the actual communication cycle (static vs dynamic)[ 141 therefore providing the framework for the exploration of new com- munication protocols

Snoop Delay

Write

Zero Delay [

Control1er

L

UCM UCM UCM Master Bus State Slave Controller Adapter Arbiter Machine Adapter Memory r] Bus

Figure 4 ECU local communication

I b Arb RequesL Request

I Delay Return

Grant OK

Snoop Delay

Write

Done

Send

4 I Frame

Bus bps

State

Delav

+

Zero Delay

Figure 5 inter ECU communication

Figures 4 and 5 show the message sequence charts (MSC) of the sequence of events being passed between the func- tional components of the VCC service stack along with the modeled delays The first MSC represents the thread of execution from the mapped behavior to the bus controller local memory In the second MSC the broadcast communi- cation is shown

67

5 Use model for rapid prototyping of communication protocols configuration and operation of the UCM

APP

The user can specify the number of different frames that each ECU sends on the bus via an array of frame data-types that define all the properties required for the UCM For example an ECU sends two frames The first one is a Slot frame which is sent once every communication cycle [ 141 at an offset of 1 millisecond and consists of two BMrsquos with a packaging overhead of 8 bits The second frame is a single BM Telegram triggered every time the BM is written The frame has an overhead of 24 bits and priority 2 The user can specify the bus arbiter parameters as well For example a particular system transmits at 1 Mbps and the communi- cation cycle repeats every half-second There is a single static part of 100 ms starting at the beginning of the cycle and a dynamic part of 400 milliseconds (arbitration) The minimum time allowed between transmitted frames is 02 milliseconds and the Arbitration Factor value defines a linear relationship between the number of nodes racing for control of the bus and how long the arbitration phase of a telegram communication lasts for

I I I I

I I I I APP Send v

Mem Bus Ctrl Master v

Receive

C v E-) Bus Ctrl Mem n W Slave + E

Figure 6 STTF

The operation of the UCM is driven by two sets of entities that are independent of each other The behavioral models of the applications running on the various ECUs of the net- work interact with the UCM when they write to a BM This causes either a register transfer taking negligible time if the recipient of the message is mapped to the same ECU or a bus transfer which calls the service stack which implements the communication A BM write operation however only causes the services required to store the required data into the ECUrsquos local memory (Fig 3) The initiation of the ac- tual bus communication is triggered by the bus controller service resident on the bus itself asynchronously from the application behavior The bus controller attempts to send messages from its local memory depending on which mode

of operation the bus arbiter is currently in The three modes of operation are

Static Time Triggered Frames (STTF) are sent when the global bus time dictates that it is time for the mes- sage to use the allotted slot The queue size should never be greater than one since the transmission period should be exactly equal to the production and con- sumption period both instantaneously and on average (Figure 6) No arbitration is needed

Dynamic Periodic Frames (DPF) are queued at regular intervals Time comes from the global state but each ECU has locally programmed triggers for its messages Once the telegram has been queued it must wait until it wins control of the bus before the bus controller can actually send it to the recipient (Figure 7) Arbitration is required

Dynamic A-periodic Frames (DAF) are queued as soon as the application invokes the behavioral write This functionality is facilitated by an interrupt register on the bus controller that the Device Driver service writes to as the message data is transferred into local memory The bus controller detects this register write and imme- diately queues the message for transmission (Figure 8) This mode requires arbitration

- - - - - - - - - I

(Time - Offset) --- Global modPeriod=O I Time

I rsquo - - - - - - - - - 1

Receiv

Mem Bus Ctrl Mem Slave

----- Arbitration

Won

Figure 7 DPF

Receive I Mem Bus Ctrl Bus Ctrl Mem

Master Slave

----- Arbitration

Won

Figure 8 DAF

68

6 Preliminary results and future work

The UCM provides a high grade of automation for rapidly prototyping of distributed communication protocols Our ideas although focused to the automotive domain can be easily adapted to other distributed applications where the assessment of the communication protocol in the early stages of the design is key The implementation of UCM has just ended the first phase Thus we only have some preliminary results We ran a simulation of a Drive by Wire imported design in VCC on an NT workstation with 512Mb of RAM and a Pentium 3 processor The design has 4 ECUs one CAN bus and 100 mapped behaviors To simulate 1 minute of real time the elapsed time was about 5 hours at the rate of 2K framedsec (88 bytes each) The results are encouraging since such simulations can be run over night For the future we plan to continue with the second phase Besides specific bus protocol features can be implemented in VCC by either refining the architectural service models where for example failure states could easily be imple- mented or by importing specific bus protocol models eg from silicon suppliers

7 Acknowledgements

The authors would like to thank Randy Janka and Lucian0 Lavagno from Cadence Design Systems for reviewing the paper Peter Schiele Juergen Ehret and Dr Max Fuchs from BMW Rainer Moser from ETAS Hedley Simmons and Claudio Zizzo from Cadence Methodology Services in Scotland Grant Martin Sherry Solden Aaron Beverly and the whole worldwide Cadence VCC team for the definition of the methodology its implementation and the valuable discussions

References Robert Bosch CAN Specification Version 20 Technical Report IS0 11898 Robert Bosch GmbH 1991 ByteFlight homepage httuNwwwbvteflightcom

TTP Forum =PC specification V05 httpNwwwttpforumor~ 1998 H Kopetz R Hexel A Kruger D Millinger R Nossal A Steininger C Temple T Fuhrer R Pallierer and M Krug A prototype implementation of a ttpc controller Proceed- ings of SAE Congress and Exhibition Feb 1997 E Dilger LA Johansson H Kopetz M Krug P Lidin G McCall P Mortara B Muller Towards An Architecture For Safety Related Fault Tolerant Systems In Vehicles ERSEL - European Conference on Safety and Reliability

E Dilger T Fuhrer B Muller S Poledna T Thurner X- By-Wire Design of Distributed Fault Tolerant and Safety Critical Applications in Modern Vehicles VDI - Verein Deutscher Ingenieure P Schiele Transition Methodology from Specifications to a Network of ECUs Exemplarily with Ascet-SD and VCC SAE Technical Paper Series Nr 2000-01-0720 2000 Translating Models of Computation for Design Exploration of Real-Time Distributed Automotive Applications - White Paper - 200 1

S Edwards L Lavagno E Lee A Sangiovanni- Vincentelli Design of Embedded Systems Formal Methods Validation and Synthesis Proceedings of the IEEE vol 85 (n3) - March 1997 p366-290 Vector Informatik Calibration of Electronic Control Units via CAN httpNwwwvectorinformatikdeenplis~uroductsindexhtml Canape 2000 Cadence Inc Virtual Component Codesign Product Docu- mentation Cadence Inc 1998 ETAS GmbH Whitepaper Ascet-SD- ETAS GmbH 1998 L Lavagno A Sangiovanni-Vincentelli and E Sentovich Models of Computation for Embedded System Design 1998 NATO ASI Proceedings on System Synthesis I1 Ciocco 1998

[14] T Demmeler P Giusto A Universal Communication Model for an Automotive System Integration Platform DATE 2001

[ IS] 1 Gutkin P Giusto J Ehret Modelling the CAN bus within the VCC environment Proceedings of the International Con- ference on Parallel and Distributed Processing Techniques and Applications 1999

[ 161 S Cardelli P Giusto M Chiodo A Jurecska L Lavagno and A Sangiovanni-Vincentelli Rapid-prototyping of em- bedded systems via re-programmable devices Proceedings of the International Workshop on Rapid Systems Prototyping 1996

1171 Chris Edwards Car makers plan to spread software around vehicles httpwwweIectronicstimzscom March 20 2001

69

is subject to the delays caused by task switching the number of instructions required etc

The Bus Controller hardware service consists of two other services a Bus Master that drives data onto the bus when the ECU is transmitting and a Bus Slave that listens to the data on the bus and passes on frames that are addressed to the ECU on which it resides The Bus Master also contains the functionality to complete the packing of frames and queuing of the packets for transmission over the Bus service

The UCM Bus service provides delay information for the actual transmission of data through the communi- cation medium It also runs the actual protocol for the bus which communicates to the Bus Controllers whether the bus is busy which time slot is currently being broadcast etc Most importantly it performs all global bus arbitration functions for the event-driven configuration

Behavior FCFS FCFS

Write Master Bus

Arbiter Adapter

BM Write BM Read

ECU ECU Device Device Driver Driver

I t v

FCFS Bus Ctrl

Slave Adapter Memory

Figure 3 The service stack

I + 1 Arb Delay 4 Grant

Send Return

b

Done

Release

The actual protocol is spread out over the bus controller (activation policy) and the bus arbiter (communication cy- cle) This allows to separate the activation policy of each frame (event-driven or time triggered) from the actual communication cycle (static vs dynamic)[ 141 therefore providing the framework for the exploration of new com- munication protocols

Snoop Delay

Write

Zero Delay [

Control1er

L

UCM UCM UCM Master Bus State Slave Controller Adapter Arbiter Machine Adapter Memory r] Bus

Figure 4 ECU local communication

I b Arb RequesL Request

I Delay Return

Grant OK

Snoop Delay

Write

Done

Send

4 I Frame

Bus bps

State

Delav

+

Zero Delay

Figure 5 inter ECU communication

Figures 4 and 5 show the message sequence charts (MSC) of the sequence of events being passed between the func- tional components of the VCC service stack along with the modeled delays The first MSC represents the thread of execution from the mapped behavior to the bus controller local memory In the second MSC the broadcast communi- cation is shown

67

5 Use model for rapid prototyping of communication protocols configuration and operation of the UCM

APP

The user can specify the number of different frames that each ECU sends on the bus via an array of frame data-types that define all the properties required for the UCM For example an ECU sends two frames The first one is a Slot frame which is sent once every communication cycle [ 141 at an offset of 1 millisecond and consists of two BMrsquos with a packaging overhead of 8 bits The second frame is a single BM Telegram triggered every time the BM is written The frame has an overhead of 24 bits and priority 2 The user can specify the bus arbiter parameters as well For example a particular system transmits at 1 Mbps and the communi- cation cycle repeats every half-second There is a single static part of 100 ms starting at the beginning of the cycle and a dynamic part of 400 milliseconds (arbitration) The minimum time allowed between transmitted frames is 02 milliseconds and the Arbitration Factor value defines a linear relationship between the number of nodes racing for control of the bus and how long the arbitration phase of a telegram communication lasts for

I I I I

I I I I APP Send v

Mem Bus Ctrl Master v

Receive

C v E-) Bus Ctrl Mem n W Slave + E

Figure 6 STTF

The operation of the UCM is driven by two sets of entities that are independent of each other The behavioral models of the applications running on the various ECUs of the net- work interact with the UCM when they write to a BM This causes either a register transfer taking negligible time if the recipient of the message is mapped to the same ECU or a bus transfer which calls the service stack which implements the communication A BM write operation however only causes the services required to store the required data into the ECUrsquos local memory (Fig 3) The initiation of the ac- tual bus communication is triggered by the bus controller service resident on the bus itself asynchronously from the application behavior The bus controller attempts to send messages from its local memory depending on which mode

of operation the bus arbiter is currently in The three modes of operation are

Static Time Triggered Frames (STTF) are sent when the global bus time dictates that it is time for the mes- sage to use the allotted slot The queue size should never be greater than one since the transmission period should be exactly equal to the production and con- sumption period both instantaneously and on average (Figure 6) No arbitration is needed

Dynamic Periodic Frames (DPF) are queued at regular intervals Time comes from the global state but each ECU has locally programmed triggers for its messages Once the telegram has been queued it must wait until it wins control of the bus before the bus controller can actually send it to the recipient (Figure 7) Arbitration is required

Dynamic A-periodic Frames (DAF) are queued as soon as the application invokes the behavioral write This functionality is facilitated by an interrupt register on the bus controller that the Device Driver service writes to as the message data is transferred into local memory The bus controller detects this register write and imme- diately queues the message for transmission (Figure 8) This mode requires arbitration

- - - - - - - - - I

(Time - Offset) --- Global modPeriod=O I Time

I rsquo - - - - - - - - - 1

Receiv

Mem Bus Ctrl Mem Slave

----- Arbitration

Won

Figure 7 DPF

Receive I Mem Bus Ctrl Bus Ctrl Mem

Master Slave

----- Arbitration

Won

Figure 8 DAF

68

6 Preliminary results and future work

The UCM provides a high grade of automation for rapidly prototyping of distributed communication protocols Our ideas although focused to the automotive domain can be easily adapted to other distributed applications where the assessment of the communication protocol in the early stages of the design is key The implementation of UCM has just ended the first phase Thus we only have some preliminary results We ran a simulation of a Drive by Wire imported design in VCC on an NT workstation with 512Mb of RAM and a Pentium 3 processor The design has 4 ECUs one CAN bus and 100 mapped behaviors To simulate 1 minute of real time the elapsed time was about 5 hours at the rate of 2K framedsec (88 bytes each) The results are encouraging since such simulations can be run over night For the future we plan to continue with the second phase Besides specific bus protocol features can be implemented in VCC by either refining the architectural service models where for example failure states could easily be imple- mented or by importing specific bus protocol models eg from silicon suppliers

7 Acknowledgements

The authors would like to thank Randy Janka and Lucian0 Lavagno from Cadence Design Systems for reviewing the paper Peter Schiele Juergen Ehret and Dr Max Fuchs from BMW Rainer Moser from ETAS Hedley Simmons and Claudio Zizzo from Cadence Methodology Services in Scotland Grant Martin Sherry Solden Aaron Beverly and the whole worldwide Cadence VCC team for the definition of the methodology its implementation and the valuable discussions

References Robert Bosch CAN Specification Version 20 Technical Report IS0 11898 Robert Bosch GmbH 1991 ByteFlight homepage httuNwwwbvteflightcom

TTP Forum =PC specification V05 httpNwwwttpforumor~ 1998 H Kopetz R Hexel A Kruger D Millinger R Nossal A Steininger C Temple T Fuhrer R Pallierer and M Krug A prototype implementation of a ttpc controller Proceed- ings of SAE Congress and Exhibition Feb 1997 E Dilger LA Johansson H Kopetz M Krug P Lidin G McCall P Mortara B Muller Towards An Architecture For Safety Related Fault Tolerant Systems In Vehicles ERSEL - European Conference on Safety and Reliability

E Dilger T Fuhrer B Muller S Poledna T Thurner X- By-Wire Design of Distributed Fault Tolerant and Safety Critical Applications in Modern Vehicles VDI - Verein Deutscher Ingenieure P Schiele Transition Methodology from Specifications to a Network of ECUs Exemplarily with Ascet-SD and VCC SAE Technical Paper Series Nr 2000-01-0720 2000 Translating Models of Computation for Design Exploration of Real-Time Distributed Automotive Applications - White Paper - 200 1

S Edwards L Lavagno E Lee A Sangiovanni- Vincentelli Design of Embedded Systems Formal Methods Validation and Synthesis Proceedings of the IEEE vol 85 (n3) - March 1997 p366-290 Vector Informatik Calibration of Electronic Control Units via CAN httpNwwwvectorinformatikdeenplis~uroductsindexhtml Canape 2000 Cadence Inc Virtual Component Codesign Product Docu- mentation Cadence Inc 1998 ETAS GmbH Whitepaper Ascet-SD- ETAS GmbH 1998 L Lavagno A Sangiovanni-Vincentelli and E Sentovich Models of Computation for Embedded System Design 1998 NATO ASI Proceedings on System Synthesis I1 Ciocco 1998

[14] T Demmeler P Giusto A Universal Communication Model for an Automotive System Integration Platform DATE 2001

[ IS] 1 Gutkin P Giusto J Ehret Modelling the CAN bus within the VCC environment Proceedings of the International Con- ference on Parallel and Distributed Processing Techniques and Applications 1999

[ 161 S Cardelli P Giusto M Chiodo A Jurecska L Lavagno and A Sangiovanni-Vincentelli Rapid-prototyping of em- bedded systems via re-programmable devices Proceedings of the International Workshop on Rapid Systems Prototyping 1996

1171 Chris Edwards Car makers plan to spread software around vehicles httpwwweIectronicstimzscom March 20 2001

69

5 Use model for rapid prototyping of communication protocols configuration and operation of the UCM

APP

The user can specify the number of different frames that each ECU sends on the bus via an array of frame data-types that define all the properties required for the UCM For example an ECU sends two frames The first one is a Slot frame which is sent once every communication cycle [ 141 at an offset of 1 millisecond and consists of two BMrsquos with a packaging overhead of 8 bits The second frame is a single BM Telegram triggered every time the BM is written The frame has an overhead of 24 bits and priority 2 The user can specify the bus arbiter parameters as well For example a particular system transmits at 1 Mbps and the communi- cation cycle repeats every half-second There is a single static part of 100 ms starting at the beginning of the cycle and a dynamic part of 400 milliseconds (arbitration) The minimum time allowed between transmitted frames is 02 milliseconds and the Arbitration Factor value defines a linear relationship between the number of nodes racing for control of the bus and how long the arbitration phase of a telegram communication lasts for

I I I I

I I I I APP Send v

Mem Bus Ctrl Master v

Receive

C v E-) Bus Ctrl Mem n W Slave + E

Figure 6 STTF

The operation of the UCM is driven by two sets of entities that are independent of each other The behavioral models of the applications running on the various ECUs of the net- work interact with the UCM when they write to a BM This causes either a register transfer taking negligible time if the recipient of the message is mapped to the same ECU or a bus transfer which calls the service stack which implements the communication A BM write operation however only causes the services required to store the required data into the ECUrsquos local memory (Fig 3) The initiation of the ac- tual bus communication is triggered by the bus controller service resident on the bus itself asynchronously from the application behavior The bus controller attempts to send messages from its local memory depending on which mode

of operation the bus arbiter is currently in The three modes of operation are

Static Time Triggered Frames (STTF) are sent when the global bus time dictates that it is time for the mes- sage to use the allotted slot The queue size should never be greater than one since the transmission period should be exactly equal to the production and con- sumption period both instantaneously and on average (Figure 6) No arbitration is needed

Dynamic Periodic Frames (DPF) are queued at regular intervals Time comes from the global state but each ECU has locally programmed triggers for its messages Once the telegram has been queued it must wait until it wins control of the bus before the bus controller can actually send it to the recipient (Figure 7) Arbitration is required

Dynamic A-periodic Frames (DAF) are queued as soon as the application invokes the behavioral write This functionality is facilitated by an interrupt register on the bus controller that the Device Driver service writes to as the message data is transferred into local memory The bus controller detects this register write and imme- diately queues the message for transmission (Figure 8) This mode requires arbitration

- - - - - - - - - I

(Time - Offset) --- Global modPeriod=O I Time

I rsquo - - - - - - - - - 1

Receiv

Mem Bus Ctrl Mem Slave

----- Arbitration

Won

Figure 7 DPF

Receive I Mem Bus Ctrl Bus Ctrl Mem

Master Slave

----- Arbitration

Won

Figure 8 DAF

68

6 Preliminary results and future work

The UCM provides a high grade of automation for rapidly prototyping of distributed communication protocols Our ideas although focused to the automotive domain can be easily adapted to other distributed applications where the assessment of the communication protocol in the early stages of the design is key The implementation of UCM has just ended the first phase Thus we only have some preliminary results We ran a simulation of a Drive by Wire imported design in VCC on an NT workstation with 512Mb of RAM and a Pentium 3 processor The design has 4 ECUs one CAN bus and 100 mapped behaviors To simulate 1 minute of real time the elapsed time was about 5 hours at the rate of 2K framedsec (88 bytes each) The results are encouraging since such simulations can be run over night For the future we plan to continue with the second phase Besides specific bus protocol features can be implemented in VCC by either refining the architectural service models where for example failure states could easily be imple- mented or by importing specific bus protocol models eg from silicon suppliers

7 Acknowledgements

The authors would like to thank Randy Janka and Lucian0 Lavagno from Cadence Design Systems for reviewing the paper Peter Schiele Juergen Ehret and Dr Max Fuchs from BMW Rainer Moser from ETAS Hedley Simmons and Claudio Zizzo from Cadence Methodology Services in Scotland Grant Martin Sherry Solden Aaron Beverly and the whole worldwide Cadence VCC team for the definition of the methodology its implementation and the valuable discussions

References Robert Bosch CAN Specification Version 20 Technical Report IS0 11898 Robert Bosch GmbH 1991 ByteFlight homepage httuNwwwbvteflightcom

TTP Forum =PC specification V05 httpNwwwttpforumor~ 1998 H Kopetz R Hexel A Kruger D Millinger R Nossal A Steininger C Temple T Fuhrer R Pallierer and M Krug A prototype implementation of a ttpc controller Proceed- ings of SAE Congress and Exhibition Feb 1997 E Dilger LA Johansson H Kopetz M Krug P Lidin G McCall P Mortara B Muller Towards An Architecture For Safety Related Fault Tolerant Systems In Vehicles ERSEL - European Conference on Safety and Reliability

E Dilger T Fuhrer B Muller S Poledna T Thurner X- By-Wire Design of Distributed Fault Tolerant and Safety Critical Applications in Modern Vehicles VDI - Verein Deutscher Ingenieure P Schiele Transition Methodology from Specifications to a Network of ECUs Exemplarily with Ascet-SD and VCC SAE Technical Paper Series Nr 2000-01-0720 2000 Translating Models of Computation for Design Exploration of Real-Time Distributed Automotive Applications - White Paper - 200 1

S Edwards L Lavagno E Lee A Sangiovanni- Vincentelli Design of Embedded Systems Formal Methods Validation and Synthesis Proceedings of the IEEE vol 85 (n3) - March 1997 p366-290 Vector Informatik Calibration of Electronic Control Units via CAN httpNwwwvectorinformatikdeenplis~uroductsindexhtml Canape 2000 Cadence Inc Virtual Component Codesign Product Docu- mentation Cadence Inc 1998 ETAS GmbH Whitepaper Ascet-SD- ETAS GmbH 1998 L Lavagno A Sangiovanni-Vincentelli and E Sentovich Models of Computation for Embedded System Design 1998 NATO ASI Proceedings on System Synthesis I1 Ciocco 1998

[14] T Demmeler P Giusto A Universal Communication Model for an Automotive System Integration Platform DATE 2001

[ IS] 1 Gutkin P Giusto J Ehret Modelling the CAN bus within the VCC environment Proceedings of the International Con- ference on Parallel and Distributed Processing Techniques and Applications 1999

[ 161 S Cardelli P Giusto M Chiodo A Jurecska L Lavagno and A Sangiovanni-Vincentelli Rapid-prototyping of em- bedded systems via re-programmable devices Proceedings of the International Workshop on Rapid Systems Prototyping 1996

1171 Chris Edwards Car makers plan to spread software around vehicles httpwwweIectronicstimzscom March 20 2001

69

6 Preliminary results and future work

The UCM provides a high grade of automation for rapidly prototyping of distributed communication protocols Our ideas although focused to the automotive domain can be easily adapted to other distributed applications where the assessment of the communication protocol in the early stages of the design is key The implementation of UCM has just ended the first phase Thus we only have some preliminary results We ran a simulation of a Drive by Wire imported design in VCC on an NT workstation with 512Mb of RAM and a Pentium 3 processor The design has 4 ECUs one CAN bus and 100 mapped behaviors To simulate 1 minute of real time the elapsed time was about 5 hours at the rate of 2K framedsec (88 bytes each) The results are encouraging since such simulations can be run over night For the future we plan to continue with the second phase Besides specific bus protocol features can be implemented in VCC by either refining the architectural service models where for example failure states could easily be imple- mented or by importing specific bus protocol models eg from silicon suppliers

7 Acknowledgements

The authors would like to thank Randy Janka and Lucian0 Lavagno from Cadence Design Systems for reviewing the paper Peter Schiele Juergen Ehret and Dr Max Fuchs from BMW Rainer Moser from ETAS Hedley Simmons and Claudio Zizzo from Cadence Methodology Services in Scotland Grant Martin Sherry Solden Aaron Beverly and the whole worldwide Cadence VCC team for the definition of the methodology its implementation and the valuable discussions

References Robert Bosch CAN Specification Version 20 Technical Report IS0 11898 Robert Bosch GmbH 1991 ByteFlight homepage httuNwwwbvteflightcom

TTP Forum =PC specification V05 httpNwwwttpforumor~ 1998 H Kopetz R Hexel A Kruger D Millinger R Nossal A Steininger C Temple T Fuhrer R Pallierer and M Krug A prototype implementation of a ttpc controller Proceed- ings of SAE Congress and Exhibition Feb 1997 E Dilger LA Johansson H Kopetz M Krug P Lidin G McCall P Mortara B Muller Towards An Architecture For Safety Related Fault Tolerant Systems In Vehicles ERSEL - European Conference on Safety and Reliability

E Dilger T Fuhrer B Muller S Poledna T Thurner X- By-Wire Design of Distributed Fault Tolerant and Safety Critical Applications in Modern Vehicles VDI - Verein Deutscher Ingenieure P Schiele Transition Methodology from Specifications to a Network of ECUs Exemplarily with Ascet-SD and VCC SAE Technical Paper Series Nr 2000-01-0720 2000 Translating Models of Computation for Design Exploration of Real-Time Distributed Automotive Applications - White Paper - 200 1

S Edwards L Lavagno E Lee A Sangiovanni- Vincentelli Design of Embedded Systems Formal Methods Validation and Synthesis Proceedings of the IEEE vol 85 (n3) - March 1997 p366-290 Vector Informatik Calibration of Electronic Control Units via CAN httpNwwwvectorinformatikdeenplis~uroductsindexhtml Canape 2000 Cadence Inc Virtual Component Codesign Product Docu- mentation Cadence Inc 1998 ETAS GmbH Whitepaper Ascet-SD- ETAS GmbH 1998 L Lavagno A Sangiovanni-Vincentelli and E Sentovich Models of Computation for Embedded System Design 1998 NATO ASI Proceedings on System Synthesis I1 Ciocco 1998

[14] T Demmeler P Giusto A Universal Communication Model for an Automotive System Integration Platform DATE 2001

[ IS] 1 Gutkin P Giusto J Ehret Modelling the CAN bus within the VCC environment Proceedings of the International Con- ference on Parallel and Distributed Processing Techniques and Applications 1999

[ 161 S Cardelli P Giusto M Chiodo A Jurecska L Lavagno and A Sangiovanni-Vincentelli Rapid-prototyping of em- bedded systems via re-programmable devices Proceedings of the International Workshop on Rapid Systems Prototyping 1996

1171 Chris Edwards Car makers plan to spread software around vehicles httpwwweIectronicstimzscom March 20 2001

69