Page 1

The magazine of record for the embedded computing industry

April 2012


The Internet OF THINGS

M2M Systems Spread Intelligence Hypervisors Pull the Best out of Multicore Fine Tuning a Hybrid Architecture

An RTC Group Publication


fully-assembled turnkey solutions Run, drive, or fly your Simulink design in real time, using Rapid Prototyping or Hardware-in the-Loop simulations on low-cost PC-based hardware. xPC Target provides a library of device drivers, a real-time kernel, and an interface for monitoring, parameter tuning, and data logging. It supports a full range of standard IO modules, protocols, and target computers.

m ®

Find it at datasheet video example trial request


Simulink and xPC Target™


©2010 The MathWorks, Inc.



The Internet OF THINGS

54 Embedded Real-time Monitoring and Control Platform Based on NI LabVIEW

56 Xeon Quad-Core 6U VPX SBC with 10Gig Ethernet Switch


59 Single PrPMC/XMC Supports Three Freescale QorIQ Processor Families



6Editorial Meeting Regulatory Demands—Is There Help from the World of IT? 8

Industry Insider Latest Developments in the Embedded Marketplace

12 & Technology 52Products Newest Embedded Technology Used by Industry Leaders Small Form Factor Forum ARM Yourself

EDITOR’S REPORT Wireless Video Networking

Technology in Context


Hybrid Architectures

Developing for Multicore Systems

Microcontrollers 18 Wireless Combine Low-Power Processing and RF Connectivity in a Hybrid Architecture

Nisha Ganwani, Silicon Laboratories

TECHNOLOGY CONNECTED Devices Rule—The Internet of Things

Firewalls—Protecting the Internet of Things 22 Embedded Alan Grau, Icon Labs

to Inter-OS 32Approaches Communication and Messaging for Multicore – Multi OS Systems Gerd Lammers, Real Time Systems

the Potential of 38Harnessing Multicore Processors for RealTime Applications Chris Grujon, TenAsys

TECHNOLOGY DEPLOYED Machine-to-Machine Systems

Weakness and Accelerating Machine-to-Machine Enumeration—Tracing the Path to System Development with 28 Common 42 Industrial Security Embedded Software Chris Tapp, LDRA

HD Video Streaming: Struggling toward a Standard 14Wireless Solution Tom Williams

Subscriptions and Additional Content Avaliable at

Kurt Hochanadel, Eurotech and Brian Vezza, Wind River

Processing Units and Multicore Programming 46Accelerated Innovation at the Cusp of Machine-to-Machine

Cameron Swen, AMD and John Havener, Texas Multicore



APRIL 2012 Publisher PRESIDENT John Reardon,




Editorial EDITOR-IN-CHIEF Tom Williams, CONTRIBUTING EDITORS Colin McCracken and Paul Rosenfeld MANAGING EDITOR/ASSOCIATE PUBLISHER Sandra Sillion, COPY EDITOR Rochelle Cohn





Advertising/Web Advertising


3/30/12 2:04:38 PM



Billing Cindy Muir, (949) 226-2021

To Contact RTC magazine: HOME OFFICE The RTC Group, 905 Calle Amanecer, Suite 250, San Clemente, CA 92673 Phone: (949) 226-2000 Fax: (949) 226-2050, Editorial Office Tom Williams, Editor-in-Chief 1669 Nelson Road, No. 2, Scotts Valley, CA 95066 Phone: (831) 335-1509


No matter how you shake it, bake it, or configure it, everyone knows the reputation, value and endurance of Phoenix solid state and rotating disk VME products. Leading the way in storage technology for decades, Phoenix keeps you on the leading edge with very cool products! Published by The RTC Group Copyright 2010, 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.

We Put the State of Art to Workk t 714-283-4800 PHOENIX INTERNATIONAL IS AS 9100/ISO 9001: 2008 CERTIFIED


Untitled-6 1


9/9/11 6:36:24 PM

Modular Computing Solutions for Embedded Applications

High-Performance Application-Optimized X8DA6, C7SIM-Q, C7Q67

Compact Form Factor Short-Depth SuperServer® 5015A-EHF-D525 SuperServer® 5017C-LF

Small Form Factor X7SPE-H(F)-D525, X7SPA-H(F)-D525 X9SCV Series

Supports Intel® Xeon®, Core® i7/i5/i3 and Atom™ Processors Energy Efficient, Low Power and Fanless Solutions High Performance, Scalable Systems High-Density, Compact Form Factors Open Standard and Multi-OS Support Ruggedized and Industrial Grade Chassis 7- Year Life Cycle Support

Versatile, Whisper Quiet and Highly Configurable SuperServer® 5037C-i/T

Industrial PC Short-Depth SuperServer® 6046T-TUF © 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 US and other countries. All other brands and names are the property of their respective owners.

SMCI-20120221- 1

t t t t t t t


Tom Williams Editor-in-Chief

Meeting Regulatory Demands—Is There Help from the World of IT?


nce upon a time in the early days of embedded systems, developers were tinkerers working on relatively small and dedicated projects—a braking controller, a vending machine, various factory automation projects. Now don’t get me wrong. These were not trivial; they had performance requirements, deterministic behavior demands, power constraints and much more. By “tinkerers” I really mean that developers tended to go about their tasks in what was once called a “chaotic” approach. That is, without a clearly defined process or discipline. It was not so long ago, maybe ten years since I actually saw the statistics, when about 50 percent of projects still used their own in-house RTOS or even RTOSs developed from scratch on their own. As the complexity and size of projects increased, tools were developed to meet the emerging challenges—source level debuggers, trace tools, logic analyzers (remember them?), event analyzers, dynamic and static analysis tools, multithreaded debuggers, multicore debuggers. The list is very long and much genius and much sweat were dedicated to keeping developers abreast of their challenges. Still, it seems that most of the effort was, quite understandably, reactive. Problems and challenges emerged and they were faced and mostly solved. Only seldom did an isolated voice cry out from the wilderness the word “process.” And even less often was heard the word “documentation” in regard to the word “process.” That is now changing. Software and systems developed for regulated application areas like aerospace, medical, automotive and for any electrical safety-critical applications, are required to conform to international standards. These include IEC 62304 for medical devices, IEC 61508 for safety-critical electrical devices, DO178 for the aerospace arena and many more. These standards do not simply require testing and certification of the finished system. They also specify and require documentation of the development process; they often provide specific requirements for development tools including design tools, testing and debugging tools and configuration management tools to name a few. All this must be complied with and documented as well.



It turns out that a number of practices and tools used in the IT world are being adapted for use by the embedded community to help meet growing regulatory and certification requirements. Additionally, some of the embedded practices known in the realm of DO178 are becoming familiar with developers engaged in other projects that nonetheless must be submitted to regulation and certification requirements equally as demanding. One of the latter of these is the preparation of software components such as RTOSs that are guaranteed “certifiable.” Only the final application can be certified by a regulator body, so it is not possible to purchase a “certified” RTOS, for example. What is possible is to have an RTOS that has already been part of a certified application/system. That means that with proper documentation accompanying the RTOS, the vendor can guarantee the customer that this part of his system will pass the certification process with no further effort on his part. Increasingly, since such components come with the required documentation, that documentation includes the development process and thus helps the customer step into the world and to continue following that process in his own project. While embedded developers are familiar with requirements tracing, a more formal process of requirements engineering is beginning to appear. This incorporates requirements definition and management with a defined requirements specification structure, tracking through the code development process based on the high-level components of a system. Other types of tools, such as static and dynamic analysis, are being adapted to the needs of embedded development and to the process compliance and documentation demands of the standards and regulatory bodies. Those companies contemplating entering this world would do well to check out not only the standards and process compliance demands ahead of time, but also what tools and “certifiable” components are available to help get started. Waiting until you are deep into a project and then deciding to apply such tools and practices is a recipe for disaster. Be sure to visit our web site at for links from selected stories to additional information.


INSIDER APRIL 2012 New Embedded Consortium for Standardization Management A new embedded consortium has been founded as announced at the Embedded World tradeshow recently held in Nuremberg, Germany. Named the Standardization Group for Embedded Technologies (SGET), its founding members include Advantech, congatec, Data Modul, Kontron, MSC, SECO, as well as the publishing houses WEKA Fachmedien and Vogel Business Media. The group has stated its commitment to developing and maintaining embedded computing specifications that will be applicable worldwide, in order to promote new embedded technology standardizations meeting the requirements of the markets. The stated purpose of the SGET is to create a globally operating, manufacturer-independent consortium, which will be in a position to react to the accelerated speed of technological progress and changing market demands in a fast and flexible manner. The founding members of the SGET say they are confident that more than one hundred vendors worldwide will join the group within a year—underlining the great need for improvement in market orientation and fast specification implementation. Other companies and institutions working in the area of embedded computing are invited to join the new Standardization Group for Embedded Technologies. In particular, the SGET welcomes embedded computer manufacturers on board- and system-level, research and educational institutions as well as embedded system integrators, OEM solution providers and industrial end-users. “Different manufacturer interests on the component level slow down standardization work on embedded module standards. This is why we are pleased that the SGET consortium of board and module manufacturers has created rules that offer more scope for innovation and that put the interests of the users first,” states Wolfgang Eisenbarth, MSC. “From the new Standardization Group for Embedded Technologies we expect major input in the area of SFF processors, as not only Computer-on-Modules, but also motherboards and SBCs, i.e., 3.5” or I/O boards of embedded systems, are in need of standardization. Until now, we have lacked a powerful consortium that addresses these issues permanently and efficiently,” states Carsten Rebmann, Advantech. “Beyond the issue of form factors, we have to consider the standardization of individual interface implementations, for example via IP stacks. This is where I expect the SGET to play a pioneering role. Ultimately, this subject will also need standardization,” says Markus Mahl of Data Modul. The Standardization Group for Embedded Technologies, which will be founded as a registered association according to German law, will form the first working groups for the Computer-on-Module specifications Qseven and a dedicated ARM module specification. Under the roof of SGET further groups are welcome to develop specifications. For further information visit

Real-Time Systems and Kontron Sign Global Distribution Agreement for RTS Hypervisor

Real-Time Systems GmbH has announced the signing of a global distribution agreement for the RTS Hypervisor with Kontron. Customers may now purchase application-ready platforms, i.e., embedded hardware preconfigured with the RTS Hypervisor and operating system licenses, directly from a single source. Getting support for realtime virtualization directly from their hardware vendor, customers may drastically shorten their own development cycles and benefit



from cost reduction. The agreement solidifies the direction of Real-Time Systems to align itself globally with leading turnkey solution providers to further the adoption of its hard real-time virtualization solution. By utilizing the RTS Hypervisor, a traditional embedded system typically consisting of an industrial PC and additional hardware for real-time tasks, can now be replaced by a single hardware platform. Executing, for example, Microsoft Windows safely in parallel to a real-time operating system on just one board based on Intel processors, reduces the bill of materials while increasing

reliability and reducing power consumption. This solution is particularly useful for products in the industrial, medical or transportation markets where many customers rely on a Real-Time Operating System (RTOS) for time- or mission-critical functions while using a different OS for other tasks, such as running a human machine interface (HMI). Because the RTS solution does not depend on a host OS, operating systems can start in any sequence, reboot independently and never harm each other. “Embedded system configurations with real-time hypervisors can be complex and sometimes not just a plug & play scenario. Consequently, customers need support for hardware and software ideally from a single source,” said Werner Ressle, director of Software & Software Services of Kontron AG. “The cooperation with RealTime Systems enables us to provide customers with a convenient out-of-the-box experience and they can now receive our embedded hardware platforms bundled with a pre-configured RTS Hypervisor including operating system licenses of their choice.”

Operating System #2 Operating System #1 Linux Linux Windows Windows VxWorks VxWorks QNX QNX Shared Memory ... ... Virtual Network CPU Core #1 Memory I/O

Real-Time Hypervisor

CPU Core #2 Memory I/O

Multi-Core & Multi-OS Kontron Platform

LabView to Enter Wider Market?

An interesting observation made at the recent Embedded World show in Nuremberg, Germany, suggested a possibly interesting development regarding the LabView graphical development environment that is a flagship product of National Instruments. In introducing their new single-board family of RIO controller projects, National quite naturally demon-

strated that applications could be developed with LabView. The new line of controllers includes a real-time CPU along with a Xilinx Spartan 6 FPGA. This is not a revolutionay development since earlier RIO products have also included a processor/FPGA combination. However, on the table next to the demo units was a sign that indicated the future of the family would be moving to the Xilinx Zynq 7000 family of devices. The

Zynq family integrates a dualcore ARM Cortex-A9 along with an FPGA fabric on a single die. One of the challenges of this class of devices is that it brings together two separate disciplines—that of C programming for the CPU section and that of FPGA design for the fabric. Providing a tool that can intuitively bridge these two realms has been the subject of a great deal of effort on the part of arch-rival vendors Altera and Xilinx. A RIO controller with a

Zynq 7000 would also quite naturally be programmed using LabView. In fact, at the same show, a German partner, S.E.A., was also announcing a single-board controller based on RIO technology—which also, naturally, is programmed using LabView. But could the horse get out of the barn? If you can program a RIO device based on Zynq 7000, that means that any other system centered on the Zynq 7000 should

684.91 (5.50%) This data is as of April 10, 2012. To follow the RTEC10 Index in real time, visit COMPANY






Adlink Technology












Concurrent Computer

















Interphase Corporation

















Elma Electronic

Mercury Computer Systems Performance Technologies






PLX Technology






RadiSys Corporation






RTEC10 involves time sensitive information and currency conversions to determine the current value. All values converted to USD. Please note that these values are subject to certain delays and inaccuracies. Do not use for buying or selling of securities. RTEC10 is sponsored by VDC research

Market Intelligence & Strategy Consulting for the Embedded Community Complimentary Embedded Market Data Available at: RTC MAGAZINE APRIL 2012



be able to be configured and programmed using LabView as well. If that is the case, it could easily mean that Xilinx has a ready-made cross-discipline tool out in the world that is already understood by a large number of developers. That would appear to give it a significant advantage in the market. If it happens, you read it here first.

Shipments of Dual-Core Smartphones Reached 60 Million Units Worldwide in 2011

Preliminary data from Berg Insight show that sales of highend smartphones equipped with dual-core application processors reached 60 million units worldwide in 2011. The first smartphones with dual-core processors were unveiled at the beginning of 2011 with sales starting in February 2011. One year later, at the upcoming Mobile World Congress in Barcelona, several handset vendors are expected to announce their first smartphones with quad-core processors. As quadcore processors gradually find their way into high-end devices, adoption of dual-core processors will accelerate in the mid-range smartphone segment. Total smartphone sales grew 59 percent to 470 million units worldwide in 2011. High-end smartphones with unsubsidised retail prices above €400 and low-cost devices priced at around €100 contributed to most of the growth in the smartphone category in 2011. Sales of high-end devices doubled from about 75 million units in 2010 to an estimated 150 million units in 2011. Sales of low-cost smartphones increased from approximately 10 million units in 2010 to 70 million units in 2011. In terms of unit sales for the full year, Samsung became the leading smartphone vendor with 20.2 percent market share, just ahead of Apple with 19.8 percent market share. Nokia was the only major vendor that experienced a



decline in unit shipments in 2011 and slipped to third place with 16.4 percent market share. While its shipments increased slightly, RIM also continued to lose market share in 2011, but managed to stay ahead of HTC. In terms of revenues, Apple remained the clear leader with a value market share of 38 percent in 2011.

Report on Graphics Shipments Reflect Rise of Tablets

Jon Peddie Research (JPR) has announced estimated graphics chip shipments and suppliers’ market share for Q4’11. The quarter in general: • This quarter, Intel celebrated its eighth quarter of shipping its Embedded Processor Graphics CPU-EPG, a multi-function design that combines a graphics processor and CPU in the same package. Intel’s desktop EPG shipments had a very strong double digit growth while Notebooks dropped double digits. Combined with a decrease in overall IGP chipsets, Intel came in for the quarter with a -12.3% drop from Q3. • A MD had huge 44.8% desktop double digit growth in its HPU shipments, and even good growth in their desktop IGPs. However, like Intel, its overall quarter results were down due to declining notebook sales. AMD’s overall quarter to quarter results showed a -3.4% drop. • Year to year this quarter Intel gained about 7% market share, AMD gained 2.6%, and Nvidia slipped -7% in the overall market partially due to the company withdrawing from the integrated segments. • The quarter’s change in total graphics chip shipments from last quarter decreased 10.4%, above the ten-year average of 0.83%. A little over 124 million graphics chips shipped, down from 138.5 million units last quarter, and up from 114 million units this quarter a year ago. • Discrete GPUs declined almost 12% from the last quarter and

were down almost 3.5% from last year for the same quarter. • Almost 93.5 million PCs shipped worldwide this quarter, an increase of 1.8% compared to last quarter (based on an average of reports from Dataquest, IDC and HSI).

Upcoming Industry Events April 24, 2012 Real-Time & Embedded Computing Conference Milwaukee, WI

April 24, 2012

Broadcom Completes Acquisition of NetLogic Microsystems, Inc.

Broadcom Corporation has announced that it has completed its $3.7 billion acquisition of NetLogic Microsystems, a leader in high-performance intelligent semiconductor solutions for next generation networks. The combination enables Broadcom to deliver seamlessly integrated network infrastructure platforms to its customers, reducing both timeto-market and development costs. The addition of NetLogic Microsystems also extends Broadcom’s infrastructure portfolio with key technologies, including multicore embedded processor and knowledge-based processor solutions, both critical enablers of the next generation infrastructure buildout. “The NetLogic acquisition is a significant milestone in Broadcom’s strategy to extend its communications infrastructure leadership and take advantage of the explosive growth in mobile and video traffic and the rise of cloud computing,” said Broadcom CEO Scott McGregor. “This acquisition adds a high-margin, highgrowth business that strongly increases the addressable market of our infrastructure and networking business.” Ron Jankov, former president and CEO of NetLogic Microsystems, joins Broadcom as a Senior Vice President and General Manager, reporting to Rajiv Ramaswami, Broadcom’s Executive Vice President and General Manager, Infrastructure & Networking Group. NetLogic Microsystems’ 700-plus employees will immediately become part of Broadcom.

Medical Electronic Device Solutions Conference Milwaukee, WI

April 26, 2012 Real-Time & Embedded Computing Conference Minneapolis, MN

April 26, 2012 Medical Electronic Device Solutions Conference Minneapolis, MN

May 15, 2012 Real-Time & Embedded Computing Conference Boston, MA

May 15, 2012 Medical Electronic Device Solutions Conference Boston, MA

May 17, 2012 Real-Time & Embedded Computing Conference Mahwah, NJ

If your company produces any type of industry event, you can get your event listed by contacting: This is a FREE industry-wide listing.


X Marks the Spot. At Extreme Engineering Solutions, you’ll find products that are designed from the ground up to handle any environment. From boards to integrated systems, our embedded solutions are rugged and reliable–ensuring your application is a success, no matter how extreme the conditions. Embedded solutions that always hit the mark. That’s the Extreme way.

Extreme Engineering Solutions 608.833.1155



Colin McCracken & Paul Rosenfeld

ARM Yourself


f, like most SFF board suppliers, you’ve spent your career building x86-based embedded PCs, you must feel challenged by the announcements coming out of Embedded World regarding new standards and SBC/COM (computer-on-module) products using ARM architecture processors. If you feel you need to join the crowd to stay competitive, it’s going to be a little bit like walking on the surface of Mars. Here’s a primer for some of the things you need to think about. Let’s start with the processor itself. In x86 land, you simply go to Intel, AMD, VIA or others to choose from dozens of processors that all work pretty much the same. Follow their reference design and in 90-120 days or so you have an embedded PC that boots Windows. No fuss, no muss. In ARM country, you can go to dozens of semiconductor suppliers who have licensed the ARM core, stacked a set of peripherals around the core, and sell a fully functional chip. The gotcha here is the set of peripherals chosen. Chip suppliers pick the peripherals to target a specific, high volume market, such as cell phones, tablets or infotainment. Most likely, this won’t be the same set of I/O that you will need to address medical devices, UAVs or industrial controllers. You can fish for the closest model and add other necessary I/O on the board, or, dare we say it, go the custom route yourself. You, too, can license the ARM core and create your own custom ARM-based chip. This has a number of advantages: You control the life cycle; you control the I/O set; and down the road you are simply buying an ASIC, so you’ll save significantly in product cost. And in the “high” volume, low margin COM market, saving a few bucks a board can make a difference in winning some volume business. Creating your own custom ARM processor requires you to have access to a good chip designer. These guys are few and far between—the real divas of the semiconductor industry. After you find one, you need to spend a few hundred thousand dollars on chip design tools. And tools are really important here. After



