Search Results

With the introduction of the ISO26262 automotive safety standard there is a burden of proof to show that the processing elements in embedded microcontroller hardware are capable of supporting a certain diagnostic coverage level, depending on the required Automotive Safety Integrity Level (ASIL). The current mechanisms used to provide actual metrics of the Built-in Self Tests (BIST) and Lock Step comparators use Register Transfer Level (RTL) simulations of the internal processing elements which force faults into individual nodes of the design and collect diagnostic coverage results. Although this mechanism is robust, it can only be performed by semiconductor suppliers and is costly. This paper describes a new solution whereby the microcontroller is synthesized into a large Field Programmable Gate Array (FPGA) with a test controller on the outside.

Electronic Control Units of safety critical systems require constant monitoring of the hardware to be able to bring the system to a safe state if any hardware defects or malfunctions are detected. This monitoring includes memory checking, peripheral checking as well as checking the main processor core. However, checking the processor core is difficult because it cannot be guaranteed that the error will be properly detected if the monitor function is running on a processing system which is malfunctioning. To circumvent this issue, several previously presented monitoring concepts (e.g. SAE#2006-01-0840) employ a second external microprocessor to communicate with the main processor to check its integrity. The addition of a second microcontroller and the associated support circuitry that is required adds to the overall costs of the ECU, increases the size and creates significant system complexity.

Electronic Control Units of safety critical systems require constant monitoring of the hardware to be able to bring the system to a safe state if any hardware defects or malfunctions are detected. This monitoring includes memory checking, peripheral checking as well as checking the main processor core. However, checking the processor core is difficult because it cannot be guaranteed that the error will be properly detected if the monitor function is running on a processing system which is malfunctioning. To circumvent this issue, several previously presented monitoring concepts (e.g. SAE#2006-01-0840) employ a second external microprocessor to communicate with the main processor to check its integrity. This paper will present a concept which maps the functions of the external monitoring unit into an internal second processing core which are frequently available on modern, 32bit, monolithic, dual-core microcontrollers.

With the ever increasing amount of available software processing resources in a vehicle, more and more high-level algorithms are emerging to improve the existing systems in a car. Often these algorithms only need a platform with a bus connection and some resources such as processing power and memory space. These functions are predestined to be integrated into existing systems that have free resources. This paper will examine the role of time protection in these multi-algorithm systems and describe what timing protection means and why it is required. The processing time will be partitioned to the different processing levels like interrupts, services and tasks. The problems of timing protection will be illustrated as well as its limitations. The conflict between real-time requirements and timing protection will be shown. Finally Autosar will be examined with focus on timing protection and applicability in actual development projects.

Advanced safety features and new services in connected cars depend on the security of the underlying vehicle functions. Due to the interconnection with the outside world and as a result of being an embedded system a modern vehicle is exposed to both, malicious activities as faced by traditional IT world systems as well as physical attacks. This introduces the need for utilizing hardware-assisted security measures to prevent both kinds of attacks. In this paper we present a survey of the different classes of hardware security devices and depict their different functional range and application. We demonstrate the feasibility of our approach by conducting a case study on an exemplary implementation of a function-on-demand use case. In particular, our example outlines how to apply the different hardware security approaches in practice to address real-world security topics. We conclude with an assessment of today’s hardware security devices.

The increased pressure for power, space, and cost reduction in automotive applications together with the availability of high performance, automotive qualified multicore microcontrollers has lead to the ability to engineer Domain Controller ECUs that can host several separate applications in parallel. The standard automotive constraints however still apply, such as use of AUTOSAR operating system, support for legacy code, hosting OEM supplied code and the ability to determine warranty issues and responsibilities between a group of Tier 1 and Tier 2 vendors who all provide Intellectual Property to the final production ECU. Requirements for safety relevant applications add even more complexity, which in most current approaches demand a reconfiguration of all basic software layers and a major effort to redesign parts of the application code to enable co-existence on the same hardware platform. This paper outlines the conflicting requirements of hosting multiple applications.

Multicore-based ECUs are increasingly used in embedded automotive software systems to allow more demanding automotive applications at moderate cost and energy consumption. Using a high number of parallel processors together with a high number of executed software components results in a practically unmanageable number of deployment alternatives to choose from. However correct deployment is one important step for reaching timing goals and acceptable latency, both also a must to reach safety goals of safety-relevant automotive applications. In this paper we focus at reducing the complexity of deployment decisions during the phases of allocation and scheduling. We tackle this complexity of deployment decisions by a mixed constructive and analytic approach.

The German funded project ARAMiS included work on several demonstrators one of which was a multicore approach on large scale software integration (LSSI) for the automotive domain. Here BMW and Audi intentionally implemented two different integration platforms to gain both experience and real life data on a Hypervisor based concept on one side as well as using only native AUTOSAR-based methods on the other side for later comparison. The idea was to obtain figures on the added overhead both for multicore as well as safety, based on practical work and close-to-production implementations. During implementation and evaluation on one hand there were a lot of valuable lessons learned about multicore in conjunction with safety. On the other hand valuable information was gathered to make it finally possible to set up a cost model for estimation of potential overhead generated by different integration approaches for safety related software functions.