Next Page

 

4.6.7 OBJECTS I UTILITIES CSC

TABLE OF CONTENTS

 

page

Introduction

II

Objects I Utilities Mission

1

Module Requirements

3

Module Control

5

Interfaces

8

Object Dependency Structure

11

Layered Object Definition Approach

13

Layered Subsystem I Class I Object Structure

15

Class Pointer System

17

Class Characteristics Templates

20

Typical Performance Envelope

22

Typical Class Performance Profile

24

Typical Class Signature Profile

26

Class Signature Attributes

28

Object Data Structure

30

Object Attributes

33

Object Pointer System

41

Subsystem Categories

43

Subsystem Parameters and Pointers

45

Associated Objects

49

Operational Tasks

52

Motion Inputs

55

Object / Utility Processing

57

Object Maintenance Utilities

59

Object Status Utilities

62

Associated Object Processing

64

Operational Task Processing

70

Remote Controller

80

Motion Options

82

Object Motion Processing

84

Basic Motion-Related Attribute Maintenance

87

Route Definition & Processing

90

Tanking Operational Task

93

Utility Categories

95

Math Utilities

97

Scenario Utilities

99

Simulation Utilities

103

Functional Descriptions

106

 

Introduction to the Object/Utilities Module

 

This module contains the programming design and maintenance information for the

Objects functional module of the JFORCES simulation. The pages here represent

an approach, which has discussion of a topic, followed by a chart containing

additional information on the topic. The pseudo code for each routine is listed at the

end or embedded in the text sections as indicated.

 

 

Objects/Utilities

The objects/utilities CSC, reference page 2. forms the backbone of the JFORCES simulation. It performs the propagation and data maintenance for all simulated assets and provides a toolbox of commonly required routines. The primary advantages to this approach are: 1) reduced code; 2) increased modularity; and 3) enhanced consistency to many artificial intelligence (AI) applications. Code is both reduced and more reliable because once a common routine is written and verified, a similar routine will not need to be created for similar functions. Modularity is superior using this approach because all common functions (e.g. all motion routines) are isolated from mission implementation routines so that they can readily be identified and this aids maintenance. Also, all motion options are invoked in the simulation code by a single controller entry point, the object motion routine, again making maintenance a simpler process. Finally, this approach is consistent with many Al applications because most AI applications are object-oriented. Interfaces to AI applications should be simpler as a result of this approach because the data for all objects are stored on an abject basis. This makes it simpler to share object attributes with Al processes because the functional code will not need to be searched and stripped apart to retrieve data pertinent to the object.

 

As stated in the introduction, the JFORCES simulation structure is based upon an object-oriented data scheme. This has allowed single routines to perform the functions common to many classes of assets. For example, the routine to move from one point to another along a great circle path Is common to both blue fighters and red bombers - the functionality is based upon geometry and physics, not on the individual specifics. Still, the capabilities of each type of asset to perform this movement in the desired manner differently depending upon fuel range, flight envelope, and acceleration and climb capabilities to name only a few common limitations. While the values for these limitations change from asset class to asset class, the types of limitations do not. Therefore, the objects module propagates the various assets in accordance with the directed movement and the asset limitations using routines that check the specific asset limitations but are based upon a generalized methodology.

 

 

 

 

OBJECTS / UTILITIES CSC MISSION

 

MAINTAIN ALL OBJECT STATES

 

PROPAGATE OBJECTS

 

PROVIDE MATHEMATICAL AND DATA ACCESS UTILITIES

 

PROMOTE MODULARITY

 

PROMOTE CONSISTENCY WITH A.I. APPLICATIONS

 

MAINTAIN REMOTE COPIES OF OBJECT COMMONS

 

 

 

 

Objects/Utilities Module Requirements

 

