Temporal Partitioning of Communication Resources in an Integrated Architecture Documentation

TEMPORIAL PARTITIONING OF COMMUNICATION

RESOURCES IN AN INTEGRATED ARCHITECTURE

Project report Submitted in the partial fulfillment for the requirement for the

award of Degree of

MASTER OF TECHNOLOGYIN

COMPUTER SCIENCE AND ENGINEERING

By

MEDIDA JAYAPAL08E21D5808

Under the esteemed guidance of

Mr J.SASI KIRAN Associate Professor & HOD- CSE

Department of Computer Science and Engineering

Vidya Vikas Institute of Technology

(Affiliated to Jawaharlal Nehru Technological University)

Hyderabad

2008-2010

VIDYA VIKAS INSTITUTE OF TECHNOLOGYChevella, R.R.Dist., A.P

( Approved by AICTE , New Delhi, Affiliated to J.N.T.U HYDERABAD )

Ref No. VVIT /O8E21D5808 Date:

CERTIFICATE

This is to certify that the project report entitled TEMPORIAL

PARTITIONING OF COMMUNICATION RESOURCES IN AN INTEGRATED

ARCHITECTURE Being submitted by Mr MEDIDA JAYAPAL, bearing Roll

no 08E21D5808 in partial fulfillment of the requirement for the award of

degree in MASTER OF TECHNOLOGY in COMPUTER SCIENCE

AND ENGINEERING to Jawarharlal Nehru Technological University is a

record work of bonafied work carried out by him under my guidance and

supervision. The result embodied in this projet report have not been submitted

to any other University or Institute or the award of any Degree or Diploma .

HEAD OF THE DEPARTMENT PRINCIPLAL

Mr. J.SASIKIRAN M.Tech., (Ph.D), DR A.GANGADHAR

Associate Professor &HOD -CSE

VIDYA VIKAS INSTITUTE OFTECHNOLOGY

(Approved by AICTE, New Delhi, Affiliated to J.N.T.University)Chevella, R.R. Dist, A.P.

Ref No. VVIT/08E21d5808 Date: ………..BONAFIED CERTIFICATE

This is to confirm that Mr MEDIDA JAYAPAL bearing rollno 08E21D5808 is a bonafide student of this college studying M.Tech(Computer Science and Engineering) II YEAR-II SEM. He is doing hisProject work entitled “Temporal Partitioning of CommunicationResources in an Integrated Architecture” in the college, in theDepartment of Computer Science and Engineering under my guidance.Certified further, that to the best of my knowledge the work reportedherein does not form part of any other thesis or dissertation on the basisof which a degree or award was conferred on an earlier occasion ofthesis of any other candidate.

PROJECT SUPERVISORSignature :

Name : J.SASIKIRAN Designation : Associate Professor &

Head of the Department Department : CSE University/College/Organization With address : VIDYA VIKAS INSTITUTE OF TECHNOLOGY

CHEVELLA, HYDERABADHEAD OF THE DEPARTMENT

Signature : Name : J. SASIKIRAN Designation :Associate Professor &

Head of the Department Department : CSE University/College/Organization With address : VIDYA VIKAS INSTITUTE OF TECHNOLOGY

CHEVELLA, HYDERABAD

DECLARATION

I hereby declare that the work presented in this project report entitled

“TEMPORAL PARTITIONING OF COMMUNICATION RESOURCES

IN AN INTEGRATED ARCHITECTURE” is done by me in Computer

Science and Engineering, VIDYA VIKAS INSTITUTE OF TECHNOLOGY,

Hyderabad (JNTU Affiliated) . No part of the dissertation is copied from

books/journals/internet and whenever the portion is taken, the same has been

duly referred in the text. The report is based on the project work done entirely

by me and not copied from any other source.

M.JAYAPAL

08E21D5808

ACKNOWLEDGEMENT

My express thanks and gratitude and thanks to Almighty God, my parents and other

family members and friends without whose uncontained support, I could not have made

this career in Master of Technology in C.SE.

I wish to place on my record my deep sense of gratitude to my project guide,

Mr. J.Sasi Kiran, Head of the Department for his constant motivation and valuable help

through the project work. Express my gratitude to Dr A Gangadhar, Principal Vidhya

Vikas Insititute of Technology for his valuable suggestions and advices through out the

course. I also extend my thanks to other Faculties for their Cooperation during my Course.

Finally I would like to thank my friends for their cooperation to

complete this project.

MEDIDA JAYAPAL

08E21D5808

vi

ABSTRACT

The project titled “Temporal Partitioning of Communication Resources

in an Integrated Architecture ” in the automotive and avionic domain promise improved

resource utilization and enable a better coordination of application subsystems compared to

federated systems. An integrated architecture shares the system’s communication resources

by using a single physical network for exchanging messages of multiple application

subsystems. Similarly, the computational resources (for example, memory and CPU time)

of each node computer are available to multiple software components. In order to support a

seamless system integration without unintended side effects in such an integrated

architecture, it is important to ensure that the software components do not interfere through

the use of these shared resources. For this reason, the DECOS integrated architecture

encapsulates application subsystems and their constituting software components. At the

level of the communication system, virtual networks on top of an underlying time-triggered

physical network exhibit predefined temporal properties (that is, bandwidth, latency, and

latency jitter). Due to encapsulation, the temporal properties of messages sent by a software

component are independent from the behavior of other software components, in particular

from those within other application subsystems

vii

TABLE OF CONTENTS

CHAPTER NO TITLE PAGE NO

ABSTRACT vi

LIST OF FIGURES xi

LIST OF ABBREVIATIONS xii

1. Introduction ……………………………………………………………………….1

2. Software and hardware requirement analysis…………..………………………..2

2.1 Hardware configuration …………………………………….2

2.2 Software configuration………………………………………..2

2.3 System development environment……………………………3

2.3.1 Introduction to .Net Frame Work………………….3

2.3.2Principal Design feature of .Net…………………….4

2.3.2.2 Common Runtime Engine ……………………….4

2.3.2.3 Base Class Library ………………………………4

2.3.2.4 Simplified Deployment ………………………….4

2.3.2.5 Security…………………………………………...5

2.3.2.6 Portability ………………………………………...5

2.3.2.7 Architecture…………………………………….....6

2.3.2.8 Common Language Infrastructure……………….6

2.3.2.9 Assemblies………………………………………..7

2.3.2.10 Metadata…………………………………………7

2.3.2.11 Class library……………………………………..8

2.3.2.12 Memory management……………………….......8

2.3.2.12 Versions……………………………………........11

viii

2.3.1 C#.NET Overview:……………………………………………….11

2.3.1.1 ADO.NET………………………………………11

2.3.1.2 Connections…………………………………….13

2.3.1.3 Command……………………….……………..13

2.3.1.4 Data Reader……………………….………….14

2.3.1.5 Dataset and Data Adapters……………………………..……..14

3. Literature survey…………………………………………………………………..17

3.1 Feasibility study……………………………………………………17

3.2 Existing system……………………………………………….……18

3.3 Proposed system……………………………………………............19

3.3.1 Mechanisms for temporal partitioning in communication

system of an integrated architecture……………..………....19.

3.3.2 Communication infrastructure for heterogeneous

application subsystems…………………………………..……19

3.3.3 Experimental assessment of temporal partitioning.…….20

3.3.4. Experimental assessment of performance……………...20

3.4 Avionic domain………………………………………………….....20

3.5 Decos………………………………………………………………..21

3.6 Virtual networks…………………………………….………………22

3.7 Time division multiple access…………………………….………..24

3.8 X-by wire …………………………………………………………..26

3.9 RTOS……………………………………………………………......27

4. System requirement analysis…………………………………………………….28

ix

4.1 Problem description…………………………………………………28

4.2 Modules description………………………………………….……..28

4.2.1 Inner-Node Partitioning module…………………………..29

4.2.2 Encapsulation module ……………………………….......29

4.2.3 Mediation of Data Flow module…………………………..29

4.2.4 Virtual networks module………………………………….30

4.2.5 Message Timing module…………………………….........30

5. System design……………………………………………………………............31

5.1 technical specifications……………………………………………..31

