Assignment 3

MSRSAS - Postgraduate Engineering and Management Programme - PEMP

Embedded RTOS i

EMBEDDED PROCESSORS AND MICRO CONTROLLERS

Module Code ESD 531

Module Name Embedded RTOS

Course M.Sc in Real-Time Embedded Systems

Department Computer Engineering

Name of the Student Bhargav Shah

Reg. No CHB0911001

Batch Full-Time 2011

Module Leader Deepak V.

PO

STG

RA

DU

ATE

EN

GIN

EER

ING

AN

D M

AN

AG

EM

EN

T P

RO

GR

AM

ME –

(P

EM

P)

M.S.Ramaiah School of Advanced Studies

Postgraduate Engineering and Management Programmes(PEMP) #470-P Peenya Industrial Area, 4th Phase, Peenya, Bengaluru-560 058

Tel; 080 4906 5555, website: www.msrsas.org

ii

Declaration Sheet Student Name Bhargav Shah

Reg. No CHB0911001

Course Real Time Embedded System Batch Full-Time 2011

Batch FT-11

Module Code ESD531

Module Title Embedded RTOS

Module Date to

Module Leader Deepak V.

Extension requests: Extensions can only be granted by the Head of the Department in consultation with the module leader. Extensions granted by any other person will not be accepted and hence the assignment will incur a penalty. Extensions MUST be requested by using the ‘Extension Request Form’, which is available with the ARO. A copy of the extension approval must be attached to the assignment submitted.

Penalty for late submission Unless you have submitted proof of mitigating circumstances or have been granted an extension, the penalties for a late submission of an assignment shall be as follows:

• Up to one week late: Penalty of 5 marks • One-Two weeks late: Penalty of 10 marks • More than Two weeks late: Fail - 0% recorded (F)

All late assignments: must be submitted to Academic Records Office (ARO). It is your responsibility to ensure that the receipt of a late assignment is recorded in the ARO. If an extension was agreed, the authorization should be submitted to ARO during the submission of assignment. To ensure assignment reports are written concisely, the length should be restricted to a limit indicated in the assignment problem statement. Assignment reports greater than this length may incur a penalty of one grade (5 marks). Each delegate is required to retain a copy of the assignment report.

Declaration The assignment submitted herewith is a result of my own investigations and that I have conformed to the guidelines against plagiarism as laid out in the PEMP Student Handbook. All sections of the text and results, which have been obtained from other sources, are fully referenced. I understand that cheating and plagiarism constitute a breach of University regulations and will be dealt with accordingly.

Signature of the student Bhargav Shah Date

Submission date stamp (by ARO)

Signature of the Module Leader and date Signature of Head of the Department and date


Embedded RTOS iii

Abstract ____________________________________________________________________________ A real-time operating system (RTOS) is an operating system (OS) supposed to serve

real-time application requests. RTOSes are designed to control an embedded system, and to

deliver the real-time responsiveness and determinism required by the controlled device.

RTOS is a multitasking operating system intended for real-time applications and

designed to be very compact and efficient, forsaking many functions that non-embedded

computer operating systems provide. In part A of assignment differences between linux and

RTOS, and different approaches to made linux as an RTOS is explained and specially the use

of Linux kernel workqueues to make it an RTOS.

RTOS provides facilities which, if used properly, guarantee deadlines can be met

generally (soft real-time) or deterministically (hard real-time). It is valued more for how

quickly or predictably it can respond to a particular event than for the amount of work it can

perform over a given period of time.

Distributed Common Ground System (DCGS), weapon system is the service's premier

globally networked intelligence, surveillance and reconnaissance weapon system. In part B of

the assignment literature survey and functionalities of the DCGS consisting of the selected

entities with the required communication system is done.

Design and development of DCGS which can help to take important decision in the war

condition is done with VxWorks Operating System. The DCGS system designed with priorities

and synchronized according to the course of event occurred. The design is made The SSD

system is designed and implemented in C code in tornado IDE in VxWorks RTOS.

iv

Contents ____________________________________________________________________________ Declaration Sheet ......................................................................................................................... ii

Abstract ....................................................................................................................................... iii

Contents ........................................................................................................................................iv

List of Tables ................................................................................................................................. v

List of Figures ..............................................................................................................................vi

List of Symbols .......................................................................................................................... vii

PART-A ......................................................................................................................................... 8

CHAPTER 1: Suitability of Linux work queues as RTOS ........................................................... 8 1.1 Introduction to Linux File System ....................................................................................... 8 1.2 Correctness faced by the developers for the performance of the system [1] ...................... 8

1.3 Differences .......................................................................................................................... 8

1.3.1 OS and RTOS Scheduling[2] ....................................................................................... 8 1.3.2 RTOS and Linux system [3] ......................................................................................... 9

1.4 Approaches for making Linux as an RTOS[4] .................................................................... 9 1.4.1 Pre-empt kernel approach ........................................................................................... 10 1.4.2 Real-time executive approach .................................................................................... 10

1.5 Use of Linux kernel work queues for making it an RTOS[5] ........................................... 10

1.6 Conclusion ......................................................................................................................... 11

PART-B ....................................................................................................................................... 12

CHAPTER 2 Design of DCGS ................................................................................................... 12 2.1 Introduction ....................................................................................................................... 12

2.2 literature survey ................................................................................................................. 12

2.2.1 Sensors system[7] ....................................................................................................... 14 2.3 Identification of functionalities ......................................................................................... 15 2.4 Requirement specifications for the DCGS ........................................................................ 17 2.5 Different tasks associated with DCGS .............................................................................. 18 2.8 Conclusion ......................................................................................................................... 20