you understand the $1M+ NRE cost for masks and such, you’ll want to be absolutely positively sure that your design is perfect before you commit to production. And yes, it’s OK to start with an FPGA with an ARM core, but if you want to save all those bucks we talked about earlier to be competitive, you’ll need to go the ASIC route eventually. Let’s say you’ve surmounted all these obstacles and now have an ARM-based CPU ready to slap on a board. What’s it gonna run? In x86 land, you have this thing called a BIOS, an extraordinarily elaborate set of x86 assembly language code, refined over almost 30 years, to initialize and test virtually any x86 system. It even does clever things like scanning each bus to determine what I/O devices might be installed (one reason boot takes so long). If you followed your chip supplier’s reference design, your BIOS should be easy to adapt. Unfortunately, in RISC country, there is no BIOS. Sure, you’ll get some kind of “boot loader” designed to get the chip up and running (unless you did a custom chip—then guess what—you own that responsibility lock, stock and barrel). But the boot loader doesn’t know anything about what kind of I/O you put on the board, so you need to adapt the boot loader for every single configuration you support. ARM assembly language, of course. Of course, your BIOS guy knows just how to do this. Did we mention the (expensive) new software tools? Next step: Pick an OS. Windows, Linux, Android all pretty much run on x86 systems. And if you gave up and used an offthe-shelf ARM processor, you might very well be able to get a customized Linux or Android. Windows 8—don’t hold your breath. And if you rolled your own chip—hahahaha. So now you have a board and an OS that boots. Let’s plug in a PC/104-Express Analog I/O card. There’s just a simple matter of an Android driver for your custom ARM processor. Doesn’t everybody have one of these? You’ve got to be kidding me. OK. Enough fun for today. Now you understand why it has taken almost twenty years for a serious ARM-based COM in the SFF board market.






;WUHPH 3&,









The Embedded Products Source ZZZZGOV\VWHPVFRP



editor’s report

ogy seems to be racing forward challenging the processing capability to keep up. In the consumer realm, TV displays are getting bigger—up to 70 and 84 inches, and new display technologies are coming online such as organic LEDs (OLED), which are still climbing the cost curve but which promise to deliver more brilliant displays with much thinner panels. OLED displays can even be made flexible. Then, of course, there are the smart displays that support touch interfaces for touch, motion sensing and gesture recognition. Tablet users can be seen sitting at their laptops (unless they’re brand new) stroking at the screen and wondering why there is no response. The new Apple iPad, for instance, has a 9.7-inch display with a resolution of 2048 x 1539. But speaking of expectations, everyone now expects wireless connectivity and they are going to expect it of HD displays along with everything else. The industry has been responding with a number of solutions, but it is going to take a few more years to arrive at a unified solution. What will it take to bring streaming wireless HD video into a mainstream technology

Wireless Video Networking

Wireless HD Video Streaming: Struggling toward a Standard Solution Wireless video streaming is nothing new and various solutions for streaming HD video have been out in niche markets for a while. But getting wireless HD into the mainstream of wireless networking—and that means the world of Wi-Fi—is yet to be but coming on strong. by Tom Williams, Editor-in-Chief


he world of high definition video took its time getting firmly established in the consumer space in the form of HDTV, which has since become practically so ubiquitous that we lose sight of how long it actually took to get established in the market. Now that it is established, it has raised expectations about all of our interactions with video and graphics— from smartphones, to tablets to kiosks to industrial HMI displays—everything. The embedded space is no exception and processors have been turning out with ever more powerful on-chip graphics processing units to meet those expectations. All the latest Atom processors from Intel have on-chip graphics engines. The Fusion G series from AMD uses generalpurpose graphic processors (GPGUs) based on the graphics technology developed by ATI, which was later acquired by AMD. Graphics specialist Nvidia has integrated its GPU technology with multicore ARM processor architectures in its Tegra series, which is being widely adapted into mobile tablets. The list goes on. At the same time, display technol-



Common Upper MAC (Management) Multi-band operation (WiGig / .11ad)

BB & Lower MAC (802.11b / a / g / n / ac)

2.4 GHz

5 GHz

BB & Lower MAC (WiGig / .11ad)

60 GHz

Figure 1 The WiGig architecture enables tri-band communications.

editor’s report

for mobile wireless networks? Not surprisingly, there are efforts underway. The question is what do they actually solve and which will ultimately be successful? There are a number of technologies that have homed in on the 60 GHz range for wireless video streaming and have attracted the attention of a number of large players. In addition, there are some other players that are still successfully holding shares of the market. One such player is the Wireless Home Digital Interface (WHDI), originated by the Israeli firm Amimon and supported to some extent by Hitachi, LG, Samsung and others. WHDI can stream uncompressed 1080p video over a wireless channel to any display device equipped with a receiver. It supports data rates up to about 3 Gbit/s in a 40 MHz channel. It is basically a pointto-point, not a networking technology. Another variant is Wireless HD, which can be thought of as a wireless HDMI. It is based on a 7 GHz channel also in the 60 GHz range and allows for either compressed or uncompressed HD video. Developed by start-up SiBeam (which was bought by Silicon Image), it has attracted the interest of companies like Samsung, Sony and Toshiba. While the initial versions had a data rate of about 4 Gbit/s, the underlying technology is thought to be scalable to about 25 Gbit/s for possible additional resolution and color depth. One disadvantage, according to Brian O’Rourke of analysis firm In-Stat, is that its power consumption limits it to linepowered devices, so it is currently not a candidate for mobile applications. It does, however, include a beam-forming technology to avoid interference and to extend the range beyond about 10 meters. One more technology that appears to have had the opportunity to be adapted and further developed, but which is still on the market on its own merits, is Ultra Wide Band (UWB). UWB came out of the effort to develop a wireless USB— an effort that was eventually abandoned. While there is no wireless USB, there are a number of UWB devices based on chips by companies like Alereon, which go into products such as wireless docking stations and video links that can stream at 720p from a dongle on a laptop to a receiver connected to a set via an HDMI cable.

The push for UWB, however, appears to have been subsumed by efforts of the Wi-Fi Alliance to develop a multi-gigabit wireless technology that ended up known

as WiGig or 802.11ad. It also operates in the 60 GHz range and will eventually integrate into existing 2.4 GHz and 5 GHz Wi-Fi networks via new devices equipped

One-to-one configuration

P2P Client: Printer

P2P Group Owner: Phone

One-to-many configuration

P2P Client: TV

Legacy Client: Printer

P2P Group Owner: Laptop

P2P Client: Camera

Concurrent Wi-Fi AP and peer-to-peer connection

P2P Client: TV

Wi-Fi AP

P2P Group Owner: Laptop

Legacy Client: Printer P2P Client: Camera

Figure 2 The three configuration modes made possible by Wi-Fi Certified Direct Connect. RTC MAGAZINE APRIL 2012


editor’s report

with tri-band radios (Figure 1). Since it is based on 802.11 and has a way of integrating into existing networks, it has attracted the support of several semiconductor companies that are expected to announce silicon in the near future. WiGig is, of course, not in and of itself a video streaming technology, but is the underlying network that can carry the video data. For that, additional software and hardware is required—such as having HD codecs on either end. Intel independently implemented a set of software on top of its silicon to allow video streaming from laptop to HDTV. It called the technology “My Wi-Fi.” Subsequently, it was renamed WiDi and built into a number of laptops so the basic video streaming could be done without another dongle sticking out of the computer. Later, Intel handed the WiDi technology over to the Wi-Fi Alliance and it is now about to release a Wi-Fi Alliance specification that will be known as Wi-Fi Display. This will truly allow HD video streaming between 802.11ab networked devices that are connected using Wi-Fi Direct. If this seems a bit involved, it is actually a simplification. Where previous HD streaming technologies involved a single peer-to-peer wireless connection (often with cables connecting receivers to displays), Wireless Direct allows connecting an enabled device in a one-to-one, a one-to-many or a concurrent Wi-Fi AP and peer-to-peer connection without necessarily having to be at a Wi-Fi hot spot (Figure 2). Wi-Fi Display runs as an application on top of Wi-Fi Direct and can then stream video to or from other devices in the configuration equipped for WiGig plus Wi-Fi Display. It will run on 802.11ad solutions but not on the lower frequency connections. In other words, devices will need the 60 GHz radio and be able to support the 5 GHz channels for a 720p or 1080p video stream. Wi-Fi Display does appear to be the wave of the future for wireless HD video streaming due to the broad and broadening industry support for Wi-Fi in the first place, and increasingly for WiGig. Adding Wi-Fi Display will take more silicon, and WiGig is also today available at a premium price. In-Stat’s Brian O’Rourke notes that


Untitled-3 1


2/3/12 2:11:13 PM

although the WiGig 802.11ad silicon is just beginning to appear and at a significantly higher price than chips for the earlier technologies, it is expected to come down in price to approximate equal cost by about 2015. The question is, will that price drop be driven by consumer acceptance or by the needs of industrial and commercial systems? Time will tell, but there is a good possibility that the perceived value of high definition, interactive wireless streaming video may have more immediate impact from the industrial side where devices and systems could gain immediate improved utility by incorporating it. Of course, given this blurring between what was once clearly consumer and what was clearly industrial, things might happen even quicker. Managers who want to interact with their factory data from their tablets might drive the acceptance in consumer devices faster than expected. One thing that seems pretty certain: now that it’s possible, it will happen. Advanced Micro Devices Sunnyvale, CA. (408) 749-4000. []. Alereon Austin, TX. (512) 345-4200. []. In-Stat Port Washington, NY. (858) 652-4012. []. Intel Santa Clara, CA. (408) 765-8080. []. Amimon Santa Clara, CA. (650) 641-3191. []. Silicon Image Sunnyvale, CA. (408) 616-4000. [].

Technology in

context Hybrid Architectures

Wireless Microcontrollers Combine Low-Power Processing and RF Connectivity in a Hybrid Architecture The ability to configure a hybrid MCU makes possible a variety of strategies to optimize RF connectivity while saving power and extending battery life in mobile connected devices. by Nisha Ganwani, Silicon Laboratories


icrocontrollers (MCUs) are indispensible in the world today. Their applications range from simple alarm clocks and coffee makers to complex electronics systems that control automobiles and airplanes. In the broad spectrum of devices driven by MCUs, one encounters a plethora of battery-operated products that pose the additional requirement of low power operation and in some cases wireless connectivity. Prime examples of low power embedded systems requiring an RF link include applications in home and building automation, wireless security, smart utility metering, asset management and portable medical systems. To address the requirements of these applications, wireless MCUs have emerged in recent years as an embedded processing solution with a hybrid architecture that integrates an MCU core and wireless transceiver into a single device. This single-chip solution offers several advantages including reductions in BOM cost, component count, board space, power consumption and overall design complexity.

Reducing Power Consumption

One of the most important design considerations for battery-operated systems is reducing power consumption, which increases



the battery discharge time and extends the operational life of a system. RF transceivers, however, require significant power to form data packets and communicate over long distances. A wireless MCU can implement features in a hybrid architecture to reduce overall power consumption without compromising RF performance. Thanks to continuous improvements in process technology, embedded processors and RF transceivers are now readily available in device geometries scaling to 180nm and even smaller. The operating voltage of the internal circuits scales with the geometry, dropping to 1.8V and even lower. However, batteries continue to have a terminal voltage of 3.3V or even 3.6V. A common design methodology to support these terminal voltages is to integrate a low drop-out voltage regulator (LDO) on-chip. This structure takes the battery input and regulates the internal voltage of the chip to something lower, i.e. 1.8V or less. However, using a linear regulator to step a 3.6V input down to a 1.8V output has at best 50 percent conversion efficiency. This efficiency gets worse as the output voltage decreases. More advanced embedded controllers have integrated switching regulators with much higher efficiency than their LDO counterparts. In many cases, these devices

can have switching efficiencies exceeding 85 percent. This high efficiency has the effect of reducing the total current sourced from the battery and extending battery life. Figure 1 illustrates the benefits of applying an advanced MCU with a DC/DC converter to a battery-powered wireless application. In this example, we greatly reduce the battery drain due to the transceiver: Idd(battery) =

Idd(xcvr) x 1.8V

3.6V x 85% efficiency

Idd(battery) = 62.5% Idd(xcvr)

In other words, using a DC/DC converter reduces the current drain from the battery for use by the radio to approximately 62.5 percent compared to using a simple LDO. This approach has the net effect of reducing the radio power consumption by the same amount. Another power saving strategy can come in the form of a data packet processing engine (DPPE). In traditional wireless systems, several CPU processing steps are required to prepare the suitable RF packets for communication. For example, a common requirement is to encrypt the data to secure transmission over-theair. The Advanced Encryption Standard (AES) is a universal specification for encrypting electronic data. The strength of

technology in context

the AES algorithm depends on the number of bits used for encryption, i.e., 128, 192 or 256 bits. Traditionally, an increase in the number of bits translates to an increase in the power used by the CPU for AES processing.

Many RF protocols require a cyclic redundancy check (CRC) for detecting errors during transmission. Additionally, certain wireless protocols, such as the wireless M-Bus stack used for metering in Europe, require encoding the bit stream to

19mA @ 3.6 V

eliminate the DC component (e.g., a string of 0s and 1s). This ensures frequent signal transitions directly proportional to the clock rate and helps in clock recovery. An advanced MCU design may include hardware blocks for each of these

19mA @ 1.8 V

19mA @ 1.8 V

19mA @ 1.8 V LDO


5mA @ 3.6 V


14.5mA @ 3.6 V

5mA @ 1.8 V

5mA @ 1.8 V (for rest of chip)

(for rest of chip) LDO


+ HEAT (wasted energy)

Traditional MCU

Total draw from the battery

Total draw from the battery


14.5mA @ 3.6 V

24mA @ 3.6 V Figure 1

Comparison of Switching Efficiencies between Traditional and Advanced MCUs.

707 Âľsec




with DPPE

132 Âľsec 2.3mA

time Figure 2 The benefits of using a DPPE can result in significant power savings. RTC MAGAZINE APRIL 2012


technology in context










PCA Timer 0


10-bit 300 ksps ADC

Timer 1 Timer 2

Voltage Comparators

Timer 3 CRC





Port 0 SPI 1 Port 2 Port 3 Port 4 Port 5 Port 6 Port 7 DPPE







8448/4352 B SRAM POR


EZRadioPRO (240-960 MHz) LNA






Figure 3 Example of Wireless MCU Hybrid Architecture.

functions, along with a Direct Memory Access (DMA) peripheral to perform a complete radio transaction without CPU intervention. A complete DPPE in hardware can accelerate packet processing by up to five times while consuming half as much current as operations performed in software. The result is power savings of up to 10x for radio packet generation (Figure 2). In certain wireless sensor applications, particularly utility meters, a device called a register encoder records the flow of natural gas or water. In a metering system, this flow can appear electrically as a series of switch closure events or pulses. In a traditional system, the CPU must wake up and sample the state of an I/O pin to determine if the switch is open or closed. If it is a physical reed switch, additional CPU bandwidth is needed to de-bounce the switch and manage pull-up resistors to guarantee it is a valid pulse as well as to minimize the current drain through the closed switch. Performing this function in



software, even in the most optimized system, can consume well over 1 µA. A better approach is to integrate a dedicated input capture timer on the MCU that can operate autonomously while the CPU is inactive. This technique has a number of advantages over a software-based approach. For example, the switch closures can be accumulated in a hardware register requiring little if any CPU intervention. Additionally, features such as switch de-bounce, pull-up resistor management and self-calibration can be integrated directly in the hardware. With two timer inputs, quadrature decode functionality can be supported to determine flow direction. This arrangement provides the capability of backflow detection as well as an anti-tamper provision. A dedicated low-power input capture timer can consume less than 400 nA at 3.6V even with a sampling rate as high as 500 Hz. This is a significant improvement over performing this function

in software and reduces the wireless meter’s overall power consumption. An ultra-low-power MCU is designed to have extremely low standby currents with a real-time clock (RTC) running. Standby currents for a transceiver are quite excessive in comparison. When integrating the MCU and the transceiver in a hybrid architecture, the latter device can be configured to go into complete shut-down mode when not in use, thereby saving power. In this scenario, the MCU’s RTC block can be configured to wake up the radio as required for operation. In a wireless MCU, a serial interface (such as SPI or 3-wire mode) can be internally connected between the MCU and a transceiver. The hard-wired interface provides access to the radio’s peripheral registers from software executing on the MCU core. This approach accelerates system design and firmware development. A highly integrated chip with fewer external pins reduces layout complexity as well as de-

technology in context

creases package cost and BOM count, enabling a more cost-effective solution than is possible using discrete components.

Multichip Wireless MCU Module vs. Monolithic CMOS Chip

Building a monolithic CMOS chip that integrates the MCU and radio operations on a single die poses several challenges. A considerable design challenge is finding an optimum process that is suitable for both the flash memory and processing functions of an MCU as well as RF operation. A single-chip solution may drive an IC designer to pick a process optimized for one of the functions while taking a cost and/or performance hit on the other. Another significant challenge is the impact of the processor’s digital blocks on the transceiver’s RF performance. In a multichip module (MCM) approach, the impact of noise from the MCU’s digital circuits on the RF frequency spectrum is minimized. Physical distances ensure that the MCU’s clock frequencies do not cause spurs and/or blocked channels on the radio. The impact

Untitled-13 1

on critical RF specifications such as sensitivity and range is also minimized, ensuring interoperability without compromising radio performance. A MCM approach provides numerous benefits for a hybrid wireless MCU solution, including lower power consumption, reduced cost, complexity and BOM count—all with continued exceptional RF performance. There are many critical design specifications for a battery-operated wireless embedded system including RF frequency, range of communication, type of modulation, software stack implementation and required operational life of the system between battery replacements. Silicon Labs’ EZRadioPRO sub-GHz transceivers, for example, provide RF output power of +20 dBm, an RF sensitivity of -121 dBm and an RF link budget of >140 dBm. These transceivers support a range of modulations, e.g. On-Off Keying (OOK), Frequency Shift Keying (FSK) and Gaussian Frequency Shift Keying (GFSK). Silicon Labs’ ultra-low-power C8051F96x MCU products have been designed from the ground up to seamlessly

interoperate with EZRadioPRO sub-GHz transceivers. These MCU products have flash sizes up to 128K and RAM sizes up to 8K, and can implement standards-based software stacks such as wireless M-Bus and 6LoWPAN, as well as proprietary RF protocols for wireless communications. These low-power MCUs have been designed to provide ultra-low-power consumption in active, sleep and deep sleep modes. The Si102x/Si103x wireless MCU family (Figure 3) pairs the ultra-low-power C8051F96x MCU core with the EZRadioPRO transceiver into a single-package solution that addresses the requirements of low-power embedded systems that use an RF link. By reducing overall system power, these hybrid devices enable developers to either reduce the size/cost of batteries or increase battery life while delivering end products with industry-leading RF performance. Silicon Laboratories Austin, TX. (512) 416-8500. [].


2/3/12 3:00:00 PM RTC MAGAZINE APRIL 2012


connected Devices Rule—The Internet of Things

Embedded Firewalls—Protecting the Internet of Things Embedded devices are far from immune to hacking and denial of service attacks. Protecting them requires measures that are appropriate to their characteristics and can be integrated into their communication environments. by Alan Grau, Icon Labs


ecently there have been a number of well documented attacks on embedded devices ranging from ploration hacked vehicle anti-theft and control sysyour goal tems to hijacked printers that sent copies k directly of documents to the hacker’s computer. age, the source. Many embedded devices include passology, word protected logins and encrypted proF lo ma d products teur tocols such as SSH or SSL, but this is not H ac sufficient. If these methods were enough, ker Au s we would not be reading about security t o m breaches in the media. ated H acking Firewall technology is the foundation Dron for network security in home and cores porate networks, yet firewalls are virtunies providing allysolutions absent now in embedded systems. This is ion into products, technologies and companies. your goaldeis to research the latest Dropped based on assumptions thatWhether embedded ation Engineer, or jump to a company's technical page, the goal of Get Connected is to put you vices are not attractive targets to hackers, Packets you require for whatever type of technology, devices and productsembedded you are searching for. are not vulnerable to Trusted attacks, or authentication and encryption provide adequate protection for embedded devices. These assumptions are no longer valid; the number and sophistication of attacks against embedded devices continues to rise and greater security measures are needed. Attacks on embedded devices can be broadly categorized as being either hacking attacks or denial of service


