rigo-allain rig final01

8/2/2019 Rigo-Allain Rig Final01

http://slidepdf.com/reader/full/rigo-allain-rig-final01 1/35

University of West Bohemia in PilsenDepartment of Computer Science and Engineering

Univerzitní 830614 PilsenCzech Republic

Model – Based Development of JavaDistributed Applications for Embedded

DevicesCésar Allain Pacheco



Model – Based Development of JavaDistributed Applications for EmbeddedDevices

César Allain Pacheco

Abstract

With the reduction in price of the computers, the information systems havesuffered a radical change. From the centralized paradigm, in which the main

applications resided in a central mainframe computer, to the decentralizedparadigm in which many personal computers share applications, besides tohave a local power computation, has changed totally the form of conception of all enterprise information systems. Therefore, the applications, that arecomposed the information systems, have to be rethinking from a centralized todistributed one. Anybody who had created programs in any programminglanguage knows that the worse part or the tedious part of this work resides inthe verification and testing programs. This task in a sequential application thatruns in one processor is also very hard to achieve but the results obtained invarious executions is the same and reliable. The former is not valid for distributed applications that run in several processors. The results after each

running are unpredictable, making the process of debugging and testing verydifficult and sometimes impossible. The task becomes more complex if we takeinto account that this distributed application will be implemented on a realhardware after testing and debugging. This task will have an effect on the costselevation of the manufacture. Create a method that can help to achieve andrelieve this problematic of verification and testing concurrent programs for embedded devices written in Java is the goal of this work.So, this work presents a model – based development of Java distributedapplications for embedded devices. The model is based on time serialization of threads of the control program, which is accomplished with the J-Serializer. Theproposed method uses two kind of computer-environment: control interface,between a computer node and its part of controlled device; and networkinterface, a serial bus interface. A first approach to this work has beendeveloped; it includes a model of the environment and the application program.

2



Contents

1. Introduction 5

2. Related Work 62.1. Background of Parallel and Distributed Simulation 62.1.1. Analytical Simulation 62.1.1.1. Conservative Synchronization 72.1.1.2. Optimistic synchronization 9

2.1.2. Virtual Environments and Real-Time Simulation 92.1.2.1. High Level Architecture (HLA) 102.2. Best Known Theoretical Methods of Testing and Verification of

Software Review Overview 122.2.1. Petri Nets 122.2.2. π-Calculus 132.2.3. LTSA – Labeled Transition System Analyzer 132.2.4. The Model Checker SPIN – Checking Formal Models 132.2.5. Java PathFinder 1 – Constructing Formal Models from Java

Multithreaded Programs 142.2.6. Bandera – Model – Checking Propierties of Concurrent

Java Software 142.2.7. The Model Checker Verisoft – Checking UNIX Concurrent Systems

142.2.8. An Executable Model of Java Programs – The ExitBlock Algorithm

152.2.9. Java PathFinder 2 – Executable Models of the Java

Virtual Machine 15

Model Architecture Overview 163.1. Model Structure 163.1.1. Structure of a Node 163.1.2. Model of the Network 173.1.2.1. Master – Slave Network Protocol 163.1.2.2. Multi – Master Network Protocol 183.1.2.2.1. Synchronous Message Passing 193.1.2.2.2. Asynchronous Message Passing 203.1.3. The Model of the Simulation on the Network 18

4. Control Program Verification Procedure 244.1. The Verification Procedure 244.2 The State Invariants and the Behavioral Protocols 24

3



5. Case Study 26

6. Conclusion and Future Work 27References 29

4



List of Figures

Figure 1: Local control mechanism in optimistic synchronization protocols

Figure 2: Structure of the HLA simulation

Figure 3: The model of a node in the network

Figure 4: Master Slave Network Protocol

Figure 5: Code for Sender at Master Side

Figure 6: Code for Receive at Master Side

Figure 7: Multi-master Network Protocol

Figure 8: Architecture of a Frame

Figure 9: Model Interfaces

Figure 10: Model for two nodes

Figure 11: Model for N-nodes

Figure 12: Case Study – Overview of the Controlled Water System

5



Chapter 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 an application.Many general and special purpose-programming languages have been developed over theyears, 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 inthe United States in 1972, [2] and today there are even more. We have chosen a languagethat will be complain with portability and tightly – integrated support for threads, whichenables 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 this goal. As a result, in recent years, the number of Javaembedded applications has been growing constantly e.g. mobile phones, PDAs, andconsumer 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. 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 isvery complicated or even impossible to deal with. The model (method) that we present isnot a theoretical one. This experimental method proofs the correctness of the concurrent

program in a distributed embedded environment. The method does not guarantee the totalcorrectness, but it is the best approach to reach the proposed solution.The work is divided six chapters. We beginning with the quick revision of the backgroundof parallel and distributed simulation, thorough the related work of theoretical methods of testing and verification of software overview, and concluding with a case study,conclusion, and future work.

6



can schedule events for other LPs, some synchronization mechanism is needed to preventthe situation where a LP receives an event with a timestamp lower than its localsimulation time (see [18] for the explanation of differences between physical, simulationand wall clock time) – a LP can process its events faster and run ahead of the other LPs.

