Posts Tagged ‘top-story’

Next Page »

IoT Security: Intel EPID Starts at the Silicon

Monday, May 22nd, 2017

With a projected 100 billion IoT devices by 2020, security cannot be reliably entrusted to end users or installers deploying millions of IoT devices every month.

There are 8.4 billion Internet-connected things in use this year, which is up by 31% from 2016, according to Gartner, which also reveals that “total spending on endpoints and services will reach almost $2 trillion in 2017.”[1] The Internet of Things (IoT) is shorthand for anything connected to the Internet that can autonomously communicate to accomplish a purpose, transceiving data. Massive amounts of data, in combination with algorithms, artificial intelligence, or other paradigms, can glean information for decision-making on an unprecedented scale. IoT automates painstaking data-gathering and can also provide a low level of interpretation that sifts out irrelevant data. The potential for deeper visibility can result in productivity gains, scalpel-like precision for decision-making, risk reduction, and a heretofore unnatural depth and breadth of information for automation, which can result in savings of time, energy, expense, and capital expenditure.

However, one of our largest IoT problems is security. Another problem is the sheer scale of the number of IoT devices; one projection indicates 100 billion IoT devices deployed by 2020, thus initiating security at deployment can be a challenge. IoT solutions that require manual registration in the field are untenable and impractical. To leave installers to implement the last step in security is overly optimistic when an installation of hundreds of IoT gateway devices need provisioning across an airport, warehouse, or stadium, for example.

IoT security (or lack thereof) creates another issue: Information Technology (IT) network personnel are loath to add IoT devices to the company network. This means that added functionality from IoT devices purchased and installed by operations technologists (OT) (e.g., facilities management) may face significant delays in getting connected to the company network due to a lack of trust. Smart solar, windmills, and simple things like pump monitoring via smartphone will not get connected to the company wi-fi until IT clears the devices as secure. Vendors are left with extra steps beyond the sale to prove trustworthiness, otherwise equipment without connections loses its “smart” status. Security has become an increasingly well-known problem as Internet-connected devices from computers to smartphones to smart light bulbs create individual points of access for hackers worldwide. At the IoT DevCon held in Santa Clara last April, the majority of keynotes were directed at IoT security. Differentiation of smart product design is simply not as interesting as innovation lower down in the stack. Intel® might have an answer, however, that starts with fundamentals in hardware and can be tailored to myriad use cases that characterize IoT.

Intel Makes a Case at IoT DevCon
Jennifer Gilburg, Director of Strategy, IoT Security at Intel corporation delivered a keynote directed at Intel’s Enhanced Privacy Identification (Intel® EPID) security technology, which begins at the physical layer. The Intel IoT Platform is a reference model intended to reduce the complexity of security and interoperability in developing and deploying IoT solutions covering the gamut of use cases (see Figure 1). Intel EPID provides a foundation for addressing secure, interoperable, and affordable IoT development and deployment solutions with the ability to scale to IoT growth while also meeting the most stringent privacy requirements.

The Intel IoT Platform Reference Security Model is a starting place for IoT security implementation. (Source:  Intel white paper: A Cost-Effective Foundation for End-to-End IoT Security.)

The Intel IoT Platform Reference Security Model is a starting place for IoT security implementation. (Source: Intel white paper: A Cost-Effective Foundation for End-to-End IoT Security.)

Gilburg asserts that security in Intel’s EPID technology begins in a hardware root-of-trust and continues throughout hardware, software, and through deployment as products are released. Security cannot be reliably entrusted to end users or installers deploying millions of IoT devices every month. Security needs to be a plug-and-play event for end users and installers if it’s not to be neglected in the last mile. Intel’s effort centers around helping developers do it right with an end-to-end technology like EPID, which Intel partners such as Microchip use, beginning in the silicon. Root-of-trust offers inherently trusted elements, whether hardware or software based, in the chain of custody for deploying secure IoT.

Gilburg rightly states that effective security extends across the entire lifecycle of a product. A viable product should have a minimum of protection, which she indicates that Intel terms a “minimum viable product,” meaning “the least that you can get away with.” That the least effort starts in silicon is no surprise, considering the sophistication of hacks at the lowest level of the stack, such as at boot up or in firmware updates. In her talk, Gilburg went on to explain that “…if you do nothing else with security, you have to have these building blocks. And so we put it into our silicon. It’s protected boot, protected storage. You want hardware and software identities, you want the ability to have a hardware root of trust, but you also want to be able to store software keys in a hardened fashion, in a trusted execution environment.”

For  IT networking personnel, assuring security requires attesting the authenticity of IoT devices throughout the lifecycle, including at hardware manufacturing, throughout software integration, installation or deployment, and even within the process of creating data. Intel’s EPID uses layers of security, starting with cryptography in the bedrock silicon of the chip using advanced hardware and software security.

A boon in EPID that U.S.-only markets are now thinking about is fundamental privacy. EPID does not require personally identifiable information to work, unlike the persistent identity associated with Public Key Infrastructures (PKI). It is not feasible to expect privacy when data is associated with an identifiable entity in every instance. To maintain hope of gaining acceptance in countries with strict privacy laws, the goal should always be to collect the minimum amount of data needed to do the job, and no more. Collect only a minimum amount of information that is tied to your data so you have only the metadata necessary to accomplish a task. IoT should not be collecting anything else, as it’s simply a liability to do so. Therefore, EPID does not require individual identifiers. This is important in countries with strict privacy laws like Japan and Germany. For example, if an IoT system monitoring traffic speed has sensors that detect a car on the highway, all the IoT monitoring system needs to know is that the car is legitimate (not someone spoofing a car) and the speed of the car. Further on down the highway the same car might pass by, but the IoT system will not recognize it as the same car, only that it is again a legitimate car and that car’s speed.


EPID starts with minimum data for strict privacy use cases. PKI can always be added for use cases that require specific identification, such as positive identification for billing. (Source: White Paper, Enhancing National Cybersecurity with the Internet of Things (IoT))

EPID starts with minimum data for strict privacy use cases. PKI can always be added for use cases that require specific identification, such as positive identification for billing. (Source: White Paper, Enhancing National Cybersecurity with the Internet of Things (IoT))

Aiming IoT only at an intended target while minimizing data collection on that target also reduces network traffic while limiting security to a “need to know basis.” As mentioned above, one of the unintended consequences of traditional PKI is the ability to trace users. When you have a public key and a private key and your device requires the signature of the private key, then you know who signed it. This is how traditional PKI works. With EPID there are multiple private keys linked to one group key. With EPID, unless you intentionally add PKI on top of EPID (e.g., for billing), you cannot determine that an action was the same user authenticating twice. If EPID is a built-in technology, developers can minimize the data that they are collecting and sharing while maintaining compliance in countries with strict privacy laws. But with traditional PKI, starting with a foundation of enhanced privacy and determining later whether the use case needs additional known data is not possible.

It’s interesting to note that EPID is in all Intel silicon. EPID is an ISO standard and a Trusted Computing Group (TCG) standard. EPID security includes two-way, mutual authentication so that the new owner needs to prove itself to the device as much as the device needs to prove itself to the new owner. Rogue devices (such as such as smart drones hovering near smart lamps) are prevented from taking over devices in an ecosystem. EPID is also available in Intel partner silicon and freely and openly available for anyone to use.

The process of how EPID gets implemented has most of the heavy-lifting done before the installer ever touches a smart product, but use cases can vary. However, in a common scenario EPID-provisioned silicon goes to an OEM, who puts in a unique General Use Identification (GUID) identifier. (A GUID is a one-time-use identifier for the IoT device to identify itself to the authentication service later on.) At the time of execution or onboarding, a URL in the device allows it to “phone home” to the onboarding service upon power up. An ownership credential is generated that initiates a chain of trust. The chain of trust allows the supply chain to sign the certificate that went before it, so when the owner buys the IoT device they can observe a chain of trust all along the supply chain. Similar practices exist for authorized parts distributors, pharmaceuticals, and evidence in criminal investigations. Within the EPID framework, the process will authenticate the new owner to the device, and the device can verify the new owner.

A Proof-of-Concept Use Case
To better illustrate how EPID can work, what follows is a proof-of-concept use case. As an example, consider a smart light bulb. Once the lightbulb is assigned a GUID number at the OEM, an entity further down the chain, perhaps a distributor, might receive the lightbulb. The distributor signs the ownership proxy, which is a digital document in the chain of trust that goes with the light bulb through the supply chain. Ultimately an end user buys the light bulb and installs it in an IoT platform management system, which we will call “Wee-wow” as a fictional example. Thus, Wee-wow will manage the lightbulb once it’s deployed. When the end user buys the smart light bulb, they import the ownership proxy into their Wee-wow platform management system. Wee-wow pings the EPID service to identify itself as the end-user platform that’s using the new smart light bulb’s unique GUID number. The Wee-wow IoT platform management system contacts the EPID service with a message stating something like, “I am GUID345. I will wait at IP address 8.8.8.8.” In this example, the installer comes in the following week, hikes up a ladder and screws in the smart light bulb.  Upon power-up, the smart light bulb connects with the service, identifies itself as GUID345, and requests the identity of its new owner. The service then tells the smart light bulb to “try the owner, Wee-wow, at IP address 8.8.8.8 because it claims that it’s your new owner.” It’s important to note that the process arranges matchmaking, so to speak, between device and owner and is not negotiating trust in the cloud.

