Safety-certified tools makes the difference

Transcription

1 by Anders Holmberg, Product Manager, IAR Systems Safety-certified tools makes the difference In November of 2013, Renesas Electronics announced the development of a functional IEC compliant safety package for the RX631 and RX63N family of devices and at the same time, Renesas Electronics and IAR Systems announced the availability of a safety-certified development and build toolchain for the RX family of microcontrollers. The combination of hardware with a known history, application software, and diagnostic software and development tools with safety-certification is a very powerful enabler that allows the developers of safety-critical applications to hit the ground running and get their end product certified as quickly as possible, thus saving money as well as time-to-market. In this article we examine what benefits accrue to users of a certified development and build chain. 1. History repeat Over the last decades there has been a tremendous increase in the number of embedded projects that have to somehow cope with requirements on functional safety. Products for applications in measurement and control, medical devices, automotive and so on are increasingly required to fulfill certain reliability thresholds and behave safely in the event of failure. The avionics field on the other hand has obsessed with safety and reliability for a long time. Unfortunately, every niche have had their own standards and concepts related to safety although the underlying ideas are very similar. However, a strong trend since the turn of the century is a drive to unify standards and concepts so that for example methods and concepts from one standard can be applied also for another application area if justifiable. A driver for parts of this unification is the work with revising the IEC standard for Functional safety of electrical/electronic/programmable electronic safety-related systems into its second edition. It was released in 2010 and now serves as a reference standard for all kinds of programmable electronic devices, although sector specific standards in for example railway and machinery are very important to codify the safety related knowledge that is fundamental for the specific application area. The IEC standard is especially interesting, since it is a direct application of IEC in a machinery specific context. The automotive standard ISO is also an application of IEC 61508, but takes a slightly different view on safety integrity levels etc. The trend towards more formal requirements on safety related functionality is partly driven by the market; end users and product integrators higher up in the value chain demand high reliability and need some form of independent judge on what s safe and what s not. This opens up for product certifications of different kinds, where IEC compliance is probably the most important one in terms of impact on our industry. The second driver is international or national regulations that require compliance with named standards. The end result is that more and more products are now under pressure to comply with functional safety requirements. This trend is not likely to change in the short run. Rather to the contrary, the number of devices with some sort of incorporated safety functionality will continue to grow. The complexity will also go up as the Internet-of-Things spread and everything from toasters to emergency functionality in your car will be connected to the outside world and the internet. This evolution also blurs the line between functional safety and device security, at least in software development since the concepts partly overlap A device that is for example susceptible to break-in attempts due to buffer overrun errors might just as well crash due to malformed data erroneously produced by a legitimate peripheral, or it might be forced to turn off the safety functionality by a malicious intruder. A paper by Stephen Checkoway and colleagues at University of California, San Diego {Comprehensive Experimental Analyses of Automotive Attack Surfaces} describe several attack channels in a modern car, where for example the in-car entertainment system can be compromised to allow command access to one or more CAN busses in the car. Another recent example that made the headlines is an online fridge that was recruited as part of a botnet to send spam s.

2 Page 2 2. Brace for impact In the hardware domain, designing a functional safety system includes answering some very basic questions: how do I ensure reliability and integrity of the selected components? How can I make sure they function as they should when reality strikes? For some components, failure rates and failure modes are fairly well understood and such components in critical pathways can either relatively easy be dimensioned to cope with required failure rates or doubled or tripled to further reduce the possibility of malfunction. In the latter case you can even opt for different suppliers to lessen the risk for common mode failures. In principle, the same kind of analysis must be carried out for the microcontroller you consider using, but a typical MCU is such a complex beast that other measures must be considered. One thing to consider is resilience to things like radiation etc. that can cause random bit errors on busses or in memory. Another is wear and tear, where especially non-volatile storage can be a serious threat due to approaching the limits on read and write cycles. A third source of issues is malfunctioning software, where things like writing beyond the stack can have disastrous effect. With their safety package for RX, Renesas Electronics provide a solid foundation for your safety related considerations by providing certified information and software that can be slotted into your project. One part of the package is a safety manual including among other things description of the safety mechanisms available and failure rates etc. A second part is a comprehensive self-test diagnostic library for the CPU core, RAM and flash ROM. This diagnostic library was tested with very high test coverage, by for example injecting and simulating faults at the gate level. A third part is slightly more intangible, but is still very important. The devices covered by the package are proven in the market and their performance in terms of possible failure modes is known, which is a huge advantage compared to selecting a device that is brand new on the market. Renesas Electronics is really ahead of the game with their safety package and since there are also certified software development tools and RTOS implementations available a large part of the necessary ground work is already done. This kind of offerings will become even more important as the market for safety related development grows. 3. Standards apply? If you are about to start a software project with safety-critical functionality or functional safety requirements, you are probably already aware that the tools you use must somehow be qualified as suitable for safety-related development. The exact requirements for how to qualify development tools differ to some extent on the criticality of a malfunctioning safety function or product. It is also dependent on the nature of the tool; a compiler that produces code that goes into your product is trickier to qualify than a source code metrics tool, which in turn is trickier to qualify than a version control system or a requirements management system. Section and sub clauses of IEC 61508, part 3 details how support tools should be qualified. However, the standard is not very detailed on exactly how a C compiler should be qualified; for example, clause states among other things that the selected programming language shall have a translator which has been assessed for fitness for purpose including, where appropriate, assessment against the international or national standards The notes to that clause then tries to explain some of the available mechanisms for a qualification effort. Taking this and other statements in the standard together indicates that qualifying a build toolchain for use in your project can result in a lot of work and associated document production, especially for higher Safety Integrity Levels. Further, if the assessment is too focused on the current project, it can be difficult to directly reuse the results in other projects. Moreover, there is a common misconception that if your project uses the same uncertified tool as another project that did achieve a safety-related certification, your tool magically becomes qualified for development of safety-critical systems. This is not the case because you are still required to prove that your project is similar enough to the other project in such a manner that you use the same functionality and in the same manner as the other project. Generally, you end up being required to provide justification all over again that your tool is still qualified.

3 Page 3 4. Jumping through the hoops As mentioned, performing an in-house qualification of your selected build tools is often very timeconsuming and the needed skills have more in common with compiler writing and testing and less in common with the typical skills required for safety critical development that is close to the hardware. Further, how do you really validate that the build chain is compliant with relevant language standards? Can you get hold of a safety manual for the tool chain? What about carrying out a HAZOP analysis for the tool chain? To eliminate most of these questions and the associated work, IAR Systems has carried out a very comprehensive certification effort for our IAR Embedded Workbench for Renesas RX together with Renesas Electronics and TÜV SÜD, specialists in functional safety and associated assessments. The assessment of our build chain covers the following areas: Our development processes and our ability to develop high-quality software in a repeatable fashion, including how we work with the specific requirements put forth by different functional safety standards. Test and quality measures, including validation of compliance with different language standards. Our processes for dealing with issues reported from the field and how users get updated about potential issues. The safety information in the safety manual and all other documentation. The assessment also covered softer issues like how many active users we have on our build chains for different MCU targets and how we make sure that the right product reaches a customer. The assessment covers both IEC and the sector-specific automotive standard ISO The latter standard is partly derived from IEC and has taken a position on tools qualification that is similar in intent but slightly different in action from IEC The outcome of the assessment is that the build tools incorporated in IAR Embedded Workbench for Renesas RX version fulfills the requirements applicable to software development tools as given by both IEC and ISO The coverage of the automotive standard can be considered a bonus from how we work but it is also a good example of the fact that different standards can have very similar requirements. 5. How on earth? If you have already been through one or more safety related projects with formal certification requirements, you know the value and importance of a streamlined process. It can sometimes be tempting to invent complex processes that involve lots and lots of paperwork and the production of artifacts that in the end are justified only by the process itself and not by the real issues the processes are intended to address. In fact, one of the biggest challenges in adapting existing development processes to the requirements in IEC is to avoid over-engineering of the processes while at the same time fulfill the requirements of safety goals, traceability, decision justification, safety planning, testing and validation/verification, and feedback loops etc. as described by the standard and the V model. Of course you don t want to cut corners or take them on two wheels, but your processes should be a help to reach your goals, not a hindrance. Another challenge is, as always, the need to balance factors like: The bill-of-materials and associated production costs, especially for high-volume products. Time-to-market and perceived market window. Buy, develop yourself or outsource various needed parts for the project? This includes not only pure development activities, but also things like specification work, functional safety management, validation and verification, qualification of hardware, tools, third-party components, etc.

4 Page 4 As suppliers of microcontrollers and development tools it s not really surprising that we advocate our own solutions, but we are convinced that existing solutions that deliver on the promise to cut down on the red tape will in the end be worth every cent. 6. Software galore In developing safety critical software the relevant standards like IEC put stringent and rather heavy requirements on how the software shall be developed. This includes things like using the V model for organizing the overall project, how you select programming language and what features you can use in the selected language. There is usually also strong advice on how to test and verify the functionality of your device and especially the parts that are relevant for functional safety. It can be quite tricky to balance the need for various safety precautions that can for example drive up total memory usage and the requirements from production and market to keep the price down while at the same time retain margins. On the other hand a lot of the recommendations in for example IEC make sense also for general development of embedded systems. For example, the certified library from Renesas Electronics for MCU self-test is useful for any product where functional integrity is highly valued. Here is another challenge: Using optimizations and language extensions are not generally encouraged by safety standards, but it is our firm belief that both language extensions and optimization can have their merit also in safety related development when weighed against alternatives that require you to, for example, implement complex functionality in assembly language or increase the clock frequency to meet real-time deadlines. As long as you have solid justification for your decision backed up with matching validation and verification activities you re on solid ground. The safety manual and other documentation gives you all the information you need to help you make an informed decision if the need arises. But how can, for example, the use of language extensions be justified and why would I need them for development? The main reason for using language extensions is to use extensions that in some way let me access special features of the underlying hardware in a type safe way and without the need to write assembly language glue code or rely on strange pre-processor magic. Such extensions can be very general, like operator used by IAR Systems compilers to indicate that a certain object shall be absolutely placed at a certain address. This can be used to safely create symbolic names for memory mapped peripherals, like timers, I/O ports etc; and this will in turn enable the linker to make sure that mapped objects do not overlap. More specific extensions are various intrinsic functions to access special features of the CPU core, like disable_interrupt() or the RX specific RMPA_B() that inserts a special instruction into the instruction stream in safe way. Optimization is another interesting area. Considerable effort goes into making modern compilers do their very best both on typical application code as well as on specific benchmarks; a modern highly optimizing compiler can perform some really amazing tricks with your code. At the same time, a buyer often spends quite a lot of time evaluating the performance of a compiler and associated tools. When the chosen compiler is then used in a project with safety requirements, the optimizations are most often simply turned off This might look slightly weird seen from above, but there are some highly relevant drivers for this: Safety standards commonly advice against using optimizations And if your project aims for certification it s always your assessor or notified body that have the final saying on what s acceptable. Use of very aggressive optimizations on a whole application can severely degrade the traceability from source code to assembly language After function inlining, loop unrolling, instruction scheduling, common sub-expression elimination and a bunch of other transformations have been applied to a program it can be very difficult and error prone to manually map a specific piece of source code to the resulting assembly code, let alone proving that the code is implementing the right piece of functionality. Traceability requirements can be an efficient blocker of wholesale optimization.

5 Page 5 Concern about faulty implementations. Unfortunately, C compilers historically have a rather sad track record of implementing complex optimizations as well as not taking the language standards too seriously. The situation is dramatically different today. But combining several very aggressive optimizations and unleashing them on large code bases definitely increases the probability to encounter problems. Perceived quality issues with optimizations. This is a tricky one A quite common scenario for us is to get a bug report on some optimization that is believed to be wrong where it turns out that the code that broke is really relying on behavior that is undefined by the language standard and the compiler exploited the fact that the source code is, in a sense, broken. What s difficult with this kind of problem is that the code might have worked as expected for a long time and then suddenly breaks after a modification that triggers different optimization behavior. Further, it might be a chain of triggering optimizations that leads up to the problem, which can make it hard to find the spot in the source that s causing the problem. So, given that there are valid arguments to go easy on the optimization, what can we do when we really need them? Let s start from the bottom of the list. The best way to avoid relying on undefined behavior is to adhere as strictly as possible to a coding standard like MISRA C or another standard with similar intent. This is already close to mandatory if you are working against IEC 61508, so this is really no additional work you do just for the benefit of correct optimizations. However, strict adherence to such coding standards requires tool support in the form of static analysis tools to be viable. But the benefits of keeping the code MISRA clean are so many, that it s really worth considering using MISRA as a basis for your work even if you re currently not under safety requirements. Of course any standard that enforces a similar subset of the language can be used, but MISRA C is the most widespread standardized subset around. So, what about traceability? First, an assessment should be made where potential performance bottlenecks are identified. In this scenario, code size of one or more modules can also be viewed as a performance bottleneck if they force the inclusion of more code memory in the HW design, which in turn can force a reevaluation of safety requirements etc. If the performance issues can be isolated to just a few places various techniques can be used to keep traceability on workable levels. This leads over to the last issue, since the techniques are very similar. No matter if you want to increase traceability to, and understandability of, object code or reduce the risk of running into unexpected optimization issues, there are a few techniques that can be used: o Most compilers have a notion of optimization levels. Three levels divided in to low, medium and high optimizations are very common. Another commonality is that the trickiest optimizations are almost always reserved for the highest level. Depending on the exact traceability and verification requirements you have, you can ponder the following techniques. Can I increase the optimization level on only the modules that are perceived as slow/big? How is performance and traceability affected by this? Maybe an even higher level works, but this must always be assessed thoroughly against all other requirements. It is also often possible to turn off some specific optimization. o o If needed, break out functions and put them in separate modules to isolate optimizations even further. When optimizations are used, no matter if the level is low or high, is used only on certain modules, or across the full application, you should consider how you test the application. As soon as optimizations are used you should run as much as possible of your tests with both optimized and non-optimized builds. This way you ensure that the code behaves the same in both versions. Further, as a complement to what we talked about above, this way of testing is an excellent way to further reduce accidental dependencies on undefined behavior. This is especially so, if you can complement your test configurations with a build where all optimizations are turned on. A good thing with optimizations, as seen from a quality perspective, is that they reduce the amount of object code that might potentially have to be verified and cross-referenced. How much verification that is

6 Page 6 done on this level depends on your safety goals, but for certain projects this can be a heavy burden. Usually, letting the optimizer work on the low level removes a lot of code that is just translation artifacts but retains a very good coupling with the original source code, thus actually simplifying ocular inspection. 7. Say what? So, what do you get if you select the functional safety version of IAR Embedded Workbench for Renesas RX? The high-level benefits can be summarized as follows: A complete build chain and development environment that is certified by TÜV SÜD to comply with the requirements for tools selection in IEC and ISO A report to accompany the certificate stating under what circumstances the certificate is valid. A safety manual and general documentation that gives in-detail knowledge of how the tools should be used and their functional boundaries. A test report on how the tool set is tested. A compiler that accepts the C89, C99 and C++ languages. Exceptions and RTTI are not supported for C++, which in the case of exceptions is just as well, since their usage is not recommended for safety related development. A Functional Safety Support and Update Agreement that includes support and prequalified bug fix updates to the certified version for as long as there are customers under contract for that version. Regular updates on newly-discovered problems in the toolchain. The combination of Renesas Electronics functional safety package for the selected RX families and IAR Embedded Workbench for Renesas RX gives you a head start for developing safety critical products and applications and removes much of the drudgery that isn t directly related to developing your application. Additionally, it gives you a compiler with outstanding optimization performance and best-inclass language conformance. On top of that it also provides various language extensions that can optionally be turned on to simplify programming close to the hardware. This includes intrinsic functions to access special hardware features as well as extensions to simplify access to memory-mapped peripheral devices.