Virtualization has proven its value in the data center, but can it work in tactical environments? Yes, but only if it’s secure.

The evolution of computing capabilities to allow the mobilization of data has paved the way for the transformation of tactical vehicles into rolling data centers. These impressive machines have provided invaluable resources for warfighters to dominate the battlefield. Unfortunately, despite the obvious benefits to packing a Humvee or tank with real-time intelligence computing equipment, these capabilities come at a not-so-obvious price: a sacrifice of precious power, cooling capabilities, and logistical space to accommodate the new equipment. For example, too many computers could adversely impact visibility or generate additional heat in an already scorching environment, dulling a soldiers’ reaction time and potentially increasing health and safety risks.

Interestingly, these rolling data centers are experiencing many of the same challenges found in today’s enterprise data centers – again, power drain, insufficient cooling, and lack of space. To address these challenges, data center managers have turned to virtualization to perform physical to virtual server consolidation, regularly achieving a 10 to 1 optimization or better. Can the lessons learned by virtualization in the data center also benefit tactical vehicle environments? What about special security requirements of tactical vehicles that contain content of differing classification levels? It is essential to understand the unique challenges and similarities between virtualized and physical server consolidation, as well as some of the secure virtualization advances made by the open source community that can be directly applied to help the warfighter.

Benefits of virtualization

There are several benefits to the deployment of virtualization to the field and in data centers, including consolidation, uniformity, live migration, and performance, which can specifically aid warfighters and increase efficiency on the front lines.

Consolidation

When workloads are consolidated with virtualization, hardware utilization increases. More can be done with less hardware, resulting in power, space, and cooling savings. In tactical environments, capabilities can be added with nominal increases in compute requirements. By consolidating workloads on fewer physical systems, the newly available space can be repurposed for additional mission features, more bullets, and literally more elbow room for the crew.

Uniformity

Virtualization allows data center managers to abstract hardware from the OS. This allows the data center manager to acquire the best performing hardware, for the lowest possible price, without needing to recertify software stacks. Hardware vendors can be pitted against one another to deliver the best value. In tactical environments, this advantage is even more profound, with no need for each application to have its own computer with an exotic form factor, power requirements, proprietary connectors, and so on. As a result, new capabilities can be added much more easily and hardware refreshes can happen much more quickly because, as mentioned, recertification time is reduced. Additionally, not every vehicle may need the same capability, so the need to rigidly budget power, space, and cooling, whether the capability is used or not, becomes relaxed. In the end, uniformity makes the warfighter much more nimble.

Live migration

If imminent hardware failure is detected on a hypervisor in the data center, a workload can be live migrated with zero downtime. Even if the hypervisor fails unexpectedly, the virtual machines running on it can be restarted on other hardware without user intervention. In tactical environments, battle damage resulting in the loss of a computer may result in loss of critical capabilities needed in the heat of battle. By running workloads directly on physical hardware, the capability may not be restored until the warfighter returns for the vehicle to be serviced, which may be too late. If the workload is virtualized, it could be migrated in real-time to or restarted on a functional server elsewhere in the vehicle without warfighter intervention. As a result, the probability of the warfighter losing a mission-critical component during battle for an extended period of time is lessened.

Performance

Some workloads that require low-latency or high-bandwidth communication between systems actually run faster when virtualized on the same piece of hardware. This is because the virtual network communication is done over the system backplane instead of going from physical system to physical system across a much slower and higher latency networking infrastructure. This increased performance and lower latency can help the warfighter respond much more quickly in the heat of battle.

Is virtualization secure?

Not by itself. If a hypervisor is compromised, not only is it compromised, but so are the virtual machines running on it as well as the virtual machine disk files connected to the hypervisor that may be running on it, on another hypervisor, or at rest. When a hypervisor exploit happens, restoring all virtual disk files from a known reliable backup is needed. If the time of exploit cannot be pinpointed, a full reinstall from scratch may be necessary. Many virtualization security solutions put in place offer a trusted means for the virtual machines to communicate with each other, but these tools offer no protection in the event of a hypervisor compromise. If virtualization is to be deployed in tactical environments, the hypervisors must be secure so the warfighter can trust the integrity of the components supporting the mission. So do technologies exist to prevent this type of exploit? Yes, thanks to the open source community.

Secure virtualization with sVirt: sVirt is a secure virtualization open source project, built upon a time-tested SELinux open source project pioneered by the NSA and the commercial software industry, dating back to 1999. sVirt is used to securely isolate KVMs (or Kernel-based Virtual Machines) from the hypervisor and from each other. Before we get into the details of sVirt, let’s do a quick review of SELinux and KVM:

SELinux predates x86-based virtualization and was originally used to lock down physical systems to prevent rogue applications from harming one another as well as the main system. SELinux is all about labeling. Every object on an SELinux system is labeled according to its function. This includes processes, users, files, hardware devices, network ports and adapters, and so on. The SELinux policy allows objects with certain labels to explicitly access objects with other labels and deny everything else. For instance, if a rogue web server process wants to read a password file, SELinux will block and log the access since the SELinux policy does not explicitly allow processes with a web server label to access files labeled as password files. SELinux is not an add-on to Linux – it is built in. SELinux has been enabled by default in mainstream enterprise Linux distributions since 2007.

KVM is an open source project that emerged in 2006 and was accepted in the upstream Linux kernel in 2007 and can today be found in numerous Linux distributions. KVM is unique in that all KVM virtual machines are Linux processes. As such, KVM is very lean because it can leverage the time-tested Linux operating system to manage VMs, perform hardware enablement, and leverage advances in power efficiency and performance, to name a few. As a tremendous side effect, in the same way a web server process can be confined with SELinux policy, a KVM virtual machine process with the SELinux policy called sVirt, mentioned previously, can also be confined.

At a high level, sVirt works by placing SELinux “force fields” around virtual machines, which confine what they can do. sVirt can even protect virtual machine guests that do not have the built-in protections of SELinux like Windows, as pictured in Figure 1.

When a virtual guest starts, the KVM Linux process is given a unique SELinux label by sVirt. Correspondingly, the virtual disk file of that virtual machine is given a matching label. With the exception of the process and the virtual disk file, no other object on the system has the same label. When a second virtual machine starts, the second virtual machine’s KVM Linux process and virtual disk file are given their own unique but matching labels. This is all pictured in Figure 2.

In the event that a virtual machine is able to do a hypervisor exploit and gain administrator access, sVirt at the kernel level confines the virtual machine to only what is allowed by the sVirt SELinux policy, namely to see its own disk file (not others), use other resources narrowly allowed by virtual machines, and nothing else.

Sounds great, but does sVirt really work? Actually, yes. At the Black Hat USA 2011 conference, Nelson Elhage presented a method to compromise KVM, but the use of sVirt defeated his approach.

