The Java CAN API -

A Java Gateway to Fieldbus Communication

Dieter Biihler' Gerd Nusser1l2

'Wilhelm-Schickard Institute, Symbolic Computation Group
University of Tiibingen
72076 Tiibingen, Germany
http://www-sr.informatik.uni-tuebingen.de
21nstitutefor Automation Engineering
University of Applied Sciences Reutlingen
72762 Reutlingen, Germany
http://www-ita.fh-reutlingen.de
{buehler, nusser} @ informatik.uni-tuebingen.de

Abstract icated Java real-time systems (e.g. SZCOMP RTVM' or

Object oriented problem analysis and software design
is getting more and more common in the field of indus-
trial control. In this paper we present the Java CAN API
which provides a convenient, object oriented pmgram-
ming framework for rapid CANfieldbus tool development.
It provides a hierarchy of classes and inte$aces to access
arbitrary CAWCANopen devices via the Java Native In-
terface. In order to access Windows-based CAN drivers
a native dynamic link library has been developed featur-
ing high pe?formance messagefiltering and asynchronous
message not$cation. The created Java class hierarchy en-
capsulates the CANopen layer 7 communication objects
as well as generic CAN layer 2 messages. Further classes
provide access to the CANopen network management ser-
vices. This paper also briefly presents some practical uses
of the Java CAN API for teleservice, distance education
and CAN system management.
1. Introduction
The fieldbus concept is the widely adopted standard for
real-time inter-device communication in automation sys-
tems. In the past, the corresponding control tasks were
mainly handled by low level programs of programmable
logic controllers. Today, with the broad acceptance of the
object oriented approach it becomes more and more at-
tractive to use programming languages like Java and C++
JBedL), Java is likely to play a major role in future indus-
trial control applications.
Furthermore, in cases where no hard real-time restric-
tions apply but a complex application logic is required
(e.g. in the fields of (remote) management, monitoring
and maintenance of fieldbus systems) Java allows rapid
creation of powerful, safe and reusable software compo-
nents. Java also accomplishes the easy integration of in-
dustrial automation systems into the business LAN of a
manufacturing enterprise or even the World Wide Web. A
multitude of freely available Java libraries provide con-
venient support for issues like security, middleware tech-
nologies and distribution, Web integration, graphical user
interfaces, database connectivity, XML support, intema-
tionalization and others. The possible reuse of software
components and the portability of Java code results in a
reduction of costs for software creation and maintenance.
We use the Controller Area Network (CAN) [ 121 field-
bus system for an exemplary mediation between a real-
time, message oriented fieldbus environment and an ob-
ject oriented enterprise programming environment. Our
Java CANApplication Programming Interface (Java CAN
A P I ) provides a convenient programming framework for
rapid CAN/CANopen tool development. It consists of
a hierarchy of classes and interfaces for most of the
CANICANopen communication primitives and network
management services.
CANopen [7] is a layer 7 network protocol3 for CAN
communication, primarily used in industrial automation
~

Siemens AG, http://www.ad.siemens.de/sicomp/html-76/sw_rtvm.-

to represent device interfaces and to specify control al- htm
gorithms in an object oriented way (cf. [13]). With the 'esmertec, http://www.jbed.com
increasing hardware performance and the advent of ded- 3Accordingto the ISO/OSI reference model

WFCS-2OO0, September6-8, Porto, Portugal

0-7803-6500-3/00/$10.00 @2000IEEE 37
 applications where devices such as distributed U 0 mod-
ules, drives etc. communicate over a CAN fieldbus link.
Almost all communication is done via the so-called De-
vice Projle, a two dimensional array of parameters, re-
flecting the current status of a device at a given time. The
- PDOHandler

entries of the Device Profile are addressed by index and

subindex. They can be read to retrieve specific param-
eters and written to change the current status of a de-
vice. CANopen is an open standard, developed within
the CAN in Automation international users’ and manufac-
turers’ group (www.can-cia.de)formed by more than 300
companies worldwide.
The underlying CAN fieldbus is a real-time, multi-
master, serial bus system with outstanding transmission
reliability, specified up to layer 2 of the ISO/OSI refer-
ence model.
The paper is structured as follows: In section 2 the de-
sign of the Java CAN API is introduced. Section 3 will
illustrate the use of the API with an example application.
Further practical uses are briefly presented in Section 4.
The paper concludes with a summary.
2. The Design of the Java CAN API
The Java CAN AP1,consists of two packages: de.-
uniduebingen.can.JCan and de.uni_tuebingen.can.Can-
Protocol. The JCan package provides a communication
infrastructure for accessing a CAN interface card via the
Java Native Interface and the CanProtocol package pro-
vides the CANKANopencommunication objects and net-
work management services. The object oriented design
is illustrated by diagrams based on the Object Modeling
Technique (OMT) [15, 141 and follow the conventions
used in [lo]. Exhaustive documentation is available on-
line at [ 5 ] .
2.1. CAN Communication Infrastructure
Figure 1. Asynchronous CAN message ser-
vice
method canEvent ( ) and sign itself as an event lis-
tener at the CanPort object using the addEventLis-
tener ( ) method. Whenever a message with a specified
identifier appears the canEvent ( ) methods of the reg-
istered listeners are called. The CanPortEvent argument
passed to the canEvent ( ) method contains information
about the event type and the event source. According to
the type and source of the event the listeners can react in
an appropriate way. In the case of an error a CanPort-
Exception is thrown.
2.2. CAN/CANopen Communication Objects
Both, CANopen layer 7 communication objects as well
as generic CAN layer 2 messages are supported by the de.-
uni_tuebingen.can.CanProtocol package. Further classes
provide the CANopen Network Management (NMT) [9]
services. Figure 2 gives an overview of the most important
classes of the CanProtocol package used to encapsulate
communication objects.
CanPortICtanMsg
read() setData()
write() seUd()
subscribeID() send0
1 I I

As mentioned before the JCan package provides a

communication infrastructure for accessing CAN hard- PDO SDO
setsynchronous() sendReadSdo()
ware via the Java Native Interface. This package repre- setAsynchronous() sendWriteSdo0

sents the Java part of the CAN communication framework

and provides classes and interfaces to transparently access ReceivePDO I TransmitPDO --+PDOnandler
the system driver software. The system driver software is sendunsigned80 addPDOHandler0
readReal320
transmitPDOArrived()
TransmitPDOError()
encapsulated in a dynamic link library called JCan.DLL4 ~

as presented in [6]. As the JCan package is vendor and

platform independent it offers an additional level of ab-
straction. To access the CAN, a Java instance needs a ref-
erence to a CanPort object providing the interface to the
CAN hardware, resp. the CAN driver software. The Can-
Port constructor is parameterized by the CAN bitrate the
physical communication channel and a timer interval.
The JCan package supports asynchronous message no-
tification as depicted in Figure 1.
This technique is implemented according to the ob-
server pattern as described in [IO]. To use asynchronous
message notification, a Java instance has to override the
IO.DLL
http://robo16.th-reutlingen.de/JavaCANAPI/JCm
Figure 2. Communication objects of the
Java CAN API
The base class for all CAN communication objects5 is
the CanMsg class. It encapsulates generic CAN layer 2
messages with eight bytes of data and an 11 or 29 bit
identifier. The reference to the associated CAN commu-
nication port has to be specified in the CanMsg construc-
tor. All CAN related communication is done via this Can-
Port reference. The methods setId( ) , setData ( )
5Exceptfor the Sync object

38
and getId ( 1, getData ( read or write the data and
the identifier bit field of a CanMsg instance. The bit fields
are implemented as dedicated BitVector objects for conve-
nient access to individual bits of the message data or the
CAN identifier. The CANopenService Data Object (SDO)
and Process Data Object (PDO) are represented by the
SDO class and the PDO class, respectively. Both classes
directly extend the CanMsg class (cf. Figure 2) by adding
higher level communication facilities.
SDO communication SDO communication is used to
access arbitrary device parameters with no real-time guar-
antees. This kind of communication is often used in a
configurationphase or in a maintenance context. Individ-
ual parameters are addressed by an index and a subindex
which are coded into the message data. Depending on
the memory size of the requested device parameter several
CAN telegrams have to be passed from client to server and
vice versa, since the data has to be split up into CAN tele-
grams of fixed size. CANopen defines various protocols
for this purpose which are all supported by the Java CAN
API. If the parameter upload or download fails a special
SDO abort protocol is used to provide the error informa-
tion.
The protocols are hidden from the programmer,
who only uses the sendReadSdo0 and send-
WriteSdo ( ) methods (cf. Table 1). Both methods use
index and subindex parameters to select a specific
Device Profile entry. The requested CAN module is iden-
tified by the nodeId parameter of the SDO constructor.
In order to create a thin interface, all parameter values are
transferred as string values with an associated dataType
value. The supported data type values are defined in the
class DatuTypes according to [8]. The issupported ( )
predicate of this class can be used to check whether a spe-
cific data type is currently supported by the Java CAN API.
At the moment the Java CAN API supports Rea132, Visi-
ble String (arbitrary length) and all Unsignedllnteger data
types.
The size and timestamp parameters of the
sendReadSdo ( ) method receive the size and the time
stamp of the received Device Profile entry.
Both, the sendReadSdo ( ) and the send-
Wri teSdo ( ) method, return an integer error code if the
SDO transfer was aborted and throw a CanPortException
if a CAN communication error occurred. Several methods
are available to retrieve the CANopen error code, error
class and additional information of an aborted data
transfer.
Behind the scenes, the SDO class constructs the neces-
sary CAN telegrams, sends them to the CAN via the Can-
Port reference and collects and analyzes the response tele-
grams. The parameter values are de/en-coded according to
the specified data type by the class DataDecoder.
PDO communication CANopen Process Data Objects
(PDOs) are preconfigured messages used for high-speed
39
exchange of specific sets of Device Profile parameters.
The class PDO extends the CanMsg class by adding PDO
specific properties and functionality like setting the trans-
fer mode to synchronousor asynchronous for instance (cf.
Table 2).
The transmit frequency of synchronous transfers is de-
fined by the mute attribute that specifies the number of
Sync telegrams to be skipped.
The parameters receive, which, and moduleId,
of the PDO constructor select a specific PDO configura-
tion (e.g. receive PDO 1 on module 0x10).
Normally, the programmer does not use the PDO class
directly but one of the TransmitPDO or ReceivePDO
classes. They are directly derived from PDO and pro-
vide CAN real-time read and write access to Device Profile
data, respectively (cf. Table 2).
In order to get notified upon the arrival of specific
PDO telegrams on the CAN the programmer can instanti-
ate a correspondingTransmitPDO object. This object per-
forms the correspondingmessage subscription at the Can-
Port object and reports incoming telegrams to a PDOHan-
dler interface implementation by calling the correspond-
ing transmitPDOArrived( ) method (cf. Figure 1
on page 2 and Table 2). A set of methods (e.g. read-
Real32 ( ) ) is available for convenient extraction of the
transmit PDO data. The class that implements the PDO-
Handler interface has to be registered at the TransmitPDO
object with the addPDOHandler ( ) method.
The CANopenreceive PDO concept is encapsulated by
the ReceivePDO class. Specific PDOs can be instantiated,
loaded with data and sent to the CAN with a corresponding
send method (e.g. sendUnsigned32).
The Sync object Periodic CANopen Sync messages can
be generated by means of a the Sync class. Since this
class is derived from java.lang. Thread a Sync object can
be started with the start ( ) method. The CanPort refer-
ence and the sync frequency are specified in the construc-
tor.
2.3. NMT services
The CANopen node state diagram defines the set of
possible system states like init, pre-operational, opera-
tional etc. of a CANopen module. To offer the possibil-
ity to invoke transitions in the node state diagram of indi-
vidual nodes (e.g. during a boot-up procedure), the class
NMT was integrated into the Java CAN API (cf. Table 3).
Each state transition is mapped to a corresponding static
method which takes a CanPort reference and the module
ID as arguments.
3. The Java CAN API Example Application
This section presents the CanApiDemo Java applica-
tion that demonstrates some of the key features of the
Java CAN API. It reads a specific Device Profile entry of
 I Class I Method I Signature
U

SDO public SDO CanPortport, int nodeld

SDO public int sendReadSdo int index, int subindex, long[] result, StringBuffer value, int[]
size, long[] timestamp, int dataType
SDO public int sendWriteSdo int index, int subindex, String value, int dataType

Class Method Signature

PDO public PDO CanPort port, int moduleld, int which, boolean receive
PDO protected boolean setAsynchronous
PDO protected boolean setsynchronous int mute
TransmitPDO public readReal32 int (byteoffset)
TransmitPDO public void addPDOHandler PDOHandler handler
ReceivePDO public void sendUnsigned32 long value
PDOHandler public void transmitPDOArrived TransmitPDO src

an U 0 module by means of an SDO object, sets the out-
put lines with a ReceivePDO instance and catches the re-
sulting transmit PDO. The transmit PDO is generated by
the VO module because the output lines are connected to
its input lines (cf. Figure 3) and a state change in the in-
put lines triggers the VO module to send a corresponding
transmit PDO to the CAN. Furthermore, a concurrent log
object is created that logs all CAN messages to the console
for observation. The console output of the application is
depicted in Figure 4. The application is kept simple in
order to focus on the Java CAN API concepts and not on
Java programming language issues.
CAN Interface-
CAN-Fieldbus
CANopen I/O-
Module
Selectron DIOC711
Node ID: Ox10
Figure 3. CanApiDemo setup
Figure 4. The console output of CanApiDemo
3.1. The CanApiDemo class
Table 4 shows the Java source code for the CanApi-
Demo class which implements the main ( ) method. In
Lines 7 and 8, the CanPort instance is created, parame-
terized by the CAN bitrate (125000), the communication
channel (2), and the timer interval (0) which is not used
by this application. In order to monitor all generated CAN
telegrams on the connected CAN, a CanLog instance is al-
located in Line 9. The CanLog class will be described in
Section 3.3. The VO module with identifier Ox10 is set to
operational by means of a startRemoteNode ( ) (cf.
Section 2.3) method call in line 11.
The next step is to read the device name parameter of
the I/O module. This parameter is accessible through the
Device Profile entry at index 0x1008, subindex 0x0. An
SDO instance is created in line 14 to retrieve this param-
eter by means of the CANopen Initiate Domain Upload
and Upload Domain Segment protocol. The constructor
takes a reference to the responsible CAN communication
port and the CAN ID of the VO module. The code in
lines 15 to 19 allocates the SDO parameters used by the
sendReadSdo ( ) method (cf. Table 1 on page 4) in line
21. As pointed out before the Java CAN API transfers all
parameter values as Java strings. Since the requested pa-
rameter is of type Visible String the data type parameter is
set to DataTypes .VISIBLESTRING and no further
value decoding is necessary. If the call is successful, i.e.
no exception is thrown, lines 24 and 25 write the parame-
ter value and the time stamp to the console (cf. Figure 4).
Line 26 frees the resources occupied by the SDO object.
In the same way the output byte Device Profile param-
eter, representing the eight output lines of the U 0 module,
could be written by sending an SDO to the entry at index
0x6200, subindex Ox 1. The CanApiDemo performs an al-
ternative approach using PDO communication to achieve
the same effect. The corresponding ReceivePDO object is
instantiated in line 31 specifying the responsible CanPort

40
 I Class I Method
L
I Signature
-
I NMT 11 Dublic
-
static void startRemoteNode I CanPort nort. int moduleld
I

I I CanPort port, int moduleld

1 ,

NMT public static void resetNode

Table 3. NMT services (extract)

1:import de.uni-tuebingen.can.JCan.*; receive PDO is detected on the C A N the MyHandler class

2:import de.uni-tuebingen.can.CanProtocol.*;
3:
is notified.
4public class CanApiDemo{
5: public static void main(String(1 args){ 3.2. The MyHandler class
6: try{
I: CanPort port = 1:import de.uni-tuebingen.can.CanProtocol.*;
8: new ~anPort(125000, 2. 0 ) ; n
L:
9: CanLog log = new CanLog(port); 3:public class MyHandler
10 4: implements PDOHandler{
11: NMT.startRemoteNode(port, 0x10); 5:
12: Thread.sleep(1000); 6: public void
13: 7: transmitPDOError(String msg){
14: SDO sdo = new SDO(port, 0x10) ; 8: System.out .print ("\n PDO error:"+ msg) ;
15: long[] result = new long[ll; 9: }
16: StringBuffer value = 10
17: new StringBufferO; 11: public void
18: int[] size = new inttl]; 12: transmitPDOArrived(TransmitPD0 pdo){
19: long[] time = new long t11 ; 13: try{
20: 14: long value = pdo.readUnsignedB(0);
21: sdo.sendReadSdo(Ox1008, 0x0, result, 15: System.out .print ("\nPDO arrived:"+
22: value, size, time, 16: Long.toHexString(value) ) ;
23: DataTypes.VISIBLESTR1NG); 17: }
24: system.out .print ("\nValue: "+ value 18: catch (CanDataTypeException e ) { / * * / }
25: + "\nTime : "+ time [ 0 1 ) ; 19: }
26: sdo .cleanup( ; 20: }
21:
28: TransmitPDO tpdo =
29: new TransmitPDO(port, 0x10, 1);
Table 5. The MyHandler class
30: tpdo.addPDOHandler(new MyHandlerO ) ;
31: ReceivePDO rpdo = The MyHandler class (cf. Table 5) implements the
32: new ReceivePDO(port, 0x10, 1); PDOHandler interface that consists of the two methods
33: rpdo.sendUnsignedE(Ox20);
34:
transmitPDOError ( ) (cf. lines 7 to 9 of Table 5) and
35: sleep(1000) ; transmitPDOArrived( ) (cf. lines 12 to 19). The
36 NMT.resetNode(port, 0x10) ; first method is called on the arrival of a faulty PDO and
31: 1 provides an error message. The second method identifies
38: catch (CanPortException e){/* * / }
39: catch (CanDataTypeException e){/* * / }
the arrived PDO with the TransmitPDO parameter and al-
- -
40: catch (Excewtion -.
e){/* * / I lows the handler to decode the arrived data. The MyHan-
41: } dler class simply writes the arrived value to the console in
42: } lines 15 to 16. Since in the CanApiDemo class the Trans-
mitPDO instance was created before the creation of the
Table 4. The CanApiDemo class
ReceivePDO, the MyHandler instance is notified upon the
write access to the output lines and writes the new input
instance, module ID and PDO identifier. The sendun- byte value6 to standard out (cf. Figure 4 on page 4).
signed8 ( ) method call in line 33 uploads a single un-
signed byte value (0x20 in this case) to the PDO, sends it 3.3. The CanLog class
to the C A N and thereby activates the 5th output line of the The CanLog class (cf. Table 6) autonomouslymonitors
U 0 module. all C A N messages on the bus and writes them to the con-
The transfer mode for the first transmit PDO of the U 0 sole with a "log:" -prefix (cf. Figure 4 on page 4). The
module is event driven by default. Whenever the value data members of this class (lines 8 to 10 and 13 to 15)
of the input byte parameter (representing the eight input are used to hold C A N message data and time stamps. The
lines) changes, a corresponding transmit PDO is gener- constructor registers the created object at the CanPort in-
ated carrying the new input byte value. A corresponding stance to be asynchronously notified upon any message
TransmitPDO instance is created in line 28 (before the Re- detected on the CAN. This is done with a call to the ad-
ceivePDO creation) and a special PDOHandler object (a dEventlistener ( ) (line 17) and subscribeA1-
MyHandler in this case, cf. Table 5) is created and regis- lIDs ( ) (line 20) method (cf. Section 2.1) of the CanPort
tered at the TransmitPDO in line 30. Thus, whenever this 6due to the feedback lines depicted in Figure 3

41
 1:import de.uni-tuebingen.can.JCan.*; ous CAN server applications which act as bridges between
2:import de.uni-tuebingen.can.CanProtocol.*;
3: import java .util.* ; the Internet and the CAN fieldbus. The servers are im-
4: plemented on top of the Java CAN API and make exten-
5: public class CanLog sive use of the CANopen communication objects provided
6: implements CanPortEventListener{ there.
I:
8: private CanPort port; Complete parameter images of (running) CANopen au-
9: private byte[] data; tomation systems are produced by the Canlnvestigator
10: private long [ I time; Java component of the CANINSIGHT remote CAN field-
11: bus management system. Every parameter image consists
12: public CanLog (CanPort port) {
13: this.port = port; of a single XML document. The involved Device Pro-
1 4 data = new bytet81; files, the CAN system setup and the monitoring filters are
15: time = new long[l]; described by a further XML document. The XML doc-
16: try{ uments are instances of the CANopen Markup Language
17: port.addEventListener(this);
18: 1 (CoML,) which is described in [ 11.
19: catch (TooManyListenersException e){} An earlier application of the Java CAN API was a ba-
20 port.subscribeAllIDs(1, true); sic cliendserver system for the integration of arbitrary
21: 1 CANopen fieldbus devices into the World Wide Web [6].
22:
23: public void canEvent(CanP0rtEvent e){ The Java client for this system is available online at http:/l-
24: int msgId = e.getEventSrc0; robol6.fh-reutlingen.de/english/demo/jrcc.html.
25: try{
26: port.peakValue(msgId, data, time);
21: 1 5. Summary
28: catch (CanPortException ex){}
29: System. out .print (”\n--- log: ”+ The Java CAN API is a generic programming frame-
30: Integer. toHexString (msgId) + ”: ”) ; work for rapid Java CAN tool development. It provides
31: CanMsg.showMsg(data);
32: powerful abstractions for the CANopen communication
33: } objects, network management services and CAN layer 2
messages. In contrast to proprietary OPC solutions or
Table 6. The CanLog class programmable logic controllers it provides an open, ob-
ject oriented programming platform with few operating
system restrictions. The Java CAN API has proven its
instance. The addEventListener ( ) method takes a
usability in several automation engineering contexts like
CanPortEventListener as its argument. The CanLog class
teleservice, distance education, and fieldbus system man-
implements this interface and passes a reference to itself
agement.
(a this pointer) to the method. Thus, the CanLog class
handles all incoming CAN messages on its own and its im-
plementation of the CanPortEventListener .can-
References
Event ( ) method is called by the Java CAN API upon the D. Buhler. The CANopen Markup Language - Represent-
arrival of any CAN message. ing fieldbus data with XML. In Proc. of the 26th IEEE
The canEvent method retrieves the CAN message International Conference on Industrial Electronics, Con-
identifier in line 24 and the message data and time stamp trol and Instrumentation (IECON 2000), Nagoya, Japan,
in line 26. Lines 29 to 3 1 write the extracted information Oct. 2000. IEEE Computer Society Press (to appear).
to the console (cf. Figure 4 on page 4). D. Buhler and G . Gruhler. XML-based representation and
monitoring of CAN devices. In Proc. of the 7th Inter-
national CAN Conference (ICC 2000), Amsterdam, the
4. Practical Uses of the Java CAN API Netherlands, Oct. 2000. CAN in Automation (www.can-
cia.de) (to appear).
The Java CAN API was used for the implementation D. Buhler and W. Kuchlin. Remote fieldbus system man-
of a teleservice infrastructure for CANICANopen automa- agement with Java and XML. In Proc. of the IEEE Inter-
tion systems [ 111, the Virtual Automation Lab [4] and the national Symposium on Industrial Electronics ( N E2000),
XML-based CANINSIGHT fieldbus management system Puebla, Mexico, Dec. 2000. IEEE Computer Society Press
[3,21. (to appear).
The teleservice infrastructure offers the possibility to D.Buhler, W. Kuchlin, G. Gruhler, and G. Nusser. The
transparently transfer CAN messages over the Internet. As Virtual Automation Lab - Web based teaching of automa-
tion engineering concepts. In Proc. of the 7th IEEE In-
a result, a remote CAN can be accessed by locally installed
ternational Conference on the Engineering of Computer
standard diagnostic software tools. Based Systems (ECBS 2000). IEEE Computer Society
The Virtual Automation Lab [4] is an interactive Web- Press, April 2000.
based learning environment for both computer science and D. Buhler and G. Nusser. Java CAN API - Source
automation engineering students within a virtual univer- Code Documentation. http://robol6.fh-reutlingen.de/-
sity setting. Java applets provide user interfaces to vari- JavaCANAPYdocl.

42
 [6] D. Biihler, G. Nusser, G. Gruhler, and W. Kiichlin. A
Java client/server system for accessing arbitrary CANopen
fieldbus devices via the Intemet. South African Computer
Joumal, (24):239-243, Nov. 1999.
[7] Can In Automation (CIA) e.V., Erlangen. CANopen Com-
munication Projile for Industrial Systems, Based on CAL,
3.0 edition, 1996. CiA Draft Standard 301.
[SI Can In Automation (CiA) e.V., Erlangen. CMS Data Types
and Encoding Rules (DS202-3), 1996. CiA Draft Standard
202-3.
[9] Can In Automation (CiA) e.V., Erlangen. NMT Protocol
Spec$cation, Draft Standard 203-1, 203-2, 1996.
[lo] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design
Patterns: Elements of Reusable Object-OrientedSoftware.
Addison-Wesley, Reading, Massachusetts, 1995.
[ 111 G. Gruhler, G. Nusser, D. Buhler, and W. Kiichlin. Tele-
service of CAN systems via Intemet. In Proc. of the 6th
International CAN Conference (ICC 99), Torino (Italy),
Nov. 1999. CAN in Automation (www.can-cia.de).
[12] IS0 11898. Road Vehicles, Interchange of Digital Infor-
mation - ControllerArea Network (CAN)for High-speed
Communication, 1993.
[13] T. Lumpp, G. Gruhler, and W. Kuchlin. Virtual Java
devices-Integration of fieldbus based systems in the In-
temet. In Proc. of the 24th IEEE International Confer-
ence on Industrial Electronics, Control and Instrumenta-
tion (IECON ’98). Aachen, Germany, Sept. 1998. IEEE
Computer Society Press.
[14] J. Rumbaugh. The life of an object model: How the ob-
ject model changes during development. Joumal of Object
Oriented Programming, 7( 1):24 - 32, March I April 1994.
[15] J. Rumbaugh, M. Blaha, W. Premerlani, and E Eddy.
Object-OrientedModeling and Design. Prentice Hall, En-
glewood Cliffs, NJ, 1991.

Acknowledgement
This paper is based upon work conducted within the
research consortium VVL funded b y the state of Baden-
Wiirttemberg through the research initiative “Virtuelle
Hochschule”.

43