L.T. Yang et al. (Eds.): ICESS 2005, LNCS 3820, pp. 430 – 440, 2005. © Springer-Verlag Berlin Heidelberg 2005

An OSEK COM Compliant Communication Model for Smart Vehicle Environment

Guoqing Yang, Minde Zhao, Lei Wang, and Zhaohui Wu

College of Computer Science, Zhejiang University, Hangzhou, Zhejiang, China 310027

{ygq78, zmdd48, alwaysbeing, wzh}@zju.edu.cn

Abstract. Smart Vehicle Environment (SVE) is an important application of the idea of smart spaces. This paper presents Smart Vehicle Multi-Agent System (SVMAS) to achieve the goal of SVE and put forwards a commutation model for SVMAS based on SmartOSEK COM [1] to support data exchange. The pa-per also presents an approach to encapsulate the message to transport by CAN bus, and bring forward a simulator model for SVMAS. Finally the paper gives an example of the communication model which implements a dialogue between two agents and analyzes the performance. The contribution of our work is three-fold. First, we adopt Knowledge Query and Manipulation Language (KQML) to describe the communication in vehicles. Second, we develop SmartOSEK COM to implement communication in vehicles. Third, we define the ACLcan proto-col to transform the message from SmartOSEK COM to CAN frame.

1 Introduction

Weiser introduced the field of Ubiquitous Computing [2] and presented a vision of people and environments augmented with computational resources that provide in-formation and services when and where desired [3]. Smart spaces adopt the concept of ubiquitous computing, and embed computation resource and perceptive equipment into our daily life and working spaces [4]. Smart spaces offer active services by inter-connected embedded devices.

Smart Vehicle Environment (SVE) [5] is an important application of the idea of Smart spaces, and it turns the vehicle into a smart human-vehicle environment by advanced technology and equipments to gather, transmit and process the environment information. Therefore, Smart Vehicle Environment needs the cooperation of many disparate embedded devices in vehicles.

Smart Vehicle Multi-agent System (SVMAS) is a multi-agent system for SVE, which we develop to achieve the goal of SVE. In SVMAS, the function modules in SVE can cooperate with each other in form of agents. In order to implement SVMAS, we develop kinds of Electronic Control Units (ECUs) to accomplish the lamp control, window control, and door control in the vehicle. The ECUs are connected by Control-ler Area Networks (CAN) [6]. We develop the SmartOSEK COM to provide commu-nication support for the agents run in ECUs, and define ACLcan protocol to fill the gap between SmartOSEK COM and CAN.

An OSEK COM Compliant Communication Model for SVE 431

The remainder of this paper is organized as follows. Section 2 introduces the re-lated work of the field. Section 3 puts forward a framework of multi-agent system in smart vehicle (SVMAS). Section 4 provides a communication model for SVMAS. Section 5 presents an implementation for the communication model. Section 6 gives an example of the communication model for SVMAS which implements a dialogue between two agents. Finally, we conclude our paper in section 7.

2 Related Work

CAN (Controller Area Network) is a serial bus system, which was originally devel-oped for automotive applications in the early 1980's. The CAN protocol was interna-tionally standardized in 1993 as ISO 11898-1. CAN provides the basic services of the communication for automotive electronics, but users prefer to CAN application proto-cols to communicate easily. SAE's J1939 [7] standards family is the preferred control-ler area network (CAN) for equipment used in industries ranging from agriculture, construction, and fire/rescue to forestry, materials handling, and on- and off-highway. Although J1939 is a mature protocol for CAN application layer, it does support multi-agent system for the lacking of the ability of knowledge description.

OSEK/VDX is a joint project of the automotive industry. It aims at an industry standard for an open-ended architecture for distributed control units in vehicles [8] and put forward OSEK COM specification to increase the portability of application software modules by defining common software communication interfaces and be-haviors for internal communication (communication within an electronic control unit) and external communication (communication between networked vehicle nodes), which is independent of the communication protocol used [9].

OSEK COM offers services to exchange data between tasks and/or interrupt service routines. Different tasks may reside in the same ECU (internal communication) or in different ECUs (external communication). The aim of the OSEK COM specification is to support the portability, reusability and interoperability of application software. The Application Program Interface (API) hides the differences between internal and external communication as well as different communication protocols, bus systems and net-works. An OSEK COM implementation can run on many hardware platforms. The implementation shall require only a minimum of hardware resources, therefore different levels of functionality (conformance classes) are provided [9].

As OSEK COM specification is brought forward, we can achieve communication in vehicles easily, and we can integrate Knowledge Query and Manipulation Lan-guage (KQML) [10] together with OSEK COM into a communication platform to achieve communication between agents.

