SpaceSystemModel & XTCE

[Lauri Kimmel]

I tried to compose simple SpaceSystemModel using XTCE from https://github.com/JohannesKlug/hbird. I made some observations and have some questions.

1) Only supported parameter types are IntegerParameterType and LongParameterType. Are there any plans to support other types in near future?

2) In SpaceSystemModel there is no difference between TM and TC. Is this intentional? For example how should UI know which ParameterGroups or Parameters has to be visible in "telemetry view" and which in "commanding view"?

3) About SpaceSystemModel interfaces – there are lots of methods like 

Parameter<XXX> getXXXParameter(String qualifiedName) and 

Map<String, Parameter<XXX>> getAllUniqueXXXParameters().

Why not to use generic methods like 

<T> Parameter<T> getParameter(String qualifiedName, Class<T> c) and 

<T> Map<String, Parameter<T>> getAllUniqueParameters(Class<T> c)

instead?

4) Same question for ParameterGroup interface.

5) What about encodings and restrictions in SpaceSystemModel - are they stable/usable at the moment or do they need some additional work?

[Mark Doyle]

1) the facility to add them is all in place. It's just a matter of creating the codec i.e., the CodecParameter<?> for the particular parameter type.. I think only one of signed or unsigned longs are supported presently. What we discovered was that most space system use calibrated values from unsigned ints so we shifted focus away from implementing the others.

Current CodecParameters are here:  https://github.com/JohannesKlug/hbird/tree/master/src/transport/payload-codec/src/main/java/org/hbird/transport/payloadcodec/codecparameters/number 

We even plan to support non-numeric types. So a space craft could send encoded Strings. As I said though, everything we have seen so far uses uints for efficiency.

2) A "piece" TM is simply a group of Parameters. A TC is also simply a groups of parameters. You see differences at the lower levels of the OSI model stack where frames or packet headers contain meta data that describes whether the contained group of parameters is tm or tc. Essentially (and particularly with regard to data in a piece of software) they are the same though, yes.

The Space System Model deals with the internals and must implement methods to return command or tm groups. The return types are the same but the model must return the correct groups. The XTCE model gets this information from the model XML file which has distinct TM and TC sections/tags. When it builds the model it separates the definitions. To answer your question (finally), a UI woudl just as for allParameters() or allCommands() depending on what it wanted to display.

3) I don;t have the code here so I can't cite a specific example but I can tell it's because of complications arising from Type Erasure. Good reading here, section 3 http://www.angelikalanger.com/GenericsFAQ/FAQSections/TechnicalDetails.html We spent a lot of time trying to work around this and decided the best way was to handle the complexities in the model and keep the API ass simply as possible for application level development.

4) See above. Not, the generics in parameters are used to reference the type required to hold the value not necessarily what the parameter type is! This information comes from (if I remember correctly) the encodings (stored in the model). The reason for this is that Java has a limited set of primitives and no concept of unsigned values. This means an abstract type 32bit uint will not fit in a Java integer as the MSB is reserved for the twos complement sign. For this you need a Long and then have to play around at the bit shifting level. It get's even more complicated when we support different endianess! This is also why there are multiple codecs for integers, longs etc.

5) Pretty stable I think. Retrictions were made very generic so one can use anythings. It's a String,Object map I think with the Object being the restriction value. We've used CCSDS apid and an ip so far in tests.

[Mark Doyle]

also for 1)

the interfaces are in place so it should be quite easy to figure out what comes in and what you need to return :)

[Mark Doyle]

2)  "a UI woudl just as for allParameters()..." should of course be  "a UI would just call allParameters()..."

[Lauri Kimmel]

1) My problem started from the point where I tried to use other parameter types than IntegerParameterType in SpaceSystem xml definition. It turned out that XtceSpaceSystemModelFactory is not supporting any other types than Integer and Long at the moment. This means that i can't use any other types in SpaceSystem xml for ESTCube and ground station. Types like Double, String, Date, Boolean are need there. As it looks to me model (XtceSpaceSystemModel in this case) can support them without codecs implemented. Of course codecs are needed at the end for "outside" communication. 

So I rephrase my question – what are the plans with the XtceSpaceSystemModel in near future?

2) Ok. This is how I see it also – model is responsible to return TM and TC to "user" on request. Only problem is – there is no method allCommands() or similar in interface SpaceSystemModel at the moment.

3) & 4) Fair enough. It just looks bit too verbose at first time if you see it as API user.

[Mark Doyle]

1) Nothing set in stone. We'll look at the specific use case. Most double values come down requiring calibration as far as I am aware. We were going to concentrate on other components and support integer and longs. As I say we'll never say never!

2) Well I never knew that, ha! I guess we better fill finish that!

3) Hopefully as an API user you won't see it. This is what we deem people writing application level code, on top of the hbird middleware if you like. Using the Creating or using the Space system model is pretty low level and requires some more knowledge :) Essentially, we decided to keep transport complexities low down in the transport code.

Hopefully J8 will support reified generics. I won't hold my breath though ;)

[Lauri Kimmel]

1) ESTCube needs at least String and raw (byte[]) parameter types. Can I add support for them into XtceSpaceSystemModel or should I create new issue somewhere eg. under https://github.com/JohannesKlug/hbird ? 

[Johannes Klug]

On Mon, March 26, 2012 09:20, Lauri Kimmel wrote:
> 1) ESTCube needs at least String and raw (byte[]) parameter types. Can I
> add support for them into XtceSpaceSystemModel or should I create new
> issue
> somewhere eg. under https://github.com/JohannesKlug/hbird ?

I think we'd love for you to implement support for those two!
I've added you as a collaborator on the hbird GitHub project.

[Mark Doyle]

The CodecParameters will also need to be written in the payload-codec project. I think a issue in github would be helpful to track this.

[Lauri Kimmel]

Issues created - https://github.com/JohannesKlug/hbird/issues

[Mark Doyle]

Lauri,

I noticed you didn't implement some String parameter methods when you implemented the String type in the XtceSpaceSystemModel. Did you just miss them or was there a deeper reason?

e.g., this method is still unsupported:

@Override
public Parameter<String> getStringParameter(final String qualifiedName) throws UnknownParameterException {
        throw new UnsupportedOperationException();
}

[Lauri Kimmel]

I completely missed those methods. No deeper reason =)