Search Results

Advanced driver assistance systems (ADAS) are becoming increasingly important for today's commercial vehicles. It is therefore crucial that different ADAS functionalities interact seamlessly with existing electronic control unit (ECU) networks. For example, autonomous emergency braking (AEB) systems directly influence the brake ECU and engine control. It has already become impossible to reliably validate this growing interconnectedness of control interventions in vehicle behavior with prototype vehicles alone. The relevant tests must be brought into the lab at an earlier development stage to evaluate ECU interaction automatically. This paper presents an approach for using hardware-in-the-loop (HIL) simulation to validate ECU networks for extremely diverse ADAS scenarios, while taking into account real sensor data. In a laboratory environment, the sensor systems based on radars, cameras, and maps are stimulated realistically with a combination of simulation and animation.

The application of a communication infrastructure for hybrid test systems is currently a topic in the aerospace industry, as also in other industries. One main reason is flexibility. Future laboratory tests means (LTMs) need to be easier to exchange and reuse than they are today. They may originate from different suppliers and parts of them may need to fulfill special requirements and thus be based on dedicated technologies. The desired exchangeability needs to be achieved although suppliers employ different technologies with regard to specific needs. To achieve interoperability, a standardized transport mechanism between test systems is required. Designing such a mechanism poses a challenge as there are several different types of data that have to be exchanged. Simulation data is a prominent example. It has to be handled differently than control data, for example. No one technique or technology fits perfectly for all types of data.

Due to tougher legislation on exhaust emissions reduction and the consumer demand for more power and mobility and less fuel consumption, the functionality in today's engine management systems continues to grow. The electronic engine control units (ECUs) have to perform more control tasks using new sensors and actuators, along with the corresponding self-diagnostics (OBD, on-board diagnosis). All this leads to continuously increasing demands on automated hardware-in-the-loop (HIL) test systems. HIL technology has advanced in parallel to the ECUs, and is today an indispensable tool for developing automotive electronics. This paper therefore aims to provide a comprehensive and state-of-the-art survey of HIL test systems for engine controllers. First of all, a brief introduction to the ECU's functionality is given.

In modern vehicles the architecture of electronics is growing more and more complex because both the number of electronic functions – e.g. implemented as software modules – as well as the level of networking between electronic control units (ECUs) is steadily increasing. This complexity leads to greater propagation of failure symptoms, and diagnosing the causes of failure becomes a new challenge. Diagnostics aims at detecting failures such as defect sensors or faulty communication messages. It is subdivided into diagnosis algorithms on an ECU and algorithms running offboard, e.g. on a diagnostic tester. These algorithms have to complement each other in the best possible way. While in the past the diagnosis algorithm was developed late in the development process, nowadays there are efforts to start the development of such algorithms earlier – at least in parallel to developing a new feature itself. This would allow developers to verify the diagnosis algorithms in early design stages.

Model-based development and autocoding have become common practice in the automotive industry over the past few years. The industry is using these methods to tackle a situation in which complexity is constantly growing and development times are constantly decreasing, while the safety requirements for the software stay the same or even increase. The debate is no longer whether these methods are useful, but rather on the conditions for achieving optimum results with them. From the experiences made during the last decade this paper shows some of the key factors helping to achieve success when introducing or extending the deployment of automatic code generation in a model-based design process.

This presentation focuses on several examples of partnerships between tool suppliers and embedded software developers in which state-of-the-art tools are used to optimize a variety of electric and hybrid vehicle architectures. Projects with Automotive OEMs, Tier One Suppliers as well as with academic institutions will be described. Due to the growing complexity in multiple electronic control units (“ECUs”) inter-communicating over numerous network bus systems, combined with the challenge of controlling and maintaining charges for electric motors, vehicle development would be impossible without use of increasingly sophisticated tools. Hybrid drive trains are much more complex than conventional ones, they have at least one degree of freedom more.

Permanently increasing software complexity of today's electronic control units (ECUs) makes testing a central and significant task within embedded software development. While new software functions are still being developed or optimized, other functions already undergo certain tests, mostly on module level but also on system and integration level. Testing must be done as early as possible within the automotive development process. Typically ECU software developers test new function modules by stimulating the code with test data and capturing the modules' output behavior to compare it with reference data. This paper presents a new and systematic way of testing embedded software for automotive electronics, called MTest. MTest combines the classical module test with model-based development. The central element of MTest is the classification-tree method, which has originally been developed by the DaimlerChrysler research department.

Hybrid test systems are gaining more and more significance in the aerospace industry. At the heart of these systems is a standardized communication infrastructure. There are many challenges when designing the communication infrastructure. For example, it requires very specific knowledge to boot a hybrid system, manage its configuration process, and start and stop the execution of applications, such as simulations, panels or recorders. Likewise, when testers use a heterogeneous test environment, they cannot commit themselves too much to every single test means and its special characteristics. Nevertheless, testers must always be able to monitor and control every test system. This means, they must be able to determine the current overall system status and the current status of its components and parts. Examples for this are hardware components, such as real-time processors and I/O boards, as well as software applications, such as real-time simulations models on the test system.

Automotive technology is rapidly changing with electrification of vehicles, driver assistance systems, advanced safety systems etc. This advancement in technology is making the task of validation and verification of embedded software complex and challenging. In addition to the component testing, integration testing imposes even tougher requirements for software testing. To meet these challenges dSPACE is continuously evolving the Hardware-In-the-Loop (HIL) technology to provide a systematic way to manage this task. The paper presents developments in the HIL hardware technology with latest quad-core processors, FPGA based I/O technology and communication bus systems such as Flexray. Also presented are developments of the software components such as advanced user interfaces, GPS information integration, real-time testing and simulation models. This paper provides a real-world example of implication of integration testing on HIL environment for Chassis Controls.

Embedded software in the car is becoming increasingly complex due to the growing number of software-based controller functions and the increasing complexity of the software itself. Model-based development with Simulink combined with TargetLink for automatic code generation helps significantly to improve the quality of the embedded software. The development of large-scale Simulink models in distributed teams is a challenging task, especially when developing safety-critical software that must fulfill requirements stated in the ISO 26262 [1] safety standard. In practice, many questions on how to avoid the pitfalls of distributed model-based development remain open, such as how to define an appropriate model architecture, handle model complexity, and achieve compliance with ISO 26262. The intent of this paper is threefold. Firstly, we summarize those requirements of ISO 26262 that are relevant for developing complex software in a distributed environment.

The technological development in the field of automotive electronics is proceeding at almost break-neck speed. The functions being developed and integrated into cars are growing in complexity and volume. With the increasing number and variety of sensors and actuators, electronics have to handle a greater amount of data, and the acquisition and generation of I/O signals is also growing in complexity, for example, in engine management applications. Moreover, intelligent and complex algorithms need to be processed in a minimum of time. This all intensifies the need for Rapid Control Prototyping (RCP), a proven method of decisively speeding up the model-based software development process of automotive electronic control units (ECUs) [1],[2]. All these demanding tasks, including connecting sensors and actuators to the RCP system, need to be performed within a standard prototyping environment.

Hardware-in-the-loop (HIL) test benches are indispensable for the development of modern vehicle dynamics controllers (VDCs). They can be regarded as a standard methodology today, because of the extremely safety-critical nature of the multi-sensor and multi-actuator systems used in vehicle dynamics control. The required high quality standards can only be ensured by systematic testing within a virtual HIL environment before going into a real car. This paper aims to provide a condensed technical over-view of state-of-the-art HIL test systems for VDCs, which are currently widely used in passenger cars, in the form of ABS and TCS, as well as ESP, or integrated chassis control, which is just coming onto the market. First, a short introduction to the basic functionality of these types of ECUs is given, and the reasons why HIL testing is necessary and especially useful for VDCs are discussed.

The development of perception functions for tomorrow’s automated vehicles is driven by enormous amounts of data: often exceeding a gigabyte per second and reaching into the terabytes per hour. Data is typically gathered by a fleet of dozens of mule vehicles which multiply the data generated into the hundreds of petabytes per year. Traditional methods for fueling data-driven development would record every bit of every second of a data logging drive on solid-state drives located on a PC in the vehicle. Recorded data must then be exported from these drives using an upload station which pushes to the data lake after arriving back at the garage. This paper considers different techniques for curating logged data.

This paper presents a demonstrator developed in the European CleanSky2 project MISSION (Modelling and Simulation Tools for Systems Integration on Aircraft). Its scope is the development towards a seamless integrated, interconnected toolchain enabling more efficient processes with less rework time in todays, highly collaborative aerospace domain design applications. The demonstration described here, consists of an open, modular and multitool platform implementation, using specific techniques to achieve fully traceable (early stage) requirements verification by virtual testing. The most promising approach is a model based integration along the whole process from requirements definition to the verified, integrated (and certified) system. Extending previous publications in this series, the paper introduces the motivation and briefly describes the technical background and a potential implementation of a workflow suitable for that target.