Automotive

Functional API

Running Typical Diagnostic Functions in Your Own Applications Easily – Even in Remote Scenarios.

The functional API in the sense of a service-oriented architecture makes it possible to have typical diagnostic functions run completely by Softing SDE as closed sequences. This means it can be used in remote applications, regardless of the quality of the connection. The descriptive names make it possible to integrate diagnostics into your own applications without great effort to study. 

Users

  • Developers of diagnostic and flash programming tools
  • Creators of test sequences in engineering, the test environment and manufacturing
  • Those responsible for diagnostic and flash programming solutions in the vehicle 
  • Developers of cloud and remote solutions including SOTA (Software over the Air)

Functions

  • Vehicle Quick Test incl. status report
  • ECU variant identification
  • Reading out and clearing the error memory (DTC)
  • Exchanging and (re-)programming of ECUs
  • ECU coding
  • Reading out and storing measurement values using diagnostic services
  • Setting and evaluating actuators
  • Automating flash processes and function tests (with and without UI)

Overview

Short Engineering Times Thanks to Functional API Access

With the help of the reduced and thus very easy to use Smart Diagnostic API (SDA), diagnostic functions can be integrated extremely efficiently into any test system. The SDA intelligently encapsulates several diagnostic service calls or entire sequences into proprietary functions and thus considerably reduces the complexity of the actual test. It is no longer necessary to have full, in-depth knowledge of the diagnostic implementation, something that avoids long familiarization times. At the same time, error-proneness is also considerably reduced as the diagnostic functions are always defined identically. In addition, the maintenance of the test is much less expensive as the test does not have to be changed for new ECUs or variants.

Remote-Capability through Service-Oriented Approach

When using SDA, diagnostic functions are completely encapsulated in the Softing SDE and run independently of the application. This is the prerequisite for remote or cloud operation because only this ensures independence from the network connection – in terms of latencies with lots of individual function calls, but in particular in terms of network availability which can scarcely be guaranteed with long-running functions. The diagnostic functions can be implemented in various ways whether as an ODX service, an OTX sequence, in Java or as C++ code directly in the SDE. This is also possible depending on the control unit or variant ensuring the greatest possible flexibility at all times. 

Automated Diagnostic Sequences and Tests with OTX (ISO 13209)

OTX compliant with ISO 13209 is a fixed component of the Softing Diagnostic Base System and the Smart Diagnostic Engine. Even complex OTX sequences can be run very efficiently with the Softing SDE as runtime environment. The SDE is suitable both for complex diagnostics and for generic test cases in test systems. Additionally, Softing-specific extensions simplify the handling of methods and the use of diagnostic sequences.
When using automated test environments (e.g. Hardware in the Loop – HiL), full access to the API is not always necessary. The SDE can be accessed efficiently and precisely via the command line for this purpose.
 

Do you have questions about our solutions or need support? 

Please contact us – we are pleased about your interest!

Possible Applications

The functional API of the Softing SDE (Smart Diagnostic API – SDA) implements diagnostic functions in the sense of a service-oriented architecture. This means that complete diagnostic sequences are run within the SDE and their results are then returned to the requesting application. Once functions have been implemented, they can be run by any applications. Alongside the functional API, the SDA also provides an interface for running diagnostic sequences in OTX format.

Sample diagnostic function

A „ReadErrorMemory_Vehicle“ function, for example, consists of several steps: 

  1. Determining the number of errors per ECU 
  2. Reading out the errors per ECU 
  3. Reading out the environmental conditions per error
  4. Repeating 1-3 per ECU

With the MCD-3-API, numerous methods are necessary for each individual step, the implementation is correspondingly complex, especially if it has to take place in several applications.

Implementation

The exact configuration of the function is usually manufacturer-specific, in some cases even ECU- or variant-specific. This is why there are several possibilities of implementation. The largest implementation variance is in an implementation in C++ or JAVA which has to be taken care of by Softing. In this case, the sequence is integrated in the SDE. Besides, an implementation in OTX or as an ODX service is also possible. Here, users can intervene themselves. 
Application Guide Lines (AGL) are used to specify how the diagnostic function is implemented. This definition can take place globally, but can also be overwritten for one vehicle, one ECU or one ECU variant.

Remote

The implementation of diagnostic functions in the Softing SDE is not only advantageous in terms of efficiency. In a remote case scenario, the Softing SDE can be kept close to the vehicle – in a TCU, a data logger, a VCI – thereby almost completely eliminating the dependence on the quality of the connection: The application submits a request, which is then processed completely independently by the Softing SDE, results are collected by the application when the connection is of a sufficiently high quality.

Technical Articles

«