Two major classes of synchronization protocols exist today (somewhat similar totransaction processing in databases):

• Conservative synchronization

• Optimistic synchronization

The first and older are the conservative protocols that try to avoid the possibility toreceive an event in the LPs past. The second class are the optimistic protocols that do not

prevent the reception of an event in the past, but instead they detect this situation andrecover from it by rolling back the LPs computed events with timestamps greater than thereceived event.

Conservative Synchronization

The conservative protocols avoid the possibility of receiving an event in the past.This basic protocol assumes that the reliable communication channels between LPs areknown before the execution and the event messages are sent over these channels in non-decreasing timestamp order. LPs process their events with the smallest timestamp. Theevent computation is allowed only if the timestamp of the processed event is smaller or equal to the smallest timestamp of all channels from which the LP can receive additionalevents.

This however can lead to a deadlock situation where each LP will wait on other LPs because its local events will have greater timestamps than the minimum timestamp of allthe communication channels. The first conservative protocols used null messages to avoidthe deadlock. A null message is an empty message with a timestamp that LP sends toother LPs. By sending this message the LP promises that the further messages will havetimestamps greater or equal than the timestamp of the null message (messages in achannel must be in non-decreasing timestamp order). The null messages increase thetimestamps of the channels and eventually some events become ready to be processed – the deadlock is avoided.

Important for sending the null messages is the value of lookahead

. Lookahead is aminimum time increment for a LP. If the LP’s local simulation time is T, then the earliesttime of a future event that this LP can schedule will be T+ L (where L is the value of lookahead). Consider a traffic simulation where the LPs represent crossroads and eventsare the car arrivals and departures. The lookahead may be the value that takes the car totravel from one crossroad to another.

The disadvantage of the null-message algorithm is that these messages mayintroduce big overhead, especially with small values of lookahead. Many protocols weredesigned to avoid this problem and increase the performance (see [18] for extensivereview). These include sending the null messages only on request, allowing deadlock and

8



recovering from it, synchronous execution using global barrier synchronization, timewindows and other.

The lookahead however complicates the design of the simulation model. It is nottrivial to design a model with good lookahead properties. The performance of conservative synchronization is dependent on lookahead – models with bad lookahead

properties have bad performance.

Optimistic Synchronization

Optimistic synchronization protocols do not prevent the possibility of receivingevents scheduled to the past. Single LPs process events from their calendars optimisticallywithout waiting for the possibly incoming events from other LPs. This however can resultin a situation where an event arrives with a timestamp lower than the local simulationtime of the LP (called often straggler ), violating the local causality constraint. Thissituation must be solved by rolling back (undoing) the computation of all events withtimestamps greater than the timestamp of the straggler.

s t r a g g l e r ( o u t o f o r d e r )m e s s a g e

