FORCES Sim - Maps Communications Notes

Purpose:

This document addresses the interprocess communications that occur between the JFORCES simulation and the various applications that together comprise the standard JFORCES graphical interface. The primary applications within the JFORCES graphical interface include a Map display, a menu system, and a background communications process that handles queuing and saving messages between the human interface and other JFORCES processes

This document will be divided into the following components:

  1. Approach
  2. Identification of graphical objects and operations
  3. Message ICDs
  4. New Message Structure Definition
  5. Mapping from current messages to new structures
  6. Tranport details

Approach:

This document describes the new approach to communications from the simulation and/or the menus to the map process. The process architecture currently used to maintain a current situational representation during runtime for the user from the simulation is shown below:

The separate grey boxes for the simulation and the MMI indicate that the simulation and the MMI can be run on separate machines. All communications between the simulation and the MMI pass through the receiver (rcvr) process. This is to provide communications buffering and prevent user lock-outs when there is a high message flow. We have experimented with removing this process and allowing the menus to maintain communications, but this has resulted in poor user interface performance. So we expect to maintain this process in the foreseeable future.

The Function of these processes are:

Sim - This is the master of the runtime. It models and maintains a situational representation of all players. It generates all constructive elements and maintains communications with all external live feeds to provide seamless integration of live exercise elements with simulated elements. For the purposes of this write-up it is easiest to think of the simulation as a single monolithic host, although in reality it might be distributed across multiple machines. The MMI need not concern itself with this possible process distribution; the executive will route messages appropriately.

Rcvr - This is intended to be a very simple communications process that acts as a message buffer between the user interface functions and the Simulation. This process is employed to provide better interface response for the user. Theoretically, there should be no user interface to this function, but the reality is that currently the status boards used to list Command and Control Sites and Airbase States are actually interfaces from this function. At some future time (not under this IR&D) these functions should be moved to the menu process to streamline the rcvr.

Menus - JFORCES-specific controls are incorporated under this process. This process provides the user with all non-map related widget interfaces control and montor this simulation.

Maps - Provides a graphical situational representation of a scenario. The intent of this new version of the Maps is to make the map process as generic as possible. The map controls will be embedded in this process so that the user will specify viewpoints and zoom from within this process without the information being sent to other processes. The information to be displayed on the screen will come in through a strictly limited set of messages which will be interpreted by the graphics process in terms of graphical objects. The maps will be responsible for filtering the display of these items in accordance with user specifications on attributes for each class. E.G. he user will have the capability to specify whether specific classes of objects (e.g. coverage volumes for specific sensor classes) will be displayed.

The information that is sent between the various processes can be categorized as:

 

 

Source / Destination

Sim

Rcvr

Maps

Menus

sim

NA

Situational Representation

NONE

NONE

rcvr

 

NA

Situational

Representation

Situational

representation

maps

NONE

NONE

NA

 

menus

NONE

Commands to Sim

  1. Graphics view changes
  2. Requests for Picks

NA

Details:

Sim to Rcvr - (Detailed Message List) All situational representation information appropriate for the user pass through this channel. The simulation is responsible for maintaining gaming security. This means that the simulation is responsible for sending ground truth on blue assets only to blue and white nodes, not to red players. Likewise for the red side. From a design standpoint this means that the MMI does not need to concern itself with filtering out information based upon sides - though at times this capablity will be employed by specific players, e.g. when the white node wants to view blue perception. So the capability to filter must be made available in the MMI, but need not be strictly enforced.

The situational representation passed from the simulation to the MMI includes:

  1. States of all assets reporting to this node type (eg Blue assets for a blue player). This includes position, health, and subsystem operations and counts
  2. All asset associations for these assets. This includes lists of assets in an organization (eg elements of a Brigade), aricraft at an airbase, organized flights, combinations for tanking
  3. Required operational task information. This includes specifics on detailed sensor tasking. More data can be made available as user needs occur.
  4. Definitions. This includes platform specifics (will soon include icons associated with specific platform classes), group definitions, targets specifications and subsystem (including sensor) specifications
  5. Sensor, intel and reconnaissance reports.

