原创 Some highlights of the Spring ESC

The recent Embedded Systems Conference (ESC) had an extraordinarily interesting mix of vendors. Some I'll feature later – like the intriguing new scope for the iPad and iPhone from Oscium, and a complete redesign of Microchip's IDE.

The Embedded App Store
But did you know the embedded world now has an app store? Or something similar. Express Logic's ThreadX kernel can now handle what they call "downloadable application modules." The idea is to cheat the linker; to completely isolate parts of a program from each other via the kernel.

These apps can be downloaded from, say, bulk flash into memory during execution of the program. They are independent and not part of the usual big monolithic executable. Communicating only via kernel API calls each application is independent of each other and of the main executable.

The up side is that the apps can live in protected memory. Any crash is mediated by the MMU. Changes don't require rebuilding the entire code base. One can conserve expensive memory by not loading an app till it's needed.

And then there's the concept of partitioning: one reason software productivity is not higher is that by building a single executable, we're caught on a trap of constant communication with our colleagues. Joe has to talk to Jill about how her code will interface with his. Partition the code into completely independent hunks and they can both work at a very high level of productivity.

Requirements
Poor requirements are an industry-wide bane. In the best of circumstances they're hard to elicit, which has led some to practically abandon the quest. But some regulated industries have very strong demands on how requirements must be handled. In avionics, for instance, requirements must be traceable to the code. If a requirement has no corresponding code, there's something wrong, and if the code can't be mapped back, it must be removed.

The current standard in the US for avionics is DO-178B. But soon – perhaps this year – this two-decade old gem will be replaced by DO-178C. According to FAA Consultants, among the changes is, as I understand it , the "requirement" that requirements must be traceable all the way down to the object code and back.

In the meantime the FDA is pretty much clueless about software engineering and uses an antiquated process to qualify medical devices. Why they don't simply replace all of the excess verbiage with the statement "DO-178C. Do that." is beyond me. But increasingly companies on their own volition are adding requirements traceability simply to insure they're building best-in-class software that will help the patients rather than their lawyers.

LDRA has updated their tool suite to support requirements traceability all the way from the source code to the object... and back up. This insures that despite an overly-aggressive optimizer, for example, the machine code matches the customer's needs.

There are quite a few traceability tools available, but to my knowledge LDRA's is the first to go to the object level.

Security
The nice folks at AdaCore directed me to a new NIST study. The government looked at C, C++ and Java for security vulnerabilities.

I found it interesting that NIST used SPARK, an Ada subset, as the baseline language since it inevitably leads to correct code. To quote: "There are languages that are, by design, more suitable for secure programming. We added SPARK as an example of one." While it's certainly possible to write great code in pretty much any language, the use of some lingos inevitably leads to better code.