01

The challenges posed by the E/E architectures in modern vehicles are enormous: Some of the advanced systems for driver assistance, infotainment and interfaces between the vehicle and external networks transmit large amounts of data. The safety-relevant systems of autonomous vehicles must be designed with redundancy. At the same time, the drivetrain and most auxiliary components are being electri-fied. All of this has significant effects on the architecture and diagnostics of vehicle E/E systems. What are the typi-cal properties of the E/E architecture in new automotive models? Domain controllers of the individual E/E segments are connected over automotive Ethernet to a central gate-way with an integrated Ethernet switch . These segments include the drivetrain, body, chassis, safety systems and in-fotainment, each of which is connected to domain-specific control units, actuators and sensors. They are intercon-nected via bus technologies such as CAN, CAN FD, FlexRay, LIN or other Ethernet clusters. The central gateway also

The electronically controlled systems of modern vehicles are networked with one another to a high degree, and they execute many complex functions. The communications protocol DoIP (Diagnostics over Internet Protocol) – which is supported by AUTOSAR – enables flexible and powerful diagnostics of systems over Ethernet, WLAN and mobile data connections: both offboard in the workshop as well as onboard and via remote access during the drive. The same applies to flashing of ECUs in manufacturing, in the workshop or over-the-air. For this to work properly, it is necessary to define the communication paths between the diagnostic tester and the specific diagnostic object (device under test or DUT) of the vehicle network precisely. It is essential to use the right tools to find optimal paths in a modern vehicle’s complex Electrical/Electronic (E/E) network.

AUTOSAR-Conformant Vehicle Diagnostics over DoIP:Developing Diagnostic Communications for E/E Systems

PREEvision Technical Article

serves as the vehicle’s communication link to the Internet and OEM-specific services in the backend (Figure 1).

Vehicle Diagnostics via the DoIP StandardThe DoIP standard (ISO 13400) offers options which are essential to efficient diagnostics and programming of modern vehicle electronics. In addition to data transfer, DoIP offers other features for finding and recognizing vehi-cles, setting up and checking connections, flashing ECUs, error management and firewall functionalities. DoIP em-beds diagnostic messages into the TCP/IP protocol that are independent of the transport layer and can be de-scribed with the UDS (Unified Diagnostic Services, ISO 14229) protocol. On the other hand, configuring communi-cations via DoIP is very complicated. That is because many elements need to be created, linked to one another and pa-rameterized, such as sockets, socket connections and PDUs (Protocol Data Units).

02

Developing Diagnostic Communications for E/E Systems / December 2018

Many Roads Lead to the Same GoalIn the example of Figure 1, an external diagnostic tester is connected to the central gateway over DoIP. During the drive, the systems are monitored in the vehicle by internal testers. In both cases, the DUTs must be connected to the relevant testers. Many alternative paths are possible based on the various options offered by the diagnostic standards DoIP and UDS, the topology of the physical network and its subdivision into logical subnets in the form of Ethernet VLANs (Virtual Local Area Networks). Connections can be implemented between testers and DUTs over all of these paths. In the case of DoIP, testers always assume the role of the client. Therefore, the gateway in the example plays the role of the server. The tester must be authenticated by the gateway. When an external DoIP tester is connected over an Ethernet gateway, different cases must be differ-entiated as described below (Figure 2):

DoIP connection to gateway with diagnostic routing over UDS to DUTs in other subnets (in figure, left):

> The gateway extracts the UDS message and routes it to the DUT in another bus system such as CAN.

DoIP connection to gateway with diagnostic routing over UDS into another logical subnet (VLAN) of the same Ether-net cluster (figure, middle):

> DUT and external tester are in the same Ethernet cluster here. However, there is no VLAN channel which could logically link the two communication partners with one another. > The gateway extracts the UDS message and routes it to the relevant VLAN of the Ethernet cluster.

DoIP connection to the switch of the gateway which routes the communication directly to the DUT over Ethernet (in figure, right):

> After successful authentication of the DoIP tester, the gateway reconfigures the switch so that the tester and DUT can communicate with one another directly. This is handled either by VLAN retagging or by incorporating the external tester into the VLAN. > In this case, the DUT assumes the role of the DoIP server.

Figure 1: E/E architecture of new model series (schematic).

BODYDOMAIN

CENTRAL GATEWAY

BODY 1

BODY 2

BODY 3

CAN

LIN

DRIVINGDOMAIN

DRIVING 1

DRIVING 2

DRIVING 3

CAN FD

COMFORTDOMAIN

COMFORT 1

COMFORT 2INTERNAL TESTER

COMFORT 3

CAN

INFOTAINMENTDOMAIN

INFOTAINMENT 1

INFOTAINMENT 2

INFOTAINMENT 3

ETHERNET

ETHERNETETHERNETETHERNETETHERNET

SWITCH

EXTERNALTESTER

HANDHELDSCAN TOOL

BACKENDSERVER

03

Developing Diagnostic Communications for E/E Systems / December 2018

All of these scenarios are applied in practice, because they each have unique advantages and disadvantages. In the first case, communication between the tester and DUT is fully decoupled. This scenario represents the only way to diagnose a non-Ethernet DUT with a DoIP tester. In the second case, communication between the tester and DUT is also decoupled by the gateway. In both cases, decoupling requires additional routings which load the gateway. The second scenario is used, however, to reprogram ECUs, where the entire data flow is explicitly routed through the gateway for security reasons. The third case gives the tester direct access to the components of the Ethernet cluster. The Ethernet switch that is integrated into the gateway leads to efficient, high-performance routing in this case. Therefore, this scenario primarily offers benefits when large amounts of data need to be transferred. Because the communications are not decoupled, there is no fundamental prevention of unauthorized external access in this case. As a result, additional protective measures are needed to supplement the mandatory authentication by the gateway.