o u t p u t q u e( a n t i m e s s a

e v e n t l i s t (

p r o c e s s e

u n p r o c e s

s a v e d s t a t

Figure 1: Local control mechanism in optimistic synchronization protocols

Figure 1 shows the local control mechanism of LPs in optimistic protocols. The LPcomputes events from the event list in increasing timestamp order. Before thecomputation of the event the state of the LP is saved for the case of rollback. When theLP sends a message with new event, it stores anti-message in the output queue. In thecase of rollback, the anti-messages are sent to the target LPs where the positive messageswere sent previously. On receipt of the anti-message the LP removes correspondingunprocessed event from its event list (so called annihilation) or initiates rollback to a time

prior the timestamp of the anti-message.

9



The output queues and saved states consume memory and thus a globalsynchronization mechanism is needed to determine when it is safe to reclaim the memory.This memory reclamation is called fossil collection. It is safe to reclaim only the memoryoccupied by events that will not possibly be subject of rollback. The events will never berolled back if their timestamps are lower than the minimum timestamp of all unprocessedevents and messages in the whole system. This time is called Global Virtual Time (GVT).

The optimistic synchronization was first introduced by Jefferson [18], [19]. Sincethat time various enhancements regarding the state saving and GVT computation weredeveloped. Two major classes of state saving mechanisms exist – checkpointing andincremental methods. In the checkpointing a whole state is saved either before each eventor before each n-th event. In the case of rollback the state is immediately available in thesaved copy. The incremental methods save only the changed portions of the state witheach event, thus saving memory, but in the case of rollback the state must be

reconstructed by reading the saved changes in reverse order. Franks et al. [20] introducednew state saving scheme for interactive simulators that offers bounded statereconstruction time. Other new approaches include using reverse computation toreconstruct the state [21] and automatically adjust the parameters using changepointdetection [22]. In [17] a comprehensive review of various mechanisms is available.Comparison of various algorithms can be found in [23]

A novel approach to increase performance of both conservative and optimisticsynchronization protocols was recently presented by Chen and Szymanski [24, 25]. The

basic concept of this approach is lookback. Lookback is the ability of a LP to execute

events that are out of the timestamp order, scheduled in the past (see [24] for formaldefinition). For example in optimistic protocols the straggler event can be processedwithout causing the rollback.

2.1.2. Virtual Environments and Real-Time Simulation

One of the key purposes of real-time simulation technologies is to constructDistributed Virtual Environments (DVE). These environments allow to train people(human-in-the-loop) or to test hardware components (hardware-in-the-loop). DVEs ofteninclude high resolution animations that depict the simulated world. The application area is

very wide, from various vehicle simulators (automobiles, mobile crane [26] and others),virtual surgical operations in medicine (for example vascular reconstruction, [27]), spaceoperations [28], to various military war games and training. DVEs are also increasinglyused for entertainment in many multiplayer and MMORPG (Massive Multiplayer On-lineRole Playing Games) games where thousands of users can interact with the DVE [29, 30].The DVEs allow participants from geographically distributed places (even betweencontinents) to participate in the same simulation and thus reduce additional cost (e.g.transportation).

The human participants are integral parts of the DVE, in contrast to the analyticalsimulations, that can be non-interactive or the humans are not such integrated into the

10



simulation. The goal of the analytical simulations is to provide accurate and exact data of the simulated system. In DVEs the goal is to provide “realistic” perception of theenvironment to the participants. The real-time performance and high responsiveness isoften more important than the exactness.

The DVEs can exploit the limitations of human perception, for example if moreevents happen closely in time, they can be executed in any order and the exactsynchronization is not required, because humans will perceive them as if they happened atonce. To save communication overhead and increase the real-time performance, theupdates of the state of entities in DVE may be less frequent and the state can beextrapolated using the saved history (dead reckoning).

High Level Architecture (HLA)

HLA was proposed by Defense Modeling and Simulation Office (DMSO) atDepartment of Defense (DoD) of USA to set standards and rules for creation of interoperable distributed simulations [31]. The HLA framework was later approved byIEEE as open standard (IEEE 1516). Basic structure of HLA distributed simulation isshown in Figure 2 (DMSO RTI 1.3.5). For a comprehensive review of the architecture see[17].

F e d e r a t e

l i b R T I

F e d e r a t e

l i b R T I

F e d e r a t e

l i b R T I

F e d E x e c

I n t e r - P r o c e s s C o m m u n i c a t i

F e d e r a t i o n

F e d e r F e d e r

I n t e r - P r o c e s s C o m m u n i c

F e d e r F e d e r a t i o nR T I E x e c

Figure 2: Structure of the HLA simulation

HLA distributed simulation consist of components called federates. Two or morefederates together form federation. The synchronization and data exchange isaccomplished by Run-Time Infrastructure (RTI) software (gray components in Figure 2).

11



Federations are managed by Federation Executive (FedExec). The whole RTI is managed by RTI Executive (RTIExec).

The HLA standard comprises of three components:

• Federation rules – define the rules that all the federations and federate mustfollow.

• Interface specification – specification of the interfaces between federates and theRTI.

• Object Model Template – specifies the format and syntax for describing theobjects in HLA models.

The RTI services are grouped into six categories:

• Federation management – services for federation creation, destroying andmanagement.

• Time management – services that, implement various synchronization policies toallow advancing logical time.

• Declaration management – publication and subscription of object instances andtheir attributes

• Object management – object management functions at producer and receiver sites,interaction between objects.

• Ownership management.

•

Data distribution management – data distribution according to declared interests.The main objective of HLA is to provide standards for interoperability and

reusability of simulations. The framework allows constructing simulations distributedover multiple nodes. It is often used as a base for distributed virtual environments andreal-time simulation. It also offers the possibility to build heterogeneous simulationswhere some of the components are represented by physical hardware [32].

12



2.2. Best Known Theoretical Methods of Testing and

Verification of Software Overview

Here we introduce several theoretical methods of modeling.

2.2.1. Petri Nets

A Petri net is a graphical and mathematical modeling tool. It consists of places,transitions, and arcs that connect them. Input arcs connect places with transitions, whileoutput arcs start at a transition and end at a place. There are other types of arcs, e.g.inhibitor arcs. Places can contain tokens; the current state of the modeled system (themarking ) is given by the number (and type if the tokens are distinguishable) of tokens in

each place. Transitions are active components. They model activities which can occur (thetransition fires), thus changing the state of the system (the marking of the Petri net).Transitions are only allowed to fire if they are enabled , which means that all the

preconditions for the activity must be fulfilled (there are enough tokens available in theinput places). When the transition fires, it removes tokens from its input places and addssome at all of its output places. The number of tokens removed / added depends on thecardinality of each arc. The interactive firing of transitions in subsequent markings iscalled token game.

Petri nets are a promising tool for describing and studying systems that are characterizedas being concurrent, asynchronous, distributed, parallel, nondeterministic, and/or

stochastic. As a graphical tool, Petri nets can be used as a visual-communication aidsimilar to flow charts, block diagrams, and networks. In addition, tokens are used in thesenets to simulate the dynamic and concurrent activities of systems. As a mathematical tool,it is possible to set up state equations, algebraic equations, and other mathematical modelsgoverning the behavior of systems.

To study performance and dependability issues of systems it is necessary to include atiming concept into the model. There are several possibilities to do this for a Petri net;however, the most common way is to associate a firing delay with each transition. Thisdelay specifies the time that the transition has to be enabled , before it can actually fire. If the delay is a random distribution function, the resulting net class is called stochastic

Petri net . Different types of transitions can be distinguished depending on their associateddelay, for instance immediate transitions (no delay), exponential transitions (delay is anexponential distribution), and deterministic transitions (delay is fixed).

The concept of Petri nets has its origin in Carl Adam Petri's dissertation Kommunikation

mit Automaten, submitted in 1962 to the faculty of Mathematics and Physics at theTechnische Universität Darmstadt, Germany.[4]

2.2.2. π – Calculus

13



The π – Calculus is a process algebra where processes interact by sending communicationlinks to each other. It was developed by Robin Milner in early 1990s as a successor to hisCSS language. The π – Calculus takes the idea of synchronous communication of

processes over named channels. The basic computational step is the transfer of acommunication link between two processes; the recipient can then use the link for further interaction with other parties. This makes the calculus suitable for modeling systemswhere the accessible resources vary over time. It also provides a significant expressive

power since the notions of access and resource underlie much of the theory of concurrentcomputation, in the same way as the more abstract and mathematically tractable conceptof a function underlies functional computation. Semantics of the π – Calculus is describedin [5]

2.2.3. LTSA – Labeled Transition System Analyzer

LTSA is a verification tool for concurrent systems development. It mechanically checksthat the specification of a concurrent system satisfies the properties required of its

behavior. It was developed by Jeff Magee and Jeff Kramer. LTSA can be downloadedfrom [6].

2.2.4. The Model Checker SPIN – Checking Formal Models

SPIN is an efficient verification system for models of distributed software systems. It has been used to detect design errors in applications ranging from high-level descriptions of distributed algorithms to detailed code for controlling telephone exchanges. It supportsthe design and verification of asynchronous process systems. The verification is mainlyfocused on proving the correctness of process interaction, specified either with randez-vouz primitives or with asynchronous message passing through buffered channels, or access to shared variables or any combination of these. More information about the SPINsee [7].

2.2.5. Java PathFinder 1 – Constructing Formal Models from

Java Multithreaded Programs

Java PathFinder [8], Jpf, is a prototype translator from Java to Promela,the modeling language of the Spin model checker [9]. Jpf is a productof a major effort by the Automated Software Engineering group atNASA Ames to make model checking technology part of the softwareprocess. Experience has shown that severe bugs can be found in finalcode using this technique [10], and that automated translation from aprogramming language to a modeling language like Promela can helpreducing the effort required. Jpf allows a programmer to annotate his Java program with assertions and verify them using the Spin modelchecker. In addition, deadlocks can be identified. An assertion is written

14



as a call to an assert method defined in a predefined Java class, theVerify class. The argument to the method is a boolean Java expressionover the state variables. The Verify class contains additional temporallogic methods which allow to state temporal logic properties aboutstatic variables. Hence Java itself is used as the specification language.An application of Jpf is described elsewhere in the proceedings [11]. Arespectable subset of Java is covered by Jpf, including dynamic objectcreation, object references as first class citizens, inheritance,exceptions, interrupts, and perhaps most importantly: threadoperations. Among major concepts not translated are: packages,method overloading and overriding, method recursion, strings, andfloating point numbers. Finally, the class library is not translated.

2.2.6. Bandera – Model – Checking Properties of ConcurrentJava Software

Bandera enables the automatic extraction of safe, compact finite-state models from program source code. Bandera takes as input Java source code and generates a programmodel in the input language of one of several existing verification tools: Bandera alsomaps verifier outputs back to the original source code. A more detailed information can

be found in [12], [13] or downloaded fromhttp://bandera.projects.cis.ksu.edu/papers/index.shtml.

2.2.7. The Model Checker VeriSoft – Checking UNIX

Concurrent Systems

VeriSoft model checker is a verification tool for methodical examination of the statespace of systems composed of numerous concurrent processes executing randomly C

programs. The heart of the checker is the scheduler, which systematically drives thesystem along all possible paths, building up the computation tree as it goes. Because thesystem is checked directly, in principle no abstraction is required. However, the user isrequired to write processes that simulate the environment, and this may requireabstracting away aspects of the environment, like infinite-domain data. As the scheduler

drives the system, it reports bad behaviors such as deadlocks and assertion violations.Checking of general temporal logic formulas is not supported. A description of Verisotf model checker can be found in [14].

2.2.8. An Executable Model of Java Programs – The ExitBlock

Algorithm

ExitBlock systematically and deterministically finds program errors resulting fromunintended timing dependencies. ExitBlock executes a program or a portion of a program

15



on a given input multiple times, enumerating meaningful schedules in order to cover all program behaviors. Applying to the Java programs , ExitBlock enumerates all possible behaviors of a Java multithreaded program for a given input. It does not need a separatemodel or specification of the tested program or its source code, it does the testingdynamically using information gathered while running the program. More detailedinformation see [15], [16].

2.2.9. Java PathFinder 2 – Executable Models of the Java

Virtual Machine

Java PathFinder 2 is an explicit-state model checker for programs written in Java. It isitself written in Java and contains a special-purpose Java virtual machine MC-JVM. The

brief description can be founded in [16]. JPF2 works directly with Java bytecode, not with

source code, as its predecessor.

Chapter 3

Model Architecture Overview

In a previous work [36] is explained a model of testing an verification of Java concurrentcontrol 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-timeconcept. This model is accomplished by using the J-Sim program simulation of thesurrounding environment and the model of the simulation itself, even before the realhardware is developed. The extension of this task to a distributed embedded simulationmodel is the aim of this work. Roughly, in order to reach this objective we must create themodel of the communication interface between a node and network. For that reason, firstwe present a model structure of a node, followed by the model of the network anddescribing the methods and classes that we are going to use.

16



3.1. Model Structure

In this section, we describe the structure of the simulation. We have N-nodes in the

network. The nodes represent a processor or a device that we want to simulate. Let usshow in the first place, the structure of a node:

3.1.1 Structure of a node

In the figure showed below, we present the structure of a node of the distributedembedded simulation.

As we said before, we need two kinds of interface connection (IC). One of them, betweenthe 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 andsensors). The second one is used to communicate to the network, for that purpose we takein account the medium and buffers. Is important to take into account that we have twokinds of nodes, 1-node for the main tank and N-nodes for the stations. (See figure 3).

Figure 3. The model of a node in the network

3.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.

A

B

Application

(Java + JiJ)

Network Model

(medium + buffers)

HardwareModel

(registers)Model

ControlledEnvironment(tank, pumps,

sensors)

A

B

IC to Network

IC to HW

computer

Network

17



3.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 eachnode by name, one at a time, letting that node talk for a certain amount of time. When it isfinished, the master addresses the next node, and so on, and so on. [37]. See figure 4.

Figure 4. Master Slave Network Protocol

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 thenodes are working correctly (e.g. the level of water is not under or above thelimits, or if are there at least K working bombs, etc.) see Case Study. A first

approach of the Java code for this task is showed in figure 5.

import java.net.DatagramPacket;import java.net.DatagramSocket;import java.net.InetAddress;

public class Sender {

public stati c void main(Str ing[] args) {

try {

/* sending data structures initialization */InetAddress receiverHost= InetAddress.getByName("localhost");

DatagramSocket mySendSocket = new DatagramSocket() ;String message = "Hi there! How do you do!?";byte msgBytes[] = message.getBytes();

/* creation of a test datagram */DatagramPacket sendDatagram= new DatagramPacket( msgBytes, msgBytes.length,

receiverHost, 54321 );

/* sending of the previously created test datagram */

Node 1

Master

Node 2 Node n…

Bus

18



System.out.println("Sending: " + message);mySendSocket.send(sendDatagram);mySendSocket.close();

/* receiving data structures initialization */DatagramSocket myReceiveSocket = new DatagramSocket(12345);byte buffer[] = new byte[50];DatagramPacket recvDatagram = new DatagramPacket(buffer, 50);

/* receiving answer for the test datagram */System.out.println("Listening...");myReceiveSocket.receive(recvDatagram);System.out.println(new String(buffer));myReceiveSocket.close();

} catch (Exception e) {e.printStackTrace();

}}

}

Figure 5. Code for Sender at Master Side

• 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 eachwater station). Also a first approach of the Java code for this task is showed infigure 6.

