Next Page

Prev Page

 

Objects Structure

 

The objects structure also includes a structure for associating objects. The next two charts ("Objects Associated with other Objects" and "Objects Related to Other Objects Via Associated Objects Use"), reference pages 50 and 51, describe the associated object structure. The two most common uses for this function are providing lists of the aircraft at an airbase and providing a list of cruise missiles on a bomber. These are not the only uses, and the assocobj.cmn common block lists 7 current uses for this function employed in the JFORCES.  Data relative to the object association is contained within this common block. The object common points to this list and each record within this list includes the associated object's id and the purpose of association (e.g. is it tanking or is it just escorting?). As with any linked list, a pointer to the next object in the list is also included in the record. In this case this pointer will point to the next object associated with the original object. In this fashion it can provide, for example, an easily maintained list of all aircraft at a base just by using one pointer in the base's object definition.

 

 

 

 

 

 

 

Final Structure

 

The final structure of interest in the object definition is the operational task data structure.  The next two charts ("Operational Task/Status for use in Operations/Commands Concerning Objects" and "Operational Task Object Pointer Structure"), reference page 53 and 54, refer to this structure. Operational tasks include the mission directives that direct an object's activities. The first chart lists some operational tasks invoked by the JFORCES.  Each record in this list includes the operational task type and the fields relating to this operational task. This data is stored in the opertask.cmn common and the fields for each operational task are documented in the header. As seen in the list in this common block, there can be a large number of these fields and the fields can include not only the parameters of the original directive but also any status updates. This is the case with some tasks, such as ASW, which are stored only to provide a convenient memory location for storing data on the status of a submarine prosecution.  As described in the processing section, operational tasks can be invoked either by a command (e.g. when an engagement command is issued either by the mmi or by the c2 module) or by the task can be invoked as a result of the object reaching a waypoint. This second method is used for prestacking a cruise missile launch when a bomber arrives at its launch point. The program executes this by searching through all operational tasks for an object as it arrives at the end of each leg to determine whether any of the operational tasks are flagged to occur at the end of that leg. Some prestacked commands are executed on a timed basis, e.g. a submarine may be commanded to launch a cruise missile at 3 hours into a scenario. These commands are NOT invoked by the operational task structure but instead are prestacked on the event stack to be issued at the appropriate time. These are issued by the event_handler routine at the designated time, and received by the simreceive routine and are processed identically with commands injected by the user during the simulation run.  The second chart provides a graphic of the described structure. It should be mentioned that some operational tasks, such as the engagement task, requires much more than the standard amount of space allocated to a single operational task. In order to accommodate this, the operational task structure is a double linked list structure. That is, each record has two pointers, one to the next operational task for this object and the other to the continuation of data (if any) for this operational task. While creating a more complex structure, this minimizes memory utilization and thereby increases run speed.

 

 

 

 

OPERATIONAL TASKS / STATUS FOR

USE IN OPERATIONAL COMMANDS

CONCERNING OBJECTS

 

OPERATIONAL TASK I STATUS:

PARAMETERS TO SUPPORT AN OPERATIONAL TASK OR STATUS

SUCH AS:

- INSTRUCTIONS TO LAUNCH CRUISE MISSILE

- PRESENT RULES OF ENGAGEMENT

- INSTRUCTION FOR AIRCRAFT TAKE OFF

- INTERCEPT STATUS

- TANKING STATUS

- FINAL COMMITMENT POINT

-INSTRUCTIONS TO DROP GRAVITY BOMB

-INSTRUCTIONS FOR USE OF COUNTERMEASURES

- REFUELING INSTRUCTIONS

- RECOVER INSTRUCTIONS FOR AIRCRAFT

 

 

Classes of Inputs

 

The classes of inputs required for various motion conditions are listed in "Motion Inputs", reference page 56. Below are listed the routines that invoke these motion conditions so that they may be accessed to determine the parameter specifics.  Except for hypersonic glide and space orbit. all of these motion conditions can be invoked at user discretion during runtime. All of the runtime commands except boost and digital intercept are invoked In the simulation by routine newroute. Digital intercept is invoked via the commandintercept routine and boost is invoked by the launchhgv routine, Boost motion is currently modeled only for the Initial phase of hypersonic glide vehicles' fly out. Hypersonic glide motion is automatically invoked at the end of boost phase for all hypersonic glide vehicles and can only be invoked this way. Finally, space orbit can be invoked only during presimulation. See the initspace and initorbit routines for an initialization of this motion condition.  During simulation the user can directly invoke the following commands through the objects motion menu (e.g. aircraft control menu):

