Integrated Data Models for Vehicle Diagnostics Development

Introduction

Not all, but in a number of instances, working groups within OEM organizations contributing to ECU/ Sub-System/ System diagnostic design, documentation, development, and verification across the diagnostic development life cycle seem to be working in silos. Furthermore, the diagnostic content is not being defined and developed in a unified and standardized format. In most cases, the data is defined in vendor-specified tooling formats. However, OEMs are increasingly realizing the need for data standardization and aligning their development strategies with industry-defined standards like ODX, DEXT, etc.

An account of the various diagnostic data development stages and how the data is typically being defined is provided below:

During the requirement definition and design phase, Diagnostic requirements are defined in Application Lifecycle Management (ALM) tools in a natural language format. However, this information cannot be consumed in an automated manner during the subsequent development stages. The diagnostic design is most of the time summarized in flow diagrams or using vendor proprietary solutions, which are then made available in a semi-automated or manual mode for consumption by downstream tooling.

During the development phase, the Diagnostic data for ECU specifications are defined either in an XLS format or in a vendor-specific proprietary format, whereas some OEMs are leveraging standard formats, i.e., Open Diagnostic eXchange (ODX). Likewise, AUTOSAR diagnostic configuration definition is defined using vendor-specific configuration authoring tools and formats, whereas some OEMs opt for an industry-standard, i.e., AUTOSAR Diagnostic Extracts (DEXT). Even in that case, it results in duplication, as most of the time, different vendor tools are utilized during the development of this content.

During the verification and validation phase, diagnostic & test data, specifications, and scripts are authored using vendor-specific tools and data formats within specific execution environments. If there are multiple execution environments, i.e., Test bench, Virtual HIL, and physical HIL, the data is duplicated multiple times.

At the end of the vehicle diagnostic development stage, the End of Line (EoL) and after-sales departments manually consume the same duplicated information to develop and update respective diagnostic solutions.

As outlined in the above-defined development process, there is a clear need to implement an intelligent diagnostic content development framework, which also leverages standards-driven approaches for vehicle diagnostics development. While various industry standards have been defined to support the standardization of diagnostic development and the structuring of relevant information, however, the respective standardization working groups have only been able to overcome department specific issues and requirements instead of a holistic, inter-departmental solution, which essentially results in a fair amount of diagnostic information overlap, driven by choice of standard leveraged by each department within an OEM organization. For instance, there is a significant overlap of information when diagnostic details for after-sales use-cases are captured in ODX, and details for diagnostic manager development-related use-cases are captured in the DEXT format. Additionally, the suggested standards might not support requirements related to future standards like Service-oriented vehicle diagnostics (SOVD).

In an attempt to break away from the prevalent trends of disintegrated, disparate, and largely manual approaches to vehicle diagnostics development, through this concept paper, we would like to outline a cloud-based, integrated, and automated solution for diagnostic information development, management, and verification. This solution can be integrated with the OEM’s upstream systems like ALM, provide tooling for content development by Engineering, EoL, and after-sales engineers, and likewise with their downstream systems for Aftersales, Update manager, and remote diagnostics related use-cases and services. This integrated solution runs on a unified diagnostic development process workflow, which notifies and tags respective stakeholders contributing to the development workflow according to their responsibilities.

An integrated approach to diagnostics development | How does it Work?

As outlined in the above section, to tackle the challenges faced with utilizing multiple, non-unified standards, an Integrated diagnostic development framework with centralized data management is being proposed. The suggested diagnostic framework comprises five major components:

• Import module- for upstream integration
• Data Authoring tools to view and edit diagnostic details
• Centralized knowledge database- For storage and automated engineering verification
• Exporter module- For downstream application integration
• Dashboards- To depict live maturity/ completion status, risk assessment, traceability, etc.

The centralized diagnostic verification solution integrates with upstream applications like ALM tools to enable linkage with diagnostic requirements/design defined in a requirement definition system. This integration also enables automated pre-population of details extracted from relevant requirements. Additionally, if the diagnostic information is defined as part of ECU diagnostic specification in specific design tools or XLS/ proprietary formats, the framework will still be able to import the relevant details from the specifications or the design extracts.

The framework also enables various user groups to jointly define and contribute to the development of diagnostic content along with the underlying requirements:

• Linkage with functional requirements
• Diagnostic data and sequences
• Engineering documentation
• Diagnostic development content
• Diagnostic verification requirements
• Details required to develop EoL & Aftersales diagnostic sequences & repair actions
• Registry of flash files and interdependencies for software/system upgrade
• Integration with the release management system

The data model must be defined considering the re-usability of diagnostic objects and relevant attributes across various ECUs/Vehicles. This reduces and avoids duplicating the same data content across various ECUs/vehicle programs. Moreover, it allows for various data from different domains to be connected, providing instant insights across engineering and after-sales areas, including other areas of interest for OEMs.

The integrated framework also allows diagnostics engineers to create extracts of various formats:

• Development (DEXT, ODX)
• Verification (HEX files, ODX, OTX, and HIL/ Test bench project linkage)
• EoL (HEX, ODX, OTX, dependency tree)
• Aftersales and remote diagnostics (HEX, ODX, OTX, dependency tree, translation, logging policies, etc.)
• Custom exports needed by downstream applications, e.g., Excel, properties, etc

Customized central dashboards allow leaders to monitor the progress of diagnostic development and risks while providing requirements coverage by leveraging a centralized data storage construct with linkages to corresponding requirements.

Summary

In the introduction section, we shared how various groups are working in silos to develop use-case/department-specific diagnostic content, resulting in duplicated information authoring, enhanced time in issue resolution, quality, and timeline issues.

This article proposed a cloud-backed, diagnostic content development and management framework that integrates with OEM’s user directory, ALM, business tools, release management, and aftersales solution to tackle this challenge.

The proposed framework also provides a provision to migrate existing legacy information to a custom-defined or an industry-standard format. The solution exposes REST APIs, allowing authorized external applications to retrieve specific details, and at the same time, supports the utilization of various industry standards, internal dependencies, and consumption by downstream tooling with the help of export modules.

In essence, the proposed framework is fully capable of meeting new and existing requirements from various departments contributing to vehicle diagnostic content development in a holistic, unified, and a transparent manner while ensuring significantly improved development & authoring productivity, consistently high content quality, maximized requirements coverage and traceability, and more so, almost negligible data duplicity.

Authors