Search Results

ISO 26262 is the actual standard for Functional Safety of automotive E/E (Electric/Electronic) systems. One of the challenges in the application of the standard is the distribution of safety related activities among the participants in the supply chain. In this paper, the concept of a Safety Element out of Context (SEooC) development will be analyzed showing its current problematic aspects and difficulties in implementing such an approach in a concrete typical automotive development flow with different participants (e.g. from OEM, tier 1 to semiconductor supplier) in the supply chain. The discussed aspects focus on the functional safety requirements of generic hardware and software development across the supply chain where the final integration of the developed element is not known at design time and therefore an assumption based mechanism shall be used.

Automotive applications classed as safety-related or safety-critical are now important differentiating technologies in the automotive industry. The emergence of safety standard ISO 26262 underlines the increasing importance of safety in automotive software. As well as functional requirements, hard real-time requirements are of crucial importance to safety-related software as there is a need to prove that the system functionality is fulfilled, even in worst-case scenarios. Measurement-based WCET (Worst-Case Execution Time) analysis combines on-target timing measurements with static analysis of program structure to calculate predicted worst-case paths and times. This is in contrast to traditional end-to-end timing measurements, which give no confidence that the worst-case path is actually tested and no insight into the location of any timing problems that do emerge.

Modern automotive systems are highly complex, incorporating more than one CPU core, running with more than 100 MHz and consisting of millions of transistors. Similarly, software complexity is growing at an even higher rate. There is thus a high expectation in the automotive market that deliveries from μC suppliers should also contain an independent software layer - the Microcontroller Abstraction Layer - placed on the register level of the μC. The I/O drivers standardization activity, which started with the HIS (Hersteller Initiative Software), is now continued with AUTOSAR (Automotive Open System Architecture) which will standardize all layers of the ECU basic software. The complex interaction between specifically implemented hardware features and standardized software requirements is a big challenge for software driver development.

In modern automotive systems, the complexity is growing by incorporating highly sophisticated microcontrollers running with more than 100MHz and consisting of more than 2500 registers. Software complexity is also growing in a similar, if not higher, rate. As semiconductor suppliers are also expected by their customers to include a hardware-dependent software layer in their products, testing must now include not only the hardware product but the delivery bundle of hardware and software modules. Testing this hardware-dependent software is complicated by the big amount of possible hardware-dependent configurations for this software layer which also extensively change the hardware test bench used in verification. The challenge of configuration complexity is solved by extensive use of test automation for both software generation, test bench configuration and test case runs.