SIMUL ATION AND TESTING

New Diagnostic Standard

for the Vehicle of Tomorrow
DE VELO PMENT Simul ation and Testing

© Softing Automotive

SOVD – The Diagnostic Standard of Tomorrow

AUTHOR The transformation of electronic vehicle architecture toward cen­

tralized high-performance computers also necessitates changes
in diagnostic procedures. The Association for Standardization of
Automation and Measuring Systems (ASAM) is currently preparing
a standardization of the new diagnostic structure entitled Service
Markus Steffelbauer Oriented Vehicle Diagnostics (SOVD). As Softing shows, today’s
is Head of Product Management
and Marketing at Softing Automotive diagnostic tools such as the so-called Smart Dia­gnostic Engine
Electronics GmbH in Haar near
Munich (Germany).
already offer the potential to meet future requirements.

g It is no secret that two mega- ple is the brake, which in an electric The continuous monitoring of funct-
trends are driving the entire automo- vehicle consists of the mechanical ions and subfunctions of the vehicle,
tive industry: electric driving and brake, recuperation via the electric as well as the interaction of differ-
autonomous driving. Both require com- motor and battery management. The ent components in which these func-
pletely new functionalities in the vehi- overall status of the braking system tions are implemented, is essential.
cle, which in many cases also influence thus results from three subsystems All these examples have one thing in
diagnostics. One example is the newly that must be diagnosed as one. common: They describe the next evo­
added battery management, which must Looking at autonomous driving – lutionary step in what is now called
be used to check both the charging pro- regardless of the level reached –, the the self-diagnosis of Electronic Control
cess and the cell status. Another exam- topic of “safety” plays a major role. Units (ECUs).
2
CHANGING DIAGNOSTICS processor cores, and, on the other, a Measuring Systems e. V. (ASAM) under
diagnostic master that merges self-diag- the name Service Oriented Vehicle Diag-
Today’s situation has grown over the nosis at the function level as in the brake nostics (SOVD). The aim is to define
years: There is an ECU for every main case described above. In addition, every an interface which allows diagnostics
function in the vehicle, every ECU HPC also performs today’s self-diagno- on a vehicle, for example in a repair
monitors its environment (self-diagno- sis. In other words, it monitors the inputs shop, via remote access or also as a tes-
sis), the ECUs are interconnected via and outputs as well as the significantly ter directly in the vehicle (Proximity,
bus systems – usually via a central gate- increased number of signals over the Remote, In-vehicle). As many existing
way, which is also connected with the Ethernet connection to other HPCs, mechanisms and standards as possible
Onboard Diagnostics (OBD) jack. This FIGURE 2. (for example TCP/IP) should be used
is how a repair shop employee can con- to simplify standardization and subse-
nect an external tester in which appro- quent implementations.
STANDARDIZED HPC DIAGNOSIS
priate algorithms read data from the As the name suggests, access should
ECUs and combine it to create meaning- An HPC therefore represents its own follow the structural pattern of the ser-
ful repair instructions. diagnostics, function diagnostics and – vice-oriented architecture. Today’s diag-
However, autonomous driving now since it enables connection to the Inter- nostic protocols operate almost exclu-
requires significantly higher processing net – also the interface for conventional sively in request-response mode. The
power in the vehicle than can be pro- ECUs. From the point of view of an tester usually queries individual data
vided by today’s ECUs. Consequently, at external tester, this approach means a elements for each ECU and then evalu-
least two High-performance Computers significant increase in the quality of ates them. The chunks of information
(HPCs) are installed in the vehicle for information because much information are closely related and often available
redundancy reasons, FIGURE 1. These are is already pre-filtered, aggregated and redundantly in different ECUs as well
usually multi-core systems with several evaluated before it is transmitted. as temporarily uncorrelated. In service­-
operating systems and possibly dynamic Such an interface for diagnostics is oriented querying, a query enables the
load distribution and implement both naturally not only of interest to OEMs, determination of precisely the informa-
centralized control and diagnostic func- but also to numerous other parties: tion needed. This means the preprocess-
tions. Furthermore, today’s ECUs will manu­facturers of HPCs and ECUs for ing is already taken care of by the data
continue to be used for local tasks for inside the vehicle, manufacturers of server, here the SOVD server in the HPC,
a long time to come. test tools used outside the vehicle, but FIGURE 3. Whether the data for this was
At least two new diagnostic tasks will potentially also fleet operators, testing queried from the individual ECUs or was
be implemented in the HPCs: on the one organizations, insurance companies and already continuously aggregated in the
hand, a system diagnosis of the HPC legislators. The standardization of the HPC is irrelevant.
which continuously monitors the func- interface thus stands to reason; this is SOVD does not make today’s diagnos-
tion of the operating systems and of currently taking place at the Association tics obsolete; rather, it fulfills all existing
the distribution of tasks to the various for Standardization of Automation and use cases, such as fault memory opera-

