Embedded Systems Engineering
|
These are my own personal views and not those of my company Phaedrus Systems. The full version of this column resides at www.phaedsys.org, under the Technical Papers button.
Happy New Year! I trust you all had a restful Christmas and a break from the pressures of commerce.
Happy New Year! Yes, you are now a year late with your project… Well the MISRA-C team is! I have just come from our fist meeting of the year and we almost have the example suite complete. However it is the usual case where you get 90% of the work done in 10% of the time and the last 10% takes 90% of the time. Well, it is not that bad. We have completed all the examples now it is “just” tidying up so hopefully it should not be too long now. There will also be a Technical Corrigendum and our problem is whether to release the examples immediately or wait until we have completed the TC. This is because the example suite reflects clarifications that will be in the TC. In any event it should all be out “soon”.
As commented before this is an exemplar suite NOT a test suite. It contains compliant and non compliant examples but not every compliant or non compliant test possible. This would be an impossible task for the MISRA-C panel. Hopefully over the years the example suite will grow and become more of a test suite.
Perennial (http://www.peren.com/ ) who arguably produce the worlds best C test suite have, according to their web site, over 67,000 test cases, in 60+ Mbytes of code…. There is a cut down version with 8000 tests. Whilst the MISRA-C suite is not a C language test suite but an example suite for MISRA-C with 8 of us on the team we are not in a position to produce over 1000 tests each whilst working full time, besides we all have lives and families.
This is the problem with committees. Generally committees and panels meet periodically and you have to do work in between. However most committee members have jobs and real work to do. Unless your position in the company you work for is working on standards and related work you have to do most of the committee work in your own time.
This is The Lawnmower Syndrome I have been told about. In order to sell a lawnmower you have to adhere to some standards. Therefore all the lawnmower companies participate in the standard in order to make sure it is not railroaded by another manufacturer and permits them to sell their designs. This usually gets working standards out quickly because the industry needs the standard in order to make money. So their people work in company time and have resources.
The automotive AutoSAR is a case in point. Here many companies are spending real time and resources on the standard for the benefit of….. the people doing the standard. Many people have commented on the pros and cons of AutoSAR and who it is good for.
However as can be seen from the recent news about the US IEEE with their 802.20 networking group ( see:-http://www.eetasia.com/ART_8800427731_499488_6eed423c200608_no.HTM ) just because the industry want the standard and companies actively participate does not mean it is all plain sailing. The panel was suspended due to dark mutterings of unfair pressure applied by one or more companies. I don’t know if this is the case or if the company was applying normal input and no one bothered to argue against or did not realise the implications until later. I have seen that happen.
In the past a company has put forward something innocuous that over the years can be seen as the first nail in a strategic plan. By the time the majority can see what is happening it is too late the standard has already drifted that direction. Standards like super tankers are very difficult to turn around once they are moving. This might be happening to the C and C++ family of languages. Whether it is good or ill I don’t know at this stage. There are people saying it is a New Dawn whilst others are saying it is the End Of The World As We Know It. In any event the embedded world is still using various dialects of C90
An interesting item of news has reached me that ECMA is going to pull it’s ISO fast track for the C++/CLI standard. This may not seem that important to the embedded community. Had it gone through C++/CLI would have effectively become the standard C++ language used in Microsoft compilers and by default in Universities. So the new graduates would be learning a C++ that has major differences to the current C++.
However the reason for pulling the ISO fast track might be that Microsoft have realised that they don’t actually need an ISO standard to drive the market.
Whilst I am talking about suspensions: BSI has effectively suspended the BSI C panel. The last convenor managed to take some actions (mainly procedural, the handling of the mail reflector and the people on it) that placed BSI in an awkward position as they could not support all of the actions taken. So the convenor closed the C panel reflector, thereby killing all panel communications and resigned. This was over the summer. Most of the BSI C panel had better things to do with their time than get involved in the messing around. The current panel has gone from 28 members when I ran it a couple of years ago to (I think) 6 some of whom are not Sw professionals and are only really doing the panel as a “hobby” according to their biographies in other places. To make matters worse this little group are now trying to run their own standards panel without the support of BSI, the former panel or the industry. This should be interesting to see.
IT should have little impact as most of the industrial members of the BSI C panel have inputs to the International C panel via other routes.
Moving swiftly on as they say I saw an interesting posting on a completely unrelated newsgroup. It proved the requirement of automated static analysis as an absolute essential for C programming of any sort.
I used to show a series of slides with seemingly random letters spread across the screen some single letters other in apparently random groups but actually in order something like ”T heo the rte amre ga r dss our cec odel ay o uta sana rtf or m.” or “The other team regards source code layout as an art form” This was to show that uniform source code layout to a recognised standard made sense. The example below
Aoccdrnig to a rscheearch at an Elingsh uinervtisy, it deosn't mttaer in waht oredr the ltteers in a wrod are, the olny iprmoetnt tihng is taht frist and lsat ltteer is at the rghit pclae. The rset can be a toatl mses and you can sitll raed it wouthit porbelm. Tihs is bcuseae we do not raed ervey lteter by it slef but the wrod as a wlohe. ceehiro.
This suggests, or rather nicely demonstrates, that we see what we want to see within certain parameters. So if you transfer this to C code it will highlight the problem with code reviews. Often in a code review you only see what you want to. There is the well known single line if problem
If ( ON == alarm)
Close_doors(); Call_police(); Reset_system();
Many times at code reviews people have mentally put the braces around both lines “in” the if statement. This is why you need automated static analysis for semantics as well as syntax before you do the code review. At least then it should have removed most of the bugs. Normally around 80% of bugs can be statically detected according to most analysis I have seen.
With a consistent style and consistent is the keyword here you have more of a chance of actually seeing the things that are incorrect.
On style software engineers should be happy using what ever house style is used. In the grand scheme of things which style you use is irrelevant. What is important it is solving the engineering problem. However many programmers seem to have a hang up with using their style. I have seen more than once. Get over it and see the bigger picture.
Whilst on the subject of style a lot of the younger generation (now I am starting to sound like my Dad, who incidentally started computing when the number of computers in the UK was still in two digits), are starting to use txt spk or Text Speak in Usenet postings, emails and in general use. In response to the jumbled letters above the following was posted.
I DONT MIND NU ENGLISH WORDS BUT I INSIST TAHT THEY B SP3L3D COR3CTLY..AFTER AL TEH SPALNG IEDNTIFEIS TEH WORDS ORIGINS OR WUT ROTS..BY DA SME 2KAN I CANT STAND TEH MODARN TANDENCY 2 MISPEL WORDS SUCH AS THRU FOR THROUGH1!1!111 LOL FOR THOSE OF US WHO WER3 TAUGHT HOW 2 SP3L AND CORACTLY SUCH ABR3VIAETD FORMS LOK ALEIN AND ACORDNG 2 OUR 3DUCATION WRONG HOWEVER!1!! OMG TEH RULAS OF EVOLUTION DICTAET TAHT THAY WIL MOST LIEKLY BCOME TEH NORMAL SPELNG IN DU3 COURS311!1!!1! LOL THRU CAREIS AL DA M3ANNG OF THROUGH WIT A SAVNG OF THRE CHARACT3RS1!11!!! OMG DA AF3CT OF GLOBAL DIGITAL COMUNICATION WIL ONLY ACALERAET THIS PROC3S TAHT WUD OTH3RWIES HAEV TAEKN 30-50 YEARS 2 OCUR POSIBLY DOWN 2 LES TAHT 10 Y3ARS IT!!1!11! OMG LOL IS A LITL3 SAD TAHT SO MANY WORDS AND T3RMS TAHT HAD SIMILAR BUT SUBTLY DIFERANT MEANNGS IN TEH PAST HAEV D3G3NERAETD 2 SYNONYMS IN DA LAST F3W DECAEDS OUR LANGUAEG LOSNG MUCH OF ITS FLARE FOR SUBTLE NUANCE IN FAVOUR OF A TRUNCAETD SIMPLIFEID LEXICON!111111 LOL WEL SO B IT!11!11 OMG LOL
I think I can read it. If you have a problem reading it get hold of the nearest Cool Dude, Man…. (New Grad) to decipher it and yes “cool”, “dude” and “Man” are back not that cool was cool the first time around some 40 years ago!
Whilst I am looking at the new way Radio 4 had an item on Open Source where they talked to several Open Source software companies. The idea behind Open Source was explained and how wonderful it was. The fact that in the US it has taken off but less so in the UK . Interestingly they said that the programmers liked it but the management did not. I can understand why. The Management, project and team leaders have a schedule to keep to which involves getting a project out. Time is money. In several places where OS software is used I have been told the programmers can spend quite a lot of time adding patches and doing maintenance and not actually working on the project. The other problem is liability of course but I have covered that before.
However the reality of the Open Source became clear when the reporter asked one of the Open Source companies how they actually made money. Simple they sell support and packaged versions with installation programs. Yes you know that. They said that more and more people require support. This is because it requires quite a bit of support for patches, maintenance and bug fixes etc. Most companies want software that works without them having to work on it. They want to just use the software because time is money.
The Open Source companies are in fact a normal commercial software company except they don’t have to pay their software development teams. As was said they encourage the wide use of their freely available software packages because the more people who use it the more who will pay for support. Ie 10% of 10 is 1, 10% of 10,000 is 1000. Also as many businesses want a shrink wrapped package with an installation CD (for back up) and an automatic installation program they will pay the low cost for the package. This is why you can buy a shrink wrapped Red Hat to Suse packages even though the software is “free”.
As with any other software company the senior management and admin staff make money the few programmers required to maintain the installation package and those who apply the patches get paid but the large numbers of programmers who would have worked in the development teams are not part of the company…. They work for free.
It is a dream commercial scenario. The raw material is free and joyfully maintained for you at no cost. Therefore you can have low unit cost for package sales and just charge standard commercial rates for support.
Open Source has effectively reduced the value of a programmer just at a time when it is being compounded by outsourcing. Now tools and staff are cheap. At one time Software Engineers, as they moved from “scientists” to computer people, were almost on a par with other leading professions, now they have to fight to stay level with the sweat shops in emerging nations and much of it is by their own hands, or rather keyboards.
It is not the management who are suffering with lower pay rates and less professional status.
Eur Ing Chris Hills BSc CEng MIET MBCS MIEEE FRGS FRSA is a Technical Specialist and can be reached at This Contact
Copyright Chris A Hills 2003 -2008
The right of Chris A Hills to be identified as the author of this work has been asserted by him in accordance with the Copyright, Designs and Patents Act 1988