RTC magazine

The magazine of record for the embedded computing industry

July 2010

www.rtcmagazine.com

MEDICAL DEVICES: SMALLER, MORE POWERFUL, MORE CRITICAL

Pick the Right Small Form Factor SBC Embedded Java Moves to Multicore Tools and Discipline Assure Software Quality An RTC Group Publication

Source code analysis for critical embedded code

CodeSonar®

Chosen by the most demanding customers.

GrammaTech CodeSonar performs whole-program, interprocedural source code analysis on your code, identifying programming bugs that can result in system crashes, memory corruption, and other serious problems.

• Take Control of Quality • Identify Trends and Recurring Problems • Try it for Free

WWW.GRAMMATECH.COM

MEDICAL DEVICES:

Smaller, More Powerful, More Critical

42 OpenVPX Tackles PED Challenge with GPU-Based Rugged Solution

44 32 Gbyte Type 1 CompactFlash Card Has Wear Leveling Data Integrity Features

TABLEOF CONTENTS

47 High-Performance GigE-based Vision Appliance for Multi-Camera Use

JULY 2010

Departments

Technology in Context

technology in systems

Small Form Factor SBCs

Embedded Java

Stackable Single Board Java Tackles Multicore Complexity 5Editorial 14 NASPI: Building the Foundation for Computers: Choosing between the 26 New Opportunities for Embedded Form Factors technology deployed 6Industry Insider Latest Developments in the Embedded Kelvin Nilsen, Atego Systems

Dr. Qi Chen, Adlink Technology

Marketplace

9Small Form Factor Forum SFFs Adapt or Perish & Technology 42Products Newest Embedded Technology Used

by Industry Leaders

EDITOR’S REPORT From M2M to Sys2Sys

10

Technology connected Quality Assurance for Software

Medical Devices

Software Quality in Embedded Medical Devices 30Ensuring

Static Analysis: Evaluating Tools to Optimize ROI 18 Advanced Medical Device Software: Why Has It Gone Code Red? 34 Time to Rethink Software Testing 22 for Embedded Devices Embedded Technology Powers Device Accessory 38Healthcare to Improve Patient Ventilator Elijah Kerry, National Instruments

Paul Anderson, GrammaTech

Bill StClair and Nat Hillary, LDRA

Paul Henderson, Wind River

DDS Component Links Incompatible Network System Interfaces to Build Multisystem Applications

Monitoring

Pete Dombrowski, Eurotech

Tom Williams

Digital Subscriptions Avaliable at http://rtcmagazine.com/home/subscribe.php RTC MAGAZINE JULY 2010

3

JULY 2010 Publisher

Advertising/Web Advertising

PRESIDENT John Reardon, johnr@rtcgroup.com

WESTERN REGIONAL ADVERTISING MANAGER Stacy Mannik, stacym@rtcgroup.com (949) 226-2024 WESTERN REGIONAL ADVERTISING MANAGER Lauren Trudeau, laurent@rtcgroup.com (949) 226-2014 EASTERN REGIONAL ADVERTISING MANAGER Shandi Ricciotti, shandir@rtcgroup.com (949) 573-7660

Editorial EDITOR-IN-CHIEF Tom Williams, tomw@rtcgroup.com CONTRIBUTING EDITORS Colin McCracken and Paul Rosenfeld MANAGING EDITOR Marina Tringali, marinat@rtcgroup.com COPY EDITOR Rochelle Cohn

ASIAN REGIONAL SALES MANAGER Jessica Marinescu, jessicam@rtcgroup.com (+852) 2548 5100

Billing Cindy Muir, cmuir@rtcgroup.com (949) 226-2021

Art/Production CREATIVE DIRECTOR Jason Van Dorn, jasonv@rtcgroup.com ART DIRECTOR Kirsten Wyatt, kirstenw@rtcgroup.com GRAPHIC DESIGNER Christopher Saucier, chriss@rtcgroup.com GRAPHIC DESIGNER Maream Milik, mareamm@rtcgroup.com WEB DEVELOPER Hari Nayar, harin@rtcgroup.com

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, www.rtcgroup.com Editorial Office Tom Williams, Editor-in-Chief 245-M Mt. Hermon Rd., PMB#F, Scotts Valley, CA 95066 Phone: (831) 335-1509 Fax: (408) 904-7214 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.

Delivers enhanced performance,

energy efficiency, manageability, security functions & smoother visual experiences The new Intel® Core™ i7 processor, 32nm process technology Avalue QM57 series verified Intel® AMT6.0 AMT6 0 compliant ECM-QM57

3.5” SBC

Intel® Core™ i7-620LE/ 620UE 3.5” Micro Module with Intel® QM57 Chipset Onboard Intel® Core™ i7-620LE/ 620UE Processor Intel® QM57 Chipset One 204-pin DDR3 SODIMM Up to 4GB DDR3 800/ 1066 SDRAM Dual View, 2-CH LVDS, VGA, HDMI 5.1-CH Audio, Dual Intel® Gigabit Ethernet 2 SATA, 2 COM, 7 USB, 16-bit GPIO Support iAMT 6.0

Avalue Technology Inc. 200 Tornillo Way, Suite 210, Tinton Falls, NJ 07712

4

Untitled-24 1

JULY 2010 RTC MAGAZINE

EPI-QM57

EPIC

Intel® Core™ i7-620LE/ 620UE EPIC Module with Intel® QM57 Chipset Onboard LV/ ULV Intel® Core™ i7 Processor Intel® QM57 Chipset One 204-pin SODIMM Up to 4GB DDR3 800/ 1066 SDRAM, Non-ECC Dual View, 2-CH LVDS, DVI-I Dual Intel® Gigabit Ethernet 1 CF, 4 SATA, 2 COM, 8 USB, 16-bit GPIO Options: Express Card/ 34mm, Built-in Touch Screen Interface Support iAMT 6.0, RAID 0/ 1/ 5/ 10

Tel: (732) 578-0200 Fax: (732) 578-0250 E-mail: sales@avalue-usa.com www.avalue-tech.com 6/15/10 3:39:03 PM

EDITORIAL JULY 2010

Tom Williams Editor-in-Chief

NASPI: Building the Foundation for New Opportunities for Embedded

T

here has long been a story (which, alas, turns out to be a myth) that in 1899 the head of the U.S. Patent Office sent his resignation to President McKinley because “everything that could be invented has been invented.” We in the optimistic age of innovation chuckle at that notion, which even though it never happened, makes for a good story and reminds us that we still have enormous problems and challenges to solve for which all of our inventive powers will be required.

It is true that today there is a vast number of embedded applications for which Gigahertz multicore processors are simply overkill. But these devices were not designed and produced for mere amusement. They have applications screaming for their capabilities. There is another, probably equally apocryphal, story that a young software developer was admonished to build his code with enough features and functionality to bog down his current development platform, because by the time he got the code developed and debugged, processor performance would be on hand that could easily run it. Of the two stories, the latter seems more believable.

Recently, as we have all been aware, the issues of energy have been much in the news as have issues of industrial safety. Creating solutions in both these areas opens huge opportunities for high-end computing power. One intriguing area is the underlying infrastructure for the Smart Grid. When we mention the Smart Grid, what usually first comes to mind are smart meters and smart appliances that can connect when rates are optimal, and smart monitoring of power usage in the home. But a much more fundamental structure must be added to the national power grid to make it more reliable, less susceptible to wide area blackouts, and better able to accommodate less centralized sources of generation like wind, solar and geothermal. This is known as the North American SynchroPhasor Initiative (NASPI).

NASPI envisions a grid-wide network system that will take input from devices called phasor measurement units (PMUs) located at strategic points around the grid such as substations and switching facilities.

The PMUs measure the voltage and current of electrical waveforms on the grid at a rate of 30 samples per second and send their data to the NASPI network. Since accurate time stamping is required for the data, PMUs synchronize using GPS signals, hence the name SynchroPhasor.

The initiative envisions a large number of such PMUs that would input

their data to phasor data concentrators (PDCs), and then by way of phasor gateways (PGs), onto the real-time, grid-wide NASPInet data bus.

At various monitoring centers there will be systems that archive the data as well as run applications that can make use of it for detecting potential failures and or responding to failures in a timely enough manner to avoid huge disruptive blackouts. There will also be strategically placed intelligent electronic devices (IEDs) that can receive data and issue control commands, such as tripping circuit breakers if they detect anomalous conditions. Applications will enable operators to do things like visualize grid conditions using Google Earth overlays.

Historical data will be available for later analysis and improvement.

The ambitions of the NASPI project alone will call for enormous embedded (and IT) computing resources as well as network and highspeed I/O. And as for software development, well . . .

Note that NASPI does not itself appear to be what we normally think of as the “Smart Grid.” However, it does provide an infrastructure and a foundation of basic data that can be utilized in realizing a smart grid, and it represents a huge opportunity for embedded computing engineers and companies to support the different expertise and goals of electrical power engineers who are working to modernize the North American power grid in order to make it more reliable and more efficient. It is upon this foundation that it will be possible to implement an advanced metering infrastructure (AMI) and the visualization technologies that will enable the reliable connection of decentralized power sources, the intelligent metering that can account for energy put onto the grid as well as energy drawn from the grid by individual consumers. It will enable applications that can detect impending failures and provide for the more efficient distribution of power across the grid. Minimizing the distance from electricity generation to electricity consumption has the potential for enormous savings.

This will be made possible by the vision and expertise of power engineers teamed with the expertise of embedded developers and semiconductor manufacturers. By building on a solid infrastructure, the potential of smart appliances can be realized, the inclusion of alternative energy sources can be achieved, and a vast number of applications can be developed that we may not have thought of yet. It turns out that there are a whole bunch of things that haven’t been invented yet.

RTC MAGAZINE JULY 2010

5

INDUSTRY

INSIDER JULY 2010 OpenVPX System Specification Standard Reaches ANSI Ratification The VMEbus Industry Trade Association (VITA), has announced the ratification by ANSI of the OpenVPX System Specification under ANSI/VITA 65.0-2010. OpenVPX is the architecture framework that defines system-level VPX interoperability for multivendor, multimodule, integrated system environments.

The VITA 65 working group set an aggressive goal to have the ANSI ratification completed by the spring of 2010. They have achieved that pace-setting goal by completing the criteria for a successful ballot.

VPX is gaining design wins in many data-intensive applications where performance in throughput and highcompute density (size) are critical factors. Example applications in which VPX systems are expected to be deployed in the coming year include signal and video processing, radar, communications, transportation, and control and management.

VPX is a broadly defined technology utilizing the latest in a variety of switch fabric technologies in 3U and 6U Eurocard format modules. The OpenVPX framework delineates clear interoperability points necessary for integrating module to module, module to backplane, and chassis. OpenVPX will evolve and incorporate new fabric, connector and system technologies as new standards are defined.

In support of the VPX family of specifications, VITA members have been rolling out a wide range of products suited to a variety of applications, from backplanes and chassis to 3U and 6U boards of various types. Nearly 100 products are already listed in the VITA product directory under OpenVPX, and more are added each week. With the completion of this specification, suppliers are now identifying their products with the profile information necessary to make product selection for specific profiles.

Companies that develop VPX products are encouraged to contact VITA to join the VPX Marketing Alliance. For more information, visit the VPX Marketing Alliance website at www.vita.com/vpx. The ANSI/VITA65-2010 document is available from VITA.

Smart Meter Penetration in Asia-Pacific Predicted to Reach 25 Percent by 2015

According to a new research report from the analyst firm Berg Insight, the installed base of smart electricity meters in Asia-Pacific will grow at a compound annual growth rate of 91.0% between 2009 and 2015 to reach 116.5 million at the end of the period.

Penetration for smart metering technology is projected to soar from very low levels to 25.0% by the end of that period. By the mid2010s, the majority of all electricity meters shipped in the region is expected to have advanced functionalities and networking capabilities. Berg Insight anticipates that the leading economies in the region will have close to 100 percent penetration by 2020.

6

JULY 2010 RTC MAGAZINE

Australia and New Zealand commenced with massive installations of smart meters at the end of the last decade. Victoria will become the first Australian state to achieve full penetration by 2013.

Mandatory rollouts are also being considered in other territories such as New South Wales. In New Zealand, the adoption of smart metering is driven by the energy industry. While many other countries have introduced regulations for the new technology, New Zealand’s government has decided not to interfere with the process.

EnOcean and Texas Instruments Agree to Expand Energy Harvesting Cooperation

EnOcean and Texas Instruments (TI) have announced the expansion of their cooperation

to provide innovative wireless solutions for building automation. Through this agreement, the companies will jointly create solutions enabling self-powered wireless sensor networks.

To further optimize its product portfolio, EnOcean will integrate TI components in its energy-efficient wireless modules.

EnOcean’s battery-less wireless technology harvests energy from its surroundings—motion, light or differences in temperature— and enables new ecologically minded self-powered wireless applications.

Texas Instruments and EnOcean have collaborated since 2005 and TI components have been implemented in a variety of EnOcean modules. TI has also been a member of the EnOcean Alliance since 2008, working with other members of the Alli-

ance on energy-efficient solutions for green buildings.

“Energy harvesting wireless technology reduces the installation cost of lighting, heating/air conditioning control and monitoring by up to 70 percent. This technology enables long-term energy conservation and sustainability for our customers,” said Laurent Giai-Miniet, general manager of TI’s Low-Power RF business unit. “Cooperation with EnOcean is an important step toward gaining a firm foothold in a fast growing market. The deciding factor in the expansion of our relationship with EnOcean was their proven expertise of energy harvesting technology, with wide market experience and a broad customer base.”

Comm-Works Announces Partnership with Advanced Telemetry

Comm-Works LLC has announced that it has secured a reseller relationship with Advanced Telemetry, a developer of proprietary, smart energy and resource management systems for both residential and small commercial applications.

“As a part of Comm-Works’ Total Energy strategy,” said Al Lampe, CEO of Comm-Works, “we found some significant synergies between our customers’ business requirements for their remote locations and Advanced Telemetry’s EcoView Energy Management System.

We are excited to work together with Advanced Telemetry to offer an efficient and costeffective solution to our customers.”

“Through an escalating number of real-world installations, this user-friendly energy management system has proven its ability to reduce utility bills

by as much as 25% and deliver a return on investment in just 6 to 12 months,” notes Advanced Telemetry CEO, Tom Naylor.

“EcoView now allows CommWorks to address the unique needs of previously underserved business owners with an affordable and effective solution specifically designed for small to mid-size facilities.”

EcoView Commercial Features: • On-site “dashboard” touch panel for local control of thermostat settings within limits predefined

by Advanced Telemetry and the customer

• Components communicate wirelessly enabling easy retrofit •W eb-based interface for realtime access, monitoring, reporting and remote thermostat control •C entralized, remote control of thermostats including set points, schedules, and heating and cooling limits that eliminates suboptimal local control •E coView Commercial can monitor and manage lighting, and other devices that would benefit from scheduling

Dot Hill Systems and Xiotech to Partner for Storage Virtualization Solutions

Dot Hill Systems has announced that it has signed a letter of intent to enter into a technology partnership with Xiotech to enable new virtual storage solutions. This is Dot Hill’s first major collaboration involving the Intelligent Storage Networking (iSN) software platform acquired in January 2010 along with Cloverleaf Communications Inc. Dot Hill’s iSN software provides advanced heterogeneous storage virtual-

ization and the ability to unify storage technologies.

The iSN platform enables OEM partners to build custom solutions thereby gaining access to and maintaining control of critical information without limits. It is based on a powerful, flexible virtualization engine that scales to over two petabytes (2 P) of actual storage with virtual volumes, tiered storage, thin provisioning, snapshots, replication and data migration built in. For companies building private and public cloud storage systems to complement virtual servers, the Dot Hill technology provides a foundation for

RTEC10 is an index made up of 10 public companies which have revenue that is derived primarily from sales in the embedded sector. The companies are made up of both software and hardware companies being traded on public exchanges. All numbers are reflected in U.S. Dollars.

Learn more at rtcmagazine.com Closing Price 52 Week Low 52 Week High Market Cap

RTEC10 Index

45.51

—

—

148.61

Adlink Technology

1.36

1.34

1.36

163.03M

Advantech

2.15

2.15

2.16

1M

408.84

408.84

408.84

93.3M

Enea

5.48

5.41

5.48

99.01M

Interphase Corporation

1.51

1.50

1.82

10.32M

Kontron

7.65

7.62

7.81

425.89M

Mercury Computer Systems

11.84

11.83

12.04

280.33M

Performance Technologies

2.46

2.46

2.46

27.35M

PLX Technology

4.03

4.02

4.08

149.28M

RadiSys Corporation

9.79

9.77

9.84

236.62M

Company Market Performance

Elma Electronic

Market Intelligence & Strategy Consulting for the Embedded Community Complimentary Embedded Market Data Available at: www.vdcresearch.com 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.

RTC RTC RTCMAGAZINE MAGAZINE MAGAZINE JUNE JULY MAY 2010

7

INDUSTRY INSIDER

a new class of midrange and enterprise storage systems.

The Intelligent Storage Network (iSN) platform can be the basis for cloud storage solutions that require sophisticated management feature sets. Dot Hill’s software provides a solution that enables companies to gain access to and maintain control of critical information without limits and across multiple tiers of storage arrays. This enables users of iSN to harness both structured and unstructured information, so they can make optimal use of resources, whether data, infrastructure, or IT staff.

New Testing Services Help Java ME Developers Obtain the Java Verified Designation

The Unified Testing Initiative (UTI), a global not-for-profit mobile application testing body, has announced new Java Verified testing services for simple Java Platform, Micro Edition (Java ME) applications. Java ME is the world’s most broadly deployed mobile runtime, utilized by 9 of the top 10 handset manufactur-

8

Untitled-3 1

JULY 2010 RTC MAGAZINE

ers, and powers nearly 3 billion phones in over 150 countries worldwide. The new Simple App testing criteria dramatically reduces the amount of time and money it takes to test many Java ME applications, making it easier for developers to meet App Store and industry requirements for Java Verified certification.

The primary goal of Java Verified is to provide developers with testing and resources for delivering more high-quality Java ME applications to more devices faster. The Java Verified management board includes representation from AT&T, LG, Motorola, Nokia, Oracle, Orange, Samsung, Sony Ericsson and Vodafone.

Java Verified membership is open to all organizations interested in advancing high-quality mobile applications in a collaborative environment.

The Java Verified organization has worked with all of its test houses to update the testing criteria for simple app testing, allowing developers to get these applications tested to the Java Verified standard, and signed with the Java Verified certificate, at a cost that typically averages 75 Euros for each application. Developers

wishing to obtain Java Verified accreditation will work with their preferred test house to establish the appropriate level of testing for their application. Java ME developers are encouraged to visit www.javaverified.com.

Myriad Group and MIPS Accelerate Android App Performance

MIPS Technologies and Myriad Group have announced availability of a high-performance full method-based Dalvik Turbo virtual machine (VM) optimized for the MIPS architecture. Myriad’s Dalvik Turbo VM replaces the standard Android Dalvik engine, accelerating performance up to 5x on real-world Android applications running on MIPS-based devices.

With Dalvik Turbo VM, MIPS licensees can create SoCs with faster, more complex applications and richer game graphics optimized for Android smart phones and other high-performance consumer devices without requiring significant increases in device memory. The VM also provides substantial battery life

improvements when running resource-intensive tasks, all while retaining full compatibility with existing software. Myriad’s Dalvik Turbo VM is operational on all current versions of Android up to and including versions 2.1 (Éclair) and soon to be available for 2.2 (Froyo).

As a founder of the Open Handset Alliance (OHA), Myriad has contributed significantly to the Android platform and today continues to heavily invest in technological advances specifically targeted at Android. These include stand-alone applications such as a WAP browser, MMS messaging, SyncML client, DRM module and IMPS client.

The company is also responsible for the Compatibility Test Suite (CTS) framework within OHA, which is used for testing the compatibility of Android systems.

11/11/09 3:45:15 PM

SMALL FORM FACTOR

FORUM

Colin McCracken & Paul Rosenfeld

SFFs Adapt or Perish

T

o say that the small form factor x86 SBC market moves at glacial speed would be an overstatement. Even the slightest change to a connector pinout or location in a migration product is usually met with outcries of foul play. The question becomes how to upgrade aging form factors (a facelift, if you will) without sacrificing the features that made them popular in the Mesozoic Era. A few years ago, established form factors such as PC/104 and ETX began to lose appeal due to the lack of a migration path to Gigabit Ethernet and PCI Express. It’s not that the market requires zillions of lanes; just one or two are sufficient for the high-data-rate portion of most applications. But those form factors languished until obfuscated by high-flying replacements built around the decidedly un-embedded PCIe x16 hand-medown from desktop motherboards.

Against all odds, an unlikely hookup of wildly different embedded “celebrities” is unfolding. On one hand we have ISA—the ubiquitous, easy-to-interface low-speed bus, the proven veteran.

On the other we have PCI Express—the speedy upstart bus with a bright future, famous as a software-compatible replacement to a space-inefficient parallel PCI. Together, ISA and PCIe form the ultimate odd couple. Oscar and Felix can’t hold a candle to them.

From actors to form factors, there is nothing that a little Botox can’t fix. Michael Douglas & Catherine Zeta-Jones. The Governator and Maria Shriver. Demi & Ashton. ISA and PCI Express.

This ain’t your mother’s embedded market, nor your grandmother’s. There is more than one bus in the sea now. When PCI joined ISA in the 90s, form factors large and small were able to cope. But putting three buses on a SFF board is simply out of the question. Since far fewer SFF baseboards and I/O cards exist based upon PCI than ISA, it is less disruptive to churn the PCI installed base to PCI Express. At the same time, PCI chips are rapidly nearing extinction due to the emergence of their PCIe offspring. For these reasons, PCI applications will be forced to migrate to PCIe even if PCI was sufficient. Thus it appears that the fast bus will always be a treadmill for the latest technology,

while the slow (and cheap) bus may stay put for quite a long time until a new slow I/O ecosystem can be built up. That may take five to ten years or more. So ISA remains—battered, wrinkled and gray. But still standing.

The situation for computer-on-modules (COMs) is somewhat different. The business case hinges on high volumes—OEMs are happy to spend time and NRE dollars designing a custom carrier up front in order to save tens to hundreds of dollars per unit in production. A new project’s budget usually can support a complete baseboard redesign to move to an incompatible module. As long as the OEM saves enough money over several years to pay for the next redesign, there is no problem. However, traditional low-volume stackables integrators who move to COMs prefer compatible COM upgrades, otherwise the business case doesn’t work. In these low volume cases, a baseboard redesign can eat the entire profit for a project really fast.

The point here is that the slow-moving SFF board market is better served by form factor evolution, not revolution. It is not about whether the combination of the slowest and fastest buses needs the blessing of some Grand Poobah; it’s about protecting investments and providing the least pain during migration. The two most horrendous words in the English language to many, many OEM customers are “legacy free.”

In fact, it’s not just the specifications that must heed the warning. Industry groups also must adapt or perish. OEMs are in the best position to judge their unique application requirements. But the folks in the standards groups need to give them the opportunity to migrate without obviating the choice they want. There will always be more Ashtons and Catherines to come along, but the Demis and Michaels are proven and can’t be replaced as easily. In this market, it’s not about whether the couple is “odd” or not.

As long as the embedded x86 market remains dependent on the desktop / notebook / netbook market for new technologies, it’s clear that the only constant will be “change.” But change for change’s sake must be balanced with a dose of reality. SFFs and trade groups that change too rapidly, or don’t change at all, will perish.

RTC MAGAZINE JULY 2010

9

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

editor’s report From M2M to Sys2Sys

DDS Component Links Incompatible Network System Interfaces to Build Multisystem Applications Eliminating the need for custom bridges between different protocols, be they non-real-time or real-time, a configurable bridge technology can link in different and legacy networks locally or globally.

by Tom Williams, Editor-in-Chief

B

y now, the world is familiar with purpose. To that end, the data that they exmachine-to-machine (M2M) sys- change, be it real-time or non-real-time, is tems in which autonomous or semi- limited to a set of compatible data types autonomous nodes communicate and and network protocols. share data over a dedicated network to opBut now what if we want to integrate nies providing solutions now erate as an integrated system even though networked real-time systems into a sort of ion into products, technologies Whether youragoal is to research the latest the nodes mayandbecompanies. distributed over local “system of systems?” Would we call that ation Engineer, or jump to a company's technical page, the goal of Get Connected is to put you area network or even across the Internet. S2S or Sys2Sys? What if it were seen as you require for whatever type of technology, many cases, for. at least parts of these M2M an advantage to connect systems that had and productsInyou are searching systems can be implemented on real-time not even been designed with each other’s local area networks. Of course, nobody existence in mind, but afterward there was is going to pretend that real-time perfor- an advantage perceived in getting them mance can be maintained between remote to work together? Such integration could nodes that must communicate via TCP/IP take place either in a local area network scenario where it would still be possible over the Internet.

Another aspect of M2M systems is to maintain real-time behavior between that they are mostly designed as an inte- systems, or between remote systems over grated, albeit distributed, application with the Internet where it would not.

Traditionally, the means of linking a predetermined idea of their scope and incompatible data boil down to two options: You can either go into the systems Get Connected themselves and modify the interfaces to with companies mentioned in this article. make them compatible, or you can build a www.rtcmagazine.com/getconnected

End of Article

10

JULY 2010 RTC MAGAZINE

Get Connected with companies mentioned in this article.

Real-Time Applications

DDS Plug-in Adapters Socket

Routing Service JMS

Socket LINK11

CANbus

Figure 1 Developers can quickly build and deploy bridges between natively incompatible protocols and technologies using the Routing Service component from RTI.

bridge between them to translate the data types and protocols to meet the different interface requirements. The solution being offered by Real-Time Innovations with the latest release of their version of the Data Distribution Service network technology, RTI DDS 4.5, amounts to the bridging approach. However, it also maintains the real-time publish/subscribe model of the DDS side yet allows the integration of real-time or non-real-time technologies over its bridge called the Routing Service (Figure 1).

DDS is networking middleware originated by the Object Management Group (OMG) that uses a publish/subscribe model for sending and receiving data among nodes on the network. Under publish/subscribe, sending nodes (publishers) need not send their messages to specific receivers; they are sent without knowledge of who the subscribers might be. Subscribers declare interest in receiving messages of a given topic or topics (e.g., temperature, pressure, etc.) without knowledge of who the publishers are. DDS also offers automatic discovery so that subscribers

Open source Linux development environment OpenEmbedded framework for cross-compiling 1000’s of software packages Hardware platform – ARM9 CPU, 256MB NAND flash, 64MB SDRAM Internal Peripherals including GPS receiver & cellular modem Several external interfaces & connectors

MTCDP-E1-DK

Developer resources & community at www.multitech.net

Up to 16 analog outputs with 12 or 16-bit resolution USB/104 form-factor for OEM embedded applications Unipolar and bipolar output ranges Real-time hardware calibration per channel Up to 64K samples per second

USB-AO Series

Two 16-bit analog inputs and 16 lines of digital I/O Extended operating temperature and DIN rail mounting provisions

Intel® Atom™ Z510 processor 1.1 GHz BGA CPU Up to 256MB on board graphics memory Compact Flash socket on board High definition audio Flat panel display support, including dual independent display

KTUS15/mITX

Long-term availability and ultra low power, only 2.3 W TDP Size: 170 x 170 mm

DM&P SoC CPU Vortex86DX- 800MHz PC/104 standard compliant, PCI-104 & PCI/104+ (Optional) Watchdog Timer, software programmable (30.5 μsec. to 512 sec.)

XGI Volari Z9s Chipset, onboard 32MB VGA Memory Integrated 10/100Mbps Ethernet

VDX-6354

256MB DDR2 onboard Audio out

The Embedded Products Source 1.800.548.2319

www.wdlsystems.com

sales@wdlsystems.com

editor’s report

Real-Time, Mobile & Embedded Apps RTI Library —DDS & JMS Direct connectivity

Enterprise & Legacy Apps

Web Apps

Including AppServers, ESBs, CEP engines...

Remote & disparate systems 3rd-party JMS, RTI sockets, file & custom DDS & JMS Routing Service

Transformation & Bridging

RDBMS

Web Services

Database Integration Service

Web Integration Service

Peer-to-Peer Communication DDS-RTPS wire protocol

Analyzer

Monitor

Spreadsheet Add-in

Recording & Playback

Persistence Service

Figure 2 DDS is extended with support for other integration standards, advanced information and routing capabilities and a set of tools and runtime services.

This accelerates the integration of DDS applications with non-DDS applications and into systems of systems.

can find publishers that are offering topics of interest. In addition, it is also possible to specify message priorities and timing constraints.

The result is that DDS provides a high level of decoupling between individual components on the network, making integration of new components easier.

This is especially notable when it comes to integrating systems that were never designed to interface with each other to begin with. As such large network projects as the DoD’s Global Information Grid (GIG) and the Smart Grid for the national energy system are being built out, it is especially important to be able to bring in legacy systems as well as systems that may seem upon later consideration to be important components to include without extensive redesign work.

Essentially, RTI’s DDS 4.5 has introduced a new network component that adheres to the capabilities to mediate between disparate applications. Using a new Adapter Software Development Kit (SDK), systems can build and deploy bridges to integrate DDS and non-DDS systems in a fraction of the time required to develop completely custom solutions. Bridges automatically inherit advanced RTI Data Distribution Service capabilities, including automatic discovery of applications; data transformation and filtering; data lifecycle

12

Untitled-4 1

JULY 2010 RTC MAGAZINE

7/21/09 12:46:17 PM

management; and support across operating systems, programming languages and network transports. With more than 20 new Application Programming Interfaces (APIs), the Adapter SDK provides developers with a flexible tool to enhance the interoperability of their systems.

The component, called the Routing Service, comes with several pre-built interfaces such as one that supports the nonreal-time Java Messaging Service (JMS), and another that supports the real-time CANbus technology. By using this bridging technology, for example, a CANbus node that needed data from the DDS network would be able, through the Routing Service, to automatically discover nodes on the DDS network that offered the data topics it was looking for. However, nothing on the CANbus side of the bridge would need to be modified. And the CANbus, being itself a real-time network, could work within the timing definitions supported by DDS. On the other hand, a JMS network would interface the same way via the Routing Service but, being a non-real-time technology, would not operate in real time.

Rather, it would most likely retrieve or supply status data needed for its applications.

A similar situation would apply when interfacing different network systems over the globe by way of the Internet.

editor’s report

The RTI DDS middleware is implemented directly on top of the Universal Data Protocol (UDP), which allows the use of hardware multicast to send data efficiently in one network operation to a large number of clients simultaneously.

The Internet protocol, TCP/IP, on the other hand, is a connection-oriented technology that is good at connecting a client to a server. Thus we can envision DDS real-time networks, perhaps with other real-time or non-real-time technologies, attached locally via the routing service and also linked to other network entities across the globe by way of the Internet (Figure 2).

This becomes even more interesting as we move into cloud computing and its applications. Cloud computing, of course, depends on the “cloud,” which is the Internet, and its many connected services and devices. The actual cloud application is conceived in terms of the unique application idea that can make creative use of not only original code but also of the existing services and devices. Often, ideas for cloud applications originate or are enhanced because their creators discover unique services that can be integrated into what they are already doing in innovative ways. The ability to realize these ideas depends on the ease of integration.

Once a service is already connected to the Internet, that is pretty straightforward.

Getting disparate, isolated and incompatible nodes connected to the cloud where they can be discovered and utilized—and where, not to be forgotten, they can potentially charge for their services—is another matter.

RTI’s DDS is a serverless solution; it is a library that is fully embedded in the application. At present, it relies on the operating system and a hypervisor function to work with multicore processors. But it is also specifically designed to take advantage of a multicore architecture. For example, it is possible to set processor core affinity for selected threads, which allows them to confidently use that core’s Level 1 cache to enhance performance. And the higher priority threads assigned to a given core naturally execute ahead of the lower priority threads.

There is also support for query conditions under which messages, once re-

ceived, are placed in a relational data structure. Then the application thread can, for example, simply request the latest track and position data of a target of interest where that data is automatically updated every time the message is received from the publisher, processed and stored in the local data structure where it is immediately available to the application.

From stand-alone devices to small networks to large real-time M2M sys-

Untitled-5 1

tems and now to globally connected system to system applications, the ability to dynamically interface and connect these components will become ever more important to the growth of networked services.

Real-time Innovations Sunnyvale, CA. (408) 990-7402. [www.rti.com].

13

11:52:40 AM RTC MAGAZINE2/17/10 JULY 2010

Technology in

context

Small Form Factor SBCs

Stackable Single Board Computers: Choosing between the Form Factors There are clear reasons to choose between using COM modules vs. SBCs in a design. But once the decision has been made to use an SBC, what are the criteria for selecting one of the various small SBC form factors?

Dr. Qi Chen, Adlink Technology

I

mplementation of an application’s embedded computing feature requirements can be done using two basic stackable modular design approaches: Single Board Computer (SBC) and Computer-on-Module (COM). These two may appear equally suited at first, but there are fundamental differences that are important to be aware of when choosing which design path to take. This article will briefly compare the two approaches and then focus on SBC design.

The SBC solution consists of a mainboard that has a CPU/chipset and a set of standard computing functions and interfaces provided, and which also has specific expansion interfaces, such as PC/104, PC/104-plus, PCI/104, SUMIT and PCIe/104, for industry standard stackable module expansion of the features and functions of the system. It is not possible to include all the likely functions needed by every application on the SBC, so the feature expansion capability is used to provide all the additional custom or application-specific features that are not provided by the standard SBC itself.

By contrast, COM, as the name sug-

14

JULY 2010 RTC MAGAZINE

gests, only has a CPU/chipset, memory and some core functions implemented on a small module, and the provided module interfaces are then designed so that the module stacks onto a user-designed baseboard, which then separately implements all the application-specific requirements, including external interfaces and function expansion. The application designer is then freed from implementing the CPU module, which requires detailed knowledge of the internal chipset implementation. Instead, he or she can focus their design effort on the application-specific baseboard. COMs should be interchangeable between the different module choices available, but there can sometimes be difficulties, for example, when chipset functions change due to chipset vendor device changes between chip generations. In this case, the user may have to redesign the baseboard to use the new functions on the latest COM modules.

Generally speaking, COM matches well when the system designer can invest considerable effort into the baseboard design, or has a well-developed solution that includes custom features or interfaces that

may not be available on standard expansion modules. When the application has a specific hardware feature set that is well covered by off-the-shelf expansion modules, there can be considerable benefit to using SBCs instead of COMs because no board design may even be needed, leading to a much faster time-to-market.

Also, SBCs often work well for providing a migration plan for existing designs. Looking at the current market, SBC has a significant percentage of the market and there are a number of board solutions available in different form factors that at first may appear to be somewhat similar.

Let’s look at the more widely used types, explaining the differences and their likely application areas. In addition, we can examine some applications in more detail, showing how the SBC approach can be used to build a powerful system from offthe-shelf boards.

Stackable SBC Advantages

Single board computers with stackable expansion for rugged embedded applications are currently available in three common form factors: the 104 core mod-

technology in context

ule, EPIC and EBX. These differ in board size significantly, but there are other aspects that generally make each form factor more suited to some applications than others.

Before considering the differences in the SBC form factors, it is useful to look at the expansion interfaces available for SBCs. This is a key element for the application because it determines the overall system capabilities. SBCs support a wide set of available module interfaces, so the system can be implemented using either older legacy interface modules, or can use modules based on the latest industry interfaces. This ability to use a wide range of well-established and well-proven legacy modules, and yet also still use modules with the latest, and more capable, industry standard interfaces, is a key reason why SBCs have become such a popular system implementation method. An SBC provides a very straightforward migration path from older designs to new designs as technology progresses and new module designs and features become available.

Currently the interfaces for SBC expansion modules are PC/104, PC/104Plus, PCI/104, PCI/104-Express, SUMIT and PCIe/104. PC/104 was the earliest interface developed and just has the ISA bus, which is still widely used as a well-proven legacy interface. Later PC/104-Plus was developed and added to the PCI bus interface so that two interfaces were supported, giving the module implementer more choice and capability. PCI/104 was then developed, but this only has PCI and was intended for applications that do not need ISA support. PCI/104-Express then added PCI Express x16 (optionally configurable as two x8 links, two x4 PCIe links, or two SDVO Interfaces) to the PCI interface provided on PCI/104. Finally, PCIe/104 is the logical development of the PCI expansion interfaces and includes only PCI express, which is gradually replacing PCI for new designs. SUMIT is an example of a recent highly capable module interface that include PCI Express, USB, SMBUS

Figure 1 A 104 module stack provides a compact, fanless solution for small spaces.

and LPC, etc., providing a powerful and flexible interface capability for the expansion modules.

Stacking limitations are generally due to bus limitations, for example, PCI only allows a maximum of four devices, so no more than four PCI modules can be included, or less than this if modules have multiple PCI devices. The range of SBC expansion modules available is very wide and includes data modems, GPS satellite receivers, analog I/O, A/D converters, graphics cards, frame-grabbers, GSM/ GPRS, CANbus, wireless LAN, FireWire, serial interface, and motor controllers, to name but a few.

104 Core Module

The smallest stackable single board computer, physically, is the 104 core module with a board size of only 90 by 96 mm. Since the mainboard is small, it often only provides the CPU/chipset along with a varying subset of important or popular functions such as device boot-up, basic I/O functions, video display, two serial ports, USB, Ethernet and a solid-state drive (SSD) for the OS. The module inter-

faces then allow additional modules to be stacked vertically one above the other over the base SBC, adding the extra capability for the application-specific functions and the other external interfaces needed. Offthe-shelf expansion modules can usually be used.

Before selecting this form factor it is necessary to make sure all the requirements can be implemented in the stack.

