Telehealth » Articles

People-centered innovation driving the next generation of telehealth – Q&A with Alan Boucher, Director of Software Architecture and Engineering, Intel-GE Care Innovations

Embedded Computing Design, — Fri, 18 May 2012 15:00:00 +0000

Intel Corporation and GE Healthcare came together in 2011 to form a new company that is transforming the world of technology-enabled health care by rethinking the role of the patient in telehealth system design. Alan describes how Care Innovations is creating a new space for embedded computing technologies in virtual care coordination applications.

BOUCHER: Intel-GE Care Innovations creates technology-based solutions that give people confidence to live independently, wherever they are. We are a unique joint venture between Intel Corporation and GE that was formed last year, combining assets and expertise from Intel’s Digital Health Group and GE Healthcare’s Home Health division.

Both Intel and GE Healthcare have a long history of driving innovation, solving hard problems, and creating new markets, with a massive body of research and expertise to back that up. GE’s health care expertise covers medical imaging and information technologies, medical diagnostics, patient monitoring systems, drug discovery, biopharmaceutical manufacturing technologies, and performance improvement/solutions services.

Intel also has a deep understanding of the health care industry. Since Intel began investigating health care in 1999, ethnographic researchers have observed and interacted with more than 1,000 households and 150 hospitals and clinics in 20 countries. Intel also initiated collaborative research projects with the Technology Research for Independent Living Centre, the Center for Aging Services Technologies, and many other organizations.

Today, Care Innovations can cull from this deep body of research in product development and prototypes. Our Care Innovations Connect and Care Innovations Guide products were developed directly out of this research. Current prototypes under investigation are also heavily informed by these extensive studies.

ECD: What telehealth products are you currently pushing to market, and how do embedded technologies enable and enhance these products?

BOUCHER: The Care Innovations Guide (Figure 1) is a next-generation telehealth solution that combines traditional vital signs capture with advanced videoconferencing and customizable multimedia education. It strengthens the connection between health care professionals and patients, and helps make virtual care coordination possible. We also offer Care Innovations QuietCare (Figure 2), a wireless monitoring technology that keeps caregivers informed about resident activity levels, which can help improve (patient) safety and security while allowing for proactive care.

Figure 1: The Care Innovations Guide strengthens the connection between health care professionals and patients by enabling vital signs capture and videoconferencing capabilities.

(click graphic to zoom by 1.9x)

Figure 2: Care Innovations QuietCare utilizes ZigBee network technology to monitor resident activity levels for facilitating independent living.

(click graphic to zoom by 1.9x)

In these products, embedded technologies such as wireless platform interfaces, ZigBee sensor networks, wireless medical peripherals, and software are designed for both wired and wireless patient use, allowing patients to integrate our products into their lifestyles without imposing restrictions or requiring significant changes. Platforms utilizing untethered devices, radio-based sensors, sensor networks, and a variety of transport media offer patients choices in how they can better manage their health care from a personal preference and lifestyle perspective.

Significant advancements in the Continua Health Alliance Bluetooth specifications, low-power Wi-Fi, Bluetooth profiles, and High-Speed Alternate MAC/PHY (AMP) offer us connectivity options and the ability to make design choices across a variety of radio platforms. However, we still face all the challenges around device integration, data acquisition, data integrity, quality, safety, and design assurance with either commercial or embedded platforms and Operating Systems (OSs). Even with the abundance of Bluetooth medical devices available today versus 3-5 years ago, many of the design challenges persist in medical systems development.

ECD: Why does Care Innovations emphasize the need to deliver “human-centered” products and services? What other important technical considerations drive the design of a telehealth device/system?

BOUCHER: At Care Innovations, perhaps surprisingly, we don’t start with technology. Instead, we start with the people who use our products, which makes all of our solutions profoundly human-centered. We’ve spent nearly 12 years living with, studying, observing, and listening to people at all levels of health care and independent living. And we’re including them as active participants in the systems we deliver. From our UX/UI formative modeling to our early design formative testing through to validation testing, we are committed to our patients and institutional customers who use and continue to influence our product design. External focus, quality, and discipline are the cornerstones of our products.

We look closely at user lifestyles when designing our products. For instance, chronically ill patients are not always tethered to their homes. Many of our patients live a more active lifestyle and need to take their devices out of their homes to remain adherent to care protocols and clinical instructions. This requires us to think differently from the core platform out to edge devices, device interactions, data acquisition, and data privacy and security. Concurrently, our clinical customers want to help their patients manage their disease states, which means effectively responding to measurement data while proactively managing patients’ needs, regardless of their location.

These are all inputs to our UX/UI and systems engineering use cases and resulting product requirements. One size, model, or type rarely fits all, and that’s certainly the case with the products that we build for our patients, clinicians, and independent living institutional customers.

ECD: What embedded technology advancements are needed to meet future goals of providing a unified technology platform with interoperable components?

BOUCHER: Building blocks simply need to be better coordinated. With embedded platforms, OS vendors like Wind River have done a good job of building the requisite core software subsystem capabilities to enable innovative embedded medical device development. To a somewhat lesser degree, we’ve seen this emerge with Android, iOS, and Windows Mobile as well. However, it’s still a complex undertaking. Companies like Care Innovations build systems that inevitably land on both embedded and commercial platforms, which patients interact with directly.

Regardless, the demands on resources, platform usage analysis, mobile/embedded platform roadmaps, and design/development trade-offs remain a complex puzzle for platforms built on embedded OSs and more commercially available operating platforms. Trying to navigate primary OS vendor core capabilities, feature/API exposure, embedded radio, and sensor and network interface availability can be the difference between success and failure in the marketplace. Bluetooth radio testing and qualification, device driver and I/O integration with platform middleware, design assurance, and data acquisition and integrity all play a role and are significant factors in development decisions.

Challenges can still arise with radio firmware, radio interface testing, API implementation/granularity, OS support for drivers, radio shims, profile implementations, and protocol and middleware integration at a platform level. Additionally, medical device development teams have compounded responsibilities in the areas of intended use validation, design assurance, quality, system test, verification, and data integrity that are expected of them according to product and medical regulations. Completing missing building blocks for platform developers, fully implementing profiles, reducing integration complexity, and improving design assurance will give medical device vendors an opportunity to focus on new capabilities and design advancements instead of solving other vendors’ core OS, I/O, and subsystem challenges.

Alan Boucher is director of software architecture and engineering at Intel-GE Care Innovations.

Intel-GE Care Innovations www.careinnovations.com

Follow Twitter Facebook Google+ LinkedIn YouTube

Harnessing technology to transform care – Q&A with Joseph Kvedar, MD, Founder and Director, Center for Connected Health

Embedded Computing Design, — Fri, 18 May 2012 15:00:00 +0000

The Center for Connected Health is creating a new model for health care delivery by developing programs to move care from the hospital or doctor’s office into the day-to-day lives of patients. Dr. Kvedar explains how an emphasis on patient engagement affects the design of personal connected health devices that can help providers and patients manage chronic conditions, maintain wellness, and improve adherence and clinical outcomes.

KVEDAR: Our in-depth experience, combined with the resources available at the Center for Connected Health and within the Partners HealthCare network, enables us to deliver expert opinions and help organizations prepare their products and services for integration into the health care delivery system. The Center’s experienced clinicians and technologists are skilled at working seamlessly with patients and providers to determine potential use cases, identify usability challenges and opportunities, and evaluate technology and workflow issues in medical settings as well as in the home. Our work continues to demonstrate how the right technology, in the right patients’ hands, in the right setting can have a profound impact on care and quality of life.

In one example, working with a company developing a medication adherence device, the Connected Health team designed the protocol, recruited more than 120 subjects, and completed the data analysis to evaluate clinical outcomes. This study is currently in publication review. In another case, we assessed a prototype Bluetooth USB device and software platform enabling data upload from the home. Our team provided a thorough and realistic evaluation of the technology’s reliability and usability and identified key factors for further product design.

ECD: What challenges do telehealth system developers face today, both on the technical side in terms of design requirements, as well as the clinical side in regards to care delivery and technology acceptance?

KVEDAR: One challenge system developers face is how to test their product or service in a real-world environment. In other words, how does the developer of an activity monitor, wireless weight scale, or blood pressure cuff have individuals use these products on a test basis in their home or connected with their provider? Working within a large provider network, the Center can bridge that need and put these devices and systems in the patients’ and providers’ hands.

A second significant challenge is the myriad of platforms and Operating Systems (OSs) currently available in the market. Designing a device or program that is suitable for the iPhone, for example, will need to be redesigned for Android, Blackberry, and on and on. Obviously, this requires significant development time and expense. Making all personal health devices plug-and-play so that any sensor or app will work on all platforms, as well as allowing patients and providers to easily and securely share data, are essential requirements for the widespread success of connected health systems. The Continua Health Alliance (www.continuaalliance.org) is creating interoperability standards and guidelines to help streamline the development of these personal health devices and make it seamless for patients and providers to use these technologies.

ECD: Where does security fit in the connected health picture, and how must technology advance to address this and any other area of vulnerability and risk?

KVEDAR: Health care providers are obligated to protect patient privacy and an individual’s health information. E-mail communication is one example of a potential vulnerability. However, there are a number of ways to safeguard against potential security breaches. First, e-mail messages can be encrypted. Providers can also communicate with patients using a secure software platform that has the same functionality as e-mail, but is specific to communication with a health care provider. Secured messaging applications are often part of a patient portal or electronic medical records systems offered by physician practices and hospitals.

ECD: The Center for Connected Health emphasizes patient engagement and supports initiatives promoting disease prevention and management. How should these objectives influence the design of a connected health device?

KVEDAR: That is a very important question. First, the device must be easy for the individual to use. In a recent remote monitoring trial conducted at the Center, we found that for a surprising percentage of diabetes patients, the step of plugging a device into the glucometer and the phone line and then pushing a single button to upload glucose readings was more work than they were willing to do. The technology must be simple and easy to use.

Moreover, we have learned that the most successful technology or product can be personalized to the patient’s experience, goals, or motivation. Patients are far more engaged in their care plan or wellness program when their own personal data is presented back to them – the feedback loop – in an easy-to-understand format. They can track their progress, see how their lifestyle choices are affecting their health, and learn how to best manage their health and wellness.

However, personal connected health data alone is not enough, except for a very small group of highly motivated individuals. Objective data is an important part of the solution, but the success of connected health programs is all about the psychology of engaging participants to motivate them to improve their health. We’re seeing many attempts at engagement strategies, including gamification, social networking, coaching, reminders, incentives, and punishments.

Our friends at Healthrageous (www.healthrageous.com), a health engagement company, offer a good example of a solution specific to an individual’s data, personal habits, and preferences. The company has developed a platform based on dynamic personalization, meaning that each intervention is tailored to meet an individual’s needs (see Figure 1). The goal is to know as much as possible about each individual using machine learning to anticipate the engagement experience that motivates each person to stay on the right track.

Figure 1: The Healthrageous platform uses machine learning technology to analyze personal health data and promote strategies tailored to achieve successful outcomes for each individual user.

(click graphic to zoom)

Joseph Kvedar, MD, is the founder and director of the Center for Connected Health.

Center for Connected Health jkvedar@partners.org www.connected-health.org

Follow: Twitter Facebook Blog LinkedIn

Panel discussion: Designing portable medical devices that emulate today’s consumer devices – with added security

Monique DeVoe, Editor, OpenSystems Media — Mon, 12 Mar 2012 15:00:00 +0000

Editor’s note: Portable devices are a top focus in the small form factor embedded scene. Medical devices lead the portable design revolution, taking patient care out of traditional clinical settings and into the home and remote settings. When we asked a group of panelists about the present and future of mobile devices, medical was at the forefront of their minds. They discussed the challenges of combining the “iPhone factor” of user-friendly design with stringent security requirements and regulations, choosing platforms, and others that stand in the way of the next-generation of devices they’re trying to develop. Edited excerpts follow.

Figure 1: Portable medical device panel.

(click graphic to zoom by 1.9x)

SFF: Portable medical devices have come a long way in the last few years. What impresses you about the current state of technology in these types of devices?

TABORN: The cell phone market, among others, is driving cost, size, power, and ease of use improvements and possibilities into all application areas, which in medical modalities are quickly being implemented to improve patient outcomes. The handheld ultrasound and its battery life is a great example. The most impressive impact on medical devices is the better focus on user experience. This will directly improve patient care by decreasing the error rate of the applications and evaluation of the data.

McCRACKEN: Out of nowhere, Android has emerged with the potential to become a dominant platform for portable embedded computing devices in the not-so-distant future. Chip-scale integration and improvements in battery technologies accompany the demand for standardized software application platforms. Finally, the performance of ARM SoCs has increased (up to Gigahertz dual core), while Intel has lowered its entry-level ultra-mobile processors to fit within size and power envelopes in order to compete for these coveted high-volume applications.

CHUNG: The projective capacitive multi-touch screen has become one of the hottest topics within this segment, but requires application software development to showcase its values. Also, energy efficiency has always been a key focal point for portable devices, and the rise of RISC-based solutions has helped to further energy savings.

Additionally, the different types of connectivity including Wi-Fi, Bluetooth, and 3.5G/4G wireless that are now readily built into portable medical devices permit easy access of electronic medical record databases or the future medical cloud in any location equipped with wireless signal reception.

MUNCH: The acceptance of x86 and Windows into a market that has traditionally relied on custom hardware and software solutions is impressive. We see Windows as the primary user interface tied to FPGAs performing data crunching in many medical applications. There is also an increasing desire to use standard building-block products like COM Express CPU modules to allow the product design to be focused on its core competency, which is increasingly software.

SFF: What design challenges are engineers currently facing in medical device development?

McCRACKEN: One key task facing engineers is platform selection. Everything from design environment and development tools to production royalties to product updating in the field hangs in the balance. Android is optimized for ARM at the moment, while other Linux platforms and Windows Embedded Compact run well on ARM and x86/Intel architectures alike. Additionally, time-to-market pressures are becoming as critical for FDA and other regulatory-based markets as they are for commercial and consumer markets where the winners take all. To that end, the richness and completeness of a product offering’s “out-of-the-box” functionality translates directly to competitive advantage. SBCs and COMs need to be ready as close as possible to the silicon launch (mass production).

MUNCH: There has been a significant increase in the speed of signals in today’s designs, resulting in the need to use expensive and complicated simulation tools to verify signal integrity. Waiting until a design is fabricated to check and catch signal integrity issues can impact launch schedules and development costs. Even when using module building blocks the design still needs to deal with high-speed interfaces such as PCI Express, SATA, and now USB 3.0 SuperSpeed.

TABORN: Of the many challenges engineers face, designers must first consider security since virtually all medical devices in the future will be connected to some type of network. Second, there are new demands for “ease of use” that are fostered by what many in the industry call the “iPhone factor.”

CHUNG: Medical customers see features like low cost, long battery life, light weight, slim design, and new technologies that are currently seen in consumer products, and expect to see these elements implemented in portable medical products, but medical devices do not yet have these features.

SFF: Where do you expect medical devices to go in the future?

CHUNG: Eventually portable medical devices will be used in the same sense that we use smartphones and tablets in our daily lives, but within a more secure network and with mechanisms to permit/deny access to sensitive patient data. Not only the patients but the physicians and healthcare administrators will benefit significantly from this development.

From a hardware perspective, lighter and thinner is always the trend. On a system level, portable medical devices have different market segments, such as general hospital/clinical administration usage that may require building a whole infrastructure, or portable diagnostic devices for ultrasound, ECG, and blood pressure monitoring that require joint system design with customers.

McCRACKEN: Someday, the portable subset of embedded devices will be nearly as ubiquitous as their consumer counterparts, relatively speaking. Whether in the form of sensors or medical patient monitors, these products will proliferate based upon consolidated, standardized ultra-mobile platforms much the way the original DOS + x86 embedded computers did. In some cases with dual- or multicore systems, the second processor core will be devoted to the deterministic and real-time aspects of the device, such as taking measurements.

TABORN: These devices will be far more flexible and extensible in the future. One of the best things to happen to medical is the advent of the iPhone. This demonstrated to the world that a small device could be intuitive and very efficient. This will cause device manufactures to address the areas of ease of use and human workflow, reducing human error and encouraging operation and use cases in non-traditional settings – improving patient care throughout the world.

SFF: What does the industry need to get to the next generation of medical portable mobile devices?

MUNCH: Continuing to drive down total power consumption would be a good start, and achieving this will just take time. This results in two benefits: an increase in battery life (or a smaller battery to reduce weight) and reduction in power that needs to be dissipated.

CHUNG: The prospect of wireless battery charging would be one technology that would help these applications realize their true potential for power-efficiency and application usage.

Additionally, comprehensive infrastructure, regulations, and mobile healthcare protocols will be key to these devices’ future. This will allow medical computing manufacturers the ability to develop portable/mobile medical-specific devices and applications that can be implemented within the same network, making the future medical cloud ecosystem possible.

TABORN: The ability to implement future security policies must be considered in today’s devices. This suggests having the “headroom” in the design shipped today to be able to implement more complex policies in the future. Unlike most devices, medical devices in clinical and hospital settings are unique in that they can be in service for 10-to-15 years. For consumer-geared medical mobile devices, we will have to ensure that the applications data acquired can be just as safe and reliable as data acquired in the clinical setting (given the various different circumstances). Multicore solutions are becoming readily available in both Intel and ARM architecture families. This topology choice will allow developers to address these unique application requirements for today with the necessary performance headroom to support the ever-changing security landscape.

McCRACKEN: Better hardware standards are needed in order to “cross the chasm.” Some existing standards like Qseven have been reasonably architecture-independent. However, there are now so many single-vendor-driven x86 and (especially) ARM module and interface standards that have been prevented from reaching critical mass in this industry. A casual stroll down the halls of Embedded World in Germany reveals that a massive shake-out will be needed; otherwise system manufacturers will be left squandering time-to-market and development budgets in taking the full custom path. Standards organizations have been portrayed as slow-moving and political, leading some suppliers to go it alone. Any standards groups that can set aside self-interests and become more responsive to customers and end users will have a major leg up in leading the consolidation that is needed to facilitate the next wave of medical portable devices.

APUs strike the ideal balance of form, function, and power consumption for graphics-intensive portable devices

Kelly Gillian, AMD — Mon, 12 Mar 2012 15:00:00 +0000

Achieving high levels of graphics and video performance for portable, small form factor systems is difficult when utilizing conventional CPU and discrete GPU processor architectures. With the recent advent of Accelerated Processing Units (APUs), designers are equipped to break this graphics barrier without giving an inch – literally – in board space.

Ongoing innovation in the x86 semiconductor industry is the foundation for the near-ubiquitous use of x86 embedded computing technology in the ever-growing range of SFF applications. Even with continued improvements in CPU performance and power efficiency, however, designers of SFF portable systems remain challenged to achieve their most ambitious design goals for graphics performance and visual immersion. Growing demand for higher performance graphics capabilities has led OEMs to explore new x86 processor architectures that promise to meet exacting multimedia performance requirements for applications spanning commercial, medical, and industrial domains, with a growing focus on portable and/or battery-powered devices.

Embedded boards and modules equipped with new-generation Accelerated Processing Units (APUs) can facilitate advanced graphics capabilities within an extremely small footprint, without compromising power and cooling efficiency or cost. The merging of advanced x86 computing capabilities with the parallel processing power of General-Purpose Graphics Processing Units (GPGPUs) in a single device allows OEMs to design low-power, graphics-intensive SFF systems that until now have been exclusive to power-hungry multicore CPUs and add-on graphics cards.

The evolution to increasingly intense graphics

Graphics-driven applications are accelerating the pace of innovation for portable, energy-efficient SFF systems. Applications spanning digital signage, information terminals, point-of-care medical imaging and diagnosis, and industrial applications are evolving to offer advanced graphics performance, but in many cases are constrained by conventional CPU and discrete GPU processor architectures. Here we’ll look at each of these applications individually and address some of their unique design constraints, and also assess the ways in which APUs can minimize these constraints.

Mobile digital signage and information terminals

The travel services industry in particular has embraced digital signage as a means to provide timely, location-aware information. GPS-assisted in-vehicle digital signage and other mobile digital signage better equip travelers for personal use and empower travel services and transportation vendors with “high proximity” advertising space for local businesses. Multi-screen display capabilities are emerging as an important feature for these applications, and mobile digital signage is especially sensitive to power consumption requirements. Low power draw is crucial if a mobile digital sign is to be powered by, for example, a shuttle bus battery.

Point-of-care medical imaging and diagnosis

Portable medical devices with sophisticated medical imaging capabilities for use at the point of care outside of the hospital can enable medical professionals to examine patients in the field, as well as access and process imaging-intensive patient data such as Picture Archiving and Communications Systems (PACS) datasets stored within hospital information systems. These devices ensure high-resolution imaging and ultra-precise diagnostic information that first responders and care providers count on to expedite treatment decisions.

Apart from the inherent design constraints associated with high-performance graphics processing, device portability, and battery-life preservation, medical device designers grapple with stringent device certification processes that often consume valuable time and intense time-to-market pressures that few other industries face as acutely.

Portable industrial applications

Imaging and data-intensive industrial applications such as image detection and recognition, automated inspection, and distributed data collection systems that require high-speed vector processing are increasingly being deployed in remote settings for monitoring purposes, and are therefore sensitive to portability requirements. In addition to requiring increased parallel processing capabilities to facilitate high-precision real-time data collection, these systems often need to be ruggedized for harsh environments. Highly compact, fluid- and particle-sealed system enclosures present obvious challenges to airflow and venting – challenges that are often insurmountable with traditional CPUs due to their thermal profiles.

APUs yield higher performance graphics with fewer components

New-generation boards and modules designed with advanced x86 APUs are ideally suited to minimize and/or eliminate the aforementioned design challenges while maximizing overall graphics performance. The combination of a low-power CPU and a discrete-level GPU into a single embedded APU provides OEMs with optimal picture resolution (frame rates and resolutions of up to 2560 x 1600 pixels, for example) for their graphics-driven, mobile SFF systems. Combining a GPU core on the same die as the CPU enables host systems to offload computation-intensive pixel data processing from the CPU to the GPU. Freed from this task, the CPU can serve I/O requests with much lower latency, thereby dramatically improving real-time graphics processing performance.

Size and integration

APUs also reduce the footprint of a traditional three-chip platform to just two chips – the APU and the companion controller hub. The combination of general purpose CPU and GPU onto a single die with a high-speed bus architecture and shared, low-latency memory model simplifies design complexity through a reduction in board layers and power supply needs, enabling SFF system designers to achieve aggressive form factor goals while driving down overall system costs.

By providing native, high-performance graphics processing at the silicon level, APUs preclude the need for bulky add-on graphics cards that usually require a right-edge connector. In space-constrained designs, an edge connector takes up more space (card-edge boards are typically 3" to 5" taller) and exposes it to additional shock and vibration that can lead to signal integrity issues. Designing APU-caliber graphics capabilities directly onto a carrier board is a more rugged, long-term option.

Power and cooling

The Performance-Per-Watt (PPW) gains enabled by APUs assure greater power efficiency and lower heat dissipation, which in turn can preclude the need for fan cooling within SFF systems, thus helping to preserve board space, improve overall system reliability, limit system noise, and lower BOM costs. Supporting Thermal Design Power (TDP) profiles from 5.5 W to 18 W, with typical power consumption below 6 W[1], AMD G-Series APUs equip designers with the ability to keep board-level total power dissipation to within approximately 35 W, well within the 45 W threshold at which mobile systems begin to become hot and physically uncomfortable to the touch. These factors enable designers to optimize their SFF systems for extremely compact enclosures and/or applications with power constraints, and can help designers stay within the 25 W threshold at which passive cooling is an acceptable (and typically favorable) option.

Multi-display video immersion

The ability to support multiple independent display outputs simultaneously is an emerging requirement for realizing ultra-immersive video displays for digital signage, and also SFF portable medical devices. New-generation APUs enable designers to cost-effectively develop multiple video displays without sacrificing board space for add-on graphics cards and controllers or compromising overall picture resolution. They also offer the ability to decode up to three HD video streams in parallel and support up to four independent digital displays via a wide range of standard interfaces, including DisplayPort, DVI, HDMI, LVDS, and VGA.

Vector processing for SFF industrial systems

Applications requiring increased parallel computing capabilities, such as the portable medical and industrial devices mentioned above, are well suited for boards and modules equipped with APUs. These applications include 3D medical X-ray image reconstruction and smart camera applications such as high-precision image/pattern detection and identification. However, traditional CPU architectures and application programming tools are optimized for scalar data structures and serial algorithms, and as such, are not the best match for data-intensive vector processing applications.

The integration of general-purpose, programmable scalar and vector processor cores for high-speed parallel processing establishes a new level of processing performance for SFF systems at an unprecedented PPW. In the case of AMD G-Series APUs, the general-purpose vector processor cores within the embedded GPU – 80 shader cores running at 500 MHz (AMD Fusion T56N) – drive the ultra-high-speed processing required to handle intensive numerical computations.

Time to market

The inherent architectural advantages introduced with APUs go a long way toward minimizing design complexity and accelerating time to market. These advantages are owed primarily to reductions in board layers, discrete add-on processors/cards, and power supply and cooling needs, which naturally minimize the number of components on the board and therefore enable designers to shorten, and in some cases eliminate, design cycles.

The underlying x86 APU architecture also enables portable SFF system designers to tap into the vast selection of existing x86-optimized software, applications, and development environments available on the market, introducing additional opportunities to enhance development efficiency and speed time to market. The open development ecosystem for the AMD G-Series platform, for example, includes support for Linux, Microsoft Windows, and Real-Time Operating Systems (RTOSs), multiple BIOS options, OpenGL 4.0 and OpenCL support, and source-level debug tools.

By implementing AMD G-Series APUs on the most common form factors for graphics-intensive applications, such as Computers-On-Module (COMs) and SFF SBCs and motherboards, Kontron is making the benefits of this new x86 processing architecture readily available for application development. OEMs and system integrators can take advantage of highly scalable, validated APU-based platforms that streamline design cycles and minimize design risks to ensure fast time to market for graphics-intensive and parallel-data SFF applications.

Making graphics performance goals achievable

New APU processor architectures are making a fast and transformative impact on SFF design initiatives, unlocking high-performance graphics capabilities in small form factors that simply can’t be achieved with conventional CPUs and GPUs. Continued innovation in the APU domain promises to push graphics performance boundaries even further, and will ultimately yield a new generation of portable SFF systems that defy space, power, and cooling limitations in ways previously unimagined.

Kelly Gillilan is the Product Marketing Manager for the AMD Embedded Solution division, overseeing worldwide marketing strategy and activities. He has worked extensively in embedded applications for most of the past decade. Kelly holds a degree in Computer Engineering and is fluent in Mandarin Chinese.

Christine Van De Graaf is the Product Manager for Kontron America’s Embedded Modules and Small Form Factor SBCs product families. Christine has more than a decade of experience working in the embedded computing technology industry, and holds an MBA in marketing management from California State University, East Bay.

AMD kelly.gillilan@amd.com www.amd.com

Kontron christine.vandegraaf@us.kontron.com www.kontron.com

References

[1] For complete test and configuration information please refer to the AMD “Brazos” Platform Performance and Power Optimization Guide Publication #48109 Rev 2.01 available on the AMD Embedded Developers Support Web site.

Giving smart energy its own "easy button"

Monique DeVoe, Editor, OpenSystems Media — Mon, 12 Mar 2012 15:00:00 +0000

One key idea of the smart grid/energy movement is to give consumers the knowledge and information to proactively monitor their energy use. A plethora of data has been produced out of smart energy programs, and having a standardized format with apps to make sense of it all would be a tremendous help. This is what U.S. Chief Technology Officer Aneesh Chopra had in mind during GridWeek in September 2011 where he challenged utilities to create standards and a framework for consumer data – the Green Button initiative.

The initiative’s medical history

The idea for the Green Button initiative came from one step over on the color spectrum: the Blue Button. This digital button was created in fall 2010 to assist returning Iraq and Afghanistan veterans to access health records in digital format, when and how they wanted it. The goal for Blue Button was to create a better use of electronic health records and other information technology in healthcare. A logical next step was to extend the concept to consumer energy data, which already has a strong presence in electronic records.

The standard foundation

Standards for interoperable usage data have been in the works for years, starting with the Energy Usage Information (EUI) “seed standard” in 2010. Building on the EUI, 2011 saw development begin on a standard to deliver historical and ongoing usage data: the Energy Service Provider Interface (ESPI). ESPI additionally defined the transmission and authorization of usage data for access by third parties (which could be anything from apps to appliances). Security features (such as OAuth) and privacy considerations were other driving features for ESPI[1].

Based on ESPI, Green Button supplies historical energy usage information directly to the end-user by providing data through XML files made consumer-friendly with an XLST file, rendering usage data that is both human and machine readable.

Within the 90-day challenge period set forth by the administration, this standard was ratified and its usage agreed upon by California utilities.

The future is green

Green Button’s availability was formally announced on Jan. 18 at a Santa Clara event called “Transforming the Energy Landscape with the Green Button” with California’s three largest utilities – San Diego Gas & Electric (SDG&E), Southern California Edison (SCE), and Pacific Gas and Electric (PG&E) – and more than 100 executives from leading smart energy companies present in support. Approximately 6 million customers from PG&E and SDG&E already have access to Green Button, with SCE planning to provide Green Button data to its 4 million customers later in 2012. Several other utilities across the country have also joined in.

Chopra expressed hope for nationwide adoption by utility companies, and various companies and individuals are hard at work creating apps to make better use of Green Button data. For example, Tendril opened its platform APIs and has provided software development tools that have attracted more than 200 app developers. Beyond simply displaying data, future applications could provide analysis to determine if windows need to be changed based on temperatures and usage data, estimate the energy costs prospective tenants can expect to pay, or verify if energy-efficiency remodeling has had an effect.

Though Chopra recently stepped down as White House CTO, the momentum gathered so far for the Green Button initiative should drive future expansion and growth.

References:

[1] See the National Institute of Standards (NIST) Green Button page for more details on the formation of the standard: http://opsy.st/yYZAM6

Programmable perks: Tallying the benefits of FPGAs

Jennifer Hesse, Editor, OpenSystems Media — Fri, 09 Mar 2012 15:00:00 +0000

Editor’s note: While many embedded design considerations depend on the target application, some requirements are inevitable: greater performance, lower costs, and increasingly faster time to market. Thanks to major advancements in process technology, FPGAs address all of these design needs by offering substantial parallel processing capabilities, as well as quick-fix infield upgradability. For a comprehensive overview of how FPGA technology can help achieve embedded design goals, we interviewed executives from the leading FPGA companies and collected excerpts from their responses in this virtual panel discussion.

Figure 1: Executive panelists

(click graphic to zoom)

ECD: With higher power requirements and recurring costs than custom logic or ASICs, which projects are best suited for FPGA technology?

BURICH: FPGAs have benefited significantly from Moore’s Law, and as a result have been able to stay at the bleeding edge of process technology while at the same time considerably reducing power consumption and development costs. As the costs of advanced process technologies rise (about $60 million for an ASIC at 40 nm), it gets harder to justify the upfront R&D costs. Today, we see a shrinking number of applications that can justify a leading-edge ASIC – mostly restricted to cell phones, PDAs, video games, and other high-volume applications. Those who can’t justify such an upfront investment seek to use trailing-edge process technologies.

In contrast, FPGAs can afford to use the latest process node and take advantage of Moore’s Law because there is a much wider array of applications that FPGAs can target. Today’s leading-edge FPGAs are 2-3 process nodes ahead of where most ASICs are, giving users the most advanced process technology available plus all the accompanying benefits at an overall lower cost. Development costs of leading-edge FPGAs are dramatically reduced because FPGA vendors can aggregate development costs across thousands of designs and customers. FPGAs are ideally suited for industrial, communications, automotive, military, medical, aerospace, and other designs with sub 1 million volumes or where a high degree of flexibility is required.

GETMAN: You have to be careful not to take an overly simplistic view when looking at power and cost and comparing different components like ASICs, ASSPs, FPGAs, and new hybrid products like Extensible Processing Platforms (EPPs). The comparison cannot just be at the device level; it also requires analysis at the system level and overall project level.

Design engineers must first answer some tough questions concerning costs, tool availability and effectiveness, production volume, time to market, and how best to present this information to management to gain support throughout the design process.

It’s interesting to compare these technologies, but in the end, the application is the final differentiator. A list of design objectives in order of importance, including cost (both development – nonrecurring engineering, and production – recurring unit cost), die size, time to market, tools, performance, and IP requirements must first be created. Then ask which technology best meets those objectives.

That analysis cannot just stay at the device level, where ASSPs and ASICs have an advantage with regard to both power and cost. For ASICs, the upfront cost means that only very high-volume applications can efficiently use an ASIC. Another trend is for companies to develop “kitchen sink ASICs,” where the design requirements for many different end products are the same, thus a single ASIC targeting multiple applications can be developed. However, this creates a problem with design complexity and project risks. Therefore, many customers are moving away from this approach after experiencing product delays and receiving products that, in the end, do not serve anyone’s needs perfectly. The other disadvantages that kitchen sink ASICs bring are that the silicon area is “inflated” to accommodate all the target applications, and therefore is less cost- and power-efficient.

We have always told our customers that if you have an ASSP that does exactly what you want and do not need or want to differentiate your product through hardware functions, then maybe that ASSP is the right choice for you. Most designs, however, can benefit from a flexible, programmable device that targets their unique applications and differentiates their products from the competition.

To accomplish that, many ASSP users add an FPGA next to their ASSP. While this offers a certain level of flexibility, it can also present some performance and power consumption challenges, stemming from the interface between the ASSP and the FPGA. This is why in the past few years, we have seen a push for fully integrated FPGA solutions, as well as FPGA vendors starting to offer hybrid solutions like an EPP (see Figure 2).

Figure 2: An Extensible Processing Platform (EPP) combines a high-performance dual-core ARM processor with standard peripherals and programmable logic.

(click graphic to zoom by 1.8x)

Over time, FPGAs have begun taking commonly used blocks such as DSP multipliers, small block RAM memories, and even high-speed serial I/O to offer the best balance of features and flexibility. The Zynq-7000 EPP family uses standard ASIC techniques to harden close to 11 million ASIC gates in the processing subsystem. This type of architecture swings the financial and technical bar around total cost of ownership, performance, and power radically away from traditional ASICs.

Massive parallel processing capabilities are another key benefit of FPGA technology, allowing designers to reach a level of performance not achievable with ASSP products. Additionally, using FPGAs within an EPP greatly reduces the risks involved when designing with ASICSs and ASSPs, as these devices cannot accommodate late design changes and do not provide the flexibility of infield upgrades. FPGAs offer the ultimate system integration platform to meet the growing need for programmable systems that cut development cycles, enable adoption to changing standards, and extend product lifetimes through field upgradability.

This segues perfectly to reducing time to market, a major advantage for any company’s product. FPGA technology allows our customers to move to market quickly, often in a matter of weeks, while drastically reducing their R&D costs. We offer design engineers a blank device that can be configured and reconfigured on-the-fly to implement any logic function that can be performed by an application-specific device. FPGA technology allows our customers to make changes to their designs very late in the design cycle. Even after the end product has been completed and shipped, they can extend its useful life by reprogramming the FPGA.

Innovations in FPGA technology have reduced the gap of power per device, making FPGAs much more competitive from a power standpoint. The battle to deliver maximum performance with minimum power expenditure is center stage in the evolution of the FPGA. Power conservation affects every budget, whether technological or financial. Product acceptability, reliability, and profitability depend as much or more on power efficiency as they do on performance, regardless of the type of project.

However, the key element of power savings will come from integration and reduced power consumption due to the chip-to-chip interface, which again, must be analyzed at the system level and not just at the chip level.

Increased system performance means new process technologies, massive parallel processing capability, advances in memory interfaces, high-speed transceivers (up to 28 Gbps), and no bottlenecks due to chip-to-chip interfaces. Decreasing power again relates to process technology, and in our case, this means using TSMC’s high-performance, low-power 28 nm process (a unified architecture across all of our 7 series FPGAs), other technology innovations, and burning no power to do chip-to-chip interfaces in a single device, as well as using fewer power supplies to reduce power consumption on the boards. Cost reduction is based on the use of a single device, which means there are no upfront costs and fewer components used on the board, resulting in a smaller bill of materials and a simpler design.

RILEY: The traditional trade-offs between FPGAs and ASICs/custom devices are still in effect. For a specific application, ASICs are lower power and lower cost, but they take much longer to develop and require a large upfront investment. What’s changing are the time-to-market requirements and useful market life for many projects.

Communications and wireless infrastructure developments are under tremendous pressure to get to market, driving engineers to consider process technologies that are reprogrammable and available today. In many cases, this is an FPGA. In the past few years, companies such as Lattice Semiconductor and SiliconBlue Technologies have been developing FPGAs that have solid capabilities and are priced well under $1. In fast-moving, cost-sensitive markets like consumer mobile, this type of solution is often the only way to add functionality in such a short time.

ECD: How can FPGA technology help embedded design teams deal with reduced budgets and increased system complexity?

GETMAN: While system complexity increases and the reduction of system design budgets becomes more of a reality, embedded system designers are jumping on the FPGA technology bandwagon to shorten design cycles, battle obsolescence, and simplify product updates. Using the constantly growing number of integrated FPGA development tools, reusable logic elements, and off-the-shelf modules, designers are creating new and innovative embedded systems that can be easily reconfigured for updates and changes in requirements with only a minimum impact on engineering and manufacturing.

FPGA designs combine multiple components into a single package that reduces component count, board size, and manufacturing complexity. Processors, memory, custom logic, and many of the peripherals in a typical embedded project are now in the FPGA. Today’s FPGA architecture has grown into billions of logic blocks (equivalent to gates), and with programmable interconnection flexibility designers can easily create hardware functions that exactly match the needs of a specific embedded application.

Drop-in IP cores from device vendors, third-party suppliers, and the open-source community ease FPGA set-up. The standardization of an IP interface (we use the AMBA 4 AXI standard) also greatly reduces design complexity when integrating functions into a single device. Furthermore, fueling a comprehensive ecosystem of hardware design tools, as well as software design tools and operating systems, is yet another key element of reducing design complexity.

Designers can segment FPGA-based signal processing algorithms into parallel computing structures to boost performance. High-level synthesis tools such as AutoESL can help simplify FPGA design and enable companies and developers not familiar with FPGAs or even hardware design to reap the inherent benefits of FPGA technology.

By utilizing a broad set of tools, the embedded designer’s tool bag for enabling FPGA technology has become increasingly mainstream. FPGA vendors are putting significant time and money into their development tools to improve the turnaround time, which will permit more iterations while reducing time to market and saving engineering efforts. The integration of many system elements into a single device reduces design complexity, as there are fewer chip-to-chip interfaces, as well as fewer performance bottlenecks.

RILEY: FPGAs are often used as bridging or coprocessing solutions. This allows embedded engineers to build systems out of the products they have. Can’t connect two dissimilar processors? No problem. FPGAs support a wide range of I/O types. Can’t handle the processing load? No problem. FPGAs can be configured to offload key functions.

FPGAs help get system products to market quickly, and the price and power of FPGA solutions has been dropping at a breakneck pace the past 10 years. FPGAs are used today in smart phones, tablets, laptops, handheld GPS devices, and many other platforms that were once the sole domain of custom logic.

BURICH: Designers today are challenged to get many different systems to market in shorter and shorter periods of time. By enabling easy customization for different features, price points, and evolving standards, FPGAs enable engineers to design a common platform and quickly spin off varying systems.

One of the most disruptive aspects of embedded design is adopting a new architecture to meet changing requirements. The industrial, medical, and military segments, for example, are also very concerned about product longevity and avoiding device obsolescence. By designing with FPGAs, customers can make incremental changes to a common design to adapt to changing market needs or industry specifications. Having a common tool flow with extensive design reuse addresses budget and time constraints.

New System-on-Chip (SoC) FPGAs featuring hard ARM processor subsystems also help embedded design teams address reduced budgets (see Figure 3). Today’s leading-edge FPGAs are targeting 28 nm process technology, which relatively few commercial CPUs or ASSPs use. A monolithic SoC FPGA system maximizes power efficiency and software partitioning flexibility. SoC FPGAs allow hundreds of data signals to connect different functional areas, thus enabling 100 Gbps or greater bandwidth with nanosecond-level latencies, representing orders of magnitude better performance and latency than discrete implementations. Furthermore, monolithic integration permits memory controllers to be shared, allowing high-bandwidth memory access for hardware accelerators. A monolithic SoC FPGA implementation enables embedded design teams to increase system performance while lowering system costs and reducing power versus a two-chip solution.

Figure 3: Today’s SoC FPGAs combine a hard ARM processor subsystem with the fabric of a 28 nm FPGA.

(click graphic to zoom by 1.9x)

ECD: One of the biggest obstacles to adopting FPGA technology has been the steep learning curve associated with development tools. How has this changed?

BURICH: This depends on the designer’s background. Those familiar with ASICs can quickly adapt to FPGA design flows and save time through the benefits of quicker verification in real silicon. Those who are not familiar with Real-Time Logic (RTL) will have a steeper learning curve. This is being addressed in two areas. The first is system-level design tools such as Altera’s Qsys, which enables designers to quickly assemble different design blocks using a higher-level graphic block environment. The second is automated RTL development from C language source. While this approach has been tried for many years, it is now coming of age for embedded developers with standards such as OpenCL. OpenCL also addresses the increasing challenge of designing multicore systems. Altera recently announced a program for evaluating FPGA-based OpenCL implementations.

GETMAN: Developing FPGA solutions can be complex, requiring the appropriate software tools. While each chip technology requires specific design tools, FPGA users are shielded from concerns of manufacturing yield and submicron issues by the nature of FPGA design flow, which brings ease-of-use, cost, and time-to-market benefits. FPGAs arrive fully tested and physically functional; the FPGA supplier handles physical design, verification, and characterization. Xilinx offers integrated design and debug tools for logic, DSP, and embedded processing, plus interfaces to third-party tools. FPGA design tools have improved dramatically, particularly [those] tools that apply high-level languages or interfaces to develop applications, such as MATLAB/Simulink from MathWorks.

Depending on the provider, software to program FPGAs varies in content and value-add features like compilation and editing tools. Very high-speed Hardware Description Language (VHDL) is the most common development language used. It allows FPGAs to be programmed via an easy-to-use graphical development environment. Additionally, FPGA vendors who provide tools such as development boards, support, and reference designs simplify the FPGA design process.

Conversely, there are longer design and verification cycles for ASICs, with a high likelihood of design re-spins and associated penalties. Plus, costly verification tools, training, and resources are required.

FPGA vendors who continue investing in software development tools and IP will enable more complex systems to be designed while carrying their silicon platform forward and promoting growth. The challenges going forward have not changed. These challenges continue to be reducing power, providing more capability at a lower cost, and further simplifying the programming. As progress is made on all of these fronts, the market share for FPGAs is increasing over ASIC/ASSP providers.

RILEY: The learning curve for FPGA design tools depends on where you are coming from. If you are an ASIC designer, the FPGA design tools will seem familiar. A design flow that includes HDL design entry, simulation, synthesis, and place and route is similar to an ASIC flow. For a software engineer who is used to programming in C/C++, the FPGA design flow will be new and require a learning curve.

Some vendors have claimed that you can write your code in C and their tools will automatically convert it to HDL. In my experience, this process still requires much human engineering to achieve the system throughput goal that drove the need to move beyond the confines of the microprocessor. There are well-established methodologies for partitioning a design between software and dedicated hardware. These still result in the best cost and performance, and FPGAs allow designers to experiment with different partitioning. Over the years, some FPGAs have included integrated processors, but they have not been successful. One reason for this is the lack of flexibility.

The world of microprocessors is vast. You can find any price, performance, or power point you desire from multiple vendors. Once you integrate the processor into the FPGA, your options become limited very quickly.

ECD: What types of IP core libraries do you offer to shorten the embedded design process?

RILEY: Lattice offers a wide range of IP cores, reference designs, and evaluation boards for PCI Express, Serial Rapid I/O, XAUI, Finite Impulse Response (FIR) filtering, Fast Fourier Transforms (FFTs), image and video scaling, MIPI interfaces, and more. Lattice focuses on the mid-range and low-density segments within the FPGA market. This means we concentrate on delivering high-end capabilities such as DDR3 memory interfaces and advanced filtering in low-cost, low-power FPGA platforms.

Lattice offers IP cores through a novel tool called IPExpress, which allows customers to change high-level parameters and generate new IP structures tuned to their feature, size, and performance requirements. Lattice provides many reference designs for free at our website. We also work closely with our customers to generate custom designs to meet their needs.

BURICH: IP libraries are important, and we offer a wide range of cores from memory controllers to embedded peripherals to high-speed communications interfaces. One of the most popular is our Video and Image Processing (VIP) Suite and our Nios II embedded processor IP. We also have a partner ecosystem that offers IP cores tailored to meet specific application requirements.

Just as important as the IP offering is the interconnect logic that ties the IP cores together into a coherent system. Altera offers a system integration tool (SOPC Builder) that automatically generates the logic that handles seemingly trivial yet critically important tasks of bus width adaptation, bus arbitration, bursting, interrupts, and more. We connect memory-mapped and streaming interfaces seamlessly and support high-performance bus standards like ARM AXI, as well as our lightweight, open Avalon interface standards. With the introduction of Qsys, we now generate a Network-on-Chip architecture offering even higher levels of performance and flexibility. Designers can not only assemble IP cores into a custom system, they can also create custom subsystems that can be shared internally to exploit the FPGA design reuse advantage.

GETMAN: Xilinx offers nearly 100 different embedded processing peripheral IP cores in categories including Processor IP Cores, Interface/Bus/Bridge IP, Peripheral IP, Communications IP, Infrastructure IP, Memory Controller IP, and Debug IP. These cores are included with the ISE Design Suite: Embedded Edition Development Kit and work directly in our Platform Studio, which supports MicroBlaze and PowerPC for PLB-based cores and MicroBlaze for AXI-based cores.

ECD: Which industry standards do you support to provide customers off-the-shelf, reconfigurable designs?

GETMAN: We see two aspects with regard to supporting industry standards, one at the external level and one at the internal level. At the external level, take the FPGA Mezzanine Card (FMC) defined in VITA 57 as an example. By using the reconfigurable I/O of FPGAs, design engineers can easily change a transceiver protocol or an I/O standard and route it through a different card connected to the FMC connector on our boards to create a new application/customer. Examples of internal standards that enable quick configuration/reconfiguration are AMBA 4 AXI, IP-XACT, and the proposed IEEE standard for IP Quality (QIP).

We support many interface standards for most market segments, including wireless communications, aerospace and defense, intelligent video, automotive, instrumentation, and medical imaging, which eases the connection to other systems. Having a comprehensive IP offering from Xilinx and its partners enables designers to quickly reconfigure their designs for applications or products.

RILEY: Lattice supports a wide range of hardware standards to help customers evaluate our silicon, design tools, and IP cores. Many of these evaluation boards are available for under $199, which allows customers of all sizes to experiment with Lattice products. Two standards that are popular with embedded designers are PCI Express and the Advanced Mezzanine Card. The AMC provides an FMC expansion connector, a USB-B connection to UART for runtime control, an RJ-45 interface to 10/100/1000 Ethernet, and an SFP transceiver module cage and connection.

BURICH: From the IP interconnect perspective, we support ARM’s AMBA AXI bus standard, as well as our own open Avalon bus standards (memory-mapped and streaming). Our Qsys system integration tool supports both AXI and Avalon, and the architecture of the tool is such that we can add other interconnect standards easily as needed.

From the IP interface standard perspective, we and our partners offer a wide range of IP cores that can be assembled into a custom system quickly with Qsys. Altera offers a wide variety of IP blocks of differing size and complexity, from the basic arithmetic blocks to transceivers, memory controllers, microprocessors, signal processing, and protocol interfaces. Altera and its third-party IP partners offer a broad portfolio of off-the-shelf, configurable IP cores optimized for Altera devices. Licensed and unlicensed IP is delivered and installed with our Quartus II design software.

ECD: Marketing materials for new processors with Advanced Vector Extensions (AVX) suggest replacing external FPGAs with code. Will this new architecture affect the FPGA industry?