Side note: Interestingly enough, the labels created by sVirt are Multi Category Security (MCS) labels. MCS (and Multi Level Security or MLS) labels are concepts derived directly from secure computing efforts driven by the NSA and other agencies. The fascinating part is that this demonstrates how agencies with classified data requirements have helped the open source community take their requirements from niche to mainstream. By leveraging the proven MCS capabilities of SELinux, Common Criteria certification of KVM with sVirt becomes much easier.

Red Hat is a contributor on both the sVirt and KVM projects, as well as SELinux, utilizing their Red Hat Enterprise Linux and Red Hat Enterprise Virtualization products. For more information on these projects, visit www.selinuxproject.org or www.linux-kvm.org.

Future work

Things can always be made better and more secure. An additional concept being integrated into virtualization is the concept of resource control groups or cgroups. In the same way as SELinux can confine access by Linux processes, cgroups is used to control the CPU, network, memory, and other resources consumed by Linux processes. Since KVM virtual machines are Linux processes, they can also be confined by cgroups in the same way they are confined by sVirt. This paves the way for resource fairness when it comes to virtualization multitenancy. One integrator’s virtual machine won’t overconsume their fair share of system resources, which could adversely affect another integrator’s virtual machine on the same hypervisor. From a security perspective, cgroups can also be used to prevent a denial of service attack on one virtual machine from taking down an entire hypervisor.

Another open source effort under consideration is that of trusted computing. As computing resources containing sensitive data are pushed deeper and deeper into the battlefield, a secure means to boot and trust federated systems that aren’t locked and under guard in a data center becomes paramount. The open source community along with government agencies and hardware and software vendors are actively working on trusted computing technologies to address these needs. Since KVMs are Linux processes, the ability to rapidly adopt these emerging trusted computing methodologies becomes much more straightforward as opposed to inventing something wholly new.

David Egts is a Principal Architect at Red Hat, Inc., specializing in the application of open source enterprise infrastructure technologies within federal, state, and local government agencies, the Department of Defense, and educational institutions. Contact Dave at degts@redhat.com.

Red Hat 703-748-2201 www.redhat.com

]]> http://tech.opensystemsmedia.com/embedded-software/2012/04/secure-virtualization-for-tactical-environments/feed/ 0 http://www.compactpci-systems.com/articles/id/?5590 http://www.compactpci-systems.com/articles/id/?5590#comments Thu, 22 Mar 2012 15:00:00 +0000 John Long, RadiSys http://tech.opensystemsmedia.com/embedded-software/?guid=9310a79e434efb8239aeeea87a66eb94

Entire Aerospace and Defense (A&D) networks, from base stations to the core, are being consolidated into small, ruggedized communications platforms that provide the ability for an entire network to be picked up and moved. Femtocells are now being found on Humvees, ships, and even carried in a soldier’s pack, providing unparalleled communications right where it’s needed most. Compact network cores can fit in 2U and 5U ATCA chassis and can easily be transported. However, these ultra-portable cellular networks require a combination of hardware and optimized software that meets specialized Size, Weight, and Power (SWaP) requirements for next-generation network-centric warfare.

Our military networks have been lacking agility and reliability in comparison to the commercial cellular devices the enemy has at its disposal. Efforts in Iraq and Afghanistan have exposed this gap between proprietary radio communications and commercial cellular networks. Smart phones and cellular networks are allowing an unprecedented level of situational awareness, giving soldiers a significant advantage in the palm of their hand, but cellular networks can be difficult to deploy from a military transport vehicle, such as a Humvee or destroyer, because they tend to be very large, heavy, bulky, and power-hungry. In addition, the network nodes are too cumbersome to be portable, lack the ability to deliver ad-hoc communications, and are not easily customizable to deliver the reliability and security that the military requires.

The military wants to take advantage of proven commercial cellular technology and the associated economies of scale for the next-generation mobile communications systems. However, it cannot simply re-use this technology as is. These portable networks require particular architectures and specific hardware and software elements to meet the specific requirements, such as Size, Weight, and Power (SWaP), of network-centric warfare. This is leading to tremendous changes in how the military implements its wartime communications networks as it moves toward adoption of standards-based cellular technology with 3G today and LTE in the future.

Transitioning from proprietary solutions to COTS hardware

The telecom industry has been steadily moving from proprietary to standards-based designs due to refined standards and the development of a healthy supplier ecosystem. As telecom companies transition from proprietary to standards-based architectures, some are now saving resources and capital by outsourcing critical design and validation tasks. By using Commercial Off-The-Shelf (COTS) hardware as opposed to designing a computing system in-house, Network Equipment Providers (NEPs) are now in a position to avoid hardware design altogether and can focus development efforts on software-based value-add features. NEPs are finding that equipment based on open standards architectures typically costs less to deploy because it makes sound economic sense to design scalable platforms that can be employed across multiple applications (Figure 1).

Open standards-based COTS solutions not only address many issues facing equipment manufacturers, they also meet the needs of military programs. Military and aerospace system designers, who are in the process of replacing proprietary architectures, are seeking COTS technologies that competently accommodate the toughest environmental conditions (such as extreme temperatures) yet are efficient enough to meet application needs for power, performance, and heat dissipation. For example, the military is now looking outside of its engineering ranks to guarantee that its components are rigorously temperature tested. Many COTS technologies were designed to both withstand the rigors of military environments, and offer developers readily available, interoperable hardware that reduces design effort.

Putting the pieces together

Next-generation network-centric warfare requires ultra-portable cellular networks that squeeze the entire system, from base station to the core, into a small, ruggedized platform that can be picked up and moved, or even carried in a soldier’s pack (Figure 2). COTS technologies have made tremendous progress in satisfying the size, ruggedness, and performance requirements for a wide range of Aerospace and Defense (A&D) applications.

When combined, COTS technologies such as AdvancedTCA (ATCA) and COM Express provide a complete, deployment-ready solution with the flexibility for design and software enhancements. Together they support a network of networks in a manner that is standards compliant, providing a high level of interoperability and scalability. Many protocols can be consolidated onto one platform of nearly any size to accommodate a variety of missions, with base stations ranging in size from a big box to several smaller distributed units.

No matter the computing technology, year after year designers try to find ways to increase performance. Successfully integrating a high level of computing power basically comes down to board size, board power consumption, and backplane technology. In all of these areas, ATCA has a significant advantage. ATCA is a bladed platform that easily scales features and performance by adding blades that support new applications or more computing power. With its roots in telecom, ATCA was designed to maximize serviceability and availability, leveraging hot-swappable components and redundancy (for example boards, switches, fans, and power entry modules). In the field, an ATCA chassis is powered by stepping up the military vehicle battery voltage to 48 volts, thus avoiding the 120-volt (AC) supply required by a rackmount server. Yet, to attain the maximum benefits from ATCA equipment, manufacturers have realized it takes a combination of telecom and ATCA expertise to bring all of the elements together — chassis, blades, operating system, middleware, and platform management software — into a cohesive platform.

