"We measure our reality according to our experience. As our experience expands, our reality is also altered." - Chin-Ning Chu, business author and management expert
I ran across this quote and thought it perfectly summarized the life of a remote service program. All programs begin with a goal. That goal leads to a set of requirements or constraints that define the solution. Once the solution is deployed, the process of experience begins. Only then do you begin to learn what you didn't know that you didn't know.
We see this often at Axeda as we work with new customers. A set of 10, 30, or 100 data values are determined to be important sources of diagnostic information or business value. As the support engineers work with the data provided, they begin to learn new things about how the connected assets operate in the real world. It may be alarm conditions that occur more (less) frequently than expected, a particular variable that doesn't correlate to a problem cause, or some variable that is useful but not recorded frequently enough.
At the same time, the support engineers find that there are problems for which the existing variable sets are not helpful or definitive enough. The problem may be detected, but you can't tell which subsystem is actually the root cause and thus what parts may be needed to affect the repair. This leads to a wish list of desired variables. In many cases, the team looks at the list, does a virtual slap on the head, and says, "I can't believe we didn't think of that one!"
What next? Everyone looks at the leader of the remote support program and asks the obvious question, "Can you drop these variables that we don't need and replace them with the ones that we do need?"
This is one example where you need the ability to not only change the Agent functionality, but also to cost effectively deploy those changes into the field. The remote service program should not create the need to dispatch technicians just to solve problems with the system that was supposed to reduce dispatches!
The solution requires intelligent Agent design and software update tools to push out new updates. The Agent must be capable of being updated while it is running, i.e., you have to use the Agent to transport the updates and then reliably execute the update without losing communication with the server. Otherwise, you just bought an extra service dispatch.
The system must also have the tools to manage software updates so you can know Agent versions and which versions have been upgraded. The software update process has to consider how updates are defined, tested, and deployed.
Let's look at an example. A new variable is to be collected and reported by an Agent. With Axeda ServiceLink, this usually requires the distribution of new Agent configuration file(s). Step 1 is to create the new files and run them through the full testing and validation process. Once the new configuration files are released, they can be packaged into a software update. The package should include checking for prerequisites, file management, file upload/download, and update execution, all while reporting status. The completed package should then go through a round of testing and validation with special attention to handling any edge cases that may be found in the deployed systems (e.g., different file paths or file locks). Only when the package is fully tested should it be made available in the system for deployment.
It is important to consider how updates will be deployed. In some cases, an update should be sent to every Agent in the device population. In other cases, you may only want to send it to a particular region, customer, or only as the result of a support case. Pushing updates may be something that is limited only to specific people or under a controlled procedure. These choices may flow directly into the decisions around user management and privileges.
One last area to consider is the impact to customers as they receive a new update. Some may be able to take an update any time the machine is in Standby mode. Others may have strict requirements that an update can only be applied during a Scheduled Maintenance window. Others may only want to receive an update under control of a local attendant. The software update process should account for this user input and operate accordingly.
The Internet is a dynamic place. Things change all the time. Your knowledge of how your machines or systems work in the field will also change as you gain experience. The remote service evaluation process should carefully consider the options around how Agent updates will be managed. Assuming an asset life of three to ten years, the change management and change deployment process can have a dramatic impact on the total cost of ownership of the remote service program.