A recent article, "M2M In The Cloud: It's Taking Shape", indicated that the combination of silo solutions and apps that run on proprietary middleware platforms has, until recently, inhibited machine-to-machine technology’s into standards-based, open systems environments. That situation is set to change: standards and a new high-level M2M (machine to machine) architecture have been defined and agreed on, but implementation will take time.
The standardization process started two years ago and the business case for integrating the relevant M2M applications into the mainstream business environment is compelling. This means that there has been a vacuum; and vendors, like nature, abhor a vacuum. Some solutions are marketed under the M2M Cloud banner but lack the requisite functionality. Some can be seen as hybrid solutions and they are effective. Once such solution is covered in this article. But there is one that checks all the cloud-centric boxes--and there are a lot of boxes to check.
Simple Concept, Complex Model
M2M communications is based on a very simple concept. Measure a quantifiable parameter; convert the analog data in TCP; transmit over an IP network, most often cellular; and convert the data into actionable information. However, that process involves several players, and solutions are realized via an ecosystem.
The lead player--the solution provider--might appear to be the mobile network operator, but in reality the vendor who realized the solution, i.e., created the application, is often a very small company. Therefore the average value chain--the basic M2M model--has a couple of downsides. It can take up to a year to develop the application because it's a long chain, and small companies do go bankrupt, so who gets to pick up the pieces?
The Delivery Challenge
It's clear that the vertical silo model as described in my previous article cannot map to the flat architecture of enterprise environments, nor can it provide cloud-centric M2M services. There are a number of intrinsic issues. Fixes can be engineered, but it takes time and it costs.
The challenge can only be met by starting with a clean slate, which is what the three vendors covered in this article did. Their solutions are distinctively different but at the same time, they all deliver cloud-centric functionality.
SensorLogic has created a model that handles the complex underlying architecture that is required in virtually all enterprise-grade M2M applications. Network operators, device manufacturers, software vendors and system integrators can use it. No surprises there. The difference in this case comes from the fact that it also allows ICT (information and communication technology) departments to create different applications relatively easily and quickly and to manage them as a unified set of services.
The model is based on a service delivery platform (SDP) that's hosted on site or in the vendor's data center. That platform comprises embedded software, mobile communications, device protocols, provisioning, and real-time data processing technologies combined with advanced Web services, security, data management, and scalable cloud technologies.
These building blocks are needed in order to offload the development of the requisite M2M infrastructure--the plumbing. In a nutshell, the SDP collapses the functionality of the regular value chain and adds the corporate and cloud functionality that ICT needs in order to deploy "M2M as a Service" within the enterprise.
The Service Delivery Platform
As illustrated in figure 1, SensorLogic's SDP comprises the core software infrastructure needed to communicate and manage the real-time information that M2M devices and applications generate. A key feature is the ability to employ a broad mix of different devices from different vendors. These devices would have been designed for a vertical application, e.g. a telematics box for fleet management, but now they can be purchased and incorporated into the corporate M2M environment.
Figure 1. SensorLogic's Service Delivery Platform
Being able to mix and match devices, and also migrate to new models of the devices in order to benefit from the latest technologies, means that the SDP must not only communicate with and manage different devices, but it must also normalize the differences for the application software--for example, the formats and encoding of common parameters such as latitude and longitude differ across device types.
Open Network Connectivity
The platform must also be agnostic with respect to network, which means support for GSM, 3G, CDMA and 4G technologies. And it must also interface, as shown in figure 2, to the authentication and activation systems of the respective mobile operators.
Figure 2. The platform can obtain parameter data via SMS or TCP connections
Something Similar But Different
The next solution comes from Viewbiquity. This vendor's model isn't complicated, but the best way to "get it" is to take it one step at a time.
Step 1: What Viewbiquity has done is to divide server functionality between the cloud and the local level (see figure 3). A similar division is made in ETSI's high-level architecture.
The hosted server enables a single Network Operations Center (NOC) to manage multiple sites and monitor the network performance while supporting multiple devices, applications and resources.
Figure 3. This model can be seen as a hybrid M2M in the Cloud solution. It enables remote management through connectivity of geographically disparate devices and processes.
Step 2: The applications run on one or several off-the-shelf computers. They function as a local application server that communicates with the cloud. In addition, the local server (or servers) connects to input and output devices, which can include sensors, as stand-alone M2M solutions and IP PBXs. These solutions can operate independently or in concert with the applications server that's in the cloud.
Step 3: The client interface is the customer-facing portal. It gives users real-time visibility into monitored and controlled business processes and activities via the Internet.
Open Systems
APIs facilitate the development of new applications and technologies in order to meet ever-changing customer requirements. Templates are employed to make it easy for manufacturers and developers to integrate products into the local application server. Developers can use them for free, customize them, and also create their own templates and offer them to the open-source community for free.
Machines in Virtual Organizations
Palantiri Systems has created a model that allows machines and production equipment to communicate with each other (M2M) as well as the people responsible for their continued operation (remote maintenance and diagnostics). That's a well-known application and when there are multiple locations communicating, is conducted via the Cloud. That's the baseline function.
It's important to keep that function in mind because this vendor has taken it to a new level--one that Palantiri positions as Collaborative Device Connectivity. But let's get there via a few steps and start with a simple example.
A company that owns vending machines for drinks and snacks needs to maintain stock levels, which is an easy M2M task. However, stocks may be fine but the delivery mechanism of some products is stuck. Therefore it makes sense to add extra devices and to relay the results to a technician and possibly the design department.
These products therefore comprise numerous distributed, intelligent devices that send information to different individuals: those that (a) restock and (b) maintain the machines in this case. And this information can also be employed in different business processes.
That was a simple example, but as shown in figure 4, it indicates that the model enables people, remote devices, and enterprise business systems to maintain real-time communications via an encrypted, firewall-transparent cloud.
Figure 4. This model is radically different. It changes the way businesses interact with their intelligent products and engage with an extended community of employees, customers and partners.
If we move up another step, it becomes clear that we are talking about a single unified system that allows users, engineers, service technicians, managers, and machines to become members of a virtual organization: a community that enables instantaneous worldwide communication between every member.
The final step is the addition of Web-based displays, instant messaging, and real-time business system integration. This is enabled by Palantri's AlwaysOn-Core platform, which provides a comprehensive set of messaging and infrastructure services: chat-based diagnostics and communications; monitoring, alarming & alerting; real-time bi-directional data access; remote application access; data collection and visualization; bidirectional file transfer and synchronization; and remote desktop and application tunnelling.
How it All Works
It's not possible to explain how all this functionality works within the space limitations of this article. But if a picture is worth a thousand words then a demo is worth 10K or more. Check it out.
Conclusions
The title of this article posed a question, and these three solutions indicate that the answer is a resounding Yes. However, all three vendors have not only embraced the concept, but they have also taken it forward in interesting and innovative ways.
SensorLogic recognised that when M2M becomes part of an enterprise environment, ICT will want to be in charge. At times that means being able to create their own apps, and when they are mixed and matched with those of a service provider it also means having everything in a unified, easy to manage infrastructure.
Viewbiquity's model is very similar to that proposed by ETSI, which has extended M2M capabilities in network cores as well as separate device domains. Applications can therefore run over local or wide area networks. The integration of voice and video into the same platform as the M2M apps is an interesting development, but we'll have to wait and see how this pans out in practice.
Palantri's model focuses on machine and production equipment, which is where M2M started. Remote diagnostics is a traditional app, but this vendor has taken the concept to another level by unifying M2M data with a comprehensive set of messaging and infrastructure services. This is a very advanced concept and here too we'll have to wait and see how it's deployed.
These models are different, but they share a common vision.
Bob Emmerson is a freelance writer who lives in The Netherlands. Email: [email protected]. Web: www.electric-words.org.
