This “Internet of Things” (IoT), “Machine to Machine” (M2M) communication, is well underway—after all, microprocessors are to be found in all manner of “things”: domestic white goods, cars, credit cards, your passport, your family pet, the CCTV camera in your street, the lift (elevator) in your office, and many more. Add the magic ingredient of Internet connectivity (or the ability to be read by an Internet-connected device), bake with applications and services that make use of the data gathered by this vastly expanded
network, and you’ve cooked up another technology revolution.

Data transfer patterns in the M2M-driven Internet of Things will differ fundamentally from those in the classic “human-to-human” (H2H) Internet. M2M communications will feature orders of magnitude more nodes than H2H, most of which will create low-bandwidth, upload-biased traffic. H2H internet traffic is rather download-biased with high bandwidth. Many M2M applications will need to deliver and process information in real time, or near-real-time, and many nodes will have to be extremely low-power or self-powered (e.g., solar-powered) devices.

The “things” in the IoT, or the “machines” in M2M, are physical entities whose identity and state (or the state of whose surroundings) are capable of being relayed to an Internet-connected IT infrastructure. Almost anything to which you can attach a sensor—a cow in a field, a container on a cargo vessel, the air-conditioning unit in your office, a lamppost in the street—can become a node in the Internet of Things.

Sensors are the components of “things” that gather and/or disseminate data—be it on location, altitude, velocity, temperature, illumination, motion, power, humidity, blood sugar, air quality, soil moisture… you name it. These devices are rarely computers, as we generally understand them, although they may contain many or all of the same elements (processor, memory, storage, inputs and outputs, OS, software). The key point is
that they are increasingly cheap and plentiful and can communicate, either directly
with the Internet or with Internet-connected devices.

Local communication: All IoT sensors require some means of relaying data to the outside world. There’s a plethora of short-range, or local area, wireless technologies available, including: RFID, NFC, Wi-Fi, Bluetooth (including Bluetooth Low Energy), XBee, Zigbee, Z-Wave, commodity remote control and sensing communication and Wireless M-Bus. There’s no shortage of wired links either, including Ethernet, HomePlug, HomePNA, HomeGrid/G.hn, and LonWorks.

For long range, or wide-area, links, there are existing mobile networks (using GSM, GPRS, 3G, LTE, or WiMAX for example) and satellite connections. New wireless networks, such as the ultra-narrowband SIGFOX and the TV white-space Zero-G, are also emerging to cater specifically to M2M connectivity. Fixed “things” in convenient locations could use wired Ethernet or phone lines for wide-area connections. Some modular sensor platforms, can be configured with multiple local- and wide-area connectivity options (ZigBee, Wi-Fi, Bluetooth, GSM/GPRS, RFID/NFC, GPS, Ethernet). Along with the ability to connect many kinds of sensors, this allows devices to be configured for a range of vertical markets.

Some types of M2M installations, such as a smart home or office, will use a local
server to collect and analyse data—both in real time and episodically—from assets on
the local area network. These on-premise servers or simpler gateways will usually also connect to cloud-based storage and services.

“Things” with short-range sensors will often be located in a restricted area but not permanently connected to a local area network (RFID-tagged livestock on a farm
or credit-card-toting shoppers in a mall, for example). In this case, local scanning
devices will be required to extract data and transmit it onward for processing.

If you think today’s Internet generates a lot of data, the Internet of Things will be another matter entirely. That will require massive, scalable storage and processing capacity, which will almost invariably reside in the cloud—except for specific localised or security-sensitive cases. Service providers will obviously have access here, not only to curate the data and tweak the analytics, but also for line-of-business processes, such as customer relations, billing, technical support, and so on.

Subsets of the data and analyses from the IoT will be available to users or subscribers, presented via easily accessible and navigable interfaces on a full spectrum of secure client devices. M2M and the Internet of Things has huge potential, but currently comprises a heterogeneous collection of established and emerging, often competing, technologies and standards (although moves are afoot here). This is because the concept applies to, and has grown from, a wide range of market sectors.

(from “The tech behind M2M and the Internet of Things” by Charles McLellan in “The Executive’s Guide to the Internet of Things” Tech Republic, ZDNet, 2013)

