M2M

M2M refers to data communications between machines. The abbreviation is commonly translated as Machine-to-Machine but has sometimes been translated as Man-to-Machine, Machine-to-Man, Machine-to-Mobile and Mobile-to-Machine. Like all evolving technologies, its definition continues to evolve, but it generally refers to telemetry or telematics that is accomplished using networks, especially public wireless networks.

In the past, telemetry systems were the exclusive domain of very large well financed organizations:

• NASA first used telemetry extensively from the very beginning of the space program,
• Large oil companies,
• Gas companies and
• Electric utilities were a few of the first private organizations to use telemetry.

M2M also means hardware, middleware, and software that improve efficiency and quality by tying together different equipment with asset management, ERP, and CRM.

The M2M market is expected to grow rapidly:

• The 2010 world market may exceed $300B in annual revenue.
• There are 500 million computers in the world,
• 1.5 billion cell phones & PDAs,
• More than 38 billion other electronic devices that have information relevant to improving an enterprise's operation.

The M2M market strives to connect these devices to corporations, governments and institutions.

Direct Web-Based Device Management

Many devices need to be managed remotely:

• Security systems,
• Fire alarms,
• Access control systems, etc.

Most have been offering at least some remote management interface for the past several decades. Early on, this was done using RS232 or RS485.

Later, these systems started to take advantage of the “ubiquitous networking” revolution that was (and still is) unfolding around the world. Dedicated RS232 and RS485 links gave way to TCP/IP communication, and equipment began to be managed using an Internet browser.

The device being configured acts as a small Web server. This Web server serves up HTML pages that include “dynamic” content such as device settings, status and event logs. No specialized software has to be installed on the user’s PC - the standard browser is used to access the device.

Disadvantages

Direct management via Web browser has significant limitations:

• No batch operations
• Intermittent Connections
• Need for static IP Addresses
• Firewalls have to be configured
• Other Network Restrictions

No Batch Operations

Control of each device incorporating its own Web server cannot be combined with another device, even if both devices are absolutely identical. Each device sends its own HTML pages, thus requiring the user to open a separate browser window for each device being accessed or access each device one-by-one. For systems including hundreds or thousands of devices, this is arduous and impractical.

Intermittent Connections

One more disadvantage of the above method is that it requires uninterrupted connection to the device. This is easy when both the device and the client computer are connected to a small LAN. Achieving the same for multiple devices distributed over the Internet is much more difficult.

Also, the reliability and availability of the data link to the device are reduced when the device is wireless (for example, Wi-Fi) and not stationary, such as:

• Mobile terminals
• Portable data collection equipment
• Hand-held computers
• All other portable connected devices

It is not practical to create a system for remote communications with such devices on the premise that uninterruptible connection to each device will be available at any time.

In many instances a “window of opportunity” for accessing and configuring the device will be smaller than the time required by the human to complete a desired transaction: The connection breaks down before the configuration is complete.

Static IP Addresses

One more disadvantage is that accessing the device over the network requires it to have a static IP address. If the device is being accessed over the Internet, its IP address must also be “real” i.e. accessible from any point of the network. Such IP addresses are not free. Having multiple devices requires multiple static real IP addresses. Combined costs and management overhead may be substantial.

Firewall Configuration

Yet another disadvantage of the above method is that it creates significant management overhead due to the necessity of configuring a firewall on each device’s site. Usually, the device is connected via an ADSL modem with a built-in firewall. The modem creates a firewall-protected private network and the device is connected to this network. Very often, the device will share this private network with personal computers and other devices.

Connecting from within the private network to a server outside does not require any setup on the firewall, but connecting from outside to a device within the private network requires proper firewall setup.

With multiple devices on multiple firewall-protected private networks, firewall setup creates a significant management overhead, not to mention the human factor: many IT departments view this kind of “opening” the network as potential vulnerability to external attacks and are not willing to compromise their networks in this way.

Network Restrictions

Finally, some kinds of networks do not allow incoming connections in principle. For example, cellular networks, such as GPRS, will only allow the device to connect to the server on the Internet, and not the other way around.

Solutions So Far

For the above reasons, large-scale systems rarely use direct web-based configuration.

They typically have an intermediary system, like a server running specialized software or a purpose-designed hardware board, which acts as a central repository of data as well as the main coordinator of the system.

Like this, the user can usually simultaneously control all or several devices without having to perform repetitive operations on each device.

Such systems have a disadvantage of a very high cost of the design of specialized central server software or hardware board.

Communications between the central server and the devices are usually based on a proprietary protocol designed specifically for each particular system.

Server software is often inflexible and requires exact match between the devices and the central software for the system to work correctly. Even a small change in the design of devices necessitates a corresponding change to the central server software. This results in high costs of maintaining the system.

Introducing new devices into the system is almost like designing a new central server software. For this reason, many systems of this class remain closed, non-expandable, and proprietary to this day.