CN110213221B - Method for performing diagnostics - Google Patents
Method for performing diagnostics Download PDFInfo
- Publication number
- CN110213221B CN110213221B CN201910145088.9A CN201910145088A CN110213221B CN 110213221 B CN110213221 B CN 110213221B CN 201910145088 A CN201910145088 A CN 201910145088A CN 110213221 B CN110213221 B CN 110213221B
- Authority
- CN
- China
- Prior art keywords
- switch
- tester
- microcontroller
- data
- host computer
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/029—Firewall traversal, e.g. tunnelling or, creating pinholes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0227—Filtering policies
- H04L63/0236—Filtering by address, protocol, port number or service, e.g. IP-address or URL
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1441—Countermeasures against malicious traffic
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/16—Implementing security features at a particular protocol layer
- H04L63/166—Implementing security features at a particular protocol layer at the transport layer
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
- H04L67/125—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/14—Session management
- H04L67/141—Setup of application sessions
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/565—Conversion or adaptation of application format or content
- H04L67/5651—Reducing the amount or size of exchanged application data
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
- H04L67/62—Establishing a time schedule for servicing the requests
Abstract
The present invention relates to a method for performing diagnostics. The invention relates to a method for performing diagnostics in a vehicle, wherein components of the vehicle are accessed by an external tester (340) via a diagnostic terminal (342), wherein the access is performed via a gateway (300), the gateway (300) having a diagnostic terminal (342) and a switch (302), wherein the switch (302) comprises a switch core (308) and a switch CPU (304), wherein data is transmitted to a microcontroller (320) of a host computer and data from the microcontroller of the host computer are transmitted in the scope of diagnostics, wherein in the method a connection is first established between the tester (340) and the diagnostic terminal (342), wherein in this case a reduced data rate is set by the switch (302) until a secure data tunnel is established.
Description
Technical Field
The present invention relates to a method for performing diagnostics in a vehicle and to a device for performing the method. The invention further relates to a computer program and a machine-readable storage medium for carrying out the method.
Background
Diagnostic methods in motor vehicles are used in order to monitor the mode of action of the components of the vehicle and thus the functional performance of the entire vehicle. Diagnosis is understood here as the recognition of a fault and the determination of the cause of the fault based on the detected data. In many cases, components or devices of the motor vehicle need to be accessed from the outside or from the outside. The access may be made here via the internet. In this regard, doIP (diagnostics over internet protocol) is known. Thereby indicating the communication protocol of the automotive electronics.
A typical ethernet switch-based gateway in a vehicle, which gateway designates a network transition, must send all ethernet packets from different vehicle areas to a host computer (Leitrechner) or a microcontroller of the host computer in order to be able to make decisions concerning the firewall and concerning the steering (Leiten) or routing of the data. This requires that a firewall be implemented generally on the host computer's microcontroller and that the data of the vehicle and the single ethernet terminal be delivered to the host computer's microcontroller. This places a significant Overhead or burden (Overhead) on both the host computer's microcontroller and the ethernet terminals that connect the host computer's microcontroller to the switch, and is thus a non-scalable solution.
For safety reasons, however, it is advantageous if the external unsafe diagnostic terminal is connected directly to the microcontroller of the host computer, so that the data packets may be sent from the unsafe terminal directly to the microcontroller of the host computer via the firewall. In this case, there is a disadvantage in that an additional burden is imposed that the microcontroller of the host computer is secured by the firewall. It is also considered that when the terminal is attacked or compromised (kompromittieren), the complete access may be compromised because the gateway is the access point for all control devices in the vehicle network.
Modern and intelligent Ethernet switch-based gateways in vehicles may have an Ethernet Firewall (Ethernet-Firewall) within the switch itself, as the switch has its own CPU. The greatest advantage is that the switch does not have to send the entire traffic (Verkehr) in the vehicle to the microcontroller of the host computer. The switch itself is a so-called SoC (System-on-a-Chip) with a microcontroller, wherein the CPU of the switch is connected to the switch and uses a 2GBit interface. Thus, the data need not be sent to the microcontroller of the host computer, which has no target address for the host computer's microcontroller. Thus, a larger communication bandwidth of the entire system is provided.
Diagnostic terminals in the vehicle, such as OBD (on board diagnostics) or DoIP, provide access to a central unit in the vehicle. Thus, when the diagnostic terminal of the vehicle is compromised, an attacker can gain full access to the vehicle. The diagnostic terminal provides a variety of critical services such as updating firmware and accessing confidential critical data.
Publication DE102015214423A1 describes a method for protecting operating parameters of a motor vehicle, wherein a hypervisor runs an application program and a vehicle recorder jointly on the hardware of a virtualized control device. The tachograph obtains the operating parameters of the application program and records them on the hardware. The diagnostic tool is connected to other control devices. The diagnostic tool reads the operating parameters from the hardware.
Disclosure of Invention
In this context, a method according to the invention and a device for carrying out the method are described. In the method, components of the vehicle are accessed via a diagnostic terminal with an external tester, wherein the access is made via a gateway having the diagnostic terminal and a switch, wherein the switch comprises a switch core and a switch CPU, wherein in the scope of the diagnosis data is transmitted to and from a microcontroller of a host computer, wherein in the method a connection is first established between the tester and the diagnostic terminal, wherein in this case a reduced data rate for the diagnostic terminal is set by the switch until a secure data tunnel is established between the tester and the diagnostic terminal. Furthermore, a machine-readable storage medium is described, which has a computer program stored thereon, which is designed to carry out the method according to the invention when the computer program is executed on a computing unit.
Thus, a method is described, in particular computer-aided, for performing a diagnosis of a component of a vehicle (for example a control device), which is accessible from an external computing unit. Here, the components should be protected against unauthorized access. In addition, a firewall is provided. Furthermore, it is provided that the bandwidth of the diagnostic terminal is reduced, in particular strongly, within a defined period of time.
Other advantages and constructions of the invention will be apparent from the description and accompanying drawings.
It is to be understood that the features described above and yet to be explained below are applicable not only in the respectively illustrated combination but also in further combinations or individually, without departing from the scope of the invention.
Drawings
Fig. 1 shows a switch-based gateway according to the prior art.
Fig. 2 shows the way in which the gateway of fig. 1 functions.
Fig. 3 shows the DoIP procedure.
Fig. 4 shows a proposed safe diagnostic procedure.
Detailed Description
The invention is schematically illustrated in the drawings according to embodiments and is described in detail below with reference to the drawings.
Fig. 1 shows a switch-based standard gateway, generally designated by reference numeral 10. The figure shows a standard ethernet switch 11, which standard ethernet switch 11 has a switch core 12 as standard ethernet switch, which switch core 12 has connections 14 to different vehicle domains, which are assigned to different VLANs. The figure also shows a microcontroller 20 of a host computer, the microcontroller 20 of the host computer having application software 22, an AUTOSAR runtime environment 24, communication traffic 26, PDU routers 28, an Ethernet interface 30, a LIN interface 32 and a CAN interface 34. Further, the figure shows a tester 40, a connection 42 for data traffic for all VLANs, and a diagnostic terminal 44.
In the illustrated configuration, tester 40 is connected directly to the DoIP edge or edge node, i.e., to the host computer's microcontroller 20. An edge node (edgene) is an endpoint in a vehicle, such as a control device or gateway, that is set up for DoIP communications. The host computer's microcontroller 20 is thus an edge node, and thus the TLS tunnel between the host computer's microcontroller 20 and the tester 40 is set up as a gateway.
Likewise, the second ethernet terminal is connected in the microcontroller 20 of the host computer to an ethernet switch in the form of a management terminal. For each of the IP addresses based on the routing decisions, the entire data traffic arriving in each terminal of the switch must be directed to the microcontroller 20 of the host computer. Thus, a complete implementation of routing and firewall is performed in the host computer's microcontroller 20. This design is ineffective in the following way: the overflow of the entire data packet to the microcontroller 20 of the host computer may reduce the amount of data traffic that can be transceived by the ethernet switch-based gateway. However, with other sensors and control devices in future vehicle systems, a high bandwidth is required. Thus, the design is not overly scalable in terms of bandwidth. There is also only one level of security in terms of security. Thus, when the diagnostic terminal is compromised by an attacker, the attacker can gain access to the vehicle.
Fig. 2 shows an intelligent ethernet switch-based automotive gateway, generally designated by reference numeral 100. The figure shows an intelligent ethernet switch 102, the intelligent ethernet switch 102 having a CPU104, an interface UNIMAC106 and a switch core 108, and having connections 110 to different vehicle domains, which are assigned to different VLANs. UNIMAC106 is thus the following interface: the interface connects the switch core network terminals directly with RAM (random access memory) of the switch CPU 104. The figure also shows a microcontroller 120 of a host computer, the microcontroller 120 of the host computer having application software 122, an AUTOSAR runtime environment 124, communication traffic 126, a PDU router 128, an Ethernet interface 130, a LIN interface 132, and a CAN interface 134. Further, a tester 140 and diagnostic terminals 142 are shown.
In this design or architecture, there is a firewall for gateway signals on the CPU104, which CPU104 is within the switch 102. In this case, it is particularly advantageous if signals of different vehicle domains on a plurality of VLANs (virtual local area networks) do not have to be routed to the microcontroller 120 of the host computer in order to make a decision regarding routing. Routing and employing firewalls is performed by the switch CPU 104. The switch core 108 is connected to the internal CPU104, using a 2GBit ethernet interface that supports high bandwidth (arrow 150). One of the switch terminals is used as a diagnostic terminal 142 and diagnostic signals arrive through the firewall and are then directed to the microcontroller 120 of the host computer.
Although this is a highly scalable solution, the main concern is to separate the diagnostic communication signal from the further signals inside the vehicle and also to protect the communication at different levels.
The proposed method is then described in its entirety, which enables secure diagnostic communication in an intelligent ethernet switch-based gateway. It is first clarified how the DoIP communication proceeds, and then it is described in detail how the DoIP communication can be protected.
Fig. 3 shows a description of a standard DoIP communication procedure. Refer to ISO13400-2. The figure shows in particular the DoIP communication initiation flow in a scene graph. The figure shows a tester 200 and a DoIP edge node 202.
The tester 200 or an external user connects to the diagnostic terminals using one of the available ethernet switch terminals.
The DoIP communication is performed as follows:
a first step of: tester 200 initiates a connection with DoIP edge node 202:
a) Tester 200 first sends a vehicle identification query to DoIP edge node 202, i.e., the host CPU, (arrow 210). b) The DoIP edge node 202 replies to this with a vehicle identification reply to the tester 200 (arrow 212).
c) Tester 200 now sends a query to DoIP edge node 202 to activate the route (arrow 214).
d) The DoIP edge node 202 responds to this with a tester route activation reply (arrow 216).
And a second step of: between the DoIP edge node 202 and the tester 200, a TLS tunnel (TLS: transport layer security) is created for secure and integrity protected communications (arrow 220):
a) After the tunnel has been created, tester 200 queries DoIP edge node 202 to enable routing for further connection with control devices in the vehicle (arrow 222).
b) The DoIP edge node 202 replies with a route activation response (arrow 224).
And a third step of: now, routing and data transfer to/from further control devices in the vehicle is allowed, (arrow 230):
a) The tester 200 sends a UDS service query, (UDS: unifieddisposity service (arrow 232).
b) Tester 200 retrieves the answer (arrow 234).
c) The UDS service is critical because it enables access to confidential data and permits overwriting of firmware.
After the TLS tunnel between the tester 200 and the host computer of the microcontroller has been set up as a gateway, the tester 200 may require access in order to communicate itself with the internal control device 250 within the vehicle, which internal control device 250 is connected to the gateway via CAN, ethernet, LIN or FlexRay. The connection would then be as from tester to gateway/from gateway to tester and gateway to internal control device 250/from internal control device 250 to gateway, meaning that a process with two (arrows 236, 238) or more steps would be performed in order to gain access to the or the internal control device 250.
An architecture for security diagnostics in an intelligent switch-based gateway is shown in fig. 4. The figure shows the proposed security diagnostic procedure in terms of a switch-based gateway, generally designated by reference numeral 300. The figure shows an intelligent ethernet switch 302, the intelligent ethernet switch 302 having: a CPU304, the CPU304 accessing RAM; UNIMAC306 and switch core 308, and connections 310 to different vehicle domains that are assigned to different VLANs. In addition, the figure shows a microcontroller 320 of a host computer, the microcontroller 320 of the host computer having application software 322, an AUTOSAR runtime environment 324, communication traffic 326, a PDU router 328, an Ethernet interface 330, a LIN interface 332, and a CAN interface 334. Further, a tester 340 and diagnostic terminals 342 are shown. The steps for completing the process are defined later.
Fig. 4 illustrates that when a diagnostic data packet is directed from the diagnostic switch terminal to the microcontroller 320 of the host computer, the diagnostic data packet has a completely different route than the other data packets. The switch core 308 is connected to the switch CPU304, wherein a plurality of data sequences (Datenreihen) are used. As soon as the DoIP packet arrives at the switch 302, TCAM rules (TCAM: ternaryContent-address memory) are implemented to send this type of packet to a specific sequence, which is connected to the switch CPU 304. The packet is analyzed in a firewall on the CPU and then directed to the DoIP edge node, i.e., to the microcontroller 320 of the host computer. The data path (arrow 350) between the diagnostic terminal 342 and the DoIP edge node (the host computer's microcontroller 320) can be seen in fig. 4. Arrow 350 thus illustrates the flow of data traffic in both directions between tester 340 and microcontroller 320 of the host computer. When tester 340 wants to communicate with host computer's microcontroller 320 via DoIP, data is passed from tester 340 up to switch CPU304 at a certain or some switch terminal, and switch CPU304 has a firewall that verifies whether the packet is allowed. When the packet is allowed, then switch CPU304 directs the packet to the terminal to which the host computer's microcontroller 320 is connected. On the way back from the host computer's microcontroller 320, the host computer's microcontroller 320 is always considered a fully trusted source, so the data packets do not have to be directed through the firewall and can be directed directly to the tester 340, rather than through the switch CPU 304.
In this figure, arrow 360 additionally designates data traffic from all VLANs to the internal CPU via the 2GBit interface so that decisions can be made regarding firewall and steering or routing. The first double arrow marks the standard data sequence, the second double arrow 364 marks the data sequence for maintenance and updating, and the third double arrow 364 marks the DoIP data packet sequence.
What is to be considered is: the ethernet switch has a MAC address table (MAC: mediaaccess address), also called an address translation table (ATU), which contains a MAC address and a terminal number. The switch follows a simple algorithm in order to forward the data packet. The MAC address is here a hardware address that serves as a unique identifier for a device in the network.
When a frame is received, the switch compares the source MAC address to a MAC address table. When the source is unknown, the switch adds the source to the table with the numbering of the following terminals: the data packet has been received at the terminal. In this way, the switch learns the MAC address and terminal for each transmitting component.
The switch then compares the destination MAC address to the table. When there is an entry, the switch forwards the frame from the associated terminal; when there is no entry, the switch sends the packet to all terminals except to the terminal from which the frame has been received, which is called flooding.
In a standard ethernet switch, the ATU database is commonly used by all switch terminals. This means that when an attacker sends multiple erroneous MAC addresses to the diagnostic terminal, the attacker will completely overwrite the MAC table database. This would incur unpredictable situations in the vehicle network whose communication network is compromised.
In an intelligent ethernet switch, the ATU database is not common, but there is a separate ATU database for each terminal. In this way it is ensured that when an attacker sends a wrong MAC address to a diagnostic terminal, only that diagnostic terminal is involved. The further communication terminals are completely unaffected by them and the vehicle communication proceeds further as hitherto. This feature is used in the presented security diagnostic solution.
Terminal-based rate limiting (Ratenbegrenzung) can be implemented as a user-limited speed at which network traffic is sent or received by: the components are connected to terminals on the intelligent switch. Unlike in 802.1P quality of service (QoS), terminal-based rate limiting does not prioritize information based on this type. 802.1p is an IEEE standard for quality of service in ethernet traffic. This enables a user to be assigned a high priority to several data packets and a low priority to further data packets. The packets are then correspondingly processed through the switch. Rate limiting simply means: the switch slows down traffic on the terminals in order to prevent the traffic from exceeding a predefined limit. When the rate limit on the terminal is set too small, degraded video stream quality, slow reaction time during online activity, and other problems are studied as necessary.
This feature in the switch can be used in order to achieve security at the diagnostic terminals. As part of the DoIP communication step shown in fig. 3, there is the following verification pursued based on the reply prior to generating the secure TLS tunnel: the verification is performed between the DoIP edge node and the tester. There are limited amounts of data as follows: this data volume is transferred between the tester and the DoIP edge node before a secure TLS tunnel has been created. Thus, limiting the rate of the diagnostic terminal to very small speeds, for example to 64KBit/s, instead of 100Mbit/s altogether, may be a safe solution. The rate limiting only has to be sufficient for the initial step. This limits the attacker's ability to use compromised diagnostic terminals and thereby begin transmitting data at very high rates in order to achieve denial of service or the like.
As soon as a secure TLS tunnel has been created between the tester and the DoIP edge node, the host computer's microcontroller notifies the switch CPU: a secure connection tunnel now exists and is interrogated in order to be able to realize data transmission with high bandwidth. After interrogation by the host computer's microcontroller, the switch CPU provides the full communication bandwidth on the diagnostic terminal. When the communication has been performed again, the tunnel is closed. The microcontroller of the host computer queries the switch CPU to reduce the communication bandwidth to a very low speed.
TLS (TransportLayerSecurity) is an encrypted protocol that provides security for communications between network endpoints. The variables described below are the basic variables of TLS that ensure that the tunnel is secure. The tunnel first attempts to ensure data integrity and confidentiality between the two communicating applications. When a connection between a client and a server is secured via TLS, the connection has one or more of the following variables:
the connection is private or secure in that symmetric encryption is used in order to encrypt the transmitted data. A key for symmetric encryption is generated once for each connection and is based on a shared secret that has been negotiated or agreed upon at the beginning of a session, a so-called TLS Handshake (Handshake). The server and client negotiate the following details: which encryption algorithm and which cryptographic key are used before the first data byte is transmitted. The agreement of the shared secret is not only secure (the agreed secret is not accessible to an eavesdropper and is not available, even not to an attacker placed in the middle of the connection), but also reliable (no attacker can modify the communication during the agreement, but is not identified).
The identity of the communicating party may be verified using encryption with a public key. The verification may optionally be set. However, in principle, for one of the parties (typically the server), this authentication should be required.
The connection protects integrity because each transmitted message includes a message integrity check in which a message authentication code is used to prevent undetected loss or change in data upon transmission.
The presented solution protects the vehicle diagnostics at a very high level. All steps of the constructed method can be summarized as follows.
1. A separate or separate communication path is created between the diagnostic terminal and the DoIP edge node, which extends through the firewall. This uses a separate sequence between the switch core and the switch CPU and a separate MAC address table database for each terminal.
2. The bandwidth of the diagnostic terminal is set to a very small access speed so that an attacker cannot send too much data to the terminal.
3. The tester connects with the diagnostic terminal of the switch and attempts to interrogate the connection.
4. For an available connection, the DoIP edge node replies to the tester.
5. The challenge response is presented between the tester and the DoIP edge node and the tester is verified.
6. A secure TLS tunnel for communication is created between the DoIP edge node and the tester.
7. The microcontroller of the host computer interrogates the switch CPU, allocates the full bandwidth to the diagnostic terminal, and thus the switch CPU allocates the full bandwidth to that terminal.
8. The secure diagnostic data communication takes place between the tester and the DoIP edge node with full bandwidth.
9. After the communication ends, the secure TLS tunnel terminates and the host computer's microcontroller queries the switch CPU, again reducing the bandwidth at the diagnostic terminal.
10. Proceed to the second step.
In some embodiments, it may be provided that a TLS tunnel is also established between the tester and the switch CPU when the switch CPU has software that is established for the DoIP communication to the further control device in the vehicle and has a TLS library. In a similar manner, a rate limiting scheme may also be applied thereto.
Claims (9)
1. A method for performing diagnostics in a vehicle, in which method components of the vehicle are accessed via a diagnostic terminal (342) with an external tester (200, 340), wherein the access is made via a gateway (300), the gateway (300) having the diagnostic terminal (342) and a switch (302), wherein the switch (302) comprises a switch core (308) and a switch CPU (304), wherein in the scope of diagnostics data is transmitted to a microcontroller (320) of a host computer and the data is transmitted from the microcontroller (320) of the host computer, wherein in the method a connection is first established between the tester (340) and the diagnostic terminal (342), wherein in this case a reduced data rate for the diagnostic terminal (342) is set by the switch (302) until a secure data tunnel is established between the tester (340) and the diagnostic terminal (342).
2. The method of claim 1, wherein the connection is established between the tester (340) and the switch CPU (304).
3. The method of claim 1 or 2, wherein the switch (302) is notified by the microcontroller (320) of a host computer: a secure data tunnel is established.
4. A method according to claim 1 or 2, wherein the data is additionally directed via a firewall.
5. The method according to claim 1 or 2, wherein the tester (340) presents a query to the diagnostic terminal (342) for a connection query, and the diagnostic terminal (342) sends a response to the tester (340) for this purpose.
6. A method according to claim 1 or 2, wherein a TLS data tunnel is established.
7. The method of claim 1 or 2, wherein the data rate for the diagnostic terminal (342) is again reduced after the diagnosis is ended.
8. A device for performing diagnostics in a vehicle, which device is set up for performing the method according to any one of claims 1 to 7.
9. A machine-readable storage medium having stored thereon a computer program which is set up to implement the method according to any of claims 1 to 7 when the computer program is implemented on a computing unit.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| DE102018202996.2A DE102018202996A1 (en) | 2018-02-28 | 2018-02-28 | Method for performing a diagnosis |
| DE102018202996.2 | 2018-02-28 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN110213221A CN110213221A (en) | 2019-09-06 |
| CN110213221B true CN110213221B (en) | 2023-08-11 |
Family
ID=67550177
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910145088.9A Active CN110213221B (en) | 2018-02-28 | 2019-02-27 | Method for performing diagnostics |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN110213221B (en) |
| DE (1) | DE102018202996A1 (en) |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR20210120287A (en) * | 2020-03-26 | 2021-10-07 | 현대자동차주식회사 | Diagnostic system, and vehicle |
| CN111736578B (en) * | 2020-08-14 | 2020-12-08 | 广州汽车集团股份有限公司 | Dual-CPU controller-based UDS diagnosis method and device |
| CN112821994B (en) * | 2020-12-31 | 2022-05-17 | 武汉光庭信息技术股份有限公司 | UDS response mediation system and method of dual-redundancy ECU |
| CN112859814B (en) * | 2021-01-19 | 2022-08-02 | 英博超算(南京)科技有限公司 | DoIP diagnostic system of heterogeneous platform |
| CN115065699A (en) * | 2022-06-08 | 2022-09-16 | 深圳市元征科技股份有限公司 | Route activation method, device, equipment and medium based on remote diagnosis |
Citations (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2004024531A1 (en) * | 2002-09-13 | 2004-03-25 | Bombardier Transportation Gmbh | Vehicle on-board diagnostic system |
| CN101751033A (en) * | 2008-12-01 | 2010-06-23 | 北京经纬恒润科技有限公司 | Vehicular remote monitoring and diagnosing system and method |
| CN102084304A (en) * | 2008-07-30 | 2011-06-01 | 宝马股份公司 | Method for programming data in at least two control devices of a motor vehicle |
| CN103037321A (en) * | 2011-10-06 | 2013-04-10 | 通用汽车有限责任公司 | Method of communicating with a vehicle having a telematics unit |
| CN104396191A (en) * | 2012-05-16 | 2015-03-04 | 宝马股份公司 | Data logging or stimulation in automotive ethernet networks using the vehicle infrastructure |
| CN105579318A (en) * | 2013-08-29 | 2016-05-11 | 宝马股份公司 | Switching over the mode of a control unit between a diagnostic bus and an external ethernet connection |
| CN106537463A (en) * | 2014-07-11 | 2017-03-22 | 因特鲁斯特公司 | Method and apparatus for providing vehicle security |
| CN206178464U (en) * | 2016-11-04 | 2017-05-17 | 上海迪璞电子科技股份有限公司 | Multi -protocols vehicle diagnostic system based on ARMCortex |
| CN106685985A (en) * | 2017-01-17 | 2017-05-17 | 同济大学 | Vehicle remote diagnosis system and method based on information safety technology |
| CN107472169A (en) * | 2017-07-31 | 2017-12-15 | 北京新能源汽车股份有限公司 | The control system and automobile of electric automobile |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8036788B2 (en) * | 1995-06-07 | 2011-10-11 | Automotive Technologies International, Inc. | Vehicle diagnostic or prognostic message transmission systems and methods |
| US20020150050A1 (en) * | 1999-06-17 | 2002-10-17 | Nathanson Martin D. | Automotive telemetry protocol |
| FR3033429B1 (en) * | 2015-03-04 | 2018-08-03 | Continental Automotive France | MICROCONTROLLER WITH A DIAGNOSTIC MODULE AND METHOD OF ACCESSING THE MODULE OF THE MICROCONTROLLER |
-
2018
- 2018-02-28 DE DE102018202996.2A patent/DE102018202996A1/en active Pending
-
2019
- 2019-02-27 CN CN201910145088.9A patent/CN110213221B/en active Active
Patent Citations (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2004024531A1 (en) * | 2002-09-13 | 2004-03-25 | Bombardier Transportation Gmbh | Vehicle on-board diagnostic system |
| CN102084304A (en) * | 2008-07-30 | 2011-06-01 | 宝马股份公司 | Method for programming data in at least two control devices of a motor vehicle |
| CN101751033A (en) * | 2008-12-01 | 2010-06-23 | 北京经纬恒润科技有限公司 | Vehicular remote monitoring and diagnosing system and method |
| CN103037321A (en) * | 2011-10-06 | 2013-04-10 | 通用汽车有限责任公司 | Method of communicating with a vehicle having a telematics unit |
| CN104396191A (en) * | 2012-05-16 | 2015-03-04 | 宝马股份公司 | Data logging or stimulation in automotive ethernet networks using the vehicle infrastructure |
| CN105579318A (en) * | 2013-08-29 | 2016-05-11 | 宝马股份公司 | Switching over the mode of a control unit between a diagnostic bus and an external ethernet connection |
| CN106537463A (en) * | 2014-07-11 | 2017-03-22 | 因特鲁斯特公司 | Method and apparatus for providing vehicle security |
| CN206178464U (en) * | 2016-11-04 | 2017-05-17 | 上海迪璞电子科技股份有限公司 | Multi -protocols vehicle diagnostic system based on ARMCortex |
| CN106685985A (en) * | 2017-01-17 | 2017-05-17 | 同济大学 | Vehicle remote diagnosis system and method based on information safety technology |
| CN107472169A (en) * | 2017-07-31 | 2017-12-15 | 北京新能源汽车股份有限公司 | The control system and automobile of electric automobile |
Non-Patent Citations (1)
| Title |
|---|
| 基于AUTOSAR标准的以太网诊断通信实现;章鸿滨;徐旭;黄熙;钟再敏;;汽车零部件(01);全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| DE102018202996A1 (en) | 2019-08-29 |
| CN110213221A (en) | 2019-09-06 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110213221B (en) | Method for performing diagnostics | |
| US10630725B2 (en) | Identity-based internet protocol networking | |
| Woo et al. | Can id shuffling technique (cist): Moving target defense strategy for protecting in-vehicle can | |
| CN106375493B (en) | Cross-network communication method and proxy server | |
| US7051365B1 (en) | Method and apparatus for a distributed firewall | |
| US7472414B2 (en) | Method of processing data traffic at a firewall | |
| US8443190B2 (en) | Method for securing a two-way communications channel and device for implementing said method | |
| EP1368726A2 (en) | Apparatus and method for providing secure network communication | |
| WO2010124014A2 (en) | Methods, systems, and computer readable media for maintaining flow affinity to internet protocol security (ipsec) sessions in a load-sharing security gateway | |
| CN111901355A (en) | Authentication method and device | |
| US20230336529A1 (en) | Enhanced privacy preserving access to a vpn service | |
| Agrawal et al. | CAN-FD-Sec: improving security of CAN-FD protocol | |
| KR20220002455A (en) | Improved transmission of data or messages in the vehicle using the SOME/IP communication protocol | |
| CN110892695A (en) | Method, device and computer program product for checking connection parameters of a password-protected communication connection during the establishment of a connection | |
| US10313305B2 (en) | Method of unblocking external computer systems in a computer network infrastructure, distributed computer network having such a computer network infrastructure as well as computer program product | |
| Sahana et al. | Survey on can-bus packet filtering firewall | |
| CN114039812B (en) | Data transmission channel establishment method, device, computer equipment and storage medium | |
| Baldanzi et al. | Analysis of cybersecurity weakness in automotive in-vehicle networking and hardware accelerators for real-time cryptography | |
| Cisco | Configuring IPSec Network Security | |
| EP3979584A1 (en) | Security network of connected vehicle | |
| KR102059150B1 (en) | IPsec VIRTUAL PRIVATE NETWORK SYSTEM | |
| Kleberger et al. | Securing vehicle diagnostics in repair shops | |
| US20080059788A1 (en) | Secure electronic communications pathway | |
| Luo et al. | Routing and security mechanisms design for automotive tsn/can fd security gateway | |
| KR20170084778A (en) | System for Protecting Server using Authenticated Server Relay Server, and Method there of |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |