Control method and system based on UDS, software and storage medium

Abstract

The invention provides a UDS-based control method and system, software and a storage medium, the control method supports online operation or offline operation, and the control method specifically comprises the steps that when a first program instruction is called, a data reading function is executed according to a subroutine in the first program instruction; when a second program instruction is called, executing a system debugging function according to a subroutine in the second program instruction; wherein the first program instruction and the second program instruction comprise self-defined service identifiers SID in the UDS protocol. By customizing the service identifier which is not defined in the UDS, external debugging interfaces such as a USB (Universal Serial Bus) and a serial port do not need to be externally connected, so that related employees can collect the log information of vehicle operation and the system state information online or offline; related employees can debug the vehicle system online or offline.

Description

Technical Field

[0001] The present application relates to the field of intelligent vehicle technology, and in particular to a UDS-based control method, system, software and storage medium. Background Art

[0002] With the rapid development of automotive electrification, the complexity and functionality of automotive electronic control units (ECUs) have increased significantly, which has brought higher safety requirements and more complex development and debugging tasks.

[0003] Automotive ECUs are responsible for managing a variety of functions, such as engine control, braking systems, in-car entertainment, etc. As technology develops, ECUs are becoming more and more complex, integrating more and more functional modules and algorithms. This complexity makes ECU development and debugging more difficult, as the number of variables and scenarios that developers need to deal with increases significantly.

[0004] Many ECUs are installed in a closed environment inside the vehicle, which makes it impossible to directly connect to external debugging interfaces (such as USB or serial ports). Although this design enhances the security and protection of the system, it also limits the debugging and troubleshooting capabilities of developers. Without direct access to external devices, developers need to rely on the on-board diagnostic system and built-in logging functions for debugging and problem solving.

[0005] Unified Diagnostic Service (UDS) is a standard protocol for automotive ECU diagnosis and debugging. Although UDS provides diagnostic service IDs (SIDs), the actual available service IDs may be limited. For example, SID 0x31 is usually used to read fault codes. For developers, these standard service IDs may not meet all debugging and development needs, especially when in-depth analysis and fault location are required.

[0006] In traditional log systems, data usually needs to be exported from the ECU to a PC for parsing and analysis. Although this method is effective, it has the following problems:

[0007] Poor real-time performance: Log data needs to be exported and transferred to the PC, which cannot reflect the operating status of the ECU in real time.

[0008] Large data volume: Large amounts of log data may lead to storage and processing challenges.

[0009] Complex analysis: Parsing log data requires professional tools and techniques, which increases the complexity of analysis. Summary of the invention

[0010] To solve the above technical problems, this application proposes a control method, system, software and storage medium based on UDS. The system designed in this scheme can monitor the operating status of ECU online in real time, and perform interactive breakpoint debugging and data breakpoint monitoring debugging.

[0011] In a first aspect, the present application proposes a control method based on UDS, the control method supports online operation or offline operation, specifically including:

[0012] When the first program instruction is called, the data reading function is executed according to the subroutine in the first program instruction.

[0013] When the second program instruction is called, the system debugging function is executed according to the subroutine in the second program instruction.

[0014] The first program instruction and the second program instruction include a custom service identifier SID in the UDS protocol.

[0015] ECUs are usually installed in a closed manner inside vehicles and cannot be connected to external debugging interfaces such as USB and serial ports. Although this design enhances the security and protection of the system, it also limits the debugging and troubleshooting capabilities of developers. This application uses a service identifier not defined in the custom UDS protocol to achieve ECU debugging and troubleshooting through UDS without disassembling the device.

[0016] Further, executing the data reading function according to the subroutine in the first program instruction includes:

[0017] The first program instruction is loaded, and a subroutine in the first program instruction is obtained.

[0018] The subroutine is executed to access the specified data source according to the user-defined subroutine parameters.

[0019] Read the corresponding data content from the specified data source.

[0020] Furthermore, the customized subroutine parameters include: data source information, read address, read data length and read data type.

[0021] Furthermore, before loading the first program instruction and obtaining the subroutine in the first program instruction, the method further includes:

[0022] The vehicle system collects data and information generated during the operation of the vehicle.

[0023] The vehicle system will collect data information generated during the operation of the vehicle. This data information is very important for vehicle maintenance, fault diagnosis and performance optimization. This application defines a service identifier that is not defined in any UDS as a first program instruction. The offline host computer or cloud server sends the first program instruction to the control system to obtain the data information. There is no need to transmit the data information to the PC for parsing and analysis. This method can timely reflect the operating status of the ECU, store more data information, and reduce the complexity of data information analysis.

[0024] Further, the performing of the system debugging function according to the subroutine in the second program instruction includes:

[0025] The second program instruction is loaded to obtain a subroutine in the second program instruction.

[0026] Load debugging environment parameters.

