I have to give the usual disclaimer that that these are my own personal views and not those of the ESE Editor and publisher. They are also those of my employer. I am working for myself! www.phaedsys.com

I had a quite a response from last months column! Thanks to all who emailed me, I intend to revisit the subject in a future column.

This month I am going back to the root of the column and looking at Standards. I should stress that these are my own personal observations and not in any way an official statement or committee view of any of the committees or panels mentioned. I also would like to say that I think Microsoft are a wonderful benevolent company with the best interests of the industry at heart… but first a quick round up of where MISRA is at.

The MISRA-C group has started on the example test suite. This is progressing well and we expect the usual 90/10 split. 90% of it done quickly and 90% of the time will be taken hammering out the last 10%. There is a wild rumour that we will actually have it finished for the end of 2006!. However that is hoping we can tie down the loose ends. The problem is we cannot show every possible conformant and every possible non-conformant solution. In some cases it is difficult to show a non-conformance without breaking other rules, this is called cross talk and means some of the example cases are going to be a little contrived. This is why it will be an Example Suite rather than a Test Suite or conformance suite. However it should clarify a lot of the rules. Any queries to the MISRA-C web site forum.

 

We are also looking at methods of delivery for the “Example Suite.” The trouble with source code is that anyone can edit it so you can never be sure the version you have is identical to the original. There has been discussion of having something like an official check summed or digitally signed version for a nominal sum from MISRA for people who need an “Official Version”.

 

We are also working on the Technical Corrigendum and by implication MISRA-C3. I have been around Standards work too long to be drawn into saying something stupid like MISRA-C:2006! Besides we want some longer term feedback on MISRA-C:2004. Any queries to the MISRA-C web site forum. It will take time for the tool vendors to catch up with MISRA-C:2004 support and pulling the wrinkles out of the example suite. Once the MISRA-C:2004+TC and test suite is stable we will work on producing MISRA-C3.

I think 5 years between releases has been suggested with the TC picking up any major problems in the mean time. It is pointless turning out new versions too quickly or nothing has a chance to stabilize. So from MISRA-C:2004 we could have MISRA-C:2009 but a lot can happen in that time especially with the C language. MISRA-C tracks C90+A1 and TC’s as there are no C99 compilers. However if C99, or rather C0x, compilers become common we will have to move from C90 to C2x as a base. However for reasons I will explain further on MISRA-C may never move from C90!

 

The MISRA-C++ team is having fun. They have rushed headlong in to the quagmire that a new standard generates. They have assembled a team and are sorting out terms of reference and the contracts in parallel with gathering source material and there is a lot of source material. Interestingly they tell me that most of the C++ subsets and coding standards they have seen have a lot in common. Though I did hear a comment that there are one or two things in most that have never actually been proved as valid. Everyone knows they are a good idea even though there is no empirical evidence to support it. In some cases there is even evidence to the contrary. There is also the C++ coding standard from the Joint Strike Fighter project in the US called JSF++, which ironically is covered by a US defence classification and can only be seen by cleared US Nationals… Therefore a lot of the people working on the JSF can’t see it and of course no one out side the US. I can’t help wondering why a coding standard is an Official Secret…. unless it is that embarrassing.

 

The MISRA Autocode is progressing well. The group has divided work up into a number of subgroups looking at generic guidelines as well as tool specific ones. This layered and modular approach sounds very helpful, as it is means that the new tools can be catered for without dismantling the whole standard.

The subgroups have representatives from OEMs and consultants with support from the tool vendors. The effort is being well supported with a good number of European OEMs and Tier 1s along with a smaller involvement from the USA. The European support is quite wide and not just the German automotive industry as was feared by some. The US support is hampered somewhat by distance and time difference. I did enquire about first drafts for review and “mid 06” was vaguely suggested which means it will probably be Christmas 06.

 

A less well-known MISRA standard is the Software Readiness for Production. These metrics are used for tracking the progress of software towards the goal of production readiness. This is how "complete" a software project is against expected targets. The metrics are derived from the Advanced Product Quality Planning (APQP) and Production Part Approval Process (PPAP) as used within the automotive industry however I am certain that like MISRA-C they will be useful for most large embedded systems.

 

APQP identifies both the key activities that are critical to the quality of the product, and their timing in the development lifecycle of the product.

 

PPAP identifies the documents that define the production acceptance criteria, which show that the required quality has been achieved. However, as they are automotive, these procedures are not designed to accommodate software development, because much of their emphasis is placed on the measurement of physical attributes. The MISRA Software Readiness for Production metrics implements the concepts of APQP and PPAP in a software context, to maintain compliance of software development with the principles of QS9000 together with equivalent procedures in ISO/TS 16949. Sources in MIRA have told me that this document will be published in February 2006. At the time of writing that is only 6 weeks away so they must be fairly confident.

 

