Microsoft and Google recently announced their HealthVault and GoogleHealth offerings as they vie for medical M2M ownership. What these offerings fail to acknowledge is the need for highly optimized, end-to-end platforms, including simple-to-set-up, cheap, secure data acquisition devices, if M2M applications such as healthcare are to grow exponentially.
For years the M2M market has largely been an area of idle curiosity, albeit a very lucrative one for a number of consulting companies. It's personified by interesting highly vertical applications like truck-fleet management or trackside monitoring of Formula One race cars.
Remote healthcare, traffic systems (road tolling), and energy monitoring - key application areas for M2M - are all about data. In essence, M2M involves retrieving data from an "asset", whether it's the health parameters of an individual, the where and how a vehicle is being driven, or the energy consumption of a washing machine. M2M networks are all about making a reliable connection to the asset to acquire the data, collecting the data on a central database, and then analyzing it. Equally important, though often forgotten, is the feedback based on the analysis, whether that is personal medical advice, a road-tolling bill, or controlling when the washing machine is allowed to run.
Because M2M networks are perceived as ultimately being about data, companies like Microsoft and Google see themselves as potential market leaders. However, the buzz around these product announcements obscures what has been one of the major stumbling blocks for the deployment of massive M2M networks - the physical mechanism of retrieving data from assets. Most of today's M2M deployments typically number in the hundreds or low thousands of users and are based on proprietary systems and hardware. However, the potential market for healthcare deployments, for example, is not in the tens of thousands, but in the millions, if not hundreds of millions. These deployments are not going to be achieved purely by offering a well designed database and middleware APIs, but rather by offering an end-to-end platform, including the data acquisition/communication pieces as well.
Missing the point
One misconception concerning M2M networks is the failure to understand that most of the assets that will require monitoring are not going to want to do it via a PC platform. Nor are they going to incorporate an embedded PC.
For one thing, it's too expensive. In healthcare, for example, the required data is likely to be as simple as a pulse-rate, temperature measurement, or the output from a bed-occupancy sensor - "occupied" or "not occupied". There's an important distinction to be made here. Exciting assets like monitoring and tuning the engine parameters of a Ferrari on a race course can afford expensive data collection and transmission solutions; every day assets can't.
Another factor is that assets will have different communication needs. Medical devices will want to communicate wherever they are, so they probably need to link via a mobile phone. In the case of assisted-living sensors, they'll need to talk to a cheap and simple home gateway. The same is true for domestic energy monitors. Automobiles will talk to roadside sensors using short range wireless networks.
The majority of these devices are unlikely to incorporate a cellular or conventional broadband link themselves. Instead they will rely on a lower-cost, lower-power wireless connection to a gateway device, which may be a residential box, municipal network, or mobile phone.