[0027] The parameters required for debugging the target task are passed to the subroutine, the subroutine is executed, the target system is debugged, and the debugging result is returned.

[0028] Furthermore, the system debugging function is implemented based on UDS and Debug monitor exception function of ARM Cortex R, specifically including: hardware debugging, software debugging and data monitoring;

[0029] After the control system receives the second program instruction sent by the offline upper device or the cloud server, the control system performs hardware debugging, software debugging or data monitoring on the vehicle system;

[0030] Furthermore, the environmental parameters include log level, debugging target, debugging interface and storage path of debugging log.

[0031] Furthermore, the method of passing the parameters required for debugging the target task to the subroutine includes:

[0032] When the target task is hardware debugging, the parameters required for the target task debugging include: hardware interface parameters, hardware breakpoint addresses, and hardware debugging tool types.

[0033] When the target task is software debugging, the parameters required for the target task debugging include: software breakpoint address, target program, interrupt instruction and software debugging tool type.

[0034] Furthermore, the method of passing the parameters required for debugging the target task to the subroutine further includes:

[0035] When the target task is data breakpoint monitoring, the parameters required for debugging the target task include: the function call path at the breakpoint, the system register value, the system operation information, and the current state parameters of the GPIO pins in the ECU.

[0036] By defining any undefined service identifier in UDS as the second program instruction and combining it with the Debug monitor exception function of ARM CortexR, FPB hardware breakpoint debugging, BKPT software breakpoint debugging and DWT data monitoring breakpoint debugging can be implemented online or offline, and external debugging interfaces such as USB and serial port cannot be connected.

[0037] In a second aspect, the present application also proposes a control system based on UDS, the system comprising:

[0038] The program loading unit is used to load the first program instruction or the second program instruction.

[0039] The data capture unit reads corresponding data content from a specified data source when the first program instruction is called.

[0040] A system debugging unit, when the second program instruction is called, executes a corresponding debugging task according to the subroutine in the second program instruction; the debugging task includes hardware debugging, software debugging and data breakpoint monitoring.

[0041] The first program instruction and the second program instruction are configured based on a service identifier that is not defined in the UDS protocol.

[0042] The control system is integrated on the vehicle domain controller and can be connected to the cloud server and the offline host computer through the vehicle domain controller.

[0043] The UDS-based control system proposed in the present application sets a first program instruction and a second program instruction based on a service identifier not defined in the UDS protocol, which can effectively achieve:

[0044] ECU online and offline log system; online and offline system information collection; online and offline system breakpoint debugging and data breakpoint monitoring debugging.

[0045] The third invention, the present application proposes a customized UDS program software, and the UDS program software is the program instructions in the UDS-based control method described in the first aspect.

[0046] In the fourth aspect, based on the same inventive concept, the present application also proposes a computer-readable storage medium, which stores computer-executable instructions, and is characterized in that when the computer-executable instructions are executed by the control processor, the control method of the UDS-based control system as described in the second aspect is implemented.

[0047] In summary, the present application proposes a control method, system, software and storage medium based on UDS. The present application proposes a control method, system, software and storage medium based on UDS. The control method supports online operation or offline operation, specifically including: when a first program instruction is called, a data reading function is executed according to a subroutine in the first program instruction; when a second program instruction is called, a system debugging function is executed according to a subroutine in the second program instruction;

[0048] The first program instruction and the second program instruction include a custom service identifier SID in the UDS protocol. By customizing a service identifier not defined in the UDS, it is possible to enable relevant practitioners to collect vehicle operation log information and system status information online or offline without the need for an external debugging interface such as a USB or serial port; and to enable relevant practitioners to debug the vehicle system online or offline.

[0049] Compared with the prior art, this application has at least the following beneficial effects:

[0050] By customizing service identifiers that are not defined in UDS, it is possible to eliminate the need for external debugging interfaces such as USB and serial ports, and to enable relevant practitioners to collect vehicle operation log information and system status information online or offline; it allows relevant practitioners to debug vehicle systems online or offline, greatly facilitating the troubleshooting of vehicle problems and reducing the time for troubleshooting important probabilistic problems, achieving the advantage of a low-cost solution with a multi-functional console for difficult analysis, improving the timeliness of solving low-probability problems, and thereby improving customer satisfaction. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] Figure 1 It is a schematic diagram of the transmission of vehicle data shown in an embodiment of the present application.

[0052] Figure 2 It is a schematic diagram of the control system of the UDS shown in the embodiment of the present application.

[0053] Figure 3 It is a schematic diagram of a vehicle-mounted domain control system shown in an embodiment of the present application. DETAILED DESCRIPTION

[0054] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0055] Embodiment 1:

[0056] This application proposes a control method based on UDS, which supports online operation or offline operation, specifically including:

[0057] When the first program instruction is called, the data reading function is executed according to the subroutine in the first program instruction.

[0058] When the second program instruction is called, the system debugging function is executed according to the subroutine in the second program instruction.

[0059] The first program instruction and the second program instruction include a custom service identifier SID in the UDS protocol.

[0060] In an embodiment of the present invention, optionally, when the control system receives the first program instruction, it outputs log information to an offline host device or a cloud server or outputs system status information to an offline host device or a cloud server.

[0061] When the control system receives the second program instruction, it executes vehicle system debugging.

[0062] The first program instruction and the second program instruction are configured based on a service identifier that is not defined in the UDS protocol.

[0063] ECUs are usually installed in a closed manner inside vehicles and cannot be connected to external debugging interfaces such as USB and serial ports. Although this design enhances the security and protection of the system, it also limits the debugging and troubleshooting capabilities of developers. This application uses a service identifier not defined in the custom UDS protocol to achieve ECU debugging and troubleshooting through UDS without disassembling the device.

[0064] Further, executing the data reading function according to the subroutine in the first program instruction includes:

[0065] The first program instruction is loaded, and a subroutine in the first program instruction is obtained.

[0066] The subroutine is executed to access the specified data source according to the user-defined subroutine parameters.

[0067] Read the corresponding data content from the specified data source.

[0068] Furthermore, the customized subroutine parameters include: data source information, read address, read data length and read data type.

[0069] In the embodiment of the present invention, optionally, log output, system status information collection, and system debugging services are implemented through a custom diagnostic routine service subroutine.

[0070] The subroutine SID is a SID that is not defined in the UDS, for example, any one of 0x82-0x82, 0x89-0xB9, 0xBF-0xC2, and 0xC9-0xF9 is acceptable.

[0071] For example:

[0072] Log and SysInfo

[0073]

[0074] System debugging

[0075]

[0076]

[0077] In the embodiment of the present invention, optionally, before outputting the log information to the offline host device or the cloud server, the method further includes:

[0078] The vehicle system collects log information generated during vehicle operation.

[0079] After receiving the first program instruction sent by the offline host device or the cloud server, the control system outputs the log information to the offline host device or the cloud server.

[0080] The vehicle system will collect log information generated during the operation of the vehicle. This log information is very important for vehicle maintenance, fault diagnosis and performance optimization. This application defines a service identifier + Log that is not defined in any UDS as the first processing instruction. The offline host computer or cloud server sends the instruction to the control system to obtain the log information. There is no need to transmit the log information to the PC for parsing and analysis. This method can timely reflect the operating status of the ECU, store more log information, and reduce the complexity of log information analysis.

[0081] As a preferred embodiment, the first program instruction may be: 31 01A8 "log", and the specific implementation process is as follows:

[0082] Host computer sends: 31 01A8 "log"

[0083] After the ECU finishes executing, it replies: 71 01A8 "Log:\n CtApSwc check warning\n freertos memorylow\n..."

[0084] Log information acquisition is complete.

[0085] In the embodiment of the present invention, optionally, before outputting the system status information to the offline upper device or the cloud server, the method further includes:

[0086] The vehicle system collects system status information generated during vehicle operation.

[0087] After receiving the first program instruction sent by the offline host device or the cloud server, the control system outputs the system status information to the offline host device or the cloud server.

[0088] The vehicle system will collect system status information generated during the operation of the vehicle. This system status information is very important for vehicle maintenance, fault diagnosis and performance optimization. This application defines a service identifier + SysInfo that is not defined in any UDS as the second processing instruction. The offline host computer or cloud server sends the instruction to the control system to obtain the system status information. There is no need to transmit the system status information to the PC for parsing and analysis. This method can timely reflect the operating status of the ECU, store more system status information, and reduce the complexity of system status information analysis.

[0089] As a preferred embodiment, the first program instruction may be: 31 01A8 "log", and the specific implementation process is as follows:

[0090] Host computer sends: 31 01A8 "SysInfo"

[0091] After the ECU finishes executing, it replies: 71 01A8 "SysInfo:\n Cpu Loading 98%\n Memory Usage325Kbit\n..."

[0092] The system status information has been obtained.

[0093] In the embodiment of the present invention, optionally, the debugging method is implemented based on UDS and Debugmonitor exception functions of ARM Cortex R, specifically including: hardware debugging, software debugging and data monitoring.

[0094] After the control system receives the second program instruction sent by the offline host device or the cloud server, the control system performs hardware debugging, software debugging or data monitoring on the vehicle system.

[0095] In the embodiment of the present invention, optionally, executing the system debugging function according to the subroutine in the second program instruction includes:

[0096] The second program instruction is loaded to obtain a subroutine in the second program instruction.

[0097] Load debugging environment parameters.

[0098] The parameters required for debugging the target task are passed to the subroutine, the subroutine is executed, the target system is debugged, and the debugging result is returned.

[0099] In the embodiment of the present invention, optionally, the environment parameters include a log level, a debugging target, a debugging interface, and a storage path of the debugging log.

[0100] In the embodiment of the present invention, optionally, the passing of parameters required for debugging the target task to the subroutine includes:

[0101] When the target task is hardware debugging, the parameters required for the target task debugging include: hardware interface parameters, hardware breakpoint addresses, and hardware debugging tool types.

[0102] When the target task is software debugging, the parameters required for the target task debugging include: software breakpoint address, target program, interrupt instruction and software debugging tool type.

[0103] In the embodiment of the present invention, optionally, the transferring of parameters required for debugging the target task to the subroutine further includes:

[0104] When the target task is data breakpoint monitoring, the parameters required for debugging the target task include: the function call path at the breakpoint, the system register value, the system operation information, and the current state parameters of the GPIO pins in the ECU.

[0105] In an embodiment of the present invention, optionally, by defining a service identifier that is not defined in any UDS + hardware debugging, software debugging or data monitoring + debugging address + execution operation, and combining the Debug monitor exception function of ARM Cortex R, FPB hardware breakpoint debugging, BKPT software breakpoint debugging and DWT data monitoring breakpoint debugging can be implemented online or offline, and an external debugging interface such as USB or serial port cannot be connected.

[0106] As a preferred embodiment, the system debugging function implements UDS breakpoint debugging and data breakpoint monitoring debugging functions through custom diagnostic routine services (UDSSID 0x31) and ARMCortex R's Debug monitor exception mode, including FPB hardware breakpoint debugging, BKPT software breakpoint debugging, and DWT data monitoring breakpoint debugging.

[0107] When a serious system failure occurs in a remote vehicle, breakpoints such as FPB, BKPT, and DWT can be set through the cloud. Without shutting down the ECU, the ECU system can be remotely debugged and the operation of the ECU system can be monitored to quickly and accurately locate the system failure.

[0108] As a preferred embodiment, FPB hardware breakpoint debugging includes:

[0109] The host computer sends: 31 01A9 "FPB" addr0 addr1 addr2 addr3 "[action = backtrace, dumpregs, sysinfo, iostate, autocontinue]"

[0110] The ECU receives the instruction and sets the FPB breakpoint and the action item after hitting the breakpoint in the remote multi-function console service program.

[0111] 1. Read the DBGDSCR register and check DBGDSCR

[14] ! = 1 (1 enables stop mode, 0 disables stop mode).

[0112] 2. Set DBGDSCR

[15] = 1 to enable monitor mode.

[0113] 3. Set the FPB breakpoint register, DBGBVR0-DBGBVR7, a total of 8 hardware breakpoint registers; set DBGBVR0 = addr[0..3].

[0114] 4. Set the DBGBCR register to enable the FPB breakpoint. Each DBGBVR register corresponds to a DBGBCR register. Set DBGBCR0[0] = 1 to enable the FPB breakpoint set in 4.

[0115] 5. When the ECU runs to the set address, the PC register is compared with the DBGBVR0 register. If they are equal, a Debug Exception is triggered.

[0116] 6.ECU enters the DebugException handler.

[0117] 7. The DebugException handler reads the DBGDSCR register and determines that DBGDSCR[15:14] == b10, indicating that the current exception is a Debug Monitor exception.

[0118] 8. The DebugException handler reads the DBGBCR register and determines that DBGBCR[22:20] == b000 (instruction address hit).

[0119] 9. The DebugException exception handler records the above status and passes it to the remote multi-function console service program, and at the same time dispatches the system to the remote multi-function console service program.

[0120] 10. The remote multi-function console service program performs the corresponding operation according to the action parameters sent by the host computer:

[0121] backtrace: Output the function call path at the breakpoint.

[0122] dumpregs: Output the system register values ​​at the breakpoint.

[0123] sysinfo: Outputs system operation information at breakpoints.

[0124] iostate: Output ECU gpio status at breakpoint.

[0125] 11.ECU replies after execution: 71 01A9 "FPB:\n Instruction Address Match Withxxxxxxxx\nbacktrace:...\n System Regs:...\n SysInfo:...\n iostate:...\nWaiting for next Operator: Continue / SetDataValue / WatchDataAddress".

[0126] 12. After the host computer receives the information, if there is autocontinue in the action, the ECU will automatically execute the program; otherwise, it can send instructions.

[0127] 31 01A9 "FPB Continue" continues to execute the instruction, and the ECU executes further.

[0128] 31 01A9 "FPB SetDataValue" DataAddr DataValue DataLen ECU changes the data at the specified address and then continues execution.

[0129] 31 01A9 "FPB WatchDataAddress" DataAddr ECU obtains the data value of the specified address and outputs it to the host computer, and continues to execute.