I think this MISRA document may be of used for general embedded systems development because apart from the marketing a car is in effect a complex series of embedded systems including networks, displays hard and soft real time, usually an RTOS and various levels of safety critical from breaks to the radio… missing the Archers omnibus can be fatal in some households.

 

MISRA Safety Analysis - this gives guidance on the management of functional safety for IEC 61508 lifecycle. Whilst the general principles of functional safety are the same for all industries, specific guidance is needed to address specific automotive issues including hazard classification, risk assessment and the supply chain. The MISRA Safety Analysis guidelines include a process for hazard classification and risk analysis based on a risk graph approach that incorporates the established "controllability" principle first introduced in the 1994 "Development guidelines for vehicle based software". I am again informed from within MIRA that Safety Analysis document will be published mid 2006. So if you are lucky they will be available from MISRA in time for ESS.

 

Whilst mentioning ESS I have received the first notifications of ESS 06 and people have booked stands already! If the current trend continues ESS06 will be bigger and better than last year, which in turn was bigger than ESS04. If I can afford the coffee I will be there. Will you? 11 & 12th October at the NEC Birmingham. Stick it in the diary.

 

Having covered the MISRA guides it is time to look at the other standards. Well there are Standards and there are Standards or even Standards and standards. There are the International: ISO and IEC, European: EN and ECMA, National: BSI, ANSI, DIN etc. Then there are the trade standards generated by trade bodies such as MISRA, IEE, IEEE, OMG and others that produced JTAG, JPEG, PCI,

 

MISRA for example came about because of a specific need in a specific area of the industry. As did standards such as XVGA, Ethernet, JPEG etc. It is for reasons of commerce. If you only have to make one version it is more cost effective. It also aids interoperability. AutoSAR is one of these where interfaces and protocols are being standardized for the benefit of…. well, a lot companies are putting a lot of effort into it.

Other standards are there for safety. For example the IEE Wiring Guide for building electrical wiring. Other standards are no more than guides. Rather they are taken as a guide and not strictly adhered to, for example the C and C++ language standards from ISO. In this case there is a complete language description that compiler companies can adhere to. This is very helpful, as long as the standard is the one that the users need. For example the ISO Basic went one way and the rest of the world went with Visual Basic. With Pascal the standard went one way and the major compiler companies went several different ways. That division probably helped to kill of the language. Though there is Borland’s Delphi, which is as close to Pascal as VB is to ISO Basic.

 

The way these ISO language standards work is that there are many panels attached to the standards organizations in each country e.g. BSI, ANSI, DIN etc These are National Bodies or NB’s in ISO parlance. In the UK anyone may join the language standards panels no matter what their experience, background or qualifications. Fortunately other panels (eg the 61508 panels) do screen applicants to ensure they have some relevant experience. These National Bodies meet several times a year and also do a lot of work by email.

 

The BSI C and C++ panels send a delegation to the ISO C and C++ meetings twice a year. The ISO C meeting is traditionally held in parallel with the ANSI panel meeting when in the USA and every other meeting is in the USA. The C and C++ meetings are held back to back and some people attend both as there is still a fair amount of linkage between C and C++.

 

The ISO WG’s produce The Standards, DR’s or defect reports (bug fixing), Technical Corrigendum, and Technical Reports. The Standards and usually the Technical Corrigendum are official documents that get passed back to the National Bodies for “rubber stamping” as local National Standards. Therefore you can buy an identical BSI, ANSI, DIN copies of the ISO C standard and indeed the ISO version as well. Curiously for a Standard the price for C 99 varies from 18 USD to over 100 GBP depending where you buy it.

 

So far: so good. Now things get vague. For reasons I have not been able to fully ascertain in the latter half of the 1990’s the C panels veered away from the industry. The 1999 version of C has, I am reliably informed, a broken maths model and a huge number (over 400 I think) of undefined and implementation defined items. I have an email from one of the better (and well known) experts saying that he managed to miss the voting on several areas that he feels should never have made it in to the standard, there are several British experts who have said similar things about other parts of the standard. The industry and indeed compiler writers and others like MISRA have stopped at C 1990 with the amendments up to 1993/4 and virtually ignored C99.

 

Other things that can be done with ISO standards are Technical Reports. These are exactly what they say and are NOT part of the Standard though often they form the basis of work that does get into the next version where appropriate.

 

These reports can form guidance for specific things for example there is a TR on the maths used in DSP’s though it is miss-named Extensions for Embedded Systems. So it is possible for a pressure group to produce a TR. There was a suggestion that MISRA C might become a TR . In fact it is usually a small group with external specialist help that does a TR.

 

However this can leave the way open for some underhand manipulation of the language. As mentioned the Embedded Extensions are in fact really just for DSPs. Though it was thought that there were too many people involved in the ISO process for anyone to get away with it. I am not so sure now.