The smart light bulb then connects to the IP address 8.8.8.8 and shows its EPID signature. In this use case, there could be an attestation service that allows you to attest to the validity of the device, as in what type of device it is, or other validation characteristics. After seeing the valid EPID signature, the Wee-wow IoT platform management system sends down the owner proxy and mutual authentication is accomplished. The first signature in the ownership proxy should match the key that was put into the smart light bulb at manufacturing. If it’s a match, the service creates a secure tunnel that allows the developer to provision whatever is needed to make the device operational, for example, updated images and instructions. The service then deletes the ownership credential, onboarding service information, and the GUID, replacing the values such that if the device ever needs to be re-provisioned there are clean credentials for the smart light bulb.

As mentioned earlier, Intel is offering the EPID technology to others. According to the 2016 Intel white paper, A Cost-Effective Foundation for End-to-End IoT Security, “Intel is making Intel EPID technology freely available to all silicon and device manufacturers, software vendors, and the broader IoT community.” A de-facto standard for IoT security couldn’t come too soon. Intel’s realistic conclusion that installers should not be depended upon to key in codes atop a ladder with a smartphone or tablet app is spot-on.

Kicking the Can Down the Road Won’t Work
If IoT is to scale to 50 – 100 billion devices by 2020, depending on the estimate’s source, group and device permissions in the EPID paradigm ease the deployment phase. If an installer is deploying 500 gateways, the installer is mainly concerned with getting the work done, and should not be burdened with keying in long numbers to implement security for each device. Kicking IoT security down the road means it will need to be dealt with later, most likely after some disaster forces positive, not passive action. IoT is vulnerable to hackers, and security is best not left to the last person on the chain. New IoT devices and innovative use cases create new opportunity, revenue, and challenges. As new IoT devices and IoT system architectures are considered for IoT edge devices (which act something like a server-gateway hybrid to pre-process massive amounts of data) we can expect system designers from respected suppliers to take security seriously. As Gilburg said in her keynote, “We’re working with enabling different industry partners…We are saying, ‘Is there a need to securely onboard these devices?’ and 99% of the time the answer is yes, so there’s a lot of opportunity and a lot of interest from customers on solving this problem.” Gilburg was three-deep in a cluster of engineers after her talk, who eagerly peppered her with questions.  Interest is high in  a solution that can be tailored to individual use cases while maintaining privacy from a global viewpoint. IoT is seen as a huge money-maker, but with it comes the cost of mobilizing security.


LynnetteReese_115Lynnette Reese is Editor-in-Chief, Embedded Intel Solutions and Embedded Systems Engineering, and has been working in various roles as an electrical engineer for over two decades. She is interested in open source software and hardware, the maker movement, and in increasing the number of women working in STEM so she has a greater chance of talking about something other than football at the water cooler.


[1] “Gartner Says 8.4 Billion Connected.” Gartner. N.p., 7 Feb. 2017. Web. 15 May 2017. <http://www.gartner.com/newsroom/id/3598917>.

How to Make Your IoT Gadget Smaller and Cooler

Thursday, April 20th, 2017

Turning away from typical approaches can stretch battery life and use space more successfully.

Charging and fuel gauging ICs—at the heart of every battery management system—are critical components of ever-shrinking mobile and IoT electronic gadgets. While size is shrinking, complexity is increasing. Faster charging with minimum heat generation calls for high-efficiency charging at a high input voltage and a high charge current. This article reviews a typical approach for meeting the challenges of reduced space requirements and minimizing heat generation. It then presents a new solution that delivers more efficient power in a smaller space, enabling longer battery life and smaller form factors.

Fig01_shutterstock_519849535WEB

Figure 1: Smartphone at End-of-Charge

Typical Power Management Implementation

A typical charger and fuel gauge system is shown in Figure 2. In addition to the charger and the fuel gauge, it includes two safeout low dropout regulators (SFLDO) that drive the system’s USB interface. For simplicity, the external passives are not shown.

Figure 2: Typical Charger and Fuel Gauge System

Figure 2: Typical Charger and Fuel Gauge System

All active and passive components for the system diagram shown in Figure 2 are accounted for in the solution drawing of Figure 3.

Figure 3: Typical Charger and Fuel Gauge System Footprint (55mm2)

Figure 3: Typical Charger and Fuel Gauge System Footprint (55mm2)

The 1.5µH, 3.5A inductor (in a large 2520 package) and the two external LDOs present a huge challenge in terms of space. This solution occupies a board area of about 55mm2.

An Integrated Solution

The PMIC in Figure 4 (MAX77818) integrates the charger, fuel gauge, and LDOs in a single chip. This eliminates the wasted space associated with using multiple components. Another advantage of this solution is the ability to use a lower value 0.47µH inductor that carries 3.5A in a smaller 2016 package.

Figure 4: Highly Integrated Charger and Fuel Gauge System-on-Chip

Figure 4: Highly Integrated Charger and Fuel Gauge System-on-Chip

All active and passive components of the system diagram shown in Figure 4 are accounted for in the solution drawing of Figure 5.

Figure 5: Highly Integrated Charger and Fuel Gauge System Footprint (37mm2)

Figure 5: Highly Integrated Charger and Fuel Gauge System Footprint (37mm2)

The total board space occupied by the components is a mere 37mm2, saving 33 percent of the real estate. In addition, the MAX77818 draws only 20µA of total quiescent current. This saves valuable battery life, which enables either system size reduction by using the smallest battery possible or longer use time between each charge.

More Efficiency in Less Space

A comparison between the efficiency (from CHGIN to BATT) of the MAX77818 charger solution and a competitive solution is shown in Figure 6. To provide a true comparison, both solutions are powered with a 1µH inductor in a 2520 package. The integrated charger solution exhibits higher efficiency across most of the load current range even with a substantially higher switching frequency. At full load (3.5A), the efficiency of the integrated solution is well above 88 percent, while the competitive solution is just above 86 percent, a more than two percent efficiency difference.

Figure 6: MAX77818 vs. Competitor Efficiency

Figure 6: MAX77818 vs. Competitor Efficiency

Even with the large 2520 inductor, the integrated solution is 30 percent smaller than the competitive solution.

MAX77818 Integrated Charger and Fuel Gauge

The MAX77818 switching charger is designed with a special CC, CV, and die temperature regulation algorithm. The ModelGauge™ (m5) algorithm delivers battery fuel gauging with the highest accuracy available while operating with extremely low battery current.

The fuel gauge must be loaded with a factory characterization file (INI) to match the battery in use. Maxim has developed a vast battery database of cell characteristics and behaviors over a wide range of test conditions based on customer use cases. This allows Maxim to provide an initial configuration file that works well with the battery until a more specific battery characterization file is created to achieve the highest accuracy operation. To learn more about the terms of support for battery characterization, please contact technical support.

Additional Advantages of Integration

A fuel gauge IC has temperature-sensing capabilities to conform to the correct charging profile based on the battery at hand. That’s not normally the case for the charger IC. However, JEITA, a Japanese electronics protocol that has become the standard for lithium-ion (Li+) batteries specifies charger behavior vs. temperature. For example, to control charge current and voltage based on temperature, which reduces the current at cold temperatures, the charger would need to integrate a temperature sensor or a microprocessor host to provide temperature information. But the MAX77818’s integration permits the fuel gauge and charger to easily access the temperature, an important function when the JEITA mode is enabled. Integration reduces silicon overhead and potentially lowers the thermistor countFinally, with the fuel gauge and charger in the same package, there is less chance of having PCB layout issues.

Conclusion

We have discussed the shortcomings of a typical charger-fuel gauge implementation and introduced a new, highly integrated solution. The new solution, compared to an alternative implementation, delivers a full load efficiency advantage of more than two percent and a 30 percent reduction in PCB area, enabling longer battery life and smaller form factors.


Bakul-DamleBakul Damle is the Mobile Power Business Management Director at Maxim Integrated. His current interests include battery and power management specifically in fuel gauges, battery charging, energy harvesting, wireless charging, and battery authentication. He has several patents in test and measurement. Bakul holds a Master of Science degree in Electrical Engineering from the California Institute of Technology and a Bachelor of Technology in Engineering Physics from the Indian Institute of Technology.

JiaHuJia Hu is an Executive Business Manager for Mobile Power at Maxim Integrated. He has more than 15 years of experience in the semiconductor industry. Jia holds a master’s degree in Electrical Engineering from the University of Washington and bachelor’s degrees in Electrical Engineering and Economics from the University of California, Berkeley.

Nazzareno-Rossetti_2017Nazzareno (Reno) Rossetti, Principal Marketing Writer at Maxim Integrated, is a seasoned Analog and Power Management professional, a published author and holds several patents in this field. He holds a doctorate in Electrical Engineering from Politecnico di Torino, Italy.

What Caught My Eye at Embedded World 2017

Friday, March 24th, 2017

This year’s show starred innovations in automotive, automation, the IoT via carrier boards, and more.


More automation was displayed at VIA Technologies, for transportation, home automation and digital signage. The company announced the VIA VTS-8589 OPS board and the VIA Custom IoT Platform Design Service.

