Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: [UCR] Attribute protocol info in device #1287

Open
wants to merge 5 commits into
base: main
Choose a base branch
from
Open

feat: [UCR] Attribute protocol info in device #1287

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
cf8f98f
feat: Add Protocol-specific Attribute Values in Device UCR.
dmocek Nov 6, 2023
b4d7ee4
fix: Remove file.
dmocek Nov 6, 2023
b1d57dd
feat: Add Protocol-specific Attribute Values in Device UCR.
dmocek Nov 6, 2023
ec2f394
feat: Protocol Info In Device
dmocek Nov 7, 2023
b286b08
fix: Clarified document and added it to the TOC.
dmocek Dec 8, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions docs_src/design/TOC.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -12,6 +12,7 @@
| [Core Data Retention and Persistent Cap](./ucr/Core-Data-Retention.md) | Use Case for capping readings in Core Data |
| [Device Parent-Child Relationships](./ucr/Device-Parent-Child-Relationships.md) | Use Case for Device Parent-Child Relationships |
| [Extending Device Data](./ucr/Extending-Device-Data.md) | Use Case for Extending of Device Data by Application Services |
| [Protocol Info In Device](./ucr/Protocol-Info-In-Device.md) | Use Case for adding Protocol Information into the Device object. |
| [Provision Watch via Device Metadata](./ucr/Provision-Watch-via-Device-Metadata.md) | Use Case for Provision Watching via Additional Device Metadata |
| [Record and Replay](./ucr/Record-and-Replay.md) | Use Case for Recording and Replaying event/readings |
| [System Events for Devices](./ucr/System-Events-for-Devices.md) | Use Case for System Events for Device add/update/delete |
Expand Down
39 changes: 39 additions & 0 deletions docs_src/design/ucr/Protocol-Info-In-Device.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -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 a type of 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 type 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 all the protocol information resides in the Device definition (not just the protocol information, but the attribute-specific protocol information e.g. HOLDING_REGISTERS), 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
<!--
How is the given use case currently implemented in the industry, with or without EdgeX?
List and describe each approach. Highlight possible gaps.
-->

## Requirements
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 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 definition contain a protocol-specific attribute, the entry in the Device definition overrides the one in the Device Profile.

Comment on lines +30 to +35
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem I see with this approach is the common protocol details in the device definition are repeated for every instance of a specific device type. Each time a device object is instantiated the common protocol details have to be known so they can be specified in the device definition. Currently the common protocol details are specified once in the Device Profile and the Define Definitions only contain the device instance specific protocol details

What if the Device Profile Resource attribute could be partition by protocol allowing the Device Services to pick the attributes base on the protocol name already specified in the Device definition.

Something like:

  name: "SwitchA"
  isHidden: true
  description: "On/Off , 0-OFF 1-ON"
  attributes:
    modbus-tcp:
      { primaryTable: "COILS", startingAddress: 0 }
    modbus-rtu:
      { primaryTable: "COILS", startingAddress: 1 }

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree, the fomat of the profile resource attribute is free, so users can define multiple protocol information in the device resources. It's simpler than adding the protocol resource attribute to Device.

## Related Issues

## References
- https://github.com/edgexfoundry/device-modbus-go/blob/main/cmd/res/profiles/modbus.test.device.profile.yml