Linux Work Queues for Real-Time Systems

EMBEDDED PROCESSORS AND
MICRO CONTROLLERS
Module Code
Module Name
Course
Department

ESD 531
Embedded RTOS
M.Sc in Real-Time Embedded Systems
Computer Engineering

Name of the Student

Bhargav Shah

Reg. No

CHB0911001

Batch

Full-Time 2011

Module Leader

Deepak V.

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

Embedded RTOS

POSTGRADUATE ENGINEERING AND MANAGEMENT PROGRAMME – (PEMP)

MSRSAS - Postgraduate Engineering and Management Programme - PEMP

i

Declaration Sheet
Student Name

Bhargav Shah

Reg. No

CHB0911001

Course

Real Time Embedded System

Batch

FT-11

Module Code

ESD531

Module Title

Embedded RTOS
to

Module Date
Module Leader

Batch Full-Time 2011

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

ii


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.

Embedded RTOS

iii

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

iv


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

Embedded RTOS

v

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

vi


List of Symbols
RTOS
OS
RAM
FIFO
SJF
EDF
DCGS
ISR
BCT
IWF
GRCS
COMINT
ELINT
SBCT
ACR
SIGINT
EW
BFSB
NCES
DIB
IPC
RPC

Embedded RTOS

Real Time Operating System
Operating System
Random Access Memory
First in, First out
Shortest Job First
Earliest Dead line First
Distributed Common Ground System
Intelligence, Surveillance, and Reconnaissance
Brigade Combat Team
Intelligence War fighting Function
Guardrail Common Sensor
Communication Intelligence
Electronic Intelligence
Stryker Brigade Combat Team
Armored Cavalry Regiment
Signals Intelligence
Electronic Warefare
Battlefield Surveillance Brigade
Network-Centric Enterprise Services
DCGS Integration Backbone
Inter Process Communication
Remote Procedural Call

vii

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 realtime 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 realtime 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


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 Preemptive 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 Linux is the name given to a specific operating
Operating System

system

Best suited for embedded systems

Linux isn’t always the best OS to use in
embedded systems
Linux is that it is slower than RTOS solutions on

RTOS is faster

the same hardware
RTOS

world

where

developers

might Linux has the same skill separation

specialise in Board Support Packages (BSPs),
device drivers or applications
RTOS application developers work best with RTOS BSP and device driver developers are
userspace applications

well suited to working in the Linux kernel

RTOS developers are used to working on Embedded Linux tools are Open Source and run
Windows development hosts

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

9


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

10


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

11


PART-B
CHAPTER 2 Design of DCGS
2.1 Introduction
Distributed Common Ground System (DCGS) is considered the backbone of the networkcentric 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

12


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

13


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

14


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-realtime 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

15


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

soilder's node

Army
commander's
office node

Airforce node

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

16


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 Basic idea behind this
in tablet

sensor

is

to

send

location of the soldier
to the cloud.
HWR_2

Temperature sensor

Should embedded in This sensor is used to
tablet

sense the temperature
of the present location

HWR_3

Camera

Should embedded in This is user to transmit
tablet

live Video/images to
the cloud

HDR_4

One tablet

Should

be

with This Plays major roll

soldiers on the battle in communicating with
field

the commander and
soldier.

This

programmed

like

is
it

will retrieve all the
data and send it on the
cloud
HRD_5

Thumb
detector

impression Should embedded in This is responsible to
tablet

authentication of the
solider

Embedded RTOS

17


Requirements for commander’s node
HRD_6

Computer with internet

Any ware

To retrieve all the data

connection
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

Process Ignited

Process description

iteration time
Processes at the solders’ node
PID_1

soldiers node

Single

time

Auto

This process is providing

when time of

security to the device by

start-up.

checking

for

thumb

impression of the user
PID_2

soldier node

Infinite

time

Auto

At every time this process

until life spam

reads location data which

of device

is sent by the GPS receiver
and update it on cloud

PID_3

Soldier’s node

Infinite

time

Auto

This process is responsible

until life spam
of device

Embedded RTOS

for reading and updating
the current temperature of

18


battle field on the cloud
PID_4

Soldier’s node

Infinite

time

Auto

This process is responsible

until life spam
of device

cloud.
time

Initiated by user

This task asks about the

until life spam

when service is

service is required for other

needed from

entity. if it is required it

other entity

PID_5

Soldier’s node

for sending photos/video to

Infinite

make a service request and

of device

returns the request number
to army
PID_6

Soldier’s node

Infinite

time

Auto

This

task

will

until life spam

show/retrieve location data

of device

of air force and show to
army.

Processes at the commanders’ node
Commander’s

Infinite time

This process reads all the

commander on

node

Initiated by the

data from the cloud and

the requirement

PID_7

displays it.

of the data
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

19


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

20


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

21


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

22


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

23


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

24


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

25


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

26


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

Testing

number

Type

Tc_1

Unit

Pass/Fail

Tested Nodes

Description of the Test case

Y

All

By the entering of the wrong password

testing

system should not allow the user to
read/write information

Tc_2

Integration

Y

All

testing
Tc_3

Unit

or race condition
Depends

All

testing
Tc_4

Integration

Unit

Y

All

Unit
testing

Embedded RTOS

Any of task should not be permitted while
reading sensor and write the data to cloud

Y

All

testing
Tc_6

Check wither speed of 3g network is enough
capable to handle live data

testing
Tc_5

While running, Should not cause dead lock

By generating the service request it should
update the location to be served.

Y

Solider and
air force

GPS receiver should send location with the
good accuracy of 10 m

27


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

Asking to make
node admin by
thumb ID

By the time of login in
soldiers node, 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.

After entering the
ID(thumb) its taking
location of soldier
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.

It is asking to enable the
service from air force

Figure 3. 14 Asking for service

After entering the time of
service program shows the
service request number
Figure 3. 15 Showing request number

Embedded RTOS

28


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.
Reading location of air force
vehical(plane).

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.
Retrives all collected data at
commander to take decision

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.

Embedded RTOS

29


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

30


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-acommander%E2%80%99s-handbook/
[7]http://www3.ausa.org/webpub/DeptGreenBook.nsf/byid/WEBP7GMWZ/$File/C4I%20Systems.
pdf?OpenElement

Embedded RTOS

31


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

32


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

33


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.

Embedded RTOS

34

Linux Work Queues for Real-Time Systems

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (11)

Similar to Linux Work Queues for Real-Time Systems

Similar to Linux Work Queues for Real-Time Systems (20)

Recently uploaded

Recently uploaded (20)

Linux Work Queues for Real-Time Systems