A NOVEL APPROACH TO REMOTE TRACKING AND CONTROL OF DISTRIBUTED REAL TIME SYSTEMS USING

SOFTWARE AGENTS

BAKTAVATCHALAM G (08MW03)

Dissertation submitted in partial fulfillment of the requirements for the degree of

MASTER OF ENGINEERING

Branch: COMPUTER SCIENCE AND ENGINEERING Specialization: SOFTWARE ENGINEERING

Of Anna University

May 2010

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING PSG COLLEGE OF TECHNOLOGY

(Autonomous Institution)

COIMBATORE – 641 004

PSG COLLEGE OF TECHNOLOGY (Autonomous Institution)

COIMBATORE – 641 004

A NOVEL APPROACH TO REMOTE TRACKING AND CONTROL OF DISTRIBUTED REAL TIME SYSTEMS USING SOFTWARE

AGENTS

Bonafide record of work done by

BAKTAVATCHALAM G (08MW03)

Dissertation submitted in partial fulfillment of the requirements for the degree of

MASTER OF ENGINEERING

Branch: COMPUTER SCIENCE AND ENGINEERING

Specialization: SOFTWARE ENGINEERING

Of Anna University

MAY 2010 _________________ ________________________ Ms.R.Shalini Dr.S.N.SIVANANDAM Faculty Guide Head of the Department Certified that the candidate was examined in the viva voce examination held on ………………

---------------------------- ------------------------------ (Internal Examiner) (External Examiner)

Acknowledgement

i

ACKNOWLEDGEMENT

We wish to express our sincere gratitude to our respected Principal Dr. R. Rudramoorthy for having given us the opportunity to undertake our project.

We also wish to express our sincere thanks to Dr. S. N. Sivanandam, Professor and Head of the Department of Computer Science and Engineering, for his

encouragement and support that he extends towards our project work.

We also wish to express our sincere thanks to Mr. B. Murali Balaraman, MD, Transpace Tech Pvt Ltd, Banglore for his support and guidance that he extends

towards our project work.

We extend our sincere thanks to our internal guide Ms. R. Shalini, Lecturer, Department of Computer Science and Engineering her helpful guidance rendered for

the successful completion of our project.

Contents

iii

CONTENTS

CHAPTER Page No. Synopsis………………….………………………………………………..…………….. .(i) List of Figures.………….………………………………………………...…………….. .(ii) List of Tables.…………………………………………………………………………….(iii) 1. INTRODUCTION.……...…………………………………………………………... .1

1.1. Problem Definition 1

1.2. Objective of the Project 1

1.3. Significance of the Project 1

1.4. Outline of the Project 1

2. SYSTEM STUDY..…….……………………..……………………………………...3 2.1. Existing System 3

2.1.1. Literature Survey on Existing Systems 3

2.2. Proposed System 13 3. SYSTEM ANALYSIS..…….……………………..………………………………….15

3.1 Requirement Analysis 15 3.2 Feasibility Study 15

4. SYSTEM DESIGN…...…….……………………..………………………………….17 4.1 Contextual Activity Diagram 17

5. SYSTEM IMPLEMENTATION.………………..…………………………………...18 5.1 Server Agent Module 18

5.2 Client Agent Module 18

6. TESTING……………………….………………..……………………………………19 6.1 Unit Testing 19

6.2 Integration Testing 20

6.3 Real time System Testing 20

6.4 Sample Test Cases 21

7. SNAPSHOT.…..……………….………………..…………………………………..22

7.1 Local Decision Manager and Control Manager 22

7.2 Signal Processing 23

CONCLUSION………………..………….……………………………….……….……..24 FUTURE ENHANCEMENTS..…………………………………………………….……. .25

BIBLIOGRAPHY...…………………………………………………………….………….26

Synopsis

i

SYNOPSIS

The Embedded Systems can accomplish many complicated tasks in

different working environments. In real time Embedded Applications such as Missile

Guidance, Satellite monitoring systems and Boiler temperature control, the system has

to be monitored and controlled continuously without any interrupt. But, because of

various factors such as over loading, system failure, resource unavailability, network

failure the system may be interrupted and the whole control will collapse.

Concurrency and Synchronization are the ordinary problems in the

embedded software usually must be confronted with. This issue presents a novel

