Requirement 5076 states that controllers must support a limited set of datatypes. Requirement 5077 states that controllers may support any datatype. This combination was intended to allow any datatype support in controllers, but require a minimum set for interoperability of application data. A new conformance unit will be written to mandate the minimum datatype support for application data (i.e., input and output data).

The following wording was approved during an AWG meeting.

UAFX FunctionalEntity Datatype Support UAFX FunctionalEntities shall support Boolean, SByte, Byte, Int16, UInt16, Int32, UInt32, Float datatypes for InputData and OutputData.

The new conformance unit was added as mandatory in the FunctionalEntity facet.
The Base Info Base Types conformance unit was removed from the controller server facet.

Wording was updated to include ConfigurationData.

UAFX FunctionalEntity Datatype Support UAFX FunctionalEntities shall support Boolean, SByte, Byte, Int16, UInt16, Int32, UInt32, Float datatypes for InputData, OutputData, and ConfigurationData.

CU added to Part 84 and profile database. Agreed to in AWG call.

As worded, the CU may be interpreted that all FEs need to support input, output, and config. That can be fixed with a simple modification.
BEFORE: UAFX FunctionalEntity Datatype Support UAFX FunctionalEntities shall support Boolean, SByte, Byte, Int16, UInt16, Int32, UInt32, Float datatypes for InputData, OutputData, and ConfigurationData.
AFTER: UAFX FunctionalEntity Datatype Support UAFX FunctionalEntities shall support Boolean, SByte, Byte, Int16, UInt16, Int32, UInt32, Float datatypes for any supported InputData, OutputData, and ConfigurationData.

Additionally it has been questioned whether this belongs at the FE or AC level.

The CU needs to be rewritten and retargeted. If we write it as is and locate it in the FunctionalEntity, all implementations (even temperature sensors) would need to support all these datatypes.
This is a controller requirement and needs to be written for the controller and put in a location that only impacts the controller (i.e., controller profile?).

Nobody felt that the conformance unit was misleading regarding the input, output, and configuration data. We decided to reject that feedback.
The second point was that we made the conformance unit required at the functional entity level. Because we did this, future less-capable implementations may not be able to reuse this FunctionalEntity facet. We accepted this feedback and removed the CU from the FunctionalEntity facet. It was moved to the controller profile and made mandatory there.

Discussed new feedback and addressed it in the AWG meeting.