Embedded Systems Engineering Standards Column vol 11.3 May 2003 Standards: Corperate Manslauter By Chris Hills

I was planning to cover the subject matter below in a few months time but other events have prompted me to raise this issue now whilst it is in the media. It is about standards but in the broader sense. If you will permit me to elaborate and follow to the end you will understand how this does relate directly to software standards.

The Hatfield and Potters Bar rail crashes have been in the news along with dark mutterings about the Corporate Manslaughter Bill. At this point I have to state that none of my many and varied qualifications are of a legal nature and this is purely the personal opinion of a non- legally trained Engineer. Added to which these are still only proposals and who knows what will finally get enacted and become law.

 

The new manslaughter proposals are designed to be an extension to the health and safety at work rules. I say "new" but these proposals have been around since May 2000. They go under the title of : Reforming the Law on Involuntary Manslaughter: The Government's Proposals and can be found on the Home office web site. At http://www.homeoffice.gov.uk/docs/invmans.html or

http://www.homeoffice.gov.uk/docs/invmans.pdf

They were there on the 8th June 2003 but the Home office site does seem to have a lot of broken links. This is based on the Law Commission's Report 237 (Http://www.lawcom.gov.uk) If you can't find them email me atChris Hills and I will email the pdfs to you.

 

The problem with legislation is much is in the implications and implementation than what is written on the page. Those familiar with IR35 and section 660 will know what I mean. Contractors should read to the conclusion. There is more to these proposals than meets the eye.

 

The idea is, whereas currently for manslaughter you have to show that a person (or persons) did something specific that lead to the death of a person, the new rules will permit the courts say that the accident was caused by actions precipitated by the way the company was run. In the case of the Herald of Free Enterprise the deck hand who did not close the doors properly was not tried for manslaughter but the intention was to prosecute the Directors of the ferry company for the way their ships were run. This case floundered. The other more significant case was the Clapham rail crash in 1988. BR was "criticized for allowing working practices which were "positively dangerous" and it was said that the errors went much wider and higher in the organization than merely to be the responsibility of those who were working that day." This has interesting connotations, as I will show later.

 

Thus if some embedded software causes a crash but the management pushed it out of the door without proper testing it is the directors who will be in the dock. There seems to be some movement as to whether the Directors will go to prison, face personal fines or the company will be fined.

 

These proposals when enacted will be a blessed relief for many programmers (and especially test managers) working in companies where there are silly deadlines, poor/changing specifications and skimped testing enforced by management deadlines. It will, at least it should, put the fear of God into the management trying to cut corners. This is the intended thrust of the proposals according to the Home Office when I spoke to them last year (2002).

 

I have seen engineers put in writing a serious concern over some software only to remove it again when it was realized (after a quiet chat) that their career prospects might suffer… Now the application of such pressure could be used against a manager, rather than the engineer, in a manslaughter case it will, I hope, be less likely for engineers to be placed in this position.

 

However there is a darker side to this legislation that could have serious repercussions to many companies and is in effect now before the new laws are enacted.

 

One point in passing: could your company suffer a large manslaughter type claim even if they don't put the director in prison.

 

The other more subtle and dangerous problem, that as far as I know the Home Office had not considered, was suggested in the Potters Bar crash. In contrast to the 1988 Clapham crash where British Rail was responsible for track, trains, stations etc separate companies now run everything. The Train Company has (I believe) suggested the faults lie with the track company, which has (I believe) in turn suggested that it was the sub-contracted maintenance company… You can see where this is going. It is going to end up with the sub-contracted team who had the contract for doing the maintenance.

 

In many embedded developments parts are subcontracted out. The aero plane/ car/ ship/ building etc is made up of many parts each made up of many parts. The larger companies will have cast iron contracts. The main company will probably have more lawyers than there are people in the company at the bottom of the chain. The contracts will, I imagine be more watertight the higher up the chain you go.

 

The weight of the law (and the insurance companies who will have to pay out) will look for a case they can win. It is easier to take on the small companies than the larger ones. Given the size of fines and/or prison sentences being discussed it could close many of the smaller companies. The interesting debate is that the government is currently suggesting that prison is not now going to be an option. I think this is good for the larger companies but not so good for the smaller ones. A large company would rather loose the money than the Director. Smaller companies would probably prefer to loose a director to an open prison than the very large fine.

 

