Published By
Various working groups have contributed to defining standard schemata to author/exchange relevant parts of diagnostic information (e.g., ODX, AUTOSAR DEXT, OTX, HMS). While these standards have been developed to enable efficient information exchange and utilization for the respective use-cases & groups, however scenarios including siloed diagnostic content development efforts between groups still do exist. Such development environments have led to the creation of duplicate and redundant information in addition to resulting in increased development, maintenance, and validation efforts. Furthermore, it has been observed that organizations lose traceability and linkage between varied and pertinent data sets due to isolated content authoring scenarios.
This article aims at presenting an integrated data model for developing, storing, and disseminating vehicle diagnostics information. The proposal also outlines various data import, linkage, authoring, convert, and export interfaces, utilizing existing legacy and proprietary information from upstream applications and delivering standardized data sets to various downstream applications across the OEM’s enterprise eco-system.
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.
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:
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:
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:
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.
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.
Solution Architect, Vehicle Diagnostics, KPIT
Solution Architect, Vehicle Diagnostics, KPIT
Group Leader, Engineering Platform, Vehicle Diagnostics, KPIT
Sr. Manager, Product Marketing, Vehicle Diagnostics, KPIT
6 likes
6 likes
Connect with us
KPIT Technologies is a global partner to the automotive and Mobility ecosystem for making software-defined vehicles a reality. It is a leading independent software development and integration partner helping mobility leapfrog towards a clean, smart, and safe future. With 13000+ automobelievers across the globe specializing in embedded software, AI, and digital solutions, KPIT accelerates its clients’ implementation of next-generation technologies for the future mobility roadmap. With engineering centers in Europe, the USA, Japan, China, Thailand, and India, KPIT works with leaders in automotive and Mobility and is present where the ecosystem is transforming.
Plot Number-17,
Rajiv Gandhi Infotech Park,
MIDC-SEZ, Phase-III,
Hinjawadi, Pune – 411057
Phone: +91 20 6770 6000
Frankfurter Ring 105b,80807
Munich, GERMANY
Phone: +49 89 3229 9660
Fax: +49 89 3229 9669 99
KPIT and KPIT logo are registered trademarks | © Copyright KPIT for 2018-2024
CIN: L74999PN2018PLC174192
Cookie | Duration | Description |
---|---|---|
cookielawinfo-checbox-analytics | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics". |
cookielawinfo-checbox-functional | 11 months | The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional". |
cookielawinfo-checbox-others | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other. |
cookielawinfo-checkbox-necessary | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary". |
cookielawinfo-checkbox-performance | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance". |
viewed_cookie_policy | 11 months | The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data. |
Leave a Reply