1) Move to location;

4) Vector; and,

3) Orbit.

The engagement menu is used to invoke the following motion conditions:

 

1) Digital intercept (note: a target track or object must be identified);

2) HGV boost (note: scrambling these assets will NOT work).

 

Separate menu controls are provided on the blue mmi for:

 

1) ASW search; and,

2) Escort.

 

 

 

 

 

 

 

Object/utilities Processing

 

The object/utilities processing can be divided into the seven categories shown in "Object/Utility Processing", reference page 58. Briefly these are: Initialization - Reading in and sorting data from the INGRES database or a prepared checkpoint file during initialization. This processing is described in the initialization documentation. Object Maintenance· Maintaining the object and class structures and mapping these back to user-defined identifiers.   Associated Object Maintenance - Maintaining lists of associated objects as the simulation dynamics changes these lists (e.g. as aircraft land and are scrambled from a base).  Operational Task Maintenance/Implementation - Maintaining operational tasks (e.g. refueling or engagement instructions) for all assets and implementing these tasks as directed.  Remote Controller - Maintaining local copies of the objects common block at remote nodes (e.g. MMI nodes). 

 

1.) Motion Processing - Maintaining the position, fuel, and state of all mobile assets in various flight conditions. 

2.) Utilities - Perform all other utilities required to support the simulation.

 

This includes Math and scenario synchronization utilities.  Except for initialization (which is described in its own documentation section) these processing categories will be described in the above order.

 

 

 

OBJECT/UTILITY PROCESSING

 

- INITIALIZATION

- OBJECT MAINTENANCE

- ASSOCIATED OBJECTS

- OPERATIONAL TASKS

- REMOTE CONTROLLER

- MOTION

- UTILITIES

 

 

 

Object Maintenance Utilities

 

As specified by "Object Maintenance Utilities", reference page 61, there are three categories of object maintenance routines: 

1)    adding new classes of objects;

2)    adding new objects: and,

3) correlating the simulation identifiers to something the user can understand.

 

The third category is essential because, in order to allow flexibility, the simulation is data driven, This allows a vast array of different assets and asset types that may not even have been envisioned during the software development to be modeled by the JFORCES. The program does this by converting the type- and object- specific data about particular assets to be stored as attributes about common asset categories (e.g. flying, stationary, mobile ground, etc.). As data about a new class is read in, the simulation assigns the class a numeric equivalent and henceforth uses the user-input name only as a handle for reference. This is done so the simulation can access the data in a real-time mode. Thus the F- 15C class might be read in as platform type 39. This assignment is done in the routine newplatform. This number not only does not mean anything to the analyst, it is not predictable and might even change from run to run. When an object that is an F-15C and has tail number 6824 is to be read in, the platform number corresponding to F-15C (i.e. 39) is retrieved and stored with the object's data. This is done once during Initialization in the newobject routine to prevent repeated loops for the platform number during the run, thereby loading the simulation needlessly. The routine that does this (findplatform) is one of the correlation routines included in the third category. Likewise, if this F-15 is to be employed on a CAP, the getobjnum routine converts the user input class and tail number to the object number used by the simulation.  Thus, these correlation routines map user-input asset specifications to the simulation standard and help keep the programmer/developer workload reasonable and the code modular.

In addition to initializing the object and platform numbers, the newobject and newplatform routines initialize the object and platform data stored in the object and platformchar commons, respectively. In addition, they set up the related common block data pertinent to all subsystems and found in the subsystem common blocks. Finally, the newobject routine initializes the motion conditions for the first motion that the object is to invoke if it is initially in motion; otherwise the object is put in an idle (waiting) state until the route (if defined) is to begin.  Both the newobject and newplatform routines are used during initialization only and are not invoked if a checkpoint (or hotstart) file is employed for initialization. This is because both of these just initialize common blocks that are initialized by the contents of the hotstart file and invoking these routines is unnecessary in this case.

 

During Pre-simulation, the database stores the object deployment data with a different identification sequence than the simple object id used in the simulation. The database uses the sequence of scenario name, object class and tail number to identify unique elements. During initialization, these combinations are converted to a simple single identification number, the object id, for quick reference as a pointer into many tables. The object class or platform and groups have similar id's as well. Tables are built in order to cross reference the class and tail numbers to object ids, as well as platform and group ids. These functions of creating new objects and platforms, creating the cross reference tables, and the functions of using the cross reference tables form the set of object maintenance utilities. These crass reference utilities are used extensively during the initialization process to determine id's for objects,

 

 

 

 

 

 

 