As indicated by "Objects/Utilities Module Requirements", reference page 4, many of the object routines are related to object attribute storage and motion. In addition, many other object activities are addresses by the objects module. Many of these other activities are addressed by the operational tasking of objects. The operational tasks (i.e. mission directives) of the object are stored and maintained by the object module. The implementation of most tasks, being mission specific, are addressed by the functional module related to that aspect of the mission. For example, the engagement cycle is maintained as an operational task for the directed interceptor to engage an indicated track. The objects module is responsible for maintaining the data related to this and any other simultaneous engagement for this interceptor, initiating the engagement and updating the parameters as the status changes or new commands are received. The engagement module, however, is responsible for actually prosecuting the engagement. The engagement module does this using and occasionally updating the data stored for this task by the objects module. Thus, the objects module performs all the maintenance functions and the engagement module performs the actual intercept.

 

The data structure used for object description is based upon a hierarchy of primitives with the two most primitive elements of any object being: 1) the subsystem definition; and 2) the performance tables. These will be discussed in detail in later viewgraphs. The next level of definition is the class description. This definition includes pointers to the appropriate subsystem and table data. The final definition level is the object itself. This level points to the platform characteristics as well as the mission specifics (i.e. the route the object is to take and any mission directives). Again, this will be described in more detail in later charts.

 

 

 

 

OBJECT / UTILITIES MODULE REQUIREMENTS

SUPPORT COMMON FUNCTIONS AND DATA STRUCTURES

FUNCTIONS:

- MOTION (E.G. GREAT CIRCLE, VECTORING)

- FLIGHT ENVELOPE RESTRICTIONS / FUEL UTILIZATION CALCULATIONS

- MATH TOOL BOX (E.G. RANGE ON A CURVED SURFACE, DOT AND CROSS PRODUCTS) -

- OPERATIONAL TASK QUEUING

- ASSET ASSOCIATION (E.G. AIRCRAFT AT A BASE)

- LOGISTICS

- SUPPORT REMOTE APPLICATIONS

DATA STRUCTURES:

OBJECT CLASS DESCRIPTIONS

OBJECT 8T ATE VARIABLES

SUBSYSTEM DESCRIPTIONS

POINTERS TO:

- ASSOCIATED OBJECTS

- OPERATIONAL TASKS / STATUSES

- PERFORMANCE AND SIGNATURE TABLES

- PERFORMANCE MODIFIERS (E.G., ECM TABLES)

- SUBSYSTEMS

- ROUTES

 

 

 

Control Function

 

The control function for the objects module is divided into two parts: 1) initialization; and, 2) runtime. As outlined in the chart, reference page 6, description ("Object/Utilities Module Control'''). There are three levels of object definition. These are initialized in order during initialization. Thus the subsystem and performance table data is read in first. The platform definitions second, and the actual object definitions (including both deployment and employment) is read in third. This approach permits the simulation identifiers for each previous definition to be used as a pointer for the next level. Thus, is F-15C is declared the 39th platform during initialization, then when an F-15C deployed at Elmendorf is initialized, it can point to the 39th platform. This greatly reduces the overhead of object maintenance and performance evaluation during runtime.

 

All of the resulting subsystem, platform, and object specific data is stored in commons blocks loosely defined as the object database for use during the simulation. During runtime, the positions and states (e.g. fuel load) for each asset will be updated by the objects module. In addition, the object states are accessed by many of the functional modules. An example of this is the operation of the sensor detection process. In order to determine whether a sensor detects a target, the object states of both assets must be accessed. The object data accessed in this case includes the location, orientation, and status of both the sensor and the target. In addition, the sensor performance specifics and the signature tables on the target must be accessed. All of these accesses employ the data found in the objects common. Occasionally this data is screened from the functional module. For example, during an intercept the engagement module determines how much (if any) of the true object data is available to the engagement asset and the engagement asset uses this perception data for calculations of its attack profile. This filtering of the true data to achieve perception is accomplished in the functional module, not in the objects module.

 

Finally, the objects and utilities module includes a toolbox of utility routines (e.g. table look-up routines) that are available to all other modules.

 

 

 

 

 

Objects/Utilities Module Interfaces

 

As shown in the "Objects/Utilities Module Interfaces", reference page 9, the entire objects module resides on the central host, and all object updating is performed on this central host. Remote nodes (e.g. the mmi nodes) have partial copies of the objects commons to support their requirements, including status board support and icon placement. The functionality of the central versus remote copies of the objects/utilities module is presented in "Central vs. Remote Objects Functionality", reference page 10, the remote local copies are partial because of:

 

1) Perception limitations (e.g. the blue node is not posted on where red objects really are).

2) The remote nodes don't need all the information and sending it would bog down comm.

 

Whenever a new type of remote node is incorporated into the simulation (e.g. a decision is made to incorporate a remote tracker) it almost certainly will require partial or complete copies of both the objects and environment databases. The actual data requirements must be carefully considered to avoid overloading the LAN with irrelevant data or performing contradictory object operations on the remote and central nodes. The processing component of this design overview includes a section on the current remote node object control employed by the MMI nodes.

 

The following table defines the message interfaces between the objects module and the other modules. More details relating to the message fields are provided in the ICD documentation. Details about the routines and data involved in common block interfaces are provided in the common block documentation.

 

 

 

 

 

 

CENTRAL VS REMOTE OBJECTS FUNCTIONALITY

 

CENTRAL

WHITE/RED

MMI

BLUE

MMI

C2

OTHER

FUNCTIONS

* ALL OBJECTS FUNCTIONS

 

* REPORTING RESPONSIBILITY TO All REMOTE OBJECTS COPIES

PERFECT DATA OF

 

* ALL OBJECT POSITIONS

* All SENSOR ABILITIES

* TOP LEVEL PLATFORM CAPABILITY

* HAS ASSOCIATED OBJECTS

 

 

DOES NOT HAVE:

 

* OPERATIONAL TASKING

*PROPAGATION\ ROUTINES

* LOGISTICS CALCULATIONS

ONLY BLUE ASSETS:

 

*PERCEPTION (I.E. SENSOR REPORTS ON RED) PROVIDED BY APPROPRIATE FUNCTIONAL MODULE

 

LIKE BLUE ASSETS:

 

* HAS ACCESS TO PLATFORM DATA, PERFORMANCE, AND RULES DATA

 

TRACKER:

 

* HAS AIR SENSOR POSITION DATA

 

 

 

 

 

 

 

Object Dependency Structure

 

This chart ("Object Dependency Structure"), reference page 12, defines the three levels of object definition: 1) the subsystem; 2) the class; and 3) the object.

 

 

OBJECT DEPENDENCY STRUCTURE

CLASS - OBJECT TYPE DEFINITION INCLUDING PERFORMANCE CHARACTERISTICS (E.G. F-15)

 

OBJECT - OBJECT DEPLOYMENT/EMPLOYMENT AND WORKING DATA FOR AN ENTITY IN

