RTC Magazine

RTOSs Gain Power, Speed and Efficiency Machine-to-Machine: Different from IoT? Meeting Medical Equipment Standards The Magazine of Record for the Embedded Computer Industry

14 22 34

Vol 16 / No 8 / AUGUST 2015

New Tools Target IoT Development An RTC Group Publication

Industrial DC/DC Power Solutions Renewable Energy, UPS, and PoE Fanless -40° to +85°C Operation

Small Form Factor Computers Intel® Atom™ E3800 and i.MX6 CPUs Fanless -40° to +85°C Operation

EPIC Single Board Computers Rugged, Stackable Form Factor Fanless -40° to +85°C Operation

Single Board Computers COM Express Solutions Power Supplies I/O Modules Panel PCs

Freedom from Support Delays and Long Lead-times

When the success of your project is on the line, you can’t afford to waste time and money on poor technical support or products with long lead times.

Call WinSystems and you’ll speak directly with an Applications Engineer in our Arlington, Texas facility. Our Engineers are ready to guide you through product selection, customization, troubleshooting, and life-long support of our product. WinSystems keeps most products in stock so we can ship your order within 1-2 business days.

Let us put over three decades of embedded computer experience, integrity, and service to work for you.

715 Stadium Drive I Arlington, Texas 76 011 Phone: 817-274-7553 I Fax: 817-548-1358 info@winsystems.com

Call 817-274-7553 or visit www.winsystems.com.

Ask about our product evaluation!

NEW WEBSITE COMING THIS SPRING

Same company – new fresh look!

CONTENTS

The Magazine of Record for the Embedded Computing Industry

EDITORS REPORT

UNITING THE IOT AND BIG DATA

10

Big Data and Small Things: prpl Foundation Aims for Compatible Connectivity

by Tom Williams, Editor-in-Chief

TECHNOLOGY CORE

RTOSS: COMPACT, POWERFUL AND FAST

14

A Scalable RTOS for Wearables and IoT

by Warren Kurisu, Mentor Graphics

26 HW/SW Platform Simplifies and Accelerates IoT Product Development DEPARTMENTS 06

07 42

EDITORIAL

18

by Jay Thomas, LDRA

TECHNOLOGY CONNECTED

MACHINE-TO-MACHINE: DIFFERENT FROM IOT?

22

How Badly Broken? How Hard to Fix?

INDUSTRY INSIDER

Addressing the Testing Challenges of Safety-Critical Embedded Systems with Ultra-Light Instrumentation

M2M is a Player; the Internet of Things is the Team

by Elizabeth Campbell, ADLINK Technology

Latest Developments in the Embedded Marketplace

TECHNOLOGY IN SYSTEMS

PRODUCTS & TECHNOLOGY

26

Newest Embedded Technology Used by Industry Leaders

DEVELOPMENT TOOLS FOR THE IOT

HW/SW Platform Simplifies and Accelerates IoT Product Development

by Vin D’Agostino, Renesas Electronics America

30

Helping Manufacturers Start Near the Finish Line in Developing IoT Mobile Apps

by Oliver Cockcroft, Ayla Networks

TECHNOLOGY DEVELOPMENT MEETING MEDICAL EQUIPMENT STANDARDS

22 M2M is a Player; the Internet of Things is the Team

34

Understanding IEC 62304 for Medical Device Compliance

by Rita King, MethodSense, and Alex Grob, Medical Equipment Compliance Associates

RTC Magazine AUGUST 2015 | 3

conga-QKIT/IoT

RTC MAGAZINE

Qseven IoT Gateway Development Kit PUBLISHER President John Reardon, johnr@rtcgroup.com Vice President Aaron Foellmi, aaronf@rtcgroup.com

EDITORIAL Editor-In-Chief Tom Williams, tomw@rtcgroup.com Senior Editor Clarence Peckham, clarencep@rtcgroup.com

A complete starter set for the rapid prototyping of embedded IoT applications.

Contributing Editors Colin McCracken and Paul Rosenfeld

ART/PRODUCTION Art Director Jim Bell, jimb@rtcgroup.com Graphic Designer Hugo Ricardo, hugor@rtcgroup.com

www.congatec.us 6262 Ferris Square | San Diego CA 92121 858-457-2600| sales-us@congatec.com

ADVERTISING/WEB ADVERTISING Western Regional Sales Manager Mike Duran, michaeld@rtcgroup.com (949) 226-2024 Western Regional Sales Manager Mark Dunaway, markd@rtcgroup.com (949) 226-2023 Eastern U.S. and EMEA Sales Manager Ruby Brower, rubyb@rtcgroup.com (949) 226-2004

intelligentsystemssource.com

WE ASSURE YOU HIT A BULLSEYE EVERYTIME...

BILLING Vice President of Finance Cindy Muir, cmuir@rtcgroup.com (949) 226-2021

TO CONTACT RTC MAGAZINE: Home Office The RTC Group, 905 Calle Amanecer, Suite 150, San Clemente, CA 92673 Phone: (949) 226-2000 Fax: (949) 226-2050 Web: www.rtcgroup.com

WITH JUST A COUPLE CLICKS. • See Instructional Videos • Shop Boards Online • Read Articles & More • Request a Quote

4 | RTC Magazine AUGUST 2015

Editorial Office Tom Williams, Editor-in-Chief 1669 Nelson Road, No. 2, Scotts Valley, CA 95066 Phone: (831) 335-1509 tomw@rtcgroup.com Published by The RTC Group Copyright 2015, The RTC Group. Printed in the United States. All rights reserved. All related graphics are trademarks of The RTC Group. All other brand and product names are the property of their holders.

EDITORIAL

How Badly Broken?

How Hard to Fix?

by Tom Williams, Editor-In-Chief

There is certainly no doubt that computer security has always been an important issue.

The advent of the Internet and services like online shopping, banking, dating, illicit affairs and the like have only increased the urgency and complexity of security. Now, with the rise of the Internet of Things, there is quite possibly no device that does not require some level of security and the issue has taken on even greater and unprecedented importance along with mind-boggling complexity. In fact, it has quite possibly become a problem for which there really is no complete solution—and not for lack of effort or hype.

One basic fact is that the Internet of Things does not mean that everything is connected to everything else. There may be some things to which everything can connect, but mostly the IoT consists of realms of exclusivity, domains that find their global connectivity via the Cloud or through smaller domain networks that ultimately connect to the Cloud. Growing numbers of devices, “things,” are vital to life, safety, the economy and national security and they are currently vulnerable to attack at some level. And the IoT is connected to the rest of the Internet, which means huge amounts of data that must also be secured while being made available to authorized users. One of the more unsettling facts is that we do not really know how secure or vulnerable many of these systems such as the national power grid really are.

We do know that major nations maintain cyber warfare groups and have acted in at least some cases, but so far there has been no all-out attack. One must ask one’s self if this is due to robust defensive security or other reasons.

We have a reason to fear, for example that the Chinese could bring down our power grid. On the other hand, the Chinese must be aware that we could bring down theirs. Is the lack of action

6 | RTC Magazine AUGUST 2015

due to some fear analogous to the “mutual assured destruction” that helped prevent nuclear attacks during the Cold War? We can only guess.

There have of course been notorious instances of breached security that must give us all pause. The break-ins at Sony, Target and the theft of millions of Social Security numbers; the Australian water system and more recently the remote hacking of a running Jeep Cherokee that was able to access the accelerator. These are just a few that we know about and we can be certain there are others, quite probably more unsettling, that are being kept very quiet.

At the same time, the industry is awash in public relations blitzes, product introductions and endless PowerPoint presentations claiming to have solutions for security in all manner of systems and devices. Most of these approaches deal with limited aspects of the overall security challenge such as secure routers, data encryption, user authentication, kernel separation— the list goes on. In many of the well-known security breach stories, the fault has appeared to lie in some neglected detail that was discovered and exploited by hackers. This is, of course, a result of the ever growing complexity of embedded, IT and networked systems, many of which host multiple users with different applications and different connection requirements.

In Franz Kafka’s short story, “The Burrow,” the main character (some sort of burrowing animal) has dug a den with deep refuges, hidden entrances and a fortified center in order to protect itself and its possessions from real and imagined enemies. Even the secret escape route is a danger if an enemy accidentally discovers it and turns it into an entrance. The character doesn’t rest and is constantly thinking of possible dangers, of enemies and assaults on its burrow.

Then there is the slight scraping or hissing, a constant, steady and never ceasing sound that

spells danger. But through all the character’s efforts and paranoid speculation, nothing it can do will make that sound go away. At the end, the final words are, “But nothing had changed.”

This is analogous to the confidence we can have in today’s secure system. We can take all the measures we find available but we can never rest in confidence that they are sufficient.

We can try to make access more difficult than the motivation of anticipated hackers but how difficult must that be? We can never be certain.

And yet we must try. But today we must face the fact that comprehensive security is broken, an illusion made up of disparate parts with varying degrees of compatibility, methods of implementation and effectiveness. Some of it does work . . . to an extent and that extent is really not well known. Some sort of unified effort is needed, or some kind of concept that stretches from Cloud to embedded sensor/actuator. It is too big a challenge for individual companies; it must be approached as an industry, maybe a society.

And if and when we do make sufficient progress for some overall level of confidence—not complete, but perhaps measureable—there is one more question no one seems to want to discuss: How do we retrofit all the existing systems and those that will be deployed in the meantime with some confident measure of security? Yes, we must try and we will make progress. But like that burrowing animal, we will never truly be able to rest without that slight hissing noise in the background.

INDUSTRY INSIDER

‘Wearable for the Mind’ May Launch New Era of Brain Research Neuroscientists in Toronto have shown that crowdsourcing brain research to hundreds of participants in a short period of time could be a new frontier in neuroscience and lead to new insights about the brain. Dr. Natasho Kovacevic of Baycrest Health Sciences Rotman Research Institute is the lead author of a scientific paper on the crowdsourcing experiment – “My Virtual Dream: Collective Neurofeedback in an Immersive Art Environment.” The researchers used the Muse wireless electroencephalography (EEG) headband to collect brain data from more than 500 adults at a major arts event in Toronto. Baycrest, in collaboration with the University of Toronto and industry partners, created a large-scale art/science installation called My Virtual Dream, which housed the experiment.

Festival-goers wore the Muse headband and participated in a brief collective neurofeedback experience in groups of 20 inside a 60-foot geodesic dome. A total of 523 adults (209 males, 314 females), ranging in age from 18 to 89, contributed their EEG brain data for the study. The participants played a collective neurofeedback game where they were required to manipulate their mental states of relaxation and concentration. The neurofeedback training lasted 6.5 minutes, which is much shorter than typical neurofeedback training experiments. The group’s collective EEG signals were used to control lighting and imagery inside the exhibit.

Muse is a clinical grade, smartphone-linked, EEG headband that helps individuals learn meditation, improve their attention, and manage stress by providing direct, real-time insights into their brains. It is used by researchers and clinicians in universities and hospitals around the world.

“Human brain research has always been very hard to do at large scales. It’s usually done in a lab, one person at a time. With Muse, we can now use proven EEG technology in a way that allows hundreds or even thousands of people to participate in brain research, both inside and outside the lab,” said Dr. Graeme Moffat, a neuroscientist with Muse. “This will open doors to new insights and new interventions for brain health. We’re witnessing the dawn of pervasive neurotechnology for healthier brains.” Studying the human brain in a social and multi-sensory environment is closer to real life and may help scientists to approach questions of complex real-life cognition in ways not previously possible.

The massive amount of EEG data collected in one night yielded an interesting and statistically relevant finding: that subtle brain activity changes were taking place within approximately one minute of starting the neurofeedback learning exercise; an unprecedented speed of neural learning, adaptation, and control that has not been demonstrated before.

Weightless-N Open Standard IoT Networks Deploy in Europe The Weightless SIG has announced the deployment of Weightless-N Smart City networks from Nwave Technologies across Copenhagen and the south of Denmark around the city of Esbjerg. Copenhagen is Denmark’s capital and largest city and Esbjerg the second largest port city and a leading European offshore energy industry center.

Nwave Technologies is collaborating with leading Accelerator organizations, Accelerace Management and Next Step City, in Denmark to roll out the country’s first Smart City networks. This announcement follows the recent publication of version 1.0 of the new Weightless-N open standard based on the low power wide area star network (LPWAN) architecture and the subsequent Weightless network deployment across London, England.

Operating in sub-1GHz, license-exempt ISM spectrum using ultra narrow band (UNB) technology, Weightless-N offers best-in-class signal propagation characteristics, leading to excellent range of several kilometers, even in challenging urban environments. Very low power consumption provides for exceptionally long battery life measured in years from small conventional cells, and leading edge innovation in design minimizes both terminal hardware and network costs.

Weightless-N is designed around a differential binary phase shift keying (DBPSK) digital modulation scheme to transmit within narrow frequency bands using a frequency hopping algorithm for interference mitigation and enhanced security. It provides for encryption and implicit authentication using a shared secret key regime to encode transmitted information via a 128 bit AES algorithm. The technology supports mobility with the network automatically routing terminal messages to the correct destination. Multiple networks, typically operated by different companies, are enabled and can be co-located. Each base station queries a central database to determine which network the terminal is registered to in order to decode and route data accordingly. The complete specification is available to Weightless SIG Members for immediate download from the organization’s website.

RTC Magazine AUGUST 2015 | 7

INDUSTRY INSIDER