Electric imp’s hardware form factors: the imp001 card (left) and the imp002 module (right)

The card has 6, the module 12 general purpose I/O pins which can be connected to an analog to digital converter, two digital to analog converters, digital input and output, pulse width generation, counters and several serial communication interfaces (3 UARTs as used for RS232 or RS485, 2 SPI and 2 I²C to connect more electronic functions such as memory or I/O).

Electric imp already sold several 100,000 of these devices for all kind of applications. Reference designs have been developed for many typical sensor and control applications and are freely available in hardware and software on electric imp’s website. This leads to short integration time for new designs. There is no special system development kit (SDK) necessary. Every imp card can be used for development. The complete development system comes from the cloud, only a browser is carrying out software development. Simple breakout boards are available to support the hardware side of the development process.

It takes two hours from receiving the hardware to controlling a LED from internet. That is the “Getting Started” project  for the software developers as described in electric imp’s website. All the developer needs is shown below. The USB cable is only for power supply.

The typical structure for systems based on electric imp (short the “imp”) consists of the imp hardware itself embedded in the device, the firmware running on the imp, the agent, which is a kind of pico virtual machine, together with the API (application programming interface) on the impCloud server (see below). The impIDE development system can access both, the imp and the agent, the impConsole which controls the programming process during production and impOverview, an use analysis tool. Each running imp has its own agent, and this agent has its own URL. Through this URL and the API apps on smartphones or tablets, software on PCs or own servers can communicate with the agent. The imp itself has its own operating system called impOS on which all programming of the real world interface takes place. There are standardized communication procedures between the imp and its agent.

Structure of imp together with cloud servers and apps

There is one interesting technical solution aspect. The imp doesn’t initially know which wireless network is the one to use and with which password. Electric imp has implemented an optical data exchange between a smartphone display and the imp (using a phototransistor) to initially set SSID and password of the intended wireless network. This process is called “BlinkUp” and exists as a generic app and it can be integrated in vendor apps.

The programming language is called Squirrel. Squirrel is a high level imperative, object-oriented programming language, designed to be a light-weight scripting language that fits in the size, memory bandwidth, and real-time requirements of applications like video games. It fits very well into the limited memory of the imp device and is also used for the agent software. The agent software runs on a virtual machine (VM), 10s of thousands on electric imp’s servers with complete resource management there.

The typical set up will allocate the real world part of the software (dealing with signals from or to the device) on the imp while the agent takes care of the internet communication.

• Imp Hardware: The Electric Imp platform starts with the imp, a powerful WiFi-enabled processor module that can be integrated into your product and act as the gateway to the Internet, providing it with secure connectivity and a brain in the cloud.
• Imp OS: The software foundation for the imp’s features and services that lets manufacturers and their software partners customize their device code to bring their product’s functions to life.
• Imp Cloud: Electric imp’s cloud allows manufacturers to run agents – server side code that runs in a secure environment – that can be used to offload heavy tasks best performed by a server, and easily connect manufacturers’ products to anything with Internet access.
• Imp Open API: Enrich manufacturers’ customer experience and build manufacturers’ business by developing enhancements like messaging, monitoring, and much more.
• Imp BlinkUp: The proprietary Electric Imp setup solution, BlinkUp, integrates seamlessly into manufacturers’ apps, letting manufacturers and their customers connect products in seconds using just a smartphone or tablet. BlinkUp goes beyond just WiFi setup to connect and provision a new device in a single step.
• Imp Services – IDE and Ops Console: Maintain software, push new code and features easily to devices anytime, and ensure that the manufacturers’ users always have the latest features. The Ops Console enables manufacturers to gain more insight into factory’s production lines and scale to millions of devices.

Electric imp’s connectivity platform

www.electricimp.com

Core Requirements of a Connected Product

It all starts with the choice of the wireless chip, studying the networking protocols, defining a hardware design, programming the processor, solve security and approval issues . Then the servers have to be setup, software has to be released and managed, network firmware defined and finally everything prepared for the end user. This is a 1 to 2 or even more years exercise. Time-to-market today in consumer electronic of more than 1 year is suicide.