PART-C ....................................................................................................................................... 21

CHAPTER 3: Implementation of DCGS .................................................................................... 21 3.1 Introduction ....................................................................................................................... 21

3.2 Program flow graph ........................................................................................................... 21

3.3 Implementation of the DCGS ............................................................................................ 23 3.4 Test cases ........................................................................................................................... 27

3.5 Disscution of obtained result ............................................................................................. 28 3.6 Conclusion ......................................................................................................................... 29

CHAPTER 4 ................................................................................................................................ 30

4.1 Module Learning Outcomes .............................................................................................. 30 4.2 summary ............................................................................................................................ 30

References ................................................................................................................................... 31

Appendix ..................................................................................................................................... 32


Embedded RTOS v

List of Tables

Table 1. 1 RTOS vs Linux ............................................................................................................. 9

Table 2. 1 Hard ware requirements for DCGS ............................................................................ 17 Table 2. 2 Required processes for DCGS .................................................................................... 18 Table 3. 1 Test cases .................................................................................................................... 27

vi

List of Figures Figure 2. 1 Conceptual diagram of DCGS (generalized)[6] ....................................................... 13 Figure 2. 2 Conceptual diagram of DCGS(designed) ................................................................. 16 Figure 3. 1 Software flow diagram for solders node ................................................................... 21 Figure 3. 2 Software flow diagram for commander node ........................................................... 22 Figure 3. 3 Software flow diagram for air force node ................................................................. 22 Figure 3. 4 Data structures for DCGS ......................................................................................... 23 Figure 3. 5 First task on target board ........................................................................................... 24

Figure 3. 6 First true functional task ........................................................................................... 24

Figure 3. 7 fn_task1 ..................................................................................................................... 25

Figure 3. 8 Service from .............................................................................................................. 25

Figure 3. 9 Temperature .............................................................................................................. 26

Figure 3. 10 Air force .................................................................................................................. 26

Figure 3. 11 Command ................................................................................................................ 27

Figure 3. 12 Asking for authentication ........................................................................................ 28 Figure 3. 13 Synchronizing location of soldier ........................................................................... 28 Figure 3. 14 Asking for service ................................................................................................... 28

Figure 3. 15 Showing request number ......................................................................................... 28 Figure 3. 16 Air force task ........................................................................................................... 29

Figure 3. 17 commanded node .................................................................................................... 29


Embedded RTOS vii

List of Symbols RTOS Real Time Operating System OS Operating System RAM Random Access Memory FIFO First in, First out SJF Shortest Job First EDF Earliest Dead line First DCGS Distributed Common Ground System ISR Intelligence, Surveillance, and Reconnaissance BCT Brigade Combat Team IWF Intelligence War fighting Function

GRCS Guardrail Common Sensor COMINT Communication Intelligence ELINT Electronic Intelligence SBCT Stryker Brigade Combat Team ACR Armored Cavalry Regiment SIGINT Signals Intelligence EW Electronic Warefare BFSB Battlefield Surveillance Brigade NCES Network-Centric Enterprise Services DIB DCGS Integration Backbone IPC Inter Process Communication RPC Remote Procedural Call

PART-A CHAPTER 1: Suitability of Linux work queues as RTOS 1.1 Introduction to Linux File System

A real-time operating system (RTOS) is an operating system (OS) supposed to serve real-

time application requests. RTOSes are designed to control an embedded system, and to deliver the

real-time responsiveness and determinism required by the controlled device. Linux is an open

source operating system which is not a real time operating system, In this part of assignment a

debate on Suitability of Linux for RTOS type applications by using kernel work queue’s is done.

1.2 Correctness faced by the developers for the performance of the system [1]

A real-time system should be able to perform computations deterministically - an important

concept in real-time systems. A system is said to be deterministic if it's possible to predict the

timings of its computation precisely, and computations are logically correct. An example for real

time system is an automobile airbag system, one of the most critical systems in a modern car. An

airbag should be deployed within a particular time interval (for example, within 1 second1) after the

sensors in the car detect a collision. Latency: In computing, latency is "the time that elapses

between a stimulus and the response to it" is the important parameter required to quantify real-time

systems.

Real-time systems can be categorized in two major groups, “hard” real-time systems and

“soft” real-time systems. Hard real-time:A system that can meet the desired deadlines at all times

(100 percent), even under a worst-case system load. In hard real-time systems, missing a deadline,

even a single time, can have fatal consequences. Some examples are airbag systems Soft real-time:

A system that can meet the desired deadlines on average. Some examples are online audio/video

broadcasts.

A real-time system does not mean faster performance. In fact, a real-time system may or

may not lead to deterioration in performance. Application developers who think they need a real-

time system for better performance of their application can actually get the performance they

require by simply upgrading their hardware with faster processors, RAM, high speed buses, etc.

1.3 Differences

1.3.1 OS and RTOS Scheduling [2]

Scheduling is the method by which threads, processes or data flows are given access to

system resources such as processor time, communications bandwidth. Goals for Scheduling in OS

are Utilization/Efficiency: keep the CPU busy 100% of the time with useful work Throughput:

maximize the number of jobs processed per hour. Turnaround time: from the time of submission to


Embedded RTOS 9

the time of completion, minimize the time batch users must wait for output waiting time: Sum of

times spent in ready queue - Minimize this. Commonly used OS scheduler disciplines are Pre-