Germany’s government is heavily promoting the advance of Industry 4.0, or the Industrial IoT. Many of the booths at Embedded World reflected this. Analog Devices, which has acquired Linear Technology, had demonstrations of Industry 4.0 and how the smart factory meets challenges around instrumentation, controllers, condition-based monitoring, industrial communications, and data analytics. Other demonstrations showed Ethernet/IP, IoT asset tracking, and healthcare, with sensors in wearable devices, and low-power sensing technology for patient monitoring. Automotive-related demonstrations featured in-vehicle communications based on the SHARC SDSP-21489 processor and radar that employs sensors for Advanced Driver Assistance Systems (ADAS).

Figure 1: Embedded World 2017 welcomed over 30,000 trade visitors.

Figure 1: Embedded World 2017 welcomed over 30,000 trade visitors.

Imagination Technologies’ booth also highlighted ADAS and the role of MIPS in the connected car. It was showing a Mobileye product for autonomous driving, just days after Intel acquired the Israeli company, and PowerVR GPU-power screens for the high end (from Renesas) to the entry-level Socionext display for ADAS.

Figure 2: Imagination Technologies had a series of automotive displays.

Figure 2: Imagination Technologies had a series of automotive displays.

IAR Systems was also concentrating on the automotive market, with updates to IAR Visual State, its state machine design tool. Version 8.1 introduced features to streamline development of user interface designs, especially in the automotive industry. This was one of several announcements at the show from the Swedish company. It also announced that it is a technology partner with Samsung for the Samsung ARTIK Smart IoT program, to offer users the development toolchain IAR Embedded Workbench to generate code for energy-efficient, time-critical Internet of Things (IoT) applications. The latest version of the IAR Embedded Workbench for ARM was also announced in Nuremberg. Version 8.10 offers C11 and C++14 language support, and an updated Integrated Development Environment (IDE).
A strong advocate for the IoT is ARM, and its booth was busy with various examples of IoT, in particular for lighting, using mbed OS 5.4. The latest release of the OS supports cellular, WiFi, 802.15.4, Bluetooth low energy, Thread, the Internet Protocol version 6 (IPv6) protocol, or sub-GHz IPv6 over Low power Wireless Personal Area Networks (6LoWPAN) for multiple protocol connectivity across networks.

Display Technology
Additions to the Kinetis family were also announced by NXP. The Kinetis K27/K28 ARM-based microcontrollers will be available in April this year and are designed for portable battery applications. The microcontrollers target smart homes and wearable devices as well as industrial portable equipment, with 1-Mbyte embedded SRAM and support for peripherals to optimize battery life, add program and data storage, or process sensors in connected IoT devices.

At Bridgetek, the PanL35 smart display module had to vie for attention with sister company, FTDI’s CleO display board controllers (Figure 3).

Figure 3: An example of pyramid selling? The CleO display board controllers.

Figure 3: An example of pyramid selling? The CleO display board controllers.

The PanL35 relies on EVE software to create apps and is described as bridging modern and legacy communications interfaces. It has Bridgetek’s Superbridge microcontroller, FT903 and EVE graphic controller, the FT811. Interfaces included are RS485, RS232, I²C, SPI, and expandable options such as WiFi and Bluetooth low energy. There is also the facility to use microphone input, audio, proximity infrared sensors, FM output, real-time clocks and SD card flash memory storage, for use in a variety of industrial applications and building automation projects, energy management systems, remote monitoring and information or operator interface panels.

Meanwhile, FTDI Chip announced that a new CleO smart TFT display controller would be released in April, with an I/O shield, a radio receiver and sensors, targeting Point of Sale (PoS) and retail shelf displays.

Figure 4: The VTS-8589 OPS board from VIA Technologies addresses digital signage.

Figure 4: The VTS-8589 OPS board from VIA Technologies addresses digital signage.

More automation was displayed at VIA Technologies, for transportation, home automation, and digital signage. The company announced the VIA VTS-8589 OPS board, designed for digital signage applications and which complies with Intel’s Open Pluggable Specification (OPS). It can be installed into OPS-compatible displays without needing additional power, connectivity, or real estate. It is based on NXP’s i.MX 6QuadPlus or i.MX 6Quad Cortex-A9 SoCs and has 8-GByte eMMC Flash memory, 2-GByte DDR3 SDRAM, onboard WiFi, Gigabit Ethernet, a Micro SD card slot, and two USB 2.0 ports for multimedia, I/O and connectivity options. The company offers a Linux Board Support Package (BSP) designed for HTML5-based digital signage applications.

Its VIA Custom IoT Platform Design Service aims to accelerate the design and manufacture of application-specific IoT systems and devices. Customers can specify form factor as well as system and I/O requirements for a custom system design. The design service offers support to define the core system, prototyping as well as hardware and software development, and I/O and wireless connectivity integration. VIA also manages the production.

Embedded Boards
Innovative embedded boards found at the show included the  SMARC 2.0 carrier board, launched by Connect Tech. It is a Commercial Off The Shelf (COTS) board with attributes for low power IoT and multimedia applications, such as USB 3.0 (there are two USB 3.0 ports), two channels for Low-Voltage Differential Signaling (LVDS), two channels for Ethernet, an additional PCI Express lane, to bring the number of lanes up to four, and an extra USB 2.0 port, to make three in total. The carrier also offers two Mobile Industry Processor Interface (MIPI) alliance Camera Serial Interface-2 (CSI-2) camera interfaces, High Definition Multimedia Interface (HDMI) outputs and Serial Advanced Technology Attachment (SATA) to support the latest Apollo Lake x86, low power processor from Intel. The carrier board is also designed to operate over the extended temperature range of -40 to +84°C.

SMARC 2.0 was also in evidence at the congatec booth, as it launched the conga-SA5 SMARC 2.0 computer module, with support for USB-C connectivity. The module (Figure 4) reduces cabling requirements and standardizes the interface needs. The USB-C option allows developers to use standard peripherals and to connect displays or a power supply. It is also based on the Intel Apollo Lake processors, Intel Atom, Celeron or Pentium processors.


Figure 5: SMARC 2.0 brings USB 3.0 to the conga-SA5 computer module.

Figure 5: SMARC 2.0 brings USB 3.0 to the conga-SA5 computer module.

Examples of wireless sensor networks included the congatec Cloud Application Programming Interface (API) for IoT gateways and IoT edge servers. The gateways communicate with local smart sensors, then process and convert the acquired data and execute automated actions based on a local rule engine. They reduce traffic to the IoT cloud and offer secure, bi-directional data exchange with clouds using the Transport Layer Security (TLS) -secured Message Queuing Telemetry Transport (MQTT) protocol. Target applications are industrial production and machinery, smart cities, smart homes, smart energy grids, medical IoT, transportation, and digital signage. It combines Bluetooth low energy, ZigBee, and LPWANs, like LoRa.

A PC/104-compatible Single Board Computer (SBC) was the highlight of the WinSystems booth. The PCM-C418 boards are low power, dual Ethernet, PC/104-compatbile SBCs. They respond to customer demand for robust SBCs with dual Ethernet, a small form factor, and the ability to operate in the extended temperature range. The SBC has full ISA compatibility, a CompactFlash socket, and external SATA connector for storage options. It is backward-compatible with legacy PC/104 systems and supports Linux, DOS, and other x86-compatible Real-Time Operating Systems (RTOS), for industrial IoT, transportation, Mil/COTS and energy applications.

The PC/104 form factor was also in vogue at RTD Embedded Technologies, which presented the LAN35MH08HR managed switch at its booth. The eight-port 10/100/1000 managed Ethernet switch has an additional two ports, one to the host CPU through a PCI Express GigE controller, and a port used as a stacking switch expansion port to make the module compatible with the company’s managed and unmanaged StackNET family of Ethernet switches, routers, compatible power supplies, and computer modules. The configuration options, with CEService Carrier Ethernet switching software for carrier and timing-critical networks, make it suitable for IoT, industrial networks, and timing sensitive networks.


Figure 6: Increased connectivity expands options for ADL Embedded Solutions SBCs.

Figure 6: Increased connectivity expands options for ADL Embedded Solutions SBCs.

Increased connectivity enables SBCs from ADL Embedded Solutions to be used in unmanned systems, robotics, wearable computing, and portable medical devices. The company introduced the ADLE3800SEC SBC with Edge-Connect architecture enabling I/O expansion and connectors.

The SBC is based on the Intel Atom E3800 SoC and measures 75 x 75mm. It can be used in harsh environments, operating at -40 to +85°C. It can be embedded in radar applications in mobile navigation systems, surveillance cameras, and traffic management systems.


hayes_caroline_115Caroline Hayes has been a journalist covering the electronics sector for more than 20 years. She has worked on several European titles, reporting on a variety of industries, including communications, broadcast and automotive.

Power Systems Design for Wearables: Life’s No PMIC – Q&A with Silego Technology

Monday, February 6th, 2017

Considering an approach to power management that could re-invigorate wearables

Editor’s note: In late 2016, Silego Technology announced a major expansion of its Configurable Mixed-signal IC family to include power management. With this announcement, designers can create “Flexible Power Islands” to slay the frustration of lengthening battery life for portable devices such as handhelds and wearables. Nathan John and Mike Noonen spoke with EECatalog not long after the announcement. John and Noonen are the company’s Marketing Director, Mixed-signal Matrix Products and WW VP Sales and Business Development, respectively. Edited excerpts from the conversation follow.

EECatalog: What’s needed in the wearables market?

Mike Noonen, Silego Technology

