With worldwide power consumption on the rise, utilities are faced with the challenge of providing more power while reducing environmental impact. Smart grids have emerged as a solution for managing output by providing electricity exactly where and when it is needed, thereby improving energy availability and reliability while improving regulatory compliance. ZigBee technology is at the core of smart grid functionality, as its low-cost sensors can be used to manage demand response and load control, automate meter reading, and provide real-time data, along with the additional capability of individually or simultaneously targeting specific groups of devices, including HVACs, water heaters, lighting, electric vehicles, and generation systems.

Until recently, ZigBee-style communicators have been dedicated devices with the sole function of reading sensors. With the standardization of the ZigBee Smart Energy profile by the ZigBee Alliance, however, there is an opportunity for tablet computers to incorporate ZigBee and become more relevant tools in the installation and maintenance of smart grids (Figure 1).

The challenge in designing a tablet computer for use within the smart grid is finding a way to bridge emerging technologies with the traditional functions of the utilities market, all while packaging it in a rugged device that can stand up to the elements and inevitable drops and spills in the field. There are several key design considerations for tablet computers used for smart grid applications, including the ability for the device to manage multiple functions, modularity, connection with the cloud, and ruggedness.

ZigBee explained

ZigBee specifies a suite of high-level communications protocols with small, low-power digital radios based on the IEEE 802.15.4-2003 standard for Low-Rate Wireless Personal Area Networks (LR-WPANS). It takes the IEEE 802.15.4 standard a few steps further with additional network and security layers, as well as an application framework. From this framework, the ZigBee Alliance also developed standards – technically referred to as public application profiles – that can be used to create multi-vendor interoperable solutions, which allow for customization and favor total integration. ZigBee advantages include:

• ZigBee uses the 2.4 GHz radio frequency to deliver a variety of reliable and easy-to-use standards anywhere in the world
• ZigBee sensors can run on harvested power or batteries. Users can expect an extended battery life that could exceed 10 years for very low-duty applications, such as automatic meter reading, when using common alkaline batteries in a typical ZigBee product. For higher duty applications, battery life can range from 100 days to three years
• Transmission distances are remarkable for a low-power solution, ranging from 1 to 1,000 meters (about 3 to 3,280 feet), depending on power output and environmental conditions such as other buildings, interior wall types, and geographic topology
• Multiple ZigBee sensors can be configured into self-healing mesh networks that extend the range of multiple sensors by miles

A more secure network

ZigBee offers Machine-to-Machine (M2M) communication, offering an advantage over Wi-Fi and WiMAX solutions that are costly and potentially less secure. Recently, some utilities have explored automatic meter-reading systems that rely on home Wi-Fi networks to push usage data and provide customers with Web-based control of thermostats. Customers, however, have balked over the companies’ perceived access to other personal information flowing through Wi-Fi access points.

In contrast, ZigBee is a more secure proposition, offering end users the same remote control of their thermostats by smartphone or computer, but ensuring the utility company is receiving only the information they are intended to get. Since data for entire neighborhoods is conveyed though a mesh network and individual addresses are assigned numerical codes no identifying customer information that could breech privacy – like addresses – is transmitted over the network.

Colonizing the smart energy space

ZigBee wireless networks have been in use for more than a decade, establishing it as a proven technology for a range of applications, including home and building automation, remote controls, healthcare, and retail services. Until the recent adoption of a standard ZigBee Energy profile, however, solutions in the smart grid/energy space had been mostly custom developments, relying on proprietary radios and communicators dedicated solely to the function of communicating with the ZigBee radios, which, for example, read meters.

In the last decade, the ZigBee Alliance began an incremental release of the ZigBee Smart Energy standard in order to create a global ecosystem of interoperable products – including meters, thermostats, outlets, load-control devices, and transformers – that monitor, control, inform, and automate the delivery and use of energy and water. The Smart Energy profile calls for the certification of products in order to provide assurance they will perform and can communicate with one another, regardless of manufacturer.

One tablet, many functions

ZigBee-enabled smart grids have added a layer of sophistication to utility operations, allowing for management of demand response and load control, automated meter reading, and identification and repair of outages. The ability to natively communicate with the devices that manage these functions is imperative, but to focus purely on incorporating ZigBee into a tablet is shortsighted. It is important to also consider how technicians use their equipment in the field, and then build on strategies for managing those technicians, maintaining fleets and inventory, and serving customers.