emptive Scheduling, FIFO,SJF and round robin scheduling. OS is time driven scheduling.

RTOS is an operating system that guarantees a certain capability within a specified time

constraint, hence an RTOS uses advanced scheduling algorithms. Commonly used RTOS

scheduling algorithms are Long-term scheduling, Medium-term scheduling, Short-term scheduling

and commonly used RTOS scheduler disciplines are Pre-emptive Scheduling and Earliest Deadline

First (EDF). In RTOS scheduling is triggered by events.

1.3.2 RTOS and Linux system [3]

Table 1. 1 RTOS vs Linux

RTOS Linux

RTOS is a specially designed TYPE of

Operating System

Linux is the name given to a specific operating

system

Best suited for embedded systems Linux isn’t always the best OS to use in

embedded systems

RTOS is faster Linux is that it is slower than RTOS solutions on

the same hardware

RTOS world where developers might

specialise in Board Support Packages (BSPs),

device drivers or applications

Linux has the same skill separation

RTOS application developers work best with

userspace applications

RTOS BSP and device driver developers are

well suited to working in the Linux kernel

RTOS developers are used to working on

Windows development hosts

Embedded Linux tools are Open Source and run

on UNIX/Linux development hosts

Its not scalable It has scalability property

It is time deterministic It may or may not be time deterministic

1.4 Approaches for making Linux as an RTOS [4]

There have been many attempts over the past several years to improve the real-time

performance of Linux so that the benefits, such as open source software availability, can be used for

real-time applications. There are two basic approaches to this: a preempt kernel and the real-time

core.


Embedded RTOS 10

1.4.1 Pre-empt kernel approach

In the preempt kernel approach, the Linux kernel is modified to reduce the amount of time

the kernel spends in nonpreemptible sections of code. Because this approach requires the

modification of the Linux kernel (via a patch) to achieve minimized nonpreemptive paths, it is an

ongoing effort and potentially requires time-consuming revalidation whenever a patch is made.

Many open source projects have been formed to create a low-latency kernel using a variety of

preemption approaches. The most significant project was started by Ingo Molnar, and is being

included in the standard Linux kernel over time. But there are certainly benefits to this approach.

The most notable is the PREEMPT_RT project that is widely considered to be "mainstream Linux"

and the quality and maturity is improving over time. Many code paths in the kernel (such as device

drivers) are being modified in the mainstream code to support preemption.

1.4.2 Real-time executive approach

With the real-time executive approach, a small real-time kernel coexists with the Linux

kernel. This real-time core uses a simple real-time executive that runs the non-real-time Linux

kernel as its lowest priority task and routes interrupts to the Linux kernel through a virtual interrupt

layer. All interrupts are initially handled by the core and are passed to standard Linux only when

there are no real-time tasks to run. Real-time applications are loaded in kernel space and receive

interrupts immediately, giving near hardware speeds for interrupt processing.

On the other hand, a real-time core is not a part of the standard Linux operating system and

is not licensed by the General Public License. It is immediately capable of providing a guaranteed

hard real-time environment for appropriately written applications within a Linux environment.

1.5 Use of Linux kernel work queues for making it an RTOS [5]

Interrupt latency is a key factor in the performance of a system. Work queues are one of

several tools available to the driver writer to avoid doing time-consuming work when interrupts are

disabled.

Linux included, device drivers typically divide the work of processing interrupts into two

parts or halves. The first part, the top half, is the familiar interrupt handler, which the kernel

invokes in response to an interrupt signal from the hardware device.

To facilitate small and fast interrupt handlers, the second part or bottom half of interrupt

handling is used to defer as much of the work as possible away from the top half and until a later

time. The bottom half runs with all interrupts enabled hence, the real work takes place in the bottom

half. Linux offers many mechanisms for implementing bottom halves. Currently, the 2.6 kernel

provides softirqs, tasklets and work queues as available types of bottom halves.


Embedded RTOS 11

Work queues are interesting for two main reasons. First, they are the simplest to use of all

the bottom-half mechanisms. Second, they are the only bottom-half mechanism that runs in process

context; thus, work queues often are the only option device driver writers have when their bottom

half must sleep. In addition, the work queue mechanism is brand new, and new is cool.

The Work Queue Interface is given in the appendix A

1.6 Conclusion

A debate on determining whether to use an RTOS or Linux to meet real-time requirements

is done. Moving to Linux has some key advantages in cost and scale and can provide significant

advantages in many situations. In this part difference between Linux and RTOS, and different

approaches to made Linux as an RTOS is explained.


Embedded RTOS 12

PART-B CHAPTER 2 Design of DCGS 2.1 Introduction

Distributed Common Ground System (DCGS) is considered the backbone of the network-

centric battlefield, providing access to time-sensitive, actionable intelligence, surveillance, and

reconnaissance (ISR) data. In an environment in which information can be the difference between

life and death, cloud computing and the rapid access to critical data and tools it offers might never

have been more important. The DCGS program establishes the core framework for a worldwide

distributed, network centric, system-of-systems architecture that conducts collaborative intelligence

operations and production. The first tactical cloud operating in Afghanistan, the Army’s Distributed

Common Ground System (DCGS-A) pools intelligence collected from the beginning of the war in

Iraq , aggregated from various databases for wider, faster and easier access and decision-making.

2.2 literature survey

Defence Department's effort to establish an Internet like, global intelligence sharing network

across the military services and defence intelligence agencies is the Distributed Common Ground

System (DCGS). DCGS continues to progress rapidly and has gained greater support across the

department. DCGS is being used by different wings of army with appropriate extensions of A army,