RILEY: AVX is an extension of the x86 instruction set targeted at improving performance, specifically in floating-point designs. Processors with AVX can work together with FPGAs to handle tasks such as bridging a dual-sensor interface to a new processor (see Figure 4). These extensions will allow embedded designers to do more with their x86 architectures; however, the performance gulf between a processor and an FPGA is still very large. Benchmark applications such as Finite Impulse Response (FIR) filtering, Fast Fourier Transforms (FFTs), and 2D image filtering are still many times faster on FPGAs than microprocessors. Also, FPGAs are superior for implementing general-purpose logic and bridging to dissimilar devices. So AVX will be a big help to many embedded designers, but it won’t obviate the need for FPGAs in embedded designs.

Figure 4: Lattice Semiconductor’s MachXO2 FPGA can be implemented as a high-speed CMOS sensor interface.

(click graphic to zoom by 1.9x)

BURICH: Custom hardware has always outperformed software. The trade-offs of off-the-shelf hardware extensions are:

1. They might not be optimal for a broad range of applications; only custom, application-specific hardware can deliver the best performance. AVX offers benefits to the PC and tablet industries, but FPGAs already come with strong parallel processing capabilities and are the better fit for embedded markets. One-size-fits-all acceleration incurs the cost of answering a wide range of needs, resulting in inherent inefficiencies.

Off-the-shelf hardware extensions don’t lend themselves to establishing a competitive advantage because competitors have access to the very same hardware and software. Custom hardware can create a competitive differentiator and help developers create a product that outperforms the competition in both performance and revenue generation.

GETMAN: These types of specialized extensions are not new trends to the industry. As an example, MMX was introduced in the mid ’90s on Intel Pentium processors to improve multimedia processing. The ARM architecture is also enhanced with NEON extensions that serve a similar purpose.

In a design where an FPGA is used to perform simple accelerator functions for the main processor, the extra gain in performance from AVX will remove the need for some FPGAs. However, FPGAs are used for other functions beyond just simple accelerators, such as adding peripherals to the main processor, and the AVX architecture cannot address this need covered by FPGAs.

With the continual need for increased system performance, fixed defined instructions might not perfectly address a great deal of proprietary algorithm processing. This results in more clock cycles per function, yielding not only lower performance, but also higher power. This makes the massive parallel approach provided by FPGA architecture well-suited for hardware acceleration, thus enabling customers to continue achieving higher system performance. Therefore, the answer on industry effect is both yes and no.

In addition, FPGA companies have introduced new hybrid architectures (such as the Zynq-7000) that combine application-class processors and programmable logic. These new architectures offer the capability to add hardware accelerators in the programmable logic and have it controlled by the processor in a similar way as AVX. The massive parallel processing capabilities of programmable logic available in these hybrid devices enable performance beyond what AVX instructions could bring to a processor.

Misha Burich is the senior VP of R&D at Altera.

Lawrence Getman is the VP of Processing Platforms at Xilinx. Prior to this role, Lawrence was in charge of corporate development at Xilinx. Before joining Xilinx, he worked as the VP of Business Development at Triscend Corporation and held a variety of marketing and sales roles. Lawrence has a BSEE from Rochester Institute of Technology and an MBA from San Jose State University.

Sean Riley is Corporate VP of the Infrastructure Business Group at Lattice Semiconductor.

Altera
Linkedin: www.linkedin.com/company/altera
Facebook: www.fb.com/alteracorp
Twitter: @alteracorp
www.altera.com

Xilinx
Linkedin: www.linkedin.com/company/xilinx
Facebook: www.fb.com/XilinxInc
Twitter: @XilinxInc
www.xilinx.com

Lattice Semiconductor
Linkedin: www.linkedin.com/company/lattice-semiconductor
Facebook: www.fb.com/latticesemi
Twitter: @latticesemi
www.latticesemi.com

New aircraft platforms get cut back, opening the door for avionics retrofits that leverage COTS hardware and software

John McHale, Editorial Director — Wed, 07 Mar 2012 15:00:00 +0000

Military cockpits – from helicopters to cargo jets to fighter aircraft – will be depending on open architecture designs and Commercial Off-the-Shelf (COTS) hardware and software to keep them flying beyond the next decade as DoD budgets scale back on new platforms. Meanwhile, industry and government experts formed a consortium to enable affordable, platform-agnostic avionics.

Doing more with less is becoming the modern-day mantra of the U.S. Department of Defense (DoD) when it comes to funding military technology procurement. As DoD officials reduce spending across the services – especially when it comes to big-ticket platforms like the Joint Strike Fighter (JSF) – greater emphasis will be placed on maintaining current airborne platforms for at least another decade or more.

No longer will the DoD fund technology development from the ground up. Consequently, the industry is forced to become more cost effective in system designs for avionics retrofits by leveraging common standards and Commercial Off-the-Shelf (COTS) technology that can be used on multiple platforms.

The U.S. financial crisis is not getting settled any time soon, but the world’s not getting any safer either, and the U.S. military will need to maintain and improve its capability during that time, says Mark Grovak, avionics business development for Curtiss-Wright Controls Defense Solutions. Newer platforms such as the F-22 Raptor and JSF will continue to face delays and cutbacks, so the U.S. military will have to update the current aircraft fleet to support current and future missions, Grovak continues. This is good news for COTS suppliers, he adds.

“Retrofits and upgrades to current programs are a huge opportunity given the government’s resistance to fund new programs, while asking the military services to do more with their existing equipment,” says Mac Rothstein, Product Manager, Systems, GE Intelligent Platforms in Charlottesville, VA.

In a lot of avionics upgrades, “we use today COTS processors and many other components,” says Dan Toy, Principal Marketing Manager at Rockwell Collins in Cedar Rapids, IA. “We leverage what is being developed throughout the electronics industry. The telecommunications industry has poured huge amounts of money into the development of electronics that are applicable to military avionics systems. We vary away only when we have a unique need that commercial markets cannot provide.”

“Basically we build thousands of processor cards a year and we use COTS chip technology in a Rockwell Collins processor design,” says Brett Tinkey, Program Manager, Rockwell Collins Airborne Solutions. “That’s primarily how we leverage COTS; we buy COTS devices such as Freescale chips and we design around the chipset.”

A typical component Rockwell Collins leverages is FPGAs, Tinkey says. “One of the best ways to effectively meet reduced size, weight, and power requirements is to leverage FPGAs, which enable you to reduce the footprint or size of a product.” In one upgrade, Rockwell Collins engineers were able to reduce the footprint for one processing function from three boards to one 6U VME board by taking advantage of high-performance commercial components such as FPGAs, he continues. Reducing the footprint enables the system to grow and add capability for the military customer, Tinkey adds.

Moore’s Law shows that the trend toward smaller designs with great capability will continue and is why a VME card today versus one from five years ago “has almost twice the functionality and twice the horsepower,” says Doug Patterson, Vice President of Business Development for Aitech in Chatsworth, CA.

Board-level COTS

“At the board level, we evaluate the efficiencies of building the boards ourselves versus buying completed boards from a manufacturer,” Toy says.

“When we build units ourselves for programs that are one-offs, we will go buy and leverage COTS suppliers such as Curtiss-Wright and GE Intelligent Platforms,” Tinkey says. “Cycle time is an issue in this decision process as well,” as COTS suppliers with a good track record can provide boards and cards more quickly than an integrator would. Design cycles are also trending shorter in the current DoD procurement climate.

“The key in being a COTS supplier is that you can get your customer at least 80 percent of the way to their final desired solution with an off-the-shelf product,” Rothstein says. “In reality, the chances of having an off-the-shelf product that meets all of your customer’s I/O, environmental, and mechanical requirements is very high if you offer enough variations of a subsystem to cover most requirements. Customers can use the off-the-shelf solution to begin their software development while we work with them on the final 10 to 20 percent of the modified system.”

A rugged GE Intelligent Platforms system used in avionics applications is the IPS511, which generates 360-degree views for improved situational awareness (Figure 1). The subsystem can process multiple simultaneous analog video inputs for a variety of different video display configurations for two simultaneous video outputs. For more information, visit http://defense.ge-ip.com/products/3613.

Figure 1: The IPS511 from GE Intelligent Platforms generates 360-degree views for improved situational awareness.

(click graphic to zoom by 1.9x)

Military avionics integrators “want higher levels of software and hardware integration and reductions in size, weight, power, and cost,” Patterson says. Regarding hardware and software integration, the military customer base wants products that can come from different suppliers to be able to work together in their system, Patterson continues. This integration is the burden of the supplier, he adds.

COTS pedigree is important

Military program managers don’t believe PowerPoint presentations anymore; they want to see real hardware and know that the supplier has a pedigree or past history of success in other platforms, says Curtis Reichenfeld, Chief Technical Officer of System Solutions for Curtiss-Wright Controls Defense Solutions in Ashburn, VA. Technical Readiness Levels (TRLs) are driving government procurements, he continues. Products earn high TRLs for new programs when they have been demonstrated or designed into military programs with similar requirements. Military aviation program managers want to reduce risk on programs by having suppliers with a proven program pedigree or high TRL – in other words a history of successful avionics design-ins on fielded platforms, Reichenfeld says.

Military customers want suppliers that have “history, heritage, and pedigree,” Patterson says. For example, imagine a program where a customer needs a new acoustic sensor for hostile fire detection on HMMWV [High Mobility Multipurpose Wheeled Vehicle], he continues. They would have to start from the ground up developing hardware; it would be six months before they had a prototype and another six months to a year before they could ruggedize it to stick in a vehicle to go through hard testing – which is about when the software team would start their development process, Patterson explains. If they leverage COTS hardware that is already qualified, the software team could get up and started immediately, shaving cost and development time, he says.

Sidebar 1: The Future Airborne Capability Environment (FACE) consortium, hosted by The Open Group, comprises industry and government avionics experts working to manage avionics design costs through open standards and COTS technology.

(click graphic to zoom by 1.8x)

Aitech’s rugged COTS avionics offerings include the M595 PMC and M597 XMC cards (Figure 2). Both use the advanced AMD/ATI E4690 Graphics Processing Unit (GPU) operating at 600 MHz with a 512 MB on-chip GDDR3 SDRAM frame buffer. The E4690 works with an integrated, onboard FPGA to support additional video output formats, overlay, underlay, and keying features. For more information, visit www.rugged.com.

Figure 2: Aitech’s rugged M595 PMC and M597 XMC cards are used in avionics applications.

(click graphic to zoom by 1.9x)

Managing the avionics component life cycle

COTS avionics components and systems cut the design cycle and are more affordable but must be closely managed to effectively refresh designs and deal with obsolescence in military platforms that last for decades.

Sidebar 2: Lockheed Martin Aeronautics upgraded the storage capability for the avionics and mission systems on the USAFճ HC/MC-130J Super Hercules with the Vortex Compact Network Storage (CNS).

(click graphic to zoom by 1.8x)

Rockwell Collins engineers have been leveraging common COTS processors, boards, and other components across Army Aviation platforms for more than 15 years through their Common Avionics Architecture System (CAAS), Toy says. CAAS was originally created to refresh variants of the Army’s MH-47G Chinook and MH-60L/M Black Hawk Special Forces helicopters, Toy says. CAAS systems are based on an open architecture approach that leverages adopted industry standards across multiple helicopter platforms, which cuts down technology insertion costs as well as capability retrofits.

CAAS is still going very well for Army Special Operations programs, Toy says. “All of the avionics systems are performing very well and we are beginning to field the second generation of processors.” One of Rockwell Collins’ most recent CAAS upgrades was on the MH-47F Chinook to keep that rotorcraft flying through 2030, he adds.

Because of CAAS, Army Aviation program managers are able to provide a large level of commonality across their fleet of Special Operations helicopters, Toy says. For example, the UH-60M Black Hawk has many of the same avionics display components of the MH-47F Chinook, he adds.

Using one set of cards or boards across multiple platforms “allows us to benefit from economies of scale to manage those common designs,” Toy continues. “We frequently take our approach to develop synergies between various offerings.”

Obsolescence can be managed

Eliminating development costs is not the only reason military customers work with traditional COTS suppliers, Grovak says. Another is that they also want to reduce the total ownership cost of the product. Military systems will need to operate effectively for many years in the field, and the customer needs a strong logistic support plan so they don’t have components go obsolete that cannot be supported anymore, Grovak says.

The most important thing when managing obsolescence is to pick the right components, Tinkey says. “We’re buying a lot of the same parts from our vendors, which will help extend the longevity of our products through a common set of parts in all Rockwell Collins products. The other thing you do is work closely with vendors from the beginning on a life-cycle management plan. It helps that many of the successful suppliers already have product longevity plans in place.”

‘Critical embedded systems’ defined

Jerry Gipper, Editorial Director, OpenSystems Media — Wed, 07 Mar 2012 15:00:00 +0000

Critical embedded systems are the hub of the military, rail transportation, medical, industrial control,
space exploration, aviation, and many other industries. But how precisely is a “critical embedded system” defined – and why does the definition matter?

As you may have come to realize, computers are used in many things never thought possible a few short years ago. These computers are “embedded” into devices, giving them intelligence that improves functionality. These intelligent devices can do more, and can do it faster than ever before. But not all embedded computers are created equal. Some have more demands placed on them than others. Many of these systems must be “able” in many dimensions: dependable, supportable, configurable, reliable, serviceable … and these systems must operate flawlessly to protect life, property, equipment, and the environment.

The term “embedded computer” is very broad without a universally accepted definition, leaving it unclear what is implied. In 2005, VITA set out to define a special-case term that matched the description of the largest share of the applications where VITA technology was deployed. The research started by understanding the definition of life- or safety-critical systems. From there, the term “critical embedded systems” was chosen, but the challenge arose in how to define this term clearly, as pertaining to what was being described.

After several weeks of discussions, “critical embedded systems” was defined as: life-critical or safety-critical systems where failure or malfunction might result in:

Serious injury to people, or
Loss or severe damage to equipment, or
Environmental harm

The definitions for “life-critical” or “safety-critical” were followed, but with the exception that the definitions be restricted to high performance, distributed computing systems that:

Manage high-bandwidth I/O
Involve real-time processing
Are environmentally constrained to Size, Weight, and Power (SWaP)

Ray Alderman, Executive Director of VITA, described several requirements that a critical embedded system must meet to fit within this description. These are systems that must survive in harsh environments: severe shock and vibration, extreme temperatures from low to high, and contamination from dust, dirt, oil, salt spray, corrosive gases, and many other contaminants.

The boards and boxes within critical embedded systems must be designed for long life-cycle applications; these are systems that are often not replaced or updated for many years. They do not become obsolete every few months like personal computers and consumer goods. Revision management is extremely critical to a product life cycle that cannot deviate from one production lot to the next. Therefore, they cannot use components or software that are constantly changing every few months. According to Alderman, if they do, they cannot possibly be called “critical embedded systems.”

Critical embedded systems are being designed with reliability as a primary design requirement. They reach the desired levels of reliability and Mean Time Between Failures through redundancy rather than hot swapping or live insertion of blades. Risks are usually managed with the methods and tools of safety engineering practices. A life-critical system is designed to lose less than one life per billion hours of operation. Typical design methods include probabilistic risk assessment, combining failure modes and effects analysis with fault tree analysis.

Critical embedded systems are highly deterministic, hard real-time in their responses to events. When an event is detected, a predictable response must be applied.

Cost, while important, is not the top priority. Trade-offs are frequently made in favor of supporting the critical aspects of the application, but at the same time, designers have to be conscious of system costs in order to maintain a workable balance. Commercial Off-the-Shelf (COTS) solutions are readily available, helping to keep costs under control; however, these COTS products are not shipped in high volumes nor do these use the same components used in personal computers. For these reasons, the unit costs are higher than consumer-grade products.

Critical applications keep us moving

There are many applications outside of military markets that need critical embedded systems. The intelligent highway, rail transportation, industrial controls, medical, scientific, space exploration, aviation, and many other applications meet the description of critical embedded systems.

Trains continue to be a major form of freight and passenger transportation. Nations around the world have automated train control (ATO) and railway operation systems with components on trains and wayside. Positive train control systems use technology that is capable of preventing train-to-train collisions. Rail safety acts have mandated the widespread installation of these systems. Rail traffic management systems enhance interoperability and signaling throughout train control and command systems. High-speed rail systems make it even more critical to improve the computing capabilities used in these
systems. [Source: MEN Mikro Elektronik, Embedded Tech Trends 2012]

The Large Hadron Collider (LHC) at CERN, used by physicists to study the smallest known particles, depends heavily on critical embedded systems for the control of the physics experiments conducted at the laboratory. Controlling the beams requires the performance and reliability found in a critical embedded system. [Source: MEN Mikro Elektronik, Embedded Tech Trends 2012]

Synthetic Aperture Radar (SAR) systems are used for environmental monitoring, Earth-resource mapping, and military systems that require broad-area imaging at high resolutions. Many times the imagery must be acquired in inclement weather or during night as well as day. SAR systems provide information that is critical to the safe success of many military missions. [Source: Pentek, Inc., Embedded Tech Trends 2012]

Software plays a major role in critical embedded systems

The best, most reliable hardware in the world is only as strong as the software that runs on the platform. While hardware failures are relatively easy to spot, software failures are not. Robert Dewar, President of AdaCore, suggests that the easy way to spot a software failure in a news story is to look for the term “glitch” in the report. Investigators will often state that a glitch was reported to have been the problem that led to a catastrophic failure.

Requests for safety-critical computer systems are increasing not only in air and ground transportation, but also in nuclear physics and critical industrial environments.

Despite using the best-designed hardware, how do you remove the glitches? Dewar suggests that a three-step process can help tremendously.

Step 1: Write a set of rigorous high-level requirements that can be understood thoroughly.

Step 2: Derive detailed requirements that can lead to well written code.

Step 3: Use the detailed requirements to generate tests that check out the code to the requirements.

He also adds that the single biggest change that could be made is to eliminate the tolerance for bad software. All too often, we accept the occasional “glitch” as something that we could not have done anything about, and so we tend to downplay bad code.

Making systems reliable is a consensus position. Both the hardware and the software teams need to be in alignment with total system design. They must work together from the requirements phase to development and on to test as a team that has reliability as a number one priority. Robert adds, “To the definition of ‘critical embedded system,’ I would also add ‘are designed through teamwork to be highly reliable.’”

Initiatives drive improvements

Several initiatives exist to promote safety-critical design. Much of this work benefits critical embedded systems. The Open-DO initiative is but one example of such an initiative led by the software community. Open-DO (as in “Open” and “DO-178C”) is an open source initiative that aims to create a cooperative and open framework for the development of certifiable software (www.open-do.org).

