P.A.T.R.I.O.T Project

At this moment, I am a student at the University of Aveiro. I am enrolled in a subject called Real-Time Systems, and also my thesis is strongly related with this area.

As a final project to the subject, I was asked to build a simulator of an anti-missile system. I based my solution in the American PATRIOT system.

I will also be needing some experience with the OCaml language, therefore this project with be built using OCaml language.

Objectives:

The objective of the project is to build a Anti-Missile Simulator, that is based on threads (task) and interprocess communications. This IPC, has to be implemented using FIFO’s, another project restriction

The end result should be a totally independent system that is able to launch, detect and destroy missiles. Each missile is a thread. There are two missile launches, one defensive and one offensive.

There are some minor objectives such as: Graphical Interface, Code Optimization, Temporal Analysis, and others.

Mazimi20121102072633990

PATRIOT System:

The enemy launcher is a simple program that launches missiles, threads. On the other hand, the defensive system, PATRIOT, is based on the American System.

The simulator I am building is a replica of the PATRIOT systems, at least on its different subsystems:

1) Radar Surveillance

2) Command and Control

3) Missile Guidance

4) Communications

As it is obvious, Radar detects enemy missiles. Command and Control decides whether to shoot or not. Missile Guidance tracks the launched counter-missile and Communication keeps the base station informed (in our case, the user)

Here is a small protocol:

1) Radar detects an unidentified object and examine its velocity, size, altitude and direction

2) Transmits the data to the Command and Control, which in turn decides whether or not to shoot.

3) If there is a green light to shoot, CC fires the missile.

4) Radar detects the launched counter-missile and tracks its course, redirecting it as needed. Coordinates with the Radar through the Command and Control

5) As soon as the missile is in the proximity required, it detonates and destroy the missile

All though out this process the Communications subsystem logs and sends all the information.

 

Solution Architecture:

All my solutions will be based on the following general architecture. All arrows represent FIFO’s, enemy, PATRIOT and world are processes, and the missiles represent threads.

 

Architecture

General system architecture

 

The architecture is a very direct application of the problem. However, some simplifications were made:

  • The base stations have fixed positions
  • Missiles behave as regular projectiles
  • World is limited
  • Drag coefficient was not taken in consideration

 

Approach:

Characteristics of each element:

Enemy Launcher:

  • Holds all the information of the enemy missile
  • Able to launch missiles into “World”
  • Able to communicate with the missiles launched

PATRIOT Launcher

  • Holds all the information of the enemy missile
  • Able to launch missiles into “World”
  • Able to communicate with the missiles launched
  • Radar implemented

Radar ->

  • Able to detect airborne objects in a certain area of World
  • Able to calculate trajectories of the incoming missiles
  • Able to calculate interception fly trajectory of the anti-missile to be launched

World

  • Controls the simulation environment
  • Updates all the information of the simulation (Processes, time, missiles, etc.)
  • Checks if the objectives were or not achieved

 

IPC (Inter-Process Communication)

This was the tricky part. After having all the processes working independently, a way to communicate between them had to be implemented. As it was previously stated, IPC had to be implemented using FIFO’s. This is quite simple in OCaml, using pipes or mkfifos. The big problem comes when you have to transmit a lot of data, and most of them in integers or floats, and the only possible way is to use text (Strings).

To solve this, I implemented a Comm module that would define, create and read a communication packet to be sent as a string. The packet can be easily created and decoded.

In the final version, with all float variables integrated the packet had a size of 47 characters. But it can be more simplified.

 

Radar (Detection and Interception)

Detection

As the movement of the missiles was simplified to simulate regular 2D projectiles, detection of the trajectory is quite easy.

The Radar checks regularly for airborne missiles, when detected it reads at least two positions.

As soon as it registers two positions of the same object it sends the data to a routine that will analyze the position and correspondent time and retrieve the velocity of the object.

With the velocity and the correspondent time extrapolating the trajectory is very easy knowing that the missile is restricted to a projectile type motion.

 

Screen Shot 2013-01-20 at 7.22.37 PM

Interception

Knowing the incoming missile trajectory we need to know a collision point to destroy it.

I implemented a simple algorithm, that determines how much time it takes for the missile (from the detected position) to reach the ground/target, and then calculates the need velocity for the anti-missile to reach that position in half that time.

Again, assuming the missiles have projectile type motion, it is easily implemented.

Screen Shot 2013-01-20 at 7.28.14 PM

Real Time Constraints

Besides the already specified requirements, real-time constraints were also required. World process needs to be activated at a specified rate, and the radar process also need a specific activation time.

I decided that the world would activate in a 10 ms rate and the radar at a 30 ms rate.

Rates can be modified, specially the radar as it influences the detection and interception algorithms. Good for testing.

At the end, test were made to see if the routines would respect the time, and if the OS would respect the activations times.

Possibly, the machine used was powerful and the code simple, but no deviations in activation or execution were detected.

 

Results

The final implementation was a success, within certain limitations.

Achieved:

  • Processes and Threads, implemented independently
  • IPC by FIFO’s and communication protocol, working perfectly
  • Algorithms, although simplified, working correctly
  • Anti-missile successfully destroying enemy missiles
  • Real-Time system restraints met, taking in consideration that a non-Real-Time operating system was used

Non-Achieved:

  • No graphical interface
  • Communication Protocol rigid. Any change to the system demands a redesign of the protocol
  • Limited to projectile type missile motion
  • Base stations are fixed

 

Future Improvements

Some possible improvements are:

  • Graphical Interface
  • Increase the complexity of the missile motion
  • Increase the number of missile airborne
  • Add drag coefficient
  • Base station can move
  • Add further jitter to the system to test the results

 

Code, Report and Results

 

Code (awaiting confirmation)

Report (not yet in english)

Results (awaiting confirmation)

 

Reasearch

http://sydney.edu.au/engineering/it/~alum/patriot_bug.html

ArmyRecognition, MM-104 PATRIOT surfasse-to-air defense missile system. Nov. 20, 2012 – http://www.armyrecognition.com/

United States General Accouting Office, “PATRIOT: Software led to system failure at Dhahran, Saudi Arabia” GAO, Washington DC, Fev. 4, 1994

INRIA, Ocaml Core Library 4.0.1, Jan. 2, 2013 http://caml.inria.fr/pub/docs/manual-ocaml-4.00/libref/index.html

INRIA, Unix Library 4.0.1, Jan. 2, 2013 http://caml.inria.fr/pub/docs/manual-ocaml-4.00/libref/Unix.html

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: