feature article
Subscribe Now

And Tomorrow, the World

ISO 26262 and the Future of the Automotive Business

There is a new international standard, and the world of automotive electronics must now change irreversibly. ISO 26262 was published a couple of weeks ago, and this means there is now a standard that covers “Road Vehicles – Functional Safety.” To quote from the standard:

ISO 26262 is the adaptation of IEC 61508 to comply with needs specific to the application sector of E/E [Electrical/Electronic] systems within road vehicles. This adaptation applies to all activities during the safety lifecycle of safety-related systems comprised of electrical, electronic, and software elements that provide safety-related functions.

ISO 26262 is intended to be applied to safety-related systems that include one or more E/E systems and that are installed in series production passenger cars with a max gross weight up to 3.5 t.

We have looked at 26262 recently, so why am I returning to the topic?  Several reasons, really.

1)   It is now a fully published international standard.

2)   In the event of a legal case involving safety, it is likely that non-compliance with 26262 will be regarded as a serious issue.

3)   I have just sat through a day conference on the issues of Embedded Software in Automotive, which raised (or re-raised) some very interesting/concerning issues.

61508 has been around for a long time now – over 13 years – and people working within the standard have developed processes and methods for developing systems that can be shown to conform to the standards. But 61508 is for large, often one-off systems. Within the aerospace domain, there are standards, such as DO-178B, that deal with longer production runs, up to the hundreds of aircraft. And, in both cases, the operators of the end products, be they power stations or commercial aircraft, will have received many hours of training. But 26262 is the first safety-related standard that applies to a product produced in production runs of hundreds of thousands and that will be operated by almost anyone, with little or no specific model training – with only the ability to pass a low-level generic driving test.

And as well as being important, ISO 26262 is big. It comes in ten volumes, has over 350 pages, and there are more than 550 requirements. (To be honest, a lot of it is taken up with repetition: since the volumes are stand-alone, they all have a large amount of identical boilerplate – but there is still a lot of other material.) From the point of view of last week’s conference, the most important volume is Part 6: Product development: software level. This uses the classic V-model of the software development process, fitted into a larger V-model for the overall system development, and it accepts modelling a method of architectural definition.

The car industry has always been run by mechanical engineers. In the early days, factories, such as Ford at River Rouge in America and Dagenham in England, were fully vertically integrated: coal and iron ore in at one end and cars out at the other. Today, the industry is hierarchical, with the car companies, Mercedes, GM, and Toyota etc. (often called OEMs) served by Tier 1 suppliers, who in turn are supplied by Tier 2, and so on. Automotive builders are used to working to very tight cost constraints: a few pennies saved on just a single element in a car translates into better margins, and even better if a few pennies of saving are made on multiple items. Saving weight is also an issue, as fuel economy is more and more an element in increasing sales and complying with environmental legislation. It is in this environment that electronic systems are developed and deployed.

The electronic systems within a car are usually supplied to the OEM by Tier 1 companies, who have bought silicon and software from other suppliers. While the OEMs may specify the electronics, they are normally defined in detail and implemented further down the chain – or created down the chain and offered up to the OEMs. Some OEMs have reportedly been asking for 26262 compliance in designs since early 2011. Over time, the electronic content of cars has increased steadily, and, although hard to verify, there is a consensus that a mid-range luxury car may have up to 85 individual processors, and that in some cases a car may have in excess of 100 million lines of codes (LOC). One application frequently cited is the infotainment system. This can combine a satellite navigation system with traffic information and a radio and entertainment centre, and it may have a CD player, Bluetooth and USB connectivity, and iPlayer docking. It is no surprising that in some estimates an infotainment center may have around 20 million LOC.

All these applications and multiple lines of code normally have been developed in isolation. The automotive environment has created a range of standards for communication and platforms (LIN, CAN, FlexRay and MOST for communication, the GENIVI infotainment platform and AUTOSAR over-reaching architecture), but communication and co-operation between applications is not always simple, and there are interesting anecdotes about what happens when some applications are linked.

The cost and weight pressures in the industry are pushing electronics from one application per processor to running multiple applications on shared platforms, frequently multi-core, both heterogeneous and homogeneous. When the platform is heterogeneous, assigning tasks to specific cores is not simple, but it is straightforward: safety-related applications can be assigned a specific processor and can be developed to be deterministic. However, homogeneous multi-core chips, where tasks within the software are assigned dynamically to specific cores, provide a whole series of well-documented and widely discussed new challenges to the system developer. A significant problem, which requires very careful design and implementation, is determinism in real-time applications: it is not always possible to predict the state of the overall system when a specific action is required. This is clearly not a good thing for safety-critical applications, and many, if not most, real-time applications in automotive are safety-critical.

26262 is likely to bring some extra and interesting challenges to the industry, according to the speakers at the “Embedded Software in Automotive – the critical component” event organised by UK trade association NMI last week. There was near unanimous agreement that the formal framework for developing software that is required by 26262 will be a significant change to the way in which much of the software for automotive applications is developed, with a need to move from coding to engineering. Since many of the speakers were tools vendors, there was an emphasis on tools, but this emphasis also came from those who were in the industry.

Given the complexity of the standard and the complexity of requirements specifications, identifying how requirements mapped onto the standard and then tracing through the process that these requirements were satisfied is a complex task that will require specialist tools.

Moving to the software itself, 26262 explicitly permits the use of modelling and code generation, and this may be a growth area within automotive, since the code created from modelling tools may be “correct by construction”. If more traditional means are used, the standard again explicitly requires the use of coding guidelines, normally a sub-set of the language. Although ADA/SPARK is being used in some areas, the overwhelming majority of software is being developed using the C programming language. And guidelines for C from MISRA, originally developed for the automotive sector but now widely used in safety-critical applications, are under revision. MISRA-C3, which now covers the C99 version of the C language, will be available for review later this year/early in 2012.

Validating that the software conforms to the guidelines is offered by many of the suppliers of static code analysis tools, as part of the overall analysis process. Most, if not all, the major suppliers of static code analysis tools are claiming that their tools are certified as appropriate for 26262. (In a parallel industry, medical electronics, the US Food and Drug Administration is emphasising static code analysis of all software.)

Even vendors of tools for debugging were stressing the importance of spending time on specification and design before creating code and using analysis tools before compilation. It is a weird thing that, despite years of evidence that a disciplined approach to software development, leaving coding until as late as possible, produces fewer bugs; and despite the general understanding that bugs found earlier in the process are easier and cheaper to resolve, while bugs found in field deployment can be so severe as to damage a company’s reputation, perhaps irretrievably; there are still many millions of lines of code that are just written to a vague specification and introduced into service because they have compiled.

There is a strong feeling that the current software industry has yet to come to terms with the needs of a new era. Programmers often feel that structures and processes are constraints on their creativity, and, “I won’t have any bugs, as I write good code,” is an attitude frequently quoted. For them, creating the code is the end in itself. Its role in the larger system is irrelevant. Managers are reluctant to invest in tools for software development both because of budget constraints, and also, in part, because of the difficulty of enforcing a development discipline on their team.

As 26262 is increasingly demanded by the OEMs, we are faced with a number of problems.

1)   Social or cultural: Programmers will have to move from being artistic souls or solid craftsmen to become, instead, software engineers. They will also have to accept the discipline of working within a controlled and documented development process.

2)   Managerial: To make this work, management is going to have to accept that software engineers need tools. They will have to invest in the tools needed to manage the development process and provide the traceability needed to meet 26262. They will also have to invest in the tools that can make software engineers more productive and enable them to produce measurably better code.

3)   Technological: And the industry as a whole is going to need to continue to develop more tools that will cope with multiple processors within a single system (multi-core, heterogeneous, or homogeneous) and multiple applications with different levels of security running on a single core.

It’s going to be an exciting time.