IBM Research Alliance Produces Industry’s First 7nm Node Test Chips An alliance led by IBM Research has announced that it has produced the semiconductor industry’s first 7nm node test chips with functioning transistors. The breakthrough, accomplished in partnership with GlobalFoundries and Samsung at SUNY Polytechnic Institute’s Colleges of Nanoscale Science and Engineering could result in the ability to place more than 20 billion transistors on the fingernail-sized chips.

To achieve the higher performance, lower power and scaling benefits promised by 7nm technology, researchers had to bypass conventional semiconductor manufacturing approaches. Among the novel processes and techniques pioneered by the IBM Research alliance were a number of industry-first innovations, most notably Silicon Germanium (SiGe) channel transistors and Extreme Ultraviolet (EUV) lithography integration at multiple levels.

Industry experts consider 7nm technology crucial to meeting the anticipated demands of future cloud computing and Big Data systems, cognitive computing, mobile products and other emerging tech-

nologies. Part of IBM’s $3 billion, five-year investment in chip R&D (announced in 2014), this accomplishment was made possible through a unique public-private partnership with New York State and joint development alliance with GlobalFoundries, Samsung, and equipment suppliers. The team is based at SUNY Poly’s NanoTech Complex in Albany.

Microprocessors utilizing 22nm and 14nm technology, such as the Intel Core famil, currently power today’s servers, cloud data centers and mobile devices, and 10nm technology is well on the way to becoming a mature technology. The IBM Research-led alliance achieved close to 50 percent area scaling improvements over today’s most advanced technology, introduced SiGe channel material for transistor performance enhancement at 7nm node geometries, process innovations to stack them below 30nm pitch and full integration of EUV lithography at multiple levels. These techniques and scaling could result in at least a 50 percent power/performance improvement for next generation mainframe and POWER systems that will power the Big Data, cloud and mobile era.

IBM and SUNY Poly have built a highly successful, globally recognized partnership at the multi-billion dollar Albany NanoTech Complex, highlighted by the institution’s Center for Semiconductor Research (CSR), a $500 million program that also includes the world’s leading nanoelectronics companies. The CSR is a long-term, multiphase, joint R&D cooperative program on future computer chip technology. It continues to provide student scholarships and fellowships at the university to help prepare the next generation of nanotechnology scientists, researchers and engineers.

Altera Joins Open Source Platform to Bring the Value of FPGAs to Network Function Virtualization Altera has announced the company has joined the Open Platform for NFV (OPNFV), a carrier-grade, integrated, open source flexible platform intended to accelerate the introduction of new products and services using network function virtualization (NFV). As an open source project, OPNFV is positioned to bring together the work of standards bodies, open source communities and commercial suppliers to deliver a de facto standard open source NFV platform for the industry.

Open Platform for NFV is a carrier-grade, integrated, open source reference platform intended to accelerate the introduction of new products and services using NFV. It brings together service providers, vendors and users to collaborate in an open forum on advancing the state-of-theart in NFV. NFV uses IT virtualization technologies to virtualize entire classes of network node functions into building blocks that may be connected, or chained, to create communication services. Altera will join working groups inside the OPNFV to expand the use of FPGA accelerators in virtual machines running different software and processes on top of industry-standard, high-volume servers, storage and cloud computing infrastructure.

“FPGAs can be used to ‘super-charge’ virtual machine applications while saving on power, making them an excellent fit for the NFV 8 | RTC Magazine AUGUST 2015

industry,” said Francis Chow, vice president and general manager of the Communications Business Unit for Altera. “At the same time, FPGAs can reduce capital and operational expenditures, speed service and improve product introduction times for NFV applications, providing a more efficient solution.”

FPGAs act as accelerators by offloading compute workloads, using less power than general-purpose graphics processing units (GPGPUs) and central processor units (CPUs) —which helps data centers run cooler.

FPGA- and SoC-based solutions are already accelerating servers in the data center in search and convolutional neural networks applications.

Initial interest in working with the OPNFV has come from the network service provider community, including OPNFV founding members AT&T, China Mobile, NTT DOCOMO, Telecom Italia and Vodafone, among others. In addition, other industries, such as the financial services industry, large enterprises and cloud service providers are showing interest in exploiting the NFV benefits.

OPNFV is a Collaborative Project at The Linux Foundation. Linux Foundation Collaborative Projects are independently funded software projects that harness the power of collaborative development to fuel innovation across industries and ecosystems.

INDUSTRY INSIDER

Technological Megatrends for Vehicles are Heavy on Electronics There are three important technological megatrends for vehicles that are now coming increasingly important. They are shaping what is designed and the market positioning of new vehicles from type of customer targeted to the location where the vehicles will be used. A new report from IDTechEx, “Electric Motors for Electric Vehicles 2015-2025,” gives forecasts and analyses for the place of electric traction motors in the creation of the $500 billion plus market for electric vehicles emerging in 2025.

Firstly consideration is electrification. Both conventional and electric vehicles, whether for land, water or airborne use, are rapidly becoming more electrical and electronic and less mechanical. For example, the newly popular switched reluctance traction motors - have no magnets or windings in the rotor. Indeed, the material cost is halved, but control and getting the optimal torque curves is more challenging calling for double the electronics.

A different trend for traction motors for both hybrid and pure electric vehicles is for there to be more than one per vehicle. For example, in-wheel motors as on the best-selling pure electric bus the BYD B9 recently landing orders up to 2000 at a time. Many cars planned for imminent launch have in-wheel motors in two or four wheels but doubling of motors is most popularl for other reasons such as four wheel drive, greater efficiency, release of space, modularization and redundancy—all achieved with inboard motors.

Secondly comes the megatrend of integration which includes those in-wheel motors as they increasingly integrate power electronics, brakes and much more. Mechanical, electric and electronic components are merging. Several companies are printing electric cars and Harvard University has printed much of the electronics, including a lithium battery, and it plans to print a motor though all of these are initially small. Meanwhile, Toyota hybrid transmissions include two motors, one acting as both generator and torque assist and the power electronics is embedded.

Structural electronics is the end game for much of this as the batteries become solid state and are part of the internal and external bodywork to save space, self-cool and possibly manage higher currents to drive those motors.

Structural supercapacitors have been demonstrated in car bodywork and there is some argument that traction motors should be driven by supercabatteries, which are hybrid supercapacitors, sometimes in the form of asynchronous electrochemical double layer capacitors (AEDLC) also called lithium-ion capacitors. These can have the superb one million cycle life of the supercapacitor, exceptional power density, good series resistance and the energy density of the lithium-ion battery or at least a lead-acid battery. Use in hybrids is now commonplace for supercapacitors. Higher power densities may call for improved motors so they can withstand the newly available pulses of power thus delivering better performance.

In aircraft on the other hand, extreme light weight is about to be achieved with structural photovoltaics, structural batteries and new traction motors with exceptional power-to-weight ratio.

For a two hundred year old technology, the electric motor is now changing surprisingly rapidly.

Zero pollution at point of use is another megatrend and it is achieved with pure electric powertrains (battery, supercapacitor, supercabattery) or fuel cell hybrid powertrains, currently only commercially successful in thousands in forklift trucks in the US. Innovations starting in forklift trucks are not new. Asynchronous motors were first successful there and are now commonplace in cars, buses and more. However, what is usually forgotten is that energy harvesting is also zero pollution at point of use and it is becoming capable of providing very serious amounts of energy such as kilowatts, albeit intermittently. Still, the power demands of a vehicle are also intermittent. Indeed, intermittency is greatly reduced by multi-mode energy harvesting such as harvesting movement in all directions plus heat difference, light, infrared and so on. It means that the expensive, short-lived traction battery can be smaller in future to drive the rapidly changing traction motors in vehicles as these technologies become commercial.

Telehealth Monitoring Device Segment Predicted to Explode The demand for telehealth services continues to increase and, according to a survey just released, that demand is driving two segments within the medical device market: cardiac and chronic disease monitoring devices.

This news comes from iData Research, which follows trends within the medical device industry. If the patterns identified by iData hold during the next half decade, the U.S. patient monitoring market will be a $5 billion one by 2020.

If that occurs, iData reports, “telehealth for disease conditions management is projected to represent more than half of the total telehealth market.” There are three primary drivers behind this projected explosive growth: • Demand for customized health care solutions; • Increased chronic illness amongst the aging population; • Strained health care budgets.

Other factors in the market growth include evolving reimbursement arrangements that will make equipment purchase more attractive to providers, and a general trend toward larger budgets for telehealth products and services.

The report cited two marketplace leaders that could be expected to benefit from the growth surge: Medtronic, the leading U.S. telehealth market, and Bosch Healthcare, which, iData said, entered the market in 2013.

Among the devices now competing for space in the telehealth marketplace are multi-parameter vital sign monitors, wireless ambulatory telemetry monitoring, telehealth monitoring, intracranial pressure devices, electromyography (EMG) devices, electroencephalography (EEG) monitors, cerebral oximetry devices, fetal and neonatal monitors, pulse oximetry devices, cardiac output monitoring devices and blood pressure monitors.

RTC Magazine AUGUST 2015 | 9

EDITORS REPORT UNITING THE IOT AND BIG DATA

Big Data and Small Things: prpl Foundation Aims for Compatible Connectivity An open-source, community-driven effort is concentrating on enabling next-generation Internet of Things with portable software, virtualized architectures and reliable security.

by Tom Williams, Editor-in-Chief

Data center to device. That’s a tall order, but that is what is implied by the ambitious phenomenon known as the Internet of Things and it is attracting huge numbers of eager participants. And there is certainly room for participation, innovation, specialization, imagination and more. There is also what might be an inherent paradox: the need for both open connectivity, i.e., public interfaces and standards, plus the need for security.

We seem to want everything to be able to connect to everything else, but not necessarily allowed to connect to everything else.

Here, but not for the first time, open source meets the need for security.

The prpl Foundation is a new consortium that was formed last year to meet the dual challenges of interoperability and security from the device to the datacenter. prpl has an early list of prominent companies as members, including board members Broadcom, Imagination Technologies, Lantiq (recently acquired by Intel) and Qualcomm, as well as more than a dozen other IP, SoC, security and software companies. In what might at first seem somewhat contradictory, the Foundation targets the MIPS architecture as the starting point for the development and collaboration efforts on security. But since the Foundation is open to other architectures, and the output of prpl’s security working group will be open sourced, concepts developed on this and similar platforms (Figure 1) should be easily portable to other architectures. The goal is to make the security framework, architecture and APIs independent of any instruction set architecture and any particular proprietary security implementation.

Members developing software for higher layers would of course not be bound to a given processor architecture.

Activities of the prpl Foundation are driven by prpl engineering groups or PEGs, which target specific domains. Currently there are three PEGs: The QEMU, which is working on a generic and open source machine emulator and virtualizer, the prplwrt PEG, which is focused on an open source embedded Linux platform for use with such things as Wi-Fi routers and other mis-

10 | RTC Magazine AUGUST 2015

Figure 1 The MIPS Creator CI20 platform from Imagination Technologies is a MIPS/ Imagination Linux and Android development system. It incorporates an Ingenic JZ4780 SoC which includes a 1.2GHz dual core MIPS32 processor and Imagination PowerVR SGX540 GPU. The CI20 board provides comprehensive connectivity, multimedia capabilities and substantial RAM and flash. Other development platforms are expected to be available in the near future.

sion-critical reliable products. Finally, there is the Virtualization and Security PEG, which has just been formed to address secure software environments across datacenter, networking, home, mobile and embedded environments—a tall order indeed.

The QEMU actually expresses the approach mentioned above.

It is a generic and open source machine emulator and virtualizer. When used as a machine emulator, it can run operating systems and programs developed for one machine such as an ARM processor on a different machine, be it based on MIPS or Intel hardware. Using dynamic translation, the QEMU is able to achieve quite good performance. When used as a virtualizer, it is able to achieve near native performance because it executes the guest code directly on the host CPU. QEMU supports virtualization when executing under the

Xen hypervisor or when using the Linux kernel virtual machine (KVM) kernel module. KVM is a module that allows a user space program to utilize the hardware virtualization features of various processors. For example, it supports Intel and AMD x86 and x86_64 processors as well as PowerPC 440 and 970 and MIPS32 as well as ARM Cortex-A15 and AArch64. The goal, then, is to have an emulator that can run any code from any other platform.

The mission of the prpl working group is to enable the close cooperation of users, hardware manufacturers, semiconductor manufacturers and the broader community of OpenWrt developers. OpenWrt is an embedded operating system based on the Linux kernel and primarily used on embedded devices to route network traffic. The main components are the standard Linux kernel, util-linux, uClibc, which is a small C library intended for Linux-kernel-based embedded and mobile systems. It is intentionally much smaller than the glibc library normally used with Linux distributions. In addition to being smaller to fit embedded application needs, uClibc can have selected features deleted to meet space requirements. OpenWrt also includes BusyBox, a set of stripped-down tools for use with embedded operating systems with limited resources that can provide something over 200 utilities. OpenWrt is an existing open source project with a vibrant developer community and is widely used by SOC vendors, Wi-Fi router OEMs, and software developers as their primary embedded Linux distribution.

The Quest for Security

The newest—and most challenging—PEG project to come out of the prpl Foundation is the effort to define an open security framework for deploying secured and authenticated virtualized services. The Security PEG initially consists of Broadcom, CUPP

Secure Extranet

TEE

Secure Intranet

OpenWRT

Secure App’s Crypto

3rd Party Containers

Linux Kernel

Secure OS

Linux Kernel

Software Hardware

Computing, Elliptic Technologies, Ikanos, Imagination Technologies, Imperas Software, Ingenic, Kernkonzept, Qualcomm, Seltech and others with more possibly to join.

Uniting the ideas of “open framework” and “security” will entail the job of transiting from today’s software-virtualized solutions to full hardware-supported virtualization (seen here as a vital element) that will enable multi-domain security across processors, heterogeneous SoCs and systems built on them including connected devices, routers and hubs. In addition, the Security PEG will define open APIs for various levels of the security stack in an effort to introduce commonality of approach to implementing security.

The idea of hardware virtualization appears to be key to the effort. According to prpl Foundations’ Chief Security Strategist, Cesare Garlati, “Security is the number one enabler of technology these days. There is no piece of technology today that does not require some security.” Attacks can of course come from all sources, from teenage hackers making mischief to PhD computer scientists in a foreign government trying to take down an entire nation’s power grid.

And let’s be frank. There is no such thing as 100 percent security. The complexity from firmware to middleware and software from endpoint to endpoint is just too great for a single solution.

So the task becomes one of risk management in what Garlati sees as the concept of layered security. “No one solution will be effectively 100 percent, but if you add more and more solutions at different layers, what you achieve becomes very close to 100 percent.” Just how close that might be is, of course, going to be the subject of endless debate.

We have been assisted greatly in the task by the enormous growth in hardware performance as well as by the scales of in-

IPC

Figure 2 The goal of true separation is the basis upon which other security measures such as encryption, authentication, etc., will be built. The hypervisor enables the creation of multiple secure domains where any damage would affect only that container and not the entire system.

Hypervisor MIPS, PowerVR

Heterogeneous Platform Network Interface

Offloads Secure Boot

Network Interface

DRAM

WAN

LAN

RTC Magazine AUGUST 2015 | 11

EDITORS REPORT UNITING THE IOT AND BIG DATA tegration that are now available to us. One fairly obvious fact is that security does affect performance as well as cost, so like any other technological issue, it is a trade-off. Garlati notes, “Now increasingly. exploding processor technology, core technology, is able to embed some of the security layers, putting multidomain security into the cores.” To that must be added usability, the idea of the common API mentioned above, to let users set up security functions.

Garlati says it is unrealistic to expect high security from any complex piece of software - such as modern operating systems even if beefed up with additional security modules. “The attack surface is simply too large,” he says. Only the smallest kernel could be actually audited and an OS kernel like Linux has over 17 million lines of code, which is incredibly difficult to analyze.

“Security has to be something that you boot before that kernel,” he says.

With today’s multicore architectures, the goal is to develop a microkernel and a hypervisor that can boot off the system itself.

That way it can maintain separation between the kernel and anything you may boot on top of that. The microkernel under

12 | RTC Magazine AUGUST 2015

consideration is something like 30k bytes, which can be audited and analyzed. Then with anything you boot on top of that you can maintain separation and contain any damage from affecting any adjacent entity (Figure 2). prpl Security and Virtualization PEG members are pursuing an ambitious goal. As hardware performance and integration increase, so does the ability to integrate security measures at the hardware level and service software security measures at higher layers. At the same time, of course, so do complexity and the ability and motivation to host multiple—often very different—services on the same system. This requires separation and security for orderly service as well as for protection against hackers. The advantage of having such basic security along with a standard model of how to implement requires industry-wide collaboration but holds the promise of greatly enhanced utility and confidence in the promise of the Internet of Things. prpl Foundation Santa Clara, CA www.prplfoundation.org

Embedded/IoT Solutions Connecting the Intelligent World from Devices to the Cloud Long Life Cycle · High-Efficiency · Compact Form Factor · High Performance · Global Services · IoT

IoT Gateway Solutions

Compact Embedded Server Appliance

Network, Security Appliances

High Performance / IPC Solution

E100-8Q

SYS-5028A-TN4

SYS-5018A-FTN4 (Front I/O)

SYS-6018R-TD (Rear I/O)

Cold Storage

4U Top-Loading 60-Bay Server and 90-Bay Dual Expander JBODs

Front and Rear Views SYS-5018A-AR12L

SC946ED (shown) SC846S

• • • • • • •

Standard Form Factor and High Performance Motherboards Optimized Short-Depth Industrial Rackmount Platforms Energy Efficient Titanum - Gold Level Power Supplies Fully Optimized SuperServers Ready to Deploy Solutions Remote Management by IPMI or Intel® AMT Worldwide Service with Extended Product Life Cycle Support Low Power Intel® Avoton, Rangeley, Quark, Core™ i7/i5/i3 and High Performance Intel® Xeon® Processors E3-1200 v3 product family • Optimized for Embedded Applications

Contact us at www.supermicro.com/embedded © Super Micro Computer, Inc. Specifications subject to change without notice.

Intel, the Intel logo, Xeon, and Xeon Inside are trademarks or registered trademarks of Intel Corporation in the U.S. and/or other countries.

All other brands and names are the property of their respective owners.

TECHNOLOGY CORE RTOSS: COMPACT, POWERFUL AND FAST

A Scalable RTOS for Wearables and IoT There is a huge growth of of wearables taking place in the IoT world. With it, developers are facing complex requirements for low power, multicore processing, communications and more.

by Warren Kurisu, Mentor Graphics

The world in which we live is evolving at a blinding pace.

While the concept of Internet-connected products is decades old, and the term “Internet of Things” (IoT) is commonly traced back to 1999 by Kevin Ashton (then, the director of the Auto-ID Center at MIT), it wasn’t until recently that technology has enabled a revolution in connected goods, including wearables. It’s fascinating that the embedded industry once again finds itself at the beginning of an era where the promise of enormous business returns is driving investments and new product development, not unlike the dot-com boom that drove the economy of the late 20th Century.

Before diving into the evolving requirements of wearables in IoT, it is useful to begin by defining some basic foundational terminology. A “wearable” can mean any product that is used for local data collection, storage, processing, and decision-making. Wearables are connected for purposes of data aggregation, data analysis, remote management, and decision-making at a gateway, in the cloud, or in some cases, both. Wearables can also be built for a specific purpose. such as a cardiac monitor.

But increasingly, these end products consolidate functions like the heart rate wristband called the Fitbit Charge HR. Others can even be fully featured application platforms like Apple Watch.

Many definitions exist for the “Internet of things” as well. But for our purposes it shall broadly mean an Internet-connected network of physical products that transmit data or information to Internet-connected servers for the purposes of data aggregation and storage, business intelligence, decision-making, and overall management of all things connected.

Connectivity Comes of Age

Connected goods or products have, of course, been around for years. A couple decades ago, we began to experience Wi-Fi connected laptops and home entertainment systems serving content from home-based servers. There were also simple connected products such as heart rate monitors and GPS navigation systems. Smart phones soon appeared and quickly became the first truly ubiquitous connected product. We are now experiencing an explosion of more sophisticated and connected items. The 14 | RTC Magazine AUGUST 2015

Figure 1 Wearables have expanded into many different product categories and industries.

wearables segment alone includes smart watches, fitness and activity trackers, glucose monitors, implantable cardiac monitors, augmented reality goggles, smart helmets, smart insoles, personal location products, and so on (Figure 1). The future is limitless for these increasingly capable and connected wearables. The trend line is clear: wearables will continue to increase in functionality and in end-user expectations – performance, battery life and reliability will also increase.

To realize the promise of complex and connected wearables, the hardware must be available to meet power and performance requirements. Fortunately, semiconductor manufacturers are working feverishly to create the hardware foundations to enable both current and future generations of wearables. Examples of this type of commitment include Freescale’s Wearables Reference Platform (WaRP) and Ineda’s Dhanush Wearable Processing Unit (WPU). Wearables today are being designed and manufactured with decreasing process geometries for minimal

Figure 2 At the core of a power management framework is the “Device Manager� that coordinates the transition of all devices during a change to a low-power state.

size and low power. They include homogeneous and heterogeneous multicore applications processors and microcontrollers for maximum flexibility that integrate support for graphics and displays, along with a plethora of options for connectivity, memory management, security, and more.

Competitive and time-to-market pressures drive the need for a solution that provides the foundational features and functionality to allow companies to focus their scarce development resources on building differentiated applications as opposed to the software platform on which those applications reside. Software developers see an extremely capable hardware foundation on which to build their wearable end product, but they now face a rather daunting task of structuring, developing, scaling, and testing the very software that enables these products.

As companies work to differentiate their wearable products and to get them to market quickly, software developers are increasingly requiring a more scalable solution with all of the key capabilities built in and with features that range from the very simple to the extremely complex. The overall solution must be able to satisfy small memory and processor requirements, but also be modular to allow the scaling of features for connectivity, graphics, and portability to accommodate more powerful multicore processors with consolidated functionality. A good example of such a solution might be a consolidated home medical unit that monitors not only blood pressure, but also measures and aggregates other vitals, connects to an infusion pump, presents a graphical and audible interface to hospice workers, and communicates to the lab, hospital, and doctors via the Internet or a cellular data network.

low-power features such as idle modes, sleep modes, dynamic voltage frequency scaling (DVFS), and hibernate. Yet, the complexity of implementing the low-power features in the hardware typically consumes precious developer time and often prevents application developers from generating power-efficient code.

Just as modern software architectures abstract hardware functions through device drivers, a power management framework (Figure 2) provides a structured mechanism for all system devices to be controlled using intuitive application programming interface (API) calls. Any alteration of one device that impacts other devices results in a coordinated transition across all involved subsystems. With a power management framework, embedded software developers developing software for wearable products can effectively write code to meet power requirements without creating code bloat and increased footprint. A power management framework allows developers to consider power specifications early in the software design cycle. Code can be written to minimize both the footprint and power consumption.

And it can be tested throughout the development process to ensure power requirements are achieved.

Single-core and Multicore Environments

As wearables become more capable and complex, they will require more capable hardware, which drives the adoption of multicore processors into the wearable space. These new multicore processors now include application cores in addition to microcontroller cores for energy-efficient operation. System architectures for wearables are beginning to run heterogeneous operating environments on these heterogeneous multicore processors. Operating systems might include a mixture of general purpose operating systems such as Linux or Android, running alongside a real-time operating system (RTOS) or even bare metal environments. The complexity introduced by these

The Importance of Power Management

Wearables are battery powered and therefore require capabilities to manage the power states of the CPU and applications.

Contemporary system-on-ship (SoC) designs for wearables offer

Figure 3 A multicore framework enables system level management of a heterogeneous multicore system.

RTC Magazine AUGUST 2015 | 15

TECHNOLOGY CORE RTOSS: COMPACT, POWERFUL AND FAST

Figure 4 To participate in the IoT, whether product-to-product or product-togateway or cloud, wearables must include the latest IoT communications protocols.

heterogeneous architectures is creating an entirely new category of problems related to the development, debugging, and optimization of the system.

Booting and management of remote cores is one such area of complexity. What developers need is a multicore framework that allows the system architect to designate one core in the system as the master (Figure 3). The software running on the master controls the power states of the other cores in the system, and it can also programmatically and dynamically load and unload software from those cores, depending on the current demands of the system. The multicore framework also requires a system-wide, inter-process communication (IPC) infrastructure, as well as integrated development tools, allowing developers to analyze and debug the entire system of heterogeneous software and cores. Such a framework provides two key benefits to architects. First, a system power management capability is enabled by the ability to control the power states of slave cores from a master core – unused cores and applications do not need to run if the wearable use-case does not require it. Second, this framework allows software to be dynamically loaded and unloaded depending on the use case, allowing the system to run many more applications than the physical hardware can actually support at a given time.

UI, Communications and Security

Wearables also commonly include a user interface (UI) that can range from simple to very complex. Thus, the solution must

16 | RTC Magazine AUGUST 2015

have the ability to scale graphics displays from a simple LCD to a sophisticated UI that leverages a GPU rendering 3-D graphics optimized for embedded wearables. Considerations must be made whether a commercial or open source graphics solution is required, and whether those solutions are available for the chosen operating platform. Many graphical UI solutions exist for wearables including the Qt platform, Embedded Wizard (Tara Systems), CGI Studio (SocioNext), Altia, and others.

Wearables can be connected to each other, directly to the cloud, or through a gateway which could be a smart phone or a local Internet-connected gateway. To be connected, wearables must support standards such as Wi-Fi, Bluetooth, and/or Bluetooth Low Energy (BLE), and also standards such as 6LowPAN and Thread. A wearable might also need to support IoT protocols such as CoAP, MQTT, and XMPP for product-to-gateway and product-to-cloud communications (Figure 4). As with other capabilities, these must work out of the box and be scalable in and out of the solution to meet the specific requirements of wearables.

Of course, with connectivity there will be concerns about security. As connected wearables become more complex and capable, private information will increasingly flow into and through them. Some examples include medical instruments with secure patient data and consumer wearables that may perform e-commerce along with digital rights management functions. These wearable systems must boot into a trusted state, data must be collected and stored safely, and data communication paths to

gateways and to the cloud must also be secured. To minimize code size and maximize performance, the solution should take advantage of secure boot technologies and leverage hardware-enforced security mechanisms such as Trusted Execution Environments (TEEs) and crypto security engines.

