Added command group support for the space system model and xtce.

[Mark Doyle]

I did this this morning. It has one test and which passes ok.

It needs reviewing, tweaking etc because I had a toddler hanging off my arm at the same time.  Lauri and Johannes are probably best to go over it?

Test is here which should give you an idea of how it works:

https://github.com/JohannesKlug/hbird/blob/master/src/core/xtce/src/test/java/org/hbird/core/xtce/CommandModelTest.java

I think the solution will work. The payload codec should be able to encode the commands without any adjustments.

I made some assumptions with XTCE as it's a little over complex for us!

• A command argument is treated the same as a Parameter. You can use the terms interchangeably when referring to commands (it wouldn't make sense to call a TM parameter an argument).
• Currently only support the definition of arguments using the xtce:ParameterTypeSet and xtce:ParameterSet. Argument declarations will be ignored. See:  https://github.com/JohannesKlug/hbird/blob/master/src/core/xtce/src/test/resources/org/hbird/core/xtce/TestSat-all-uints.xml
• Commands are defined by MetaCommands. The CommandContainer seems, on the surface, to define attributes outside of our current scope.
• Arguments must be defined along with their type in the xtce:CommandMetaData section of the xml file. In theory there is no problem in reusing parameters and their type definition from the  xtce:TelemetryMetaData section. This would prevent duplication of common types (for example, 1 bit flag, 8 bit ints). An adjustment to the XtceSpaceSystemModelFactory class would achieve this.
• Like TM (I think) we ignore initial value and a few other xtce attributes.

TODO:

• I haven't changed the publisher. This means one can't grab a list of  currently supported commands or (in the future) be updated if the command model changes. It's next on the list.
• There is currently no CCSDS protocols support for command forwarding...I think. Johannes? What happens if the Packet encoder receives a generic payload to forward? Obviously, this doesn't matter for Strands UDP as the design will be different.

Thanks!

P.S. I probably missed a lot of stuff from this mail.

[Johannes Klug]

I've looked at the code - it all makes sense.

A question about your test case, though: What's the spacecraft id for? I
presume you meant that to be some sort of identifier, but should it end
up in the encoded command, too?

PayloadCodec supports encoding to GenericPayload, which carries a
payloadIdentifier. That would be the logical place to stick some id
(like ApId) for the encoded command. For TM, we used the "HEADER" / base
container reference in XTCE (see our test xml file). What's the
equivalent we'd use for encoding commands?

Regarding the CCSDS protocols support: Commanding is definitely
supported, see
org.hbird.transport.protocols.ccsds.spacepacket.CcsdsPacketEncoder.
If it is initialised with CcsdsPacketType.TC, it will set the command
flag to 1. The rest is identical to TM encoding.

On 04/29/2012 03:41 PM, Mark Doyle wrote:
> I did this this morning. It has one test and which passes ok.
>
> It needs reviewing, tweaking etc because I had a toddler hanging off my
> arm at the same time. Lauri and Johannes are probably best to go over it?
>
> Test is here which should give you an idea of how it works:
> https://github.com/JohannesKlug/hbird/blob/master/src/core/xtce/src/test/java/org/hbird/core/xtce/CommandModelTest.java
>
> I think the solution will work. The payload codec should be able to
> encode the commands without any adjustments.
>
> I made some assumptions with XTCE as it's a little over complex for us!
>

> * A command argument is treated the same as a Parameter. You can use

> the terms interchangeably when referring to commands (it wouldn't
> make sense to call a TM parameter an argument).

> * Currently only support the definition of arguments using the

> xtce:ParameterTypeSet and xtce:ParameterSet. Argument declarations
> will be ignored. See:
> https://github.com/JohannesKlug/hbird/blob/master/src/core/xtce/src/test/resources/org/hbird/core/xtce/TestSat-all-uints.xm

> <https://github.com/JohannesKlug/hbird/blob/master/src/core/xtce/src/test/resources/org/hbird/core/xtce/TestSat-all-uints.xml>l
> * Commands are defined by MetaCommands. The CommandContainer seems, on

> the surface, to define attributes outside of our current scope.

> * Arguments *must *be defined along with their type in

> the xtce:CommandMetaData section of the xml file. In theory there is
> no problem in reusing parameters and their type definition from the
> xtce:TelemetryMetaData section. This would prevent duplication of
> common types (for example, 1 bit flag, 8 bit ints). An adjustment to
> the XtceSpaceSystemModelFactory class would achieve this.

> * Like TM (I think) we ignore initial value and a few other xtce
> attributes.
>
> TODO:
>
> * I haven't changed the publisher. This means one can't grab a list of

> currently supported commands or (in the future) be updated if the
> command model changes. It's next on the list.

> * There is currently no CCSDS protocols support for command

[Mark Doyle]

Ja, SpacecraftId is meaningless, an arbitrary name chosen (read, copy and pasted) for the test file, it could be anything.

[Johannes Klug]

Ok. What about the "identifier" question?
In SpaceSystemModel.java, we've got this:
// TODO XTCE specific hack. Should move to the xtce project.
Investigate. - Mark
String HUMMINGBIRD_PROCESSED_HEADER = "HEADER";

We need something like this in the CommandMetaData section in XTCE, so
we can determine the id of a command.

On 04/30/2012 12:19 AM, Mark Doyle wrote:
> Ja, SpacecraftId is meaningless, an arbitrary name chosen (read, copy
> and pasted) for the test file, it could be anything.
>
> On 29 April 2012 23:09, Johannes Klug <j...@jklug.com

> <mailto:j...@jklug.com>> wrote:
>
> I've looked at the code - it all makes sense.
>
> A question about your test case, though: What's the spacecraft id
> for? I presume you meant that to be some sort of identifier, but
> should it end up in the encoded command, too?
>
> PayloadCodec supports encoding to GenericPayload, which carries a
> payloadIdentifier. That would be the logical place to stick some id
> (like ApId) for the encoded command. For TM, we used the "HEADER" /
> base container reference in XTCE (see our test xml file). What's the
> equivalent we'd use for encoding commands?
>
> Regarding the CCSDS protocols support: Commanding is definitely
> supported, see

> org.hbird.transport.protocols.__ccsds.spacepacket.__CcsdsPacketEncoder.

> If it is initialised with CcsdsPacketType.TC, it will set the
> command flag to 1. The rest is identical to TM encoding.
>
>
>
>
> On 04/29/2012 03:41 PM, Mark Doyle wrote:
>
> I did this this morning. It has one test and which passes ok.
>
> It needs reviewing, tweaking etc because I had a toddler hanging
> off my
> arm at the same time. Lauri and Johannes are probably best to
> go over it?
>
> Test is here which should give you an idea of how it works:

> https://github.com/__JohannesKlug/hbird/blob/__master/src/core/xtce/src/test/__java/org/hbird/core/xtce/__CommandModelTest.java

> <https://github.com/JohannesKlug/hbird/blob/master/src/core/xtce/src/test/java/org/hbird/core/xtce/CommandModelTest.java>
>
> I think the solution will work. The payload codec should be able to
> encode the commands without any adjustments.
>
> I made some assumptions with XTCE as it's a little over complex
> for us!
>
> * A command argument is treated the same as a Parameter. You
> can use
>
> the terms interchangeably when referring to commands (it
> wouldn't
> make sense to call a TM parameter an argument).
> * Currently only support the definition of arguments using the
>
> xtce:ParameterTypeSet and xtce:ParameterSet. Argument
> declarations
> will be ignored. See:

> https://github.com/__JohannesKlug/hbird/blob/__master/src/core/xtce/src/test/__resources/org/hbird/core/xtce/__TestSat-all-uints.xm
> <https://github.com/JohannesKlug/hbird/blob/master/src/core/xtce/src/test/resources/org/hbird/core/xtce/TestSat-all-uints.xm>
> <https://github.com/__JohannesKlug/hbird/blob/__master/src/core/xtce/src/test/__resources/org/hbird/core/xtce/__TestSat-all-uints.xml

[Mark Doyle]

Brain dump alert:

We can see the reason given the log errors in the code:

else {

        LOG.error("Hummingbird does not process hierarchical container models due to their incompatiablity with multi-packet spanning payloads

                        and/or multi-frame spanning packets.");

        LOG.error("Specific error: ");

        LOG.error("ParameterGroup: " + parameterGroupContainer.getName() + " extends base container " + baseContainer.getContainerRef());

}

Forcing XTCE file devs to extend a kind of virtual "HEADER" allows us to map a packet header parameter restriction i.e. something from further down the stack (CCSDS violates the responsibility of abstraction layers somewhat), to the layout. Correct?

I guess we just enforce the same virtual header for XTCE based model definitions? You can create abstract commands and derive commands from them.  Perhaps there is something in the XTCE command container scheme too? Remediable, I've used the simplest method so far, i.e. just the MetaCommand scheme.

If I remember correctly, the abstract base classes of TM and TC wouldn't be necessary for another protocol, at least one that doesn't use data across all OSI abstraction layers indiscriminately. We could move layout id work to a mina/netty still protocol pipelin e.g.

https://github.com/JohannesKlug/mandolay-pigeon/blob/master/src/main/java/org/hbird/mandolaypigeon/protocols/UdpReceiver.java

I'll have to think this through properly though. The payload codec treats a raw binary stream as an amalgamation of all defined parameter groups (layouts) if there are no restrictions (ID's...terms are so overloaded these days!). Having said that, it is passed the restriction/ID from the lower layer so it only needs a reference in the space system model. This doesn't have to be an abstract container in XTCE. I guess that technique was a hangover from previous attempts to create a full XTCE implementation.