Most mainboards can stack modules on both the top and bottom side, but for some high-power mainboards (>15W), the thermal solution forces the limitation that I/O modules can only stack either on the bottom or the top, but not both. Therefore a 104 core module is also often a good system choice where relatively low power is a known requirement, and this can also be achieved by carefully selecting the expansion modules to provide just the features needed. Another consideration is that the compact shape of this form factor is suited to fanless solutions where space for forced airflow is not needed.

When modules are stacked over the base 104 core module SBC, they preserve the very small system footprint. Because of this and RTC MAGAZINE JULY 2010

15

technology in context

Figure 2 An EPIC solution can accommodate a fan if needed for a higher-power CPU, and can often meet the application needs with its available on board interface.

This example includes SUMIT connectors if advanced stackable I/O modules are needed.

the efficient use of space due to the stacking of boards, the 104 core module form factor is very well suited to applications where available space is an issue, and where the larger EPIC and EBX do not even fit in the limited space available. Figure 1 shows the CM740, a PC/104 core module from Ampro by Adlink, in a stack-up with an Ethernet card, a 4x USB port card and a FireWire card. This mainboard also supports multiple serial ports, USB ports and an SSD. The resulting system is for an application requiring a compact fanless solution for the military, transportation and avionics markets. The operating temperature range is -40° to +85°C and the system achieves high levels of vibration and shock resistance. A typical application where the Ampro by Adlink 104 core module works well is as part of a heads-up display installed in an aircraft cockpit, where space constraints are very demanding.

EPIC

The EPIC mainboard is 115 by 165 mm and therefore physically larger than a 104 core module. This allows designs with more I/O functions on the mainboard, including serial ports, USB and even Mini PCI Express card and CompactFlash slots for removable boot-up devices. Also the

16

JULY 2010 RTC MAGAZINE

greater available space more easily allows mid- to high-power CPU solutions to be used with less challenging thermal issues than occur using the smaller 104 core modules. Because EPIC also provides more space for I/O, the mainboard can often already include the I/O required, and in that case, maybe only one applicationspecific expansion module—if any—is needed, which can be a benefit for lowcost or turnkey designs.

EPIC mainboards generally include I/O in PC-style connectors so EPIC is suited for many applications that need embedded PCs controlling the system, such as many medical, digital signage and machine automation designs. Another very different application area where EPIC excels is in systems that need to withstand high levels of vibration and shock. Shockresistant pin-headers can be used on the mainboard because of the space available provided for I/O. The EPIC board is then usually built into a custom designed enclosure with custom cabling connecting the EPIC board connectors to external connectors on the enclosure. When space is not the major constraint, EPIC works well for such applications, even when compared to 104 core modules.

A good example of an EPIC mainboard is the Ampro by Adlink RB740, which has been used in many different vertical markets. By including an automotive power module (such as MiniModule PWE) this EPIC board can directly be used in automotive applications. The onboard HD Video decoder can also play back high-definition video up to 1920 x 1088 and makes the RB740 also very suited to digital signage applications. Another application well suited to EPIC is video surveillance systems requiring multiple video channels, such as the Ampro

by Adlink RB850 shown in Figure 2. This system is implemented using the standard EPIC board with a single 4-channel framegrabber SUMIT expansion interface card PCIe-RTV24.

104 core modules would have a limitation here because of the small size available for the frame-grabber card, and the problem of dissipating sufficient heat. The larger EPIC board allows for a more fully featured frame-grabber. A higher power CPU can also be more easily used with fewer challenges in the thermal design. This system requires no further expansion boards because there is sufficient I/O provided already on the mainboard for the application. The result is a straightforward path to a complete hardware solution, which needs no additional hardware design and comes with proven software drivers and support.

This allows the system implementer to devote more design effort to implementing software and application-specific features.

This same hardware solution is also good for other applications such as digital video recorder (DVR), factory monitoring systems, machine vision inspection systems, and systems for scientific and medical research instrumentation.

EBX

EBX has dimensions of 203 by 146 mm and is an even larger footprint board than EPIC. Because of the large surface area on the mainboard, there is considerably more space available for expansion areas and for the CPU/chipset. The thermal solution can also be less restrictive, the larger form factor making it significantly easier to design thermal solutions

technology in context

for even the highest power CPUs. EBX has more mainboard I/O area available, enabling it to directly support more standard I/O devices such as multiple storage devices, multiple serial ports and multiple USB ports, all of which are often needed in the application areas using this form factor.

EBX also can include on the mainboard some vertical market feature requirements such as FireWire, GPS, CANbus and wireless LAN. The stackable interfaces presented on EPIC and the 104 core module are also still included, and are used in the same way to add applicationspecific functions. For many applications almost all functions are already included on the EBX mainboard, so that expansion modules are sometimes only needed for the special requirements for vertical market solutions, where highly specialized systems are developed. An example would be using modules with PCI/104-Express and the PCIe/104 support for high-performance MXM PCI Express x16 graphics card for the gaming industry and for airplane in-seat entertainment systems.

Comparing EBX to EPIC, the former has even more I/O space available for shock- and vibration-resistant pin-headers for the external I/O connectors, making EBX particularly well suited for rugged systems that also need to utilize the latest high-power CPUs and OS environments. The combination of a wide range of interface solutions and the availability of additional expansion module functions, along with high compute power make EBX a particularly good choice where small size is not a critical requirement, and where the somewhat lower cost of EPIC is not a major concern, but where high overall compute performance is the major requirement.

The key steps for successfully selecting between single board computer systems are to choose the CPU/chipset power, determine the space allowed, know what kind of I/O is needed, and also to select the bus interface expansion between PC104/PC104-Plus/PCI/104, etc. according to the current market availability of the application-specific modules needed.

Generally it is preferred to use the solu-

tion that occupies the smallest space. And because chip technology has been continually moving to smaller footprints, the smaller boards such as 104 core module and EPIC will continue to grow in applications, but EBX continues to provide a solution where fully featured systems with extensive I/O and powerful CPUs are required in the SBC form factor.

Untitled-5 1

ADLINK Technology San Jose, CA. (408) 495-5557. [www.adlinktech.com].

17

4:47:07 PM RTC MAGAZINE 2/17/09 JULY 2010

Technology

connected Quality Assurance for Software

Advanced Static Analysis: Evaluating Tools to Optimize ROI The cost of bugs getting through into deployed products can be devastating, yet no tool is perfect. Still, there are ways to compare the real value of tools to minimize revenue losses and optimize quality and ROI.

by Paul Anderson, GrammaTech

A

dvanced static-analysis tools have become popular in recent years because they are capable of finding serious programming errors that might otherwise go undetected. Unlike conventional testing tools, they do not actually execute the code, so test cases are not needed. An unavoidable property of all such tools is that they cannot find all bugs—i.e., they have false negatives—and they may also give warnings for code that is defect free, which are false positives. Tools that find many real bugs, or true positives, generally have a high false-positive rate, and tools that have a lower false-positive rate usually find fewer real bugs.

Users strongly dislike false-positive results, so tools are generally designed or configured to minimize these. However, this also reduces the probability that the tool will find real defects. Interestingly, a simple cost model can be used to compute the return on investment (ROI) for these tools, and which can help users understand the trade-off between finding real defects and suppressing false positives.

This model confirms that the value of the tools is dominated by the cost of the

18

JULY 2010 RTC MAGAZINE

1000 900 800 700 600 500 400 300 200 100 0

Tool A

Tool B

Bugs not detected by tool

Tool C False positives

No tool

Perfect tool True positives

Figure 1 The raw performance from the candidate tools.

incidents that a bug might trigger in a deployed application. However, it also shows that a very low false-positive rate is not the optimal choice for these tools. It is worth tolerating a higher false-positive rate as long as a tool can find more real defects

too. Advanced static-analysis tools generate a report comprising a list of warnings for the project under analysis. Users then inspect the warnings to determine which are true positives (i.e., things that matter), and which can be reasonably ignored.

technology connected

The ability of a tool to find real problems is known as its “recall,” defined as the probability that the tool will find a given defect. The “precision” of a tool is a measure of the quality of the results: it is the probability that a given report is a real defect. Both recall and precision are very difficult if not impossible to measure accurately. Recall is especially difficult because it is based on the number of defects actually present in the code, which is impossible to determine for all but the most trivial programs.

Nevertheless, it is practical to compare the rate at which defects are found by different tools (or by the same tool configured differently), and it is also practical to measure false positives. This allows us to measure the relative ROI for tools.

Because the results of the staticanalysis tool must be judged by a human, mistakes will inevitably be made. Understanding the causes and risks of these mistakes is crucial in deciding how to use the tools most effectively.

At first glance, it might appear that the best tool to use is the one with the highest recall. After all, that tool will find the most real defects. Remember though that higher recall also implies a higher false-

positive rate. If a tool reports too many false positives, they will drown out the real problems in two ways. Simply spending time inspecting them consumes valuable resources. The greater risk is that the more false positives there are, the greater the probability that a true positive will be misjudged to be a false positive.

Typically tools are configured so that warnings marked as false positives are not shown to the user, so the most important consequence of this class of misjudgment is that the warning will be suppressed in future reports, and the defect will remain in the system. To compute the return on investment for an advanced static-analysis tool, it is useful to model the software development process mathematically. Some important inputs are the following: The cost of an incident. When a bug causes a failure in fielded software, there is almost always a cost to the software developer, although the amount can vary wildly. The cost typically rises depending on the number of units deployed and the criticality of the system. A bug in a medical device can trigger a hugely expensive FDA-mandated recall of the device. Only some of the bugs that survive into a deployed product will trigger an incident

100 90 80 70 60 50 40 30 20 10 0

Tool A

Misjudged true positives

Tool B

Tool C Undetected introduced bugs

Figure 2 Bugs that remain in the application.

No tool

Perfect tool Bugs not detected by tool

before they are removed through routine maintenance. This aspect is easily modeled by assigning a probability of an incident being triggered.

The cost to fix a bug. The earlier a bug is found, the easier and cheaper it is to fix. Bugs found after deployment are especially expensive, as the program may have to undergo revalidation.

The cost to inspect a warning. Most warnings can be inspected and judged very quickly, but those that involve long paths through the code or complicated relationships between variables can take a lot longer. On average it takes ten minutes to inspect each warning.

Tool characteristics. For the purposes of computing ROI, the important properties of each tool are its purchase price, its precision and its recall.

Risk of true-positive misjudgment.

As discussed above, the risk of interpreting a true positive as a false positive rises as the false-positive rate rises. There is no data available to allow us to empirically determine the exact relationship, so we make the simplifying assumption that the probability of misjudgment is equal to the false-positive probability. This is a pessimistic assumption that may overstate the influence of false positives in practice, but the main conclusions hold for a more optimistic model too.

Given these inputs, it is useful to compute the following: • The cost to run the static-analysis tool and act on the results • The number of bugs that remain undetected in the deployed product • The cost of dealing with all the triggered incidents For comparison purposes let’s consider three hypothetical static-analysis tools: • Tool A is quite good at finding bugs, but many of the warnings it gives are false positives.

• Tool B is good at suppressing false positives, but consequently does not find as many real problems as Tool A. RTC MAGAZINE JULY 2010

19

technology connected

• Tool C is extremely good at finding bugs, but has a correspondingly high false-positive rate.

Assume that these tools each cost $20,000 to license. We also consider the case where no tool is used, and an imaginary perfect free tool that finds all bugs with no false positives. These cases are summarized below in Table 1 Let’s assume that there are 100 defects in the software before static-analysis is applied. Figure 1 shows the raw performance of each tool. Note that Tool C has a very large number of false positives as a consequence of its low precision.

Figure 2 shows the number of bugs that remain in the application, assuming that all of the real bugs that were reported have been fixed. There are two interest-

ing conclusions that can be drawn from this chart. First, note that although Tool C reported the most true-positive results, its high false-positive rate meant that most of these were subsequently misjudged as false positives. Secondly, although Tool B had a low false-positive rate, it simply found fewer real bugs than Tool A. Let’s assume that engineering labor costs $75/hour; and it takes 4 hours to fix a bug early in the development cycle, versus 20 to fix it after deployment. Assume also that each warning takes 10 minutes to inspect. Finally, if the cost of a single incident is $40,000 and if the probability of an unfixed bug triggering an incident during the lifetime of the deployed product is 5%, then the savings for each tool is as shown in Figure 3.

As might be expected, the value is

Tool A

Tool B

Tool C

No Tool

Perfect Tool

Recall

60%

30%

95%

0%

100%

Precision

60%

80%

10%

0%

100%

Cost

$20,000

$20,000

$20,000

—

—

TABLE 1 Three hypothetical tools, and two controls. $200,000 $175,950 $150,000

$100,000

$50,000

$35,574

GrammaTech Ithaca, NY. (888) 695-2668. [www.grammatech.com].

$20,301 $-

$-

$(50,000)

$(41,288)

$(100,000) Tool A

Tool B

Tool C

Figure 3 The cost savings from static-analysis tools.

20

JULY 2010 RTC MAGAZINE

No tool

strongly dominated by the cost of incidents. The influence of false positives is very strong too, but not entirely in the way one might expect. Note that Tool C shows a negative return on investment, even though it is very good at finding real bugs, because most of the true-positive results are misjudged. The cost of inspecting all the warnings then drowns out the benefit from the bugs that were found. However, Tool B, which has a very low level of false positives, does not do quite as well as Tool A even though Tool A reports five times as many false positives.

This simple model shows how to calculate the return on investment of staticanalysis tools based on the risk of an undetected defect making it through to a deployed product and triggering an expensive incident. As stated, the model is dominated by the cost of these incidents.

A less obvious conclusion is that an emphasis on minimizing false positive results at the expense of reducing true positives is not entirely justifiable. Yes, it is important to keep false positives reasonably low, but it is important to not take this to extremes.

Similarly, tools that are good at finding real bugs may be rendered worthless if the false-positive rate is too high, because higher false-positive rates increase the risk of misjudging reports.

The best approach to choosing an appropriate static-analysis tool is to try several on your own code base. In cases where the results vary, it is important to compare the tools rationally. Although users may prefer tools with very low falsepositive rates, such tools may not offer the most benefit. The model described above provides a quick and easy way to compare the real value of tools.

Perfect tool

Technology

connected Quality Assurance for Software

Time to Rethink Software Testing for Embedded Devices No longer relegated to the end of the process, test must become an integral, high-value contributor to every stage of the software development process.

by Paul Henderson, Wind River

W

hether they realize it yet or not, test teams and their software development colleagues at embedded product companies are headed for trouble— or are knee-deep in it already. There is an increasing likelihood that they will discover serious defects in their products late in their software development cycles, or worse—after products have been shipped to customers.

In a recent Wind River embedded industry survey, for example, 72% of the nearly 900 respondents reported that they had their product schedules disrupted by late-cycle quality surprises this year, which caused 58% of them to delay product shipment.

These problems can cause significant and sometimes devastating damage to companies and careers. That’s why it’s time for executives, development managers and test team leaders to step up, recognize the problem and develop an action plan for dealing with it.

The most obvious evidence of this growing problem is the recent news coverage of high-profile, software-related product failures. But a closer review of news outlets and technical journals turns up many more problems with embedded

22

JULY 2010 RTC MAGAZINE

products stemming from their software components. Although most of these situations are handled outside of the media spotlight, they still cause significant damage to the companies involved.

For leaders at embedded product companies, the first step back from trouble is to understand why these problems are happening. They need to see and appreciate how changes and trends in the industry are combining to make the job of producing software for embedded products to quality, on time and on budget much harder than it has ever been before.

Product failures are actually the symptom. The “disease” is the fact that in many companies, software quality testing methods, tools and cultures have not kept up with the accelerating pace of change. At most embedded companies today, test and development teams are contending with skyrocketing software content, which is roughly doubling or increasing even more every two years. This brings with it increasing architectural complexity—usually involving 32and 64-bit architectures, COTS operating systems, and often, multicore processors.

In addition, evolving development

models, such as Agile, Extreme and other iterative development environments, require early, often and continual testing throughout the entire cycle, not just at the end. But at the same time product development and test teams are being forced to deliver far more complex products in less time than ever before so delivery schedules remain tight, resulting in less thorough testing.

When Staying ‘Positive’ Doesn’t Pay

Most embedded companies today base their quality assurance strategy on “positive” testing of functional requirements. This means that the test group takes the user specification and exercises the device with manual and automated tests to see if all the features do what they were specified to do. Leading test teams actually map these positive tests to requirements to show traceability to tested features and results.

Positive testing is good—it’s a fundamental and necessary component of any QA or test program. But research shows that many, if not most, of the defects customers are seeing in the field relate to un-

technology connected

foo()

Dynamically Inject Test Data To Force Edge Condition {Temp=101}

Is Temp > 99?

process

errorHdl()

Figure 1 Dynamic instrumentation features enable white box testing by manual or automated manipulation of data in the device under test at runtime. Here a test script can dynamically access the temperature value in production software during the test and inject “fake” data values to force an over-temperature condition so the error handler path (errorHDL()) can be properly tested.

usual conditions that the device was not tested to handle.

In the aforementioned Wind River survey, the top two causes of shipped defects were “the product was used in unanticipated ways” and “edge conditions were not tested.”

Sources of these problems include unusual combinations of data inputs, overflows from long running operation, performance bottlenecks triggered by unanticipated sequences of events, and unrecoverable system conditions caused by hardware failures or other untested fault conditions.

As a result, support personnel often hear statements from developers like, “Why are they using it like that?” or “We never tested the product in that failure mode.” That may be true, but it isn’t really acceptable. In the end, products are failing more often, and doing so in customers’ hands. In other words, development and test teams have been staying “positive”— and it isn’t getting the job done.

Getting Negative with White Box Testing

To catch and address these issues before they blow up into major problems at customers’ sites, companies need to do much more “negative” testing. They need to run tests that try to break the system, validate fault and exception handlers or otherwise force the device under test into an unusual state or “edge condition.”

Making this shift requires a mindset change among team members—a focus that expands beyond what should happen to what could happen. Teams need to start thinking more about how to anticipate and test for failure modes and other conditions that devices may encounter in the real world. Increasingly devices are no longer single function and are part of an ecosystem of interoperable devices. Therefore the potential modes of operation and modes of failure are exponentially greater.

This transition also presents an op-

portunity to institute more of a “design-fortestability” approach that starts up front in the development process. Product requirements should specify anticipated failure modes and should contain requirements such as “The device will have a fault handler to cover the following conditions and these shall be tested as specified…” Test planners need to translate these requirements into suitable test plans. Software developers must then work with test developers to provide appropriate “hooks” to allow automated tests to drive the software or device into failure conditions during testing.

Given that many of these failure modes can be time-consuming and expensive to test using traditional manual methods, test planners need to look at new tools that can allow automated testing using “white box” techniques that let tests access device internals at runtime. This not only saves time and money, but more importantly, allows deep and thorough regression testing of edge conditions “early and often,” with each new software build.

Leading unit test tools like IPL’s Cantata++ and modern device simulation systems like Wind River’s Simics provide white box features for developers to use. Now new embedded test optimization solutions like the Wind River Test Management system are providing white box testing capability for quality assurance professionals.