SIMULATION (E.G. TAIL #6317)

 

SUBSYSTEM - FUNCTIONAL UNIT ON AN OBJECT (E.G. AVIONICS SUITE APG-63)

 

CLASS MAINTAINS UST OF SUBSYSTEMS ON AN OBJECT TYPE

 

OBJECT MAINTAINS OPERATIONAL STATUS ON EACH SUBSYSTEM

 

 

 

 

Layered Approach to Definition Primitives

 

The chart "Layered Approach to Definition Primitives..." reference page 14, points out that because the object definition is a hierarchical approach object attributes may be shared between different classes of assets. The object structure is a triple level hierarchy with only downward pointers (e.g. class data points to the subsystems onboard but subsystems do not point to the class of asset they are on). The organization based upon downward pointers permits two or more classes of asset to share data on the primitives. Thus, two platforms can each have the same sensor suite, or can share performance tables. This allows for rapid generation of new asset classes and rapid generation of platform defaults by pointing to the attributes of similar classes until specifics for the particular class may be obtained.

 

 

 

 

 

 

 

 

Layered Subsystem/Class/Object Structure

This chart ("Layered Subsystem/Class/Object Structure"), reference page 16, diagrams the three levels of object definition hierarchy, As described in the previous chart" the class points to the subsystems on-board that class and the performance and signature tables defining the class. The object then points to the class data and thus indirectly at the subsystem and table data. Finally, the mission specifics for each object are pointed to by the object itself. These mission parameters are stored separately from the object definition in linked lists in order to increase mission definition flexibility by avoiding limiting mission tasks or routes for Individual objects. Thus some objects can have very complex missions without requiring large mission storage areas for all objects. This avoids the massive overhead associated with a larger objects data storage area, due to RAM limitations it would be impossible to define even moderately detailed missions for objects on the current workstations without this approach.

 

 

Class Pointer System

 

The chart ("Class Pointer System"), reference page 18, lists the performance and signature tables pointed to by the class definition. All classes point to all of these tables, though not ail tables are appropriate 10r all classes. For example, the performance tables are superfluous to fixed site classes. When a table is not specified but the table is required (e.g. the RCS table for an aircraft) the simulation will provide a default. Current defaults are:

 

Performance envelope - no limits

Acceleration - infinite

Deceleration - infinite

Climb - infinite

Dive - infinite

Fuel utilization - zero (0.)

RCS - 10 meters^2

IR - 10 Watts/sterradian

Sonic signature - 10 dBs

Emissions - 10 watts

 

The concept driving the selection of defaults for performance was to allow the analyst to quickly generate a vehicle capable of doing whatever was envisioned for a new concept

 

The following chart ("Class Performance Representation"), reference page 19, details the first six tables covered by the class definition. These six tables constitute the performance definition for the class.

 

 

 

 

 

 

CLASS PERFORMANCE REPRESENTATION

PRESENT REPRESENTATION FOR ALL MOBILE CLASSES INCLUDES:

 

- PERFORMANCE ENVELOPE (SPEED AND ALTITUDE RESTRICTIONS)

 

- ACCELERATION/ DECELERATION PROFILES

 

- DIVE I CLIMB RATES

 

- FUEL UTILIZATION RATES

 

THE LAST THREE PERFORMANCE ATTRIBUTES ARE DEFINED WITHIN THE

PERFORMANCE ENVELOPE AND MAY BE DEFINED BY THE USER AS EITHER:

 

1) FUNCTIONS OF ALTITUDE (DEPTH) AND SPEED~ OR

 

2) CONSTANTS, OR

 

3) THE PROGRAM WILL PROVIDE THE FOLLOWING DEFAULTS:

 

- INSTANTANEOUS CLIMB, DIVE, ACCELERATION, AND DECELERATION

- NO FUEL USAGE

 

THIS ALLOWS THE USER TO DEFINE THE SYSTEM ACCORDING TO HIS GRANULARITY NEEDS

 

 

 

Class Characteristics Templates

 

This chart ("Class Characteristics Templates"), reference page 21, provides an additional way of looking at the class definition. Any class may incorporate up to 20 unique subsystems. This count does not include multiple armament or jamming subsystems of the same type. Thus an F-16 with 6 Sidewinders and a gun with 10 salvos would be counted as having only two armament subsystems- the Sidewinder and MM61, with counts of 6 and 10 respectively. The number of salvos is used for the count, thus if it is desired that the Sidewinders should be launched in pairs the number of salvos should be decreased to three and the probability of kill per salvo should be modified appropriately in the armament subsystem definition. This allows up to 18 additional different subsystem types to be included in the definition of this class.

 

 

Typical Performance Envelope

 

This chart ("Typical Performance Envelope"), reference page 23, illustrates a typical performance envelope. The analyst should include the minimum and maximum speed at altitudes (or depths) that he selects. JFORCES will perform a linear interpolation between user-defined points. The lowest attitude defined will be used as the minimum altitude the asset can fly at and the highest altitude will be the service ceiling. Thus, if the lowest altitude for which the min and max speeds are defined for the F-15C by the analyst is 500 feat, the F-15C will not be able to descend to 100 feet during the simulation execution (though these limits are ignored for landing). To define a mobile ground asset, include only one altitude definition at 0 feet. For submarines, the altitude should be set at negative numbers (or 0.).

 

 

 

 

 

Typical Class Performance Profile

 