ke rs

s DoS Attack

Packet Floods



cks ta


Do S

l na o i e ss


D ing ck


Trusted Sender


Pr ofe ssi on

rH ac

al Hack ers

s od

Tru sted Sen d


et ck Pa


d ate Autom

u ate Am


e rs

ck Ha

Embedded Firewall

Processed Packets

End of Article

Figure 1

Get Connected

with companies mentioned in this article.


An embedded firewall filters packets at the IP layer in the protocol stack. This allows attacks to be detected and blocked before a higher layer connection is established.


Get Connected with companies mentioned in this article.





Extend your system’s I/O cards ‘outside-the-box’ over cable to a chassis containing additional card slots Basic to Smart expansion options for practically any environment For test and measurement, medical imaging, surveillance, aerospace and defense, telecommunications, data acquisition, high performance computing, and audio/video production congurations Rock solid expansion solution provider since 1987




Copyright © 2012 Mission Technology Group, Inc. dba Magma

RoHS Compliant

ISO9001:2008 Cer tified

Magma is a trademark of Mission Technology Group, Inc. PCI Express is a registered trademarks of PCI-SIG. Thunderbolt and the Thunderbolt logo are trademarks of Intel Corporation in the U.S. and/or other countries.

technology connected

Embedded Firewall Components Static Rules

COM Express™ MSC CXB-6S Intel Core ®


– 2nd Generation

ƒ Single, dual and quad core solutions ƒ Intel® HD Graphics 2000 / 3000 ƒ Intel® QM67 or HM65 Platform Controller Hub ƒ Up to 16GB DDR3 SDRAM, dual channel ƒ Four SATA-300 interfaces ƒ One PATA interface ƒ LVDS (24 Bit, dual channel) and VGA ƒ Resolution up to 2560 x 1600 ƒ Five PCI Express™ x1 lanes ƒ Eight USB 2.0 interfaces


ƒ COM Express Type 2 125 mm x 95 mm (4.92 x 3.74”)


MSC Embedded Inc. direct: (650) 616 4068


Firewall Callback Routines Figure 2

ƒ Multiple i5, i7 and Celeron processor options available

Untitled-6 1


MSC Embedded offers a large variety of COM products in COM ExpressTM, QsevenTM and ETX®. Our COM products are scalable, easy to install and powerful to enable long living industrial applications with an upgrade path to future needs.

Threshold Database



Embedding Excellence

Connection State Table

3/1/12 9:52:51 AM

Callback routines isolate the filtering engine, making the firewall easier to integrate with the TCP/IP stack and to port between embedded operating systems.

(DoS) attacks. Hacking attacks attempt to gain control of the embedded device via a web, CLI or other control interface. Once a hacker has gained access to the device they can steal data, reprogram or reconfigure the device, or even disable the device. Hackers often use dictionary attacks to exploit weak or default passwords, or in cases of insider attacks, use stolen passwords. DoS attacks attempt to disable or disrupt the functioning of the device. These are often protocol-based attacks such as packet floods, TCP SYN-floods, or buffer overrun attacks. While authentication and encryption play an important role in embedded device security, they do little or nothing to protect against dictionary attacks, insider attacks with stolen passwords, or protocol-based DoS attacks.

Firewalls for Embedded Devices

Embedded systems require a firewall that is small, fast and provides packet filtering that is appropriate for protecting an embedded device. As with operating systems, desktop firewalls do not meet the needs of embedded devices. Windowsbased firewalls are slow, big and not easily ported to embedded devices. They also perform virus scanning and other filtering that is not relevant for embedded devices. Most open source firewalls use Linux iptables for packet filtering. These firewalls are only useful for embedded systems using Linux as most other embedded OSs do not support Linux iptables. To provide protection for embedded systems, a firewall must be able to block attacks that authentication and encryption cannot. The firewall must also be scalable

technology connected

Filtering Engine Received Packet From Network Match? Yes

Log Event Drop Packet

Dynamic Filtering Engine

as they are received, blocking unwanted packets, thereby protecting against packet floods, login attempts by hackers, DoS attacks and other cyber-attacks. An embedded firewall uses one or more filtering methods to enforce policies. Common filtering methods are rulesbased filtering, Stateful Packet Inspection (SPI) and threshold-based filtering. Rules- or policy-based filtering works by comparing each packet to a set of rules to

determine if the packet should be blocked or allowed. All decisions are made based on the information in the packet. SPI maintains information on the state of each connection and uses that information to make filtering decisions. Threshold-based keeps statistics on packets received and monitors for threshold crossings to detect packet floods and (DoS) attacks. Rules-based filtering enforces policies by blocking unused protocols, clos-

No Match?


Log Event Drop Packet

Static Filtering Engine No Match?


Log Event Drop Packet

Threshold Filtering Engine No

Normal Packet Processing Figure 3 As packets are received by the embedded device, they are passed to the firewall for filtering. Packets are either dropped by the firewall before they are processed by the device, or passed up the network stack for normal processing.

to a wide range of devices, from small 8-bit systems running a minimal or no OS, to a sophisticated multicore system running a commercial RTOS. An embedded firewall works by enforcing a set of rules or policies that govern to whom the device can talk, what protocols and ports can be used, and who can initiate communication with the device. Policies can be thought of as creating a safe zone in which the embedded device operates. The firewall filters packets Untitled-2 1


4/9/12 9:47:24 AM RTC MAGAZINE APRIL 2012

technology connected

ing unused ports and enforcing whitelists or blacklists of IP addresses. For some devices, rules-based filtering is all that is required. Consider a utility meter that collects monthly electrical usage and reports data back to a central server. Such a device only communicates with a small set of known IP addresses. A rules-based firewall configured with policies providing a trusted list of IP addresses and blocking unused ports and protocols provides strong protection for this type of device. Packets sent by a non-trusted IP address are blocked, isolating the device from attack. Other devices require more open communication. A printer, for example, would typically need to accept print jobs from any IP address. Rules-based filtering can still be used to block unused ports and protocols, but SPI or threshold-based filtering may be added for additional protection. SPI provides protection against packets received with invalid TCP state information, a common Internet-based attack. SPI can also be used to create a “lockdown mode” in which connections must originate from the embedded device, or support dynamic port allocation. Threshold-based filtering is complex and requires significant system processing time and memory, but provides a powerful tool for detecting packet floods and DoS attacks.

Firewall Components

Rules-based filtering, also called static filtering, uses a filtering engine to evaluate each packet against the configured rules or policies. Rules specify the filtering type (whitelist vs. blacklist), the filtering field (IP address, protocol number, port value, etc.), and the values to be matched. A whitelist is a list of allowed values. If a packet is received and the value is on the list, it is allowed. If not, it is blocked. A blacklist is the opposite—any values on the list are blocked and all other values are allowed. For example, a rule set could look like the following: Rule 1, WHITELIST, IP source address, { –} Rule 2, WHITELIST, IP protocol, {1,2,6,17} Rule 3, BLACKLIST, UDP destination port, {600-799} Rule 4, BLACKLIST, TCP destination port, {600-799}


Untitled-11 1


3/30/12 2:21:16 PM

When a packet is received, the filtering engine first checks Rule 1. If the source IP address is not in the range of -, the firewall blocks the packet. Otherwise the filtering engine proceeds to the next rule. The second rule specifies that IP protocols of ICMP, IGMP, TCP and UDP (protocol numbers 1, 2, 6 and 17) are allowed. Packets received with any other protocol value are blocked, even those from a whitelisted IP address. The third and fourth rules specify that UDP and TCP ports 600-799 are blacklisted; UDP or TCP packets received on these ports are blocked. Stateful packet inspection (SPI), also called dynamic filtering, maintains information on the state of each connection and uses that information to make filtering decisions. For connection-oriented protocols, such as TCP, the protocol connection state is used. In contrast, for connectionless protocols such as UDP, the connection state is inferred as either CLOSED or ESTABLISHED based on how recently a packet was sent or received for a given IP address and UDP port. SPI requires a state table that is updated as connections are established, proceeds through the connection states, and closed. As packets are received, the firewall validates them based on the current state of the connection, and then updates the state table. SPI is protocol specific and therefore the SPI engine must implement a state transition and state validation routine for each supported protocol. For devices requiring a high level of security, SPI can be used to create a lockdown mode in which all communication must initiate with the device. Lockdown mode can be augmented with a trusted senders list that specifies a set of IP addresses that can initiate communication with the device. In lockdown mode, the device can initiate communication with any IP address, but only the trusted senders can initiate communication to the device. The SPI engine determines if received packets are associated with an existing connection or from a trusted sender. All other packets are blocked. Threshold-based filtering monitors system traffic, keeping statistics on packets received, to detect packet floods. If the

technology connected

number of packets received from a specific IP address during a time interval exceeds the configured high-water threshold, future packets from that IP address are blocked. Once the traffic from that IP address falls below the configured low-water threshold, the filter is disabled and packets from that IP address are again allowed. Implementing threshold-based filtering requires a database to maintain packet counts and a monitoring module to detect and enforce threshold crossings. These three function can be integrated into a firewall and thus into the TCP/IP stack (Figure 2).

details. The firewall may also provide notifications of attacks and threshold crossing events. A firewall provides a simple and effective layer of security for embedded devices. When implementing a firewall, engineers must first consider the policies the firewall needs to enforce. The types of policies supported dictate the types of filtering that are required. Engineers must also choose between buying a commer-

Icon Laboratories West Des Moines, IA. (888) 235-3443. [].


Integration with the TCP/IP Stack

There are several options for integrating the firewall with the communication stack. One is to integrate the firewall at the Ethernet driver layer, allowing filtering by MAC addresses. The drawback of this approach is that it adds processing to the device driver, possibly increasing interrupt latency. For most applications, filtering can be performed at the IP layer (Figure 3). By filtering low in the stack, unwanted packets can be dropped before the embedded device utilizes additional processing resources. When filtering at the IP layer, the firewall can first perform filtering based on IP packet header information, then on protocol-specific criteria such as TCP port, UDP port, etc. Another approach is performing filtering at multiple layers in the communication stack. Filtering by IP address and protocol could be performed at the IP layer, while filtering for TCP and UPD ports could be performed at the TCP and UDP layer. This simplifies the filtering at the IP layer and can be used to provide custom filtering for a specific protocol or application. In addition to providing filtering, there are a number of important requirements for an embedded firewall. It is crucial to provide users with a flexible and easy to use, yet secure interface for configuring firewall policies. If the firewall configuration can be compromised, the firewall can be reconfigured and bypassed, or even disabled. The firewall should also provide statistics and logging capability to allow security audits to determine if the device has been attacked, what IP address the attack originated from and other relevant

cial embedded firewall, porting an open source firewall, or building a firewall solution from scratch. Regardless of the approach, it is critical to include a firewall to protect the devices making up the Internet of Things.



FEATURES ‹ Intel Atom N455 @ 1.66 GHz ‹ 1 GB @ 667 MHz DDR3 ‹ Electrical per VITA-46 3U VPX ‹ Electrical per VITA-65 OpenVPX ‹ BP Connectors per VITA-57 FMC ‹ 4 Slot + Storage ‹ Conduction Cooled with Fins ‹ Dimensions (W x H x D) 4.88� x 4.12� x 4.38� ‹ 4.5 lbs (average) ‹ Conduction Cooled ‹ Operating Temberature 40° C to + 71° C ‹ +28 VDC (18 to 36 VDC) ‹ MIL-STD-810G, MIL-STD-461F TARGET APPLICATIONS ‹ Mission Computing ‹ Payload Control ‹ Real Time Control ‹ Data Recording ‹ Small Storage and Communications Systems ‹ Mobile Robotics


FEATURES ‹ Intel Atom N455 @ 1.66 GHz ‹ 1 GB @ 667 MHz DDR3 ‹ VITA-74 Derivative ‹ I/O Through Front Panel Connector ‹ Dimensions (H x W x D) 89 mm X 21 mm X 90 mm ‹ Conduction Cooled ‹ Operating Temperature -40° C to + 71° C ‹ MIL-STD-810G, MIL-STD-461F TARGET APPLICATIONS ‹ Real Time Control ‹ Data Recorders ‹ Small Storage and Communications Systems ‹ Mobile Robotics





Â&#x2039;;:)*P?<=7?:PUNSL)VHYK*VTW\[LY^P[O0U[LS*VYL;4P*7< Â&#x2039;;06*?<=7??4*74**HYYPLY4VK\SL Â&#x2039;;:*?<=7?7VY[:(;(:(:9(0+4VK\SL^P[O74*?4* Â&#x2039;;:4?<=7?:(;(:(:4HZZ:[VYHNL+YP]L4VK\SL Â&#x2039;;.(?<=7?.YHWOPJZ7YVJLZZVY^P[O(4+, .7< (510) 252-0870

Untitled-8 1

Š 2012 Themis Computer. All rights reserved. Themis Computer, Themis and the Themis logo are trademarks or registered trademarks of Themis Computer. All other trademarks are the property of their respective owners.


10:20:22 AM RTC MAGAZINE 3/6/12 APRIL 2012

ploration your goal k directly age, the source. ology, d products


connected Devices Ruleâ&#x20AC;&#x201D;The Internet of Things

Common Weakness and Enumerationâ&#x20AC;&#x201D;Tracing the Path to Industrial Security Many industrial control systems have evolved from being stand-alone to Internet-connected without giving due consideration to the security issues. The CWE software assurance initiative can be the basis for a development and testing discipline to build in security from the start. by Chris Tapp, LDRA


ost reduction is the primary driver for connecting critical infrastrucSecurity ture components to the Internet. Performance Safety Utility meter reading and the control and monitoring of remote plants traditionally required significant numbers System Readability Availability of feet on the ground. Many companies Quality and municipalities now put systems in place to reduce these costs by allowing these tasks to be carried out remotely. Portability Maintainability Robust cyber nies providing solutions now security is required to Reliability ensure that the systems Whether are adequately ion into products, technologies and companies. your goal is to research the latest ation Engineer, or jump to a from company's technical the goal of Get protected those whopage, may wish to Connected is to put you you require for whatever type of technology, Figure 1 cause harm. and products you are searching for. Many organizations, including the System quality is determined by Department of Homeland Security, have many attributes, including those raised concerns that criminal and terror relating to security. organizations are attempting to take control of critical infrastructure. Numerous using authentication credentials previincidents show that these concerns are ously obtained when the system manumore than theoretical. Recent reports facturerâ&#x20AC;&#x2122;s security was compromised. on the Internet claim that on November The hackers appear to have commanded 8th 2011, a pump used by a U.S. water the pump to start and stop repeatedly, utility plant was destroyed after hackers causing it to overheat. gained access to the SCADA system by A second incident is also under investigation after screen shots were Get Connected posted to the Internet on November with companies mentioned in this article. 18th showing what purports to be the user interface for a control system used

End of Article


APRIL 2012 RTC MAGAZINE Get Connected with companies mentioned in this article.

within the Water and Sewer Department of the City of South Houston, Texas. The poster claims to have proof that other industrial systems have also been compromised. As security-related issues are now being given greater importance, contracts increasingly include clauses related to security. Many require proof that the vulnerabilities identified by the Common Weakness and Enumeration (CWE) are not present at system delivery. Notably, the security of industrial control systems was often not considered when they were initially designed because the first versions were stand-alone replacements for traditional analog processes. They then evolved through locally networked SCADA devices to become fully connected to the Internet. The assumption that no one would be interested in gaining access to such systems led to very little being done to enhance the security of the devices. Even though newer systems are designed with connectivity in mind, it is common even today for industrial control systems to use hard-coded user names and passwords as the only attempt to provide

technology connected

security. Worse still, many of these credentials are shared across all the installations for a particular range of devices, making it very easy for a generic piece of malware to spread and gain access to a wide range of plants. However, securing the passwords of the devices only gives a minor improvement in overall security, as the underlying communications channels of the devices expose a significant attack surface. It is often assumed that the data passed over these channels would be produced by a trusted system and that per-device data validation is either unnecessary or could be simplified. This assumption fails when a third party (e.g., a hacker or malware) is able to manipulate or generate data passed over a channel. For example, the signals for a Polish tram system had been designed so that the drivers could control them by using a remote control. The system was considered to be secure as the hardware was not commercially available and no thought was given to the injection of commands from any other external source, resulting in a decision to use encrypted data without any validation. In 2008, a teenager modified a different remote control unit so that he could change the signals. His actions lead to the derailing of at least four trams, resulting in twelve people being injured.


According to research by the National Institute of Security Technology (NIST), 64% of software vulnerabilities stem from programming errors. The Common Weakness and Enumeration (CWE) is a strategic software assurance initiative run by the MITRE Corporation under a U.S. Federal grant, co-sponsored by the National Cyber Security Division of the U.S. Department of Homeland Security. It lists those programming errors that lead to security failures within systems with the aim of improving the software assurance and review processes used to ensure connected devices are secure. Enumeration of the vulnerabilities in this way allows coding standards to be defined to target



them so that they can be eliminated during development. The CWE database contains information on security weaknesses that have been proven to lead to exploitable vulnerabilities. These weaknesses could be at the infrastructure level (e.g., a poorly configured network and/or security appliance), policy and procedure level (e.g., sharing usernames and/or passwords) or coding level (e.g. failing to validate data). The CWE database holds information on actual exploits, not theoretical, and so only captures those coding weaknesses that have been exploited in the field. CWE should be used within the development environment to ensure that known vulnerabilities are not introduced into the software. Many of the issues that have been identified are amenable to automatic detection by static and/or dynamic checking tools. To obtain maximum benefit, such tools should be used as early as possible in the development process, as trying to add security in at the last minute is very unlikely to succeed. The adoption of other tool-enforced security standards, such as the CERT-C Secure Coding Standard, complements this objective and enhances the security characteristics even further.

To prevent the introduction of security vulnerabilities, a development team needs to have a common understanding of the security goals and approaches to be taken during development. This should include an assessment of the security risks and the establishment of the secure coding practices that are to be used. The risk assessment determines the quantitative and qualitative security risk for the various system components in relation to a concrete situation and recognized threat. This information is used to reduce security vulnerabilities in the areas that will have a high impact if their security is breached. The assessment results in the development of a set of security control and mitigation strategies that will form the core of the system security requirements. These security requirements become part of the same development process used for all other requirements. Detailed at the outset, the security requirements are then traced through the design, coding and testing stages in order to ensure fulfillment of the initial requirements. These linkages form documentation that demonstrates how the final system meets the security objectives laid down at the beginning.

Ensuring System Security

Coding Standards

Many security vulnerabilities can be traced to coding errors or architecture flaws and are generally hard and/ or expensive to fix once a system has been deployed. Unfortunately, many developers are only interested in the development and testing of core application functionality. Security is rarely tested with the same rigor. The security of a system needs to be considered as one of the most important attributes of a system. Security requirements need to be included up front in the system design and implemented during normal development if the final system is to be secure. Figure 1 illustrates the attributes associated with system quality. By focusing on these measures at all phases of the software development lifecycle, developers can help eliminate known weaknesses.

CWE is a â&#x20AC;&#x153;do not get caught byâ&#x20AC;? list and is not an actual coding standard. However, coding standards can be used to ensure that the CWE issues are not present in a project. Compliance with these standards helps to ensure that project security goals are achieved, especially as many security issues result directly from the coding errors that they target. Additionally, compliance with a recognized standard helps to demonstrate that contractual security obligations have been met. Compliance with the chosen coding standard, or standards, should be a formal process (ideally tool-assisted, but manual is also possible) as it is virtually impossible for a programming team to follow all the rules and guidelines throughout the entire code-base. Adherence to the standards is a useful metric to apply when determining code quality.

technology connected

Static and dynamic testing should be considered essential practices. Static analysis tools confirming CWE compatibility systematically enforce the standard across all code. Dynamic analysis assures that the code does not contain run time errors, including those that could be exploited to compromise security.


contained within CWE and choosing to develop and test software with the aid of CWE-aware tools represents a significant step forward. Companies that incorporate CWE and embark on a process of continual improvement help ensure that only dependable, trustworthy, extensible and secure systems are released for production.

LDRA Wirral, UK. +44 0151 649 9300. [].