These new test optimization systems use new dynamic instrumentation technology to allow white box access to the actual production software on the embedded device under test—at runtime. They allow injection of test data or code in synch with test cases without stopping or rebooting the device. This enables automation of normally hard-to-test scenarios by easily injecting faults, forcing failovers, or otherwise triggering exception conditions at runtime.

In white box testing, developers working to the test plan create reusable dynamic instrumentation that can be used to manually or automatically input data, force states, read or log data at a given subsystem, or inject faults or failures in synch with test cases (Figure 1). Example uses of dynamic instrumentation for white box testing include: • Injecting specific values into variables RTC MAGAZINE JULY 2010

23

technology connected

• Forcing faults or conditional expressions to execute code paths, error handlers, or failover • Logging internal device data generated at runtime for validation against expected parameters • Altering the system’s environment (e.g., change values read from sensors, set CPU and peripheral controllers register values, modify streaming data) White box testing features like this can now dramatically expand the range and depth of both positive and negative testing that can be accomplished on device software while still meeting product delivery schedules and staying within testing budgets.

Focus on the ‘Deltas’ with Change-based Test Automation

Negative testing is far easier to accomplish when the testing group understands how the code is structured, what their test suites are actually testing, and what code is actually not being properly

Untitled-11 1

24

JULY 2010 RTC MAGAZINE

Cross-reference Traceability Map Auto-identify Changes in Latest Release Binaries

Build 6

Build 7

function1( ) function6( ) function11( ) function32( ) function202( ) function42( ) function66( ) function85( )

Module1

Testcase2

function43( ) function44( ) function521( ) function53( ) function214( ) function64( ) function86( ) function89( )

Module2

Testcase3

function19( ) function71( ) function382( ) function752( ) function25( ) function87( )

Module3

Testcase1

New? Changed?

Deleted?

Auto-generate Change-driven Test Suite Testcase1 Testcase3

Figure 2 White box testing techniques help assure that device software is more thoroughly tested. Runtime test coverage analysis can alert test teams what code remains untested by their suites. This information can be used to develop more comprehensive suites that test every path. Advance test systems also identify changed functions and create test-to-code traceability maps that together tell testers precisely what tests need to be rerun to verify changed code.

tested (e.g. error handlers). This information can be extremely difficult to obtain using only traditional tools. Fortunately new dynamic instrumentation technology

and tools can now provide this visibility.

Using the same white box techniques, auto-generated instrumentation can be deployed into the production software at

7/9/10 10:35:39 AM

technology connected

runtime to gather test coverage information as test suites are run. This tells the user specifically what software has been tested and, more importantly, what software has not been tested. Test coverage reports provide pointers to areas of the code needing special attention.

Test coverage information can then be leveraged to generate a traceability map that shows specifically what code is exercised by which test cases. This provides clues to the developer and tester as to specifically what tests verify what code and where to apply resources to enhance test suites to fill gaps.

As software changes over the life of the project, testers have to rerun their tests to guard against regressions. The traceability map can also be used to help testers then decide specifically what tests to rerun to verify this hard-to-test code. For example, an automated binary compare between software builds can be used to identify changes, and leveraging test coverage information and the traceability map, can determine precisely what tests need to be rerun to verify changed code (Figure 2).

Each of these white box techniques works together to give the device testing professional better visibility and control of the device under test. By helping testers “see inside” embedded systems at runtime, these white box testing systems can help engineers and QA professionals test more thoroughly. They also help management get more accurate and thorough assessments of the quality of their software projects at any point in the development process, so they can focus their scarce time and resources more effectively.

error, component failure, or complex deployment configurations. They must anticipate how devices may fail in ways that were not anticipated by designers Tools are available today that can help. Real advances have been made around leveraging real-time, white box input from devices under test and this can significantly help create more focused, more informed and more automated quality testing. These new advances enable

teams to build on the positive testing components they already have in place, and make comprehensive negative testing an integral and cost-effective element of their overall programs.

Wind River Alameda, CA. (510) 748-4100. [www.windriver.com].

It’s Time for Testers to Step Up

None of this will be possible, however, if QA and test teams and their management don’t step up to the challenge.

More sophisticated devices require more sophisticated approaches to testing them.

QA teams need to take a more active role in understanding how these devices work internally. They need to work much more closely with development teams, particularly when using new iterative and agile methodologies. They also need to provide an independent view to device operation and deployment that can project where additional failures could occur from operator Untitled-4 1

25

9:38:50 AM RTC MAGAZINE 1/20/10 JULY 2010

technology in

systems Embedded Java

Java Tackles Multicore Complexity While multicore solutions offer superior processing capacity while lowering power consumption, they force software developers to address a bewildering assortment of new issues. Fortunately, the Java language was designed to simplify management of these multicore issues.

by Kelvin Nilsen, Atego Systems

A

s VLSI transistor densities continue to rise, microprocessor vendors are increasingly turning toward multicore architectures as the most effective utilization of available transistors. This trend places a large burden on software engineers who must structure software so that it runs efficiently on multiple processors. Besides dividing a program into independent smaller tasks, each of which can be performed by a distinct processor core, software engineers must carefully craft the implementation of each independent task to (a) minimize its dependencies on other tasks, (b) reliably communicate information that must be shared with other tasks, and (c) arrange for certain tasks to wait at appropriate times for coordination with other tasks.

On top of this, the system must be designed to achieve high throughput and low latency and all code must be structured so that it is easily maintained in the face of anticipated functional and platform evolution.

The Java language syntax and its standard libraries were designed from the ground up to support multiprocessing. This is a big improvement over legacy languages like C

26

JULY 2010 RTC MAGAZINE

Calculate Read input outputs based values from on PID 1,000 sensors control algorithm

0 ms

5 ms

Log all input and output values

10 ms

Write output values to 1,000 actuators

15 ms

20 ms

Figure 1 Soft PLC Implementation of Proportional Integral Derivative (PID) Control

and C++, for which mastering concurrency issues requires a perplexing mix of compiler optimization choices, non-portable invocations of operating system services, and non-portable assembly language.

The Thread type, part of Java’s standard libraries, provides a portable and convenient notation to allow programmers to state that certain activities are performed concurrently, in a separate thread of control. The Java programmer simply extends the thread class and overrides the run() method with the code that is to be executed by the independent thread. Spawning this thread is as easy as performing a new operation to instantiate it, and then invoking

the thread’s inherited start() method to cause it to begin executing.

Once multiple threads are running within shared common memory, it is occasionally necessary to enforce mutual exclusion for certain activities, ensuring that only one thread at a time is involved in those activities. Consider, for an illustrative example, a situation where one thread updates a record representing the name and phone number of a person while many other threads are consulting this same record to look up the person’s name and phone number.

Synchronization between threads is necessary to ensure that the consulted in-

tech in systems

formation is always coherent. If one thread fetches the person’s name while the name is being modified, it might receive a name that is an inconsistent mix of the two. Another inconsistency arises if the updating thread is preempted between overwriting the person’s name and his phone number. A reading thread might obtain the new person’s name, but the old person’s phone number.

Addressing this challenge in Java is a simple matter of adding the synchronized key word to the methods that overwrite and fetch the name and phone number. The benefits of having this keyword built into the language are significant. First, it is easy for a Java programmer to read and understand the intended concurrency aspects of this code.

Second, implementation of the concurrency intentions is provided by the Java virtual machine in a portable and efficient way. Third, synchronization provided by the Java virtual machine is more reliable and less error prone than synchronization implemented in handwritten assembly language by software engineers.

Within a synchronized method, Java programs have access to implicit condition variables associated with the object’s synchronization lock. The typical Java thread acquires an object’s mutual exclusion lock by entering a synchronized method, checks for a certain condition and, if that condition is not satisfied, blocks itself by invoking the wait() service. When a thread executes wait(), it is placed in a blocked state on a special queue associated with the enclosing object. While on this queue, the thread temporarily releases its mutual exclusion lock.

Other threads operating on the same object will presumably make the condition true. Before making the condition true, the other thread must acquire the object’s mutual exclusion lock. After making the condition true, but while still holding the mutual exclusion lock, the thread performs a notify() (or notifyAll()) operation.

This has the effect of unblocking one (or all) of the threads on the object’s condition queue. Each unblocked thread automatically reacquires the mutual exclusion lock before it executes within the synchronized block that was running when it invoked

Partial Java Implementation of a Four-Stage Pipeline public class Main { final static long FIVE_MS = 5000000;

// 5 ms = 5,000,000 ns public static void main() { long now = VM.upTime(); long start = now + FIVE_MS;

// start first stage 5 ms from now FIFO fifos[] = new FIFO[2]; fifos[0] = new FIFO(); fifos[1] = new FIFO(); Stage1 stage1 = new Stage1(start, fifos[0]); start += FIVE_MS;

// stage2 waits one period for stage1 to provide inputs Stage2 stage2 = new Stage2(start, fifos[0], fifos[1]); start += FIVE_MS;

// stage3 waits another period for stage2 to provide inputs Stage3 stage3 = new Stage3(start, fifos[0], fifos[1]); start += FIVE_MS;

// stage4 waits yet another period for stage3 to provide inputs Stage4 stage4 = new Stage4(start, fifos[1]); stage1.start(); stage2.start(), stage3.start(), stage4.start(); } } public class Stage1 extends Thread { FIFO out_channel; long next_period; public Stage1(long start_time, FIFO output) { next_period = start_time; out_channel = output; }

}

public void run() { while (true) { PercThread.sleepUntil(next_period); next_period += Main.FIVE_MS; Buffer b = out_channel.getEmptyBuffer(); for (int j = 0; j < FIFO.BUFFER_LENGTH; j++) { float input_value = IO.readPort(j); b.put(j, input_value); } out_channel.putFullBuffer(b); } }

public class Stage2 extends Thread { FIFO in_channel, out_channel; long next_period; public Stage2(long start_time, FIFO input, FIFO output) { next_period = start_time; in_channel = input; out_channel = output; }

}

public void run() { while (true) { PercThread.sleepUntil(next_period); next_period += Main.FIVE_MS; Buffer in_buf = in_channel.getFullBuffer(); Buffer out_buf = out_channel.getEmptyBuffer(); for (int j = 0; j < FIFO.BUFFER_LENGTH; j++) { float input_value = IO.readPort(j); float output_value = PID.compute(j, input_value); out_buf.put(output_value); } in_channel.returnFullForOtherUse(in_buf); out_channel.putFullBuffer(out_buf); } }

RTC MAGAZINE JULY 2010

27

Tech In Systems

Calculate Read input Log all input values from outputs based and output on PID 1,000 sensors values control algorithm

Write output values to 1,000 actuators

Calculate Log all input Write output Read input values to values from outputs based and output on PID 1,000 values 1,000 sensors control actuators algorithm Calculate Read input Log all input Write output values to values from outputs based and output on PID 1,000 1,000 sensors values control actuators algorithm

0 ms

5 ms

10 ms

15 ms

20 ms

Figure 2 Two-Processor Pipelined Implementation of Soft PLC. wait(). The mutual exclusion lock will

not be available until the notifying thread releases the lock by leaving the synchronized body of code.

A syntax shared with C and C++ is the volatile qualifier, which can be added to the declaration of certain fields (variables).

As with C and C++, variables declared to be volatile are implemented such that their values cannot be cached. Every read or write access must go all the way to physical memory. The semantics of the volatile keyword in Java are stronger than for C or C++. The Java compiler is prohibited from reordering all other read operations (even non-volatile reads) to precede a volatile read, and from reordering all other write operations (even non-volatile writes) to follow a volatile write. With C and C++, the reordering prohibition applies only to other volatile reads and writes. This subtle difference makes it much easier to write reliable and efficient multicore code in Java.

Another strength of Java for multicore programming is the java.util.concurrent package that was introduced with the Java 5.0 release in 2005. These libraries provide implementations of threadsafe collections, semaphores, prioritized blocking queues, atomically modifiable data abstractions and a reentrant lock data type. The reentrant lock data type offers services not available with synchronized statements, such as an API to conditionally acquire a lock only if the lock is not currently held by some other thread.

28

JULY 2010 RTC MAGAZINE

Restructuring Code to Maximize Multicore Efficiency

To exploit the full bandwidth capabilities of a multiprocessor system, it is necessary to divide the total effort associated with a particular application between multiple, largely independent threads with at least as many threads as there are processors. Ideally, the application must be divided into independent tasks, each relatively rarely needing to coordinate with other tasks. For efficient parallel operation, an independent task would execute hundreds of thousands of instructions before synchronizing with other tasks, and each synchronization activity would be simple and short, consuming no more than a thousand instructions at a time.

Software engineers should seek to divide the application into as many independent tasks as possible, while maximizing the ratio between independent processing and synchronization activities for each task.

To the extent that these objectives can be satisfied, the restructured system will scale more effectively to larger numbers of processors.

Serial code is code that multiple tasks cannot execute in parallel. As software engineers work to divide an application into independent tasks, they must be careful not to introduce serial behavior among their â&#x20AC;&#x153;independent tasksâ&#x20AC;? because of contention for shared hardware resources.

Suppose, for example, that a legacy application has a single thread that reads values from 1,000 input sensors. A programmer

might try to parallelize this code by dividing the original task into ten, each one reading values from 100 sensors. Unfortunately, the new program will probably experience very little speedup because the original thread was most likely I/O bound.

There is a limit on how fast sensor values can be fetched over the I/O bus, and this limit is almost certainly much slower than the speed of a modern processor. Asking ten processors to do the work previously done by one will result in ineffective use of all ten processors rather than just one.

Similar I/O bottlenecks might be encountered with file subsystem operations, network communication, interaction with a data base server, or even access to a shared memory bus.

Explore pipelining as a mechanism to introduce parallel behavior into applications that might appear to be highly sequential. Figure 1 shows an example of such an application. This same algorithm can be effectively scheduled on two processors as shown in Figure 2. Pipeline execution does not reduce the time required to process any particular set of input values. However, it allows an increased frequency of processing inputs. In the original sequential version of this code, the control loop ran once every 20 ms. In the two-processor version, the control loop runs every 10 ms.

This particular example is motivated by discussions with an actual customer who was finding it difficult to maintain a particular update frequency using a sequential version of their programmable logic controller (PLC) software. In the two-processor version of this code, one processor repeatedly reads all input values and then calculates new outputs while the other processor repeatedly logs all input and output values and then writes all output values. This discussion helped them understand how they could use multiprocessing to improve update frequencies even though their algorithm itself was inherently sequential. With two processors working together on a pipelined solution, the system is able to perform, on average, a complete actuator update every 10 ms, with each processor doing roughly

tech in systems

Calculate Read input outputs based Log all input values from and output on PID 1,000 sensors control values algorithm Calculate Read input outputs based values from on PID 1,000 sensors control algorithm

Write output values to 1,000 actuators Log all input Write output and output values to 1,000 values actuators

Calculate Read input outputs based Log all input values from on PID and output 1,000 sensors control values algorithm Calculate Read input outputs based values from on PID 1,000 sensors control algorithm

Write output values to 1,000 actuators Log all input Write output and output values to 1,000 values actuators

Calculate Read input outputs based Log all input Write output values from and output values to on PID 1,000 1,000 sensors control values actuators algorithm

0 ms

5 ms

10 ms

15 ms

20 ms

Figure 3 Four-Processor Pipelined Implementation of Soft PLC.

half of the computation that would have been required to achieve a 10 ms update frequency on a single processor system.

The two-processor pipeline was suggested based on an assumption that the same I/O bus is fully utilized by the input and output activities. If inputs are channeled through a different bus than outputs, or if a common I/O bus has capacity to handle all inputs and outputs within a 5 ms time slice, then the same algorithm can run with a fourprocessor pipeline, yielding a 5 ms update frequency, as shown in Figure 3.

Remember that one goal of parallel restructuring is to allow each thread to execute independently, with minimal coordination between threads. Note that the independent threads are required to communicate intermediate computational results (the 1,000 input values and 1,000 output values) between the pipeline stages.

A naive design might pass each value as an independent Java object, requiring thousands of synchronization activities between each pipeline stage. A much more efficient design would save all of the entries within a large array, and synchronize only once at the end of each stage to pass this array of values to the next stage.

Relevant code for implementing the pipeline in Figure 3 is shown in the sidebar “Partial Java Implementation of

Four-Stage Pipeline,” p27. The Main class provides the main() startup method. This main() program instantiates two FIFO buffers to connect stages of the pipelines, plus four Stage objects. Each FIFO is associated with three buffers. This allows one stage to fill one buffer, while second and third stages are each reading previously stored data from distinct buffers.

Code is not shown for the FIFO or Buffer data types.

Code is shown for Stage1 and Stage2. The code for the other stages is very similar. Each Stage extends Thread, and all four threads are started from the main() program. Note that the constructors for each Stage identify the desired start time. Each pipeline stage requires 5 ms. During the first 5 ms, only the first stage can run because there is no data ready for the subsequent stages. During the second 5 ms, only the first two stages can run, and so on.

Refer to the run() methods in the Stage1 and Stage2 classes to see the code that is executed by each stage. The implementations of the FIFO and Buffer classes are not shown. However, it is important to recognize that no synchronization is required for any Buffer operations.

That’s because each Buffer is visible to only one thread at a time. Synchroniza-

tion is required in the implementations of the FIFO operations. That’s because each FIFO represents a communication channel for coordination between two neighboring pipeline stages. In order for Stage1 to receive an empty buffer, Stage2 has to evacuate a previously filled buffer.

Thus, the Stage1 loop performs only two synchronizations every 5 ms. And the Stage2 loop performs four synchronizations every 5 ms.

Multicore hardware and system design is an inevitable progression of technology that enables more processing to be done with less power consumption and cost, but these gains can’t be fully realized without incurring associated increases in software complexity. Java enables developers to more efficiently address these complexities than is possible with other languages.

Atego Systems San Diego, CA. (858) 457-2700. [www.atego.com].

RTC MAGAZINE JULY 2010

29

technology deployed Medical Devices

Ensuring Software Quality in Embedded Medical Devices

to any application that is life-sustaining or invasive, such as an artificial heart (i.e., Class III).

• Part 820: This section defines the expectations the FDA has for the process under which a device is developed and manufactured. The software you write for an embedded device may not need to demonstrate compliance with this standard if it is to be classified as Class I under Part 860, but this can vary. For embedded engineers, this means that you not only have a development process, but that it’s documented and can be demonstrated to the FDA. This is In medical devices, increasing complexity and market similar in many regards to the popular ISO 9000 standard for a controlled process. pressure bring additional risk and cost associated with • Part 11: Any application that has acdefects. Attention to quality standards as well as the use cess to or creates patient data needs to enof fundamental tools and practices can be applied to help force very specific practices to ensure the accuracy and integrity of the information meet these standards and mitigate the risk. as well as observe privacy laws when appropriate. Unlike some of the other more vague standards, Part 11 is very specific

by Elijah Kerry, National Instruments when it comes to criteria such as passwords and authentication.