import java.net.DatagramPacket;import java.net.DatagramSocket;import java.net.InetAddress;

public class Receiver {

public static void main(String[] args) {

try {

/* receiving data structures initialization */DatagramSocket myReceiveSocket = new DatagramSocket(54321);byte buffer[] = new byte[50];DatagramPacket recvDatagram = new DatagramPacket(buffer, 50);

/* receiving of a test datagram */System.out.println("Listening...");myReceiveSocket.receive(recvDatagram);System.out.println(new String(buffer));myReceiveSocket.close();

19



/* Wait a moment so that a receiver is ready */ Thread.sleep(1000);

/* sending data structures initialization */InetAddress receiverHost

= InetAddress.getByName("localhost");DatagramSocket mySendSocket = new DatagramSocket();String message = "Hi! I am fine :-) Thanks.";byte msgBytes[] = message.getBytes();

/* creation of an answer for the test datagram */DatagramPacket sendDatagram

= new DatagramPacket( msgBytes, msgBytes.length,receiverHost, 12345 );

/* sending an answer for the test datagram */

System.out.println("Sending: " + message);mySendSocket.send(sendDatagram);mySendSocket.close();

} catch (Exception e) {e.printStackTrace();

}}

}

Figure 6. Code for Receive at Master Side

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.The code will be similarly to Sender and Receiver classes.

3.1.2.2. Multi – Master Network Protocol

Multi – Master protocol, where each node gets a turn to talk (one at a time), and thengrants permission for the next node to talk when it is done. Permission to talk is passedaround from node to node as each one hands off the "token" to the next in sequentialorder. The token itself is not a physical thing: it is a series of binary 1's and 0's broadcaston the network, carrying a specific address of the next node permitted to talk. Althoughtoken-passing protocol is often associated with ring-topology networks, it is not restrictedto any topology in particular. Moreover, when this protocol is implemented in a ringnetwork, the sequence of token passing does not have to follow the physical connectionsequence of the ring. [38]. See figure 7.

20



Figure 7. Multi-master Network Protocol

In the Multi-master model the communication among the nodes will be achievablethrough message passing paradigm. There are two types of this paradigm,

synchronous and asynchronous. We well explain the advantages an disadvantagesof each one, concluding that in our proposed model the asynchronous one suits better our model.

3.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() andsrecv() are the synchronous send and receive system calls. This model suits better in atightly coupled computer environment where there is a multiprocessor system sharingmemory. But in the distributed setting synchronous external calls seemless satisfactory; at best resulting in inefficient use of processorcapacity, at worst resulting in deadlock. Furthermore, it is difficult tocombine active and passive behavior in concurrent objects. It is clearlyless suitable in a distributed setting with loosely coupled components. [39].