Mike Noonen, Silego Technology

Mike Noonen, Silego: I used to be at National Semi, and more than 10 years ago National did a chipset for Microsoft when Microsoft introduced its first smartwatch, SPOT Watch. Nobody remembers it because the battery life lasted all of one day.

Now, fast forward a decade later, and in the more advanced smartwatches the battery life is two days. One of the reasons smartwatches have not taken off to the degree that people had hoped and expected is that it requires care and feeding of a battery that is definitely a gigantic step backward with regard to the maintenance that people have had to put into watches for the past century.

At Silego, we’re approaching the problem and the opportunity in a different way. We believe that for a lot of sensors and the most basic of wearables, what most designers are proposing or doing is overkill, and consumers are frustrated.

However, by using a Configurable Mixed-signal IC—in many cases asynchronous state machines—a lot of functionality can be done at an order of magnitude lower power [compared to] throwing an ARM microprocessor at the problem. Not to say that we can do everything, but we think that innovative solutions like ours are part of attaining the functionality as well as the user experience that customers want. Having to plug something in every night isn’t the answer, nor is or having a form factor that requires a battery that makes the smartwatch less decorative and not very fashionable.

We think this is an opportunity for Silego to re-invigorate wearables, and the customers we’ve engaged with are seeing our solution, our technology, as a step in the right direction to get that longer battery life, small form factor and functionality that users expect.

Nathan John, Silego Technology

Nathan John, Silego Technology

Nathan John, Silego: Silego has been successful in wearables, but that is not because we have been focused on wearables; it has more to do with the fast pace of the wearables market. Customers in that space have big challenges, and they are inventing new architectures, and—typical of our customers—they are boldly going where nobody has gone before.

We use configurability to allow customers to make solutions their own. In industries that are in the midst of disruption, as wearables is right now, configurability and flexibility are valuable.

Figure 1: Design challenges for power systems designers. [Image courtesy Silego].

Figure 1: Design challenges for power systems designers. (Image courtesy Silego)


EECatalog: What are Flexible Power Islands and why are they needed?

John, Silego: Smartphones and other consumer electronic devices with relatively complex electronics (Figure 1) often have a battery that the manufacturer wants to be large to improve battery life, but at the same time, the physical form factor of the device can’t get bigger.

So, this delicate balancing act occurs: How do you make it last longer and not get bigger, heavier, less portable? Power designers in particular face a host of challenges with small form factor consumer electronic devices.

If the device is a smartphone, among the keep-you-up-at-night problems it presents to power designers are complex board shapes, the clustering of amplifiers and microphones at the edge, and worries about heat. And all that is on top of the battery muscling in on PCB space.

What you’d typically have in the smartphone would be a Power Management IC (PMIC) at the center. With a distance of as little as two inches from the edge though, that PMIC is less effective than power management at the edge, where the microphones, etc. are. The SLG46125M device we’ve introduced can be used as a Flexible Power Island to augment the capabilities of the PMIC. Designers do not have to replace the PMIC or change the device’s fundamental architecture.

EECatalog: You noted that distance from the edge, are there other drawbacks that PMICs have?

John, Silego: One thing about the suppliers that sell these PMICs: They don’t make changes very fast. So often our customers say, “I would love to have my PMIC supplier just make this change for me,” but either the PMIC supplier won’t do it because they expect a really, really high volume to do that, or they say, “Yes, I’ll make that change and I’ll give you that change in six months.” Whereas we would say, “Hey, take one of our little devices, configure it in a couple of days, drop that on your board, and you’re off and running.

EECatalog: PMIC suppliers might have reason to look over their shoulders?

John, Silego: Over time we expect to build more devices that will serve in this role of Flexible Power Islands, and the ultimate end game could be for a customer to say, “Well, if I put two of these FPI parts on there, can I remove the PMIC altogether?” That is certainly the long-term vision for how we are attacking this.

EECatalog: What are some of the characteristics of the Flexible Power Islands that support Silego’s being comfortable with taking that long-term vision?

John, Silego: One of the things that we are touting to our customers is that besides getting the ability to perform functions—switching regulation; linear regulation; power gating/slew rate control; control/sequencing /timing; power monitoring; RTC; GPIO—they should now expect to have flexibility as one of the extra added benefits that they might not have had before.

Also, the SLG46125M can capitalize on the full flexibility of our GreenPAK architecture. Customers can mix and match the functions that we supply and do the interconnect so that they can turn it into their own little ASIC. We also supply a set of software that allows them to do that.

So quite literally, our typical design time is a couple of days, and somebody has an ASIC. They can program a few samples of their own to test it out in their system. Next, they supply that as a design file to us, and we say, “How many do you want to buy?” We program it; we test it; we sell it to them as if it was an ASIC.

This particular device has a set of power switches, so not only can you do the control aspects, but you can also switch on and off the different power rails. The SLG46125M device is also small, a 1.6 x 2.0 mm MSTQFN package.

And with regards to long term, we’ll be offering new resources that we don’t offer in this first device, making it possible for designers to have all the functional elements in their power system included in one of our tiny flexible devices.

EECatalog: Some of the frustration designers have been experiencing as devices shrink could be alleviated.

John, Silego: Absolutely, and the frustration will be avoided especially for power systems designers, who feel they get the least attention of anybody—they [traditionally] get the oldest, boring-est technology, so when we tell them these parts are small and flexible, the power systems designers are interested in that.

Figure 2: The blue rectangles represent physical pins; the green wires represent connections. (Image courtesy Silego Technology)

Figure 2: The blue rectangles represent physical pins; the green wires represent connections. (Image courtesy Silego Technology)

EECatalog: What else is in the works?

John, Silego: We want to make our fast design cycles even faster. We want to give customers tools so that they can be more accurate in the development process and do it more easily and at less cost.

To support those goals, we’re enhancing our development tools by including SPICE simulation. The little blue rectangles shown on Figure 2 are the physical pins on the device. Customers cannot only add the functional elements, they can also add the little green wires to connect them all together.

Figure 3: Green circles show simulation test points. [Image courtesy Silego Technology]

Figure 3: Green circles show simulation test points. (Image courtesy Silego Technology)

One way for designers to debug their designs is by downloading that design directly into a part and then testing it out at the physical board level. What we are adding here is a new capability enabling customers to do this is a simulation environment, using SPICE. The little red indicators on Figure 3 are the signals being generated in a simulation world, and then there are little green circles to indicate where the designer has dropped down a simulation test point. It’s possible to view the signals at those various parts in the circuit as it’s running in the simulation environment. Customers gain the ability to quickly assess their design and look for mistakes that they might have made. They can do all the debug steps in a faster and more efficient manner.

Simulation environment debugging is also complementary with our existing debug methodology, which is a hardware-centric model. For each one of their devices, we have a development board, and you can download the capability for your custom solution into that board and then test it out at a hardware level. That certainly won’t go away, but [simulation environment debugging] adds a new parallel methodology.

EECatalog: Does simulation environment debugging save time?

John, Silego: Yes, although we were not taking much of their time in the first place. I mentioned earlier that we have development cycles of a couple of days—that’s from assembling the specifications; designing the circuits; doing debug and testing, and saying, “It’s a done deal.”

We have already given them valuable tools that allow them to do this process quickly. This is just another way to maybe save a couple of hours off the debug process. We are not saving them days and weeks, because we never asked them for days and weeks in the first place.

Extending Battery Life in IoT Devices

Tuesday, January 31st, 2017

Use embedded FPGAs to perform low-level chores.

optional_lead-in_image

Most Internet of Things (IoT) integrated circuits are battery operated, and users do not want to change batteries (consider smoke alarms chirping in the middle of the night). Ironically, during the life of an IoT chip, little time is spent doing complex processing. Rather, most time and energy is being dissipated in low-level, repetitive tasks. The good news is that battery life can be extended, at least in the cases we analyzed, by using an embedded FPGA to do the low-level, repetitive tasks instead of the processor. The embedded FPGA does not replace the processor, as it is still used for the more complex tasks. This article considers an example using the ARM® Cortex®-M4 processor only because of availability of data for comparison. However, the conclusion is not specific to ARM, but applies to any embedded processor on the market today.

Introduction to Embedded FPGAs

An FPGA combines an array of programmable/ reconfigurable logic blocks in a programmable interconnect fabric. In an FPGA chip, the outer rim of the chip consists of a combination of GPIO, SERDES and specialized PHYs such as DDR3/4. In advanced FPGAs, the I/O ring is roughly 1/4 of the chip and the “fabric” is roughly 3/4 of the chip. The “fabric” itself is mostly interconnect in today’s FPGA chips, where 20-25% of the fabric area is programmable logic and 75-80% is programmable interconnect. An embedded FPGA is an FPGA fabric without the surrounding ring of GPIO, SERDES, and PHYs (Figure 1). Instead, an embedded FPGA connects to the rest of the chip using standard digital signaling, enabling very wide, very fast on-chip interconnects.

Figure 1: Typical FPGA compared to an embedded FPGA

Figure 1: Typical FPGA compared to an embedded FPGA