The Reliability Community is a collaborative effort by VITA members to develop a series of standards and guidelines to establish reliability practices for the critical embedded systems industry. The community is comprised of representatives from electronics suppliers, system integrators, and the Department of Defense (DoD). These members have developed community of practice documents that define electronics failure rate prediction methodologies and standards (see http://opsy.st/vitareliability).

Critical embedded systems: The cornerstone of the future

Future computing applications will become even more dependent on critical embedded systems as they continue to reach further into autonomous systems; these systems represent the next great step in the fusion of machines, computing, sensing, and software to create intelligent systems capable of interacting with the complexities of the real world. These systems must be “able,” often needing to be critical embedded systems.

Ten critical embedded system trends to watch in 2012

Jerry Gipper, Editorial Director, OpenSystems Media — Wed, 07 Mar 2012 15:00:00 +0000

Editorial Director Jerry Gipper presents his list of the top 10 VITA critical embedded systems trends for 2012.

Some believe that the Mayan calendar forecasts the end of the world in 2012, but this year promises to have much adventure for VITA technologies. Here are
10 trends to watch unfold in 2012:

1VPX revenues are projected by industry analysts to match VME in 2012. The numbers are rapidly approaching the crossover. New product announcements featuring VPX are in the majority. Not all systems need the performance of VPX so VME design wins continue, but design wins featuring 3U and 6U VPX products are becoming more common, raising expectations that this is the year.

2Military programs will take a hit in 2012. Upgrades will be the safe harbor, but they don’t offer much opportunity for companies looking to enter the market, as these opportunities usually go to the incumbent supplier. At the same time, defense programs look to reduce manpower costs by using more automation and robotics, especially in unmanned vehicles of all types. 2012 promises to be a tough year but could offer great opportunities for companies positioned well with products and business strategies to address this automation.

3Small form factor fever rages on in 2012. Making products smaller while not giving in on capability and performance promises to open up new markets. VITA has four small form factor working groups in play. Which will win is yet to be determined, but we may get a clearer picture by the end of the year. Count 3U VPX in this mix as well.

4FPGAs are poised to take over the majority of I/O responsibility on single board computers. They offer a cost/flexibility ratio never before possible, and it only promises to get better. FMC technology makes the use of FPGAs very attractive as board supplies look for ways to create niches for their expertise.

5Intel just bought the InfiniBand product lines and certain related assets from QLogic. InfiniBand dominates the storage connectivity markets, but does this acquisition mean a more prominent role for InfiniBand in critical embedded systems? Will we start to see the dot specifications for VPX and other VITA technologies fill in the InifinBand gaps? 10 Gigabit Ethernet is not going to give any ground any time soon.

6Optical interconnects have been discussed for decades, but technology breakthroughs combined with eventual approach to copper bandwidth limitations make even more critical the search for optical interconnects that are cost effective and practical. 2012 promises to show some of the first VPX products at least allowing optics to be passed through the backplane using VITA 66 blind mate optical interconnect.

7With all the focus on small form factors, will we see proposals for smaller mezzanines for blade boards appear in a working group? The technical community has been discussing options, but none of them seem to ever gain any traction. 2012 could be the year we see some serious cards get played.

8PowerPC processors held the dominant spot on VME single board computers for many years. But Intel architecture processors have since taken over the top spot. Can the mistakes made with Power Architecture be corrected in time to regain some of that market share? QorIQ with AltiVec makes a return in 2012. Keep an eye on the progress.

9ARM processors are everywhere. With more than 200 licensees, it is impossible to find a processor supplier who does not offer an ARM option. Multicore offerings start to put ARM near the high end of performance. Many I/O boards use some type of ARM processor. Pair these with the low power capability and the multitude of processor options and it becomes only a matter of time before ARM shows up as the primary processor in single board computers.

10 Reliability is a key part of the definition of
“critical embedded systems.” The work done by the Reliability Community has received high marks within the DoD. MIL-HDBK-217 needs updating, and VITA 57 can help. Will the suppliers start to use the guidance of VITA 57 to define the reliability levels of their products? Many in the user community would like to see that happen in 2012.

Embedded computing off the power grid

Robert A. Burckle, WinSystems — Wed, 07 Mar 2012 15:00:00 +0000

With all the advances in low-power and extended-temperature capabilities today, embedded computing systems don’t need to be tied down by a reliance on AC power. Particularly in remote applications, systems can benefit from using alternative energy sources such as solar panels. Off-the-shelf components such as PC/104 SBCs can be configured as part of a solar-powered system with battery backup to operate reliably in unpredictable and potentially harsh environments.

Computers are everywhere, yet most are tethered to the public utility electric power grid to obtain the requisite AC. For isolated applications such as telemetry, pipelines, outdoor signage, military, and others, it is neither convenient nor possible to find reliable AC power mains for an embedded system. Additionally, wireless networking is becoming abundant in remote areas. Low-power, extended-temperature computer systems can now operate using solar, wind, and battery sources. But if you’re not relying on the standard power grid, how can you configure a system to run reliably over time, extreme temperature ranges, and different atmospheric conditions?

Current technology dictates that an engineer should configure a system using a solar panel, power controller, and a battery for storage/backup during the night and periods of overcast weather (see Figure 1). For an outdoor embedded computer system such as this, the electronics and sensors should be able to operate from -40 °C to +85 °C in a sealed box with no fans or heaters. The design must also address four key factors:

1. Total power requirement

2. Amount of sun available at location

3. Battery capacity

4. Solar panel size

Figure 1: A solar-powered embedded system consists of a solar panel, power controller, battery, and low-power SBCs (PCM-VDX and PCM-DC/DC).

(click graphic to zoom by 1.8x)

Starting off with off-the-shelf

Before assessing these parameters, designers should consider the basics of CPU selection and board form factor.

Remarkable progress has been made in low-power electronics. Advances by Intel, AMD, VIA Technologies, and DMP Electronics in high-integration, low-power, x86-based processor families have permitted the functionality and software compatibility of the ubiquitous PC to be used in rugged embedded systems. They also allow the physical size of a system to be shrunk to a 90 mm x 96 mm-sized board while enabling additional I/O boards to be stacked on top of the SBC if necessary.

As designers are increasingly turning to industry standards, they are consequently switching from in-house proprietary designs to commercially available embedded x86-compatible products. This shift in design methodology brings well-designed, technologically advanced system components at reasonable prices, complete with device drivers and application software building blocks and tools.

Of course, other computer solutions are available. The processor could contain one or two low-power ARM cores, and the board could be a Computer-On-Module (COM) mounted on a baseboard or application-specific custom board. But for this example, standard PC/104 off-the-shelf hardware components running either a Windows- or Linux-based operating system were used to provide a fast and easy way to develop and implement the application software program. PC/104 was selected rather than a COM approach because the standard form factor has a wide variety of off-the-shelf I/O modules to interface with many different sensors and peripherals. A COM, on the other hand, requires a custom baseboard, which offers less flexibility and involves longer time to market.

PC/104 is a worldwide standard with multiple vendors offering compatible SBCs and I/O boards in a wide-ranging ecosystem. I/O support is available with legacy PC/104 boards all the way to newer PCI Express-expandable boards. This capability smoothes the evolution from older technologies to new bus architectures by maintaining support for the I/O cards. It’s the I/O that makes applications unique.

Step 1: How much power is needed?

One example of an extended-temperature system is a PC/104 SBC powered by a DC/DC supply. WinSystems’ PCM-VDX-1 is an ultra-low-power 3.5 W Pentium-class SBC with a variety of onboard I/O to interface with different sensors. Power is supplied by the PCM-DC-AT500, a PC/104 board with a DC/DC power supply that is 90 percent efficient. Together, these two products create a load of 3.85 W for 800 MHz computational speed (see Figure 2).

Figure 2: The PCM-VDX (left) and PCM-DC-AT500 (right) PC/104 boards combine a variety of I/O connectivity options with efficient DC/DC power supply in an embedded system that can operate over a -40 °C to +85 °C temperature range.

(click graphic to zoom by 1.9x)

For continuous operation, this represents a 92.4 Wh (3.85 W x 24 h) daily load. In a 12 V photovoltaic system, this requires 7.7 Ah per day (92.4 Wh/day ÷ 12 V). Any real-world I/O, such as analog-to-digital conversion for data acquisition of sensors or transducers, would involve a similar calculation for the additional power required.

Because the embedded computer system is selected the amount of power needed for the application is known. Now the designer can focus on issues concerning energy harvesting and storage.

Step 2: How much sun is available?

The sun is not a reliable source from which to harvest energy due to the darkness at night, plus the variables of extended overcast and inclement weather. To determine the amount of useful sunlight for a specific application, refer to maps of insolation that are available online from the National Renewable Energy Laboratory (www.nrel.gov/gis/solar.html) and other organizations. These spatial interpolations of solar radiation values are derived from the 1961-1990 National Solar Radiation Database.

Maps of minimum, maximum, and average solar radiation data are available. Produced by averaging all 30 years of data for each site, maps of average values predict the amount of average solar irradiation expected on average every day. For example, Arlington, Texas averages 4.5 sun hours per day.

Step 3: What size battery is needed?

Powering the target system directly from the solar panel is difficult due to its current source-like behavior. Therefore, a battery is needed to store the energy harvested by the panel and provide a stable voltage to the system.

The cheapest and most mature storage mechanism is the battery. Batteries have relatively decent energy-storage capability. Four types of rechargeable batteries are commonly used: Nickel Cadmium (NiCd), Nickel Metal Hydride (NiMH), Lithium based (Li-ion), and lead acid. The choice of battery chemistry for a harvesting system depends on its power usage, recharging current, cost, operating temperature, and serviceability in the field. For this example, a lead acid battery was selected because of its low cost, wide range of sizes, low self-discharge rate, reliability over wide temperature ranges, low maintenance, and stable battery chemistry. A lead acid battery can be left on trickle or float charge for prolonged periods. Even though this type of battery can be heavy and a bit bulky, it is a proven and robust technology that is tolerant of abuse in stationary applications.

Lead acid batteries should not be discharged by more than 50 percent of their capacity. Also, it is a good rule of thumb to have at least three days of storage capacity, assuming that at the system’s location there could be at least three days without sun. Other areas may differ, and depending on the nature of the intended application designers might want even more reserve capacity.

Because this system uses 7.7 Ah per day, a three-day discharge would require 23.1 Ah. Therefore, a 12 V, 46.2 Ah lead acid battery would be the minimum size required to ensure continuous uninterrupted operation.

Step 4: What size solar panel should be used?

To calculate the size of the solar panel, it is important to remember that panel size = daily watt hour load/sun hours. Dividing the 92.4 Wh daily load from Step 1 by the 4.5 sun hours from Step 2 yields 20.53 W. Thus, a minimum panel size of 21 W should be sufficient to keep up with system power demands. However, another good rule of thumb would be to add at least 20 percent more capacity when designing the system.

This configuration with WinSystems’ PCM-VDX and PCM-DC-AT500 will operate effectively with a 21 W solar panel and a 48 Ah battery, providing plenty of backup power to support up to one week of low-sun weather.

Controlling system power

A key to the system’s efficiency is the power control module, which draws power from the solar panels, manages energy storage, and routes power to the target system. The power control module should provide multibattery chemistry 2A charging, fast seamless power-source switching, and a wide 9-40 V input range. It is very important not to overcharge during sunny streaks or undercharge with no current during cloudy days. Designers should use a maximal power point tracker that can continuously track and operate at the solar panel’s maximum efficiency rate.

With solar panel technology undergoing rapid change, designers must make sure to select an efficient and reliable unit. Also, when performing design calculations, be sure to choose a battery that can handle the temperature extremes and charge/discharge cycles. Carefully evaluate other battery chemistries and the type of environment that the system must endure.

Due to the increase in solar panel efficiency rates, solar panels are now stronger in output and smaller in size than ever before, while the amount of electrical power needed for embedded computing continues to drop. Other renewal sources such as wind and hydroelectricity provide an alternative to solar power; however, advances in solar technology and lower costs make this combination a viable solution for off-grid computing in remote applications.

ECD in 2D: Following the simple four-step process discussed in this article, engineers can learn how to harness solar energy using low-power PC/104 products. Use your smartphone, scan this code, watch a video: http://opsy.st/x9UCEi.

(click graphic to zoom by 3.5x)

Robert A. Burckle is VP of WinSystems.

WinSystems
817-274-7553
bburckle@winsystems.com
Linkedin: www.linkedin.com/company/winsystems-inc.
Facebook: www.fb.com/WinSystemsInc
Twitter: @WinSystemsInc
www.winsystems.com

Demanding big-time graphics in little packages

Dan Demers, congatec — Wed, 07 Mar 2012 15:00:00 +0000

The demand for graphics performance in small form factor embedded devices is continuing to grow to the next level. This push has created new challenges for designers in a broad array of vertical markets. Silicon platforms available today enable the creation of small devices with enhanced embedded graphics capabilities.

Embedded PCs are being pushed to excel like never before. Much of this pressure is generated by user requirements stemming from the consumer market and its vast array of computing devices. Today, it’s hard to find a vertical market that doesn’t have a need for more powerful graphics capabilities. At the same time, the push for low-power smaller form factors compels embedded PCs to keep up with shrinking board sizes. Many years ago, the future of embedded computing was defined with a focus on “smaller is better.” Now that objective seems to have been redefined as “smaller, with more capabilities, is better.”

To achieve high-quality video in an embedded system, designers have traditionally needed to incorporate peripheral-based graphics engines in the form of a plug-in card or module. This increased the overall hardware component count in the system and often led to additional form factors and heat concerns.

Today, major silicon vendors are providing embedded graphics processors powerful enough to tackle multiple application requirements. One such processor is the Accelerated Processing Unit (APU), which combines the functionality of a Central Processing Unit (CPU) and a Graphics Processing Unit (GPU) into one chip.

Processes run mostly serially on a standard CPU. Under these circumstances, parallelization can only occur in multiprocessor systems or virtually via time-splicing control of relatively large processes. On the contrary, with a GPU, tasks are distributed over many small and highly specialized engines. These engines are linked to one another according to their respective tasks, which they manage in each time step in parallel. With another type of processor, the General-Purpose GPU (GPGPU), the individual processor tasks are not hardwired, as is the case with the Vertex Shader Unit using a simple GPU. Instead, the particular tasks are freely configurable, similar to a network processor within a certain range.

An APU such as the AMD Fusion distinguishes itself from a standard GPU with its flexible parallel processing units. Its GPGPU can be used for compute-intensive parallel operations and can considerably increase performance in the non-graphics sphere. This APU not only provides a powerful graphics engine, it also gives developers the freedom to use it for other purposes as well.

Qseven addresses graphics needs

When it comes to implementing the latest APU silicon in a system, the best choice is often a small form factor module. One example of a small form factor module utilizing AMD’s Fusion APU is congatec’s latest Qseven module, the conga-QAF (Figure 1). The Qseven standard is an off-the-shelf, multivendor Computer-On-Module (COM) that integrates all the core components of a common PC. It is mounted to a carrier board that enables designers to match their I/O requirements with their footprint requirements.

Figure 1: The conga-QAF Qseven module combines high graphics performance, dual-core processing power, and low power consumption in a small form factor.

(click graphic to zoom)

Measuring 70 mm x 70 mm, the Qseven form factor utilizes a high-speed MXM system connector that has a standardized pinout regardless of the vendor. The Qseven specification defines an ultra-low overall height of 13.9 mm for the carrier board, Qseven module, and flat heat spreader combination when using the lowest-profile MXM connector.

In addition to offering a compact design, the Qseven module allows designers to address the challenge of potentially running the system on battery power. To obtain the most uptime from batteries, designers need to focus on keeping total system power draw as low as possible. Depicted in the block diagram in Figure 2, the AMD G-Series APUs found on congatec’s conga-QAF modules have a clock speed of 1.0 GHz and a Thermal Design Power (TDP) of 5.5 W in the single-core version and 6.4 W in the dual-core version. Either model enables the Qseven module to fall under the specified 12 W ceiling for Qseven modules.

Figure 2: AMD’s Embedded G-Series architecture integrates a low-power processor and advanced GPU into a single embedded APU.

(click graphic to zoom)

APUs in action

One area of the embedded market where APUs and modules like Qseven are beginning to play a major role is medical equipment. Geared by the consumer market, the efficiency of the graphics core has steadily increased in the medical equipment market. In particular, the 3D representation of virtual worlds has advanced the specialization of graphic cards to the highest parallel of computing power. Due to the variety of graphics data such as computations of textures, volumes, and 3D modeling for collision queries, as well as Vertex Shader for geometry computations, the functionalities are no longer cast firmly in hardware, but rather can be freely programmed. Therefore, modern graphics cores offer flexible and enormous potential.

A specific example in the medical equipment industry is the computational requirements found in today’s portable 3D ultrasound devices. Certain data forms from sensors, gauge heads, transceivers, or video cameras are processed more efficiently and faster with dedicated processing cores than with the generic, serial computing power of x86 processors. With the GPGPU, it is irrelevant if program codes are virtually produced or forwarded from external sources. Thus, there is an advantage in uniting the CPU and GPU in an APU to create an even stronger team.

These days, portable computing-based devices, regardless of whether they are used in medical, automation, logistics, or kiosk systems, require higher graphical and computing performance than what is offered by previous embedded technologies. Users can easily upgrade their machines and devices by changing modules to enable future performance gains. This leads to new possibilities in portable devices, particularly in regard to imaging technology and analysis devices, where the APU architecture can fully exploit the advantages of parallel processing. In addition, the excellent ratio of computing power to power consumption enables battery-operated devices with higher performance. Moving forward, it is inevitable that more and more applications will take advantage of future developments around APUs, with Qseven modules available to help designers turn their ideas into reality.

Dan Demers is sales and marketing manager at congatec Inc.

congatec 858-457-2600 info@congatec.com www.linkedin.com/company/congatec-ag www.congatec.us

The value of usability: Getting developers to ‘push the button’ on static analysis – Q&A with Gwyn Fisher, CTO, Klocwork

Jennifer Hesse, Editor, OpenSystems Media — Wed, 07 Mar 2012 15:00:00 +0000

The ubiquitous nature of embedded software has made source code analysis a critical component of the development process. Gwyn discusses the impact this technology has on software security and reliability, and emphasizes the importance of making static analysis a natural part of a developer’s coding practice.

FISHER: Any new development is an exercise in balancing expectation against risk. In the case of multicore, the naive expectation is always linear acceleration tempered perhaps by some jocular “wouldn’t that be nice” acceptance that the final result won’t be quite that good, but no real understanding of the reality that without significant effort (read: time, money, angst) the result might be slower than the old, interrupt-driven single-core code. So tools have a role to play in terms of helping developers understand the impact of what they’re doing, what pitfalls they’re unwittingly leaving themselves open to, and how to mitigate the associated risks.

Dynamic analysis in this space has received the lion’s share of attention for obvious reasons. If I can see a nice set of graphs over time that shows the performance of my code in action, I can presumably narrow in on problem areas quickly and apply my own knowledge to figuring out what’s going on. The challenge with dynamic analysis is that it depends on a) defining a test set that shows execution problems, and b) the reviewer’s intimate knowledge and understanding of what to do about those problems.

Static analysis, by contrast, assumes little knowledge on behalf of the reviewer and requires no effort to be expended in defining test cases. Every conceivable code path through the application is exercised with as much rigor as every other path. This approach is therefore far more likely to show complex and costly issues such as data races, deadlocks, and resource contention than any constructed test bench. That speaks directly to the bottom line of cost control in what is inevitably a large, over-budget project. Leaving issues such as these in a code base until late in the validation process will cost exponentially more to address than doing so during initial development.

In addition, due to the way that static analysis works by modeling the expected program execution, the finding is accompanied by a detailed walk-through of how the situation is predicted to occur, allowing even a relatively junior resource to interpret the issue at hand, determine whether or not it’s likely to happen, and apply an appropriate design fix. In one example we like to describe in seminars on the subject, a design flaw in a popular open-source database kernel resulted in months of effort expended to identify a deadlock and eventually rewrite key modules to avoid the data race at its heart. This same problem was identified during the first analysis using our tools, which provided a walk-through description enabling developers to easily see that the data race was causing the problem and that the deadlock was merely the symptom.

Contrast a few hours to run the tool to analyze the code and an hour at most to interpret and act upon the result (what turns out to be a one-line fix) with months of community effort to determine an appropriate set of tests, followed by design effort attempting to fix the deadlock, and finally requiring the designer to rewrite the whole thing from scratch.

ECD: How is static analysis introduced in the software development cycle, and how can it be used with existing Integrated Development Environment (IDE) tools?

FISHER: There’s absolutely no doubt that any developer-facing tool that doesn’t integrate seamlessly with any existing tooling is going to face significant friction in deployment. We’ve been selling this message effectively for years, with development managers almost asking the “why wouldn’t you do it this way?” question for us.

Whether developers have migrated to IDEs or their idea of an IDE is a bunch of gVim macros or emacs lisp modules, to them it’s where they live and work. And woe betide any vendor who tries to get them to change. Even if you’re not suggesting that they change tools, and instead asking them to visit somewhere else to see what they might have done wrong in some retrospective manner, your tool is going to suffer waves of disinterest and ultimately become shelfware.

Thus, static analysis has to be part of the developer’s native habitat, and more importantly, it has to work in a way that feels natural and follows the way other tools in that habitat work. For a gVim developer, issuing a ‘:’ command is second nature, so tools in that environment should follow suit. Put that same interaction mechanism in front of a Visual Studio user, and that will make for a fun-filled afternoon of derisive commentary.

At Klocwork we’ve gone through various iterations of technology design, getting closer to the developers themselves. It’s one thing to be resident as a tool within an IDE; it’s another to get the developer to “push the button” to use it. Making a button available is only changing geography, and it does nothing to help with the tool’s fundamental usability.

With this in mind, we’ve recently introduced a new technology that allows static analysis to take place in much the same way as spell checking in a Word document or e-mail. That is, as you’re writing your code and the tool detects a problem with what you’re doing, it can point out the problem in a perceptually instant manner, highlight it with a squiggly underline, and deliver all the value of static analysis with none of the “what do I have to do to use it?” resistance that is typically encountered during any new tool’s introduction (see Figure 1).

Figure 1: Following in the footsteps of word processors, Klocwork Insight highlights coding issues with a squiggly line the instant they’re introduced.

(click graphic to zoom by 1.9x)

Getting a tool into an IDE is tough; getting it to be useful in the part of the IDE the developer truly lives in (the editor component, whatever that looks like in the environment at hand) is really tough. But until you’re there, you’re a distraction.

ECD: Can source code analysis be used to protect embedded devices against potential security threats?

FISHER: Absolutely, source code analysis has a significant role to play in threat identification and validating whatever threat model is being used to determine vulnerability in the device. The connectivity requirement is common in the embedded world today. That connection might be to another chip, or another device, or the whole Internet. In any case, there’s somebody else either sending you information or receiving information you’re sending. That’s the starting point for having to worry about your entire application design.

Static analysis doesn’t typically know, or try to know, anything about your surrounding environment. Tools can sometimes be tuned to perform their analysis within certain data boundaries, for example, such as knowing that a particular input will only range between -20 and +30 because it’s a temperature sensor intended for use in Western Europe. But that kind of thing is discouraged because you’re allowing the user to define limits to what the modeling technology naturally does – that is, assume nothing and point out everything that looks wrong.

In the case of threat detection, we’re most worried about how the data you’re interacting with from the outside world is used internally. Is it used to create a buffer into which you’ll read data (code or value injection), or is it used for memory allocation (Denial of Service or DoS), or perhaps interpreted as a reference into an internal data structure (hijacking or redirection)? This kind of data and path validation – that is, the path that tainted data follows from the outside world to its point of use within the code – is natural for source code analysis, as it accomplishes this modeling in order to perform everything else it does.

As a wonderful gentleman at a defense contractor once said to me, “Son, it’s a bomb; it’s supposed to blow up. We just want to be sure it doesn’t get hijacked on its way.”

ECD: What educational events or online classes does Klocwork offer to help embedded designers get started with its code analysis tools?

FISHER: Like any commercial organization attempting to encourage users to gain value from its tools, Klocwork provides a full suite of educational and professional services, running the gamut from introductory materials aimed at first-time users, to more advanced courses targeting secure coding and threat modeling, to full-on deployment services and mentoring.