During smart grid installation, for example, some technicians carry a ZigBee communicator, laptop computer, GPS, measurement instruments, and a camera. Incorporating all of these on a tablet computer simplifies their jobs and cuts costs. As each data point is gathered, the tablet can be used to test and validate the new meter or transformer, document and pinpoint its exact location using location-based services and GPS, acquire the work order and communicate with the central office, scan equipment barcodes, access mapping data and manuals, and more in a single lightweight portable computer. Ultimately, combining these tools into a single device lowers purchase and maintenance costs for the end user by as much as 50 percent. Alternatively, a technician might carry a rugged laptop worth $3,000 (sometimes also with a data plan for $50/month), GPS worth $300, a handheld worth $1,000 (with a data plan for $50/month), measurement devices (such as an ohmmeter) worth $500 to $1,000, and a ZigBee programming device worth $500. The cost of a similarly equipped mobile tablet could be about half.

After installation, the same tablet can be used for reading meters, assessing outages, maintaining the network, and restoring power – all while providing the company a powerful tool for routing assignments to the closest technician, maintaining inventory, and geofencing.

There isn’t an app for that: The importance of modularity

Industry-specific tools such as measurement equipment often inhibit using a computer as the primary tool for field service. In many cases an installer or field technician will carry a computer as well as separate equipment to fulfill their job function; smart grid installers need an ohmmeter to test voltage, transformer technicians need equipment to test for vibration, and solar installers need a compass.

Modular design that affords the integration of key equipment into a tablet is the antidote to static designs that disallow change and custom designs that require expensive R&D. DAP Technologies’ M9010 tablet, for example, features a backpack design that allows end users to add their own circuitry to accommodate a range of tools and data inputs for custom solutions, or specify packaged solutions such as RFID (Figure 2).

(click graphic to zoom by 1.9x)

The future is in the cloud(s)

With ZigBee radios along the smart grid continually pinging data, cloud computing will play an ever greater role in managing the billions of bytes of data that are produced daily, providing real-time usage information to customers and technicians analyzing data in the field.

When designing a tablet for the smart grid, wireless broadband communication is imperative for accessing the vast quantities of data and providing field analysis. Field technicians might be sent to investigate repeat outages in a particular network. Using tablets to access the cloud, they could look for trends in peak consumption and use that data in conjunction with information from the ZigBee modules to correct the issue.

It is also important for the tablet to be compatible with the utilities’ existing systems. For most utilities, that means a Windows-based operating system.

Built to last

Any computer that is to be used in field applications must be built to withstand the elements and abuses that come with heavy outdoor use. In addition to remaining operational in weather conditions that range from driving rain, snow, and ice to humidity, blazing hot temperatures, and dust storms, tablets for utility applications should be safe for use around chemicals including acetone, crude oil, ISO-propane, diesel, oil, acetaldehyde, benzene, chloride, and more. Minimum requirements for rugged tablets in these applications should be IP67 – completely sealed against dust and water – and the ability to survive multiple 6-foot (1.8-meter) drops to concrete.

A multi-use, connected tool

Rugged tablets offer a lightweight, mobile, durable, and user-friendly platform for incorporating ZigBee into a solution that performs most of the required tasks for smart grid installation and maintenance. As ZigBee continues to gain prominence in smart grid applications and beyond, it is important to remember that incorporating this essential technology into a complete package will reap the most benefits for the user, both in terms of cost savings and field efficiency.

Khalid Kidari is Director of Product Management and Marketing at DAP Technologies. He oversees the company’s entire line of rugged tablet, handheld, and fixed-mount computers. DAP serves customers in industries that include field service, utilities, warehouse, supply chain, transportation, and logistics.

DAP Technologies K.Kidari@daptech.com www.daptech.com

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

The initiative’s medical history

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

The standard foundation

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

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

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

The future is green

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

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

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

References:

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

(click graphic to zoom)

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

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

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

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

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

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

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

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

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

(click graphic to zoom by 1.8x)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(click graphic to zoom by 1.9x)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(click graphic to zoom by 1.9x)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Qseven addresses graphics needs

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

(click graphic to zoom)

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

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

(click graphic to zoom)

APUs in action

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

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

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

Dan Demers is sales and marketing manager at congatec Inc.

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

“Because that’s where the money is.”

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

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

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

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

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

What happens in a buffer overflow?

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

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

(click graphic to zoom by 1.9x)

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

A simple example can illustrate what a stack looks like:

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

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

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

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

This should be executed first This should be executed next

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

In main(), it shows:

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

And in password(), it shows:

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

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

(click graphic to zoom by 1.9x)

Analyzing the attack

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

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