5.1.1 UML Diagrams…………………………………………...31

5.1.2 Types of UML Diagrams…………………………………31

5.1.2.1 Use case diagrams………………………………32

5.1.2.2 Class diagrams………………………………….32

5.1.2.3 Sequence diagrams……………………………..32

5.1.2.4 Collaboration diagrams…………………………32

5.1.2.5 Activity diagrams……………………………….33

5.1.2.6 State chart diagrams……………………............33

5.1.2.7 Component diagrams…………………………..33

5.1.2.8 Deployment diagrams………………………….33

5.2 Data Flow Diagram………………………………………………….35

5.3 System architecture ………………………………………………....36

5.4 UML Diagram .................................................................................37

6. Coding…………………………………………………….…………………..44

7. System testing and maintenance…………………………...….……………..48

x

7.1 Testing ……………………………………………………..............48

7.2 purpose of testing……………………………….……………………52

7.3 Testing Types……………………………………………….…………..52

7.3.1 Black box testing:…………………………………………..……52

7.3.2 White box testing:………………………………..………………52

7.3.3 Unit testing: ………………………………………………………53

7.3.4 Incremental integration testing: …………………..……………...53

7.3.5 Integration testing:………………………………………………..53

7.3.6 Functional testing: …………………………………….…………53

7.3.7 System testing: ……………………………………..……………53

7.3 Maintenance………………………………………………….…..................54

8. Output screens……………………………………………………..…...............55

9. Conclusion……………………………………………………………...............66

10 Scope for future enhancement………………………………………………….69

11. Bibliography……………………………………………………………………..70

xi

List of figures

Fig. No Name of the figures Page No’s

2.1 Net Architecture 7

2.2 Microsoft .NET Framework includes a set of standard class

libraries.

10

2.3 Net Framework Stack 11

3.1 DECOS real time systems 22

3.2 DECOS Architecture 22

3.3 Virtual network architecture 24

3.4 TDMA Architecture 25

5.1 Data Flow Diagram 35

5.2 System architecture 36

5.3 Use case Diagram 37

5.4 Class Diagram 38

5.5 Object Diagram 39

5.6 State Chart Diagram 40

5.7 Activity Diagram 41

5.8 Collaboration Diagram 42

5.9 Sequence Diagram 43

7.1 System testing 49

8.1 Starting Screen 55

xii

8.2 Browse for a resource

56

8.3 Ready for Encapsulation of process

57

8.5 Path of Encapsulated file 58

8.6 Before starting the transfer of the file over virtual network

59

8.7 Transfer of the file in progress over virtual network

60

8.8 Screen after completion of transfer of file over virtual network

61

8.9 Details of transfer in case of any failure of circuits 62

8.10 Details of transfer without any failure of circuits

63

8.11 Details description of transfer over an integrated Architecture

64

xiii

List of Abbreviations

S.No Symbol Description

1 DECOS Dependable Embedded Components and Systems

2 CLR Common Language Runtime

3 TDMA Time division multiple access

4 GSM Global System for Mobile Communications

5 PDC Personal Digital Cellular

6 CDMA Code division multiple access

7 RTOS A Real-Time Operating System

8 VN Virtual Network

CHAPTER 1

INTRODUCTION

1

Temporal Partitioning of Communication Resources in an Integrated Architecture

CHAPTER 1

INTRODUCTION

Integrated architectures in the automotive and avionic domain promise

improved resource utilization and enable a better coordination of application

subsystems compared to federated systems. An integrated architecture shares the

system’s communication resources by using a single physical network for

exchanging messages of multiple application subsystems. Similarly, the

computational resources (for example, memory and CPU time) of each node

computer are available to multiple software components. In order to support a

seamless system integration without unintended side effects in such an

integrated architecture, it is important to ensure that the software components do

not interfere through the use of these shared resources. For this reason, the

DECOS integrated architecture encapsulates application subsystems and their

constituting software components. At the level of the communication system,

virtual networks on top of an underlying time-triggered physical network exhibit

predefined temporal properties (that is, bandwidth, latency, and latency jitter).

Due to encapsulation, the temporal properties of messages sent by a software

component are independent from the behavior of other software components, in

particular from those within other application subsystems

CHAPTER 2

SOFTWARE AND HARDWARE

REQUIREMENTS

2


CHAPTER 2

SOFTWARE AND HARDWARE REQUIREMENT

ANALYSIS

In the literature survey we have seen the different existed system and the

problems of those systems. The system which is to overcome the problems of existed

system is analyzed in this chapter with its requirements. This chapter describes the

hardware specifications that we are required for the proposed system.

2.1 HARDWARE CONFIGURATION

§ Hard disk : 40 GB

§ RAM : 512MB

§ Processor : Pentium IV

2.2 SOFTWARE CONFIGURATION

§ VS .NET 2005

§ C#.Net

§ Windows XP.

3


2.3 System Development Environment

2.3.1 Introduction To.NET Framework

The Microsoft .NET Framework is a software technology that is available with

several Microsoft Windows operating systems. It includes a large library of pre-coded

solutions to common programming problems and a virtual machine that manages the

execution of programs written specifically for the framework. The .NET Framework is a

key Microsoft offering and is intended to be used by most new applications created for

the Windows platform.

The pre-coded solutions that form the framework's Base Class Library cover a

large range of programming needs in a number of areas, including user interface, data

access, database connectivity, cryptography, web application development, numeric

algorithms, and network communications. The class library is used by programmers,

who combine it with their own code to produce applications.

Programs written for the .NET Framework execute in a software environment

that manages the program's runtime requirements. Also part of the .NET Framework,

this runtime environment is known as the Common Language Runtime (CLR). The

CLR provides the appearance of an application virtual machine so that programmers

need not consider the capabilities of the specific CPU that will execute the program.

The CLR also provides other important services such as security, memory management,

and exception handling. The class library and the CLR together compose the .NET

Framework.

4


2.3.2 Principal design features of .NET:

2.3.2.1 Interoperability

Because interaction between new and older applications is commonly required,

the .NET Framework provides means to access functionality that is implemented in

programs that execute outside the .NET environment. Access to COM components is

provided in the System. Runtime Interop Services and System. Enterprise Services

namespaces of the framework; access to other functionality is provided using the

P/Invoke feature.

2.3.2.2 Common Runtime Engine

The Common Language Runtime (CLR) is the virtual machine component of the

.NET framework. All .NET programs execute under the supervision of the CLR,

guaranteeing certain properties and behaviors in the areas of memory management,

security, and exception handling.

2.3.2.3 Base Class Library

The Base Class Library (BCL), part of the Framework Class Library (FCL), is a

library of functionality available to all languages using the .NET Framework. The BCL

provides classes which encapsulate a number of common functions, including file

reading and writing, graphic rendering, database interaction and XML document

manipulation.

2.3.2.4 Simplified Deployment

Installation of computer software must be carefully managed to ensure that it

does not interfere with previously installed software, and that it conforms to security

requirements. The .NET framework includes design features and tools that help address

these requirements..

5


2.3.2.5 Security

The design is meant to address some of the vulnerabilities, such as buffer

overflows, that have been exploited by malicious software. Additionally, .NET provides

a common security model for all applications.

NET has its own security mechanism with two general features: Code Access

Security (CAS), and validation and verification. Code Access Security is based on

evidence that is associated with a specific assembly. Typically the evidence is the

source of the assembly (whether it is installed on the local machine or has been

downloaded from the intranet or Internet). Code Access Security uses evidence to

determine the permissions granted to the code. Other code can demand that calling code

is granted a specified permission. The demand causes the CLR to perform a call stack

walk: every assembly of each method in the call stack is checked for the required

permission; if any assembly is not granted the permission a security exception is

thrown.

2.3.2.6 Portability

The design of the .NET Framework allows it to theoretically be platform

agnostic, and thus cross-platform compatible. That is, a program written to use the

framework should run without change on any type of system for which the framework is

implemented. Microsoft's commercial implementations of the framework cover

Windows, Windows CE, and the Xbox 360. In addition, Microsoft submits the

specifications for the Common Language Infrastructure (which includes the core class

libraries, Common Type System, and the Common Intermediate Language), the C#