FIGURE 1 Paradigm shift:

centralized processing power
(© Softing Automotive)

3
DE VELO PMENT Simul ation and Testing

ECU diagnosis HPC diagnosis

ECU HPC

Sensor Actuator

Sensor Actuator

Core/OS diagnosis

CAN bus
Diagnosis
master

Ethernet
FIGURE 2 New diagnostic capabilities in HPCs (© Softing Automotive)

tions, ECU programming, variant cod- SMART DIAGNOSTIC ENGINE sequences, on the other hand, is too
ing, and adds new ones. With regard to AS SOVD PROTOT YPE difficult to operate and is also not ideal
data-oriented use cases, this includes, for from a security point of view; it has
example, the possibility of reading out The idea of a data server is nothing new already been supplemented in a stan-
current HPC-internal variables or large in diagnostics; it has been established for dardized manner by OTX.
data containers. With reference to the many years now as a Modular Vehicle Softing has therefore been using an
process, it should be possible to directly Communication Interface (MVCI) server extended solution for years; it is imple-
analyze the vehicle status or log vehicle with ODX data. However, the standard- mented as a platform-independent
data in the HPC. Addressed vehicle- ized object-oriented Application Pro- version and extends the MVCI server
related use cases include, for example, gramming Interface (API) is not suitable and the OTX runtime with a function­-
the execution of processes directly in for remote use cases due to the large oriented interface, FIGURE 4. With it, the
the vehicle and simultaneous access number of function calls required. The application engineers can always access
by multiple testers. integrated Java-based environment for precisely the functions they require at

FIGURE 3 Service Oriented Vehi-

cle Diagnostics (SOVD) standard
(© Softing Automotive)

4
 ECU programming Diagnostic tester

ECU variant coding

Vehicle quick test
ECU identification
DTC operations
Diagnostic measurement Diagnostic sequences
Actuator test Test sequences
Diagnostic services ... Automation Diagnostic services

Remote Remote Local

Application
GuideLine C++, C#, COM Softing SDE

AGL Smart diagnostic API

OTX scripts
OTX runtime
OTX
OTX
C++, C#, Java, COM
Diagnostic data MVCI server API
MVCI server
ODX D-PDU-API

FIGURE 4 Smart Diagnostic Engine (SDE) from Softing (© Softing Automotive)