For this analysis, to show power specifications we will use those of the Flex Logix EFLX embedded FPGA. Flex Logix provides high-density, high-performance, energy-efficient embedded FPGA hard IP. Its EFLX platform is a scalable architecture of silicon proven IP that enables embedded FPGAs from ~100 LUTs to >100K LUTs. The smallest core (EFLX-100) has 120 LUTs with 152 inputs and 152 outputs. The larger core (EFLX-2.5K) has 2,520 LUTs with 632 inputs and 632 outputs. The cores can be “tiled” to form arrays. The EFLX-100 cores can be tiled to build arrays up to 5×5 or 3,000 LUTs of reconfigurable logic with 760 inputs and 760 outputs. The EFLX 2.5K cores can be tiled to build arrays up to 7×7 or 123K LUTs of reconfigurable logic with 4424 inputs and 4424 outputs. The EFLX cores have two versions that can be mixed together in arrays. One version is all logic, and the other has 22-bit MACs for DSP functions. The small core can have 2 MACs, and the large cores can have 40 MACs. The cores also support memory structures that can be part of the array for small memory sizes or outside of the array for larger memory sizes.

The embedded FPGA is programmed using Verilog or VHDL, which are input to a synthesis tool such as Synopsys’ Synplify. The EFLX Compiler takes the synthesized output and packs/places/routes the array and generates a bit stream that programs the EFLX array to emulate the RTL. The bit stream for a single EFLX-100 is ~50K bits and can be stored in the same flash memory that stores the embedded processor code. The EFLX array can be reprogrammed at any time, just like an embedded processor.

Embedded FPGAs can also be integrated as accelerators on the processor bus, as programmable logic in the control path or as I/O processors; or some combination of these.

Using Embedded FPGAs to Offload DSP Functionality

The embedded FPGA can be used to offload some DSP algorithms that take fewer clock cycles and consume less energy than running the DSP algorithms on an ARM Cortex M4F CPU. This analysis was done in TMSC 40ULP process as an example showing that the ARM Cortex M4 consumes ~1.5-4.75x more energy over EFLX for the same DSP computations. The actual ARM power will be higher due to instruction fetch and memory access power that were not factored into the power analysis for the ARM CPU. The ARM Cortex M4 requires ~17-31x more clock cycles than EFLX for the same DSP functions. The total energy for running the DSP algorithm on EFLX embedded FPGA is frequency independent and the data throughput of EFLX is fully proportional to EFLX frequency (e.g. no cache misses, etc.). A 5-tap FIR filter and a single stage Biquad filter were examples of DSP algorithms used for the analysis.
Embedded FPGA Power Architecture Features

A typical FPGA architecture is shown in Figure 2.

Figure 2: Typical FPGA architecture

Figure 2: Typical FPGA architecture

An embedded FPGA has none of the most power-hungry blocks: PLL, SERDES, PHYs, and connections with the rest of the chip are through standard CMOS “pins” or drivers.

The EFLX embedded FPGA in TSMC 40ULP has power gating (Figure 3) on the array level with state retention (down to 0.5V) and fine grain clock gating on the logic-block level, reducing dynamic and static power.

Figure 3:  Power gating of the array

Figure 3: Power gating of the array

Figure 4: ARM vs EFLX data flow and power profile

Figure 4: ARM vs EFLX data flow and power profile

Processor vs Embedded FPGA Data Flow and Power Profile

Figure 4 shows the data flow of running the DSP algorithm in an ARM Cortex CPU versus an EFLX array. For the ARM CPU, the DSP algorithm execution requires cache, FLASH and SRAM resources to be used. For EFLX, only a DMA bus master and the EFLX array is used to run the DSP algorithm while the rest of the SoC can be powered off. The memory controller and external memory is used for both cases.

Energy Analysis Details

Two filters were used for the analysis: 5-tap FIR filter and a single stage Biquad filter (Figure 5). Both filters were chosen because of their relevance in low-power, battery-powered applications (FIR filters are extensively used for data communications, audio echo cancellation and smoothing data, and Biquad filters are extensively used for audio equalization and motor control).

Figure 5: 5-tap FIR  and single stage Biquad filters

Figure 5: 5-tap FIR and single stage Biquad filters

Figure 6: Cortex M4F C-Code for Biquad and FIR Filter

Figure 6: Cortex M4F C-Code for Biquad and FIR Filter

Figure 7: FIR and BIQUAD filters Verilog code

Figure 7: FIR and BIQUAD filters Verilog code

Figure 8: EFLX-100 Energy Curves For DSP Filters For 256 Data Sample

Figure 8: EFLX-100 Energy Curves For DSP Filters For 256 Data Sample

Running the filter algorithms in an ARM Cortex MF4 took 4080 cycles for the biquad and 8080 cycles for the FIR for 256 data samples (Figure 6). Running the same algorithms in EFLX took 256 cycles for 256 data samples, which was 17.5 times to 31.6 times faster than running on the ARM CPU respectively (Table 1).

Table 1: EFLX-100 Total Energy Compared with ARM Cortex M4 for 256 Data Samples

Table 1: EFLX-100 Total Energy Compared with ARM Cortex M4 for 256 Data Samples

  1. M4 joules per cycle estimated at 8pJ based on TSMC 40 nm G process @.9V, 25C
  2. M4 power will be higher due to cache, instruction fetch power
  3. External memory accesses are normalized between M4 and EFLX

The 16-bit FIR filter and 16-bit biquad filter (Figure 7) used 3 EFLX-100 cores and the 32-bit FIR filter used 5 EFLX-100 cores using only ~20% of the total LUTs available (the number of cores is driven by the number of MACs required for the DSP). This low utilization provided extra resources for additional functionality.

The ARM M4 consumed ~1.5x-4.75x more energy than embedded FPGA for the same function. The higher energy was caused by the M4 taking ~ 17x-31x more clock cycles to perform the same function. This did not include the memory access power for code and cache references, which will increase the processor total energy even higher versus embedded FPGA.

The total energy to perform the DSP computation on EFLX is frequency independent at higher frequencies. Leakage energy is a large contribution to total Energy at the lower frequencies. Leakage energy contribution at low frequencies (Figure 8) can be eliminated by power gating EFLX between computation cycles by using EFLX’s power gating and state retention feature.

The DSP logic is the main contributor of dynamic power for these specific benchmarks. Figure 9 shows the DSP logic in the center consuming most of the power while the rest of the core (top and bottom of each core) are idle and consuming very little power.

Figure 9: 16-bit 5 Tap FIR DSP Tiles Power Map

Figure 9: 16-bit 5 Tap FIR DSP Tiles Power Map

Conclusion

Using embedded FPGA to offload some DSP algorithms takes less clock cycles and consumes less energy than an ARM Cortex M4F for those functions. As the above analysis demonstrated, EFLX has higher data throughput than ARM Cortex M4F across all frequencies. ARM Cortex M4F requires ~ 17x-31x more clock cycles than EFLX to perform the same function and consumes ~1.5x – 4.75x higher energy than EFLX for the same computations. In fact, actual ARM Cortex M4F power will be even higher due to instruction fetch and memory accesses that were not factored in to this analysis.

This conclusion is not specific to ARM and will apply to any processor. ARM Cortex M4 was simply used because of the availability of data for comparison. The total Energy to perform DSP computations on EFLX is frequency independent. Leakage energy contribution at low frequencies can be eliminated by power gating EFLX between computation cycles. Data throughput of EFLX is fully proportional to EFLX frequency (e.g. no cache misses, etc.). 5 tap FIR filters and single stage Biquad filters are examples of DSP algorithms that can yield these types of results.


Flex-Logix-Tony-kozaczuk-headshotTony Kozaczuk is Director, Solutions Architecture, Flex Logix Technologies, Inc. Originally from Buenos Aires, Argentina, Kozaczuk earned his BSEE at San Francisco State University. His team’s role at Flex Logix is to provide support to customers to evaluate architectural alternatives for using EFLX to achieve the best result. Kozaczuk has more than twenty years’ experience architecting systems and ICs at National, Sun and Intel. Most recently at Intel, he was Lead System Architect for multiple generations of Intel CPU Cores, and led system clocking architecture for all client systems.

Roots of Trust for Edge-Based Solutions: Q&A with Avnet

Monday, January 9th, 2017

What goes into offering a secure foundation for connected devices?

Editor’s Note: In November Avnet, Inc. released an add-on module, the Infineon TPM V1.2 Peripheral Module, and reference design for its MicroZed™ Industrial IoT Kit. Following the announcement, EECatalog e-mailed a few questions to Avnet’s Jim Beneke, the company’s Vice President, Global Technical Marketing.

Figure_1_web

EECatalog: What should embedded designers and developers know about the functionality the Peripheral Module lends to the Industrial IoT Kit?

Jim-Beneke_webJim Beneke, Avnet: Awareness of the importance of security in connected devices is growing every day. It doesn’t matter what market or application your product is targeting, if it’s connected, security is becoming a requirement. The Infineon TPM solution offers developers the most basic hardware-based roots of trust for any edge-based solution. Security is not a problem that is solved by one device at one location. It’s something that must be addressed at multiple points and layers in the system. The TPM provides the secure hardware and storage for implementing boot measurement, key storage, and cryptographic algorithms at the edge devices. It offers the secure foundation upon which additional layers of security can be built within the edge device and the entire system.

In releasing a security Pmod for its MicroZed Industrial IoT Kit, Avnet noted that designers can use the Pmod to investigate a number of security options, such as those which factory automation, smart cities, smart grid and health care applications require. [Source: Fotolia]

EECatalog: What steps were taken to assure that the trade-offs needed to keep the cost of the security peripheral module low did not mean compromising security?

