ISO26262 – Catching up with the train

I used to think that the automotive industry is far in advance of the rail industry. If you go back to the 1930s and compare cars with trains, they come up a very inferior; slower, less comfortable, less reliable, ‘cruder’! Come up to date and trains have changed very little. A significant change from coal to diesel or electricity but apart from that very little has changed. Even the sandwiches are the same!!

Now look at the modern car! The range of engine designs, comfort and safety features and infotainment is huge. The modern car resembles the 1930s offering only in the number of wheels! The colours, performance, styling and number of body types to suit every lifestyle lead one to believe that the automotive industry is leading the world in design and development.

So I was extremely surprised to hear that formalising the development of safe software lags the rail industry by some decades.

I recently attended a seminar of ISO26262 organised by Infineon and Hitex. ISO26262 is the new international standard for developing safe software for automotive application. This standard maps fairly well onto ISO50129, the equivalent standard for railways, and both have been derived from ISO61508, the standard for safe software in any electrical application. The difference lies in the level of implementation of procedures and processes to meet these standards in companies developing rail systems compared to those developing automotive software.

I guess that there has always been the argument that in a car the driver has ultimate control and can take corrective action. If the system deciding that it is not safe for two trains to be on the same piece of track at the same time fails, there is a very high likelihood of a loss of life. If a similar failure occurs in a road vehicle, the likelihood of a loss of life is significantly reduced by driver intervention. This argument has probably caused the demand for proven safe software to be reduced in cars. However for whatever reason, possibly commercial, the standard is now in place and the automotive system suppliers must comply with it.

The seminar provided a very good overview of the ISO26262 standard and its demands on companies having to comply with it. The formalisation of the design, build and test process along with the very necessary reviews at each stage are what we have become accustomed to in rail applications. Tracing requirements through design to tests is nothing new either and represent good software engineering. I would suggest that the lower levels of ISO50129, up to SIL2, are really what a conscientious software engineer would always do, given time, budget and a good set of requirements!

The message from the seminar, which rings true to our experience, is to pick the minimum set of processes that will deliver the required integrity level. Aiming too high will inhibit your chances of ever getting to market; too low and you will never achieve approval. AND you need to have a very good reason for picking the set that you have picked.

The assessors’ role is entirely procedural. They are not there to review your design but to ensure that you have one! They need to ensure that you have chosen to do enough to show that what you have developed meets the required ASIL level and that you have done those things properly!

So, much to my surprise, I am working in a state of the art industry! Not only that, it is one which has a lot to offer to other industries, even those that, at first glance, appear to lead the way.