(gdb) disassemble main Dump of assembler code for function main: 0x0804840e <main+0>: lea 0x4(%esp),%ecx 0x08048412 <main+4>: and $0xfffffff0,%esp 0x08048415 <main+7>: pushl -0x4(%ecx) 0x08048418 <main+10>: push %ebp 0x08048419 <main+11>: mov %esp,%ebp 0x0804841b <main+13>: push %ecx 0x0804841c <main+14>: sub $0x4,%esp 0x0804841f <main+17>: movl $0x8048514,(%esp) 0x08048426 <main+24>: call 0x80483f4 <password> 0x0804842b <main+29>: movl $0x804851f,(%esp) 0x08048432 <main+36>: call 0x8048324 <puts@plt> ← Call to first printf() 0x08048437 <main+41>: movl $0x804853d,(%esp) 0x0804843e <main+48>: call 0x8048324 <puts@plt> ← Call to second printf() 0x08048443 <main+53>: add $0x4,%esp 0x08048446 <main+56>: pop %ecx 0x08048447 <main+57>: pop %ebp 0x08048448 <main+58>: lea -0x4(%ecx),%esp 0x0804844b <main+61>: ret End of assembler dump.

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

Sophisticated code testing

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

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

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

Data flow analysis

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

(click graphic to zoom by 2.8x)

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

Interprocedural analysis

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

(click graphic to zoom)

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

False path pruning

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

(click graphic to zoom by 2.7x)

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

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

Rutul Dave is senior development manager at Coverity.

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

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

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

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

1.  Total power requirement

2.  Amount of sun available at location

3.  Battery capacity

4.  Solar panel size

(click graphic to zoom by 1.8x)

Starting off with off-the-shelf

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

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

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

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

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

Step 1: How much power is needed?

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

(click graphic to zoom by 1.9x)

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

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

Step 2: How much sun is available?

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

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

Step 3: What size battery is needed?

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

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

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

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

Step 4: What size solar panel should be used?

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

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

Controlling system power

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

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

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

(click graphic to zoom by 3.5x)

Robert A. Burckle is VP of WinSystems.

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

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.

(click graphic to zoom by 1.9x)

(click graphic to zoom by 1.9x)

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

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

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

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

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

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

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

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

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

Board-level COTS

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

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

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

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

(click graphic to zoom by 1.9x)

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

COTS pedigree is important

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

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

(click graphic to zoom by 1.8x)

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

(click graphic to zoom by 1.9x)

Managing the avionics component life cycle

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

(click graphic to zoom by 1.8x)

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

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

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

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

Obsolescence can be managed

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

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

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

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

The DO-178C supplements

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

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

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

Object Oriented Technology and Related Techniques

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

(click graphic to zoom)

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

Model Based Development and Verification (MBD&V)

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

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

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

Formal methods supplement

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

Software tool qualification considerations

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

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

(click graphic to zoom by 1.9x)

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

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

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

DO-178C simplifies avionics development

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

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

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

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

LDRA 650-583-8880 www.ldra.com

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

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

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

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

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

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

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

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

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

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

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

Critical applications keep us moving

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

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

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

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

Software plays a major role in critical embedded systems

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

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

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

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

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

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

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

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

Initiatives drive improvements

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

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

Critical embedded systems: The cornerstone of the future

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

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.

(click graphic to zoom by 1.9x)

Reuse of previously qualified tools

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

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

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

Agile requalification

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

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

(click graphic to zoom by 1.9x)

Transitioning to the new qualification guidance

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

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

References:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(click graphic to zoom by 1.9x)

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

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

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

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

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

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

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

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

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

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

(click graphic to zoom)

Gwyn Fisher is CTO of Klocwork.

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

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

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

Standing on the shoulders of giants

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

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

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

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

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

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