N navy etc.

As the Intelligence Surveillance and Reconnaissance (ISR) component of Battle Command,

DCGS provides the Commander, faster and more complete situational awareness enabling better

understanding of the operational environment. This increased situational awareness allows the

Commander to fight in ways that exceed the historical limitations through the following three

interrelated main ideas:

1. Increased situational awareness reduces risk for the Commander when executing missions.

2. A flattened network enables Commanders greater access to information historically only

available to Corps and above echelons.

3. Providing Commanders with unprecedented access to the Intelligence Enterprise affords the

greatest impact at the lowest level.

The capabilities of DCGS align the centre of gravity shift from the division to the brigade

combat team (BCT) with increased accessibility to critical information to fulfil the mission

requirements. The accessibility to previously restricted information provides the Commander at the

lowest level the capability to leverage the vast intelligence enterprise to better assess the current

operational environment and to receive actionable intelligence in a timely manner. Previously,


Embedded RTOS 13

collection, processing, and analysis from a stove-piped process restricted critical information from

most Commanders, particularly at brigade and below. Consequently, their decisions, often made

without the critical information, came with high risk. DCGS reduces that high risk and enables the

Commanders to better drive combat operations.

The system comprises information gleaned from various types of reports including patrol

and incident debriefings, improvised explosive device operations, civil military, and handheld

reports from the field that have been filed in databases such as the Combined Information Data

Network Exchange and Tactical Ground Reporting system.

In conjunction with the three main ideas, DCGS, through system configuration and

application, enables the Commander to meet seven of his Army Tasks. A primary function is the

intelligence war fighting function (IWF). The IWF is the flexible and adjustable activity to generate

knowledge of and products portraying the enemy and the environmental features required to plan,

prepare, execute, and assess operations. The personnel and organizations within the IWF conduct

four primary tasks that facilitate the Commander’s visualization and understanding of the threat and

the environment. These tasks are interactive and often take place simultaneously throughout the

intelligence process. DCGS-A supports the following Army tasks and mission areas

a.) Support to situational understanding (and all sub-tasks).

b.) Support to strategic responsiveness (and all sub-tasks).

c.) Conduct Intelligence, Surveillance and Reconnaissance (and all sub-tasks).

d.) Provide Intelligence Support to Effects (and all sub-tasks).

Figure2.1 graphically illustrates the process in with DCGS-A facilitates.

Figure 2. 1 Conceptual diagram of DCGS (generalized)[6]


Embedded RTOS 14

The DCGS-A fielding of various configurations extends across BCT, fires, maneuver

enhancement, Battlefield Surveillance Brigade (BFSB), aviation and sustainment organizations.

The fixed, mobile, and embedded configurations allow Commanders to have a better awareness and

enable understanding of the operational environments.

FIXED: The fixed configuration leverages the power and stability of sanctuary for the most

complex processing and analytic tasks. Additionally, it provides the greatest historical data

repository. The fixed DCGS-A configurations facilitate reach and split-based operations by

providing the “heavy lifting” intelligence analysis and strategic planning from stationary locations.

MOBILE: The mobile configuration of DCGS-A provides a tactical, deployable capability

to deliver responsive, forward support to Commanders from BN through operational headquarters.

Analytical tools, sensor inject, data storage, and integration with other BCS are the highlights of the

Mobile configuration. The configuration is the “access” point or intelligence service provider for

ISR data and information in theater. Mobile DCGS-A provides a wide range of ISR capabilities

including direct downlink of select DCGS baseline sensors, robust tasking, posting, processing,

using (TPPU) tools, and advance ISR analysis capabilities directly support tactical and force

protection operations. DCGS-A Mobile has the capability of receiving “plug” augmentation for

increased capability while remaining connected to various networks through provided

communications.

EMBEDDED: The embedded DCGS-A software on BCS enables the connection of the

intelligence enterprise with the battle command network. Embedded software provides battalion

and company intelligence efforts unprecedented access to data never before available. Surveillance

and reconnaissance collected from non military intelligence sources was not available to the

intelligence enterprise. The embedded software provides the shared access to both battle command

and the intelligence enterprise. This ability enables a more complete picture of the operational

environment to the commander.

2.2.1 Sensors system [7]

The ability to integrate data from sensors with different characteristics offers the potential

of significant performance improvements over what could be achieved from each sensor separately.

Here list of sensors associated with the exacting DCGS system.

The Guardrail Common Sensor (GRCS) system is the Army’s corps-level airborne signal

intelligence (SIGINT) collection, location and dissemination system providing tactical commanders

near-real-time targeting information. The GRCS systems consist of seven to 12 aircraft, depending

on the system, that normally fly operational missions in sets of two or three aircraft providing near-


Embedded RTOS 15

realtime SIGINT and targeting to tactical commanders with emphasis on deep battle and follow-on

forces attack support. Key features include integrated communications intelligence (COMINT) and

electronic intelligence (ELINT) reporting, enhanced signal classification and recognition, near-real-

time direction finding, precision emitter location and an advanced integrated cockpit. Primary

capabilities include integrated signals exploitation, enhanced signal classification and recognition,

fast direction finding, precision emitter location and advanced integrated avionics. Interoperable

data links provide microwave connectivity between the aircraft and the integrated processing

facility (IPF).

The Prophet system (three-block acquisition approach: Blocks I, II and III) is the

division, brigade combat team (BCT), Stryker brigade combat team (SBCT) and armored cavalry

regiment (ACR) principal ground tactical signals intelligence (SIGINT) and electronic warfare