3.1.2.2.2 Asynchronous Message Passing

Node 1

Node 3

Node 4 Node 6

Node 7

Node 8 Node 2

Node 5

Bus

Token

21



In the other hand, asynchronous message passing gives better control andefficiency, but lacks the structure and discipline inherent in methodcalls. The integration of the message concept in the object-orientedsetting is unsettled, especially with respect to inheritance andredefinition. An object offers methods to its environment, specified through a number of interfaces and co-interfaces. All interaction with an object happens through methodcalls. In the asynchronous setting method, calls can always be emitted, because thereceiving object cannot block communication. Method overtaking is allowed: if methodsoffered by an object are invoked in one order, the object may start the method instances inanother order. A method instance is, roughly speaking, program code with nested

processor release points, evaluated in the context of local variables. Due to the possibleinterleaving of different method executions, the values of an object’s program variablesare 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 beencreated. 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, whichcan 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 severalconditions:

Conditions

• Tested media is a serial bus.

• We will use an asynchronous message passing. In this case there are twoalternatives: blocked and unblocked asend(), areceive() functions. For thesimplicity 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 5)

22



• 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 amedium 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 6-A.

asend( adrNode, frame)- adrNode = 0, broadcast.

- adrNode = 0, accept eachmessage.

frame areceive(adrNode) - return null = nothing isincoming.

Index connection

Address 1-n

256 bytes of data

Type Frame

23



Figure 8. Architecture of a Frame

• Implementation (model) (5 classes) (figure 6-B)

- Frame – sent message

- sendBuffer – passive object is composed by:

message queue for sending

reference to sending thread SendThread

Figure 9. Model Interfaces

Application Network Interface

Network model

A B

24



Implementation of asend(). Put one frame to buffer (queue) andawakes the thread.

Function (method) transmitFrame(RecBuffer buf) uses sendingthread 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:

1. Takes a message from sendBuffer. ( if there aren’t then passivate() ) (J-sim).

2. Test serialBus, if bus is free then gives the address (reference) fromreceive 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) (thinking!!!)

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 10.

25



Figure 10. Model for two nodes

Connections is done by Java – references

Figure 11. Model for N-nodes

Application 2

1 SendBuffer

1 ReceiveBuffer

1 SendThread

Application 1

Network IC

HW IC

HW IC

Network IC

1 SendBuffer

1 ReceiveBuffer

1 SendThread

S

ER IAL

BUS

Network

model

n

Application

Communication

Controller

Model

Network IC

Network Model

Connection

Network Model

Communication

Controller

Model

Communication

Controller

Model

26



Chapter 4

Control Program Verification Procedure

4.1. The Verification Procedure

The verification procedure is strongly application dependent, so we can only give somegeneral recommendation here. Generally, the procedure is similar as when testing the

control program within its real-world environment, i.e. a well-chosen set of activityscenarios (tests) is developed and then executed. Let us assume a non-stop activity of theoverall system. Then the model of environment should issue a (very long) stream of (possibly random) events that the control program should cope with. The model-basedexecution gives us the possibility of arbitrarily detailed observation of the execution

process without a “probe effect”, i.e. the model-time dynamics of the modeled system isnot influenced by the observation. The execution can be deterministically repeated aswell, even when a random sequence of events is used to stimulate the control programactivity. We have two basic possibilities what to follow during a model-based testexecution:

27



4.2.1. The State Invariants

State invariants, i.e. conditions that should apply all the time of execution (or – moregenerally – within a bounded part of the model execution). These invariants can beconstructed using variables (objects states) from both the control program andenvironment parts of the simulation model. As for the timing of invariants evaluation wehave two possibilities again: to do it either with every change of the model state (i.e. after every step of the dicrete-time simulation run) or regularly – using a special “Sample andEvaluate” simulation process.

4.2.2. The Behavioral Protocols

Behavioral protocols, i.e. rules that should apply for a sequence of events (possiblyincluding their timing) at the control interface. Clearly, the problem of the performed testsnumber and length (diagnostic coverage, completeness) stays open – similarly as whenwe are testing the program at a real device. But here we have extended possibilities of thetests organization (e.g. the possibility to use a “wild” environment activity or to changerandomly the control program timing in order to reveal race conditions). The possibilityof the model activity observation and investigation is better here as well, what means thatthe number (and the coverage) of the tests performed can be extended in this case.

28



Chapter 5

Case Study

A case study has been development. It is an abstract embedded application that controlswater level of a water station tank and several connected water sources (see figure 12).

The first prototype was theoretically and practically developed in [33]. Here weconcentrate our effort in the distributed embedded application form. Then we have to usetwo 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 businterface). Obviously, the model complexity will arise fast, because the model shouldinclude all the nodes of distributed system and a sub-model of communication protocol aswell [34].