method for controlling such problems efficiently. To avoid the inefficiency or collision

induced by directly coupling amongst multi-tasks that conventional methods mostly did,

software agent architecture designing can cope with such work more properly.

The main work of this project includes designing software agent

architecture for typical Concurrent Embedded System Applications which have Soft Real

time Requirements. Also the Embedded System Components are controlled by real time

conditions which are triggered in the Local Embedded System components or/and other

Remote Embedded System Components. Our Multi-Agent architecture provides

improved Accuracy and Concurrency between the embedded systems Components.

List of Figures

ii

LIST OF FIGURES

FIGURE NO LIST OF FIGURES PAGE NO.

Fig: 2.1

Fig: 2.2

System Architecture

Context Diagram

3

8

List of Tables

iii

LIST OF TABLES

TABLE NO TABLE NAME PAGE NO.

Table 6.1 Sample Test Cases 15

Introduction Chapter 1

1

CHAPTER 1

INTRODUCTION

This chapter provides a brief overview of the company profile problem definition,

objectives and significance of the project and an outline of the report.

1.1 PROBLEM DEFINITION Design and Implementation of Software Agents to Monitor and Control the

Embedded Systems Components which are Distributed Geographically and to provide

better Data Analysis & Sampling Accuracy and better Synchronization between the

Agents

1.2 OBJECTIVE OF THE PROJECT Conditional Control of the Embedded System Components is critical in nature

when the conditions computed from various Embedded System Components which are

in Distributed Places. So this project gives a better solution to control the Distributed

Embedded system components using conditions which are computed over required

distributed components.

1.3 SIGNIFICANCE OF THE PROJECT With the enormous growth in embedded systems, there is a corresponding need

for tools that enable fast and efficient control & tracking of Embedded System

Components. The concurrent execution of Multi-Agents will greatly simplify the

complexity of the Accuracy & Synchronization between the Components.

1.4 OUTLINE OF THE PROJECT

Introduction Chapter 1

2

The rest of the report is structures as follows. Chapter 2 provides a detailed study

of the existing system and the basic ideas of the proposed system. Chapter 3 discusses

the requirements for the development of the system and an analysis on the feasibility of

the system. Chapter 4 presents the overall design of the system. Chapter 5 discusses

the implementation details. Chapter 6 explains various testing procedures conducted on

the system. Chapter 7 contains the snapshot of various forms in our system. The last

section summarizes the project.

System Study Chapter 2

3

CHAPTER 2

SYSTEM STUDY

This chapter elucidates the existing system and a brief description of the

proposed system.

2.1 EXISTING SYSTEM 2.1.1 A Simple Literature Survey on Existing System Approaches

1. “Software Agent Design with Real Time Scheduling for Embedded Systems” by Hu Jin, Liang-Yin Chen, Nian-Wei Chen, Yang Lei

Fig. Heterogeneous Embedded System Architecture with agent

In this paper, Agent design is in software level, and would not change the

hardware structure of embedded system. The agent schedulers and

synchronizes components that in charge of the concurrent tasks. Concurrent

tasks with synchronization or real time constraints should register in the agent

System Study Chapter 2

3

firstly. Then, after agent figuring out reasonable execution sequence, it

synchronizes all tasks and schedules them in turn. That can avoid the heavy and

complicated synchronization work amongst processes and lowers shared

resources access collision.

The agent needs not to be persistent for economic resources usage, and

it can be triggered by concurrent tasks request dynamically. When receiving new

service requests, the agent will re-computes possible response time and decides

whether or not they can be merged into current task group for scheduling.

Here Rate Monotonic Scheduling Algorithm is used in the agent design

for group scheduling work. The System consists of n tasks S = {t1, t2, …, tn}.

Also these tasks should be independent of each other. If this group of tasks is

schedulable, it can satisfy the next equation,

(1)

Where Ci is the worst time cost and Ti is the period of task i. Tasks with

shorter periods are assigned higher priorities with RMS algorithm. Usually, the

tasks are not completely independent because there is synchronization or

cooperation. Then, RMS relaxes the previous constraint and gets the next

equation.

(2)

Where Ci and Ti are the same as that of (1), Bi is the time that task i

blocked by lower priority tasks. Case that lower priority processes block higher