It started with the Secure C library. It contained “secure” versions of all 2000 functions in the C library…. Hang on there are only 483 functions in the ISO C library. It turned out that the TR refers to the Microsoft C library. In my view it should have been stopped there and then but the only major objection was the name. Partly because the new functions are not really any more "secure " than the current functions,So they changed it to “Safer C “ Library until Les Hatton the author of Safer C mentioned something about copyright…. So we now have the “Safe” C Library Technical Report.

 

Well so what? It is a TR and not part of the Standard. Marketing people do not always appreciate that distinction when writing marketing copy…. Nor it appears do some writers of technical manuals. I have seen Microsoft literature that describes the MS library as highly standards compliant. Other people have noticed this. I read an item in the current ACCU Overload magazine (www.accu.org) where the writer was commenting that Microsoft were using standards language in their error messages and manuals and referring to the Safe C++ library (yes they are doing a TR that covers the Microsoft C++ library) as though it were a full part of the ISO C++ standard. It seems there is some miss-understanding but the impression is being given that the Microsoft C and C++ libraries are fully ISO Standard compliant and that anything that is not Microsoft compatible is non-standard. I am sure that this is just a misunderstanding in phrasing and the matter will be clarified in the next versions of the compiler and the manuals.....

 

The method of making an ISO standard is the normal route I have described. National Panels, voting and two ISO-WG meetings a year. It can take a decade to get a new version of the standard out. There is another way of getting an ISO standard. There is an agreement with the European Computer Manufactures Association (ECMA) that their standards can be fast tracked.

I think the last one came in as a fully fledged standard and the ISO panels had to vote on it in about a month to accept or reject. In ISO terms that is virtually instantaneous. The voting system means that there have to be a majority of NO votes (with reasons etc) to stop something. In practice this is not easy to do. So what are the language standards that ECMA is doing? ]

http://www.ecma-international.org/memento/TC39.htm
Here is the list:-

 

Do you see a common thread? Do bear in mind the two Microsoft ISO TR Libraries for C and C++.

The penny has finally dropped with others at last. I commented on it in early 2004 when the MS C library TR was suggested. Some have woken up to the new Safe C++ library. To be fair most C users are either using MS C/C++ or they are using embedded compilers based on C90 and have no real interest in C99 so either way it is not going to bother them. However C++ is a different kettle of fish. Most C++ compilers are tracking the current standard.

 

Other C++ users have realized that the latest fast tracked standard from ECMA the C++/CLI is an extended C++. Yes ECMA have fast tracked a NEW language based on C++ C++/CLI adds more than two dozen new keywords, some of which are two part key words, ie they have spaces in them e.g. "ref class", to the 63 keywords of C++ syntax. This makes the basic language more than a third larger. It also changes the behaviour of some current constructs etc. This is a NEW and “Improved” C++/CLI. The problem is that this new C++ will only work in a Microsoft environment. Worse some correct ISO C++ functions have been labels as “depreciated” in the MS error messages. They have used the wording used in ISO standards when in fact these functions are not going to be depreciated by ISO C++.

This is a link to the accu Overload editorial which sheds some more light on the matter:
(http://www.octopull.demon.co.uk/editorial/N8037_Objection.pdf).

Start here (a page which actually does mention C++/CLI in a low-key way):
http://msdn2.microsoft.com/en-us/library/xey702bw.aspx

But you shouldn't have trouble finding many more; almost any page with the slightest relevance to .Net should suffice, especially those that show equivalent code in C#, Basic, and "C++". Also look for links like "abstract (C++)" or one of the other new keywords. Here are some that show up on a quick troll:

http://msdn2.microsoft.com/en-us/library/b0z6b513.aspx

http://msdn2.microsoft.com/en-us/library/ms173675.aspx

http://msdn2.microsoft.com/en-us/library/213x8e7w.aspx (which is titled "Generic Delegates (C++) ")

 

I may be misreading things and be miss-understanding but it looks to me as though Microsoft have rather than conform to the C and C++ language standards managed to convert the standard to be Microsoft compatible. So where does that leave us?

 

As I said the ISO C has already gone off in a different direction to the majority of the industry so it will have little effect on the embedded world. I suspect there will be an Embedded C Standard in a few years, maybe under MISRA or the IEEE.

However these new standards will have a far more marked effect on C++. With the new Safe C++ library and the C++/CLI and confusion the new Microsoft C++ will become the standard. I understand from some one who has seen the new MS C++ manuals that it makes no distinction between C++ and C++/CLI and in fact the MS C++ is C++/CLI

 

Finally I should like to bring to your attention an item from an IEEE newsletter. It said that: Universities no longer assume that the new engineer will learn ethical practices on the job and are now offering instruction on the subject. The IEEE is also playing a role in highlighting ethical practices by promoting students' awareness of their professional responsibilities as engineers. Find out more at http://boldfish.ieee.org:80/u/1353/41449924

 

I wonder if they will cover Standards in their ethics classes or if they will run correspondence classes for busy engineers in other parts of the country…