If a claim is to be made that a system complies with a security standard like CWE, then evidence must be provided to support that claim. Traceability makes it possible to show which test result(s) prove that a particular security requirement has been met. Tracing from requirements to the design, verification plan and the resulting test artifacts can be used to support such a claim. Figure 2 illustrates how requirements can be mapped to the design specification, verification plan, source code and verification reports. Such graphical representation makes it easy for developers to immediately spot unnecessary functionality (code with no requirement), unimplemented requirements and failed or missing test cases. Adoption of a security standard that targets the CWE vulnerabilities allows security quality attributes to be specified for a project. Incorporation of security attributes into the system requirements means that they can then be measured and verified before a product is put into service, significantly reducing the potential for in-the-field exploitation of latent security vulnerabilities and the elimination of any associated mitigation costs. The use of a qualified and well-integrated application lifecycle management (ALM) tool to automate testing, collation of process artifacts and requirement traceability dramatically reduces the resources needed to produce the documentation required by certification bodies. It minimizes the workload for developers and allows managers to efficiently track progress. With the increase of attacks on industrial security, itâ&#x20AC;&#x2122;s clear that application developers need to rethink their assumptions. Leveraging the knowledge Untitled-19 1


2/3/12 3:55:28 PM RTC MAGAZINE APRIL 2012

technology in


Developing for Multicore Systems

Approaches to Inter-OS Communication and Messaging for Multicore – Multi OS Systems Realizing the potential of multicore processors involves more than simply running multiple RTOSs. Additional functions to manage communications control and messaging are needed and must be kept transparent to the operations. by Gerd Lammers, Real Time Systems


he fact that embedded hypervisors can be used to run multiple operating systems independently in parallel and under real-time constraints on multicore platforms has become public knowledge. And quite a few of the market leaders have already consolidated their distributed old designs into cost-saving platforms using embedded virtualization. As operating systems don’t seem to be jacks of all trades, different requirements like those for real-time performance, strong graphics capabilities or efficient data processing and connectivity are typically solved by using different operating systems. Instead of still running these different operating systems each on separate hardware, developers now use embedded hypervisors to consolidate multiple platforms into a less expensive single-board solution with one or more multicore CPUs. Such a design allows the parallel execution of multiple operating systems without them influencing one another. Since the deployed operating systems don’t know of each other’s existence, the integration effort can be kept to a minimum. Now imagine taking the first steps toward a modern, optimized system architecture: writing a concept and defining



which operating systems should be used, which CPU(s) to be assigned to which OS, and specifying which devices should be assigned to the individual virtual machines for their exclusive use. Maybe the concept even includes details like the present cache topology of the available CPUs and an intelligent decision about which OSs should have their own, exclusive cache available to them and which OSs may share caches with others. In a user friendly, easy to configure hypervisor, like the RTS Hypervisor, the implementation is a walk in the park. Little changes made to the supplied example configuration file will already allow the system to start in the intended setup. Once all the software components have been defined and all the hardware resources are partitioned, the details of hypervisors come into play: How will these cleanly separated, partitioned, hard and software modules work as a simple to use, integrated system that can be turned into a product for a user? For quite some time most hypervisors have offered a virtual network, providing an easy means for communication as if the separate operating systems were running on separate hardware, connected with a physi-

cal network cable. Especially if porting an existing solution of multiple hardware boards to a modern design, this functionality is often used to reduce porting effort. After these initial steps, unfortunately, only a few of the advantages of a multicore multi-OS design have been made use of: Power requirement (heat) and the bill of materials have been lowered, size and weight have been reduced, and the mean time between failure (MTBF) has been increased due to the reduced number of hardware components. The real advantages that would have required additional hardware on a distributed system can be obtained when digging deeper into the capabilities of some embedded hypervisors. When running multiple operating systems on a single piece of hardware, a very simple but powerful method of communication now becomes available: shared memory. Two big advantages of shared memory over the virtual network are fast data exchange along with random access to data. To set up shared memory, only a name and the size of the memory need to be configured and assigned to the guest operating systems. Since the Intel multicore architecture provides cache co-

tech in systems

herence for RAM, this is also an attractive functionality to replace expensive DPRAM (Dual-Ported RAM) implementations. There are many good use cases for the use of shared memory. These include configuration settings that are generated at runtime, commonly used data bases, measurement data collected by one operating system but processed by another OS, or working with multiple operating systems on images that have been acquired by a camera (Figure 1). But shared memory is very useful for more than data exchange. In addition, the ability to pre-initialize a shared memory section with files at boot time can be very advantageous. In a common scenario, by running a traditional real-time operating system (RTOS) in parallel with Windows as a user interface, you may actually kill two birds with one stone. A file created by a user may, depending on the application at hand, contain project settings or even applications. This file can then be accessible by the RTOS via a pre-initialized shared memory section. If the hypervisor setting is such that the RTOS boots before a Windows boot, the RTOS may start its execution before Windows has even finished its boot. As a second advantage a user may, without changing the RTOS image or without even knowing about its

Operating System for Data Acquisition Acquire data and put to 1st Shared Memory Partition. Send signal when done.

Operating System for Data Processing

Data available in SHM 1

Acquire data and put to 2nd Shared Memory Partition. Send signal when done.

Release data Data available in SHM 2

Switch back to 1st Shared Memory Partition and start over again.

Release data

Wait for data Process data from 1st Shared Memory Partition. Send signal when ready. Wait for data Process data from 2nd Shared Memory Partition. Send signal when ready.

Figure 1 Wireless industrial M2M networks face challenges in terms of connectivity and security as well as the ability of the wireless gateway to recalculate and manage the network topology as the number of nodes continues to grow.

existence, change the functionality of the RTOS simply by providing different content in the shared memory section. An essential feature of most real-time operating systems is an event system. Programming a multicore multi-OS system with embedded virtualization can provide yet one more major advantage over old distributed hardware solutions. The RTS Hypervisor provides the ability to share events between operating systems, even if

the installed operating systems are heterogeneous, e.g., Windows 7 running alongside an RTOS with a POSIX API like QNX Neutrino, Linux or VxWorks. These events may then be used just like semaphores for signaling resource usage, release of data in a shared memory section, to show that an application has started or even for fast data communication. In the RTS Hypervisor such an event system has been implemented using inter processor

Quad-Core Processor Core Logical CPU

Core Logical CPU


Logical CPU

Core Logical CPU


Logical CPU

Core Logical CPU


Logical CPU

Logical CPU


Figure 2 On the Intel Architecture, a modern Hypervisor can send IPIs (Inter Processor Interrupts) to and from any CPU to signal events in real time.














Sharpen your engineering skills

with Intel® at RTECC Real-Time & Embedded Computing Conference May 15, 2012 Boston, MA

Morning & Afternoon Sessions Plus Hands-On Lab

Seating Is Limited

Intel® Boot Loader Development Kit (BLDK) for Embedded Systems

Complete Agenda Available Online

Start with an overview of BLDK and complete your training with a Hands-on Lab In the hands-on lab you will learn how to: • Create a Boot Loader Development Kit (BLDK) Project • Build a Firmware Image Using Windows Hosted Tools • Boot an E6XX Systems to UEFI Shell & Explore the Various Options • Update E6XX Firmware from UEFI Shell

Register today at

See what’s on the schedule at

May 15, 2012 2012 Locations 5/15 RTECC Boston 8/21 RTECC Irvine

Attendees who complete the class will be entered in a drawing for an Intel® Atom™ Processor E6xx System (a $300 value)

… … … … … … … … …

Tech In Systems


Untitled-4 1

Safety-critical and Redundant CompactPCI® and VMEbus

Certifiable up to SIL 4 or DAL-A with safe operating system N Safe and reliable through triple redundancy N Simple software integration through lockstep architecture N Voter implemented as IP core in safe FPGA N Conductive-cooling options for harsh environments N Meets environmental standards DO-160 and EN 50155 N Developed according to DO-254 and EN 50129 N Guaranteed quality based on ISO 9001, EN 9100 and IRIS MEN delivers redundant computers on board and system level (COTS or customized) for safetycritical control systems for railway, avionics and industrial.

MEN Micro, Inc. 24 North Main Street Ambler, PA 19002 Tel: 215.542.9575 E-mail:


3/14/11 9:55:04 AM

interrupts (IPI). In this implementation the hypervisor event system can be used for real-time tasks as well (Figure 2). With these three capabilities, integrating distributed, multi hardware systems into a multicore multi-OS system, with applications now distributed over multiple virtual machines on one hypervisor platform, messaging and inter-OS communication becomes extremely powerful, fast and much more efficient. Having powerful inter-OS communication and shared memory as well as an event system available, multicore multi-OS may even be the answer to some of the traditional symmetric multiprocessing (SMP) problems. Even though SMP may be used on embedded virtualization, assigning application tasks or processes to separate, independent instances of an identical operating system and using the event system and shared memory to synchronize them instead, may result in much better performance than a traditional SMP solution. One of the advantages over regular SMP is that in this case, tasks and processes may now be pinned statically to a specific physical CPU. Even though real-time operating systems featuring SMP are not inherently non-deterministic, keeping an overview over the scheduling and interrupt handling is a challenge due to the fact that different tasks or processes may execute on different CPUs in parallel. Performance of multiple single core RTOSs in parallel can sometimes be much better than in an SMP solution, because the synchronization overhead of symmetric multiprocessing may be higher than expected from an RTOS. Given all of these benefits of a multicore multi-OS design, one could argue that one of the disadvantages of a virtualized platform could be that a user may only have access to the information about one virtual machine at a time, but not about the complete system. Information at runtime about which systems are currently running, how many CPUs are available, which devices are assigned to which guest operating system or details about the PCI bus topology, may not be accessible. In the RTS Hypervisor, for example, all this information provided by the hypervisor is readily accessible, not only in human readable format but also in XML, so this data can be processed in software. Using such an interface, user

applications may generate new or modified hypervisor configurations automatically, or verify that all operating systems have been started in the originally intended configuration and on the genuine hardware board. As multicore multi-OS systems have become more commonly used in the last few years, additional requirements have emerged. Uptime is important and safety and reliability are essential. With the above methods, some of these requirements can be satisfied with only limited effort. However, on modern hypervisors, watchdogs are often available. For example, each operating system running on the hypervisor is equipped with a watchdog counter incrementing constantly in a preset interval. These counters are accessible via an application programming interface (API), and if one of the guest operating systems stops counting, the appropriate action may be taken. Such an action could simply be an alarm, rebooting the operating system that failed, or any other measure the user wishes to take. If designing and developing a system based on embedded virtualization, some attention should also be paid to the development process. During the development phase, an API for rebooting a single OS may save quite a bit of time. During development an OS may not respond to a reboot or shutdown request anymore, so it is also helpful if an API call may simply hard reset one of the virtual machines and then restart this guest OS, maybe even with a new operating system image. Embedded hypervisors are very different from server-type virtual machine monitors. Guaranteeing hard real-time performance for an RTOS and providing access to the real, non-virtualized devices, are two of the key requirements an embedded hypervisor should provide. A number of realtime hypervisors have emerged over the last few years. Working with such a multicore multi-OS system is a different story. Simply running multiple operating systems in parallel is something most of them can do, but it is the details of inter-OS communication, guest OS control and messaging that will make the final product a success. Real-Time Systems Ravensburg, Germany. +49 (0)751 359 558-0. [].


• Systems tailored to your requirements • Built tough for extended system deployments • Designed-to-meet and certified MIL-STD-810 systems • 5-year factory warranty for Trenton SBCs, motherboards and backplanes • Standard and custom boards with BIOS revision control • COTS hardware maximizes system flexibility • Key industry partnerships enable advanced turnkey solutions


The Global Leader in Customer-Driven Computing Solutions™

technology in


Developing for Multicore Systems

Harnessing the Potential of Multicore Processors for Real-Time Applications Making a multicore real-time system behave transparently requires a number of communication and system management functions running under the hood to provide transparency while realizing the performance potential of multicore processors. by Chris Grujon, TenAsys


ulticore processing provides many opportunities to the embedded community, including the potential to scale applications while using the same code. In spite of this, many within the embedded community remain averse to using multicore platforms for real-time applications. This is because they have found no optimum way to harness the additional processing capability while maintaining a well-defined environ-



ment necessary to ensure determinism. Basic symmetric multi-processing (SMP) and asymmetric multi-processing (AMP) architectures have been tried and found wanting for use with multicore platforms. As a means for distributing processing resources, SMP is being applied very successfully in non-real-time systems. But for real-time applications, additional features are needed to allow it to work properly, such as the means to allocate a

Drive Video Controller Capture & Analysis


particular core to an application, or what is known as â&#x20AC;&#x153;core affinity.â&#x20AC;? There are also many unknown variables in an SMP platform that cannot be discounted when developing mission-critical applications. However infrequent it may be, an occasional hiccup can be devastating. AMP architecture partitions resources into discreet known entities, an environment that makes it easier to develop real-time control systems. This is








Core 0 I/Os

Multicore Processor Core 1 Core 2 I/Os I/Os

Core 3 I/Os


Figure 1 Functional blocks (FBs) are mapped from individual platforms to a single multicore platform, each FB running on a separate processor core and RTOS with its associated I/Os.



tech in systems

more like the original development environment for real-time applications, which makes it easier to move those applications over. But multicore processors are single devices that share many resources and services, such as memory, interrupts and I/Os. For real-time applications to function properly, these resources must also be separated. They also need a managed way to communicate with each other to allow segments of an application to pass information much like they would if they were running as a single application on a single processor. New technologies are enabling AMP architecture to be deployed successfully on multicore platforms. These technologies include embedded virtualization that allows memory, I/Os and their associated interrupts to be allocated to a specific processor core and the application that is selected to run on it, along with a networking layer that provides the communications link between the processes that are running on the individual processor cores. With these technologies, developers can create fully scalable, real-time applications for multicore platforms. Such a solution moves easily from one to two to four or more cores or even an entirely different platform without re-engineering the application and while preserving dedicated I/O and cores for time-critical tasks.

Control System Requirements for Multicore Platforms

Historically, devices that handled real-time applications were implemented as discrete functional blocks (FBs) of a control system and each was deployed on a separate processing platform. But recent advancements in processing performance and especially multicore architectures are making it possible to consolidate multiple FBs onto a single platform. This not only reduces the cost of the system but also provides the potential for more efficient interconnect between the function blocks, yielding better overall system performance and greater reliability. Still, consolidating several FBs onto one multicore processor brings up the same challenges of distributing single applications across several processors as discussed above. It requires a system man-

A Solution Example Embedded Virtualization technology partitions a multicore platform allowing memory and I/Os to be associated with one instance of a TenAsys INtime RTOS (node) with each node running on a separate processor core.

Global Objects Technology The essence of Global Objects technology is that INtime RTOS is an object-based operating system that makes use of exchange objects, such as mailboxes and semaphores, to pass data and control to and from processes within the RTOS. Global Objects extend that capability to processes running on different instances of the RTOS (“nodes”). This means that applications that were once running under one RTOS, on one processor core, can communicate even though they are running on a different node and different processor cores. The same communication is also possible between nodes that exist on different platforms, by extension of the technology over an Ethernet network. Global Objects technology (GOBSnet) comprises: • GOBS manager: The GOBS manager is an RTOS process that runs on every node. Its function is to manage the creation, the removal and the linkage of objects and to pass control messages from node to node on the same platform. • GOBSnet: GOBSnet is an INtime process that run on every INtime platform. Its function is to manage the communication of GOBS messages between platforms. Messages received by the GOBSnet manager for other nodes on the same platform are forwarded via shared memory to the target node. • Distributed System Manager (DSM): The DSM tracks the state of the system, monitors the health of its components, and cleans up in the event of component termination or failure. The DSM provides system-level management of tracking the state of the nodes and automatically notifies nodes that are dependent on the service of another node if and when that node has shut down. The DSM also provides process level management services, such as the notification of the termination of a process on a remote node. These services are available to user applications in order to establish process dependency relationships and can be setup with an API. When a process wants to pass data to a process on a different node, it makes use of the same APIs as it would if it was communicating with a process within the same node (instance of the RTOS). The only difference is that there needs to be some initial discovery to locate the node where the remote process resides. Once returned, all interaction with the remote exchange object is identical to that of a local one. From an application/user point of view, the above described operations and the associated management/housekeeping tasks are executed automatically and there is no need to concern oneself with the inner working of GOBSnet to make use of it. Existing applications can easily be partitioned to run across multiple processors. The architecture is designed to scale across additional nodes according to the needs of the application.

agement layer to apportion the common resources such as memory and I/O and the available processing resources. If one considers a functional block to be comprised of application-specific hardware and software components and a processor or controller to implement the function, a multi-system manager can achieve the isolation required to keep the FBs separate. Using embedded virtualization techniques, each FB in a control system can be assigned to run on a separate core of a multicore platform, with dedicated

I/O and memory management (Figure 1). Each core operates under the control of an individual system manager (RTOS), essentially functioning as an asynchronous multi-processing (AMP) system. The next step is to enable the FBs to communicate with each other. This functionality can be added to the application layer or embedded within each FB RTOS. Traditionally this is a solution that has manifested itself as either a network service requiring more execution overhead or managed shared memory requiring RTC MAGAZINE APRIL 2012


Tech In Systems

DAQFlex Program in any OS









Multicore Processor Core 1 Core 2 I/Os I/Os

Core 3 I/Os


Core 0 I/Os Figure 2

Inter-process communications (IPC) capability is integrated into each RTOS, allowing multi-FB applications to be hosted on multicore processors with minimal code changes. This allows large applications like FB3 to be distributed across two processor cores.

Small footprint driver ideal for OEM’s • For use with Windows®, Linux®, Mac®, Android™, and more • Supported MCC DAQ hardware from



Integrating IPC into the RTOS

For more information on DAQFlex, visit: To read our white paper on tablet-based DAQ and download sample code for Android OS, visit:

Contact us

1.80 0.234.4232 ©2012 Measurement Computing Corporation 10 Commerce Way, Norton, MA 02766


Untitled-1 1


extensive engineering effort. Networking interfaces scale nicely but carry a lot of overhead. Shared memory, while optimum in performance, doesn’t scale beyond a single system. With shared memory it is difficult to engineer an implementation that includes an application’s priority level management to ensure that tasks initiated from one core observe the priority levels of tasks on the cores that they are interacting with.

3/8/12 10:05:52 AM

A better method is to integrate the inter-processor communication (IPC) mechanism into the RTOS (Figure 2) where it may be automatically handled by the RTOS priority scheduler. This enables programmers to use to standard “exchange objects,” such as mailboxes, semaphores and shared memory blocks within their code to perform IPC between processor cores and across platforms. This embedded IPC methodology is so transparent that it allows FBs to be separated and distributed among available processors with minimal code changes. For the IPC mechanism to work reliably there must be a means for the FBs to keep track of the state of other FBs on which they depend. To do this a system management layer needs to be added to the environment. This layer should provide the means of signaling system events, such as the creation and deletion of interdependent processes and the FBs that they reside on. In addition, both the IPC and

the management layers are designed to be extended across multiple instances of the RTOS to enable a system to scale from one to many processors, whether they are on the same platform or even multiple platforms. Most importantly these solutions should require no additional work on the part of the application developer. The IPC link should work implicitly and exchange objects should be able to reside anywhere within the system and operate at the same level of priority that the application would require them to be if the system were not partitioned. This is a fundamental requirement for meeting the needs of multiple, high-priority processes that could otherwise fight for CPU resources.

Adding a Message-Passing Network Layer

With multiple RTOSs running independently on each core of a multicore processor, it is essential that when a process on one RTOS is interacting with an object on another RTOS, the behavior of both instances of the RTOS must continue to be predictable and the operational overhead must be negligible. More importantly, functional integrity of the system must be preserved. So as mentioned above, task priorities must remain intact across the RTOSs, and the implementation must ensure that false priority such as a lowpriority thread on one node blocking a higher-priority thread on another node, cannot happen.

tech in systems

To minimize overhead and maximize predictability, the implementation needs to consist of a lightweight messagepassing layer based on a simple shared memory plus inter-processor interrupt for the transport. A local agent on the receiving node can handle operations on behalf of the sending thread to execute that class of operations, including those that wait on an object. At the same time, proxy threads execute at the priority of the original caller ensuring that the calling thread is effectively woken up according to the scheduling policy of the RTOS where the object is resident. With so many multicore processors

