A Standard individual: New year, new opportunities - Embedded.com

A Standard individual: New year, new opportunities


Last year was a bit of a struggle, but most in the UK seem to have come out of it well and, not withstanding some dips many are reporting, 2010 is looking good so far. Though some are saying that the economic crisis has hit some big long-term projects in aerospace and defence, so there will be a dip in 2011 to 2013. Hopefully by then, other sectors will have recovered enough to make up the difference overall.

As a new columnist to embedded.com, I was looking around some of the other columns. It seems that many of the same questions are asked on both sides of the Atlantic. Certification of tools and engineers, outsourcing, standards: both ISO and de-facto, piracy, copyright, patents and licensing of tools and software. I covered some of these issues in previous columns.

One thing I have noticed of late, probably due to the recession to some extent, is people looking for “free” tools and software. Now this may cheer the Open Source fraternity, but it is not what it seems. What people are looking for is something for free not only do they not want to pay any money, but neither do they want to bother with any license restrictions or obligations, feeding bug fixes back and helping the community, etc., let alone making their source code available.

Whilst some commercial tools and software are being pirated, so are the Open Source equivalents, but in a slightly different way. The problem is that whilst one is clearly illegal as it usually involves hacking or hacked software and passwords or license keys of dubious origin, Open Source piracy is less obviously as the source code is “free” and who reads the licence files with software anyway? The FSF is taking steps to reverse this for Open Source, but it's a drop in the ocean.

Another factor is that silicon companies are releasing more free software to generate microprocessor sales. This includes peripheral libraries, USB, TCP/IP, file systems, and all manner of example projects that contain far more code than ever before. They also put pressure on compiler companies and distributors to make the commercial tools available at a discount. I saw a comment from a couple of engineers that “if the silicon companies want me to use their chips, the tools should be provided free of charge.” Try suggesting to a software distributor that they give you free MCUs to help make a compiler/software sale.

The perceived value of software is dropping and this increases the subconscious idea that it should be free. This is not good for programmers and it won't help Open Source as the programmers will be expected to build and maintain the tools on their own time and not spend company time feeding back bug reports and going on-line to help the community. This is already happening. One company I know “re-organised” out some of its staff that were their Open Source gurus, as it was felt they were spending too much time helping others outside the company and “playing” rather than developing. They still use the Open Source tools, but staff is encouraged to chat with the community (support & maintenance) on their own time.

Think back to the “good old days” in other trades when you were expected to make your own tools on your own time and expense before starting a job.

I have started to see a bit more of the short-term accountancy coming in as well. People look at the cost to buy an item not the “total cost of ownership.” This has come up several times recently.

In one case, there were two development suites. One was a quarter the cost of the other. However, it became apparent some months into the project that the cheaper tool was less efficient in its code generation by a large margin. The code required additional memory chips. This costs not only the memory chips, but design time, added cost to the PCB manufacture—holes cost money—and more power required and more heat generated. On a build of 10,000 units per year, they were already into costs of five or six times the initial saving.

Then it came to test and debug; debugging with the cheaper tool is far less capable and harder to use than the more expensive one. There have now been weeks of project slippage and more in view. The cost in this part of the project alone has been about five man-weeks or the cost of two more of the more of expensive compilers, never mind the slippage on the deadlines.

In addition, the debug system in the cheaper compiler is less capable. Hence, it's not so easy to use, and the testing was not as comprehensive and the system is less reliable.

The saving of 1500 GBP at the start of the project will cost them around 10,000 GBP per year of production. It's more difficult to calculate the cost of a late and/or unreliable product. Ask Toyota what the damage is or ask Microsoft what Vista did to its bottom line. A late and unreliable product can change the profile of a company and give a competitor an advantage it may never loose. Read “In Search of Stupidity” to see how disastrous it can get.

The trouble I have found is that most engineers are as clueless about project control, resources, time lines, and presenting cost analysis as accountants are about software. Embedded engineers must be able to quantify things and present the financial arguments.Now don't tell me that software is an art. It is no more an art than architecture is. Architects design beautiful buildingswell sometimes! Their designs are artistic in the same way programming is an art form. However, they can also give you reasonably accurate costs for time, labour, and materials. Okay, they can't account for the weather or other external problems, but they are generally quite accurate in their own space.

So why not embedded engineers? Part of the problem is estimation, and software people are not very good at it (yet), but there is really no excuse. For example, a developer should be able to show the benefits of buying 10,000 GBP of static analysis tools: fewer bugs, shorter development time, and more reliable product. You should be able to show that spending 10,000 GBP on a tool will be cost effective. Or for that matter, implementing a “free” Open Source tool which will have different costs and impacts. There's another problem: is it worth 10,000 GBP to the project? Many tools will only be used on one project, while others will be used on many projects for years to come.

I took a course at school called Applied Maths. It was not particularly advanced as it was for students aged 14 to 16. It taught the basics of critical path analysis (our example was servicing an airliner), project planning, estimating, surveying, statistics, and finance. It has been absolutely invaluable and I think something similar should be part of all technical degrees. It gave me the ability and the perspective to play the accountants at their own game. All embedded engineers should be able to do that.

As an aside, I know a small contract company that has spent a lot of money on some tools and an RTOS for a family of MCUs and intends to base all their work on this. They said it was a risk, but after the next three projects, they will be making a larger profit for the foreseeable future from their increased speed of development and ability to re-use tested components from a good version control system. By planning, spending money, and thinking longer term, they are becoming more efficient and cost effective. They have stopped reinventing the wheel and have a box of components they can use.

The aftermath of the recession is the time to do it. Costs are at the front of everyone's minds. Don't let the accountants run rings around you. Get out the spreadsheet and take back control of your projects.

Chris Hills has extended experience in designing, implementing and supporting safety-critical and high-reliability embedded systems, both in the lab and in the field. He founded Phaedrus Systems to serve companies in that space with tools, methodologies, and consulting services. An active participant in standards bodies, including ISO C, C++ and IEC 61508-3, Chris was a principal author of MISRA-C:2004 and is a member of the MISRA-C2010 team and Chair of the MISRA-Languages group. He has written regularly on the standards scene and other areas for over seven years. For more information on Chris, go to www.phaedsys.com.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.