language, and the C++/CLI language to both ECMA and the ISO, making them

6


available as open standards. This makes it possible for third parties to create compatible

implementations of the framework and its languages on other platforms.

2.3.2.7 Architecture

Fig 2.1 Architecture

2.3.2.8 Common Language Infrastructure

The core aspects of the .NET framework lie within the Common Language

Infrastructure, or CLI. The purpose of the CLI is to provide a language-neutral platform

for application development and execution, including functions for exception handling,

garbage collection, security, and interoperability. Microsoft's implementation of the CLI

is called the Common Language Runtime or CLR.

7


2.3.2.9 Assemblies

The intermediate CIL code is housed in .NET assemblies. As mandated by

specification, assemblies are stored in the Portable Executable (PE) format, common on

the Windows platform for all DLL and EXE files. The assembly consists of one or more

files, one of which must contain the manifest, which has the metadata for the assembly.

The complete name of an assembly (not to be confused with the filename on disk)

contains its simple text name, version number, culture, and public key token. The public

key token is a unique hash generated when the assembly is compiled, thus two

assemblies with the same public key token are guaranteed to be identical from the point

of view of the framework. A private key can also be specified known only to the creator

of the assembly and can be used for strong naming and to guarantee that the assembly is

from the same author when a new version of the assembly is compiled (required to add

an assembly to the Global Assembly Cache).

2.3.2.10 Metadata

All CLI is self-describing through .NET metadata. The CLR checks the

metadata to ensure that the correct method is called. Metadata is usually generated by

language compilers but developers can create their own metadata through custom

attributes. Metadata contains information about the assembly, and is also used to

implement the reflective programming capabilities of .NET Framework.

.

8


2.3.2.11 Class library

Namespaces in the BCL

SystemSystem. Code DomSystem. CollectionsSystem. Diagnostics

System. GlobalizationSystem. IO

System. ResourcesSystem. Text

System. Text. Regular Expressions

Fig 2.2

Microsoft .NET Framework includes a set of standard class libraries. The class

library is organized in a hierarchy of namespaces. Most of the built in APIs are part of

either System.* or Microsoft.* namespaces. It encapsulates a large number of common

functions, such as file reading and writing, graphic rendering, database interaction, and

XML document manipulation, among others. The .NET class libraries are available to

all .NET languages. The .NET Framework class library is divided into two parts: the

Base Class Library and the Framework Class Library.

The Base Class Library (BCL) includes a small subset of the entire class library

and is the core set of classes that serve as the basic API of the Common Language

Runtime. The classes in mscorlib.dll and some of the classes in System.dll and

System.core.dll are considered to be a part of the BCL. The BCL classes are available in

both .NET Framework as well as its alternative implementations including .NET

Compact Framework, Microsoft Silver light and Mono.

9


The Framework Class Library (FCL) is a superset of the BCL classes and refers

to the entire class library that ships with .NET Framework. It includes an expanded set

of libraries, including Win Forms, ADO.NET, ASP.NET, Language Integrated Query,

Windows Presentation Foundation, Windows Communication Foundation among

others. The FCL is much larger in scope than standard libraries for languages like C++,

and comparable in scope to the standard libraries of Java.

2.3.2.12 Memory management

The .NET Framework CLR frees the developer from the burden of managing

memory (allocating and freeing up when done); instead it does the memory

management itself. To this end, the memory allocated to instantiations of .NET types

(objects) is done contiguously from the managed heap, a pool of memory managed by

the CLR. As long as there exists a reference to an object, which might be either a direct

reference to an object or via a graph of objects, the object is considered to be in use by

the CLR. When there is no reference to an object, and it cannot be reached or used, it

becomes garbage. However, it still holds on to the memory allocated to it. .NET

Framework includes a garbage collector which runs periodically, on a separate thread

from the application's thread, that enumerates all the unusable objects and reclaims the

memory allocated to them.

The .NET Garbage Collector (GC) is a non-deterministic, compacting, mark-

and-sweep garbage collector. The GC runs only when a certain amount of memory has

been used or there is enough pressure for memory on the system. Since it is not

guaranteed when the conditions to reclaim memory are reached, the GC runs are non-

deterministic. Each .NET application has a set of roots, which are pointers to objects on

10


the managed heap (managed objects). These include references to static objects and

objects defined as local variables or method parameters currently in scope, as well as

objects referred to by CPU registers. When the GC runs, it pauses the application, and

for each object referred to in the root, it recursively enumerates all the objects reachable

from the root objects and marks them as reachable. It uses .NET metadata and reflection

to discover the objects encapsulated by an object, and then recursively walk them. It

then enumerates all the objects on the heap (which were initially allocated contiguously)

using reflection. All objects not marked as reachable are garbage. This is the mark

phase. Since the memory held by garbage is not of any consequence, it is considered

free space. However, this leaves chunks of free space between objects which were

initially contiguous. The objects are then compacted together, by using memory to copy

them over to the free space to make them contiguous again. Any reference to an object

invalidated by moving the object is updated to reflect the new location by the GC. The

application is resumed after the garbage collection is over.

11


2.3.2.12 Versions

Microsoft started development on the .NET Framework in the late 1990s

originally under the name of Next Generation Windows Services (NGWS). By late

2000 the first beta versions of .NET 1.0 were released.

Fig 2.3 .Net Framework Stack

2.3.1 C#.NET Overview:

2.3.1.1 ADO.NET

ADO.NET is an evolution of the ADO data access model that directly addresses

user requirements for developing scalable applications. It was designed specifically for

the web with scalability, statelessness, and XML in mind.

12


ADO.NET uses some ADO objects, such as the Connection and Command

objects, and also introduces new objects. Key new ADO.NET objects include the

Dataset, Data Reader, and Data Adapter.

The important distinction between this evolved stage of ADO.NET and previous

data architectures is that there exists an object -- the Dataset -- that is separate and

distinct from any data stores. Because of that, the Dataset functions as a standalone

entity. You can think of the Dataset as an always disconnected record set that knows

nothing about the source or destination of the data it contains. Inside a Dataset, much

like in a database, there are tables, columns, relationships, constraints, views, and so

forth.

A Data Adapter is the object that connects to the database to fill the Dataset.

Then, it connects back to the database to update the data there, based on operations

performed while the Dataset held the data. In the past, data processing has been

primarily connection-based. Now, in an effort to make multi-tiered apps more efficient,

data processing is turning to a message-based approach that revolves around chunks of

information. At the center of this approach is the Data Adapter, which provides a bridge

to retrieve and save data between a Dataset and its source data store. It accomplishes

this by means of requests to the appropriate SQL commands made against the data

store.

The following sections will introduce you to some objects that have evolved, and

some that are new. These objects are:

• Connections. For connection to and managing transactions against a database.

13


• Commands. For issuing SQL commands against a database.

• Data Readers. For reading a forward-only stream of data records from a SQL

Server data source.

• Dataset. For storing, removing and programming against flat data, XML data

and relational data.

• Data Adapters. For pushing data into a Dataset, and reconciling data against a

database.

When dealing with connections to a database, there are two different options:

SQL Server .NET Data Provider (System.Data.SqlClient) and OLE DB .NET Data

Provider (System.Data.OleDb). In these samples we will use the SQL Server .NET Data

Provider. These are written to talk directly to Microsoft SQL Server. The OLE DB

.NET Data Provider is used to talk to any OLE DB provider (as it uses OLE DB

underneath).

2.3.1.2 Connections

Connections are used to 'talk to' databases, and are represented by provider-

specific classes such as SqlConnection. Commands travel over connections and result

sets are returned in the form of streams which can be read by a Data Reader object, or

pushed into a Dataset object.

2.3.1.3 Command

Commands contain the information that is submitted to a database, and are

represented by provider-specific classes such as SqlCommand. A command can be a

stored procedure call, an UPDATE statement, or a statement that returns results. You

can also use input and output parameters, and return values as part of your command

14


syntax. The example below shows how to issue an INSERT statement against the North

wind database.

2.3.1.4 Data Reader

The Data Reader object is somewhat synonymous with a read-only/forward-only

cursor over data. The Data Reader API supports flat as well as hierarchical data. A Data

