Assignment 3
Upcoming SlideShare
Loading in...5
×
 

Assignment 3

on

  • 169 views

 

Statistics

Views

Total Views
169
Views on SlideShare
169
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Assignment 3 Assignment 3 Document Transcript

  • 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
  • MSRSAS - Postgraduate Engineering and Management Programme - PEMP 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
  • MSRSAS - Postgraduate Engineering and Management Programme - PEMP 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
  • MSRSAS - Postgraduate Engineering and Management Programme - PEMP 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
  • MSRSAS - Postgraduate Engineering and Management Programme - PEMP 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
  • MSRSAS - Postgraduate Engineering and Management Programme - PEMP 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
  • MSRSAS - Postgraduate Engineering and Management Programme - PEMP 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
  • MSRSAS - Postgraduate Engineering and Management Programme - PEMP 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
  • MSRSAS - Postgraduate Engineering and Management Programme - PEMP 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
  • MSRSAS - Postgraduate Engineering and Management Programme - PEMP 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
  • MSRSAS - Postgraduate Engineering and Management Programme - PEMP 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
  • MSRSAS - Postgraduate Engineering and Management Programme - PEMP 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
  • MSRSAS - Postgraduate Engineering and Management Programme - PEMP 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
  • MSRSAS - Postgraduate Engineering and Management Programme - PEMP 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
  • MSRSAS - Postgraduate Engineering and Management Programme - PEMP 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
  • MSRSAS - Postgraduate Engineering and Management Programme - PEMP 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
  • MSRSAS - Postgraduate Engineering and Management Programme - PEMP 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
  • MSRSAS - Postgraduate Engineering and Management Programme - PEMP 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
  • MSRSAS - Postgraduate Engineering and Management Programme - PEMP 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
  • MSRSAS - Postgraduate Engineering and Management Programme - PEMP 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
  • MSRSAS - Postgraduate Engineering and Management Programme - PEMP 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
  • MSRSAS - Postgraduate Engineering and Management Programme - PEMP 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
  • MSRSAS - Postgraduate Engineering and Management Programme - PEMP 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
  • MSRSAS - Postgraduate Engineering and Management Programme - PEMP 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
  • MSRSAS - Postgraduate Engineering and Management Programme - PEMP 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
  • MSRSAS - Postgraduate Engineering and Management Programme - PEMP 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
  • MSRSAS - Postgraduate Engineering and Management Programme - PEMP 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
  • MSRSAS - Postgraduate Engineering and Management Programme - PEMP 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
  • MSRSAS - Postgraduate Engineering and Management Programme - PEMP 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
  • MSRSAS - Postgraduate Engineering and Management Programme - PEMP 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