Boosting performance is especially challenging for designers of small form factor systems who face stringent space and power constraints. It’s also difficult to keep up with the design churn associated with implementing new processor generations and increasingly complex design rules. As a result, military system developers are turning to COM Express boards, which remove the processor, chipset, and memory from the rest of the design. For example, for the purpose of reducing size and cost, a leading provider of military mobile telecommunications technology and software development completely revamped its system architecture using COM Express, and now the core network is the size of a shoebox and one-tenth the cost of other available solutions.

The case for small cells in military applications

Small cells provide unparalleled communications right where it’s needed most without adding extra weight or taking up a lot of space. As opposed to a traditional macrocell on a hilltop or a tall tower, a small cell is a wireless base station that is portable and transmits at very low power. Small cells typically use an IP broadband connection (such as cable, DSL, or fiber) for backhaul and eliminate the need for dual-mode handsets, as virtually any existing wireless handset should work seamlessly with a small cell offered by the carrier.

A wireless equipment manufacturer recently set out to design a flexible LTE network solution that could scale from small to large networks to serve U.S. state and local governments seeking to improve public safety. Increasing capacity had to be as simple as adding processing blades to the chassis and activating additional subscriber licenses, while minimizing SWaP was essential for supporting military or disaster response applications in which the wireless network may need to be transported via van or military Humvee. For customers with existing mobile infrastructure, the solution required the flexibility to make use of legacy equipment. To meet its objectives, the equipment manufacturer developed an Evolved Packet Core (EPC) that is available in different hardware configurations, making it a highly scalable and cost-effective solution. The EPC ships in either a 2- or 14-slot ATCA chassis from Radisys, running the full complement of Trillium LTE protocol software including open interfaces for integrating external network elements.

But is it secure?

Commercial cellular networks have built-in security and integrity protection features. These, however, are being modified for military applications. Existing features that can be customized include:

1.  Air interface ciphering – In commercial networks this is based on the Advanced Encryption Standard (AES) and KASUMI and SNOW 3G algorithms, but can be modified to use any defense-grade encryption approach.

2.  Integrity protection – Mobility and session state information is encrypted and decrypted in the core of the network leveraging commercial-grade algorithms, which may be customized for military requirements.

The ATCA platform enables a robust telecom security gateway that offers world-class security features with multi-gigabit performance to secure the backhaul capabilities — the infrastructure for connecting cell sites to the core network. Furthermore, the COM Express combination of Intel Active Management Technology (Intel AMT) and Trusted Platform Management (TPM) ensures remote access transactions are safe and secure. In addition, since small cells are portable and not left in the same spot for long periods of time, they are less vulnerable. However, many NEPs are also addressing security through protocols. For example, Radisys provides the COTS solutions for mobile infrastructure and the expertise needed to customize the solutions based on SWaP constraints, while NEPs bring the specific insight needed to wrap A&D security features around the standard offering.

Warfighters need more situational awareness on the battlefield and better communications back to the command center. Adoption of commercial standards-defined cellular technology solves the agility, reliability, and cost challenges, but does not deliver an ultra-mobile solution enabling ad-hoc network roll-out and the network of networks concept central to next-generation network-centric warfare. These ultra-portable cellular networks require a combination of hardware and optimized software that meets specialized security and SWaP requirements. Modular, ruggedized computers combined with a customizable carrier board provide COTS-based hardware ideal for ultra-portable warfighter communications applications and are specifically developed to support the extreme conditions in the field. The addition of small cell software solutions provides unparalleled communications right where it’s needed most, without extra weight or bulk.

John Long is a product line manager at Radisys, with a focus on ATCA single board computers and storage.

Radisys

www.radisys.com

john.long@radisys.com

A good Graphical User Interface (GUI) can thrill customers, and a good reusable GUI development platform can save developers time and money; however, design subtleties and pitfalls keep developers on their toes.

A good User Interface (UI) is priceless. Think of the clean iTunes interface. The meaning of “UI” is quickly becoming something other than “User Interface”; it can now stand for “Unbelievably Important” and an “Untapped Investment” in embedded systems.

As microcontrollers move up the ladder in capability and out into the world of the consumer, and processors have moved from low-capacity 8-bit to high-capacity 32-bit systems, human interaction with software becomes more important. Along the way, programmers wondered, “What do I do with this horsepower?” Now they’re in a position to use this power to respond to customer requirements that say, “I want this to look like an Android or iPad app.”

However, the amount of effort involved in creating an effective UI is non-trivial. Graphical User Interface (GUI) development takes at least three basic steps: designing a visual interface (windows and widgets), writing the code that implements that interface, and getting that code to work on the specified hardware. Additionally, as processor power has grown, so have customer expectations. Color, touchscreens, gesture recognition, and speech recognition continue to up the ante in development efforts and create even greater challenges. Tools like GUI software packages are available to help automate the basics, but programmers still have a lot of work to do to create a polished interactive interface where each step of development has its own challenges and remedies.

Designing and building the interface

The old-fashioned, and still valuable, way to build a visual interface is pencil and graph paper. In essence this step involves creating “storyboards” and mapping out the interface.

The updated version of those storyboards is a good GUI package that includes an interface builder: a way for the developer to define a window’s complete layout with adornments, scroll bars, text areas, buttons, widgets, colors, text, and so on. This allows items to be positioned accurately with correctly configured behavior and styles.

There should be transparent objects that can act as containers to group certain objects together, such as a collection of radio buttons that respond to a single message. The library will have a message-delivery system that can deliver the message to the objects in the group. All of the required properties and connections among the controls in the window can be set up using a container hierarchy.

There is a critical subtlety here to be aware of. Typically the layout utility is a desktop tool that ultimately generates code for an embedded platform. It is important for the interface to look and behave precisely the same on both the host development platform and the platform being developed. The window builder should enable a What-You-See-Is-What-You-Get (WYSIWYG) design. The same runtime library rendering the image on the desktop should render the image on the destination device. The OS shouldn’t, for example, render a font one way on the desktop OS and appear differently on the end product. Pixel-for-pixel spacing on a small output device can matter a great deal.

Creating the code

Once settled on a design, some libraries make developers write code from scratch. That’s not the ideal solution. A good GUI package will generate all the code and configuration files required to create the interface. The generated code should be compiler-neutral, typically standard ANSI C or C++.

A good bit of the UI’s basic behavior code can be generated as well. For example, a collection of radio buttons has the standard behavior of all turning off except the one selected. That update behavior can be coded automatically. This is not rocket science; programmers spending time writing basic functionality wastes their true value.

