EDA FEATURE
EMBEDDED COMPILERS FOR THE AUTOMOTIVE INDUSTRY
Jan Schlemminger, Field Application Engineer, Altium Europe, looks back at the evolution of Embedded Compilers for the Automotive Industry and how the next generation platforms have emerged
an item causing another element or elements of the same item to fail (ISO 26262, Part 1, Definition 1.13) Evidence that the failure of one element is
not spreading to other elements is possible only by considering the overall system. While classic unit testing covers this in part by system or integration testing, instrumentation is a must and a lot of test cases are required.
This imposes certain restrictions: •The application is modified for testing, and tests on the hardware are generally impossible or restricted because of interference with peripherals such as watchdog or additional Flash and RAM
O
ver the last 30 years, the competitive landscape for embedded tools in the
automotive sector has experienced a shift in focus. In the early days, key differentiating factors included performance metrics such as code size, memory usage and execution speed – the outcome of optimisations carried out during code compilation. To some extent, these factors have been joined by system power usage. While this may be less of an issue in automotive designs compared to other market sectors, it is nevertheless of significance as processor-based systems proliferate in vehicles and finite energy resources are becoming increasingly stretched. But most importantly, today there is much greater emphasis on correct output code and safety-related issues. Looking back at what happened in the
automotive industry over the past 30 years, several parallel trends emerge. In the 1980s there was a marked increase in overall quality levels; in the 1990s many mechanical systems were replaced or at least assisted by electrical solutions. Electronic fuel injection and anti-lock braking are two notable examples. Microcontroller-based electronic control units
(ECUs) became the norm to control subsystems in a car, and the number of ECUs per vehicle multiplied. After 2000 the level of complexity in automotive systems increased rapidly, and multicore processors were required to meet the computational and safety requirements of powertrain applications. This was accompanied by a continuing increase in the complexity of algorithms applied in chassis control and advanced driver assistance systems (ADAS). At the same time, in the wider context of embedded code generation awareness of the
need for a structured and disciplined approach to software engineering grew, as the vulnerability of all types of safety-critical systems to software errors became apparent.
ISO 26262 The ISO 26262 standard "Road vehicles - Functional safety" aims to ensure the safety of electrical and electronic systems in road vehicles. Like other safety-related ISO standards, ISO 26262 does not aspire to the creation of systems that cannot and will not fail. Rather, it explicitly recognises the fact that errors will occur, and seeks to ensure that the response of the overall system to a failure will in all circumstances result in a safe outcome. The standard therefore aims to guarantee that the design process is constructed in such a way that it results in a safe system. While a structured program is offered for the
TASKING compiler in the form of the ISO 26262 Safety Kit, users must provide evidence that the application also adheres to ISO 26262. In particular, proof of freedom from interference is not yet fully automated. The
standard defines this as follows: • ISO 26262, Part 1, Definition 1:49: • Freedom from interference: •Absence of cascading failures between two
or more elements that could lead to the violation of a safety requirement.
• element = system or part of a system including components, hardware, software, hardware parts, and software units (ISO 26262, Part 1, Definition 1.32)
• cascading failure = failure of an element of
Altium Europe
www.altium.com T: +1 858 864 1500
/ ELECTRONICS ELECTRONICS | NOVEMBER 2016 21
Figure 2: Safety Checker output
Figure 1:
Definition of safety classes and access rights
• System testing requires a large number of test cases and is therefore only carried out after a large part of the application has been completed. By then, it is too late for more substantial changes in the application. In practice, validation is carried out by
manually reviewing the design specifications and controlled by a memory protection unit (MPU) during operation. Manual testing is prone to errors, expensive and there is a risk that the application differs from the specification. The MPU allows only a limited number of memory regions and detects errors only as they occur. All tests require instrumentation and the MPU is turned on only during the final integration phase. While the MPU is essential to detect unpredictable errors when the system is running, it should never be used to find design errors. TASKING has adapted the principles to
verify freedom from interference and developed the Safety Checker. Designed specifically for the safety level, this tool is the ideal complement to existing test tools because it allows the detection of violations during development. To achieve this, the application is divided into safety classes and access rights are assigned. Violations will be detected right from the compilation process, without the need for test cases or instrumentation. The tool itself does not modify the application, and all data necessary for validation is stored as debugging information. In this way, even multicore applications can be tested without restrictions.
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50 |
Page 51 |
Page 52 |
Page 53 |
Page 54 |
Page 55 |
Page 56