The "Typical Class Performance Profile" chart presents the variables and level of detail available in the performance tables. Except for the flight envelope table, all of these tables are functions of:

 

1) Current speed; and

2) Current altitude.

 

The independent values depend upon the table.

They are climb and dive tables: ft/sec

Acceleration/deceleration tables: ft/(sec*sec)

Fuel utilization table: Ib/sec

 

As with the performance tables, the granularity is user-definable and need not be constant throughout the entire flight envelope. But every defined speed/altitude combination must be defined or it will default to zero, leading to unexpected and only moderately amusing consequences. The table function used in JFORCES does not extrapolate, but instead uses the last defined point. One advantage of eliminating extrapolation in this simulation is that if a constant value is desired (e.g. the fuel rate is always 1 lb/sec), the performance at only one point in the flight envelope needs to be defined. This value will be used for ail flight conditions since it will always be the closest defined point to any flight condition that will occur during the simulation. As with the signature tables, this table function WILL interpolate between any four defined performance values.

 

 

 

 

Typical Class Signature Profile

 

The "Typical Class Signature Profile", reference page 27, chart provides a description of the tabular representation of an asset's signature profile. In this case a "typical" RCS profile Is displayed. The RCS is a table lookup based upon angle from bore sight and frequency of the search radar. The table look-up routine works with arbitrary granularity so the RCS may be defined in any granularity the analyst desires and need not be a constant granularity for the entire table. Thus, the analyst could use a table defining the RCS near the nose of a projected threat in .1-degree increments and 10-degree increments near the beam, and 5-degree increments near the tail. The only requirement is that all angle/frequency grid points specified by the analyst be defined. Thus, if the analyst defines the RCS at 10 degrees and 1 GHz and at 12.7 degrees and 1.6 GHz, the RCS values at both 10 degrees, 1.6 GHz and 12.7 degrees, 1 GHz must also be defined. If not, these values will default to 10, and this may not be representative of the modeled system.

 

 

 

Final Four Tables

 

The final four tables in the class definition relate to the signature. The parameters used are included here ("Class Signature Attributes"), reference page 29. The visual detection and identification ranges are also included here due to functional similarity, but the data is a scalar number instead of a table. These visual ranges are modified by day/night criteria and local weather to determine the actual success of an attempted sighting. The signature data is used by the sensor routines in the sensor module and the avionics and visual routines found in the engagement module.

 

 

 

 

 

 

Object Data Structure

 

"Object Data Structure", reference page 31, introduces the data structure related to an individual object. This structure consists of three components:

 

1) Header - This includes any general object data.

2) Mobile/Static storage - This contains data related strictly to either mobile or static objects.

 

The "Header Attributes for Objects", reference page 32, chart lists the attributes stored for all objects in the objects header. More information can be found in the objects.cmn common file.

 

 

 

 

HEADER ATTRIBUTES FOR OBJECTS

 

CATEGORY

CALL SIGN / UNIQUE NAME

CLASS TYPE

GROUP IDENTIFICATION

MEDIUM OF OPERATION

FORWARD TELL:

ADOC, ROCC, SOCC, SUBSOCC ELEMENTS

ID

RECOVERY BASE

RED, BLUE, OR NEUTRAL FLAG

BASE OF ORIGIN

STATIC VS MOBILE FLAG

CURRENT STATE VECTOR

FORCE FLAG

LAST UPDATE TIME

STATUS FLAG

OPERATIONAL PARAMETERS FOR

OPERATION CAPABILITY

OBJECT SUBSYSTEMS:

AVAILABILITY

OPERATIONAL STATUS

CURRENT NUMBER ONBOARD

OPERATIONAL TIME

COMMUNICATIONS LINKED LIST

OPERATIONAL STATUS ASSOCIATED

MAXIMUM OBJECT OUTPUT

OBJECT LIST OPERATIONAL TASK / STATUS LIST

PROBABILITY OF CORRECT MESSAGE RECEPTION

COMMUNICAT1ONS THROUGHPUT

NUMBER OF SUPPORTED CLASS IDS FOR AIRBASE

 

 

 

Pertinent Attributes Related

 

