FXD A new exchange format for fault symptom descriptions

Transcription

1 FXD A new exchange format for fault symptom descriptions Helmut Wellnhofer, Matthias Stampfer, Michael Hedenus, Michael Käsbauer Abstract A new format called FXD (=Fault symptom exchange Description) was developed for provision of machine-readable descriptions of fault symptom algorithms which are implemented as diagnostic software in an Engine Control Unit (ECU). The main business case is the data exchange from a function & software supplier to a car manufacturer in a standardized format (XML schema) in order to enable a tool based processing. This new format was initiated by cooperation between several German OEMs and suppliers. The supplier will feed software related raw data into a FXD editor, which can be extended and refined by the OEM for different use cases. Based on the FXD content and associated calibration values, several end user documents can be generatedsuch as the summary sheet for OBD monitors. The expected main benefits of the FXD approach are an overall improved efficiency as well as an independency of supplier- and OEM-specific format handling. Kurzfassung Ein neues Format FXD (=Fault symptom exchange Description) wurde entwickelt, um maschinenlesbare Beschreibungen für Diagnosealgorithmen zu ermöglichen, welche in einem elektronischen Motorsteuergerät implementiert sind. Den Hauptanwendungsfall stellt der Datenaustausch zwischen dem Funktions- und Softwarelieferanten und dem Automobilhersteller in Form eines standardisierten XML-Formates dar. Das neue Format wurde in einer Kooperation zwischen mehreren deutschen Automobilherstellern und Zulieferern definiert. Der Zulieferer pflegt im FXD-Editor softwarenahe Rohinformationen ein, welche vom Automobilhersteller je nach Anwendungsfall erweitert und angepasst werden können. Basierend auf dem FXD-Inhalt und dazugehörigen Kalibrationswerten können diverse Anwendungsdokumente wie z.b. OBD summary sheets erstellt werden. Die erwarteten Hauptvorteile des FXD-Ansatzes bestehen sowohl in einer insgesamt verbesserten Effizienz als auch einer Unabhängigkeit von firmenspezifischen Formaten.

2 1. Motivation The complexity of OBD monitoring systems is continuously evolving. Technological progress as well as regulatory updates drive the complexity of both engine systems themselves and the related OBD monitoring systems. For instance, the number of monitors and thereby also Diagnostic Trouble Codes (DTC) has considerably increased over time as shown here for a 6-cylinder gasoline application from 2000 up to today. In addition to the pure number of monitors, also the OBD monitors themselves have become more and more sophisitacted. Figure 1: Evolving complexity of OBD systems Last but not least today s project complexity (e.g. variants) at the OEMs is also an important aspect for diagnostic documentation. For all OBD relevant monitor strategies a corresponding OBD documentation must be generated. When these monitors are integrated by often different project teams, they may need to be specifically adapted and calibrated in order to operate properly in the different projects. To assure accurate OBD documentation across all projects, considerable efforts for synchronization and manual adjustment are necessary. Obviously, this specific approach will provide only a limited reuse potential. Figure 2: Project complexity and accurate OBD documentation

3 In addition more complicated business models (multiple job shares across companies) challenge the OBD documentation process. In the past, typically one ECU supplier also supplied most of the corresponding software. Nowadays and even more in future with the Autosar approach, the trend towards software packages from OEM and 3 rd parties will increase. As a consequence, multiple suppliers provide the information for the generation of OBD documentation with different format-, structure- and content. For understanding it is often necessary to dig into the details of the complete Software documentation itself. Owing to this, the efforts for the integration and generation of OBD relevant information increases due to manual analysis and adjestment. Obviously this scenario will allow only a limited reuse. Figure 3: Challenging job share and consistent OBD documentation Scheduling constraints for generating OBD documentation along the development phase also represent a motivating factor for the introduction of the FXD approach. As the OBD development has become more and more extensive, the documentation must be established as early as possible, but on the other hand late changes will cause iterations. Without efficient management of the corresponding OBD relevant information, it is nearly impossible to answer to the challenging engineering targets and tight project schedules of today. 2. FXD concept Driven by the obove mentioned factors the German OEMs Audi, BMW, Daimler, Porsche and VW specified the requirements for provision of OBD relevant information and contracted Bosch and Continental to develop a corresponding concept and format. The main objectives were: Develop a machine readable automotive format ready for ISO standardization The FXD data shall be the single source of diagnostic information for different documentation use cases (e.g. type approval, service manual) across project variants Data processing shall be possible by state-of-the-art tooling

4 In answer to this the following main design decisions were taken: Use XML as base technology for the format definition (XML schema) Reuse structural patterns from ASAM (Association for Standardization of Automation and Measuring Systems), especially from ODX (ISO 22901) The naming of structure elements shall be close to the end user needs 2.1 Worfklow as of today As of today the FXD relevant information is exchanged between OEM s and ECU- Software suppliers based on proprietary templates and formats (e.g. EXCEL). Even the main FXD use cases type approval and service manual are driven by different stakeholders and lead partly to unequal exchange formats and processes for one and the same OEM. At the Software suppliers the situation is even worse as they have to process the full variety of templates and formats with limited reuse and a lot of manual interaction. Finally the integration and document generation at the OEMs can hardly be automated due to missing stable and standardized data formats. Figure 4: Constraints of the today s workflow 2.2 Future planned worfklow By introducing a machine readable and standardized exchange format it is possible to overcome those constraints and drawbacks of the today s workflow. At the ECU-Software suppliers the variety of formats and templates will be replaced by a standard. This will enable a homogeneous tool chain and a reuse of FXD data. The ECU-Software supplier will deliver raw data, i.e. data, which are close to the Software implementation and can be refined depending on the use case. For the OEM s the following tasks can be efficiently supported by tools in order to reduce the manual interaction: Integration of FXD data from different ECU-Software suppliers Refinement of FXD data for different use cases (type approval, service manual) Enhancement of FXD data with calibration values Creation of end user documents

5 Figure 5: Future planned workflow 3. FXD format and example The main challanges for the XML schema will be presented based on the documentation needs of the OBD summary sheet. In order to enable an automatic publishing process from the FXD format to an OBD summary sheet, all relevant information needs to be captured by the FXD format. As the main structure criterion for the OBD summary sheet is the fault symptom, there is a corresponding node inside the FXD schema called FAULT-SYMPTOM, where all related information is organized below. Within the OBD summary sheet the most complex information deals with nested algorithmic expressions for malfunction criteria and enable conditions. No control structures as known from programming languages are necessary. Sample expression: <parameter_1(operand)> < greater than (operator)> < threshold_1(operand)> <and/or..(operator)> <parameter_2(operand)> < less than (operator)> < threshold_2(operand)> The operands and operators have to be marked sperately within the XML structure, as both have to be prepared for specific rendering, e.g. publishing to different table columns. As the FXD data delivered by the software supplier will contain raw data close to the software implementation, a refinement concept is necessary to support different use cases. Therefore the principle of inheritance is introduced to FXD, i.e. the symptom related raw data can be refined for a specific use case just by adding refined information characterisitics to the FXD data. Later on the tool chain will process the use case specific characteristics.