available—and more on the way—embedded developers need to find ways to leverage the scalability of these platforms while preserving the core affinity required for real-time functional blocks. Because control systems are actually complex collections of discrete functional blocks, it’s only natural that there should be a way to consolidate them onto a single hardware platform. As suggested, developers can use a lightweight message passing layer and system manager to enable inter-process communication between the isolated realtime applications running on discrete FBs portioned by means of embedded virtu-

alization technology. This concept forms the foundation for TenAsys’s INTime Distributed RTOS and enables programmers to write applications that run without modification on different system configurations spanning from single-core to multicore processor systems to multi-platform systems with multicore processors. TenAsys Beaverton, OR. (503) 748-4720. [].

PC/104, PC/104 Express & ISM Showcase Featuring the latest in PC/104, PC/104 Express & ISM technologies PC/104-Plus Watchdog Timer Board

High-Speed USB/104 Module Provides 96 Lines of Optimized Digital I/O

Temperature measurement, monitor, and alarm Fan status and speed control PCI/104 power monitor / limit alarm interrupt Opto-isolated input to trigger reset General purpose opto-isolated input, two outputs Two general purpose 8-bit A/D inputs External fused 5V and 12V power Light sensor for enclosure security

ACCES I/O Products, Inc. Phone: (858) 550-9559 Fax: (858) 550-7322

High-speed USB 2.0 device Twelve or six 8-bit ports independently selectable for inputs or outputs All I/O lines buffered with 32 mA source, 64mA sink current capabilities Jumper selectable I/O pulled up to 5V for contact monitoring, down to ground, or floating Resettable fused +5VDC outputs per 50-pin connector PC/104 module size and mounting compatibility

ACCES I/O Products, Inc. E-mail: Web:

Phone: (858) 550-9559 Fax: (858) 550-7322

ADLQM67PC – First Ever Sandy Bridge in PC/104 Form Factor

USB Wi-Fi Modules 802.11b/g/n Compliant USB 2.0 hot swappable interface Compatible with USB1.1 and USB2.0 host controllers Up to 300Mbps receive and 150Mbps transmit rate using 40MHz bandwidth Up to 150Mbps receive and 75Mbps transmit rate using 20MHz bandwidth 1 x 2 MIMO technology for exceptional reception and throughput 2 U.FL TX/RX antenna ports Wi-Fi security using WEP, WPA and WPA2 Compact size: 1.0” x 1.0” x 0.25” (Modules)

Intel® Core™ i7 Gen2 Quad 2.1GHz - 3GHz Intel® QM67 PCH Up to 8GB DDR3-1333 DRAM SoDIMM204 Type 1 Bottom-Stacking PCIe/104 V2.01 with Gen2 protocol (2.5 to 5 GT/s) 2x SATA 600 Ports with RAID 2x 10/100/1000 Mbit Ethernet LAN Port 2x RS232 COM Ports, 8x USB2.0 Ports Separate Onboard VGA, LVDS, HDMI / DVI, Display Port

ADL Embedded Solutions Inc. Phone: (858) 490-0597 Fax: (858) 490-0599 rtc1204_showcase.indd 2

E-mail: Web:

E-mail: Web:

Radicom Research, Inc. Phone: (408) 383-9006 Fax: (408) 383-9007

E-mail: Web:


1:43:26 PM RTC MAGAZINE 4/10/12 APRIL 2012

technology deployed Machine-to-Machine Systems

Accelerating Machineto-Machine System Development with Embedded Software

hand-crafted system. By leveraging embedded software, OEMs can reduce the cost of embedded product development and focus on their core competencies and differentiators instead of the “foundation” software.

The Challenges of Do-It-Yourself M2M

For companies just starting M2M projects, a do-it-yourself (DIY) approach can look attractive. M2M sounds deceptively simple: Take a device, connect it, and send data to another machine. We use connected devices every day, but it took many years and focused efforts to make connecting The advent of standardized components and tools will your iPad to iTunes so easy. ease and accelerate the development of M2M systems The challenges of DIY M2M are vast, by providing compatible and complete solutions that and risks include slower time-to-market, reduced quality, fewer features and less will implement ready-to-go software platforms and time to focus on value-added functionality. connectivity. The same issues arise both for companies building devices with M2M functionality by Kurt Hochanadel, Eurotech and Brian Vezza, Wind River and for those deploying devices and M2M services. Developers typically do not know all the pitfalls they may face down the line, and may lack the broad spectrum of expern machine-to-machine (M2M) communications, a device cap- tise required to develop an end-to-end M2M application. Teams can often navigate the hardware and embedded softtures an event and relays meaningful information to an apware with the right people and the right expertise. The real stickplication through a network. M2M means smart—from smart ing point is connectivity. When a device gets connected, it leads services to smart connectivity to smart devices in every industry. to a host of other concerns, including protocols, security, manageM2M systems are becoming smarter every day, giving a ability, software and firmware updates, discovery, performance, more accurate picture of what is happening in closer to real time cloud interface and more. than ever before. This valuable information enhances productivOther technology implementation challenges include decouity as organizations use it to make smarter decisions faster, which pling producer/consumer implementations, adopting open mescan lead to reduced costs and improved processes. sage transports, developer-centric application frameworks, and Not only are M2M applications becoming more valuable, they are becoming more ubiquitous as well. According to a re- public or private cloud deployment infrastructures. cent study conducted by IDC, over 33% of all connected devices Ultimately, the team must consider the reason they need the shipped in 2015 will be “Intelligent Systems” or M2M devices M2M solution in the first place. Reasons vary, but typically the (Figure 1). IDC defines Intelligent Systems as connected embed- solution will either monitor or control an aspect of the operating ded devices with a high level operating system (OS). environment. Data will be generated that can be analyzed to proEricsson CEO Hans Vestberg said, “In the future everything that vide situational awareness. Of course, the solution will probably will benefit from being connected, will be connected.” The number need to be able to scale and add new devices over time. of connected devices worldwide is expected to rapidly increase over All of these considerations lead to any number of pitfalls the next 10 years—now the challenge is developing these smart de- that can slow down the product or project, increasing risk and vices in the simplest, fastest, most cost-effective way possible. expenses, and reducing value. DIY M2M requires a broad range Original equipment manufacturers (OEMs) are often chal- of expertise. Companies have expertise in many areas, but will lenged to develop M2M solutions since the process can be com- almost always be missing a few areas and may not recognize it plex and may extend beyond their area of expertise. Embedded until deep into the project when it can be expensive to adjust. software operating systems, middleware platforms and tools can As billions of new M2M devices are developed and consimplify M2M and accelerate its adoption in the marketplace. nected in the marketplace, each will need a minimum kit of funcAccelerating M2M through embedded software improves tionality to address these issues, and embedded software can help time-to-market with an integrated, optimized solution instead of a to simplify the process.




Technology deployed

The Building Blocks for Successful M2M Solutions

Teams often take only a passing glance at the M2M software “foundation”—the protocols, security mechanisms and management aspects—and skip ahead to making sense of the data. However, if the foundation is not in place and solid, the project is prone to issues down the road. The M2M software foundation has two primary functions. One is that it provides the ability to connect and manage M2M devices securely while ensuring that they perform at expected levels. These capabilities need to be built into the devices from day one. The second is the ability to minimize operational expenses and headaches. Many businesses will start small, with a limited number of M2M devices in a pilot. A solid M2M foundation allows for future expansion and other devices. Specifying M2M software requirements may seem impossible, given the multitudes of hardware options, features and deployment scenarios that must be considered. However, our experience at Wind River and Eurotech shows that while there is a broad range of M2M devices, there is a relatively small set of common software requirements. In fact, the requirements typically boil down to the following 10 key considerations, and your vendor selection process should account for each prospective vendor’s ability to deliver on these core tenets: 1. Devices must be secure, reliable and have acceptable performance. 2. Connectivity options include wired and wireless, WAN, LAN and PAN. 3. Devices must be manageable beyond just seeing if the device is working. 4. Deployments must scale to large numbers unattended. 5. M2M experience must be simplified: easy to understand, order, buy, install, build, use, operate, manage, fix, etc. 6. Solutions must be flexible. 7. Many devices will be mobile and may transition from one domain to another. 8. Location determination will be important for many devices and applications. 9. Solutions must be smart—i.e., services, data and applications all must be smart. 10. S  tandards must be supported.

A Solid Foundation for M2M Solutions: Linux

M2M solutions need software that is secure, manageable, scalable, simple, flexible, mobile, supports industry standards, and offers a broad range of connectivity. Linux is a solid foundation for M2M solutions with an optimized development environment, reduced project risk and faster time-to-market. Independent Software Vendor (ISV) applications often run on Linux for embedded devices, and a rich ecosystem means more resources for OEM teams. Of course, more resources can lead to more complexity, albeit of a different type, and integration of core capabilities is valuable.

8000 7000

5.7% CAGR

6000 5000

Traditional embedded systems


Intelligent Systems (M2M)


24.0% CAGR

2000 1000 0

Source – IDC 2011 2010






Figure 1 Growth of embedded units shipped annually in millions. According to a 2011 study by IDC, Intelligent Systems are growing four times faster than traditional embedded systems.

An optimized embedded Linux development environment, such as Wind River Linux, provides optimized run-time, life cycle tools, open source assurance and value-adds such as services and training. In addition, by working with partners such as Eurotech, deeper integration and enhanced capabilities can be enabled.

A Standardized Approach to M2M

By using a pre-integrated operating system, hardware, connectivity and software, companies can improve time-to-market, save money and reduce risk. IT integration and communications become a native capability of the system instead of an afterthought. Together, Kontron, Intel, Wind River and Eurotech have built a next-generation M2M Reference Design Developer Kit targeted at M2M gateways and higher performance M2M devices. The primary components are common, simplified M2M hardware based on off-the-shelf industry standard boards along with an integrated communications platform for wireless and wired connectivity. In addition, the kit includes an embedded operating system and tools plus M2M software, including cloud capability. Collectively, this M2M development kit has transformational potential for the M2M market. Today, most companies repeat the same steps of hardware, computing, connectivity, OS and M2M software development in a thousand different ways. By using a standardized approach where a large number of the DIY M2M pitfalls are eliminated, companies can focus on their specific differentiators while speeding time-to-market. Over time, this approach will expand and provide a platform for accelerating M2M adoption. By expanding the M2M community, M2M projects will benefit from proven knowledge and processes to accelerate the adoption of M2M solutions in the marketplace. Recently, an M2M Industry Working Group was formed to ease the developRTC MAGAZINE APRIL 2012


technology deployed

• Performance constraints • Hardly any standards • Resource constraints (C++) • Expensive, limited transports (WAN) • Monolithic approach • Single-purpose devices • Operations-centric approach • Single-purpose solutions

• Powerful embedded systems • Open and industry standards • No human resource constraints (Java) • Inexpensive, available transports (WAN) • Systemic and platform approach • Multi-service systems • IT-centric approach • Interconnected, integrated solutions


M2M 2.0

Figure 2 As M2M adoption accelerates, projects will embrace simpler solutions driven by embedded software.

ment, testing and deployment of M2M solutions. The founding members of the Industry Working Group believe that the creation of open tools, open protocols, open interfaces and open application programming interfaces (APIs) is the best approach to addressing these problems, bringing tremendous value to the M2M ecosystem. Late last year, the Eclipse Paho project also began as an open source project to create highly scalable messaging technology. The project aims to provide a more cohesive system of interconnectivity and also the possibility of an “Internet of things.” M2M is already key to much of the world’s functions, but over constrained wireless connections; this step could theoretically create new messaging opportunities, integrating web and enterprise middleware much more seamlessly with physical objects. As the M2M community expands, the industry is working to move from what might be called M2M 1.0 to M2M 2.0 (Fig-

ure 2). Billions of embedded devices—from RFID tag readers to smartphones and cardiac monitors—can be interconnected to one another. The future of M2M lies in powerful embedded systems, open industry standards and a systematic platform approach. The M2M market can simplify device connectivity by taking advantage of these proven technologies to build smart, connected systems. Eurotech Columbia, MD. (301) 490-4007. []. Wind River Alameda, CA. (510) 748-4100. [].

Multicore Debugging: Mix & Match 44

Untitled-6 1


2/6/12 5:17:55 PM

» Where can I get a pre-integrated M2M platform that is market ready today? « Kontron's M2M Smart Services product portfolio of development kits and deployment units serve the industry's need for high performance M2M devices that can be easily enabled to develop M2M services today. M2M SMART SERVICES SOLUTIONS: CONNECTED, MANAGED, SECURE With a vast ecosystem of hardware and software partners, Kontron’s costeffective M2M systems are designed to offer production ready solutions and accelerate your smart services deployment opportunities. M2M Development Kits and Deployment Units

Learn mo ko nt ro n .c re at om / M2M

Scan this QR Code to open the M2M Deployment Unit Datasheet

» Feature rich development kits and application specific deployment units » Connectivity: IEEE802.11, IEEE802.15.4, 3G/4G Cellular » Cloud enabled secure communication with existing Carriers / Cloud providers » Application ready “Machine to Machine” middleware » Ecosystem partnerships with global market leaders » Commercial and industrial grade designs

CRITICAL QUESTIONS ... ANSWERED Call, Email or Visit today.

Call: 1-888 -294-4558 Email: Visit: / M2M

If it’s embedded, it’s Kontron.

technology deployed Machine-to-Machine Systems

Accelerated Processing Units and Multicore Programming Innovation at the Cusp of Machine-to-Machine Implementing parallelism in powerful accelerated processors can be a complex task. Software parallelization can ease the process and quickly help manage growing and complex M2M wireless industrial networks. by Cameron Swen, AMD and John Havener, Texas Multicore

or thousands of field devices (nodes), introduces new challenges related to reliability, security and throughput of the network. Therefore, management devices are necessary within the network to take care of access control and encryption, device identification and configuration, wireless channel control and communication paths, message handling and protocol translation, and finally but most importantly, to maintain a database of I/O states and report I/O status. And this all needs to be done with a small, cost-effective, robust and reliable device, referred to as a wireless gateway (Figure 1). The biggest limitation of these types of networks is the ability of the wireless gateway solution to adapt and manage its topology to ensure that a robust connection exists to all of the intelligent devices distributed throughout the plant. Testing of current implementations of these wireless gateway solutions shows that they take three to five minutes to recalculate the network topology of a 50 node network, placing a practical limit to these solutions of 50-75 nodes.


eterogeneous system architectures promise to transform many applications and the usability of machineto-machine (M2M) solutions in these applications, enabling reliable and real-time communication. To support these solutions, multicore programming solutions are required to help software application developers optimize for parallel processing environments. Through the availability of both of these advanced technologies, developers will be able to create intelligent, ultra-responsive M2M enabled systems that, while operating independently, can efficiently be centrally monitored and controlled in real time. Replacing traditional wired communication networks with wireless M2M communication in applications such as manufacturing process control, offers the benefit of being able to quickly and easily install new equipment or sensors without the need to run difficult-to-install or costly communication wiring. But implementing an M2M solution in this type of application, which may include hundreds



Automation Network

Wireless Gateway

Field Device Field Device


Field Device


Field Device

Field Device

Field Device

Field Device Field Device

Wireless Monitor

Figure 1 Wireless industrial M2M networks face challenges in terms of connectivity and security as well as the ability of the wireless gateway to recalculate and manage the network topology as the number of nodes continues to grow.

Technology deployed

With the advent of new heterogeneous processing solutions, the siliconlevel integration of general-purpose, programmable scalar and vector processor cores for high-speed parallel processing establishes a new level of processing performance for embedded systems, at previously unobtainable performance-per-watt ratios. This merging of low-power x86 CPU cores with the parallel processing performance of a discrete-level general-purpose graphics processing unit (GPGPU) in a single device, also known as an Accelerated Processing Unit (APU), is enabling the high-speed processing required to handle intensive numerical computations such as, letâ&#x20AC;&#x2122;s say, that which is required of a plant-floor wireless gateway tasked with calculating the network topology of a 10,000 node network in under one minute (Figure 2).

APU-Caliber Computational Performance and Power Efficiency

The general-purpose vector processor engines within an APU are able to deliver from 10s to 100s of GFLOPs of performance, far outstripping the computational capabilities of the traditional processors used for these applications. And with this APU architecture, direct access to the unified memory shared between the CPU and GPU enables a true zero-copy data transfer path and the lowest possible latency, yielding a fully optimized data pipeline. But computational performance and real-time device/network awareness are only part of the equation. It is essential that the solution be available in a small form factor and reliable platform, so power consumption naturally remains a critical concern for implementing an APU in a wireless gateway. The performanceper-watt gains enabled by APUs assure greater power efficiency and lower heat dissipation, which in turn can preclude the need for a cooling fan and therefore facilitate the use of compact and/or vent-less system enclosures distributed throughout a harsh factory floor environment.

Figure 2 An example of an accelerated processing unit (APU), the AMD Embedded G-Series platform has a dual-core x86 processor along with a graphic processing unit that can also do parallel general computation plus multiple display interface options and a full complement of I/O.

Making the Most of Parallel Processing

While many systems today run on multicore CPUs, many software applications have yet to take full advantage of the parallel processing potential of these systems. Indeed, parallel programming limitations remain a lingering but wholly surmountable barrier to exploiting the full performance benefits of multicore architectures, including massively multicore APUs. The fundamental challenge with sequential programming languages is that the sheer complexity of the code obscures opportunities to employ parallel processing, and overcoming this obstacle via manual analysis and coding processes can be very difficult.

Using traditional software development methodologies originally developed for sequential programming, there are three well-defined steps required for parallel programming. 1. I dentify parallelisms: Analyze the problem to identify tasks that can execute in parallel. 2. E  xpose parallelisms: Restructure a problem so tasks can be effectively exploited. This often requires finding the dependencies between tasks and organizing the source code to manage them effectively. 3. Express parallelisms: Express the parallel algorithm in source code using a parallel programming notation. RTC MAGAZINE APRIL 2012


technology deployed

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42

Let S be the set of explored nodes with downlink route constructed Initially S = g ∪ VAP Initially for each AP i in S, set Gi = ({g ∪ i}, {eg i}) and Ri = Gi

while S ≠ V do Find S′ ⊆ V−S: ∀ v ∈ S′, v has at least two edges from S // Sr is the reliable node set in S′, initially Sr = ∅ if S′ ≠ ∅ then for all nodes v ∈ S′ do for all edge pairs (eu1,v, eu2,v) from S do hu1,u2 = (hu1 + hu2 )/2 end for Find Pv, set of edge pairs of v satisfying C1 ∧ (C2 ∪ C3) if Pv ≠ ∅ then Sr = Sr ∪ {v} Choose (eu1,v, eu2,v) from Pv with min hu1,u2 else Choose (eu1,v, eu2,v) from S′ with min hu1,u2 end if hv = hu1,u2 + 1 end for if Sr ≠ ∅ then Add v in Sr with min hv to S else Add v in S with min hv to S end if ConstructDG(G, u1, u2, v); else Find S′′ ⊆ V−S and ∀v ∈ S′′, v has one edge eu,v from S if S′′ ≠ ∅ then for all node v ∈ S′′ do hv = hu + 1 end for Add v to S with min hv Gv = ({u ∪ v},{eu,v}) Rv = Ru → Gv else return FAIL; end if end if end while return SUCCESS


The expertise, time and effort required to manually develop parallel programs using these traditional techniques can be significant. And it isn’t enough to simply understand how an application can be split into parallel threads. The second

barrier to parallel programming is the need for the application developer to understand how the multicore system will process the multiple threads. Among the details of the computing system that the application developer may need to under-

stand to optimize the application are such things as load balancing, memory access and processor communications. Load balancing means keeping all the processors fed with work at the right times. Though the target system might have multiple cores, some of those cores will be engaged by the operating system or by other critical applications. The developer must understand how to distribute the application across available resources so that the resources are used efficiently. As processes are distributed, the data accesses may also be distributed across processors. The user must take into account the available memory and how the processors communicate with memory to avoid processors sitting idle waiting for data, creating memory conflicts, or worse, corrupting data. At the same time, application developers must understand multicore bus protocols to ensure the inter-processor communications don’t create bottlenecks that slow the operation of the application, making the parallel code slower than the sequential implementation. And so it is necessary, in order to optimize an application for parallel processing, that the application developer must understand the target multicore system in great detail, manipulating processes that are normally taken for granted in sequential programming. It is for this reason that software applications developed for specific multicore architectures typically need to be rewritten to accommodate new and different multicore architectures— and this, of course, requires significant investment in labor and support resources.

cyclicNodes(node1, node2, edges(1)) := subset([(source: node1, destination: node2), (source: node2, destination: node1)], edges);