The functionality behind that interface is up to the developer. Here the library can be a great help. This code should be well documented, showing developers where to add (and not add) code to the program. The automatically generated code should have function stubs with statements equivalent to // put your code here. The designers of the library know what kind of code belongs where and should provide a great deal of guidance. Look for that kind of help in good GUI tools.

Finally, in addition to the actual programming code, consider UI text. Fonts in foreign languages and non-Roman scripts like Mandarin, Kanji, or Arabic are an important consideration. Look carefully for font support in a tool. How does text get into the UI, and how easy is it to update and modify that text? What happens when a client says, “We’re going after the market in India; we need to have the software localized into Hindi”? Developers need to be able to change the language independently of the code for smooth system transitions.

Running on hardware

Once the interface is fully designed and coded, it has to work. It should be compatible with multiple processors, multiple display screens with different display technologies, physical dimensions, and color depths. It needs to be independent of hardware assumptions and dependencies so migration to new platforms and the addition/removal of components will not require substantial recoding or redesign. Input mechanisms should also be independent – mouse, stylus, capacitive touch, resistive touch, and so forth. The library should be software independent as well, and should work with a choice of operating systems, drivers, and other software packages.

To work on a hardware platform, no library can stand alone. It must have a runtime library that sits on the hardware and does work like render images and fonts. There are also hardware drivers for input and output devices. As an example, take a look at the block diagram for the PEG library from Freescale (Figure 1).

Moving a GUI to a new platform is still work, but a compartmentalized design reduces the work to a minimum. If input is changed from mouse to gesture-based resistive touch, the design is going to need a new input driver. However, a well-factored GUI should require very few if any changes to the design and code. In a well-factored design, the GUI calls a routine to get an XY coordinate instead of calling a mouse driver. The mouse will feed that coordinate into the input layer, isolating the GUI from the hardware. Then if the mouse changes to a stylus or a touch screen, the GUI code doesn’t change at all; each new driver feeds its data to the right place.

But wait, there’s more. Recall the importance of WYSIWYG between the desktop designer and the embedded platform: This isn’t just for quality control and testing – there is another significant benefit from that. It’s possible to build a functional prototype on the desktop without having the actual physical device complete and in hand; the application can be distributed to key stakeholders in the beginning of the development cycle and get buy-in without developing hardware. Then after the device really exists and when the specs come in for the next-generation device that needs to hit the market in three weeks, developers will be as prepared as they can be.

Focus on implementation, not code

Using GUI tools can help lock down the basics and give developers more time to focus on making sure an interface’s logic is sound and the interaction is intuitive. Because it is relatively easy to create a working mockup of a UI, developers can test usability before or in parallel with application functionality. End users will thank UI designers when they don’t have to figure out what to choose for messages like the one in Figure 2.

Jump off the shoulders of giants

Creating a UI for the first time is revolutionary. Modifying and leveraging it in future products is evolutionary. Creating a new UI for every new piece of software, or even writing code to create windows and widgets isn’t a smart use of time. Very bright people solved these problems a good while back, and the intelligent thing to do here is to reuse known good practices – a simple UI consistent across and independent of different platforms – with the help of a good GUI engine. The proper choice of GUI tools allows UI code to be future-proofed (as much as possible) during development, reducing time and support burdens during its lifetime.

Jim Trudeau is Senior Technical Marketer focusing on software solutions with the Industrial and Multi-Market Group of Freescale, in Austin, TX. He is the author of Programming Starter Kit for Macintosh (1995) and Mastering CodeWarrior (1997), as well as numerous articles and training courses on software development. He is inordinately fond of a good UI.

Roger Edgar is responsible for product management and business development for Freescale’s Industrial and Multi-market Enablement team, including the PEG software line. Prior to Freescale, Roger was as a founding partner for JumpStart Marketing and served as Vice President at Impart Technologies.

Freescale Semiconductor Jim.Trudeau@freescale.com Roger.Edgar@freescale.com www.freescale.com

]]> http://tech.opensystemsmedia.com/embedded-software/2012/03/effective-ui-development-with-gui-tools-for-embedded-devices/feed/ 0 http://www.smallformfactors.com/articles/id/?5556 http://www.smallformfactors.com/articles/id/?5556#comments Mon, 12 Mar 2012 15:00:00 +0000 Kelly Gillian, AMD http://tech.opensystemsmedia.com/embedded-software/?guid=036ab977e3ec2ed4817e20dda112196f

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.

]]> http://tech.opensystemsmedia.com/embedded-software/2012/03/apus-strike-the-ideal-balance-of-form-function-and-power-consumption-for-graphics-intensive-portable-devices/feed/ 0 http://www.smallformfactors.com/articles/id/?5559 http://www.smallformfactors.com/articles/id/?5559#comments Mon, 12 Mar 2012 15:00:00 +0000 Monique DeVoe, Editor, OpenSystems Media http://tech.opensystemsmedia.com/embedded-software/?guid=94c6955d10ef0e1af8df1d1988bc2ca7

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.

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.

]]> http://tech.opensystemsmedia.com/embedded-software/2012/03/panel-discussion-designing-portable-medical-devices-that-emulate-todays-consumer-devices-with-added-security/feed/ 0 http://www.embedded-computing.com/articles/id/?5553 http://www.embedded-computing.com/articles/id/?5553#comments Fri, 09 Mar 2012 15:00:00 +0000 Jennifer Hesse, Editor, OpenSystems Media http://tech.opensystemsmedia.com/embedded-software/?guid=d22f4303dee8bf7bc1dc45ec349c0f2e

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.

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).

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.

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.

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

]]> http://tech.opensystemsmedia.com/embedded-software/2012/03/programmable-perks-tallying-the-benefits-of-fpgas/feed/ 0 http://www.mil-embedded.com/articles/id/?5579 http://www.mil-embedded.com/articles/id/?5579#comments Wed, 07 Mar 2012 15:00:00 +0000 Sharon Hess http://tech.opensystemsmedia.com/embedded-software/?guid=7fc83c772519d5c405301ed63af11ff9

Editor’s note: While the issue of military stovepipes continues on, Government Off-the-Shelf software provider Intelligent Software Solutions’ toolkit – already in use by several branches of the U.S. Armed Forces – is thwarting the challenge by making it possible to link several disparate databases or data sources that would have otherwise not been able to “talk” to each other. As Managing Editor Sharon Hess found out when she recently talked to Carl Houghton, Vice President, Strategic Initiatives & Advanced Technology at Intelligent Software Solutions, the “real-time” ability of the software to combine data fast and automatically notify operators of data changes greatly simplifies the challenge for command and control operatives, as well as other government personnel. Meanwhile, the open source software company also does a thing or two with iOS and Android – and watches to see which one will capture the market. Edited excerpts follow.

