C2MS12 — Clarify how to specify array and aggregate parameters (MNEMONICs) in MVAL and related messages

The text for MVAL and related messages doesn't explain or give examples of how to specify for example an array or record – for example a BATV[1] or something more complicated like: SBUS.STATUS.PFRAME[27].STACK_DEPTH.

Any text addressing this should also discuss the XTCE repeat concept which the author of this issue believes today is handled by NUM-OF-SAMPLES.

document unrolling of arrays and aggregrates to individual scalars

Two overall approaches are being considered – unroll all the arrays and aggregate to their scalars and supply the values one at a time. OR possibly use a novel syntax such as json to specify the values in some sort of bulk fashion...
The most obvious approach is to unroll them and have each individual array or aggregate field to the scalar of interest, here's some examples below.
But we might also want to provide some more efficient manner if we want to support some kind bulk request at the very least (& then decide if the response is a bulk response or an unrolled response)
Given a database definition like this:

FLOAT[4] BATV // ARRAY of 4 FLOAT

Then each of these “unrolled” can be considered as individual mnemonic definitions:

FLOAT BATV[0] // ARRAY INDEX 0
FLOAT BATV[1] // ARRAY INDEX 1
FLOAT BATV[2] // ARRAY INDEX 2
FLOAT BATV[3] // ARRAY INDEX 3

The above array syntax is common and aligns well with the flight software and/or makes the database definitions etc…

Below is an example of another complex type that is a mixture of aggregate/array. We use quasi-C-like syntax to illustrate:

Struct[4] BATV { // array of 4 of these
INT A;
INT B;
INT[2] C; // array of 4 here also
Struct D

}
We intend this to mean and array of BATV (4), with fields/members A, B, array of C (2), and Struct D which itself has members X and Y;

Unrolling this produces a lengthy set of paths to each scalar:

BATV[0].A
BATV[0].B
BATV[0].C[0]
BATV[0].C[1]
BATV[0].D.X
BATV[0].D.Y

(And 3 more for indices 1,2 and 3).

In essence then any complex type can be unrolled out to a list of all the "paths" through it which results in often lengthy list of individual scalars.

The question then becomes how to handle a request from MVAL for say "BATV".

There's two possibilities in the unroll scenario: the first one is that the receiver of the request rejects it because it doesn't support complex MVAL requests and this would with the right return error code prompt the requester to break the query up into BATV[0] to BATV[3] request PER individual array index. The second possibility is the receiver does support it, and breaks the response up itself something like this:

REQUEST: MVAL BATV

RESPONSE:

NUM-OF-MNEMONICS : 4

MNEMONIC.1.NAME : BATV[0]
MNEMONIC.1.NUM-OF-SAMPLES : 1
MNEMONIC.1.SAMPLE.1.FLOAT-VALUE : 1.0

MNEMONIC.2.NAME : BATV[1]
MNEMONIC.2.NUM-OF-SAMPLES : 1
MNEMONIC.2.SAMPLE.1.FLOAT-VALUE : 2.0

MNEMONIC.3.NAME : BATV[2]
MNEMONIC.3.NUM-OF-SAMPLES : 1
MNEMONIC.3.SAMPLE.1.FLOAT-VALUE : 3.0

MNEMONIC.3.NAME : BATV[3]
MNEMONIC.3.NUM-OF-SAMPLES : 1
MNEMONIC.3.SAMPLE.1.FLOAT-VALUE : 4.0

(And so on ... note that the complex type example is not shown but in either case we're exploding the size of the messages)

Either of these approaches would seem to work – in both cases it's up the requestor to get the data it wants and to "re-roll" the complex types if it wants to present the information to the user in that manner – and we believe this is technically feasable.

Still the shear explosive nature in terms of the number of fields needed to implement this for realistic sized telemetry mnemonic arrays or complex types we've seen is going to be large.

So... let's consider another approach. We allow JSON strings in the SAMPLE result and we define THREE new fields to support it:

DATA-TYPE-FORMAT – send in the REQUEST
RAW-TEXT-VALUE – JSON like text RESULT
EU-TEXT-VALUE – OR JSON like text RESULT

Essentially the requester specifies the DATA-TYPE complex form of the requested data and specifies either RAW or EU, and the RESPONSE packages up this data in a JSON like indentation form. The various scalar DATA-TYPE text forms will have to be defined. Further to be clear this means for complex types any requester wishing for BOTH RAW and EU types will have to break the request into two individual requests.

Here's an example of the BATV[4] array.

REQUEST:

NUM-OF-MNEMONICS = 1
MNEMONIC.1.NAME = BATV[4] // all of the array
MNEMONIC.1.DATA-TYPE = EU
MNEMONIC.1.DATA-TYPE-FORMAT =

RESPONSE:

NUM-OF-MNEMONICS = 1
MNEMONIC.1.NAME = BATV[4] // all of the array
MNEMONIC.1.NUM-OF-SAMPLES = 1
MNEMONIC.1.SAMPLE.1.EU-TEXT-VALUE =

All for now... work up example of struct above.