The world of IoT wearables is expanding. A perfect environment exists today for unprecedented business opportunity due to the capacity of the Internet and wireless bandwidth, combined with advances in processor and device technologies, standardization of IoT and communication protocols, and embedded solutions that enable the overall solution. These technical capabilities enable the creation of IoT products that can seamlessly gather enormous amounts of data, which can be analyzed to provide valuable information.

The wearable market is driving a wave of innovation and new products to market. Companies building wearables today will benefit from a highly scalable embedded development platform that addresses challenging requirements posed by small, resourced-constrained systems to more complex consumer end-products that support heterogeneous operating environments on homogeneous or heterogeneous SoCs, graphics, connectivity, and security.

Mentor Graphics Hillsboro, OR (503) 685-7000 www.mentor.com

WE ASSURE YOU HIT A BULLSEYE EVERYTIME. Electronicly and NOW in print.

The sourcebook is a large industry compendium drawing off our inventory on Intelligent Systems Source (ISS) website. The book will feature over 90 OEM manufacturers, manufacturers’ representatives, approximately 20 software vendors, listing over 1200 industry products from SBC, Systems, IO Boards, Displays, Power supplies and ARM products it will be the most thorough directory available in the industry.

Request your copy today.

intelligentsystemssource.com

RTC Magazine AUGUST 2015 | 17

TECHNOLOGY CORE RTOSS: COMPACT, POWERFUL AND FAST

Addressing the Testing Challenges of Safety-Critical Embedded Systems with Ultra-Light Instrumentation Traditional approaches to testing and verifying today’s complex multicore systems to meet safety-critical standards can affect memory and runtime performance to the point of creating even more uncertainty. A new approach promises to provide verification with minimal effect on system behavior.

by Jay Thomas, LDRA

Every embedded development environment, from 8-bit microcontrollers to 64-bit multicore CPUs has a variety of debug and code trace capabilities either built in or used commonly, from printf() debugging to hardware-assisted trace solutions. In early development, these tools are essential to acquiring insight into the behavior of the code. However, when a system is required to meet the needs of safety-critical industry standards, these debug and code trace capabilities are simply not sufficient. Their overly intrusive nature causes them to adversely affect performance and behavior of the software and the system as a whole.

Satisfying safety-critical industry standards (e.g., DO-178C for aerospace, IEC 62304 for medical devices, IEC 61508 for industrial systems, and ISO 26262 for automotive) requires that code be executed and tested to completion on the final system hardware. The overhead of using debug and code trace capabilities for system level testing and for assessing test completion through coverage analysis is particularly onerous.

Traditional debug and trace solutions typically require the software build process to include debug symbols, which has a significant impact on the software memory footprint and the run-time performance. The complexity added with multicore applications potentially creates an exponentially more difficult debug situation and environment. In addition, debug and trace mechanisms are not always available for multicore systems, but when they are, this overhead becomes so intrusive that it affects the synchronization mechanisms required to handle the resource contentions inherent in multicore systems (Figure 1).

When it comes to cost effectively proving that embedded software meets the requirements of safety-critical standards, the state-of-the-art requires collecting test and structural coverage data by instrumenting the code under test. With increasingly tight 18 | RTC Magazine AUGUST 2015

Figure 1 Traditional coverage collection focuses on monitoring each line of code, which requires substantial overhead just to facilitate the data logging of the debug traces.

development schedules and industry’s drive to reduce the size, weight and power (SWaP) of embedded systems, the memory and run-time overhead of traditional instrumentation and data collection techniques has become a productivity and application performance barrier. Traditional instrumentation and data collection techniques are simply not viable with the multicore systems increasingly used to meet SWaP requirements. However, new instrumentation techniques are now available that help to eliminate these challenges, enabling the cost-effective verification of multi-core systems to safety critical-standards.

Meeting the verification requirements for safety-critical industry standards requires that all testing be performed at the system level on the final system hardware, and test completeness must be proven through the use of structural coverage analysis.

Both of these objectives are addressed by the new instrumentation techniques.

What Makes Safety-Critical Code Harder to Test?

Before looking at the multicore challenge, we need to look at the typical dynamics of safety-critical development. First of all, the hardware arrives quite late in the project timeline. Clearly, software development cannot wait until the hardware shows up to start testing, particularly since the best way to produce a high-quality system is to test early and test often.

In order to keep the project on track, particularly with the enormous increase in the quantity and complexity of the code, the traditional test harness “stubs out” the missing hardware interfaces and/or enables test automation. While this enables software development to proceed, safety-critical software must be tested at the system level. And this is when the challenges begin. Target systems never have the same memory and run-time performance as the development platforms. The instrumentation of the code necessary to prove structural coverage tends to bog systems down, particularly if onboard I/O is needed to export test results.

Since instrumentation is often the ultimate challenge, let’s drill down to where the limitations lie. The traditional instrumentation used for performing structural coverage analysis is a combination of precompilation and run-time processes. Most companies place probe points on every line of code. Each instrumentation point becomes a function call in a data logging library, which at runtime records the points of code that are executed.

While this approach seems logical, the impact on both the size of the compiled executable and the run-time performance is significant. The size of the compiled executable is affected not only by each of the instrumentation points in code, but also by the inclusion of the instrumentation data logging library. These extra components can have a significant memory impact on both the firmware image in non-volatile memory and the runtime image in RAM. At run-time, each of the instrumentation data logging function calls incurs a significant performance overhead that can easily compromise the run-time performance of the system.

Because of the impact on system performance, it is not normally possible to instrument an embedded system in its entirety due to limited target resources. This limitation is typically addressed by verifying and analyzing the code one component at a time and then aggregating the results. In the safety-critical world, this stepby-step process is made more challenging by the fact that the processors and tool chains used are typically not the latest and so have even greater resource limitations. Traditional processes therefore require that system-level testing be repeated for each component, significantly extending the overall verification schedule.

Figure 2 Safety-critical libraries typically control data into and out of the application, which restricts the use of typical IO functionality and memory allocation. Because of this, instrumentation to collect code coverage must be independent of this functionality.

Testing on multi-core systems further complicates these challenges. When multiple processes run on different cores, collecting structural coverage data efficiently can be hampered by concurrency, reliability, and robustness roadblocks. For example, the typical approach to creating thread-safe instrumentation data-logging functions relies on the use of synchronization objects such as mutexes. This ensures that only one process can execute the data logging code at a time; the first process to execute the function “grabs” the mutex, blocking any other process attempting to use the same function from executing.

Once the first function has completed the data logging process, it “releases” the mutex and the next process in the execution list then “grabs” it and continues its processing. It’s not hard to see that this hand-off method could adversely affect the run-time performance of the system (Figure 2).

So, How Can Multicore Testing Happen?

First of all, we need to rethink instrumentation. Remember how traditional instrumentation is a combination of precompiled and run-time processes where probe points are inserted on every line of code. There is a better way!

To make things more efficient, static analysis of the code under test can be used to determine the best locations to place instrumentation points. This ultra-light instrumentation coupled with a new form of highly optimized test harness framework significantly reduces the memory footprint required to perform system-level testing and coverage analysis. With this approach, it is now possible to use test automation and hardware stubbing on target systems with well under 1K bytes RAM/ ROM! This approach takes advantage of a highly optimized data collection approach that integrates all platform test results and coverage dependencies into one data structure, a data structure generated by static analysis that takes into account concurren-

RTC Magazine AUGUST 2015 | 19

TECHNOLOGY CORE RTOSS: COMPACT, POWERFUL AND FAST cy constraints as part of its structure. Finally, developers can instrument applications on resource-constrained platforms.

To prevent concurrency issues at run-time, this approach eliminates calls into the operating system or to other library functions that manage memory or deadlocks. Thus, on resource-limited target platforms, it enables the test environment to mirror the speed and functionality of the final application execution. Rather than having to piece together multiple component-level tests, system-level testing can be accomplished with fewer—if not a single—pass, enormously cutting the time needed for testing. Structural coverage analysis can be captured at the individual core or aggregated to provide a multicore system-level view.

The test results and coverage data are tracked in a scoreboard-like matrix of bits, whereby each bit translates to a particular control-flow decision point in code. This means that storing results or “checking off ” each instrumentation point involves setting a value in a position of the matrix that corresponds to the location in code that was just executed.

The challenge here is performance, especially for the coverage instrumentation. A straightforward “index into a matrix” operation involves calculation of target addresses each time, which may sound trivial, but it adds up. Multicore systems just make matters worse, not only because you might expect such new programs to be bigger, but because now you have the possibility of collisions writing to the data structures.

As a result, a unique precompilation process can perform all of the address calculations for each instrumentation point ahead of runtime and store the results into a data structure set up so that multiple cores can read and write to it, consistently and simultaneously as necessary. This minimizes runtime overhead while at the same time reducing address collisions which may be

possible in multicore applications (Figure 3).

Multicore Testing Breakthroughs

For the first time, the technology exists that can enable multicore systems to achieve compliance. What’s made that possible?

Two new “bests” in verification technology. First, the structure can now be set to fully use every bit. To minimize memory footprint, one bit per decision point makes the instrumentation as light as possible.

Secondly, the inline structure manipulation is done at compile time, and results in anywhere between one and three instructions, depending on the processor and memory-addressing scheme. This approach is many times lighter than traditional approaches, which can result in 10-20 instructions per probe point.

Together, these approaches have been validated by users to produce an overall overhead of one to ten percent in terms of executable size and execution time, marking a significant reduction in overhead from other mechanisms.

By minimizing the memory and performance overheads of both system test frameworks and code coverage instrumentation, developers can not only instrument applications on resource-constrained platforms such as multicore platforms, but they are also able to run tests once and capture data for the entire application. This helps to reduce or eliminate any test duplication that is required to achieve the verification objectives for meeting safety-critical standards, increasing productivity.

Furthermore, by explicitly addressing the vagaries of instrumenting, verifying, and measuring the coverage analysis of code executed in a multicore environment, this approach helps projects realize the tight development schedules inherent to industry’s drive to reduce SWaP. LDRA Technology Atlanta, GA (855) 855-5372 www.ldra.com

Figure 3 If you compare the speed of traditional single core to multicore instrumentation, you quickly see why system verification has not been possible. However, all of this overhead goes away when you use structured bitmap techniques. Here concurrence management can be done directly at the instrumentation layer and the instrumentation optimized to 1-3 instructions per probe point versus dozens of instructions and the waits of the traditional approach.

20 | RTC Magazine AUGUST 2015

Mini-ITX

COM Express Module

PICMG SBC

www.portwell.com info@portwell.com 1-877-278-8899

Small Form Factor System

Network Security Appliance

TECHNOLOGY CONNECTED MACHINE-TO-MACHINE: DIFFERENT FROM IOT?

M2M is a Player; the Internet of Things is the Team Machine-to-machine systems were a start. Different dedicated devices cooperating for an application could share data and interact for a common purpose. Now with the emergence of the Internet of Things, such collaboration has become easier and the access to data and analysis has grown much richer.

by Elizabeth Campbell, ADLINK Technology

22 | RTC Magazine AUGUST 2015

When the IoT first became a buzzword, there was much talk of it being machine-to-machine (M2M) 2.0. But there is an enormous expansion of application scope and anticipated benefits when moving from M2M to the IoT. While it can be argued that the IoT is simply the next evolution of M2M, does it make sense to attribute the promised business benefits of big data and its manipulation to a term as limited as machine-to-machine?

M2M is simply that: the transference of data from one machine to another. And while there was always an implied usage benefit, the original definition of M2M limits the term to a subset of the Internet of Things.

The origin of the term M2M is in telecommunications. M2M is network focused; traditional M2M solutions typically rely on point-to-point communication using embedded hardware modules and either cellular, satellite or wired, public networks.

With M2M deployments, the main focus is on the quantity of devices one connects to the (money generating) network, with the M2M ecosystem built around that network. And while M2M has evolved over the years to include the IP-based network communication more commonly used to interface device data to a Cloud or middleware platform, it is really just the communication enabler in the IoT concept.

What the IoT can provide, with M2M as a key enabler, is big data. Big data can offer detailed demographics and interaction patterns for better marketing, individual buying behaviors for improved sales, network usage patterns of bandwidth and storage for optimized information technology (IT) planning, inventory and maintenance requirements for more efficient logistics, and patterns of revenue fluctuations for more accurate financial projections. Big data can also reveal how all of these issues affect the overall company for better operations.

M2M & Cloud Computing

Connecting to remote devices to extract collected data can be done in different ways, but all require hardware, firmware, and software components. A good place to start is with a dedicated board management controller (BMC). Initially designed for power sequencing tasks, the BMC has evolved to include many new and useful features for board management and control.

Measuring the supply current to get a snapshot of the system’s power consumption is only one example of these new capabilities. And compatibility with the latest embedded application programming interface specification (EAPI) reduces design efforts to port existing calls to the BMC. Providing the interface from the hardware to the operating system is one of the most important functions of the device’s remote management system. The BMC first collects all relevant information from the chipset and other sources. Utilizing the System Management Bus, the application layer fetches the data and presents it to the user, displayed either in the BIOS menu or a user-friendly dashboard suitable for supervision and troubleshooting.

Cloud connectivity takes today’s intelligent middleware a step further than previous generations of remote management technology. By employing a Cloud server architecture and an M2M

Figure 1 By employing full connectivity, from edge to Cloud to end application, SEMAenabled embedded devices can connect to the Cloud without additional design requirements. Being a holistic solution, Adlink’s Smart Embedded Management Agent (SEMA) Cloud offers users the entire infrastructure required. Customers do not need to develop their own Cloud solution, avoiding laborious checking of hardware compatibility, finding a suitable Cloud server, implementing data encryption or developing proprietary communication protocols.

