PREEvision Technical Article

Transcription

1 PREEvision Technical Article AUTOSAR-Conformant Vehicle Diagnostics over : Developing Diagnostic Communications for E/E Systems 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 (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 ) 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. 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 electrified. All of this has significant effects on the architecture and diagnostics of vehicle E/E systems. What are the typical 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 gateway with an integrated Ethernet switch. These segments include the drivetrain, body, chassis, safety systems and infotainment, each of which is connected to domain-specific control units, actuators and sensors. They are interconnected via bus technologies such as CAN,, FlexRay, LIN or other Ethernet clusters. The central gateway also serves as the vehicle s communication link to the Internet and OEM-specific services in the backend (Figure 1). Vehicle Diagnostics via the Standard The standard (ISO 13400) offers options which are essential to efficient diagnostics and programming of modern vehicle electronics. In addition to data transfer, offers other features for finding and recognizing vehicles, setting up and checking connections, flashing ECUs, error management and firewall functionalities. embeds diagnostic messages into the TCP/IP protocol that are independent of the transport layer and can be described with the UDS (Unified Diagnostic Services, ISO 14229) protocol. On the other hand, configuring communications via is very complicated. That is because many elements need to be created, linked to one another and parameterized, such as sockets, socket connections and PDUs (Protocol Data Units). 01

2 HANDHELD SCAN TOOL BACKEND SERVER CENTRAL BODY DRIVING COMFORT INFOTAINMENT CAN CAN BODY 1 DRIVING 1 COMFORT 1 INFOTAINMENT 1 BODY 2 DRIVING 2 COMFORT 2 INTERNAL INFOTAINMENT 2 LIN BODY 3 DRIVING 3 COMFORT 3 INFOTAINMENT 3 Figure 1: E/E architecture of new model series (schematic). Many Roads Lead to the Same Goal In the example of Figure 1, an external diagnostic tester is connected to the central gateway over. During the drive, the systems are monitored in the vehicle by internal testers. In both cases, the s must be connected to the relevant testers. Many alternative paths are possible based on the various options offered by the diagnostic standards 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 s over all of these paths. In the case of, 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 tester is connected over an Ethernet gateway, different cases must be differentiated as described below (Figure 2): connection to gateway with diagnostic routing over UDS to s in other subnets (in figure, left): > > The gateway extracts the UDS message and routes it to the in another bus system such as CAN. connection to gateway with diagnostic routing over UDS into another logical subnet (VLAN) of the same Ethernet cluster (figure, middle): > > 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. connection to the switch of the gateway which routes the communication directly to the over Ethernet (in figure, right): > > After successful authentication of the tester, the gateway reconfigures the switch so that the tester and 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 assumes the role of the server. 02

3 VLAN 2 VLAN 2 UDS UDS Figure 2: Options for connecting external testers to a Device Under Test () via a central gateway. 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 is fully decoupled. This scenario represents the only way to diagnose a non-ethernet with a tester. In the second case, communication between the tester and 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 Vehicle Diagnostics Consistently Advanced 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). 03

4 Design of the network topology: Ethernet, CAN, Recognizing communication paths Defining testers and s Assigning s to testers Figure 3: Workflow for describing vehicle diagnostics with PREEvision. In the first step, the network topology of the vehicle E/E system and the components are defined. The offboard testers that are not part of the vehicle network are considered external components in the model. In the second step, the internal testers and s that are to be linked to one another are highlighted. A tester may monitor any number of s. A 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 s can communicate with one another. If there is only one communication option, PREEvision automatically generates its associated path information. If different paths are identified, the user can select one of the paths. The tester-to- assignments are stored in the PREEvision model. They assist users as a target state for diagnostic communication both in specifying vehicle diagnostics and in checking the finished model for diagnostic communication. In the last step of the workflow, the communication infrastructure needed for diagnostics is fully synthesized. Afterwards, all the paths and routings over which testers and s can communicate with one another are fixed. Various AUTOSAR artifacts of the communication infrastructure are generated which depend on the connection scenario and the transmission medium, such as PDUs, connections, sockets and socket connections, CAN frames or segmentation PDUs. Diagnostic contents related to specific UDS service requests/responses are not created here. Selecting the communication paths Synthesizing the infrastructure for diagnostic communications: PDUs, transport protocol, sockets, routings Achieving an Optimal Communications Infrastructure More Quickly To 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 Communications Explorer is based on an existing network topology, and it starts with definition of the testers and s. 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 assignments that can simply be made by drag-and-drop operation, 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 artifacts that are generated in the synthesis of the communications infrastructure. They enable efficient navigation and editing of the relevant communication artifacts and ensure consistent model structures when changes and adaptations are made. This is done with tables, which are assigned to the last workflow step. 04

5 Figure 4: Diagnostic Communications Explorer with network diagram in PREEvision. Summary Modern 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 protocols including routing via diagnostic gateways. The first step is to define all external offboard and internal onboard testers and the s (Devices Under Test), i.e. the components to be diagnosed. Each 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 s. Alternative paths are presented to the user for selection. In the final step, the tool synthesizes all the supplemental artifacts which are needed for AUTOSARconformant diagnostic communications. This significantly reduces the effort needed to configure the communication infrastructure for -based diagnostics. Authors Dr. Daniel Gebauer Vector Informatik GmbH Product Management PREEvision Originally published in Automobil Elektronik magazine Issue December