Reader object is returned after executing a command against a database. The format of

the returned Data Reader object is different from a record set. For example, you might

use the Data Reader to show the results of a search list in a web page.

2.3.1.5 Dataset and Data Adapters

The Dataset object is similar to the ADO Record set object, but more powerful,

and with one other important distinction: the Dataset is always disconnected. The

Dataset object represents a cache of data, with database-like structures such as tables,

columns, relationships, and constraints. However, though a Dataset can and does behave

much like a database, it is important to remember that Dataset objects do not interact

directly with databases, or other source data. This allows the developer to work with a

programming model that is always consistent, regardless of where the source data

resides. Data coming from a database, an XML file, from code, or user input can all be

placed into Dataset objects. Then, as changes are made to the Dataset they can be

tracked and verified before updating the source data. The Get Changes method of the

Dataset object actually creates a second Dataset that contains only the changes to the

data. This Dataset is then used by a Data Adapter (or other objects) to update the

original data source.

15


Data Adapters (OLEDB/SQL). The Data Adapter object works as a bridge

between the Dataset and the source data. Using the provider-specific SqlDataAdapter

(along with its associated SqlCommand and Sql Connection) can increase overall

performance when working with a Microsoft SQL Server databases. For other OLE DB-

supported databases, you would use the OleDbDataAdapter object and its associated

OleDbCommand and OleDbConnection objects.

The Data Adapter0 object uses commands to update the data source after

changes have been made to the Dataset. Using the Fill method of the Data Adapter calls

the SELECT command; using the Update method calls the INSERT, UPDATE or

DELETE command for each changed row. You can explicitly set these commands in

order to control the statements used at runtime to resolve changes, including the use of

stored procedures. For ad-hoc scenarios, a Command Builder object can generate these

at run-time based upon a select statement. However, this run-time generation requires an

extra round-trip to the server in order to gather required metadata, so explicitly

providing the INSERT, UPDATE and DELETE commands at design time will result in

better run-time performance.

ADO.NET is the next evolution of ADO for the .Net Framework.

ADO.NET was created with n-Tier, statelessness and XML in the forefront. Two new

objects, the Dataset and Data Adapter, are provided for these scenarios.

1. ADO.NET can be used to get data from a stream, or to store data in a cache for

updates.

2. There is a lot more information about ADO.NET in the documentation.

16


Remember, you can execute a command directly against the database in order to do

inserts, updates, and deletes. You don't need to first put data into a Dataset in order to

insert, update, or delete it. Also, you can use a Dataset to bind to the data, move through

the data, and navigate data relationships

CHAPTER 3

LITERATURE SURVEY

17


CHAPTER 3

LITERATURE SURVEY

This chapter explains about the existed system, disadvantages of the existing

system and proposed system with its advantages. We can see the mechanism that is

being used and how we are overcoming the drawbacks of the existing system.

3.1 Feasibility study

The feasibility of the project is analyzed in this phase and business proposal is

put forth with a very general plan for the project and some cost estimates. During

system analysis the feasibility study of the proposed system is to be carried out. This is

to ensure that the proposed system is not a burden to the company. For feasibility

analysis, some understanding of the major requirements for the system is essential.

Three key considerations involved in the feasibility analysis are

v Economical feasibility

v Technical feasibility

v Social feasibility

Economical feasibility:

This study is carried out to check the economic impact that the system will have

on the organization. The amount of fund that the company can pour into the research

and development of the system is limited. The expenditures must be justified. Thus the

developed system as well within the budget and this was achieved because most of the

technologies used are freely available. Only the customized products had to be

purchased.

18


Technical feasibility

This study is carried out to check the technical feasibility, that is, the technical

requirements of the system. Any system developed must not have a high demand on the

available technical resources. This will lead to high demands on the available technical

resources. This will lead to high demands being placed on the client. The developed

system must have a modest requirement, as only minimal or null changes are required

for implementing this system.

Social feasibility

The aspect of study is to check the level of acceptance of the system by the user.

This includes the process of training the user to use the system efficiently. The user

must not feel threatened by the system, instead must accept it as a necessity. The level

of acceptance by the users solely depends on the methods that are employed to educate

the user about the system and to make him familiar with it. His level of confidence must

be raised so that he is also able to make some constructive criticism, which is

welcomed, as he is the final user of the system.

3.2 EXISTING SYSTEM

In present-day electronic systems, application subsystems from different

vendors and with different criticality levels are integrated within the same hardware.

Hence, encapsulation of these subsystems is required in the temporal as well as in the

spatial domain. Partitioning Operating Systems (OSs) are employed to allow shared

access of applications to critical resources within an integrated system. In recent years,

Integrated Modular Avionics (IMA) has been gaining more widespread adoption in civil

and military avionics programmes. Instead of using individual subsystems to perform a

19


dedicated function (known as a federated architecture), IMA uses generic computing

platforms to run multiple types of applications concurrently. This approach results in

fewer subsystems, reduced weight and less platform redundancy. Although there are a

number of different IMA approaches, they share the same high-level objectives

3.3 PROPOSED SYSTEM

In the proposed system we use the following technique to resolve the problem

with the data sharing. They are as follows.

3.3.1 Mechanisms for temporal partitioning in the communication system of

an integrated architecture.

Present a conceptual model of an integrated computer system that distinguishes

clearly between logical and physical structuring. Based on this model, we use the

communication slots of a time-triggered physical network and subdivide them

hierarchically for the structural entities of the logical and physical system structuring.

Software mechanisms (for example, communication middleware) in conjunction with

hardware mechanisms (for example, bus guardians) protect these communication slots

down to the level of individual software components, which can be collocated on shared

integrated node computers.

3.3.2 Communication infrastructure for heterogeneous application

subsystems.

The presented communication system supports both time-triggered and event-

triggered communication activities and the coexistence of application subsystems with

mixed criticality levels.

20


3.3.3 Experimental assessment of temporal partitioning.

In this paper, the invariance of the temporal properties of a communication

system comprising multiple VNs is subject to comprehensive tests. We provide

experimental evidence for the guaranteed temporal properties of the message

exchanges. Two experimental campaigns systematically explore different scenarios for

the behavior of software components at the communication system. We also assess the

effects of faulty software components (for example, babbling-idiot failures).

3.3.4. Experimental assessment of performance.

By comparing the observed performance with the bandwidth and latency

requirements of present-day and upcoming automotive applications, we demonstrate

that a communication system with rigid temporal partitioning can also support a

competitive temporal performance.

3.4 AVIONIC DOMAIN

Electronic instruments used in air or space flight; also the design and production

of such instruments. Early planes had few instruments, but as aviation and aircraft

became more complex, so did instrumentation. Most of the new technology was

electronic; hence, the expression "aviation electronics" arose and was later shortened to

"avionics." After World War II, the increasing sophistication of military avionics helped

spawn a proliferation of electronic applications to commercial and private aviation.

