Tag Archives: IoT Designs

Atmel and IoT and Crypto, oh my!

One of the companies that is best positioned to supply components into the Internet of Things (IoT) market is Atmel. For the time being most designs will be done using standard components, not doing massive integration on an SoC targeted at a specific market. The biggest issue in the early stage of market development will be working out what the customer wants and so the big premium will be on getting to market early and iterating fast, not premature cost optimization for a market that might not be big enough to support the design/NRE of a custom design.

Latest product in Atmel's SmartConnect family, the SAM W25 module

Here is Atmel’s latest product in the SmartConnect family, the SAM W25 module

Atmel has microcontrollers, literally over 500 different flavors and in two families, the AVR family and a broad selection of ARM microcontrollers ad processors. They have wireless connectivity. They have strong solutions in security.

Indeed last week at Electronica in Germany they announced the latest product in the SmartConnect family, the SAM W25 module. It is the industry’s first fully-integrated FCC-certified Wi-Fi module with a standalone MCU and hardware security from a single source. The module is tiny, not much larger than a penny. The module includes Atmel’s recently-announced 2.4GHz IEEE 802.11 b/g/n Wi-Fi WINC1500, along with an Atmel | SMART SAM D21 ARM Cortex M0+-based MCU and Atmel’s ATECC108A optimized CryptoAuthentication engine with ultra-secure hardware-based key storage for secure connectivity.

Atmel at Electronica 2014

Atmel at Electronica 2014

That last item is a key component for many IoT designs. Security is going to be a big thing and with so many well-publicized breaches of software security, the algorithms, and particularly the keys, are moving quickly into hardware. That component, the ATECC108A, provides state-of-the-art hardware security including a full turnkey Elliptic Curve Digital Signature Algorithm (ECDSA) engine using key sizes of 256 or 283 bits – appropriate for modern security environments without the long computation delay typical of software solutions. Access to the device is through a standard I²C Interface at speeds up to 1Mb/sec. It is compatible with standard Serial EEPROM I²C Interface specifications. Compared to software, the device is:

  • Higher performance (faster encryption)
  • Lower power
  • Much harder to compromise

Atmel has a new white paper out, Integrating the Internet of Things, Necessary Building Blocks for Broad Market Adoption. Depending on whose numbers you believe, there will be 50 billion IoT edge devices connected by 2020.

Edge nodes are becoming integrated into everyone’s life

As it says in the white paper:

On first inspection, the requirements of an IoT edge device appear to be much the same as any other microcontroller (MCU) based development project. You have one or more sensors that are read by an MCU, the data may then be processed locally prior to sending it off to another application or causing another event to occur such as turning on a motor. However, there are decisions to be made regarding how to communicate with these other applications. Wired, wireless, and power line communication (PLC) are the usual options. But, then you have to consider that many IoT devices are going to be battery powered, which means that their power consumption needs to be kept as low as possible to prolong battery life. The complexities deepen when you consider the security implications of a connected device as well. And that’s not just security of data being transferred, but also ensuring your device can’t be cloned and that it does not allow unauthorized applications to run on it.
IoT Design Requirements - Software / Development Tools Ecosystem

IoT design requirements: Software / development tools ecosystem

For almost any application, the building blocks for an IoT edge node are the same:

  • Embedded processing
  • Sensors
  • Connectivity
  • Security
  • And while not really a “building block,” ultra-low power for always-on applications

My view is that the biggest of these issues will be security. After all, even though Atmel has hundreds of different microcontrollers and microprocessors, there are plenty of other suppliers. Same goes for connectivity solutions. But strong cryptographhic solutions implemented in hardware are much less common.

The new IoT white paper is available for download here.

This post has been republished with permission from SemiWiki.com, where Paul McLellan is a featured blogger. It first appeared there on November 19, 2014.

Kaivan Karimi talks IoT building blocks with Design World