Rcvr to Maps - (Detailed Current Message List) (Detailed Future Message Lists) - The graphical components of the situation as reported by the simulation to the MMI are passed from the rcvr to the maps. This includes:

Asset and group location, heading and speed

Required Definitions (e.g. icons associated with various display objects)

target specifics

Sensor, intel and reconnaissance report locations and Ids. Currently report specifics are transfered to the Menus and displayed from this process.

Rcvr-to-Menus - (Detailed Message List) Basically all information passed by the simulation to the rcvr is forwarded to the menus. In this case it's easier to list the information not sent to the menus:

  1. raw radar data
  2. Bombing flashes
  3. any graphics-specific messages. This includes the following submessages:

Menus-to-Rcvr - (Detailed Message List) This incorporates all commands from this user to the simulation. Examples include:

Umpire messages including start, pause, change time ratios and perform checkpoints

Engagment commands

Requests for status updates (e.g. fuel checks)

Sensor controls including specific tasking and heightfinder requests

Manuever controls (go to point, building routes)

Detailed Asset commands (e.g. turn on/off specific subsystems)

Menus-to-Maps - (Detailed Current Message List) (Detailed Future Message List) -

Identification of Graphical Objects and Operations

To date the following graphical objects have been used by JFORCES and are shared by the map displays and rest of the JFORCES environment (note that no attempt will be made to identify objects wholely contained by the graphics process, e.g. world globes):

Object

Use:

Bitmap (AKA icon)

Logically all assets, groups, targets and so on. In reality most of these have been line drawings in the current Phigs implementation. This was done to reduce drawing time. This implementation will need to be reviewed with the realization that it will be difficult (possibly impossible) to permit the user to dynamically add new icons to the current list without adding code. A new system that actually uses bitmaps for assets and groups is implemented in the mission planner. In this system the user defines icons in a bitmap editor and then associatiates them with th e platform type or group type. To see how this is done enter the JFORCES environment and enter "system controls"->DBA->Edit Icons. While flexible, the results have been disappointing because many of the object attributes incorporated in the message have not been implemented (see msggraphicselement) and icon layering has been poor.

polylines

Used for communications information, sensor detections, data-driven overlays (user defined roads, rivers, exercise boundaries, etc).

Circles (This object should be ellipses, but currently only circles are implemented).

Should be used to display sensor coverages - actually polylines are generally used to suppoer varied map projections. Also used (at least logically) for display of sensor tasking, SAM coverages, and certain sensor "detections" (e.g. submarine localizations).

polygons

This has never been inplemented as a dynamically shared object betwen the maps and other processes. The initial intent is to provide the user with the ability to indicate regions of interest (e.g. exercise ares or foliage regions)

Fans

This is the representation of an area defined by a minimum and maximum distance from a point and lef and right limits (note the angular limits can not be min and max because of angular wrapping). This is most commonly used to display sensor coverages.

text

Group names, flight call signs, etc.

Note that this is a list of two dimensional objects. This is because JFORCES has only had two dimensional map capabilites to date. The expectation is that we will start to use three dimensional objects once available. But we must not allow the addition of new 3D objects to delay our reimplementation of the existing 2D objects. 3D objects might be nice but the success of this IR&D hinges on our ability to resurrect our current 2D capabilities on new platforms.

The following graphical operations are required to have public interfaces - that is a capability for the other processes (e.g. the rcvr and menu processes) to update:

  1. Adding/deleting/modifying any of the above graphical elements. This means whether they are stored by the maps NOT whether they are displayed. See the list of internal map operations, below.
  2. The ability to provide information on user map selections. This must include the ability to provide:

In addition the following graphical operations need to be addressed internally by the graphics process:

Panning

Remember that this list is still draft - we need to verify that no functionality in the current maps displays (during runtime, mission planning, or in platter mode) is lost.

 

Message ICDs

All of the messages maintained by the executive are documented on line. To view them :

  1. Enter the JFORCES environment (start)
  2. Go to System Controls -> Debug Options -> Review JFORCES ICDs
  3. Enter search criteria , or just enter "Go" for a complete list of messages
  4. Double click on the message name to review structure

MMI -Related Messages (DRAFT - TAKE THIS AS A WARNING!)

