feat: Create UCR for System Events for Devices

docs_src/design/TOC.md

@@ -1,4 +1,11 @@
-# ADR Table of Contents
+# Use Cases and Design Records
+
+## Use Case Records (UCRs)
+| Name/Link                                                                 | Short Description                                             |
+|---------------------------------------------------------------------------|---------------------------------------------------------------|
+| [0001 System Events for Devices](./ucr/0001-System-Events-for-Devices.md) | Use Case for System Events for Device add/update/delete |
+
+## Architectural Design Records (ADRs)
 
 | Name/Link                                                            | Short Description                               |
 | -------------------------------------------------------------------- | ----------------------------------------------- |
@@ -23,4 +30,4 @@
 | [0020 Delay start services (SPIFFE/SPIRE)](./adr/security/0020-spiffe.md)                      | Secret store tokens for delayed start services          |
 | [0021 Device Profile Changes](./adr/core/0021-Device-Profile-Changes.md)                      | Rules on device profile modifications          |
 | [0022 Unit of Measure](./adr/core/0022-UoM.md)                                                                       | Unit of Measure|
-| [0023 North South Messaging](./adr/0023-North-South-Messaging.md)                              | Provide for messaging from north side systems through command down to device services |
+| [0023 North South Messaging](./adr/0023-North-South-Messaging.md)                              | Provide for messaging from north side systems through command down to device services |                       | Provide for messaging from north side systems through command down to device services |

docs_src/design/ucr/0001-System-Events-for-Devices.md

@@ -0,0 +1,49 @@
+## System Events for Devices
+### Submitters
+- Lenny Goodell (Intel)
+
+### Change Log
+- [pending](https://github.com/edgexfoundry/edgex-docs/pull/779) (2022-06-22)
+
+### Market Segments
+- All or Any segments that can take advantage of auto on-boarding of new devices and auto start some AI/ML processing on the data from the new devices.
+
+### Motivation
+When a new camera device is added to the system only Core Metadata and the Device Service managing the new camera device are aware. There are use cases when other parts of the  system need to know when a new device has been added to the system. This UCR will focus on the camera management uses case which illustrates the need for these new System Events.
+
+### Target Users
+- Device User
+- Software Deplorer
+- Software Integrator
+- Deployment Customer
+
+### Description
+System Events (aka Control Plane Events - CPE) are events generated by the system when there are changes in part of the system that are important for other parts of the system to know about. This UCR will focus on the Device System Events use case as related to camera management. These Device System Events could be utilized by many other use cases in similar manner.
+
+The new EdgeX USB and ONVIF camera Device Services (not yet released) implement auto provisioning which detects when a new camera device has been connected to USB or added to the network. New Device objects are created in Core Metadata for the new camera devices that have been auto provisioned. The auto provisioning also detects existing known camera devices, determines if there have been changes to the device details, such as IP address, and updates the Device object in Core Metadata with any changes. Device objects can also be manually deleted from Core Metadata once camera devices have been permanently disconnected.
+
+A camera management application service needs to know when a new camera has been added so that it can initiate AI/ML processing on the stream from the new camera. The service also needs to know when an existing camera device has been updated so that it can make any needed adjustments such as restart the AI/ML processing using the new IP address of the camera. Finally the service needs to know when an existing camera device has been removed so that it can stop the AI/ML processing for the removed camera.
+
+### Existing solutions
+Parts of the system (i.e. application service) must poll Core Metadata for list of devices to determine if a device has been added, update or deleted. To do this it must keep its own list or Device objects for the know devices to make these determinations.
+
+As a temporary stop gap for the initial upcoming release of the new ONVIF camera device service, an enhancement was added which publishes an EdgeX Event/Reading when a new camera device has been added, updated or modified. The Reading contains the information about the event type and the device name. This is improper use of the EdgeX Event/Reading which is intended for readings from devices, not System Events. This feature in the ONVIF Camera Device Service will be removed once System Events for Devices are in place.
+
+### Requirements
+- Added/Updated/Deleted Device System Events are created and sent in a manner that other parts of the system can subscribe and receive them.
+
+- Each System Event must contain at a minimum the following:
+
+  - Event Type: Added, Updated or Deleted
+  - Device Name
+    - All that is needed to send a command to the device to get the stream URL or stop the AI/ML processing
+
+
+!!! note
+    Other details about the device, if not present in the System Event,  can be queried from Core Metadata using the Device Name
+
+### Other Related Issues
+- None
+
+### References
+- None