This Software Requirements Specification (SRS) is for an Air Traffic Control (<ATC>) Radar Data Processing System (<RDPS>). The purpose of this document is to translate the high-level statement of customer’s need into software requirements, including both functional and non-functional requirements.

1.1 Purpose

The purpose of the <RDPS> is to help maintain the safety of the airspace that is monitored by radar. It helps to coordinate the flight paths of aircraft in its range in order to prevent collisions, as well as monitor the airspace for unidentified objects that may be hazardous to aircraft, in an error-tolerant manner.

1.2 Scope

This document has the following objectives:

1. Identify the functional requirements of the <RDPS> (section 3 of this document);

2. Identify the non-functional requirements of the <RDPS> with respect to performance, safety, security and software quality attributes (section 4)

1.3 Data Dictionary

This section defines the terminology used in this document.

1.3.1 Definitions and Acronyms

Adaptation data	data used to initialize the system at startup
Air traffic controller	person who coordinates the movement of air traffic to make certain that planes stay a safe distance apart
ATC	Air Traffic Control
Coast out	event in which a track exceeds the <coasting period>
Coasting	the state in which a <track> becomes when radar reports are no longer correlated with it
Coasting period	duration of time when the <RDPS> does a coating action on a <track> when <radar reports> are no longer correlated to the <track>.
Correlation	to relate a <radar report> to an exiting <track>
Data elements	it is used to associate with <track update output message>
Dynamic resource management policy	a resource management policy in which resources are evaluated and allocated at run time
Established track	a <track> that has been successfully correlated to a <radar report>.
Flight coordinator	person who coordinates the flights based on <radar reports> and <track> output messages.
Latitude	a number that indicates the latitude of the current <track> position
LED	Light Emitting Diode
Longitude	a number that indicates the longitude of the current <track> position
MDC	Multiple Discrete Codes
MDC status	When two or more <tracks> have been updated by different <radar reports> transmitting the same <Mode A SSR code>, the value of the <MDC status> will be set to "true", "false" otherwise.
Mode A SSR code	a four digit octal number transponded by an aircraft
Mode A SSR code status	the status of a <track> indicating whether the aircraft has a <Mode A SSR code>.
Mode C altitude	altitude information transponded by an aircraft derived from the air pressure sensed by the aircraft.
Mode C altitude status	the status of a <track> indicating whether the aircraft has a <Mode C Altitude>.
MSA	Minimum Safe Altitude
MSAW	Minimum Safe Altitude Warning
MSAW status	If flying over a congested area of a city, town or settlement, and over any open air assembly of persons, if an altitude of 1000 feet above the highest obstacle within a horizontal radius of 2000 feet of the aircraft is not maintained, the <MSAW status> will be set to "true", "false" otherwise.
Pending State	A state whereby any further transmissions of the same <SCC status> from the same plane is ignored for a <pending time VSP> period.
Primary processor	the main processor that the <RDPS> runs on
PSR	Primary Surveillance Radar
PSR-only	one of the modes of the radar report in which the aircraft only contains a PSR code
Radar report	report generated by a radar in one radar sweep. It is used to correlate <track>.
Radar sweep	one single rotation of the radar head
RDPS	Radar Data Processing System
SCC	Special Condition Code
SCC status	When an <SCC> is detected for a track, the <SCC status> is "active". This <SSC status> shall remain "pending" until the <SCC status> is acknowledged by an operator or the client system. =8 This <SSC status> will be "false" otherwise.
SSR	Secondary Surveillance Radar
Stand-by processor	The <secondary processor> that is in a stand-by state in case of the failure of the <primary processor>
Startup self checking	system checkup done at startup
System switchover	when the <stand-by processor> takes control over the <primary processor>
Tentative track	A <track> that has not been successfully correlated to a <radar report>.
Terrain model	it divides the surface of the earth (for the radar coverage area) into units that are associated with a minimum safe altitude. The terrain model is part of the “<adaptation data>” for the system.
Track	report resulting from a <correlation> of radar reported position of an aircraft and its associated information
Track initiation	Occurs when the first <track> update of a <track> is associated to a chain that has not already had a <track> associated to it.
Track quality	an enumerated type with three values: “active,” “coasting” and “coasted out”. If a <track> is correlated to the radar reports, it is "active". The <RDPS> will “coast” a <track> when <radar reports> are no longer correlated to the <track>. After the coasting period, if no subsequent radar reports are correlated to the coasting <track>, the <track> will be “coasted out.”
Track update	to update a <track> based on recent <radar reports>
Unique track identifier	identification used to select a particular <track>. It is an integer between 0 and 1000