•     Maximize data throughput (potential for more than 40 GBps

•     Minimize latency (copper track delays only)

•     Reduce FPGA design complexity (no additional protocol overheads)

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

•     Reduce system overhead (reduced power and cooling needs)

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

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

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

Rapid solutions

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

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

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

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

Fast flexibility

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

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

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

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

The work continues

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

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

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

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

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

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

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

A flexible future

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

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

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

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

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

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

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

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

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

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

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

Turning to COTS

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

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

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

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

Advantage of GPPs and FPGAs

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

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

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

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

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

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

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

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

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

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

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

FPGAs key in Air Force long-range surveillance radar upgrade

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

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

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

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

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

(click graphic to zoom)

(click graphic to zoom)

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

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

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

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

Sensing technology for robotics

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

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

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

Mixed-signal SoCs are key

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

(click graphic to zoom by 1.9x)

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

Mixed-signal SoC tech helps robots save the day

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

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

Cypress Semiconductor www.cypress.com

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

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

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

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

Beat frequencies in parallel arrays of DC-DC converters

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

(click graphic to zoom by 1.9x)

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

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

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

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

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

(click graphic to zoom by 1.9x)

Suppressing the beats

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

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

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

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

Input filtering tames AC input ripple current

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

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

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

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

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

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

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

Portable simulators for any platform

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

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

(click graphic to zoom by 1.9x)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

One GPS for you and your UAV

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

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

(click graphic to zoom by 1.8x)

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

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

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

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

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

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

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

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

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

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

Secure smartphones and a tactical app store

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

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

(click graphic to zoom by 1.9x)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Custom versus COTS

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

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

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

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

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

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

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

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

(click graphic to zoom by 1.8x)

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

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

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

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

Power electronics for space

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

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

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

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

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

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

(click graphic to zoom)

(click graphic to zoom by 1.9x)

VPX power solutions in demand

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

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

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

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

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

(click graphic to zoom by 1.9x)

(click graphic to zoom by 1.8x)

Radar and sonar are mainstays and pervasive applications for military platforms worldwide. More recently, these Digital Signal Processing (DSP)-based systems provide a sophisticated foundation for missile defense – searching, tracking, and launching with great precision. System demands are increasing even further today, as systems must simultaneously locate and discriminate targets through tracking and identification to launch effective and appropriate countermeasures. At the same time, the Size, Weight, and Power (SWaP) of systems is required to decrease; for example, functionality previously implemented by 19" rack-mount servers installed in a pressurized wide-body aircraft must now be implemented in a ½ ATR on an Unmanned Aerial Vehicle (UAV). DoD requirements add to this growing challenge, mandating that systems are flexible and upgradable to respond to new threats and new applications. COTS-based systems gain an advantage here, as tech insertions to upgrade to the latest CPUs and communication technologies will be necessary during the lifetime of these deployed systems.

In response to this paradigm shift, depending upon the particular application, DSP-based radar and sonar systems can be achieved by using virtually every blade form factor available today; 3U/6U CompactPCI, VME, MicroTCA, or 3U/6U VPX can all be implemented with success. Additionally, contractors and manufacturers are responding to the latest challenges by offering a greater array of technologies for high-end DSP computing, including standards-based CompactPCI and VPX options. While high processing power is a common requirement, one COTS computing architecture does not fit all radar and sonar applications. It is usually the communication topology of the specific radar and sonar applications that suggests the optimal COTS computing architecture. Examples of CompactPCI and VPX illustrate this point.

Digital Signal Processing in action

The bulk of the computation in radar and sonar applications involves DSP. The essence of DSP is to efficiently transform a stream of data into relevant information quickly enough to be highly useful and applicable. In radar and sonar applications, for example, this may mean processing incoming electromagnetic or acoustic signals to determine the location, speed, and direction of potential threats, targets, and terrain while filtering out irrelevant data such as a small bird or fish.

Processing the data in an appropriate timeframe requires a high amount of computing power as well as the ability for each compute node to communicate with other nodes. The amount of processing and communication required is highly application dependent, varies widely, and likely increases with each tech refresh. But the topology of the communication is generally fixed, and that is the most likely discriminator in determining the best COTS architecture for a given application.

Figure 1 shows the communication topology of two real-world DSP applications. Each node in these topologies is a compute node, which is a sequence of transforms and filters implemented on one CPU node. The arrows represent data flow (communication), with darker arrows indicating higher bandwidths. For simplicity’s sake, only the higher-speed data plane communication is shown; each application also used GbE for control plane communication. Topology 1(a) was used for a sonar-based mapping application, while 1(b) was used for a high-end radar application for real-time use in theater.

(click graphic to zoom by 1.5x)

For each communication topology, an appropriate COTS-based architecture was selected and implemented to meet the application requirements while still optimizing for SWaP.

CompactPCI meets the challenge in underwater sonar

The topology shown in Figure 1(a) for the sonar application reflects a typical “well-behaved” DSP application. The bulk of the communication is essentially a pipeline, with data flowing from one node to the next.

The digitized sonar data from the sensors is front-end processed by the left node, which then passes the data to a bank of three main compute nodes. Each of these implements a series of transforms for beamforming and filtering. The final node consumes all the data and synthesizes it into a spatial representation. The required bandwidth between nodes was less than 1 GBps in the main direction of dataflow [heavier lines in Figure 1(a)], with the backflow and control plane communication links requiring much lower bandwidths.

Given this topology, conduction-cooled 3U CompactPCI was chosen as the optimal COTS architecture for this application based on its small size and relative simplicity. Routinely considered a bus-based architecture, CompactPCI also supports multiple GbE communication links over the backplane, which was essential for this sonar application. Although originally implemented with dual-core processors, the COTS approach and a consistent pinout from generation to generation will allow this deployment to be extended, using multiple quad-core boards if and when higher precision is required for a technology refresh.

6U VPX for military radar

Conversely, the radar application’s communication topology shown in Figure 1(b) is much more complex. It requires many nodes, all able to directly communicate with each other at high bandwidths.

Sensor data is injected via high-speed links (>5 Gbps) in parallel to each six-node cluster. Within each cluster, a mesh topology allows the nodes to operate as a tightly coupled supercomputer, communicating with each other at >10 Gbps bandwidths. The clusters, in turn, require high-speed communication with the other clusters, also in a mesh topology.

The sheer number of high-speed data connections suggests that a switched-serial topology would be required, provided the data switches allowed enough bandwidth for all nodes to simultaneously communicate at full speed. VPX was a logical architectural choice because it allows for multiple high-speed interconnects; 6U VPX was selected specifically because its power envelope and Printed Circuit Board (PCB) real estate allow for two high-performance CPUs to be implemented in a single slot. Thus, each six-node cluster can be implemented with only three slots. This also makes the architecture scalable from a single six-node cluster in three slots up to 6 six-node clusters (36 CPUs in total) in 18 slots.

To handle the hierarchical high-speed communication topology, multiple data plane interconnect technologies were used. Within each cluster, PCI Express links provide high data throughput and a deterministic latency between CPU nodes. Between clusters, 10 GbE provides the required bandwidth and scalability. Figure 2 shows a simplified version of this as implemented on a 6U VPX architecture, including the aforementioned high-speed data plane links and the GbE control plane. Note that the architecture supports more connectivity than strictly needed to meet the requirements. Specifically, multiple 10 GbE links are available for each cluster, and nodes within adjacent clusters can directly communicate via PCI Express. These additional communication links currently go unused, but provide a valuable upgrade path looking forward.

(click graphic to zoom by 1.5x)

A potential challenge of this type of VPX architecture is software complexity, resulting from the use of multiple high-speed serial communication technologies (PCI Express, 10 GbE, and GbE), each with a different software interface. Kontron VXFabric removes the complexity of these high-speed protocols by providing an API for a thin layer of software that allows IP-based data transport over PCI Express. As a result, from the software’s point of view, each interface looks like a high-speed IP socket, regardless of the underlying electrical implementation.

Determining COTS DSP approaches

It is important to note that both VPX and CompactPCI support multiple communication topologies beyond those highlighted here. However, a convenient rule of thumb is that complex board-to-board interconnect topologies with multiple high-speed connections tend to lend themselves well to a VPX implementation; applications with more “well-behaved” communications tend to use less complex and more pervasive technologies such as CompactPCI. Only careful analysis can determine the optimal COTS architecture for a given application. Specifically, the communication topology is the discriminating factor pointing toward one architecture or another. Regardless of the underlying architecture, the COTS approach will allow future upgrades and seamless tech insertions well into the future.

David Pursley is Product Line Manager at Kontron. He is responsible for business development of Kontron’s MicroTCA, AdvancedTCA, CompactPCI, VME, and VPX product lines in North America and is based in Pittsburgh, PA.

Kontron

800-523-2320

www.kontron.com

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

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

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

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

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

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

(click graphic to zoom by 1.9x)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(click graphic to zoom)

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

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

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

(click graphic to zoom by 1.9x)

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

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

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

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

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

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

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

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

Varun Nagaraj is senior VP of product management at Echelon.

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

Today, the range of applications for microcontrollers (MCUs) is vast. While these ubiquitous computing engines advance in processing capabilities, peripheral offerings, and more efficient power consumption, the number of applications continues to increase at incredible rates.

As application requirements have expanded, so have key system components that reside on the microcontroller, one of which is the clock system. This system plays a critical role in a microcontroller and is vital to various aspects of overall system performance, including optimized power dissipation, accurate time keeping, communication interface clocking, and internal clocking requirements for other key components within the microcontroller.

Resources and requirements

The clock system can be considered a pool of resources, called clock resources (see Figure 1). Each clock resource is optimized for a primary purpose even though it can be used for various functions within the system. The clock system typically includes various clock sources, called system clocks. These system clocks are used to control various subsystem components such as the CPU, bus interfaces, peripherals, and data converters. Because application requirements can vary considerably, each system clock offers several clock resources.

(click graphic to zoom by 1.9x)

Given that a general-purpose MCU can be used in hundreds if not thousands of applications, the clock system must be highly programmable. This allows the clock system to be reconfigured as needed in a specific application. Some simple applications require only a static configuration, and the clock system is configured only once during initialization. Others require a dynamic configuration that allows the clock system to be reconfigured based on the application’s real-time behavior.

The types of clock resources available in the clock system are important. Applications have different demands needed to implement a particular function. For example, real-time clock systems require an accurate time base for keeping time over the application’s lifespan. Most clock systems have an integrated oscillator that supports the most common watch crystal available, 32,768 Hz. External crystals require the proper load capacitance to center the frequency properly and optimize start-up.

To reduce system cost, some microcontrollers integrate programmable load capacitors that allow for a range of capacitance values to support the most common crystal load requirements. Some systems already have a real-time clock resource available. For these systems, a bypass mode can allow this resource to be shared with the microcontroller. In a similar fashion, the microcontroller clock system can output a buffered real-time clock source to be used elsewhere in the system when required.

Microcontroller frequency range has increased dramatically in the past several years. Processing requirements have driven this expanded frequency range as software complexity levels have increased. Most MCUs have various methods for generating the high-speed clocks required in the system, most commonly with an embedded oscillator that requires no external components. This saves component cost and, more importantly, reduces the microcontroller’s pin requirements. The oscillator is typically designed to have good start-up times, as well as fairly tight tolerances on the order of 1 to 3 percent over voltage and temperature.

Finding faults and preventing errors

One critical aspect of the clock system is the reliability of system clocks, especially the processor clock. Ideally, the processor clock should be readily available at all times to ensure the application can recover from a system error that can lead to a deadlock situation. Because the clock system is highly programmable, it poses some risks by incorrect or inadvertent programming if code execution goes astray.

Most clock systems have password-protected access to all the critical clock system configuration registers. This minimizes the chances of an inadvertent configuration due to errant code execution. In addition, a good clock system should have other hardware mechanisms to prevent a deadlock situation.

A good example of this is proper fail-safe mechanisms for all crystal resources. External crystals or resonators can fail due to board wear, electrostatic discharge events, weak solder joints, and other reasons. If the processor system clock uses a crystal for its resource and it fails, this could cause clock loss, and a deadlock situation could occur.

To prevent this, most microcontrollers have hardware mechanisms that check if the crystal is operating correctly. Checks include non-oscillation or perhaps oscillation at the improper frequency range. Regardless, if a fault is detected, the system clock is automatically switched to a known, good clock resource, allowing the application code to continue to execute. Furthermore, an error condition is reported to the application, such as a non-maskable interrupt or a reset condition where the application can determine which action to take. This known, good clock source is often a fully embedded oscillator that is robust in terms of start-up characteristics and oscillation reliability.

Improving energy efficiency

Most MCU applications demand low or ultra low power. Because many applications use limited energy sources such as small, low-capacity batteries, product longevity depends on efficient energy usage. The best way to conserve energy is to use the proper amount of energy required at a given time and reduce all energy consumption to a minimum at all other times. This is the classic duty-cycle profile. In general, most vendors call this active time versus sleep or standby time. The longer the device can remain in sleep time, the less energy will be consumed overall.

Clock system design is critical to minimize energy requirements during sleep or standby operation. Most standby or sleep modes are characterized by the use of low-frequency clocks. Several options can provide this low-frequency clock operation.

The watch crystal is one such resource. It has a nominal 32 kHz operation, is very precise, and can be designed to operate at very low current consumption on the order of 500 nA or less depending on the crystal type. This is a good option if a watch crystal is already in the system, so no additional cost is incurred. If a crystal is not required, an embedded oscillator is another valid option that can be extremely low power, some as low as 100 nA.

These oscillators typically involve a trade-off in power versus accuracy. Higher accuracy often requires dissipating higher power. The oscillator is affected by temperature and voltage changes that could be important in some applications. Therefore, many microcontrollers have various clock resources for this purpose, some with higher power requirements yet improved accuracy or drift characteristics. These oscillators are robust and low cost and require no external components or pins.

Another important aspect of the clock system that can significantly reduce power is the clock distribution logic, which entails how the various clock systems are routed or distributed inside the MCU. Because clocking is a key factor in dynamic power consumption, it is critical that the clock distribution logic is completed in such a way to minimize unnecessary clock loading and clock switching. All system clocks should be gated off or held static when not required. In addition, only logic that requires a particular system clock should be seen as loads to that respective clock.

Many microcontrollers divide a particular system clock into several individual clocks, which only feed a specific module or peripheral. When a particular module needs the system clock, it will send a request and only the module that has requested the clock receives it, dramatically reducing overall dynamic power.

Flexible design for diverse applications

Many aspects are involved in designing a clock system for microcontrollers. The MSP430 5xx/6xx series of microcontrollers from Texas Instruments Incorporated (TI) contains many of the necessary components described previously. These MCUs support low-frequency watch crystal operation, as well as a broad range of high-frequency crystals. Both crystals have fail-safe logic and can be used in bypass mode. The clock system also contains an embedded oscillator with a Frequency-Locked Loop (FLL) for high-frequency operation with no external components. The FLL allows for any multiple of the low-frequency clock as its reference, providing flexibility in frequency selection.

An extremely low-power embedded oscillator of less than 100 nA is available for low-power, non-accurate, crystal-less clocking applications. A more accurate low-power embedded oscillator is also available for more stringent clocking needs. Furthermore, sophisticated clock distribution logic is offered with a highly flexible clock request system. All of these aspects of the clock system allow TI’s MSP430 5xx/6xx series of microcontrollers to serve a broad range of diverse microcontroller applications in a low-power, cost-effective manner.

Craig Greenberg is a systems developer in the MCU Division at Texas Instruments.

Texas Instruments Incorporated 972-995-2011 www.fb.com/texasinstruments https://plus.google.com/#104292131839044508100/posts @TXInstruments www.ti.com

Building control systems have traditionally employed miles of wires connecting the sensors and switches needed to monitor the environment within buildings. Battery-powered devices were sometimes added for hard-to-wire locations, especially in retrofit situations. However, the costs associated with battery replacement and disposal prohibited widespread market acceptance.

The EnOcean wireless standard overcomes many of the installation barriers that have stood in the way of making buildings more energy efficient. Building automation products such as sensors, switches, and controllers based on the EnOcean wireless protocol are not only interoperable with each other regardless of the manufacturer, they are also interoperable with other communication protocols such as TCP/IP. The maturation and convergence of the EnOcean and TCP/IP communication protocols have led to a dramatic increase in the number of energy management options available to integrators.

Limitless supplies of energy

Self-powered wireless sensors and switches implement energy harvesting technologies. The concept of harvesting energy from the environment is not new; wind and water have been sources of energy for hundreds of years. However, the concept of making a wireless and battery-less system has only recently been achievable.

The EnOcean energy harvesting model stems from a simple observation: Where building sensor data resides, sufficient ambient energy exists to power sensors and radio communications. Harvestable energy sources include motion, indoor light, and temperature differentials. These rudimentary sources provide enough energy to transmit and receive radio signals between controls and sustain vital communications within an energy management system. Instead of batteries, EnOcean-based controls use miniaturized energy converters to supply power to building energy management devices.

Harvesting motion, indoor light, and temperature differences

Three types of energy harvesting techniques are optimized for use in today’s buildings (see Figure 1):

• Kinetic: Harvesting energy from motion
• Solar: Harvesting energy from indoor light
• Thermoelectric: Harvesting energy from differences in temperature

(click graphic to zoom by 1.9x)

Implementing a wireless energy harvesting system

Building Automation Systems (BAS) reduce energy consumption in buildings on average 40 percent when smart sensors and controls are in place. However, most buildings still do not contain the controls necessary for managing energy, nor do they contain the cabling infrastructure needed to connect the essential sensors and controls. While widespread BAS integration has been hindered by several factors, self-powered wireless controls have overcome major hurdles, including:

• Expenses required for retrofitting existing buildings (installation costs, slow payback, complicated installations)
• Limited interoperability among devices
• Limited interoperability among communication protocols

These classic barriers have been overcome by wireless controls that power themselves using energy infinitely available in office building spaces.

Faster installations = faster paybacks

Wired devices are generally less expensive to purchase than wireless devices. However, installing wired systems, particularly in retrofit scenarios, entails considerably more labor and materials than it does for installing wireless systems. In a conventional wired installation, the process involves pulling miles of wire for sensors, switches, and controllers. Obstacles such as asbestos and impassable materials are frequently encountered when fishing wires through walls and ceilings. Additionally, wired retrofit installations can disrupt business operations and force building closures. Wired installations often require patching and repainting, which increase the amount of time and labor costs required for the installation.

Interoperability among devices

The EnOcean Alliance has created an ecosystem around energy harvesting wireless technology to develop an industry standard, continue product interoperability, and promote the technology among members. Interoperability of different end products based on EnOcean technology is an important success factor for establishing the technology in the market. For this reason, the EnOcean Alliance standardizes communication profiles, ensuring that sensors from one manufacturer can communicate with receiver gateways of another, for example.

Integrators and end users thus have the entire product portfolio at their disposal to meet their unique needs. Product manufacturers can focus on their own special field while contributing their particular niche to the market. Profiles of existing and upcoming types of equipment are defined in EnOcean Equipment Profiles. Visit the EnOcean Alliance website at www.enocean-alliance.com for more information on application-specific profiles.

EnOcean wireless technology is already established in building systems through standardized sensor profiles. A portfolio of more than 800 products creates interoperability among the different operating facets of a building. Worldwide implementation of EnOcean technology in hundreds of thousands of buildings has made it an industry standard.

Interoperability among communication protocols

Internet Protocol (IP) has now become a worldwide standard for over-the-Internet data communication among devices. One idea currently being discussed involves assigning every outlet and every filament lamp its own IP address and then connecting them over the Internet. What many do not know is that all electric loads today already can be addressed over an IP network enabled by battery-less wireless technology and matching access points.

Leveraging the strengths of both technologies will create long-term value by allowing the existing wired or wireless TCP/IP infrastructures to seamlessly add wireless devices for additional functionality and greater energy savings. As a practical, wireless extension of TCP/IP systems, EnOcean technology can lower cost of ownership in retrofits and new buildings. Many facilities have successfully deployed wireless systems in which EnOcean and TCP/IP technologies are interoperating to reduce installation and maintenance costs, along with providing energy savings beyond 30 percent.

EnOcean technology in action

Hotels are notoriously difficult to wire, and thus provide an ideal habitat for implementing energy harvesting wireless controls. For example, in lieu of ceiling lights, floor and table lamps are most commonly used for lighting since ceiling access is extremely limited. However, most hotel rooms are now fitted with TCP/IP and Ethernet or Wi-Fi connections.

This is an example where energy harvesting wireless controls truly shine. The self-powered controls can be installed without access to line power. The sensors can feed sensor data such as occupancy status into a TCP/IP backbone and allow the hotel’s lighting and HVAC control system to make smart decisions regarding energy usage and management. Furthermore, the energy management controls can be installed in hotel rooms in between guest stays, which is unheard of when strictly using wired controls.

Because hotel rooms are so often left unoccupied, they represent great potential for conserving energy. As illustrated in Figure 2, a hotel room energy system can use occupancy status data provided by the wireless controls to turn off lights and TVs, as well as change temperature set points to stop heating or cooling unoccupied rooms.

(click graphic to zoom by 1.9x)

These simple forms of lighting and HVAC control are low-hanging fruit in terms of energy conservation. As technology has made BAS easy to install, hotel owners can begin recouping dollars lost to energy mismanagement. An access point can receive data from wireless controls, then feed the system the information it needs to make smart decisions regarding energy management. When a guest enters a hotel room and inserts the key card into its dock, a radio signal is sent alerting the system that the room is occupied. When the guest leaves the room unoccupied, the removed key card automatically shuts off controlled lights and/or electronics and sets the in-room HVAC system back to its unoccupied/energy conservation mode. Hotels can cut energy consumption by 40 percent overnight by integrating wireless building automation controls.

Greater flexibility, lower costs

Together, the EnOcean and TCP/IP communication protocols provide buildings with unparalleled performance and flexibility. Wireless system providers such as Magnum Energy Solutions help bridge the communication protocols for the benefit of integrators and building owners.

EnOcean-enabled devices do not require line power or batteries and are therefore highly flexible in their positioning. Each wireless device has a unique ID address, so it can be integrated seamlessly in an IP network through an access point or gateway. This eliminates any elaborate or extra Web server systems for each sensor and actuator. A legacy network can be easily merged with energy harvesting technology to benefit from all its native advantages. The user is rewarded with more flexibility, comfort, and convenience, accompanied by low installation costs and reduced power needs.

More than 800 EnOcean-enabled energy harvesting products are now available worldwide. Building automation sensors and controls enabled by EnOcean include wireless switches, sensors, actuators, controllers, gateways, and building management systems. These products are available in both 315 MHz (for North America) and 868 MHz (for Europe).

(click graphic to zoom)

Jim O’Callaghan is president of EnOcean Inc.

Mike Giorgi is president of Magnum Energy Solutions.

EnOcean Alliance 801-943-3215 jim.ocallaghan@enocean.com www.fb.com/pages/EnOcean-Alliance/109269292485427 www.linkedin.com/groups?mostPopular=&gid=3578554 @EnOceanAlliance www.enocean-alliance.com

Magnum Energy Solutions 866-271-3961 mike.giorgi@MagnumES.com www.linkedin.com/company/magnum-energy-solutions-llc www.magnumenergysolutions.com