stack on top of the intelligent middleware, embedded devices can connect to the Cloud without additional design requirements (Figure 1). For example, the M2M stack pushes system data to the user’s Cloud server via any kind of TCP/IP connection. System managers have easy access to data and analytics through any commercial Cloud portal, using any device (e.g., PC, tablet, smart phone).

When systems are available, operators can observe their performance. Cloud-based remote management furthers that process by enabling observation anytime, anywhere. Embedded management agents may be used to continuously upload data through an encrypted Transport Layer Security (TLS, the successor protocol of Secure Sockets Layer or SSL) connection.

Data to the Cloud enables operators to verify, monitor and manage system performance from a single, central location – providing immediate improvements to reliability and reduction in management costs. But the larger promise is realized when this big data is integrated into back-end business systems, such as enterprise resource management (ERP) and customer relationship management (CRM).

Machine-to-X Communication

With the IoT, communication has broadened from M2M to become machine-to-human or machine-to-Cloud. A critical challenge to deploying industrial IoT solutions is the lack of a single standard of network connection. For example, brownfield devices use a scattered variety of proprietary protocols; using an IoT gateway that supports cross-communication protocols and RTC Magazine AUGUST 2015 | 23

TECHNOLOGY CONNECTED MACHINE-TO-MACHINE: DIFFERENT FROM IOT? well—such as a hardware root of trust—to secure the communication channel, the data, and the end device. In addition, McAfee Embedded Control adds dynamic whitelisting. This technology locks the system down to a known good baseline so no program outside the authorized set can launch. McAfee Embedded Control also contributes a policy-based change control feature that monitors files and prevents unexpected changes.

Benefitting from M2M & the IoT

Figure 2 : Adlink’s embedded IoT gateway platforms feature fieldbus control interface, as well as superior WiFi/LTE/3G enabled edge device/Cloud connectivity.

Secure, scalable computing gateways with fieldbus interfaces enable seamless connection, aggregation, filtering, and data transmission to the Cloud with confidence. Looking beyond the gateway, Adlink’s SEMA Cloud includes a secure Cloud server architecture and machine-to-machine (M2M) stack on top of its intelligent middleware. This built-in service means the Adlink IoT gateways can connect to a commercial Cloud without additional design requirements.

can connect with IP-based networks can greatly simplify an IoT deployment.

The ideal gateway platform integrates routing and data collection functions, conversant with existing protocols. Strong support for widely-used fieldbus protocols provides bi-directional communication and acquisition (Figure 2). Simple IoT gateways are capable of accepting a wide range of connectivity protocols for analog and digital data and can provide communication for a wide array of industries, taking advantage of the valuable data existing in their hardware assets.

Intel has invested much time and effort in an Intel IoT Gateway platform that addresses the need for incorporating both legacy devices and newer, more open systems into IoT deployments. The Intel IoT Gateway platform integrates an Intel processor-based third-party hardware with an Intel software stack. This software platform bundles together the Wind River Intelligent Device Platform (IDP) XT and McAfee Embedded Control to provide a complete, pre-validated communications and security solution.

Wind River IDP XT provides a software stack for communicating with local equipment and the Cloud. Its extensive connectivity choices include Wi-Fi, Bluetooth, ZigBee, and short-range wireless protocols widely used in smart buildings. Wind River IDP XT supports the MQ Telemetry Transport (MQTT) protocol for data transportation, and remote management protocols such as Technical Report 069 (TR-069), CPE WAN Management Protocol (CWMP) and Open Mobile Alliance Device Management (OMA DM). For developers, the Wind River IDP XT software stack provides Lua, Java, and OSGi application environments to enable rapid, reusable application development.

Wind River IDP XT delivers built-in security features as

24 | RTC Magazine AUGUST 2015

Embedded platforms are in transformation, evolving from standalone compute systems to becoming part of the Internet of Things (IoT). More than just Internet-enabled, these intelligent systems are networked and communicating, gathering and sharing information that enables insight and solves problems. Improving healthcare, enabling intelligent transportation systems, and modernizing manufacturing, intelligent IoT applications are delivering benefits to a wide range of industries, empowering business transformation all over the world.

While the concept of sharing and analyzing business information is not new, the IoT leapfrogs piecemeal, proprietary M2M data transfer applications by enabling greater access and more in-depth analytics and action with standards-based, third-party vendor solutions. Software, hardware and end-user applications work together in real-time to expand network access, functionality and intelligent performance. Now capitalizing on the business value of real-time data analytics is no longer limited to enterprises with the resources to develop their own proprietary systems, but instead is open to both consumers and industries alike.

ADLINK Technology San Jose, CA (408) 360-0200 www.adlinktech.com

SUBSCRIBE NOW Full-On Develop ment Suite Targets Industri al Automation

The Magazine

of Record for

the Embedded

Computer Industry

Medical Devices Merge Intelligence with Connectivity Temperature Conside rations for Critical Solid State Storage Vol 16 / No 3

COM Modu Variety andles Grow in Capability

/ MARCH 2015

An RTC Group Publication

@RTCMAGAZINE.COM

10 24 32

www.intelligentsystemssource.com

ADLMES-8200

ADLMES-8200 High-Ingress Protection Modular Enclosure System Intelligent Systems Source announces the ADLMES-8200 series from ADL Embedded Solutions as its Modular Enclosure System of the Month. With its ability to support variable stack heights, reduce time to market, and customizable I/O plate the ADLMES-8200 leads all others in function and design.

The ADLMES-8200 is an innovation within embedded enclosure design. Its highly conngurable modularity makes it possible to expand or reduce a system without replacing the entire enclosure. Side modules may be added or removed as system requirements evolve. Three basic size prooles provide a high availability starting point for meeting your speciications. Once integrated, the ADLMES-8200 lends itself to extending the life of existing products by allowing the enclosure to be modiied with minimal impact; translating into lower development and sustaining costs, and shorter development cycles.

Request More Information at: www.IntelligentSystemSsource.com/ADLMES8200

TECHNOLOGY IN SYSTEMS DEVELOPMENT TOOLS FOR THE IOT

HW/SW Platform Simplifies and Accelerates IoT Product Development

Designing new product or redesigning product for the world of the Internet of Things involves a set of challenges that can cost engineers the advantage of time to market.

A new generation of tools that aids and abstracts many of these issues can speed innovative and accurate product development.

by Vin D’Agostino, Renesas Electronics America

26 | RTC Magazine AUGUST 2015

Traditional Development Hardware Design

Driver Software Design

Middleware Design

Itegration Cloud w/RTOS Connect

Application Code

System Test

Development Using Integrated IoT Platform Hw Dsgn

Essential System Code

Application Code

Additional Innovation

Differentiated Code

Product Differentiation

By now we’re all aware of the growth expected for the Internet of Things market. Industry analyst Gartner estimates that 4.9 billion connected devices will be in use by the end of 2015, up 30 percent from 2014. Numbers like these have captured the attention of embedded device OEMs and IDHs alike, and much of their new product development efforts are now focused on creating IoT-enabled devices. But the IoT is having a profound effect on the way companies design new products, and to successfully bring new IoT designs to market, engineers need to adopt a new approach to product development.

But why? What is it about designing a product for the IoT that makes it necessary to move to a new design model? There are many factors, but they can all be put into one of three areas of concern: time to market, total cost of ownership, and barriers to entry.

Time to Market

One of the toughest challenges the IoT market presents is its impact on the pace of development. Today everyone understands that those who bring their product to market first reap the largest profits. But the advantage of beating the competition to market doesn’t end there. For the most part, today’s IoT market lacks accepted industry standards. Those who get to market first will have the greatest opportunity to influence those standards and gain an edge over the competition.

Additionally, the IoT market forces embedded developers to reconsider their definition of system-level design. They have to stop thinking of their application as a discrete unit. Instead, they must think in a broader sense about how their application fits into an interconnected world. That, in turn, will force developers to adopt new technologies. As new communications, security, user interfaces and sensor technologies become increasingly commonplace, embedded designers building products for the IoT market must enhance their skills and knowledge of connectivity, the Cloud, and portable applications. Adding support for these technologies

System Test

Figure 1 By providing preconfigured drivers, middleware and RTOS integration, a truly integrated IoT platform shortens the design time required for new IoT product development.

to an embedded device increases overall complexity, which can negatively impact a new product’s time to market.

Total Cost of Ownership

For most embedded devices, the design process starts with the selection of a microcontroller (MCU) to serve as the hardware platform for the product. Following that, most OEMs and IDHs then mix and match various software components (design software, drivers, middleware, etc.) to build their product’s core system software. However, this process fails to account for much of the hidden costs that come into play when designing a new product. A great deal of time and expense can be required to find and qualify the proper software for the product, getting trained to use it, porting it to the MCU, and qualifying and debugging it. Furthermore, much of this software is open source or comes from vendors with limited support resources. So if a software problem arises it can slow development to a crawl while the design engineers wrestle with vendors as they attempt to get one of them to take ownership of the problem.

Barriers to Entry

In addition to time to market and cost of ownership issues, design engineers must also overcome different barriers to entering the IoT market that can take many forms, but are all detrimental to progress. For example, in addition to the technical challenges involved in working with embedded software from different vendors, there are usually struggles around negotiating licensing and pricing terms for using the software. Many software vendors require large upfront fees and the purchase of seat licenses in order to use their products. Design teams may also want to leverage legacy software they’ve developed in their new product, which will need to be ported to the new system and tested for compatibility with any new software or hardware. All of these issues can add unwanted cost and monopolize valuable

RTC Magazine AUGUST 2015 | 27

TECHNOLOGY IN SYSTEMS DEVELOPMENT TOOLS FOR THE IOT Software API

Complete RTOS-based Integrated Application Framework

S/W AddOns

Scalable MCU

Figure 2 A well-integrated API and application framework gives design engineers direct access to key hardware and software components for easy application development.

engineering resources to an IoT design.

As we look at the design challenges described above, it becomes apparent that much of the work required for designing an IoT device involves software and hardware configuration, licensing, technical support, debugging and qualification. While these issues must be addressed if the product is going to function properly, ultimately they detract from the design team’s ability to develop application software or other device features that will help differentiate the IoT device from the competition. An IoT development platform that addressed these concerns and challenges upfront would free design engineers to spend more time focusing on developing a product’s unique value added features and less time on basic device functionality, while still allowing them to get to market quickly, efficiently and cost effectively.

For an IoT Platform, Software is Key

To address these concerns around time to market, total cost of ownership and barriers to entry, design engineers need access to easy-to-use, integrated hardware and software platform for IoT product development. That said, there are many embedded and IoT design solutions available today that claim to be highly integrated hardware and software platforms, so let’s examine exactly what a truly integrated IoT development platform should look like.

A core requirement of this integrated IoT platform is a software package that provides all the key software components necessary for most embedded systems and IoT applications, including a real time operating system (RTOS). For example, Renesas recently announced a new IoT development platform, Renesas Synergy, and bundled with it is a premium quality, high-performance and low foot-print RTOS, Express Logic’s ThreadX, along with various middleware components from Express Logic’s X-Ware suite of embedded software. These elements have 28 | RTC Magazine AUGUST 2015

been tested and verified by Renesas against a published set of specifications, a first in the MCU industry. This eliminates much of the time required to configure basic device functionality and accelerate the IoT product design cycle (Figure 1).

Another key component of an integrated IoT platform’s software offerings is the API, which gives design engineers access to the platform’s RTOS, middleware and libraries, and hardware peripherals as easy-to-use, feature-oriented functions.

This approach allows the developer to begin building applications almost immediately without spending considerable time learning detailed MCU hardware peripherals, device drivers, specific register definitions, or RTOS integration. A complete set of low-level peripheral driver modules should also be available for a wide array of functions including memory, connectivity, analog, timing, power management, security and encryption, safety and human machine interface. Since some embedded developers will require direct access to individual peripheral drivers from outside the API framework, they should also be able to make direct calls from the application to meet application-specific requirements or to operate within time-critical bounds.

Furthermore, since the drivers abstract hardware registers by using logically defined values, the API must provide a consistent experience across different MCUs within the product family, so application code is easily portable to faster, more robust MCUs if the device’s performance demands increase over time.

In addition to the APIs, the platform should support an application framework that integrates with the platform APIs and abstracts MCU hardware features to provide a uniform and consistent interface for application programmers to access and utilize most major features in platform without having to worry about complexity of the underlying low-level device interfaces in the platform. This helps speed the development of common applications used in IoT designs. The application framework should consist of a collection of system level services that are integrated with the RTOS’s features to manage resource conflicts between applications and synchronize between multiple user threads. This would be particularly useful as many of the framework’s modules utilize the services of other application framework modules and have mutual dependencies. The primary purpose of these framework components is to relieve the application developer from having to reinvent commonly used services across applications (Figure 2).

An example of this can be seen in the Renesas Synergy Platform’s Serial Peripheral Interface (SPI) Framework, which provides ThreadX-aware API functions for communicating with SPI peripherals from application threads. The SPI Framework makes use of lower level SPI driver modules to communicate with SPI peripherals and the framework handles the integration and synchronization of multiple SPI peripherals on a single SPI bus. For example, in an IoT-connected thermostat or environmental controller application, its temperature and humidity sensors would communicate over a common SPI bus, which would require separate threads communicating asynchronously with temperature and humidity sensors on the same SPI bus.

