From cf8f98f665b9397bd1f1b63352a4664dc10707bd Mon Sep 17 00:00:00 2001 From: Darryl Mocek Date: Mon, 6 Nov 2023 15:09:22 -0800 Subject: [PATCH 1/5] feat: Add Protocol-specific Attribute Values in Device UCR. Signed-off-by: Darryl Mocek --- .../design/ucr/Protocol-Info-In-Device.md | 39 +++++++++++++++++++ 1 file changed, 39 insertions(+) create mode 100644 docs_src/design/ucr/Protocol-Info-In-Device.md diff --git a/docs_src/design/ucr/Protocol-Info-In-Device.md b/docs_src/design/ucr/Protocol-Info-In-Device.md new file mode 100644 index 0000000000..5aadcb3bda --- /dev/null +++ b/docs_src/design/ucr/Protocol-Info-In-Device.md @@ -0,0 +1,39 @@ +# Use Case Title +Protocol-specific Attribute Values in Device + +## Submitters +Darryl Mocek (Oracle Corporation) + +## Changelog + +## Market Segments +Any segments using EdgeX with device services that contain protocol-specific values in Device Profile attributes. + +## Motivation +The Device Profile describes the device. There are many different manufacturers of the same type of device (e.g. HVAC). The Device Profile of a specific type of device could used be for many or all of the Devices of that type, reducing the need to duplicate a Device Profile just to account for differences in the protocol-specific attribute values. + +## Target Users +Any users that create Device Profiles and Devices that have protocol-specific attribute values. + +## Description +The Device Profile **describes** the device and its attributes, it's type. Different manufacturers can build the same type of device using different protocols and the same device using the same protocol but different configuration (e.g. different Modbus HoldingRegister). For example, two different manufacturers may build an HVAC using ModBus, and another may build an HVAC using SNMP. In the case of two Modbus devices, there will need to be two different Device Profiles, even though the devices are the same and have the same attributes, because the protocol configurations (e.g. HoldingRegister) will conflict. Device Profile + +If the protocol information resides in the Device, which describes a specific (instance of a) device only a single Device Profile is needed as all devices of the same type can use the same Device Profile. This becomes more important as you have more devices, potentially increasing the number and management of Device Profiles when one will do. + +## Existing solutions + + +## Requirements +The requirement is to support the protocol-specific attribute values (e.g. HoldingRegister) in the Device as well as the Device Profile (for backward compatibility). + +- If only the Device contains a protocol-specific attribute, it is used for that device. +- If only the Device Profile contains a protocol-specific attribute, it is used for all Devices that have that Device Profile. +- If both the Device Profile and the Device contain a protocol-specific attribute, the entry in the Device overrides the one in the Device Profile. + +## Related Issues + +## References +- https://github.com/edgexfoundry/device-modbus/blob/master/src/main/resources/MBUS-RTH-LCD.profile.yaml From b4d7ee4ac0f51ad001f4080ab69eb95a1adb9c0e Mon Sep 17 00:00:00 2001 From: Darryl Mocek Date: Mon, 6 Nov 2023 15:24:01 -0800 Subject: [PATCH 2/5] fix: Remove file. Signed-off-by: Darryl Mocek --- .../design/ucr/Protocol-Info-In-Device.md | 39 ------------------- 1 file changed, 39 deletions(-) delete mode 100644 docs_src/design/ucr/Protocol-Info-In-Device.md diff --git a/docs_src/design/ucr/Protocol-Info-In-Device.md b/docs_src/design/ucr/Protocol-Info-In-Device.md deleted file mode 100644 index 5aadcb3bda..0000000000 --- a/docs_src/design/ucr/Protocol-Info-In-Device.md +++ /dev/null @@ -1,39 +0,0 @@ -# Use Case Title -Protocol-specific Attribute Values in Device - -## Submitters -Darryl Mocek (Oracle Corporation) - -## Changelog - -## Market Segments -Any segments using EdgeX with device services that contain protocol-specific values in Device Profile attributes. - -## Motivation -The Device Profile describes the device. There are many different manufacturers of the same type of device (e.g. HVAC). The Device Profile of a specific type of device could used be for many or all of the Devices of that type, reducing the need to duplicate a Device Profile just to account for differences in the protocol-specific attribute values. - -## Target Users -Any users that create Device Profiles and Devices that have protocol-specific attribute values. - -## Description -The Device Profile **describes** the device and its attributes, it's type. Different manufacturers can build the same type of device using different protocols and the same device using the same protocol but different configuration (e.g. different Modbus HoldingRegister). For example, two different manufacturers may build an HVAC using ModBus, and another may build an HVAC using SNMP. In the case of two Modbus devices, there will need to be two different Device Profiles, even though the devices are the same and have the same attributes, because the protocol configurations (e.g. HoldingRegister) will conflict. Device Profile - -If the protocol information resides in the Device, which describes a specific (instance of a) device only a single Device Profile is needed as all devices of the same type can use the same Device Profile. This becomes more important as you have more devices, potentially increasing the number and management of Device Profiles when one will do. - -## Existing solutions - - -## Requirements -The requirement is to support the protocol-specific attribute values (e.g. HoldingRegister) in the Device as well as the Device Profile (for backward compatibility). - -- If only the Device contains a protocol-specific attribute, it is used for that device. -- If only the Device Profile contains a protocol-specific attribute, it is used for all Devices that have that Device Profile. -- If both the Device Profile and the Device contain a protocol-specific attribute, the entry in the Device overrides the one in the Device Profile. - -## Related Issues - -## References -- https://github.com/edgexfoundry/device-modbus/blob/master/src/main/resources/MBUS-RTH-LCD.profile.yaml From b1d57ddd1a816bc9a8e95b2b29303bea9427f0f9 Mon Sep 17 00:00:00 2001 From: Darryl Mocek Date: Mon, 6 Nov 2023 15:26:32 -0800 Subject: [PATCH 3/5] feat: Add Protocol-specific Attribute Values in Device UCR. Signed-off-by: Darryl Mocek --- .../design/ucr/Protocol-Info-In-Device.md | 39 +++++++++++++++++++ 1 file changed, 39 insertions(+) create mode 100644 docs_src/design/ucr/Protocol-Info-In-Device.md diff --git a/docs_src/design/ucr/Protocol-Info-In-Device.md b/docs_src/design/ucr/Protocol-Info-In-Device.md new file mode 100644 index 0000000000..5aadcb3bda --- /dev/null +++ b/docs_src/design/ucr/Protocol-Info-In-Device.md @@ -0,0 +1,39 @@ +# Use Case Title +Protocol-specific Attribute Values in Device + +## Submitters +Darryl Mocek (Oracle Corporation) + +## Changelog + +## Market Segments +Any segments using EdgeX with device services that contain protocol-specific values in Device Profile attributes. + +## Motivation +The Device Profile describes the device. There are many different manufacturers of the same type of device (e.g. HVAC). The Device Profile of a specific type of device could used be for many or all of the Devices of that type, reducing the need to duplicate a Device Profile just to account for differences in the protocol-specific attribute values. + +## Target Users +Any users that create Device Profiles and Devices that have protocol-specific attribute values. + +## Description +The Device Profile **describes** the device and its attributes, it's type. Different manufacturers can build the same type of device using different protocols and the same device using the same protocol but different configuration (e.g. different Modbus HoldingRegister). For example, two different manufacturers may build an HVAC using ModBus, and another may build an HVAC using SNMP. In the case of two Modbus devices, there will need to be two different Device Profiles, even though the devices are the same and have the same attributes, because the protocol configurations (e.g. HoldingRegister) will conflict. Device Profile + +If the protocol information resides in the Device, which describes a specific (instance of a) device only a single Device Profile is needed as all devices of the same type can use the same Device Profile. This becomes more important as you have more devices, potentially increasing the number and management of Device Profiles when one will do. + +## Existing solutions + + +## Requirements +The requirement is to support the protocol-specific attribute values (e.g. HoldingRegister) in the Device as well as the Device Profile (for backward compatibility). + +- If only the Device contains a protocol-specific attribute, it is used for that device. +- If only the Device Profile contains a protocol-specific attribute, it is used for all Devices that have that Device Profile. +- If both the Device Profile and the Device contain a protocol-specific attribute, the entry in the Device overrides the one in the Device Profile. + +## Related Issues + +## References +- https://github.com/edgexfoundry/device-modbus/blob/master/src/main/resources/MBUS-RTH-LCD.profile.yaml From ec2f39481afe99b7df2c61eb017375bd1d20e751 Mon Sep 17 00:00:00 2001 From: Darryl Mocek Date: Mon, 6 Nov 2023 16:32:27 -0800 Subject: [PATCH 4/5] feat: Protocol Info In Device Signed-off-by: Darryl Mocek --- docs_src/design/ucr/Protocol-Info-In-Device.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs_src/design/ucr/Protocol-Info-In-Device.md b/docs_src/design/ucr/Protocol-Info-In-Device.md index 5aadcb3bda..dd58202ad7 100644 --- a/docs_src/design/ucr/Protocol-Info-In-Device.md +++ b/docs_src/design/ucr/Protocol-Info-In-Device.md @@ -16,9 +16,9 @@ The Device Profile describes the device. There are many different manufacturers Any users that create Device Profiles and Devices that have protocol-specific attribute values. ## Description -The Device Profile **describes** the device and its attributes, it's type. Different manufacturers can build the same type of device using different protocols and the same device using the same protocol but different configuration (e.g. different Modbus HoldingRegister). For example, two different manufacturers may build an HVAC using ModBus, and another may build an HVAC using SNMP. In the case of two Modbus devices, there will need to be two different Device Profiles, even though the devices are the same and have the same attributes, because the protocol configurations (e.g. HoldingRegister) will conflict. Device Profile +The Device Profile **describes** the device and its attributes, it's type. Different manufacturers can build the same type of device using different protocols and the same device using the same protocol but different configuration (e.g. different Modbus HoldingRegister's). For example, two different manufacturers may build an HVAC using ModBus, and another may build an HVAC using SNMP. In the case of two Modbus devices, there will need to be two different Device Profiles, even though the devices are the same and have the same attributes, because the protocol configurations (e.g. HoldingRegister) will conflict. -If the protocol information resides in the Device, which describes a specific (instance of a) device only a single Device Profile is needed as all devices of the same type can use the same Device Profile. This becomes more important as you have more devices, potentially increasing the number and management of Device Profiles when one will do. +If the protocol information resides in the Device, which describes a specific (instance of a) device, only a single Device Profile is needed as all devices of the same type can use the same Device Profile. This becomes more important as you have more devices, potentially increasing the number and management of Device Profiles when a single one will do. ## Existing solutions ## Requirements -The requirement is to support the protocol-specific attribute values (e.g. HoldingRegister) in the Device as well as the Device Profile (for backward compatibility). +The requirement is to support the protocol-specific attribute values (e.g. HOLDING_REGISTER's) in the Device definition as well as the Device Profile (for backward compatibility). -- If only the Device contains a protocol-specific attribute, it is used for that device. +- If only the Device definition contains a protocol-specific attribute, it is used for that device. - If only the Device Profile contains a protocol-specific attribute, it is used for all Devices having that Device Profile. -- If both the Device Profile and the Device contain a protocol-specific attribute, the entry in the Device overrides the one in the Device Profile. +- If both the Device Profile and the Device definition contain a protocol-specific attribute, the entry in the Device definition overrides the one in the Device Profile. ## Related Issues ## References -- https://github.com/edgexfoundry/device-modbus/blob/master/src/main/resources/MBUS-RTH-LCD.profile.yaml +- https://github.com/edgexfoundry/device-modbus-go/blob/main/cmd/res/profiles/modbus.test.device.profile.yml