In the case of many embedded engineering sub-contractors the owner is the engineer. At this point the fine distinction between a two million pound fine and two years in gaol is a moot point. The company will effectively close in either case. Though if this government continues it's current course and lets the Revenue continue with IR35 and 660 this is irrelevant because there will be no small embedded engineering companies in the UK by the time the corporate manslaughter proposals become Law. (BTW contractors with IR35/660 concerns should see www.pcg.org.uk)

 

The "good news" is that this will only apply to accidents after the date the legislation is enacted. This is a false hope! The word is accidents… not software developed after that date. So in about 2 years time any of your software that is then running in a system that is involved in a fatal accident may be subject to a scrutiny by an "Expert" for an insurance company looking for some one to blame. They will have a suitably qualified Engineer who will go through your processes and software. This is after your team have been interviewed, under caution, by the police and your computers taken as evidence.

 

This is where sub-contractors will have to show "best practice", coding standards (MISRA-C for example), style guides, specifications and design documentation. Test specifications, version control, static analysis, dynamic testing and source documents.

 

Now you may think that, as I work for a development tools company, I have a vested interest in suggesting this. However most of what you need is free. Specifications, test specifications and design documentation require little more than a pencil and paper. Though do remember to date and version-number them. Coding standards: there are a few on the web. MISRA-C will cost you £25 from MIRA or Phaedrus Systems Ltd. Style guides are all over the internet, I have one I did myself (the Tile Hill guide at http://www.phaedsys.com).

 

Version control can be done using GNU-RCS or a manual method and static analysis using lint can be free using GNU lint or less than £150 using PC-lint. By the way static analysis is a "must" not an option.

A good C compiler will help. Using a cheap compiler with a dubious pedigree will not help in court. Use a decent industrial strength compiler it will save money in the long run anyway.

 

As for source documents: You can use various ISO SW process standards or, as long as it is documented, do your own system. This is basic ISO 9000… document the system. MISRA-C is worth having as it is in use in most areas of the embedded C world though a new version is due out in about three months. Email me if you want to know when the new one becomes available.

 

You do have a copy of the C standard? The C90 version of the standard used by MISRA-C and most tools (as opposed to the newer C99 standard which as not been implemented by tool vendors yet) is available from BSI) for £30…. less than the cost of most books on C. So what is your excuse for not having a copy? This is the only time BSI have ever made an old or "superseded" standard available again (and at a fraction of it's original cost) this it is largely due to these manslaughter amendments.

 

For users of C++ you are stuck with having to get the new (expensive) standard even if you are using EC++. The free EC++ guide references the ISO C++ standard. Again the good news is that John Wiley are about to publish version of both the C and C++ standards in book for at around £35 each published by John Wiley due out around August/September. Note the C book will be the C99 standard, which is not implemented by any embedded compiler vendors so far.

 

So on the whole there is little cost involved in setting up and running the procedures. Many of the tools are free or inexpensive. Though of course if you go to the other end you can spend a few thousand per engineer…

 

If you are stuck with a load of legacy C projects Phaedrus Systems do a tool (DAC) that for a few hundred pounds will turn out full documentation with flow charts, structure charts, cross references metrics etc. Most users say it pays for itself in the first day of use. There is, or was, a similar tool called Sniff that would do a similar thing for C++.

Testing can cost more money though as tools will be needed. No one is going to accept that printf statements constitute good practice for debugging embedded systems. Now debug tools will cost you money, there is no two ways about this. In this case the cheap option may not be good enough.

The silly thing is that these procedures and tools like PC-Lint and version control software are actually very cost effective and make good business sense anyway. (see the Embedded C traps and pitfalls paper on http://www..phaedsys.com) There is a very good business case for using these tools and methods without the threat of a manslaughter charge.

 

The important point to note is that whilst the law is not retrospective it is for the accidents that happen and the systems involved in the accident. If you have anything running in a system that might be in use in two years time now is the time to tighten up the documentation and records.

 

Please note:- I am not a lawyer or legally trained. These views are my own personal opinion from reading the Home Office and Law Commission documents, watching the news reports and reading other journals. You if you should seek properly qualified legal opnion when the bill is enacted.

 

Authour Contact Details

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 April 2003
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