Peripheral and Pin Compatibility Across and Between Product Series

4M

2M 1M 512K 256K 128K

FLASH DENSITY

3M

Concentric Footprint

64K

PIN COUNT 38

48

84

100

121

144/145

178

224

Figure 3 To accommodate scaling performance demands, an integrated IoT development platform should offer a range of MCUs with different memory and performance capabilities, with all devices in the product family having pin and peripheral compatibility for easy code portability.

This would create resource conflicts between threads, which the application developer will need to manually resolve by blocking the peripheral at a low level when one thread is accessing it.

However, using the Synergy SPI framework this task is automated and streamlined using the thread-safe APIs of the SPI Framework module to handle these resource conflicts and ensure only one application thread gets access to the hardware resource at any time during execution. The SPI Framework also takes care of automated chip select handling, so designers don’t have to enable and disable chip select signals in their applications.

To complement this highly-integrated software offering, the IoT platform should also offer a selection of compatible and scalable 32-bit MCUs based on an industry standard CPU core like the ARM Cortex-M architecture. These MCUs should be designed for IoT requirements and with the objective of maintaining compatibility with the platform’s software components for as long as possible to minimize maintenance. This means that across the board, all MCUs used in the IoT platforms have the same or similar peripherals to minimize the learning curve and maximize re-use of software. Moreover, the pin definitions should also remain same or similar for all like-packages across the entire family to facilitate easy migration to higher- or lower-function devices. Scalability also requires that peripheral capabilities scale from lower to higher and higher to lower while keeping the same register footprint. For example, a simple 16-bit version of a timer peripheral and a complex 32-bit version of the same timer have the same basic control registers, but the 32-bit version adds registers to match the added functions orthogonally which have no effect on the 16-bit version. Also, the register address offsets are designed to simplify the software; if a timer

function does not exist, neither does the register, but this does not change the overall register address offset scheme.

An example of such a hardware platform would be the four MCU classes in the Renesas Synergy family (Figure 3). They include four different sub-classes, each with different performance capabilities to meet the needs of a variety of IoT applications.

The first class of MCU in the Synergy family, the S1 series, features an ultra-low-power MCU based on a 32 MHz Cortex-M0+ core. Three additional members of the Renesas Synergy MCU family, the S3, S5 and S7 series, use Cortex-M4 cores to support operating frequencies that currently range up to 240 MHz. Designed with industrial automation, motor control, sensor fusion, and similar embedded and IoT applications in mind, the Cortex-M4 features extended single cycle multiply accumulate (MAC) instructions, optimized SIMD arithmetic, saturating arithmetic instructions and a single precision Floating Point Unit (FPU).

Finally, to eliminate many of the challenges around time to market, cost of ownership and barriers to entry described above, the software and hardware included in the IoT platform should be supported as a single, unified product, with one vendor assuming all responsibility for the development and integration of the platform’s components, so design engineers only have one point of contact to deal with when sourcing licensing agreements or technical support.

Renesas Electronics America Santa Clara, CA (408) 588-6000 www.am.renesas.com

RTC Magazine AUGUST 2015 | 29

TECHNOLOGY IN SYSTEMS DEVELOPMENT TOOLS FOR THE IOT

Helping Manufacturers Start Near the Finish Line in Developing IoT Mobile Apps Designing and manufacturing connected products for the IoT requires a completely different mindset than making traditional, static products. Manufacturers need tools to easily provide expertise in areas previously unfamiliar, starting with embedded design and networking to the development of full-featured mobile apps.

by Oliver Cockcroft, Ayla Networks

Until recently, manufacturers of everything from washing machines and coffee makers to air conditioners and water heaters have not needed to be experts in computer and networking technologies. While their products might have digital displays or timers or other simple electronics built into them, manufacturers are unlikely to have in-house teams of software engineers steeped in the latest best practices in programming and mobile user experience.

The Internet of Things (IoT) is changing all that. Manufacturers of all kinds of everyday products are realizing the advantages of connecting to the IoT, and they might have even started to turn their traditional products into first-generation connected products (Figure 1).

But when it comes time to create a mobile app to give end users control over those connected devices, manufacturers face a quandary: Do they bulk up their in-house software engineering expertise—which takes time and can slow their market entry while they ramp up the ability to add mobile-app control of their connected products—or do they resign themselves to the expense of hiring a custom development house to create the savvy, secure, reliable mobile apps that today’s consumers expect?

There’s now a third alternative, which is to use an IoT-specific mobile application platform. For manufacturers that lack the specialized software development skills to create their own mobile control apps from scratch, a mobile application platform can provide a rapid, cost-effective way to take advantage of IoT opportunities.

This article describes one such platform that provides the majority of the coding and development work common to any high-performing, reliable and secure IoT mobile app, leaving only business logic and user experience (UX) design work to be completed. This approach allows the manufacturer to focus

30 | RTC Magazine AUGUST 2015

Figure 1 More and more connected devices, such as home appliances, are expected to enter the market.

on the branding and customer experience, while dramatically accelerating time to market.

IoT Mobile Apps Take Center Stage

Smartphones have become ubiquitous. As a result, users expectations for mobile apps have skyrocketed. They have no patience or interest in mobile apps that aren’t high-performing, reliable, secure and intuitive. They want a great mobile app experience.

In the IoT, mobile apps are the way that consumers interact with and control their connected devices. They use mobile apps to set thermostat or lighting controls, or to schedule when coffee makers start brewing in the morning.

In a very real way, end users often equate the IoT mobile app with the IoT device itself. That means that the quality of

the mobile app forms a crucial part of the user’s opinion of any connected product.

It turns out that the vast majority of what makes a good IoT mobile app is the same regardless of the specific device it controls. Only about 10% to 15% of the development effort is spent defining device-specific and manufacturer-differentiated features, functionality, and look and feel. This final development push provides the personalization that spells the difference between a thermostat mobile app from company A vs. company B, or between a company’s mobile app controlling a dishwasher and one controlling a clothes washer.

Taking a Platform Approach to Mobile App Development

A mobile app platform such as Ayla Networks’ Agile Mobile Application Platform (AMAP) lets manufacturers begin almost at the finish line to develop iOS or Android apps that can control IoT devices of any kind. The platform provides the 85% of coding and development work that’s common to any good IoT mobile app.

Manufacturers that license the mobile app platform code need only specify the remaining 15% or so of functionality that is specific to their company and device type, and to “skin” the app with company-branded colors, graphics and other features.

This mobile app platform includes mobile libraries that authenticate with the Ayla cloud; enable connection to the end user’s local area network (LAN); manage the user’s interactions with the device; and take advantage of all the cloud functions built into the IoT platform.

In addition, the platform includes pre-made, pre-tested software code supporting the primary features and functionality that users expect from mobile app control of a connected device.

These features include user sign-in and registration, device setup, wireless (Wi-Fi and Zigbee) setup, timer setup, device control, schedule creation and management, password recovery, and support for push notification. It also supports over-the-air (OTA) updates for adding new device features or upgrading security capabilities while the devices are deployed in the field.

The mobile app code is delivered as workflows optimized for specific vertical markets, including HVAC (heating, ventilation and air conditioning), home appliances or lighting.

Through the service-oriented architecture (SOA) of its underlying IoT platform, the mobile app platform provides application services that include a rules engine, third-party integrations and custom rules. The IoT platform architecture also includes device services (templates, notification, time and location, image service, OTA updates), user services (security, triggers and alerts, OEM dashboard, developer website) and data and analytics services (logging and metrics, statistics, reports and data discovery, ETL [extract/transform/load data]).

Application programming interfaces (APIs) provide the common language among the SOA-based services, allowing the Ayla cloud to communicate with the APIs of other secure clouds and services.

The mobile app platform is scalable to almost all types of

Figure 2 Ayla’s Agile Mobile Applications Platform allows manufacturers to jump-start their mobile app development with a pre-configured solution.

connected device. It provides a framework on top of the APIs and mobile libraries that allows manufacturers’ IoT devices to connect to the Ayla cloud and to integrate with iOS or Android mobile operating system (OS) code. All the code development is done in native Objective C and Java languages, which ensures a high level of quality for manufacturers’ mobile apps.

The IoT platform delivers additional application capabilities, such as an automated join/discovery process at setup for both iOS and Android devices; performance optimization in the LAN for low-latency connectivity; the ability for Ayla-enabled devices to work in the LAN even if the broadband connection goes down; the capture of network logs to assist with customer support issues; and an API for web application development.

Securing IoT Mobile Apps

Security is a top-of-mind concern for every aspect of a connected product. Even if an IoT connected device isn’t set up to transmit end users’ credit card numbers or sensitive health or financial information, consumers have legitimate concerns about their privacy and the kinds of data that are being transmitted. If for no other reason than to allay consumers’ concerns, manufacturers need to be scrupulous about the security of their IoT products.

A good IoT platform will be designed with comprehensive security in mind, from device to cloud to mobile app. IoT platform security should encompass: • Encryption at the chip level to protect data in transit and to prevent spoofing • Transport-specific security measures to encrypt data in transit (e.g., using X.509 certificates, public/private key generation, AES crypto ciphers, hashing, and generating and checking packet signatures) and data at rest (encryption keys, backup) • Key transmission protocols such as TLS, so that data safely reaches its destination RTC Magazine AUGUST 2015 | 31

TECHNOLOGY IN SYSTEMS DEVELOPMENT TOOLS FOR THE IOT

Figure 3 The Ayla IoT platform provides software throughout the spectrum from device to cloud to mobile application.

• Multi-factor authentication • Role-based access control, to limit who can access the device and what functions they can access, control or change • Multi-tenant operation, enforced with a tenant ID associated with every piece of data and a data access mechanism that enforces the separation of data by manufacturer

• Cloud security, such as leveraging services deployed with an Amazon Web Services (AWS) Virtual Private Cloud (VPC) environment • Security measures that deal with transfers in ownership or control of a connected device, including new people purchasing a house with smart home controls, or IoT technology in place in a hotel or vacation rental To some extent, security measures will vary from one type of device to another. For example, unlocking car doors requires strong user authentication, while protecting medical data transmitted from an out-patient’s heart monitor to the doctor’s iPad requires a rock-solid data encryption solution. The architecture of an IoT platform must understand and be able to incorporate multilevel security with end-to-end protection.

A few manufacturers might decide it’s worth the investment to hire in-house or outsourced technical expertise to create their own IoT mobile apps. For the vast majority, though, the best way to compete in the IoT market will be to take advantage of a comprehensive and agile IoT mobile app platform.

Ayla Networks Sunnyvale (408) 830-9844 www.aylanetworks.com

RTC PRODUCT GALLERY 3U CompactPCI Showcase AmITX-HL-G: Mini-ITX Embedded Board with 4th Gen Intel® Core™ i7/i5/i3 Desktop Processor • 4th gen Intel Core i7/i5/i3 Desktop Processor • Dual SODIMM DDR3L-1600 memory sockets supporting up to 16 GB • PCIe x16, PCIe x1 and Mini PCIe expansions • 3 DisplayPort outputs on rear IO

ADLINK Technology, Inc. Phone: (408) 360-0200 Toll free: (800) 996-5200 Email: info@adlinktech.com Web: www.adlinktech.com

G23; 3U CompactPCI Serial SBC MEN Micro’s G23 is a 3U CompactPCI Serial SBC based on the 4th generation Intel Core i7 CPU. The scalable SBC follows the same I/O interface assignment and front plate design as previous versions. Existing systems can be easily upgraded to the latest CompactPCI Serial technology extending a system’s lifecycle.

Technical Specifications: • Intel Core i7, 4th generation • Up to 16 GB DDR3 DRAM soldered, ECC • Intel Turbo Boost, Hyper-Threading, AMT 9.0 • Standard front I/O: two DisplayPorts, two Gb Ethernet, two USB 3.0 • Standard rear I/O: seven PCIe, eight USB 2.0, two USB 3.0, five SATA, DisplayPort/HDMI • Rear I/O via mezzanine board: up to eight Gb Ethernet

Men Micro Phone: (215) 542-9575 FAX: (215) 542-9577 Email: sales@menmicro.com Web: www.menmicro.com

32 | RTC Magazine AUGUST 2015

The medical industry has a unique demand for highest safety and reliability meeting regulatory requirements. Applications range from demanding computing requirements for optical Analysis to low power mobile diagnostic and supportive equipment. The NOVAsom8© is a module card designed with a System On Module (SOM) architecture based on quad core ARM Cortex-A9, 64 bit memory until 2 GB and 3 graphic engines that is perfect for medical applications.

Designed with the latest generation, high performance microprocessor. NOVAsom8© can be used in many distinct industrial applications. On-board connectivity solutions, advanced multimedia and other standard peripherals allow our customers quick and easy From the integration into numerous innovative, high-tech product applications.

NOVAsom8© is based on Freescale processors that are focused on industrial products and market segments requiring stability and long product life cycle.

Data Center to the Battlefield. www.novasom.info

23263 Madero, Suite C, Mission Viejo, CA 92691 (800) 543-3830 • (949) 855-3235

TECHNOLOGY DEVELOPMENT MEETING MEDICAL EQUIPMENT STANDARDS

Understanding IEC 62304 for Medical Device Compliance

As software becomes an ever more important component of medical devices, compliance with standards will become essential. This will require the establishment of a standards compliance program that will meet the demands of standards for operation and certification.