Describing DoIP Vehicle Diagnostics ConsistentlyAdvanced software environments such as PREEvision from Vector can be used to consistently model, evaluate and optimize complex E/E architectures. Within this environment, many assigned tasks can be processed consistently based on a common model. They begin with requirements analysis and extends to the logical, functional and software levels of the architecture, the design of network topologies, block circuit diagrams and wiring harnesses and finally the geometric layout of E/E systems. In addition, PREEvision provides tools and functions that are used for detailed modeling of the communication within the vehicle network. It is also possible to conduct parallel, collaborative work on a common model among many teams. High-performance import and export interfaces for AUTOSAR and other relevant exchange formats enable easy integration of the engineering environment into existing tool chains. PREEvision offers a workflow for describing vehicle diagnostics (Figure 3).

Figure 2: Options for connecting external testers to a Device Under Test (DUT) via a central gateway.

VLAN 1

VLAN 2

DoIPGATEWAY

DUT

ETHERNET

DoIP

UDS

SWITCH

EXTERNALTESTER

VLAN 1CAN FD

VLAN 2

ETHERNET

DoIPGATEWAY

DUT

CAN FD

DoIP

UDS

SWITCH

EXTERNALTESTER

SWITCH

DoIPGATEWAY

DUT

ETHERNET

DoIP

SWITCH

EXTERNALTESTER

VLAN 1

04

Developing Diagnostic Communications for E/E Systems / December 2018

Achieving an Optimal Communications Infrastructure More QuicklyTo support the workflow, PREEvision provides a Diagnostic Communications Explorer (Figure 4). The left side of the Explorer window contains categories which are organized in line with the specific step. The right side contains one or more table views of the specific data. The Diagnostic Com-munications Explorer is based on an existing network to-pology, and it starts with definition of the testers and DUTs. Then the user is guided through the workflow based on individual categories. Table-based editors are useful for checking the status of the model after each step and also advancing the modeling process. Elements selected in the Explorer are also highlighted in a diagram that represents the network topology. This is how PREEvision graphically depicts, in a user-friendly way, the paths and routings in the E/E architecture that are used in diagnostics. For as-signments that can simply be made by drag-and-drop op-eration, the relevant elements are chosen by what is known as an artifact picker and are made available to the user. For complex synthesis tasks, there are selection-sensitive buttons in the upper area of the Explorer, which are located next to the usual buttons for standard functions such as sorting and filtering. The Explorer also shows the key arti-facts that are generated in the synthesis of the communi-cations infrastructure. They enable efficient navigation and editing of the relevant communication artifacts and ensure consistent model structures when changes and adapta-tions are made. This is done with tables, which are assigned to the last workflow step.

In the first step, the network topology of the vehicle E/E system and the components are defined. The offboard tes-ters that are not part of the vehicle network are considered external components in the model. In the second step, the internal testers and DUTs that are to be linked to one an-other are highlighted. A tester may monitor any number of DUTs. A DUT can also be addressed by multiple testers, e.g. one external tester and one internal tester. In the third step, PREEvision finds the paths within the network over which the testers and DUTs can communicate with one an-other. If there is only one communication option, PREEvi-sion automatically generates its associated path informa-tion. If different paths are identified, the user can select one of the paths. The tester-to-DUT assignments are stored in the PREEvision model. They assist users as a tar-get state for diagnostic communication – both in specify-ing vehicle diagnostics and in checking the finished model for diagnostic communication. In the last step of the work-flow, the communication infrastructure needed for diag-nostics is fully synthesized. Afterwards, all the paths and routings over which testers and DUTs can communicate with one another are fixed. Various AUTOSAR artifacts of the communication infrastructure are generated which de-pend on the connection scenario and the transmission me-dium, such as PDUs, DoIP connections, sockets and socket connections, CAN frames or segmentation PDUs. Diagnos-tic contents related to specific UDS service requests/re-sponses are not created here.

Figure 3: Workflow for describing vehicle diagnosticswith PREEvision.

Design of the network topology: Ethernet, CAN, CAN FD

Defining testers and DUTs

Assigning DUTs to testers

Synthesizing the infrastructure for diagnostic communications:PDUs, transport protocol, sockets, routings

Selecting thecommunication paths

Recognizingcommunication paths

05

Developing Diagnostic Communications for E/E Systems / December 2018

Authors Dr. Daniel Gebauer Vector Informatik GmbH Product Management PREEvision

Originally published in “Automobil Elektronik” magazine Issue 11-12 – December 2018

SummaryModern E/E engineering environments can be used to model diagnostic communication over CAN and automotive Ethernet, simply and quickly, with the help of the UDS and DoIP protocols including routing via diagnostic gateways. The first step is to define all external offboard and internal onboard testers and the DUTs (Devices Under Test), i.e. the components to be diagnosed. Each DUT is then assigned to relevant internal and external testers. The development tool then uses the assignments which have been made to determine the possible communication paths between testers and DUTs. Alternative paths are presented to the user for selection. In the final step, the tool synthesizes all the supplemental artifacts which are needed for AUTOSAR-conformant diagnostic communications. This significantly reduces the effort needed to configure the communication infrastructure for DoIP-based diagnostics.

Figure 4: Diagnostic Communications Explorer with network diagram in PREEvision.