During simulation, the status of objects can be changed through the use of another set of utilities. These object status utilities maintain the object status in the common blocks, as well as informing the remote node common blocks of changes. The simulation wartime status can also be changed at any time, and

remote nodes must be informed as well.

 

 

OBJECT STATUS UTILITIES

 

FUNCTION

ROUTINE

CHANGE OPERATIONAL STATUS

(CHANGEOPSTATUS)

INFORM MMI OF OPERATIONAL STATUS CHANGE

(MSGSTATUSCHANGE)

CHANGE STATUS TO KILL OBJECT

(KILL OBJECT)

INFORM MMI OF OBJECT DEATH

(MSGKILLOBJECT)

CHANGE WARTIME STATUS AND INFORMMMI

(CHANGEWARSTATUS)

 

 

 

Associations of objects made during pre-simulation scenario deployment determine the starting conditions of the scenario. These associations are maintained in linked lists established during initialization with the Object class, category, and tail number. These tail numbers must be converted to object ids after all lists have been established when all Objects have been initialized. The lists are established through the use of a set of basic utilities to maintain the lists, and are expanded to cross-reference the object ids from database Identification during the cold start initialization process. After initialization, the associated object lists are distributed to remote nodes. The set of routines that perform the basic list maintenance functions, as well as the cross reference and data dispersal routines form the set of associated object utilities.

 

 

 

 

ASSOCIATED OBJECT PROCESSING

 

UTILITIES

  -    PROVIDE SIMULATION UTILITIES TO MAINTAIN/REVIEW ASSOCIATED OBJECT LISTS

 

INITIALIZATION

-        BUILD LISTS USING UTILITIES DURING INITIALIZATION COLD 8T ART

-        CROSS REFERENCE TAIL NUMBERS AND CLASSES TO GET OBJECT IDS

-     POPULATE REMOTE NODES FROM ESTABLISHED LISTS

 

 

 

The associated object utilities are used by routines during the initialization cold start sequence and by routines requiring associated object list access during runtime. During the initialization process, the object lists are built for the individual objects of selected categories. These categories are listed in the chart, as well as the utilities used to accomplish the action. The cross-reference activity uses two routines, instantassoc, and instantassoclist to get object ids. The data dispersal activity uses a routine, msgassoclist, to synchronize the data with the MMI nodes with the routine, mmiassoclist, through the use of EXEC messages.

 

INITIALIZATION OF ASSOCIATED OBJECTS

 

SIMULATION INITIALIZATION INITSIM

 

BUILD OBJECT LISTS FOR SPECIFIC OBJECT CATEGORIES USING:

CROSS REFERENCE LISTS

 

SYNCHRONIZE DATA WITH REMOTE NODES

AIRBASE

 

(MSGASSOCUST)

BOMBERS · C2 SITES

PROCESS ALL DATA (INSTANTASSOC)

RECEIVE DATA AT BEM01E NODES

STATIC RADAR · SUBS

(PUSHASSOCOBJ)

PROCESS DATA FOR ALL OBJECTS IN A CATEGORY

(MMIASSOCLIST)

 

 

The set of basic list maintenance utilities includes adding objects to the list (pushassocobj), deleting objects from the list (deleteassocobj), and finding the existence of a particular object in the list (findassocobj).  Additional routines return the next item in the list when requested (returnassocobj), and returning the associated object list information for a given object in an array (reviewassocobj). The second routine used the first routine to retrieve the information.

 

 

 

 

 

Operational Task Processing

 

"Operational Task Processing", reference page 71, lists the categories of processing associated with operational tasks. Like associated objects' maintenance processes, operational tasks incorporate a set of utilities to maintain linked lists. In addition, routines are incorporated to perform the operational tasks listed below:

1)       Launch cruise missiles

2)       Refuel

3)       Reach commit point

4)       Begin/terminate jamming

5)       Land aircraft

6)       Rendezvous and escort

7) Return to orbit station

Finally, a routine is included to broadcast the operational task status to MMI nodes. These three categories of operational task processing are described in the following charts .

 

 

OPERATIONAL TASK PROCESSING

 