The next two charts ("Pertinent Attributes Related to,..."), reference pages 34 and 35, list the data attributes pertinent only to: 1) static objects; and, 2) mobile objects, respectively. JFORCES accomplishes this by using a memory template equivalency the fields in this area to two sets of variables, It is important that only the set pertinent to the specific type of object is employed. Thus, only the variables valid for static objects should be accessed for a static Object and only those valid for mobile objects should be accessed for a mobile object. This is because, since both sets of variables take the same positions in memory, the values would be meaningless. The static flag in the object header, however, informs the programmer which set of variables to use. This makes this a viable system. The reason that memory overlays are used is that the reduced memory requirement permits more objects to be simulated and reduces swapping in cache, thus increasing processing throughput to real-time requirements.

 

 

 

 

PERTINENT ATTRIBUTES RELATED TO OBJECT CATEGORIES

FOR STATIC OBJECTS

 

 

       TIME FAILURE REPORTED

       NEXT SITE FAILURE TIME

       POINTER TO TERRAIN TABLE

       MAXIMUM VIEWING AZIMUTH

       MINIMUM VIEWING AZIMUTH

       LAST TIME OBJECT STATUS UPDATED

       BASE FLUSHED FLAG

 

 

 

 

PERTINENT ATTRIBUTES RELATED TO MOBILE OBJECT CATEGORIES

FOR OBJECTS FLYING GREAT CIRCLE ROUTES

 

ADDITIONAL PARAMETERS FOR GREAT CIRCLE ROUTE

 

ANGULAR DELTA BETWEEN LOCATION AND DESTINATION

 

ANGULAR MOTION IN LAST TIME STEP

 

UNIT VECTOR IN DIRECTION OF EARTH CENTERED ROTAT10NAl

COORDINATES OF LEG DESTINATION

 

UNIT VECTOR 90 DEGREES FROM OTHER UNIT VECTOR

 

EAST I WEST DESTINATION FLAG

 

 

 

Pertinent Attributes Related to Mobile Object

 

This chart ("Pertinent Attributes Related to Mobile Object..."), reference page 37, gives a listing of the parameters used in the flight parameters array of the mobile object data area. The purpose of the chart is to provide a concrete example of the sort of data stored in this area. If there are any questions about an object's motion, it is suggested that the contents of the flight parameters array be evaluated. This array is yet another memory overlay area and the field contents and formats stored in this array for each motion condition are documented in the objects.cmn common block.

 

 

 

PERTINENT ATTRIBUTES RELATED TO OBJECT CATEGORIES

FOR MOBILE OBJECTS

 

       SPEED

       HEADING

       INTENDED ALTITUDE

       INTENDED SPEED

       MOTION TYPE

       FUEL LOAD

       ROUTE POINTER

       LEG POINTER

       HOME BASE

       RECOVERY BASE

       TRANSPONDER LOCATION IN SUBSYSTEM

       PRIMARY COMMUNICATIONS LOCATION IN SUBSYSTEM

       GUIDANCE LOCATION IN SUBSYSTEM

       ESCORT FLAG

 

 

Pertinent Attributes Related to Fixed Ground Site Categories

 

The next two charts ("Pertinent Attributes Related to Fixed Ground Site Categories" and "Pertinent Attributes Related to Bombers "), reference pages 39 and 40, provide composite lists of the parameters stored for typical mobile and static objects. The previous charts actually addressed all of these parameters, these charts are provided only to give examples of how all of these elements can come together to completely define a particular object's current state.

 

 

 

 

 

 

 

 

Object Pointer System

 

This chart ("Object Pointer System"), reference page 42, lists all of the pointers from the

objects block to other storage areas. The following commons are used:

 

 

Data Description

Common

Structure type

Object Definition

objects.cmn

Sequential

Platform Type

platformchar.cmn

Sequential

Operational params, for subsystems

objects.cmn

Sequential

Associated objects

assocobj.cmn

Linked list

Operational tasks

opertask.cmn

Linked list

Route

routedata.cmn

Linked list

Terrain table

terrain.emn