Beneke, Avnet: Avnet’s goal in offering the MicroZed IIoT Kit is to enable designers that are developing next-generation, cloud-enabled industrial platforms, with a low-cost, expandable development system that will speed their development efforts. In introducing the TPM Pmod for enhanced security capabilities, we want to make it as easy as possible for those same designers to prototype with the Infineon TPM solution.

The base MicroZed IIoT kit was designed for expandability, with the Pmod and Arduino expansion connectors provided for easy connectivity into the MicroZed and Zynq processing system. We simply leveraged this capability by offering the Infineon TPM solution in a small, postage-stamp-size Pmod form factor. The standard SPI interface between the TPM and Zynq devices was easily implemented using the 2×6 Pmod connector format. There were no compromises made in terms of security. By simply plugging the TPM module into the MicroZed IIoT kit, designers instantly get access to all the benefits that the TPM offers.

Keep in mind that this kit and the TPM Pmod is not something that designers would use as-is in production. It serves as a development and prototyping platform that offers easy migration to a production ready system, given the MicroZed system on module (SOM) approach. By using the MicroZed SOM as the basis of the system, 100 percent of the designer’s software can be developed using the kit and then transferred to their production platform with zero changes. What is more likely to happen is that developers would design their own carrier card or baseboard that includes the TPM device on it, along with other application-specific interfaces, plug the MicroZed SOM into that carrier card, and instantly have a secure, production IIoT product.

EECatalog: Are you seeing that the reasons for choosing a commercially backed kit versus a DIY or Maker kit have changed?

Beneke, Avnet: I think the DIY or Maker movement has helped all developers due to the increased recognition that low-cost development platforms are important and necessary tools for OEM developers as well as Makers. The advantage in choosing a more commercially backed kit like the Avnet MicroZed IIoT kit are many: it’s built using products that have long term product life cycles; it offers industrial temperature ranges; it includes support from Avnet’s global network of sales and field application engineers, and it has the support and backing of industry leading suppliers like Xilinx and Infineon. In addition, Avnet has partnered with Wind River to include its Pulsar Linux software as the basis of the software environment for the Zynq processing system. Developers can rely on the availability of long term maintenance and security updates to the Linux kernel, which is critical for commercial grade products.

EECatalog: What goes into avoiding a kit that is overkill for what embedded hardware and software designers need now, and at the same time, avoiding the other extreme—a kit too bare bones for what is needed?

Beneke, Avnet: The modular design and expandability that Avnet offers with the MicroZed IIoT kit enables developers to add features as their requirements grow or change. The base platform provides the core of what designers need to start their development, and through add-ons like the TPM module, more features can be added. This approach addresses the needs of a broad base of customers while not targeting a specific application with fixed functionality that may not be needed by others outside of that space.

How Can the Smart Home Save Money?

Tuesday, January 3rd, 2017

A smart meter’s mission may have less to do with empowering homeowners to save costs and more to do with energy delivery—but it doesn’t have to be that way.

Many utilities are installing what they call “Smart Meters” to control and manage the energy usage in the home. However, most of these meters are not smart at all. In most instances, instead of enabling the home owner to control the amount of energy used, they are in place to allow the utility to monitor and control how much energy is delivered to the home—especially useful in times of stress on the grid. In many areas of the world, power for air conditioning as well as for the freezers in homes and businesses during hot afternoons comes close to consuming most of the power being generated. In those cases, so-called smart meters allow the utility to control the amount of power used, thus avoiding grid overload.

Lead_in_Image_Qorvo

Minimizing electricity costs for homeowners to charge their plug-in vehicles could be one benefit of true smart meters, according to the author. (Photo courtesy commons.wikimedia.org Kiwiev)

In contrast, a true smart meter not only informs the consumer—on a real-time basis—how much power is being used, but also recognizes where in the home power is being wasted and helps reduce power requirements.

For example, by using well placed motion and position sensors, the smart home meter system recognizes where the occupants are and ensures that they are comfortable. The system also recognizes where the occupants are not. The system can turn down (or off) the air conditioning in empty rooms as well as making sure the windows are closed, lights are turned off, and the drapes are shut. In addition, if there are power consuming devices that are on but are not used, e.g., TV, computer, gaming consoles, the system turns those off as well.

Figure 1: Smart plugs can help homeowners avoid consuming power when appliances such as hair dryers, curling irons, and electric razors are plugged in, yet not in use.

Figure 1: Smart plugs can help homeowners avoid consuming power when appliances such as hair dryers, curling irons, and electric razors are plugged in, yet not in use.

The system is smart enough to identify the so-called zombie devices in the home—those household appliances that even if they are not on, continue to draw power (Figure 1). The smart meter identifies those and with smart plugs turns off power to those systems as well.

Disasters That Don’t Happen

Another way smart home technologies could reduce costs is by preventing disasters. This type of smart home tech is getting a lot of interest from insurance companies, as well as from the utilities.

Pipes leak. Water heaters leak. Often these leaks occur when no one is home and no one recognizes the problem until literally thousands of dollars in damage occur. Water heaters often suffer catastrophic failure, flooding garages, attics, and basements, places where leakages can continue creating damage for days before being noticed.

Not only can a smart home leak detection system provide early warning that something is wrong, but a true smart system can prevent damage before it occurs. A smart leak detection system, connected to a smart home network, can talk to the water meter and turn it off, preventing damage from flooding and reducing the cost of the spilled and wasted water.

In addition to saving money on the water, this kind of system can also turn off the power and gas. Instead of using power to warm up the water—that in turn gets spilled— the smart system turns off the power and gas to the heater, in addition to turning off the water. By turning off the power and gas to the home, potential damage can be averted.

For example, when a house gets hit by a natural disaster such as a hurricane, earthquake, tornado, etc., broken power and gas lines can cause fires. Having a system that is smart enough to turn off the power can prevent this extra damage. It is no surprise that insurance companies are very interested in this kind of system.

Imagine a water flow sensor that measures when and how much water is flowing into the house. Wouldn’t it be intelligent for that device to recognize that water is flowing when no one is home? If there is water flow during the day when the home is empty—or while the family is on vacation—the system is smart enough to talk to the water meter and turn off the flow.

Another interesting possibility is having the smart meter charge the home’s power storage system during the day via solar panels on the roof, or at night when power is less expensive. That way, the home’s power-greedy appliances can use “cheap” stored electricity instead of drawing from the grid during expensive rate times. These systems are already in use in industrial applications and are moving to home use. This would be especially valuable for those with plug-in vehicles who need to minimize the cost of the electricity required for charging them up.

Live and Learn

An effective smart home might make its occupants smarter as well. When people are educated about how much power each appliance is costing them, they are more likely to be more energy-thrifty when they do use them. For instance, it is much more efficient to run washing machines or dishwashers when they are filled. Running appliances under capacity wastes power and water, not to mention detergents.

The “secret sauce” empowering these smart home solutions is a network of various sensors and analytics. It is the analytics that make the system smart. The system learns from the people who live in the home to make predictions about future behaviors—the number of household members, how rooms are used and when, bedtimes, who works from home and where, who gets up early, etc., and then compares them with weather conditions, various pricing tiers for power, consumer use data, etc. This knowledge is integrated into the system and used to enhance comfort and convenience settings that also happen to be cost-saving.

These two technologies—sensors and analytics—provide a growing new market for technology developers and offer a new way for manufacturers to target their product development and marketing messages. More than just trendsetting and fun, smart home technology can also benefit the consumer’s budget.

______________________________________________________________________________________________________

CeesLinksCees Links is a pioneer of the wireless data industry. He is the founder and CEO of GreenPeak Technologies, a Smart Home and IoT radio communications semiconductor company, now part of Qorvo.

Earlier in his career Cees worked for NCR, AT&T and Lucent Technologies. Under his responsibility, the first wireless LANs were developed for PCs and notebooks, which ultimately became household Wi-Fi technology integrated into computers, smartphones and connected smart devices. He also pioneered the development of access points, home networking routers, and hotspot base-stations. He was involved in the establishment of the IEEE 802.11 standardization committee and the Wi-Fi Alliance. He was also instrumental in establishing the IEEE 802.15 standardization committee that became the basis for ZigBee sense and control networking.

After Qorvo’s acquisition of GreenPeak in May 2016, Cees has become the General Manager of the Wireless Connectivity business unit in Qorvo.

ARM Cortex-R52 Meets Challenge of Autonomous Systems

Monday, October 10th, 2016

The new ARM® Cortex®-R52 can meet raised functional safety standards across multiple markets, from automotive to industrial and including healthcare. ARM Product Manager, James Scobie, tells Caroline Hayes how the company’s latest processor can meet raised standards in increasingly complex systems.

Across multiple markets, automation is increasing complexity in electronic systems, fuelling demand for functionally safe operation. In vehicles, there are already driver assistance systems, with functionality on the way to autonomy, such as automatic lane changing. Engine management systems are also increasingly complex to meet stringent emission controls. They must also control the engine to prevent damage or hazards, and, as electrification progresses, systems must control powerful motors and manage large Lithium-ion batteries, which contain significant amounts of energy.

The autonomous trend is also being seen in other areas. Conventional robotic production lines, where robots carry out a defined fixed task and are segregated from operators, are being replaced by collaborative industrial robots. These have unconstrained interaction with human operators, sensing their environment and taking action safely. They may be capable of selecting and placing the correct component while working in conjunction with a human operator. They are also being used in environments that are too harsh for humans, such as the nuclear industry.

