Tag Interface Annotation

[theSloopJohnB]

I was thinking about this at the end of @SimonRPSM's talk today on his use of a control word interface between two modules. Essentially, he is counting on readers and writers of that tag to know exactly what that tag is and how to use it. The issue appears generally in DCAF applications and is worth a discussion.

Take a look at the Example diagram for reference.

Here, we have many doubles zooming from one module to another. If a user wants to connect the Scan Engine temperature channel to the temperature channel on the controller logic, they are presented with all of the available double tags to use. This is not ideal, because they may mistakenly connect something that has nothing to do with temperature.

I would propose adding another piece of data to the tags - an Interface.

Interfaces can be associated with tags and channels. They are sugar on top of channels that further restrict what can be connected to each other. In the above (quick and dirty) example, I have created an interface column for tags. When a user tries to connect a tag to a channel, it can only happen if they have a matching interface. In the example diagram, Temperature-cRIO, the scan engine input channel, can be connected to Lamp PWM, the Temperature Chamber Model process, assuming the DCAF rules of today. With Interfaces, this no longer becomes possible, letting users write safer code.

Mapping channels becomes even easier on the module configuration page. Creating a tag will automatically fill in the channel's predefined Interface to the tag's information in cases where the module chooses to, e.g. a static module expecting temperature. Dynamic modules like Scan Engine could let users choose to add an interface when they create the channel. Finding matching tags will be much easier because they will already be filtered down by the interface.

DCAF is full of these interfaces which have to be handled manually by users. There are things that can be done to make this easier, such as the 'Automated Interface Matching' tab under the mappings configuration. The existing solution of today piggybacks on the names of tags and channels, where an explicit value for this kind of behavior would be more ideal.

Another advantage would be in preventing cross communication between similar subsystems. For example, imagine if one DCAF instance is controlling two identical control systems in the same engine instance, Control Subsystem1 and Control Subsystem2. you could have two interfaces for each instance. E.g. You can set a module wide Interface, Control Subsystem1, and the channels will further describe their interfaces, e.g. Control Subsystem1:Temperature Input. Then you can't accidentally connect your control logic from Control Subsystem2 to Control Subsystem1's channels.

One more note: We don't want to over-limit the ability to connect tags and channels. For example, a user who wants to log everything want interfaces on all of their channels and tags except their TDMS Datalogger channels. Maybe we could adopt an interface named * to allow for these use cases where we want to ignore the interface and just map it anyway.

[Beazurt]

The ability to ensure clean interfaces between two modules is certainly a challenge with DCAF. It would be fantastic to come up with a good solution, and I think your proposal is a great start. I've thought about this for a long time now, and there are a lot of additional considerations to work through.

Which module defines an interface, how do they define it, and what happens if two modules have different definitions of the same interface? How is an interface versioned?

How strict should an interface definition be? Do the number of channels and their datatype have to match exactly or could an interface use a Double and Single interchangeably for one of its values for example?

Does ordering of values within an interface matter? If not, how do we identify each element within the interface?

What if two interfaces are identical in terms of the number of channels, their datatype, and order, but actually have two different interface names, should we still allow them to be connected?

Do we also need a concept of units? A Double could be a voltage or a current, and could still be included as part of a larger interface (say motor command with a voltage for torque and a Boolean for direction).

Do interfaces exist for Tags or only for Channels? If Tags need interfaces, how are interface Tags added and what happens if someone tries to delete a subTag?

There are probably a lot of other items that would need to be addressed. I like this idea a lot, but we need to agree to a lot of specifics, and experiment with a prototype, before we can get something into Core. I think a good place to start would be a list of use-cases that we would like to support.