any one time, regardless of the diag­ plays a major role (session selection, engineering in development, where rare
nostic protocol, such as “FaultMemory- SecurityAccess). Therefore, with the test objects are managed centrally and
WholeVehicle” or “EcuProgramming.” completion of the standardization, can be used and updated by different
The implementation is manufacturer­ a standardized API based on the REST users all over the world [1]. A similar sce-
specific or, depending on the function, paradigm and building on the current nario is increasingly found in the repair
even vehicle-variant-dependent and can API will be offered alongside the current shop, where a service technician can
therefore be controlled via a configura- C++ API, FIGURE 5. receive remote support from a technical
tion file (Application GuideLine, AGL). center in complicated cases. This is par-
Today, the so-called Smart Diagnostic ticularly important when the repair shop
REMOTE DIAGNOSTICS
Engine (SDE) from Softing is already in has to come to the vehicle, for example
WITH SOFTING SDE
use in all kinds of applications: in PC in the case of construction machinery or
applications in engineering, manufactur- The service-oriented approach is particu- agricultural equipment. This is where the
ing and repair shops, on smart devices, larly well suited for remote diagnostics combination of Vehicle Communication
such as cell phones and tablets, but also because it decouples the retrieval and Interface (VCI) and a 4G/5G-capable TCU
in embedded applications such as data preparation of information from the is an incredible help.
loggers and on Telematic Control Units often unreliable transmission link: The integration of Softing SDE in the
(TCUs) in the vehicle. Comparing the A request is made to the data server – VCI is a great advantage, particularly
use cases with those of the SOVD server, regardless of whether it is implemented in manufacturing, as the complete
a complete match can be discovered. as an SOVD server or with Softing SDE diagnostic solution can be plugged into
Both solutions address in-vehicle, in its current form – and the server the right place in the vehicle and diag-
near-vehicle and remote applications, obtains data from various sources and nostic sequences can then be performed
offer a service-oriented API and also prepares it. The result can then be at all line positions independently of
support today’s (classic) diagnostics. reported back. Delays, due perhaps to the Wi-Fi coverage. A Wi-Fi connection
A genuine service-oriented architecture an interrupted connection, do not affect is then no longer required for ECU pro-
is not given with Softing SDE because the validity of the information. gramming; test results from autonomous
the current focus is on today’s vehicles There are numerous use cases for processes in the VCI are read out at a
in which the communication status the procedure: One example is remote suitable point.
5
DE VELO PMENT Simul ation and Testing

FIGURE 5 Softing SDE

as SOVD proto­t ype of ASAM
(© Softing Automotive)

BEGINNING THE DIAGNOSTICS in encrypted form on the HPC in the and for the HPCs. Solutions that exist
OF TOMORROW TODAY vehicle, but the release procedures today, such as the Softing SDE, target
remain the same as they are today. the same use cases and have been
Using a standard has advantages Finally, the data processing chain is proven in practice. They can be imple-
especially when there is considerable closed: In development, the SDE is mented immediately and later expan­
co­­­­operation with other companies. integrated in the engineering tester on ded into a standardized solution.
Re­­gardless of this, there is some- the PC, in manufacturing, it moves
REFERENCE
thing to be said for starting with to the VCI, and, in the event of service,
[1] Steffelbauer, M.: Biggest Possible Develop­
established implementations such it is available in the HPC as part of the ment Efficiency with Remote Engineering. In:
as Softing SDE today: vehicle. Once the SOVD methodology ATZelectronics worldwide 10/2019, pp. 36-39
– parallelism of legacy and is implemented in the company, the
new implementation cor­responding extension can be retrofit-
– functioning ODX data process ted. Diagnostics remains reliable in all
– continuity of the solution. cases because data and runtime behav-
Even though, in the case of new vehi- ior never change.
cles, significantly more diagnostics
can be implemented in the vehicle due
CONCLUSION
to the introduction of HPCs, today’s
vehicles will still need to be main- Autonomous and electric driving are
tained and repaired for decades. If leading to new electric/electronic archi-
both solutions use similar basic func- tectures that also enable a new form of
tionalities, the changeover is simpler diagnostics through the integration of
and less error-prone. The introduction HPCs in the vehicle and connection to
of functioning ODX data processes the Internet. This is currently being stan-
in particular required a great deal dardized by ASAM e. V. under the name
of effort – today, these processes are SOVD. In the process, today’s use cases
stable. Integrating Softing SDE only are being complemented by new capabil­
leads to a new localization in this ities that include, in particular, remote
case, with the data then available diagnostics and specific diagnostics with

IMPRINT MANAGING DIRECTORS:

Special Edition 2021 in cooperation with Softing Automotive Electronics GmbH, Stefanie Burgmaier | Andreas Funk | Joachim Krieger
Richard-Reitzner-Allee 6, 85540 Haar; Springer Fachmedien Wiesbaden GmbH,
PROJECT MANAGEMENT: Anja Trabusch
Postfach 1546, 65173 Wiesbaden, Amtsgericht Wiesbaden, HRB 9754,
USt-ldNr. DE81148419 COVER PHOTO: © Softing Automotive Electronics GmbH

6
DIAGNOSTIC AND
TEST SOLUTIONS
BY SOFTING