Message

sim

->

rcvr

rcvr

->

sim

rcvr

->

menus

rcvr

->

maps

menus->

rcvr

menus

->

maps

maps

->

menus

Controlled By Exec

msg_add_asset

 

x

   

x

   

x

msg_master_time

(1)

 

(1)

(1)

     

x

msg_reg_external_app

(1)

(1)

(1)

(1)

(1)

(1)

(1)

x

msg_reg_external_msg

(1)

(1)

(1)

(1)

(1)

(1)

(1)

x

msg_save_da_file

x

     

x

   

x

msgacland

x

 

x

       

x

msgadjcovcmnd

 

x

   

x

   

x

msgairbaseinit

x

 

x

       

x

msgalertsta

x

x

x

 

x

   

x

msgartillerymission

 

x

   

x

   

x

msgassetho

 

x

   

x

   

x

msgassetinit

x

 

x

x

     

x

msgassetloc

x

 

x

x

     

x

msgassobjchng

x

 

x

       

x

msgassocobjs

x

 

x

       

x

msgaswdetect

x

 

x

x

     

x

msgaswellipse

x

   

x

     

x

msgaswsearch

x

   

x

     

x

msgauroralcap

x

   

x

     

x

msgavlwpn

x

   

x

     

x

msgbadroutedefn

x

           

x

msgbeir2dtracks

x

   

x

     

x

msgbeirdetection

x

   

x

     

x

msgbeirtrackrpt

x

   

x

     

x

msgbiochem

x

   

x

     

x

msgc2change

 

x

   

x

   

x

msgc2control

 

x

   

x

   

x

msgc2operate

             

x

msgchangestatus

x

x

x

 

x

   

x

msgcheckpoint

x

x

x

 

x

   

x

msgchemeffects

 

x

   

x

   

x

msgchngalt

 

x

   

x

   

x

msgchngephem

 

x

   

x

   

x

msgchngspeed

 

x

   

x

   

x

Message

sim

->

rcvr

rcvr

->

sim

rcvr

->

menus

rcvr

->

maps

menus->

rcvr

menus

->

maps

maps

->

menus

Controlled By Exec

msgclassbycomm

             

x

msgcmdrefuel

 

x

   

x

   

x

msgcommand

x

x

x

 

x

   

x

msgcommbandstatus

x

 

x

       

x

msgcommlinkdefn

             

x

msgcommlnkinit

x

 

x

       

x

msgcommlnkupd

x

 

x

       

x

msgcommroot

x

 

x

       

x

msgconveffects

x

   

x

     

x

msgdeassintercept

 

x

   

x

   

x

msgdeleteflight

x

x

x

 

x

   

x

msgdeletetrack

 

x

   

x

   

x

msgendinit

x

 

x

x

     

x

msgengagearea

x

 

x

x

     

x

msgengasset

x

 

x

       

x

msgengvsgroups

x

 

x

       

x

msgephemerids

x

 

x

       

x

msgesmbearing

x

   

x

     

x

msgexterntrack

x

   

x

     

x

msgfaacheck

 

x

   

x

   

x

msgfaaconfirm

x

   

x

     

x

msgfastfrwd

x

x

x

 

x

   

x

msgformation

 

x

   

x

   

x

msgfreebeacon

x

   

x

     

x

msgfreeecm

x

   

x

     

x

msgfreesearch

x

   

x

     

x

msgfreetrack

x

   

x

     

x

msgfuelrqst

x

x

x

 

x

   

x

msggraphics

         

x

x

x

msggraphicsalert

x

     

x

   

x

msggraphicselement

x

   

x

   

x

x

msggrndengage

 

x

   

x

   

x

msggrndsnsr

x

 

x

x

     

x

msggroupass

x

 

x

x

     

x

msggroupdeath

x

 

x

x

     

x

msggroupinit

x

 

x

x

     

x

msggrouploc

x

 

x

x

     

x

msgheightreport

x

 

x

       

x

msgheightrqst

 

x

   

x

   

x

Message

sim

->

rcvr

rcvr

->

sim

rcvr

->

menus

rcvr

->

maps

menus->

rcvr

menus

