feat: Create UCR for System Events for Devices

[lenny-goodell]

Prerequsit for #581

Signed-off-by: Leonard Goodell leonard.goodell@intel.com

If your build fails due to your commit message not passing the build checks, please review the guidelines here: https://github.com/edgexfoundry/edgex-docs/blob/main/.github/Contributing.md

PR Checklist

Please check if your PR fulfills the following requirements:

• Changes have been rendered and validated locally using mkdocs-material (see edgex-docs README)

[farshidtz]

Looks good overall. I've made several inline comments.

[JamesKButcher]

Hi @lenny-intel
Some use cases we're seeing relate to being made aware when a device service becomes disconnected from a device. For example when there is a network disconnect between the Modbus Device Service and the Modbus device. Do you think that would be covered by this UCR, or would it warrant a separate use case?

[lenny-goodell]

Do you think that would be covered by this UCR, or would it warrant a separate use case?

@JamesKButcher , Would you also want Connected and Reconnected for that use case? I do think that is a slightly different Use Case, but does it warrant a separate UCR document? @farshidtz , thoughts?

[farshidtz]

Do you think that would be covered by this UCR, or would it warrant a separate use case?

@JamesKButcher , Would you also want Connected and Reconnected for that use case? I do think that is a slightly different Use Case, but does it warrant a separate UCR document? @farshidtz , thoughts?

I think it does make sense to have another UCR document since those aren't about onboarding. At the same time, the UCR title is generic (System Events for Devices) rather than something line "Onboarding System Events for Devices". We could change the title to allow future separate UCRs. Alternatively, we could amend this UCR in a future revision (the new process allows that) to cover connection events.

If we do extend this one right now, we need to further discuss to understand what events are needed. For example, why do we need to distinguish between Connected and Reconnected? Do we need Disconnected too? Should there be a configurable timeout before a device is considered disconnected, to avoid getting numerous events when the connection is unstable? Does Deleted event imply Disconnected?

IMO, if we add a separate UCR or amend this one later, we wouldn't need another ADR since the architecture to support it would become available via the ADR that will design how to tackle system events.

[lenny-goodell]

IMO, if we add a separate UCR or amend this one later, we wouldn't need another ADR since the architecture to support it would become available via the ADR that will design how to tackle system events.

Yea, after thinking about this, I agree as separate UCR doc is warranted. Thinking the Device DTO needs the connection status, then the Updated system event would be sent when the Device Service changes the connection status.

[JamesKButcher]

@lenny-intel @farshidtz ok happy with that. Approved from my perspective

[lenny-goodell]

recheck

[TomBrennan-Eaton]

Would it be within the scope of this UCR to say that the Subscription is required to have the usual CRUD operations?
And whether multiple subscriptions should be handled with separate requests and Identifiers, or done by updating the one subscription for the initiating service?

[lenny-goodell]

Would it be within the scope of this UCR to say that the Subscription is required to have the usual CRUD operations? And whether multiple subscriptions should be handled with separate requests and Identifiers, or done by updating the one subscription for the initiating service?

I think those are design details on show the subscription is accomplished. i.e. message bus or some notification service. For this use case It just need to subscribe, details on how are TBD on the ADR.