In addition to these standards, it’s imhe term “medical device” is used to refer to any item that portant to consider whether you will need to submit a Pre-Market treats, diagnoses, prevents or monitors patients. This ranges Notification (PMN) or file for Pre-Market Approval (PMA). The from simple stethoscopes, to teleoperated surgical devices, distinction between these comes down to whether or not a preto implantable defibrillators. As the complexity of these appli- existing or “substantially equivalent” product has already been cations increases along with the power of embedded hardware, released prior to May of 1976. Any and all Class III Devices medical devices have come to increasingly rely on complex em- have to submit a PMA so that the safety and effectiveness of the bedded software. The challenge of bringing these cutting-edge product may be evaluated by the FDA. An application for either devices to market is compounded by the need to ensure patient standard has to include information demonstrating software desafety and meet regulations set by agencies like the Food and velopment, verification and validation information.

Drug Administration (FDA).

Ultimately, it’s important to engage the FDA early in the process in order to confirm the regulations and requirements that apply Breaking Down Medical Device Standards to your device. However, meeting the regulations does not mean that The FDA is responsible for administering Title 21 of the any and all risks of failure or harm have been removed, as shown Code of Federal Regulations (CFR), which is intended to cover by the recent increases in medical device recalls. This further unany and all products that could impact the welfare, health, or derscores the importance of abiding by best practices to ensure the safety of people. Of the hundreds of parts within Title 21, there quality and reliability of embedded software applications. are a few in particular that engineers working on embedded medThe use of the best practices serves to help identify, resolve and ical devices should be aware of. prevent defects in software as early in the lifecycle as possible. A •Part 860: One of the fundamental questions that should be medical device recall is the most costly and damaging result of a examined as early as possible is “will the FDA consider my ap- missed defect or problem, and can be devastating to the reputation of plication a medical device, and if so, what kind?” The answers to a company. However, an increasingly competitive market puts presthese questions can have a significant impact on the development sure on developers to meet hard deadlines at the expense of quality. process and the cost to certify and productize an FDA-approved This trend has been blamed by many for the recent spike in Class III application. There are three classifications of medical devices, Recalls, which represents the most serious recall category. As a reranging from non-threatening devices like dental floss (i.e., Class sult, officials at the FDA have indicated the possibility of modifying I), to non-invasive applications like CAT Scanners (i.e., Class II), Part 820 to require stricter quality system regulations.

T

30

JULY 2010 RTC MAGAZINE

Technology deployed

Cost Reduction and Time-to-Market Drive Medical OEM Outsourcing of Embedded Computers

by Erich Heikkila, Venture Development Corporation Primary Reasons for Medical Respondents’ Company Obtaining Embedded Boards from Third-Party/ Outsourced Suppliers (% of respondents identifying) 70%

Meeting cost reduction goals Meeting time to market compression goals

57%

Re-organization / staff reduction-driven

Figure 1 FPGAs have become increasingly popular as they allow designs to rapidly be prototyped and tested in hardware for difficult control systems, which are increasingly common in medical applications.

Best Practices for Ensuring Quality

Ensuring the quality and reliability of an embedded application requires a strong understanding and use of software engineering practices. Software engineering generally refers to a regimented and procedural methodology for designing, developing and testing applications. While multiple-process models for software engineering have emerged over the years, they almost all describe specific phases and criteria that must be met before moving on in the lifecycle process. Certain practices from within the software engineering process are recommended for engineers developing embedded medical devices.

First it is important to define a process. Ideally, all software vendors have a path that leads from the initial concept to a deployed application. However, in the medical field it’s not enough to trust that a process exists; the process needs to be documented.

Additionally, it’s important to document how and when the process was followed with regards to a specific project or application.

Ensuring this process is documented makes people more accountable for some of the less pleasant tasks like code reviews, documentation and unit testing. It also makes it possible to bring new engineers into an existing project, as their tasks and checklists are prescribed. Finally, it provides an audit trail for the FDA, which helps demonstrate that you’ve done your due diligence to ensure proper and safe operation. Failure to do so can not only open the doors for software bugs, it can lead to allegations of negligence.

Within the process, the use of a change management system is imperative. Developing any software without a change management system is like playing with fire—you are going

35%

Developing the platforms no longer a differentiator

13%

Specific customer request or requirement

13% 9%

Other competitive pressures 0%

10%

20%

30%

40%

50%

60%

70%

80%

When VDC Research Group surveyed 50 medical/ healthcare OEMs for the medical module of its 2010 embedded hardware demand-side research in Q2 of 2010, the medical customers were asked about their current and expected future utilization of outsourced embedded computer platforms. Medical OEMs are certainly big-time users of merchant embedded platforms. Ninety-six percent of the medical customers surveyed were already outsourcing some portion of the embedded computers used in the medical equipment they were building. And the majority of these OEMs expected that in five years time they would be outsourcing a greater percentage of their embedded computers to merchant third-party embedded suppliers.

The main reasons that the medical customers cited for outsourcing their embedded compute platforms rather than building them in-house were meeting cost reduction and time-to-market acceleration goals. Customers in the medical vertical market are under extreme cost containment pressure and must implement highly efficient product development models to remain competitive, which is driving their adoption of merchant/outsourced embedded computers.

RTC MAGAZINE JULY 2010

31

technology deployed

Figure 2 FPGAs, like the one deployed in this Retinal Disease Treatment Device from OptiMedica, help scientists bring new concepts and research to market much faster than custom ASICs while still satisfying the regulatory requirements of the FDA. Photo courtesy of OptiMedica

to get burned. Change control systems are a critical component of any development process. As the name implies, they provide mechanisms for tracking and understanding when something in the application is modified, who modified it and the potential implications of the modification. One of the most fundamental components of a change control system is source-code control.

FPGAs, or Field Programmable Gate Arrays, represent one of the most important tools for embedded programmers working on safety-critical applications and should be used for critical components. FPGAs allow developers to define low-level, timing-accurate hardware behavior, which is paramount in control and safety applications. FPGAs also make it easy to execute timing-accurate operations in parallel, ensuring that nothing else can occur to interrupt a safety-critical operation. This complex hardware component can also shorten development time with the help of tools like LabVIEW, which makes it easy to rapidly iterate on different concepts in hardware instead of producing custom ASICs (Figures 1 and 2).

Don’t confuse prototypes with development. Keep them separate. New projects, especially at small start-ups, often ignore development process and structure in order to deliver a prototype that demonstrates a new proof-of-concept. For start-ups, this is often an important part of receiving additional funding. At estab-

32

JULY 2010 RTC MAGAZINE

lished companies, this is often done to uncover potential patents or explore new research areas. However, one of the biggest follies to be avoided is to attempt to productize an application by simply polishing a prototype. Use the prototype to refine and define requirements as well as to estimate project timelines, but keep this separate from the development of the end-use application. Not doing so leads developers to skip over architectural and design considerations, which are mandated steps in any software engineering lifecycle.

Do use prototypes to derive specifications and requirements.

In a perfect world all software projects would begin with complete requirements that represented the exact same vision for all stakeholders. However, the reality is different stakeholders have slightly different expectations for the final product during the early part of the lifecycle. Prototypes serve as a way to help align multiple parties with the expectations for the final product, which mitigates the need for last minute changes or feature-creep.

Manage and track requirements traceability. As we acknowledged earlier, requirements evolve and change throughout the development process. Understanding how these changes impact the entire application requires traceability from code to requirements. This can be achieved by requiring that developers enumerate requirements as they cover them in the implementation.

For a project manager, tools like Telelogic DOORS and Requisite Pro are designed to manage and track the relationship between different requirements. They also integrate tightly with tools like National Instruments Requirements Gateway, Geensys’s Reqtify and LDRA’s TBreq to trace these specifications to the implementation automatically. Finally, these tools will also generate traceability matrices, which are expected as part of your documentation for the FDA. In light of growing recalls and highly publicized defects in embedded devices, it’s impossible to ignore the need for a structured development approach that ensures safety and complies with regulatory standards. In addition, developers must satisfy these quality requirements while meeting increasingly shortened deadlines in order to remain competitive.

The good news is there are some fundamental software engineering practices that can be employed by companies of any scale for projects of any scope. The extent to which certain tools or processes are followed depends heavily on the criticality of the application, but their proper use can serve to improve the quality and reliability of all embedded applications.

National Instruments Austin, TX. (512) 794-0100. [www.ni.com].

technology deployed Medical Devices

Medical Device Software: Why Has It Gone Code Red?

A repeatable process for medical device software ensures that the same levels of software quality are met for the initial product certification and any subsequent release.

Criteria for software quality take into account not only the core functionality of the device, but also the device safety integrity level classified by the FDA as the software Level of Concern. It would not be economically viable, for instance, to apply the same software development rigor in the development of a cardiac defibrillator (major level of The typical medical device software engineering process concern) to the development of an electronic thermometer (minor level of concern). often suffers from gaps in repeatability. These gaps Guidance for establishing a repeatable present enormous legal and financial risks to suppliers process that addresses the quality and safety concerns of medical devices that meet or exas well as health and safety risks to patients. The use exploration ceed international standards can be obtained r your goal of application lifecycle management within a project can from both the FDA and the international eak directly effectively mitigate these risks. community. In its document Guidance for page, the resource. the Content of Premarket Submissions for hnology, Software Contained in Medical Devices nd products issued on May 11, 2005, the FDA clearly

by Bill StClair and Nat Hillary, LDRA outlines the documentation that is required for the certification of a medical device to include software requirements specification, n FDA analysis of 3,140 medical device recalls conducted software design specification and traceability.

It’s also necessary to produce a software development environbetween 1992 and 1998 reveals that 79% of software-rement description, a document that outlines the software development lated recalls were caused by software defects introduced panies providing solutions now process(es) used for the device. For this, the FDA recognizes as a when changes were made to the software after its initial producation into products, technologies and companies.

Whether your goal is to research the latest consensus standard the international standard IEC 62304 Medical tion and distribution. The primary cause of these critical failures: cation Engineer, or jump to a company's technical page, the goal of Get Connected is to put you Device Software – Software Lifecycle Processes, so any compliant repeatability. A software development process with a lack of rece you require for whatever type of technology, software development process meets the FDA requirement. peatability is destined to failure. es and products you are searching for.

Defining a repeatable software development process is vitally All software contained in medical devices with a level of conimportant.

Figure 1 describes the software development process adcern of major or moderate are inherently safety critical (Table 1). vocated by IEC 62304 for medical device software. This standard Therefore, when submitting a device for certification, manufacturdefines a rigorous software development process that incorporates ers must show that hazards are appropriately identified with risks the concept of risk (or safety) throughout the software development managed effectively, in addition to providing traceability to link process and incorporates the need for both configuration managetogether design, implementation, testing and risk management. ment and defect tracking (i.e., problem resolution) systems.

In addition, to address both domestic and international Layered on top of the IEC 62304 software development promarkets, manufacturers are subject to laws and regulations that cess must also be the FDA requirement for traceability, which is a further complicate this task, such as the International Standards key factor in defining a repeatable software development process.

Organization (ISO) standards ICS 11.100.20 and 11.040.01 for Traceability ensures that each high-level requirement originatmedical devices, the International Electrotechnical Commission ing in the system development activity step (as shown in Figure (IEC) standard IEC 62304 for medical software, and the FDA Get Connected 1) is traced through the requirements decomposition tree down guidancewith published the Code of Federal Regulations: 21 companiesagainst mentioned in this article. through the software design process and is then implemented and CFR Subchapter H – Medical Devices. It is not surprising that www.rtcmagazine.com/getconnected medical device manufacturers complain that 80% of their soft- traced to code. This traceability must also map to the validation and verification activities used to ensure that the medical deware development budget goes into documentation and testing. vice software meets its functional and safety requirements. This yields a traceability matrix, where all of the traceability informaGet Connected with companies mentioned in this article. www.rtcmagazine.com/getconnected tion is captured into a single document or database.

A

End of Article

34

JULY 2010 MONTH 2010RTC RTC MAGAZINE MAGAZINE

Technology deployed

A traceability matrix maps the decomposition of each requirement into one or more sub-requirements, design elements, code and validation and verification activities. From this, the reverse is also true, so that any validation and verification task, design element or sub-requirement can be mapped back to its original requirement(s), whether primary or derived.

Maintaining a traceability matrix has two significant benefits. First, it helps in the certification process by providing clear documentation of how high-level requirements translate to code.

Second, it assists in assessing the impact of any requirements, design or software changes. This latter point is especially important when it comes to post-release software, as the impact of any changes can be accurately assessed by determining how many system requirements, design, code and validation and verification activities are affected.

Where requirements are concerned, careful consideration must be made of the two primary sources of requirements: primary requirements that come from the system functional definition, and derived requirements that are inferred or derived from a primary requirement. For instance, a primary requirement may state that a system â&#x20AC;&#x153;differentiate between blood types O and B,â&#x20AC;? and a derived requirement might be the proprietary laboratory technique, including any necessary preconditions used to determine this. A traceability solution needs to accommodate both primary and derived requirements.

For all but the most simple medical device software projects, manually creating and maintaining a traceability matrix is an arduous and error-prone task when done between high-level and low-level requirements. In a typical project, the number of system level and operating requirements multiplies up to five times when decomposed into sub-requirements, so a project of 100 primary system and operation requirements would decompose into 500 sub-requirements.

When you add derived requirements and map all of these to the design and code implementation, the complexity of manually creating and managing the traceability matrix magnifies. Extend this manual traceability to incorporate validation and verification activities, and you multiply both the effort and the possibility of introducing an error by an order of magnitude.

In a conservative example, if each high-level requirement traces to five sub-requirements, each of which maps to a single procedure in code and each procedure requires a set of five test cases for validation and verification (known good inputs, known bad inputs and three input parameter bounds tests), then it becomes immediately clear how challenging such an endeavor is.

The traceability matrix would need to track the one-to-one, oneto-many and many-to-one mappings from the original 100 requirements through the decomposition to 500 sub-requirements to 500 procedures in code, and then onto 2,500 test cases.

Although itâ&#x20AC;&#x2122;s tempting to simply ignore such a step, the impact of maintaining this mapping from high-level requirements through the decomposition, design, implementation and valida-

Activities outside the scope of this standard

Customer needs

Customer needs satisfied

System development activities (including risk management)

7 Software risk management 5.6 5.8 5.7 5.5 5.4 5.3 5.2 5.1 Software Software Software Software Software Software unit Software Software integration development requirements architectural detailed implementation and integration system release testing design & verification design analysis planning testing 8 Software configuration management

9 Software problem resolution

Figure 1 The International Electrotechnical Commission developed the IEC 62304 Software Lifecycle Processes for Medical Device Software to provides a framework of life cycle processes necessary for the safe design and maintenance of medical device software.

Requirements Engineering

Requirements

Modeling Integration

Analysis & Design

Planning

Static and Dynamic Analysis

Implementation

Initial Planning

Test Verification Enterprise Reporting

Test Evaluation Target IDE Integration

Automated Unit Testing

Deployment

Figure 2 An application life cycle solution, automatically feeds data back and forth through the phases of development.

Thanks to automatic updating, immediate feedback is provided for problems such as a primary requirement not tracing down to sub-requirements or code without tests, etc. With this approach, testing begins much earlier, preventing development from proceeding based on errant code.

RTC MAGAZINE JULY 2010

35

technology deployed

tion and verification processes is so significant, especially for certification, that it cannot be ignored.

This is where Application Lifecycle Management (ALM) solutions step in, providing a way for a development team to get their arms around the need to manage the myriad of details in a way that is cost-effective. Given that all medical device projects containing software include at least one processor, an IDE, an RTOS and other development tools, medical development teams should seek an ALM solution that addresses the extensive microdetail of embedded devices to ensure that a repeatable software development process can be developed and maintained.

Application Lifecycle Management (ALM)

ALM is made possible by tools that facilitate and integrate software development activities such as requirements management, traceability, coding, software analysis, testing and configuration management. Whether it is a requirement, line of code, or test case, each artifact in the development process has its own lifecycle and workflow. It is the job of an ALM solution to provide a framework that supports the creation and evolution of each artifact through its lifecycle as a component of a complete product.

In Figure 2 the role of an ALM solution, such as the EmbedX solution from LDRA, within a typical embedded software development lifecycle can be understood.

Whether a new product or a new version of an existing product, the process normally starts with requirements capture, something that is handled by either a formal requirements management solution or using standard office editing tools. As requirements are developed and evolved, requirements decomposition occurs whereby high-level requirements are translated into sub-requirements. It is also at this phase that derived requirements start to appear. An embedded ALM solution supports both requirements management and the ability to trace the evolution of requirements through the decomposition process, including the translation of requirements into the software design phase.

Once the code creation part of the process is reached, the ALM traceability solution extends to the software itself, creating a mapping from the high-level requirements through design and onto the actual code. At this phase, the code validation and verification tasks can be performed.

The validation and verification of safety-critical embedded software incorporates a number of different phases, starting as soon as the code is first created. An embedded ALM solution assists in the process of building quality into the software from code creation onward, combining static analysis, unit and module testing, and dynamic code analysis.

Static analysis assesses the code under development without executing it, ensuring that errors and defects can be identified in code at the point of creation. A number of coding standards have been developed by industry groups specifically for high-reliability software. Medical developers could borrow from these disciplines and use other safety-critical standards such as the Motor Industry Software Reliability Association (MISRA) standard MISRA-C:2004 or MISRA C++. These standards identify code constructs that are known to introduce latent defects in software, compromising dependability, and should therefore be avoided.

Static analysis tools enforce these standards, in addition to iden-

36

JULY 2010 RTC MAGAZINE

Software Level of Concern Major

Description A failure or latent flaw could directly result in death or serious injury to the patient or operator, or a failure or latent flaw could indirectly result in death or serious injury of the patient or operator through incorrect or delayed information or through the action of a care provider

Moderate

A failure or latent design flaw could directly result in minor injury to the patient or operator, or a failure or latent flaw could indirectly result in minor injury to the patient or operator through incorrect or delayed information or through the action of a care provider.

Minor

Failures or latent design flaws are unlikely to cause any injury to the patient or operator.

TABLE 1 The FDA classifies medical devices according to the software level of concern; an estimate of the severity of injury that a device could permit or inflict on a patient or operator as a result of device failures, design flaws, or simply by virtue of employing the device for its intended use.

tifying other issues in software, such as unnecessary complexity that may affect code testability or maintainability.

Once the medical device code has been verified to meet the selected code standard, it is ready for unit and module testing. Incorporating a unit and module testing tool into an Embedded ALM solution enables the generation of requirements-based tests. The beauty of the integration inherent in an ALM solution ensures that the pass/fail results of these tests map back to the original requirements so that the project manager can monitor the current status.

While executing the code for either unit, module or system tests, it is then possible to perform dynamic analysis on the code under test. For example, it is possible to use coverage analysis to assess the effectiveness of the testing to date. Once again, the ALM integration tests completeness of the information which all maps back to the requirements in order that the project manager can monitor status. Not only does an ALM solution enable the monitoring and management of software through the development process, but the traceability of requirements through the development process to code and the associated verification activities and results also make documentation for project status and/or certification as straightforward as pushing a button.