29



Figure 12. Case Study – Overview of the Controlled Water System

Chapter 6

Conclusion and Future Work

Further work will be focused mainly on customization of the Java source codeconversion 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 beextended in order to gain more experience. We plan to extend this set for distributedenvironment using e.g. CAN (Controlled Area Network) or TTP (Time TriggeredProtocol) serial bus based control application as well. The Controller Area Network (CAN) and the Time-Triggered Protocol (TTP) are two fundamentally differentcommunication protocols for the design of distributed real-time systems. CAN belong tothe class of event triggered protocols where the class of event-triggered protocol wherethe temporal control signals is derived primarily from non-time events occurring outside

sensor

actuator

sensor

Highlevel

Low

level

full

Source Source

N instances

To village(randomconsumption)

…

Input flow

Highlevel

Lowlevel

sensor

sensor

sensor flow

Water Station

30



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 studythe 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 methodcombines model-time serialization of the control program threads with the conventionaldiscrete time simulation of the control program environment. Unlike other existingmethods, it is an experimental, method targeted on testing real Java code and not atheoretical system model. Moreover, the method does not require any especial Javavirtual machine and is convenient for non-terminating programs running in a distributedenvironment. The method takes into account the control program environment behavior

and tests both parts of the (designed) control system together which is completely omittedin other program verification approaches.

References

[1] Robert E. Shannon.: Introduction to Simulation Languages. Winter SimulationConference. 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. Communicationsof the ACM, v.15 n.7, p.601-610, July 1972.

[3] Jaroslav Kačer, Stanislav Racek.: Model Based Development of Java Embedded

Applications, [Extended Abstract], Book of Abstracts of the 5 th EuroSim Congresson Modeling and Simulation, EuroSim-FrancoSim-ArgeSim, Francie, září

31



2004ISBN 3-901608-28-1, Strany: 84-85.

[4] http://pdv.cs.tu-berlin.de/~azi/petri.html

[5] R obin Milner: The Polyadic _-Calculus: A Tutorial. LFCS ReportECS-LFCS-91-80, Laboratory for Foundations of Computer Science,School of Informatics, University of Edinburgh, Edinburgh, UK,1991. http://www.lfcs.inf.ed.ac.uk/reports/91/ECS-LFCS-91-180/-ECS-LFCS-91-180.ps

[6] Jeff Magee: LTSA – Labeled Transition System Analyzer.University of London, Imperial College of Science Technology andMedicine, Department of Computing, London, UK, 1999.

http://www-dse.doc.ic.ac.uk/concurrency/ltsa/LTSA.html

[7] Gerard J. Holzmann: The Model Checker SPIN. IEEE Transactionson Software Engineering, Vol. 23, No. 5, 1997.http://spinroot.com/spin/Doc/ieee97.pdf

[8] K. Havelund and T. Pressburger. Model Checking Java Programsusing Java PathFinder. Appearing in International Journal onSoftware Tools for Technol ogy Transfer (STTT), 1999.

[9] G. Holzmann. The Design and Validation of Computer

Protocols. Prentice Hall, 1991.

[10] K. Havelund, M. Lowry, and J. Penix. Formal Analysis of a SpaceCraft Controller using SPIN. In G. Holzmann, E. Najm, and A.Serhrouchni, editors, Proceedings of the 4th SPIN workshop, Paris,France, November 1998. To appear in IEEE Transactions of Software Engineering.

[11] K. Havelund and J. Skakkeb_k. Applying Model Checking in JavaVerification. In R. Gerth, G. Holzmann, and S. Leue, editors,

Proceedings of the 6th SPIN workshop (these proceedings),Toulouse, France, September 1999.

[12] James C. Corbett, Mathew B. Dwyer, John Hatcliff, Shawn Laubach, Corina S.Pasareanu, Robby, Hongjun Zheng: Bandera: Extracting Finite-state Models

from Java source Code. Proceedings of the 22nd International Conference onSoftware Engineering, 2000.http://www.cis.ksu.edu/santos/bandera/papers/bandera.pdf

[13] John Hatcliff, Matwhew Dwyer: Using the Bandera Tool Set to Model-check

Properties of Concurrent Java Software. Proceedings of CONCUR 2001 –

32



Concurrency Theory: 12th International Conference, Aalborg, Denmark, 2001.http://www.cis.ksu.edu/~hatcliff/Papers/ CONCUR01-tutorial.ps.gz

[14] Patrice Godefroid: Model Checking for Programming Languages using

VeriSoft. Proceedings of the 24th ACM Symposium on Principles of ProgrammingLanguages, Paris, France, 1997. http://www.bell-labs.com/project/verisoft/popl97.ps

[15] Derek Bruening: Systematic Testing of Multithreaded Java Programs. Master’sThesis, Massachusettes Institute of Technology, Cambridge, Massachusettes, USA,1999. http://web.mit.edu/iye/www/docs/thesis.ps.gz

[16] Derek Bruening, John Chapin: Systematic Testing of Multithreaded Programs.MIT/LCS Technical Memo, LCS-TM-607, Massachusetts Institute of Technology,

Cambridge, Massachusettes, USA, 2000. http://web.mit.edu/iye/www/docs/tester-TM607.ps.gz