7 thoughts on “And Tomorrow, the World”

  1. I feel that this article unfairly paints all of the software development industry with the same brush. The article makes statements about the lack of engineering and professionalism of software developers without any references to back them up. This is the first such EE Journal article that has driven me to register and leave a reply.

    I personally feel that IEC 61508 has been around for long enough that there are many professionals in the field of software development that know how to create a SIL2 systems that use complex software components. For reference look at the number of SIL2 compliant PLC’s and DCS that can be used in safety critical control. If ISO 26262 is anything close to IEC 61508 then I see no problem in adapting existing software practices to meet the standard requirements.

    The biggest problem is reducing the cost of such development, in particular when it comes to SIL3 or SIL4 systems. For example: How do you partition the systems so as to reduce the total cost of meeting the standard (when required by some regulator like a local govenment)?

  2. I absolutely agree that the ISO 26262 standard is going to propel the shift of the automotive industry to that standard. Notably, LDRA & QNX just yesterday launched a release that streamlines the regulatory burden for ISO 26262 (you can see the release at: http://www.ldra.com/news.asp) as well as IEC 61508 and IEC 62304.

  3. Hi Codonell

    Thanks for joining and welcome.

    Bear in mind that we at EE Journal do try to be provocative, and thanks for the chance to respond.

    Sorry I didn’t reference studies. While VDC and others have done some work in this area, I haven’t seen any serious academic studies.

    I agree that there are many professionals out there that are doing a good job. The sad news is that there are infinitely more people out there that are not doing a good job.

    At embedded world in Germany a year or so back Dan O’Dowd of Green Hills asked how many people in the room were using static code analyis. Less than five per cent of engineers, who remember were sufficiently aware to go to a trade show and attend the presentation, admitted to using tools,

    There is a culture of hacking and it is playing a part in the embedded world. The challenge is to harness the undoubted skills of the hacker to produce sofware for the safety-critical world.

  4. A couple of comments
    First thanks to adversising exec Janice for pushing her advertising. Though she fails to mention that CATS, IKV, Programming Research, HCC and many other companies all have 26262 tools, some like Programming Research’s QAC tool are 26262 certified. As she does not mention them I assume they are not her clients Caveat We do distribute some of the above. We can all start advertising if we want to.. so lets leave it out?

    Second as an Engineer involved in ISO 61508, ISO-C and MISRA-C panels (ADVERT MISRA-C3 review due soon see
    http://www.misra.org.uk/LinkClick.aspx?fileticket=d2UoWNgmuWw%3d&tabid=59

    ) and working for many years on critical projects I know the benefit of doing things properly.

    However working for a tools distributor I see very many companies working in the embedded field. From critical systems at SIL4 to the cheapest consumer. Also as many of our custoemrs are involved in the automotive market I agree with Dick.

    *SOME* areas of the automotive world do work to high standards but large parts of the lower tiers most certainly dont work to any standards.

    For years I have done straw poll at conferences where I speak on Sw engineering process. I ask how many now use static analysis. I tend to get better results than Greenhills (In the UK) but the numbers using static analysis are still low… and this is from those who attend conferences and events.

    When I talk to people on a daily basis looking for C compilers VERY few are using static analysis. Few want to buy Static Analysers with their compilers

    BTW to give some idea of costs at the entrly level we sell PC-Lint at about 400 USD. Compilers are about 3000 USD upwards and tools like LDRA are around 10K USD.

    I would not say it is as low as 5% but the vast majority are not using static analysis for C…. I would say the rest of 26262 is going to come as a great shock to them.

    In fact at an automotive conference at TRW two weeks ago (I was speaking about MISRA-C:2012) another automotive consultacy said much the same as Dick. Most of the lower tiers have no idea and certaily don’t conform or use many of the techniques required. They are in a bit of a panic.

    Many working in the lower levels of the automotive industry, during 2010 and 2011, had not even heard of 26262!

  5. Mr. Selwood,

    Thank you for responding. I appreciate your clarifications.

    I disagree with you that it is “sad news” that parts of the industry operate at different proficiency levels. Isn’t this the way a market is supposed to work? There are different solutions at different prices for different requirements.

    I also don’t feel that informal polls at tradeshows or conferences say much about the entire industry (the sample set is biased).

    The term “hacking” is overloaded, could you explain more clearly what culture you are talking about and what role it plays in the embedded world? When it comes to harnessing “hackers” are you talking about harnessing open source and free software?

    As a suggestion: I would really enjoy a followup article in a year, talking specifically about lower tier automotive companies and how they have handled the new standards. That would be a very interesting followup article!

    Mr Hills,

    Thank you for your comments!

    As an aside: I’m a Canadian member of CAC/JTC1/SC22 and in fact we are meeting tomorrow 🙂

  6. Great article Dick. My experience with ISO26262 and other safety critical standards comes from a tool vendor perspective. We build dynamic testing tools for embedded developers.

    From my experience, and I have visited hundreds of companies over the years, it is unusual for companies to go through a formal testing process if there is no requirement to test. This applies to all markets not just auto.

    Prior to ISO26262, there was no formal requirement for automotive companies to do unit/integration test, system test, and prove some level of code coverage. With the new standard, and having our VectorCAST tools certified by TUV, we have seen a huge interest in doing this kind of testing. The interest though has mainly come from outside of the US.

Leave a Reply

featured blogs
Apr 24, 2018
Counterfeit parts and the issues posed by them are a growing concern throughout the electronic industry.  However, counterfeit products are nothing new when it comes to consumer goods, and for many years, in any large city, traveling merchants have sold everything from purse...
Apr 24, 2018
In mid-April I was at the Linley Processor Conference. As usual, Linley Gwennap gave the opening keynote. He titled it How Well Does Your Processor Support AI? which was the perfect straight man question for us since we were using the conference to announce our new processor,...