Architecture of the Network for Model Based Development of Java Distributed Applications for Embedded Devices

Csar Allain Pacheco

*

allain@kiv.zcu.cz

Abstract
This work presents an Architecture of the Network for model based development of Java distributed applications for embedded devices. The model is based on time serialization of threads of the control program, which is accomplished with the J-Serializer. The proposed method uses two kind of computer-environment: control interface, between a computer node and its part of controlled device; and network interface, a serial bus interface. The model of the network is inspired in the messagepassing paradigm, asynchronous message passing without blocking.

1. Introduction
Working in a distributed computer environment is a very interesting but not a very easy task, mainly when one wants to simulate and verify the correctness of the application. Many general and special purpose programming languages have been developed over the years, that is a nearly impossible task to decide which language best fits or even a near best fit to any particular application [1]. Over 170 programming languages were in use in the United States in 1972 [2] and today there are even more. We have chosen a language that will be complain with portability and tightly integrated support for threads, which enables developing distributed applications not depending of the software platform or hardware you chose. For that reason, Java is among other languages, e.g. C++, Smalltalk and Simula, that better fit for our goal. As a result, in recent years, the number of Java embedded applications has been growing constantly e.g. mobile phones, PDAs, and consumer electronic devices. Java was conceived from the beginning as a language for embedded applications. The demand of the world market increases the number of applications for those devices [3]. An unresolved question is the verification of correctness of a concurrent Java program. The model (method) that we present is not a theoretical one. This experimental method proofs the correctness of the concurrent program in a distributed embedded environment. The method not guarantees the total correctness, but it is the best approach to the proposed solution. Sequential programs have just one possible path of execution in a time unit. A distributed program leads us to many possibilities of execution in the same portion of time, so proving the correctness of such a program is very complicated or even impossible to deal with.

2. Model Architecture Overview

In a previous work [4] is explained a model of testing an verification of Java concurrent control programs aimed to embedded devices, in where threads of the control program are mapped onto a simulation process that can be executed using discrete model-time concept. This model is accomplished by using the J-Sim program simulation of the surrounding environment and the model of the simulation itself, even before the real hardware is developed. The extension of this task to a distributed embedded simulation model is the aim of this work. Roughly, in order to reach this objective we must create the model of the communication
* Ing., University of West Bohemia in Pilsen. Faculty of Applied Sciences. Department of Computer Science and Engineering, Univerzitn 8, CZ 30614 Plze

interface between a node and network. For that reason, first we present a model structure of a node, followed by the model of the network and describing the methods and classes that we are going to use. 2.1. Model Structure In this section, we describe the structure of the simulation. We have N-nodes into the network. The nodes represent a processor or a device that we want to simulate. Let us show in the first place, the structure of a node: 2.1.1. Structure of a node In the figure showed below, we present the structure of a node of the distributed embedded simulation. As we said before, we need two kinds of interface connection (IC). One of them, between the node and hardware (registers) that is achieved through the Java Native Interface (JNI), which read/write data from/to controlled hardware, registers. (e.g. tank, pumps and sensors). The second one is used to communicate to the network, for that purpose we take in account the medium and buffers. Is important to take into account that we have two kinds of nodes, 1-node for the main tank and N-nodes for the stations. (See figure 1).

IC to Network A B

Network Network Model (medium + buffers)

Application

(Java + JiJ) A B Hardware Model (registers)

IC to HW computer

Model Controlled Environment (tank, pumps, sensors)

Figure 1. The model of a node in the network 2.1.2. Model of the Network In this section we will concentrate in emphasizing the differences between two models of network, in order to decide which of them better suits with our goals. 2.1.2.1. Master Slave Network Protocol Master Slave protocol, is a strategy for node communication in where a single master device allots time slots for all the other nodes on the network to transmit, and schedules these time slots so that multiple nodes cannot collide. The master device addresses each node by name, one at a time, letting that node talk for a certain amount of time. When it is finished, the master addresses the next node, and so on, and so on. [5]. In this contest the master node might have the following functions:

Sender(sendDatagram), master sends a message to all the nodes e.g. if all the nodes are working correctly (e.g. the level of water is not under or above the limits, or if are there at least K working bombs, etc.) see Case Study. Receiver(recvDatagram), all nodes answering to the send message of the master node. Master node evaluates all the responses and does the correction if it is necessary (e.g. turn the pump off/on in order to control the water level in each water station). Each node will have the following functions: Acknowledge(respDatagram), message was received without troubles. Response(acknDatagram), send message to the master node, responding for the claimed task. 2.1.2.2. Multi Master Network Protocol Multi Master protocol, where each node gets a turn to talk (one at a time), and then grants permission for the next node to talk when it is done. Permission to talk is passed around from node to node as each one hands off the "token" to the next in sequential order. The token itself is not a physical thing: it is a series of binary 1's and 0's broadcast on the network, carrying a specific address of the next node permitted to talk. Although token-passing protocol is often associated with ring-topology networks, it is not restricted to any topology in particular. Moreover, when this protocol is implemented in a ring network, the sequence of token passing does not have to follow the physical connection sequence of the ring [5]. In the Multi-master model the communication among the nodes will b0e achievable through message passing paradigm. There are two types of this paradigm, synchronous and asynchronous. We well explain the advantages and disadvantages of each one, concluding that in our proposed model the asynchronous one suit better our model. 2.1.2.2.1. Synchronous Message Passing The program that initiates the send (receive) waits until the send (receive) is complete. This waiting is called blocking. Completion of a send only means that the message buffer can be reused and does not imply that the message has been received. ssend() and srecv() are the synchronous send and receive system calls. This model suits better in a tightly coupled computer environment where there is a multiprocessor system sharing memory. But in the distributed setting synchronous external calls seem less satisfactory; at best resulting in inefficient use of processor capacity, at worst resulting in deadlock. Furthermore, it is difficult to combine active and passive behavior in concurrent objects. It is clearly less suitable in a distributed setting with loosely coupled components. 2.1.2.2.2 Asynchronous Message Passing In the other hand, asynchronous message passing gives better control and efficiency, but lacks the structure and discipline inherent in method calls. The integration of the message concept in the object-oriented setting is unsettled, especially with respect to inheritance and redefinition. An object offers methods to its environment, specified through a number of interfaces and co-interfaces. All interaction with an object happens through method calls. In the asynchronous setting method, calls can always be emitted, because the receiving object cannot block communication. Method overtaking is allowed: if methods offered by an object are invoked in one order, the object may start the method instances in another order. A method instance is, roughly speaking, program code with nested processor release points, evaluated in the context of local variables. Due to the possible interleaving of different method executions, the values of an objects program variables are not entirely controlled by a method instance, which suspends itself before completion. A method may have local variables supplementing the object variables. In particular, the values of formal parameters are stored locally, but other local

variables may also been created. asend() and areceive() are the asynchronous send and receive system calls. An asynchronous send or receive does not block. It returns a unique message id, which can be used later to check for completion of the message. Implementation of Asynchronous Message Passing In order to follow the develop of this method, we have to take into account several conditions: Conditions Tested media is a serial bus. We will use an asynchronous message passing. In this case there are two alternatives: blocked and unblocked asend(), areceive() functions. For the simplicity let get the unblocked situation. Node addresses are integer numbers in the interval 1 to n. We transmit a frame of fixed length of 256 bytes (for example).(see figure 2) Each node has one unlimited buffer for sending and one for receiving. Multiple access (M.A.) is implemented in the same way as in Ethernet it is when a medium is occupied then the station is randomly waiting for a period of time.

Program solution We build an abstract class NetworkInterface (Java IC) in that two functions are built. Figure 3-A. asend( adrNode, frame) frame areceive(adrNode) adrNode = 0, broadcast. adrNode = 0, accept each message. return null = nothing is incoming.

Type Frame

Address 1-n Index connection 256 bytes of data

Figure 2. Architecture of a Frame Implementation (model) (5 classes) (figure 3-B) - Frame sent message

sendBuffer passive object is composed by: message queue for sending reference to sending thread SendThread Implementation of asend(). Put one frame to buffer (queue) and awakes the thread. Function (method) transmitFrame(RecBuffer buf) uses sending thread to own transfer message.

Implementation of SendThread and ReceiveBuffer SendThread . This is a thread that sends message (J-Sim process), contains: Reference to own buffer of type SendBuffer. Reference to shared objects serial bus. Method run() (J-Sim), which follows algorithm:

Application

Network Interface

Network model

A Figure 3. Model Interfaces

1. Takes a message from sendBuffer. ( if there arent then passivate() ) (J-sim). 2. Test serialBus, if bus is free then gives the address (reference) from receive buffer then 3, else 4 3. Hold(sending time), transmitFrame(receiveBuffer), free seriaBus release() goto 1 4. If not free then hold(randomize time) then goto 2 ReceiveBuffer. Receiving buffer (analogous like SendBuffer) SerialBus. (One for the entire network model). Serial bus model is passive and has: Attribute occupied bus, type Boolean Reference array to receiving buffers Method RecBufferTestBus( int adrNode) (returns either null or occupied, or reference to buffer, then we can start sending). Method releaseBus() release bus when transmission ends. See figure 4. Connections is done by Java references that is showed in the figure 5.

3. Case Study
A case study has been development. It is an abstract embedded application that controls water level of a water station tank and several connected water sources.

Network IC
1 SendBuffer

Application 1 HW IC Network IC HW IC Application 2

1 ReceiveBuffer 1 SendThread

S E R I A L B U S

1 SendBuffer 1 ReceiveBuffer 1 SendThread

Network model

Figure 4. Model for two nodes The first prototype was theoretically and practically developed in [4]. Here we concentrate our effort in the distributed embedded application form. Then we have to use two kinds of computer-environment interface control interface (i.e. between a computer node and its part of controlled device) as well as network interface (i.e. a serial bus interface). Obviously, the model complexity will arise fast, because the model should include all the nodes of distributed system and a sub-model of communication protocol as well [6].
Connection Network Model

n Application

Communication Communication Communication Controller Controller Controller Model Model Model

Network IC

Network Model Figure 5. Model for N-nodes 4. Conclusion and Future Work Further work will be focused mainly on customization of the Java source code conversion tool for purposes of this project and also on the J-Sim JiJ (Java in Java) sub package

improvements and extensions. The set of demonstration applications will be extended in order to gain more experience. We plan to extend this set for distributed environment using e.g. CAN (Controlled Area Network) or TTP (Time Triggered Protocol) serial bus based control application as well. The Controller Area Network (CAN) and the Time-Triggered Protocol (TTP) are two fundamentally different communication protocols for the design of distributed real-time systems. CAN belong to the class of event triggered protocols where the class of event-triggered protocol where the temporal control signals is derived primarily from non-time events occurring outside or inside the computer system. CAN was originally developed for non-safety critical body-electronics applications within vehicles. TTP belongs to the class of time triggered-protocols, where the temporal control signals are solely derived from the progression of time. TTP was originally developed for high-dependability hard real-time applications, where timely error detection and fault-tolerance must be provided. We are currently study the background of CAN and TTP. The paper presents a method of a model based development and (partial) verification of concurrent Java-written control programs that are embedded within a device. The method combines model-time serialization of the control program threads with the conventional discrete time simulation of the control program environment. Unlike other existing methods, it is an experimental, method targeted on testing real Java code and not a theoretical system model. Moreover, the method does not require any especial Java virtual machine and is convenient for non-terminating programs running in a distributed environment. The method takes into account the control program environment behavior and tests both parts of the (designed) control system together which is completely omitted in other program verification approaches. This work has been supported by the Grant Agency of Czech Republic grants No. 102/03/0762 "Research of methods and tools for verification of embedded computer system fault". References [1] Robert E. Shannon.: Introduction to Simulation Languages. Winter Simulation Conference. Proceedings of the 9th conference on Winter Simulation Volume 1. Gaitherburg, Maryland, United States. Pages 14-20. Publication year 1977. [2] Jean E. Sammet.: Programming Languages: history and future. Communications of the ACM, v.15 n.7, p.601-610, July 1972. Jaroslav Kaer, Stanislav Racek.: Model Based Development of Java Embedded Applications, [Extended Abstract], Book of Abstracts of the 5th EuroSim Congress on Modeling and Simulation, EuroSim-FrancoSim-ArgeSim, Francie, z 2004 ISBN 3-901608-28-1, Strany: 84-85. Jaroslav Kaer.: Model Based Development of Java Embedded Applications. Technical Report No. DCSE/TR-2004-03. Version 1. University of West Bohemia in Pilsen, Faculty of Applied Sciences, Department of Computer Science and Engineering, Pilsen, Czech Republic, September 2004. Language: English. Kopetz H.: Real Time Systems, Design Principles for Distributed Embedded Applications. Kluwer Academic Publishers, 1997. FIT Fault Injection for TTA. http://www.fit.zcu.cz

[3]

[4]

[5]

[6]