->

maps

maps

->

menus

Controlled By Exec

msghgvlaunch

 

x

   

x

   

x

msgintassignments

x

 

x

       

x

msgintcourse

 

x

   

x

   

x

msgintel

x

 

x

       

x

msgintercept

 

x

   

x

   

x

msgjettison

 

x

   

x

   

x

msgjmmrcmmnd

 

x

   

x

   

x

msgjssbeacon

x

   

x

     

x

msgjsssearch

x

   

x

     

x

msgjssstrobe

x

   

x

     

x

msgkillgroup

 

x

   

x

   

x

msgkillobj

 

x

   

x

   

x

msgkillreport

x

 

x

x

     

x

msgkilltgt

 

x

   

x

   

x

msglandaircraft

 

x

   

x

   

x

msgminefield

x

x

x

x

x

   

x

msgmmiacrft

 

x

   

x

   

x

msgmmidrop

 

x

   

x

   

x

msgmmigasp

 

x

   

x

   

x

msgmmiland

 

x

   

x

   

x

msgmmitarg

 

x

   

x

   

x

msgmmitrack

 

x

   

x

   

x

msgmodbeacon

 

x

   

x

   

x

msgmodsensorcov

 

x

   

x

   

x

msgmodsnsrrpt

 

x

   

x

   

x

msgmufreport

x

   

x

     

x

msgnewengstatus

x

 

x

       

x

msgnewflight

 

x

   

x

   

x

msgnewgraphicsclass

x

   

x

 

x

 

x

msgnewroute

 

x

   

x

   

x

msgnewwx

 

x

   

x

   

x

msgnobullets

x

 

x

       

x

msgnogo

x

 

x

       

x

msgnooper

 

x

   

x

   

x

msgnotifychngop

x

 

x

       

x

msgnudet

x

   

x

     

x

Message

sim

->

rcvr

rcvr

->

sim

rcvr

->

menus

rcvr

->

maps

menus->

rcvr

menus

->

maps

maps

->

menus

Controlled By Exec

msgobjsschange

x

 

x

       

x

msgobjstatusup

x

 

x

       

x

msgothbar

x

   

x

     

x

msgothbrcon

x

 

x

       

x

msgothecm

x

   

x

     

x

msgothtrack

x

   

x

     

x

msgpartscen

 

x

   

x

   

x

msgpause

 

x

   

x

   

x

msgpid

       

x

x

 

x

msgplatforminit

x

 

x

x

     

x

msgpostmmi

x

 

x

       

x

msgprgsnap

 

x

   

x

   

x

msgratio

x

x

x

 

x

   

x

msgrelaymmiinfo

x

 

x

       

x

msgrestart

x

 

x

       

x

msgresume

 

x

   

x

   

x

msgroechange

x

x

x

 

x

   

x

msgrqstintass

 

x

   

x

   

x

msgrqstmufrpt

 

x

   

x

   

x

msgrqsttrnrpt

 

x

   

x

   

x

msgsafepass

x

x

x

 

x

   

x

msgsbrcov

x

 

x

       

x

msgsbrcovcmnd

 

x

   

x

   

x

msgscramble

 

x

         

x

msgsdinudet

x

   

x

     

x

msgsearchpatt

 

x

   

x

   

x

msgsensordefn

x

 

x

x

     

x

msgsensorinit

x

 

x

x

     

x

msgsetwpn

 

x

   

x

   

x

msgstatusbdinit

x

           

x

msgstopengage

 

x

   

x

   

x

msgstopreplay

       

x

   

x

Message

sim

->

rcvr

rcvr

->

sim

rcvr

->

menus

rcvr

->

maps

menus->

rcvr

menus

->

maps

maps

->

menus

Controlled By Exec

msgsublocal

x

 

x

x

     

x

msgtargetinit

x

 

x

x

     

x

msgtaskcompl

x

 

x

       

x

msgtdlaecmtrack

x

   

x

     

x

msgtdlatrack

x

   

x

     

x

msgtrackdes

 

x

   

x

   

x

msgtrkupdate

x

 

x

x

     

x

msgtrnreport

x

   

x

     

x

msgtrueposdata

x

 

