420 likes | 589 Views
ATCoach Tactical Edition PAR Simulator (APARS) DATA MANAGEMENT: ATCOACH FILES PART THREE Scenario Files CLS2004.A.0-004.3. Scenario Files Intro. Scenario Files. (UM Section 4.2.1 & Chapter 7).
E N D
ATCoach Tactical Edition PAR Simulator • (APARS) • DATA MANAGEMENT: • ATCOACH FILES • PART THREE • Scenario Files • CLS2004.A.0-004.3
Scenario Files Intro • Scenario Files. (UM Section 4.2.1 & Chapter 7) • Scenario files are used to create the aircraft and flight conditions used in a simulation exercise. • Scenarios are site dependent, which means that a scenario file is associated with a site file. • The last three letters (suffix) of the scenario name must match the first three letters of the site name. • For example; ex001.gsb is associated with the gsb.st, ex001.lyb is associated with the lybs.st. prob01.tuz is associated with the tuz.st
The scenario file is displayed. Scenario Files • Scenario Files. (UM Section 4.2.1 & Chapter 7) • To open the Scenario editor: • Click on the Scenario option on the Workspace menu. • The File Manager opens to the top level directory for sites: /space/atcoach/scenario. • Double click with the left mouse button on the desired file.
Scenario Files • Scenario Files. Requirements, formats, and explanation of terms. • The following presentation includes all Scenario file formats and entries (in a suggested sequence). • Scenario filenames can contain a maximum of twenty-nine alphanumeric characters, including the extension. • There is no limit to the number of aircraft that can be entered into a scenario at a given time. The simulator will continue to allocate memory until the system’s resources are depleted. • The user can limit the number of aircraft for each exercise and manipulate events. • Atmospheric data such as wind shears and multiple weather patterns can be entered • Data Format Symbols: • Mandatory data (< >). • Optional data ([ ]). • Space is required (_).
Scenario Files G • Weather - ATIS - (UM Section 7.4.1) • This entry is optional. • The single letter identifies the current weather at the primary airport. • Format G_<atis letter>_<message> • <atis letter> A- Z ATIS code identifier. • <message> 14 character maximum message. • EXAMPLE G B RWY8
Scenario Files T • Weather - Barometric Setting (T) - (UM Section 7.4.2) • This entry is optional. If not specified, ATCoach defaults to 29.92. • The barometric setting is the altimeter setting used by the primary airport for landing and departing aircraft. • Format T_<altimeter setting> • <altimeter setting> Specifies the barometric pressure in inches of mercury. • EXAMPLE T 30.12
Scenario Files K • Weather - Temperature Setting (K) - (UM Section 7.4.3) • This entry is optional. If not specified, ATCoach defaults to a temperature of 70.0 degrees. • The temperature is a decimal entry in degrees Fahrenheit e.g., 59.0. • Format K_<temperature> • <temperature> Specifies the temperature in Fahrenheit. • EXAMPLE K 31.0
Scenario Files L • Weather - System Visibility (L) - (UM Section 7.4.4) • This entry is optional. If not specified, ATCoach defaults to 10 miles. • The system visibility format allows the user to change the visibility within a scenario. • When traffic advisories or landing clearances are issued, this visibility is checked by ATCoach to determine if it is possible for the pilot to have the runway in sight or whether or not traffic can be seen. • Format L_<dd> • <dd> Sets the system visibility in nautical miles. • EXAMPLE L 2 • System visibility set at 2 miles. Any traffic advisories or runway in sight queries issued for a distance greater than 2 miles will not be seen by the pilot.
Scenario Files V • Weather - Storm System (STORM)- (UM Section 7.4.5) • This entry is optional. A storm system (STORM) displays one or more storm cells (STORM_CELL) on the radar display. • The format includes a speed to indicate movement of a cell or a speed of zero may be entered depicting clutter. • Varying intensities may be displayed. Combining two or more of these types may form a larger area or weather front. • The associated storm cell entry is required for the weather pattern to be displayed, and each storm cell makes up the storm system immediately preceding it. • The underscore in the STORM_CELL definition is not a space. • NOTE: Storms are displayed as raw radar video; subsequently they are not visible on the supervisor display.
Scenario Files V • Weather - Storm System (STORM)- (UM Section 7.4.5) • Format STORM_<start time>_ <end time | FOREVER>_ <range>_ <azimuth>_ <speed>_<heading>_<intensity> STORM_CELL_<range>_<azimuth>_<diameter>_<base alt>_ <ceiling alt>_<intensity> • STORM: • <start time> Specifies the time that you want the storm to enter the exercise. • <end time | FOREVER > Specifies the time that you want the storm to clear the exercise, or makes it remain for the duration of the exercise. • <range> Specifies the distance from touchdown for the center mass of the storm system. May be entered as a single digit, and decimal values are supported. • <azimuth> Specifies the azimuth from touchdown for the center mass of the system, entered in three-digits, decimal values are supported. • <speed> Speed in knots. May be entered as a single digit, and decimal values are supported. • <heading> Direction of movement in degrees. Leading zero is not required and decimal values are supported. • <intensity> Severity of the storm system. Levels range from 1 (low) to 9 (high). • STORM_CELL: • <range> Specifies the distance outward from the center mass of the storm system. May be entered as a single digit, and decimal values are supported. • <azimuth> Specifies the azimuth from the center mass of the system, entered in three-digits, decimal values are supported. • <diameter> Size of the cell in nautical miles. May be entered as a single digit, and decimal values are supported. • <base altitude> Lower (base) altitude in hundreds of feet. • <ceiling altitude> Upper (ceiling) altitude in hundreds of feet. • <intensity> Severity of the storm system. Levels range from 1 (low) to 9 (high). • EXAMPLE STORM 00:00 FOREVER 0.25 080 02.0 260.0 9 STORM_CELL 1.0 080.0 1.0 010 050 4 STORM_CELL 1.0 079.5 1.0 005 170 7 STORM_CELL 0.0 079.0 1.0 015 120 4 The example above specifies weather of moderate severity at the touchdown point out to approximately one mile in either direction. The storm cell will be displayed at start up, and will remain for the duration of the exercise.
Scenario Files W • Weather - Winds Aloft (W) - (UM Section 7.4.6) • This entry is optional. • Winds aloft simulate air movement within an altitude stratum. • A maximum of twenty winds aloft may be entered in each scenario. • Depending on the wind velocity entered aircraft performance such as airspeed and heading may be affected. • Format W_<base altitude>_<upper altitude>_<direction (from)> _<velocity> • <base altitude> Lower (base) altitude in hundreds of feet. • <upper altitude> Upper (ceiling) altitude in hundreds of feet. • <direction (from)> Direction from which it originates, entered in 3 digits. • <velocity> Speed in knots, entered in three-digits. • EXAMPLE W 000 005 060 030 • The example above specifies wind from the surface to 500 feet, blowing from 060 at 30 knots. • Note: The wind may also be entered on the fly during a exercise by using the format shown above. (Or F7 key on Instructor position - CW 000 013)
Scenario Files Expert Sys • Expert System - ATExpert - (UM Section 7.5) • This entry is optional. If not specified, ATCoach defaults to on. • This entry allows ATCoach to activate a “snitch box” when a defined airspace boundary, separation, or airspeed violation occurs during a exercise. • Each time an error occurs, an audible alert is sounded and the expert system alert window pops-up on screen. The type of violation and the applicable reference from the 7110.65 are displayed. • The screen command COX toggles on or off the display of the expert system window. Note: If the expert system responses are disabled in the scenario, the system is still running in “stealth” mode. The audible alert will not sound, nor will the alert window pop-up, but the errors are still saved to an error file in the student’s directory. When the exercise is terminated the “View Eval” option (section 1.2.1.3) will bring this report up for review. • Format X_<ON | OFF> • <ON | OFF> Toggles expert system on or off. • EXAMPLE X OFF
Scenario Files Time • Start Time - (UM Section 7.6) • Each Scenario may have a specific start time assigned within the Scenario. • Format TIME_<hhmmss> • <hhmmss> Six-digit start time assigned to the scenario. This time is displayed in the clock area of the Instructor screen. • EXAMPLE TIME 110000
Scenario Files Flight Plans • Flight Plan Formats - (UM Section 7.7) • There are two formats used to create aircraft flight plans: the C and CI format. • They are used for arrivals, departures, and final approach aircraft. • The letters C or CI are the first items entered in the flight plan. • The CI format designates the aircraft as an independent departure or arrival, which gives the Instructor the option to enter the aircraft during an exercise at any time. • The C format designates the aircraft as an automatic departure or arrival, this format is used to have the aircraft enter an exercise at a pre-designated time.
Scenario Files • Flight Plan Format Definitions - (UM Section 7.7.1 - 7.7.3) • The following terms are all of the items necessary to generate an aircraft for a scenario. • A number of the items are repetitive and are used with departures, arrivals, and finals. Those items will be covered only once but apply to all. • In the format that follows, items in parenthesis ( ) are the only allowable entries for the field. • Format C[I] _<entry time>_<entry controller (F)>_<acid>_<beacon code (NO_BCN)>_ <aircraft type/suffix [<type approach (SA | PA)>]_ <altitudes>_ <airspeed>_ <[<SID>] | [<fixes>] | [<(R<dd>A<ddd>H<ddd>)> | <([T]R<d[d][d]>[A[+|-]<ddd>][H[+|-]<ddd>])>]>
Scenario Files • Flight Plan Format Definitions - (UM Section 7.7.1 - 7.7.3) C[I] _<entry time>_<entry controller (F)>_<acid>_<beacon code (NO_BCN)>_ <aircraft type/suffix [<type approach (SA | PA)>]_ <altitudes>_ <airspeed>_ <[<SID>] | [<fixes>] | [<(R<dd>A<ddd>H<ddd>)> | <([T]R<d[d][d]>[A[+|-]<ddd>][H[+|-]<ddd>])>]> • The following fields are mandatory entries in the flight plan (C/CI)format. • <entry time> Specifies the time that you want the aircraft to enter the exercise. • The time may be entered in six digits ([05:] 10:00), hours, minutes and seconds. The hour’s entry is optional. • When the CI format is used, the entry time has no affect since the aircraft is entered at the Instructor’s discretion. The entry is still required in spite of this.
Scenario Files • Flight Plan Format Definitions - (UM Section 7.7.1 - 7.7.3) C[I] _<entry time>_<entry controller (F)>_<acid>_<beacon code (NO_BCN)>_ <aircraft type/suffix [<type approach (SA | PA)>]_ <altitudes>_ <airspeed>_ <[<SID>] | [<fixes>] | [<(R<dd>A<ddd>H<ddd>)> | <([T]R<d[d][d]>[A[+|-]<ddd>][H[+|-]<ddd>])>]> • The following fields are mandatory entries in the flight plan (C/CI)format. • <entry controller> For APARS, F is the only applicable entry. This specifies that the final controller has control jurisdiction and enables communications with the aircraft.
Scenario Files • Flight Plan Format Definitions - (UM Section 7.7.1 - 7.7.3) C[I] _<entry time>_<entry controller (F)>_<acid>_<beacon code (NO_BCN)>_ <aircraft type/suffix [<type approach (SA | PA)>]_ <altitudes>_ <airspeed>_ <[<SID>] | [<fixes>] | [<(R<dd>A<ddd>H<ddd>)> | <([T]R<d[d][d]>[A[+|-]<ddd>][H[+|-]<ddd>])>]> • The following fields are mandatory entries in the flight plan (C/CI)format. • <acid> This is the call sign of the aircraft. • There are 4 restrictions within ATCoach: • Call signs must begin with an alphanumeric character. • If a call sign ends in 2 letters, the first of the 2 letters cannot be a "C"; for example, N245CA would create an ambiguous response when used with a pseudo-pilot command. All other alphanumeric combinations are acceptable. • If voice recognition is used, the aircraft identifications must be one of the 200 call signs listed in the VRR aircraft identification database. • Two aircraft with identical call signs cannot be active at the same time. The first aircraft will have to terminated or “dropped” before the second aircraft may enter.
Scenario Files • Flight Plan Format Definitions - (UM Section 7.7.1 - 7.7.3) C[I] _<entry time>_<entry controller (F)>_<acid>_<beacon code (NO_BCN)>_ <aircraft type/suffix [<type approach (SA | PA)>]_ <altitudes>_ <airspeed>_ <[<SID>] | [<fixes>] | [<(R<dd>A<ddd>H<ddd>)> | <([T]R<d[d][d]>[A[+|-]<ddd>][H[+|-]<ddd>])>]> • The following fields are mandatory entries in the flight plan (C/CI)format. • <beacon code> For APARS, NO_BCN is the only applicable entry.
Scenario Files • Flight Plan Format Definitions - (UM Section 7.7.1 - 7.7.3) C[I] _<entry time>_<entry controller (F)>_<acid>_<beacon code (NO_BCN)>_ <aircraft type/suffix [<type approach (SA | PA)>]_ <altitudes>_ <airspeed>_ <[<SID>] | [<fixes>] | [<(R<dd>A<ddd>H<ddd>)> | <([T]R<d[d][d]>[A[+|-]<ddd>][H[+|-]<ddd>])>]> • The following fields are mandatory entries in the flight plan (C/CI)format. • <aircraft type/suffix> Specifies the type of aircraft and it’s equipment suffix. • There is one restriction within ATCoach: • The aircraft type must be defined in the aircraft model file. • Suffixes supported by ATCoach: D, M, X, Y, A, B, C, N, P, R, T, U • Note: ATCoach defaults to /A if no suffix is specified.
Scenario Files • Flight Plan Format Definitions - (UM Section 7.7.1 - 7.7.3) C[I] _<entry time>_<entry controller (F)>_<acid>_<beacon code (NO_BCN)>_ <aircraft type/suffix [<type approach (SA | PA)>]_ <altitudes>_ <airspeed>_ <[<SID>] | [<fixes>] | [<(R<dd>A<ddd>H<ddd>)> | <([T]R<d[d][d]>[A[+|-]<ddd>][H[+|-]<ddd>])>]> • This field is optional. • [<SA | PA>] Type Approach. Used to indicate the type approach requested. Enter either SA or PA for type approach. Note: This entry must be defined if using the <approach> keyword, otherwise a surveillance approach will be requested if queried.
Scenario Files • Flight Plan Format Definitions - (UM Section 7.7.1 - 7.7.3) C[I] _<entry time>_<entry controller (F)>_<acid>_<beacon code (NO_BCN)>_ <aircraft type/suffix [<type approach (SA | PA)>]_ <altitudes>_ <airspeed>_ <[<SID>] | [<fixes>] | [<(R<dd>A<ddd>H<ddd>)> | <([T]R<d[d][d]>[A[+|-]<ddd>][H[+|-]<ddd>])>]> • The following fields are mandatory entries in the flight plan (C/CI)format. • <altitude> Specifies the altitude of the aircraft. • There is one restriction within ATCoach: • The altitude entry is not used when creating a departure flight plan using a SID. The aircraft will climb to the altitude specified in the departure profile (DP), defined in the site file.
Scenario Files • Flight Plan Format Definitions - (UM Section 7.7.1 - 7.7.3) C[I] _<entry time>_<entry controller (F)>_<acid>_<beacon code (NO_BCN)>_ <aircraft type/suffix [<type approach (SA | PA)>]_ <altitudes>_ <airspeed>_ <[<SID>] | [<fixes>] | [<(R<dd>A<ddd>H<ddd>)> | <([T]R<d[d][d]>[A[+|-]<ddd>][H[+|-]<ddd>])>]> • The following fields are mandatory entries in the flight plan (C/CI)format. • <airspeed> Specifies the three-digit indicated airspeed (IAS) the aircraft will maintain. Within ATCoach, the airspeed is constrained by the following: • The true airspeed (TAS) of the aircraft may be affected by the wind speed defined in the scenario, depending on its velocity. • The airspeed cannot exceed the maximums defined for the aircraft type in the aircraft model file.
Scenario Files • Flight Plan Format Definitions - (UM Section 7.7.1 - 7.7.3) C[I] _<entry time>_<entry controller (F)>_<acid>_<beacon code (NO_BCN)>_ <aircraft type/suffix [<type approach (SA | PA)>]_ <altitudes>_ <airspeed>_ <[<SID>] | [<fixes>] | [<(R<dd>A<ddd>H<ddd>)> | <([T]R<d[d][d]>[A[+|-]<ddd>][H[+|-]<ddd>])>]> • The following fields are mandatory entries in the flight plan (C/CI)format. • <SID> This field is only used for departure flight plans. Specifies the aircraft’s standard instrument departure procedure. • To use this entry, ATCoach requires that the departure profile (DP) be defined in the Site file. • Do not enter an altitude when using a SID in the flight plan.
Scenario Files • Flight Plan Format Definitions - (UM Section 7.7.1 - 7.7.3) C[I] _<entry time>_<entry controller (F)>_<acid>_<beacon code (NO_BCN)>_ <aircraft type/suffix [<type approach (SA | PA)>]_ <altitudes>_ <airspeed>_ <[<SID>] | [<fixes>] | [<(R<dd>A<ddd>H<ddd>)> | <([T]R<d[d][d]>[A[+|-]<ddd>][H[+|-]<ddd>])>]> • The following fields are mandatory entries in the flight plan (C/CI)format. • <fixes> This field is used for departure and arrival flight plans. Identifies the aircraft’s route of flight, specifically locations; NAVAIDs, intersections or waypoints the aircraft is to proceed to. • May be individual fixes, or a route. • To use this entry, ATCoach requires that the fixes/routes be defined in the Site file.
Scenario Files • Flight Plan Format Definitions - (UM Section 7.7.1 - 7.7.3) C[I] _<entry time>_<entry controller (F)>_<acid>_<beacon code (NO_BCN)>_ <aircraft type/suffix [<type approach (SA | PA)>]_ <altitudes>_ <airspeed>_ <[<SID>] | [<fixes>] | [<(R<dd>A<ddd>H<ddd>)> | <([T]R<d[d][d]>[A[+|-]<ddd>][H[+|-]<ddd>])>]> • The following fields are mandatory entries in the flight plan (C/CI)format. • <(R<dd>A<ddd>H<ddd>)> Referred to as the Target Generation format, this format may be used for arrival, departure, or over flight aircraft in lieu of using the <departure SID> or <fixes> format used in a normal flight plan. This allows for aircraft to be placed at any range, azimuth and heading. • To use this format the following restrictions apply: • The location where the aircraft appears is relative to the AN (antenna) location defined in the site file. • The aircraft position is defined by Range, Azimuth and Heading. • The letter R (Range) is followed by a two-digit integer; letter A (Azimuth) is followed by a three-digit integer and H (Heading) is followed by a three-digit integer. • There are no spaces between the entries in the parenthesis. The parentheses that enclose the range, azimuth and heading are mandatory. Example: (R10A240H060)
Scenario Files • Flight Plan Format Definitions - (UM Section 7.7.1 - 7.7.3) C[I] _<entry time>_<entry controller (F)>_<acid>_<beacon code (NO_BCN)>_ <aircraft type/suffix [<type approach (SA | PA)>]_ <altitudes>_ <airspeed>_ <[<SID>] | [<fixes>] | [<(R<dd>A<ddd>H<ddd>)> | <([T]R<d[d][d]>[A[+|-]<ddd>][H[+|-]<ddd>])>]> • The following fields are mandatory entries in the flight plan (C/CI)format. • <([T]R<d[d][d]>[A[+|-]<ddd>][H[+|-]<ddd>])> • A variation of the Target Generation format, the Offset Generation format is used exclusively for arrival aircraft. This format allows aircraft to be placed at any location and heading without using absolute values. • This permits the aircraft to enter the exercise within the field of view of the antenna regardless of the active runway. • To use this format the following restrictions apply: • The aircraft position may be defined by Touchdown Range/Range, Azimuth value and Heading value. • If the optional T is not specified, the location where the aircraft appears is relative to the main bang’s orientation to the selected runway during the exercise. i.e., (R10A-09H260 • If the optional T format is specified, the entry location will be relative to the runway touchdown point of the selected runway. i.e., (TR10A-09H260 • The [T]R (Range) is defined by a two-digit integer. • A (Azimuth) and H (Heading) value entries are optional, but the actual letters (A and/or H) are still required. i.e., (R10A), or (R10H), or even (R10AH) may be used. • When the values are specified, the following formats are supported: • Offset values specifying whether the target will appear clockwise or anticlockwise from the antenna azimuth may be assigned with a +/- number i.e., (R10A-09H260). • Offset values specifying whether the target’s heading will track towards or away from the antenna azimuth may be assigned with a +/- number i.e., (R10A-09H+015) • One offset value and one absolute value may be assigned i.e., (R10A-09H260) or (R10A080H-010). • If the azimuth and/or heading value is left out, then it is considered an offset of 0. i.e., (R10AH) • If used, the azimuth value must be between -10 and +10, otherwise it will be outside the antenna’s scan limits and therefore not visible. • There are no spaces between the entries in the parenthesis. The parentheses that enclose the range, azimuth value and heading value are mandatory
Scenario Files • Flight Plan Format Definitions - (UM Section 7.7.1 - 7.7.3) C[I] _<entry time>_<entry controller (F)>_<acid>_<beacon code (NO_BCN)>_ <aircraft type/suffix [<type approach (SA | PA)>]_ <altitudes>_ <airspeed>_ <[<SID>] | [<fixes>] | [<(R<dd>A<ddd>H<ddd>)> | <([T]R<d[d][d]>[A[+|-]<ddd>][H[+|-]<ddd>])>]> • EXAMPLES Departure using a SID (The DP defined in the site file) C 00:01 F SAM32 NO_BCN BE20/X PA 150 OZR/06 Using fixes defined in the site file: C 00:01 F EAGLE6 NO_BCN H60/X PA 015 100 OZR TP26 TP4 TP3 TBR Using the target generation format: CI 00:00 F SAINT3 NO_BCN C130 PA 040 150 (R17A083H240) Arrival, using offset generation format: C 00:01 A EAGLE6 NO_BCN H60 PA 015 100 (TR11A-04H+010)
Scenario Files PPEs • Pre-programmed Events - (UM Section 7.8) • Pre-programmed events (PPEs) allow the user to execute pseudo-pilot commands and certain screen commands at a specific time. • At the instructor position, all future PPEs may be stopped started, delayed, or changed from the PPE dialog box (UM Section 3.4). • A PPE will be delayed by 2 minutes each time the delay button is pressed. • A PPE can only be changed after the <ACID> field.
Scenario Files PPEs • Pre-programmed Events - (UM Section 7.9.1) • Pilot commands PPEs. • Affect the flight plan of the aircraft, such as heading, altitude, airspeed, and frequency changes. • The list and description of the various pseudo-pilot commands can be found in Chapter 5, ATCoach Commands (section 5.3). • Format P_<entry time>_<acid>_<command>[<;><command>] • <entry time> Command launch time in HH:MM:SS from the start of the scenario. The hour’s entry is optional. • <acid> Aircraft call sign. • <command> Any command listed in Chapter 5, section 5.3. • [<;><command>] Any subsequent command(s) must be delineated with a semicolon ;. • EXAMPLE P 02:00 EAGLE2 A020;HR260 • The example above pre-programs EAGLE2 to climb or descend (depending upon its current altitude) and maintain 2,000 and turn right heading 260 at 2 minutes into the exercise. Note that there are no spaces between the altitude command, semicolon, and heading command. • Whether the aircraft climbs or descends depends on what altitude the aircraft is at when the P command activates.
Scenario Files PPEs • Pre-programmed Events - (UM Section 7.9.2) • Screen Command PPEs. • Screen commands are those that display of the radar screen, such as color settings, range settings, maps, and NAVAIDS. • All screen commands begin with a ‘C’. • The list and description of the various screen commands can be found in Chapter 5, ATCoach Commands (section 5.4). • Format P_<entry time>_<command> • <entry time> Command launch time in hours, minutes and seconds from the start of the exercise. The hour’s entry is optional. • <command> Any command listed in Chapter 5, section 5.4. • EXAMPLE P 00:10 CCR • The example above inhibits the compass rose 10 seconds into the exercise.
Scenario Files PR • Pre-programmed Pilot Responses (PR) - (UM Section 7.9) • Pre-programmed Pilot Responses (PR) allow the user to program the words and/or phrase to be spoken by an aircraft pilot at a specified time. • The format string is limited to 200 characters. • Any of the words that are listed in the Pilot Voice Recording Script (UM Chapter 8, section 8.6) may be used. • The entry of Site Specific data in a PR is not permitted, with the exception of the facility names listed under Facilities and Frequencies (UM Chapter 8, section 8.5.4). • PR entry data must be entered exactly as shown in section 8.6. • Words or phrases that are more than a single word must be entered with an underscore between them (the underscore in this format is not a space). • For example, under Air Traffic Control Words and Phrases, “with you” would be entered as with_you.
Scenario Files PR • PR Keywords - (UM Section 7.9.2) • Certain keywords may be used in developing PRs. • Keywords allow context specific information to be given. • More than one keyword may be used in any response.
Scenario Files PR • PRs with C and CI Formats - (UM Section 7.9.3) • The PR command reacts the same way as the pre-programmed event command described earlier. • The PR performs differently with the C and CI formats, • Regardless of the type format, subsequent PR times should be planned using time vs. speed and distance. • In other words, if a PR is required to be activated at specific position, the user must calculate the time of flight by factoring the aircraft’s airspeed and distance. • The following formulas and table will assist the developer in determining the time necessary to reach the desired position. Time = (Distance x 60) / Airspeed Distance = (Airspeed x Time) / 60
Scenario Files PR • PRs with C and CI Formats - (UM Section 7.9.3)
Scenario Files PR • PRs and the C Format - (UM Section 7.9.3) • With the C format, the PR occurs automatically at the time specified (unless the user intervenes) relative to the exercise start time. • Example: • An aircraft using the C format in its flight plan is automatically activated at 00:00. • From the aircraft’s starting point, if the initial call is to occur at a position that is at five minutes in time, the entry would be PR 05:00. • If a subsequent PR is required forty seconds after the initial call, the PR entry would be PR 05:40. • The times are all relative to when the exercise is started.
Scenario Files PR • PRs and the CI Format - (UM Section 7.9.3) • With the CI format, the PR occurs relative to the aircraft’s activation time. Because the user can enter the aircraft at any time during an exercise, the PR entry time should be proportional to the amount of time after the aircraft is launched to activate the PR. • Example: • An aircraft using the CI format in its flight plan is activated at 10:00 during the exercise. • From the aircraft’s starting point, if the initial call is to occur at a position that is at two minutes in time, the entry would be PR 02:00 instead of PR 12:00. • If a subsequent PR is required forty seconds after the initial call, the PR entry would be PR 02:40. • The times are all relative to when the aircraft is started, regardless of the clock time.
Scenario Files PR • PRs with C and CI Formats - (UM Section 7.9.3) • Format PR_<entry time>_ <facility> <CALL SIGN>_[free text]_ <keyword>_[free text]_<keyword>… • EXAMPLES • <entry time> Command launch time in hours, minutes and seconds from the start of the scenario. The hour’s entry is optional. • <facility> Keyword that will have the aircraft call the facility by its name as defined by the site file. • <CALL SIGN> Call sign of the aircraft that is to make the transmission. • [free text] Any of the allowable words and phrases described in section 7.10.1 - VRR Tables Chapter 8. • <keyword> Any of the keywords listed in section 7.9.2. C 00:05 F A91423 NO_BCN UH1/X PA 025 100 (R19A075H240) PR 01:00 A91423 <facility> <acid> • In the example above, A91423 makes its initial call at one minute into the exercise runtime: “Seymour Final A91423” CI 00:00 F TIGER4 1200 BE20 PA 025 150 (R17A-001+005) PR 00:10 TIGER4 <facility> <acid> Note: Keywords and free text are entered in the order you want the phrase to be said. • In the example above, TIGER4 makes its initial call ten seconds after being activated: “Seymour Final TIGER4”
Scenario Files PR • PR Planning - (UM Section 7.10) • An aircraft will normally have a minimum of 2 PR’s defined in the scenario. • The first PR is the initial call from the aircraft and will simply have the aircraft announce its callsign. • The initial call notifies a controller that an aircraft is on his frequency and is requesting service. • In ATCoach, it also serves as a warning that all the pilot’s information will be announced automatically unless action is taken by the controller to delay (“Standby”) or initiate (“Go Ahead”) the next PR. • The second PR is defined within a user specified time relative to the first one. • It should contain all the information necessary for the controller to provide service. • When the controller gives the command “go ahead” (WG), the aircraft will reply this information. • If the controller forgets about, or ignores the aircraft, the PR will activate automatically at its specified time. • EXAMPLE C 00:05 F A91423 NO_BCN UH1/X PA 025 100 (R19A075H240) PR 01:00 A91423 <facility> <acid> PR 02:30 A91423 <facility> <acid> <type> <altitude> REQUEST PAR_APPROACH APPROXIMATELY ONE FIVE MILES EAST <heading> • In the example above, A91423 makes its initial call one minute into the exercise runtime: “Seymour Final A91423” • If the controller responds “A91423, SEYMOUR FINAL GO AHEAD”, the 2nd PR activates. • If the controller responds “A91423, SEYMOUR FINAL STANDBY”, one minute will be added to the 2nd PR’s activation time if it is less than two minutes from occurring. • If the controller does not respond to the aircraft’s initial call, the 2nd PR will activate automatically at 02:30.
Check on Learning Check on Learning • Practical Exercise. • Access. • Copy. • Edit. • Error Check.
ATCoach Tactical Edition PAR Simulator (APARS) PART THREE COMPLETE CLS2004.A.0-004.3