HOUGHTON: Intelligent Software Solutions is a software and public services company founded about 15 years ago and headquartered in Colorado Springs. The company was started by four software engineers who still own the company. We’ve got close to 700 employees today, with offices in Tampa, Florida; Rome, New York; Washington, D.C.; and Hampton, Virginia; and we just opened an office recently in Boston. We’ve got four major business units in the company: One focuses on Command and Control and Intelligence, Surveillance, and Reconnaissance. We also have a National Systems division, focused on D.C. area customers and the Coast Guard. Then we have our Enterprise System Division, which used to be called Combat Systems and provides support to ongoing operations in Afghanistan and a couple other places. And then we’ve got my division, Strategic Initiatives, and we focus on advanced technology development. We are doing things for DARPA and other service laboratories and research and development work, both IRAD as well as government-funded research and development.

You’re focused on Government Off-the-Shelf [GOTS], I believe?

HOUGHTON: Yes, we develop software for desktop, Web, and mobile device applications; we’re predominantly a Government Off-the-Shelf software provider: The government owns unlimited use rights to everything we develop, so they don’t have to license for each deployment. What is nice about that model is that we’ve got this ubiquitous data access framework on the backend that can connect up to a lot of different data sources. And then we can use that to push the data out, whether it be to a desktop application, a Web application, or a mobile application. And so we try to reuse these government off-the-shelf frameworks as much as we can in our applications.

Can you tell me which government entities you work with and which kinds of open source software you’re providing them?

HOUGHTON: Our largest contract is actually with the Air Force Research Laboratory [AFRL], and they use our WebTAS-TK toolkit. It started out as a $350 million indefinite delivery/indefinite quantity [AFRL] contract, but any government agency can use [the contract] to purchase software and services. The toolkit is software that provides ubiquitous data access, visualization, and data analysis for a wide range of applications. And what’s nice about it is we can build on top of that framework. [When] you want to build the new application, we have a 70 to 80 percent solution at the starting point and then we can build what we call “business layers” on top of that to extend it to solve different problems. So for the Coast Guard, we could take a piece of Government Off-the-Shelf software, build a business layer on top of that that is specific to their requirements and workload, and they have a solution without having to start from scratch and [without having to] ask for licensing and software. So we replicate that model across the government space.

We do a lot of work with the Air Force and the Army and some work with the Coast Guard, as I mentioned. We typically provide them with WebTAS-TK or perhaps CIDNE, which is software that tracks events. So if you have a series of events that takes place and you want to track it and you want to track who was involved, for example, CIDNE enables you to do that. So the main two applications we deploy to our customer base right now are WebTAS-TK and CIDNE. We’ve got other types of software that are more minor applications. We do service oriented architecture infrastructures for the space community and for several others.

Are WebTAS-TK and CIDNE used by warfighters or by operators at a desk?

HOUGHTON: Yes to both. The users could be [soldiers] deployed in Afghanistan, who use the software for various visualization/analytical purposes [and transmit that information] to people who are back in the U.S. using the data for Command and Control purposes. The Coast Guard is using it for maritime operations for securing our ports.

Let’s drill down on how WebTAS-TK works.

HOUGHTON: Sure. So the software itself is predominantly a Java-based framework that allows us to do database connections. We can use JDBC- or ODBC-type connections to connect to relational databases. We can connect to other relational data sources; we can connect to Web services and various streaming data sources. I can’t go into specific details about specific applications on the government space, but I can give you some information. For example, if you had 20 different relational databases that range from Excel spreadsheets through Access databases all the way up to enterprise Oracle instances and you wanted to federate those into a single data space that could have a single logical object monolog you could query against – [WebTAS-TK] provides the ability to federate and provide that single logical object model and data space.

So once you have that, then we have a whole series of different analytical tools that allow you to visualize and analyze data temporally, geospatially, and internodally to look for interesting bits of data from your federated data space.

Tell me more about the Web and mobile applications you work on.

HOUGHTON: On the Web side, we use a wide variety of technologies, anything from Java server faces to Flex and Flash. We do a lot with pure Flash with Flex and ActionScript. We also were doing some HTML5 applications, and all of those have the ability to come through the WebTAS-TK backend or provide Web-based access to that data. In the mobile space we develop on both iOS and Android, and we get to those through the use of JSON or other transport media to get the information from a WebTAS-TK backend to a mobile device on the front end.

Can you give a scenario of how the military would use WebTAS-TK?

HOUGHTON: Let’s say you had a Command and Control application requirement and that you have a database that has information on where a particular aircraft is located. And maybe you have other sources of information that say, “Here is the status of all the various bases.” And then you’ve got a third database that has maybe targets for flying purposes, and you need to federate those things so you can plan missions, know what your available resources are and what their status is, and know which targets you are going to plan against. And you need the ability to eventually bring that data together from these three disparate databases that don’t talk to each other in order to be able to do that planning. That is what you could do with this software. You could imagine that could be 50 different databases. Today it is a classic problem [in the military] of “I’ve got all these different stovepipes and no way to federate and look across them such that I can make those decisions.”

Does WebTAS-TK deliver the data, analyses, and so on in real time?

HOUGHTON: It’s real time. It can operate transactionally. So as a database or data source gets updated in real time or when a table gets data added to it or updated, or a Web service fires an event to say “Hey, something has changed,” the software can make a real-time update to the displays and the analytics and notify the operator. I know you’re talking embedded systems, so when you talk “real time,” it may be on a different sort of scale or level, but in a database transaction level, we are real time. If there has been a transaction in the database, we’re talking less than a second that the other data is updated and the operator can be made aware there has been a change to a database table.

So the change notifications are automatically generated by the software?

HOUGHTON: Correct. So the services piece that we do is customization of the software to a particular domain. But we’re not a data producer.

Since your products are deployed to the military or government, is there a security feature built into the software?

HOUGHTON: Yes. There is a security manager built into the software and it does go through security accreditation by the appropriate government agency(ies) for deployment. Both CIDNE and WebTAS-TK go through accreditation for every release.

Can you tell me more about CIDNE – how it works or a real-life military scenario?

HOUGHTON: I can’t go into as much detail on CIDNE specifically. I am basically constrained as to what is in the public domain on the program. But we use Adobe ColdFusion; it runs on top of the Microsoft SQL Server database and allows people to enter events of interest and track those events over time and space.

Is it looking for just a preset, specific event like “I am looking for a man wearing a hat going into a building,” or does it look for similarities between events?

HOUGHTON: In and of itself, it is not an analytical program. It is really a database, a federated database of events. So really it’s a series of forms where people can enter events, and they really can be any kind of event. So it could be that we’ve got burglaries around San Antonio and I want to be able to track those burglaries for the police department. It will allow users to track who was involved, where the burglaries took place, geospatially and temporally, and gives you a standardized way of everybody entering that information. But that is just one class of events; you could have a thousand classes of events and you could track them all in a single database. That is really what the power of the thing is.