x

x

     

x

msgupdatetarget

 

x

   

x

   

x

msgwartime

 

x

   

x

   

x

msgwxreport

x

 

x

x

     

x

request for Icon Pick

         

x (2)

   

Change Map View

         

x (3)

x (3)

 

Icon Pick Result

           

x

 

Location(s) pick Request

         

x (2)

   

multi locations

           

x

 

single location

           

x

 

Notes:

  1. These messages are passed by the executive and are not used at the application level. Ina nutshell, tese can be ignored except to rely on the clock settings and the message passing mailbox data provided bythe executive to be accurate.
  2. These messages involve sending the entire contents of the graph.cmn common block back and forth between the applications in shared memory. This large common block includes sufficient data for the graphics to determine the type of pick desired and how to filter possible data. While the system works, it is cumbersome, difficult to maintain, and injects an otherwise unneccessary amount of simulation-specific data into the map process. We will need to rewrite this approach. (TBD)
  3. These messages involve sending the entire contents of the graph.cmn common block back and forth between the applications in shared memory. There are two problems with this approach. The first involves the maintenance issues mentioned in note 2. The second problem is that it requires the menus to know too much about the current map viewports. We should redesign this to keep the display information within the map process instead of sharing it as currently done.

New Message Structure Definition

This section defines the new messages used to interface to the map process. At this time it is not intended that there will be significant overhaul of the other communications channels.

The new interface to the maps will focus on a strictly limited number of flexible messages. These will be

Messages to the Maps:

  1. New Object Definition - this will include class data for new objects. This includes whether they're circles, lines or bitmaps and, if bitmaps, which bitmap file to use. It will also include text descriptions and categorical information required to help the user filter the displays.
  2. Object Instance - location and associated data for objects required for actual rendering. Note that this will inlude ancillary data that the user must be allowed to display when desired.
  3. Request for a pick - This message is sent when the menus require the user to select something. The picks can either be of a map location (e.g. selecting where and aircraft is to fly) or on an object. Apriori we can limit the selectable objects to objects sent to the Maps from external sources (rcvr or menus). We must also allow a selection filter to be used so that the user's pick can only be interpretted as one of a provided list of selection candidates.

Messages from Maps

The only message sent from the map application (outside executive internal messages) is a response to a pick request. This will return either the lat/long of the the pick (I assume altitude is out of the question for a location pick) or the ID (as originally provided to the maps by the rcvr or menus) of the object selected.

Message Structures

New Object Definition (MSGNEWGRAPHICSCLASS)

Name

Type

Description

Clss

int

Class ID . Will correlate to the class ID that is provided with new instances

shape

int

shape (e.g. circle, line, bitmap, etc.) Current values are maintained in graphical_elements (the h, inc & tcl files are autogenerated) .values include:

CIRCLE 1, POLYGON 2, POLYLINE 3, FAN 4, RECTANGLE 5, ELLIPSE 6, TEXT 7, PIE 8, ICON 9

fill_type

int

Values are maintained in graphical_elements. Current values:

HOLLOW,SOLID, PATTERN,HATCH, EMPTY. This attribute is used only if appropriate to the shape.

line_type

int

Values are maintained in graphical_elements. Current values:

SOLID_LINE, DASHED, DOTTED, DASH_DOT. This attribute is used only if appropriate to the shape.

lock_to_sim_entity

int

Probably defunct now that the graphics don't register sim entities.

priority

float

Drawing priority - the highest is drawn on top of the others. Used only for assets at same altitude. This was made a float to allow tailoring specific priorities arbitrarily as needs arose.

thickness

float

Line (or outline) thickness.

color

int

Object default color. Note this can be overriden by the instance information, thereby allowing the same object to be used for both blue and red representation. Values are maintained in graphical_elements. Current values:

WHITE, RED, GREEN, BLUE, CYAN, MAGENTA, YELLOW.

It would seem reasonable to change this to a standard RGB representation to permit true color representation.

icon_type

int

The intent is too allow multiple types of icons. I'm guessing this would differentiate bitmap "masks" where the color could be defined for each instance versus true multi-color bitmaps. But I'm only guessing. Currently this field is note used.

