1. It's all about the software.
For mechanical and electrical engineers, whose education and experience revolve around hardware, it's hard to imagine that software could matter more than anything else. But in the embedded world, it does. Whether the project involves avionics, automobiles, phones, computers, thermostats, automation systems, or myriad other products, the brunt of the engineering will emanate from the software effort.
Ganssle estimates that 70 to 80 percent of electronic engineering time is devoted to software. Many products incorporate hundreds of thousands of lines of software code, and some use more than a million.
To figure out how that translates into engineering work hours, consider this: The average programmer writes about 200 lines of code per month. At that rate, a staff of 50 would need 100 months -- more than eight years -- to write a million lines of code.
Low-cost embedded applications that are less code-intensive can be served by microcontrollers such as Texas Instruments' MSP430 line. (Source: Texas Instruments)
"When it comes to embedded systems, software is the big engineering effort, period," said Bill Graham, product line manager for tools and lifecycle solutions at Wind River Systems, a maker of embedded operating systems. "Most experienced companies have a hardware group, which is a handful of people. And then they have a software group, which is a tremendous number of people." However, because newcomers to the embedded world almost universally underestimate the software contribution, more than a third of embedded projects are late or never delivered.
"We still hear about managers who say, 'Just change the code,' and then expect it to get done in an afternoon," Ganssle said. "But months go by, and they're still struggling with it."
2. It costs more than you think.
Cost is one factor that trips up even the most experienced embedded developers. After years of watching design teams underestimate costs, Ganssle cites this rule of thumb, which puts it in perspective: Each line of code costs between $20 and $40 to create. As a result, development of a product with a million lines of software code could cost $20 million to $40 million.
"Even people who are in the field tell me they don't believe it," Ganssle said. "But there's been way too much data collected and far too many studies done on this to argue it." Development teams who ignore such data do so at their own peril. And because so many of today's top engineers came to age in an era when software wasn't fully understood, the risks of underestimating software costs are great.
"Software is a relatively new field -- only about 50 or 60 years old -- and we're really still figuring it out," he said. "But the truth is that it's probably the most expensive thing in the history of engineering."
Great job, Chuck, highlighting the common misperceptions and challenges associated with embedded development. The whole notion that the development effort is predicated more around software design, not hardware design, is a huge cultural barrier for many engineering organizations which may lack a deep pool of expertise in that area and for years, have priortized and emphasized non-software related development.
The tools are also a huge issue. You talk about the need to invest in development tools specifically around writing embedded code. There also needs to be an investment in tools that integrate the embedded development effort with the rest of the product design effort, both mechanical and electrical components. If all the work is done in silos, you can run into intercompatibility problems and design snafus late in the cycle when it is expensive to make changes.
"Software is a relatively new field -- only about 50 or 60 years old -- and we're really still figuring it out,"
I think this is one of the best points in the article. This is a relatively unrecognized fact in the computer world. There is a lot about software that we are still trying to figure out.
Great article, Chuck. You have hit many of the major pinch points in embedded development.
I like your first point "It's all about the software" and your second - "Software is a relatively new field... and we're really still figuring it out". The difficulty arises from Moore's law -- with every 18-months the capability of each component doubles as we continue to innovate.
Five years late with their product? That's more than three generations out of date before the team launched their first product.
If the development team decided to use traditional "requirements-based" project management, they need to freeze the requirements and build to the original specification. But as most teams find out quickly, even if they don't change requirements for new technology, the requirements change because of unanticipated difficulties and incorrect assumptions made by the original designers.
May I suggest an initial "Zeroth Point" on your list: "0. Use an Agile Software Development Method". Once the team develops using Agile methods, the subsequent components on your list are still important, but can be altered with less difficulty. The smart-phone industry is one of the best examples of successful Agile development. Pushing software updates to the devices, new models with new features arriving often, and using standard ports and interfaces so upgraded devices can be swapped out with relative ease are slowly becoming the norm.
Charles, really good article and lots of good points!!
I know and have been on those projects that seem to keep going and going and begging for someone to put them down. Many good projects have over run budgets or just failed due to poorly written or no requirements or requirement creeping or engineer's free give aways.
If I had a .01 for every time I've heard an engineer say I can do this better and it would be nice to have this extra feature and just write it in without really understanding it is out of scope and most likely budget, I would be a millionaire.
I remember having to fight management to purchase good lab equipment to test our designs. It cost the company more money and the designers unnecessary time due to fighting with management to get what we needed to get the job done.
Very good point, Bill. The smartphone industry HAD to learn agile software development to survive, given their rate of progression of their products. Others need to learn to follow their lead.
Beth: As a former hardware guy, I feel comfortable saying this: Those of us who were educated in mechanical/electrical in the 1980s or earlier are have more trouble bridging that cultural barrier that you refer to. We've been trained to think in terms of hardware, and it's a tough habit to break. Maybe it's a bit of an ego thing, but it's tough to say, "Yes, software is the most important part of our product."
Great point about agile development practices, William. I'm hearing more and more about those as I start to dive into cloud-based design tools and mobile apps. It's definitely a mind set change. Hopefully, it's a practice being woven into new curriculum to help engineers get their arms around how to do it adeptly.
I went back to my last embedded project and tallied the hours and code, and the result was 50 lines of assembly-level code per 8 hour day, and this includes the algorithm development. This was a small medical device (2100 lines of code not including LUTs) where I did both the H/W and S/W. The S/W was real-time in nature due to a feedback controller.
So I think there are several caveats to the 200 lines per month number. It's no doubt accurate on large projects with a random assortment of programmers, and I find that just the problem of having multiple entities involved bogs the process down. In my example I had intimate knowledge of the H/W since I designed it as well, an advantage never afforded the typical project. But a factor critical to assess is the motivation and technical ability of the individuals involved rather than the use of a fixed line/day estimate; in fact I'd argue that using the smallest (carefully chosen) S/W staff possible has a significant benefit toward minimizing the development time.
To point #1 (all about SW) truer words were never spoken. A recent contract assignment involved placement of a Standardized (COTS) transceiver on a motherboard. One staff meeting discussion entertained the topic of eliminating the COTS transceiver in favor of a direct chipset embedded solution. Easier for the EE's; easier for the ME's. But the SW guys hit the ceiling, citing months of recoding development. All the points of your article are great checkpoints for whole teams and especially program managers to post on their walls for continuous awareness.
We recently posted an online slideshow called, “18 People You Didn’t Know Were Engineers.” Within hours of its publication, readers began to suggest names of other luminaries -- astronauts, politicians, athletes and actors -- who were educated or had worked as engineers.
In yet another sign that hydrogen is creeping into the consciousness of global automotive designers, sports car maker Aston Martin plans to run a hydrogen-fueled vehicle in a 24-hour Grand Touring race later this month.
One of the ugly truths of engineering is that life has a price. Cars, buildings, power plants, and industrial machinery can always be made safer for a cost, but manufacturers are at the mercy of the market.
Front-seat television technology is beginning to creep into the worldwide automotive market, but regulators, automakers, and suppliers say it’s unlikely to take hold in the US.
From Dell / Intel® New Paradigms in Design Work Scott Hamilton, vertical market strategist for Dell Precision workstations, 5/2/2013 3
Early in my career, I worked as a draftsman and remember the days of drawing on vellum with numbered pencils and Mylar with plastic lead. This was a fun experience in the sense that I ...
I've been using workstations for more than 10 years and love finding ways to get more performance from my system. With demanding professional applications that require more power each ...
A lasting memory from my first job as an engineer in an auto assembly plant is standing on hard concrete at six in the morning, vending-machine coffee clutched in hand, listening to ...
A quick look into the merger of two powerhouse 3D printing OEMs and the new leader in rapid prototyping solutions, Stratasys. The industrial revolution is now led by 3D printing and engineers are given the opportunity to fully maximize their design capabilities, reduce their time-to-market and functionally test prototypes cheaper, faster and easier. Bruce Bradshaw, Director of Marketing in North America, will explore the large product offering and variety of materials that will help CAD designers articulate their product design with actual, physical prototypes. This broadcast will dive deep into technical information including application specific stories from real world customers and their experiences with 3D printing. 3D Printing is
To save this item to your list of favorite Design News content so you can find it later in your Profile page, click the "Save It" button next to the item.
If you found this interesting or useful, please use the links to the services below to share it with other readers. You will need a free account with each service to share an item via that service.
Tweet This
25 
