A ConformanceUnit is supposed to describe an individual testable functionality. In the context of Companion Specifications this means that some functionality of the information model or additional rules in the context of the information model are described.
When defining ConformanceUnits, both ConformanceUnits that concern the model contents and ConformanceUnits that concern the model behaviour are beneficial to be considered. ConformanceUnits concerning the model are used to verify all model elements have been implemented correctly. Their granularity can be chosen such that independent parts of the model can be both implemented and tested independently, e.g. model parts about energy usage can be tested and implemented independently of model parts about the component structure of a device. ConformanceUnits concerning the behaviour of the model can be used to ensure that all functionality that can’t be included in the model itself is implemented correctly. That might be special constraints on optional model elements (e.g. exclusive or, if a then b, etc.) or the behaviour of Methods and other application logic.
ConformanceUnits are referenced by Profiles and used for testing and certification. In a nutshell, it is possible to figure out what ConformanceUnits a product supports (also via the OPC UA interface). Especially for optional features it has to be decided, whether it is important to know if the optional feature is supported or not. As an example, an ObjectType may have ten optional Variables. It is possible to define just one ConformanceUnit for the ObjectType (not preferred), or one for the ObjectType and one for each optional Variable, or maybe putting three related optional Variables in one ConformanceUnit. All approaches may make sense, depending on the Variables.
The recommendation is: If an optional feature is important to be exposed there should be an individual ConformanceUnit. Many optional components should be grouped, if they belong together. If not, it should be grouped into an overall ConformanceUnit. Providing separate ConformanceUnits for optional Nodes, simplifies testing and allow better reuse of information models. A derived model may require an optional item, but if the optional Item does not have a unique ConformanceUnit, then the derived model needs to define a ConformanceUnit for functionality defined in the reused model.
ConformanceUnits may require that the TypeDefinition is available in the AddressSpace. They may also require, that at least one instance exists and behaves as expected. It is recommended to split those requirements.
For optional features, it may be required that at least one instance supports the feature, or that all instances support the optional feature. Those are very different requirements and it should clearly be stated what is expected. For example, a ConformanceUnit may just exist to test if the asset identification is implemented correctly (if present) whereas a ConformanceUnit may also require that all assets of the server have an asset identification (implemented correctly).
Since many products are configurable, it is recommended to state for any requirements on instances, that the product is configurable to support at least one instance of something.
Profiles should combine several ConformanceUnits. It is recommended, that concrete domain-specific Companion Specifications define at least one application profile (defining everything that is needed for a product including protocol etc.) to improve interoperability in that domain.
Generic Companion Specifications designed to be used by others may only define Facets or even only ConformanceUnits which then may be used by other Companion Specifications. If a group of functionalities is expected to be added into other specification it is recommended that that group be defined in a Facet, which can make it much easier to reuse a model. These Facets can be used in an overall Profile that is defined in a Companion Specification.