feat: Add Device Service System Events docs and update SDK APIs

also fix some broken links

Signed-off-by: Ginny Guan <ginny@iotechsys.com>

docs_src/V3TopLevelMigration.md

@@ -68,7 +68,7 @@ The following are where you can find the configuration migration specifics for i
 
 ### Customized Environment Overrides
 
-If you have custom [environment overrides](../microservices/configuration/CommonEnvironmentVariables/#environment-overrides) for configuration impacted by the V3 changes you will also need to migrate your overrides to use the new name or value depending on what has changed. Refer to the links above and/or below for details for migration of common and/or the service specific configuration to determine if your overrides require migrating.
+If you have custom [environment overrides](./microservices/configuration/CommonEnvironmentVariables.md) for configuration impacted by the V3 changes you will also need to migrate your overrides to use the new name or value depending on what has changed. Refer to the links above and/or below for details for migration of common and/or the service specific configuration to determine if your overrides require migrating.
 
 !!! note
     When using the Configuration Provider, the environment overrides for common configuration are applied to the **core-common-config-bootstrapper** service. They no longer work when applied to the individual services as the common configuration setting no longer exist in the private configuration.

docs_src/about.md

@@ -1,7 +1,7 @@
 # About
 
 EdgeX Foundry is an open source, vendor neutral, flexible, interoperable, software platform at the
-edge of the network, that interacts with the physical world of [devices](./general/Definitions.md#Device), sensors, actuators, and other IoT objects. In simple terms, EdgeX is edge middleware - serving  between physical sensing and actuating "things" and our information technology (IT) systems.
+edge of the network, that interacts with the physical world of [devices](./general/Definitions.md#device), sensors, actuators, and other IoT objects. In simple terms, EdgeX is edge middleware - serving  between physical sensing and actuating "things" and our information technology (IT) systems.
 ![image](./general/EdgeX_middleware.png)
 
 The EdgeX platform enables and encourages the rapidly growing community of
@@ -42,13 +42,13 @@ overall architecture:
     - Distribution
  (allowing for the distribution of functionality through micro services at the edge, on a gateway, in the fog, on cloud, etc.)
     - Deployment/orchestration (Docker, K8s, roll-your-own, ... )
-    - Protocols ([north or south](./general/Definitions.md#South-and-North-Side) side protocols)
+    - Protocols ([north or south](./general/Definitions.md#south-and-north-side) side protocols)
 
 - **EdgeX Foundry must be extremely flexible**
-    - Any part of the platform may be upgraded, replaced or augmented by other [micro services](./general/Definitions.md#Micro-service) or software components
+    - Any part of the platform may be upgraded, replaced or augmented by other [micro services](./general/Definitions.md#micro-service) or software components
     - Allow services to scale up and down based on device capability and use case 
 
-- **EdgeX Foundry should provide "[reference implementation](./general/Definitions.md#Reference-Implementation)" services but encourages best of breed solutions**
+- **EdgeX Foundry should provide "[reference implementation](./general/Definitions.md#reference-implementation)" services but encourages best of breed solutions**
 
 - **EdgeX Foundry must provide for store and forward capability**
     - To support disconnected/remote edge systems
@@ -59,12 +59,12 @@ overall architecture:
     - Bandwidth and storage concerns 
     - Operating remotely concerns
 
-- **EdgeX Foundry must support [brown and green](./general/Definitions.md#Brownfield-and-Greenfield) device/sensor field deployments**
+- **EdgeX Foundry must support [brown and green](./general/Definitions.md#brownfield-and-greenfield) device/sensor field deployments**
 
 - **EdgeX Foundry must be secure and easily managed**
 
 ## Deployments
-EdgeX was originally built by Dell to run on its IoT [gateways](./general/Definitions.md#Gateway). While EdgeX can and does run on gateways, its platform agnostic nature and micro service architecture enables tiered distributed deployments.  In other words, a single instance of EdgeX’s micro services can be distributed across several host platforms.  The host platform for one or many EdgeX micro services is called a node.  This allows EdgeX to leverage compute, storage, and network resources wherever they live on the edge.
+EdgeX was originally built by Dell to run on its IoT [gateways](./general/Definitions.md#gateway). While EdgeX can and does run on gateways, its platform agnostic nature and micro service architecture enables tiered distributed deployments.  In other words, a single instance of EdgeX’s micro services can be distributed across several host platforms.  The host platform for one or many EdgeX micro services is called a node.  This allows EdgeX to leverage compute, storage, and network resources wherever they live on the edge.
 
 Its loosely-coupled architecture enables distribution across nodes to enable tiered edge computing.  For example, thing communicating services could run on a programmable logic controller (PLC), a gateway, or be embedded in smarter sensors while other EdgeX services are deployed on networked servers. The scope of a deployment could therefore include embedded sensors, controllers, edge gateways, servers and cloud systems.
 
@@ -196,7 +196,7 @@ In edge computing, simply collecting sensor data is only part of the job of an e
 - Act quickly on that analysis
 Edge or local analytics is the processing that performs an assessment of the sensor data collected at the edge (“locally”) and triggers actuations or actions based on what it sees.
 
-Why [edge analytics](./general/Definitions.md#Edge-Analytics)?  Local analytics are important for two reasons:
+Why [edge analytics](./general/Definitions.md#edge-analytics)?  Local analytics are important for two reasons:
 
 - Some decisions cannot afford to wait for sensor collected data to be fed back to an enterprise or cloud system and have a response returned.
 - Additionally, some edge systems are not always connected to the enterprise or cloud – they have intermittent periods of connectivity.
@@ -224,8 +224,7 @@ The device service receives the request for actuation, translates that into a pr
 ## Project Release Cadence
 Typically, EdgeX releases twice a year; once in the spring and once in the fall.  Bug fix releases may occur more often.  Each EdgeX release has a code name.  The code name follows an alphabetic pattern similar to Android (code names sequentially follow the alphabet).
 
-The code name of each release is named after some geographical location in the world.  The honor of naming an EdgeX release is given to a community member deemed to have contributed significantly to the project.  A release also has a version number.  The release version follows sematic versioning to indicate the release is major or minor in scope.  Major releases typically contain significant new features and functionality and are not always backward compatible with prior releases.  Minor releases are backward compatible and usually contain bug fixes and fewer new features.  See the project Wiki for more information on [releases, versions and patches](https://wiki.edgexfoundry.org/pages/viewpage.action?pageId=21823969).
-
+The code name of each release is named after some geographical location in the world.  The honor of naming an EdgeX release is given to a community member deemed to have contributed significantly to the project.  A release also has a version number.  The release version follows sematic versioning to indicate the release is major or minor in scope.  Major releases typically contain significant new features and functionality and are not always backward compatible with prior releases.  Minor releases are backward compatible and usually contain bug fixes and fewer new features.  See the project Wiki for more information on [releases, versions and patches](https://lf-edgexfoundry.atlassian.net/wiki/spaces/FA/pages/11670494/Releases+Versions+Patches).
 | Release | Schedule | Version |
 | :------------- | :----------: | -----------: |
 |Barcelona |Oct 2017 | 0.5.0 |

docs_src/design/Process.md

@@ -3,7 +3,7 @@ This document describes the EdgeX use case driven requirements engineering and d
 
 Approved by consent of the TSC on 2022-07-13
 
-Supersedes the processes documented on the [EdgeX Wiki](https://wiki.edgexfoundry.org/pages/viewpage.action?pageId=73663048)
+Supersedes the processes documented on the [EdgeX Wiki](https://lf-edgexfoundry.atlassian.net/wiki/spaces/FA/pages/11668586/Project+Design+Architectural+Decisions)
 
 ## Use Case Driven Approach to Requirements and Design
 Designing an architecture is a very time consuming task. It is best to start that with a solid foundation. The obvious goal is to design an architecture that satisfies the functional requirements, while being secure, flexible, and robust. Requirements are very important factors when designing a system. They should be derived from established, validated, and most importantly, written use cases. To avoid feature creep, the architecture should focus on requirements that are backed by multiple use cases and in the meantime try to remain extensible.

docs_src/general/ServiceConfiguration.md

@@ -12,12 +12,12 @@ Please refer to the general [Common Configuration documentation](../microservice
     |Service Name|Configuration Reference|
     |---|---|
     |core-data|	[Core Data Configuration](../microservices/core/data/Configuration.md)|
-    |core-metadata	|[Core Metadata Configuration](../microservices/core/metadata/Configuration.md#core-metadata---configuration)|
-    |core-command	|[Core Command Configuration](../microservices/core/command/Configuration.md#core-command---configuration)|
+    |core-metadata	|[Core Metadata Configuration](../microservices/core/metadata/Configuration.md)|
+    |core-command	|[Core Command Configuration](../microservices/core/command/Configuration.md)|
 === "Supporting"
     |Service Name|Configuration Reference|
     |---|---|
-    |support-notifications	|[Support Notifications Configuration](../microservices/support/notifications/Configuration.md#configuration-properties)|
+    |support-notifications	|[Support Notifications Configuration](../microservices/support/notifications/Configuration.md)|
     |support-scheduler|	[Support Scheduler Configuration](../microservices/support/scheduler/Configuration.md)|
 === "Application & Analytics"
     |Service Name|	Configuration Reference|

docs_src/getting-started/Ch-GettingStartedDockerUsers.md

@@ -153,7 +153,7 @@ docker-compose logs -f [compose-service-name]
 docker-compose logs -f data
 ```
 
-See [EdgeX Container Names](./quick-start/index.md#REFERENCE-EdgeX-Container-Names) for a list of the EdgeX Docker Compose service names.
+See [EdgeX Container Names](../general/ContainerNames.md) for a list of the EdgeX Docker Compose service names.
 
 ![image](EdgeX_GettingStartedUsrLogs.png)
 *A check of an EdgeX service log usually indicates if the service is running normally or has errors.* 

docs_src/getting-started/Ch-GettingStartedGoDevelopers.md

@@ -55,7 +55,7 @@ This part of the documentation assumes you wish to get and work with the key Edg
 
 To work with the key services, you will need to download the source code from the [EdgeX Go repository](https://github.com/edgexfoundry/edgex-go). The EdgeX Go-based micro services are
 all available in a single GitHub repository download.  Once the code is pulled, the Go micro services are built and packaged as
-platform dependent executables.  If Docker is installed, the executable can also be [containerized](../general/Definitions.md#Containerized) for end user deployment/use.
+platform dependent executables.  If Docker is installed, the executable can also be [containerized](../general/Definitions.md#containerized) for end user deployment/use.
 
 To download the EdgeX Go code, first change directories to the location where you want to download the code (to edgex in the image below).  Then use your **git**
 tool and request to clone this repository with the following command:

docs_src/getting-started/Ch-GettingStartedHybrid.md

@@ -37,7 +37,7 @@ With the EdgeX containers running, you can now download, build and run natively
 
 ### Get the service code
 
-Per [Getting Started Go Developers](./Ch-GettingStartedGoDevelopers.md#Get-the-code), pull the micro service code you want to work on from GitHub. In this example, we use the latest released tag for device-virtual-go as the micro service that is going to be worked on. The main branch is the development branch for the next release. The latest release tag should always be used so you are worked with the most recent stable code. The release tags can be found [here](https://github.com/edgexfoundry/device-virtual-go/tags). Release tags are those tags to do not have `-dev` in the name.
+Per [Getting Started Go Developers](./Ch-GettingStartedGoDevelopers.md#get-the-code), pull the micro service code you want to work on from GitHub. In this example, we use the latest released tag for device-virtual-go as the micro service that is going to be worked on. The main branch is the development branch for the next release. The latest release tag should always be used so you are worked with the most recent stable code. The release tags can be found [here](https://github.com/edgexfoundry/device-virtual-go/tags). Release tags are those tags to do not have `-dev` in the name.
 
 ``` bash
 git clone --branch <latest-release-tag> https://github.com/edgexfoundry/device-virtual-go.git

docs_src/getting-started/quick-start/index.md

@@ -38,7 +38,7 @@ docker compose ps
 *If all EdgeX containers pulled and started correctly and without error, you should see a process status (ps) that looks similar to the image above.*
 
 ## Connected Devices
-EdgeX Foundry provides a [Virtual device service](https://github.com/edgexfoundry/device-virtual-go/tree/{{edgexversion}}) which is useful for testing and development.  It simulates a number of [devices](../../general/Definitions.md#Device), each randomly generating data of various types and within configurable parameters.  For example, the Random-Integer-Device will generate random integers.
+EdgeX Foundry provides a [Virtual device service](https://github.com/edgexfoundry/device-virtual-go/tree/{{edgexversion}}) which is useful for testing and development.  It simulates a number of [devices](../../general/Definitions.md#device), each randomly generating data of various types and within configurable parameters.  For example, the Random-Integer-Device will generate random integers.
 
 The Virtual Device (also known as Device Virtual) service is already a service pulled and running as part of the default EdgeX configuration.
 
@@ -57,7 +57,7 @@ curl http://localhost:59880/api/{{api_version}}/event/device/name/Random-Integer
 
 ## Controlling the Device
 
-Reading data from devices is only part of what EdgeX is capable of.  You can also use it to control your devices - this is termed ['actuating'](../../general/Definitions.md#Actuate) the device. When a device registers with the EdgeX services, it provides a [Device Profile](../../microservices/core/metadata/details/DeviceProfile.md) that describes both the data readings available from that device, and also the commands that control it. 
+Reading data from devices is only part of what EdgeX is capable of.  You can also use it to control your devices - this is termed ['actuating'](../../general/Definitions.md#actuate) the device. When a device registers with the EdgeX services, it provides a [Device Profile](../../microservices/core/metadata/details/DeviceProfile.md) that describes both the data readings available from that device, and also the commands that control it. 
 
 When our Virtual Device service registered the device `Random-Integer-Device`, it used a [profile](https://github.com/edgexfoundry/device-virtual-go/blob/{{edgexversion}}/cmd/res/profiles/device.virtual.int.yaml) to also define commands that allow you to tell the service not to generate random integers, but to always return a value you set.
 

docs_src/microservices/application/Configuration.md

@@ -95,8 +95,8 @@ The tabs below provide additional configuration which are applicable to Applicat
     |Configuration  |     Default Value     | Description |
     | --- | --- | -- |
     | Type | edgex-messagebus*   | Indicates the `Trigger` binding type. valid values are `edgex-messagebus`, `external-mqtt`, `http`, or `<custom>` |
-    | SubscribeTopics | events/#*   | Topic(s) to subscribe to. This is a comma separated list of topics. Supports filtering by subscribe topics. Only set when using `edgex-messagebus` or `external-mqtt`. See [EdgeXMessageBus](details/Triggers.md#edgex-message-bus) Trigger for more details. |
-    | PublishTopic | blank*   | Indicates the topic in which to publish the function pipeline response data, if any. Supports dynamic topic places holders. Only set when using `edgex-messagebus` or `external-mqtt`. See [EdgeXMessageBus](details/Triggers.md#edgex-message-bus) Trigger for more details. |
+    | SubscribeTopics | events/#*   | Topic(s) to subscribe to. This is a comma separated list of topics. Supports filtering by subscribe topics. Only set when using `edgex-messagebus` or `external-mqtt`. See [EdgeXMessageBus](details/Triggers.md#edgex-messagebus-trigger) Trigger for more details. |
+    | PublishTopic | blank*   | Indicates the topic in which to publish the function pipeline response data, if any. Supports dynamic topic places holders. Only set when using `edgex-messagebus` or `external-mqtt`. See [EdgeXMessageBus](details/Triggers.md#external-mqtt-trigger) Trigger for more details. |
 
 === "Trigger ExternalMqtt"
 

docs_src/microservices/application/details/CommandLine.md

@@ -18,5 +18,5 @@ Indicates the service should skip the Core Service's version compatibility check
 
 Sets the service key that is used with Registry, Configuration Provider and security services. The default service key is set by the application service. If the name provided contains the placeholder text `<profile>`, this text will be replaced with the name of the profile used. If profile is not set, the `<profile>` text is simply removed
 
-Can be overridden with [EDGEX_SERVICE_KEY](EnvironmentVariables.md#edgexservicekey) environment variable.
+Can be overridden with [EDGEX_SERVICE_KEY](EnvironmentVariables.md#edgex_service_key) environment variable.
 

docs_src/microservices/application/services/AppServiceConfigurable/details/AvailablePipelineFunctions.md

@@ -412,7 +412,7 @@ Please refer to the function's detailed documentation by clicking the function n
     ```
 
 !!! note
-    The new `TargetType` setting must be set to "metric" when using this function. See the [Metric TargetType](../../../sdk/details/TargetType.md#metric-targettype) section above for more details.
+    The new `TargetType` setting must be set to "metric" when using this function. See the [Pipeline Function APIs](../../../sdk/api/BuiltInPipelineFunctions.md#tolineprotocol) for more details.
 
 ## [WrapIntoEvent](../../../sdk/api/BuiltInPipelineFunctions.md#wrap-into-event)