Connected Field Service – Part 1


IoT is a hot topic at the moment, the number of connected devices is set to explode to 30 billion devices by 2020. Recently there have been a number of requests, especially from manufacturing prospects to help with IoT projects. Many manufacturers have been using IoT in a format for years through systems like SCADA, using the cloud we can now extract expand on this and extract more value from connected devices. The cloud has really enabled capturing of vaster quantities of data and running advanced workloads like machine learning at speed. Furthermore the cloud enables companies to develop these workloads in a cost effective manner, testing machine learning experiments, tweaking and re-running. With the ability to discard an experiment (or service) without an ongoing cost.

One key area of value is for companies to drive down the cost of their operations, this falls into one of the main pillars of digital transformation. Microsoft is well positioned to help customers like Manufacturers reduce operating costs, a key solution that can enable this is Connected Field Service. Connected Field Service enables customers to monitor devices around the world for changes in status. These statuses can cause thresholds to fire actions which in turn can automatically create a alert within the D365 service and/or another(eg a logic app). At this point it is easy to start applying business impact to that alert, the device that triggered it is known as is the function of the device and who (which customer) it is working for. It is possible with this information to create new premium services that can increase the revenue of a field service operation. Furthermore with early warning to better optimise the service engineers so they can make more visits, reducing the cost which additionally will increase profitability of the field service operations.

Over a series of three technical blogs we will step through how to configure 'Connected Field Service' to run with remote monitoring and use a physical device to create alerts.

For the first blog we will configure the connected field service solution out of the box and use the simulated device to create alerts.

Requirements

  • D365 environment with a Plan 1 license (it is possible to use a trial but it will expire after 30 days)
  • Field Service App in D365
  • Azure subscription (it is possible to use a trial but it will expire after 30 days)

This configuration can be done in a trial environment however the environment will expire after 30 days. To get an Azure trial environment a credit card is required for verification, by default no money is taken from the credit card. If you have access to an Azure subscription (e.g. with MSDN or other test areas) the overall usage for this solution is about $50 per month, although make sure to downgrade the IoT Hub to S1. S1 can handle multiple devices and should have plenty of messages to survive each day's use.

Connected Field Service [CFS]

CFS can be deployed via AppSource, the installation is simple and going the process deploys both the entities needed in D365 and the Azure elements. The process is really simple to go through and can be deployed in under an hour.

cfs - from Appsource

The url below guides admin through the steps to get CFS deployed (the PowerBI section is optional and it is possible to create PowerBI stream easily manually after the install).

https://www.microsoft.com/en-us/dynamics/crm-customer-center/use-connected-field-service-to-remotely-monitor-and-service-customer-equipment-field-service.aspx

Stepping through the guide will deploy a new app within D365. Within the D365 navigation bar there will be an App for Internet of Things. This along with related entities is deployed by CFS. This provides everything that is required to get started with CFS.

d365entities

The entities deployed are:

  • Registered Devices - register a device to a customer or customer asset
  • Device Categories - for grouping, such as Thermostat
  • Registration History - whether a device has been registered with IoT Hub
  • Commands - messages that can be sent to a device, such as restart
  • IoT Alerts - when a threshold limit is exceeded, such as temperature > x
  • Dashboard - dedicated dashboard that shows Iot Alerts over time and by customer

It is simple to set up a simulated device from here to verify that the solution is working properly. In D365 click registered devices then click 'New'. Complete the device details, making sure that you put a descriptive DeviceID in. Then hit save, this should make a 'Register Device' button appear on the top ribbon. Hitting this will register a device.

There is a simulator deployed with CFS that can be used to quickly test whether a device is registered and sending data into IoT Hub properly. The simulator can also be used to spike Humidity or Temperature to see if an alert is raised in D365 (by default only spiking Temperature will raise an alert).

capthkgljghilure

There is now a device that can be run in the simulator. The simulator runs within Azure and was created as part of the installation process.

A quick guide on using the simulator, it can be launched through the Azure portal (it is easier to go through the portal because the URL has a Unique ID appended to it which makes it hard to find the first time). The simulator is a app service called Simulator<environmentname><uniqueID>. On launch it will require connection to be setup. which includes the 'Hostname', 'Policy Name' & 'Key'. These can all be found in the Azure portal within the IoTHub in the resource group, there is an image below showing the fields. More information on the resources can be found below however to get the simulator working.

simulator

The <Host> can be found on the overview tab of the IoTHub, its important to note that you only require the hostname. For example <HOSTNAME>.azure-devices.net. The <Policy Name> can just be left as iothubowner, this references the 'shared access policy' that will be used to connect. This can be found in the IoTHub under settings, shared access policy. It is important to grab the <Key> from within the shared access policy as highlighted in the diagram.

iothubdetails

Once this has been configured the drop-down box for 'Device ID' on the simulator will be populate. Selecting a device will push values out and the temperature & humidity dials can be clicked on to change the out going values. NOTE: when there can be differences between browsers, I found that I could click the dials in Edge & Chrome however in Firefox I was unable to, so please try other browsers if you experience the simulator being unresponsive.

Azure Connected Field Service Resource Group

A quick look at the components that have been deployed within Azure show the following components:

  • 3x App Service
  • 2x Logic Apps
  • 1x Stream Analytics
  • 1x Storage Account (includes 1 Blob)
  • 2x API Connection
  • 1x Service Bus
  • 1x Web App
  • 2x App Service
  • 1x IoT Hub
  • 1x Service Plan

 

More details on the underlying Azure architecture and resources can be found here: https://msdn.microsoft.com/en-us/library/mt744253.aspx

Summary

In this blog we have seen how quickly Connected Field Service can be deployed. Which provides a data model in D365 for monitoring and attaching devices to customer records. This works with standard Field Service capabilities which means core propositions such as SLA's, entitlements, schedule optimisation and customer self-service are all easily available as value additions to D365 customers. 

Next time we will look at how to take CFS and connect it to a real physical device so that a Proof of Concept can quickly be run demonstrating data from real sensors triggering a field service response.

The second part can be found here.


Comments (0)

Skip to main content