[17] R. M. Fujimoto: Parallel and Distributed Simulation Systems. WileyInterscience, January, 2000

[18] D. R. Jefferson, H. Sowizral: Fast Concurrent Simulation using the Time Warp

Mechanism. Technical Report N-1906-AF, RAND Corporation, 1982

[19] D. Jefferson, B. Beckman, F. Wieland, L. Blume, M. DiLoreto, P. Hontalas, P.Laroche, K. Sturdevant, J. Tupman, V. Warren, J. Wedel, H. Younger, S. Bellenot:

Distributed Simulation and the Time Warp Operating System. In Proceedingsof the 12th Symposium on Operating Systems Principles (SIGOPS), pp. 77—93,1987

[20] S. Franks, F. Gomes, B. Unger, J. Cleary: State Saving for Interactive Optimistic

Simulation. In Proceedings of the 11th Workshop on Parallel and DistributedSimulation (PADS-97), pp 72—79, 1997

[21] Ch. D. Carothers, K. S. Perumalla, R. M. Fujimoto: Efficient Optimistic Parallel

Simulations using Reverse Computation. In ACM Transactions on Modeling andComputer Simulation 9(3), pp 224—253, Jul 1999

[22] A. Kuratti: Improved Techniques for Parallel Discrete Event Simulation. Ph.D.thesis, University of Illinois at Urbana-Champaign, 1997

[23] E. Niewiadomska-Szynkiewicz, A. Sikora: Algorithms for Distributed Simulation

– Comparative Study. In Proceedings of the IEEE International Conference onParallel Computing in Electrical Engineering (PARELEC’02), 2002

[24] G. Chen, B. K. Szymanski: Lookback: A New Way of Exploiting Parallelism in

Discrete Event Simulation. In Proceedings of the 16th Workshop on Parallel andDistributed Simulation, pp 143—152, 2002

33



[25] G. Chen, B. K. Szymanski: Four Types of Lookback . In Proceedings of the 17th

Workshop on Parallel and Distributed Simulation (PADS'03), pp 3—10, 2003

[26] J. Y. Huang, Ch. Y. Gau: Modelling and designing a low-cost high-fidelity

mobile crane simulation. In International Journal of Human-Computer Studies 58, pp 151—176, 2003

[27] R. G. Belleman, R. Shulakov: High performance distributed simulation for

interactive simulated vascular reconstruction, Computational Science - ICCS2002, Proceedings Part III, in series Lecture Notes in Computer Science, vol. 2331,

pp. 265—274, 2002

[28] F. Dubuc: Distributed Interactive Simulation in Europe: The EDISON Project

and Perspectives. In Proceedings of the 5th

Workshop on Simulation for EuropeanSpace Programmes (SESP’98), 1998 [29] W. T. Cai, P. Xavier, S. J. Turner, B. S. Lee: A Scalable Architecture for

Supporting Interactive Games on the Internet. In Proceedings of the 16th IEEEWorkshop on Parallel and Distributed Simulation (PADS’02), pp 60—67, 2002

[30] J. Smed, T. Kaukoranta, H. Hakonen: A Review on Networking and Multiplayer

Computer Games, Turku Centre of Computer Science Technical Report No. 454,April 2002

[31] Defense Modeling and Simulation Office: High Level Architecture homepage.https://www.dmso.mil/public/transition/hla/rti/

[32] R. Jokl, J. Šafařík: From monolithic to HLA based model of a safety critical

system [stať] / Roman Jokl, Jiří Šafařík. - In: 5th international carpathian controlconference : Zakopane, Poland : May 25-28, 2004. - Krakow : AGH-UST, 2004. -ISBN 83-89772-00-0. - S. 75-80

[33] Jaroslav Kačer.: Simulation-Based Checking of Java Concurrent Programs

Ph.D. Thesis, consigned 2005-01-10, (waiting for reviews) University of WestBohemia in Pilsen, Faculty of Applied Sciences, Department of Computer Science

and Engineering, Pilsen, Czech Republic, January 2005Language: English.

[34] FIT – Fault Injection for TTA. http://www.fit.zcu.cz

[35] Kopetz H.: Real Time Systems, Design Principles for Distributed Embedded

Applications. Kluwer Academic Publishers, 1997.

[36] Jaroslav Kačer.: Model – Based Development of Java Embedded Applications.

Technical Report No. DCSE/TR-2004-03. Version 1. University of West Bohemia

34



in Pilsen, Faculty of Applied Sciences, Department of Computer Science andEngineering, Pilsen, Czech Republic, September 2004. Language: English.

[37] Network Protocols. http://www.allaboutcircuits.com/vol_4/chpt_14/6.html

[38] Einar Broch Johnsen and Olaf Owe. An Asynchronous Communication Model

for Distributed Concurrent Objects Department of informatics, University of Oslo PO Box 1080 Blindern, N-0316 Oslo, Norway . Proceedings of the SecondInternational Conference on Software Engineering and Formal Methods (SEFM’04)0-7695-2222-X/04 IEEE.

http://www.allaboutcircuits.com/vol_4/chpt_14/6.html

http://www.allaboutcircuits.com/vol_4/chpt_14/6.html

rigo-allain rig final01

Documents