-        MAINTAIN/REVIEW OPERATIONAL TASKS AND TASK STATUS

 

-        ACTIVATE OPERATIONAL TASKS

 

-        REPORT COMPLETION OF TASK TO REMOTE NODES

 

 

Operational Task

 

These operational tasks, reference page 73, have several sets of basic utilities to maintain operational task lists based upon the complexity of the individual task. An operational task block contains five data items related to the operation or status of a task. Some tasks require additional information, such as engagement status, which requires twenty data items. The task can be composed of as many blocks as required, and is stored and retrieved as a unit if required. The basic utilities handle single section tasks, and the multiple section task utilities handle tasks up to ten sections in length. The general utilities can handle single or multiple section tasks.

 

 

Processing to Invoke Operational Tasks

 

The processing to invoke operational tasks within the objects/utilities module is diagrammed in "Operational Task Processing", reference page 75. These operational tasks are triggered by the completion of route legs by the asset that is to perform the task. Notice that soma operational tasks, such as engaging a track, are not invoked by the objects/utilities module and are NOT controlled by this structure.  In this example, the engagement task is invoked by the engagement module on a flexible time basis (see engagement module documentation).  For all operational tasks controlled by the objects/utilities module, the objectmotlon routine acts as the controller that identifies the end of a route leg. When the end of a leg is identified, the optaskcheck routine is called in order to determine whether any tasks should be invoked and then perform the necessary processing. The following chart, "Operational Task Routines" identifies the routines that simulate the execution of these tasks. Many of these tasks are outside of the objects/utilities module because they are mission specific. This chart identifies the module that incorporates these routines. The routine documentation may be found in the documentation for the designated module. All of the routines invoked by optaskcheck are invoked as a result of a message call via the exec, NOT by a direct routine call. See ICD documentation for message details.  In addition to performing tasks at the end of a leg, tasks may be performed at the end of the defined route. Landing an aircraft is an example of this (though landing can also be included in the middle of a route for staged threat attacks). The objectmotlon routine controls the invocation of these tasks by calling termtaskcheck. The tasks are processed in the same manner as when they are invoked by optaskcheck, but termtaskcheck is a streamlined version of the other routine.

 

 

 

 

Operational task performance is triggered by route legs.  Tasks are performed at the end of a leg, or at the last leg of a route.  Objects are moved by the routine objectmotion, which determines if the object has reached the end of a leg. Optaskcheck is called to determine if any tasks need to be activated and placed on the event stack. If the object has reached the end of the route and has operational tasks, termtaskcheck is called.

 

OPERATIONAL TASK ROUTINES

 

TASK

ROUTINE

MESSAGE

MODULE

- CRUISE MISSILE LAUNCH

LAUNCHCMS

MSGLAUNCHCMS

THREAT

- TANKER REFUEL

CMDREFUEL

MSGCMDREFUEL

OBJUTIL

- COMMIT POINT

COMMITPTCMD

MSGCOMMIT

THREAT

-GRAVITY BOMB DROP

BOMBDROP

MSGBOMBDROP

THREAT

- CRUISE MISSILE DETONATION

CMUP

MSGBOMBDROP

THREAT

-JAMMING

JAMMERCOMMAND

MSGJMMACMMND

THREAT

- LAND AIRCRAFT AT AIRBASE

lANDAIRCRAFT

MSGLANDAIRCRAFT

OBJUTIL

- RENDEVOUSFORESCORT

RENDEVOUS

(CALLED DIRECTLY)

OBJUTIL

- RETURN TO ORBIT STATION ABOVE AIRBASE

CMDAIRBASERECALL

MSGRECALLBASE

 

OBJUTIL

 

When an operational task or other activity has reached a milestone, a operation status message is sent to remote nodes informing the user of the current operation, These messages are sent through the exec to a receiver at the remote node which reports the message to a text window.

 

 

 

Remote nodes maintain copies of the common blocks with selected information received during initialization and runtime. These remote applications receive the data through the EXEC messages to support a remote node. These remote controllers have been developed to support current and future expansion of remote nodes. Currently, remote controllers are not being used to their full capabilities.  MMI has a separate remote controller, rcvr, which uses several of these routines, other object utilities, and many utilities developed just for the MMI controller that duplicate the actions of the remote controller.

 

 

 

Motion Options

 

