Merge pull request #2411 from Cumulocity-IoT/feat/DM-3890-changed-DM-…

…title

[DM-3890]: Changed DM title to be title cased.

content/cloud-remote-access/cra-general-aspects-bundle/how-it-works.md

@@ -17,7 +17,7 @@ The following protocols are supported:
 
 See [Supported protocols and gateways](/cloud-remote-access/communication/#supported-protocols) for details.
 
-Cloud Remote Access works as in the illustration below. The remotely controlled device runs a VNC, SSH or Telnet server and is connected to a gateway compatible with Cloud Remote Access. This gateway must be registered as a device within the Device management application in {{< product-c8y-iot >}}. More information about registering devices and instructions can be found in [Registering devices](/device-management-application/registering-devices).
+Cloud Remote Access works as in the illustration below. The remotely controlled device runs a VNC, SSH or Telnet server and is connected to a gateway compatible with Cloud Remote Access. This gateway must be registered as a device within the Device Management application in {{< product-c8y-iot >}}. More information about registering devices and instructions can be found in [Registering devices](/device-management-application/registering-devices).
 
 ![Cloud Remote Access - VNC](/images/cra/cra-VNC2.png)
 

content/cloud-remote-access/cra-general-aspects-bundle/when-to-use.md

@@ -4,7 +4,7 @@ weight: 30
 layout: bundle
 ---
 
-To provide the best level of control, remote devices should be represented as devices in the [Device management application](/device-management-application) of {{< product-c8y-iot >}}, with the corresponding reporting, remote control and real-time functionality.
+To provide the best level of control, remote devices should be represented as devices in the [Device Management application](/device-management-application) of {{< product-c8y-iot >}}, with the corresponding reporting, remote control and real-time functionality.
 
 In some cases however, it is not possible or not economic to implement every aspect of a machine or remote device in a {{< product-c8y-iot >}} agent. For example, in case of a legacy device that does not have APIs for accessing certain parts of the functionality, or in case of a device that has many very low-level configuration parameters that would be very involved to map to {{< product-c8y-iot >}}.
 

content/cloud-remote-access/using-cloud-remote-access-bundle/accessing-cra.md

@@ -4,7 +4,7 @@ weight: 20
 layout: bundle
 ---
 
-In the Device management application in the {{< product-c8y-iot >}} platform, click **All devices** in the **Devices** menu and select the desired gateway from the device list.
+In the Device Management application in the {{< product-c8y-iot >}} platform, click **All devices** in the **Devices** menu and select the desired gateway from the device list.
 
 When you open the gateway you will find the **Remote access** tab in its tab list.
 

content/cockpit/managing-assets-bundle/asset-hierarchy.md

@@ -22,23 +22,23 @@ Assets are organized in hierarchies. For example, an energy monitoring applicati
 
 The asset hierarchy is composed of two types of objects:
 
-* **Groups**: Objects which group single devices or other groups. Groups can either be created in the Cockpit application or in the Device management application.
+* **Groups**: Objects which group single devices or other groups. Groups can either be created in the Cockpit application or in the Device Management application.
 
 * **Custom assets**: Objects defined by an asset model and created in the [Digital twin manager](/dtm/dtm-introduction/) application.
 
-* **Devices**: Devices which are linked into the asset hierarchy. Before you can use devices in the Cockpit application, they must be connected to {{< product-c8y-iot >}}. This is done in the Device management application. For details on connecting devices refer to [Registering devices](/device-management-application/registering-devices/).
+* **Devices**: Devices which are linked into the asset hierarchy. Before you can use devices in the Cockpit application, they must be connected to {{< product-c8y-iot >}}. This is done in the Device Management application. For details on connecting devices refer to [Registering devices](/device-management-application/registering-devices/).
 
 In this example, the group objects represent a building asset. The device objects represent the room asset. The group names and hierarchy can be defined individually by the user. The hierarchy can have multiple levels, like region level, city level, street level, building level, floor level and room level. Any device can be part of multiple and different hierarchies, like part of regional hierarchy and part of customer hierarchy.
 
 To position a device in the asset hierarchy, you must "assign" the device to the respective group (see below).
 
 {{< c8y-admon-info >}}
-Single devices are not managed in the Cockpit application. They are managed in the Device management application.
+Single devices are not managed in the Cockpit application. They are managed in the Device Management application.
 {{< /c8y-admon-info >}}
 
 {{< c8y-admon-related >}}
 - [Getting started > Technical concepts > {{< product-c8y-iot >}}'s domain model](/concepts/domain-model/) for details on {{< product-c8y-iot >}}'s domain model.
-- [Device management > Device management application](/device-management-application/) for details on working with devices in {{< product-c8y-iot >}}.
+- [Device management & connectivity > Device Management application](/device-management-application/) for details on working with devices in {{< product-c8y-iot >}}.
 - Refer to the [{{< product-c8y-iot >}} Codex](https://styleguide.cumulocity.com/apps/codex/#/) for more information on developing applications in the {{< product-c8y-iot >}} environment. Moreover find various related tutorials in the [{{< sag-dev-community >}}]({{< link-sag-tech-forum >}}).
 {{< /c8y-admon-related >}}
 
@@ -69,10 +69,10 @@ The second example shows how gateway devices can be used in the Cockpit applicat
 
 ![Linked gateway devices](/images/users-guide/cockpit/cockpit-groups-image3.png)
 
-Gateway devices are as well represented as top level devices in the Device management application. Their attached devices (like for example Modbus or KNX devices) are shown as child devices. These child devices can be organized in the asset hierarchy in the Cockpit application as shown above.
+Gateway devices are as well represented as top level devices in the Device Management application. Their attached devices (like for example Modbus or KNX devices) are shown as child devices. These child devices can be organized in the asset hierarchy in the Cockpit application as shown above.
 
-As you can see from the example, devices can have completely different hierarchies in the Device management application and in the Cockpit application:
-While inside the Device management application all child devices are below the gateway device, the same child devices are organized in two different buildings in the Cockpit.
+As you can see from the example, devices can have completely different hierarchies in the Device Management application and in the Cockpit application:
+While inside the Device Management application all child devices are below the gateway device, the same child devices are organized in two different buildings in the Cockpit.
 
 ### Cockpit assets versus business assets {#cockpit-assets-versus-business-assets}
 

content/cockpit/managing-assets-bundle/working-with-assets.md

@@ -19,7 +19,7 @@ Moreover, subassets are shown in the **Subassets** tab of the particular group w
 {{< c8y-admon-info >}}
 The count displayed on top of the table on the **Subassets** tab shows the total number of child assets assigned to the current group. Any type of managed object can be a child asset. For more details on the counting of objects refer to the operation [Retrieve all child assets of a specific managed object](https://{{< domain-c8y >}}/api/core/#operation/getManagedObjectChildAssetsResource) in the {{< openapi >}}.
 
-If you add a gateway device, the child devices are not shown. To show child devices, you must add them to the related asset. Details related to the child hierarchy are visible and editable in the Device management application.
+If you add a gateway device, the child devices are not shown. To show child devices, you must add them to the related asset. Details related to the child hierarchy are visible and editable in the Device Management application.
 {{< /c8y-admon-info >}}
 
 Use the navigator, to navigate through the asset hierarchy.
@@ -96,7 +96,7 @@ In the resulting dialog box, you can select to also delete all devices inside th
 
 ### To assign devices to a group {#to-assign-devices-to-a-group}
 
-Before adding a device to the asset hierarchy, it must be connected to {{< product-c8y-iot >}}. Connecting devices to the platform is done in the Device management application. For details on connecting devices refer to [Device management application](/device-management-application/registering-devices/).
+Before adding a device to the asset hierarchy, it must be connected to {{< product-c8y-iot >}}. Connecting devices to the platform is done in the Device Management application. For details on connecting devices refer to [Device Management application](/device-management-application/registering-devices/).
 
 To assign devices to a group, follow these steps:
 

content/cockpit/smart-rules-collection.md

@@ -13,7 +13,7 @@ In certain rule parameters, various trigger fields can be used as variables, see
 {{< /c8y-admon-info >}}
 
 {{< c8y-admon-related >}}
-- [Device management > Monitoring and controlling devices > Working with alarms](/device-management-application/monitoring-and-controlling-devices/#working-with-alarms) for details on alarms in {{< product-c8y-iot >}}.
+- [Device management & connectivity > Monitoring and controlling devices > Working with alarms](/device-management-application/monitoring-and-controlling-devices/#working-with-alarms) for details on alarms in {{< product-c8y-iot >}}.
 - [Analytics > Streaming analytics > Troubleshooting and diagnostics > Alarms generated by the Apama-ctrl microservice](/streaming-analytics/troubleshooting/#alarms) for more information on alarms for smart rules generated by the Apama-ctrl microservice.
 - [Alarms](https://{{< domain-c8y >}}/api/core/#tag/Alarms) in the {{< openapi >}} for details on managing alarms via REST.
 {{< /c8y-admon-related >}}

content/concepts/applications-bundle/extensible-device-registration.md

@@ -20,7 +20,7 @@ Extensible device registration requires [application extensions](/concepts/appli
 
 The extended device registration provides the following advantages:
 
-- **Extensibility of the device registration wizard**: You can easily add own forms to the device registration wizard in the Device management application UI. The values to be entered in the user-specified forms can be freely customized by the device integration developers.
+- **Extensibility of the device registration wizard**: You can easily add own forms to the device registration wizard in the Device Management application UI. The values to be entered in the user-specified forms can be freely customized by the device integration developers.
 
 - **Support for bulk registration using custom CSV**: You can customize the bulk registration and hence implement support for CSV files of a different format.
 
@@ -62,7 +62,7 @@ There are two types of extensions:
 
 ### Single device registration {#single-device-registration}
 
-After enabling the `extensibleDeviceRegistration` extension type, the **Devices** > **Register device** menu in the Device management application is extended with an entry corresponding to the extension `name` property.
+After enabling the `extensibleDeviceRegistration` extension type, the **Devices** > **Register device** menu in the Device Management application is extended with an entry corresponding to the extension `name` property.
 
 From now on, everything will be rendered based on data provided via the custom microservice. The added menu entry opens a window which fetches the form definition using the following endpoint:
 
@@ -170,7 +170,7 @@ The following diagram visualizes the single device registration flow:
 
 Many device integrations require the registration of many devices at the same time. Currently, all protocols must rely on the bulk registration mechanism of the platform, which often either requires too many fields or requires custom fields to be added. The latter ones can however so far not be validated, as the core directly creates devices -- and microservices and agents have no control over the properties being written to the managed objects.
 
-After enabling the `extensibleBulkDeviceRegistration` extension type, the Device management > Devices > Register device  `Bulk device registration` modal is displayed with an extended wizard entry corresponding to the extension `name` property.
+After enabling the `extensibleBulkDeviceRegistration` extension type, the Device management & connectivity > Devices > Register device  `Bulk device registration` modal is displayed with an extended wizard entry corresponding to the extension `name` property.
 
 Additionally, the microservice provides the title of the wizard step and example bulk file(s):
 ```json

content/concepts/interfacing-devices.md

@@ -15,7 +15,7 @@ To interface these systems with {{< product-c8y-iot >}}, a driver software calle
 {{< c8y-admon-related >}}
 
 - [Getting started > Technical concepts > {{< product-c8y-iot >}}´s domain model](/concepts/domain-model) for understanding the data structures exchanged between agents and the {{< product-c8y-iot >}} core.
-- [Device management > Device integration](/device-integration) for understanding in detail how to develop agent software using the REST or MQTT protocols.
+- [Device management & connectivity > Device integration](/device-integration) for understanding in detail how to develop agent software using the REST or MQTT protocols.
 - [REST implementation](https://{{< domain-c8y >}}/api/core/#section/REST-implementation) in the {{< openapi >}}, for a detailed specification of the interfaces between agents and the {{< product-c8y-iot >}} core.
 
 {{< /c8y-admon-related >}}

content/data-broker/data-broker-application-bundle/data-subscriptions.md

@@ -27,7 +27,7 @@ Use the toggle to temporarily stop forwarding data into your tenant.
 3. When the connection is established, click **Accept** to start forwarding data into your tenant. The subscription is active now.
 4. You can use the toggle in the card to temporarily stop forwarding data into your tenant.
 
-You can now navigate to the Device management application or the Cockpit application. You will find a new "virtual group" with a specific icon <i class="c8y-icon c8y-icon-group-remote c8y-icon-duocolor"></i> showing the forwarded devices. The group will have the same name as your subscription. Devices are "lazily" created on the destination side whenever they send data for the first time after setting up an active subscription.
+You can now navigate to the Device Management application or the Cockpit application. You will find a new "virtual group" with a specific icon <i class="c8y-icon c8y-icon-group-remote c8y-icon-duocolor"></i> showing the forwarded devices. The group will have the same name as your subscription. Devices are "lazily" created on the destination side whenever they send data for the first time after setting up an active subscription.
 
 ![Data broker group in cockpit app](/images/users-guide/enterprise-tenant/et-data-broker-group-created.png)
 

content/datahub/working-with-datahub-bundle/configuring-offloading-jobs.md

@@ -230,7 +230,7 @@ The first time an offloading run processes multiple fragments with the correspon
 
 ##### Raising alarms {#raising-alarms}
 
-Offloading as well as compaction runs may fail due to various reasons such as network issues and timeouts. As described in [History per offloading pipeline](/datahub/working-with-datahub/#history-per-offloading-job) and [History of compactions per offloading pipeline](/datahub/working-with-datahub/#history-compaction-per-offloading-job), the offloading and compaction job histories provide details for successful and failed runs. Additionally, an alarm can be raised within the {{< product-c8y-iot >}} platform in case of a failure. Such an alarm is available in the {{< product-c8y-iot >}} [Device management application](/device-management-application/monitoring-and-controlling-devices/#working-with-alarms).
+Offloading as well as compaction runs may fail due to various reasons such as network issues and timeouts. As described in [History per offloading pipeline](/datahub/working-with-datahub/#history-per-offloading-job) and [History of compactions per offloading pipeline](/datahub/working-with-datahub/#history-compaction-per-offloading-job), the offloading and compaction job histories provide details for successful and failed runs. Additionally, an alarm can be raised within the {{< product-c8y-iot >}} platform in case of a failure. Such an alarm is available in the {{< product-c8y-iot >}} [Device Management application](/device-management-application/monitoring-and-controlling-devices/#working-with-alarms).
 
 Under **Create alarm on** you can activate raising alarms for offloading as well as compaction failures. Per default, the setting is activated for offloading and deactivated for compaction failures. When activated and an offloading run fails, an alarm is raised. If the offloading fails multiple times in a row, the associated alarm is updated with each new failure. The more successive runs fail, the higher the severity of the alarm will be, ranging from warning up to critical. Each alarm comprises information which offloading pipeline has failed and how often it has failed in a row. The same applies to alarms being raised for compaction failures.
 

content/device-integration/device-certificates.md

@@ -53,7 +53,7 @@ The device_user will be created when the API is called for the first time, provi
 
 **Bulk registration**
 
-The user for the device can also be created via the standard [bulk registration](/device-management-application/registering-devices/#to-bulk-register-devices) in the Device management application.
+The user for the device can also be created via the standard [bulk registration](/device-management-application/registering-devices/#to-bulk-register-devices) in the Device Management application.
 
 The CSV file used in bulk registration should meet the requirements described in [Create a bulk device credentials request](https://{{< domain-c8y >}}/api/core/#operation/postBulkNewDeviceRequestCollectionResource) in the {{< openapi >}}. Moreover, it is required that the CSV file has an additional column AUTH_TYPE with value CERTIFICATES, and that the column CREDENTIALS is either not present or has an empty value.
 
@@ -330,7 +330,7 @@ Upload your CA (or intermediate) certificate to the platform. This operation wil
 
 **Via UI:**
 
-1. In the Device management application, navigate to the **Management** menu in the navigator and select **Trusted certificates**.
+1. In the Device Management application, navigate to the **Management** menu in the navigator and select **Trusted certificates**.
 2. In the resulting dialog, enter a custom name for the new certificate.
 3. Drop your CA certificate (caCert.pem or intermediateCert.pem).
 4. Select the **Auto registration** check box.
@@ -377,7 +377,7 @@ To ensure verification of ownership by the uploader, a proof of possession is re
 
 The steps for the proof of possession are as follows:
 
-1. Navigate to **Management** > **Trusted certificates** in the Device management application and verify that the certificate has been uploaded properly.
+1. Navigate to **Management** > **Trusted certificates** in the Device Management application and verify that the certificate has been uploaded properly.
    <br>![Verify certificate](/images/mqtt/mqtt-cert-check.png)
 
 2. In the **Proof of Possession** section of the certificate details, download the verification code.