And from the reaction of the developers, architects, and defense and aerospace industry executives at the event, the need and desire for advanced productivity in how they procure, create, modify, and distribute software is acute. Remember, we're talking about a market that will explode to some 14 billion embedded software-enabled and networked devices over the next five years.
So two big take-aways from the event. The first is that Wind River has tapped a deep vein of developer interest with its testing and diagnostics capabilities that span, at present, its commercial RTOS, VxWorks 6.x, and its Eclipse-based tools, WorkBench. The addressable market of developers seeking an early test and diagnostics benefit (remember the earlier bugs are caught the less total cost), however, will expandinto the real-time Linux sector in Spring 2006 when Wind River enables the testing features to operate between its embedded Linux (2.6.14 kernel) target platform and WorkBench.
The WorkBench Diagnostics functions, which allows tweaks and fixes to running systems using lightweight agents called "sensor points," approach a true lifecycle benefit for test and debug of embedded applications. Testing has been especially laborious in embedded projects given that the application and platform targets are developed and customized in tandem, often uniquely for every device. Having early testing span commercial RTOSes and Linux is huge for houses where both types of targets are in use, which is, of course, increasingly frequent.
The second take-away from the event is the damned auspicious implications for the power and functionality of embedded systems when new software development exploits the threading capabilities in the new breeds of multi-core processors hitting the market. Intel is not shy about spouting off about how parallelism applied properly and richly to embedded systems allow for powerful concurrent processing and highly tuned memory use. The bottom line is that multi-core devices will soon be able to provide much greater intelligence and reliability.
The other bottom line, however, is that architecting applications to avail themselves well of parallelism is difficult and complex. The notions of thread checking, compiling to virtualized targets, and tuning apps and multi-threaded platforms are daunting. Hence the added importance of an automated test and diagnostic function for the next generation of embedded development and deployment projects.
Remember the 3D chess played by Spock and Kirk on Star Trek? Well, parallelism in embedded development requires a similar leap in complexity from 2D to 3D chess as monolithic development moves to threaded application modularity. COTS automation will become essential as hand-crafting code becomes untenable at scale.