ones is said to priority inverse. Formula (2) guarantees that synchronization tasks

can meet real time requirement.

2. “Deadline assignment in a distributed soft real-time system” by B. Kao and

H. Garcia-Molina.

In this paper, they focus on soft real-time systems (although they would like to

remark that the techniques they will discuss can also be applied to hard systems).

They assume that the distributed system consists of independent components, each

System Study Chapter 2

3

with its own scheduler. The schedulers do not perform load balancing among them.

They believe that large systems are built out of preexisting components. Each

component will have its own scheduling policy and will be unable or unwilling to

coordinate or subordinate its scheduling decisions with (or to) others.

They consider two types of tasks in their system: locals and globals. A local task

is one that is executed at one and only one node. (Each system component, e.g., a

database server, is represented by a node in their model.) A global task, on the other

hand, can be quite complex and may involve work at multiple nodes in the system. In

this paper, they only consider global tasks that are serial-parallel. As shorthand, they

use the notation T = [T1 T2 ... Tn] to represent a global task T that consists of n

subtasks, T1, T2, ..., Tn, to be executed in series. A subtask Ti (i > 1) cannot execute

before subtask Ti-1 finishes. They also use the notation T = [T1 k T2 k ... k Tn] to

represent a global task T consisting of n subtasks T1, T2, ..., Tn to be executed in

parallel. The n subtasks arrive at the same time and task T is considered finished

only if all n subtasks finish. Composition of these notations is possible. They call a

subtask which involves execution only at a single node a simple subtask. A subtask

that is itself a global task is called a complex subtask.

A task X (whether it is a local task, a simple subtask, or a global task) has the

following five attributes: arrival time (ar(X)), deadline (dl(X)), slack (sl(X)), real

execution time (ex(X)), and predicted execution time (pex(X)). They do not assume

the value of ex(X) be available, but some of their SDA strategies do take advantage

of an estimate, pex(X), which is an approximation to ex(X). These attributes are

related by: dl(X) = ar(X) + ex(X) + sl(X). They also define flexibility (denoted by fl(.))

of a task X to be the ratio of X’s slack to the execution time of X. That is, fl(X) = sl(X)/ex(X). Intuitively, the more flexible a task is (higher fl(.)), the less stringent is its

timing constraint. Finally, tardy tasks are not aborted.

System Study Chapter 2

3

2.2 PROPOSED SYSTEM Our proposed methodology uses Client-Server Computing Model. The Clients

are distributed geographically and connected through any network. Each Client has its

separate dedicated Software Agent Application and connected with a dedicated

Embedded System Component. The Server has a Software Agent Monitor Application to

monitor all clients.

Fig. Proposed System Architecture

We use following signal format to exchange data between the Agents,

Fig. Signal Data Format

This data packet format is fixed size, so the network latency will be reduced. The

server agent parses data packet and sends the signal ID to the corresponding client

agent which is having the corresponding destination device ID within the given Time

System Study Chapter 2

3

Limit period. The Time Limit for the components are specified and fixed for each

component.

Our System model consists of ‘n’ clients (Ci [ith client]) and each client contains a

separate queue ‘Qi [ith client Queue]’ which stores the requests (‘REQij [ith client jth

request] ‘) and Decision Rule Set ‘Ri[ith client Rule Set]’.

The time needed to execute the rule set Ri for an item REQij in the queue Qi is denoted

as TRQi and calculated as,

TRQij = TRij + Wij + Nij where,

TRij is the approximate execution time of REQij

Wij is the approximate waiting time of REQij in Qi

Nij is the approximate Network Delay of REQij

The Queue in the agent is designed with Multiple Fetchers then we can optimize

the TRQi, for example if we use ‘m’ fetchers then ‘m’ REQij are fetched from the Queue

simultaneously, so the optimized TRQi is calculated by,

TRQij = TRij + (Wij/Mi) + Nij where,

Mi is the number of fetchers in the queue Qi

To decrease network latency we only transfer the control signals and we use

fixed size format for control signal as (256 bits [for signal] and 128 bits [for

acknowledgement]) and all other data samples of embedded system components are

dumped into local storage for future analysis, so the Network Delay Nij is calculated as,

Nij = CFij * PRij where,