CODE BLOCK 2 cyclicNodes(node1, node2, edges(1)) := [node1, node2] when node1 < node2 and // return the nodes, but only if they’re in order subset([(source: node1, destination: node2), (source: node2, destination: node1)], edges);

CODE BLOCK 3 cyclicParents(node, edges(1)) := let p := parent(node, edges); in appends(cp_helper(p, p, edges));

// find all the parents of the node // pass them (twice) to the helper and concatenate results

cp_helper(parent1(1), parent2, edges(1)) := cyclicNodes(parent1, parent2, edges);




// all this function does is normalize the data // by passing it along to cyclicNodes()

Technology deployed

As a result, software applications that previously gained performance with every new processor release have become static, impaired by the ability of developers to add new features and functionality and/or pivot to a new processing architecture.




Taking the Burden off of Parallelizing Code

The recent emergence of auto-parallelizing software compilation technologies promises to help neutralize the aforementioned challenges and ensure that application developers can take full advantage of new heterogeneous system architectures. While this approach will allow developers to let compilers manage application segments they have already parallelized manually, they will still need to work through the three defined steps and will need at least some understanding of the target multicore system. Auto-parallelizing programming technology on the other hand introduces a simple declarative language for expressing algorithm intent—without the need to specify parallelisms or implementation structure—and employs compiler mechanisms that automatically identify, expose and express the parallelisms, enabling application developers to quickly generate optimized threaded application code from simple algorithmic descriptions of the code functionality. This approach avoids the need for developers to become experts in heterogeneous processor design, since the technology distributes the application across the available processors and optimizes memory access and communications for parallel implementation. Parallelizing programming technology actually becomes the abstract layer that allows the developer to focus on what the function is without concern about how it will be computed—leading to dramatic improvements in innovation and productivity. Auto-parallelizing software compilers automatically extract parallelism from the application code, enabling code compilation to any parallel architecture from common source code. As a result, the auto-parallelized code remains independent of computing system architecture, eliminating the need to re-write application code for new multicore processor releases. Applications can be ported to





5 (a) Original network topology

Figure 3 Original network topology.

new multicore processors, new machine configurations and new operating systems without incurring the costs, time and effort associated with traditional programming methodologies.

Putting It to the Test

In recent proof-of-concept trials with a major process automation supplier, the combination of an APU and auto-parallelizing software compilation technologies was applied by Texas Multicore Technologies to help improve the processing capability required to calculate the network topology of a hundred-node wireless network to under one minute. Early tests significantly exceeded that goal by demonstrating the ability to recalculate the topology of a 250-node network in less than 14 seconds, promising to significantly improve the performance of the supplier’s wireless gateway solution for its large scale manufacturing customers. TMT’s SequenceL was chosen for the test because it provides developers with a

declarative, functional language that selfparallelizes, which means that if you express the algorithm in SequenceL, the SequenceL compiler will generate massively parallelized C++ code, which is provably race- and deadlock-free. It will also generate GPU code, if desired, to support parallel processing on a GPU, or APU. It was chosen for this project because of its simplicity of coding, its ability to leverage the multicore and parallel processing nature of the AMD G-Series APU being used for the test, and the ease of embedding the C++ output of the compiler into other code bases. The section in Code Block 1 explains some of the implementation details of the SRDR algorithms under SequenceL, using the example of “Constructing Sequential Reliable Downlink Routes” published in Reliable and Real-Time Communication in Industrial Wireless Mesh Networks by Chen, Nixon, Han, Zhu and Mok. The algorithm in Code Block 1 refers to three constraint conditions, defined as RTC MAGAZINE APRIL 2012


technology deployed

1 main(S(1), notS(1), DLGs(1), Routes(1), graph) := 2 let 3 twoPsInS := atLeastNparentsIn(notS, S, graph, 2); // line 6 4 candidates := genCandidateGraphsFromNodes(twoPsInS, S, graph, DLGs) when notEmpty(twoPsInS) 5 else []; // lines 8-12, 20 6 C1 := Constraint_1(candidates, graph); // 7 C2 := Constraint_2(candidates, DLGs); // Constraints from Pg 7 8 C3 := Constraint_3(candidates, DLGs); // 9 Pv := intersection(C1, remdups(C2 ++ C3)); // line 13 10 twoPwinners := minHops(Pv) when notEmpty(Pv) // lines 14-16 11 else minHops(candidates) when notEmpty(candidates) // lines 17-18 12 else []; 13 onePinS := exactlyNparentsIn(notS, S, graph, 1); // line 29 14 onePcandidates := genCandidateGraphsFromSingleParentNodes(onePinS, S, DLGs, graph); // line 29 15 onePwinners := minHops(onePcandidates) when notEmpty(onePcandidates) else []; // lines 30-34 16 nn := twoPwinners when notEmpty(twoPwinners) else onePwinners; // lines 8, 28, 40 17 nextNodes := [head(nn)]; // lines 22-26 18 onePDLG := oneParentDLG(onePwinners); // line 35 19 onePRoute := oneParentRoute(onePwinners, Routes, onePDLG); // line 36 20 nextS := S ++ nextNodes.index; // line 34 21 nextNotS := takeaway( notS, nextNodes.index ); 22 nextDLG_Routes := genDLGs(nextNodes, DLGs, Routes, graph); // line 27 23 nextDLG := nth(nextDLG_Routes, 1) when notEmpty(twoPwinners) 24 else onePDLG when notEmpty(onePwinners) 25 else []; 26 nextRoute := nth(nextDLG_Routes, 2) when notEmpty(twoPwinners) 27 else onePRoute when notEmpty(onePwinners) 28 else []; 29 nextDLGs := DLGs ++ nextDLG; 30 nextRoutes := Routes ++ nextRoute; 31 in 32 33 34

[DLGs, Routes] when Empty(notS) else [[], []] when Empty(nextNodes) else main(nextS, nextNotS, nextDLGs, nextRoutes, graph);

// line 8 - recursion base case // lines 37-38 - failure condition // recursion


follows: C1: h as at least two parents u1, u2, and they form a cycle. C2: u1 is u2’s parent in u2’s local downlink graph. C3: u2 (or u1) has at least one parent from the cycle in Gu1 (or Gu2). As an example, we will look first at the evaluation of C1. In this case, the problem is to find the parents P of a vertex v, and see if any two of them form a cycle (i.e., there are 2 edges connecting a pair of nodes p1 and p2, one in each direction, where p1 and p2 are both elements of P). In a procedural language, you’d construct an algorithm for this, by either asking v for its parents (if it knew them), or looping through the entire graph looking for nodes that have v as a child (if it didn’t keep track of its parents). Thus armed with the list of parents P, you’d construct another loop that would either generate all of the (|P| choose 2) parent pairs, and then



analyze each for cycles; or traverse P looking for parents Pʹ that connected to other parents Pʹʹ—and then analyze which ones of those might connect back to Pʹ. In SequenceL, we use the definitions themselves to write the code. For instance, when finding the parents of a vertex, a vertex v’s parents are defined as those vertices P that are connected to v by an edge pàv (where p is an element of P). Or more specifically, those vertices that are the source of an edge, whose destination is v. Or, in actual SequenceL: parent(node, edge) := edge.source when edge.destination = node;

The above function, given a single node and a single edge, will return the source of the edge (i.e., the parent of the node), if and only if the destination of the edge is the node. In other words, it will return the source of the edge, if that source is the node’s parent.

But SequenceL also has the unique ability to “normalize” input data, so if you pass it the entire list of edges in the graph, instead of a single edge, it will return all of the sources that have a destination of v. In other words, all of the parents. So the code snippet above is all that’s required to generate the full list of parents for any node—just by using the definition of a parent: it’s the source of an edge whose destination is the child. Likewise, if a pair of parents p1 and p2 were to form a cycle, then by definition, there must be two edges somewhere in the graph that connect p1àp2, and p2 àp1. That is, two vertices p1 and p2 form a cycle if [p1àp2 , p2 àp1] is a subset of the set of edges in the graph. Or, in SequenceL, just as shown in Code Block 2. No looping, traversing or analyzing involved—just the definition of a cycle. This returns true or false. If we want it to operate in the same way that parent() does, acting on entire sets of data, we might want to modify it to return the

Technology deployed

parents themselves, and to eliminate potential duplicates by forcing an ordering on the parents. We can do this just by inserting the line in Code Block 3. Now, to generate a list of all cyclic parents of a node, we just use the functions in combination, by using a helper function to call them and concatenate the results as shown in Code Block 4. The second helper function cp_ helper() serves merely to normalize the input, so that we can pass the entire list of parents to cyclicNodes(), instead of just two nodes at a time. But given that, with just those four one or two line functions, we can easily generate the cyclic parents of any node, saying, for example:

As these trials proceed toward the aforementioned 10,000 node in one minute calculation performance goal, the supplier will be well enabled to optimize its wireless network solution to adapt and manage its topology to the intelligent devices distributed throughout a plant with unprecedented speed, enabling reliable and ultra-responsive monitoring and/or control of these systems.

Advanced Micro Devices Sunnyvale, CA. (408) 749-4000. []. Texas Multicore Technologies Austin, TX. [].


cyclicParents(6, edgeList)

to see all of the parents of node 6 that form cycles. As an illustration, assigning the sample topology shown in Figure 3 to â&#x20AC;&#x153;edgesâ&#x20AC;? (and representing the Access Points AP1 and AP2 as nodes -1 and -2, respectively), then we can just ask for the parents: => parent(2, edges) [-1,-2,1,3] => parent(3, edges) [-1,-2,2]

and the cyclic parents:

XMC . +!

=> cyclicParents(2, edges) [[-2,-1]] => cyclicParents(3, edges) [[-2,-1],[-1,2]]

Note that while node 2 has more parents than node 3, it only has the Access Points as its cyclic parents, while node 3 has the Access Points, as well as the (AP1, node 2) pair. Using SequenceL, then, to write the algorithm, the main body can be expressed as in Code Block 5. In this case, the main body is really the three lines that are boxed at the end, after the â&#x20AC;&#x153;inâ&#x20AC;? statement. All of the â&#x20AC;&#x153;letâ&#x20AC;? statements are just helpers, providing arguments to those 3 lines. Other functions outside of the main() function implement other helpers, such as intersection(), head(), minHops(), etc., but they are similar to the previous examples in simplicity. Note the comments in the code that match specific lines of SequenceL to specific lines in the algorithm.





Technology For: Communication Industrial Instrumentation Medical Military Scientific Transportation



Untitled-9 1


10:05:38 AM RTC MAGAZINE 4/9/12 APRIL 2012


PRODUCTS 32-Bit Mixed-Signal MCUs Offer Easy Configuration of Rich Peripheral Set A new microcontroller family offers a highly integrated, flexible architecture, a rich peripheral set, ultra-low-power, and Eclipse-based development tools that are downloadable at no charge. The Precision32 family from Silicon Laboratories is based on the ARM Cortex-M3 processor and is suitable for a wide range of applications including portable medical devices, point-of-sale peripherals, motor control, industrial monitoring, barcode scanners, optical touchscreen interfaces, sensor controllers and home automation systems. The new Precision32 family includes 32 SiM3U1xx and SiM3C1xx MCU products with footprintcompatible USB and non-USB options. The following on-chip peripherals greatly reduce component count and system cost: • I ntegrated precision oscillators with an advanced phase-locked loop (PLL) eliminate the need for a costly 8 MHz crystal by providing the clocking accuracy necessary for crystal-less USB operation while running the core independently at any frequency from 1 to 80 MHz. •A  n internal 5V voltage regulator enables the MCU to be powered directly from USB or a 5V source without the need for an external regulator. •S  ix high-drive I/Os (up to 300 mA each) can directly drive highpower LEDs, small motors, buzzers and power MOSFETs, as well as serve as a boost converter controller. •U  p to 16 capacitive touch channels eliminate the need for separate touch sensor ICs in applications requiring buttons, sliders or wheels. •T  he Precision32 family offers a complete USB 2.0 PHY and analog front-end interfacing directly to the USB connector, while most other MCUs require an external USB pull-up resistor and termination circuit.

than competing 32-bit solutions. Numerous power modes and clocking options enable developers to optimize their embedded designs for the lowest power at a given performance level. Silicon Labs offers a rich set of hardware and software tools in-

Using Silicon Labs’ patented dual-crossbar technology and a dragand-drop GUI, developers can easily choose their analog and digital peripherals and pin locations for these peripherals. Competing MCUs often have preset peripheral locations and pinouts, leading to pin conflicts that force developers to alter their designs or move to larger, costlier packages. Silicon Labs’ crossbar design and GUI-based AppBuilder software enable developers to optimize their peripheral mix and pinout placement and locate peripherals near connecting components, thus eliminating pin conflicts, simplifying PCB routing, minimizing PCB layers and ultimately reducing system cost. The Precision32 family’s analog peripherals are specified and tested to operate over temperature and voltage (down to 1.8V). Moreover, the Precision32 analog peripherals are highly configurable, enabling developers to simplify their designs and optimize performance for a wide variety of embedded applications. Silicon Labs engineered the Precision32 family to power efficiency in both active and sleep modes. The MCUs leverage Silicon Labs’ lowpower design technologies to achieve power reductions within every block of the MCU design, resulting in up to 33 percent lower active current (22 mA at 80 MHz or 275 µA/MHz) and 100 times lower sleep current (0.35 µA with RTC enabled and 4 Kbyte of RAM retention)

cluding a unified development platform (UDP) featuring interchangeable MCU and radio components and other subsystems designed to match each developer’s application needs. The UDP includes a single motherboard, modular plug-in boards, and ample room for prototyping, expansion and system integration. It also supports MCU code and firmware development and an array of network and protocol stacks and USB drivers. To accelerate sub-GHz RF design, Silicon Labs offers RF test cards for the UDP that support the company’s new Si446x EZRadioPRO transceivers. Silicon Labs’ complimentary Eclipse-based IDE includes a compiler, debugger and an online dashboard for application-critical information such as a software library with example code, data sheets, schematics, PCB footprints, app notes, active version tracking and automatic updates. A centerpiece of the IDE is Silicon Labs’ GUI-based AppBuilder software, which enables developers to quickly and graphically select their peripheral mix and properties, set up clocking modes, customize pinouts and generate source code—all without having to write a line of code or read a data sheet.



Watchdog Timer

Debug/ Programming Hardware


CORE ARM Cortex M3


Voltage Supply Monitor POWER Low Droupout Regulator


External Regulator


Comparator 0

Comparator 1 IVC0

Capacitive Sensing 0

4/12/28 kB RAM 4 kB retention RAM




2 kB Buffer


16-Channel Controller

5 Directional Endpoints

Standard I/O Pins

Peripheral Crossbar

5 V Tolerant Pins

Internal Oscillator

High Drive Pins



Real Time Clock


Low Frequency Oscillator Low Power Oscillator External Oscillator Control Phase-Locked Loop Peripheral Clock Control



32/64/128/256 kB Flash

Voltage Regulator

Power Management Unit


Power on Reset/ PMU


SPI0 Clock Control



12C1 12S0




PCA1 12C1

AES0 CRC0 Timer 0

Timer 1

Low Power Timer

Silicon Laboratories, Austin, TX. (512) 416-8500. [].




DAC IS THE LARGEST EDA AND DESIGN EXHIBITION Exciting technical program with 35% of the content focused on Embedded Systems and Software and 65% on Electronic Design Automation • • • • • • •

168 Technical Papers 10 Special Sessions 9 Technical Panels User Track presentations 8 Workshops and 8 Colocated Events ESS Executive Day - Tuesday, June 5 Management Day - Wednesday, June 6

HIGHLIGHTS FROM THE EXHIBIT FLOOR • Over 200+ Exhibitors • 15 PAVILION PANELS – topics include: Power, IP, Verification, Analog, Embedded Systems, and Business

ARM® Connected Community® Pavilion

USER TRACK: Sponsored by: 80 posters, 11 sessions

Sponsored by:

DAC.COM In technical cooperation with: WHY ATTEND DAC?

products &

TECHNOLOGY Embedded Real-time Monitoring and Control Platform Based on NI LabVIEW

A new monitoring and control platform for embedded applications is distinguished by the fact that it is a third-party product designed to be programmable with the LabView system design software from National Instruments. The BMX platform S.E.S. has been designed to meet the needs of various industries for a cost-effective, compact and powerful solution to master local control, measurement and condition monitoring functions on a real-time basis. The BMX platform is based on the National’s Single-Board RIO technology. Programming of the built-in real-time processor and FPGA, as well as programming of the complete application is easy and fast thanks to LabView. S.E.A. also makes high-level LabView API and driver functions available to access the module’s hardware and I/O capabilities. The unit comes with a basic software framework to acquire, process and store measurement and control data. A core PowerPC CPU running on a real-time operating system and the embedded FPGA for fast, deterministic control and monitoring are the key functional elements performing these tasks. The module is equipped with a separate communication controller and a GSM/3G modem or WLAN/WiFi module. At the same time embedded VPN functions ensure secure access for authorized personnel. As a result, not only can stored data or new control parameters be remotely and securely transferred, but the operator is even able to comfortably upload data and exchange the complete LabView application. A high-performance GPS receiver is available to provide precise geo-position information as well as time stamp data accurate to microseconds. The new BMX platform has been designed as an embedded or stand-alone control unit for OEM applications, but accessories such as enclosures (IP65 and IP67 compliant) as well as antennas and cabling can be provided as needed. Another auxiliary tool offered by S.E.A. is the RDX Remote Data Exchange Software, which allows automation of the data exchange between the BMX units and central control center without having to program special transfer functions. Science & Engineering Applications, Datentechnik, Troisdorf, Germany. +49 (0)2241 127 37-0. [].

Remote TTL I/O Card Supports up to 32 External Devices A remote 48-point TTL I/O card is designed for fast real-time PCbased control systems. The 7I69 from Mesa Electronics communicates with the host with a robust RS-422 link with up to 100 feet of link length. Standard CAT5 cables are used for wiring convenience. The 7I69 is supported by Mesa’s low-cost FPGA cards, which present a simple parallel register interface to the host, with all protocol details handled by the smart interface. One FPGA card can support up to 32 external devices and up to 3072 control points while still maintaining 10 kHz service rate for all points. The 7I69 provides 48 open collector TTL-compatible I/O points. I/O connectors are two 50 pin headers with I/O module rack compatible pinouts, allowing the 7I69 to drive two 24 point I/O module racks. 7I69 is suited for high-performance industrial automation and machine tool applications. Price of the 7I69 in quantity 100 is $50 MESA Electronics, Richmond, CA. (510) 223-9272. [].



Linux OS-Based AMP Solution Supports Xilinx Zynq-7000 EPP

An open-source Linux OS with Asymmetric Multi-Processing (AMP) support for the Xilinx extensible processing platform (EPP), enables developers to put Zynq-7000 devices to work on applications that need to deliver deterministic, real-time responsiveness for markets such as automotive, industrial and others with similar requirements. The Zynq-7000 is a device that integrates an ARM CortexA9 dual-core processor on the same die with a configurable/ programmable FPGA array. Using open-source Linux and FreeRTOS operating systems and the RPMsg Inter Processor Communication (IPC) framework between the Zynq EPP’s two high-performance ARM Cortex-A9 processor cores, Xilinx is able to simplify the implementation of AMP systems so system software developers can build their systems quickly. In a real-time system, responses to events must occur within a fixed, predetermined time, which can be a difficult task to achieve when the required response time is short and must be handled in a safety relevant manner. Automotive driver assistance applications, or next-generation industrial control systems that integrate the control loop with motor control and safety supervision, are examples of such systems. Multiple events must be processed in these systems, leading to multiple responses, each with a different timing requirement. Implementing a real-time system using the Xilinx AMP solution with the Zynq-7000 EPP means that one processor can run Linux as the master OS, while the other runs the smaller FreeRTOS OS, which focuses exclusively on real-time functions, essentially controlling the complex computational capabilities and data processing that’s performed in the device’s integrated 28nm programmable logic. Communications between the two processors is carried out using the RPMsg standard. Xilinx, San Jose, CA. (408) 559-7778. [].


Single Board Embedded Controllers with Multifunction I/O for Custom Development