Sequential

 

 

The objects common points into each of these structures based upon the index scheme used by the particular data structure. For example, if the object is an F-15C and this is the 39th defined platform class, the pointer will equal 39. Alternately, if a new associated object is added to a list (e.g. an aircraft lands at a base) then the pointer value will be based upon the available space in the linked list, but the linked list structure will partition the data on associated objects relative to this base from associated Object data for other objects.

 

 

 

 

 

Object Subsystem Categories

 

This chart ("Object Subsystem Categories"), reference page 44, lists all of the subsystems currently defined and employed in the JFORCES. The parameters used to define these subsystems are found in the headers for the appropriate common blocks. The common block names are based upon the subsystem type. For example, the armament.cmn contains the data on the armament subsystem and a description of the parameters defining this type of subsystem will be found in the header to this common block. In addition, these common blocks are defined in the most closely related functional module design overview. For example, the design overview description of the armament common is found in the engagement module.

 

 

OBJECT SUBSYSTEM CATEGORIES

 

 

ARMAMENTS

BOOSTERS COMMUNICATIONS

JAMMERS COMMUNICATIONS

SUITES

FIRE CONTROL RADAR (AVIONICS)

GUIDANCE

IFFN

SENSORS

SENSOR JAMMERS

TANKERS

TRANSPONDERS

WARHEADS

 

 

 

Object Subsystem Parameters Identified with Objects and Classes

 

As shown in "Object Subsystem Parameters Identified with Objects and Classes", reference page 46, certain data items related to object subsystems are located with the object definition instead of the class description. This is because some of the data about the subsystem is naturally object dependant. For example, while the class definition might state that the F-15C can carry 4 Sidewinders, the object data for an individual F-15 would need to be consulted to determine whether that particular aircraft is currently carrying 4 Sidewinders. Likewise, the Sidewinders might be non-operational because EMP destroyed them. The object data relative to this subsystem can provide this data. In addition, just because a platform has a subsystem does not mean that the subsystem is currently turned on. The on/off data is also stored in the object data block. See the objssystems array in the objects.cmn for the actual structure employed to do this and how it interfaces with the class subsystem data found in the system array of the platformchar.cmn common. Note that the indices for both of these arrays are common. Therefore, by using the same indices both the object and platform subsystem characteristics are immediately available to the programmer after the object and platform-working area is loaded.

 

 

 

OBJECT SUBSYSTEM PARAMETERS IDENTIFIED

WITH OBJECTS AND CLASSES

 

CLASS: OBJECT:

SUBSYSTEM DEFINITION PARAMETERS SUBSYSTEM OPERATIONAL PARAMETERS

 

NUMBER OF SUBSYSTEMS AVAILABILITY

 

POINTERS TO SUBSYSTEMS: OPERATIONAL STATUS

 

CATEGORY POINTER TO ADDITIONAL PARAMETERS

 

SUBSYSTEM TYPE WITHIN CATEGORY

 

INITIAL NUMBER ONBOARD

 

 

 

 

Subsystems Related to Objects and Classes via Pointers

 

This chart ("Subsystems are Related to Objects and Classes via Pointers"), reference page 48, illustrates the pointers from the object and platform data through to the subsystem performance data and the pointer from the object definition to additional storage space. The structure pointing through the object and platform structures has already been discussed. The new element in this chart is the' additional storage space for object-based subsystem data. This data includes additional subsystem specifications required only for a few subsystems and therefore it is more efficient to put these in a linked list than it is to provide more space for them in the subsystem area for all objects (the latter approach would waste space and increase data access time). The only current use for this area is storing the current azimuthal restrictions in sensor search patterns. For example, if it is known that an advanced airborne sensor concept has two radars, one pointing right and one left, and that each radar has a coverage of 120 degrees, the data on the coverage for each of these two radars is stored in this extra subsystem data. The object data area of the aircraft points to this area and this data would be updated as the aircraft moves. The information is contained in the sssiopdata linked list array of the objects common block. A generalized approach was taken to enhance JFORCES flexibility in the future.

 

 

 

Next Page