The spectrum of M2M devices and solution patterns is extremely wide and varied, however it is useful to chunk these device classes together in order to build a shared mental model and vocabulary as we discuss M2M. This article will define some of these device types and introduce the key related concepts.
NOTE: While it is true that devices that communicate over wired Ethernet or Wi-Fi can be considered M2M, we’re going to focus on devices that use cellular technology here.
Background
In order to understand how M2M devices are used in solutions, the section below will define some terms and concepts, and correlate those concepts with elements of the Axeda technology stack.
Agent
an embedded program that runs on or near an M2M device and reports status of some asset or environment. There is always some agent present in an M2M application. Typically the agent “reads” status from sensors or local connectivity to an asset, applies some rules or logic about how often to sender how to aggregate info, then sends the info for the long-haul (also called OTA – over the air) over the cellular network to the server. This works in reverse as well, where the server can push info OTA to the agent.
Short Haul / Local Protocols
M2M is about monitoring and controlling assets and device that are remotely deployed. Some sort of sensing of the device and/or local environment typically accomplishes this monitoring and control. Local communication between these sensors and/or equipment can take the form of a simple serial connection between a device and an “M2M” device, or it may use short-haul wireless technologies like Zigbee. Industries may define standard protocols for interfacing with equipment, for example OBD II for automotive, or DEX and MDB for vending machines. All of these represent short-haul protocols, because they are for local communication between these sensors and control systems and an agent.
Long Haul Protocols
Almost invariably, M2M solutions require the status of the environment or device to be made available to a remote server-based application. Increasingly these solutions are implemented using cloud-computing technology so that many different stakeholders can consume the information and to enable future innovation of applications that make use of this data. Once an agent has received information via short-haul, it must retransmit that information to a remote server (cloud). We call this the long-haul, and the desired characteristics of these protocols are much different than short haul,particularly in the categories of security, footprint, and reliability.
Axeda Wireless Protocol (AWP)
Our Axeda protocol is designed to be used by agents on M2M devices. Compact,secure, and expressive. Our Axeda servers natively “speak” AWP. Our AWP toolkits are C and Java libraries that make it easy for folks to build agents that speak AWP. The toolkits are not required – they just make the job easy.
Read more about the Axeda Wireless Protocol.
Axeda Codecs
When someone else already wrote an agent (OEM,customer with legacy system, etc.) that uses some long-haul protocol other thanAWP, we produce an encoder/decoder that runs in the Axeda cloudand translates that protocol to AWP.
Read more about Axeda Codecs.
Modules
Modules are chips with a cellular radio and the minimum circuitry to attach to the base station tower, “log in” to the network, and push voice or data. For the general market (as opposed to manufacturers of modems, routers, etc. described below) modules are meant to be used in a custom board. OEMs or custom solution providers who are building M2M capability directly into products will buy modules and build themselves a board to fit into the product. Vendors that build modems, routers, and other boxes (described below)use these modules in their products.
Example
Can I put an agent on there?
No. There’s no CPU.
Do I need to certify this on the network?
The module itself will not be certified by the manufacturer.This means if you use a module and built a custom thing with it, that custom thing needs to be certified by the carrier before use.
Modems
A module on a board, usually in some sort of housing, with serial connection to plug into a computer. No CPU, no memory, really just a physical box for the module, and a power supply and a port to connect to a computer that will actually use it. Remember in the old days when you used dial-up modems to get on the internet? You bought a modem card or box and connected it to your PC. That’s what this is, only for cellular instead of landline telephone. The “agent”would be on a PC that is connected to the modem via serial cable. The PC handles all TCP/IP stuff.
Example
Can I put an agent on there?
No. There’s no CPU.
Do I need to certify this on the network?
The manufacturer would have done that. This is nice because you (a solution provider) can just buy the modem and start using it as long itson the carriers certified list.
Router
Like a modem, but instead of just a single serial connection to one PC, it’s just like an Ethernet router, with Ethernet ports for various computers to plug into, all of them sharing the cellular data connection. The router also can initiate the “dial up” to the cellular network itself, as opposed to a modem which needs to be explicitly controlled by the serial-connected PC.
Example
Can I put an agent on there?
No.
Do I need to certify this on the network?
The manufacturer would have done that.
M2M Computer
These are like industrial micro-form-factor computers with cellular modems built in. They feature a general purpose CPU, often use fully featured operating systems like Linux have RAM and permanent storage, include GPS and lots of serial connections(GPIO, RS-232, USB). These are the Cadillacs of the M2M world. Often an SDK is included for making agent programming easy in terms of accessing the serial ports, GPS, and establishing the cellular data connection.
Example
Can I put an agent on there?
Yep! Use one of the AWP toolkits.
Do I need to certify this on the network?
The manufacturer would have done that.
M2M Tracker
A fixed-purpose M2M device that is engineered to perform as specific set of functions for a specific vertical market. These are modems with a CPU, but the CPU is not a generally programmable one. Instead there is some configuration scheme (which may be very advanced, but still not custom programming) to dictate the behavior of the tracker. These have agents built in, and have their own long-haul protocols.
Example
Can I put an agent on there?
No. You can only configure the one that’s built in. Axeda Codec technology can be used to translate these devices’ native long-haul protocol to AWP without modification of the device.
Do I need to certify this on the network?
The manufacturer would have done that. Plug n’ Play.
Summary
As indicated in the introductory paragraph, this article is by no means a complete treatment of the M2M device ecosystem, but rather a high level classification system to help put other concepts into perspective. When approaching an M2M project, ask yourself "do I need a module, modem, tracker, M2M computer?", which will spawn other questions like "where is the agent", and "what long-haul protocol will I use?". These questions are a great way to shape and explore what your solution will be like.
