1 / 8 Support of Electric/Electronic Diagnosis in Production for Passenger Car Project in China 1 Overview In Mercedes-Benz passenger car production the IS tester is used for both purely diagnostic functions and production-relevant tasks which are elemental for the operability of the overall vehicle. Mercedes-Benz C-Class and E-Class passenger cars will be produced in China beginning from the year of 2005. To build up the know-how of the diagnosis system, configure and deploy the environment, adapt and test the applications are key issues for the production line set up. In addition, stable & robust routine operation, and immediate technical services should be strictly guaranteed. DaimlerChrysler SIM Technology Co. Ltd. should be closely involved in these tasks and services for reasons of localization and in-house knowledge. The structure of this document is as follows. In Section 2, a description of the ECU diagnosis in production line is provided with emphasis on the NISP environment. The possible tasks for DaimlerChrysler SIM Tech. for supporting the electric/electronic diagnosis for passenger cars in plants in China is given in Section 3. Section 4 describe the necessary information we need for a possible start. 2 ECU Diagnosis in Production In Mercedes-Benz passenger car production, the so-called IS tester was introduced for diagnosis of ECUs when automotive diagnostics first became a key issue. In principle, the IS tester is an application system which allows an ECU to be tested over a serial diagnostic line. There is a steady increase in the number of electronics systems deployed in the vehicle and the trend is growing. These systems need to be tested and their coding customized for the vehicle and its environment. This means that you will not find a car on the market today that wasn't built using the IS tester. The IS tester is used for both purely diagnostic functions and production-relevant tasks which are elemental for the operability of the overall vehicle. The latest generation of ECUs no longer consists of isolated partial systems. Instead, they belong to a networked overall system. ECU communication is effected over CAN or optical bus systems, enabling data, status messages, and error states to be exchanged. In contrast to diagnosis of smaller individual systems, diagnosis of large, networked systems requires extensive system know-how. 2.1. The IS Tester There are four key tasks for testing operations using the IS tester. 1. Test whether the ECU is functional (self-diagnosis). 2. Test whether all of the sensors and final control elements are functional and the wiring (cables) has been done properly (functional test). Often such errors will only be detected, if some kind of interactive operation has been performed by the testing personnel. 3. Test whether the correct ECU has been installed in the vehicle. The prerequisite for this task is that a released vehicle data record has to be available. 4. Load coding data to customize the ECU to the vehicle.
2 / 8 Hardware The IS tester system is a standard (industrial) PC which is connected to the diagnostic jack by means of an appropriate communications hardware device the so-called coupling card. The coupling card deploys firmware which allows all of the communication protocols used to be processed independently. Each pin of the diagnostic jack leads to its own coupling card, enabling simultaneous communication with several ECUs. A printer is connected for output of the test label, which is stuck onto the paperwork accompanying (assembly documents) the vehicle. There are various hardware versions of the IS tester used, most of which are either suspended or stationary devices. The suspended testers are moved along with the vehicle in the line, whereas the stationary testers are generally found at rework stations and other stationary testing stations such as the roller tester. All of the devices are linked to a central master computer via a radio network. The transmission protocol used is TCP/IP. Testers are generally operated via an infra-red remote control, typically requiring only YES/NO decisions to be input. Software The software used depends on the testing station. The roller tester software allows all of the ECU tests to be done in sequence. It is programmed in C/C++. For these systems, changes to the test content can only be effected through subsequent modification of the entire system, i.e. a completely new routine will have to be installed. In assembly (trim line, chassis, and finish) and for the engine check, diagnosis is done using the NISP system (New IS Tester Program). NISP is based on a multi-application core which interprets editable test program files and ECU description files. Thus, NISP reacts considerably more flexibly to changes to test content. In addition to more flexible parameterization, NISP enables several ECUs to be diagnosed in parallel. All of the software systems mentioned above are DOS applications. The roller tester software is a pure real-mode application while NISP itself runs in protected mode to enable multitasking (the underlying software is the RT kernel from OnTime Informatik). 2.2. Where Testing Is Done Passenger car production is done in a line made up of a number of different stations where parts are installed and electronic components need to be tested to ensure that they will function properly. Most production lines comprise the stations set out below: Trim Line (Assembly) The vehicle is in a state where the electrical harness is easily accessible. Many of the ECUs have been mounted and wired. Often the sensors and final control elements have not yet been hooked up so that an ECU may only be partially tested. This station is where the ECUs are typically coded. Due to the incomplete state of the assembly, some errors have to be ignored (i.e. they are masked out). At this stage in production, it is important that all of the errors resulting from incorrect wiring or where the ECU is poorly accessible are detected because correcting these errors requires enormous effort at later stages in the process (paneling or the cockpit might need to be removed). Chassis (Assembly) At this stage in the production process, the vehicle is almost complete, i.e. paneling has been mounted, the engine and transmission assembled, and all the sensors and actuators should be operable and connected to the related ECU. This is where the sensors and final control elements are tested. Also, the coding done in the trim line is checked and, if need be, completed as far as is feasible. Finishing (Assembly) At the end of the assembly line, the internal error memory in all of the ECUs are cleared. In addition, special types of vehicles or those equipped with extras (e.g. anti-theft protection system) are tested since testing of such special features in the line would have been too time consuming. Roller Tester The roller tester is used to perform all the tests where the vehicle needs to be driven (so-called dynamic tests). Here, testing personnel can determine whether the engine speed sensor, for example, is putting out the correct signals. Testing done at this station consists of a driving program, where the driver can check the vehicle's reactions in various situations. The ECUs to be tested are put into diagnostic mode and are either read out or
3 / 8 actively control their respective control elements (e.g. ABS braking tests). Sensors capture the changes taking place in the vehicle during these actions and the data is interpreted by the ECU or the testing device. In addition to testing of ECU functions, manual tests are carried out where testing personnel evaluated the quality of the braking system subjectively. Engine Check The engine check targets correct adjustment of the engine settings (emissions, idle speed, etc.). Since this should only be done when the engine is warm, this station generally follows on the roller tester. Dynamic tests are performed here with control elements in this case the throttle valve or fuel injection pump. The ECUs are typically measured using an oxygen sensor or external equipment which analyzes the exhaust emissions. Rework If there is a need, a vehicle may be pulled from the line at any time and tested in a rework station. Rework means that those errors which would delay work in the line due to their scope or difficulty are corrected at reserved stations on the shop floor. In addition to rework in the line, there is a separate rework station where severe or time-consuming faults are cleared. The IS tester supports rework personnel in locating the error: individual ECUs may be selected and tested. After an error has been corrected, the entire vehicle is rechecked, including the tests already done in the trim line and chassis assembly. Special Tests In addition to the testing stations described above, special tests may be performed on vehicles which have already been delivered. This is the case, for example, for test vehicles taking part in road tests because new electronic components have been installed. Typically, the scope of testing done here corresponds to rework testing. 2.3. Testing Operations Testing operations using the IS tester are typically made up of five steps: 1. Adaptation The vehicle is delivered to the tester station, where the IS tester is connected to it via the diagnostic jack. The vehicle needs to be unambiguously identified for the testing system, so the production number is entered. This is typically done using a bar code scanner. At some roller tester stations, the production number may also be input directly into the testing system by being automatically read out from a mobile data medium when the car is driven into the tester. The production number is transferred to the testing system over a PC-SPC coupling. The IS tester in the roller tester station also controls peripheral devices (the doors, bollards, rollers, ventilation, etc.). 2. ECU Test All the ECUs in the vehicle are put into diagnostic mode so that their identifying information may be read out. Based on the vehicle data set, which contains all of the part IDs for released ECUs), the system checks whether the right ECUs have been installed in the correct places. 3. Functional Test The functional test is made up of all the steps where communication with the ECU in diagnostic mode is effected in order to check that it is operating trouble-free. In the simplest case, the only thing that will happen is that the internal error memory is read out. In more complicated testing, test personnel are required to perform actions that should be detected by the ECU (e.g. actuating a switch). The test program for functional testing is customized to each vehicle (and depends largely on the features and extras installed). All of the actions are initiated by the testing system (i.e. prompted testing). 4. Coding Many ECUs are codable, i.e. the vehicle is adapted to the ECU. For example, the instrument cluster is adapted to consider a ski-bag which may lead to a difference in the characteristic curve of the fuel tank. In the engine system, type-specific ID fields for the ignition point and injection period. The coding information is either read out of the ECU-specific coding files or gathered during the testing operations on the basis of the vehicle data record.
4 / 8 5. Documentation A test label is output for documentation of the testing operations. The label lists all the ECUs tested, together with the part IDs, software releases, and errors returned. The label is stuck onto the assembly documents, which are microfilmed and archived. At the same time, the label data and other result data are transferred to a central archive for statistical evaluation of the tests performed (not done in all plants). The archiving system is a UNIX system. 2.4. Components Making up the Application NISP (New IS Tester Program) aims at making testing of ECUs in the vehicle using the new technology more efficient and faster, thus cutting costs. Also, a number of new concepts have been introduced to ensure the extensibility of this diagnosis tool in the long run. The concepts on which NISP is based on, are as follows: The core system is a fixed-programmed application for performance of all testing operations. The core is ECU independent, i.e. no matter which modifications are made to existing ECUs or how many different new control units are developed for implementation, the NISP core will require no changes. Functional testing is configured using a problem-oriented language. This language describes testing at the logical level. As an alternative, NISP offers a graphical input tool so that test programs (in part, at least) may be created by others than programmers. All the ECU functionalities at the protocol level are located in ECU description files. This allows a separation between the logical description of the test program and the physical communication between the tester and the ECU at the protocol level and the presentation of the results of this communication. The ECU description files may be either NISP-own SET files or CBF files parameterized in DIOGENES. The system is able to test more than one ECU in parallel. The availability of separate diagnostic lines to each of the ECUs makes this viable. A drawback, however, is the growing trend towards implementing the ECUs in bus topologies. NISP is not just a single program: it is a system made up of individual components which have been aligned to interwork smoothly for efficient and fast testing of the electric/electronics system. The principle structure of the NISP system is set out below:
5 / 8 Test program, compiler and interpreter The NISP core system (PAH), which actually executes the test program, is controlled by the so-called control table. The control table contains a number of basic functions (handler functions) and elementary control constructs (loops, assignments, and conditional branches) and is not created manually as its format is a binary format which has been optimized for the PAH. The test program is created in a general language PAS (test application language) and then converted into the binary format needed by the test program compiler (PAC). This approach allows the test operations to be time-optimized and the programs to be created at a higher level of abstraction. Communications processors are required for the communication with the ECUs. The devices used are the CAESAR communications modules. The firmware installed on this hardware enables emulation of the legacy coupling card. The communication modules use a variety of protocols. Test application generator The test programs are typically created manually using a standard text editor. A graphical tool the test application generator PAG is also provided, which allows graphical objects to be combined to create a test program. This approach is quick and easy and does not necessitate expertise in the programming language. On the contrary, the tool is facilitating a clear overview of the overall scope of operations and aims preventing syntactic programming errors, allowing testing personnel with no programming know-how to create a test program. While the PAG makes it easier testing staff to create a syntactically correct test program, it does not provide assistance in placing the individual testing sequences in the correct logical order. Therefore, a great deal of experience is the key factor in designing a good test program, either by using the graphical tool, either by creating them manually. Vehicle data For vehicle testing, more is needed than just the control table: ECU description data and the vehicle data are both required. The ECU description data DIOGENES data (or SET files) sets out the byte strings necessary for access to the related ECU information and how the responses are to be interpreted. The vehicle data is used to detect the vehicle-specific parts to be tested and for generation of the vehicle-dependent coding information necessary for most of the ECUs. IS Tester Server The higher-ranking components are found on a so-called IS tester server, one of which is located in almost all of the plants. This is typically a UNIX system which, supported by a database, gathers all the result data and interprets it. In addition, this system is the primary source of vehicle data for the test system. In its function as the central pool for result data, this computer is also an administrative tool which maintains the test programs and miscellaneous configuration data at a central location and is responsible for distributing them as required. The IS tester server has interfaces to the data pools within the plant, receiving the necessary vehicle data periodically and providing quality data relevant for the testing operations as needed. In exceptional cases, an individual IS tester may access the inter-plant data systems in order to load the most current vehicle data or to check sensitive result data directly into the appropriate databases. 2.5 The NISP Environment NISP is the testing system of choice which is integrated into the current Mercedes-Benz passenger car production process. The figure below shows the position of NISP within production and the interfaces to the respective process components. The configuration set out below is representative for the large production plants Sindelfingen, Bremen, and Rastatt. As is clearly depicted, the NISP runtime system in combination with the ECOS runtime system creates the interface to the vehicle. Configuration of these runtime systems is effected by the related programs responsible for their creation (PAG for NISP, the test step editor for ECOS). Provision of data (shown in red) in the form of the current ECU description data in DIOGENES/CAESAR format is in the pipeline. To be able to recognize the possible functions offered by the ECUs, the generating systems will also require access to this data.
6 / 8 2.6. Overview of NISP technical features Graphical creation tool and problem-oriented standard language for testing operations. Enables parallel communication with several ECUs. Multiplatform support for the intermediate code (DOS, Windows, UNIX). Combination of ECU testing (serial) with testing of the electrical system (consumer test, ECOS). Several testing operations can be run separately with manual or automatic selection (model dependent). Multilanguage capability through deployment of text files for output texts with referencing done by assigning numbers. Graphical user interface with specific add-ons (operation via remote control). Network integration: o Pull vehicle data (data needed daily is gathered and stored in a group file). o Online provision of vehicle data individually for each vehicle to be tested. o Send result data and error states. o Remote maintenance. Coding may be done either via external coding files or via SCN. Generation of quality and/or statistical data. Configurable printer functions (label printout). Auto-recognition of ECU variants. Check for error masking (e.g. vehicle-specific errors). Definition of ECU interdependencies. Rework functions (dynamic menus as per the relevant error state). 32-bit DOS application in protected mode. Cooperative multitasking (RT Kernel) Diagnostic protocols: o Kühner (MB-Iso) o Keyword FB, Keyword 2000 (passenger cars and trucks) o RTMD+ o Free-Running
7 / 8 Communication hardware: o CAESAR module(s) Parts A, B, C (recommended) o CAESAR Part C/IR infra-red interface o BaRa 4x coupling cards (Coupling cards via V24) System requirements (for NISP 5.0 and later): o Minimum requirements Pentium 133 (recommended: 300 MHz or faster) o 64 MB RAM, 100 MB hard disk o ISA port for CAESAR Part C 3 Possible tasks for DaimlerChrysler SIM Tech. Mercedes-Benz C-Class and E-Class passenger cars will be produced in China beginning from the year of 2005. Since the testing system is integrated in the production process, it is subject to the cycle times applicable for the line. This means that a complete vehicle test needs to be finished within 5 to 10 minutes. This is the time for only a single vehicle and, in volume production, this means that the system may be in operation round the clock. If the time frame for testing a vehicle is exceeded because the unavailability of the system or the lack of training of the testing personnel, the untested vehicles leaving the line (which naturally continues to run) will have to go to rework, which costs time and money. Therefore, there are a number of basic technical requirements that a testing system deployed in the production environment has to fulfill: Stable The testing system should evidence almost 100% availability. In particular, it should neither crash nor lose performance because of the plant relocation. Fast The complete vehicle test must be finished within the time frame defined for the station. Easy to use and robust To build up the know-how of the diagnosis system, configure and deploy the environment, adapt and test the applications are key issues for the production line set up in China. In addition, stable & robust routine operation, and immediate technical services should be strictly guaranteed. DaimlerChrysler SIM Technology Co. Ltd. should be closely involved in these tasks and services for reasons of localization and in-house knowledge to bridge the possible problems that may be encountered. Our possible entry points are set out below: Multilanguage support Although multi-language capability is offered by NISP through the deployment of text files for output texts with referencing, there is no Chinese version available up till now. The development of Chinese add-ons (output texts, specific graphical user interface, technical documentation) is necessary for the local production both for the line diagnoses and the repair services in the workshop. Setup, modification and adaptation There are some possible modification expected due to the plant relocation (to be found out during the road test). These modifications will affect the diagnosis system as well, so, the task of adaptation and configuration of hardware/software will have to be handled. Training Even though the sequence of operations is predefined, line staff is responsible for supervising testing. And, in some cases, testing is interactive: the test program requests testing personnel to perform specific action. Therefore testing personnel have to undergo a thorough training to be able to perform: o routine operations using the IS Tester, o documentation, o adaptation or alteration of test sequences.
8 / 8 Maintenance and technical services Engineers from DaimlerChrysler SIM Tech. could provide after-setup technical services and monitoring to guarantee a continuous availability of the overall diagnosis system. Tasks include: o adaptation or redefinition of test sequences on necessity, o monitoring and supervising the diagnosis, o maintaining and supervising the IS Tester server, o reporting and communicating with DaimlerChrysler engineers for trouble-shooting. 4 Preparation for a possible start In order to prepare for a possible start, we would need the followings: Documentation: o A thorough description of the following protocols: MB-Iso, Keyword FB, Keyword 2000, RMTD+, CAN protocol Communication protocol between the testing stations and the server o Technical documentation of the latest NISP system (PAH, PAG, PAS, Test Server) o Vehicle and ECU description data structures Hardware: o CAESAR module(s), Coupling cards o Sample ECU Software: o The graphical tool for test application generation (PAG) o The NISP Test program setup system + compiler (PAC) o The NISP Runtime system (complete core including the RT kernel) o The ECOS Setup system + ECOS Test step editor + ECOS Runtime system o IS Tester Server software, the administration tool and the analysis/statistics/visualization tool Data: o o o Sample test programs in text format (PAS), as well as created by the graphical tool (PAG) Sample vehicle and ECU data (CAESAR/DIOGENES) Sample queries (IS Tester Server) Guidelines 5 Sources of information The DaimlerChrysler intranet (Diagnosis site): http://intra-diag.sifi.daimlerchrysler.com/nisp/doku/english/index.htm