Avionics includes numerous types of devices, including those used for navigation (see

air navigation air navigation, science and technology of determining the position of an

aircraft with respect to the surface of the earth and accurately maintaining a desired

course

21


3.5 DECOS

Dependable Embedded Components and Systems .Over the past decades, the

development of computing systems to support safety-critical realtime computer

applications (nuclear, aerospace, railway, etc.) has often followed a customized solution

design approach. The reinvention of system design concepts, middleware and limited

reuse of code across diverse application domains are exacerbated by the extensive costs

of verifying and validating such complex single-of-a-kind safety critical systems. With

the expected deployment of safety-critical systems in many more application domains

(automotive, medical, process control, etc.) the availability of a component-based

methodology for the cost-effective design, implementation, validation, and certification

of integrated dependable embedded systems becomes instrumental for the

competitiveness of the European economy.

DECOS methodically targets, investigates, and develops approaches to

significantly alleviate elimination would be an idealised goal - the identified five key

obstacles - Electronic Hardware Cost, Diagnosis and Maintenance, Dependability,

Development Cost, Intellectual Property (IP) Protection - to the deployment of

advanced electronic functions in embedded systems. The intent is to provide an

integrated distributed execution platform and a set of pre-validated hardware

components and software modules and tools for the design of dependable embedded

systems. Generic design solutions for integrated dependable systems will be developed

such that the invariance of the design strategies and technology. Neutral interfaces are

considered upfront as a design objective. System design approaches that are applicable

to diverse application domains will be considered. We target automotive, aerospace,

railway, control and medical applications.

22


FIG 3.1

FIG 3.2

3.6 VIRTUAL NETWORKS

The virtual network architecture of Virtual Server 2005 allows the traffic in each

virtual network to be isolated from that of other virtual networks. Communication with

the host operating system and devices on the network is handled by the virtual machine

network services driver, which is installed by Virtual Server Setup on the host operating

system at a low level, just above the hardware network driver. The virtual machine

network services driver determines the routing of network packets, sending them to the

23


host operating system or a virtual network adapter assigned to a virtual machine. The

degree to which the network traffic of virtual machines and the host operating system is

isolated depends on the configuration of the virtual networks and virtual machines, as

follows:

• Virtual network not attached to a physical network adapter. In this scenario, the

virtual network is a self-contained private network with its own optional virtual DHCP

server. The network traffic of the virtual machines attached to this network and the host

operating system is completely isolated. The host operating system cannot read,

monitor, or capture the network traffic of the virtual machines, and the virtual machines

cannot read, monitor, or capture the network traffic of the host operating system. In

addition, all network traffic is confined to the physical computer—in other words,

isolated from the physical network.

• Virtual network attached to a dedicated physical network adapter. If no other

virtual networks are attached to this physical network adapter, the virtual machines

attached to this network cannot read, monitor, or capture the host operating system's

network traffic, nor can the host operating system read, monitor, or capture network

traffic between the virtual machines. The host operating system can, however, read,

monitor, or capture network traffic between a virtual machine and another device on the

physical network.

• Two or more virtual networks attached to the same physical network adapter.

When two virtual networks are attached to the same physical network adapter, the

network traffic is only partly isolated. Virtual machines attached to such virtual

networks will be able to read, monitor, and capture one another's inbound network

traffic, although they cannot read, monitor, and capture one another's outbound traffic.

24


• Virtual machines attached to the same virtual network. In this scenario, virtual

machines can read, monitor, and capture the network traffic of other virtual machines

attached to this virtual network. This is the same situation that exists when physical

computers are attached to the same network hub: they can read, monitor, and capture

one another's network traffic.

The following figure depicts virtual network architecture in Virtual Server.

FIG 3.3

3.7 TIME DIVISION MULTIPLE ACCESS

Time division multiple access (TDMA) It is a channel access method for shared

medium networks. It allows several users to share the same frequency channel by

dividing the signal into different time slots. The users transmit in rapid succession, one

25


after the other, each using his own time slot. This allows multiple stations to share the

same transmission medium (e.g. radio frequency channel) while using only a part of its

channel capacity . TDMA is used in the digital 2G cellular systems such as Global

System for Mobile Communications (GSM), IS-136, Personal Digital Cellular (PDC)

and iDEN , and in the Digital Enhanced Cordless Telecommunications (DECT)

standard for portable phones. It is also used extensively in satellite systems, and

combat-net radio systems. For usage of Dynamic TDMA packet mode communication,

see below.

FIG 3.4

TDMA is a type of Time-division multiplexing, with the special point that

instead of having one transmitter connected to one receiver , there are multiple

transmitters. In the case of the uplink from a mobile phone to a base station this

26


becomes particularly difficult because the mobile phone can move around and vary the

timing advance required to make its transmission match the gap in transmission from its

peers.

TDMA characteristics

§ Shares single carrier frequency with multiple users

§ Non-continuous transmission makes handoff simpler

§ Slots can be assigned on demand in dynamic TDMA

§ due to reduced intra cell interference

§ Higher synchronization overhead than CDMA

§ Cell breathing (borrowing resources from adjacent cells) is more complicated

than in CDMA

§ Frequency/slot allocation complexity

§ Pulsating power envelop: Interference with other devices

§ Less stringent power control than CDMA

§ Advanced equalization may be necessary for high data rates if the channel is "

frequency selective" and creates Inter symbol interference

3.8 X-BY WIRE

Drive-by-wire, DbW, by-wire, or x-by-wire technology in the automotive

industry replaces the traditional mechanical and hydraulic control systems with

electronic control systems using electromechanical actuators and human-machine

interfaces such as pedal and steering feel emulators. Hence, the traditional components

such as the steering column, intermediate shafts, pumps, hoses, fluids, belts, coolers and

brake boosters and master cylinders are eliminated from the vehicle. Examples include

electronic throttle control and brake-by-wire.

27


3.9 RTOS

A Real-Time Operating System (RTOS) IT is a computing environment that

reacts to input within a specific time period. A real-time deadline can be so small that

system reaction appears instantaneous. The term real-time computing has also been

used, however, to describe "slow real-time" output that has a longer, but fixed, time

limit. Learning the difference between real-time and standard operating systems is as

easy as imagining yourself in a computer game. Each of the actions you take in the

game is like a program running in that environment. A game that has a real-time

operating system for its environment can feel like an extension of your body because

you can count on a specific "lag time:" the time between your request for action and the

computer's noticeable execution of your request. A standard operating system, however,

may feel disjointed because the lag time is unreliable. To achieve time reliability, real-

time programs and their operating system environment must prioritize deadline

actualization before anything else. In the gaming example, this might result in dropped

frames or lower visual quality when reaction time and visual effects conflict.

The cockpit of an aircraft is a major location for avionic equipment, including

control, monitoring, communication, navigation, weather, and anti-collision systems.

The majority of aircraft drive their avionics using 14 or 28 volt DC electrical systems;

however, large, more sophisticated aircraft (such as airliners or military combat aircraft)

have AC systems operating at 115V 400 Hz, rather than the more common 50 and 60

Hz of European and North American, respectively, home electrical devices. There are

several major vendors of flight avionics, including Honeywell (which now owns

Bendix/King, Baker Electronics, Allied Signal, etc..), Rockwell Collins, Thales Group,

Garmin, Narco, and Avidyne Corporation

CHAPTER 4

SYSTEM REQUIREMENTS ANALYSIS

28


CHAPTER 4

SYSTEM REQUIREMENTS ANALYSIS

4.1 Problem Description

In present-day electronic systems, application subsystems from different vendors

and with different criticality levels are integrated within the same hardware. Hence,

encapsulation of these subsystems is required in the temporal as well as in the spatial

domain. Partitioning Operating Systems (OSs) are employed to allow shared access of

applications to critical resources within an integrated system. In recent years,

Integrated Modular Avionics (IMA) has been gaining more widespread adoption in

civil and military avionics programmes. Instead of using individual subsystems to

perform a dedicated function (known as a federated architecture), IMA uses generic

computing platforms to run multiple types of applications concurrently. This approach

results in fewer subsystems, reduced weight and less platform redundancy. Although

there are a number of different IMA approaches, they share the same high-level

objectives

4.2 Module Description

The project entitled as “Temporal Partitioning of Communication Resources in

an Integrated Architecture ” developed using .NET using C#. Modules display as

follows.

• Inner-Node Partitioning module

• Encapsulation module

• Mediation of Data Flow module

• Virtual networks module

29


• Message Timing module

4.2.1 Inner-Node Partitioning module

In avionics, the need for the temporal partitioning of communication

resources within a line-replaceable unit has gained high recognition it is stated that the

execution environment of each function in a cabinet should be as much like the

environment in the discrete line-replaceable unit. Therefore, SAFE bus has been

designed as a table-driven protocol, which enforces strict deterministic control for

temporal partitioning.

4.2.2 Encapsulation module

Due to encapsulation, developers need not look at all possible

interactions between jobs in order to understand the temporal behavior of a VN. In

particular, upon the occurrence of faults covered in the fault hypothesis, the

encapsulation of VNs preserves the modularization of the overall system jobs, as

introduced in the logical system structuring. The primary purpose of encapsulation is

the prevention of adverse effects on the message exchanges of a particular VN induced

by the message exchanges on other VNs.

4.2.3 Mediation of Data Flow module

The VNs presented in this project provide temporal partitioning with respect to

the communication resources. The only way in which a faulty job can affect other jobs

is by providing to the other jobs faulty inputs. The elimination of interference in the use

of communication resources is an important baseline for partitioning mechanisms at

higher levels. In particular, higher levels can focus on the mediation of data flows

between different levels of criticality.

30


4.2.4 Virtual networks module

An overlay network is a computer network that is built on top of another

network. The DECOS architecture provides overlay networks, which are denoted as

VNs, on top of a time-triggered physical network. Each VN handles the message

exchanges and provides encapsulation for the jobs by preventing jobs from affecting the

temporal properties of messages sent by other jobs.

4.2.5 Message Timing module

In this module each circuit is given separate work if a circuit fails it waits for the

given interval of time to check if the circuit gets repaired automatically if the circuit

remains un repaired and the file goes to the rest of the circuits.

CHAPTER 5

SYSTEM DESIGN

31


CHAPTER 5

SYSTEM DESIGN

This chapter discuss about the system design. It specifies how the project going

to be developed so as to requirements specified in the previous chapter. The

consequences listed in requirement analysis phase are used as input for this design

phase.

5.1 Technical Specification

The technical specification outlines all the information needed to define the

technical requirements of a site, including platform, system, hosting arrangements,

customizations of existing code and bespoke programming requirements.

5.1.1 UML Diagrams

UML stands for Unified Modeling Language. This object-oriented system of

notation has evolved from the work of Grady Booch, James Rumbaugh, Ivan Jacobson

and the Rational Software Corporation. These computer scientists fused their respective

technologies into a single standardized model.

The Unified Modeling Language (UML) is a standard language for specifying,

visualizing, constructing, and documenting the artifacts of software systems as well as

fro business modeling and other non-software systems.

5.1.2 Types of UML Diagrams

UML defines nine types of diagrams. Those are Class diagrams, Object diagram,

Use case diagram, Sequence diagram, Collaboration diagram, State chart diagram,

Activity Diagram, Component diagram and Deployment diagram.

32


5.1.2.1 Use case diagrams

A Use Case Diagram is a diagram that help system analyst to discover the

requirements of the target system from the user's perspective. It describes the behavior

of a system from a user’s standpoint and provides functional description of a system and

its major processes. It provides graphic description of the users of a system and what

kinds of interactions to expect within that system and displays the details of the

processes that occur within the application area.

5.1.2.2 Class diagrams

A class diagram describes the static structure of the symbols in your new system.

It is a graphic presentation of the static view that shows a collection of declarative

(static) model elements, such as classes, types, and their contents and relationships.

Classes are arranged in hierarchies sharing common structure and behavior, and are

associated with other classes.

5.1.2.3 Sequence diagrams

A Sequence diagram is a model that describes how groups of objects collaborate

in some behavior over time and capturing the behavior of a single use case. It shows the

objects and the messages that are passed between these objects in the use case.

5.1.2.4 Collaboration diagrams

A collaboration diagram is an interaction diagram that emphasizes the structural

organization of the objects that send and receive messages. It is crossed between a

symbol diagram and a sequence diagram. It describes a specific scenario. Numbered

arrows show the movement of messages during the course of a scenario. Collaboration

diagram express similar information as in sequence diagram, but shown in different way

33


5.1.2.5 Activity diagrams

Activity diagram describes activities and flows of data or decisions between

activities and provides a very broad view of business processes, breaks out the

activities that occur within a use case. It shows many different activities that will be

handled by lots of different symbols, shows parallel threads.

5.1.2.6 State chart diagrams

A state diagram provides a very detailed picture of how a specific symbol

changes states. A state refers to the value associated with a specific attribute of an object

and to any actions or side effects that occur when the attribute’s value changes.

5.1.2.7 Component diagrams

A component diagram is a simple, high-level diagram that shows the

organization of and dependencies among a set of components. Component diagrams

address the static implementation view of a system. There is usually a one-to-one

relationship between package diagrams and component diagrams.

5.1.2.8 Deployment diagrams

Deployment diagram shows the configuration of run time processing nodes and

the components that live on them, Shows a set of nodes and their relationships.

Design is multi-step process that focuses on data structure software architecture,

procedural details, (algorithms etc.) and interface between modules. The design process

also translates the requirements into the presentation of software that can be accessed

for quality before coding begins.

Computer software design changes continuously as new methods; better analysis

and broader understanding evolved. Software Design is at relatively early stage in its

revolution. Therefore, Software Design methodology lacks the depth, flexibility and

34


quantitative nature that are normally associated with more classical engineering

disciplines. However techniques for software designs do exist, criteria for design

qualities are available and design notation can be applied.

35


5.2 Data Flow Diagram

FIG 5.1

Stop

Efficiency

Procedure

Process Flows

Circuit

User

Next Circuit

Stores Separately

yes

No

36


5.3 System architecture

FIG 5.2

UserfixesTheprocess

Encapsulates sothat process not lost

Sends to everyCircuit

Whenever circuit failsefficiency gets reduced

Again encapsulationcarried out to preventprocess loss

Storesefficiency andtotal time

37


5.4 UML Diagram

Use case Diagram

FIG 5.3

GiveProcess

ProcessStarts

ProcessBreaks

Waits

NextProcess

Proceeds

Completes

ShowsEfficienc

y

38


Class Diagram

FIG 5.4

User

Sets Process()Sends Process()

Data Flow

Process Starts()Process Breaks()

Virtual Network

Integrated Architecture()

Encapsulation

Process Hiding()

Timing

Efficiency()Process Completion()Invalid Process()

39


Object Diagram

FIG 5.5

Process

Start Time

Process Size

VN

Partioning

Breaking

Encapsulation

Process Hiding

Message

Efficiency

User

40


State Chart Diagram

FIG 5.6

User SelectProcess

Encapsule

ProcessTransfers

CheckAvailability

ContinueEfficiencyWith Time

Graph

41


Activity Diagram

FIG 5.7

Calculates

Clear Defect

start

Select process

Temporal partitioning

Defect found

Efficiency

Chart

42


Collaboration Diagram

FIG 5.8

Sequence Diagram

User Select Process Encapsule

TimeEfficiency

1: Starts Process 2: Hides Process

3: Gives Process

4: Calculates

5: Graph

43


FIG 5.9

User : (User) Select Process Encapsule :(Encapsule)

Time : Time Efficiency :(Efficiency)

Starts Process

Hides Process

Gives Process

Calculates

Graph

CHAPTER 6

CODING

44


CHAPTER 6

Coding

Encapsulation module

using System;

using System.Collections.Generic;

using System.ComponentModel;

using System.Data;

using System.Drawing;

using System.Text;

using System.Windows.Forms;

using System.IO;

using java.util;

using java.util.zip;

using java.io;

namespace avionics

{

public partial class Form1 : Form

{

public static string t1,t2;

public long s1,s3;

public static long s2,s4;

45


string k;

public static string c1 = null, c2 = null, c3 = null, c4 = null, c5 = null, c6 = null;

public int i;

int f1=0;

public Form1()

{

InitializeComponent();

}

private void timer1_Tick(object sender, EventArgs e)

{

label1.Text = DateTime.Now.ToLongTimeString();

}

private void button1_Click(object sender, EventArgs e)

{

if (folderBrowserDialog1.ShowDialog() == DialogResult.OK)

{

System.IO.DirectoryInfo dir=new

System.IO.DirectoryInfo(folderBrowserDialog1.SelectedPath);

s1 = 0;

foreach (System.IO.FileInfo f in dir.GetFiles("*.*"))

{

k = folderBrowserDialog1.SelectedPath+"\\" + f.Name;

46


s1 = s1 + f.Length;

listBox1.Items.Add(k);

}

s2 = s1;

}

button2.Visible = true;

MessageBox.Show("Now Click ENCAPSULE Button to Encapsule The

Process", "ENCAPSULATION", MessageBoxButtons.OK,

MessageBoxIcon.Information);

}


{

if (saveFileDialog1.ShowDialog() == DialogResult.OK)

{

string[] list = new string[listBox1.Items.Count];

for (i = 0; i <= listBox1.Items.Count - 1; i++)

{

textBox1.Text = saveFileDialog1.FileName + ".zip";

list[i] = listBox1.Items[i].ToString();

}

MessageBox.Show("The Encapsulated FIle Is Located In The Path

"+saveFileDialog1.FileName+" ","ENCAPSULATION

DONE",MessageBoxButtons.OK, MessageBoxIcon.Information);

47


Zip(textBox1.Text.Trim(), list);

}

}

private void Zip(string zipfilename, string[] sourcefile)

{

FileOutputStream filopstrm = new FileOutputStream(zipfilename);

ZipOutputStream zipopstrm = new ZipOutputStream(filopstrm);

FileInputStream filipstrm = null;

foreach (string strfilname in sourcefile)

{

filipstrm = new FileInputStream(strfilname);

ZipEntry ze = new ZipEntry(Path.GetFileName(strfilname));

zipopstrm.putNextEntry(ze);

sbyte[] buffer = new sbyte[1024];

int len = 0;

while ((len = filipstrm.read(buffer)) >= 0)

{

zipopstrm.write(buffer, 0, len);

}

}

zipopstrm.closeEntry();

filipstrm.close();

zipopstrm.close();

48


filipstrm.close();

}

private void timer1_Tick_1(object sender, EventArgs e)

{

label1.Text = DateTime.Now.ToLongTimeString();

}


{ timer2.Enabled = true;

t1 = DateTime.Now.ToLongTimeString();

}

CHAPTER 7

SYSTEM TESTING AND MAINTENANCE

49


CHAPTER 7

SYSTEM TESTING AND MAINTENANCE

7.1TESTING

Fig 7.1System testing

Testing is vital to the success of the system. System testing makes a logical

assumption that if all parts of the system are correct, the goal will be successfully

Checks

Checks

Checks

Ends Ends Ends

Encapsulates

Procedure

Procedure

Procedure

Encapsulates

Circuit Circuit Circuit

50


achieved. In the testing process we test the actual system in an organization and

gather errors from the new system operates in full efficiency as stated. System

testing is the stage of implementation, which is aimed to ensuring that the system

works accurately and efficiently.

In the testing process we test the actual system in an organization and gather

errors from the new system and take initiatives to correct the same. All the front-end

and back-end connectivity are tested to be sure that the new system operates in full

efficiency as stated. System testing is the stage of implementation, which is aimed at

ensuring that the system works accurately and efficiently.

The main objective of testing is to uncover errors from the system. For the

uncovering process we have to give proper input data to the system. So we should

have more conscious to give input data. It is important to give correct inputs to

efficient testing.

Testing is done for each module. After testing all the modules, the

modules are integrated and testing of the final system is done with the test data,

specially designed to show that the system will operate successfully in all its aspects

conditions. Thus the system testing is a confirmation that all is correct and an

opportunity to show the user that the system works. Inadequate testing or non-

testing leads to errors that may appear few months later.

This will create two problems

Time delay between the cause and appearance of the problem. The effect of

the system errors on files and records within the system. The purpose of the system

51


testing is to consider all the likely variations to which it will be suggested and push

the system to its limits.

The testing process focuses on logical intervals of the software ensuring that all

the statements have been tested and on the function intervals (i.e.,) conducting tests to

uncover errors and ensure that defined inputs will produce actual results that agree with

the required results. Testing has to be done using the two common steps Unit testing and

Integration testing. In the project system testing is made as follows:

The procedure level testing is made first. By giving improper inputs, the errors

occurred are noted and eliminated. This is the final step in system life cycle. Here we

implement the tested error-free system into real-life environment and make necessary

changes, which runs in an online fashion. Here system maintenance is done every

months or year based on company policies, and is checked for errors like runtime errors,

long run errors and other maintenances like table verification and reports.

Testing is a process used to help identify the correctness, completeness and

quality of developed computer software. Testing is the process of detecting errors.

Testing performs a very critical role for quality assurance and for ensuring the

reliability.

Software testing is a critical element of software quality assurance and

represents the ultimate review of specification, design and coding, testing presents an

interesting anomaly for the software engineer. Testing helps is verifying and Validating

if the Software is working as it is intended to be working. This involves using Static and

Dynamic methodologies to Test application.

52


7.2 Purpose of Testing

The aim of the testing is often to demonstrate that a program works by showing

that it has no errors. The basic purpose of testing with the intent of showing that a

programs works, but the intent should be to show that a program doesn’t work. Testing

is the process of executing a program with the intent of finding errors.

“The purpose of testing is to discover errors”. Testing is the process of trying to

discover every conceivable fault or weakness in a word product.”

“The purpose of testing is to ensure the customers spoken and unspoken

expectations are met. The testing is very powerful. When the cost of change is high, it

stops being fun. With tests, I can change things worry free. Without tests, there’s this

pressure not to touch things. Law of Unintended Consequences: Almost all human

actions have at least one unintended consequence. Little changes can break things

across an application, and it happens all the time. As programs get large, it’s harder to

keep things in line-this whack a mole!. The reload button just doesn’t scale.

7.3 Testing Types:

7.3.1 Black box testing:

Internal system design is not considered in this type of testing. Tests are based

on requirements and functionality.

7.3.2 White box testing:

This testing is based on knowledge of the internal logic of an application’s code.

Also known as Glass box Testing. Internal software and code working should be

known for this type of testing. Tests are based on coverage of code statements,

branches, paths, conditions.

53


7.3.3 Unit testing:

Testing of individual software components or modules. Typically done by the

programmer and not by tester, as it requires detailed knowledge of the internal

program design and code. May require level Oping test driver module or test

harness.

7.3.4 Incremental integration testing:

Bottom up approach for testing i.e. continuous testing of an application as new

functionality is added; Application functionality and modules should be independent

enough to test separately done by programmers or testers.

7.3.5 Integration testing:

Testing of integrated modules to verify combined functionality after integration.

Modules are typically code modules, individual applications, client and server

applications on a network, etc. This type of testing is especially relevant to

cline/server and distributed systems.

7.3.6 Functional testing:

This type of testing ignores the internal parts and focus on the output is as per

requirement or not. Black-box type testing geared to functional requirements of an

application.

7.3.7 System testing:

Entire system is tested as per the requirements. Black box type testing that is

based on overall requirements specifications, covers all combined parts of a system.

54


7.4 Maintenance:

The key to reducing need for maintenance, while working, if possible to do

essential tasks.

1. More accurately defining user requirement during system development

2. Assembling better systems documentation.

3. Using more effective methods for designing, processing, login and

communicating information with project members

4. Making better use of existing tool and techniques.

5. Managing system engineering process effectively.

CHAPTER 8

OUTPUT SCREENS

55


CHAPTER 8

.OUTPUT SCREENS

Fig 8.1 Starting Screen

56


Fig 8.2 Browse for a folder resource

57


Fig 8.3 Ready for Encapsulation of process

58


Fig 8.4 Destination of resource

59


Fig 8.5 Path of Encapsulated file

60


Fig 8.6 Before starting the transfer of the file over virtual network

61


Fig 8.7 transfer of the file in progress over virtual network

62


Fig 8.8 Screen after completion of transfer of file over virtual network

63


Fig 8.9 Details of transfer in case of any failure of circuits

64


Fig 8.10 Details of transfer without any failure of circuits

65


Fig 8.11 Details description of transfer over an integrated Architecture

CHAPTER 9

CONCLUSION

66


CHAPTER 9

CONCLUSION

This project has shown that a time-triggered physical network is an

effective foundation for establishing multiple VNs, each tailored to a

respective application subsystem via its control paradigm (event message

versus state messages) and its temporal properties (for example,

bandwidth). The experimental assessment has yielded evidence that the

realized VNs exhibit predefined temporal properties for the messages

transmitted by a job, independent of the transmission behavior of other jobs

and other application subsystems. In particular, rigid temporal partitioning

is achievable while at the same time meeting the performance requirements

imposed by present-day automotive applications and those envisioned for

the future (for example, X-by-wire). These results are particularly

important in the context of the increasing complexity of embedded systems.

System architects become forced to follow divide-and-conquer strategies

that permit a reduction of the mental effort for developing and

understanding a large system by partitioning the system into smaller

subsystems that can be developed and analyzed in isolation.

The temporal encapsulation of the communication resources

belonging to subsystems, such as DASs or jobs in the DECOS architecture,

is a key requirement for the constructive integration of integrated computer

67


systems. By ensuring guaranteed temporal properties (for example,

bandwidth and latencies) for the messages transmitted by each job, prior

services cannot be invalidated by the behavior of newly integrated jobs at

the communication system. This quality of an architecture, which is

denoted as temporal composability, relates to the ease of building systems

out of subsystems. A system, that is, a composition of subsystems, is

considered temporally composable if the temporal correctness is not

invalidated by the integration, provided that temporal correctness has been

established at the subsystem level. VNs on top of a time-triggered network

support temporal composability by ensuring that the temporal properties at

the communication system are not invalidated upon system integration.

Furthermore, in the context of upcoming time-triggered technology in the

automotive domain, the availability of a time-triggered communication

network with high bandwidth enables the elimination of some of the

physical networks deployed in present-day cars. The communication

resources of a single timetriggered network can be shared among different

DASs. In conjunction with nodes for the execution of application software

from different DASs, this integration not only reduces the number of node

computers but also results in fewer connectors and wires. For future work,

additional experiments are suggested as part of the development path

68


toward the exploitation of VNs in ultradependable systems such as a drive-

by-wire car.

The experiments presented in this paper have focused on a single

probe job within a selected VN. Interesting scenarios for future

experimental evaluations include test cases with multiple probe jobs, which

can exhibit simultaneous timing failures and are located in different VNs.

Thereby, additional experiments can further increase the confidence in the

presented hypotheses with respect to fault isolation and performance

CHAPTER 10

SCOPE FOR FUTURE ENHANCEMENTS

69


CHAPTER 10

SCOPE FOR FUTURE ENHANCEMENTS

This project presents the mechanisms for the temporal partitioning

of communication resources in the Dependable Embedded Components and

Systems (DECOS) integrated architecture. Furthermore, experimental

evidence is provided in order to demonstrate that the messages sent by one

software component do not affect the temporal properties of messages

exchanged by other software components.

CHAPTER 11

BIBLIOGRAPHY

70


CHAPTER 11

BIBLIOGRAPHY

11.1 References

[1] Aeronautical Radio, Inc., ARINC Specification 651: Design Guide for Integrated

Modular Avionics, Nov. 1991.

[2] H. Heinecke et al., “AUTomotive Open System ARchitecture—An Industry-Wide

Initiative to Manage the Complexity of Emerging Automotive E/E-Architectures,”

Proc. Convergence Int’l Congress and Exposition on Transportation Electronics,

Oct. 2004.

[3] R. Obermaisser and P. Peti, “A Fault Hypothesis for Integrated Architectures,” Proc.

Fourth Int’l Workshop Intelligent Solutions in Embedded Systems (WISES ’06), June

2006.

[4] P. Peti, R. Obermaisser, F. Tagliabo, A. Marino, and S. Cerchio, “An Integrated

Architecture for Future Car Generations,” Proc. Eighth IEEE Int’l Symp. Object-

Oriented Real-Time Distributed Computing (ISORC ’05), May 2005.

[5] J. Swingler and J.W. McBride, “The Degradation of Road Tested Automotive

Connectors,” Proc. 45th IEEE Holm Conf. Electrical Contacts, pp. 146-152, Oct.

1999.

[6] Embedded Systems Design, B. Bouyssounouse and J. Sifakis, eds.,

Springer, 2005.

[7] F.P. Brooks, “No Silver Bullet: Essence and Accidents of Software

Engineering,” Computer, Apr. 1987.

71


[8] CAN Specification, Version 2.0. Robert Bosch Gmbh, 1991.

[9] R. Obermaisser and B. Huber, “Model-Based Design of the Communication System

in an Integrated Architecture,” Proc. 18th IASTED Int’l Conf. Parallel and

Distributed Computing and Systems (PDCS ’06), pp. 96-107, 2006.

[10] H. Kopetz, Real-Time Systems, Design Principles for Distributed Embedded

Applications. Kluwer Academic Publishers, 1997.

[11] J. Rushby, Partitioning for Avionics Architectures: Requirements, Mechanisms,

And Assurance, NASA Contractor Report CR-1999- 209347, NASA Langley

Research Center, Also to be issued by the FAA, June 1999.

[12] J. Sifakis, “A Framework for Component-Based Construction,” Proc. Third IEEE

Int’l Conf. Software Eng. and Formal Methods (SEFM ’05), pp. 293-300,

Sept. 2005.

[13] H. Kopetz and R. Obermaisser, “Temporal Composability,” Computing & Control

Eng. J., vol. 13, pp. 156-162, 2002.

[14] R. Obermaisser, P. Peti, and H. Kopetz, “Virtual Networks in an Integrated Time-

Triggered Architecture,” Proc. 10th IEEE Int’l Workshop Object-Oriented Real-

Time Dependable Systems (WORDS ’05), 2005.

[15] B. Huber, P. Peti, R. Obermaisser, and C. El Salloum, “Using RTAI/LXRT for

Partitioning in a Prototype Implementation of the DECOS Architecture,” Proc.

Third Int’l Workshop Intelligent Solutions in Embedded Systems (WISES ’05),

May 2005.

[16] G. Bauer, H. Kopetz, and W. Steiner, “The Central Guardian Approach to Enforce

Fault Isolation in a Time-Triggered System,” Proc. Sixth Int’l Symp. Autonomous

Decentralized Systems (ISADS 03), pp. 37-44, 2003.

72


[17] Node-Local Bus Guardian Specification Version 2.0.9, FlexRay Consortium,

BMW AG, DaimlerChrysler AG, General Motors Corp., Freescale GmbH, Philips

GmbH, Robert Bosch GmbH, and Volkswagen AG, Dec. 2005.

[18] D. Kim, Y.-H. Lee, and M. Younis, “SPIRIT— Kernel for Strongly

Partitioned Real-Time Systems,” Proc. Seventh Int’l Conf. Real-Time

Computing Systems and Applications (RTCSA ’00), 2000.

[19] J. Penix et al., “Verification of Time Partitioning in the DEOS Scheduler

Kernel,” Proc. 22nd Int’l Conf. Software Eng. (ICSE ’00), pp. 488-497,

2000

20] K. Hoyme and K. Driscoll, “SAFEbus,” IEEE Aerospace and Electronic Systems

Magazine, vol. 8, pp. 34-39, Mar. 1993.

[21] E. Totel, J.P. Blanquart, Y. Deswarte, and D. Powell, “Supporting Multiple Levels

of Criticality,” Proc. 28th Ann. Int’l Symp. Fault- Tolerant Computing (FTCS

’98), p. 70, 1998.

[22] R. Obermaisser and P. Peti, “Specification and Execution of Gateways in

Integrated Architectures,” Proc. 10th IEEE Int’l Conf. Emerging

Technologies and Factory Automation (ETFA ’05), Sept. 2005.

[23] Software Fundamentals: Collected Papers by David L. Parnas.

Addison-Wesley, Apr. 2001.

[24] H.D. Heitzer, “Development of a Fault-Tolerant Steer-by-Wire Steering System,”

Auto Technology, vol. 4, pp. 56-60, Apr. 2003.

73


[25] Int’l Electrotechnical Commission, IEC 61508-7: Functional Safety of

Electrical/Electronic/Programmable Electronic Safety-Related Systems—Part 7:

Overview of Techniques and Measures, 1999. in Embedded Systems (WISES

06), June 2006.

11.2 Websites:

• www.support.mircosoft.com

• www.developer.com

• www.15seconds.com

• www.ieee.org

• www.decos.in

• www.decossoftdev.com

http://www.support.mircosoft.com

http://www.developer.com

http://www.15seconds.com

http://www.ieee.org

http://www.decos.in

http://www.decossoftdev.com

Date post:	29-Jul-2015
Category:	Documents
Upload:	vijendhar-reddy
View:	46 times
Download:	0 times

Temporal Partitioning of Communication Resources in an Integrated Architecture Documentation

Documents