Some platforms compliant with OSEK COM specification have been developed such as OSEKTurbo, OSEKWorks and OSCan, etc, but none of them have been ap-plied into multi-agent system.

In this paper, we put forward SVMAS by which we apply the multi-agent system into the field of automotive electronics to achieve the goal of SVE, and describe the information in smart vehicle environment by agent communication language (ACL) [11], and we develop a communication software platform according to OSEK COM to fulfill the communication requirement in automotive electronics.

432 G. Yang et al.

3 The Agent Framework of SVMAS

The paper puts forward SVMAS to assist the driver to finish complex operations. Using SVMAS, all ECUs in the car can share the information, cooperate with each other, and can accomplish complex tasks as a whole.

USER

Identifier

Agent

USER

Broker

Steering

Agent

Comfort

Agent

Engine

Agent

AMT

Agent

Air-condition

Agent

Lamp

Agent

Sensitometer

Agent

Fig. 1. Agent framework of SVMAS

As there are differences in processing ability and function among ECUs in SVE, the abilities of agent in every ECU are different too. We classify agents of SVMAS into different hierarchies: task agent and function agent. Task agent is used to accom-plish grand tasks that require the collaborative work of many function units. Function agent undertakes small tasks that can be done by smaller ECU individually.

Each ECU has a function agent. Tasks agent partition the task into smaller ones and then hand them over to different function agents. At the mean time task agents are in charge of the coordination of different function agents. The coordinator of function agents is dynamic. The goal of coordination is achieved by passing messages and negotiations.

The agent framework of SVMAS is shown in Fig. 1. There are different types of agents in the framework. They are interrelated with each other. When a driver enters SVE, agents are started, and services are provided initiatively. Firstly an USER Bro-ker is assigned to the user, and then the USER Broker would contact with SVMAS instead of the user. Identifier Agent would identify the user. If the user has the legal identity, he can obtain kinds of services provided by SVMAS, such as starting the car, starting the air conditioner, etc. The service of starting the car is provided by Steering Agent, which is a task agent. Steering Agent divides the function of starting car into opening the engine, modulating the state of AMT, and operating the car lamp etc. Opening the engine is finished by Engine Agent, and operating the car lamp is fin-ished by Lamp Agent. When the function agent accomplishes the given function, it needs to communicate with other function agents. For example, Lamp Agent needs the information of lightness when it accomplishes the lamp operating, and it needs to communicate with Sensitometer Agent to obtain the information of lightness. For the method of agent communication, we will give an example of the dialogue between two agents in section 6.

An OSEK COM Compliant Communication Model for SVE 433

4 The Communication Model for SVMAS

The communication model for SVMAS is shown in Fig. 2. Communication is the key for agents to share the information they collected, and to coordinate their actions. In the communication model for SVMAS, four layers are brought forward as follows: agent layer, SmartOSEK COM layer, ACLcan layer, and underlying networks layer. In agent layer, the communication form of SVMAS is dialogue; in SmartOSEK COM layer, the communication form of SVMAS is message; in ACLcan layer, the commu-nication form of SVMAS is CAN frame defined by ACLcan; and in underlying net-works layer, the communication form of SVMAS is electric signal.

The communication between agents is described in KQML, a well known ACL, and it is in dialogue form. The dialogue could be transformed into messages in Smar-tOSEK COM. ACLcan protocol processes the messages from SmartOSEK COM, and transforms them into the CAN frame form, and then sends them out by CAN Bus.

In SVMAS, we describe dialogues between agents in KQML to improve the com-patibility of the communication model, so each agent should have a parser of KQML. The parser interprets the performative of KQML, by which the agents can understand each other.

For SVMAS, we adopt CAN bus as the underlying communication protocol be-cause CAN is developed specially as a communication bus to in-vehicle networks and has high performance. Thus, the innovation of our SmartOSEK COM is to integrate OSEK to CAN bus, and to provide an approach to set the frame ID of CAN. We de-velop ACLcan protocol as the interface between SmartOSEK COM and CAN bus. In ACLcan, the frame ID of CAN is set according to the ECUs’ addresses of sender and receiver and the agent identifiers of sender and receiver. Moreover, the performative of ACL is also considered in the frame ID of CAN.

Fig. 2. The communication model for SVMAS

5 The Implementation of the Communication Model for SVMAS

To implement the communication model for SVMAS, we develop SmartOSEK COM which is a specialized communication platform for automobile electronics, and

434 G. Yang et al.

develop ACLcan which is a protocol to convert a message from SmartOSEK COM to CAN bus frame.