While ARM TechCon 2014 may be a thing of the past, product releases, discussions and trends from the show floor continue to make their way forward. Case in point, Design World’s Aimee Kalnoskas recently sat down with our very own Kaivan Karimi to discuss the building blocks of the ever-growing Internet of Things in a candid post-TechCon interview. During the conversation, the Atmel VP and GM of Wireless Solutions shares his insights and adds flavor and some color to this ‘thing’ commonly referred to as IoT.  You can read the entire interview — which was brought to our attention by our friends at ARM and whose original article can be found here — in its entirety below.

AK: What do you think the IoT infrastructure looks like? How does it compare to the current communications infrastructure?

KKThe first thing we must do is to define the IoT industry infrastructure properly – what kinds of devices are connected and how are they connected. We then define the infrastructure of IoT services to determine what the weak points within this infrastructure and how do we resolve them.

First, let us define the weak points. For a while, the cellular operators where the ones claiming that IoT was all about cellular “telemetry-like” services. In IoT, most “things” will be battery operated, requiring long battery lives. But if you assume a cellphone tower is making the connections through an LTE modem with less than two days of battery life, then you can see why edge nodes of IoT have practically nothing to do with cellular. Additionally, IoT is all about secure low data rate command- and control- type of communications, but cellular generally is not. The fact is that by the time IoT services role out, cellular pipes will only carry about five to 10 percent of the WAN traffic. There are many reasons why cellular is the wrong pipe.

IoT communications infrastructure would be based on a “smart” box inside of the home or premise –hierarchical gateways – but not the access points of today. Today’s access points only switch, route and collect information upstream or retrieve it from downstream. For IoT, there will be a new generation of smart gateways that will have intelligence on board to process the information, make decisions, and disperse that information. This “smart gateway” functionality could be an add-on to the existing access points or set-top boxes, or could be a standalone box, but the bottom line is that the “intelligence” will move to the customer premises versus only in the cloud today.

A smart gateway accesses the cloud using various WAN communication technologies, which would be different than BAN/PAN/LAN connectivity technologies used inside the home or on premise. Due to the variety of end segments IoT covers, the smart gateway can be installed anywhere, depending on the use case and application within a given IoT segment.

For example in a smart-highway use case, the gateway is inside a shiny cabinet on the side of a bridge, communicating with tiny seismic sensors (microphones) positioned on the bridge. In the Western world, we have an aging infrastructure, with multiple incidents of collapsing bridges in the past few years. Each of these inexpensive seismic sensors can generate a ping every 30 seconds measuring the integrity of the bridge every 30 minutes or so, and ensure against future bridge collapses.

In this case, communication from the sensor to the gateway or the box is short-range. That can be one of the many 802.15.4 (mesh) technologies such as ZigBee, 6LowPAN, Wireless Hart, etc. Communication through the gateway to the cloud, on the other hand, is WAN connectivity such as Fiber/Ethernet through local networks, cellular, satellite, PLM/PLC, or the next generation of IoT pipes in sub-GHz bands such as SigFox, Weightless, etc.

AK: What’s the role of the smart gateway with regards to provisioning a service?

KK: Think about how you create value as a service provider. It’s this idea of service provision. You need to be concerned not only about connecting the widget but the service delivery frameworks that sit on top of that connection and manage the overall system ensuring quality of service, as well as security of the service.

Smart gateways are key drivers for IoT communications. For instance, a smart gateway in a home could involve communication between thermostats to the gateway box but there is little value in simply connecting these widgets. You need to create a tangible value – the box needs to provision the IoT service. Also note that not everyone is technology savvy enough to program these connections….something we usually lose sight of in Silicon Valley. It needs to become foolproof so that a non-techy can use it just as easily. Again, service providers will play a key role in that.

There is a belief that the IoT edge nodes will generate massive amounts of data and this will all go to the cloud, so you need a lot of bandwidth, a lot of storage space, and data management in the cloud. This is a big fallacy advertised by the people who make money from big bandwidth or cloud storage.

