A common theme in the technology industry, in general, is that technical issues can arise. Sometimes these technologies we depend on don’t work as expected – a frustrating experience for any end user. In a recent J.D. Power study, it was noted that there’s a climate of high consumer demand for new in-vehicle technology, such as audio, entertainment, and navigation, and that these systems are some of the most problematic categories in today’s new vehicles. In fact, a consumer report on infotainment reported that a vast majority of the 3,148 respondents found infotainment systems “complicated and trouble-prone.” While some of this can be attributed to learning curves, there is no doubt that technical issues can arise with new and old technology.
In looking at telematics specifically, it should come as little surprise that a large amount of data gets generated every day. The data moves from the device to the server and is then presented in easy to view reports for the end user. Should a technical issue occur along the way, root causes must be identified. The purpose of this article is to provide you with a bigger picture of how technical issues are typically identified, in addition to looking at the debugging steps for external technicians.
Since telematics systems are such amazing sources of information that drive business decisions, there’s always an expectation that repairs are prompt. One quick way to the root of an issue is to try to isolate it.
Here’s a map of how a telematics system’s architecture might look like:
Figure 1 presents two axis:
Component: This axis isn’t ordered exactly, it just presents a nice way of categorizing and ordering atomic services necessary to serve core business use cases. It is roughly sorted by number of links used to different types of servers from the web cient (Figure 1 far right) point of view. You can also imagine how other technologies might fit into this picture.Web client: Any device using a telematics portal such as my.geotab.com.
Abstraction scale: this axis shows all logical levels of technology driving each particular piece in the telematics system.External logical interfaces: The external interface of a technology. The data provided through the application programming interface(API) is an example. This level is public and subject to telematics users’ requirements.
The way to understand this technology map is to analyse a concrete example. An example of a business use case is determining the history of trips for a particular device. Here is a possible corresponding map of the input information flow:
Let’s see what the input process for a trips history report is in detail:
This very small business process example is only the input required to get a trips history report. The output process should follow a similar, reverse path. The timings of information flow is often an important detail. The technology map highlights a few useful tricks that can be used on a day where nothing is going right, in addition to covering the five Ws.
Do you have additional tips and idea when it comes to fixing technical issues? If so, please leave your questions and comments in the box below.
If you liked this post, let us know!