JSON Library

Collaboration diagram for JSON Library:

Modules
	JSON Name Space variable type constants
	JSON Constants
	JSON typedefs
	JSON Name Space
	JSON Packet
	JSON functions

Detailed Description

A library providing functions in support of the COSMOS specific JSON format and the associated Nodal Namespace concept.

COSMOS JSON is a special application of JavaScript Object Notation. It has been designed to fill the needs of COSMOS for a mechanism by which it can share data between the various Agent and Programs, both internally, and cross platform.

COSMOS JSON is defined by the following key elements:

• implements all elements of JSON
• defines base types of double, float, int32, uint32, int16, uint16 and string
• allows for the creation of complex types as combinations of base types
• defines a unified Name Space, in which each name is tied to a base or complex data type.

The JSON functions provide mechanisms for mapping names from the JSON Name Space to internal data structures. JSON strings can then be parsed directly in to memory. Similarly, JSON strings can be created directly from memory.

The COSMOS Nodal Namespace is the unique application of COSMOS JSON to manage data within COSMOS.

The Node is the highest level physical entity in the COSMOS system. Every COSMOS installation will consist of a number of Nodes, all interacting through their Agents (as described in the Agent Server and Client Library). Each Node has a detailed description, stored both as structures in memory, and as elements of the JSON Name Space. These descriptions are broadly separated into the following categories:

• Node: summary information about the Node, including counts of various other categories
• Piece: physical pieces in Node
• Device General: that subset of pieces that have some electronic nature
• Device Specific: the subset of General Devices that have qualities unique to that specific device

Every physical thing in COSMOS is part of a Node. All Nodal actions are implemented through Agents, as described in the Agent Server and Client Library. Interactions between Nodes are always expressed as interactions between Node:Agent pairings. Thus, Messages and Requests will be addressed to names expressed as Node:Agent (though wildcards are in some case supported eg. Node:* or *:Agent).

Each Node will also have a number of associated tables and/or dictionaries. These will be lists of either straight JSON, providing additional information about the Node, or JSON Equations, providing conditional information about the Node.

The first type currently supports:

• ports.ini: information about the specific port for any device that requires one
• target.ini: a list of other locations of possible interest, to be used with targetting
• state.ini: the most recent state vector for the Node
• node_utcstart.ini: the mission start time

The second type currently supports:

• events.dict: table of Physical Events, to be matched against current data to determine events.
• commands.dict: table of Command Events

Targetting

Information about alternate targets is supported in memory through the use of a table of type targetstruc, stored within the cosmosstruc. These values can be accessed externally through names of type "target_*". This table is initialized using load_target, and updated with values in the current cosmosstruc using update_target. Information calculated includes the Azimuth and Elevation to and from each target, as well as its range.

Events

Unlike Targetting, information about Physical Events is not stored directly in the cosmosstruc. Instead, the user keeps a table of type eventstruc, initialized with load_dictionary, that provides templates for all possible events. These templates can be matched against current conditions using calc_events. This will return a second table of type eventstruc that includes an entry for each event that:

• had its condition calculate non zero
• did not have its condition calculate non zero previously