by Rita King, MethodSense, and Alex Grob, Medical Equipment Compliance Associates

What do hospital beds, blood pressure cuffs, dosimeters, and pacemakers all have in common? They are all medical devices with software that regulates their functionality in a way that contributes to Basic Safety or Essential Performance. With the FDA reporting that the rate of medical device recalls between 2002 and 2012 increased by 100% – where software design failures are the most common reason for the recalls – it’s no wonder IEC 62304 has been implemented. Its implementation, however, has medical device manufacturers asking questions about if, when and under what circumstances the standard is required.

For Starters, What is IEC 62304?

IEC 62304 is the international standard that defines software development lifecycle requirements for medical device software.

The standard was developed from the perspective that product testing alone is insufficient to ensure patient safety when software is involved. The standard requires all aspects of the software development life cycle to be scrutinized, including: • Development • Risk management

34 | RTC Magazine AUGUST 2015

• Configuration • Problem resolution • Maintenance The standard provides a common framework for medical device manufacturers to develop software. Conformance with this standard provides evidence that there is a software development process in place that fulfills the requirements of the Medical Device Directive. Because it has been harmonized with the Medical Device Directive in the EU and recognized as a Consensus Standard by the FDA in the US, IEC 62304 can be used as a benchmark to comply with regulatory requirements in both markets. To date, this standard has been recognized in most countries that use compliance standards to fulfill regulatory requirements.

One of the most commonly asked questions of test labs is, “Is compliance with this standard required?” Technically, the answer is “no” because compliance with the standard is voluntary.

But, in practice, the answer is “yes.”

[

][

Since most medical devices in today’s market contain some type of software, manufacturers must determine under which circumstances IEC 62304 is required.

These include: • FDA regulatory compliance with IEC 60601-1 Amendment 1 • Reliance upon software to perform Basic Safety functions •Reliance upon software for Essential Performance

If your device falls into any of the above categories, you must have evidence that the software development process used is as good as, or better than, the process presented in IEC 62304.

Complying with 62304 enhances the reliability of your device’s software by requiring attention to detail in design, testing and verification, ultimately improving the overall safety of the medical device.

Does your device have to meet IEC 60601-1 requirements?

The EU has been using IEC 62304 since 2008, but it has gained even more traction with its incorporation into the third edition of IEC 60601-1’s Amendment 1. The inclusion of Amendment 1 shifted the standard from a recommendation to a requirement if your device utilizes software.

For those who design or manufacture electromedical equipment, 60601-1 is one of the most important safety and performance standards to meet. The standard addresses critical safety issues, including electrical shocks and mechanical hazards, such as pinching, crushing, and breaking. Devices that must meet IEC 60601-1 requirements include those which: • Diagnose, treat, or monitor the patient under medical supervision • Make physical or electrical contact with the patient • Transfer energy to or from the patient; and/or • Detect such energy transfer to or from the patient.

60601-1 Clause 14 requires manufacturers to comply with IEC 62304 unless the device’s software has no role in providing basic safety or essential performance or risk analysis demonstrates that a failure of any Programmable Electronic Safety System (PESS) does not lead to an unacceptable risk.

Basic safety is the main focus of IEC 60601-1. It’s important that you conduct a risk analysis to identify your device’s level of unacceptable risk and determine the role of software in risk mitigation. This analysis will determine the applicable basic safety requirements for your device, and, for some requirements, the test parameters that might be required by the test laboratory.

In conjunction with IEC 60601-1, 62304 is intended to minimize the occurrence of these situations. When device software is mitigating a known potential hazard, ensuring that the code is developed properly is critical for the management of patient safety, as well as liability to the manufacturer.

]

A COMMON MISTAKE...

The most common mistake that medical device manufacturers make is that they do not always assess which elements of risk their software mitigates. These are the elements that must be addressed by IEC 62304. For example, what would happen if the creator of a hoist didn’t properly vet the software that signaled the hoist to lower the patient at a certain speed? If a patient were lowered to quickly – or not at all – there would be a risk management nightmare.

Since software plays a role in the Basic Safety functions of the hoist, it must comply with 62304’s requirements.

Does your Software Impact Essential Performance?

It can be difficult to determine if a device’s software is tied to its essential performance (EP), especially because the definition of EP has been widely debated for years. Thankfully, the definition and requirements for essential performance changed with Amendment 1 of IEC 60601-1 to help provide more clarity.

Determining essential performance begins with a list of all functional aspects of your device, including accuracy, measurements and its capabilities. Once you identify these items, determine whether any of these are already covered by the basic safety requirements of IEC 60601-1 or whether any item is not part of the device’s intended use. Then, and this is key, every item remaining gets posed the question, “If this item degrades, will it create a risk for the patient?” If the answer is yes, you must identify how its functionality must be maintained so the risk is still acceptable. This is your essential performance.

A good example to help clarify the impact of essential performance on IEC 62304 is accuracy. Consider a device that claims its EP is accurate within 5%. If the device is relying on software to maintain that accuracy or provide an alert when outside of 5%, and that software fails, then the manufacturer will be unable to detect if the device’s essential performance is being met.

This means the software is providing essential performance.

Once you know your device software is responsible for essential performance, you must comply with IEC 62304 to ensure there is no unacceptable risk to a patient.

What are Common Scenarios Manufacturers Miss?

There are several situations that manufacturers often don’t realize require compliance with IEC 62304. These product features can create major headaches and costly delays if they are not properly developed. These scenarios include:

RTC Magazine AUGUST 2015 | 35

TECHNOLOGY DEVELOPMENT MEETING MEDICAL EQUIPMENT STANDARDS

[

]

Alarms & Alerts, Speed & Position Sensors and Algorithms are components that are often missed by manufacturers. They all use software for Basic Safety and Essential Performance functions… requiring IEC 63204 compliance.

Alarms & Alerts Alarms are often an Essential Performance requirement because they are intended to detect abnormalities. If the alarm were removed, the device would no longer meet its performance requirements, making the risk unacceptable. Software is used to detect the issue, instigate the alarm and make the sound.

Speed & Position Sensors These sensors are in place to address basic safety concerns.

For example, a hospital bed has a position sensor to keep it from crushing the operator’s foot and mammography has sensors to gauge compression. Devices like these use software to limit range of motion, speed and force.

Algorithms Algorithms are frequently used with physiological monitoring. If the software is removed, the device is no longer able to operate as intended, resulting in the algorithms being part of essential performance.

It is important to note that these situations apply to the patient, operator or service personnel.

How is Compliance Assessed?

Once you know you must comply with IEC 62304, how do you go about preparing for it? To start, know that compliance with this standard is defined as implementing all of the processes, activities and tasks identified in the standard in accordance with the software safety class. IEC 62304 itself does not prescribe a particular organizational structure or specific format for documentation, however. Compliance is determined by a review of all required documentation, including the risk management file.

[

]

The logical first step toward achieving compliance is to assess risk management as seen in IEC 60601-1. This includes: • Defining your operational and manufacturing processes • Documenting and assessing operational risks • Defining controls

Once your risk management file is complete, your next step is to review the requirements for IEC 62304. Make sure all required elements are defined and met in your procedures. Then, you’re ready to compile your documentation and submit it to your test lab.

The test lab will review your documentation against a test report form. They will comb through each step and verify you are including requirements in your procedures. If it has been decided that the software performs basic safety or essential per-

36 | RTC Magazine AUGUST 2015

formance for your device, the lab will conduct a product review.

The lab will only review the segments of your software development process that apply to basic safety and essential performance. When the review is c omplete and approved, you’ll receive a compliance report. If you’ve failed any areas, they will be noted, allowing you to make corrections. If you passed, you are able to move forward with your other regulatory commitments, such as obtaining a 510(k) for the US market or CE Marking for Europe.

What are Some Key Pitfalls to Look Out For?

Well-documented Processes: When meeting the requirements of IEC 62304, there are areas you would benefit from paying close attention to. The most critical is making sure you have clearly defined processes for your company and your software development lifecycle in particular. IEC 62304 identifies several expectations related to the information that should be included in your software development lifecycle procedures. If your processes are not well documented, you will have a lengthy, costly process ahead of you. Document management is essential for meeting compliance goals.

The SOUP Can: The next most difficult issue is SOUP, and we’re not talking about chowder or minestrone here. SOUP is an acronym for software of unknown provenance (or pedigree).

This is software you did not develop and have limited knowledge as to how it was created. Think of when an operating system, such as Windows, sends you updates and how your device’s software interacts with them.

While test labs don’t expect you to be able to explain the development process of your SOUP manufacturer, you will have to identify how your software relies on SOUP to function. You must identify if SOUP contributes to any unacceptable risk. In your software development process, you will need a plan for how you will handle the SOUP. It’s recommended that you build your software around SOUP in a way that enables your device to operate properly in the event that it (the SOUP) causes your software to fail. Unfortunately, many developers and device manufactures neglect to consider the impact of SOUP. Software Partitioning: The certifying body reviewing your device will only look at software partitioned around your Essential Performance and Basic Safety. However, if you’ve not taken the time to partition the code well, they will have to apply the principles of IEC 62304 to your entire code. Partitioning makes for a faster review process and minimizes your compliance risks. This is something to consider at the onset of your development process, as well as when your software undergoes changes over time.

Document Development: While software developers know what they are doing when it comes to writing code, that doesn’t mean they know what they are doing as it relates to medical devices. Documenting the software lifecycle as the code is created makes for a much smoother, more accurate process than trying to remember how the software was developed after the fact.

All too often, software developers are unaware of the scope of

documentation required for medical devices. This is particularly critical because over the last couple decades software development methodologies have evolved and many of the emerging methodologies place less emphasis on documentation and more emphasis on rapid development. So, the key to the software development process is the management of a software development methodology that creates the efficiency the company is looking for with the accountability that the IEC 62304 is expecting.

Version Control & Updates: The chance of your software requiring updates or version changes is pretty likely, and changes conducted after achieving compliance are often forgotten.

When you create your software development lifecycle process, be sure to include how these are defined including how you maintain your software in a validated state. Keep in mind that when changes are made to your software, additional testing may be necessary.

What about Non-Compliance?

If you get caught in any of the abovementioned pitfalls, you can expect that you will not be in compliance. You will either not receive a report at all, or will receive a report that says you failed somewhere in IEC 60601-1 or IEC 62304.

Because the standards are voluntary, you don’t necessarily have to make product changes if you fail. ¬You can choose to not comply. However, for each “fail,” you will be required to provide justification for each deviation. If you have valid justification, your device should still attain regulatory approval from the

TRACE 32

FDA or in the EU, although developing this justification can be a lengthy process in itself. The reality is these standards are here to stay, especially as software becomes an even more influential component in medical devices.

Based on our experience, when seeking CE Marking, notified bodies try to create a level of consistency with their reviews.

Thus, it has become more and more difficult to convince a notified body that you don’t have to comply with IEC 62304 when it is clear the role of software in your medical device contributes to essential performance. Attempting to take the path of “justification” will likely add more time to your process, and you may find yourself needing to complete IEC 62304 in the long run. Our recommendation is to avoid loopholes that don’t really exist and to go through the process of meeting IEC 62304 requirements. Not only will this be more effective for meeting commercialization goals, but it will prove you stand behind the safety of your device.

Method Sense Research Triangle Park, NC (919) 313-3960 www.methodsense.com Medical Equipment Compliance Associates Franklin, WI (847) 919-3512 www.60601-1.com

®

advertisement_arm-overview_7,375x3,375mm.indd 1

08.10.2014 11:11:16

RTC Magazine AUGUST 2015 | 37

PRODUCTS & TECHNOLOGY

Complete EtherCAT Solution offers ruggedness and motion function scalability

A new EtherCAT solution from Adlink Technology consists of the Talos-3012 IEC 61131-3-compliant automation controller and EPS Series time-deterministic I/O and motion control system. The combined solution provides time-deterministic control of automatic process, featuring high performance, easy development, rugged construction, intelligent management in ultra-small form factors, and minimal total cost of ownership. Integrated hardware and software elements, fast and easy API configuration, and Adlink’s Softmotion control kernel all drive speedy high performance for EtherCAT applications. Numerous ready-to-use features also speed development for next-generation smart factory environments.

The new Talos-3012 is a palm-size Ethernet for Control Automation Technology (EtherCAT) master controller based on the Intel Atom quad-core processor E3845 1.9GHz, with IEC-61131 compliant syntax. The Talos master controller allows easy migration of legacy PLC programming to a PC-based environment and Softmotion function blocks, with a single master controller able to connect up to 64 axes and 10,000 I/O points of control through a daisy-chained slave system. Superior computing power enables the Talos-3012 to perform simultaneous multitask processing for HMI, motion control, PLC, and gateway operations in industrial automation.

The modular design of Adlink’s EPS Series slave system empowers flexible channel density in a 110 x 130 x 105 mm package.

Incorporating the latest RISC processor and FPGA, Adlink EPS slave systems provide a wide variety of I/O modules, including DI/O, AI/O, thermal measurement, motion control, and EtherCAT communication modules, easily daisy-chained for system expansion with no compatibility issues.

