Hey Chris,
I am not certain if "tag" is standardized or not. Earlier, knowing only
modbus registers and bacnet objects, I been confused multiple times what
the tag is. For regular IT tag is rather a marker placed on something to
categorize elements. Our field currently specifies rather a unique data
point than a tag.
If tag meaning comes from IEC standard then I'd opt in for a change. If
its not standardized then I'd advice staying with a field. Our use is
mixed IT/OT (with probably still more IT?), if we stick too much to
automation industry terminology then we will need to bake definition of
a tag, fight situations where we miss a "common understanding" cause we
can't beg others for unification of their meaning.
I've seen tag used in context of ethernet/ip (more precisely Rockwell
PLCs), but haven't done a research of why. Keep in mind we have also
object oriented protocols such as BACnet (with `device.object.property`)
and CANopen (with `device.sdo` or `device.tpdo..`) thus in their context
tag is far less meaningful than field.
Cheers,
Łukasz
On 5.11.2022 12:23, Christofer Dutz wrote:
Hi all,
I’m currently working on harmonizing our different API variants a bit and
hopefully finalizing our Browse API (Which sort of wen’t through multiple
levels of change between Java and Go, back to Java and now back to Go.
One thing I learned at Rivian is, that everyone seems to be talking about
“Tags” on PLCs. So I asked on LinkedIn and it seems pretty obvious that “Tag”
seems to be the term mostly used in the automation industry.
So, I would like to consequently rename “Field” to “Tag”.
What do you folks think?
Chris
