We briefly discussed Objects in an earlier post related to Begin- and End – Envelope on CAN-X. To just transfer binary data values creates a lot of fuzz with so many devices involved, so we create a generic tagged system known from ASN.1 and very similar to users of Modbus and CANopen etc. This means that all data on a device have an unique 16 bit identifier that we call “Parameter ID” or PID. Every time we send a value we send the PID + the value.
The PID can be a command, a simple variable or a complex object. More important is that only the sender and receiver need to know the PID as it is private for the stream. To do this we need a few global PID’s and we need maintenance messages allowing the device to inform about it’s data repository during start-up. For me as a device developer this means I only need to care about a few common PID’s and the rest can be used as I please regardless of how things are designed on different devices.
This also means that we have a device that will inform the rest of the network about its interface, something that makes plug & play on the level I want possible. Interfacing to this needs to be done through an API where the user access a specific device with a known interface. We can use the same PID technique here but use names to map the PID’s at start. I will return to the API layer later.
I indicated earlier that we should use PID=0 and 1 for the envelope. I am actually reconsidering to move the fixed PID’s into the 60,000 ++ area because if I am on a device it would be efficient if my PID also was an index into my local object map. But, I can still do that if I just subtract an offset.
Different versions of the same device might include changes in the PID array. And some applications might prefer a fixed PID array so they can be coded directly without supporting the more complex plug & play. I need to think about this one because I am not sure I want to take it into consideration at all. It is probably better to create fixed map’s in the API than complicate the devices if we need this later.
The drawing above illustrate a possible Object Repository on a device. This will typically be set up as a static array initialized at start-up. Each entry point to an actual data value/object in this case. If data is written we look up the repository, fetch the pointer and write the actual data variable. The same value is available top-side through our communication system and the top-side application will see this as if it was a local entity. This technique is called “Remote IO”.