5.1 KQML: The Agent Communication Language for SVMAS

In the multi-agent system field, the exchange of knowledge among disparate com-puter systems is the most important. Knowledge Interchange Format (KIF) [12] is a language designed for the exchange of knowledge among disparate computer systems. It has declarative semantics; it is logically comprehensive; it provides for the repre-sentation of knowledge about the representation of knowledge, and provides for the definition of objects, functions, and relations. Recently, research on multi-agent sys-tem makes great progress. Agents contact with each other by Agent Communication Language (ACL). KQML, a well known ACL, is a part of the ARPA Knowledge Sharing Effort and is developed as an agent communication language and protocol for exchanging information and knowledge. Agents can use KQML to communicate attitudes about information, such as querying, stating, believing, requiring and sub-scribing.

As the research of multi-agent system in vehicles is deficient and few works have been done to apply KQML into automotive electronics field, we adopt KQML to describe the information to interchange between agents in vehicles, and the descrip-tion in KQML can be parsed by agent itself and others.

5.2 SmartOSEK COM: The Foundation of Communication for SVMAS

According to OSEK/VDX specifications, we develop the SmartOSEK system. Smar-tOSEK system includes SmartOSEK OS compliant with the OSEK/VDX Operating System specification [13] and SmartOSEK COM (compliant with the OSEK/VDX Communication specification).

SmartOSEK COM is based on messages. A message contains application-specific data. Messages and message properties are configured statically in the OSEK Imple-mentation Language (OIL) [14]. The content and usage of messages is not relevant to SmartOSEK COM.

SmartOSEK COM supports two kinds of communications, internal communication and external communication. Interaction Layer (IL), an important part of SmartO-SEK, provides users with the OSEK COM API which contains services for the trans-fer (send and receive operations) of messages. In the case of internal communication, the IL makes the message data immediately available to the receiver. In the case of external communication the IL packs one or more messages into assigned Interaction Layer Protocol Data Units (I-PDU) and passes them to the underlying layer.

Administration of messages is done in the IL based on message objects. Message objects exist on the sending side (sending message object) and on the receiving side (receiving message object). The data communicated between the IL and the underly-ing layer is organized into I-PDUs which contain one or more messages. The IL offers an API to handle messages. The API provides services for initialization, data transfer and communication management. Services transmitting messages over network are non-blocking. SmartOSEK COM provides notification mechanisms for an application to determine the status of a transmission or reception [9].

An OSEK COM Compliant Communication Model for SVE 435

5.3 ACLcan: The Interface Between SmartOSEK COM and CAN Bus

In SVMAS, agents communicate with each other under the message mechanism. The communication mechanism based on message is provided by SmartOSEK COM. We transform the message in KQML to message into the message in SmartOSEK COM. The message in SmartOSEK COM is defined in OIL [15]. Each message in SmartO-SEK COM is described by a set of attributes and references, and in SVMAS, each performative in KQML has a corresponding kind of message.

7 6 5 4 3 2 1 0

Byte1 Frame Format RTR X X DLC

Byte2 ID.28-ID.21(sender’s node address)

Byte3 ID.20-ID.13(receiver’s node address)

Byte4 ID.12-ID.7(performative) ID.6-ID.5(sender)

Byte5 ID.4(sender) ID.3-ID.1(receiver) ID0(Type) X X X

Byte6 Index of Message Content

Byte7

..

Byte13

Message Content

Fig. 3. CAN frame format in ACLcan protocol

ACLcan is the interface between SmartOSEK and CAN Bus. Since we choose CAN as the network communication bus for SVMAS, the transmission of the mes-sage between agents in SVMAS will use the CAN BUS. The ID of each CAN frame is defined in message and each message has a unique CAN ID. We develop ACLcan to configure the CAN frame’s ID. The configuration mechanism of CAN ID in the message is shown in Fig. 3. In SVMAS, every transmission of message uses extended frame. The frame header of the extended frame has 29 bits (ID.28-ID.0) to show the ID of the CAN extended frame. ID.28-ID.21 is the sender’s node address. We give each ECU in SVMAS a unique node address. In CAN ID, we use 8 bits to denote the node address, thus 256 nodes are admitted at most in SVMAS. ID.20-ID.13 is the receiver’s node address. ID.12-ID.7 is the identifier of KQML performative. Each performative is accorded with a unique ID. ID.6-ID.4 is the agent identifier of sender. We identify the agents of each ECU, and agents in different ECU can use the same agent identifier. ID.3-ID.1 is the agent identifier of receiver. ID.0 shows whether the message is simple frame or multiple frames. If ID.0 is 1, then the message is multiple frames. In CAN frame format, the content of Byte6 shows the index of the frame in the message, or else it shows the content of message.