1.3.2 Variable System Parameters

Amount of tracks the CPU can process VSP	the maximum amount of <tracks> the CPU can process.
Coasting period VSP	the duration of the coasting period. It is between three to ten <track> updates.
Collision distance VSP	the distance between / among <tracks> when a collision signal is issued. The value is 1000 feet.
Critical system resource level percentage VSP	the percentage level before the <RDPS> is considered low on resources.
Hold time VSP	the duration of time in which the <SSC> signal is active. The valuse is 3 seconds.
Max number of tracks VSP	the maximum number of <tracks> the system can allow simultaneously.
Maximum acceptable hardware malfunction notification time VSP	the maximum amount of time within which the system shall issue a notificaton message after a hardware failure
Maximum acceptable switchover time length VSP	The maximum allowable duration of time for the overall <switchover> process to finish.
Maximum coasting period VSP	the maximum duration of time when the <RDPS> coast on a <track>.
Maximum correlation tolerance percentage VSP	the maximum allowable error in the <correlation> process.
Maximum time out period for tentative track VSP	the maximum duration of time at which the <RDPS> shall discard a tentative <track>.
Maximum warning delay VSP	the maximum allowable duration of time from the issuing of the warnings by the system to the notification of the operator or the client system. It is 5 milliseconds.
Minimum distance between tracks VSP	when two or more <tracks> that are <PSR>-only have a distance smaller than or equal to the this VSP, the system will terminate the <tracks>.
MSAW suppression distance from airport VSP	the distance between the airplane and the airport within which the <MSAW> is suppressed. The value is 500 meters radial distance.
Pending time VSP	the duration of time in which the system ia at <pending state>. The value is 10 seconds.
Plane speed VSP	the plane speed within which the <MSAW> is supppressed. The value is 100 meter per second.
The maximum acceptable switchover delay VSP	the maximum allowable duration of time from the <primary processor> malfunction to <system switchover> occur. =8 =8 =8 =8 =8 =8 =8 =8
Threshold percentage of number of tracks the CPU can process VSP	the predefined maximum percentage of the maximum number of <tracks> the system can process before the system issues a warning.
Track update interval VSP	the time interval between subsequent <track> updates.It is a length of time that is between 5 to 15 seconds.

1.3.3 System Messages

Coast out warning message	a warning issued by the system when the <track> is coasted out.
Deletion of coasted out track warning message	message to indicate that a <track> has been terminated due to it being coasted out.
Error in stand-by processor message	message to indicate that an error has occurred in the <stand-by processor>.
Error message	message displayed in case of an error occurs.
Hardware malfunction message	message to indicate that a hardware failure has occurred.
Missing terrain model file message	message to indicate that the <terrain model> file is missing.
Multiple discrete code alert message	message to indicate that two or more <tracks> have the same discrete code.
Radar malfunction warning message	<warning message> indicating a radar malfunction has been detected.
RDPS output message	it consists of all the <RDPS> outputs.
SSC alert message	message to indicate that an aircraft has transponded an <SSC>
System resources low warning message	<warning message> indicating system resources low.
System switchover warning message	message to indicate that the <RDPS> is initiating a <system switchover>.
System warning messages	it consists of all warning messages.
Too many tracks warning message	message indicating too many <tracks> are being produced and the system cannot handle.
Track update output message	message generated for a <track update>.
Workstation malfunction warning message	message to indicate that one or more of the workstations have malfunctioned.

1.4 References

Dr. Joyce, J. Discussions with Dr. Jeff Joyce, EECE 415 course instructor. September-October, 2002.

Dr. Joyce, J. EECE 415 – Comments on RDPS Concept Papers. October 22, 2002

Dr. Joyce, J. High Level Statement of Customer’s Need, http://www.ece.ubc.ca/~elec415/teamproject.html.

Stevens, Mchael C. Secondary Surveillance Radar, Artech House, Inc., 1988.

Wong, Ken. Question and Answer session with Ken Wong, a RDPS domain expert. October 4, 2002.

1.5 Intended Audience and Reading Suggestions

The intended audience of this SRS consists of software designers, systems engineers, software developers and software testers of the <RDPS>.

1.6 Overview

This SRS contains the requirements specification for a <RDPS>. Section 2 of this document contains an overall description of the <RDPS>. It provides a general description of the <RDPS> by describing the product perspective, general product functions, system constraints, and assumptions and dependencies. Section 3 contains the functional requirements. Section 4 contains the non-functional requirements of the <RDPS>.

1.7 Document Conventions

2 Overall Description

The <RDPS> is a software system that processes <radar reports>, <correlates> them, and produces <track output messages> as output. It also issues warnings when conditions warrant them. Fault-tolerance is also an integral part of the <RDPS> design. Users of the system include <flight coordinators> and <air traffic controllers>. The <RDPS> assumes and depends on the correctness of the <radar reports>; the accuracy of the <RDPS> output depends on the <radar reports> produced by the radar systems connected to the <RDPS>.

2.1 Product perspective

The <RDPS> is one of the subsystems in an <ATC> system; an <ATC> system also includes a radar system and a <FDPS>. Figure 1 shows how the <ATC> system components are related.

Figure 1 Air Traffic Control System Block Diagram (if picture not shown click here)

2.2 Product Functions

The <RDPS> shall <correlate> the incoming <radar report> in order to create, update and terminate <tracks>. =8 The <RDPS> shall warn and alert the client system about any unusual conditions or errors. The system shall update the <established track> according to input of the <radar report>. The system shall be fault tolerant.

2.3 Assumptions and Dependencies

In order to operate correctly, the <RDPS> depends of all of the following assumptions:

1. The <radar reports> from the radar systems connected to the <RDPS> are correct;

2. The <terrain model> is correct;

3. The <adaptation data> is correct

The alerts and warning system requires the use of a terrain model that divides the surface of the earth (for the radar coverage area) into units that are associated with a minimum safe altitude (<MSA>). The terrain model is part of the “adaptation data” for the system.

3 Functional Requirements

The following subsections in section 3 describe the functional requirement of the RDPS in detail.

3.1 Correlation

The goal of <correlation> is to identify aircraft based on matching incoming <radar reports> from the radar system with established <tracks> in the <RDPS>, or in the case where the <radar report> does not match an existing <track>, correlation is the process of using the <radar report> information as a basis for creating a new <track>. The information from the <radar report> is used for <track generation>, <track update> and <track termination> by the <track update> system.

The basis upon which <correlation> is established is a match between the <SSR code> in the <track> with the discrete <Mode A SSR code> in the <radar report>. =8 For <tracks> without <SSR codes>, other criteria such as azimuth, slant rant, altitude and PSR code are used to <correlate> with incoming <radar reports>.

3.1.1 Track Establishment

The <RDPS> shall <correlate> an incoming <radar report> with an <established track> and <tentative track>.

The <RDPS> shall store an uncorrelated <radar report> as a <tentative track>.

The <RDPS> shall use the transponded discrete <Mode A SSR code> from an incoming <radar report> to <correlate> with the <Mode A SSR code> associated with an <established track> or <tentative track>.

The <correlation> of <SSR codes> shall be an exact match between the 4-digit <SSR code> in the <radar report> and the one in the <track>.

The <correlation> of a PSR code and other criteria from a <radar report> shall be a match with a tolerance of <maximum correlation tolerance percentage VSP> in accuracy compared to those in <established tracks>.

3.1.2 Track Modification

The <RDPS> shall update an <established track> that <correlates> with a <radar report> with the information from the <radar report>.

The <RDPS> shall <correlate> a <radar report> that does not have a <Mode A SSR code> with an <established track> or a <tentative track> using all of the following criteria:

1. the azimuth information;

2. the <Mode C altitude> information;

3. the slant range information

The <RDPS> shall promote a <tentative track> to an <established track> that contains a <Mode A SSR code> which matches the <Mode A SSR code> from the <radar report>.

The <RDPS> shall coast an <established track> if it is not <correlated> successfully in a single <radar sweep>.

The <RDPS> shall compare information from different <radar reports> that <correlate> to the same <track> in one <radar sweep> with information form the <track> based on all of the following criteria:

1. the azimuth information;

2. the discrete <Mode A SSR code> information;

3. the <Mode C altitude> information;

4. the slant range information

The <RDPS> shall <coast out> an <established track> if no report is <correlated> to the <track> that has a <coasting> status after <maximum coasting period VSP>.

The <RDPS> shall discard a previously <correlated> <radar report> from a <track> if all of the following conditions are true:

1. two or more <radar reports> are <correlated> to the same <track> in one <radar sweep>;

