Search Results

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.

Hardware-in-the-loop (HIL) simulation is now a standard component in the vehicle development process as a method for testing electronic control unit (ECU) software. HIL simulation is used for all aspects of development, naturally including safety-relevant functions and systems. This applies to all test tasks (from function testing to release tests, testing a single ECU or an ECU network, and so on) and also to different vehicle domains: The drivetrain, vehicle dynamics, driver assistance systems, interior/comfort systems and infotainment are all tested by HIL simulation. At the same time, modern vehicles feature more and more safety-related systems such as Adaptive Cruise Control, Electronic Stability Program, Power Assisted Steering, and Integrated Chassis Management.

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.

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.

The number of electrical and electronic components in modern vehicles is constantly growing. Increasingly, functionalities are being distributed across several electronic control units (ECUs). While suppliers themselves are responsible for ensuring that individual ECUs function properly, only the OEM can test distributed functions. Moreover, with the volume of testing steadily growing, automated sequences are absolutely essential. To test electronic networks in the vehicle, Ford Europe is using platform-based hardware-in-the-loop simulation with integrated failure insertion. The company is setting up a uniform, project-independent procedure, from standardized test definition to automated test sequences on a virtual vehicle, right through to structured evaluation.

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.