[0130] The ECU performs the above operations and then outputs.

[0131] 71 01A9 "FPB:Continue,Set / WatchData Successful: DataValue".

[0132] As a preferred embodiment, BKPT software breakpoint debugging includes:

[0133] The host computer sends: 31 01A9 "BKPT" addr0 addr1 addr2 addr3 "[action = backtrace, dumpregs, sysinfo, iostate, autocontinue]"

[0134] The ECU receives the instruction and sets the BKPT breakpoint and the action item after hitting the breakpoint in the remote multi-function console service program.

[0135] 1. Read the DBGDSCR register and check DBGDSCR

[14] ! = 1 (1 enables stop mode, 0 disables stop mode).

[0136] 2. Set DBGDSCR

[15] = 1 to enable monitor mode.

[0137] 3. Read the value of the addr[3:0] memory address and save it to BKPTInstruction.

[0138] 4. Change the instruction of the addr[3:0] memory address to the BKPT instruction.

[0139] 5. When the ECU runs to the set address, the PC register triggers a DebugException because it is loaded with the BKPT instruction.

[0140] 6.ECU enters the DebugException handler.

[0141] 7. The DebugException exception handler reads the DBGDSCR register and determines that DBGDSCR[5:2] == b001, indicating that the current exception is a Debug Monitor exception.

[0142] 8. The DebugException handler reads the DBGDSCR register and determines that DBGDSCR[5:2]==b0011 indicates a BKPT exception.

[0143] 9. The DebugException exception handler records the above status and passes it to the remote multi-function console service program, and at the same time dispatches the system to the remote multi-function console service program.

[0144] 10. The remote multi-function console service program performs corresponding operations according to the action parameters sent by the host computer.

[0145] backtrace: Output the function call path at the breakpoint.

[0146] dumpregs: Output the system register values ​​at the breakpoint.

[0147] sysinfo: Outputs system operation information at breakpoints.

[0148] iostate: Output ECU gpio status at breakpoint.

[0149] 11.ECU replies after execution: 71 01A9 "BKPT:\n Instruction Address Match Withxxxxxxxx\nbacktrace:...\n System Regs:...\n SysInfo:...\n iostate:...\nWaiting for next Operator: Continue / SetDataValue / WatchDataAddress".

[0150] 12. After the host computer receives the information, if there is autocontinue in the action, the ECU will automatically execute the program; otherwise, it can send instructions.

[0151] 31 01A9 "BKPT Continue" continues to execute the instruction, and the ECU executes further.

[0152] 31 01A9 "BKPT SetDataValue" DataAddr DataValue DataLen ECU changes the data at the specified address and then continues execution.

[0153] 31 01A9 "BKPT WatchDataAddress" DataAddr ECU obtains the data value of the specified address and outputs it to the host computer, and continues to execute.

[0154] The ECU performs the above operations and then outputs.

[0155] 71 01A9 "BKPT:Continue,Set / WatchData Successful: DataValue".

[0156] As a preferred embodiment, DWT data monitoring breakpoint debugging includes:

[0157] The host computer sends: 31 01A9 "DWT" addr0 addr1 addr2 addr3 "[action = backtrace, dumpregs, sysinfo, iostate, autocontinue]"

[0158] The ECU receives the instruction and sets the FPB breakpoint and the action item after hitting the breakpoint in the remote multi-function console service program.

[0159] 1. Read the DBGDSCR register and check DBGDSCR

[14] ! = 1 (1 enables stop mode, 0 disables stop mode).

[0160] 2. Set DBGDSCR

[15] = 1 to enable monitor mode.

[0161] 3. Set the DWT breakpoint register, DBGDSWVR0-DBGDSWVR7, there are 8 hardware breakpoint registers in total, set DBGDSWVR0 = addr[0..3].

[0162] 4. Set the DBGWCR register to enable the DWT breakpoint. Each DBGDSWVR register corresponds to a DBGWCR register. Set DBGWCR0[0]=1 to enable the DWT breakpoint set in 4.

[0163] 5. When the ECU runs the data loading instruction to access the specified address, the data address bus is compared with the DBGDSWVR0 register. If they are equal, a Debug Exception is triggered.

[0164] 6.ECU enters the DebugException handler.

[0165] 7. The DebugException handler reads the DBGDSCR register and determines that DBGDSCR[15:14] == b10, indicating that the current exception is a Debug Monitor exception.

[0166] 8. The DebugException handler reads the DBGBCR register and determines that DBGDSWVR[22:20] == b000 (instruction address hit).

[0167] 9. The DebugException exception handler records the above status and passes it to the remote multi-function console service program, and at the same time dispatches the system to the remote multi-function console service program.

[0168] 10. The remote multi-function console service program performs the corresponding operation according to the action parameters sent by the host computer:

[0169] backtrace: Output the function call path at the breakpoint.

[0170] dumpregs: Output the system register values ​​at the breakpoint.

[0171] sysinfo: Outputs system operation information at breakpoints.

[0172] iostate: Output ECU gpio status at breakpoint.

[0173] 11.ECU replies after execution: 71 01A9 "DWT:\n Instruction Address Match Withxxxxxxxx\nbacktrace:...\n System Regs:...\n SysInfo:...\n iostate:...\nWaiting for next Operator: Continue / SetDataValue / WatchDataAddress".

[0174] 12. After the host computer receives the information, if there is autocontinue in the action, the ECU will automatically execute the program; otherwise, it can send instructions.

[0175] 31 01A9 "DWT Continue" continues to execute the instruction, and the ECU executes further.

[0176] 31 01A9 “DWT SetDataValue” DataAddr DataValue DataLen ECU changes the data at the specified address and then continues execution.

[0177] 31 01A9 "DWT WatchDataAddress" DataAddr ECU obtains the data value of the specified address and outputs it to the host computer, and continues to execute.

[0178] The ECU performs the above operations and then outputs.

[0179] 71 01A9 "DWT:Continue,Set / WatchData Successful: DataValue".

[0180] In the embodiment of the present invention, optionally, as shown in the attached Figure 1 As shown, the control system can be integrated on the vehicle domain controller, and connected to the TSP cloud server through the vehicle domain controller domain as a transit gateway. The vehicle domain controller transparently transmits console instructions through the TCP protocol to realize the information collection between the TSP cloud server and the remote hardware-in-the-loop ECU.

[0181] For example:

[0182] 1. TSP cloud server connects to the control system in the vehicle domain controller:

[0183] TSP->Vehicle domain controller: TCP Connect domain controller IP address multi-function console port number.

[0184] On-board domain controller->TSP:SYNC+ACK OK.

[0185] 2. The TSP cloud server sends instructions to the control system in the vehicle domain controller:

[0186] TSP->vehicle domain controller: TCP header + "control system instructions".

[0187] For example, query the TCP header +31 01A8 "log" of events supported by ECU.

[0188] 3. The control system in the vehicle domain controller forwards the command to the ECU:

[0189] On-board domain controller -> ECU: control system instructions (extract instructions).

[0190] For example, query the log 31 01A8 "log" supported by the ECU.

[0191] 4.ECU performs operations:

[0192] After the ECU finishes executing, it replies: 71 01A8 "Log:\n CtApSwc check warning\n freertos memorylow\n..."

[0193] 5. The vehicle domain controller receives the response from the ECU and transparently transmits it to the TSP cloud server:

[0194] On-board domain controller->TSP: TCP header + reply content

[0195] For example, query the events supported by ECU TCPs header +71 01A8 "Log:\n CtApSwc check warning\nfreertos memory low\n..."

[0196] 6. TSP cloud server extracts the received reply information

[0197] The extracted information can be displayed to the screen:

[0198] Desv Console:

[0199] log

[0200] >

[0201] Or recorded in a database.

[0202] When a vehicle fails remotely (for example, the vehicle stalls remotely, has power system problems, etc.), log information output can be triggered on the TSP platform to automatically collect the operating status information of the faulty vehicle.

[0203] Embodiment 2:

[0204] As attached Figure 2 As shown, the system comprises:

[0205] The program loading unit is used to load the first program instruction or the second program instruction.

[0206] The data capture unit reads corresponding data content from a specified data source when the first program instruction is called.

[0207] A system debugging unit, when the second program instruction is called, executes a corresponding debugging task according to the subroutine in the second program instruction; the debugging task includes hardware debugging, software debugging and data breakpoint monitoring.

[0208] The first program instruction and the second program instruction are configured based on a service identifier that is not defined in the UDS protocol.

[0209] The control system is integrated on the vehicle-mounted domain controller and can be connected to the cloud server and the offline host computer through the vehicle-mounted domain controller.

[0210] The vehicle domain controller (Domain Controller) is a control unit specifically used for automotive electronic systems, responsible for coordinating and managing various electronic functions in the car. As a preferred embodiment, the vehicle domain controller can be interconnected and coordinated through communication protocols such as CAN bus, LIN bus, Ethernet, etc. to achieve integration and optimization of vehicle electronic systems.

[0211] In the embodiment of the present invention, optionally, as shown in the attached Figure 3 As shown, the vehicle-mounted domain controller includes: a gateway connection module, a central control screen and an OBD port.

[0212] Wherein, the gateway connection module is respectively connected to the central control screen and the OBD port via a CAN bus.

[0213] The control system is integrated on a vehicle-mounted domain controller, which includes a gateway connection module, a central control screen and an OBD port. Through this design method, the control system can realize online or offline execution of vehicle-mounted diagnostic services through the vehicle-mounted domain controller.

[0214] As a preferred embodiment, the gateway connection module is also connected to the control system via a CAN bus.

[0215] As a preferred embodiment, the gateway module includes a hardware component and a software component.

[0216] The hardware components include:

[0217] Processor / Microcontroller:

[0218] Responsible for executing the software of the gateway module and processing data flow. Usually a high-performance processor to ensure processing speed and data transmission efficiency.

[0219] Communication interface:

[0220] Including different types of bus interfaces, such as CAN (Controller Area Network), LIN (Local Interconnect Network), Ethernet, etc. The gateway module needs to support various protocols to achieve interconnection between different systems.

[0221] Memory:

[0222] Includes RAM (Random Access Memory) and Flash storage for storing operating systems, applications, configuration data, and log information.

[0223] Power Management Unit:

[0224] Responsible for providing stable power and protecting the gateway module from power fluctuations.

[0225] The software components include:

[0226] Communication protocol stack:

[0227] Realize the support and conversion of different communication protocols, such as CAN protocol stack, LIN protocol stack, Ethernet protocol stack, etc. This protocol stack is responsible for the encoding, decoding and transmission of data.

[0228] middleware:

[0229] Provides high-level communication services and functions to help simplify the communication process between different ECUs.

[0230] Application layer software:

[0231] Includes applications for specific functions, such as message routing, data filtering, protocol conversion, etc. It is responsible for implementing the core functions of the gateway module, such as data exchange and protocol conversion.

[0232] Configuration and management tools:

[0233] Used to configure gateway module parameters and management functions, usually including diagnostic and debugging tools.

[0234] The gateway module further comprises:

[0235] Physical interface:

[0236] Provides connections to in-vehicle buses and networks, such as CAN connectors, LIN connectors, Ethernet ports, etc.

[0237] Network Interface:

[0238] Supports the connection between the in-vehicle network and the external communication network to ensure smooth data transmission.

[0239] As a preferred embodiment, the gateway connection module is also remotely connected to the cloud server via a wireless network.

[0240] Through this system design, the control system can be indirectly connected to the cloud server through the vehicle-mounted domain controller to realize online execution of vehicle-mounted diagnostic services.

[0241] In the embodiment of the present invention, optionally, the OBD port is connected to an offline upper device via a wiring harness.

[0242] Through this system design, the control system can indirectly connect to the offline host device through the vehicle-mounted domain controller to achieve offline reception of control instructions transmitted by the offline host device.

[0243] As a preferred embodiment, the OBD port includes:

[0244] OBD-I:

[0245] This is an early OBD standard with basic functions. It is mainly used to read and clear fault codes and usually only supports basic vehicle data.

[0246] OBD-II:

[0247] It has been a standard since 1996. Compared with OBD-I, OBD-II provides more detailed fault codes and real-time data, and supports multiple communication protocols, such as ISO 9141, ISO 14230 (KWP2000), ISO 15765 (CAN), etc.

[0248] In the embodiment of the present invention, optionally, the control system uses OBD-II, and the specific functions of the OBD-II are:

[0249] Fault code reading:

[0250] Through the OBD port, the diagnostic tool can read fault codes (DTCs), which are codes that indicate problems or malfunctions in the vehicle's systems.

[0251] Real-time data monitoring:

[0252] Various sensor data of the vehicle can be monitored in real time, such as engine speed, vehicle speed, fuel consumption, etc.

[0253] To perform diagnostic tests:

[0254] Allows the user to perform various tests and checks such as sensor test, system test, etc.

[0255] Clear fault codes:

[0256] When the fault is repaired, the fault code can be cleared through the OBD port and the vehicle's fault indicator light can be reset.

[0257] In the embodiment of the present invention, optionally, the offline host device may be a cutting tool or a scanner.

[0258] The vehicle's diagnostic information can be accessed through a diagnostic tool or scanner connected to the OBD port. There are many different types of diagnostic tools on the market, from simple trouble code readers to advanced diagnostic equipment.

[0259] app:

[0260] Some smartphone apps and portable devices can connect to the OBD port via an OBD-II adapter, enabling diagnostic and data monitoring functions.

[0261] Embodiment three:

[0262] The third invention, the present application proposes a customized UDS program software, and the UDS program software is the program instructions in the UDS-based control method described in Example 1.

[0263] Embodiment 4:

[0264] Based on the same inventive concept, the present application also proposes a computer-readable storage medium, which stores computer-executable instructions, and is characterized in that when the computer-executable instructions are executed by the control processor, the control method of the UDS-based control system as described in Example 2 is implemented.

[0265] It should be noted that since the computer-readable storage medium in this embodiment and the assisted driving method in the above embodiment are based on the same inventive concept, the corresponding contents in the method embodiment are also applicable to the system embodiment and will not be described in detail here.