This chart ("Motion Options"), reference page 83, provides a description of the motion options currently available in the JFORCES. For the most part this chart is self-explanatory.  The only comment on this chart is that there are a few options that cannot be invoked for certain categories. The user interface guards against most of these, but not all. An example of a limited motion option is found in the hypersonic glide vehicle (HGV). An HGV must be launched through boost and into a glide without human intervention in the flight process.  Thus the only motion legal for an HGV is launch, all others are provided only to allow white node override of HGV performance. If white node commands the HGV to do something else, the HGV will be removed from its nominal glide sequence. Thus, if the white node vectors the HGV, the HGV will not glide to earth as dictated by its flight dynamics.  The following chart lists the routines employed in each of these motions.

 

 

 

 

 

 

 

 

Objectmotion

 

The main controller for all object motion is the routine objectmotion. See "Object Motion Processing", reference page 85. Two status utilities are used which are common to all motion types: fuel and flight and turn limit. These will be described in the next chart. The pseudo code that describes each of these routines is appended to the design overview. Comments on each function are below:

 

1) Objectmotion is called on a periodic basis by the simulation executive. Currently the update rate is 12 seconds times the current simulation granularity. The basic structure of objectmotion is a loop through all objects. Within this loop it has a case structure based upon motion type. Except for escort, it immediately updates the fuel and position of all assets and checks to see if the current motion leg is over. if the current motion leg is over, it accesses the data on the next leg (if any) and sets up any required working variables for the next leg so that the object will begin moving in accordance with the new motion during the next update. Escort is treated differently because the escort's motion must be determined after the escortee's new position is determined. To do this, all escort updates are performed after the position updates of all other They better not even try to appeal because that's just fleecing the system (this ruling wouldn't be turned around in an appeal anyway).. Then, using a list of escorts and escortees created during the first loop, the position of all escorts is determined by routine escortmotion. The purpose of routine escortcompl is to determine, during the first loop through ail objects, whether the escort command has expired and the escort should perform another motion next update. The final process performed in objectmotion is the maintenance of all the location based linked lists for objects that support the makerangelist and makaselectrangelist utilities described in the simulation utilities section of this overview. Basically, these are linked lists of assets and their attributes for each latllong pair. The function of these lists is to provide a quick, rough list of all objects in vicinity to reduce range calculations when determining object interactions (e.g. sensor detections).

 

2) Move to a location - See named routine.

 

3) Vector - See named routine.

 

4) Maintain a racetrack - This is simply a cycle through a set of point destinations. Thus two legs would be stored for a simple back-and-forth racetrack and each leg would be identical except for the motion flag to a move to a location. The motion flag would indicate this leg is part of a racetrack instead of a move to a location". When one leg is complete, the next would be invoked, and when the last leg is completed ( if the racetrack end time is not exceeded) the nextleg routine will loop back through the legs to the first leg of the current racetrack series.  Thus, the racetrack routine forms a loop through a prescribed number of legs and ends this loop only when the time-on-station parameter has been satisfied. In every other way, however, this is the same as a move to location command and the grtcircle routine is used to update the position of both motion types.

 

5) Maintain a station - See named routine.

 

 

 

 

6) Maintain an orbit in space - This process 15 standard astrophysics using first order approximations (e,g. Earth is a sphere), See named routine,

 

7) Perform digital Intercept - This allows a 75% proportional navigation course based upon:

 

1) The last reported (or autonomously detected) track position if the interceptor is blue; or,

 

2) The actual target location if the interceptor is red. Thus, there is no need to update the target information for red interceptors but for blue interceptors it is critical that the track data be recent for reliable intercepts. This is done using the blue engagement menu during runtime. Because this is a man-intensive operation, this motion condition is not allowed to be predefined and can only be invoked during runtime.

 

8) Escort - Much of the processing procedure for this option was covered by the objectmotion description above. During escortmotion processing the escort attempts to fly to a point at the distance and direction from the escortee specified by the escort command. Because of the need to escort different types of vehicles (e.g. a TomCat escorting a carrier as part of the Outer Air Battle) no attempt is made to match speeds and altitudes. When there is a large speed differential, as in the example, the faster escort will flip-flop around the aimpoint in a attempt to maintain relative position. See this routine for more details.

 

9) ASW search pattern - See the Engagement Module for information.

 

