A Digression This Week!
Last Friday, I said that Id continue on the Which G is Right for M2M? post ... well, actually, I am going to digress onto another topic for a while and get back to the next installment on that other post later. This past week, I presented a paper at a panel session at the Telit Developers Conference in San Diego. During the presentation, it struck me that the material I was presenting was very relevant to our Aeris user community and that it would be good for me to show the same slides here. So, while things are still fresh, I am going to take the opportunity to present that paper here in the next set of posts.
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 (the first two slides were about Aeris and do not need to be shown here). I had two slides on Device Management and two on Application HostingI will describe the first slide on Device Management today and the other slides in later posts.
It Was a Developers Conference
Since I expected the attendees at Conference to be mostly developers and engineers, I addressed the presentation to themwith real-world information from our experience with Customers deploying M2M Applications. Let me assure you that attempting to condense this experience into four slides was an agonizing process! Selecting just the right list of items from the myriad things to watch out for was not easyclearly I could not cover everything on the topic in the allocated time. Hence, I picked a few major items from our 15 years of experience assisting our Customers with application development and cover these items for Customers to take into account for new M2M Applications. Thus, what I am going to cover here is distilled information and is not a comprehensive listour Sales Engineering staff can help Customers who need development assistance.
Framed as Questions
Rather than abstract information, I decided to frame the points that I wanted to make 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 1
Plan for Scalability
What is the Plan for Growth?
Customers must plan for unit and data throughput growth if they expect to grow and offer a capability and service that their end-users will find useful. This does not mean that all Customers must architect and deploy huge Device Management Databases immediately! Merely that they should design their host solutions to grow without requiring a major overhaul every time they achieve certain unit levels or exceed certain aggregated data throughput. As an example, using a spreadsheet on a PC to manage the Device information (numbers, etc.) is necessarily limitingeven with more recent versions of spreadsheets that can deal with a large number of rows. The spreadsheet may not be on a central server for general access by the Customer personnel who need to have access, etc. It is essential to use databasesperhaps on a Corporate IT server, or in the cloudto manage this information. In particular, using the web services to receive the results from the Aeris AerAdmin systems when units are provisioned, makes it easy to design and scale the databases over time.
Product Needs Complex Installation?
If the application requires field installationi.e., it is not a factory-installed solutionthe installation procedures and training methods must be well written and definitive. Particularly if the installation contains relatively complex procedural steps. For example, one of our Customers experienced difficulty with an after-market automotive telematics unit that required the GPS and cellular antenna to be hidden (it was an automobile theft application!) and they said so in their installation manuals. What they did not anticipate is that a few installers at 12 Volt shops (who were also installing the units at car dealerships) hid the antenna under the rear seat of the car! At the time, the concept of tracking units and GPS location, etc., was a relatively new concept and these people understandably did not know what signal strengths, etc., meant! Needless to say, the quality of service after these installations simply was not acceptable!
Do You Train and Test the Installers?
Often, weaknesses in installation manuals can be overcome with effective installer training, but this requires on-going effort to maintain a high level of quality, since there is usually significant turnover in such personnel. The information content of the installation material can also change as the product changes and refresher training is often necessary. Using third-party installation service companies is a viable option, even though they do need to get good installation manuals and procedures from the start, since they may not be familiar with the application. The better third-party installation service companies can work on the procedures and training manuals with the Customer, to increase the success rates for the installations. And, of course, it is important to test the installers and the procedures periodically. Without ensuring that the information is valid (and updated via feedback too) and that the installers understand changes, problems can arise. Remember that installation costsparticularly for field repairs and changescould significantly exceed the cost of the Device if it is remote and requires special access.
What is the Data Throughput Scaling Needs?
In most M2M applications, the data (whether it is SMS or IP packets) usually traverses the cellular network to the Customer host systems for analysis, display, logging, etc. The Customer systems can crunch the raw information into the necessary display formats and reports. Or take the necessary actions based on the Application requirements. Understanding the throughput volume expectations and handling this quantity of dataparticularly when units are added over timeis crucial to a successful deployment. Systems and network connection speeds to accept the level of data expected, within the timeline of any future system updates, must be implemented to avoid a backlogparticularly if the information is time-sensitive in any way. For example, security alarm events and automobile automatic crash notifications (ACN) must be dealt with rapidly. Dropping the information, or delaying the processing of time-sensitive events, could lead to serious overall Application problems. At Aeris, we stress-test Customers host systems that are using the Application Programming Interfaces (API) to the Aeris systems, to ensure that their systems are capable of receiving data without difficulty. Systems that fail these stress-tests must be modified to ensure that future unit and data quantity growth occurs without issues.
Decide What Information to Keep
Some are Essential Numbers
Clearly, the Customer host systems must record specific information about the Devices in their databases. For example, the Mobile System Identification Number (MSID), Mobile Equipment Identifier (MEID), Integrated Circuit Card Identifier (ICCID) for GSM, etc., are essential to maintain knowledge of the specific radio and unit that is deployed in the field. Often, this must be correlated with the specific Serial Number that the Customer has for their Device and this correlation must be maintained by the Customer. Thus, while some of these numbers can be retrieved from the Aeris AerAdmin systems, Customer-specific information (for example, their own product Serial Number) is unique to them, of course, and must be maintained in the Customer databases. (Note that the AerAdmin systems allow a few custom data fields for use by the Customer for information storage, but this is not a full replacement for this level of detail and data storage.)
Specific Unit Assignments
Of course, the relationship between a specific Device and the actual end-user account information (assuming that the unit is providing service to some other person or entity) must also be maintained by the Customer. This is necessary for billing and other purposes.
Should the Customer Keep Data Content?
The answer to this question has many considerations to take into account. The Customers must review the issues of content privacy, duration of storage, size of the data, etc., when making a decision to keep the Application Data content in their systems. This topic is beyond the scope of Aeris to provide direct assistance to the Customer, because it depends strongly the specific needs of the application, but Aeris can provide general guidance as to what is practical and possible. For example, it is generally fairly easy to store the content of SMS packets (if so desired!)the maximum size of each packet is well-defined and the scaling requirements (based on number of units and number of messages per time period) are relatively easy to quantify and model. However, storing the content of a general IP data stream would be impractical, unless the data content was well understood. For example, if the Device always sends a specific set of engine parameters for a truck on a regular basis, this information can be parsed and stored as needed for later access by personnel who need to know the content.
What and/or When Was the Data Sent?
Sometimes, storing the date and time that a particular item of data was sent, is much more important than the actual content. For example, the information in the transmission may be time-sensitive, and after processing, has little or no value, but noting the act of sending and receiving the data at a particular time might be very important. This storage could be for billing or trace-ability purposes, for example. The logging of SMS traffic can be used to audit bills received from Aeris. Or, it could be used to provide a bill to an end-user Customer of a particular unit. While Aeris provides such detailed information in the monthly bills sent to the Customers, their own storage of this information, on a real-time basis, can be very appropriate for their application.
I will cover the second slide on Device Management.