2. there exists a better match <radar report> in one <radar sweep>

3.1.3 Track Termination

The <RDPS> shall discard a <tentative track> after <maximum time out period for tentative track VSP>.

The <RDPS> shall check and terminate two or more <tracks> that are <PSR-only> and that are within the distance of <minimum distance between tracks VSP> in one <radar sweep>.

3.2 Track Update

The purpose of <track update> is to update an existing <track> that is being monitored and maintained by the <RDPS>. <Track update> is done asynchronously depending on the <track update interval VSP>. For each <track update>, all <radar reports> <correlated> with a <track> will be used to provide a <track update output message> for the <track>.

3.2.1 Periodic Generation of a Track Update

Once a <track> is established, subsequent <radar reports> <correlated> with that <track> shall be used for the generation of a <track update output message>.

The length of time between each <track update> shall be determined by the <track update interval VSP>

Each <track update output message> shall be associated with a <data element>.

A <data element> shall consist of all of the following attributes:

1. <Unique track identifier>

2. <Latitude>

3. <Longitude>

4. <Mode A SSR code status>

5. <Mode A SSR code>

6. <Mode C altitude status>

7. <Mode C altitude> (pressure corrected)

8. <MSAW status>

9. <SCC status>

10. <MDC status>

11. <Track quality>

3.2.2 Data Element Constraints

The <unique track identifier> shall be an integer between 0 and 1000.

The <latitude> shall have a precision of 1/10,000 of a degree.

The <latitude> shall be in the range of -90.0000 to 90.0000 degrees.

The <longitude> shall have a precision of 1/10,000 of a degree.

The <longitude> shall be in the range of -180.0000 to 180.0000 degrees.

The <SCC status> shall be an enumerated type of two values: “active”, “pending” and “false”.

The <MSAW status> shall be an enumerated type of three values: “true” and “false”.

The <MDC status> shall be an enumerated type of two values: “true” and “false”.

The <track quality> shall be an enumerated type of two values: “active”, “coasting” and “coasted out”.

3.2.3 Coasting a Track

The <RDPS> shall <coast> a <track> when <radar reports> are no longer <correlated> to that <track> and the <track quality> is in the “active” status.

When coasting a <track>, the <track quality> of that <track> shall be changed to “<coasting>” if the <track quality> was “active”.

The <coasting period> shall be determined by the <coasting period VSP>.

The <RDPS> shall recover an <established track> from “<coast>” status if a <radar report> successfully <correlates> to the <track>.

3.2.4 Coasting Out a Track

After the <coasting period>, if no subsequent <radar reports> are <correlated> to the <coasting> <track>, the <track> quality shall be set to “coasted out”.

When a <track> is <coasted out>, the <track quality> of that <track> shall be changed from “<coasting>” to “<coasted out>”.

When the <track> is <coasted out>, the <track> will be terminated unless the <SCC status> is “active”.

If the <track> has been <coasted out> and the <SCC status> is “active”, the <track> will not be terminated until the <SCC alert message> has been acknowledged by an operator or a client system.

3.3 Alerts and Warnings

The purpose of the alerts and warnings system is to inform the <RDPS> of the possibility of danger or extreme conditions. The alerts and warnings system helps to ensure the safety of air traffic and people on the ground. It also provides warnings and alerts to air traffic controllers so that they can respond to unusual situations as quickly as possible. The alerts and warnings system monitors the various other systems in the RDPS and ensures their functionality and operation. Warnings and alerts from the system are produced based on the data received from <radar reports>, computers’ conditions, <SCCs> and Multiple Discrete Codes (<MDCs>). The most critical functions are the <MSAW> and collision warning alerts.

3.3.1 Minimum Safe Altitude Warning

1. If a plane is lower than the <MSA> of a particular piece of terrain, then an <MSAW> shall be issued to the operator or client system. =8

2. To prevent a <MSAW> warning when the plane is taking off or is landing, when a plane’s distance from an airport is less than <MSAW suppression distance from airport VPS> and the plane is traveling at less than <plane speed VSP>, then the system shall not issue a <MSAW>.

3.3.2 Collision warning

When two aircraft are within <collision distance VSP> distance of each other, a <collision warning message> shall be issued to the operator or the client system.

3.3.3 Special Condition Code alert

The following describes the events taken when an <SCC alert message> is detected:

1. When an <SCC alert message> is detected for a <track>, the <track> shall be attached with a <SCC> alert.