CFij is the total congestion factor / probability for REQij

CFij={0.0 to 1.0} if the value is 1.0 then the network is fully congested

PRij is the propagation time of REQij from source to destination

Here the CFij is reduced because of fixed data packets, so the Nij will be reduced.

System Analysis Chapter 3

4

CHAPTER 3

SYSTEM ANALYSIS This section describes the hardware and software specifications for the

development of the system and an analysis on the feasibility of the system.

3.1 REQUIREMENT ANALYSIS 3.1.1 Software Requirements After experimenting with various commercial software available and analyzing

the Pros and Cons of the software, the following are chosen.

• Operating System – Platform Independent • Programming Languages – Java 1.6+ • Front End - Java Swing, JSP • Framework - jUSB • IDE – Netbeans 6.5

3.1.2 Hardware Requirements The Hardware requirements of the proposed system are as follows:

• Pentium-III machine & above

• RAM-256 MB

• Hard Disk with a Capacity of 10 GB • Network of Computers with above configuration for Cluster

3.2 FEASIBILITY ANALYSIS Feasibility deals with step-by-step analysis of the system. Analysis showed that

this project was feasible in all respects. Three kinds of feasibility factors are considered:

• Economic Feasibility

System Analysis Chapter 3

5

• Technical Feasibility

• Operational Feasibility

3.2.1 Economic Feasibility

The system is developed only using those softwares that are very well used in

the market, so there is no need for installation of new softwares. Hence, the cost

incurred towards this project is negligible

3.2.2 Technical Feasibility

3.2.2.1 Concurrency & Synchronization The main aim of our project is to develop the software agents which are provide

better concurrency & synchronization between the distributed embedded systems

components.

3.2.2.2 Decision Control Rules Next important thing that must be done in our project is to create better rules for

making control decision for individual components.

3.2.3 Operational Feasibility The functions needed to be performed by the system are all valid and without

any conflicts. All functions and constraints specified in the requirements are completely

operational. The requirements stated are realistically testable.

The requirements are adaptable to changes with out any large-scale effects on

other system requirements. The system is capable of accommodating future

requirements if they arise.

System Design Chapter 4

6

CHAPTER 4

SYSTEM DESIGN This chapter describes the functional decomposition of the system and illustrates

the movement of data between external entities, the processes and the data stores

within the system, with the help of contextual and architecture diagrams.

4.1 CONTEXT DIAGRAM

System Design Chapter 4

7

4.2 SYSTEM ARCHITECTURE

Our System is a Client-Server Model Extension. Our System consists of Single

Server Agent and Multiple Client Agents (distributed & connected through network).

The Server Agent Consists of Global Decision Manager and Global Control

Manager to handle the Global decision rule set which are used decide which client agent

need to connect and what signal produced & send to the embedded system component

controller for the given request.

The Client Agent Consists of Data Fetcher to handle the USB port for data

retrieval and data transmission and Local Control & Decision Manager to handle the

Local decision rule set which are used to decide what signal produced & send to the

System Design Chapter 4

8

embedded system component controller for the given request or generate signal when

any conditional trigger occurrences in the controller and a Data Visualizer to handle the

past data’s of embedded system component and present the data in visual graph from

specified parameters of component.

To optimize the performance an extended Queue is designed with Multiple

Fetchers (MIMO [Multi-In Multi-Out]). This queue is used in both Client & Server Agents

to handle Requests.

.

Implementation Chapter 5

10

CHAPTER 5

IMPLEMENTATION

This phase is broken up into two phases: Development and Implementation. The

individual system components are built during the development period. Programs are

written and tried by users. During Implementation, the components built during

development are put into operational use. In the development phase of our system, the

following system components were built.

• Server Agent module

• Client Agent module

5.1 Server Agent Module 5.1.1 Queue

• Contains methods (enqueue, multi-fetch dequeue, …) to handle the

Signal(dev_id,sig_id,time) type data.

5.1.2 Global Control Manager

• Contains methods (signal forward, queue fetch, rule check , …) to handle the

client agents requests.

5.1.3 Global Decision Manager

• Contains methods to handle the Local decision rule set which are decide

which client agent and what signal produced & send to the embedded system

component controller for the given request.

Implementation Chapter 5

11

5.2 Client Agent Module 5.2.1 Data Fetcher Module

• Contains methods to handle the USB port for data retrieval and data

transmission. The data from USB port is coming from Embedded system

component controller.

5.2.2 Queue • Contains methods (enqueue, multi-fetch dequeue, …) to handle the

Signal(dev_id,sig_id,time) type data which are sent by the global control

manager.

5.2.3 Local Control Manager

• Contains methods (signal forward, queue fetch, rule check , …) to handle the

arrived client agent requests.

5.2.4 Local Decision Manager

• Contains methods to handle the Local decision rule set which are decide

what signal produced & send to the embedded system component controller

for the given request or generate signal when any conditional trigger

occurrences in the controller.

5.2.3 Data Visualizer • Contains methods to handle the past data’s of embedded system component

and present the data in visual graph from specified parameters of component.

Testing Chapter 6

12

CHAPTER 6

TESTING

This chapter explains the various testing procedures conducted on the system.

Testing is a process of executing a program with the intent of finding an error. A

successful test is one that uncovers an as yet undiscovered error. A testing process

cannot show the absence of defects but can only show that software errors are present.

It ensures that defined input will produce actual results that agree with the required

results. A good testing methodology should include

• Clearly define testing roles, responsibilities and procedures

• Establish consistent testing process

• Streamline testing requirements

• Overcome “requirements slow me down” mentality

• Common sense process approach

• Use some elements of existing Process

• Not an attempt to replace, rewrite or redefine Process

• To find defects early and to give good time to developers for bug fixes

• Independent perspective in testing

Some of the testing principles used in this project are:

• Unit Testing

• Integration Testing

6.1 UNIT TESTING Unit testing is a strategy by which individual components, which make up the

system, are tested first to ensure that system works up to the desired extent. It focuses

on the verification effort on the smallest unit of the software design i.e. module. Various

modules of the system are tested to see whether they perform their intended functions.

Using procedural design description, important control paths are tested to uncover the

Testing Chapter 6

13

errors with in the boundary of the module. While accepting a connection using specified

functions we go for unit testing in their respective modules. The unit test is normally a

white box test (a testing method in which the control structure of the procedural design is

used to derive test cases).

6.1.1 Process Objectives To test every unit of the software in isolation before integrating it with other units

6.1.2 Definition of Unit

A unit is a module as identified during size estimation process with a size

estimate that does not exceed 1000LOC.

For GUI applications each screen will be a unit.

If the size estimate for a unit exceeds 1000 LOC and it is not feasible to break it

into smaller logically independent units that can be tested in isolation, the project lead in

concurrence with the SQA can decide to define this as a unit.

6.1.3 Entry Criteria The entry criteria for this process are the following:

• Unit completed

• Unit peer reviewed

6.1.4 Exit Criteria The exit criteria for this process are the following:

• Unit test cases executed

• Any defects that are identified during unit testing and that are not fixed before the

unit enters component testing is listed in the test report and verified

• 100% statement coverage

If unit will be tested before code review of unit, this must be identified in the

project plan. In these projects the developer will self-review (desk check) the code

before unit testing.

In cases of exception handling of error conditions that are difficult to generate,

thereby making it impossible to achieve 100% statement coverage, the code should be

formally reviewed with this additional criteria

Testing Chapter 6

14

6.2 INTEGRATION TESTING The integration testing is a systematic technique for constructing the program

structure while conducting tests to uncover errors associated with interfacing. It is a type

of testing by which the individual modules of the system are combined and tested

whether they work properly as a whole. The objective is to take unit test modules and

build a program that has been dictated by the design. Integration testing can be either

‘Incremental’ or ‘Non-Incremental’.

The objective of the integration testing is to help engineers plan and execute the

component and Integration testing for their respective projects.

Integration testing should include the following objectives:

• Performed by the product group/Dev test team after feature complete

• Determines that all product components on a list of specific platforms function

successfully together (The List specified in Master test plan)

• Performed in a basic product / platform environment (Basic environment

specified in Master test plan)

• Tests the product functionality against the specification

• Tests functionality of fake languages with sample single and double byte

languages

• Tests scaling to an acceptable minimum level as called out in the master test

plan

• Tests performance, reliability to an acceptable level as called out in the master

test plan