(EW) system that has been designed to support the Army vision, transformation and unit of action

battlespace. Prophet detects, identifies and locates enemy electronic emitters and provides enhanced

situational awareness and actionable 24-hour information for the warfighter throughout the

division, ACR and BCT areas of operations. Prophet is made up of a vehicular SIGINT receiver

mounted on a Humvee on the battlefield, plus a dismounted manpack SIGINT version for airborne

insertion or early entry into the battlespace to support rapid reaction contingency and antiterrorist

operations.

Army night-vision and sensor programs and activities include day/night, allweather

mobility and engagement sensors; all-weather imagery; passive and radar target acquisition sensors;

artillery and mortar- locating radars; and advanced sensors for the Army’s Future Force. These

systems provide critical, on-the-ground, direct support to base station. One key area is thermal

sensors, which dramatically increase the lethality and survivability of Army soldiers. These sensors

read the heat signature from distant objects, such as personnel or vehicles, day or night, penetrating

smoke, fog and obscurants.

2.3 Identification of functionalities

DCGS is the ISR component of the modular and future force BCS and the Army’s primary

system for ISR tasking of sensors, processing of data, exploitation of data, and dissemination of

intelligence information. DCGS provides critical battle information about the threat, weather, and

terrain at all echelons. DCGS will provide the capabilities necessary for Commanders to access

information, task organic sensors, and synchronize non-organic sensor assets with their organic

assets. These services will be shared by Commanders across an enterprise (provided by the


Embedded RTOS 16

Network-Centric Enterprise Services (NCES)) using the DCGS Integration Backbone (DIB) to

enhance interoperability of ISR information

DCGS will provide continuous acquisition and synthesis of data and information from Joint,

Interagency, Intergovernmental, and Multi-national sources that will permit Commanders to have

an updated and accurate picture of the operational environment. This will allow Commanders to

maximize their combat power and enhance their ability to operate in an unpredictable and changing

environment throughout the operational spectrum. Here communication between soldier,

commander (head quarters) and air force plane is highlighted.

soilder's node Airforce nodeArmy

commander's

office node

Cloud

Figure 2. 2 Conceptual diagram of DCGS(designed)

The whole system is divided in to three nodes. One node is operated by the soldier from

Warfield. After pressing start button on the soldier’s node, it prompts to authenticate by thumb

impression. Thumb impression will authenticate the person and associated data gives a signal to

start. In the battle field to know the location of the each soldier is essential. To fulfil this

requirements one GPS module is assigned in the device. Basically this device can be a device like a

tablet which includes the GPS, 3G, Touch screen, temperature sensor. For reading the temperature

of the battlefield a temperature sensor is embedded with device. To be updated with the live

situation one camera is also embedded in device which can pick snaps and send this information to

the main unit. After getting all the information from the various sensors, device uploads the data to

the cloud by using the GSM modem.

The other node is at the head quarter which is capable of retrieving all the data. At the

receiver side all real time data will be retrieved by the accessing the cloud. To access this cloud

authentication is required.

In some scenarios, army which is on ground need the services from the air force. To handle

this situation one facility is added in the designed system is the “service from”. By using this

facility army can check the current location of air force & generate a service request for air force.


Embedded RTOS 17

This reinforce task asks the location of the service and the time of service from the army. Figure 2.2

shows the functional block diagram of the designed system.

2.4 Requirement specifications for the DCGS

To achieve full-fledged functionality of the DCGS requirements of the system are mention

here. At the initial stage for storing and retrieving the data on the cloud fast wireless network

connectivity is essential. The speed of this wireless is network is enough capable to handle live

videos. As the best option of this requirement any of 3G network is recommended, which has good

connectivity under the area of surveillance. Table 2.1 shows the Hardware specification and

arrangement of the hardware for the DCGS.

Table 2. 1 Hard ware requirements for DCGS

Requirement No. Sensor Detail Place for Sensor Propose

Requirements for soldier node

HWR_1 GPS module Should be embedded

in tablet

Basic idea behind this

sensor is to send

location of the soldier

to the cloud.

HWR_2 Temperature sensor Should embedded in

tablet

This sensor is used to

sense the temperature

of the present location

HWR_3 Camera Should embedded in

tablet

This is user to transmit

live Video/images to

the cloud

HDR_4 One tablet Should be with

soldiers on the battle

field

This Plays major roll

in communicating with

the commander and

soldier. This is

programmed like it

will retrieve all the

data and send it on the

cloud

HRD_5 Thumb impression

detector

Should embedded in

tablet

This is responsible to

authentication of the

solider


Embedded RTOS 18

Requirements for commander’s node

HRD_6 Computer with internet

connection

Any ware To retrieve all the data

Requirements for Air force node

HRD_7 One tablet Any ware This device is used to

receive the service

request from cloud

which is sent by the

army

2.5 Different tasks associated with DCGS

Inter process communication (IPC) is a set of programming interfaces that allow to

coordinate activities among different program/processes that can run concurrently. This allows a

program/process to talk with each other by using some set of rules. Here nine process has been

identified which are running on the DCGS are described by the table 2.3.There are couple of ways

to achieve IPC/RPC. Here, internet cloud based shared data structure has been used to pass data

from one node to another.

Table 2. 2 Required processes for DCGS

Process ID Process node Process

iteration time

Process Ignited Process description

Processes at the solders’ node

PID_1 soldiers node Single time

when time of

start-up.

Auto This process is providing

security to the device by

checking for thumb

impression of the user

