Search Results

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.

It is the beginning of a new age: multicore technology from the PC desktop market is now also hitting the automotive domain after several years of maturation. New microcontrollers with two or more main processing cores have been announced to provide the next step change in available computing power while keeping costs and power consumption at a reasonable level. These new multicore devices should not be confused with the specialized safety microcontrollers using two redundant cores to detect possible hardware failures which are already available. Nor should they be confused with the heterogeneous multicore solutions employing an additional support core to offload a single main processing core from real-time tasks (e.g. handling peripherals).

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.

Prototyping of a complete powertrain controller is not generally permissible due to the large number of subsystems involved and the resources required in making the design a reality. The availability of a complete control system reference design at an early stage in the lifecycle can greatly enhance the quality of the system definition and allows early ideas to be prototyped in the application environment. This paper describes the implementation of such a reference design for a gasoline engine and gearbox management control system, integrated into robust housing which can be used for development in a prototype vehicle. The paper also outlines the powertrain subsystems involved, discusses how the system partitioning is achieved, shows the implementation of the partitioning into the physical hardware, and concludes with presenting the system benefits which can be realized.

Machine learning systems are gaining acceptance in the fields of inferential sensing, mechatronic control and prognostics. However, software implementations can place excessive demands on the ECU, and so real-time classification rates are not always possible. This paper describes the integration of a hardware implementation of a machine learning algorithm into a comprehensive hardware and software prototyping environment for powertrain applications. The paper describes the hardware and software architectures developed, provides an overview of the new methodologies necessary to access the power of the machine learning system, and illustrates its application in the powertrain control field

This paper will give an overview of multicore in automotive applications, covering the trends, benefits, challenges, and implementation scenarios. The automotive silicon industry has been building multicore and multiprocessor systems for a long time. The reasons for this choice have been: increased performance, safety redundancy, increased I/O & peripheral, access to multiple architectures (performance type e.g. DSP) and technologies. In the past, multiprocessors have been mainly considered as multi-die, multi-package with simple interconnection such as serial or parallel busses with possible shared memories. The new challenge is to implement a multicore, micro-processor that combines two or more independent processors into a single package, often a single integrated circuit (IC). The multicores allow a computing device to exhibit some form of thread-level parallelism (TLP).

With the increased adoption of AUTOSAR operating systems across the different automotive system domains a notable exception has been that of the safety critical systems. This domain has strict requirements on precise requirements capturing, proven design flow, robust implementation, exhaustive testing, detailed documentation and traceability, and project management processes. These requirements are normally prohibitive to adopt for commercial ‘one size fits all’ solutions due to the huge expense and resources required to meet such a strict regime. So under these constraints AUTOSAR is far from a perfect fit for safety systems. Nonetheless, the attractive features of reuse and portability still make AUTOSAR based systems highly desirable.