Embedded Systems December 2000 Vol13_13

Issue link:

Contents of this Issue


Page 193 of 197

BREAK POINTS Unhappily, the dream of the 'oftware IC seems dead, doomed by lack of interest, pricing problems, and quality concerns. In the embedded domain , quality is probably the major reason why devel- opers don't reuse code. When I ask developers why, for instance, they con- tinue to write the ir own RTOSes instead of buying one of the 100 or so commercial products , the first con- cern is "what if there's a bug? If! write my own I can debug it, even at 3 a.m." These are valid concerns, and clearly the vendors haven't adequately wres- tled with this issue. Several open-source RTOSes are available. Still developers write their own; sti ll I hear the same complaint, now modified to "well , if I write it myself at least I'll understand it when problems arise." Why is this? Is the old bugaboo, Not Invented Here, the root cause behind the failure of develope rs to institutionalize reuse? Once, in a fit of despair, u-ying to reach some understanding of these issues, I downloaded J ean Labrosse's pCI OS3 and ran it through a line counting program. Four thousand lines of C. Not so much, reall y, 4,000 lines. I could write that in, um, well , pretty quick I bet. Maybe not. Commercial firmware typically costs around $15 to $30 per lin e. That 4,000 lines might cost $100,000 to design, code, and test- a lot of money by any standard. So I'm cynical about the success of re use because out of the tiny amount of purchasable code that exists (like RTOSes), 50% to 70% of users chose to write their own. Perhaps, though, th e re latively rece nt focus on open source can thwart people's determination to write as much code in-house as possible. One sign of hope: people ask where they can get a TCP l IP stack now, in tead of immediately planning to write the ir own. I see fo lks ripping stacks out of Linux, for example. Perhaps this is a harbinger of future success. Open source quality? At September's Embedded Systems Conference, paneli sts discussed the pros and cons of open source and proprietary software. As always, each side had powe rful a rguments that leave me convinced there's plenty of room in th e market for any son of lice nsing scheme. But a question from the audience caught my atten- tion. "How can I trust your open- source code in my safety-cri tical appli- cation when anyone can make changes?" This is quite an inte resting twist from the paradigm that lots of eyes looking at the code equals high quali ty. The panelists returned, at best, ambiguous answers, nothing that gave me a feel ing of securi ty. Having looked at a fair amount of the open-source software myself, I'm struck by the wide dive rsity of coding styles, comme ntin g standards (o r lack thereof), and gene ral approach to writing software. Much of the source is frankly te rribl e, even if it wo rks. Some is beautiful. Given such a range how doe o ne ensure quality? Testing, whi le alway a vital part of any qualification process, is not, by itself, enough to guarantee the stuff works. Quali ty sta rts with a good specificatio n and design, is enforced by rigid standal-ds and inspections, and confirmed by rigorous tests that have been as carefully designed as th e software itself. Are we sure that the latest patch to, say, Linux meets all of those criteria? Puzzled by this inu-iguing question, I asked it of a Linux vendor. His an wer was as reasonable as it was sur- prising (surprising since the show floor was flooded with compani es pro- moting Linux as the solution to all embedded needs, from Internet-aware toaste rs to mart pi cture fl-ames). "Forget Linux for safety critical appli- cations," he said. "It's not certified to any standard, and is so complex it probably never wi ll be." Not being a Linux guru I have no idea how accu- rate the statement is, but coming frol11

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems December 2000 Vol13_13