PID_2 soldier node Infinite time

until life spam

of device

Auto At every time this process

reads location data which

is sent by the GPS receiver

and update it on cloud

PID_3 Soldier’s node Infinite time

until life spam

of device

Auto This process is responsible

for reading and updating

the current temperature of


Embedded RTOS 19

battle field on the cloud


until life spam

of device

Auto This process is responsible

for sending photos/video to

cloud.


until life spam

of device

Initiated by user

when service is

needed from

other entity

This task asks about the

service is required for other

entity. if it is required it

make a service request and

returns the request number

to army


until life spam

of device

Auto This task will

show/retrieve location data

of air force and show to

army.

Processes at the commanders’ node

PID_7 Commander’s

node

Infinite time Initiated by the

commander on

the requirement

of the data

This process reads all the

data from the cloud and

displays it.

Processes at the Air force node

PID_8 Air force node Infinite time Auto This is basically

background process. This

process checks the for the

service request for Air

force. If any of service

requests is available then it

will inform by giving

popup.

PID_9 Air force node Infinite time Auto The main purpose of this

task is to take location of

the air force/aircraft and

send it on a cloud.


Embedded RTOS 20

Figure 2.3 represent whole IPC/RPC scenario (data flow diagram) with appropriate data

which is being communicate. In figure, inner arrows shows that process is sending the data and the

outer arrow shows that process is the receiving the data. Labels associated with the arrows shows

the type of the data exchange.

Figure2. 3 Data flow diagram

A: Location Data structure of solider troops

B: Location Data structure of air force

C: Tempeature data

D, E: All Data structure

F: Photos/video information

G, H: Request data structure

2.8 Conclusion

Detailed survey on distributed common ground system is done and a system with

Commander, solider and air force/plane is designed as a part of this chapter. Functionalities,

requirement specifications and different task for implementing DCGS with their full-fledged

operations are documented.

Note: This is not a real DCGS system. To Develop DCGS, it is essential to use remote procedure

call which is out of scope of this document. In place of the RPC here, common data structure has

been used to analyze the functionality. By the other side, data which should come from sensor is

entered by the user.


Embedded RTOS 21

PART-C CHAPTER 3: Implementation of DCGS 3.1 Introduction

Device which is working at the battle field should be well scheduled. In above designed if

the pulse is not detected for a minute that can stop device. To implement above designed real time

functionality, operating system is essential. In view of this, Vxworks is good option for time critical

tasks between commander and soldier.

3.2 Program flow graph

A figure 3.1 shows the programme flow graph for soldier node. At the solders node, after

starting the device is will ask for the authentication by using the thumb impression. Is the

impression is matched with the desired information then only this device will be activate otherwise

it will again go to read the thumb.

Figure 3. 1 Software flow diagram for solders node


Embedded RTOS 22

After successful completion of the thumb identification phase, device reads the current

location and current temperature and image/video update; send this data to the cloud. After

successful completion of these tasks it displays the current location of the air force to the screen.

After this process firm ware asks the user/army man if service from the air force is required or not.

If the service is required then it will asks the location of the service and time from the army person.

It generates the service request on the cloud.

Figure 3. 2 Software flow diagram for commander node

Figure 3. 3 Software flow diagram for air force node


Embedded RTOS 23

Figure 3.2 shows the program flow graph for the commander node. At the initial stage after

starting of the device/node, user/commander has to give the thumb impression for security of the

data and device. At the successful identification of the device will start reading the data from the

cloud and display it into appropriate format. This is shown in figure.

Figure 3.3 shows the program flow graph for the air force node. At the initial stage after

starting of the device/node, air force fallow has to give the thumb impression for security of the

data and device. After this stage it will search for the pending service request. If new service

request is available then it pop up the user with appropriate data (location and time to be served).In

the case of the no request it sync the location of the particular device (aero plane) to the cloud.

3.3 Implementation of the DCGS

Here, programming language c is chosen for programming of the above designed system.

Data structure associated with the cloud is used by the global deceleration. Image 3.3 shows the

peace of code (Data structure) which is defined globally. There are three structures defined here.

Data structure named database is used to keep record of the location of the army/solider and air

force and the temperature of the battle field. Structure instance named data is created for this

structure.

Figure 3. 4 Data structures for DCGS

The other data structure named request is used to keep track of the data related to the

serving request. It will store the request number, location to be served and time (delay from current

time).sev is structure instance created to access this structure.

Thumb sensor sends a unique 10 bit string for each thumb impression. Structure password is

used to store this thumb impression string for user. At the starting of the device each user will enter


Embedded RTOS 24

thumb to protect the device from the misuse. This thumb pattern is stored in the 1st instance of the

structure named pas[1]. This is the procedure for only 1st time log in to device. Structure instance

pas[2] is used to store the user entered thumb impression by the time of login. By comparing the

two instances authentication of the device is achieved.

Figure 3. 5 First task on target board

Figure 3.5 shows the first task running of the target board. First task asks about to decide

administer of the device by thumb impression. This stored the all thumb impression to 1st instance

of the structure password. After accessing the thumb impression it asks user to confirm administer

for device and starts/spawns first true functional task of DCGS with the priority of the 100.At this

stage only one task is available for processor so priority doesn’t affect at this stage.

Figure 3. 6 First true functional task

The first true functional task is responsible for spawning all the tasks of the DCGS. By the

starting of the task service request number is assigned to zero because by the starting no service

request can possible. All the tasks with the different priority spawn from this task. This

functionality runs for infinite time by using the go to statement.