• Final integration tests done after all components are integrated, with the build in

production format

The tasks of the project have been integrated and the functioning of the entire

system has been found to be satisfactory. The functionality of the entire system has

been subjected to a series of tests and all the modules have been found to interoperate

properly.

Finally the integration testing was performed on the integrated system and found

to work properly.

Testing Chapter 6

15

6.3 REAL TIME SYSTEM TESTING A Real Time System must run continuously until it has been powered off and •

Failure to run properly can mean great economic loss and/or loss of human life. So the

testing of Real time System Applications are critical in nature.

We can minimize failure in real time systems by Software Test (various levels),

System Test, Build test and recovery software and/or hardware into the design,

Exception handling (limit checking, etc.) to recover from bad data inputs, Redundant

hardware solutions (e.g. 5 processors on Space Shuttle), Fault Tolerant software and

hardware .

Black Box Testing

• – Only inputs and outputs of functions are considered

• – How outputs are generated based on a set of inputs is ignored

• – Run a suite of test cases

o • Exhaustive combination of all inputs

o • Corner cases (min, max, avg)

o • Pathological cases (inputs likely to result in error)

• – Disadvantage: Often bypasses unreachable code

White Box Testing

• – Exercises all paths in a module

• – Driven by logic

Testing Chapter 6

16

• – Static Example: Code Inspections

o • group walkthrough of software logic

o • inspect code line-by-line

• – Dynamic Example: Test all the links and buttons on a web page

6.4 SAMPLE TEST CASES The following are the some of the sample test cases employed along with the

test results have been described in the table below.

Table 6.1 Sample Test Cases

Test Description

Result

Is Agents running with more than one real time components? OK

Is All Agents are return the results properly? OK

Is Agents executes Optimally? OK

Is Decision control computed Accurately? OK

Is Synchronization between all Agents are fine with no errors? OK

Snapshot Chapter 7

16

CHAPTER 7

SNAPSHOT

This chapter contains the snapshot of various snaps from our system.

7.1 Local Decision Manager and Control Manager

7.2 Signal Processing

Conclusion

17

CONCLUSION

The propose method improves the concurrency & Synchronization between the

agents and also maintains the accuracy of data between the components of distributed

embedded systems components. The proposed method gives the best software agents

which are give good accuracy for tracking and controlling of distributed embedded

systems components. Also the extended support of Decision control rules gives better

conditional control over the distributed embedded systems components.

Bibliography

19

BIBLIOGRAPHY

• [1] Hu Jin, Liang-Yin Chen, Nian-Wei Chen, Yang Lei, "Software Agent Design with Real Time Scheduling for Embedded Systems”, pp. 443-447, 2009 International Conference on Embedded Software and Systems, 2009

• [2] X.Koutsoukos, R.Tekumalla, B.Natarajan, C.Lu. ”Hybrid Supervisory Utilization

Control of Real-Time Systems”. 11th IEEE RTAS 2005

• [3] T. Abdelzaher, J. Stankovic, C. Lu, R. Zhang, and Y. Lu. ”Feedback performance control in sofware services”. IEEE Control Systems, 23(3), June 2003

• [4] B. Kao and H. Garcia-Molina. “Deadline assignment in a distributed soft real-time

system”. IEEE Trans. Parallel Distrib. Syst., 8(12):1268–1274, 1997. • [5] [Booch 1994] Booch, G. Object Oriented Analysis and Design with Applications

(second edition), Benjamin/Cummings 1994, ISBN 0-8053-5340-2.

• [6] Java Network Programming, O'Reilly & Associates, Inc.,, Second Edition

Websites

http://java.sun.com/javase/technologies/realtime/ http://jusb.sourceforge.net/ http://javax-usb.org

Future Enhancements

18

FUTURE ENHANCEMENTS

Currently a prior step is needed to setup all Decision Control Rules for remote

controlling of components before the starting of the Agents. In future New Decision

Control Rules are accepted & adopted dynamically. In Future Agents are developed

using JavaRTOS (which supports Nano Second Threads and highly improved

Concurrency & Synchronization). Currently Agents provides only Aggregated Reports for

visualization, In Future individual Real time visualization reports are produced

dynamically. In Future Agents are extended to support different input methods like

Blutooth, IR …