[0266] In the computer-readable storage medium, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be transmitted from a website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website site, computer, server or data center. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integrated. The available medium may be a magnetic medium, (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state hard disk SolidState Disk (SSD)), etc.

[0267] The present application proposes a control method, system, software and storage medium based on UDS, wherein the control method supports online operation or offline operation, and specifically includes: when a first program instruction is called, a data reading function is executed according to a subroutine in the first program instruction; when a second program instruction is called, a system debugging function is executed according to a subroutine in the second program instruction;

[0268] The first program instruction and the second program instruction include a custom service identifier SID in the UDS protocol. By customizing a service identifier not defined in the UDS, it is possible to enable relevant practitioners to collect vehicle operation log information and system status information online or offline without the need for an external debugging interface such as a USB or serial port; and to enable relevant practitioners to debug the vehicle system online or offline.

[0269] By customizing service identifiers that are not defined in UDS, it is possible to eliminate the need for external debugging interfaces such as USB and serial ports, and to enable relevant practitioners to collect vehicle operation log information and system status information online or offline; it allows relevant practitioners to debug vehicle systems online or offline, greatly facilitating the troubleshooting of vehicle problems and reducing the time for troubleshooting important probabilistic problems, achieving the advantage of a low-cost solution with a multi-functional console for difficult analysis, improving the timeliness of solving low-probability problems, and thereby improving customer satisfaction.

[0270] In several embodiments provided in the present application, it is understood that each box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, a program segment or a part of a code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from that marked in the accompanying drawings. For example, two consecutive boxes can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved.

[0271] If the functions are implemented in the form of software function modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application can be essentially or partly embodied in the form of a software product that contributes to the prior art. The computer software product is stored in a storage medium and includes several instructions for enabling an electronic device to perform all or part of the steps of the methods described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0272] The specific embodiments described above further describe the purpose, technical solutions and beneficial effects of the present application in detail. It should be understood that the above description is only a specific embodiment of the present application and is not intended to limit the scope of protection of the present application. It is particularly pointed out that for those skilled in the art, any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of protection of the present application.

Claims

1. A control method based on UDS, characterized in that: The control method supports online operation or offline operation, and specifically includes: When the first program instruction is called, a data reading function is performed according to a subroutine in the first program instruction; When the second program instruction is called, a system debugging function is executed according to a subroutine in the second program instruction; The first program instruction and the second program instruction include a custom service identifier SID in the UDS protocol.

2. The UDS-based control method according to claim 1, characterized in that: The performing of the data reading function according to the subroutine in the first program instruction comprises: Loading the first program instruction, obtaining a subroutine in the first program instruction; Execute the subroutine and access the specified data source according to the customized subroutine parameters; Read the corresponding data content from the specified data source.

3. The UDS-based control method according to claim 2, characterized in that: The user-defined subroutine parameters include: data source information, read address, read data length and read data type.

4. The UDS-based control method according to claim 3, characterized in that: The performing of the system debugging function according to the subroutine in the second program instruction comprises: loading the second program instruction and obtaining a subroutine in the second program instruction; Load debugging environment parameters; The parameters required for debugging the target task are passed to the subroutine, the subroutine is executed, the target system is debugged, and the debugging result is returned.

5. The UDS-based control method according to claim 4, characterized in that: The environment parameters include log level, debugging target, debugging interface and storage path of debugging log.

6. The UDS-based control method according to claim 5, characterized in that: The parameters required for debugging the target task are passed to the subroutine, including: When the target task is hardware debugging, the parameters required for the target task debugging include: hardware interface parameters, hardware breakpoint addresses, and hardware debugging tool types; When the target task is software debugging, the parameters required for the target task debugging include: software breakpoint address, target program, interrupt instruction and software debugging tool type.

7. The UDS-based control method according to claim 5, characterized in that: The method of passing the parameters required for debugging the target task to the subroutine also includes: When the target task is data breakpoint monitoring, the parameters required for debugging the target task include: the function call path at the breakpoint, the system register value, the system operation information, and the current state parameters of the GPIO pins in the ECU.

8. A system based on the UDS control method according to any one of claims 1 to 7, characterized in that: The system comprises: A program loading unit, used for loading the first program instruction or the second program instruction; A data capture unit, which reads corresponding data content from a specified data source when the first program instruction is called; A system debugging unit, when the second program instruction is called, executes a corresponding debugging task according to the subroutine in the second program instruction; the debugging task includes hardware debugging, software debugging and data breakpoint monitoring.

9. A custom UDS program software, characterized in that: The UDS program software is the program instructions in the UDS-based control method described in any one of claims 1-7.

10. A computer-readable storage medium storing computer-executable instructions, characterized in that: When the computer executable instructions are executed by the control processor, the UDS-based control method according to any one of claims 1 to 7 is implemented.

Images