Is this really an Information Model issue - I would think it is more of a descriptor issue, since the ConnectionManager is who create the connection (and the pairings). You could probably specify this in more then one manner and I don't think we should mandate any specific manner. in addition to sub-FunctionalEntities as you described. A very simple manner which would easy for a engineer to understand is a naming convention for the preconfigured sets. The naming conventions could also apply to sub-folders in the input/output groups. Another option could be to have ControlGroups (which is what they were defined for - grouping of inputs and outputs that should go together - Along with any configuration that also is part of the group).

we could add an examples in one of the Annexes for this type of configuration.

Yes, we should discuss further. Since the descriptor is supposed to reflect the information model, I don't think it's strictly a descriptor issue. I don't see how ControlGroups would solve this, as it really has no notion of inputs and outputs. What the application engineer would want to see is the engineering tool presenting a list of input/output pairs for selection, from which the associated application data structures can be created, and from which the EstablishConnections method can be created with the correct inputs & outputs. Relying on a naming convention seems undesirable b/c the tool may have no knowledge of that being used, and the AC would reject a connection that asked for the wrong pairings.

There may be more than one way to solve it, but it needs to be solved in a way that a tool can be driven off of the descriptor and present allowable options to the user to select.

Control group are not limited to input or outputs, It could point to the two dataset (via ListrOfRelated) and give the grouping a name (in the name of the control group). This would indicate that the two dataset are to be used together (it could even use one of the other list if desired to lock them - and list the inputs and output also) Part of the purpose of a ControlGroup is to describe functionality that is grouped.

Control Groups don't seem to be described very well in Part 81, if they are to be used for a purpose like this. I see that you can have a List of Related. But consider that we want to allow for "dumb" engineering tools to be driven completely off of a descriptor (to borrow from what Rick has said in the past). The engineering tool needs to present to the user a list of input/output pairs, so it needs to know how to find those in a consistent way, strictly based off of what it finds in the descriptor.

Just using a descriptive name would not be enough. The tool would need to first see that Input/Output DataSets are available in the FE, and then it would need to look to see if any ControlGroups exist that link input/output DataSets, and then present those as pairs only. That seems like a roundabout way to do it, and it really would need to be written down in the spec, if the engineering tools are going to be able to work consistently with descriptors.

Discussed in call - that control group should fit, but need more example and text explaining it (also this should be prototyped) - target might not be the next maintenance release but a little further down the road (motion is also working on more example for ControlGroups)

Discussed in call that this addition should have prototyping, and that it is ok to push off to next release