You said that military is using CIDNE now?

HOUGHTON: Yes, but I can’t really go into the details of that, unfortunately.

What would you say is the focus of your government and military customers? What are the trends?

HOUGHTON: I think what we see and again when you look at constrained budgets going forward, they don’t want to necessarily pay huge licensing fees for software. And then the ability for them to fund just development on the specific functionality that they want and the ability to rapidly get that functionality into their hands.

What else – any specific technology capabilities?

HOUGHTON: Yeah, the ability to provide ubiquitous data access and connect up to and federate all those data sources is something that is very attractive. The other functional thing that people like is the ability, for instance, to send output to Google Earth. Seemingly that is a very simple thing, but when you get in and say, “OK, I want to take Google Earth and I want to connect up to 50 different data sources with it,” there is not a way to do that out-of-the-box using just Google Earth – especially if those are relational databases with very complex data models. And so we have a lot of users that use us as kind of an intermediary to translate from all the databases they want to get at and send to Google Earth on the other side.

All the software your company designs – WebTAS-TK and CIDNE and your software for mobile devices – that’s ALL Government Off-the-Shelf?

HOUGHTON: That is correct. Everything we do is GOTS.

Would there be security issues in using GOTS software for commercial customers, if your commercial customers knew how to use the same software that government customers were using?

HOUGHTON: No, because the core software itself is rather innocuous. There are no security issues with providing that in the commercial space. We have gotten approval from the government to actually sell it as a commercial product, so they have gone through the security reviews and have no issues with it. We have also gone through the Commerce Department and gotten a commerce jurisdiction to sell it externally to foreign countries. And anytime we deal with potentially foreign military sales, we have to go through ITAR, which is, of course, a rather involved review before we can export anything.

Are there any new trends in open source software?

HOUGHTON: The biggest one that we are seeing is the transition to rich Internet technologies – and the trend over the past year to push toward more HTML5 functionality in the rich Internet application space and even in the mobile application space. With Adobe announcing this year that they are giving up on Flash runtime on the mobile devices and feeding that to HTML5, it’s really interesting. One of the best things with HTML5 is that it provides the ability to do all the things you can do with Flash in terms of having a rich experience inside the browser (the ability to play video and to play audio and to have interactive content) – without having any plug-ins. HTML5 is still not a standard ratified by the World Wide Web Consortium, so Internet Explorer and Microsoft are still not fully compliant with the HTML5 spec. But other browsers such as Google Chrome and Safari are implementing all the functionality.

The other huge growth area that we are seeing is just Android being proliferated as an open source operating system on mobile devices and really providing an [alternative] to iOS. The fact that you have an open source operating system in a mobile space is very attractive. So I think the proliferation and growth of Android and in particular in the tablet space is going to be interesting as they try to compete with the iPad and iOS.

Carl Houghton, Vice President, Strategic Initiatives & Advanced Technology at Intelligent Software Solutions (ISS), is responsible for facilitating strategic business development goals across numerous business units in the company. Carl is a combat veteran of the U.S. Air Force. He flew more than 2,000 combat hours in support of operations in the Middle East and Bosnia and Herzegovina. He has a Bachelor’s of Science in Information Technology and is a graduate with honors from the Defense Language Institute in Modern Standard Arabic. Contact him at carl.houghton@issinc.com.

Intelligent Software Solutions 719-457-0690 www.issinc.com

]]> http://tech.opensystemsmedia.com/embedded-software/2012/03/open-source-clears-up-the-military-stovepipe-mess-interview-with-cal-houghton-vice-president-strategic-initiatives-advanced-technology-intelligent-software-solutions/feed/ 0 http://www.mil-embedded.com/articles/id/?5578 http://www.mil-embedded.com/articles/id/?5578#comments Wed, 07 Mar 2012 15:00:00 +0000 Dr. Benjamin Brosgol, AdaCore http://tech.opensystemsmedia.com/embedded-software/?guid=dc7970dc74b6e85c6a2929b361994c0b

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.

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.

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

]]> http://tech.opensystemsmedia.com/embedded-software/2012/03/trusting-the-tools-an-agile-approach-to-tool-qualification-for-do-178c/feed/ 0 http://www.mil-embedded.com/articles/id/?5581 http://www.mil-embedded.com/articles/id/?5581#comments Wed, 07 Mar 2012 15:00:00 +0000 Dr. Andrew Coombes, Rapita Systems http://tech.opensystemsmedia.com/embedded-software/?guid=63c71724cdc9443d781d750245cb3b73

The ongoing success of military embedded systems on land, sea, and air depends on the ability to modify the systems to meet emerging requirements. Over time, accumulated modifications to software-based systems result in degradation of the performance of that system. Eventually, the resulting performance degradation leaves system developers with the choice of either abandoning planned new features or replacing the hardware and accepting early obsolescence. There is an alternative. Automated performance measurement and timing analysis technology provide developers with the tools to optimize away much of the performance degradation resulting from accumulated modifications, thereby avoiding either abandoning features or early obsolescence.

Military embedded systems are typically enhanced many times during their lifetime. Many of these enhancements are software updates. Over time, the software updates cumulatively increase the demands placed on the computing platform. This can lead to the hardware’s capabilities becoming insufficient to meet application demands, potentially resulting in intermittent failures.

System developers then face the difficult choice of either abandoning planned new features, leading to capability decay, or replacing the hardware (that is, early obsolescence).

A viable alternative requires the identification of high-impact, low-risk strategies for optimizing software, thereby maximizing the service life of the computing platform. This alternative includes automated performance measurement and timing analysis.

The problem of performance

Military embedded systems, and especially avionic systems, such as the BAE Systems Hawk’s mission control computer, are often real-time embedded systems. Real-time systems are distinct because their correct behavior depends both on their operations being logically correct, and on the time at which those operations are performed. Engineers developing these systems must be able to provide convincing evidence that the software always executes within its time constraints.

The nature of software means that every time it is executed, it could take a different path through the code, leading to different execution times. Even when using the system in the same way, differences in the internal state could mean that the user sees widely varying execution times. Because of this, it is entirely possible to rigorously test software without seeing any timing problems, then to encounter a situation in actual use that results in significant timing problems. So to be sure a system always meets its execution time, it is necessary to establish its Worst-Case Execution Time (WCET), which is also a consideration for DO-178B.

Finding Worst-Case Execution Time

Measurement is an approach often taken to obtain confidence in the timing behavior of a real-time system. To measure timing, engineers typically place instrumentation points at the start and end of sections of code they wish to measure. These points record the elapsed time, either by toggling an output port (monitored via an oscilloscope or logic analyzer) or by reading an on-chip timer and recording the resulting timestamps in memory.

Unfortunately, these high-water marks might not reflect the longest time that the code could take to execute. This happens when the longest path through the code has not been exercised by tests, as illustrated in Figure 1. Two tests, represented in Figure 1 by the green path and the blue path, are run. The observed execution times from these tests are 110 and 85 respectively. Despite these tests executing all code in the software, there is a third path (shown in red), which has an execution time of 140, making it the longest path.

This example shows that simply executing all code isn’t enough to exercise the longest path. For nontrivial code, it is very hard to devise tests that are certain to drive the code down its longest path. This situation can be avoided by adding instrumentation points at each decision point in the code. Whenever an instrumentation point is executed, its ID and a timestamp are recorded. Running a series of tests on the system results in the creation of a timing trace. Combining the timing information from the trace with information about the structure of the code makes it possible to find information about the timing behavior of the software, including predictions of WCET.

For typical military applications, which can run into millions of lines of code, it would be extremely laborious to instrument programs by hand; moreover, the volume of trace data typically produced would make manual attempts to combine trace data with program structural information infeasible. Fortunately, the tasks of program instrumentation, trace processing, combining trace data with program structural information, and data mining/presentation are all amenable to automation. RapiTime from Rapita Systems is an automated performance measurement and timing analysis technology that helps solve the challenge of obtaining detailed timing information about large military embedded systems implemented in C, C++, or Ada.

Performance optimization

Knowing the WCET is only one part of the solution: When faced with the problem of a software component that overruns its execution time budget, it is essential that a systematic, scientific approach is taken to optimizing the component’s performance.

Software performance optimization requires three questions to be answered:

• Where is the best place to optimize?
• Is the proposed optimization making an improvement?
• How much improvement can be made?

Where is the best place to optimize?

In a typical complex application:

(1) Most subprograms are not actually on the worst-case path; they contribute nothing to the worst-case execution time. Optimization of these subprograms would not reduce the WCET at all.

(2) Many subprograms contribute a small amount to the WCET and so do not represent good candidates for optimization. Effort spent optimizing these subprograms would not constitute an effective use of resources.

(3) A small number of subprograms contribute a large fraction of the overall WCET (Figure 2). Therefore, the subprograms are potential candidates for optimization.

By inspecting WCET information, engineers can easily identify a relatively small number of components where optimization could potentially have a large impact on the overall worst-case execution time.

Am I improving things?

It is sometimes tempting to try to short circuit the analysis process by guessing where the worst-case hotspots are, optimizing that code, and then seeing what the effects are. However, the experience of software optimization tells us that even highly skilled software engineers with an in-depth understanding of their code find it almost impossible to identify the significant contributors to the WCET, and hence the best candidates for optimization, without access to detailed timing information.

Often it seems so obvious – “It must be that section of code that makes all those floating-point calculations that is the best candidate for optimization” – when actually, some innocuous-looking assignment hides a memory copy that is taking nearly all of the time. The answer to this problem is simple: Don’t guess, measure. Then repeat the measurement to quantify the improvement (or lack thereof).

How much improvement can be made?

Table 1 indicates the level of improvements in Worst-Case Execution Times that can be obtained through a simple process of software optimization. These results were achieved using RapiTime technology to provide detailed timing information on the mission computer of a BAE Systems Hawk. These optimizations led to an overall decrease of 23 percent in WCET.

The benefits of WCET and performance optimization

Access to automated performance measurement and detailed timing analysis during the modification of military embedded systems can provide a number of advantages to the developer:

1. A systematic and scientific approach is utilized in obtaining confidence in the system’s timing behavior.

2. Detailed information about worst-case execution time allows candidates for optimization to be quickly identified.

3. Automated measurement allows the effectiveness of candidate optimizations to be assessed.

The ability to do the best possible timing optimizations means avoiding making the hardware unnecessarily obsolete and eliminating the need to abandon planned new features or replace the hardware and accept early obsolescence.

Dr. Andrew Coombes is Marketing and Engineering Services Manager at Rapita Systems. For the past 15 years, he has helped develop and commercialize software tools for embedded, real-time applications. He received his DPhil in Computer Science at the High-Integrity Systems Engineering Group at the University of York (UK) before working in a consultancy and for the BAE Systems Dependable Computing Systems Centre (DCSC). Contact him at acoombes@rapitasystems.com.

Rapita Systems +44 1904 567747 www.rapitasystems.com

]]> http://tech.opensystemsmedia.com/embedded-software/2012/03/automated-performance-measurement-and-timing-analysis-help-military-embedded-systems-avoid-early-obsolescence/feed/ 0 http://www.mil-embedded.com/articles/id/?5580 http://www.mil-embedded.com/articles/id/?5580#comments Wed, 07 Mar 2012 15:00:00 +0000 Paul Anderson, GrammaTech http://tech.opensystemsmedia.com/embedded-software/?guid=12dd6153af04a69f0be98ce7cc584c7b

Multicore processors are becoming increasingly popular in safety-critical applications because they offer significant price and performance improvements. However, writing multithreaded applications for multicore hardware is notoriously difficult and could result in catastrophic failures. The following describes symbolic execution techniques for identifying issues including data races – one of the most common concurrency defects – and how static analysis can help developers find and eliminate them.

Maximizing performance is especially important for military embedded systems because of the growing need to keep costs low while satisfying the requirements of connectivity in an increasingly digital battlefield. As manufacturers reach the limits of what can be wrung from increased miniaturization and integration, the best approach to increased performance is the use of multicore processors.

The downside is that to take full advantage of many cores executing in parallel, the software must be written to be intrinsically multithreaded. Software written to be single-threaded for a single core processor will realize little or no performance benefit when executed on a multicore processor: It must be rewritten or adapted to use multithreading. The key challenge is to keep the cores busy as much as possible, while ensuring that they coordinate access to shared resources properly. Unfortunately writing such code is much harder than writing single-threaded code. When there are defects such as deadlocks or race conditions, they can manifest in ways that are difficult to diagnose. Traditional techniques for finding and eliminating concurrency bugs may be ineffective.

One of the core reasons why concurrency bugs are so difficult is because there is an enormous number of ways in which the events in the threads can be interleaved when those threads execute. As the number of threads or instructions increases, the number of interleavings increases exponentially. If thread A executes M instructions and thread B executes N instructions, there are N+MCN possible interleavings of the two threads. For example, given two trivial threads with 10 instructions each, there are 184,756 possible interleavings of those instructions. Even with very small programs it is clear that it is next to impossible to test all possible combinations. Secondly, even if it is possible to identify a single interleaving that leads to a failure, it can be very difficult to set up a repeatable test case that uses that particular interleaving because scheduling of threads is effectively nondeterministic. Consequently, debugging concurrent programs can be very expensive and time consuming. A race condition is a class of concurrency defect that is easy to accidentally introduce and difficult to eliminate with conventional testing. However, there are techniques programmers can use to find and remove them.

