Internet terminology has always been as vague as the squiggly closed line that is often used to represent it. Intuitively, we know that the Cloud and the Internet of Things (IoT) are different expressions for the same general concept. When designing embedded systems, it is essential to make a much clearer distinction—and to understand its consequences.
IoT is a subset of the Cloud. From a hardware perspective, it is populated with embedded systems and other edge devices such as mobile phones – whereas the full roster of Cloud hardware consists of web servers, application servers, database servers, routers, gateways, computing resources, and edge devices.
It is easy for embedded-system designers to think of the Cloud simply as supplying connectivity resources to move data between an edge device and a server, computer, or database. Inevitably, they discover that while the Internet might be considered as “just a pipe” between the embedded system and a server, the Cloud cannot. If this revelation arrives toward the end of the design process it can be quite costly and this is why project engineers or managers need to make sure they involve parties reasonable for Information Technology or IT operations when scoping their projects.
Connecting products to the Cloud loads additional layers of design effort on embedded designers, particularly in terms of security and privacy. In addition to the efforts of Cloud architects to create a universal, robust virtual computing system, there are an increasing number of laws dictating requirements for security and privacy. The reasons may have more to do with social media than with embedded systems, but the same rules apply to all data.
On the other hand, although the data transferred over IoT may be a trickle compared to the petabytes that stream between data centers daily, IoT data is as particularly susceptible to security breaches because in aggregate it will eventually control an extremely large number of embedded devices in homes, factories, and offices.
Times are changing for embedded designers – and with it their design paradigms. Consider, for example, the relatively new phenomenon of wearable embedded devices, such as wireless fitness and health monitors, which are commonly used as sports-watch systems, including pulse-monitor sensors or step counters that measure fitness parameters.
The present generation of wearables communicate mainly over Bluetooth to a mobile phone or tablet, and then to a PC. Connections to the Cloud are for the most part managed by the PC, which already has robust security provisioning. Security, such as SSL/TLS must be supported and implemented on both ends of a connection.
The ratification of Bluetooth Core Specification 4.1 will change that by enabling the sensor to connect directly to the Cloud without a smartphone or PC acting as intermediary. Among other things, this will allow embedded designers to aggregate the data of multiple sensors so that a full fitness report can be calculated inside the Cloud and shared over social media sites with others for motivational purposes.
Devices located in smart homes, factories, remote monitoring locations, and Cloud-connected cars are other examples of embedded systems that should provide at least the same level of security as computers. The Internet demands that embedded systems pay attention to the implications of security and privacy provisioning.
Where cultures collide
At the same time that the nature of the connection between an embedded system and the Internet is changing, the Internet itself is evolving. A decade ago the squiggly closed line that represented the Internet referred to a hardware infrastructure that was connected but not really integrated.
In today’s diagrams, the Cloud refers to an infrastructure in which resources are shared to the point that they can be considered a single virtual machine. This happens though the magic of Cloud software, which brings us to subject of public, private, hybrid, and community clouds, all of which are defined and implemented by the Cloud software that engenders them.
Detailed Cloud definitions are not relevant to this article but the concept of choosing a Cloud service is because that is the starting point of a Cloud-connected design.
As a result of the complexity of Cloud software, connecting to the Internet via the Cloud is managed by third parties. For example, Amazon’s 25 percent market share make it the dominant vendor of IaaS/PaaS (Infrastructure as a Service/Platform as a Service) Cloud services.
Figure 1 shows the relative market share of companies that provide Cloud Infrastructure.
Figure 1: Cloud-computing market shares by revenue for the first quarter of 2013 (Courtesy of Microchip Technology).
An embedded system can, of course, bypass the Cloud vendors and connect the Internet through a royalty-free web server that provides dynamic websites capable of serving tens of thousands of requests more or less simultaneously. A typical choice might be LAMP – which stands for Linux (OS), Apache (http server), MySQL (database management), and the scripting language (PHP).
It is difficult, however, to think of an embedded system that is not susceptible to illegal, illicit, or simply disruptive activity. The susceptibility of a garage door opener – often used as an example of a simple but useful web-based embedded system – is obvious. Less obvious, perhaps, are the devices inside a smart home. Thermostat settings, for example, could be monitored by web-savvy criminals to locate the homes of families on vacation. Billions of unmonitored IoT edge devices could be useful in Denial of Service (DoS) attacks.
From this perspective, a LAMP server’s lack of robust security makes a poor choice for a production server even though it is a good choice for server-side development.
Seamless connections via MCU vendors
Less painful and considerably faster routes to a secure, robust Cloud connection are being offered by MCU vendors by leveraging the computing platforms provided by Cloud vendors. This is where the worlds of embedded design and IT interface.
The basic unit of Amazon’s Cloud-based services, for example, is the Amazon Machine Image (AMI). AMI is a virtual appliance that is used to create a virtual machine within the Amazon Elastic Compute Cloud (EC2). MCU vendors create a bridge to their specific products to AMI with a layer of middleware. Demo boards and development kits are available to handle all of the intricacies of the Cloud-to-MCU interface.
Once the wisdom of connecting through a security-aware Cloud service is accepted, more familiar complexities such as establishing the connections downstream from the Cloud come into play. Figure 2 shows the four most frequently used data paths between embedded devices and the cloud. It may be desirable for an embedded design to utilize more than one of them.
Particularly when learning how to create an AMI interface specific to an MCU vendor, Wi-Fi makes the most sense because the embedded design basically becomes a centralized coordinator for the network. This is somewhat like an Access Point (AP), which means that the topology is both standard-based and familiar.
For example, in Microchip Technology’s WCM Development Kit 1 (DM182020), the firmware programmed into the onboard 32-bit PIC32MX695F512H
MCU can be set up to connect to a Microchip Amazon Machine Image (AMI) using Microchip’s onboard MRF24WG0MA
When instantiating a new product design, however, Wi-Fi is not the only choice. Each of the options in Figure 2 has advantages and disadvantages. A few are noted below.
Figure 2: Configuration options for connecting an embedded system to the Cloud (Courtesy of Microchip Technology).
- Wi-Fi is almost ubiquitous and easy to configure but is relatively power hungry. Bluetooth has native security and low-power consumption. As more and more smartphones are deployed, Bluetooth is developing widespread availability. However, it has limited range and typically requires royalty payments.
- ZigBee (IEEE 802.15) and proprietary sub-gigahertz technologies offer advantages such as lightweight stacks, excellent range and penetration, low cost, and sometimes ultra-low power. On the other hand, they usually require the inclusion of an additional project – a concentrator – in the design.
- Ethernet is a cost-effective technology that has plug-and-play, flexible design, high bandwidth, and is immune to high-RF traffic in its favor. It also has all the downsides of a wired system.
Not surprisingly, planning for a Cloud connection exerts a significant influence when choosing an MCU for an embedded system. Power consumption, clock rate, memory, and per-unit cost are, as always, important considerations. The Cloud connection adds a few important twists – not a few of them having to do with security.
Particularly, when e-commerce is part of the application, hardware acceleration for executing AES, DES, and CRC may be in order and these functions may require longer instruction set words. Similarly, cryptographic-hash functions such as Secure Hash Algorithm (SHA) and Message Digest Algorithm-5 (MD5) can also be employed with 32-bit MCUs.
Security functions can be executed on an MCU with integrated peripherals in product lines such as Microchip Technology’s PIC32MZ EC
family. There are also software stacks provided by Microchip for the embedded engineer that support security protocols such as SSL/TLS within the TCP/IP stack.
offers its Tiva C
Series Connected LaunchPad Dev Kit (EK-TM4C1294XL
), which features out-of-the-box Internet connectivity for Cloud-enabled applications. A low-cost evaluation platform for ARM Cortex-M4-based microcontrollers, the TI Connected LaunchPad design highlights the TM4C1294NCPDT microcontroller with its on-chip 10/100 Ethernet MAC and PHY, USB 2.0, hibernation module, motion-control pulse-width modulation, and various serial communication peripherals.
Typically, these product lines – and those of other MCU vendors – integrate communications peripherals such as Hi-Speed USB 2.0, 10/100Mbps Ethernet controllers, CAN 2.0b control modules, UARTs, SPI/I²S serial interfaces, multiple-I²C communications interfaces, and 4-bit Serial Quad Interfaces (SQI). Integrated analog-to-digital converters (ADCs) are typically employed in industrial applications.
As previously mentioned, there is little wisdom in re-inventing all the processes and code that has already been developed by Cloud experts.
MCU vendors are capturing that institutional knowledge – along with the capabilities of their own chips and software – into development kits. One example is Microchip Technology’s previously mentioned WCM Development Kit 1. Using this development kit and the Microchip Amazon Machine Image (AMI), both the IT department and the engineering department can learn the basic steps needed to launch a Cloud-based solution.
The kit allows the user to set up an Amazon AWS (Amazon Web Services) account and provision the device included in the kit. There are four basic introductory steps:
- Find Microchip’s AMI on Amazon’s AWS marketplace.
- Launch an EC2 (Amazon Elastic Compute Cloud) instance from this AMI.
- Configure the demo to access your local router or access point.
- Run the demo.
There are several customization options, but the demo requires only two: a selection for a security group, which provides the names of the ports that must be open to proceed; and, the key pair for encryption.
Accepting Amazon’s usage terms and conditions starts the EC2 instance based on the Microchip AMI. When the instance is ready (it takes a few minutes) the AMI console can be accessed. Although there is a substantial amount of information on the new page, the demo only requires finding the public IP address.
Start a new browser page and enter the public IP address. A web interface for the server appears on the screen.
Connecting the demo board to the web involves setting the board into AP mode so it can be configured. The demo kit prompts the user through the configuration, including choosing the appropriate security option. Entering the public IP address and passcode is all that needs to be done to configure the demo board for use.
Figure 3 shows a browser window of the demo with the web page on the left and the board on the right. Buttons on the board can be pressed to illuminate virtual LEDs on the web page and adjusting a potentiometer on the board is reflected on the web page by a changing number at the bottom of the browser screen.
Figure 3: Microchip Technology demo web page and board (Courtesy of Microchip Technology).
Although the functionality achieved by the demo board and software is very simple, the real point of the demo is that a fully-connected device can be used with a predefined Amazon AMI specific to a Microchip MCU that can be set up in just a few minutes.
Having a product that makes use of remote processing or storage and can connect to the Cloud is an attractive and novel concept, but you need to pay attention to security and privacy issues. Server-side software is, however, complex and non-intuitive for embedded-design engineers, so MCU vendors are beginning to set up partnerships that provide nearly plug-and-play connections to the Cloud. Using these development kits saves time and effort for design teams that are more intent on providing market-leading functionality in their products than becoming IT experts.
This article is based on a course by Stephen Porter, Applications Manager for the Home Appliance Solutions Group at Microchip Technology, which was originally presented at Microchip’s 2014 Worldwide MASTERs Conference.