5.4 Simulation of the SVMAS

We develop Smart Simulator to provide the ability of simulation to evaluate the per-formance of communication of the multi-agent system by the included sub-simulators.

436 G. Yang et al.

The architecture of Smart Simulator is shown in Fig. 4. The simulator provides Smart OSEK COM Simulator to simulate the communication compliant with OSEK/VDX, and SmartOSEK OS Simulator to simulate the scheduling of the tasks. For external communication between ECUs, the simulator provides CAN Simulator to simulate the in-vehicle networks. As a real system has inputs and outputs, the simulator also pro-vides Interrupt Simulator and Actuator Simulator to simulate the signal inputs and outputs.

Interrupt Simulator

Actuator Sim

ulator

Fig. 4. The Architecture of Smart Simulator

In the simulator, the messages are classified into two types, one is internal message denoted by IMessage and the other is external message denoted by OMessage. The agents communicate in the same ECU by IMessage, and the communication process is simulated by SmartOSEK COM Simulator. When an agent communicates with an agent in other ECUs by OMessage through CAN bus, CAN Simulator would firstly encapsulate the message into CAN frame and decapsulate it after a delay according to the baud rate of CAN bus. ACLcan Simulator would encapsulate and decapsulate the OMessage by the ACLcan protocol. The simulation results are displayed by Smart Monitor and saved into files which the developers can refer to modify the network configuration. Smart Simulator simulates the running process of the system, and the temporal behavior of the system.

6 A Case Study of the Communication Model for SVMAS

In this section, we give an example of communication model for SVMAS. Suppose there are two agents, one is named Lamp and the other one is Sensitometer, as shown in Fig. 5. The scenario we assume is that when it becomes dark, the Lamp Agent needs the information of the lighteness to decide whether it should open the lamp or not, thus it needs to communicate with Sensitometer Agent to obtain the information of lightness.

An OSEK COM Compliant Communication Model for SVE 437

Fig. 5. Communication example of SVMAS

Dialogue ( Example ) (evaluate :sender Lamp :receiver Sensitometer :language KIF :ontology LampControl :reply-with q1 :content ( val ( luminance L1 ) ) ) (reply :sender Sensitometer :receiver Lamp :language KIF :ontology LampControl :reply-with q1 :content ( = (luminance L1 ) (scalar 880 lumen) ) )

Fig. 6. Dialogue Example in KQML

MESSAGE evaluate { TYPE = EXTERNAL; LENGTH=5; QUEUED = False; TRANSMISSION = DIRECT; IPDU = lamp_control; NOTIFICATION = FLAG { FLAGNAME = "require_luminance"; }; CANID = Get_Can_ID (evaluate, Lamp, Sensitometer) }; MESSAGE reply { TYPE = EXTERNAL; LENGTH=5; QUEUED = False; TRANSMISSION = DIRECT; IPDU = lamp_control; NOTIFICATION = FLAG { FLAGNAME = "respond_luminance"; }; CANAID = Get_Can_ID (reply, Sensitometer, Lamp) };

Fig. 7. Messages defined in OIL

Lamp agent and Sensitometer agent process a dialogue for the lighteness of the current environment, and we use KQML to describe this dialogue as shown in Fig. 6 [16]. Firstly, lamp sends a message to request for the lightness. The format of the

438 G. Yang et al.

message uses KIF, and the request is defined as ql. The message is sent by SmartO-SEK COM via CAN Bus. The ontology of the dialogue is defined as “LampControl”. After receiving the message, Sensitometer sends the request result to lamp via another message. Definitions of these two messages for the dialogue are shown in Fig. 7.

The first message is “evaluate”, and it is an external message which can provide communication between ECUs. The CAN ID of “evaluate” defines the ID of CAN frame. When the message is sent, a flag named “require_luminance” would be set.

The agent Lamp could tell agent Sensitometer about its requirement by calling a SmartOSEK API SendMessage. Then the requirement of Agent Lamp would be trans-formed into message in predefined format. Subsequently, messages would be split into CAN frames in order to be transmitted on CAN bus, and ACLcan protocol would participate in setting the CAN frame’s ID. When the agent Sensitometer receives the requirement of Lamp, it would decode the CAN frame, and find the requirement of the agent Lamp.

In the example, the “evaluate” has a CAN ID as “0x01020490”. In the same way the “reply” has a CAN ID as “0x02010590” by ACLcan.

Fig. 8. Scenario of the Communication Model for SVMAS

