Industry standard COM Express CPU module and dual XMC modules
Innovative Integration is a leader in signal processing and data acquisition hardware and software. Our products combine DSPs and FPGAs with high performance analog, ready for integration into demanding real-time applications such as wireless, medical, and military.

e-clips news alerts by keyword

by jason mcdonald, senior editor | read other blog posts

the embedded software crisis is here. more and more devices have more and more lines of code, causing the potential for everything from benign glitches to catastrophic failures. all the more threatening is the embedded software security crisis, which is just beginning. here are some thoughts about embedded software quality from the recent embedded systems conference, spring, 2009.

contents of this post:

1. the crisis of 'embedded software quality'
2. embedded 'static analysis' software
3. beyond static analysis?
4. feedback - read it
5. feedback - give it

the crisis of 'embedded software quality'

Almost everyone realizes that there is a crisis in embedded software. As devices become more complex, code expands in size, features creep upward, and consumers (as well as governments and militaries) demand more reliable code - the potential for all sorts of failure increases. These can be benign failures, as when a software glitch forces you to reboot your cell phone. They can be "business catastrophic" failures as when large manufacturers are forced to recall millions of shipped devices. Or they can be "safety catastrophic" failures when military, government, or commercial programs fail causing significant loss of life.

Aside: the guru who has written most on this is Jack Ganssle .

Unfortunately, most embedded software is still created in a very ad hoc way, with little thought to the long-term consequences of its software. Many of these devices are now becoming networked to each other and/or connected to the Internet - adding another level of complexity and new possibilities for failures. In addition, the security of these embedded devices is of increasing concern in a world of terrorism and commercial espionage.

Aside: Green Hills Software has made its name warning developers about embedded security risks, and has a whole line of new offerings designed to bolster embedded products against outside hacking.

But back to you and your software process. Are you looking at your software code? Does your company have some sort of coding standard system in place? If you are a programmer or manager leading a programming team, you should think seriously about how your embedded software is being created and what procedures you have in place for enforcing coding standards. If you are a manager, you should consider some of the new products and technologies on the market for detecting bugs before shipping as well as some of the high-level software methodologies that add new ways to prevent software failures.

embedded 'static analysis' software

At the recently concluded, Embedded Systems Conference , San Jose, I was fortunate to have several press interviews with leading vendors in the embedded software quality space. This helped to clear my head and think about the software creation process in embedded systems, and hopefully with this blog entry to help you (a designer) orient yourselves to the problems and possible solutions.

First, consider the software creation process. In simplistic terms, here are the basic steps:

1. Conceive of the device and its requirements - i.e., what is this device or application going to do?
2. Hardware selection - i.e., what is this device going to run on?
3. Software coding - i.e., turning the device requirements into an actual application all the way up from bare metal to application software.
4. Debugging and testing - i.e., testing and debugging in the laboratory to see if the device actually works, and if there are any foreseeable bugs.
5. Shipment - i.e., shipping the device out into the field, and praying - hoping - wondering if it works in the real world, like it worked in the lab.

Looking at it conceptually, there are therefore two basic ways to address software quality. One, improve the software process itself - i.e., improve/standardize your software coding methods and/or move to new methodologies and software standards to prevent bugs from being created. Or, two, check software after the fact to see if there are any bugs.

Ironically, the greatest effort these days is going into No. 2, checking software for bugs after it has been created. This reflects the innate conservatism of the embedded software industry, and our penchant for "legacy" code / code reuse. Right out of the gate, however, you should recognize that this method is intellectually inferior to preventing software bugs in the first place; and I would recommend that you look for vendors that can not just check for answers but also get your team to improve your software coding methodologies as well.

Aside: check out Michael Barr, an embedded software guru, whose company Netrino consults on software quality, and has just published a new book, Embedded C Coding Standards online.

The primary method here is Static Analysis , which basically means analyzing your software code without actually running the application. Here are some vendors that specialize in static analysis for embedded software:

• GrammaTech, Inc.
• PRQA - Programming Research
• Klocwork
• Rapita Systems Ltd.
• LDRA Technology Inc.

beyond static analysis?

LDRA Technology Inc. is perhaps he most interesting company of the bunch. It offers static analysis tools, but is transitioning to a more complete approach to the creation of embedded software. That company just released v 8.0 of the LDRA tool suite, which they claim to be the first fully automated end-to-end solution for software verification support. With the integration of requirements management, LDRA has enabled companies for the first time to trace, verify, and test their code through all stages of software development from requirements through static and dynamic analysis and testing.

The buzz word to focus on is "requirements management." Says the company:

By integrating requirements management into the LDRA tool suite using TBreq, LDRA’s tool for next-generation management and complete automation of requirements traceability, developers can reduce software errors, project costs, and resource constraints. TBreq creates a relationship between requirements, code modules, and verification artifacts (static analysis, dynamic analysis, unit- and system-level test). All informal changes and test results are recorded, and any requirements impacted by these changes are highlighted so that all team members can identify data and code which might be suspect.
(Details, here ).

Finally, especially if you are in high-end applications that really require software resiliance and quality (i.e., you have the budget for top-of-the-line tools), check out IBM Rational Software , which has acquired Telelogic which had previously acquired the Rhapsody family from iLogix. They are all about transitioning to object-oriented, UML as your software management process. The company has an excellent free webinar series, here .

feedback - read it:

feedback - give it:

	submit feedback to this blog post your name: your company (optional): your e-mail (optional): (Email will not be published!) please type your comment below, and hit send: IMPORTANT: to prevent spam, please re-type the letters that you read in this graphic: * graphic says:

Express Logic develops, markets and supports the ThreadX® real-time operating system (RTOS), NetX™ TCP/IP networking stack, USBX™ USB stack, and FileX® embedded file system, and PEGX™ GUI toolkit for embedded applications. ThreadX is a royalty-free, full source code, small-footprint, low-overhead RTOS that is extremely easy to learn and use. ThreadX is one of the most widely deployed RTOS products in the world, with over 700 million products based on ThreadX.