Surgical robots are increasingly being used in operating theaters with remote surgery, and to deliver medication. In future, commercial autonomous drones are expected to need these characteristics.

As a result of these levels of automation, systems require functional safety at a higher level than previous generations of systems demanded. The new ARM® Cortex®-R52 processor has been introduced to addresses the challenging needs of these types of systems.

The automotive case

A functionally safe system has to be protected against two types of errors: random or systematic (Figure 1).

Figure 1: In a vehicle braking system, safety features in the processor protect against random errors and system faults.

Figure 1: In a vehicle braking system, safety features in the processor protect against random errors and system faults.

The impact of random errors, for example a memory bit flipping due to radiation, can be protected against through the inclusion of features in the processor. Cortex-R52 integrates the highest level of safety features of any ARM processor to guard against this type of error.

Figure 2: The features and processes within the Cortex-R52 that enhance functional safety within a system.

Figure 2: The features and processes within the Cortex-R52 that enhance functional safety within a system.

Systematic errors are typically the result of software or design errors. Protection against these is provided by appropriate processes and procedures at the design stage. Cortex-R52 has been developed from the ground up and a comprehensive safety documentation package simplifies and reduces the effort needed by SoC partners in certifying the end system.

There are a number of different standards and guidelines related to functional safety, such as ISO 26262. (For more information about functional safety, there is The Functional Safety Imperative in Automotive Design white paper.)

There are many, different applications where functional safety and fast, deterministic execution is necessary. In many real-time control systems, the application can be managed either with a single Cortex-R52 processor or across multiple homogeneous processors. This might be typical in a conventional control system, like an automotive engine management system or industrial controller.

Autonomous behavior

Functions in an autonomous system can be divided into four stages: sense, perceive, decide, actuate. In the first, a range of sensors gathers raw information. In the perceive stage, data from the sensors is used, with complex algorithms, such as machine learning, to interpret the environment in which the system operates. At the decide stage, outputs from the various systems are gathered ready for the fourth stage, where the decision is carried out or communicated.

ARM enables all aspects of these autonomous systems with processors from across the Cortex-A, Cortex-R and Cortex-M families being used according to the need of each stage (Figure 3). The decide and actuate stages must be functionally safe. For example, in an automotive system, the decision stage can take inputs from the navigation system, speed sensors and the vision and radar systems, and decide when to change lanes or to get ready to exit the highway.

Figure 3: The four stages in an autonomous system, in a Cortex-R52-based system.

Figure 3: The four stages in an autonomous system, in a Cortex-R52-based system.

These autonomous systems need to apply another level of judgement by interpreting more about the environment in which they are operating. These tasks can be confidence based and require high levels of throughput to process large amounts of data. Such operations are well suited to the Cortex-A class of processors.

The systems need to be functionally safe with deterministic execution. When combined together in a heterogeneous processor, the Cortex-R52 can provide a safety island to protect the operation of the system.

In the case of an Advanced Driver Assistance System (ADAS), inputs can be gathered from sensors such as cameras, radar and lidar. This data is processed and combined by the Cortex-A processors to identify and classify targets. The information can be passed to the Cortex-R52 to decide what action to take and perform the necessary checks to ensure safe operation.

Software challenges

Systems are also integrating more software from multiple sources, and with multiple safety criticality needs. This is a complex integration challenge. Safety critical software needs to be validated and certified. The interaction between the software means that the entire software stack would typically be safety certified, even if only a small proportion is safety critical. The more complex the system, the harder this becomes.

If the independence of safety critical code could be guaranteed, development and integration of functional safety software would be simplified, with clear separation between levels of software criticality. Safety code, critical safety code and non-safety code can each be validated and certified to the required level. Changes to one module do not require re-certification of all of the software.

ARMv8-R architecture

For many of these systems, this separation must be achieved whilst still maintaining deterministic execution.

Cortex-R52 provides the hardware to support both isolation and real-time execution, through the addition of a new exception level and two-stage MPU, introduced in the ARMv8-R architecture. Monitor or hypervisor software can manage access to resources and create sandboxes to protect each task. The design of the Cortex-R52 allows for fast switching between protected applications and maintains deterministic execution.

As well as protecting software, it simplifies the integration of code into a single processor. Using a hypervisor, multiple operating systems can be supported to consolidate applications.

Many systems require deterministic operation, with the appropriate action being controlled, and also performed at the right time, without significant delay, regardless of what else is happening in the system.

The Cortex-R family offers real-time processors and Cortex-R52 is the first processor in the ARMv8-R architecture and further extends the capabilities of the Cortex-R5, both in terms of functional safety and increased performance.

Cortex-R52 delivers up to 35% higher single core performance over Cortex-R5, when running standard benchmarks. (EEMBC certified Automotive Industrial benchmark, using the Green Hills Compiler 2017.)

This performance increase is enhanced by additional real time performance gains. Interrupt latency has been reduced to half that of the Cortex-R5 with fast access and integration of the interrupt controller within the cluster. The improved Memory Protection Unit, with finer granularity and faster reconfiguration, significantly reduces context switching time, to 14 times faster than the Cortex-R5. System performance is also increased as twice as many Cortex-R52s than Cortex-R5s can be integrated within a cluster.

Cortex-R52 supports an adaptable memory architecture with integrated deterministic Tightly Coupled Memories. These enable assured memory latencies and can be allocated to instruction or data and configured in a range of sizes. The processor supports a rich set of interface ports around which the system can be built, for example a low latency peripheral port, AXI interfaces and a dedicated wide Flash memory interface to provide access to resources with managed arbitration.

Ecosystem support

Ecosystem partners provide software packages, drivers, stacks, operating systems and tools to simplifying development. Adopters can leverage the common architecture to reduce costs as multiple suppliers address requirements. They can also can develop on a single platform and implement heterogeneous systems and port solutions between different platforms faster and with more reliable results. For more information visit software development tools for ARM Cortex-R.

One ecosystem partner is Synopsys, which has announced tool support for the Cortex-R52.

For an extended version of this piece, please visit the ARM Connected Community

Open Source Community Strengths for the IoT, Security, More

Wednesday, May 11th, 2016

Collaboration is a powerful change agent for good for embedded security, device interoperability, and software portability—and that’s just for starters.

To catch EECatalog readers up on the initiatives of the prpl Foundation, a collaborative open source community that is driving innovation in areas ranging from big data, cloud computing and analytics to embedded devices, IoT hubs and residential gateways, I’ve come up with a set of questions—ones I hope you will find similar to one or more you might have posed. I’ll begin with question and answer sets related to recent news from the prpl foundation, but you will also find information helpful to anyone not yet familiar with the organization and its key objectives at the end of this article.

What are the key takeaways/findings of the Security Guidance for Embedded Computing report?

Three Principles

Our “Security Guidance for Critical Areas of Embedded Computing” report lays out a vision for a new hardware-led security approach that is based on open source and interoperable standards. It proposes to engineer security for connected and embedded devices from the ground up, using three general areas of guidance.

First, we are addressing the fundamental controls for securing devices. This includes a trusted operating environment enabled via a secure boot process that is impervious to attack. This requires a root of trust forged in hardware, which establishes a chain of trust for all subsystems.

We have also outlined the need for a Security by Separation approach in embedded systems. This approach—already proven to protect computer systems and their data—can enable embedded systems to retain their security attributes even when connected to open networks. This is based on the use of logical separation created by hardware-enforced virtualization, and also supports technologies such as paravirtualization, hybrid virtualization and other methods.

Finally, we believe it’s important to support secure product development and testing, with an infrastructure that enables secure debug. Rather than allowing users to see an entire system while conducting hardware debug, the document proposes a secure system to maintain the separation of assets.

Through focusing on these three areas, stakeholders can take action to create secure development environments, operating environments and APIs in embedded devices.

Reaction

The reaction to our peer-reviewed Security Guidance document has been overwhelmingly positive, with comments from the reviewers on the comprehensiveness of the report, and the helpful nature of the highlighted case studies. The VP of engineering of one leading broadband and connectivity group indicated that by “using detailed examples of recent hacks in embedded computing…the reader is taken step by step though weaknesses and shown how they can be overcome using methods like root of trust, secure boot process, separation of duties and secure development and testing.”

Can open hardware based IoT security balance innovation and regulation?

Yes. We are seeing the rapid rise of a new generation of smart, connected products that feature computing power, network connectivity and sophisticated software. And while it’s logical that lawmakers and regulators must lock down certain functionality of these products in order to ensure the safety and well being of their citizens, this has the potential to stifle innovation.

In our Security Guidance document, we outline how open source development, secure boot based on a root of trust anchored in the silicon, and hardware virtualization can keep both regulators and consumers happy. By building security-by-separation into the hardware of embedded systems, regulators can control specific functions under their regulatory purview, while allowing consumers free reign to tweak other parts of their product.

Router Example

Take, for example, regulations that the FCC is considering for the domestic router market. The goal is to prevent users adapting their devices in a way that could interfere with the device’s Wi-Fi capabilities. Since radio frequency parameters are controlled in drivers inside the Linux kernel, the only way to guarantee that a third party—or the router owner—can’t touch the Wi-Fi in these devices is to prevent modification or replacement of the driver itself. This effectively means restricting modifications to the OS as a whole—locking down the entire system.

