Validating Diagnostics in Early Development Stages Explanations by means of an Example of an automatic exterior lighting control Dipl.-Ing. Valentin Adam, Daimler AG Dipl.-Ing. Matthias Kohlweyer, Daimler AG Dipl.-Inf. Petra Nawratil, dspace GmbH Dipl.-Wirt.-Inf. Heinrich Balzer, dspace GmbH Translation of: Diagnoseverifikation in frühen Entwicklungsphasen Published at: Elektronik automotive, 12/2008
Validating Diagnostics in Early Development Stages Explanations by means of an Example of an automatic exterior lighting control Electronic faults in a vehicle, such as a broken cable or a sensor that returns erroneous data, are unavoidable. The Electronic control s task is to react to them. For example, an automatic lighting control that activates the lights in darkness must also be able to switch them on for safety if the light sensor is defective. The fault can also be indicated in the vehicle s display. This all requires diagnostic functionality that detects and analyzes a fault and reacts to it. The diagnostic functionalities of the electronic control units (ECUs) have to be tested at an early stage of the development process. The Challenge of Testing Diagnostics In today s development processes, individual software components are often developed and tested first, then integrated, and it is not possible to study the overall system from the diagnostics point of view until the end. This means that diagnostic functionality cannot be tested in the overall system until a very late stage frequently not until the actual vehicle. One reason for late testing is that diagnostics are distributed across the entire system. They not only have to identify faults in individual components but also diagnose the system s interconnected functionality, which is often distributed across several ECUs and implemented by various software components. Ideally, the development process needs tool support for setting up a complete system of several software components at an early stage so that the diagnostics can be analyzed and verified. The ultimate objective is to achieve greater maturity of diagnostic functionality more quickly and more efficiently. These processes need methods and tools to support them. The AUTOSAR standard [1] makes it possible to produce a formal representation of software components and whole system architectures so that an unambiguous description is available. In SystemDesk, the architecture tool from dspace, an AUTOSAR architecture can not only be modeled [2] but also simulated [3]. This means that an overall (distributed) system can be set up at an early stage, and tests covering the diagnostic functionalities can be run. System Architecture for Exterior Lighting Control In a joint project with Daimler AG, dspace is studying an example to investigate the potential of early diagnostics testing. Daimler AG already relies intensively on model-based development with AUTOSAR, so complete system models based on AUTOSAR are already available. A system for automatic lighting control was chosen as the example for this case study (Figure 1). The aim is to model a simulatable system that can be used for testing the diagnostics. A central lighting module is responsible for activating the different lamps on the vehicle. It receives inputs from various sources such as the light switch that is turned on by the driver and a rain/light sensor. When the rain/light sensor detects a rainy or dark situation, the driving lights can be activated automatically. The system comprises a central light control software component and software drivers deployed on two ECUs, one for the front and one for the rear lighting module. In addition, the models of the drivers and lamps are integrated as plant models. Figure 1: Graphical modeling of components for lighting control (dark color on the left) and the associated plant models (light color on the right). 2 Elektronik automotive 12/2008
The key factor is the ability to model the application software components access to the basic software and to simulate it later. Two modules in the basic software are particularly important in implementing diagnostic functionality: the Diagnostic Event Manager (DEM) and the Diagnostic Communication Manager (DCM). When system misbehavior is detected by the application or reported by a driver, a function call is sent to the DEM, which sets the misbehavior as the status of a predefined event. The diagnostic module itself stores the associated failure as a diagnostic trouble code (DTC). Diagnostic trouble codes can be read out by a tester, for example, in a service dealership. The DCM receives the diagnostic queries from the dealership tester, collects the necessary data, and generates the response. After the individual application software components have been modeled with an AUTOSAR-compliant behavior modeling tool such as TargetLink from dspace, code is generated for them, including the AUTOSAR software component description. If the system architecture is already available, the user only needs to complete the implementations. If it is not available, the individual components are brought together to make an architecture in SystemDesk. The DEM is also configured and connected to the application software components in this process. For simulation, either a manufacturerspecific DEM or a DEM that is configurable in SystemDesk itself can be integrated. The architecture is also mapped to the hardware topology comprised of several ECUs. Finally, the run-time environment (RTE) can also be generated in SystemDesk as middleware implementing the communication between application software components and basic software components. This can then be used in conjunction with the application code for individual software components to simulate the overall system in SystemDesk. Diagnostics Testing The diagnostic functionality in the system model can now be verified at an early stage in the development process. The following questions can be investigated and answered: Are faults in the system correctly detected by the diagnostic functionality that has been implemented, and is the response to them correct? Are all faults detected? Were the fault memory modules configured correctly, and are the right DTCs stored in the basic software? Test vectors Performing system analyses that will answer these questions requires tool support, since the systems under investigation are usually highly complex. Moreover, it is usually not possible at all to test a system that consists of networked software components and ECUs before the ECUs are available. The solution is offline simulation of such systems on a PC, which provides the decisive ability to validate the diagnostic behavior implemented for a system at an early stage. Some inputs in the exterior lighting control system are still open. For example, signals are received from the rain/light sensor and the light switch, but these have not been explicitly included in the model. For the system to be tested, these open inputs have to be stimulated by test vectors. The data for these is created by means of special test tools. The test vectors used in a real test process are converted to a text file, read into SystemDesk, and used to stimulate the open ports during simulation. The test tool also provides information for evaluating Behavior modeling tool.h.c.arxml Architecture and simulation tool Test creation and evaluation tool Test results Figure 2: Tools and exchange data used for diagnostics testing. the tests. This includes the data to be measured and logged, and the expected results. Information on the data to be measured is also read into SystemDesk so that the data can be logged during simulation. The captured simulation results can then be read back into the test tool, where it is evaluated against the expected results to decide whether the test was successful (the system reacted as expected) or not (there were differences between the logged and the expected behavior). The tools needed for the diagnostics test and the data to be exchanged are shown in Figure 2. Early validation of diagnostics makes it possible to correct any discovered weaknesses and to close any gaps. It is also possible to implement and test only a part of the diagnostics initially if so decided. Because they provide a better understanding of the system to be diagnosed, the validation test results are an aid to implementing other parts of the diagnostics and enhancing the maturity of the diagnostic functionality. Elektronik automotive 12/2008 3
Tested Error Cases In the example of the exterior lighting control system described here, three different error cases are investigated by means of simulation to make a correct decision on diagnostics implementation based on the logged system behavior: (1) The component connected to an ECU automatically detects a fault and reports it to the exterior lighting control. This acts as the function master and takes appropriate substitute action, at the same time placing a DTC in the fault memory. In the simulation, this behavior is mimicked by the stimulating test vector sending the diagnostic signal that the rain/ light sensor would send to the lighting control. In response to the absence of sensor data, the function activates the emergency lighting and switches the vehicle s exterior lighting on. (2) In another scenario, a part of the diagnostic functionality is integrated into the lighting control itself. The driver s input, i.e. turning the light switch, is passed to the lighting ECU. The application implemented in the ECU checks the plausibility of the light switch position that it received, and if there is a fault, instigates defined substitute actions. In the simulation, this is achieved by manipulating the signals of the light switch so that the stimulating test vector simultaneously activates two mutually exclusive states. The Off and Automatic Driving Light signals of the light switch are modified for this. Here too, the misbehavior is detected by the application and results in a fault memory entry based on the interfaces defined in AUTOSAR. (3) As well as misbehaviors that are detectable at application level, there are other fault cases such as short circuits to ground and open outputs that can be detected and reported to the diagnostics module by intelligent hardware drivers. For example, these different states can be detected by current measurements in the paths of the controlled lights. In the simulation, a short circuit is simulated by manipulating the measured current values in the system model. In addition to simulating faults with suitable test vectors and logging the output signals, the fault memory entries are also evaluated separately. For offline simulation of this, it is sufficient to integrate rudimentary DCM functionality. This queries the contents of the fault memory cyclically via the interfaces standardized by AUTOSAR and uses them to log the behavior of the DEM. Conclusion and Outlook In the project run by dspace and Daimler AG, an environment was created in which it was possible to validate the diagnostic functions of a system in a very early development phase. This was done by integrating AUTOSARcompliant ECU applications, such as the lighting control that is used, including the necessary plant and driver models, into a system architecture. Work on integrating configured basic software modules into the system continues, and the RTE needed for communication is generated. For simulating the system offline, the test vectors used in the real test process are employed. These are read into SystemDesk during simulation, and the software components output signals and the fault memory s behavior in response to stimulation are logged. By studying an overall system and not only individual, selected components, the diagnostics for distributed functions can be verified almost completely. Any dependencies and fault effects in the overall system can be identified. By using the architecture standardized in AUTOSAR, consisting of the ECU applications, the RTE, and parts of the basic software, the simulation system is also able to verify whether the implemented diagnostic modules are correctly configured. Literature [1] http://www.autosar.org [2] Stichling, D.; Niggemann, O.; Stroop, J.; Otterbach, R.: From Function Design to System Design in Model-Based Software Development, Translation of Vom Funktionsentwurf zum Systemdesign in der modellbasierten Software-Entwicklung ; ATZ Automobiltechnische Zeitschrift, 01/2007. [3] Nawratil, P.; Niggemann, O.: The Little Green Arrow, Translation of Der kleine grüne Pfeil ; Hanser Automotive, 08/2008. 4 Elektronik automotive 12/2008
www.dspace.com Company Headquarters in Germany dspace GmbH Technologiepark 25 33100 Paderborn Tel.: +49 5251 1638-0 Fax: +49 5251 66529 info@dspace.de China dspace GmbH Shanghai Representative Office Jinlinghaixin Building 13A No. 666, Fuzhou Road 2000001 Shanghai Tel.: +86 21 6391 7666 Fax: +86 21 6391 7445 infochina@dspace.com United Kingdom dspace Ltd. Unit B7. Beech House Melbourn Science Park Melbourn Hertfordshire. SG8 6HB Tel.: +44 1763 269 020 Fax: +44 1763 269 021 info@dspace.co.uk Japan dspace Japan K.K. 10F Gotenyama Trust Tower 4-7-35 Kitashinagawa Shinagawa-ku Tokyo 140-0001 Tel.: +81 3 5798 5460 Fax: +81 3 5798 5464 info@dspace.jp France dspace SARL 7 Burospace Route de Gisy 91570 Bièvres Tel.: +33 169 355 060 Fax: +33 169 355 061 info@dspace.fr USA and Canada dspace Inc. 50131 Pontiac Trail Wixom. MI 48393-2020 Tel.: +1 248 295 4700 Fax: +1 248 295 2950 info@dspaceinc.com 12/2008