Potential catastrophic failures

Compared to single-threaded code, entirely new classes of defect can occur in concurrent programs, including deadlock, starvation, and race conditions. Such defects mostly cause mysterious failures during development that are very difficult to diagnose and eliminate. One avionics manufacturer we have worked with spent two person-years applying traditional debugging techniques in an effort to find the root cause of an intermittent software failure that turned out to be a race condition. Sometimes the consequences can be dire – two of the most infamous software failures ever were caused by race conditions. The Therac-25 radiation therapy machine featured a race condition that was responsible for the deaths of several patients[2]. Similarly, the 2003 Northeast blackout was exacerbated by a race condition that resulted in misleading information being communicated to the technicians[3].

There are several different kinds of race conditions. One of the most common and insidious forms – data races – is the class of race conditions involving access to memory locations.

A data race occurs when there are two or more threads of execution that access a shared memory location, at least one thread is changing the data at that location, and there is no explicit mechanism for coordinating access. If a data race occurs it can leave the program in an inconsistent state.

Consider avionics code that controls the position of a flap. In normal circumstances the flap is in a position dictated by the flight control software, but the pilot can override that position by pressing a button on his control panel, in which case a manually set position is used. To keep things simple, let’s say that there are two threads in the program: one that controls the flap and one that monitors the position of the elements on the control panel. There is also a shared Boolean variable, named is_manual, that encodes whether the manual override is set or not. The flap position thread checks the value of is_manual, and if true, it sets the position accordingly. The control panel thread listens for button press events, and if the override button is pressed, it sets is_manual to true. Figure 1 shows the code that one might write to implement this specification. This code is likely to work most of the time; however, because the is_manual variable encodes a state that is shared by both threads, it is vulnerable to a data race because access to it is not protected by a lock. If the flap positioning code is being executed at the exact time that the pilot hits the override button, then the program may enter an inconsistent state and the wrong flap position will be used. Figure 2 shows how this might happen.

This example neatly illustrates one of the properties of data races that makes them hard to diagnose: The symptom of corruption may only be observable long after the data race has occurred. In this case, the fact that the wrong flap position is being used may only be noticed when the pilot notices the aircraft is not responding as expected.

A widely held belief is that some instances of data races are benign and can be tolerated. However, it is now clear beyond doubt that this is only rarely true. The C standard[4] states unambiguously that compilers are allowed to assume that there are no data races, so optimizers can and do make transformations that are valid for improving the performance of single-threaded code but which introduce bugs when there are apparently benign race conditions. These are subtle effects – even experienced programmers are regularly surprised by them. (See reference [1] for a full explanation and several compelling examples.) Because of this, to achieve high levels of assurance and avoid disastrous failures, it is very important to find and remove all data races.

Eliminating concurrency defects

Given that concurrency defects, and data races in particular, are so risky, it is important to use multiple techniques to eliminate them. Traditional dynamic testing is not well suited for finding many concurrency defects because of non-determinism. A program that passes a test hundreds of times may later fail in the same environment with exactly the same inputs because the bug can be exquisitely sensitive to timing. Engineers looking for high assurance must turn to other techniques if they are to eliminate concurrency defects.

Static analysis tools offer a means for finding such bugs. The key difference between testing and static analysis is that it tests a particular execution of a program for a given set of inputs, whereas static analysis finds properties that are good for all possible executions and all inputs. (In practice, static analysis tools make approximations to achieve acceptable performance and precision, so fall short of this ideal model. Nevertheless, they do cover many more cases than would ever be possible with traditional testing.)

Roughly speaking, static analysis tools work by creating a model of the program and by doing a symbolic execution of that model, looking for error conditions along the way. For example, GrammaTech’s CodeSonar static analysis tool finds data races by creating a map of which locks are held by which threads and by reasoning about the possible interleavings that could result in unsynchronized access to shared variables. Deadlock and other concurrency defects (including lock mismanagement) are found using similar techniques.

Custom concurrency constructs: A case study

Standard defect detection techniques are most useful when programs use standard ways of managing concurrency. Most tools recognize and can reason about the special properties of standard libraries such as the POSIX threads library or proprietary interfaces such as VxWorks. However, many systems use custom techniques for managing concurrency.

For example, another manufacturer we worked with built a safety-critical device on a platform that used a custom pre-emptive multithreaded software interface. In this design, a key constraint was that all data instances that could be accessed from multiple priority levels of threads had to be protected with proper guard constructs. Prior to using static analysis, validating that this constraint was respected required a person-month of manual analysis. To reduce the cost, they sought a solution by turning to static analysis. An important property of modern advanced static analysis tools is that they are extensible: They provide an API with abstractions that make it convenient to implement custom static-analysis algorithms. Using CodeSonar’s API, they were able to program a solution that piggybacked on the algorithms used at the core of the existing analyses to find locations in the code where the design constraint was being violated. The resulting tool, implemented as a plug-in, is able to find violations of the key constraint automatically, all at a fraction of the cost and in much less time than was previously possible.

Multicore trade-off

There are compelling reasons to move to multicore processor designs, but the risk is that doing so introduces the possibility of concurrency defects in the software. These are easy to introduce – even apparently innocent code can harbor nasty multithreading bugs – and notoriously difficult to diagnose and eliminate when they occur. Traditional testing techniques alone are inadequate to ensure high-quality software, mainly because of the high degree of nondeterminism. The use of advanced static analysis tools that use symbolic execution is one approach that can help because such tools can reason about all possible ways in which the code can execute. These tools can find defects such as data races and deadlocks in code that uses standard multithreading libraries, and can even be adapted to designs that use nonstandard concurrency constructs.

References

[1] Boehm, H.-J., How to miscompile programs with “benign” data races. In HotPar’11 Proceedings of the 3rd USENIX conference on Hot topics in parallelism.

[2] Leveson, N.G., An investigation of the Therac-25 accidents. IEEE Computer, 1993. 26: pp. 18-41.

[3] Poulsen, K., Tracking the blackout bug, www.securityfocus.com/news/8412.

[4] C Standards Committee (WG14). Committee Draft: www.open-std.org/jtc1/sc22/wg14/www/docs/n1539.pdf

Paul Anderson is VP of Engineering at GrammaTech. He received his B.Sc. from Kings College, University of London and his Ph.D. in Computer Science from City University London. Paul manages GrammaTech’s engineering team and is the architect of the company’s static analysis tools. Paul has worked in the software industry for 20 years, with most of his experience focused on developing static analysis, automated testing, and program transformation tools. Contact him at paul@grammatech.com.

GrammaTech, Inc. 607-273-7340 www.grammatech.com

]]> http://tech.opensystemsmedia.com/embedded-software/2012/03/symbolic-execution-techniques-identify-vulnerabilities-in-safety-critical-code/feed/ 0