Increasingly short model cycles with more and more complex systems require innovative solutions both in the creation of diagnostic systems and for efficient and targeted diagnostics in the workshop.
Could the Cloud be a possible solution? If so, what modifications are needed?
The Cloud offers many advantages with regard to a scalable system, a current diagnostic application without a complex update process as well as a reduction in the amount of hardware required in the field. The platform described in this article combines an offline and a Cloud-based diagnostic solution without any need for additional modification to the code of the application or the data. Specific requirements from the sectors of Development, After Sales and the final Customer can be covered with the help of different licences.
Single source as a basis
In order to be able to offer client improved support, the company Vaillant has decided to expand the service by adding a Cloud-based component for the After Sales. This solution picks up the previously developed components of the existing diagnostic solution from the development sector and adds a telematics platform to this. The new platform is also designed to cover and unite use cases from the development sector (extended support), technical customer services (remote maintenance) and the final customer (control of heating functions).
This basis is formed by standards from the automotive industry, which allows a single source concept for the data. Use across all sectors allows Vaillant to cover the entire supply chain.
A concept and its challenges
The diagnostic concept includes a telematics platform, a central server and a web-based user interface in order to display the entire product life cycle.
The existing system was replaced through a solution with standardised components from the automotive industry. The scope of function was extended and the maintainability and expandability of the new system was increased. The new solution needed to be data-driven, as it is standard in the automotive industry. It was therefore possible to add new Vaillant heaters and platforms by installing a data packet.
The pillars of future-oriented architecture
The first pillar is the use of standardised components
- D-PDU API with connection of the Vaillant specific protocols
- MVCI MCD-3D server
-ODX data
The ODX database, which is created and released in the development department, enables consistent, data-driven functionality across all areas of use and use cases of the diagnostic solution within the Vaillant Group.
The second pillar is represented by the OTX processes. The process includes a full and cross-sector use.
This requires a corresponding architecture and a mutual understanding of the authoring guidelines during content creation.
Data are stored in a version control system so that different departments and/or development centres in different locations can work together. Meta-information on the individual OTX procedures document the progress, and enables a unified workflow and release process.
Combining diagnostics and connectivity
The solution covers 3 main components in order to provide the concepts described above as well as their use cases
- Telematic platform with connection to the heating bus
- Business server for administration of the client platforms
- Client web interfaces for the different users and areas of use
The telematic platform is based on an embedded Linux system, which was developed in-house by Vaillant. The connection to the Vaillant IT systems is taking place by GSM interface or via DSL / LAN of the final customer.
The security of the interface and the client data is an important aspect. Therefore this Smart Home solution was approved and certified by the VDE Testing and Certification Institute.
The telematics platform offers a use case-based interface to the business server as shown in the graphic. The telematics protocol MQTT is used as a communications medium. The interface is served from the business server using RPCs (remote procedure calls). ProtoBuf is used to optimise communication in the GSM case.
A generator was implemented to create the communication structures and their methods (Java interfaces) which generates the ProtoBuf messages. ProtoBuf serves to (de)serialise the objects in a compressed byte stream.
The box client on the telematics platform is a Java application. In addition to execution of the use cases shown in the graphic this also allows the definition of cyclical tasks. The results are then made available to the business server.
These tasks include
- Fault memory: any new entries are communicated automatically to the business server. Then, the responsible service engineer will get informed
- Topology scan: monitoring of the control device at the bus and its condition
- OTX jobs: expert interface for the execution of any OTX processes. They can be loaded into the box at any time
Experience from the field
After integration of the relevant components the application was able to begin productive operation approximately 2 ½ years ago. The system was first validated with field test devices. Following release the telematics platforms were delivered to the final customers in several phases and then put into operation by the service engineers. It was thus possible to successfully replace the old system.
During operation it was recognised that the performance of the telematics platform was not able to satisfy the requirements. The selected CPU was identified as a limiting factor with the help of performance analyses. The execution of Java code proved to be the primary problem.
This experience was used to commission telematics platform 2.0. This is currently in the release process and will be delivered to clients before the end of this year.
The new controller with an improved floating point calculation and support for the selected Java VM provided the greatest performance gain. The problem was finding the appropriate combination of processor, Linux operating system and the right Java VM. Neither the CPU setting nor the size of the memory were the limiting factors in the old hardware.
Another learning effect was that OTX needs to be treated as the 'correct' programming language in order to be able to use the advantages of the procedural, graphic programming. Thus the focus is on the definition of the authoring guidelines, the use of Design-Pattern and the informative specification of the required functionality before processes are created.
In a further development step the scope of function of the service solution has now also been extended. One of the new functions is guided troubleshooting. This allows the service engineer to already test functionality during remote diagnosis and to make conclusions from the error pattern or possible symptoms. The service engineer can thus already make decisions before travelling to the customer and may be able to take the correct replacement parts along.
Outlook: future Cloud diagnostic systems
The system described here demonstrates the advantages of a data-driven diagnostic solution. The distribution of the required data is taking place automatically via update. Thus both final customers and service engineers can profit from the latest functionality of the Vaillant products and the After Sales diagnostic system.
By using proven standards from the automotive industry this platform can be adapted to different areas of application in various industries.
Modifications must be done on following components
- Protocol implementation within the D-PDU API interface
- Mapping of the ECU diagnostic functions within the ODX data
- Adaptation of the specific properties of the ECU in the OTX-based diagnostic processes
The solution also offers ideal prerequisites for the 'right to repair' legislation in the automotive industry. This system can make an important contribution thanks to the different user roles and views. The partial components can be moved between the server and the workshop depending on requirements. Great importance is placed on the security of the data and the processes.
The use of the KPIT authoring systems for the ODX data and the OTX diagnostic processes and the integration into the KPIT framework for execution in the Cloud has created a scalable system that fulfils any client requirements within the diagnostic sector.
Original published in HANSERautomotive: issue 5-6 2015
Could the Cloud be a possible solution? If so, what modifications are needed?
The Cloud offers many advantages with regard to a scalable system, a current diagnostic application without a complex update process as well as a reduction in the amount of hardware required in the field. The platform described in this article combines an offline and a Cloud-based diagnostic solution without any need for additional modification to the code of the application or the data. Specific requirements from the sectors of Development, After Sales and the final Customer can be covered with the help of different licences.
Single source as a basis
In order to be able to offer client improved support, the company Vaillant has decided to expand the service by adding a Cloud-based component for the After Sales. This solution picks up the previously developed components of the existing diagnostic solution from the development sector and adds a telematics platform to this. The new platform is also designed to cover and unite use cases from the development sector (extended support), technical customer services (remote maintenance) and the final customer (control of heating functions).
This basis is formed by standards from the automotive industry, which allows a single source concept for the data. Use across all sectors allows Vaillant to cover the entire supply chain.
A concept and its challenges
The diagnostic concept includes a telematics platform, a central server and a web-based user interface in order to display the entire product life cycle.
The existing system was replaced through a solution with standardised components from the automotive industry. The scope of function was extended and the maintainability and expandability of the new system was increased. The new solution needed to be data-driven, as it is standard in the automotive industry. It was therefore possible to add new Vaillant heaters and platforms by installing a data packet.
The pillars of future-oriented architecture
The first pillar is the use of standardised components
- D-PDU API with connection of the Vaillant specific protocols
- MVCI MCD-3D server
-ODX data
The ODX database, which is created and released in the development department, enables consistent, data-driven functionality across all areas of use and use cases of the diagnostic solution within the Vaillant Group.
The second pillar is represented by the OTX processes. The process includes a full and cross-sector use.
This requires a corresponding architecture and a mutual understanding of the authoring guidelines during content creation.
Data are stored in a version control system so that different departments and/or development centres in different locations can work together. Meta-information on the individual OTX procedures document the progress, and enables a unified workflow and release process.
Combining diagnostics and connectivity
The solution covers 3 main components in order to provide the concepts described above as well as their use cases
- Telematic platform with connection to the heating bus
- Business server for administration of the client platforms
- Client web interfaces for the different users and areas of use
The telematic platform is based on an embedded Linux system, which was developed in-house by Vaillant. The connection to the Vaillant IT systems is taking place by GSM interface or via DSL / LAN of the final customer.
The security of the interface and the client data is an important aspect. Therefore this Smart Home solution was approved and certified by the VDE Testing and Certification Institute.
The telematics platform offers a use case-based interface to the business server as shown in the graphic. The telematics protocol MQTT is used as a communications medium. The interface is served from the business server using RPCs (remote procedure calls). ProtoBuf is used to optimise communication in the GSM case.
A generator was implemented to create the communication structures and their methods (Java interfaces) which generates the ProtoBuf messages. ProtoBuf serves to (de)serialise the objects in a compressed byte stream.
The box client on the telematics platform is a Java application. In addition to execution of the use cases shown in the graphic this also allows the definition of cyclical tasks. The results are then made available to the business server.
These tasks include
- Fault memory: any new entries are communicated automatically to the business server. Then, the responsible service engineer will get informed
- Topology scan: monitoring of the control device at the bus and its condition
- OTX jobs: expert interface for the execution of any OTX processes. They can be loaded into the box at any time
Experience from the field
After integration of the relevant components the application was able to begin productive operation approximately 2 ½ years ago. The system was first validated with field test devices. Following release the telematics platforms were delivered to the final customers in several phases and then put into operation by the service engineers. It was thus possible to successfully replace the old system.
During operation it was recognised that the performance of the telematics platform was not able to satisfy the requirements. The selected CPU was identified as a limiting factor with the help of performance analyses. The execution of Java code proved to be the primary problem.
This experience was used to commission telematics platform 2.0. This is currently in the release process and will be delivered to clients before the end of this year.
The new controller with an improved floating point calculation and support for the selected Java VM provided the greatest performance gain. The problem was finding the appropriate combination of processor, Linux operating system and the right Java VM. Neither the CPU setting nor the size of the memory were the limiting factors in the old hardware.
Another learning effect was that OTX needs to be treated as the 'correct' programming language in order to be able to use the advantages of the procedural, graphic programming. Thus the focus is on the definition of the authoring guidelines, the use of Design-Pattern and the informative specification of the required functionality before processes are created.
In a further development step the scope of function of the service solution has now also been extended. One of the new functions is guided troubleshooting. This allows the service engineer to already test functionality during remote diagnosis and to make conclusions from the error pattern or possible symptoms. The service engineer can thus already make decisions before travelling to the customer and may be able to take the correct replacement parts along.
Outlook: future Cloud diagnostic systems
The system described here demonstrates the advantages of a data-driven diagnostic solution. The distribution of the required data is taking place automatically via update. Thus both final customers and service engineers can profit from the latest functionality of the Vaillant products and the After Sales diagnostic system.
By using proven standards from the automotive industry this platform can be adapted to different areas of application in various industries.
Modifications must be done on following components
- Protocol implementation within the D-PDU API interface
- Mapping of the ECU diagnostic functions within the ODX data
- Adaptation of the specific properties of the ECU in the OTX-based diagnostic processes
The solution also offers ideal prerequisites for the 'right to repair' legislation in the automotive industry. This system can make an important contribution thanks to the different user roles and views. The partial components can be moved between the server and the workshop depending on requirements. Great importance is placed on the security of the data and the processes.
The use of the KPIT authoring systems for the ODX data and the OTX diagnostic processes and the integration into the KPIT framework for execution in the Cloud has created a scalable system that fulfils any client requirements within the diagnostic sector.
Original published in HANSERautomotive: issue 5-6 2015
