paramSet_* Handlers

[maxfirefly]

Having developed in F' for a number of years now I've run into a number of designs that either aren't feasible or would be more robust if the component had access to either:

• Monitor/check the value of parameter in paramSet_*_cmdHandler before the parameter is set (similar to how users can override the parameterUpdated parametersLoaded functions)
• Call paramSet_* directly from the component

Example: I have an enum parameter and the PRM_SET cmdHandler allows it to be set to any value in the enum. However, for whatever reason only a subset of the enum entries are valid for this component's purposes. When ground sends a parameter set command with an invalid value:

1. Ground command: MY_PARAM_PRM_SET("INVALID_VALUE")
2. F' autocoded paramSet_MY_PARAM() runs (it's private, I can't override it)
3. Parameter gets set: m_MY_PARAM = "INVALID_VALUE"
4. Then my parameterUpdated() hook gets called
5. I can detect it's invalid and emit an event but the damage is done. I have no way to correct this value from the component

We've avoided this issue by using regular member variables and defining our own set_cmdHandlers that check validity, but these obviously can't persist through reboots or leverage the other benefits of parameters.

Being able to validate before the set happens (allow overrides of paramSet_* maybe) would either let the user:

• Return an error response to PRM_SET command and keep the parameter at its current value
• Or detect the invalid value in parameterUpdated, and call paramSet_*(serializeCorrectedValue) to a valid fall-back value

Just spitballing here.

[timcanham]

@maxfirefly In your example, is the value invalid due to the mode/phase of the mission, or something else?

[maxfirefly]

yeah let me give a more pointed example:

lets say you have a component that uses an enum to host the "configuration" or "mode" of that component. The port connections of that component use the enum so example fpp:

enum MyEnum {
    ENTRY_0 = 0,
    ENTRY_1 = 1,
    ENTRY_2 = 2,
    ENTRY_3 = 3
}

deployment 1 uses these connections:

myComponent.myPort [myEnum.ENTRY_0] -> foo.fooPort
myComponent.myPort [myEnum.ENTRY_2] -> bar.barPort

deployment 2 uses these connections

myComponent.myPort [myEnum.ENTRY_1] -> foo.fooPort
myComponent.myPort [myEnum.ENTRY_3] -> bar.barPort

lets say MyComponent has a parameter CONFIG that houses an instance of MyEnum and the source looks like this

this->myComponent.myPort(this->paramGet_CONFIG(vld))

lets say we also kept track of valid configurations for this instance in some container that was added to in the Config phase:
myComponent.registerConfig(ENTRY_1)
so the instance would know if an entry is valid or not.

there's no way for the user to enforce that CONFIG is set to 0 or 2 for deployment 1 and 1 or 3 for deployment 2

[timcanham]

So you have an enum with a set of values that covers usage in multiple deployments where some of the values are not ever valid for those deployments?

[maxfirefly]

not valid, or not "configured", but yes.

other scenario:

lets say you have a string parameter. you want to use that string to do a lookup into an unordered_map (memory reserved with .resevere(<some static constexpr size>)). there's no way to restrict the values of that string parameter within the confines of that unordered_map 's keys. It'd be great to be able to do a quick "find()" to check if thats a valid value before accepting the PRM_SET

[timcanham]

Traditionally JPL has not allowed modification of the parameter values because as the number of parameters scale (rovers have thousands), it becomes much more difficult to track the values from ground if the software is rejecting or changing them. If you have context-sensitive values that should be validated, then I get the desire to at least valildate them.

[maxfirefly]

that makes sense, thanks for your input Tim. I think Zimri's suggestion of the external parameter fits the need here to validate before setting.

[zimri-leisher]

I suggest maybe external params could help in this use case

[SterlingPeet]

This type of use case also fits neatly into a (voice) discussion from last Friday, where FPP annotation extensions at the project level could (potentially) grow into supported FPP down the line. @thomas-bc captured that discussion with @zeroping in nasa/fpp#977 that points specifically at the baseline support needed to do this sort of thing.

The concrete example here being that a project could leverage a custom FPP annotation to potentially adjust the autocoding for certain parameters; particularly adding a validation step.

This looks a lot like tooling to support configurable topologies at runtime. I'd like to mention that this topic has been discussed in the hallways at symposiums and conferences, but the concept is not currently supported by the F Prime framework. It is certainly possible, and some of us are interested in experimenting with pushing it forward. The engineering has not be done to support it, and that does show in the assumptions of things like autocoded parameter plumbing.

I am interested in topologies configured at runtime, hence why I mention it.

[Kronos3]

@zimri-leisher We have discussed an approach pretty much exactly like what you are describing, applying some sort of value constraint to relevant types. Also as Tim mentioned this work is on our roadmap https://github.com/nasa/fprime/wiki/F%C2%B4%C2%A0-Roadmap#modeling under Command argument validation (includes parameters)

[maxfirefly]

@SterlingPeet , topologies configured at run-time is the impetus of this post. I'd be very interested in learning more about this if/when that information is available

[bocchino]

I'm sure you guys have thought about this, any thoughts on what I suggest?

Sounds good. We have already prototyped a way to restrict numeric command arguments. I agree that adding the restrictions to the type system would be better.

[zimri-leisher]

@bocchino @Kronos3 here is a github issue + some first draft syn/semantics for this nasa/fpp#980