To evaluate the performance of the communication model for SVMAS, we meas-ure the time of the process on CPUs by Smart Simulator. In the simulator, we set the CAN bus baud rate at 125kbps and configure the CPU as MPC555. Fig. 9 shows the simulation results. To test the real performance of the model on CAN bus, we ex-periment the example by the hardware platform MPC555. As shown in Fig.8, in the experimentation, the sensitometer gets the lighteness of the environment, and sends the information to the lamp by the communication model we present. When the room becomes dark, the lamp would be lighted. We set the CAN bus baud rate as the same with the simulator, and measure three parameters, the encapsulation time and the decapsulation time by the logic analysis device LA5540 at 50MHz. For each parame-ter, we have measured ten times and the minimum time, maximum time and average time are shown in Fig. 9.

An OSEK COM Compliant Communication Model for SVE 439

As shown in Fig. 9, we find the average time of decapsulation is 53.46us and it is a little faster than the average time of encapsulation, which is 56.38us because of adopt-ing speculative arithmetic. As the average times of decapsulation and encapsulation are about only 8 times than the task switch time in SmartOSEK OS which is 7.6us, we can draw the conclusion that the communication model for SVMAS we present is applicative and has high performance, and is suitable to develop automotive electron-ics software.

Fig. 9. Simulation and experiment results of the communication model for SVMAS

7 Conclusion

In this paper we make a valiant try in smart spaces field, and put forward a communi-cation model for SVMAS. The innovation is applying agent communication lan-guage-KQML to SVMAS and adopting CAN bus as the underlying networks for agent communication. Moreover, we develop ACLcan protocol to provide good sup-port for the CAN based communication of agents. In the example of the communica-tion model for SVMAS, we accomplish a dialogue between two agents and get good results in our simulation and experimentation, thus the cooperation of multiple agents could be achieved easily by dialogues among agents. The communication platform we present works well, and is suitable to develop automotive electronics devices.

Acknowledgement

This work is supported by 863 National High Technology Program under Grant No. 2003AA1Z2140 and No. 2004AA1Z2180.

440 G. Yang et al.

References

1. Minde Zhao, Zhaohui Wu, Guoqing Yang, Lei Wang, Wei Chen: SmartOSEK: A Depend-able Platform for Automobile Electronics. The First International Conference on Embed-ded Software and System. (2004), vol. Springer-Verlag GmbH ISSN: 0302-9743, pp. 437.

2. Mark Weiser: The Computer for the 21st Century. Scientific American. (1991) pp. 94-100. 3. Gregory D.Abowd, Elizabeth D. Mynatt: Charting Past, Present, and Future Research in

Ubiquitous Computing. ACM Transactions on Computer-Human Interaction. (2000), vol. 7, No. 1.

4. Michael Coen: Design Principles for Intelligent Environments. Proceedings of The Fif-teenth National Conference on Artificial Intelligence. (Madison Wisconsin, 1998).

5. Guoqing Yang, Zhaohui Wu, Xiumei Li, Wei Chen: SVE: Embedded Agent Based Smart Vehicle Environment. The 2003 IEEE International Conference on Intelligent Transporta-tion Systems. (2003).

6. Cia: CAN. http://www.can-cia.de/can/. 7. Sae: J1939. http://www.sae.org/standardsdev/groundvehicle/j1939.htm. 8. Osek/Vdx: OSEK/VDX Binding Specification Version 1.4.1. (2003). http://www.

osek-vdx. 9. Osek/Vdx: OSEK/VDX Communication Specification Version 3.0.3. (2004).

http://www.osek-vdx.org. 10. T.Finin, J.Weber, G.Wiederhold, M.Genesereth: Specification of the KQML agent com-

munication language. DARPA knowledge sharing initiative external interfaces working group. (Enterprise Integration Technologies, University of Toronto, 1994).

11. Munindar P.Singh: Agent Communication Languages: Rethinking the Principles. IEEE Computer. (1998), vol. 31, pp. 40--47.

12. Matt Ginsberg: Knowledge interchange format: The KIF of death. AI Magazine. (1991). http://logic.stanford.edu/kif/dpans.html.

13. Osek/Vdx: OSEK/VDX Operating System Specification Version 2.2.2. (2004). http://www.osek-vdx.org.

14. Osek/Vdx: OSEK/VDX OSEK Implementation Language Specification Version 2.4.1. (2003). http://www.osek-vdx.org.

15. Joseph Lemieux: Programming in the OSEK/VDX Environment. (CMP Books, 2001). 16. Michael Wooldridge: An Introduction to Multiagent systems. (John Wiley&Son, Inc,

2002).