description

char(64)

A text description of the object to be provided to the JFORCES user to aid him in setting up a display filter.

filename

char(32)

The bitmap filename. FYI this is generally the icon filename associated to the asset or group by the user in the "Edit Icon" utility.

rotate

int

A logical flag (TRUE/FALSE as defined in constants) for whether this object should be rotated according to instance information, or should always point due North.

range_bearing

int

A logical flag (TRUE/FALSE as defined in constants) for whether a range stick (like used on a radar track box) should be drawn from this object to indicate speed and heading. Probably should be renamed, but this is the current name.

scale

float

The distance in meters across the front face of the icon to be used to maintainproper map scaling. This is only valid for bitmaps. Not currently used because the conventions to be used for drawing individual assets and when to "scale out" the drawing of objects so that the user can no longer see them have not been fully defined.

:

Object Instance (MSGGRAPHICSELEMENT)

Field

Type

Description

clss

int

Class ID. Correlates to msgnewgraphicslass message

id

int

Instance ID. The clss & id fields together uniquely identify an object. Note that ID's are only unique within the class, e.g there can be a object in clss 1 with an ID of 1 and a separate object in clss 2 with an ID of 1. If there is an object already in the list with this clss and id this message is processed as an update, otherwise it is treated as a new object. Note that negative Ids are used.

transparency

float

object transparency. Not yet used. Values range from 0 (transparent) to 1 (opaque).

color

int

instance color. same values as used in msgnewgraphicsclass, above. a value of 0 implies the default color should be used.

posting_time

float

time to post the object. Allows delayed postiing. Note that this implies the graphics is hosted under the executive can checks the simtime_ function.

deleteing_time

float

Time to unpost the object. . Currently when this field is specified the JFORCES environment will not send another message for this object when the object is to be unposted. It is used at times when the uposting time is predetermined, e.g if a flah is to be shown for 5 minutes after a bomb is dropped a single message will be sent for the flash and the delete time will be noted; the graphics are resposible automatically unposting the flash. Note that this implies the graphics is hosted under the executive can checks the simtime_ function.

entity_id

int

simulation entity ID. This was used when we planned to tie a number of objects to a simulation entity and let them all update together. An example would be an AWACS with it's icon and sensor tasking fields. To date this has not been implemented and we should discuss whether we want to do this or force the sim (or rcvr) to do it with all the extra communications load this would entail.

entity_type

int

Simulation type (asset, group or target level). Used in conjuction with the entity_id, above, to uniquely identify the entity to tie a graphics object to. Same comments apply.

numpoints

int

number of points in this object

add_delete

int

a flag (ADD / DELETE as defined in constants) to identify whether this object should be added or withdrawn from the display. Note that getting a delete message about an object would immediately withdraw it from the screen - this is how assets losses are handled.

lat_long

float[10][2]

locations associated with points. We should discuss adding altitude to this field

radius

float

radius of a circle (in NM)

min_radius

float

minimum radius of a fan (in NM)

max_radius

float

maximim radius of a fan (in NM)

right

float

rightmost extent of a fan. Measured in degrees clockwise from North.

left

float

leftmost extent of a fan. Measured in degrees clockwise from North.

heading

float

icon heading. Ignored if the class rotation flag is set to NO. Measured in degrees clockwise from North.

altitude

float

object altitude, in feet above ground level. Negative are allowable (e.g. submarines, certain targets). Might disappear if altitude incorporated in lat_long array.

text_length

int

length of associated text. Used to support Fortran.

speed

float

speed, in knots

callsign

char(16)

call sign. used to identify icons. user must be able to turn these on or off.

amplify

char(16)

amplifying data. Used to further identify icons. user must be able to turn these on or off.

 

Pick Request (Not Yet Defined)

This is very much a work in process. Here's my initial stab at it.

Name

Type

Description

pick_type

int

LOCATION for location, ICON for object pick. Note this is generalized from picking only icons. Values will be stored in constants.

num_picks

int

Number of picks to return. Max of 10.

object_filter

char*??

char array of whether various objects are pickable. Used only whenthe pick_type is = ICON. We might incorporate a max number of objects for picking to provide a fixed filter size. I'm also game to make this bit packed, but recongnize this would require more calculations.

