I'm curious what the intended use of of deviceRef is?
I don't see it as a tagOn points or equips or devices
My thought is that it should be a tagOn all 3, but I'm not sure what the correct application is.
point -> deviceRef -> device - this is the device where the point originates from. Use case: points on a common equip that come from different controllers or devices.
equip-> deviceRef-> device - this is the device that controls/monitors the equipment.
device-> deviceRef-> device - for containment where you have multiple controllers ganged together to build one large controller.
Is that the correct usage?
Thomas MaltesenThu 16 Feb 2023
I think only your first example is correct.
point -> deviceRef -> device defines which device "contains" the point.
For defining that a device is part of some equipment you should turn the reference around as an equipment can contain multiple devices.
device -> equipRef -> equip
The second use solves both of you remaining examples. In addidition the device tag defines a physical device and as such you cannot have devices containing devices. As I understand it, then you are talking about equipment. So if several devices a ganged together it is an equipment entity...
The result is that deviceRef is only used on points and references the device where the point exists.
Brian FrankThu 16 Feb 2023
Well its not formally defined, so I guess officially it is left open to be designed - that is why I haven't added it as a tagOn anything yet.
As a general rule a point is "owned" by one controller, so putting deviceRef on a point probably always makes sense.
But after that it gets messy.
Something like a built-up AHU might have multiple controllers in which case thinking of the equipment as "containing" those devices would make sense.
But then again on the flip side, a supervisor controller often is used manage many different points, equips, and sub-devices.
If there is an appetite to really try to model devices and their relationships to equipment, then we could add it to Lab WG agenda?
Thomas MaltesenFri 17 Feb 2023
I agree, then one that really makes sence is that the point is owned by a device and to describe that the point has a deviceRef to the device/controller..
For the other cases you are also using the word equipment. So an equipment can contain multible devices/controllers. Therefore the modeling should be done by making a equipRef on the device/controller.
A device that is not contained by a specific equipment such as the supervisor device, simply has no equipRef... Or you could define a high level equip to contain the supervisor. The AHU equip could have a equipRef to the higher level equip... And in relation to this there is a very interresting "system" discussion going on where the supervisor device would fit in.
Francis MahonyThu 2 Mar 2023
This would be an interesting concept to fully bring into Haystack 4. We had this implemented using the Haystack 3 convention using a connection with device1Ref and device2Ref. Modeling serial network bus health has been very valuable.
annie dehghani Wed 15 Feb 2023
I'm curious what the intended use of of
deviceRef
is?I don't see it as a tagOn
points
orequips
ordevices
My thought is that it should be a tagOn all 3, but I'm not sure what the correct application is.
point
->deviceRef
->device
- this is the device where the point originates from. Use case: points on a common equip that come from different controllers or devices.equip
->deviceRef
->device
- this is the device that controls/monitors the equipment.device
->deviceRef
->device
- for containment where you have multiple controllers ganged together to build one large controller.Is that the correct usage?
Thomas Maltesen Thu 16 Feb 2023
I think only your first example is correct.
point -> deviceRef -> device defines which device "contains" the point.
For defining that a device is part of some equipment you should turn the reference around as an equipment can contain multiple devices.
device -> equipRef -> equip
The second use solves both of you remaining examples. In addidition the device tag defines a physical device and as such you cannot have devices containing devices. As I understand it, then you are talking about equipment. So if several devices a ganged together it is an equipment entity...
The result is that deviceRef is only used on points and references the device where the point exists.
Brian Frank Thu 16 Feb 2023
Well its not formally defined, so I guess officially it is left open to be designed - that is why I haven't added it as a tagOn anything yet.
As a general rule a point is "owned" by one controller, so putting deviceRef on a point probably always makes sense.
But after that it gets messy.
Something like a built-up AHU might have multiple controllers in which case thinking of the equipment as "containing" those devices would make sense.
But then again on the flip side, a supervisor controller often is used manage many different points, equips, and sub-devices.
If there is an appetite to really try to model devices and their relationships to equipment, then we could add it to Lab WG agenda?
Thomas Maltesen Fri 17 Feb 2023
I agree, then one that really makes sence is that the point is owned by a device and to describe that the point has a deviceRef to the device/controller..
For the other cases you are also using the word equipment. So an equipment can contain multible devices/controllers. Therefore the modeling should be done by making a equipRef on the device/controller.
A device that is not contained by a specific equipment such as the supervisor device, simply has no equipRef... Or you could define a high level equip to contain the supervisor. The AHU equip could have a equipRef to the higher level equip... And in relation to this there is a very interresting "system" discussion going on where the supervisor device would fit in.
Francis Mahony Thu 2 Mar 2023
This would be an interesting concept to fully bring into Haystack 4. We had this implemented using the Haystack 3 convention using a
connection
withdevice1Ref
anddevice2Ref
. Modeling serial network bus health has been very valuable.