Four new single board-level embedded devices for custom embedded control and monitoring applications feature a real-time processor, Xilinx Spartan-6 field-programmable gate array (FPGA), analog and digital I/O and more built-in peripherals. The new Single-Board RIO devices from National Instruments provide engineers with off-the-shelf FPGA and real-time processor technology through NI LabView while maintaining the custom I/O often required for high-volume deployments through the option of a RIO mezzanine card connector. The connector provides direct access to FPGA digital input/output (DIO) lines and certain processor-specific functions for mating custom daughter cards. NI Single-Board RIO alleviates the effort of designing an entire system from scratch so designers can focus on the custom parts of their application, such as the I/O. With the new devices, engineers can achieve shorter time-to-market of an off-the-shelf system along with the I/O customization offered by in-house designs, providing the best of both worlds. The devices also feature built-in analog I/O. The devices’ low cost, small form factor, built-in I/O, real-time processor and FPGA provide a suitable platform for embedded monitoring and control applications in industries such as medical and energy. • NI sbRIO-9623: 256 Mbyte of memory, 128 Mbyte RAM, 16 channels 12-bit analog input, 4 channels 12-bit analog output, 4 DIO, 96 RMC DIO • NI sbRIO-9626: 512 Mbyte of memory, 256 Mbyte RAM, 16 channels 16-bit analog input, 4 channels 16-bit analog output, 4 DIO, 96 RMC DIO • NI sbRIO-9633: 256 Mbyte of memory, 128 Mbyte RAM, 16 channels 12-bit analog input, 4 channels 12-bit analog output, 28 DIO • NI sbRIO-9636: 512 Mbyte of memory, 256 Mbyte RAM, 16 channels 16-bit analog input, 4 channels 16-bit analog output, 28 DIO NI reconfigurable I/O (RIO) hardware combined with NI LabVIEW system design software provides a commercial off-the-shelf solution to simplify development and shorten time-to-market when designing advanced control, monitoring and test systems. NI RIO hardware, which includes CompactRIO, NI Single-Board RIO, R Series boards and PXI-based FlexRIO, features an architecture with powerful floating-point processors, reconfigurable FPGAs and modular I/O. Engineers can program all NI RIO hardware components with NI LabVIEW to rapidly create custom timing, signal processing and control for I/O without requiring expertise in low-level hardware description languages or board-level design. National Instruments, Austin, TX. (888) 280-7645. [].

Pico-ITX Embedded Motherboard with Dual-Core ARM Cortex A9 Processor

A new ARM-based Pico-ITX embedded motherboard is equipped with a dual-core ARM Cortex A9. The KTT20/pITX from Kontron is based on the NVIDIA Tegra2 processor and is the first key element to the planned Low power Embedded Architecture Platform (LEAP) offerings. It is specifically designed as a ready-to-use board for videocentric applications that require an extremely low power profile on a small form factor (SFF). OEMs benefit from the KTT20/pITX and the established Pico-ITX ecosystem in terms of minimized time-to-market and TCO for innovative low power applications. With its standards-based form factor and readily available solutions for housing and cooling, the new embedded motherboard KTT20/ pITX is an easy to implement and cost-efficient building block for application-ready platforms. With a maximum power consumption of only three watts, the new module enables fanless designs with an unprecedented performance per watt ratio and rich graphics capabilities for cost-sensitive SFF applications. And with Kontron’s software support, including board support packages (BSPs) for all relevant operating systems, OEMs can create new applications or scale their applications across all processor platforms with minimal efforts. The Kontron Pico-ITX embedded motherboard KTT20/pITX features the highly integrated NVIDIA Tegra 2 1 GHz super processor with two ARM Cortex A9 cores. It provides up to 1 Gbyte of DDR2 system memory. Up to 512 Mbyte of onboard NAND-Flash and a microSD socket provide non-volatile memory for OS, application software and data. The integrated ultra-low-power NVIDIA GeForce GPU delivers graphic performance for mobile devices in high-resolution gaming console quality. A comprehensive range of hardware accelerations for flash, video and audio codecs ensure fluent and brilliant playback of multimedia and web content on two independent displays that can be connected via single channel LVDS with backlight support and DVI-I interface. The KTT20/pITX supports all common monitor and panel types with resolutions of up to 1920 x 1080 (DVI) respectively 1680 x 1050 (LVDS) pixels. For audio, the embedded Pico-ITX motherboard features SPDIF digital out for 5.1 sound plus stereo line-out and linein and MIC. For networking, the Kontron KTT20/pITX features one 10/100/1000 Mbit RJ45 interface. For application-specific extensions, there is a miniPCIe slot and five USB 2.0 ports that can be used to connect peripherals, such as touch panels, Wi-Fi etc. 3x RS-232 and up to 24 configurable GPIOs round off the feature set. Optionally, the Kontron KTT20/pITX includes a battery charger for 3 cell Li-ion batteries and a wide range power supply for up to 15 VDC. The board supports Windows Embedded Compact 7, Linux and Android. Support for the upcoming Windows 8 is planned. Kontron, Poway, CA. (888) 294-4558. []. RTC MAGAZINE APRIL 2012



ATCA Blade with Dual Xeon Processor E5-2648L and AMC Bay

A next-generation AdvancedTCA (ATCA) processor blade features two 1.8 GHz eight-core Intel Xeon processors E5- 2648 L, the Intel C604 chipset, DDR3-1600 memory up to 128 Gbytes and a PICMG mid-size AMC bay. The aTCA6200 from Adlink Technology has on-card connectivity that includes dual 10GBASE-KX4 Fabric Interfaces, dual GbE Base Interfaces, dual front panel GbE egress ports, CFast socket and quad SAS channels, which provide leading-edge network performance and storage capabilities. The aTCA-6200 is suitable for carrier-grade applications such as media servers in IPTV, IP Multimedia Subsystem (IMS) broadband networks and wireless infrastructures, providing telecom equipment manufacturers (TEMs) and network equipment providers (NEPs) with a flexible, cost-effective solution for missioncritical applications and a reliable, smooth path for scalability and expansion. The new aTCA-6200 provides high-speed data transfer on the PICMG 3.1 Fabric Interface enabled by an Intel 82599EB 10GbE Ethernet controller and Base Interface connectivity provided by Intel 82576EB Gigabit Ethernet controllers. Versatile storage support includes four channels of SAS RAID 0/1, onboard bootable CFast socket, onboard 2.5” SATA drive space, and modular Fabric riser card for additional PICMG Fabric Interface protocols. The mid-size AMC bay supports AMC.1 PCI Express and Advanced Switching, AMC.2 Gigabit Ethernet and AMC.3 SATA/SAS storage expansion. I/O features of the aTCA- 6200 include Base Interface channels, Fabric Interface channels and front/rear egress ports. Front panel I/O includes two RJ-45 GbE ports, three USB 2.0 ports, an RJ-45 to DB-9 standard serial port and a DB-15 connector for analog graphics output. ADLINK Technology, San Jose, CA. (408) 360-0200. [].

Extremely Small Fully Embedded Wi-Fi Module

What is being billed as the world’s smallest fully embedded Wi-Fi module allows fast and easy application development of low power sensor and actuator solutions—enabling devices, machines and other systems to connect directly to the Internet for a wide range of emerging machine to machine (M2M) applications. With the RTX4100 Wi-Fi module, embedding Wi-Fi directly inside a device makes installation extremely simple as it can use existing infrastructure and works “out of the box” with applicable cloud services. The module is suitable for application development due to its small footprint, high efficiency and low power consumption, which is achieved through the use of the Energy Micro EFM32 Gecko MCU and the Qualcomm Atheros AR4100 Wi-Fi System-in-Package. At a time when the growth of the Internet-connectable M2M market is soaring, RTX’s new Wi-Fi module will meet the demand for small low-cost and low-power products. The small RTX4100 Wi-Fi module, measuring just 30x18 mm, reduces the complexity involved in advanced Wi-Fi application designs. Developers can bring their product to market faster using less energy and space compared to existing solutions. This module is an expansion of the Qualcomm Atheros ecosystem that leverages the AR4100 low-power 802.11n Wi-Fi, enabling use of small footprint, low cost and low-power microcontrollers for the “Internet of Things” application space. RTX, Aalborg, Denmark. + 45 9632 2300. [].



Xeon Quad-Core 6U VPX SBC with 10Gig Ethernet Switch

A rugged, high-performance 6U VPX (VITA 46) Single Board Computer (SBC) features a quad-core Intel L5408 Xeon processor and integrated 10 Gigabit Ethernet switch to support full-mesh backplane data layer interconnectivity for up to eight SBCs integrated into a single chassis. Available in air-cooled or conduction-cooled formats, the CPU-11110 from Eurotech conforms to the OpenVPX (VITA 65) payload module profile MOD6PAY-4F2T- with four fat pipes (10 GBase-BX4) and two thin pipes (1000Base-T).

The CPU-111-10 serves as a suitable open-architecture building block for nextgeneration command, control, communications, computers, intelligence, surveillance and reconnaissance (C4ISR) applications onboard (un)manned air / ground vehicles and shipboard platforms. Standard onboard I/O resources includes up to 8x 10 Gigabit Ethernet, 2x 1 Gigabit Ethernet, 4x SATA, 2x USB 2.0, 1x RS-232/485 and 1x VGA video ports. Dual XMC / PMC expansion module sites enable additional I/O expansion, including 10G XAUI lanes from each XMC card to the 10G switched fabric. Offered in both convection-cooled and ruggedized conduction-cooled variants, the CPU-111-10 is designed for use with ANSI/ VITA 46 1.0” pitch VPX form factor backplanes. Air-cooled variants provides a front panel SFP+ port supporting CX4 copper and Fiber applications for chassis-to-chassis and rack-to-rack communications. Conductioncooled variants feature traditional board stiffeners, heat spreaders and wedge locks to passively transfer heat to the chassis and tolerate high shock and vibration environments. An optional Rear Transition Module (RTM) is available that brings out VPX I/O over industry standard connectors. Eurotech, Columbia, MD. (301) 490-4007. [].

Medical Electronic Devices Are Changing the Way We Live. Be Part of the Action!

BRINGING TOGETHER ENGINEERS & DEVELOPERS TO LEARN, ENGAGE AND COLLABORATE ON SOLUTIONS TO POWER THE NEXT ERA OF HEALTHCARE. Free Technical Conference · Keynote Address · Exhibition · Seminars/Workshops · New Product Showcase · Networking

Upcoming Events

April 26th Minneapolis, MN May 15th Boston, MA



industry computing embedded m ord for the ine of rec www.r tcm The magaz

12 March 20


The magaz ine of rec ord for the embedded 2012 computing industry ww


w.r tcmag


I=: LO

C?N M?J>


CPUs ililddss oonn uilild Buui naagggee Bu ggnna ign SSiiig al Sig al ttal gitita igggi ws ws Diiigi D Wiinnndddooow ed Wi bedddddeed mbbe m EEm

ks rks rks work ewo mew Fraame Fr arrree Fra waaare tw fftw oofft Soft So meeennntt oppm llop Devveelo eed De SSpppeee tthhe ng the ing in ing dggin iid idg Brririd B Gap abblllee Ga kab tac taaccckka Stta M/SSta M/ OM CO CO

up An RTC Gro



An RTC Gro up



S ria Se riiall Int Inte nterc rcoonnn rco nneeccts Proov vid ide de Speed and tts Pr Scalability Andr d oid id Po P ise i edd to is to M Move into Embe ve dded A tom Au ttomaate attte Po Powe werr Ma Manna nag age gementt in Industria meen l Sites





Single PrPMC/XMC Supports Three Freescale QorIQ Processor Families

An air-cooled PrPMC/XMC module supports the Freescale QorIQ P3, P4 and P5 processor families. The XPedite5400 from Extreme Engineering Solutions joins the existing XPedite550x line of PrPMC/XMC modules that support the Freescale QorIQ P1 and P2 processor families. The complete line of QorIQ PrPMC/XMC modules provides processor mezzanine solutions that span a broad spectrum of embedded applications and satisfy a wide range of power, performance and feature requirements. The XPedite5400 supports five processors across the QorIQ P3, P4 and P5 processor families. These include the P4040 processor with four PowerPC e500mc cores at up to 1.5 GHz, the P4080 processor with eight PowerPC e500mc cores at up to 1.5 GHz, the P3041 processor with four PowerPC e500mc cores at up to 1.5 GHz, the P5010 processor with one 64-bit PowerPC e5500 core at up to 2 GHz, and the P5020 processor with two 64-bit PowerPC e5500 cores at up to 2 GHz. Key features include a Freescale P4080 processor with eight PowerPC e500mc cores at up to 1.5 GHz (alternate processors P3041, P4040, P5010, P5020) plus two channels of DDR3-1333 ECC SDRAM, up to 8 Gbyte (4 Gbyte each). In addition there are up to 16 Gbyte of user flash and 256 Mbyte of boot flash—with redundancy. There are three Gigabit Ethernet ports plus a x4 PCI Express interface to P15 and two SATA 3.0 Gbit/s ports to the XMC site. Supported operating systems include Linux, Wind River VxWorks and Green Hills Integrity in the form of BSPs. Extreme Engineering Solutions, (608) 833-1155. [].

HD Video Switching, Recording and Network Distribution System

A new approach for deployed platform video management integrates switching, recording and network distribution of high definition (HD) video for aerospace and defense platforms in a single compact rugged unit. The VRD1-CC from Curtiss Wright Controls is a video management system (VMS) that delivers comprehensive functionality in a single unit optimized for SWaP-C-constrained platforms. The VRD1CC speeds and simplifies the integration of HD VMS for applications deployed in harsh environments, such as vetronics and avionics. The conduction-cooled VRD1-CC (an air-cooled variant is also planned) is a lightweight, compact subsystem. A single VRD1-CC unit combines six channels of full resolution HD 30fps MPEG4 H.264 compression, video and audio recording with metadata/event markers, and Ethernet video distribution or storage to disk. A simple, intuitive man-machine interface provides an onboard or remote operator with complete access to the VRD1-CC’s wide range of VMS options and functionality. This powerful VMS supports up to 18 video inputs in a mix of different standards, including HDSDI, RGB and DVI. These video inputs can then be easily routed to any of the VRD1-CC’s 12 video outputs for real-time viewing or routed to the system’s real-time HD video compression subsystem for recording or distribution over a standard Ethernet network. For applications that require multiple video streams to be viewed simultaneously, the VRD1-CC has a real-time scaling engine that scales and positions any four inputs into a single video stream for viewing, recording or distribution. Key features include eighteen video inputs with switching, scaling and windowing, twelve video outputs and four audio inputs and outputs in addition to 3G-SDI embedded audio. MPEG4 H.264 video compression and decompression is supported for up to six HD channels in real time as is network video distribution of raw and compressed video. There is also solid state storage support for up to two removable solid-state drives.

Smart Cooling Pipes Pave the Way for Performance Growth in COM Express

A new cooling system for the COM Express specification is based on cooling pipes, which are integrated in the standardized heat spreader. Introduced by congatec, this solution makes it possible to cool next generation high-performance processors with a power dissipation of well over 35W TDP. “The real problem lies with hot spots around the processor and chipset,” states congatec Product Manager Martin Danzer. “Our improved cooling concept results in a lower processor temperature, which is essential for a more frequent activation of Turbo Boost 2 Technology to ensure maximum COM performance and energy efficiency. As a result, the processor can operate at higher levels than the maximum permitted thermal design power (TDP).” The advantages at a glance: • Fast spot cooling for full performance • Elimination of gap filler layer • Elimination of mechanical stress leads to higher quality • Better cooling extends the life span of the module • Heat pipe principle enables innovative customer-specific cooling concept The new heat pipe cooling design is available in different variants comprising a passive, active and customer-specific solution that creates space for innovative ideas. For example, the heat pipe can be designed in such a way that it can be connected to a customer-specific heat sink. Fanless designs are possible provided the casing is equipped with appropriately sized cooling fins. Ultimately, the design depends on the specific application. The key features of the concept are equally applicable to other electronic circuits. The new cooling solution is also appropriate for systems with low power dissipation. The modules have a higher thermal reserve, which increases their life span and reliability. Average temperature reductions of only 5 Kelvin can double the statistical life span—a convincing argument when considering the total cost over the lifetime of a system. Congatec, San Diego, CA (858) 457-2600. [].

Curtiss-Wright Controls, Charlotte, NC. (978) 952-2017. [].




Conduction Cooled SBC in EMX Basic Form Factor Features Atom E680T

A rugged EMX Basic single board computer (SBC) is based on the Intel Atom E680T CPU running at 1.6 GHz and features dual Gigabit Ethernet ports, 4 serial ports and 4 USB 2.0 ports. The Altair from Diamond Systems is also the first SBC to implement the new EmbeddedXpress (EMX) stackable I/O standard, the next step in I/O connectivity for small form factor embedded computing. Altair supports 1 Gbyte or 2 Gbyte of DDR2 DRAM soldered on board and provides high-resolution LVDS and VGA graphics interfaces. Additional I/O ports include SATA, USB, serial, digital I/O and dual Gigabit Ethernet. Flexible system expansion is based on stackable EMX modules and a PCIe MiniCard socket. A socket is also provided for an optional onboard USB flashdisk of up to 8 Gbytes. Altair’s power-efficient design leverages Intel’s ultra-low-power (Queensbay) silicon platform, consisting of the Atom E680T (Tunnel Creek) processor and chipset (Topcliff). The heat-generating CPU and chipset are located on the bottom side of the SBC, and a conduction-cooled bottommounted heatspreader dissipates heat efficiently to the system enclosure. This configuration leaves the SBC’s top side free for easy access to onboard I/O and expansion sockets. Altair’s rugged features include a wide temperature operating range of -40° to +85°C, soldered-on memory, plus dedicated locations on the PCB to replace configuration jumpers with 0 ohm resistors for resistance to shock and vibration. Conformal coating is also available as an added cost option. EmbeddedXpress is a new form factor specification for embedded computers introduced by Diamond Systems that defines an efficient stackable I/O expansion. The EMX specification enables flexibility, scalability and increased longevity in the final product by providing interchangeable processor modules. Single unit pricing starts at $795. Diamond Systems, Mountain View, CA. (510) 810-2514. [].

Quad-Core ARM Module on Qseven Form Factor

A new generation of ARM-based modules has been initiated by congatec with the introduction of the conga-QMX6 Qseven module. The Qseven standard Revision 1.2, which was published back in September 2010, already prepared the ground for the early optimization of Qseven for dedicated ARM support by adding the I/O interfaces UART and CAN. The conga-QMX6 Computer-On-Module (COM) is equipped with the Freescale i.MX6 ARM Cortex A9 processor family, which is scalable from 1 to 4 ARM cores and sports a high-end, 3D-ready HD graphics interface. The Qseven module will be available in four processor versions, starting with Freescale’s i.MX6 Solo ARM Cortex A9 (1.0 GHz, 512 Kbyte cache) up to the Freescale i.MX6 Quad ARM Cortex A9 (1.2 GHz, 1 Mbyte cache). The standardization of ARM processors has increased in line with the rise in high-performance mobile multimedia devices, leading to more tightly integrated, less application-specific processors with reliable, well-defined interfaces. Freescale’s new i.MX6 family is suitable for the Qseven module form factor, which provides both standard PC interfaces as well as traditional industrial interfaces on the chip. The integrated graphics core is designed for multimedia applications with a video processor unit (VPU), 2D and 3D graphics (GPU2D/3D), four shaders with up to 200 MT/s (million triangles/ second) and a dual stream of 1080p/720p. A dual HDMI v1.4 graphics interface is available, with the second HDMI port shared with LVDS. LVDS also supports 18/24 bit dual channel with a resolution of up to 1920x1200 pixels (WUXGA). A MicroSD socket can be used for inexpensive mass storage; for a more robust application there’s the option of soldering on up to 16 Gbyte solid state drive (eMMC). Differential interfaces including 1x PCI Express 2.0, 2x SATA 2.0, 6x USB 2.0, Gigabit Ethernet, 1x SDIO, CAN bus, LPC and I2S sound are available. The conga-QMX6 module is equipped with the universal boot loader (uBoot). In addition, functions such as Multi Watchdog Timer, CAN and I2C bus are implemented, making the application faster and more reliable, even when the system is in standby mode. Congatec, San Diego, CA. (858) 457-2600. [].



CompactPCI Serial Multi-Display Controller with AMD Radeon GPU

