Reading time
5 minutes

High demands are placed on the tools needed for modern-day control unit development in the automotive industry. This is due to the large number of file formats and their variants. Further to this, many different partners are involved in control unit development. Automobile manufacturers define the overall system of communication between ECUs and parts of the application software, which is a big portion of the function of a control unit.

The Tier1 supplier develops the entire application software, making use of basic software components including operating system and RTE, which they in turn receive from a Tier2 software supplier. This opens up a variety of different collaboration models. But which is now the best way forward in terms of AUTOSAR 4, in order to master new challenges such as Ethernet, multi-core, safety and security in an AUTOSAR environment and to establish the necessary cooperation between parties to the optimal extent?

To date, the design of the electrical systems has followed the motto “one ECU for one function”. However, the electrical system architecture for vehicles has been evolving for several years: we are moving away from a system using several individual ECUs towards so-called domain controllers. These are powerful control units which perform several functions within a vehicle domain, for example Body, Powertrain, Chassis and Interior (Fig. 1).

Interoperable tool support is necessary in developing such complex systems. This is the only way to guarantee that software integrators (OEM, Tier 1, or the software company) can combine the different functions of the various suppliers in the controller, such as the Autosar-Multi-Core operating system, basic software and applications (Fig. 2). There are traditionally numerous suppliers in software development for automotive ECUs. The AUTOSAR standard supports compatibility of the software shares. AUTOSAR thus makes it easier to implement complex software architectures in projects.

Open tool chains are able to perfectly handle the amount of different deliveries. Individual function demands, such as functional safety or security, can be seamlessly fulfilled across the entire system.

 

 

Get the most out of processors

A “state of the art” ECU is defined by the combination of software and microprocessor. This means that the software must be tailored to fit the microprocessor. This is achieved when the AUTOSAR operating system and the AUTOSAR-MCALs (Microcontroller Abstraction Layer) fully take advantage of the capabilities of the microprocessor. With a domain controller you can, for example, allocate a number of functions to different cores. MultiCore OS and Autosar RTE thereby allow for the functions to be performed across the entire system.

An open AUTOSAR-Tooling offers many advantages in developing MCALs. As a result, easy integration into the ECU project is guaranteed. To develop marketable MCAL modules, microprocessor manufacturers such as Infineon, Freescale and others use open software configuration tools such as EB tresos Studio by Elektrobit in developing their MCALs. The MCAL modules form the interface between the microprocessor and basic software. OEMs, Tier 1s and Tier 2s also use open configuration tools for basic software configuration. EB tresos Studio supports the AUTOSAR standard and is open to many interfaces of other tools. That is what matters in the AUTOSAR mindset, among other things: MCALs and their ease of integration into projects.

 

Basic software, configuration and optimization tools

As well as the MCALs, each AUTOSAR system needs a highly developed basic software such as EB tresos AutoCore. This also includes the operating system. Both can be developed with the corresponding configuration tool, which rounds off project implementation and, at the same time, provides docking facilities to other ECU-software-development tools (Fig. 3).

 

 

Tools for Multi-Core-System application optimization use such docking facilities as an ECU does not automatically improve in performance by having more cores. This means that the application and basic software on the CPU cores must be optimally distributed in order to achieve the best possible performance. Optimization tools such as Tool Suite from Timing Architects are often used. These tools make it possible to consider and compare various distribution scenarios.

 

Application software

The ECU application is developed from various viewpoints. Among other things, maintainability, extensibility, safety relevance and distributability are taken into account. The corresponding areas of the AUTOSAR world are system modeling, ECU-Extract creation, function development and basic software.

Established and open AUTOSAR authoring tools are available for application development at various manufacturers. The basic software configuration tool EB tresos Studio offers options for exchanging data with all AUTOSARauthoring tools such as dSPACE Systemdesk or Dassault Autosar Builder.

Therefore each area in ECU software development has its own tasks that are best implemented by the corresponding tool. AUTOSAR file formats ensure interoperability between the tools. The standalone tools thereby constitute a continuous toolchain from system design, through function development, basic software configuration and MCAL development, all the way to the optimization of multi-core software architecture

 

The make-toolchain

With a so-called make-toolchain (Fig. 4), which prompts action from various development programs, developers can achieve a high degree of automation within a project. Many processes can also be carried out automatically. The EB tresos Studio tool provides command-line interfaces to import system descriptions, ECU Extracts and configuration files. It also offers a variety of exporters.

Automated evaluations of the project can also be created using the make-toolchain. For example, there is always a need for information on software memory usage or the operation of a continuous integration system in order to carry out software testing.

 

 

Optimal usage of the different AUTOSAR versions

Modern ECU development is carried out on a range of AUTOSAR versions. An open toolchain takes this opportunity to convert project deliveries between the AUTOSAR versions. The objective thereby is to update them to the newest AUTOSAR version. With EB tresos Studio, it is even possible to carry out projects with the combination ASR3.2/ASR4.0.3/4.1.x and ASR4.0.3/4.1.x /ASR4.2.x. This ensures the reusability of previously developed AUTOSAR applications, although new specifications are still published.

Depending on the vehicle manufacturer, OEM-specific modules and third-party modules are required. Open basic software tools integrate these modules directly. This enables the seamless configuration of the modules in an AUTOSAR context. In modern-day ECU development, there is a need for mechanisms which allow efficient and independent work based on project requirements, particularly with regard to complex domain controllers of the future, which will use, for example, AUTOSAR and Linux operating systems in parallel. A harmonized open toolchain provides precisely these mechanisms. It enables the optimal and optimized integration of the ever-increasing volume of software and reduces the levels of complexity.

 

Download our free version of EB tresos evaluation package