The first task, named tstart is created with the priority of the 1.This is the highest priority

task which stores the location of the army man in the data structure. At the starting of this task it

asks to authenticate the device by users thumb impression. After successfully authenticating the

user, location data is stored in data structure. This is function should be permitted. To fulfil this


Embedded RTOS 25

requirement reading and storing of the data is being done by locking the task. Here in the

simulation process user should enter data manually. At the scanf statement control of the

programme goes to the second task due to the wait in entering of the user parameter. To achieve

synchronization and avoid unwanted context switching taskSuspend () is used at the starting of all

tasks. By the ending of the one task will resume the other task. So at some instance of the time only

one task is in the ready queue of the Vxworks. Figure 3.7 shows the code with the above discussed

mechanism.

Figure 3. 7 fn_task1

Before the ending of the tfn_task1, task service is in the suspend state. By the end of

fn_taks1, it will resume task named service. After executing the resume instruction for this task,

context switches at this piece of code. At the initial stage it asks the user if want to generate the

service or not. If the service is enabled then it asks the user to enter the location (longitude and

latitude) and time (delay from current time) from the user. It stores this data to the request structure.

Figure 3. 8 Service from


Embedded RTOS 26

At the end, this task will resume the temperature task which is having priority of the

15(lowest priority among all tasks in this node).This will reads the current temperature of location

and send it to the data structure. Figure 3.9 shows this mechanism.

Figure 3. 9 Temperature

Above three tasks runs on the solider node. At the end of temperature task resumes the

fn_task2.This task runs on the air force node. Initially is checks the data structure wither any

service request is available or not. On the arrival of the service request it shows the location and the

time of the service to the screen. If no service request is available/after serving the service request

function it stores the location of the airplane to the global structure. Figure 3.20 shows the above

mechanism.

Figure 3. 10 Air force

At the end of above task it resumes the task command. This is investigation task. Command

task dose not writes anything to the global data structure. It only reads and display whole operation

and service request with the location on the screen. As the back ground process, this task updates

the photo library with the new arrival of the photos from the cloud. So, by the end of this process

the commander’s node is updated with the all photos/videos which is recently sent by the army

node. Figure 3.11 shows this mechanism.


Embedded RTOS 27

Figure 3. 11 Command

3.4 Test cases

Table 3.1 shows the test case and the description for above designed DCGS. Here all the test

cases are tested and obtained result is documented along with this table.

Table 3. 1 Test cases

Test case

number

Testing

Type

Pass/Fail Tested Nodes Description of the Test case

Tc_1 Unit

testing

Y All By the entering of the wrong password

system should not allow the user to

read/write information

Tc_2 Integration

testing

Y All While running, Should not cause dead lock

or race condition

Tc_3 Unit

testing

Depends All Check wither speed of 3g network is enough

capable to handle live data

Tc_4 Integration

testing

Y All Any of task should not be permitted while

reading sensor and write the data to cloud

Tc_5 Unit

testing

Y All By generating the service request it should

update the location to be served.

Tc_6 Unit

testing

Y Solider and

air force

GPS receiver should send location with the

good accuracy of 10 m


Embedded RTOS 28

3.5 Disscution of obtained result

At the first starting of the device it asks about the node admin. This phenomena shown by

the figure 3.12. After setting the admin for login, it asks to re enter the particular node’s login

identity. This both output is pointed by the calloutsin figure 3.12.

Figure 3. 12 Asking for authentication

After entering the authentication ID it enter(log in) to the node and synchronize current location of the

soldier to the cloud. This phenomena is pointed by the callout in the figure 3.13.

Figure 3. 13 Synchronizing location of soldier

After synchronization of location it asks for the service from the other entity (in this case air

force) is required or not. This mechanism is shown by the figure 3.14.

Figure 3. 14 Asking for service

Figure 3. 15 Showing request number

After entering the ID(thumb) its taking location of soldier

Asking to make node admin by thumb ID

By the time of login in soldiers node, asking for authentication

It is asking to enable the service from air force

After entering the time of service program shows the service request number


Embedded RTOS 29

After receiving of the all the data related to the service program shows the service request

number .This is pointed by the callout in figure 3.15.

Figure 3. 16 Air force task

Figure 3.16 shows the task running at the air force node. In this task, after authentication

task will read the location of the plane(air force vehicle) and synchronize this data to the cloud.

Figure 3. 17 commanded node

Figure 3.17 shows the output generated by the commanders’ task. This task will regenerate

all the information and display it to take decision. Commander will forward service request to the

air force department.

3.6 Conclusion

DCGS system is implemented by using Vxworks RTOS which can develop in tornado

IDE/Cross compiler. Software flow diagram, test cases and results are documented.

Reading location of air force vehical(plane).

Retrives all collected data at commander to take decision


Embedded RTOS 30

CHAPTER 4 4.1 Module Learning Outcomes

� Basic RTOS concepts

� Concepts of Vxworks, ucos and osec

� Scheduling associated with different RTOS

� Creating , managing and deleting of the task under tornado IDE

� Synchronization mechanism and inter process communication

� Interrupts signals and timer under Vxworks

4.2 summary

As part a of this assignment, essay is prepared on “Suitability of the Linux kernel work

queues as RTOS” is created. In part b DCGS system is designed which can communicate between

solider, commander and air force/air plane. This designed system is developed using Vxworks and

documented as part c.


Embedded RTOS 31

References

[1] Myths & Realities of Real-Time Linux Software Systems

[2] http://www.edaboard.com/thread144931.html