Experience in other industries, such as avionics, has shown that seeking certification of a safety-critical software project drives the adoption of repeatable software development processes. The value of the concept and application of an Application Lifecycle Management tool suite within an avionics development process has been proven time and again within the avionics community.

By adopting the software development processes advocated

by IEC 62304, the medical device software development community ensures that software-related defects attributed to software maintenance can all but be eliminated. At the same time, by managing the evolution of a project from requirements through design, coding and validation using an embedded ALM solution, they can make a significant dent in the 80% of development time typically spent on documentation and testing.

LDRA San Bruno, CA. (650) 583-8880. [www.ldra.com].

USB Module & Data Acquisition

Showcase

USB-AO Series: Multifunction USB/104 modules provide up to 16 Analog Outputs and 2 Analog Inputs

Featuring the latest in USB Module & Data Acquisition technologies ACCES I/O Products, Inc. Phone: (858) 550-9559 Fax: (858) 550-7322

P104-WDG-CSMA: PC/104Plus Watchdog Timer Status Monitor

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

E-mail: contactus@accesio.com Web: www.accesio.com

Delkin Devices, Inc.

Delkin Embedded USB Modules have an optional Tekta˙ Infusion process that enables protection from virtually all environmental elements, including: high altitudes, sand, dust, chemicals, water, humidity, fungus, extreme temperatures, shock, vibration and impact.

Capacity: 128MB ~ 16GB High-speed USB 2.0 compatible Static & dynamic wear-leveling Error Correction: Up to 12bit BCH ECC per 512 Bytes High-performance SLC (Single Level Cell) Flash Low power consumption allows USB interface to supply module Industrial and Tekta˙ temp. available (-50°C ~ 100°C)

Phone: (800) 399-5257 Fax: (858) 391-1417

E-mail: sales@delkinoem.com Web: www.delkinoem.com

Model 5350: 3U VPX with Quad 200 MHz, 16-bit A/D and Virtex-5 FPGAs

USB Embedded Modem Modules USB modems, in module or standalone form factor Linux, Windows and Mac O/S support -40C to +85C operating temperature (Module) Compact size: 1” x 1” x 0.2” (Module) USB 2.0 compatible up to 56K bps data rate, fax and voice AT command Transferable FCC68, CS03, CTR21 telecom certifications Global safety: IEC60950-1, IEC606011 (Medical) approved CE marking

3U VPX provides a compact rugged platform Supports gigabit serial fabrics including PCIe, RapidIO and Aurora Four 200 MHz, 16-bit A/Ds Up to 1 GB DDR2 SDRAM Two Xilinx Virtex-5 FPGAs Clock/sync bus for multiboard synchronization Ruggedized and conduction-cooled versions

Pentek, Inc. Phone: (201) 818-5900 Fax: (201) 818-5904

E-mail: contactus@accesio.com Web: www.accesio.com

Embedded USB Module

PC/104-Plus watchdog timer Watchdog open collector reset outputs Temperature sensor with calibration pot Temperature monitor / alarm Temperature measurement with 8-bit A/D Fan status and speed control PCI/104 power monitor / limit alarm Opto-isolated input to trigger reset General purpose opto-isolated input Two isolated outputs, current limited TTL reset pushbutton input Two general purpose 8-bit A/D inputs Light sensor for enclosure security

ACCES I/O Products, Inc.

4, 8, or 16 analog outputs with 12 or 16-bit resolution USB/104 form-factor for OEM embedded applications PC/104 module size and mounting compatibility Two 16-bit analog inputs and 16 lines of digital I/O Connections made via industrystandard 37-pin D-Sub connectors Alternate micro-fit embedded USB header connector Type B USB connector features industrial strength and high-retention design Extended temperature

Radicom Research, Inc. E-mail: info@pentek.com Web: www.pentek.com/go/rtc5350

Phone: (408) 383-9006 Fax: (408) 383-9007

E-mail: sales@radi.com Web: www.radi.com

technology deployed Medical Devices

Embedded Technology Powers Healthcare Device Accessory to Improve Patient Ventilator Monitoring Through the development of a medical device accessory to capture ventilator data from a patient ventilator, embedded technology was able to improve patient care, balance clinician requirements for a more accurate picture of patient health and succeed with a long FDA approval process.

by Pete Dombrowski, Eurotech

T

he Engström Carestation is an expandable respiratory care station from GE Healthcare. Its design is intended to help satisfy clinicians’ need for accurate, timely data with advanced features, networking options, equipment integration, patient care documentation and medication delivery. The ability to recreate the past has become an expectation and nearly a requirement in the monitoring of a patient’s heart rate and other patient vital signs, and ventilators should be able to provide the same level of detailed patient data.

In order to gather more meaningful data from Engström ventilators, GE Healthcare began to develop a portable data capture device accessory. The solution would need to be designed for ease of installation, and most importantly, it needed to capture the output data of the ventilator reliably and continuously. GE Healthcare had to develop a modular, wireless device accessory that could move with the patient for constant data capture. The platform needed to function independently from the Engström—a life support product that can never fail—so as not to impact its operation in any way.

Designing an Embedded System for a Medical Device Accessory

The new medical device accessory, called EView (Figure 1), runs on Microsoft Windows, as do many other offerings from GE Healthcare. GE Healthcare chose to work with Eurotech for the

38

MONTH JULY 2010 2010RTC RTC MAGAZINE MAGAZINE

Figure 1 The EView medical device accessory collects vast amounts of ventilator data reliably and continuously to allow clinicians to record patient health moment-by-moment.

embedded computing platform. Based on prior experience, Eurotech was uniquely familiar with the specific medical equipment design requirements needed to qualify for 510(k) certification.

The new medical device accessory needed to meet the following requirements from GE Healthcare: 1. M ount on the back of the Engström Carestation’s display unit 2. Connect to the Engström Carestation via a single 9-pin connector 3. Buffer waveform, numeric, setting, checkout/calibration and alarm data 4. Output data to transfer media in a Microsoft Excel version 9 (Excel 2000) or newer compatible format GE Healthcare and Eurotech worked together to create a solution designed to better serve the healthcare industry and its potentially chaotic working conditions. The resulting data capture device accessory, called the EView, is based on the Eurotech TurboXb computer-on-module (COM). The embedded COM was customized to satisfy secure data transmission needs and stringent power requirements while meeting FDA guidelines (Figure 2).

Secure Data Transmission

The EView medical device accessory needed to collect vast amounts of ventilator data reliably and continuously to allow clini-

Technology deployed

cians to record a comprehensive view of patient health. GE Healthcare wanted to allow clinicians to gather data at all times, with customizable settings to meet every patient’s unique situation. The embedded system powering the EView needed to communicate with the Engström Carestation to obtain ventilator information and store patient data. The top priority was to ensure that if the device accessory lost power, none of the data would be lost.

The COM was designed to bring data to the board and store it as a file in a compact flash card, secure digital card or USB memory. However, if the device accessory suddenly lost power, the files could be corrupted and some of the data could be lost. As a result, the carrier board was designed with a supercapacitor, a power storage device that can be charged up and store enough power to run the system for seven seconds after loss of primary power. The supercapacitor allows the EView to run long enough after the power loss is detected to allow the software to finish storing all of the data to the file. Essentially, the supercapacitor allows the EView to reach a safe state before allowing the device accessory to power down.

A usability issue was discovered during system level testing.

The system did not prevent removal of the secure digital memory card while a file was being written. If a user removed the card, it created a functional problem for the file system, which could not resume use of the card after it was reinserted. This significant issue had to be solved, since there was nothing to prevent it from happening once the units were in the field. After a detailed investigation into the low-level operation of the secure digital card driver, a fix was created that ensured proper system operation after sudden removal of the secure digital card.

Low-Power Consumption

Since the EView would be powered by tapping into the reserves of the Engström Carestation, the embedded system was only allotted two to three watts of power. To meet the low-power requirement, some of the ways the COM typically operates were changed.

When the system first powers up, the supercapacitor is not charged.

The supercapacitor has to be charged and the system has to boot, all with a collective power budget of under three watts. One design goal was to minimize the time after power on before the system was ready for use and protected by a charged supercapacitor. If there were no power limitations, the system could have powered on and charged the supercapacitor in parallel. However, there had to be a compromise to keep within the power budget, so two alternatives were proposed.

The first option diverted more available power to charging the supercapacitor by reducing the operational speed of the COM. Once the supercapacitor reached a state where it could preserve data, the system switched to full speed operation and continued operation at the faster rate.

As an alternative, GE Healthcare could keep the COM in reset mode while the supercapacitor charged as fast as possible. This option reduced the total amount of time before the system was ready for operation, since the charge of the supercapacitor defined when

Figure 2 Eurotech’s TurboXb computer-on-module was customized to satisfy secure data transmission needs and stringent power requirements.

the system could begin to store data and achieve power loss protection. As a result, GE Healthcare chose the second option to help the EView achieve a faster start-up and better user experience.

FDA Requirements

All medical devices and medical device accessories must meet a list of regulatory requirements. Each requirement requires extra testing and specialized design considerations, including the following for the EView: Temperature: When operating, the temperature inside the EView could not exceed 50°C at an ambient temperature of 40°C. This was easily accomplished with the low power consumption of the TurboXb-based system.

Static Electricity: Designers had to ensure that static electricity from user contact would not damage or interfere with operation of the unit.

Vibration and Shock: When mounted on the Engström Carestation, the EView had to be capable of withstanding 1000 threshold cycles without affecting operation. A threshold cycle consisted of all wheels of the cart system passing randomly over a 3/16” thick by ½” wide threshold, rotating 180 degrees and returning back across the thresholds to its original position.

Isolation: Medical standards governed how the signals were connected between the components and how far apart the signals were on the circuit board. The requirements ensure that if there was a hazardous voltage that passed through the system, it could not jump from one signal to another, eventually reaching the user.

Reduction of Hazardous Substances: Reduction of Hazardous Substances standards call for reduction to less than 0.1% of weight in homogenous materials for lead, mercury, hexavalent chromium, Polybrominated Biphenyls (PBB), Polybrominated Diphenyl Ethers (PBDE), and less than 0.01% of cadmium.

Manufacturing Facility Approval: GE Healthcare visited and approved the manufacturing facility Eurotech used to build the RTC MAGAZINE JULY 2010

39

technology deployed

embedded system that would power the EView.

Documentation: The FDA requires detailed documentation for medical device accessories, so Eurotech was required to keep very detailed documentation on the embedded systems design.

Any changes in the design required documentation and approval.

Figure 3 The EView attaches directly to the back of the Engström, capturing the output data of the ventilator.

The Result: A Step Forward in Respiratory Care

The EView is designed for quick installation, and the accessory is also very rugged for the healthcare environment. To meet regulatory requirements, the device was tested and adjusted for shock and vibration, electrostatic discharge, electromagnetic emissions and temperature as part of the product development process.

The EView attaches directly to the back of the Engström, capturing the output data of the ventilator (Figure 3). Once captured, this data is then available to the clinician for downloading and viewing at any given time. The mobility of EView also allows the device accessory to move from one Engström ventilator to another.

EView offers the ability to look back as far as seven days and recreate the past, allowing for evaluation and review of patient information at a very detailed level. Detailed information at this level can not only influence current patient care, but also guide a clinician toward developing specialized solutions to meet individual and unique patient requirements. Eurotech and GE Healthcare worked together to develop a product that utilizes innovative embedded technology with a long useful life. Medical device accessories typically depreciate after about seven years, but due to budget and time constraints they often remain in the field much longer.

Eurotech Columbia, MD. (301) 490-4007. [www.eurotech.com].

Affordable performance, super low power!

The new Tomcat single board computer gives you great performance in an affordable low power package. This compact PC/104-Plus embedded computer is backed by VersaLogic’s long-term (5+ year) product availability guarantee and legendary quality.

Q Q Q Q Q Q Q

800 MHz Vortex86DX processor 128 to 512 MB soldered-on DDR2 RAM Low power. 2.7W (typical)!

PC/104-Plus expansion Only 3.8” x 3.8” Industrial temp. (-40 º to +85ºC) version CompactFlash socket

Evaluate the Tomcat for your application today. Customization is available in low OEM quantities.

With more than 30 years experience delivering extraordinary support and on-time delivery VersaLogic has perfected the art of service, one customer at a time. Experience it for yourself. Call 800-824-3163 for more information!

Recipient of the VDC Platinum Vendor Award for five years running!

800-824-3163 | 541-485-8575 | www.VersaLogic.com / tom

40

Untitled-5 1

JULY 2010 RTC MAGAZINE

7/20/10 12:54:29 PM

RTECC

TRANSPORTING ENGINEERS INTO THE WORLD OF EMBEDDED

RTECC provides world-class engineers with world-class exposure to the latest technology in the embedded computing market. We offer...

Market-revealing keynote speakers Technically focused embedded seminars and workshops Vendors demonstrating newest technologies Network opportunities with the

ARE YOU BEING LEFT BEHIND?

embedded industries brightest engineers

UPCOMING LOCATIONS Seattle, WA 08/24/10 Austin, TX 09/14/10 Dallas, TX 09/16/10

Can you afford to miss it? FREE admission, lunch, parking and prize drawing entries at each event.

RTECC is your best opportunity to discover a new world of possibilities within the embedded market.

www.RTECC.com

REGISTER FOR FREE TODAY!

products &

TECHNOLOGY Rugged Atom-based SBC the Size of an iPhone

A new Intel Atom-based rugged SBC offers extremely low power consumption combined with an exceptionally small footprint and high performance. The Atom XPC40x (extended temperature, conduction-cooled) and Atom XP40x (standard temperature) from General Micro sytems satisfy the intense demand for an ultra-small com¬puter with full-size processing power.

Easily accommodating 64 gigabytes of storage via onboard solid-state disk in its miniature 3.5 x 2.5 x 0.5” package, the Atom XPC40x and XP40x boast 533 MHz DDR-2 SDRAM and are powered by a 1.6 GHz Intel Atom processor that provides 512 Kbytes of cache. With full laptop functionality, the module offers high-performance graphics with 3D accelera¬tion, and includes five USB-2.0 ports and support for two Express Mini Cards for Wi-Fi, CanBus or other user I/O. The Atom XPC40x is designed to operate at -40° to +85°C with a maximum thermal gain of only 5°C above ambient. Because of its heat tolerance, it is ideal for applications where ambient temperature is high, such as a controller located in an engine compartment or for small robots and UAVs working in extreme temperatures. With its exceptionally low power consumption/dissipation (3W average, 10W peak), it imposes little to no impact on the user, eliminating many inherent problems with wearable computers. Low power consumption means that the smallest support batteries can be used and the length of battery operating time is greatly increased. An additional benefit of its small size is security: in situations where storage needs to be removed for security reasons, now personnel can actually remove the whole computer.

As the smallest form factor currently produced by GMS, Atom XPC40x and XP40x are sutiable for applications that extend far beyond the military to fields such as medical and law enforcement. GMS also offers fully integrated systems based on this module.

The Atom XPC40x and XP40x support Windows XP/XPE, Vista, LINUX and VxWorks.

Pricing starts at $1,295 for the conduction-cooled XPC40x and $695 for the standard-temperature XP40x in single quantities.

General Micro Systems, Rancho Cucamonga, CA. (800) 307-4863. [www.gms4sbc.com].

PowerPC PrXMC Card Uses Freescale MPC8536E

An ultra-low-power Processor XMC module is based on the Freescale PowerQUICC III MPC8536E processor. The IC-PQ3-XMCa from Interface Concept is designed to offer both the Gigahertz-class complex application processing abilities and high-speed connectivity in a small board footprint.

Typical consumption in full-operational configuration (1 GHz) is 10W. The IC-PQ3-XMCa is suited for a large range of embedded applications such as compute-intensive solutions requiring high-speed I/O transactions, Gigabit Ethernet interfaces for high-performance network connectivity or redundant failsafe links, powerful control element for network switches, storage subsystems, network appliances, print and imaging devices, etc.

Other features include up to 1 Gbyte DDR2- ECC, 128 Mbyte flash, 4 Gbytes of NAND flash and up to three Gigabit Ethernet ports. The IC-PQ3-XMCa is available in standard, extended and rugged grades. Interface Concept provides BSP for VxWorks and Linux operating systems. Other RTOSs can be ported on request.

Interface Concept, Briec de l’ Odet, France. +33 (0)298 577 176. [www.interfaceconcept.com].

42

JULY 2010 RTC MAGAZINE

OpenVPX Tackles PED Challenge with GPU-Based Rugged Solution

One of the toughest challenges is to improve the warfighters’ situational awareness through timely and precise delivery of actionable information by PED capabilities. Mercury’s ISR subsystems are uniquely designed to provide these Embedded Smart Processing capabilities, enabling sensors to be smarter, able to accept unrelenting streams of data, and extract and deliver situational awareness and other crucial information to warfighters, empowering them to decide and react.

Mercury’s scalable intelligence, surveillance and reconnaissance (ISR) subsystem is powered by the Ensemble 6000 Series GSC6200—an OpenVPX module powered by GPU technology working in conjunction with Intel-based processing in a conduction-cooled, 6U form factor. The subsystem currently delivers performance in the TeraFLOPS range, and the incorporation of GPUs enables the solution to be delivered in an optimized size, weight and power (SWaP) footprint. Mercury’s innovative packaging technology on the GSC6200 leverages the easy-to-upgrade MxM GPU form factor, which enables customers to rapidly upgrade and deploy the latest and fastest GPUs from ATI or NVIDIA, resulting in even higher performance.

In addition to the GSC6200, other critical modules and services enabled the successful production of this subsystem. Mercury’s Services and Systems Integration team combined a multi-vendor hardware and software approach with their expert integration services to create the subsystem. The GSC6200 is providing industry-leading processing and exploitation capabilities to enable substantial SWaP improvements and parallel stream computing capabilities.

Mercury Computer, Chelmsford, MA (866) 627-6951. [www.mc.com].

PRODUCTS & TECHNOLOGY

CompactPCI Processor Board Brings Core i7 Performance to 6U Systems

A 6U CompactPCI SBC is based on the latest Intel Core i7 mobile processor technology. The CO6002 from Kontron is designed to bring high performance with low power consumption and low heat dissipation to a broad range of applications. With the 2.53 GHz Intel Core i7-610E or the LV 2.0 GHz Intel Core i7-620LE, the long-term available CP6002 speeds up multiprocessing tasks via hyper-threading technology (HTT) and also processes single-threaded tasks much faster thanks to the new Intel Turbo Boost technology. This allows for a clock speed of up to 3.33 GHz without exceeding the defined thermal design power (TDP) and without the need to oversize the entire system for peak loads. On the memory side, up to 8 Gbyte of soldered DDR3 1066 MHz ECC memory ensures data accuracy for demanding and safety-critical applications like radar, sonar, or imaging systems. In addition to the CompactFlash socket for rugged, industrial grade flash modules, up to 32 Gbyte of NAND flash (64 Gbyte upon availability) are possible via SATA interface, which are able to hold complete operating systems or application code, substantially increasing overall system speed and availability.