Adlink’s EtherCAT solution has been verified for interoperability with a variety of EtherCAT servo drives and third party EtherCAT products, providing the flexibility to select only the requisite EtherCAT elements. With Adlink’s self-developed EtherCAT configuration utility, LinkMasterPro, the master system is able to automatically detect slave systems and I/O modules of any type and create corresponding XML files to complete configuration without any additional settings. Adlink EtherCAT master controllers can easily connect to existing or expanded third party slave systems for automatic recognition and configuration with no compatibility problems. Moreover, Adlink’s Softmotion utility provides a complete IEC 61131-3 edition environment supporting application-oriented functions and APIs for ease-of-use and shortened development time.

ADLINK Technology, San Jose, CA (408) 360-0200. www.adllinktech.cpm

38 | RTC Magazine AUGUST 2015

Integrated Analog Front-end Simplifies Sensor Interfaces

A new a new analog front end (AFE) with a field effect transistor (FET) input AFE and an integrated ADC driver is designed to interface directly with current mode sensors such as photo diodes and high output impedance voltage sensors. The ADA4530 from Analog Devices simplifies design and lowers power and PCB footprint by more than 50 percent compared to discrete implementations.

The ADA4350 features low-noise performance at low frequencies of 90nV/√Hz at 10 Hz and broadband noise of 5 nV/√Hz at 100 kHz to maximize the signal-to-noise ratio of the sensor output. Wide dynamic range measurement for small, sensitive signals such as photons or electrons is enabled with the inclusion of integrated gain switching. The on-chip programmability of the ADA4350 allows designers to select external, optimized feedback components. With one chip, a single-ended or differential sensor current or voltage signal can be transformed to a high-speed, low-noise, single-ended or differential-output voltage.

In analytical measurement applications, light may need to be monitored over many decades of intensity. This requires a variety of gain switching networks that often incorporate multiple external amplifiers and analog switches, which increases the potential for system errors. The ADA4350 integrates the switching networks and input amplifier to minimize leakage and allow the switching network to select up to six externally configurable feedback networks. In test and measurement systems, the same high measurement accuracy must be maintained across the gain levels as the user adjusts the input range of the instrument. For measuring a wider dynamic range, the ADA4350 is an ideal choice because of its high-impedance/low-Ib input amplifier and serial port-controlled switch network. The device also reduces PCB footprint while significantly increasing channel count without thermal density restrictions.

Analog Devices, Norwood, MA (781) 329-4700. www.analog.com

PRODUCTS & TECHNOLOGY

10 Gigabit Ethernet and 6 Gbit/s SAS/ SATA XMC Modules

Two new XMC modules provide integrators with a method of introducing 10 Gigabit Ethernet or 6 Gbit/s SAS/SATA ports into their existing or future systems. XMC modules are widely used to add functionality to a range of modular, open standards-based form factor boards including VPX, VME and CompactPCI within the defence, security, telecommunications, scientific and industrial markets.

For applications needing high-speed networking connectivity, XM530/x22 from Concurrent Technologies provides two 10 Gigabit Ethernet ports. This module supports rear I/O connectivity making it suitable for deployment in harsh environments where boards are typically mounted inside a rugged enclosure with all external connectivity through suitable grade connectors.

The conduction cooled version of XM 530/x22 is certified for operation between -40°C and +85°C, has a conformal coating for protection and has been tested to survive harsh levels of shock and vibration.

XM SA1/001 is an XMC module with the capability to connect to four external SAS or SATA 6 Gbit/s drives via a convenient front panel connector. A typical use would be to mount XM SA1/001 on a Concurrent Technologies’ processor board giving the combined solution the ability to connect to the latest, high speed drives without the need for any rear transition modules.

XM SA1/001 is expected to be used in a range of data recorders, database management and video security systems.

Concurrent Technologies, Woburn, MA (781) 933 5900. www.cct.co.uk

3U VPX System Quick Start Kit that Speeds System Development

A new family of rugged 3U VPX Lab System Quick Start Kits (QSK) accelerates the development of rugged deployed systems for defense and aerospace applications. The QSKs from Curtiss-Wright provide proven 3U VPX modules pre-configured in a 6-slot lab/demonstration chassis. Available in a wide range of configurations, these fully integrated COTS development platforms are designed to speed the development of VPX-based compute-intensive deployed applications.

The fully integrated QSKs feature Curtiss-Wright’s rugged 3U VPX modules, including Single Board Computers (SBC), FPGA solutions, Ethernet switches, graphics/video, and flexible I/O. Use of the QSKs enables system integrators to rapidly start their software development process. They reduce development cycles, increase test coverage, and speed the verification of a new system’s hardware performance, while it undergoes rigorous levels of simultaneous usage. As QSK configurations are pre-tested and pre-validated - development time and design risks are significantly reduced. Supported Curtiss-Wright 3U VPX modules can be provided in a QSK, enabling the system integrator to “mixand-match” the system configuration to meet their application’s specific requirements. Once the customer defines their desired configuration, delivery is within 4-8 weeks.

Curtiss-Wright QSK development systems can be configured with a wide range of 3U VPX modules. Advanced features such as Trusted COTS and Secure Routing are available on some modules, such as the Freescale-based SBC - VPX3-133 and Secure Router - VPX3-685. The QSK’s modular design supports a wide range of I/O, Intel® Core™ i7 and Freescale Power Architecture CPUs, and Linux and VxWorks operating environments.

Curtiss-Wright Defense Solutions, Ashburn, VA 703.779.7800. www.cwcdefense.com

RTC Magazine AUGUST 2015 | 39

PRODUCTS & TECHNOLOGY

PC/104-Plus SBCs with Intel E3800 Bay Trail Processor ARIES

A rugged, highly integrated PC/104-Plus single board computer is based on the Intel E3800 “Bay Trail” processor family. Highlights of the Aries SBC from Diamond Systems include excellent CPU performance / power consumption ratio, high feature density in a compact size, integrated high-quality data acquisition, versatile I/O expansion, conduction cooling for improved high temperature performance and rugged construction.

Designed in the PC/104-Plus form factor with wings (114 x 102 mm / 4.5 x 4.0 in), Aries’ full rectangular shape provides more coast line for I/O connectors, enabling an enhanced level of feature integration onto a single board its size. In this compact form factor, Aries includes a wide range of display capabilities, system I/O, plus data acquisition, meeting the majority of today’s connectivity requirements in a single board.

Available configurations include the E3845 1.91GHz quad core processor and the E3826 1.46GHz dual core processor, with choice of 2GB or 4GB soldered memory. Dual independent displays are supported, with connections for dual channel 24-bit LVDS LCD, VGA, DisplayPort, and HDMI. Available PC I/O includes 3 USB 2.0 ports (1 can operate as USB 3.0), 4 RS-232/422/485 ports with fully programmable configuration, dual Gigabit Ethernet, and a SATA port that supports both on-board SATA DOM and off-board SATA devices.

The optional integrated data acquisition includes 16 16-bit A/D channels with 250KHz sample rate, 4 16-bit D/A channels with voltage and current outputs, a programmable waveform generator, and 22 programmable digital I/O lines, all supported by Diamond’s free, industry-leading Universal Driver data acquisition programming library. An interactive, easy to use graphical control panel for Windows and Linux is provided to control all data acquisition features.

Aries’ built-in heat spreader efficiently removes heat from the SBC directly to the system enclosure and helps keep the interior cooler for improved reliability. The novel bottom-side mounting configuration of the heat spreader provides a convenient mounting system for the board. It also simplifies the installation of topside I/O expansion modules by eliminating interference or airflow problems that can occur with traditional heat sinks. A heat sink accessory option can be installed to use Aries in a traditional heat sink style installation.

The Aries SBC family was designed with rugged applications in mind. With an operating temperature of -40°C to +85°C, memory soldered on board, an integrated heat spreader thermal solution, 50% thicker PCB, and latching I/O connectors.

Diamond Systems, Mountain View, CA (650)810-2500. www.diamondsystems.com

40 | RTC Magazine AUGUST 2015

Interface Simplifies Sensor Conditioning with Integrated MUX, DAC, PGA and LDO A highly integrated sensor interface analog front end (AFE) provides calibration of sensor outputs. The XR10910 from Exar offers an onboard 16:1 differential multiplexer, offset correction DAC, programmable gain instrumentation amplifier and voltage reference. This AFE provides 14-bit signal path linearity and is designed to connect multiple bridge sensors to a microcontroller (MCU) or field-programmable gate array (FPGA) with an embedded ADC. The integrated, DAC provides offset calibration for any offset voltage generated by bridge sensors, improving overall system sensitivity and accuracy. An independent offset value can be set for each of the 16 differential inputs. The XR10910 allows the customer to select from eight fixed-gain settings (from 2V/V to 760V/V) to ensure the amplified sensor signal falls within the optimum input range of the downstream ADC. The integrated LDO provides a regulated voltage to power the sensors and is selectable between 3V and 2.65V for lower voltage compatibility. An I2C serial interface provides an easy way to control the XR10910’s many functions.

The XR10910 operates from 2.7V to 5V supplies and offers a wide digital supply range of 1.8V to 5V. It typically consumes 457µA of supply current and offers a sleep mode which reduces the supply current to only 45µA. The XR10910 is available in a RoHS compliant, green/halogen free, space-saving 6mm x 6mm QFN package. Pricing starts at $8.10 each for 1,000-piece quantities.

Exar, Fremonnt, CA (510) 668-7000. www.exar.com

Embedded Software Development Tools

Build smaller, faster, and more energy efficient software with SOMNIUM速 DRT SOMNIUM DRT Freescale Kinetis Edition is a complete C/C++ embedded software development environment for Freescale Kinetis MCUs.

SOMNIUM DRT is: Kinetis Design Studio Code Warrior Kinetis SDK Processor Expert

Compatible

No source code changes needed!

Enhanced Eclipse features

Best results Easy to use

Benchmarks show 15% faster 40% smaller 20% less energy

Available now

Windows and Linux versions

Download your free trial now from http://ow.ly/M9PrW RTC Magazine AUGUST 2015 | 41

ADVERTISER INDEX

Company...........................................................................Page................................................................................Website congatec, Inc....................................................................................................................... 4.............................................................................................................www.congatec.us Intelligent Systems Source...............................................................................4, 17, 25......................................................... www.intelligentsystemssource.com Lauterbach...........................................................................................................................37...................................................................................................www.lauterbach.com Novasom...............................................................................................................................33....................................................................................................... www.novasom.info One Stop Systems.......................................................................................................5, 12.................................................................................. www.onestopsystems.com Pentek.....................................................................................................................................44............................................................................................................www.pentek.com Portwell....................................................................................................................................21.......................................................................................................... www.portwell.com Somnium................................................................................................................................41......................................................................................................................ow.ly/M9PrW Super Micro Computers, Inc...................................................................................13.................................................................................................. www.supermicro.com Trenton Systems.............................................................................................................43..................................................................................... www.TrentonSystems.com WinSystems......................................................................................................................... 2................................................................................................ www.WinSystems.com Product Gallery.................................................................................................................32......................................................................................................................................................

RTC (Issn#1092-1524) magazine is published monthly at 905 Calle Amanecer, Ste. 150, San Clemente, CA 92673. Periodical postage paid at San Clemente and at additional mailing offices. POSTMASTER: Send address changes to The RTC Group, 905 Calle Amanecer, Ste. 150, San Clemente, CA 92673.

Here’s to Another 30 Years of Building Connections.

Connecting Engineers for Three Decades

RT

16

Connecting Engineers for Three Decades

January 19, 2016 Register today at www.rtecc.com

42 | RTC Magazine AUGUST 2015

30th 0

Santa Clara, CA

30th

ECC

2

Got Tough Software Radio Design Challenges?

Unleash The New Virtex-7 Onyx Boards!

Pentek’s OnyxŽ Virtex-7 FPGA boards deliver unprecedented levels of performance in wideband communications, SIGINT, radar and beamforming. These high-speed, multichannel modules include: ‡ ‡ ‡ ‡ ‡ ‡ ‡ ‡ ‡ ‡ ‡

A/D sampling rates from 10 MHz to 3.6 GHz D/A sampling rates up to 1.25 GHz Multi-bandwidth DUCs & DDCs Gen3 PCIe with peak speeds to 8 GB/sec 4 GB SDRAM for capture & delay Intelligent chaining DMA engines Multichannel, multiboard synchronization Ž ReadyFlow Board Support Libraries Ž GateFlow FPGA Design Kit & Installed IP Ž GateXpress FPGA - PCIe configuration manager OpenVPX, AMC, XMC, PCIe, cPCI, rugged, conduction cooled ‡ Pre-configured development system for PCIe ‡ Complete documentation & lifetime support

With more than twice the resources of previous Virtex generations plus advanced power reduction techniques, the Virtex-7 family delivers the industry’s most advanced FPGA technology.

Call 201-818-5900 or go to www.pentek.com/go/rtconyx for your FREE online Putting FPGAs to Work in Software Radio Handbook and Onyx product catalog.

3HQWHN ,QF 2QH 3DUN :D\ 8SSHU 6DGGOH 5LYHU 1- ‡ 3KRQH ‡ )D[ ‡ H PDLO LQIR#SHQWHN FRP ‡ ZZZ SHQWHN FRP :RUOGZLGH 'LVWULEXWLRQ 6XSSRUW &RS\ULJKW ‹ 3HQWHN ,QF 3HQWHN 2Q\[ 5HDG\)ORZ *DWH)ORZ *DWH;SUHVV DUH WUDGHPDUNV RI 3HQWHN ,QF 2WKHU WUDGHPDUNV DUH SURSHUWLHV RI WKHLU UHVSHFWLYH RZQHUV