Currently, if a configuration is rejected by a FR or FP then this NACK reply is ignored by the FR/FP adapters.
The proposal to solve this is to:
1) Maintain a set of parameters to record messages have been sent to a FR/FP
2) Update the parameters when the reply from the FR/FP is received
3) Keep a record of the failures for any monitoring clients (which can be cleared using the standard clearing mechanism for faults)
1 & 2 combined would provide useful status in the event of FR/FP freezes or crashes when sending configurations.
3 would allow client applications to check or report failed configurations in the same manner as fault states are currently reported, latched until cleared explicitly.
Currently, if a configuration is rejected by a FR or FP then this NACK reply is ignored by the FR/FP adapters. The proposal to solve this is to: 1) Maintain a set of parameters to record messages have been sent to a FR/FP 2) Update the parameters when the reply from the FR/FP is received 3) Keep a record of the failures for any monitoring clients (which can be cleared using the standard clearing mechanism for faults)
1 & 2 combined would provide useful status in the event of FR/FP freezes or crashes when sending configurations. 3 would allow client applications to check or report failed configurations in the same manner as fault states are currently reported, latched until cleared explicitly.