The Kontron CP6002 is offered in three versions, with either one (CP6002-R1) or two XMCs/PMCs slots (CP6002-R1-MC and CP6002R2-MC). The Kontron CP6002-R1 can further accommodate an onboard 2.5” SATA HDD/SSD and provides two Gigabit Ethernet ports, one VGA (CRT) port, one COM port and two USB ports on the front panel. The Kontron CP6002-R1-MC and CP6002-R2-MC provide one Gigabit Ethernet port, one DisplayPort (alternatively RS232) and two USB ports on the front panel. Kontron CP6002 supports a configurable 64-bit/66 MHz PCI or PCI-X, hot swap CompactPCI interface. When installed in the system slot, the interface is enabled, and when installed in a peripheral slot, the board is isolated from the CompactPCI bus. Safety and security features via an optional Trusted Platform Module (TPM) 1.2, two redundant firmware hubs (failover) and Intelligent Platform Management Interface (IPMI) are supported as well.

The CP6002 runs with VxWorks 6.8, Linux (RedHat), Microsoft Windows 7, Windows XP, XP embedded, or Windows Server 2003 or 2008.

Highly integrated support packages support all onboard hardware devices, and also specific features like hot swap ability, IPMI, power and thermal management, enabling effortless integration among scalable multi-CPU systems.

Kontron, Poway, CA. (888) 294-4558. [www.kontron.com].

OpenVPX Module Uses Freescale Eight-Core P4080 Processor

A high-performance 3U OpenVPX single board computer is based on the Freescale QorIQ P4080 processor. The XPedite5470 from Extreme Engineering Solutions delivers enhanced Power Architecture performance and power efficiency for today’s customers who require high performance in small form factors.

XPedite5470 provides Power Architecture computing with features including the Freescale P4080 processor with eight Power Architecture e500 cores running at up to 1.5 GHz, 8 Gbyte DDR3-1333 ECC SDRAM in two channels and 256 Mbyte NOR and 16 Gbyte NAND flash including hardware writeprotection for NVRAM. I/O includes Serial RapidIO, x4 PCI Express and SerDes Gigabit Ethernet interconnects plus Ethernet and serial ports.

X-ES is committed to delivering Freescale Semiconductor’s QorIQ P4080 in five additional unique form factors: 3U CompactPCI, PMC/XMC, VME, 6U VPX and 6U CompactPCI, covering the entire embedded product market. To satisfy the widest range of customer applications, from telecommunications to MIL-STD 810F military requirements, all of X-ES’s P4080 products are engineered to scale from air-cooled commercial (0 to 55ºC) to full conduction-cooled (-40° to +85ºC) with appropriate shock and vibration testing. Linux, Wind River VxWorks, QNX Neutrino and Green Hills INTEGRITY Board Support Packages (BSPs) are available.

Extreme Engineering Solutions, Middleton, WI. (608) 833-1155. [www.xes-inc.com].

Rugged EPIC SBC Offers SUMIT Expansion

A rugged EPIC single board computer (SBC) includes the SUMIT expansion connector, supporting both a single mezzanine card and multiple modules in a stack for optimal flexibility. The ReadyBoard 850 from Adlink Technology is based on the Intel GM45/ICH9-M chipset with the Intel Socket P processor socket, which supports a wide range of CPUs—from entry-level Intel Celeron M processors to the latest Intel Core2 Duo processors. The ReadyBoard 850 was developed to satisfy the most extreme conditions, has an operating temperature range of -20° to +70°C and meets MIL-STD-202 vibration up to 11.95 Grms and shock up to 15 Grms.

The ReadyBoard 850 strikes a balance between performance and feature set by including the additional I/O connectivity in the form of two PCI Express x1 lanes, one PCI Express x4 lane, two Ethernet ports, two SATA ports and up to 8 USB ports. In addition, there are up to 4 Gbytes of 1066 MHz DDR3 RAM plus both VGA and LVDS connectors and two serial ports. The ReadyBoard 850 also supports a full range of popular embedded and desktop operating systems including Linux (Ubuntu), VxWork 6.6, QNX 6.3, Windows Embedded CE 6.0 and Windows XP Embedded.

ADLINK Technology, San Jose, CA (408) 495-5557. [www.adlinktech.com].

RTC MAGAZINE JULY 2010

43

PRODUCTS & TECHNOLOGY

32 Gbyte Type 1 CompactFlash Card Has Wear Leveling Data Integrity Features

An industrial Type 1 CompactFlash card offers a capacity of 32 Gbytes and data transfer rates of 35 Mbytes/s for sustained write and 45 Mbytes/s for sustained read. The C-320 from Swissbit is designed to satisfy demanding non-volatile, high-reliability applications for transportation, aerospace, military, telecommunications, medical, mobile computing and factory automation requirements.

The C-320 CF card series use Single-Level Cell (SLC) flash technology, which provides a minimum of ten times (10x) the program/erase endurance over Multi-Level Cell (MLC) flash components.

Intelligent wear-leveling ensures that all dynamic and static data is balanced evenly across the entire flash memory card. This approach to wear-leveling will guarantee maximum write endurance. Full SelfMonitoring, Analysis and Reporting Technology (SMART) support is also built into all C-320 CF cards. Using this technology, the card can report its detailed lifetime status, which allows users to predict imminent system stops to avoid costly downtime. Various lifetime relevant statistics are available for analysis, such as the usable flash spare blocks and remaining guaranteed flash write life. The lifetime statistics information is collected online while operating, and the SMART status will change to warn when critical values are reached.

Swissbit has also developed an easy-to-use Windows or Linux application to interpret the lifetime statistical data. The applications also allow users to collect data in the background and display historical charts of all relevant values. This allows for detailed control over the lifetime statistics and aids in early failure prediction.

Data integrity is assured by use of a power-loss management system to prevent data corruption during an unexpected loss of power. Support is provided for UDMA4, MDMA4 and PIO6 communication modes and can be used in True IDE and PCMCIA applications. Swissbit CompactFlash Cards come standard with a commercial operating temperature range of 0° to +70°C TAmbient. An industrial temperature version that can operate at -40° to +85°C TAmbient is also available allowing for further design flexibility in harsh environments.

Swissbit, Austin, TX (512) 302-9001 [www.swissbitna.com].

NEW BOOK

New Development Tools for PSoC 5 Programmable System-on-Chip Architecture

New development tools are becoming available for the PSoC 5 programmable system-on-chip architecture from Cypress Semiconductor in the form of two new design kits and a new version of the PSoC Creator Integrated Development Environment (IDE). PSoC 5 incorporates both analog and digital peripherals along with the high-performance 32-bit ARM Cortex-M3 processor, which positions PSoC 5 for demanding applications such as industrial, medical, automotive and consumer equipment. PSoC 5 devices offer integrated analog resources, including one 20-bit Delta Sigma ADC and two 12-bit SAR ADCs with sample rates as high as 1 Msps. The PSoC 5 architecture also includes PLD-based Universal Digital Blocks for implementing standard and custom digital peripherals. The new PSoC 5 development platform including kits, samples and PSoC Creator are available today.

The PSoC 5 FirstTouch Starter Kit (CY8CKIT-014) helps designers get acquainted with the new PSoC 5 architecture. It includes software and example projects that take advantage of the kit’s onboard sensors including an accelerometer, a thermistor, proximity sensing and CapSense. The kit enables easy development via 28 general-purpose I/O pins, a 12-pin wireless module header and Serial Wire Debugging (SWD). It also includes the PSoC Creator IDE design environment that combines schematic and textual entry with preconfigured, pretested components that can be simply “dropped into” designs.

The CY8CKIT-010 PSoC CY8C55 Family Processor Module Kit is available for more in-depth design work. It works with the PSoC Development Kit (CY8CKIT-001), which offers support for the entire PSoC line. The CY8CKIT-001 kit contains a main PSoC development board, and three processor module boards for the different architectures: PSoC 1, PSoC 3 and PSoC 5 devices. It also includes a MiniProg3 debug and evaluation device, prototyping cable kit, a USB cable, a 12V AC power adapter and both PSoC Creator and PSoC Designer software. Sample projects are also provided.

The PSoC 5 FirstTouch Starter Kit and CY8CKIT-010 PSoC CY8C55 Family Processor Module Kit are both available today, priced at $49 and $65, respectively. The CY8CKIT-001 PSoC Development Kit is also available, priced at $249.

Cypress Semiconductor, San Jose, CA. (408) 943-2600. [www.cypress.com].

Principles of IC Field Applications and Sales Engineering Selling and buying are two sides of the same coin. This book is for sellers and buyers of ICs. Buy the book and receive an e-gift

Milk your vendor for margin & support

44

Untitled-6 JULY1 2010

RTC MAGAZINE

winICdesigns.com 7/15/10 3:57:49 PM

PRODUCTS & TECHNOLOGY

IEC60601-1-Compliant PCIe Medical LAN Card

Windows Embedded Compact 7 Supports Connectivity from Device to Enterprise

Microsoft has just unveiled the public community technology preview (CTP) for Windows Embedded Compact 7, the next generation of Microsoft’s Windows Embedded Compact platform for hardware manufacturers of specialized devices. The Windows Embedded Compact 7 toolkit is targeted at allowing richer customer experiences on a variety of specialized devices.

One of the major aims is that specialized devices built on Windows Embedded Compact 7 will be able to provide immersive multimedia user experiences for consumers and businesses and offer seamless connectivity to PCs running Windows 7, servers and online services, as well as simplified access to corporate information for enterprise users.

New technologies in Windows Embedded Compact 7 will provide developers and designers with powerful tools and a streamlined development experience to build compelling devices quickly and easily, while also providing customized and branded experiences.

Additional features and capabilities of Windows Embedded Compact 7 include rich and connected experiences for consumers. Windows Embedded Compact 7 gives consumers the ability to share and manage content across networked devices with Digital Living Network Alliance, such as new HDTVs, and a new media library.

The effort also seeks to simplify access to information for enterprise users by making it easier to transfer data and media between PCs and devices. This involves simplifying the ability to connect to corporate e-mail, calendar and contacts over enterprise networks through Microsoft AirSync and Microsoft Exchange, as well as to Microsoft Office and Adobe PDF viewers to access important documents, and to Windows 7 Device Stage.

Windows Embedded Compact 7 provides resources to help bring high-performing, highly reliable and differentiated specialty devices to market quicker with support for multicore and the latest asset relationship management-based architecture and tools, including Platform Builder, Visual Studio, Expression Blend and Silverlight for Windows Embedded. The Windows Embedded Compact 7 CTP is available now for developers at http://www.windowsembedded.com/compact7. The platform is expected to be released to manufacturing in the fourth quarter of this year.

An IEC60601-1-compliant PCIe Gigabit Ethernet card can be used for the direct network connection of conventional IT equipment to medical devices. With this card, expensive medical LAN isolators, which otherwise would have to be inserted between the LAN port and a medical device, are no longer needed, lowering costs and simplifying overall system design.

The PCIe Medical LAN Card from Kontron will find applications in hospitals, rehabilitation centers, doctors’ offices and anywhere where medical devices are connected to conventional workstations or to high-availability archiving, backup and storage solutions. In order to transmit data between medical devices and systems via Ethernet to non-medical devices in an office or hospital network, the LAN card needs a galvanic separation according to the IEC60601-1 standard, which has already been engineered into the new PCIe Medical LAN card.

The PCIe 2.0-compliant Kontron PCIe Medical LAN Card is suitable for installation in any PCI Express x1-compatible card slot. Matching slot brackets for full-height or low-profile assembly are included. The long-term available Kontron PCIe Medical LAN Card features either one or two isolated Ethernet 1000Base-T interfaces on RJ45 connectors. Both variants are based on the Intel 82574L GbE controller, which ensures a particularly high level of compatibility and high transfer rates Kontron, Poway, CA. (888) 294-4558. [www.kontron.com].

NEW!

Dual IF for PCI Express with 16-bit ADCs (200 MSPS)

Ask for DRX16 • • • •

Two IF inputs (DC to 300 MHz) — adjustable sample rates Giant congurable FPGA (XC6VLX240T) 10 MHz timebase with timestamping capability Pairs with EDT’s x8 PCIe main board for high-speed DMA, plus additional FPGA resources and memory

www.edt.com

Microsoft, Redmond, WA. [www.windowsembedded.com].

RTC MAGAZINE JULY 2010 Untitled-2 1

45

7/9/10 10:16:46 AM

PRODUCTS & TECHNOLOGY

Rugged, Efficient Atom-based System Targets Harsh Applications

A high-reliability Atom-based rugged system integrates a high-efficiency processor, RAM, graphics, networking, serial I/O and PC/104-Plus expansion into an Extreme Rugged enclosure, capable of operating in extreme temperatures at full CPU speed. The RuffSystem 735 by Adlink Technology is designed for mission-critical applications where other systems would fail, such as military vehicles, transportation control and field monitoring. The system excels in high-vibration mobile applications. Leveraging Ampro by Adlink Extreme Rugged boards and having no moving parts, these systems run reliably for years and years with absolutely zero maintenance. In remote mobile applications, this translates to mission success.

The RuffSystem 735 features a 1.6 GHz Intel Atom processor N270, up to 2 Gbytes of DDR2 RAM, and Intel GMA 950 graphics core supporting display resolutions of up to 2048x1536 at 75Hz. A broad range of I/O includes one Gigabit and one Fast Ethernet port (dual GbE in Q3), four USB 2.0 ports, stereo audio, four serial ports (two supporting RS-232/422/485), and parallel port. Storage is provided by an internal conventional or solid-state drive (SSD) via SATA interface and a CompactFlash socket. The system also provides flexible expansion with PCI Express Mini Card slot and PC/104-Plus interface.

A military version, the MilSystem 735, provides the same level of ruggedness as the RuffSystem 735, but uses MIL-STD-D38999 connectors in place of the standard PC connectors found on the RuffSystem. Both systems are fanless, designed to meet MIL-STD-810 shock and vibration, and operate at full speed in an extended operating temperature range of -40° to 75°C. The RuffSystem and MilSystem 735 are available at competitive prices with Ubuntu Linux 8.04 LTS or Windows XP Professional preinstalled. The systems also support a full range of additional embedded and desktop operating systems, including VxWorks.

ADLINK Technology, San Jose, CA. (408) 495-5557. [www.adlinktech.com].

Low Power, High Processing Combine in Compact ESMini COM Module

3U CompactPCI IPv4/v6 Gigabit Ethernet Switch with Range of Management Interfaces

MEN Micro, Ambler, PA. (215) 542-9575. [www.menmicro.com].

Kontron, Poway, CA. (888) 294-4558. [www.kontron.com].

A new ESMini module uses a PowerPC MPC5121e or a MPC5123 processor, each based on an e300 processor core incorporating a memory management unit (MMU) and a floating point unit (FPU) as well as a powerful 760 MIPS using clock frequencies of up to 400 MHz. The rugged, ultra-small form factor MM550 ESMini module from Men Micro is suitable for use in mobile applications. The processor’s e300 core pairs a display interface unit, with or without a 3D graphics engine, and integrated I/O features with exceptionally low power of up to 3 watts maximum and performance to make the MM50 an attractive solution for industrial and mission-critical applications as well.

The MM50’s soldered 512 Mbytes of DDR2 SDRAM withstands severe shock of 15g, 11 ms, bump of 10g, 16 ms and vibration of 1g from 10 Hz to 150 Hz (sinusoidal). The MM50 also provides up to 128 Kbytes of non-volatile FRAM and mass storage expansion through SDHC on the carrier board. In addition to serial I/O interfaces, such as USB, the MM50 also features legacy interfaces including CAN bus, COM, Fast Ethernet, I2C and GPIO. The MM50’s graphics controller and audio function combined with its low power dissipation make it a suitable platform to build up compact control systems with the need for visualization. Six individually programmable controllers give further flexibility to implement serial I/O. As with all ESMini modules, the MM50 operating temperature is from -40° to +85°C. An optional version with a conduction-cooling frame gives each ESMini module full EMC protection. The module can be used without an enclosure as well.

ESMini modules, which measure only 95 mm x 55 mm, are firmly screwed to a carrier board and come with rugged, industry-proven and railway-compliant connectors with differential signals. By standard, only soldered components are used to withstand shock and vibration, and the design is optimized for conformal coating. The Men Micro XC4 evaluation carrier board in microATX format is used to test all of the MM50’s functions and to develop a specific application. Pricing for the MM50 is $384.

46

JULY 2010 RTC MAGAZINE

With up to 16 Gigabit Ethernet ports, a new fully managed IPv4/v6 switch is a cost-effective, high-performance solution for harsh environments. The new 3U CompactPCI CP3929 switch from Kontron is designed to meet the growing demand for high-performance IPv4/v6 Ethernet switching for rugged intra- and inter-system communications. With its implemented Kontron Embedded Network Technology, which unifies an advanced feature set and a wide range of operational interfaces across multiple form factors, the Kontron CP3923 is aimed at enabling system designers to build new applications most efficiently. The extensive management capabilities plus a set of configuration services for OEM applications reduce customers’ hardware and software design efforts, thus minimizing costs and time-to-market.

The Gigabit Ethernet Switch CP3923 is a fully managed Layer 2/3 Gigabit Ethernet (GbE) switch offering IPv4 routing and optional IPv6 routing as well as full management capabilities. It supports CLI, Telnet, Web and SNMP management interfaces to configure the entire set of protocols and parameters including Layer 2 and Layer 3 (IPv4/v6) protocols, Multicasting, QoS and Security. For applications requiring higher bandwidth, it also supports link aggregation. On top of that, the CP3923 maximizes the reliability of rugged COTS applications by supporting Intelligent Platform Management (IPMI) and hot-swap capabilities.

The base configuration (CP3923-8C) supports eight GbE ports via RJ45 and eight GbE ports via rear I/O to ensure high-connectivity capabilities and broadband flexibility. Two additional versions directly target transportation and mobile applications, providing four (CP3923-4M) or eight (CP3923-8M) Fast Ethernet ports via M12-D connectors. All versions support eight GbE via rear I/O. To have access to the 8x GbE ports routed to the rear, a special Rear Transition Module is available. The new CP3923 is also compliant with the EN 50155 railway standard and offers an extended operating temperature range (E2) of -40° to +85°C. Additionally, the use of soldered components ensures resistance against the typical effects of shock and vibration. For even harsher environments a rugged conduction-cooled version is planned.

PRODUCTS & TECHNOLOGY Conduction Cooled VME Solid State Disk

High-Performance GigE-based Vision Appliance for Multi-Camera Use

A new Gigabit Ethernet (GigE)ready vision appliance is compatible with the full range of Dalsa Genie and Spyder3 cameras. GEVA, which stands for GigE Vision Appliance from Dalsa, offers a cost-effective and expandable performance platform for a multitude of industrial inspection tasks. The GEVA platform offers cost savings for multi-camera vision applications, such as final inspection of large assemblies. The high-bandwidth GigE camera ports are compatible with a wide range of mono or color, area and line scan GigE cameras, which can be mixed to suit the application need. Camera expansion is easily accommodated using commercially available network technologies, allowing large configurations to be realized with much lower system cost. At the heart of GEVA is a powerful multicore processor, equipped with high-speed memory resources to tackle the most demanding applications.