client_data

void *

Client data that will be passed back with the pick(s) This menus process will keep a record of the routine to call and all required parameters and will pass the location in the menus process where this is stored so that the processing can resume when the message and this datum is passed back. This will provide our required call-back functionality for event processing.

Pick Response (Not Yet Defined)

This is very much a work in process. Here's my initial stab at it.

Name

Type

Description

num_picks

int

Number of picks made by the user. Max 10.

pick_data

a union of 10 ints class/int pairs or 10 float lat/long pairs.

Pick data. If the request was for ICON picks the response will be the icon classes and Ids. If the request was for LOCATION, the response will be pairs of location (decimal lat/long) data. Latitude is measured in degrees north of the Equator and Longitude in degrees east from the Greenwich meridian.

client_data

void *

Client data that will be passed back with the pick(s) This menus process will keep a record of the routine to call and all required parameters and will pass the location in the menus process where this is stored so that the processing can resume when the message and this datum is passed back. This will provide our required call-back functionality for event processing.

 

Mapping from current messages to new structures

This should be worked, but the reality is that the NRO demo is brewing up, so I'm going to postpone this. I don't believe the people working the graphics require this data at this time, and it'll be July before anybody is ready to tackle restructuring the Menus calls, so we'll postpone this writeup until late June.

Transport Details

We'll need to get together late June to discuss this, but currently my basic thoughts are:

  1. Almost all messages should use executive messaging. Advantages include: it's portable, crossplatform (deomstrated on Win 9x platforms with data correction for big endian / little endian problems for fully defined messages) and it's there - we'll need it for simulation interfaces for the foreseeable future. The only exception to this approach will be updating large volumes of raw data where the current shared memory approach might be faster.
  2. The only alternative data passing scheme I see is the use of share memory (mentioned above) for bulk raw data. Today I'd say we don't need this mechanism for passing asset state vectors; I believe the only place we need to use this is in the transfer of raw sensor results. See the UK GAP scenario in a blue perceived mode to see what I'm talking about. While implementation can certainly vary, it might be worth looking in $GRAPHICS_DIR/map/ snsrup.F to see how the data is currently used by the grphaics and the following routines in the $GRAPHICS_DIR/map/ drawing_support.c file to see how the data is used and maintained:

Routine

Description

update_detections_

Forces an update of the detection structure, cleaning out outdated detections

update_track_data_

Maintains track data. This includes storing it in a retrievable manner (allocating space as deemed necessary, but attempting to minimize this impact) and reusing space for tracks when the first tracks expire.

get_detection_

Permits Fortran procedures to progress through the detection structure

get_first_detection_

Permits Fortran procedures to find the beginning of structures so they can then progress through the detection structure (the progression is handled though get_detection_).

add_detection_

Permits Fortran add detections to the detection structure

find_nearest_detection_by_type_

Searches the detection array for the nearest match of a type

update_detections_

Forces an update of the detection structure, cleaning out outdated detections

draw_historical_

runs through a set of points, drawing dashes

add_poly_

adds a polyline to a structure, draws it as necessary

poly_flush

flushes any remaining polyline data

reload_detection_

Reloads original detection message

check_detections

searches the detection array for the nearest match of a type

maintain_extra_sensor_data

maintains extra sensor data (i.e. detection amplification) in a fashion acceptable to C and Fortran

Clearly, a number of these routines have to do with maintaining data for Fortran and supporting the current Fortran infrastructure with interfaces to C routines, so these specifics can be ignored since the new map process is expected to be C & C++.. Also, there're a few routines having to do with drawing historical detections. Again, see the UKGAP sccenario if you don't know what thisis about. Under the new system it would probably be better to send two icon nstances in the first place - one for the immediate detection using whatever shape and color is appropriate, and a second icon with a lower priority "dash" in the appropriate historical color with it's own timeout. Also, many things won't need distorical data if we can draw speed/heading track rays.

At this point I'm passing this document around for comments. Clearly many parts are very rough, but I'm sure that working together and using this living document as a vehicle for discussion we can flesh this out and make a truely robust and high-performance interface.