This is bad news for home Internet users who could otherwise leverage open source operating systems like OpenWRT (the Linux distribution at the heart of most routers) to add new functionality —for example a print server or parental control application.

The way to solve this challenge is by containerizing separate software components at a hardware level. In this way, the FCC could enforce control over the elements that manage radio frequency parameters, and consumers have the ability to modify other functionality in the router. With such an approach, we’re preserving the rights of the consumer, addressing regulator concerns and protecting innovation—which occurs when current technologies can be tweaked and adapted.

What are the starting points for marrying the IoT with Big Data?

Collaboration not just within the prpl Foundation, but across the entire industry, is the key here, as this infographic shows. With the IoT, more and more devices will be deployed to monitor and collect data in just about every environment from homes to cars to farms to hospitals and beyond. The sheer amount of data that will be generated by these billions of devices is staggering. Finding new ways to analyze and synthesize this ‘Big Data’ presents an enormous array of opportunities on which companies, organizations and individuals across the world are looking to capitalize. But there are many challenges in the realization of this vision. ‘Marrying the IoT with Big Data’ requires that we solve challenges such as embedded security, device interoperability and software portability. Many of the projects on which prpl is focused are aimed at helping the industry to realize this vision.

What are the prpl Foundation’s objectives?

We’re focused on enabling next-generation datacenter-to-device portable software and virtualized architectures. As such, the Foundation brings together a variety of new and existing community open source projects to help address these issues.

One of these existing open source projects is OpenWrt—an important community project that is attracting a great deal of new interest from network operators and manufacturers of residential gateways and CPE systems.  The goals of our prplWrt PEG (prpl Engineering Group) are to provide active support to the existing OpenWrt community while helping to define and implement a set of new carrier-grade features which will expand the reach and use of OpenWrt. These features include such items as carrier-grade containers, secure updates and better package management for next-generation residential gateways.

Driving better embedded security is a key objective for prpl. Our Security PEG is defining an open software security framework and methodology for secured and authenticated virtualized services. The group is developing a security roadmap and related open APIs that will lead from today’s software-virtualized solutions to full hardware supported virtualization. This will enable multi-domain security across processors, heterogeneous SoCs and the systems built on these technologies.

Another key initiative is around the principle of portability. To help avoid fragmentation across products – a real risk with the dawn of the IoT—it’s key that the ecosystem reduce its dependency on instruction set architecture (ISA) compatibility. We believe that code should be written once, and deployed to many devices – regardless of architecture. By pushing portable software (JITs, emulation, binary translation), prpl enables developers to innovate on their core strengths.

Reaching Developers

Our prpl.works online community—by and for open source developers and users—has already reached over 40,000 developers worldwide. Some of the key subgroups in which prpl and community members are engaged include prplSecurity, Android MIPS, Linux MIPS, prplWrt (supporting OpenWrt), OVP (Open Virtual Platform) and QEMU for developers needing Quick Emulator and virtualizer technology.

Membership

The prpl Foundation currently has more than 25 members comprised of companies and individuals that design and market wireless telecommunication products and services, data storage solutions, virtual platform simplification, cloud based security services, analog and digital semiconductor connectivity solutions, and more. And there are a number of leading global higher education institutions as well. The members are all leaders in the technology industry investing in innovation in efficiency, portability and compatibility for the good of a broad community of developers, businesses and consumers. 


Art_SwiftArt Swift is president of the prpl Foundation. He has more than 20 years of marketing and executive management for semiconductor and processor IP companies and has spent most of the last decade building innovative chips and IP for the mobile PC, tablet and smartphone industries. He holds a Bachelor of Science degree in electrical engineering from Pennsylvania State University and is a co-inventor of three U.S. patents. art@prplfoundation.org.

Newest Arduino Brings Wi-Fi and ARM to a Trim New Form Factor

Monday, May 2nd, 2016

Makers can choose from multiple development platforms for the Internet of Things (IoT), many of which feature processors based on ARM® design cores. Mark Woods, ARM’s Applications Architect and Maker, discusses how the average maker, regardless of whether they’ve a degree in electrical engineering or not, can get started on a project.

By Jeff Dorsch, Contributing Editor

Single-board computers, such as the Arduino MKR1000 / Genuino MKR1000, the Raspberry Pi 3 and other models, are extremely useful to the maker community, offering increased capabilities while prices continue to fall and form factors are shrinking. Makers can now get their hands on microcontrollers or microprocessors, even full system-on-a-chip devices, when selecting a board-level development platform.

Figure1_Arduino MKR1000

Figure 1: The Arduino MKR1000 development board. (Courtesy https://www.arduino.cc/ )

“Makers —or DIYers for us Brits!—have always been pushing the boundaries, and have long been ardent users of MCUs,” says Mark Woods. “As more complex SoCs have made their way to low-cost platforms, they have seen rapid adoption. Examples are 3D printers built on ArduinoRaspberry Pi and BeagleBone—enabling low-cost system development and requiring only custom electronics for the machine control or user interface specifics. Another great example is the OpenROV community—a community of developers creating personal underwater robots—and again starting with BeagleBone and Arduino.”

“Low cost and high performance have been critical, alongside the ability to code in high-level languages, such as Java or Python—I see these attributes echoed in other successful communities.”

“What’s important here is that makers, who may have no formal electrical engineering skills, can develop complex systems without having to worry about the costs, time and complexity of building and debugging complex hardware just to get to the system creation starting line. Of course, makers typically share, so the whole community benefits from open-source software and sharing of builds and techniques.”

Figure2_Mark Woods

Figure 2: Mark Woods, ARM’s Applications Architect and Maker

Woods speaks enthusiastically about the new Arduino MKR1000, known outside the United States as the Genuino MKR1000. He notes the shape of the MKR1000 is different than previous Arduino boards.

“The MKR1000 is both more and less at once! The new form factor is much smaller than traditional Arduino boards, but integrates connectivity into that new smaller form factor, avoiding the need to add shields just for that function. In my mind, MKR1000 is fundamentally an Arduino ZERO and WiFi101 shield in one tiny package,” he says. “What’s also nice is this small board comes with standard 0.1-inch header in a DIP format, providing 28 pins for interfacing to the outside world with a nice mix of analog and digital functionality—perfect for hooking up sensors and for control manipulation.”

This IoT platform with Wi-Fi connectivity, priced at $35, includes software aimed at use by designers, hobbyists, makers and others, not just full-time embedded systems engineers. Woods adds, “Integration, high performance, low power, huge code ecosystem, bank-quality security and yes, a low price, tells me you can prototype quickly, pivot, try lots of different ideas, and once it looks like you have a winner, you can test your market with an RF-certified solution. Arduino is solving a lot of these issues with moving from a prototype to production. Remember Pebble? With modules like this, your path from prototype to small- or large-scale production is safe, predictable and visible.”

The MKR1000 is based on Atmel’s ATSAMW25 SoC device, which incorporates the ARM Cortex®-M0+ low-power microcontroller. Woods comments, “The Cortex-M0+ is the smallest and lowest-power ARM to date, but it punches above its weight, with a great blend of 32-bit performance, upward compatibility with the ARM world, and wicked power control. It has become the go-to CPU for low-power wearables, toys, sensor nodes, beacons and the Internet of Things.”

“One key design aspect of the MKR1000 is that Arduino chose Wi-Fi over Bluetooth Low Energy (BLE), and with the SAMW25, they gave us a high-performance, standards-rich connectivity solution with security. 802.11 b/g/n—n is 1×1—at up to 72Mbits per second is fantastic capability for this class of device, in my opinion. But who am I to judge—let’s see what the one thousand Hackster MKR1000 competition entries do with that bandwidth! I also like that the board can be powered from a small LiPo (a Lithium Ion battery pack), and has a charging circuit onboard.”

What about the choice of Wi-Fi over BLE? “There are hundreds of BLE-capable compute nodes, perfectly suited to their applications, but I think Wi-Fi enables different use cases, and with the mix of bandwidth and range, should provide some interesting options and connectivity for IoT. If you don’t want to connect to a host, or just want point-to-point communications, well, that’s fine, too,” Woods notes.

Figure3 MKR1000

Figure 3: Connectivity options are expanded with the use of Wi-Fi on the MKR1000.

The MKR1000 features crypto-authentication for cybersecurity. “Designers of connected products have to consider security from the outset,” Woods says. “I think we’ve seen too many instances of products come to market with inadequate or no security, so having a crypto feature is great, and makes the statement that this is not only for hobby projects. Offering security also reaffirms this module as a competent platform to prototype and go to market with. The technical spec of the security agent is also excellent—unique serial, random number generator, secure key store, SHA-256, public-key algorithms. I can see many of these features themselves opening up design ideas and opportunities.”

“The Hackster-run World’s Largest Arduino Maker Challenge should provide plenty of inspiration. I wonder if we’ll see any winners on Kickstarter? I’ve just bought two myself and will be using them in my own top-secret build!”

These capabilities with the MKR1000 should propel multiple makers with their own projects.  “It’s not all philanthropic, of course—many open-source 3D printers, CNC (Computerized Numerical Control) machines, robots and more have come from successful companies that live alongside the open-source community that they both feed into and from,” Woods concludes.

This article was sponsored by ARM.

Next Page »