GEVA provides a number of external interfaces for system integration.

It includes dedicated display and USB ports for setup and run-time control, a third Gigabit Ethernet port and a serial port for factory communication, dedicated trigger inputs for inspection timing, dedicated strobe outputs for lighting control and opto-isolated I/O for associated equipment interfacing.

Vision solutions on GEVA are set up using Dalsaâ&#x20AC;&#x2122;s iNspect or Sherlock application software. The iNspect software is easy to use and requires little or no prior vision experience, while the Sherlock software offers greater flexibility to tackle more challenging inspection tasks.

Both packages offer a full complement of tools, together with interfacing and control options for both users and equipment. For performance migration, applications built on other Dalsa equipment with the same camera setup will also run on GEVA. GEVA is also available completeUntitled-6 with camera drivers for integration with third-party software.

Phoenix Internationalâ&#x20AC;&#x2122;s VC1-250-SSD Conduction Cooled Serial ATA (SATA) based Solid State Disk VME blade delivers high capacity, high performance data storage for military, and y, aerospace p industrial applications requiring rugged, extreme emee envi eenvironmental i ron ronmen me tal and secure mass data storage.

LLow ow w Ope OOperational Op per pperational e r aatio era tio ti ioo nal al TTemperature Te Temp em emp mperat mp pper e rraatu er ature tur tu urre re --4 -40 -40° 40° C

t H NT PQFSBUJPOBM TIPDL t H SNT )[ SBOEPN WJCSBUJPO tt -PX QPXFS DPOTVNQUJPO -PX QPXFS DPOTVNQUJPO -PX QPXFS DPOTVNQUJPO t 0QFSBUJPOBM 5FNQFSBUVSF ÂĄ UP ÂĄ$ t #VSTU EBUB USBOTGFS SBUF UP .# TFD t 4VTUBJOFE EBUB USBOTGFS UP .# TFD t *OEJWJEVBM QPJOU UP QPJOU EFWJDF DPOOFDUJWJUZ t *OUFHSBUFE 4-$ /"/% 'MBTI FFUT NJMJUBSZ BOE *3*( EFDMBTTJGJDBUJPO TUBOEBSET E E t .FFUT NJMJUBSZ BOE *3*( EFDMBTTJGJDBUJPO TUBOEBSET

High Operational Hi Temperature +85° C

Operational Altitude to 80,000 feet

'PS PVS FOUJSF MJOF PG TUPSBHF QSPEVDUT XXX QIFOYJOU DPN t 714ď&#x161;ş283ď&#x161;ş4800 An ISO 9001: 2000 CertiďŹ ed Service Disabled Veteran Owned Small Business

1

10/16/09 11:43:57 AM

Dalsa, Waterloo, Ontario, Canada. (519) 886-6000. [www.dalsa.com].

1U Networking Platform Supports Core2 Processors, Expands to 14 x RJ45 GbE LAN

A 1U rackmount platform is designed to support network services with flexible processor choices. Built with Intel Embedded IA components to enable OEM product longevity, the PL-80230 from Win Enterprises offers a choice of Intel Core2 Duo, Core2 Quad or more economical Pentium and Celeron processors. Two unbuffered and non-ECC DDR3 800/1066 MHz DIMM sockets provide memory to 4 Gbyte. The unit features a 3.5â&#x20AC;?

SATA HDD and CompactFlash. In addition to PCI Express x8, the PL80230 also supports one mini PCI socket and one PCI expansion slot.

The platform has 6 GbE LAN ports, which is expandable to a maximum of 14 GbE Ethernet ports all available on the front-panel. The device also features dual USB 2.0 ports, one RJ-45 console port and LED indicators that monitor power and storage device activities. The PL-80230 is RoHS, FCC and CE compliant. The unit is RoHS compliant and OEM customizations can include logos, unique chassis color and bezel design.

PL-80230 units are available now for evaluation and begin selling at $554 in OEM quantities. Linux (Fedora, MontaVista, SUSE), Microsoft Windows Embedded, Microsoft Windows XP and Microsoft Windows CE 6.0 are supported.

WIN Enterprises, North Andover, MA. (978) 688-2000. [www.win-ent.com].

;HYNL[LK MVY! â&#x20AC;˘ Embedded â&#x20AC;˘ Communication â&#x20AC;˘ Enterprise

++9 ,** :THSS -VYT -HJ[VYZ â&#x20AC;˘ 244-pin MiniDIMM & VLP MniDIMM â&#x20AC;˘ 204-pin SODIMM â&#x20AC;˘ All ECC Registered or Unbuffered â&#x20AC;˘ JEDEC Compliant â&#x20AC;˘ Commercial & Industrial Temperature ZZZ YLNLQJPRGXODU FRP _ VDOHV#YLNLQJPRGXODU FRP

Untitled-3 1

RTC MAGAZINE JULY 2010

47

3/15/10 11:18:23 AM

PRODUCTS & TECHNOLOGY

6U SBC Delivers 10x Performance without Increasing Power

A rugged 6U VMEbus single board computer is based on Freescale’s QorIQ P2020 dual core processor and with 2 Gbytes of DDR3 ECC memory. It is designed to provide an upgrade path for PowerXtreme users by maintaining the power envelope of previous family members such as the PPC4A and PPC7A while delivering around 10 times the processing performance (depending on the application). The PPC9B’s power dissipation of only 20-25 watts makes it attractive for rugged, deployed applications where minimal heat dispersion is essential such as sensor fusion and processing, tracking and targeting, weapon guidance and electronic support subsystems. The Freescale QorIQ P2020 achieves its ~10x performance increase (compared with the 7410 processor that was at the heart of the PPC4A) through its dual core architecture, its faster clock speed (1.2 GHz), its higher degree of silicon integration, faster memory interface and implementation of PCI Express and RapidIO. In addition, the PPC9B offers substantial configuration flexibility, allowing customers to create a solution precisely tailored to the requirements of the application. PMC and XMC sites are provided, as is an AFIX site. AFIX is GE’s proprietary Additional Flexible Interface Extension daughter card, which allows system integrators to add features to a host card without using a PMC site, offering the possibility of reduced slot count and therefore lower cost, space and weight. AFIX cards can be custom-developed, or acquired as COTS products—the latter including single/dual channel dual redundant MIL-STD-1553, 8- or 16-bit SCSI with VGA graphics, and flash memory.

Connectivity for the PPC9B is provided via dual Gigabit Ethernet, two UART ports, four fast serial COM ports, two USB ports, two SATA ports and 24 GPIO ports, with an additional Gigabit Ethernet, USB and UART port available via front I/O for air-cooled versions.

Keyboard/mouse PS/2 ports are provided for legacy applications that require them: these can be substituted by two additional USB ports.

Available in five rugged air- and conduction-cooled build levels for optimum cost-effectiveness, the PPC9B is fully supported by comprehensive Deployed Test Software (BIT and BCS) while operating system support for VxWorks, LynxOS and Linux gives customers the choices they require.

GE Intelligent Platforms, Charlottesville, VA. (800) 368-2738. [www.ge-ip.com].

Extended Temp, Low-Cost PC/104 A/D and D/A Modules Don’t Require Calibration

8.8 Pound ½ ATR System Satisfies Demanding SWaP Requirements

WinSystems, Arlington, TX. (817) 274-7553. [www.winsystems.com].

Extreme Engineering Solutions, Middleton, WI. (608) 833-1155. [www.xes-inc.com].

Two new, low-cost PC/104-compatible analog I/O cards operate at a temperature range of -40° to +85°C without the need for calibration. Introduced

by WinSystems, the PCM-MIO-G-AD-1 is a 16-channel, 16-bit analog input card and the PCM-MIO-G-DA-1 is an 8-channel, 12-bit analog output card.

Both cards also support 48 lines of digital I/O. These small, 90 x 96mm expansion boards are designed to meet customer requirements for accurate analog and digital I/O over an extended temperature range. They are designed for industrial, medical, security, transportation and Mil/COTS applications. Based upon Linear Technologies' precision converters and voltage references, these cards do not require calibration, which results in quick, easy setup; plus it eliminates the necessity for readjustment and recalibration to installed units in the field.

The input ranges for the PCM-MIO-G-AD-1 are 0-5V, ±5V, 0-10V and ±10V. Two independent, 16-bit A/D converters support up to 16 single-ended or 8 differential channels or various combinations of both. The conversion speed is 100K samples/sec. The PCM-MIO-G-DA-1 has eight independent, 12-bit D/A converters on board. The output voltage ranges are 0-5V, 0-10V, ±5V and ±10V. All output channels are programmable and can be updated and cleared individually or simultaneously.

Both the PCM-MIO-G-AD-1 and PCM-MIO-G-DA-1 boards have 48 lines of digital I/O individually programmable for input, output, or output with read-back. The lines are TTL-compatible and can sink 12 mA, which supports direct connection to industry-standard, optically isolated AC and DC signal conditioners. Isolated signal conditioners protect, filter and isolate the analog input and output signals from electrical transients. Both cards are supplied with free drivers for C, Linux and Windows XP Embedded, which can be downloaded free of charge from the Web site. The PCM-MIO-GAD-1 list price is $249 and the PCM-MIO-G-DA-1 list price is $279.

48

JULY 2010 RTC MAGAZINE

An 8.8 pound sub-½ ATR, forced air-cooled enclosure for conductioncooled modules is designed to reduce the Size, Weight and Power (SWaP) of deployed military systems. A fully populated XPand4200 from Extreme Engineering Solutions weighs less than 15 pounds and is suitable for C4ISR applications in vehicles such as UAVs, helicopters, planes, tanks and light armored vehicles, HMMWVs and UGVs. The XPand4200 conducts heat from conduction-cooled modules to heat exchangers, where the heat is dissipated to the ambient environment by forced-air cooling. Compared to similar systems, the cooling capability of the XPand4200 is significantly higher due to a heat exchanger integrated into the top of the unit. Because the design supports conduction-cooled boards in an air-tight enclosure, the XPand4200 provides enhanced shock and vibration protection and isolation of the boards from the outside environment.

The system measures 4.88” (W) x 6.0” (H) x 13.5” (D). The XPand4200 has an optional removable memory module attachment that supports the XPort6191 Solid State Disk (SSD) Removable Storage Module, with 64 Gbyte of storage capacity. With the memory module attachment the height increases to 7.62” and the weight to 11.1 pounds. Up to six conduction-cooled, 0.8” pitch 3U VPX, 3U cPCI, or power supply modules can be configured into the XPand4200. Additionally, the XPand4200 can be configured to meet custom I/O requirements with conduction-cooled PMC / XMC modules available from X-ES or third parties.

The XPand4200 supports Gigabit Ethernet, graphics, RS-232/RS422, MIL-STD-1553, ARINC 429, as well as custom conduction-cooled PMC/XMC I/O through D38999 circular connectors. An optional frontpanel USB port provides system monitoring and maintenance capabilities. There are several power supply options, supporting up to 200W from a MIL-STD-704 28V DC or 115V AC input, as well as internal EMI filtering and hold-up for up to 60 ms at 200W.

PRODUCTS & TECHNOLOGY

Quad-Channel Data Acquisition and Processing Board Hits 200 MSPS at 16 Bits

A four-channel data acquisition module targets radar and communications applications requiring next-generation performance. The 71600 from Pentek has four 200 MSPS, 16-bit data acquisition channels that deliver nearly 90 dB of spurious-free dynamic range, allowing users to detect small signals of interest surrounded by large interferers. The channels operate from a common clock that can come from an external source or an onboard, programmable, crystal-controlled oscillator. An external clock can drive the ADCs directly as a sample clock or be used as a phase-lock reference for the internal oscillator. The 71660 also utilizes two sync and two gate/trigger signals for synchronizing data acquisition channels across multiple modules.

Four independent memory banks provide the 71660 with a capacity of up 2 Gbyte of DDR3 SDRAM for applications requiring deep memory, or up to 32 Mbyte of QDRII+ SRAM for applications requiring fast random access.

The memory can also be configured to offer two banks of each type, giving users the flexibility to accommodate complex applications. Built-in functions of the memory controller include multi-channel ADC data capture, data streaming and tagging of data streams with metadata packets that include channel ID, sample count and time stamp information.

The Virtex-6 FPGA on the 71660 provides customers with a combination of turnkey and custom functionality. Customers can select the specific FPGA device installed, ranging from the lower-cost LX130T to the high-performance SX475T with up to 2016 DSP slices. The board ships with the FPGA configured to provide synchronization, triggering, multiplexing and data acquisition features including a complete radar range gate engine. The FPGA controls and implements data flow paths for all resources on the board, giving users full command of board operation when desired. Users can configure the FPGA using Pentekâ&#x20AC;&#x2122;s GateFlow Design Kit. The Cobalt version of GateFlow has been optimized for the Virtex-6 family and features increased modularity to help simplify development.

The native form factor for the 71660 is an XMC module and is also offered in a conduction-cooled version. Other offerings include the 78660 PCI Express board, 53660 3U VPX board, 73660 3U cPCI and the 72660 6U Compact PCI board. Software support initially includes drivers for Windows and Linux platforms, with support for VxWorks to follow. The Model 71660 pricing starts at $9,995 depending on the memory and FPGA configuration.

Pentek, Upper Saddle River, NJ. (201) 818-5900. [www.pentek.com].

The New Standard in Low-Power Networking Engines The CSB1725, based on the Marvell MV78200 Dual Sheeva Core SoC, is a highly integrated System On a Module (SOM). The CSB1725 provides an ultra small, powerful, flexible engine for low-power 10/100/1000 Ethernet based networking systems. The main features include: 1GHz Dual Superscalar ARMv5TE Cores w/512KB L2 Cache 512MByte 64-Bit Wide DDR2-667 Memory with 8-Bit ECC 64MByte NOR with Secure ID, and 512MByte SLC NAND Two PCIe x4 Port (or one x4 and four x1's) Two 10/100/1000 ports via 88E1121R RGMII to Copper PHY Two SATA Gen 2 (1.5Gbit or 3.0Gbit/sec) Channels Two 480Mbit USB 2.0 Host Ports <6W Typical, 10W Maximum, Both Cores Enabled 70mm x 75mm x 5.2mm (on 4.3mm Low Profile MXM Socket) Uboot and Linux 2.6.x BSP

COMING SOON - Freescale P2020 Dual Core The CSB1725 is manufactured in our in-house state of the art, lead-free surface mount manufacturing line. All products carry a 1-year warranty and are offered in commercial and industrial temperature versions. Cogent also offers standard and custom carrier boards, plus royalty free licensing options for the CSB1725.

COGENT "ALWAYS COMPLETE" Untitled-9 1

Cogent Computer Systems, Inc. 17 Industrial Drive, Smithfield RI 02917 tel: 401-349-3999, fax: 401-349-3998, web: www.cogcomp.com

49

5/13/10 4:32:36 PM

RTC MAGAZINE JULY 2010

with an Application Engineer, or jump to a company's technical page, the goal of Get Connected is to put you in touch with the right resource.

Whichever level of service you require for whatever type of technology, Get Connected will help you connect with the companies and products you are searching for.

www.rtcmagazine.com/getconnected

Advertiser Index Get Connected with technology and companies providing solutions now Get Connected is a new resource for further exploration into products, technologies and companies. Whether your goal is to research the latest datasheet from a company, speak directly with an Application Engineer, or jump to a company's technical page, the goal of Get Connected is to put you in touch with the right resource. Whichever level of service you require for whatever type of technology, Get Connected will help you connect with the companies and products you are searching for.

www.rtcmagazine.com/getconnected

Company

Page

Website

ACCES I/O Products.......................................................................................................... 17.............................................................................................................www.accesio.com ADLINK Technology America, Inc....................................................................................... 52............................................................................................... www.adlinktechnology.com

End of Article AMD................................................................................................................................. 24................................................................................................ www.amd.com/embedded Products American Portwell Technology, Inc..................................................................................... 21............................................................................................................ www.portwell.com AVAGO. 51........................................................................................ www.avagoresponcecenter.com Get.............................................................................................................................

Connected with companies and Get Connected products featured in this section. with companies mentioned in this article. www.rtcmagazine.com/getconnected Avalue Technology.............................................................................................................. 4.........................................................................................................www.avalue-usa.com www.rtcmagazine.com/getconnected Cogent.............................................................................................................................. 49.......................................................................................................... www.cogcomp.com Delkin Devices.................................................................................................................... 4................................................................................................................ www.delkin.com Get Connected with companies mentioned in this article. www.rtcmagazine.com/getconnected Get Connected with companies and products featured in this section.

EDT.................................................................................................................................. 45................................................................................................................... www.edt.com www.rtcmagazine.com/getconnected ELMA Electronic Inc.......................................................................................................... 13.......................................................................................................www.acttechnico.com GrammaTech...................................................................................................................... 2...................................................................................................... www.grammatech.com ISI Nallatech Inc................................................................................................................ 25...........................................................................................................www.nallatech.com One Stop Systems............................................................................................................. 33................................................................................................www.onestopsystems.com Phoenix International......................................................................................................... 47........................................................................................................... www.phenxint.com Real-Time & Embedded Computing Conference.................................................................. 41................................................................................................................ www.rtecc.com Red Rapids, Inc.................................................................................................................. 8....................................................................................................................redrapids.com TRI-M Systems................................................................................................................. 12.................................................................................................................www.tri-m.com USB Module & Data Acquisition Showcase......................................................................... 37........................................................................................................................................

VersaLogic Corporation..................................................................................................... 40......................................................................................................... www.versalogic.com Viking Modular Solutions Sanmina-SCI Corporation............................................................ 47....................................................................................................www.vikingmodular.com WDL Systems.................................................................................................................... 11.......................................................................................................www.wdlsystems.com Win IC Designs.................................................................................................................. 44.....................................................................................................www.winicdesigns.com

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.

50

JULY 2010 RTC MAGAZINE

Imagine... )BSOFTTJOH Renewable Energy More Efficiently Your Imagination: Efficiently control and protect power generation systems from lightning, EMI interference, extreme temperatures and high winds, while maximizing the energy produced.

Our Innovation: Avagoâ&#x20AC;&#x2122;s fiber optics, isolated gate drivers, isolation amplifiers and digital optocouplers deliver solutions for wind turbine and solar energy designers.

Avago delivers: t )JHI WPMUBHF JTPMBUJPO t &.* JNNVOJUZ t /P HSPVOE QPUFOUJBM JTTVFT t *ODSFBTFE TBGFUZ BOE SFMJBCJMJUZ t 6MUSB MPX QPXFS N" TPMVUJPOT If a commitment to technical excellence and success is critical to your new designs â&#x20AC;&#x201C; contact Avago at: www.avagoresponsecenter.com/302

Your Imagination, Our Innovation

Š 2010 Avago Technologies. All rights reserved.