10) Boost and Hyperglide - These two motion conditions are linked together because currently the only assets that have boost phase modeled are HGVs and the only legitimate manner of getting into a hypersonic glide is through boost. The boost profile is determined strictly by the user-input speed, altitude, and downrange distance charts for the booster subsystem type and the glide performance is determined by the wing loading and Iift/drag ratio of the vehicle. The direction of both the boost and the glide are determined by a 75% proportional navigation course relative to the track, so these motions have a lot of code in common with the interceptcourse routine. Note that the motion is only reasonable if a track is being prosecuted, so the only appropriate method of launching these is to use the launch HGV commands found in the blue engagement menu. The HGV will be terminated if the speed falls below 2000 ft/sec or the bearing angle to the target exceeds 60 degrees.

 

 

 

Two Motion Utilities

 

The two motion utilities are fuelandfllght and turnlimit. See chart on page 88 "Maintaining Basic Motion-Related Attributes" far a functional description of each. The function of fuelandflight is to determine the new altitude and speed for a one time-step update. This is based upon a desired altitude and speed, current altitude and speed, and platform performance. The fuel load is also decremented and, if the asset is airborne and runs out of fuel, to eliminate the asset. This function is used for all mobile assets EXCEPT hypersonic glide vehicles. Their flight performance is determined by user input tables during boost and flight characteristics during launch and they can never run out of fuel. Turnlimit limits turns based upon desired heading, current heading, current altitude and speed, and platform turn limits. Turnlimlt does not consider any out-of-plane maneuvers (e.g. split 5'5) to provide faster turns. This would have to be added if more fidelity is ever desired by the engagement routine. This routine is used for all assets, including HGVs.

 

 

Route

 

A route is a pre-defined series of motion legs that will be invoked in order during scenario execution. "Route Definition" describes the user interface and computer internal aspects of route definition. The motion options are described above. In addition to motion, however, the route can incorporate operational commands (or tasks), turn a series of waypoints into a mission. For example, a sensor can be instructed to go on station or a bomber told to drop a bomb at a specified position (target). The next two charts on pages 90 and 91 provide a description of the series of questions that need to be addressed to define a bomber's mission. The motion data is stored as a series of legs in the simulation. This is done by the addouteleg routine. As each leg is completed the objectmotion routine will retrieve data for the next leg using the nextleg routine. For motion conditions involving a great circle plane (e.g. move to a location or perform a race track) this plane is initialized by the newdest routine.  More data is provided in "Route/Motion Processing Options", reference page 92. The basic simulation motion and route functions are listed in this chart as well as the routines used to perform these functions. The pseudo code for these routines is attached to the end of the design overview.

 

 

 

 

 

Tanking Operational Task

 

The tanking operational task, reference page 94, is described in the Threat Module. See that module's documentation for the processing flow; in this section only the critical flight conditions to achieve tanking for different farces.  The tanking operation requires several different object motion and flight conditions to activate properly. These conditions are listed in '"Tanking Motion Requirements". Red and blue forces require different levels of control to achieve tanking. This is because the JFORCES is intended to model actual control of blue forces but in order to permit one workstation to control red forces human interaction for red control was minimized. If the specific conditions listed in the chart are not met the tanking operation will be broken off and must be rescheduled by the operator after the necessary motion and route conditions have been implemented.  As described in the threat tanking process documentation, the first activity performed is linkup, and this process is modeled by the routine cmdrefuel.  Afterwards routine tankerrendevous continues the tanking operation. The tanking operation takes place over an extended time as a result of:

1)    Delays in rendezvousing the tanker and the customer;

2)    Linkup delays; and

3)    The limited refueling rate of the tanker.

 

For these reasons, tankerrendevous repeats calls itself over time by stacking calls on the event stack. In this fashion tankerredevous periodically updates the relative states of the two participants. Tankerredevous will continue to stack these calls until either: "1) tanking is successfully completed; or 2) tanking is deemed impossible because one of the listed conditions is no longer met. The pseudo code for this routine documents the implementation of the tanking procedure. Because tankerrendevous is called for a unique tanker/customer pair, and because each call to this routine is separately maintained by the event stack, multiple separate commands involving a single tanker can be performed simultaneously, thus modeling the case of a tanker refueling a flight of aircraft. In this case, the aircraft are refueled on a first come, first served basis, and aircraft must await refueling until the tanker is done tanking the customer currently being refueled. The algorithm can not adapt to low fuel quantities in waiting aircraft either by partially refueling aircraft in order to service low-fuel aircraft sooner, or by re-queuing the aircraft in recognition of low fuel states.

 

 

TANKING MOTION REQUIREMENTS