A new CompactPCI Serial peripheral board offers excellent graphics performance thanks to the AMD Radeon E6760 GPU and is especially suited for multi-display applications. The G214 from Men Micro is used in control rooms for (video) surveillance, in simulators, in professional audio/video equipment as well as in digital signage applications. Thanks to AMD’s Eyefinity technology, which is supported by the E6760 GPU on the G214, up to six different displays can be controlled independently. The standard version of the G214 is equipped with four DisplayPort 1.2 interfaces at the front, which have a maximum resolution of 4096x2560 at 60 Hz and a color depth of 24 bpp. By choosing a wider front panel, two additional DisplayPorts with a resolution of 2560x1600 can be accommodated. The GPU offers 480 stream processors with a frequency of 600 MHz—having a power dissipation of only 35W. Key features of the G214 include the AMD Radeon E6760 GPU running at 600 MHz, six SIMD engines, 480 shaders and 1 Gbyte integrated graphics RAM. It supports AMD EyeSpeed, Eyefinity and HD3D Technology along with DirectX 11, OpenGL 4.1 and OpenCL 1.1. The G214 has up to 6x DisplayPort (4x DP 1.2, 2x DP 1.1a) with a maximum resolution of 4096x2560 at 60 Hz and 24 bpp. There is also one PCIe x8 CPU interface. The OpenCL standard supported on the E6760 GPU makes it possible to increase the computing power using GPGPU (general purpose computation on graphics processing unit). As the GPU executes the programs with a high level of parallelism, speed is increased considerably. A 3D graphics engine and Microsoft’s DirectX 11 make for increased graphics performance. The AMD Unified Video Decoder functionality supports the H.264, VC-1, MPEG-2 and MPEG-4 formats. MEN Micro, Ambler, PA. (215) 542-9575. [].


3U OpenVPX Xilinx Virtex-6 FPGA Board with FMC Site

A 3U OpenVPX front-end processing board boasts a flexible Virtex-6 FPGA and a FMC site (VITA 57.1). The IC-FEPVPX3b from Interface Concept is suitable for applications such as radar, sonar, electronic warfare, imaging and communications, by offering high-performance logic and powerful digital signal processing slice resources, while maintaining low power. The FMC site, being VITA 57.1 compliant, interconnects ADC, DAC, general IOs, video, Serial FPDP cards, or additional FPGA FMC modules. In terms of processing unit, the board, based on a Xilinx Virtex-6 FPGA, offers two banks of 40-bit 1.25 Gbyte DDR3 memory and a Spartan-6 control node. Complying with the VPX standard, the IC-FEP-VPX3b features four 4-lane fabric ports on the P1 and general purpose IOs (on P2). The board is available in standard, rugged and conduction-cooled grades and comes with the Xilinx ISE design tool. Interface Concept, Quimper, France. +33 02 98 57 30 30. [].

COM Express Mini Computer-on-Module with Dual Core Processors

A COM Express Module with dual-core processing power is the latest addition to the family from Kontron of products formerly named nanoETXexpress modules, and is based on next-generation Intel Atom processors N2600, N2800 and D2700. Optimized for low-power, small form factor designs, the PICMG COM Express Type 10 pin-out COMemCT10 provides up to twice the graphics power, up to 28% higher processor performance and processor thermal design power (TDP), which is cut in half as compared to second generation Intel Atom processors. The platform’s enhanced power management features include Intel Deeper Sleep and Intel SpeedStep Technology and enable thinner and lighter low power designs such as robust mini handheld terminals that benefit from 20 percent improved battery life compared to the previous generation. Intel Smart Connect Technology enables usage scenarios where an instant Internet connection is available as soon as a device is (re)activated and also allows for constant updates even while in standby. Furthermore, Intel Rapid Start Technology enables fast resume from standby mode and helps to conserve battery life. The COMe-mCT10 Computer-on-Modules are equipped with 2x 1.6 GHz, 2x 1.86 GHz or 2x 2.13 GHz Intel Atom processors (N2600, N2800 and D2700) as well as the Intel NM10 Express chipset and up to 2 Gbyte of fast onboard DDR3 800/1600 system memory. The integrated Intel Graphics Media Accelerator 3600/3650 combined with the integrated memory controller provides enhanced performance and system responsiveness with twofold graphics performance compared to the previous generation platform. A dedicated media engine enables full 1080p high definition playback of videos and BluRay. The COM Express Type 10 pin-out complete with two serial interfaces results in the COMe-mCT10 supporting two independent digital displays with either 1x LVDS 18-bit 1366x768@112 MHz (N2600/2800) or 1x LVDS 24-bit 1440x900@112 MHz (D2700) and 1x DisplayPort. The module also offers two different options for data storage: either 2x SATA II 300 Mbyte/s interfaces or versions with soldered on SATA Flash Memory (up to 8 Gbyte SLC- or 32 Gbyte MLC-Flash) and 1x SATA II 300 Mbyte/s. Further interfaces include 8x USB 2.0, Gigabit Ethernet, plus 3x PCI-Express x1 lanes for custom extensions. The Kontron Computer-on-Module COMe-mCT10 supports a wide range of operating systems including Wind River VxWorks 6.8, Linux, Windows XP, XPe, WEC 7 and WES 7 where Windows 8 support is planned. Kontron, Poway, CA. (888) 294-4558. [].

Cloud Operating System Supplements Supplied Embedded OS

Ad Index

The practice of supplying complex embedded systems (COMs = Computer-on-Modules, SOMs = System-on-Modules) together with a specific operating system is the norm for nearly all manufacturers today. SSV Software Systems is now going one step further. Intechnology addition toand the Get Connected with embedded operating system, a cloud operating system will benow offered as companies providing solutions an option for selected modules.Get This operatingissystem is usedforonfurther a rootexploration Connected a new resource server on the Internet. Both into ope¬rating systems are interconnected to your goal products, technologies and companies. Whether form a distributed to research the latest datasheet from a company, speak directly an Application Engineer, or jump system to a company's The embeddedwith operating system is a Linux whosetechnical kernel page, the goal of Get Connected is to put you in touch with the right resource. has been optimized for mi-nimum resource use. In other words, the Whichever level of service you require for whatever type of technology, kernel contains onlyGet theConnected drivers andwill functions nee¬ded particular help you connect withfor theacompanies and products hardware module. This results you are searching for. in very low memory ments and very fast boot-up. In addition to the kernel with a TCP/IP stack for IPv4 and IPv6, the scope of de¬livery includes a file system developed for use in flash memory Get Connected with technology and companies prov modules and an SSV/ECC Get Connected is a new resource for further exploration into pro driver for cloud communicadatasheet from a company, speak directly with an Application Engine tion. in touch with the right resource. Whichever level of service you requir Get system Connected will help the companies The cloud operating is based onyoua connect Debianwith Linux server and produc system for x86 platforms that has been expanded to include a special (cloud) service framework. Different scalable servi¬ces run within this framework, some of which communicate directly with the embedded ope¬rating system. Other services offer, for example, Web-based user interfaces (SSV/WebUI) for monitoring the current operating status of an embedded system over the Internet or a da¬ta logger for long-term data recording with E-mail alerts. Also available is a special VPN rendezvous service that enables an SSL/TLS-based VPN to be established between embedded systems and remote maintenance PCs of external support personnel. Typical applications for these interconnected systems include web pages whose purpose is to allow status monitoring via a smartphone or Get Connected withmonitoring companies andof important system funcPC browser, automatic remote productsnotification, featured in thiscentral section.configuration and software manations with e-mail gement, and VPN-secured remote access at the system level.


SSV Software, Hanover, Germany. +49 (511) 40 00 042. [].

Get Connected with companies and products featured in this section.




WiFi Modules Feature Soft AP Support For Easy HotSpot Device Integration

A family of WiFi modules provides easy WiFi connectivity through any processor-based device. With support for the latest wireless standards -- including 802.11b/g/n -- and USB 2.0 connectivity, the WiFiHU2 from Radicom Research offers next-generation WiFi transmission, all at a last-generation price. The WiFiHU2 features reliable transmissions, protocol stack, and integrated 2TX/2RX MIMO antenna technology for maximum over-the-air throughput of 300Mbps downstream and 300Mbps upstream (PHY rates using 40MHz bandwidth). Optimal analog transceiver performance is achieved through fast receiver Automatic Gain Control (AGC) with synchronous and asynchronous control loops among antennas, antenna diversity functions, and adaptive transmit power control functions. Designed for industrial OEM use, the WiFiHU2 features low overall power consumption and extreme temperature capabilities (-40°C to +85°C), all in a small footprint. WEP/WPA/WPA2 security protocols ensure host protection and firmware/configuration parameters are stored in on-board NVRAM. Soft AP support transforms any WiFiHU2 device into a WiFi wireless access point, allowing nearby WiFi devices (smartphones, tablet devices, etc.) to connect to the internet. Radicom’s WiFiHU2 series comes in two models: WiFiHU2a and WiFiHU2-c. The WiFiHU2-a model enables a faster timeto-market with built-in dual-chip antennas, eliminating the need for costly and time-consuming RF development. The WiFiHU2-c model offers OEM design flexibility for antenna location using two U.FL connectors to attach antenna cables and antennas. Bulk pricing and custom OEM specifications are available. WiFiHU2-a and WiFiHU2-c are now available with prices starting at US$19.00 in quantities of 1,000 pieces. Radicom Research, San Jose, CA. (408) 383-9006. [].

Algorithmic Memory Technology: Speeding the Design of Embedded Multiport Memory

A new technology to enhance embedded memory has been dubbed Algorithmic Memory Technology by its inventor, Memoir Systems. Now available in as a product family called Rennaissance 2X, it creates new multiport embedded memories by combining algorithms with standard 1-port SRAM, the technology brings a new approach to embedded memory development across the semiconductor industry. Renaissance 2X offers four separate memory generators: a 2 port (1R1W), a dual port (2RW), and specialty memories for 2Ror1W and 1RW1W. Renaissance 2X eliminates the need to build multiple variants of dual-port and 2-port physical compilers based on the conventional 8-transistor memory bit cells for new process nodes. As a result, customers benefit from dramatically improved time-to-market and timefor-adoption of new process nodes, reduced development cost and

maintenance effort, and lowered risk to build embedded multi-port memories. Furthermore, Renaissance 2X offers up to 30% increased clock speeds and up to 50% area and power savings over comparable industry-standard physical memory compilers. Perhaps the most fundamental change Renaissance 2X brings is that it eliminates the need for specialized 8-transistor bit cell development. While single-port memories use 6-transistor bit cells, traditional dualport and 2-port memories require specialized 8-transistor bit cells. This requires extra effort to develop an additional set of physical compilers, and also necessitates extensive silicon validation and characterization. It also means maintaining several versions of these compilers for high density and high speed versions, and for several process variants. This then delays chip design starts on a new process node. In contrast, Renaissance 2X creates dual-port and 2-port memories by building on 1-port SRAM, thus obviating the need for 8-transistor dual-port and 2-port bit cells and avoiding the associated costs, risks and delays. Furthermore, since the new memories are constructed from IP which has been exhaustively formally verified, no further silicon verification is required.Renaissance 2X Generators are available now and list pricing starts at $250K plus royalties. With Algorithmic Memory technology, Renaissance 2X provides faster time to tape out chips on a new process node, significantly reducing area and power, increasing performance, providing applicationoptimized memories for a variety of usages, lowering total memory development and ownership cost, and reducing SoC design risk by eliminating the need for further silicon validation. Memoir Systems, Santa Clara, CA. (408) 550-2382. [].




3U VPX Development System for Multiple Processing Node Applications

A Requirements Engineering Solution for Embedded Systems

The SY VPX/507 is based on an EMC enclosure, incorporating an integrated power supply and cooling fans, providing the user with a total of seven slots: one slot is reserved for the fabric switch and one slot is reserved for the system controller SBC. The remaining five slots can be populated with SBCs or peripheral cards. The backplane is compliant with the OpenVPX BKP3-CEN07-15.2.3.n profile, interconnecting each of the six slots with the fabric switch via a PCI Express (PCIe) fat pipe on the data plane and a 1000 Base-BX (SerDes) link on the control plane. The pre-installed boards supplied by Concurrent Technologies are compatible with the OpenVPX (VITA 65) specification and are fitted as follows: • System Controller Slot: TR 803/592 - 2.2 GHz 2nd generation Intel Core i7-2655LE SBC with 8 Gbytes Flash Module and RTM • Peripheral Slot: TR 803/592 - 2.2 GHz 2nd generation Intel Core i7-2655LE SBC with 8 Gbytes Flash Module and RTM • Fabric Switch Slot: FR 331/506 - VPX Fabric Switch Board providing switching for six x4 PCIe data plane ports and six 1000 Base-BX (SerDes) control plane ports Concurrent Technologies provides a range of additional 3U VPX modules to further enable customization of the SY VPX/507 development system—including SBCs, Fabric Switches, Mass Storage solutions and Carrier Boards. The TR 803/592 supports many of today’s leading operating systems, including Linux, Windows, VxWorks and QNX, thereby making the SY VPX/507 suitable for a wide range of user configured applications. In addition, the SY VPX/507 is supported by Concurrent Technologies’ Fabric Interconnect Networking Software (FIN-S), which provides a high performance, low latency, communications mechanism for multiple host boards to intercommunicate across high-speed serial fabrics like PCI Express (PCIe).

Visure Solutions, Ontario, Canada. (514) 944-0154. [].

A free-standing, centrally switched, 7-slot 3U VPX development system is designed to aid in bench development of applications where the computation power of multiple SBCs is required. To enable rapid development, the SY VPX/507 from Concurrent Technologies comes pre-installed with two dual core processor SBCs (supporting the 2nd generation Intel Core processor) with onboard flash, associated reartransition modules and a fabric switch board. An additional four slots are available for system expansion. Typical applications include industrial control, transport, aerospace, security and defense applications.

Concurrent Technologies, Woburn, MA. (781) 933-5900. [].



The IRQA Systems Engineering Template, an extension to the IRQA Requirements Engineering Suite from Visure Solutions, is designed to address the challenges of increasingly complex embedded software systems. Embedded systems raise a plethora of design issues—diversity of platforms and architecture, increased regulatory compliance, mechanical constraints—that create a complex requirements matrix that can no longer be maintained through manual methods. As a field-proven requirements engineering, IR specification and change management tool, Visure Solutions’ IRQA offers companies a way to gain assurance that their software functions as specified and can meet product deadlines. Applied to the Embedded Software Requirements Lifecycle, IRQA becomes the process backbone. The requirements process metamodel, including all the requirement-related artifacts, their relationships and their interactions with the users, are graphically represented, showing compliance through all stages of software development. IRQA helps standardize and enforce the requirements definition across the organization, formalize a common requirements specification structure, and handle changes throughout the lifecycle. With IRQA, project collaboration—whether between various software groups or with hardware or mechanical contributors—becomes easier as specific information can be communicated and shared both inside and outside the company. IRQA helps avoid pitfalls and mitigate risk at all levels, from writing better requirements and prioritizing needs to providing the industry’s best change impact analysis capabilities. As requirements are written, IRQA Quality Analyzer performs semantic analysis to give each requirement a quality rating based on such weaknesses as ambiguous words, conditional sentences, poor structure, implementation suggestions, overlapping requirements, inconsistent use of units, and even legibility. For FMEA standards, the IRQA Systems Engineering Template includes the capability for risk assessment when performing failure modes and effects analysis. IRQA’s change impact analysis ensures that midstream requirements changes don’t breach the feasibility constraints or create budget overruns. IRQA supports a wide range of development processes, including traditional V and waterfall, as well as supporting the shift toward a more iterative process. Thanks to a central repository, developers are not limited to a web experience, but gain desktop control with the complete functionality of the IRQA solution, even when geographically dispersed throughout the world. IRQA’s structure also supports product families and variants, ensuring that a well-defined set of requirements will be faithfully rendered for each project without the error-prone work of recreating those requirements each time.





Advertiser Index Company



ADLINK Technology, Inc...................................................................................................... Advanced Micro Devices, Inc............................................................................................. 68................................................................................................................. American Portwell............................................................................................................. 63............................................................................................................ Commell........................................................................................................................... Design Automation Conference.......................................................................................... Elma Electronic, Inc........................................................................................................... Express Manufacturing, Inc............................................................................................... 67............................................................................................................... Extreme Engineering Solutions, Inc.................................................................................... 11............................................................................................................. Innovative Integration......................................................................................................... 31.................................................................................................. Intel Corporation............................................................................................................. 34, JK Microsystems, Inc.......................................................................................................... 4.............................................................................................................. Kontron America............................................................................................................... Lauterbach........................................................................................................................ 44........................................................................................................ Logic Devices, Inc............................................................................................................. Logic Supply, Inc............................................................................................................... Magma............................................................................................................................. Mathworks, Inc.................................................................................................................. Measurement Computing Corporation................................................................................ 40............................................................................................................ MEDS............................................................................................................................... 57...................................................................................................... MEN Micro, Inc................................................................................................................. 36.................................................................................................................... MSC Embedded, Inc.......................................................................................................... One Stop Systems, Inc...................................................................................................... PC/104, PC/104 Express & ISM Showcase........................................................................ 41........................................................................................................................................ Phoenix International.......................................................................................................... 4............................................................................................................ Real-Time & Embedded Computing Conference.................................................................. 65................................................................................................................ RTC magazine................................................................................................................... Super Micro Computer, Inc................................................................................................. 5........................................................................................................ Themis Computer.............................................................................................................. 27.............................................................................................................. Trenton Systems................................................................................................................ 37................................................................................................. VITA.................................................................................................................................. WDL Systems.................................................................................................................... Xembedded.......................................................................................................................


A seasoned embedded technology professional? Experienced in the industrial and military procurement process? Ever thinking about writing as a career? CONTACT SANDRA SILLION AT THE RTC GROUP TO EXPLORE AN OPPORTUNITY RTC (Issn#1092-1524) magazine is published monthly at 905 Calle Amanecer, Ste. 250, San Clemente, CA 92673. Periodical postage paid at San Clemente and at additional mailing offices. POSTMASTER: Send address changes to RTC, 905 Calle Amanecer, Ste. 250, San Clemente, CA 92673.



Visit us at the Del Mar Electronics Show Booth #1109 ->˜Ê ˆi}œ]Ê ʜ˜Ê>ÞÊӇÎ]ÊÓä£Ó ÜÜÜ°ÛÌðVœ“


MAKE EMI YOUR MEDICAL MANUFACTURING PARTNER. We offer: UÊ iÈ}˜ÊÛiÀˆvˆV>̈œ˜ÊEÊ«ÀœÌœÌÞ«iÊ Û>ˆ`>̈œ˜ UÊ*>VŽ>}i‡œ˜‡*>VŽ>}iÊ­*œ*®Ê ÌiV…˜œœ}ÞÊvœÀʅˆ}…Ê`i˜ÃˆÌÞÊ *  UÊ“iÀˆV>˜ÊœÜ˜i`ÊEʜ«iÀ>Ìi`Ê v>V̜Àˆià ­1-Ê>˜`Ê …ˆ˜>®Êà ÃÌÀˆ˜}i˜ÌÊ*Ê«ÀœÌiV̈œ˜ UÊ/ÕÀ˜ŽiÞÉ *Ê-iÀۈViÃʈ˜VÕ`i\Ê i˜}ˆ˜iiÀˆ˜}ÊÛ>Õi‡>``]Ê «Àœ`ÕV̈œ˜ÊÃÕ««œÀÌ]Ê«>VŽ>}ˆ˜}Ê >˜`Ê}œL>ÊœÀ`iÀÊvՏvˆ“i˜Ì UÊ+ՈVŽÊ̈“iÊ̜ʓ>ÀŽiÌ UÊ-"Ê£Î{nx\ÓääÎÊViÀ̈vˆV>̈œ˜ UÊ-"ʙää£\ÓäänÊViÀ̈vˆV>̈œ˜



Fueling Innovation for Tomorrow’s Technology……Today AMD is ushering in a new era of embedded computing. The AMD Embedded G-Series processor is the world’s first integrated circuit to combine a low-power CPU and discrete-level GPU into a single embedded Accelerated Processing Unit (APU).

AMD is also proud to offer extended availability of the AMD Geode™ LX processor family until 2015.

Learn more about new levels of performance in a compact BGA package at: © 2011 Advanced Micro Devices, Inc. All rights reserved. AMD, the AMD Arrow logo, ATI, the ATI logo and combinations thereof are trademarks of Advanced Micro Devices, Inc. Other names are for informational purposes only and may be trademarks of their respective owners. Features, performance and specifications may vary by operating environment and are subject to change without notice. Products may not be exactly as shown. PID# 50599C

RTC magazine  

April 2012

Read more
Read more
Similar to
Popular now
Just for you