Let’s illustrate what we mean here: For example, consider a thermostat in your home set between 73 and 75 degrees F. A sensor comes on every few seconds and notes what the temperature is. The gateway box gets that information and registers it but it doesn’t need to send it to the cloud because that’s not necessary (not a “cloud-worthy” event). The gateway captures the event from a certain time span and simply registers it – say from 1:25PM to 1:45PM it was 74 degrees F. Now, if the sensor communicates to the box that the temperature has gone to 76 degrees F, then the box activates the air conditioner (actuates). But it still doesn’t need to go to the cloud.

At some point, the thermostat might reach 90 degrees in a couple of readings and then, two intervals later, 110 degrees. The box determines that this is not a false reading but, perhaps, an event and alerts the smoke detector to the event. Smoke sensed by the device confirms the event.

The gateway then communicates this information to the cloud and an emergency call is triggered to the fire department. Test have shown that in a scenario like this, when the sensor device (i.e. thermostat) and gateway are involved, you shave about 15 to 18 minutes of police or EMT-response time off of an otherwise manual 911 call. This event is an exception that goes to the cloud right away. Think about how often someone’s house catches on fire, and you see that indeed this is an exception and not the rule.

In a mobile health (mHealth) application, you could monitor heart rate or check other biometrics with the gateway box perhaps every five minutes. The sensor simply delivers the information to the box as opposed to the scenario where a healthcare worker checks in with a patient every few hours and spends less than three seconds checking vitals. If you are monitoring a potential heart attack patient and the vitals are within range, then the box records the event as satisfactory. But if the patient is having a heart attack, that is an exception to the event and the box calls the hospital.

The bottom line is that it is not necessary to be continuously communicating to the cloud. Because you upload metadata and not all the data at scheduled intervals, you consume far less bandwidth and power.

AK: What are the real or perceived challenges with adding connectivity to devices for IoT?

KK: The reason the industry has challenges is that most wireless-device connectivity technologies (i.e. Wi-Fi, BT) traditionally have been designed for cellular, enterprise, and data communications. In these applications, the device is always on so the off state is not a consideration. These are also data-intensive applications that demand bandwidth to carry the data.  However, IoT devices such as the tiny sensors in thermostats, smoke detectors, or entries to a house, or those sensors on the bridges, or moister sensors in a farm, for example, are almost all battery-operated devices and spend most of their time in sleep or off condition.

If you architect it the traditional way then, yes, you will have power-consumption issues. In IoT, the total cost of ownership is extremely important, due to the large number of devices that will be deployed. Hence, it is not cost effective to send technicians out into the field to change batteries on these devices every four to six months. In consumer applications, the batteries need to last between four and five years, and in industrial anywhere from eight-12 years. What we need for IoT communication devices is a new generation of wireless connectivity solutions, built from the ground up for IoT applications and battery operation. Implementing Wi-Fi in an IoT application cannot be about simply retrofitting from another market where power consumption is far less of a consideration and using it now for IoT, which most vendors are doing today.

Connectivity in IoT is a new way of doing things, hence you need to enable additional modes of operation (including deep-sleep modes) from a software and device-architecture perspective. You also need to enable very fast shut down and wake-up time, as well as partial memory retention to bring the device back to a known state of connection with the least leakage current possible.

One size does not fit all in IoT connectivity and a broad portfolio is required. If a vendor does not have multiple wireless technology capabilities, they cannot offer a complete solution. Simply because you don’t have expertise in a technology or IP, does not mean that the technology is not applicable. Even in 802.15.4, you use ZigBee for lighting and use 6lowPAN for home automation, but you may also need Bluetooth Smart and/or NFC for secure pairing in a multimode solution.

AK: What role do microcontrollers play in this market?

KK: From an architecture perspective, IoT devices are smart devices and what makes them smart is the tiny MCU. All IoT edge nodes include an MCU or MPU, connectivity, sensors and sensing platforms, and an energy source. About 85 percent of IoT devices use MCUs, and the rest will use MPUs. Design an MCU into a toaster oven with a user interface and you can control it in a more predictable and systematic manner. It now has become a “smart” toaster. Add the appropriate connectivity and you can now communicate and control that smart toaster remotely. And because these devices are sleeping most of the time, they benefit from the nonvolatile memory (FLASH) in many MCUs. When the power is off, the device’s memory retains the content.