FUNCTION

RED REQUIREMENT

BLUE REQUIREMENT

LINKUP OPERATION

REQUIREMENTS

 

* CUSTOMER IS ALIVE

* CUSTOMER SPEED AND ALTITUDE

MATCH SPEED AND ALTITUDE

ENVELOPE FOR TANKER

* CUSTOMER IS ALIVE

* CUSTOMER SPEED AND

ALTITUDE MATCH SPEED AND

ALTITUDE ENVELOPE FOR TANKER

MOTION CONDITIONS

REQUIRED FOR

TANKING

 

* TANKER IN ORBIT POSITION

* CUSTOMER IN ORBIT POSITION

* DISTANCE BETWEEN OBJECTS LESS

THAN OR EQUAL TO PLATFORM LINKUP

DISTANCE

 

* TANKER IN ORBIT POSITION OR

ESCORTING CUSTOMER

* CUSTOMER IN ORBIT POSITION OR FLYING

LESS THAN OR EQUAL TO PLATFORM

LINKUP DISTANCE

 

TANKING OPERATION

MOTION

REMAIN ON ORBIT STATION

CUSTOMER ON ORBIT STATION

REMAIN ON ORBIT STATION

CUSTOMER FLYING:

* TANKER LEAVES ORBIT STATION TO FLY

ESCORT DURING OPERATION

* TANKER RETURNS TO ORBIT STATION AT

COMPLETION OF OPERATION

 

 

 

Utility Categories

 

As outlined in "Utility Categories", reference page 96, there are three major categories of utilities in the JFORCES:

1)    those dealing with basic math functions;

2)    those used to support the software aspects of the simulation; and

3)    those non-math functions used to support other simulation aspects. 

The next three charts describe the routines used in each of these functional categories"

 

 

 

 

 

 

 

UTILITY CATEGORIES

1) MATH UTILITIES

    E.G. VECTOR FUNCTIONS

 

2) SCENARIO UTILITIES

    E.G. SCENARIO/SIMULATION TIMING SYNCHRONIZATION

 

3) SIMULATION UTILITIES

    E.G. CHECKPOINTING FUNCTIONS

 

 

 

Math Utilities

The basic math utilities identified in "Math Utilities", reference page 98, are described below

(for more detail, see the attached pseudo code):

Routine

Function

arccos

Compute arc Cosine. Unlike the machine version, this version does not blow up when round off errors result in looking up the arccos of 1.0000001 (the machine version is very annoying in this way.)

arcsin

Compute arc sine. Unlike the machine version, this version does not blow up when round off errors result in looking up the arcsin of 1.0000001 (the machine version is very annoying in this way.)

byteand

Performs a bitwise-and on two byte strings.

byteor

Performs a bitwise-or on two byte strings.

ceaz

Computes bearing from point one to point two using the curved earth range (instead of straight-line range) for the distance.

cerange

Computes curved-earth range between two points (assumes both points are on the Earth's surface).

cnvrhtall

Computes the lat/long coordinates of a point a given range and heading from another lat/long point.

cross

Computes the cross product of 2 3-0 vectors.

dot

Computes the dot product of 2 3-D vectors.

ecrll

Converts from Earth Centered Rotational (ECR) coordinates to latitude, longitude, and altitude.

ecrrange

Computes straight-line distance between two points in Earth Centered Rotational (ECR) coordinates. (includes the altitude difference in the calculation).

getratio

Exactly what the name implies. Stupid, but what can you say about some of this legacy.

heading

Determines bearing from first lat/long point to the second based upon conversion of points into Eel coordinates, Ignors Earth curvature.

lIecr

Converts from lat/long coordinates to Earth Centered Rotational (ECR) coordinates.

 

 

Ilrange

Computes range in Nautical Miles between two lat/long points.  WARNING: this range is a straight-line range and could go through the Earth.

 

 

lluecr

Converts from lat/long coordinates to unitized Earth Centered Rotational (ECR) coordinates.

 

 

mindist

Computes the minimum distance between a line and a point (e.g. between a nudet and a comm link). No longer used. Watch out- this puppy does not check for end of line segments.

 

 

mod2pi

Performs a 2*pi modulo on an angle.

truefalse

Converts "t" to true and "f" to false

vmag

Computes the vector magnitude of a 3-D vector.

vnorm

Returns the narmailized vector paralle! to the original 3-D vector.

 

Next Page

Prev Page