[3] Embedded Linux Best Practices, 2 December 2006

[4] Electronics Weekly's Focus on Mobile Linux

[5] RTOS vs. Linux kernel workqueue - Embedded Systems and Real-Time OS

[6]https://publicintelligence.net/army-distributed-common-ground-system-dcgs-a-

commander%E2%80%99s-handbook/

[7]http://www3.ausa.org/webpub/DeptGreenBook.nsf/byid/WEBP7GMWZ/$File/C4I%20Systems.

pdf?OpenElement


Embedded RTOS 32

Appendix

The first step in using work queues is creating a work queue structure. The work queue structure is represented by struct work_struct and defined in linux/workqueue.h. if want to create work queue structure statically, declare it directly with: DECLARE_WORK(name, function, data) This macro creates a struct work_struct and initializes it with the given work queue handler, function. The work queue handler must match the following prototype: void my_workqueue_handler(void *arg) The arg parameter is a pointer passed to work queue handler by the kernel each time it is invoked. It is specified by the data parameter in the DECLARE_WORKQUEUE() macro. By using a parameter, device drivers can use a single work queue handler for multiple work queues. The data parameter can be used to distinguish between work queues. If you do not want to create your work queue structure directly but instead dynamically, you can do that too. If you have only indirect reference to the work queue structure, say, because you created it with kmalloc(), you can initialize it using: INIT_WORK(p, function, data) In this case, p is a pointer to a work_struct structure, function is the work queue handler and data is the lone argument the kernel passes to it on invocation. Creating the work queue structure normally is done once—for example, in your driver's initialization routine. The kernel uses the work queue structure to keep track of the various work queues on the system. You need to keep track of the structure, because you will need it later. Your Work Queue Handler Basically, your work queue handler can do whatever you want. It is your bottom half, after all. The only stipulation is that the handler's function fits the correct prototype. Because your work queue handler runs in process context, it can sleep if needed. So you have a work queue data structure and a work queue handler—how do you schedule it to run? To queue a given work queue handler to run at the kernel's earliest possible convenience, invoke the following function, passing it your work queue structure: int schedule_work(struct work_struct *work) This function returns nonzero if the work was successfully queued; on error, it returns zero. The function can be called from either process or interrupt context. Sometimes, you may not want the scheduled work to run immediately, but only after a specified period has elapsed. In those situations, use:


Embedded RTOS 33

int schedule_delayed_work(struct work_struct *work, unsigned long delay) In this case, the work queue handler associated with the given work queue structure will not run for at least delay jiffies. For example, if you have a work queue structure named my_work and you wish to delay its execution for five seconds, call: schedule_delayed_work(&my_work, 5*HZ) Normally, you would schedule your work queue handler from your interrupt handler, but nothing stops you from scheduling it from anywhere you want. In normal practice, the interrupt handler and the bottom half work together as a team. They each perform a specific share of the duties involved in processing a device's interrupt. The interrupt handler, as the top half of the solution, usually prepares the remaining work for the bottom half and then schedules the bottom half to run. You conceivably can use work queues for jobs other than bottom-half processing, however. Work Queue Management When you queue work, it is executed when the worker thread next wakes up. Sometimes, you need to guarantee in your kernel code that your queued work has completed before continuing. This is especially important for modules, which need to ensure any pending bottom halves have executed before unloading. For these needs, the kernel provides a function to wait on all work pending for the worker thread: void flush_scheduled_work(void) Because this function waits on all pending work for the worker thread, it might take a relatively long time to complete. While waiting for the worker threads to finish executing all pending work, the call sleeps. Therefore, you must call this function only from process context. Do not call it unless you truly need to ensure that your scheduled work is executed and no longer pending. This function does not flush any pending delayed work. If you scheduled the work with a delay, and the delay is not yet up, you need to cancel the delay before flushing the work queue: int cancel_delayed_work(struct work_struct *work) In addition, this function cancels the timer associated with the given work queue structure—other work queues are not affected. You can call cancel_delayed_work() only from process context because it may sleep. It returns nonzero if any outstanding work was canceled; otherwise, it returns zero. Creating New Worker Threads In rare cases, the default worker threads may be insufficient. Thankfully, the work queue interface allows you to create your own worker threads and use those to schedule your bottom-half work. To create new worker threads, invoke the function: struct workqueue_struct * create_workqueue(const char *name)


Embedded RTOS 34

For example, on system initialization, the kernel creates the default queues with: keventd_wq = create_workqueue("events"); This function creates all of the per-processor worker threads. It returns a pointer to a struct workqueue_struct, which is used to identify this work queue from other work queues (such as the default one). Once you create the worker thread, you can queue work in a fashion similar to how work is queued with the default worker thread: int queue_work(struct workqueue_struct *wq, struct work_struct *work) Here, wq is a pointer to the specific work queue that you created using the call to create_workqueue(), and work is a pointer to your work queue structure. Alternatively, you can schedule work with a delay: int queue_delayed_work(struct workqueue_struct *wq, struct work_struct *work, unsigned long delay) This function works the same as queue_work(), except it delays the queuing of the work for delay jiffies. These two functions are analogous to schedule_work() and schedule_delayed_work(), except they queue the given work into the given work queue instead of the default one. Both functions return nonzero on success and zero on failure. Both functions may be called from both interrupt and process context. Finally, you may flush a specific work queue with the function: void flush_workqueue(struct workqueue_struct *wq) This function waits until all queued work on the wq work queue has completed before returning.

Assignment 3

Technology

Transcript of Assignment 3