We also recently introduced the Klocwork Developer Network (http://developer.klocwork.com), a website serving our users and acting as a repository for online courses, video tutorials, in-depth courseware, and the usual variety of community forums and ticketing.

Each customer has something unique they wish to gain from a tool such as source code analysis, so a large part of our educational focus is on internal champions, people who take knowledge of how the tools work and how other organizations have applied them and leverage those lessons in deploying our tools for their own use. A large part of that is learning from the community, so I’ve been thrilled to see the fast uptake that the Klocwork Developer Network has seen amongst users, both as a less formal mechanism for interacting with our staff, but most importantly as a way to learn from other customers.

ECD in 2D: Klocwork Insight’s plug-in for Visual Studio continuously runs data flow analysis to accurately identify defects and security vulnerabilities. Use your smartphone, scan this code, watch a video: http://opsy.st/zdEhC1.

(click graphic to zoom)

Gwyn Fisher is CTO of Klocwork.

Klocwork info@klocwork.com www.klocwork.com/blog www.facebook.com/klocwork www.twitter.com/@klocwork www.klocwork.com

Attack the stack: Identifying unauthorized code execution caused by buffer overflows

Rutul Dave, Coverity — Wed, 07 Mar 2012 15:00:00 +0000

Nearly half of all critical security leaks in embedded software are due to heap overflows. Stack-based buffer overflows account for a smaller percentage, but are exploited with the same technique to inject and execute unauthorized code or change execution flow. Instead of policing such attacks to manage security risk, a better approach is to use the strength of quality software development and code testing with static analysis to find and fix the underlying defects that lead to security vulnerability.

“Because that’s where the money is.”

That’s what Willie Sutton, a prolific bank robber in the United States from the late ’20s to the early ’50s, reputedly said when asked why he robbed banks.

Embedded systems typically don’t suffer from popular sources of Web application security exploits like cross-site scripting and SQL injection. However, security threats are real and ever-present in embedded systems. So where’s the “money” when it comes to security in embedded software?

When reading through the release notes of most software vendors, developers will notice that security patches often contain fixes to a variety of buffer overflow defects. For example, take a look at the security update for Mac OS X at http://support.apple.com/kb/HT4723. It contains a good number of string and heap buffer overflows.

On average, about half of all critical security leaks are caused by heap overflows. Stack-based buffer overflows in embedded software are also a major source of security exploits from altered code. Even without the security risk, buffer overflows are still problematic, as they can cause program execution to halt or produce unexpected values that can be tough to trace at execution time.

With a large amount of software services moving to the cloud, embedded systems at the core of cloud computing infrastructures are more exposed to threats from unauthorized code execution, arbitrary control of resources, corruption of sensitive information, and Denial of Service (DoS) attacks. Developers can benefit from looking at what goes on behind the scenes in a simple buffer overflow and seeing how it allows hackers to change program flow or execution.

What happens in a buffer overflow?

Memory management lies at the heart of buffer overflow exploits. At its most basic level, the problem arises from the fact that Operating Systems (OSs) mix variables and buffers from the program with program execution data. If developers can overflow the program data buffer and overwrite program execution data, they usually can alter program execution.

In its simplest form, a program in memory is organized in three sections/segments: text, data, and stack (Figure 1). The text section, also known as the code segment, is the fixed-size, read-only area that contains code and instructions on executing the program. Similarly, the data section is a fixed-size segment that contains the global variables and static variables initialized in the program.

Figure 1: Program memory is organized in text, data, and stack sections.

(click graphic to zoom by 1.9x)

The stack is the area most relevant to this discussion. It starts at a fixed address, with a register pointing to the top of the stack. Elements called stack frames are PUSHed when calling a function and POPed when returning. A stack frame contains the value of the instruction pointer when the function is called. This instruction pointer is necessary to alter an execution flow from a buffer overflow.

A simple example can illustrate what a stack looks like:

void password (char *buf) { char var[16]; strcpy(var, buf); }

void main () { password(“mypassword”); printf(“This should be executed first\n”);

printf(“This should be executed next\n”); }

When this program is executed, it will show the following:

This should be executed first This should be executed next

The key to understanding what can be done with the stack is to look at the assembler code generated by the compiler. For this discussion, assume this program is executing on an Intel x86 CPU and the OS is Linux.

In main(), it shows:

call password ← This will push the instruction pointer (IP) on to the stack so that it can be used as a return address (RET)

And in password(), it shows:

pushl ebp ← This pushes the frame pointer (EBP) on to the stack movl ebp, esp ← This copies the stack pointer (SP) onto EBP making it the new frame pointer (SFP)

Now when password() is called, the stack looks as depicted in Figure 2.

Figure 2: A call to mypassword() alters the program stack.

(click graphic to zoom by 1.9x)

Analyzing the attack

In lieu of this example, how can the stack be attacked, considering that there is a fixed-sized buffer on the stack that can overflow? Notice that just before the buffer var[16] on the stack is the stack frame pointer, and before that is the return address. So if var[16] could be modified and filled with a value larger than the 16 characters allocated, code could then be executed at the address filled with the return address. In this simplistic example, password() calls an unprotected string-copy function (strcpy()), allowing var[16] to overflow and thus change the return address.

Using GDB can obtain the address of an instruction to execute:

(gdb) disassemble main Dump of assembler code for function main: 0x0804840e : lea 0×4(%esp),%ecx 0×08048412 : and $0xfffffff0,%esp 0×08048415 : pushl -0×4(%ecx) 0×08048418 : push %ebp 0×08048419 : mov %esp,%ebp 0x0804841b : push %ecx 0x0804841c : sub $0×4,%esp 0x0804841f : movl $0×8048514,(%esp) 0×08048426 : call 0x80483f4 0x0804842b : movl $0x804851f,(%esp) 0×08048432 : call 0×8048324 ← Call to first printf() 0×08048437 : movl $0x804853d,(%esp) 0x0804843e : call 0×8048324 ← Call to second printf() 0×08048443 : add $0×4,%esp 0×08048446 : pop %ecx 0×08048447 : pop %ebp 0×08048448 : lea -0×4(%ecx),%esp 0x0804844b : ret End of assembler dump.

Now it’s a matter of passing a string larger than 16 characters that contains the address 0x0804843e, overflowing the buffer and changing the program execution flow.

Sophisticated code testing

Writing embedded code that works, does what it is supposed to do efficiently, and is simple to understand and maintain is not an easy task. While higher-level security concerns like these are often addressed later in the development process, they can be tackled earlier by using proven practices to build quality software.

Defects like string buffer overflows that open possible exploits can be mitigated by not using functions like strcpy() that produce unprotected copies of character arrays to fixed-size buffers. In addition, techniques such as automated code testing using static analysis provide a more sophisticated approach to avoiding static and dynamic buffer overflows.

The following techniques make static analysis an extremely powerful tool for finding programming errors accurately and efficiently at compile time.

Data flow analysis

Modern static analysis tools use data flow analysis to identify the execution path during compile time by creating a control flow graph representation of the source code.

Equation 1: Data flow analysis

(click graphic to zoom by 2.8x)

In Example 1, the if statements have four possible execution paths through the code. When the value of x passed into the function is not zero, p is assigned a null pointer with p=0. Then the next conditional check (x != 0) takes a true branch, and p is dereferenced in the next line, leading to a null pointer dereference.

Interprocedural analysis

Another useful technique that static analysis employs is interprocedural analysis for finding defects across function and method boundaries.

Equation 2: Interprocedural analysis

(click graphic to zoom)

Example 2 contains three functions: example_leak(), create_S(), and zero_alloc(). To analyze the code and identify the memory leak, the analysis engine traces the execution to understand that memory is allocated in zero_alloc(), initialized in create_S(), and leaked when variable tmp goes out of scope when it is returned from function example_leak().

False path pruning

A third technique that smart static analysis uses is false path pruning. Regardless of the type of defect or its impact on the embedded system’s security or quality, automated defect-reporting tools must be accurate. This expectation is the same for static analysis; the tool should report critical defects and not false positives. A key to ensuring that the reported defects are real is to only analyze the executable paths.

Equation 3: False path pruning

(click graphic to zoom by 2.7x)

Example 3 is slightly modified from Example 1. In this case, the execution path simply cannot be executed. Consider the case where the first conditional check (if (x != 0)) results in the false case being evaluated. This will assign variable p the value of 0. At the next conditional check, if the analysis engine looks at the true path it will report a null pointer dereference defect, but that would be a false positive because the execution logic will never traverse this path. It is not possible to evaluate the same conditional check (if (x != 0)) in two different ways. By pruning a path that can never be executed (a false path), good analysis can report up to 50 percent fewer incorrect defects.

Data flow analysis, interprocedural analysis, and false path pruning are only a few of the tricks that a good static analysis tool uses to provide a list of actionable defects that, left unchecked, can have a direct impact on software security … and that’s “where the money is.”

Rutul Dave is senior development manager at Coverity.

Coverity coverity@lewispulse.com www.linkedin.com/company/coverity www.facebook.com/Coverity www.twitter.com/@Coverity www.coverity.com

Trusting the tools: An agile approach to tool qualification for DO-178C

Dr. Benjamin Brosgol, AdaCore — Wed, 07 Mar 2012 15:00:00 +0000

The new avionics software safety standard DO-178C, along with its supplemental Software Tool Qualification Considerations (DO-330), has clarified and expanded the tool qualification guidance provided in DO-178B. The challenge of maintaining qualification-ready tools throughout a system’s evolution can be expedited through an approach based on agile development principles.

If a manual activity required for avionics software certification is reduced or replaced by an automated tool, and the output of that activity is used without being verified, then the developer needs to qualify the tool: demonstrate that the tool is at least as trustworthy as the activity that it is replacing. The new avionics safety standard, DO-178C – together with its companion Software Tool Qualification Considerations, DO-330 – has clarified and expanded the tool qualification guidance defined in DO-178B. The following discussion summarizes the new guidance and describes an agile approach to maintaining qualification-ready tools in the presence of system maintenance and changes.

Tool qualification in DO-178B

DO-178B[1], a commercial avionics software safety standard that is finding increasing usage in military aircraft development, is often referred to as “process based”: It specifies an interrelated collection of software life-cycle processes, each comprising a set of activities and associated objectives. The activities produce outputs (“artifacts”) that are evaluated by certification authority personnel to see if they comply with the objectives specified in DO-178B. The applicable objectives (and thus the applicable activities and artifacts) depend on the Software Level: the criticality of the software in ensuring aircraft and occupant safety. The levels range from E (no effect) to A (software failure can directly lead to loss of aircraft and, therefore, lives).

Some DO-178B activities are automatable, and the standard describes how a tool can be trusted to replace or reduce a manual activity if the tool’s output is used without being verified. It defines two categories: development tools and verification tools. A development tool generates output that is part of the airborne software and thus has the potential to introduce errors. An example is a code generator that produces source code from a model-based design. A verification tool cannot introduce any errors but may fail to detect errors, for example, a static analysis tool that identifies variables that are read before being initialized.

Tool qualification entails preparing, among other data items, the Tool Operational Requirements (TOR). The TOR defines various properties of the tool including its features, installation, usage, and operational environment.

A development tool needs to be qualified if, and only if, the software generated by the tool will not be subjected to the same applicable certification objectives as the other airborne software. Development tool qualification entails meeting the same objectives as for the certification of the airborne software. (Although compilers and linkers are development tools, qualification is not required since their output is verified through other DO-178B activities. Indeed, qualification would be expensive and would not simplify the effort in meeting other objectives such as traceability analysis.)

Qualifying a verification tool is considerably simpler than qualifying a development tool, in part because DO-178B’s philosophy is to encourage the use of such tools to automate activities involving repetitive and rule-based tasks, which are better performed by automated tools than by humans. Qualifying a verification tool basically consists in demonstrating that the tool complies with its TOR.

Tool qualification in DO-178C

Tool qualification has been an important part of DO-178B certification, but several issues have arisen in practice:

The distinction between a verification tool and a development tool is not always straightforward. Moreover, a verification tool might not simply automate a specific activity; its output may also be used to eliminate or reduce some other activity.
Requiring a development tool to meet the same objectives as the airborne software is unnecessarily restrictive, since the operational environments are different. For example, an unbounded recursion in the avionics software could exhaust stack storage and lead to a system failure; the same behavior in a development tool would not present a safety hazard.
Although tool qualification is intrinsically in the context of a specific system, it would be beneficial if the qualification requirements expedited reuse of qualified tools on a modified version of an existing system.

All of these issues are addressed in either DO-178C[2] or its accompanying supplement DO-330, Software Tool Qualification Considerations[3].

The terms “development tool” and “verification tool” have been replaced by three criteria. Criterion 1 corresponds to a development tool (that is, the tool could insert an error into airborne software). Criterion 2 corresponds to a verification tool that could fail to detect an error and is used to reduce other development or verification activities. Criterion 3 corresponds to a verification tool that could fail to detect an error but is not used to reduce other development or verification activities.
The required qualification for a tool – its Tool Qualification Level (TQL) – depends on its Criterion and on the Software Level of the software that the tool is used for, as shown in Table 1. The TQL ranges from 5 (comparable to a DO-178B verification tool) to 1 (similar to Software Level A). The activities and data items associated with each TQL are defined in a separate document, DO-330, with the same structure as DO-178C. DO-330 provides comprehensive guidance for tool qualification and recognizes the differences between the execution environments for the airborne software and the tool.
DO-330 explicitly covers the usage of previously qualified tools. In brief, the reuse of a previously qualified tool is allowed as long as the developer can demonstrate, through a change impact analysis, that the tool still complies with its TQL requirements despite any changes in the operational environment or to the tool itself.

Table 1: The required qualification for a tool – its Tool Qualification Level (TQL) – depends on its Criterion and on the Software Level of the software for which the tool is used.

(click graphic to zoom by 1.9x)

Reuse of previously qualified tools

The ability to reuse, or easily adapt, the qualification artifacts for a previously qualified tool is especially important. DO-178B provided no explicit guidance here. Tool qualification that was performed for one system would need to be repeated for any new system or if any aspect of the tool or environment changed. As a result, a project manager would commonly choose the operational environment and tools at an early stage, and then commit to these versions so that the tool qualification artifacts could be used during final system certification. This is sometimes referred to as the “big freeze,” where the environment and tools are locked in early.

DO-330 addresses these issues. Specific guidance for previously qualified tools allows reuse of the qualification artifacts as long as nothing has changed that would affect qualification. It considers three scenarios:

Reuse of a previously qualified tool without change – An example is when a tool is used for related projects or on multiple phases of an existing project. The developer needs to identify the approach and rationale in the plans.
Changes to the tool operational environment – The developer needs to update one or more of the plans, but the bulk of the original qualification artifacts may be reused as is. Only the updated artifacts related to the operational environment need to be reviewed by the certification authority.
Changes to the tool itself – A change impact analysis has to be provided, but tool requalification still has a reduced cost, essentially only requiring activities associated with aspects that have changed or are affected by the change. The key is to be able to exactly determine and specify what has changed and what these changes impact, or perhaps more importantly, what they do not impact.

Agile requalification

Based on the tool qualification guidance – either from DO-178B or from DO-178C and DO-330 – it is possible to define a framework for tracking the changes to a tool or its operational environment and for automatically initiating the tool qualification activities triggered by the changes.

For example, a tool can be initially developed and qualified based on the objectives defined in DO-178C and DO-330. The full tool development life-cycle processes and their associated qualification artifacts can be captured and maintained in a Configuration Management (CM) system, including all dependence relationships (see Figure 1). The core CM system allows basic regeneration of all qualification data and artifacts needed to reproduce a tool qualification. The full structure allows impact and change analysis. In this way any change to the tool’s operational environment or to the tool itself can be tracked. Most importantly, the structure will clearly show which parts of the tool and its artifacts are not affected and thus can remain unchanged and retain their previous review and qualification readiness.

Figure 1: The full tool development life-cycle processes and their associated qualification artifacts can be captured and maintained in a Configuration Management (CM) system, including all dependence relationships.

(click graphic to zoom by 1.9x)

Transitioning to the new qualification guidance

DO-178B is effectively a subset of DO-178C. Thus, a project can continue with the development and certification plans established for DO-178B while migrating chosen portions to DO-178C, for example, to exploit the tool qualification objectives in DO-330. Therefore, both existing DO-178B projects and new DO-178C projects can take advantage of DO-330’s cost-effective guidance on tool qualification and requalification.

The AdaCore Qualifying Machine framework[4], an in-progress implementation of the agile technique described in the previous section, supports this approach. It can help projects avoid the “big freeze,” so that tools and development environments can evolve smoothly. Tools may be upgraded to newer versions as updates become available, without the risk of losing the tool qualification required for system certification.

References:

[1] RTCA SC-167/EUROCAE WG-12. RTCA/DO-178B – Software Considerations in Airborne Systems and Equipment Certification, December 1992.

[2] RTCA/DO-178C – Software Considerations in Airborne Systems and Equipment Certification; publication expected in 2012.

[3] RTCA/DO-330 – Software Tool Qualification Considerations; publication expected in 2012.

[4] www.open-do.org/projects/qualifying-machine

Dr. Benjamin Brosgol is a senior member of the technical staff at AdaCore. He has more than 30 years of experience in the software industry, concentrating on languages and technologies for high-integrity systems. He has presented papers and tutorials on safety and security certification at numerous conferences and has published articles on this subject in a variety of technical journals. He holds a Ph.D. in Applied Mathematics from Harvard University. He can be contacted at brosgol@adacore.com.

Greg Gicca is Director of Safety and Security Product Marketing at AdaCore. He has more than 20 years of experience in designing and implementing software development tools and has participated in industry and government groups responsible for defining software quality evaluation standards. He has concentrated on the safety and security arena for embedded systems, with a particular focus on the DO-178B safety standard and the Multiple Independent Levels of Security (MILS) architecture. He can be contacted at gicca@adacore.com.

AdaCore 212-620-7300 www.adacore.com www.linkedin.com/company/adacore www.twitter.com/AdaCoreCompany

DO-178C brings modern technology to safety-critical software development

Tim King, LynuxWorks — Wed, 07 Mar 2012 15:00:00 +0000

Avionics software technology has improved by leaps and bounds since DO-178B was introduced in 1992. DO-178C will bring safety-critical software development into the modern era, adding support for advanced techniques such as UML and mathematical modeling, object-oriented programming, and formal methods. The ready availability of third-party tools, platforms, and certification services will hasten the adoption and deployment of DO-178C.

As software becomes more complex, it becomes hard to manage the design of that software at the code level. Object oriented programming (C++, Ada, and Java) and modeling (UML, mathematical, and so on) simplify the development of complex software by enabling designers to conceptualize, architect, and encapsulate their design at a higher level. Formal methods, which are related to model based development, make it easier to assess correctness of complex software functions like control loops.

DO-178C inherits the DO-178B core document, principles, and processes, while adding support for high-level modeling, object oriented programming, and formal methods, with an emphasis on two-way traceability from model to executable code and back (Sidebar 1). DO-178C also provides a tools supplement for addressing in detail the qualification and capabilities of the tools used for not only modeling, object-oriented programming, and formal methods, but also for other development technologies such as procedural software and assembly-level programming.

The DO-178C supplements

The DO-178C working group has produced three development technology supplements: Object Oriented Technology and Related Techniques (OOT & RT), Model Based Development and Verification, and Formal Methods. It also greatly expanded the tool qualification guidance present in DO-178B. These four supplements have been published by the RTCA as:

DO-330, Software Tool Qualification Considerations
DO-331, Model-Based Development and Verification Supplement to DO-178C and DO-278A
DO-332, Object-Oriented Technology and Related Techniques Supplement to DO-178C and DO-278A
DO-333, Formal Methods Supplement to DO-178C and DO-278A

Note that DO-278A is the ground system equivalent of DO-178C.

Object Oriented Technology and Related Techniques

The Object Oriented Technology and Related Techniques (OOT & RT) is a comprehensive safety-critical software guide for hand code development and verification. It encompasses not only object oriented software development, but also techniques that are used in procedural languages. These related techniques include such things as dynamic memory management, overloading, parametric polymorphism (such as templates in C++ and generics in Ada) type conversions, and virtualization. The net result is that the OOT & RT supplement could be invoked on most projects utilizing procedural languages as well as OOT.

Sidebar 1: The incorporation of advanced modeling and object oriented programming techniques in DO-178C places new demands on verification.

(click graphic to zoom)

The most significant addition to the OOT & RT is the definition of new objectives. Objectives identify which development assets, integrated processes, and verification artifacts must be produced for a product to be certifiable. The OOT & RT defines two new verification objectives: The first verifies local type consistency, which enables subclass methods to safely override parent class methods. The second verifies that the use of the dynamic memory management system is robust. In particular, it verifies the following characteristics of the dynamic memory management system: reference ambiguity, fragmentation starvation, deallocation starvation, memory exhaustion, premature deallocation, lost updates and stale references, and unbound allocation or deallocation time.

Model Based Development and Verification (MBD&V)

The biggest and most contentious challenge in reviewing and approving the MBD&V supplement was determining the final verification method used on the Executable Object Code (EOC) compiled, linked, and loaded on the target system. In the context of the MBD&V systems under consideration, the EOC is directly traceable to the source code automatically generated by the model. Historically, there has been a precedent set in the verification of some avionics software that was tested both by and in the model itself without doing target testing on the EOC, effectively obviating the objectives for EOC testing in the DO-178C “core document.” Instead, the DO-178C plenary agreed that a form of independent verification must be performed on the EOC on the target system, thereby preserving the EOC objectives of DO-178C.

Notwithstanding the consensus reached with respect to EOC verification, the MBD&V supplement did add many objectives that provide certification credit for verification activities performed by the model, or at least defined by the model, on the model architecture and model code. These verification activities are primarily performed by “simulation cases,” which are run in lieu of test cases and other forms of verification.

Probably the most definitive of the FAQs added to any of the DO-178C tech supplements were those added to the MBD&V supplement. The scope of the new FAQs spans development and verification, including not only standard high- and low-level software requirements and the associated specification and design models, but also the system requirements allocated to software. Historically, the gaps between these model types and requirements hierarchies and their various provenances have been a leading cause of ambiguity and poorly realized designs in MBD&V projects.

Formal methods supplement

The Formal Methods supplement follows a similar trajectory to that of MBD&V in that it also eventually agrees to preserve the EOC objectives of the core document by stipulating independent verification for the EOC ultimately produced by formal methods or mathematical proofs. A key question that has not been definitively addressed by either the Formal Methods or MBD&V supplements is the obvious domain overlap that can occur between these supplements. That is, Formal Methods (FM) as a development and verification technology utilizes a form of model based development itself. This and other potential domain overlaps will be addressed by the FAA in circulars, which will be published this year.

Software tool qualification considerations

Qualification of a tool is needed when processes of DO-178C are eliminated, reduced, or automated by the use of a software tool without its output being verified as specified in the standard. The purpose of the tool qualification process is to ensure that the tool provides confidence at least equivalent to that of the process(es) eliminated, reduced, or automated.

The Software Tool Qualification Considerations document introduces a new tool qualification structure that consists of three criteria and five Tool Qualification Levels (TQLs) as shown in Table 1.

Table 1: The Software Tool Qualification Considerations document introduces a new tool qualification structure that consists of three criteria and five Tool Qualification Levels (TQLs).

(click graphic to zoom by 1.9x)

Criteria 1’s applicable TQL is the replacement for the development tool in DO-178B.
Criteria 2 is new for DO-178C and is intended to address the expansion of tool use in new methodologies. Criteria 2 basically requires an increased level of rigor over DO-178B criteria for tools used on software level A and B in order to increase the confidence in the use of the tool.
Criteria 3, which consists entirely of the level TQL-5, is the replacement for the verification tool in DO-178B.

To help safety-critical developers take full advantage of DO-178’s advanced capabilities, tools that automate and streamline the development, verification, and certification process have become essential. For example, DO-178C, section 11 introduces Trace Data, which it describes as reference links among life-cycle data items such as requirements, design, source code, and test cases. A key aspect of tools that automate life-cycle data traceability is a facility for establishing traceability forwards and backwards, from requirements down through the decomposition tree, onto the executable code and back again, including verification tasks.

Automated tools greatly reduce the time and cost associated with developing DO-178-compliant software. DO-178 certification, however, is still an expensive, time consuming, and arduous process. To help expedite this process for avionics equipment makers, some companies, such as DDC-I, offer Eclipse-based development tools and RTOS platforms that have already undergone DO-178B Level A certification, in addition to turnkey development and certification services for both DO-178B and DO-178C.

DO-178C simplifies avionics development

DO-178C marks a big step forward for developers of complex avionics software that must be certified to the highest levels of safety criticality. DO-178C simplifies the development process by embracing formal methods, high-level modeling, and object oriented techniques that enable designers to conceptualize and encapsulate their software at a higher level. It also streamlines the verification and certification process by providing two-way traceability that extends from the models and requirements to the executable code and back again. Together with automated tools, platforms, and certification services, DO-178C greatly clarifies the risk and potential means of reducing the costs associated with developing, certifying, and deploying complex safety-critical avionics software.

Tim King is the Technical Marketing Manager at DDC-I. He has more than 20 years of experience developing, certifying, and marketing commercial avionics software and RTOSs. Tim is a graduate of the University of Iowa and Arizona State University, where he earned Master’s degrees in Computer Science and Business Administration, respectively. He can be contacted at tking@ddci.com.

DDC-I 602-275-7172 www.ddci.com

Bill StClair is currently Director, US Operations for LDRA Technology in San Bruno, California and has more than 25 years in embedded software development and management. He has worked in the avionics, defense, space, communications, industrial controls, and commercial industries as a developer, verification engineer, manager, and company founder. He is an inventor of a patent-pending embedded requirements verification system. He can be contacted at bstclair@ldra-usa.com.

LDRA 650-583-8880 www.ldra.com

Flexibility required? – FMCs

Dr. Malachy Devlin, Forasach — Thu, 01 Mar 2012 15:00:00 +0000

Constantly changing requirements for I/O functionality can leave designers in a quandary, but VITA’s FPGA/reconfigurable device supportive FMC standard provides a remedy.

Perhaps one of the most challenging aspects of board design is in the area of I/O design and management; systems require digital I/O for USB, Ethernet, SATA, optical, and much more, plus the incredible number of analog to digital (ADC) and digital to analog (DAC) interfaces needed. Embedded computing systems rarely have a common subset of I/O needs because of the wide range of applications and markets covered; therefore, flexibility is demanded when it comes to I/O functionality on boards. Typically, this I/O functionality is in a fixed location on the computer board, or it was configured with mezzanine boards like PMC or XMC modules. These modules provide configurable I/O, but they use much of the carrier card area and incur, in some cases, unacceptable data overhead and system complexity because of the PCI or PCI Express bus interface between the host and the mezzanine.

A change in market requirements can typically lead to a change in I/O functionality, causing a difficult and expensive board respin to relocate connectors, change connector types, or add or delete functionality. Over the past two decades, designers have depended more heavily on FPGA technology to implement this I/O. FPGAs enable designers to create custom I/O or utilize libraries of off-the-shelf IP for USB, Ethernet, SATA, optical, and much more. Furthermore, FPGAs are used to “package up” the data for transfer over the mezzanine card connector, for example PCI. This helps with the cost of the host platforms, but it requires a substantial list of modules to be developed to achieve a highly robust product line and a wide range of technical knowledge to understand not only the external I/O but the mezzanine-to-host protocols as well.

Standing on the shoulders of giants

The leading FPGA suppliers, Xilinx and Altera, advocate the use of modular I/O as a front-end to their FPGAs and development kits.

Xilinx adopted the FPGA Mezzanine Card (FMC) standard, created within the VITA 57 working group, as their architectural foundation for a modular I/O capability for their development kits. FMC is a standard method focused on putting I/O devices on mezzanines connected to and directly controlled by FPGAs residing on a host or carrier card.

“FMC has rapidly become the de facto standard for daughtercards in the FPGA industry,” stated Raj Seelam, Sr. Marketing Manager, Platform Solutions at Xilinx. “We now have a thriving ecosystem in place for FMC that offers users a wide variety of I/O options to customize their designs. Our customers can use the same FMC with multiple generations of Xilinx FPGAs, which protects their R&D investments and accelerates their design cycles at the same time.”

Altera developed the High-Speed Mezzanine Card (HSMC) specification to standardize the interface of mezzanine cards to host boards. Altera and partners offer a variety of host platforms and mezzanine cards that comply with this specification. Altera is now creating development kits with FMC capabilities reinforcing the benefits of standardization.

The purpose of the FMC is to allow an FPGA on a host card to connect directly with the I/O devices on the mezzanine module – just as if the devices were on the host board. This intimacy means the interface can be optimal and removes the protocol “fat” and legacy shackles. Savings are made in design time, real estate, cost, and power, while maintaining maximum bandwidth with minimum latency. The FMC standard is described in ANSI/VITA 57.1 and defines a small form factor I/O mezzanine card that can be connected to most carrier board form factors. It assumes that FMCs connect to an FPGA device or other device with reconfigurable I/O capability.

The FMC standard is FPGA architecture independent and is designed to:

• Maximize data throughput (potential for more than 40 GBps

• Minimize latency (copper track delays only)

• Reduce FPGA design complexity (no additional protocol overheads)

• Minimize system cost (smaller FPGA real estate, fast design times)

• Reduce system overhead (reduced power and cooling needs)

The standard describes FMC I/O modules and introduces an electromechanical standard that creates an extremely low overhead bridge between front panel I/O on the mezzanine module and an FPGA processing device on the carrier card, which accepts the mezzanine module.

FMC takes a new approach on interface protocols by removing the need to inject protocol data into the raw data to be processed as what happens with a defined bus interface. It assumes that the FPGA has a unique closeness with the I/O mezzanine module. This enables the FMC standard to capitalize on the unique reconfigurable capability of FPGAs to process natively the raw data formats that the module sources and sinks. Rather than get into defining functionality for the pins, FMC simply defines the upper limit of connections for both parallel lines and multigigabit serial signals.

“The ability to place signals anywhere on [the] FMC is generally helpful,” according to Jim Mooney, Director of Sales and Marketing at Integre Technologies, LLC. “Having more signals available on the FMC than are used in the design allows for optimized spacing and routing of sensitive signals. You do have to be careful if the design demands that signal groups target the same I/O banks of the FPGA, as this can be different for each FMC carrier.” Since each design is different, a comparison of different mezzanine capabilities is shown in Table 1, courtesy of Curtiss-Wright Controls Defense Systems.

Table 1: A comparison of different mezzanine capabilities, data courtesy of Curtiss-Wright Controls Defense Systems

Rapid solutions

Businesses and engineers are measured on delivering results, rapidly. FMC provides a path to de-risking developments and opens up the availability of knowledge within the precipitously expanding FMC ecosystem.

“The FMC standard reduces design costs and time-to-market by bringing the benefits of modular design much closer to the FPGA user community,” commented Seelam.

“Designers find it easier to get something pre-built, particularly for higher-speed interfaces,” mentioned Dave Lautzenheiser, Faster Technology. “With all the standards out there, FMC makes it a lot easier for the system designer to build something, becoming a component choice at the board subsystem level. They can then focus on the application.” Because the modules are smaller and FPGA technology independent, they can be used with carrier or host cards in any size format.

Building either custom FMCs or carriers is further enabled through reference designs. Xilinx offers several reference designs for carriers, including complete schematics, Gerber files, and other tools needed to quickly layout a host carrier. “They can get something operational quickly so they can get started on the application,” stated Seelam. “With our release of the KC705 reference kit, we were able to launch with FMCs on day one; it took over a year to launch our first kit.” It is hard to tell if there is a trend to using reference designs or off-the-shelf carriers with FMCs, or integrating all the functionality into one board. To Seelam, it looks like the granularity of the FMC is about right for a building block style of system design.

Fast flexibility

Marc Couture, Director of Product Management, Microwave and Digital Solutions at Mercury Computer Systems, elaborated on what FMCs can typically do and where they are used, “FMCs tend to be used for higher data rate, multichannel I/O as opposed to lower data rate control applications. For example, a number of companies put Analog-to-Digital Converters (ADCs) and Digital-to-Analog Converters (DACs) on the FMCs to convert analog data and transfer the digitized data into embedded computers where it can be processed and then disseminated using the DACs. In this case, often more than one FMC is used reaching MHz and even GHz sampling rates. In addition, FMCs are used for high-speed digital I/O using some sort of Small Form-Factor Pluggable Transceiver (SFP) or quad SFP. For instance, an Unmanned Aerial Vehicle (UAV) with an imaging gimbal may support an Infrared (IR) camera for thermal imaging and an electro-optical camera that captures color images. The images are converted to 1s and 0s, streamed out through the fiber, and routed to an FMC on a processing board in an embedded computer. The FMC serves as the conduit into the FPGA, bringing in digitized imagery.”

FMCs are most commonly used in applications that have a need for very low-latency I/O. Getting the high-speed data quickly into an FPGA for processing and then turning it around as output without the need to transfer around the buses in a system has great advantages.

“The speed and number of connections that an FMC-format module uses, together with direct FPGA to I/O devices, mean that the FMC format is particularly suited to applications benefitting from multi-Gbyte per second I/O with low latency,” pointed out Jeremy Banks, Curtiss-Wright Controls Defense Solutions. “Examples of such applications are direct RF I/O, radar, Signals Intelligence (SIGINT), satellite communications, and Electronic Countermeasures (ECM).”

Mooney noted that he sees a lot of lab environment prototyping with the intent of migration to a full custom board. He believes that there is also a strong demand in vision markets, with a broad range from inspection to high-speed physics. Several of his customers are designing vision platforms using FMCs. The high-speed nature of FMC has made them an attractive method for interconnecting high-speed DSPs with FPGAs in some applications.

The work continues

There are complementary specifications to the ANSI/VITA 57.1 FMC specification. VITA 57.2 defines an “electronic datasheet” metadata standard to provide automated validation of FMC configurations and performance capability. In short, VITA 57.2 aids in determining the compatibility of various FMC products from different vendors before products are purchased. Furthermore, VITA 57.2 enables the automated creation of pin description files that can be loaded in FPGA design tools. VITA 57.3 defines the logic interfaces for firmware that resides in the carrier card FPGA that is used to communicate with the FMC mezzanine module, effectively providing a “device driver” layer. Both of these specifications are currently in development by the VITA 57 technical working group.

While FMCs can ease the pain of system development, using them is not without challenge. “Many system designers will ask which carriers to use with a specific FMC,” commented Lautzenheiser. “They want a level of assurance that they can get past the integration issues quickly, getting onto the challenge of working on their application software.”

Seelam agrees that compatibility is the biggest challenge: “With so much flexibility, there is an inherent increase in risk factor – Is this going to work with this or that card?”

An automated checker with tests that can look at voltage levels, connectivity, and other signals is something that appeals to Lautzenheiser. He also feels that there is something missing at the application level. Maybe it is an extension of the Dot 2 specification that gets into the application. Some way to quantify the functionality is needed; it is hard to test some FMC functionality because carriers may not support it, for instance, I/O bank assignments on the FPGA.

Lautzenheiser asks, “Is there a way to clearly and consistently define what the carrier can support?” A carrier with the high pin count option supports certain capabilities, high-speed pairs at a specified data rate, which may or may not be easy to match up to a compatible FMC. He feels that something is missing at the application layer, something that would package and deliver a known reference point, or a benchmark that can be demonstrated. He doesn’t know exactly how to do that, the physical level is covered in the VITA 57.2 work, but something above that is missing.

While “certification” is not something the ecosystem is willing to endorse, the idea of plugfests to test compatibility is very attractive. The FMC Marketing Alliance, an ecosystem of FMC and carrier suppliers, did host their first plugfest in June of 2011. Xilinx provided the facilities and test equipment, inviting suppliers to bring in both FMCs and carriers to conduct compatibility testing. The group learned a lot from the exercise and is looking forward to the next event scheduled for this summer.

“The pin assignment flexibility of the FMC standard benefits designers, but it can lead to a false sense of interoperability between boards with identical functionality. Every FMC board connection becomes unique, requiring new carrier FPGA pin assignments. Switching out FMC boards from different vendors may lead to resource conflicts. Developers need to keep in mind this is an application-specific mezzanine connection and not a bus interface meant for interoperability,” adds Mooney.

A flexible future

As with anything, even though FMCs are easily supporting the demands of current generations of FPGAs with lots of high-speed I/O and power, eventually what was an ample amount of bandwidth and number of pins will became inadequate and designers will want more of both. The interesting thing is that companies like National Semiconductor, which is now part of Texas Instruments, and other companies, came out with digitizers that sampled at 1 GHz. Now they are sampling at 5 and even 10 GHz. While the current revision of the VITA 57 FMC standard can handle these data rates, the standard needs to continually look forward to refresh and enhance the standard to satisfy the increasing capabilities of FPGAs and external I/O interfaces.

Couture believes that in the future, we will see an FMC 2.0 with more pins and/or with pins that can sustain higher digital bandwidths. An ecosystem has clearly been defined around FMCs, and there are engineers purchasing FMCs and using them in next-generation designs. “FMC 2.0, I believe will need to be faster and wider in terms of bandwidth that can be sent from the mezzanine card to the baseboard.”

“More serial paths will need to be defined,” according to Banks, “either through a more dense connector or redeploying parallel lines to serial.”

“Stacking multiple FMCs to gain more front panel space or creating an extended PCB with FMC connectors, making a wider FMC, is something that TechwaY is exploring,” mentioned Patrick Mechan, TechwaY. This does not impact the electrical specification as much as it presents some creative ways to get more I/O into the system.

The VITA Standards Organization’s FMC working group consists of a mix of FPGA, mechanical, board, and SW/IP suppliers that work together to develop the FMC specification. The effort has resulted in a specification that enables product developers to bring more complete solutions to customers and reduces their time to market.

Much more information on FMC is provided by the FMC Marketing Alliance. Visit www.VITA.com/FMC to learn more.

Dr. Malachy Devlin is the FMC Marketing Alliance Chair. His career spans more than two decades of technical, management, and board level experience in the embedded defense, signal processing, and high-performance computing markets. He operates internationally with a range of companies and is responsible for bringing a number of innovations to market. He is the working group chairperson of VITA 57 within the VITA Standards Organization and a board member of the OpenFPGA organization. Malachy holds a Bachelor’s degree and a PhD in Electronics from Strathclyde University and was awarded his MSc in Corporate Leadership from Napier University.

Mitigating undesired input beat frequencies in parallel DC-DC converter arrays

Kai Johnstad, Vicor Corporation — Mon, 20 Feb 2012 15:00:00 +0000

When an array of switching DC-DC converters is connected in parallel for higher power output, differences in operating frequencies result in undesired beat frequencies at the common input bus. The result is an unwanted increase in AC ripple currents circulating in the input sections of the converters. By using simple input filtering, the AC input ripple current can be significantly curtailed. DC-DC converters with higher fundamental switching frequencies (>1 MHz) permit the use of smaller filtering components, suiting systems where overall space and weight are at a premium.

While a single DC-DC converter is often a preferable solution, there are many instances when two or more converters are needed to meet a military system’s power capacity requirements. In such applications, an array of two or more DC-DC converters may be connected in parallel to generate the requisite power – and in other cases where an application needs to be robust, fault-tolerant or N+1 redundant power supplies are used to meet the capacity requirements.

In critical military applications where power supply failure can be catastrophic, fault-tolerant power supplies use N+1 similar converters to provide a very high level of reliability. Through redundancy, fault-tolerant systems ensure that there is at least one more module than the minimum required to carry the load in case of converter failure.

If the DC-DC converters in an array are operating off the same feed, they are typically collocated to gain the benefit of shared thermal and shielding features, while saving real estate. Although these converters may be of the same type, switching frequency mismatches will occur unless the DC-DC converters selected permit synchronization.

Because of slight variations or mismatches in nonsynchronous DC-DC converters operating in parallel off the same input bus voltage, there are small differences in operating frequencies of these converters. This difference in converter operating frequencies results in undesired beat frequencies in the input current to the array. As a result, the AC ripple current circulating in the input section of the converters is increased. While converters offering a synchronization method do avoid beat frequencies as there are no operating frequency mismatches, the choice of selecting converters off-the-shelf is restricted, which can lead to lower overall system efficiency and power density. By implementing simple input filters, the input ripple currents of an array of unsynchronized converters can be easily suppressed significantly, along with beat frequency components, allowing unsynchronized converters to be considered.

Beat frequencies in parallel arrays of DC-DC converters

To demonstrate this problem and the impact of input filtering, let us take a look at military power systems such as RF transmitters or microwave radio links, which require substantial power. For example, a system requiring 2.1 kW output power from a MIL-STD-704E supply connects eight 270 W bus converters in parallel to form a high-power DC-DC array. For simplicity, a scaled-down version – an array of two high-input voltage 270 W sine amplitude bus converters in parallel, providing a total output power of 540 W – will be used for measurement (Figure 1).

Figure 1: An array of two high-input voltage 270 W DC-DC converters in parallel with subsequent input filter inductors, L1 and L2, shown in green.

(click graphic to zoom by 1.9x)

Even though sine amplitude bus converters switch at fixed multi-MHz frequencies, part-to-part variations in members of this family result in each converter in the array operating at a slightly different switching frequency. The interaction between the switching noise of each DC-DC converter in the array creates the undesired beat frequencies, at multiples of the differences between the operating frequencies of the converters.

The impact of the undesired beat frequency is most notable in the ripple current circulating amongst the DC-DC converters of the array. The ripple currents of the switching frequencies add up to generate an amplitude modulation of the overall ripple current envelope of the converters. For instance, in the parallel DC-DC converter array described earlier and test setup depicted in Figure 1, a pair of interconnected bus converters with nominal switching frequency of 1.7 MHz might have actual switching frequencies of f1=1700 kHz, and f2=1702.7 kHz. The 2.7 kHz difference between the two means that the total input current will have a much lower frequency component to the apparent ripple.

During periods of time when the ripple amplitudes are highest, the copper losses in the interconnects wiring between the two converters in question are higher than they need to be: The circulating AC ripple current is not being used by the DC-DCs, but it is still flowing through conductors with finite resistance. High additive ripple currents can stress input bypassing capacitors as well, and system noise can be increased, depending on the board layout. In some cases these circulating currents can constructively interfere with sufficient amplitude to lead to an unpredictable behavior of the converters themselves, for example, erroneous detection of an overcurrent condition inside a module.

To practically demonstrate the problem of increased input ripple current and generation of low beat frequency components, a pair of high-voltage 270 W BCM bus converters is connected as a simple parallel array, as shown in Figure 2. For the initial measurement, the input inductors L1 and L2 are not included and there is no input filtering beyond the input bypass capacitors C1 and C2. Because of asynchronous switching of two modules in the array, the AC input ripple current frequencies are also different. With a common input and no inductive filtering, the AC ripple currents mix and generate ripple with modulated amplitude based on the lower beat frequency as discussed previously.

This array was built from two bus converters operating at 270 VIN and 45 VOUT. The nominal fundamental operating frequency for this converter model is 1.7 MHz, and again to start with, the filtering inductors shown in Figure 1 were not in the circuit. The input ripple current to one of the modules, shown in Figure 1, was measured. The time domain plot of the resulting performance is shown in Figure 2(a). For the bus converter array used in this measurement, the total input current was about 2.1 ADC for full-load operation.

Figure 2: The time domain scope plot (2a) shows that ripple current without the filter inductors is high (844 mA peak-to-peak). Plot (2b) shows ripple current is substantially curtailed (143 mA peak-to-peak) with filter inductors.

(click graphic to zoom by 1.9x)

Suppressing the beats

With fairly simple input filtering, the unwanted AC ripple currents circulating between unsynchronized converters in an array can be easily controlled. The input inductors, labeled L1 and L2 in Figure 1 are incorporated to serve as additional input filters. In this experimental setup, the inductors were 0.4 µH, and were placed in series with the +In leg of each bus converter in the array. The input inductors increase the impedance between the input stage of one converter and the other converters in the array at the switching frequency. In this case, the impedance of the inductors is roughly 4 Ω at the 1.7 MHz fundamental switching frequency of the bus converters. This impedance reduces the high frequency AC circulating currents in the system.

The resulting performance after the input inductors were added is shown in Figure 2(b).

The overall ripple amplitude is significantly reduced, with a corresponding reduction in the lower frequency modulation of the ripple current envelope. As a result, with input filter inductors, the amplitude of the input ripple current drops from 844 mA peak-to-peak to below 143 mA peak-to-peak.

Hence, it was observed that the circulating AC ripple current at the input of an array of nonsynchronized DC-DC converters can be substantially higher if no filtering is employed at the common input bus of this array of parallel converters. In fact, the AC ripple current can be substantial compared to the DC input current. However, by using simple input filtering, the AC input ripple can be significantly curtailed. Because V•IChip converters used in this example operate at higher fundamental switching frequencies (>1 MHz), smaller filtering components with lower losses were employed, compared to those required for lower switching frequency converters. This can be advantageous for systems where overall space, weight, and efficiency are at a premium.

Input filtering tames AC input ripple current

From the results depicted in Figure 2, it is obvious that input filtering plays an important role in significantly curbing the influence of beat frequencies in an array of switching DC-DC converters connected in parallel. Using simple input filter inductors, it is seen that the amplitude of the AC input ripple current in one of the bus converter modules – in an array of two high-input voltage 270 W DC-DC bus converters – was reduced by more than 80 percent.

Kai Johnstad is Sr. Product Marketing Manager, Transportation, Aerospace, and Defense Products, Vicor Corporation in Andover, Massachusetts, USA. Kai has more than 15 years of experience in the power electronics industry with 8 years in various product marketing roles for Vicor. He holds a BS in Engineering from the University of Illinois at Urbana-Champaign and an MBA from the University of San Francisco. Contact him at kjohnstad@vicorpower.com.

Vicor Corporation 800-735-6200 www.vicorpower.com

Innovations for the warfighter: Small, COTS-based, portable, and platform agnostic

John McHale, Editorial Director — Mon, 20 Feb 2012 15:00:00 +0000

Requirements for platform-independent, portable, cost-effective solutions that leverage commercial technology will drive innovation among designers of future military electronic systems.

During the next 5 to 10 years, the U.S. military will be forced to accomplish its missions with fewer resources as the U.S. Department of Defense (DoD) initiates major funding cuts. Major platforms will be cut or scaled back and new research and development dollars will also be hard to come by.

Designers of new military systems will need to not only be innovative in improving performance but in managing design costs.

Across the industry, system integrators and suppliers are already anticipating these needs by creating systems that are built with as much COTS technology as possible to save costs and shorten design cycles. They are also designing smaller, portable systems and components that can be used across multiple platforms, as that also saves money.

Let’s look at three examples of where the defense industry leveraged COTS technology in portable systems with small components that can work in air, land, and sea platforms: the Multi-Function Training Aid (MFTA) portable simulation system from Lockheed Martin Global Training and Logistics, the postage-stamp sized MicroGRAM GPS receiver from Rockwell Collins, and the MONAX 4G tactical cellular system from Lockheed Martin.

Portable simulators for any platform

In the world of training and simulation, engineers at Lockheed Martin have developed a portable simulator that can travel anywhere; be assembled in hours; be adapted for aircraft, ground vehicles, and naval vessels; and is completely designed with COTS technology.

“We can take the Multi-Function Training Aid (MFTA) to pilots wherever they are located to use as a refresher or [for] training on a new version of an aircraft software” says Chester Kennedy, Vice President of Engineering at Lockheed Martin Global Training and Logistics in Orlando. The MFTA takes only an hour or two to assemble on location, as opposed to trying to get a full-motion simulator out to different locations, he adds.

Figure 1: The portable Multi-Function Training Aid (MFTA) from Lockheed Martin leverages commercial gaming technology and can train pilots wherever they are located.

(click graphic to zoom by 1.9x)

“It does not replace the need for a full-motion simulator nor real flight time in an airplane,” Kennedy says. “However, we were able to take a tremendous percentage of the learning objectives and enable them for training in a more affordable way by simply being able to take the MFTA to different environments.”

U.S. Air Force Special Operations and C-130 aircrews are using it today to train their pilots. The fixed-wing aircraft community was the early adopter of the MFTA, but the system’s application potential is much broader than just aviation, Kennedy says.

“We can bring it out for a variety of airplanes, ground vehicle, and surface Navy applications,” Kennedy says. For the Navy demonstrations, the system has ship controls instead of avionics, he adds.

In a reduced funding atmosphere as the DoD is forced to accomplish its mission with fewer resources, there may be more demand for affordable solutions such as the MFTA, Kennedy says.

Largely because the system is a COTS solution, “We were able to turn around the MFTA from the first prototype request to delivery in six months,” Kennedy says. “The customer didn’t have a hard requirement, just a general need to fill gaps in the training pipeline.”

“For the C-130 configuration, we took the mission computer out of the C-130 cockpit and right into the MFTA,” Kennedy says. “However, the core software runs on a PC that you could buy at Best Buy.”

Not every system will use the mission computer of the flight platform, but every MFTA will have the simulation software running the system, which is the real game changer, Kennedy continues.

“The heart of the MFTA is the Flight Sim software we acquired as intellectual property from Microsoft,” Kennedy says. “It is the COTS kernel at the core of this solution. We put a lot of work at taking the gaming technology and bringing it a new level in realism and simulation to create the enhanced Prepar3D gaming kernel.”

Prepar3D gives “us affordability and the agility” to enable different platforms in the simulator through software without having to build an entirely new, expensive simulator for each application, he continues.

Simulating with a gaming environment fills a gap in the training path by enabling pilots to train while deployed instead of having to take the more expensive route of going off-station to a location that has a full-motion simulator, Kennedy explains. All the functionality and switches do exactly what they would do in an actual aircraft or vehicle, he adds.

“We’ve brought in capabilities that are much more important to a military customer than a gamer-built system would,” Kennedy says. “We built off the foundation Microsoft had that goes back to their flight simulator product. We then sell it commercially and, in an interesting twist on this, anyone can buy it – including our competitors.

“We decided to offer Prepar3D as a COTS product to encourage others to innovate on top of it,” he continues.

The user community can go out and look at it online and enhance it in a variety of ways such as by adding graphic plug-ins for a region of the country, modeling different parts of the globe in high fidelity, and adding weather modules or “aircraft instruments in any kind of airplane you can imagine,” Kennedy says.

“It is a very different business model from what Lockheed Martin has done in the past,” he continues. “However, it allows us to take the best of that development and incorporate it into our product.”

Much like an iPad, it is all about the applications or apps that users create in the open development environment, Kennedy says. “I love my iPad, but wouldn’t love it if it weren’t for the apps or if the apps only came from Apple. It’s the beauty of seeing one app developed, then seeing how I or others can extend it.”

Visit www.prepar3d.com to buy the software and download development kits to create add-ons to the system such as instruments, buildings, and so on.

One GPS for you and your UAV

In the spirit of platform agnosticism, engineers at Rockwell Collins located in Cedar Rapids, IA, funded their own development of a miniature Global Positioning System (GPS) smaller than a postage stamp that can fit underneath a small Unmanned Aerial Vehicle (UAV) or be attached to a soldier’s radio.

The MicroGRAM GPS receiver (Figure 2) is a 90 percent reduction in size and an 85 percent reduction in weight from its predecessor, the Miniature Precision Lightweight GPS Receiver Engine SAASM (MPE-S Type I), says Trevor Overton, Program Manager for Surface Embedded and the MicroGRAM at Rockwell Collins. The MicroGRAM has already been provided to AeroVironment for a small UAV application, he adds.

Figure 2: The MicroGRAM GPS receiver from Rockwell Collins can be used on a small UAV, a tactical radio, and even a rifle site.

(click graphic to zoom by 1.8x)

“This technology falls into the DoD’s philosophy of combining capabilities into platforms,” Overton continues. “In this case, putting GPS into radios, combining navigation and communications into one device. “

In addition to unmanned systems, “We’ve been talking to several different user communities about potential applications for the MicroGRAM such as rifle mounts, mortar computers, laser range finder devices, as well as the large community of reconnaissance and unmanned aircraft.” Its weight, small size, and low power also make it useful for a large number of radios.

A radio manufacturer is currently interested in the MicroGRAM concept and is getting ready to test it out, Overton notes. However, “We do not have the MicroGRAM on the Rifleman radio,” which is part of the Joint Tactical Radio System (JTRS) program. “We are trying to get on that platform, though,” he adds.

Inside the DoD, there was a real need for a small, secure GPS receiver, Overton says. The alternative was to purchase a commercial GPS receiver for the task, but the main problem with commercial devices is that they are not secure, as they do not have Selective Availability Anti-Spoofing Module (SAASM) capability, Overton continues.

The result was the MicroGRAM GPS receiver, which not only has SAASM capability, but it is secure at the die level as well, he says. The chip inside the receiver meets NSA anti-tamper requirements for any probing that might occur by an enemy agent, Overton adds.

Its design combines the functionality of six ASICs into one, which eliminates die-to-die communication signaling by using only one single die, which cuts down on tampering risk, Overton says.

At the moment, ASICs also are better than FPGAs as FPGAs are not quite as small as they need to be for this application and they still consume more power than is optimal, Overton says.

Smaller and smaller designs are the overriding theme throughout the DoD, Overton says. Requirements are demanding smaller, lighter electronics that consume less power while adding more capability, he adds.

The MicroGRAM is engineered to be low power – as low as four tenths of a watt, Overton says.

“We are definitely looking at even greater size reduction in the future,” Overton says. Size reduction is a never-ending struggle in the embedded community.

Secure smartphones and a tactical app store

Future military outposts will have their own private network with its own app store, enabling U.S. and allied personnel to access a tactical app store with iPads or commercial smartphones, depending on their security clearance level.

Engineers at Lockheed Martin are designing a portable system that integrates the capabilities of these commercial products into a secure solution for warfighters called MONAX (Figure 3).

Figure 3: MONAX is a secure 4G wireless network that enables warfighters to use commercial smartphone and tablet technology to manage their missions.

(click graphic to zoom by 1.9x)

MONAX is basically a 4G tactical cellular system, but one that functions within a private, secure network, explains David Weber, Business Development Manager at Lockheed Martin in Philadelphia. Essentially, the network can be set up in places where there are no cell towers and, within hours, a private, secure cellular network is operational.

The system consists of a portable MONAX Lynx sleeve that connects off-the-shelf touch-screen smartphones to a MONAX XG Base Station infrastructure located on the ground or on airborne platforms, says a Lockheed Martin MONAX brochure. The MONAX interface uses a secure RF Link with exportable encryption.

“MONAX is device agnostic,” Weber says. Warfighters can use an iPad or commercially available smartphone like an Android for voice, video, and data transmission, but to connect to the MONAX network will require having the proper security protocols, he adds.

For example, U.S. Marines and NATO personnel can all bring their own unique smartphones and still access the network if they have the proper clearance, Weber continues. Once connected, their device will access a VPN tunnel that is encrypted, he adds.

Just as iPad users go to an app store for personal and business uses, MONAX users will also have access to a secure, tactical app store that is available 24 hours a day, 7 days a week, Weber says. The apps, which could be tactical maps or other mission-specific information, are developed for or rehosted on a smartphone, then approved for and made available to warfighters in the app store, he adds.

“MONAX uses a layered approach to security, but another reason it is secure is that we use nonstandard commercial frequencies,” Weber says.

The solution has a mobile device management feature, which enables users to set secure access policies, Weber says. For example, if the Marines want NATO allies to only have access to a certain level, they can set policy and push it out to the phones, he continues. MONAX also can be set to give different security access based on rank, with a general having access that lance corporals would not, Weber adds.

The MONAX network is capable of interfacing with tactical radios like devices within the Joint Tactical Radio System (JTRS), Weber says. Radio users would just have to enter the VPN tunnel, he adds.

MONAX was just made available for sale this year and is not being used in the theater yet, but is being evaluated in different exercises, Weber says. The Marines have tried it out already and found it very user intuitive, he adds.

Robots in the military: Brave, autonomous, and dispensable warriors

Jim Davis, Cypress Semiconductor — Mon, 20 Feb 2012 15:00:00 +0000

The airspace in today’s military conflicts is filled with Unmanned Aerial Vehicles of all sizes – from the hand-launched vehicles of the Special Forces to the jet-powered Predator drones flown by airmen
thousands of miles away from the conflict area. On the ground are autonomous and wirelessly controlled
robotic vehicles for everything from high-risk patrols to explosive ordnance detonation and disarming. These robotic vehicles support a variety of military missions ranging from covert intelligence gathering to direct support to ground forces and overt military strikes. And this is just scratching the surface of what is moving autonomously on the battlefield. System-on-Chip (SoC) advances finetune mixed-signal designs, enabling reduced power consumption and expense.

The use of robots in war dates back as early as World War II with the German Goliath remote-controlled explosive vehicles and the Soviet’s wirelessly controlled, unmanned Teletanks. Today, the military robotic force also saves lives. As designers and engineers of robotic systems and components might or might not even know, they are playing a large part in enabling these and future systems. Developing these systems, however, is not a trivial task. Robotic systems, in their most basic form, simulate or otherwise artificially sense their environment and, through programmed logic, respond and interact with their surroundings. As far as complex embedded systems go, they are the ultimate mix of analog sensing, driving and digital logic, processing, and communications. While mixed-signal design is not a new concept, state-of-the-art advances in the fundamental components that make up these designs – including Systems-on-Chip (SoCs) – provide ways to implement robotic subsystems easier with lower power requirements and at greatly reduced cost.

Sensing technology for robotics

Interactions with the real world are inherently analog. A robotic system’s ability to not only accurately sense its surroundings but to do so with high resolution provides the system a stream of data inputs to more effectively enable correct decision making and response. For example, to enable a robotic sentry to effectively protect a perimeter, the system must be able to monitor and detect movement – be it through sight, sound, or touch. Through the use of a combination of high-precision thermal, IR, ultrasonic, and/or optic analog sensors, the raw input of what the robot can see can be streamed into a programmable movement detection algorithm to measure the change between snapshots and processed for the decision-making process – effectively an analog-to-digital conversion. The response itself is also an analog process (that is, a robot interacting with its environment requires movement, motors, and motor control), effectively a digital-to-analog conversion.

The brain of the robotic system lies within the digital domain. Based on the converted analog signals, the preprogrammed logical steps of responding to those signals are carried out by the robotic brain and/or externally communicated commands to the robot. For example, in a robotic sentry, after the detection algorithm feeds an alert to this brain, a series of preprogrammed logical functions is executed to steadily increase the robot’s overall alertness state. This is done by executing intimidation actions to thwart the intruder into retreating via floodlights, verbal warnings, and so on.

Historically, designs engineered for systems like a robotic sentry required sensors, costly analog discrete ADCs, amplifiers, highly accurate voltage references, DACs, PWMs, and multiple processors and microcontrollers. These are the components that make up the individual sense-detect-decide-respond-report subsystem – just one of many functions for which a robotic sentry would be responsible. The challenge in implementing just this one function is the selection of the right analog discrete components (ADCs, amps, Vrefs, DACs, and so on) designed for or compatible with the selected high-precision sensors. It can also be difficult to choose the digital components, processors, and even potentially the custom logic gates to build the alarm-level state machine to enable the appropriate decision and response. Not only is this a complicated and challenging task, but should any part of this require redefinition – perhaps swapping a sensor, adding additional sensors, adding additional response mechanisms, and so on – the same complicated task must be repeated all over again. Finally, the large number of discrete components also quickly adds up in total subsystem BOM cost and increases power requirements, doubly impacting the system because of the number of components.

Mixed-signal SoCs are key

Considering the aforementioned challenges in building a robotic system, the good news is that mixed-signal programmable SoC architectures and software tools can ease robotic design burdens. Through the integration of an analog, digital, logic, and processing core into a single mixed-signal device, designers can realize system cost savings while greatly improving the power budget. Systems-level programmability in both the analog and digital domains in these types of devices also eases the often difficult and time-consuming analog design process; these devices also provide the ability to rapidly prototype, test and, without even having to relayout designs, change and incrementally update the design along the way. For example, with systems-level programmability, tools designed at this level of design present developers with a method for defining the signal chain in a mixed-signal device and the ability to modify any part of that same signal flow as the design progresses. In this way, it becomes possible to define the signal path and configure the components at the system level via the ADC itself, using parameters such as desired resolution, sample rates, voltage reference sources, and so on. All this can be done without having to consult an analog component data book when using, for example, Cypress’s PSoC architecture and software tool, PSoC Creator (Figure 1).

Figure 1: Mixed-signal programmable SoC software generates an ADC based on parameters such as desired resolution, sample rate, and voltage reference source.

(click graphic to zoom by 1.9x)

The PSoC Creator dialog shown in Figure 1 generates an ADC based on parameters such as desired resolution, sample rate, and voltage reference source. If there are significant changes in system requirements, developers can accommodate them without any hardware modifications by adjusting these parameters and rebuilding the system application.

Mixed-signal SoC tech helps robots save the day

The military robot is a brave and autonomous warrior, and unlike its human counterpart on the battlefield, can be a dispensable asset that protects those it serves. Through the use of state-of-the-art, programmable mixed-signal SoC architectures and software, engineers can further evolve these robotic warriors with greater ease within power/cost budgets, freeing designers to apply more time and effort on the things that matter most: the robot’s core mission.

Jim Davis is Product Marketing Manager for Programmable System-on-Chip (PSoC) products at Cypress Semiconductor. He joined Cypress in 2008 and prior to that served eight years in the U.S. Air Force as a Communications Officer. He has a Bachelor’s degree in Computer Science from the U.S. Air Force Academy and a Master’s degree in Software Engineering from the University of Maryland. He can be contacted at jfmd@cypress.com.

Cypress Semiconductor www.cypress.com

Radar signal processing upgrades use embedded COTS hardware

John McHale, Editorial Director — Mon, 20 Feb 2012 15:00:00 +0000

Military radar designers are turning more and more toward Commercial Off-the-Shelf (COTS) signal processing solutions to modernize existing radar systems. (Photo courtesy of Lockheed Martin)

The capabilities of modern radio detection and ranging systems, better known as radar systems, are light-years ahead of where they were when radar was invented in the World War II era.

There are so many different slices and flavors of radar now, and the technology available today versus 5 or 10 years ago is night and day in terms of performance, says Rodger Hosking, Vice President of Pentek in Upper Saddle River, NJ. Radar system requirements coming out of the DoD put a tremendous demand on signal processing solutions that not only deliver compute performance, but that must be rugged and low power, he adds.

A major source for the ruggedization demands are Unmanned Aerial Vehicles (UAVs) that perform Intelligence, Surveillance, and Reconnaissance (ISR), Hosking says. The UAVS, which continue to increase in number, need rugged, light radar payloads with unique small form factor configurations that can operate in hazardous environments, he adds. Military customers also are interested in generating stealthy radar pulses that are difficult for an enemy to defeat, Hosking says.

The military wants higher and higher performance to be able to track multiple targets simultaneously and track every signal coming in, says Anne Mascarin, Solutions Marketing Manager at Mercury Computer Systems.

Turning to COTS

Because of performance requirements and the expectation of reduced funding, system integrators are looking to outsource radar signal processing tasks to COTS suppliers, says Jane Donaldson, President of Annapolis Microsystems in Annapolis, MD. Integrators are essentially wanting to do more with less, she says.

Where in the past they would use internal resources to develop signal processing boards, they will be forced to outsource because of lack of funding and possibly workforce reductions as well, she explains. Military system integrators also will want to use open architecture designs based on commercial standards as they are more cost-effective in the long run and easier to upgrade, Donaldson says.

The open standards tie so much to the spiral upgrade strategy the DoD uses, where there must be open standards or the spiral upgrade will not work, says Tom Roberts, Solutions Marketing Manager at Mercury Computer Systems.

System integrators want an open architecture at the board and chassis levels so they can actually plan out lower-cost technology insertions, says Eran Strod, Systems Architect at Curtiss-Wright Controls Defense Solutions in Ashburn, VA.

Advantage of GPPs and FPGAs

Two key enabling signal processing technologies for radar are the performance capabilities of General Purpose Processors (GPPs) such as Intel’s Core i7 family and the growing capability of FPGAs.

COTS GPPs are still the main processing tool for radar systems, and that probably will not change any time soon as Intel is continuing to make inroads into this space with high-performance processors such as the Core i7, says Doug Patterson, VP of Business Development for Aitech in Chatsworth, CA. The extra processing power is essential for new radar applications such as some K-band multimode radars that do not emit signals an enemy could detect, he adds. For more information on Aitech signal processing systems, visit www.aitech.com.

FPGAs and GPPs are not virtually exclusive either; new radar designs are making use of both components to meet substantial processing demands of modern radar systems.

There is a need to have the FPGA and GPP work together, Pentek’s Hosking says. The FPGA is good for doing parallel operations very quickly, but is not good at sophisticated analytical type tasks, which is where a GPP comes in, he adds. For more on Pentek’s FPGA signal processing products, visit www.pentek.com.

“We see virtually every radar program using a mix of general purpose processors and FPGAs in radar systems,” Roberts says.

FPGAs are phenomenally good at dealing with the problem of power, as they are only tuned to do what you want them to do, Jeff Milrod, President and CEO of BittWare in Concord, NH, says. They also are better at doing data independent processing where you do the same thing every time, he adds.

FPGAs are good at taking data and filtering it and sending it out to other processors that do a better job of interrogating data, Curtiss-Wright’s Strod says.

Many FPGAs also have digital signal processors built into them as cores, which enables designers to pack more processing capability into an even smaller footprint, says Ian Stalker, Product Manager at Curtiss-Wright Controls Defense Solutions. For more on Curtiss-Wright’s signal processing and FPGA solutions, visit www.cwcembedded.com.

The major drawback with FPGAs is the difficulty in programming them with VHDL. It is harder, more expensive, and more time consuming than programming in C or C++, Donaldson says. Also, there are fewer VHDL programmers than C programmers, she adds. With the DoD cutting back funding, military radar designers will want to find more cost-effective alternatives to VHDL for programming FPGAs, Donaldson continues. “Annapolis offers a product called CoreFire, which enables engineers to program FPGA boards very quickly and get them completed much faster.”

BittWare also has a new solution aimed at cutting down on FPGA development time (see sidebar on page 35).

The Annapolis CoreFire is a data flow-based tool that eases FPGA design by allowing developers to automatically generate intermodule control fabrics and use a drag-and-drop graphical interface. The tool also has hardware-in-the-loop debugging and can easily port completed applications to new technology chips and boards, according to the Annapolis website at www.annapmicro.com.

FPGAs key in Air Force long-range surveillance radar upgrade

Engineers at Lockheed Martin in Syracuse, NY combined GPP and FPGAs and programmed their FPGA board with the Annapolis CoreFire tool for an upgrade of 29 U.S. Air Force AN/FPS-117 long-range surveillance radars – 15 in Alaska, 11 in Canada, and one a piece in Hawaii, Puerto Rico, and Utah. The radar system makes up the Air Force’s Atmospheric Early Warning System.

The upgrade program, dubbed the Essential Parts Replacement Program (EPRP), has Lockheed Martin engineers replacing and updating all the radars’ data and signal processors to state-of-the-art commercial technology to help extend their operational lives through 2025, Chris Atherton, Technical Director for Long Range Radar at Lockheed Martin, says. The radar site’s secondary surveillance radar, which is used for air traffic control purposes, will also be modernized.

This is not a capability upgrade for the Air Force, but more an effort to “sustain existing missions in a better, faster, cheaper manner,” Atherton says. The mission of this radar system has not substantially changed even with the upgrade, he continues. It is an air defense early warning radar system covering the periphery of Alaska and northern Canada with its main customers being the Federal Aviation Administration (FAA) and the North American Aerospace Defense Command (NORAD), Atherton adds.

“We have an open architecture approach to L-Band radars that enables technology refresh long-term for sustaining a fleet of more than 175 radar systems,” he says. At the design level, the goal is to not only decrease failures but to decrease the Mean-Time Between Failures (MBTF) too, he adds.

The older system was not an open architecture, by any means. “We literally made our own computers that used a digital data processor, a memory board, and our own operating system to handle the demands for radar signal processing.

Sidebar 1: The Patriot Air and Missile Defense Systemճ radar for Taiwan and Saudi Arabia uses OpenVPX technology from Mercury Computer Systems.

(click graphic to zoom)

Sidebar 2

(click graphic to zoom)

With this upgrade, “We replaced five cabinets measuring 6 feet by 3 feet by 3 feet that were completely filled with homemade electronics” with 15 COTS cards with “substantial commercial processing capability,” Atherton says. “We used COTS technology wherever possible, as it was the easiest and least expensive way of supporting the system over the next 15 years. The processing is done via an Oracle Sun Netra 5220 server – which has an UltraSPARC T2 processor – and a 10 Gigabit Ethernet interface is used to move the radar data, Atherton says. The Oracle devices have plenty of horsepower and are very efficient parallel machines, he continues. The operating system is Solaris, Atherton adds.

“We also used a Wildfire FPGA board from Annapolis Microsystems that uses their CoreFire FPGA development tool” to program the boards to do the digitization and digital filtering inside the radar system, Atherton continues. “They’ve taken what was a row of cabinets of electronics and fit it all onto a 6U VME board.

Thanks to CoreFire, “We were able to use the same software folks [who] worked on the GPP on the FPGA, instead of having to employ a VHDL specialist,” Atherton says. “This also gives us advantages for when we migrate to the next generations of their board.”

Power electronics designs trending smaller and more efficient

John McHale, Editorial Director — Thu, 16 Feb 2012 15:00:00 +0000

Designers of power electronics components for the military market say business is steady, but they continue to be challenged to increase efficiencies while simultaneously shrinking component size. Meanwhile, in the space arena there is a move toward digital devices.

Procurement strategies in the defense world are embracing more open architectures and a greater use of COTS designs in new electronic systems and legacy upgrades. New Department of Defense (DoD) program requirements are also pushing for lower Size, Weight, Power, and Cost or SWaP-C.

Designing low-power systems is trickier than ever as military systems integrate high-energy commercial processors and components.

“Managing power is not a glamorous endeavor, but is essential as military electronics designers continue to add capability to platforms not originally designed to handle the energy that modern electronics expend,” says Bud Jewett, Director of Business Development and Company Relationships at Crane Aerospace & Electronics in Lynnwood, WA. “Every design is unique with unique requirements for packaging, size, and weight.

“Military customers are looking for smaller, lighter, more efficient power devices with a lower total cost of ownership,” Jewett continues.

There is a push from DoD customers for higher efficiency as well as a requirement for wider input voltage ranges and smaller sizes, says Kai Johnstad, Product Marketing Manager for Vicor in Andover, MA. “The usual things,” he adds.

On the application side, the big push is toward unmanned systems, Johnstad continues. In the unmanned market, the demand for smaller power supplies is quite strong as platforms such as small Unmanned Aerial Vehicles (UAVs) continue to shrink, requiring unique size requirements for electronic components, he adds.

“More efficient power supplies also are going to be necessary for high energy producing applications such as high-powered jammers for long-range communications and directed energy weapons,” Jewett says.

Custom versus COTS

“Many of the capability upgrades for existing military systems require unique size and weight considerations, which creates opportunities for designers of custom power solutions such as Crane,” Jewett says. “The various form factor and weight requirements are not conducive to an off-the-shelf, one-size-fits-all solution.”

Regarding custom versus COTS, a lot of those decisions depend on the expertise and comfort level of the customer, says Vicor’s Johnstad. The primes have more expertise in design and will typically purchase modules they can design into their systems.

Weight can be just as important as form factor, because many platforms have weight thresholds that cannot be exceeded, Jewett says. Meeting these requirements is challenging because military designs often do not factor in the power conversion considerations until later in the design process, he adds.

In an ideal world, the power design of a system would be laid out first, but that does not happen. Therefore, more customization is needed. If it is done at the last minute, designs become limited as to how much power can be saved.

Whether or not a customer needs a more complicated custom design or a COTS solution really depends on the expertise of the in-house system integrator, Johnstad says.

Many times, customization consists of ruggedizing brick-based designs, Johnstad says.

For more on custom designs by Crane and Vicor, visit at www.craneae.com and www.vicorpower.com.

A COTS product offered by Vicor is the MIL-COTS VI BRICK filter as a compact DC front-end module, either as stand-alone or integrated with the 28 V MIL-COTS PRM, which provides EMI filtering and transient protection, according to a Vicor release (Figure 1). The device meets conducted emission/conducted susceptibility per MIL-STD-461E and input transient surges per MIL-STD-704 or MIL-STD-1275.

Figure 1: The Vicor MIL-COTS VI BRICK filter is a compact DC front-end module that can function as either a stand-alone device or be integrated with the company’s 28 V MIL-COTS PRM.

(click graphic to zoom by 1.8x)

Also on the COTS side, engineers at VPT Inc. released a new DC-DC converter for use in commercial avionics, military avionics, and other high-reliability power systems. The DVAB Series eliminates cross-regulation errors and has tightly controlled line and load regulation errors enabled by the use of two independent control loops, according to a company release.

VPT’s avionics “customers demand long-term reliability with extremely tight performance metrics,” says Michael J. Bosmann, Senior VP of VPT. For more information, visit www.vpt-inc.com.

Emerson Network Power’s rugged small digital control devices are also getting design wins in commercial avionics and in-flight entertainment systems, says Shreek Raivadera, Marketing Communications manager at Emerson Network Power in Leicester, U.K. The IFE systems generate a phenomenal amount of power, he adds.

Emerson mostly focuses on the commercial market, but is looking to expand in the military and sees these devices as ideal for military applications such as radar and sonar as well as ground-based Command, Control, Communications, Computers, Intelligence Surveillance, and Reconnaissance (C4ISR) applications, Raivadera continues. The products have yet to go through an official mil-standard testing process, but internal testing shows they can handle the extreme requirements, Raivadera says. For more information, visit www.emersonnetworkpower.com.

Power electronics for space

Smaller size and lower weight requirements are also driving designs of power integrated circuits for space. Designers in this market segment also are seeing greater demand for digitization and standardization across different platforms.

The most common trends in the military space market are standardization, TOR compliance, improved performance, and increased demand for digital devices, says Fred Farris, Vice President of Sales and Marketing for International Rectifier’s (IR’s) HiRel Products in El Segundo, CA.

“Customers are interested in standardizing across platforms and payloads to reduce development time and cost, and this standardization is being flowed down to components and power supplies they purchase,” Farris says.

Regarding TOR compliance, Farris says, “Many if not most of the military space programs today are requiring compliance to the TOR – reliability requirements for government space contracts that involve design, development, and test of spacecraft bus, payload, and launch vehicles.

The demand for digital devices also “is expected to climb as the needs for digital and signal processors onboard a spacecraft continue to rise,” he continues. “Other performance trends see bus voltages continuing to increase while efficiency demands on power electronics increase as well.”

One of International Rectifier’s latest digital space power products is the GH Series of radiation-hardened (rad-hard) DC-DC converters (Figure 2). These devices are designed for onboard spacecraft applications with a mission life as long as 15 years. The series is targeted for designs that use new digital signal processors and FPGA technologies that require a supply voltage as low as 1.0 V. Other features include 18 V to 40 V input range, a Total Ionization Dose (TID) of more than 100 kilorads, and a weight of less than 110 g, according to an IR release. For more information, visit www.irf.com.

Sidebar 1: Thales UK is using the DDC 16-Channel Programmable Solid-State Power Controllers (SSPCs) for the UK Ministry of Defenseճ new Foxhound Light Protected Patrol Vehicle (LPPV).

(click graphic to zoom)

Figure 2: The GH Series of radiation-hardened (rad-hard) DC-DC converters from International Rectifier is designed for onboard spacecraft applications with a mission life as long as 15 years.

(click graphic to zoom by 1.9x)

VPX power solutions in demand

Board designers continue to see more requirements for ruggedization of power components and are also seeing more demand for VPX-related power supplies.

Over the past several years, there has been a demand for 3U CompactPCI power supplies, says Lou Garofolo, Product Manager at the Power Supply division of North Atlantic Industries in Bohemia, NY. North Atlantic has addressed this demand with their 55LQ and 55MQ product lines. “Most recently, we have seen the trend toward higher-density VPX power supplies that are designed per VITA standards – such as form factor, pinouts, and signaling. We are addressing this through our line of 3U and 6U VPX products with either DC or AC inputs.”

“In the military, conduction-cooled power supply market, our customers are typically looking for fully integrated power solutions that include built-in EMI filtering and input transient protection, which require output power ride-through during severe input power transients that take place on military platforms,” Garofolo says. “Today’s smaller, lighter systems require high-efficiency power supplies in the highest power density possible.”

Another trend Garofolo says he sees is for “intelligent power supplies, which can either report status through discrete signals or through detailed reporting via communication buses such as I2C. Common requirements are for monitoring and/or reporting of input status, output voltage, output current, and temperature monitoring/shutdown. Along with intelligence, there are very often requirements for features such as inhibit/enable, current share, and holdup time.

North Atlantic’s VPX product is the VPX55-3 (Figure 3), a high power density 3U VPX power supply with a +28 Vdc input and 6 outputs (per VPX) at a total output power of 300 W. The conduction-cooled device meets MIL-STD 461 EMI requirements when used with additional system filtering. For more information, visit www.naii.com.

Figure 3: The VPX55-3 from North Atlantic Indus-tries is a high power density 3U VPX power supply with a +28 Vdc input and six outputs (per VPX) at a total output power of 300 W.

(click graphic to zoom by 1.9x)

Sidebar 2

(click graphic to zoom by 1.8x)

Microcontroller market and design dynamics – Q&A with Gaute Myklebust, VP of MCU Product Planning, Atmel

Gaute Myklebust, Atmel — Wed, 15 Feb 2012 15:00:00 +0000

The microcontroller market is continuing to expand year after year, boosted by demands for embedded control in popular applications such as smartphones and smart energy systems. Taking a big picture perspective, Gaute highlights important factors influencing microcontroller development today and in the future.

ECD: In which market segment do you foresee the fastest growth for microcontroller-based products?

MYKLEBUST: Capacitive touch-screen controllers with cellular phones are the largest application driver right now. Capacitive touch screens have become the technology of choice for smartphones and are also working their way into feature phones, replacing resistive touch screens and increasing the penetration rate of touch-enabled phones.

ECD: What new microcontroller technologies are available to meet the growing customer demand for extremely small, low-power embedded devices?

MYKLEBUST: Migration to more advanced technology nodes drives both lower active power consumption and smaller form factor. However, this migration also poses a challenge for static power consumption. Many applications are battery-powered, and some require several years of battery lifetime. For these applications, static power consumption is the most important factor for overall power use. To address this, numerous sophisticated techniques have been developed, including back-biased memories and a magnitude of power domains with an associated power management system.

ECD: Software development is a huge portion of each new embedded development project. What software tools, libraries, and educational materials does Atmel offer developers?

MYKLEBUST: This has always been a focus area for Atmel. Our development environment includes full-chip cycle-correct simulation models and on-chip debug modules, which serve as the base platform for software development. In addition, we offer the Atmel Software Framework (Figure 1), which is a comprehensive set of software modules our customers can use in their development.

Figure 1: The Atmel Software Framework offers hardware abstraction layers that help ease migration between microcontrollers.

(click graphic to zoom by 1.9x)

The software framework consists of low-level device drivers, software stacks, and drivers for external devices. Hardware abstraction layers simplify migration between microcontrollers, and a carefully designed API makes it easy to integrate software components with a third-party Real-Time Operating System (RTOS). We provide a number of different ways to educate those who use our microcontrollers, including data sheets, application notes, discussion forums, direct customer support, webinars, road shows, videos, and e-learning courses, as well as the Atmel Technology Live developer conference coming up this fall.

ECD: With cloud computing and connectivity dominating embedded designs, what security precautions are available to prevent unauthorized access?

MYKLEBUST: Companies are usually very protective about their software. We’re seeing that customers who have software as their main asset are currently reluctant to use cloud storage for their projects and rely on closed network repositories and version control. It is important that the development environment itself is safe and protected so that code projects cannot be downloaded by any backdoor through online Integrated Development Environments (IDEs).

ECD: What radio frequency elements are available with Atmel microcontrollers, and what are the most popular applications?

MYKLEBUST: We are engaged in multiple areas with respect to RF. For example, Atmel has a wide offering of stand-alone transceivers and System-on-Chip (SoC) devices based on the IEEE 802.15.4/ZigBee standard. Application areas include smart energy, lighting, and remote keyless entry/access control. With Atmel’s wide microcontroller portfolio, our devices are often used alongside radio transmitters, even in areas where we do not provide a radio offering.

Gaute Myklebust serves as VP for MCU product planning at Atmel Corporation, where he is responsible for defining microcontroller products and technology platforms. He has been working with microcontroller architectures and products at Atmel for 16 years. Gaute holds an MSc in Computer Science and a PhD in Computer Architecture from the Norwegian University of Science and Technology.

Atmel
Facebook: www.fb.com/AtmelCorporation
Linkedin: www.linkedin.com/company/atmel-corporation
Twitter: @Atmel
www.atmel.com

Managing network traffic flow for multicore x86 processors at 40/100G

Rolf Neugebauer, Netronome Systems, Inc. — Tue, 07 Feb 2012 15:00:00 +0000

Part 2 in a 2-part series: Embedded systems migrating to 40G today and 100G in the next few years demand an intelligent in-line preprocessor capable of handling traffic at this high line rate, while communicating with the x86 CPU subsystem over a high-performance, virtualized PCI Express interface. Part 1 in this series examined the challenges of processing network traffic at 100G and some of the commercially available solutions attempting to solve such challenges. Part 2 highlights the need for a coprocessor that is tightly coupled to a multicore x86 CPU and can manage functions such as intelligent L2/L3 switching, flow classification, in-line security processing, virtualization, and load balancing for x86 CPU cores and virtual machines.

To keep pace with the explosion of traffic in the enterprise and carrier network, embedded designers have tried a variety of methods to meet the demand for 100G secure communication, including embedding hardware accelerators into multicore processors or using devices such as network processors, Ethernet switches, or Ethernet controllers. These approaches each come with their own drawbacks that limit performance and increase complexity. Furthermore, attempts to use a single-chip heterogeneous multicore processor to bypass performance issues have led to proprietary architectures that are not operating system friendly.

A high-performance multicore heterogeneous architecture builds on a single-chip multicore heterogeneous processor, but divides the solution into two processors: a general-purpose multicore x86 CPU focused on application and control plane processing and a separate in-line multicore coprocessor focused on L2-L4 processing and accelerating L4-L7 applications. The key to this architecture is having a tightly coupled interface between the two processors that is in-line, secure, virtualized, and high-performance (see Figure 1). A good analogy here is the use of a graphics processor unit alongside a multicore x86 processor in workstations and other graphics-intensive servers.

Figure 1: In a multicore heterogeneous architecture, an external coprocessor integrates all of the hardware acceleration functions to optimize power and performance.

(click graphic to zoom)

Efficient processing and memory utilization

The coprocessor needs to access packets, forwarding the packet and its associated metadata (packet state) in a timely manner with minimal latencies. This dictates having hierarchical memory architecture of on- and off-chip memories, with packet data effectively managed through the hierarchy. For example, first-level lookup tables can be in on-chip memories, while large volumes of data can be stored in external memory tables.

In addition, the use of multiple threads per processing core can bypass the memory wall problem. A core or thread continues to execute until an external memory access is needed, at which point another processing thread takes over. The resulting asynchronous memory architecture decouples external memory accesses from processing, maximizing overall system performance. This allows for bulk memory transactions, where many memory accesses are pooled together into one memory transaction, further increasing the efficiency of the external memory interface.

In-line or look-aside processing with security and virtualization

The coprocessor is in-line with ingress and egress traffic and should be able to, on-the-fly, encrypt and decrypt the packets, classify packets into flows, and look up the flow state table to determine the action needed on the flow. The coprocessor also implements I/O virtualization, allowing the x86 cores and their Virtual Machines (VMs) to share the I/O subsystem. In addition, the coprocessor should be able to dynamically load balance the traffic to the x86 cores and VMs based on flows.

Fast interconnect with x86

Supporting a heterogeneous processing architecture requires a high-performance interconnect to the x86 processor with I/O virtualization capability. For example, an 8-lane PCI Express Gen 2 interface supports up to 40 Gbaud of traffic to an x86 CPU socket. (Note: Overhead on read and write cycles brings this number down to the low 20s.)

Cut through/intra-flow cut through

Ideally, not all flows need to be transmitted to the x86 processor, as the coprocessor is intelligent enough to classify packets into flows. Based on the flow state table, an action can be taken to cut through, drop, or forward to x86. In some cases, the first few packets of a flow are forwarded to the x86 subsystem for inspection. The x86 processor can then instruct the underlying coprocessor to cut through the remainder of the packets in the same flow.

Inter-VM switching

The advent of VMs and the need for I/O virtualization have created a new set of requirements that mandates a more intelligent approach for managing I/O. This has prompted the need for an intelligent way to interconnect VMs on different cores to handle the so-called east-west traffic. Such VMs can belong to different tiers of servers in the data center. Having the VM-aware switch on the coprocessor can achieve the VM interconnect.

Passive NIC mode

The coprocessor should be able to support a mode where all network I/O traffic is passed to the x86 processor. This mode is required for monitoring and statistics or for applications requiring 100 percent of x86 CPU processing.

Implementing the OpenFlow protocol

Software-Defined Networking (SDN) allows users to bring the benefits of virtualization – including shared resources, user customization, and fast adaptation – to the switched network by defining traffic flows and deciding how these flows are treated in the network. In other words, it allows the system user to remotely control the network hardware with software in a dynamic and programmable fashion.

SDN puts the intelligence of the network into a hierarchy of controllers. In this hierarchy, switching paths are centrally calculated based on IT-defined parameters and then downloaded to the distributed switching architecture. A hardware-agnostic architecture that uses standard open interfaces to the hardware can change the way we build networking systems today.

The new OpenFlow protocol supports SDN. An OpenFlow controller typically runs on a multicore x86 processor and implements the control plane protocols. It downloads the state information onto multiple flow state tables in the coprocessor, implementing the data-switching plane through a standard OpenFlow API. The coprocessor, being a stateful flow processor, can be optimized to support the OpenFlow architecture.

Best of breeds for the future

As line speeds continue to grow, it remains to be seen how application workloads will be divided among x86 general-purpose multicore CPUs and external supporting coprocessors. The flexibility of riding a product roadmap for multicore x86 processors separate from that of coprocessors gives designers the choice to use the best of breeds in trying to meet ever-increasing future challenges.

Editor’s note: Read Part 1 in this series online at http://embedded-computing.com/managing-processors-40100g-part-of-2.

Nabil G. Damouny is senior director of strategic marketing at Netronome.

Netronome 408-496-0022 info@netronome.com @netronome www.netronome.com

Real-time performance: Build or buy?

Warren Webb, Editorial Director, OpenSystems Media — Tue, 07 Feb 2012 15:00:00 +0000

As more and more embedded devices evolve from single-function controllers to complex platforms supporting high-speed graphics, user interfaces, and network communications in addition to the primary application, real-time responsiveness is becoming a critical performance requirement. Although developing in-house software offers some advantages, the benefits of reduced complexity and shorter development schedules often justify the purchase of a commercial Real-Time Operating System.

The average person interacts with hundreds of embedded processors every day in phones, automobiles, home appliances, toys, cash registers, entertainment electronics, security systems, environmental controls, and personal electronics. The common link among all of these products is their ability to react in real time to the user, external events, and the communications channel.

The software for these embedded devices can be divided into application software and Operating System (OS) software. Application software makes the product unique and contains the data collection, signal processing, and hardware control routines required to make the product perform to its specification. The OS allows the programmer to break up large application programs into smaller, individually developed processes or tasks.

At the heart of an OS is the kernel, which schedules programs for execution and manages shared resources. A Real-Time OS (RTOS) processes hardware requests or interrupts from timers or external events within a guaranteed maximum time. Programmers interact with the OS through an API and set up the priorities and data dependencies. During execution, the RTOS manages the application software with a flurry of external real-time activity.

In-house code

Even with the advantages of an RTOS, homegrown OSs still occupy a non-trivial percentage of embedded real-time products. Developers have multiple incentives for bypassing a commercial RTOS entirely and writing their own real-time routines. The biggest reason developers cite for not choosing a commercial OS is lack of need. With only one task running, designers think they can easily keep track of the required hardware interaction.

Special situations sometimes justify in-house software. For example, the design objectives of a portable health care device can include low cost, low power, and a one-year battery standby life without extra memory and processing power to support a commercial RTOS. Furthermore, if a new project is an upgrade of a previous project, developers likely will want to use as much legacy code as possible.

Components that aren’t invented at the same company might also be one reason why many developers write their own OSs. Installing software from a third party into their showpiece product is like admitting they are somehow not up to the task. In addition, developers might think they’ll lose the ability to make software adjustments to compensate for hardware changes or to correct bugs. The designer can easily adjust the order of execution or drop to assembly language to solve critical timing problems with in-house developed software. However, with a commercial RTOS, the scheduler handles many of the timing issues, so developers lose the perception of being in total control. And finally, programmers list sticker shock as another reason to write their own operating software. The initial license for a full commercial RTOS and associated tools can be in the $15,000 to $20,000 range for a single development seat, plus recurring royalties for every unit shipped.

Software shortcuts

As embedded systems grow in complexity and project schedules shrink, software has displaced hardware as the highest-priced item in most embedded development projects. If design teams can buy an RTOS and eliminate the coding, debug, and documentation of the most complicated portion of the software structure, then the purchase decision should receive careful consideration. Although a commercial RTOS can be expensive, a smaller development team and shorter project time frame might create more than enough savings to justify the purchase.

An RTOS allows programmers to write independent, reusable modules to reduce software complexity and shorten the development schedule. Programmers can write each software routine independently without getting bogged down with intertask timing problems. Most RTOS vendors provide a full interactive development environment including a source code editor, code manager, linker, downloader, runtime tools, and one or more debuggers. Software vendors also supply software performance analysis tools to help profile and visualize real-time activity in application routines. Programmers can monitor which tasks are running, observe the stream of data flow, and detect when and how often a task is interrupted by a higher-priority item. RTOS vendors agree that high-quality development tools can dramatically shorten debug time.

Along with the cost savings, RTOS vendors cite multiple technical reasons to justify their products. For example, if an application involves heavy data processing, many RTOSs can be scaled easily to spread tasks across several processors for a significant performance boost. The RTOS provides communication and synchronization services to make multiprocessing transparent. In addition, an off-the-shelf RTOS working alongside multicore processors simplifies legacy code integration within new designs or products updates.

A commercial RTOS is modular, so users can select only those portions or features of the OS that they need. Specifying a subset of the full-blown commercial RTOS can reduce acquisition costs and the required memory footprint. With the current connectivity trend, even the simplest embedded products might need to connect to and send data over the Internet. A graphical user interface could also become standard in small embedded systems, even if just for maintenance. These features are included or optionally available in most commercial RTOSs, but can be very expensive or impossible to add to a proprietary OS. Vendors also promote product on-demand technical support as a major benefit of a commercial RTOS.

Off-the-shelf platforms

Commercial RTOSs are constantly upgraded to add new features and keep up with changing technology. For example, the popular VxWorks OS from Wind River was recently revised to deliver 64-bit computing support along with improved multicore features. VxWorks includes a shell, debugging functions, memory management, performance monitoring, and support for multiprocessing. Real-time features include a kernel for preemptive multitasking, interrupt response, interprocess communication, and a file system (see block diagram in Figure 1). Software development is enabled by the Wind River Workbench development tools suite and Intel Integrated Performance Primitives for VxWorks.

Figure 1: The VxWorks RTOS from Wind River fits many embedded applications and features 32-bit or 64-bit processing, multicore support, and numerous connectivity options.

(click graphic to zoom)

The RTOS supports various multicore configurations in Symmetrical Multi-Processing (SMP) and Asymmetrical Multi-Processing (AMP) modes or as a guest OS on top of Wind River Hypervisor. VxWorks also has a configurable and tunable small memory footprint, allowing the user to control how much of the OS to employ for each project.

In addition to offering a multitude of commercial RTOS products, the embedded systems community maintains an open-source OS based on a real-time kernel that is free for use in commercial applications. The FreeRTOS Project is under continuous active development and is distributed under the GNU General Public License with an optional exception that allows users to keep their proprietary software confidential. Free source code and the lack of recurring royalties are popular features for small, low-budget embedded projects. FreeRTOS has been ported to multiple microcontroller platforms and has minimal ROM, RAM, and processing overhead, resulting in a typical kernel binary image in the 4 KB to 9 KB range. Although FreeRTOS source code for the kernel is contained in only three C code files, the zip file download includes numerous demonstration applications to help new users get started.

The biggest complaint among potential open-source software users is the lack of a central resource to provide support similar to that offered by a commercial software vendor; however, the FreeRTOS website has an active free support forum where developers can find answers to their technical questions. In support of the open-source platform, Microchip Technology offers the FreeRTOS Microchip PIC32 Education Kit (see Figure 2). This $95 kit includes a development board that enables users to develop USB embedded host, device, and On-The-Go applications on the PIC32 microcontroller family.

Figure 2: The Microchip PIC32 Education Kit includes the hardware, software, and tutorials needed to get started using the open-source FreeRTOS platform.

(click graphic to zoom by 1.9x)

Real-time future

Although programmers might get excited when considering the challenge of developing an in-house OS, the “roll your own” days might be fading away. Designers can look forward to real-time software as the norm in future embedded products.

Customer demand for faster response times, complex functionality, and instant data access continues to increase the challenge of embedded design. Advancing technology also dictates that embedded products be capable of periodic software updates as requirements change, along with the possible transfer to the next-generation hardware platform.

Developers should take the time to analyze their system requirements, development schedule, software support, expandability, communications, scalability, and future growth before embarking on an in-house software development project. An off-the-shelf commercial RTOS or even an open-source operating system could be in your future.

Getting into the grid-to-device market with the LonWorks platform – Q&A with Varun Nagaraj, Senior VP of Product Management, Echelon

Varun Nagaraj, Echelon — Tue, 07 Feb 2012 15:00:00 +0000

To achieve the highest level of energy efficiency in buildings and factories, energy awareness must be designed from the inside out by embedding energy control networking into every device, making the whole system responsive to real-time conditions on the local grid. Varun emphasizes the importance of interoperability in smart energy systems and explains how embedded designers can leverage the LonWorks standard to speed product development.

NAGARAJ: The market opportunity for smart grid-aware devices and services is rapidly growing worldwide. In the past, energy management and efficiency were the domain of only those countries that lacked their own energy resources. Today’s world is much different. Energy fuels GDP growth, with industrialized nations consuming more on a per-capita basis than ever before. While this puts a strain on our collective generation capacity, it pales in comparison to the strains that are coming.

The U.S. Department of Energy reports that China’s energy consumption is expected to double by 2035 from its current position of parity with the United States, which is only expected to increase use by about 25 percent. The drive to supply electricity – especially in many fast-growth countries like China or India – puts tremendous global price pressure on raw materials like coal. For example, India will need to fuel the generation capacity required to add nearly a billion more people to their grid within the next 10 years – half of their population today.

What this all means is that we need to design products, systems, and services with an eye toward grid awareness and energy efficiency.

ECD: How can designers interact with smart grid technology to create new embedded products and services for customers?

NAGARAJ: One key aspect designers have to consider is that their products exist in a much larger context than their core function. Let’s say you designed a backup generator that’s highly efficient. Designers should consider the generator’s full business or value chain, which includes the utility, energy services companies, building automation systems, and smart devices.

In this example, many systems must interoperate to complete a cycle of smart grid responsiveness. The utility exercises its right to lower peak demand via contracts with the service provider; the service provider signals its building customers that their systems need to shed energy load by some percentage; the individual building systems broadcast rules that inform the smart devices to change to a low energy state; and the smart generator kicks in to help ensure that the tenant remains productive and comfortable.

None of this could be possible without open standards like ISO/IEC 14908.1, also known as the LonWorks standard (see block diagram in Figure 1). Without the LonWorks standard, we would not have a consistent way to communicate with or leverage the generator’s embedded intelligence.

Figure 1: The elements of the LonWorks platform – including a communications protocol, signaling technology, dedicated microprocessors, a network operating system, and more – enable devices to sense, monitor, and control energy usage.

(click graphic to zoom)

In the previously mentioned example, a LonWorks-based network allows the building owner to react to energy cost in a way that will lower expenses. This knowledge is supplied to the building and owner in the form of a service from an energy services company. The cycle starts when utilities react to the availability of energy by balancing loads to keep up with the demand occurring on the segment that contains the building. Designing a LonWorks interface in the generator means it can join an existing building network. All of these networks (building, energy service provider, utility) come together to form the backbone of a more efficient and smarter grid.

ECD: What is the LonWorks smart energy control network standard, and how does it fit in the embedded industry?

NAGARAJ: The LonWorks standard for energy control networks is widely adopted in several key energy markets. It’s the leading standard used in smart street lighting systems, commercial buildings, smart homes, and a newly emerging control market for solar installations (see Figure 2). It’s also a global control standard (ISO/IEC 14908.1, .2, .3, and .4) that encompasses the communications protocol, twisted-pair and power-line signaling technologies, and IP tunneling. It’s important to realize that the protocol is a complete ISO seven-layer stack and that it provides a fully documented, freely accessed, comprehensive set of open, interoperable, and industry-accepted data types and profiles.

Figure 2: The LonWorks platform works with existing and emerging control and networking technologies, offering flexible implementation in a variety of smart grid applications, such as smart streetlights, solar installations, and intelligent building control.

(click graphic to zoom by 1.9x)

This means that designers can focus on what they do best – their applications and solutions – rather than spend time on the nuts and bolts of communications and networks. So if you’re building a complete system, you don’t have to design signaling technology, tools for optimizing performance, or communications protocols. You can use the LonWorks standard or work with companies supplying LonWorks-based tools and technologies that can be easily leveraged to get products to market faster at a lower development cost.

ECD: What software tools and development aids are available for building automation and industrial management projects?

NAGARAJ: Echelon and other companies offer a variety of evaluation kits, development environments, test tools, network analysis tools, system software, and installation tools. Because the LonWorks standard is open, developers have several options to choose from.

Free software development kits and information on ways to kick-start development efforts are available at http://info.echelon.com/ecd-downloadsdk.html. Another good place to start is the LonMark International website at www.lonmark.org. This provides an overview of the application profiles available to help designers ensure a product works with other LonWorks-based products, as well as an indication of what’s on the market today.

ECD: What hardware/software educational events or online classes does Echelon offer to help embedded designers get started with its products?

NAGARAJ: Echelon offers a full curriculum of courses that can be presented on-site. These include:

100: Introduction to the LonWorks Platform
201: LonWorks Network Design
301: Using the LonMaker Integration Tool
320: i.LON 100/i.LON 600 Installation and Configuration
401: LonWorks Device Development

We also provide an extensive eTraining catalog of courses in topics ranging from basic Neuron C programming (essentially ANSI C with some minor changes that support the event-driven communications paradigm of a LonWorks network) to full device development. The full list of courses is outlined at www.echelon.com/training/courses/default.htm.

Varun Nagaraj is senior VP of product management at Echelon.

Echelon 408-938-5200 Info@echelon.com www.fb.com/pages/ Echelon-Corporation/117116285042073 https://plus.google.com/102546002380846580056/posts www.linkedin.com/company/echelon?trk=fc_badge @echeloncorp www.echelon.com

Telehealth » Articles

People-centered innovation driving the next generation of telehealth – Q&A with Alan Boucher, Director of Software Architecture and Engineering, Intel-GE Care Innovations

Harnessing technology to transform care – Q&A with Joseph Kvedar, MD, Founder and Director, Center for Connected Health

Panel discussion: Designing portable medical devices that emulate today’s consumer devices – with added security

APUs strike the ideal balance of form, function, and power consumption for graphics-intensive portable devices

Giving smart energy its own "easy button"

Programmable perks: Tallying the benefits of FPGAs

New aircraft platforms get cut back, opening the door for avionics retrofits that leverage COTS hardware and software

‘Critical embedded systems’ defined

Critical embedded systems are the hub of the military, rail transportation, medical, industrial control, space exploration, aviation, and many other industries. But how precisely is a “critical embedded system” defined – and why does the definition matter?

Ten critical embedded system trends to watch in 2012

Editorial Director Jerry Gipper presents his list of the top 10 VITA critical embedded systems trends for 2012.

Embedded computing off the power grid

Starting off with off-the-shelf

Step 1: How much power is needed?

Step 2: How much sun is available?

Step 3: What size battery is needed?

Step 4: What size solar panel should be used?

Controlling system power

Demanding big-time graphics in little packages

The value of usability: Getting developers to ‘push the button’ on static analysis – Q&A with Gwyn Fisher, CTO, Klocwork

Attack the stack: Identifying unauthorized code execution caused by buffer overflows

Trusting the tools: An agile approach to tool qualification for DO-178C

DO-178C brings modern technology to safety-critical software development

Flexibility required? – FMCs

Constantly changing requirements for I/O functionality can leave designers in a quandary, but VITA’s FPGA/reconfigurable device supportive FMC standard provides a remedy.

Standing on the shoulders of giants

Rapid solutions

Fast flexibility

The work continues

A flexible future

Mitigating undesired input beat frequencies in parallel DC-DC converter arrays

Innovations for the warfighter: Small, COTS-based, portable, and platform agnostic

Requirements for platform-independent, portable, cost-effective solutions that leverage commercial technology will drive innovation among designers of future military electronic systems.

Robots in the military: Brave, autonomous, and dispensable warriors

Radar signal processing upgrades use embedded COTS hardware

Military radar designers are turning more and more toward Commercial Off-the-Shelf (COTS) signal processing solutions to modernize existing radar systems. (Photo courtesy of Lockheed Martin)

Power electronics designs trending smaller and more efficient

Designers of power electronics components for the military market say business is steady, but they continue to be challenged to increase efficiencies while simultaneously shrinking component size. Meanwhile, in the space arena there is a move toward digital devices.

Microcontroller market and design dynamics – Q&A with Gaute Myklebust, VP of MCU Product Planning, Atmel

Managing network traffic flow for multicore x86 processors at 40/100G

Real-time performance: Build or buy?

Getting into the grid-to-device market with the LonWorks platform – Q&A with Varun Nagaraj, Senior VP of Product Management, Echelon

Critical embedded systems are the hub of the military, rail transportation, medical, industrial control,
space exploration, aviation, and many other industries. But how precisely is a “critical embedded system” defined – and why does the definition matter?