Member: Softing Automotive Electronics GmbH, Mercedes-Benz Group AG
Featured Standard: ASAM MCD-2 D, ASAM MCD-3 D
Since 1997 Daimler has been implementing a diagnostic system which, using a proprietary, data-driven communication platform, exchanges data between the diagnostic application and the vehicle. This platform incl. the data is used consistently at Daimler in Engineering/Development, Manufacturing and After Sales. When the S-Class 222 was launched in 2013, Daimler opted for a COTS product (commercial off-the-shelf) from Softing. Since then, the Softing product has been used for data communication between the diagnostic application and the vehicle for all new Mercedes cars and VAN series in Engineering/Development, Manufacturing and After Sales. Thanks to a clever migration strategy that was implemented from the very beginning, the project was not just successful in technological terms, but also ensured a fast return on investment.
After years of contributing to standards it was time to implement and use them – and it paid off very fast even if you take the previous efforts into account.
Marc Blatter, Project Manager, Daimler AG
Daimler had already successfully introduced a diagnostic communication platform in 1997, operating it in all processes throughout Engineering/Development, Manufacturing and After Sales. This system was (further) developed especially for use at Daimler. In essence this system was a Database for storing ECU diagnostic information and sequence systems with an API. The ECU diagnostic information from the Database was converted into a runtime system and processed by the sequence system making it legible for operators.
The advantage of this procedure is obvious:
Finally, the data process has the distinct advantage that the data for Manufacturing and After Sales Service is of uniform quality due to the fact that it is created in parallel to Engineering/Development.
As it is extremely time-consuming to maintain a proprietary tool environment, Daimler decided to use an off-the-shelf tool for the areas of use named. Standardization had already created the prerequisites for this as the Database was standardized with ODX (ASAM MCD-2D), and with ASAM MCD-3D the company had a programming interface for a Standard-based diagnostic system at its disposal. Furthermore ODX 2.2. had a maturity and function scope that allowed it to be used as a replacement for the existing solution.
A new communication platform can generally only be introduced with a new vehicle project because otherwise all diagnostic descriptions, test sequences and tools would have to be modified during operation. For the new vehicle project, however, this means not only the challenge of implementing a new development, but also of migrating to the new communication platform. This necessitates a fallback which would enable Diagnostics if the implementation of the new communication platform should falter. In this case, this was relatively simple because the authoring system for the ECU diagnostic data enables both an export to the old format and to ODX. All that needed to be done was generate both databases for a while. The data for the new vehicle was modified and then exported from the authoring system to the new format for the migration of acquisition control units.
On the tool side, three tools in particular had to be adapted to suit the new runtime environment from the very beginning: the engineering tester that had just been launched and was already based on the new format (DTS Monaco from Softing), the manufacturing system NISP (used all over the world in all car manufacturing sites), and the After Sales service tester XENTRY Diagnostics. NISP is an Daimler-specific development whereas XENTRY Diagnostics is based on a framework that has already been implemented on the basis of a previous version of the ASAM MCD-3D Standard. All components are very critical in terms of performance, instabilities and bugs due to their implementation worldwide.
A multiple-phase procedure was agreed from the outset to be able to ensure project completion:
In the run-up to the implementation of a new VCI (Vehicle Communication Interface, eCOM) the driver layer was converted to the D-PDU API Standard. This meant that the old system and a D-Server could work on the same hardware.
Then, a Proof of Concept (PoC) project was started in collaboration with several suppliers. The aim was to prove that the scope defined in the standards did actually satisfy requirements and could be implemented in the entire environment.
The system was implemented after a successful PoC within the engineering tester DTS Monaco, which, just like the MVCI-Server, is a Softing product. As this tester processes the data both in the old format and as ODX data, the quality of the data and ODX processing were very easy to achieve in a comparison of old data and ODX data. This meant that there was only minimal limitation of the test tasks with the ECUs. At the same time, the Manufacturing and After Sales testers as well as the authoring systems were adapted, and users trained.
To minimize migration, Daimler decided to run the old and new world in parallel to one another and phase out the old communication platform in Engineering/Development and Manufacturing. Support in After Sales does, however, have to be guaranteed for many years to come. The advantage is that existing data and test sequences no longer have to be changed which saves on time-consuming releases.
It was exciting to see that after years of standardizing, after years of developing a tool, the real life utilization of a Standard implementation worked smoothly – even more smoothly than expected!
Markus Steffelbauer, Director Product Management, Softing Automotive Electronics GmbH
During the project, it became clear that the procedure selected was exactly the right one. All in all, the implementation was on schedule and delivered the right quality. To ensure total adherence some extra functions had to be added to the Softing MVCI-Server. This was necessary because the tools featured some operating sequences which could not be reproduced with the Standard. The development methodology selected enabled simple extension implementation.