The hardware manufacturers have a lack of the necessary domain expertise and fear the challenge to work with prototype or experimental solutions. But this approach is also in high cost and need of resources. Hardware manufacturers have to invest largely and prepare themselves for ongoing operational support. Iterations on solutions are difficult because of the development cycles and so the best consumer value gets lost. Last but not least security and privacy is hard to identify for hardware manufacturers. Especially with the cultural and political differences between Europe, where the technology shall be used, and Asia, where it is manufactured, are big in these terms. But even in Europe it will be difficult to identify the tipping point between usefulness and invasiveness.

The devices (sensors and switches) provide in principle very simple data compared to a camera: on/off, open/close, smoke/no smoke, motion detected or not for the lowest level and a single value for dimming the light or reading a temperature. Data also comes in a much lower frequency than from a camera: 1 bit per minute (or less) compared with 1 MBit per second.

The devices deliver or receive this small amount of data through a proprietary wireless channel that will be connected to a gateway. It’s not the device that has to be changed for a standardized approach, it’s sufficient if the gateway communicates with a number of devices, understands their protocol and translates it into a standard format. Software on the cloud server can deal with the standardized data format without adapting to manufacturer’s specialties. All hardware and manufacturer dependent information is kept in the firmware of the gateway.

That means that server functions need to be outsourced to companies that serve more users and can come to better rates. A target is USD 1 per year.

It also makes clear, that the server operation should not stay in the responsibility of the hardware manufacturers. If a brand doesn’t want to depend on one hardware manufacturer only, each hardware manufacturer would offer his own solution. That means a higher risk of failure and also higher cost. Even if the hardware manufacturer doesn’t charge directly for the cost, they will either develop on his side and he has to charge higher prices for his products or they will run risks while operating their servers.

With IPv6 addresses this will change, since every device in internet can get its individual address and with that can be reached from everywhere. Although it is technically feasible today it will still take 5 to 10 years, before IPv6 becomes the standard addressing scheme.

Before that is solved, connections to devices inside a local network have to be made by cloud server, where both, the device and the human or other machine interfaces have to register first, before they are connected by the server.

The current technologies for wireless communication include

-       Infrared (as for remote controls)

-       Radio frequency communication in the free ISM bands (in Europe 433MHz, 868MHz, 2,4GHz) with standard (such as Z-Wave, Enocean or Zigbee) or vendor proprietary protocols

-       Bluetooth (especially version 4.0 low energy, BLE)

-       Wifi according IEC 802.11bgn… (as we use it for our numerous IT applications)

-       Radio frequency communication in TV white space (“Weightless”, 400 to 800 MHz)

-       Cell phone communication according to GSM or CDMA standard

To connect to internet each of these technologies need to use a gateway to the cable bound copper or fiber optic internet grid. Some of these gateways are in the same house where the sensors and controls are (ISM, Wifi), some are part of the network infrastructure outside of the house (Cell phone, Weightless).

The current markets for remote sensors and controls concentrate on a local (10m to 300m range) connection. An alarm system can connect a number of devices to a base station. The base station has the user interface for arming/disarming, status display and alarm functions. A remote controlled power plug can be reached by a handheld battery operated hand set. That means that there exists already a mature supplier market for most of the remote controlled functions. That is good news, since the time to market is extremely shortened if you can already access a whole portfolio of products that can connect to the real world.

Another important aspect is the cost per intelligent device. Intelligence is typically defined by a micro controller unit (MCU), a micro computer with peripheral functions such as analog or digital input or output signals, and a wireless communication interface. The cost of this functionality heavily depends on the technology. The table below gives an indication of today’s and next year’s cost of each node:

Comparison of node cost of different technogies

1. to give the homeowner complete control over all lighting and small appliances within their home. From the porch light to the coffee maker, control your lights and appliances right off your Smartphone, tablet or PC, regardless of where you are. As long as you have your mobile device, you’re in control: Program On/Off Control, Dimming/Brightening Control, Timers, Scenes, Zones and much more.
2. to let the homeowner monitor possible threats to his home or the people living in it. That starts with checking doors and windows, finding out whether somebody is entering into or moving inside the house, checking on flooding, smoke or heat, and also includes messages from helpless people by panic button or emergency switches. All these signals should not stay in the house anymore, the come to your mobile device with all the necessary information to take action.