That’s why thousands of application developers are turning to MCUs. Maker movements are the perfect example of how MCUs in the hand of smaller players are fueling the innovations on the edge node side of IoT. There were nearly 17 billion MCUs sold in 2013 alone and approximately 170 to 200 billion over the past 10 year. Most of these were never connected wirelessly or networked in the traditional sense of “networking”.  Suddenly, MCUs are becoming even more popular because they are the intelligence behind IoT devices. They will go into the sensors which connect to gateways which connect to the cloud, yet a lot of MCU developers don’t necessarily have the expertise in connectivity, networking, and security.

AK: How will the industry address the learning curve of designers who must transform a previously non-IoT device into an IoT device?

KK: It’s true that many of the current MCU developers are not security and connectivity experts and that is a challenge. Remember that the majority of IoT – about 95 percent – is industrial IoT which is a wide application spread out among thousands of small- to medium-sized companies.  These SMEs aren’t in a position to hire another couple of dozen people simply for connectivity and security expertise. As an MCU supplier, you need to understand MCU designers and the fact they are using products without the full expertise needed to optimally use connectivity and security.

At Atmel, we have over 40,000 MCU customers. With that many customers, we have had to learn how to sell in a no-touch fashion, leveraging our tools and development environment. I believe we will measure success in the IoT market by how well you can get to the point with mass market MCU developers where they can “consume” connectivity and security in a no-touch fashion without needing to become experts at it.

AK: What types of companies stand to benefit the most from IoT and why do you feel the Maker community is a key component to success?

KK: There are two sets of players in the IoT market: the traditional MCU companies who have the channels and reach into the mass market, and the traditional wireless connectivity companies whom I call “elephant hunters” since they have traditionally been focused on tens – not thousands – of customers. Most traditional MCU companies don’t have the level of connectivity expertise or the IP required, or their understanding of “things” is elementary. On the other hand, connectivity companies while they have rich connectivity know-how, don’t have the channels and mass market reach or expertise – an absolute must have for this market. Loyalty in channels takes years to develop, and is not an overnight situation into which you can buy your way.

Based on the dynamics of the edge nodes where billions of devices are to be developed, I believe it is the MCU guys who are at the center of IoT-device development. The MCU player that can provide a broad range of MCUs and MPUs, and simultaneously a full portfolio of connectivity solutions (including Wi-Fi which is the toughest nut to crack between all short-range connectivity technologies), will be the winner and capture this market.

Just as in nearly any other market, the majority of innovation in electronics came from small players.  Because IoT is so wide and has so many different segments involved, there is the potential for thousands of starts ups to innovate.

Importantly for IoT, smaller players heavily equates to the Maker community. There are over 1.3 million Arduino users, and of course our partnership with them has made our MCUs prominent on Arduino platforms. You simply can’t establish these this kind of community, allegiances, customers, or critical channels overnight. It’s a 10- to 15-year investment. As an example we have 680,000+ AVR freaks in our community. How long do you think it will take for a newcomer to develop a technology community of that size?


Atmel is committed to becoming the number one fully-integrated edge node provider in the world through an expanded MCU and MPU portfolio, sensing platforms, full IoT communications technologies built from the grounds up for battery operations, integrated security, and a whole host of software offerings related to service delivery and provisioning. Along with this we are establishing a robust ecosystem of partners that can jointly provide full IoT system solutions from the tiniest edge nodes to the service providers in the cloud seamlessly.

At each step along the way, we are bringing innovation, ease-of-use, and integrated solutions to conserve power, extend battery life, ensure data security, and conform to wireless standards in the next big connected design. It’s our way of powering the possibilities of next-generation ideas. Get started today enabling a smarter world of tomorrow!

Want to read more? Access the original Design World interview here.