2. This <SSC alert message> state shall remain until the <SCC alert message> is acknowledged by an operator or a client system.

3. After acknowledgement, the system shall go to a “pending state” for <pending time VSP> whereby any further transmissions of the same <SCC alert message> by the same plane is ignored.

4. If the <SCC alert message> is detected and holds for less than <hold time VSP> then the <RDPS> shall ignore the <SCC alert message>.

3.3.4 Coast Out Warning

When a <track> is to be <coasted out> in the next <track update>, a <coast out warning message> shall be issued to the operator or the client system.

3.3.5 Multiple Discrete Code alert

The <RDPS> shall signal a <multiple discrete code alert message> when two or more <tracks> have been updated by different radar reports transponding the same discrete Mode C SSR code.

3.3.6 Deletion of Coasted Out Track Warning

When a coasted out <track> is about to be deleted, a <deletion of coasted out track warning message> shall be issued to the operator or the client system.

3.3.7 Too Many Tracks Warning

When more than <max number tracks VSP> <tracks> are being monitored and maintained by the <RDPS>, then a <too many tracks warning message> shall be issued to the operator or the client system.

3.4 System Services and External Interfaces

The System Services and External Interfaces subsystem of the <RDPS> helps to ensures the smooth operation of the system. All fault-tolerant requirements are specified in this subsystem. The System Services and External Interfaces subsystem also specifies the requirements for system startup, system warnings, external interface failure, and adaptation data.

3.4.1 System Startup

The <RDPS> shall load a <terrain model> for issuing <MSAW> during system startup.

If at startup, the <RDPS> determines that the <terrain model> file is missing or has been modified, the operator shall be notified with a <missing terrain model file message>.

The <RDPS> shall perform <startup self checking> at system startup.

If the startup process does not complete correctly, or is completed with errors, the operator shall be notified of the error with a <startup error message>.

The operator shall be notified of the absence or malfunction of the <stand-by processor> with an <error in stand-by processor message>.

3.4.2 Fault Tolerance

The <RDPS> shall include the capability to tolerate the failure of one processor by means of a <stand-by processor>.

If the <primary processor> malfunctions, <system switchover> shall occur.

The operator shall be notified whenever <system switchover> occurs with a <system switchover warning message>.

The automatic <system switchover> shall be transparent to the operator in terms of <RDPS> functionality.

After <system switchover>, the <RDPS> shall allow the <primary processor> to be disconnected from the hardware system.

The operator shall have the option to perform <system switchover> manually.

The operator shall be able to route <RDPS output messages> to a different workstation in the case of a workstation malfunction.

3.4.3 System Warnings

If the number of <tracks> exceeds <threshold percentage of number of tracks the CPU can process VSP> of <amount of tracks the CPU can process VSP>, the <RDPS> shall issue a <too many tracks warning message>.

If the available system resources is below <critical system resource level percentage VSP>, the <RDPS> shall issue a <system resources low warning message>.

The operator shall be notified within <maximum acceptable hardware malfunction notification time VSP> of malfunction of the system hardware with a <hardware malfunction message>.

All <error messages> shall remain until the operator acknowledges the <error message>.

3.4.4 External Interface Failure

If the radar system malfunctions, the <RDPS> shall issue a <radar malfunction warning message>, and state which part of the radar system malfunctioned.

If the radar system malfunctions, <RDPS> shall ignore all preceding <radar reports> from the malfunctioned part of the radar system.

If a workstation malfunctions, the <RDPS> shall issue <workstation malfunction warning message> to other workstations.

4 Other Nonfunctional Requirements

This section details the non-functional requirements of the <RDPS> with respect to performance requirements, security requirements, and software quality attributes.

4.1 Performance Requirements

The <RDPS> shall have a real-time constraint of <real time constraint VSP>.

The <RDPS> shall use a <dynamic resource management policy>, which determines resource allocation at run time.

The <RDPS> shall perform <system switchover> within <maximum acceptable switchover delay VSP> after the <primary processor> malfunctions.

The overall switchover process shall be finished within the <maximum acceptable switchover time length VSP> seconds.

The warnings issued by the system to the operator or the client system, shall have a delay of no more than <maximum warning delay VSP>.

4.2 Security Requirements

The <RDPS> shall restrict manual <system switchover> to authorized personnel only.

4.3 Software Quality Attributes

The <RDPS> shall be fault-tolerant such that it is available 99.999% of the time.