Continuing from Last Week
Last Friday, I digressed onto the topic of a presentation I did at the Telit Developers Conference in San Diego, to cover material that is very relevant to our Aeris user community.
Device Management and Application Hosting
The panel session was entitled Device Management and Application Hosting, which I covered in my allocated 15 minutes with four relevant slides. Today, I cover the second slide on Device Management.
Framed as Questions
As a reminder, rather than abstract information, I decided to frame the points as questions and comments to think about when developing applications. Ideally, this caused people at the Conference (and readers here too!) to think of the concepts behind the question and the ramifications of a particular answer, rather than simply taking my bullet points at face value.
Device Management Slide 2
Understand Your Access to Units
What is Your Plan for Firmware Issues?
After Customers deploy their units into the field, it is not unusual for Devices to need an update. In our multiple years of existence, experience with hundreds of Applications shows that Customers who plan ahead for such updates are more successful. From a Device perspective, this means that the hardware and firmware design must allow for firmware updates appropriately, depending on the update method of choice. For example, if a human does the work manually, then the Device may not need extra memory to hold multiple firmware imagesthe update can be a reload of the entire firmware. And the person doing the update can check for proper operation. However, if it is a remote update (without human intervention), the Device must be able to hold multiple versions, validate the updates, and recover gracefully from mishaps. Some Customers have added a USB port to their Devices, and automated software for simpler field updateseliminating the need for a programming device (for example, a PC).
How Expensive is it to Send a Tech?
The issue is access to the unit! This access requirement has multiple facets to consider. In some deployments, the Application usage pattern allows for opportunities to touch the Deviceperhaps when brought in for service for other purposes. If a particular update can wait for such touch occasions, it may mitigate the cost issues considerably. In other cases, updates may require a technician dispatch (or truck-roll). Depending on the distances involved and complexity of the work, this truck-roll may be expensive enough to justify early development to assist the process. In large nationwide deployments, it may be worth signing on with a service company that can deal with the remote Devices.
Many Units to Update?
Of course, the updates can get very expensive if the number of Devices is largeparticularly if the change requires truck-rolls. If updates are likely, planning ahead for ways other than a truck-roll is important. For example, implementing Firmware Over-the-Air (FOTA) updates may prevent cost issues. The unit may be accessible by an end-user owner, and they could perform the update. Or even return the Device for a swap out! If the process involve a swapi.e, an old Device is changed out for an updated Deviceback-end systems may also need updates (for example, to associate the new Device numbering information with the old account).
Are Your Devices Capable of FOTA Updates?
In all likelihood, any FOTA update will be large enough to require packet-radio services to download the new code. If the Application does not use packet-radio as a normal data delivery method, it may still be worth implementing the support for these updates via packet-radio. This also means that the download code must be independent from the application code being updated, as well as validation (code check-sums, operational checks, and automatic roll-back on errors) prior to the final update. The hardware must also accommodate the necessary design elements to support FOTA. For example, the download generally requires extra flash (non-volatile) memory to hold more than one copy of the code being downloaded and updated.
Plan for End-of-Life and Replacements
Similar to Device updates, planning for End-of-Life (EOL) or replacement of the unit is important. If the Device is installed inside something elsefor example, an after-market telematics unit inside a carremoving, or replacing, it may require a lot of work and effort. Indeed, this process may be tougher than the installation complexities mentioned in last weeks post.
How Do You Replace Non-Functional Units?
In addition to the complexities associated with removing or replacing non-functional Devices, the back-end systems may need to be modified to accommodate such swaps. For example, the new Device numbers may need to be associated with the account in Customer billing systems. The Aeris AerAdmin system may need to be accessed to cancel the old Device, etc. Basically, a careful and documented process must be developed and deployed to make this all work cleanly!
Can You Remove Cancelled Units?
Often, the cancelled Devices should be removed from service cleanly. Else they may continue to try and acquire cellular service, for example, and impact service for other units. In the cellular handset world, this is generally not a problem since the handsets use batteries that will eventually lose their charge.
How to Permanently Remove Devices?
However, with M2M Applications, the Devices are often connected to very good power sourcesfor example, battery of a car or truck, or plugged into a wall socketand removing these units from service is not as easy as handsets. Experience shows that building software and hardware mechanisms to permanently remove a Device from service (i.e., one that is not specifically retrieved from the field) is quite important. for example, the power to the radio Module can be controlled by a relay (or equivalent) and code should be implemented to allow for permanently preventing power being applied to the Module once the Device application firmware knows the unit is cancelled.
What is Your Application EOL Process?
In the event that an entire Application is removed from service over time, it is best to ensure that the large scale Device removal process is properly managed. The Devices must be Cancelled in the Aeris AerAdmin system, for example, to avoid being billed for Devices that are no longer in service. The back-end host systems may also need to be turned down or disconnected as needed. The connections to various Aeris systems (such as AerFrame, AerAdmin, AerTraffic, etc.) must be modified to prevent sending messages that might accidentally re-activate Cancelled Devices, while still properly servicing new Applications and new Devices.
The Bottom Line? Planning is Essential!
In general, planning for Device and Application removal, once the product and service have reached their EOL, is almost as important as getting the Application commercially deployed in the first place!
I will cover the first slide on Application Hosting.