CN116483693A - Vehicle-mounted controller software debugging method and system, electronic equipment and storage medium - Google Patents

Vehicle-mounted controller software debugging method and system, electronic equipment and storage medium Download PDF

Info

Publication number
CN116483693A
CN116483693A CN202310292233.2A CN202310292233A CN116483693A CN 116483693 A CN116483693 A CN 116483693A CN 202310292233 A CN202310292233 A CN 202310292233A CN 116483693 A CN116483693 A CN 116483693A
Authority
CN
China
Prior art keywords
vehicle
mounted controller
debugged
tested
address
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.)
Pending
Application number
CN202310292233.2A
Other languages
Chinese (zh)
Inventor
王均彬
袁正
左健
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Chongqing Changan New Energy Automobile Technology Co Ltd
Original Assignee
Chongqing Changan New Energy Automobile Technology Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Chongqing Changan New Energy Automobile Technology Co Ltd filed Critical Chongqing Changan New Energy Automobile Technology Co Ltd
Priority to CN202310292233.2A priority Critical patent/CN116483693A/en
Publication of CN116483693A publication Critical patent/CN116483693A/en
Pending legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/362Software debugging
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/3668Software testing
    • G06F11/3672Test management
    • G06F11/3688Test management for test execution, e.g. scheduling of test suites
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02PCLIMATE CHANGE MITIGATION TECHNOLOGIES IN THE PRODUCTION OR PROCESSING OF GOODS
    • Y02P90/00Enabling technologies with a potential contribution to greenhouse gas [GHG] emissions mitigation
    • Y02P90/02Total factory control, e.g. smart factories, flexible manufacturing systems [FMS] or integrated manufacturing systems [IMS]

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

The invention provides a method, a system, electronic equipment and a storage medium for debugging software of a vehicle-mounted controller, which are used for directly communicating with the vehicle-mounted controller to be debugged through a preset communication protocol, namely, a service request for processing the address and length information of a variable to be tested is initiated by acquiring the address and length information of the variable to be tested, and a response result of the vehicle-mounted controller is acquired based on the communication protocol corresponding to the service request so as to debug the vehicle-mounted controller to be debugged; according to the invention, the vehicle-mounted controller fixed on the vehicle can be directly subjected to data interaction through the existing communication interface of the vehicle-mounted controller to be debugged without disassembling the vehicle-mounted controller, so that software debugging is realized under the condition that the structure of the vehicle-mounted controller is not changed, convenience and practicability are enhanced, and debugging efficiency is improved.

Description

Vehicle-mounted controller software debugging method and system, electronic equipment and storage medium
Technical Field
The application relates to the field of vehicle-mounted controller software development and debugging, in particular to a vehicle-mounted controller software debugging method and system, electronic equipment and a storage medium.
Background
Along with the rapid development and popularization of new energy automobiles, vehicle-mounted controllers on the new energy automobiles are more and have more and more complex functions, various software problems are inevitably encountered in the development process, and for positioning problem reasons, variables in the vehicle-mounted controller software are observed in real time and displayed to developers in a graphical mode for analysis. The traditional method is that a debugging tool is used for being connected with a special debugging port on a PCB board of the vehicle-mounted controller for debugging, and the method is convenient for debugging in a laboratory environment, because the method can be easily connected with the special debugging port of the vehicle-mounted controller for software debugging. However, the above-described debugging method becomes difficult or even impossible to implement when the in-vehicle controller is mounted on the vehicle. Because the vehicle-mounted controller does not expose a special debugging interface to the shell, the vehicle-mounted controller needs to be subjected to uncovering processing when in software debugging on the vehicle, but the connection of the debugger becomes very difficult due to the fact that the vehicle-mounted controller is arranged on the whole vehicle or because the vehicle-mounted controller is subjected to sealing processing.
A Chinese patent with publication number CN113190454A relates to a vehicle-mounted test method and system for vehicle-mounted terminal software, which belongs to the field of software testing, but not development and debugging, wherein a test upper computer reads CAN bus data and data values reported by a vehicle-mounted terminal in a test platform, and the consistency of the CAN bus data and the data reported by the vehicle-mounted terminal platform is compared after the data are analyzed. Therefore, the patent only can test the function of the software, can not observe and modify the internal variables of the software, and can not achieve the purpose of development and debugging.
Disclosure of Invention
In view of the above drawbacks of the prior art, the present invention provides a software debugging and system for an on-board controller, an electronic device, and a storage medium, so as to solve the above technical problems.
The invention provides a vehicle-mounted controller software debugging method, which comprises the following steps: the vehicle-mounted controller software debugging method comprises the following steps: acquiring address and length information of a variable to be tested; initiating a service request for debugging the variable to be tested; transmitting address and length information of a variable to be tested to a vehicle-mounted controller to be debugged based on a communication protocol corresponding to the service request; determining a debugging result of the vehicle-mounted controller to be debugged according to the response result of the vehicle-mounted controller to be debugged so as to debug the vehicle-mounted controller to be debugged, wherein the response result is feedback after the vehicle-mounted controller receives address and length information of a variable to be tested.
In an embodiment of the present invention, obtaining address and length information of a variable to be tested includes: generating an ELF file, wherein address and length information of variables to be tested are stored in the ELF file; and extracting address and length information of the variable to be tested from the ELF file.
In an embodiment of the present invention, address and length information of variables to be tested are sent to a vehicle-mounted controller to be debugged based on a communication protocol corresponding to the service request, where the service request includes a request for reading target variable data and a request for modifying target variable data, the communication protocol includes a first communication protocol and a second communication protocol, the first communication protocol is a memory service read by a passing address of a unified diagnostic service protocol, and the second communication protocol is a memory service write by a passing address of the unified diagnostic service protocol, including: if the service request is a read target variable data request, the address and length information of the variable to be tested is sent to a vehicle-mounted controller to be debugged through an address read memory service of a unified diagnosis service protocol; and if the service request is a request for modifying the target variable data, transmitting the address and length information of the variable to be tested to the vehicle-mounted controller to be debugged through an address writing memory service of a unified diagnosis service protocol.
In an embodiment of the present invention, a debug result of the on-vehicle controller to be debugged is determined according to a response result of the on-vehicle controller to be debugged, so as to debug the on-vehicle controller to be debugged, where the response result is feedback after the on-vehicle controller receives address and length information of a variable to be tested, and the response result includes a first response result, including: acquiring a first response result of the vehicle-mounted controller to be debugged, wherein the first response result comprises a forward response, a overtime response and a negative response, the forward response is that the vehicle-mounted controller to be debugged searches for variable data to be tested in a memory of the vehicle-mounted controller to be debugged according to the address and the length information of the variable to be tested within a preset time, and the overtime response is that the vehicle-mounted controller to be debugged searches for the variable data to be tested in the memory of the vehicle-mounted controller to be debugged according to the address and the length information of the variable to be tested within the preset time, and the negative response is that the vehicle-mounted controller to be debugged does not search for the variable data to be tested in the memory of the vehicle-mounted controller to be debugged according to the address and the length information of the variable to be debugged within the preset time; and if the first response result is a forward response, determining the received variable data to be tested as target variable data, and displaying the target variable data.
In an embodiment of the present invention, a debug result of the on-vehicle controller to be debugged is determined according to a response result of the on-vehicle controller to be debugged, so as to debug the on-vehicle controller to be debugged, where the response result is feedback after the on-vehicle controller receives address and length information of a variable to be tested, and the response result further includes a second response result, including: acquiring a second response result of the vehicle-mounted controller to be debugged, wherein the second response result comprises a forward response, a timeout response and a negative response; the forward response is that the vehicle-mounted controller to be debugged searches variable data to be tested in a vehicle-mounted controller memory according to variable address and length information to be tested in a preset time, modifies the variable data to be tested into target variable data and sends an execution result; the overtime response is that the to-be-debugged vehicle-mounted controller modifies the variable data to be tested into target variable data within preset time, but does not send an execution result; the negative response is that the to-be-debugged vehicle-mounted controller does not modify variable data to be tested into target variable data within preset time; and if the second response result is a forward response, receiving an execution result, wherein the execution result represents that the vehicle-end vehicle-mounted controller updates the target variable data to the memory address corresponding to the variable to be tested within a preset time.
In an embodiment of the present invention, the method for debugging the vehicle-mounted controller software to be debugged further includes: reading an abnormal log of the vehicle-mounted controller to be debugged through a unified diagnosis protocol, wherein the abnormal log comprises fault information records of abnormal moments of the vehicle-mounted controller to be debugged; and analyzing fault information of the vehicle-mounted controller to be debugged according to the abnormal log.
In an embodiment of the present invention, before obtaining the address and length information of the variable to be tested, the method further includes: the to-be-debugged vehicle-mounted controller is connected through a local communication interface; or, the vehicle-mounted controller to be debugged is remotely connected through the vehicle cloud.
In an embodiment of the present invention, there is provided a software debug system for a vehicle-mounted controller, including: the first acquisition module is configured to acquire address and length information of a variable to be tested; the service initiation module is configured to initiate a service request for debugging the variable to be tested; the sending module is configured to send the address and length information of the variable to be tested to the vehicle-mounted controller to be debugged based on a communication protocol corresponding to the service request; the determining module is configured to determine a debugging result of the vehicle-end vehicle-mounted controller to be debugged according to a response result of the vehicle-mounted controller to be debugged so as to debug the vehicle-mounted controller to be debugged, wherein the response result is feedback after the vehicle-mounted controller receives address and length information of a variable to be tested.
The invention has the beneficial effects that: directly communicating with the vehicle-mounted controller to be debugged through a preset communication protocol, namely, initiating a service request for processing the address and length information of the variable to be tested by acquiring the address and length information of the variable to be tested, and acquiring a response result of the vehicle-mounted controller to be debugged based on the communication protocol corresponding to the service request; according to the invention, the vehicle-mounted controller fixed on the vehicle is not required to be disassembled, and the data interaction can be directly carried out through the existing communication interface of the vehicle-mounted controller to be debugged, so that the software debugging is carried out under the condition that the structure of the vehicle-mounted controller is not changed, the convenience and the practicability are enhanced, and the debugging efficiency is improved.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the application.
Drawings
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the application and together with the description, serve to explain the principles of the application. It is apparent that the drawings in the following description are only some embodiments of the present application, and that other drawings may be obtained from these drawings without inventive effort for a person of ordinary skill in the art. In the drawings:
FIG. 1 is a schematic diagram of an in-vehicle controller software debug system architecture shown in an exemplary embodiment of the present invention;
FIG. 2 is a flow chart of a method for debugging software of an on-board controller according to an exemplary embodiment of the invention;
FIG. 3 is a schematic diagram illustrating a flow of extracting variables to be tested in a method for debugging software of an on-board controller according to an exemplary embodiment of the present invention;
FIG. 4 is a schematic diagram of a transmission process flow of a variable to be tested in a method for debugging software of an in-vehicle controller according to an exemplary embodiment of the present invention;
FIG. 5 is a schematic diagram illustrating software debugging of an onboard controller using the UDS communication protocol, in accordance with an exemplary embodiment of the present invention;
FIG. 6 is a flow chart of a method for debugging software of an on-board controller according to an exemplary embodiment of the invention;
FIG. 7 is a schematic flow chart of reading target variable data according to an exemplary embodiment of the present invention;
FIG. 8 is a flow chart of a method for debugging software of an on-board controller according to an exemplary embodiment of the invention;
FIG. 9 is a schematic flow diagram illustrating modification of target variable data in accordance with an exemplary embodiment of the present invention;
FIG. 10 is a flow chart of a method for debugging software of an on-board controller according to an exemplary embodiment of the invention;
FIG. 11 is a schematic diagram showing an abnormality log reading function of an in-vehicle controller according to an exemplary embodiment of the present invention
Fig. 12 shows a schematic diagram of a computer system suitable for use in implementing the electronic device of the embodiments of the present application.
Detailed Description
Further advantages and effects of the present invention will become readily apparent to those skilled in the art from the disclosure herein, by referring to the accompanying drawings and the preferred embodiments. The invention may be practiced or carried out in other embodiments that depart from the specific details, and the details of the present description may be modified or varied from the spirit and scope of the present invention. It should be understood that the preferred embodiments are presented by way of illustration only and not by way of limitation.
It should be noted that the illustrations provided in the following embodiments merely illustrate the basic concept of the present invention by way of illustration, and only the components related to the present invention are shown in the drawings and are not drawn according to the number, shape and size of the components in actual implementation, and the form, number and proportion of the components in actual implementation may be arbitrarily changed, and the layout of the components may be more complicated.
In the following description, numerous details are set forth in order to provide a more thorough explanation of embodiments of the present invention, it will be apparent, however, to one skilled in the art that embodiments of the present invention may be practiced without these specific details, in other embodiments, well-known structures and devices are shown in block diagram form, rather than in detail, in order to avoid obscuring the embodiments of the present invention.
The CAN (Controller Area Network) bus communication interface integrates the functions of a physical layer and a data link layer of the CAN protocol, and CAN complete framing processing of communication data, including bit filling, data block coding, cyclic redundancy check, priority discrimination and the like. One of the biggest features of the CAN protocol, which allows the number of nodes in the network to be theoretically unrestricted, is that the conventional station address coding is eliminated, but instead the coding LIN (Local Interconnect Network) of the communication data blocks is a low-cost serial communication network for realizing the control of the distributed electronic system in the automobile. The purpose of LIN is to provide auxiliary functions for existing automotive networks (e.g. CAN bus), so LIN bus is an auxiliary oneBus network. Ethernet (ETH) is the most widely usedThe universal LAN communication mode is also a protocol. The ethernet protocol defines a series of software and hardware standards that connect different computer devices together. The basic elements of the Ethernet equipment networking include switches, routers, hubs, optical fibers, common network cables, ethernet protocols and communication rules. The port of the network data connection in the ethernet is the ethernet interface.
As shown in fig. 1, fig. 1 shows a schematic diagram of an exemplary system architecture to which the technical solution of the embodiment of the present invention is applied. As shown in fig. 1, the system architecture may include a commissioning host computer 110, a vehicle 120 to be commissioned. An OBD interface is provided within the vehicle 120 to be commissioned. The upper computer can be a computer, a tablet or a mobile phone, etc. The external communication interface of the new energy vehicle-mounted controller mainly comprises CAN, LIN or Ethernet. In order to achieve the purpose of debugging the vehicle-mounted controller, data interaction is needed to be carried out on the existing communication interface of the vehicle-mounted controller, so that the purpose of software debugging can be achieved under the condition that the structure of the vehicle-mounted controller is not changed. Therefore, the invention is realized by adopting any one of CAN, LIN or ETH communication modes. In one embodiment of the application, the vehicle-mounted controller to be debugged is connected through a local communication interface; or, the vehicle-mounted controller to be debugged is remotely connected through the vehicle cloud, and for example, the local communication interface is an OBD interface. As shown in fig. 1, a related technician may connect the debug host computer 110 with the vehicle 120 to be debugged through an OBD interface, or directly connect the vehicle 120 to be debugged remotely through a vehicle cloud. The debugging upper computer can be connected through an OBD interface in the vehicle to be debugged, and the bus protocol of the connection interface can be any one of CAN, LIN, ETH. Therefore, the connection mode of the invention and the vehicle-mounted controller does not depend on the debugging interface of the vehicle-mounted controller, and the existing communication interface of the vehicle-mounted controller is used without adding a new interface. And support local connection and remote connection, not only the connection is convenient, has still promoted the efficiency to on-vehicle controller software debugging.
Fig. 2 shows a flowchart of an in-vehicle controller software debugging method according to one embodiment of the present invention, which may be performed by a computing processing device, which may be the upper computer 110 shown in fig. 1. Referring to fig. 3, the method for debugging the software of the vehicle-mounted controller at least includes steps S210 to S240, which are described in detail as follows:
step S210, obtaining address and length information of variables to be tested.
Step S220, a service request for debugging the variable to be tested is initiated.
And step S230, the address and length information of the variable to be tested are sent to the vehicle-mounted controller to be debugged based on the communication protocol corresponding to the service request.
In one embodiment of the present application, the communication protocol may employ a custom protocol or a generic protocol. Modification of the test software is required if custom protocols are employed. If a generic protocol is used, simple configuration of the generic protocol can support software debugging.
Step S240, determining a debugging result of the vehicle-mounted controller to be debugged according to a response result of the vehicle-mounted controller to be debugged, so as to debug the vehicle-mounted controller to be debugged, wherein the response result is feedback after the vehicle-mounted controller receives address and length information of the variable to be tested.
In one embodiment of the application, the debugging condition of the vehicle-mounted controller is judged through the response result, so that a related technician can know the debugging condition of the vehicle-mounted controller in time conveniently, and meanwhile, the related technician can debug the vehicle-mounted controller to a preset debugging effect through the response result conveniently. In an embodiment of the application, the debugging upper computer further has a terminal printing function, and can print debugging condition information of the vehicle-mounted controller.
In the technical scheme of the embodiment shown in fig. 2, the invention directly communicates with the vehicle-mounted controller to be debugged through a preset communication protocol, namely, a service request for processing the address and length information of the variable to be tested is initiated by acquiring the address and length information of the variable to be tested, and a response result of the vehicle-mounted controller to be debugged is acquired based on the communication protocol corresponding to the service request. Therefore, the vehicle-mounted controller is not required to be detached from the vehicle, and data interaction can be directly carried out on the existing communication interface of the vehicle-mounted controller to be debugged, so that the aim of debugging the vehicle-mounted controller software is fulfilled under the condition that the structure of the vehicle-mounted controller is not changed.
Referring to fig. 3, fig. 3 is a schematic flow chart of step S210 in the method for debugging the vehicle-mounted controller software shown in fig. 2 according to an exemplary embodiment of the present application, and in the embodiment shown in fig. 3, step S210 in the method for debugging the vehicle-mounted controller software further includes the following steps:
in step S310, an ELF file is generated, where address and length information of the variable to be tested are stored.
Step S320, extracting address and length information of the variables to be tested from the ELF file.
In one embodiment of the present application, ELF (Executable and Linkable Format) files are generated by a compiler, and variables to be tested include global variables and static variables. In the embodiment, the debugging upper computer can extract all variables to be tested from the ELF file, so that secondary processing of information of the variables to be tested is not needed, and the efficiency of debugging the vehicle-mounted controller software can be improved.
In the technical scheme of the embodiment shown in fig. 3, address and length information of the variables to be tested are directly extracted from the ELF file without secondary processing, so that the debugging efficiency of the vehicle-mounted controller software is improved.
Referring to fig. 4, fig. 4 is a schematic flow chart of step S230 in the method for debugging the vehicle-mounted controller software shown in fig. 3 according to an exemplary embodiment of the present application, and in the embodiment shown in fig. 4, step S230 in the method for debugging the vehicle-mounted controller software further includes the following steps:
in step S410, if the service request is a read target variable data request, the address and length information of the variable to be tested is sent to the vehicle-mounted controller to be debugged through the address read memory service of the unified diagnostic service protocol.
Step S420, if the service request is a request for modifying the target variable data, the address and length information of the variable to be tested are sent to the vehicle-mounted controller to be debugged through the address writing memory service of the unified diagnosis service protocol.
Unified diagnostic service protocol (Unified Diagnostic Services), abbreviated as UDS communication protocol. The system is an automobile universal diagnosis protocol defined by ISO15765 and ISO 14229, is positioned at an application layer in an OSI model, can be realized on different automobile buses, and is a vehicle-mounted diagnosis protocol standard widely used in the current automobile field. The application layer definition of the UDS communication protocol is ISO 14229-1, and most automobile manufacturers currently adopt the diagnosis protocol of UDS on CAN. The UDS communication protocol includes a plurality of diagnostic services, which are classified into different functional units according to functions and processing purposes. The data transfer functional unit (Data Transmission) includes a read memory (23 service) and a write memory (3D service). The address read memory (23 service) is used for requesting to read the data of the variable to be tested in the specified memory range, and the request parameters are the address and length information of the variable to be tested. The address-through-memory (3D service) is a memory that allows the target variable data record to be written directly into ECU (Electronic Control Unit), and the request parameters are address and length information of the variable to be tested.
In the technical scheme of the embodiment shown in fig. 4, the data communication is performed by adopting the universal protocol, only the simple configuration is required for supporting the software debugging, and the user-defined protocol needs to modify the test software, so that the workload is very large, and the application scene is limited, therefore, the universal protocol is used, the vehicle-mounted controller does not need to develop a communication protocol specially used for the software debugging, the development workload is reduced, and the stability and the universality of the vehicle-mounted controller software debugging system are improved.
In one embodiment of the present application, the UDS communication protocol is used for debugging the vehicle controller software, as shown in fig. 5, and fig. 5 is a schematic diagram of debugging the vehicle controller software using the UDS communication protocol. The UDS communication protocol is a generic protocol for automotive diagnostic services. By using the UDS communication protocol, the vehicle-mounted controller does not need to develop a communication protocol special for software debugging, reduces development workload, and improves the stability and universality of the vehicle-mounted controller software debugging system.
Referring to fig. 6, fig. 6 is a schematic flow chart of step S240 in the method for debugging the vehicle-mounted controller software shown in fig. 2 according to an exemplary embodiment of the present application, and in the embodiment shown in fig. 6, step S240 in the method for debugging the vehicle-mounted controller software further includes the following steps:
step S610, a first response result of the vehicle-mounted controller to be debugged is obtained, wherein the first response result comprises a forward response, a overtime response and a negative response, the forward response is that the vehicle-mounted controller to be debugged searches for variable data to be tested in a memory of the vehicle-mounted controller to be debugged according to the address and the length information of the variable to be tested within a preset time, the overtime response is that the vehicle-mounted controller to be debugged searches for variable data to be tested in the memory of the vehicle-mounted controller to be debugged according to the address and the length information of the variable to be tested within the preset time, the negative response is that the vehicle-mounted controller to be debugged does not search for variable data to be tested in the memory of the vehicle-mounted controller to be debugged according to the address and the length information of the variable to be tested within the preset time.
In step S620, if the first response result is a forward response, the received variable data to be tested is determined as target variable data, and the target variable data is displayed.
In one embodiment of the present application, if the first response result is a timeout response and a negative response, an error message is prompted. And sending the address and length information of the variable to be tested again, and waiting for the response of the vehicle-mounted controller until the response result is forward response.
In one embodiment of the application, the debugging upper computer supports imaging and numerical display, and in the embodiment, target variable data can be displayed in an imaging mode, so that a developer can conveniently conduct data analysis. In this embodiment, all target variable data can also be saved locally, thereby facilitating offline analysis of the data by the developer. And moreover, a developer can edit the target variable data conveniently, and after editing is finished, the debugging upper computer can update new data to the vehicle-mounted controller. Thus, the debugging efficiency of the vehicle-mounted control software is improved.
In one embodiment of the present application, fig. 7 is a schematic flow chart of reading target variable data, as shown in fig. 7, address and length information of a variable to be tested are extracted from an ELF file, a service request for reading the target variable data is initiated to a vehicle-mounted controller through a UDS communication protocol, after the completion of the sending, the vehicle-mounted controller waits for feeding back a first response result, and if the first response result is a forward response, the received target variable data is sent to a display module for data display. And if the first response result is a negative response or a timeout response, displaying a fault prompt. In this way, the address and length information of the variable to be tested are obtained, and a service request for reading target variable data is initiated through the UDS communication protocol, so that a first response result of the vehicle-mounted controller to the service request is obtained, and the vehicle-mounted controller to be debugged is debugged. Therefore, the vehicle-mounted controller is not required to be detached from the vehicle, and the target variable data can be directly read through the existing communication interface of the vehicle-mounted controller to be debugged, so that the aim of debugging the vehicle-mounted controller software is fulfilled under the condition that the structure of the vehicle-mounted controller is not changed.
Referring to fig. 8, fig. 8 is a schematic flow chart of step S240 in the method for debugging the vehicle-mounted controller software shown in fig. 2 according to an exemplary embodiment of the present application, and in the embodiment shown in fig. 7, step S240 in the method for debugging the vehicle-mounted controller software further includes the following steps:
step S810, obtaining a second response result of the vehicle-mounted controller to be debugged, wherein the second response result comprises a forward response, a timeout response and a negative response; the forward response is that the vehicle-mounted controller to be debugged searches variable data to be tested in the vehicle-mounted controller memory according to the variable address and the length information to be tested in a preset time, modifies the variable data to be tested into target variable data, and sends an execution result; the overtime response is that the to-be-debugged vehicle-mounted controller modifies the variable data to be tested into target variable data within preset time, but does not send an execution result; and the negative response is that the to-be-debugged vehicle-mounted controller does not modify the variable data to be tested into target variable data within the preset time.
Step S820, if the second response result is a forward response, receiving an execution result, wherein the execution result represents that the vehicle-end vehicle-mounted controller has updated the target variable data to the memory address corresponding to the variable to be tested within a preset time.
In one embodiment of the present application, if the first response result is a timeout response and a negative response, an error message is prompted. And sending the address and length information of the variable to be tested again, and waiting for the response of the vehicle-mounted controller until the response result is forward response.
In one embodiment of the present application, fig. 9 shows a flow chart of modifying target variable data, as shown in fig. 9, address and length information of a variable to be tested is extracted from an ELF file, a request for modifying target variable data service is initiated to a vehicle-mounted controller through a UDS communication protocol, after the completion of the transmission, the vehicle-mounted controller waits for feeding back a second response result, and if the first response result is a forward response, an execution result is received and sent to a display module for display. And if the second response result is a negative response or a timeout response, displaying a fault prompt. And sending the address and length information of the variable to be tested again until the response result of the vehicle-mounted controller is a forward response. In this way, the address and length information of the variable to be tested are obtained, a target variable data modification service request is initiated through the UDS communication protocol, and a second response result of the vehicle-mounted controller to the service request is obtained so as to debug the vehicle-mounted controller to be debugged. Therefore, the vehicle-mounted controller is not required to be detached from the vehicle, and the target variable data can be directly modified on the existing communication interface of the vehicle-mounted controller to be debugged, so that the aim of debugging the vehicle-mounted controller software is fulfilled under the condition that the structure of the vehicle-mounted controller is not changed.
Referring to fig. 10, fig. 10 shows that the method for debugging the to-be-debugged vehicle-mounted controller software according to an exemplary embodiment of the present application further includes steps S1010 to S1020, which are as follows:
step S1010, reading an abnormal log of the vehicle-mounted controller to be debugged through a unified diagnosis protocol, wherein the abnormal log comprises fault information records of abnormal moments of the vehicle-mounted controller to be debugged.
And step S1020, analyzing fault information of the vehicle-mounted controller to be debugged according to the abnormal log.
In the technical scheme of the embodiment shown in fig. 10, the exception log of the on-board controller to be debugged is read through the unified diagnosis protocol, so that the fault information of the on-board controller to be debugged is analyzed according to the exception log. The traditional reading mode needs to detach the vehicle-mounted controller from the fault vehicle, and then reads an abnormal log in the vehicle-mounted controller through a debugging tool after the laboratory uncovers. The debugging upper computer can directly read out fault information through the remote or local OBD interface through the unified diagnosis protocol, the fault part is not required to be detached to be taken to a laboratory for reading and analysis, and the abnormal problem is rapidly positioned by combining the abnormal log analysis function of the debugging upper computer software, so that the efficiency of fault analysis is greatly improved.
In an embodiment of the present application, as shown in fig. 11, fig. 11 is a schematic diagram of an abnormality log reading function of a vehicle-mounted controller, when the vehicle-mounted controller is abnormal, the controller records fault information at an abnormal moment into an internal storage for controlling the controller, and a debugging upper computer can directly read the fault information through a remote or local OBD interface through a UDS protocol, so that a fault part does not need to be detached to be taken to a laboratory for reading and analyzing, and an abnormality problem is rapidly located by combining an abnormality log analysis function of debugging upper computer software.
The embodiment of the application also provides electronic equipment, which comprises: one or more processors; and the storage device is used for storing one or more programs, and when the one or more programs are executed by the one or more processors, the electronic equipment realizes the vehicle-mounted controller software debugging method provided in each embodiment.
Fig. 12 shows a schematic diagram of a computer system suitable for use in implementing the electronic device of the embodiments of the present application. It should be noted that, the computer system 1200 of the electronic device shown in fig. 12 is only an example, and should not impose any limitation on the functions and the application scope of the embodiments of the present application.
As shown in fig. 12, the computer system 1200 includes a central processing unit (Central Processing Unit, CPU) 1201 that can perform various appropriate actions and processes, such as performing the methods described in the above embodiments, according to a program stored in a Read-Only Memory (ROM) 502 or a program loaded from a storage section 1208 into a random access Memory (Random Access Memory, RAM) 1203. In the RAM 1203, various programs and data required for the system operation are also stored. The CPU 1201, ROM 1202, and RAM 1203 are connected to each other through a bus 1204. An Input/Output (I/O) interface 1205 is also connected to bus 1204.
The following components are connected to the I/O interface 1205: an input section 1206 including a keyboard, a mouse, and the like; an output portion 1207 including a Cathode Ray Tube (CRT), a liquid crystal display (Liquid Crystal Display, LCD), and a speaker, etc.; a storage section 1208 including a hard disk or the like; and a communication section 1209 including a network interface card such as a LAN (Local Area Network ) card, a modem, or the like. The communication section 1209 performs communication processing via a network such as the internet. The drive 1210 is also connected to the I/O interface 1205 as needed. A removable medium 1211 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is installed as needed on the drive 1210 so that a computer program read out therefrom is installed into the storage section 1208 as needed.
In particular, according to embodiments of the present application, the processes described above with reference to flowcharts may be implemented as computer software programs. For example, embodiments of the present application include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising a computer program for performing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via the communication portion 1209, and/or installed from the removable media 1211. When executed by a Central Processing Unit (CPU) 1201, performs the various functions defined in the system of the present application.
It should be noted that, the computer readable medium shown in the embodiments of the present application may be a computer readable signal medium or a computer readable storage medium, or any combination of the two. The computer readable storage medium may be, for example, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of the computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-Only Memory (ROM), an erasable programmable read-Only Memory (Erasable Programmable Read Only Memory, EPROM), flash Memory, an optical fiber, a portable compact disc read-Only Memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the present application, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, with a computer-readable computer program embodied therein. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination of the foregoing. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. A computer program embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wired, etc., or any suitable combination of the foregoing.
The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present application. Where each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
The units involved in the embodiments of the present application may be implemented by means of software, or may be implemented by means of hardware, and the described units may also be provided in a processor. Wherein the names of the units do not constitute a limitation of the units themselves in some cases.
Another aspect of the present application also provides a computer-readable storage medium having stored thereon a computer program which, when executed by a processor of a computer, causes the computer to perform the on-board controller software debugging method as described above. The computer-readable storage medium may be included in the electronic device described in the above embodiment or may exist alone without being incorporated in the electronic device.
Another aspect of the present application also provides a computer program product or computer program comprising computer instructions stored in a computer readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions so that the computer device performs the on-vehicle controller software debugging method provided in the above-described respective embodiments.
The above embodiments are merely illustrative of the principles of the present invention and its effectiveness, and are not intended to limit the invention. Modifications and variations may be made to the above-described embodiments by those skilled in the art without departing from the spirit and scope of the invention. It is therefore intended that all equivalent modifications and changes made by those skilled in the art without departing from the spirit and technical spirit of the present invention shall be covered by the appended claims.

Claims (10)

1. The vehicle-mounted controller software debugging method is characterized by comprising the following steps of:
acquiring address and length information of a variable to be tested;
initiating a service request for debugging the variable to be tested;
transmitting address and length information of a variable to be tested to a vehicle-mounted controller to be debugged based on a communication protocol corresponding to the service request;
determining a debugging result of the vehicle-mounted controller to be debugged according to the response result of the vehicle-mounted controller to be debugged so as to debug the vehicle-mounted controller to be debugged, wherein the response result is feedback after the vehicle-mounted controller receives address and length information of a variable to be tested.
2. The method for debugging software of a vehicle-mounted controller according to claim 1, wherein obtaining address and length information of a variable to be tested comprises:
generating an ELF file, wherein address and length information of variables to be tested are stored in the ELF file;
and extracting address and length information of the variable to be tested from the ELF file.
3. The method according to claim 1, wherein address and length information of variables to be tested are sent to the on-vehicle controller to be debugged based on a communication protocol corresponding to the service request, the service request includes a request for reading target variable data and a request for modifying target variable data, the communication protocol includes a first communication protocol and a second communication protocol, the first communication protocol is a through address read memory service of a unified diagnostic service protocol, and the second communication protocol is a through address write memory service of the unified diagnostic service protocol, including:
if the service request is a read target variable data request, the address and length information of the variable to be tested is sent to a vehicle-mounted controller to be debugged through an address read memory service of a unified diagnosis service protocol;
and if the service request is a request for modifying target variable data, transmitting the variable address and length information to be tested to a vehicle-mounted controller to be debugged through an address writing memory service of a unified diagnosis service protocol.
4. The method for debugging software of a vehicle-mounted controller according to claim 1, wherein a debugging result of the vehicle-mounted controller to be debugged is determined according to a response result of the vehicle-mounted controller to be debugged, the response result is feedback after the vehicle-mounted controller receives address and length information of a variable to be tested, the response result comprises a first response result, and the method comprises the following steps:
acquiring a first response result of the vehicle-mounted controller to be debugged, wherein the first response result comprises a forward response, a timeout response and a negative response; wherein, the liquid crystal display device comprises a liquid crystal display device,
the forward response is that the vehicle-mounted controller to be debugged searches the variable data to be tested in the memory of the vehicle-mounted controller to be debugged according to the address and the length information of the variable to be tested within a preset time, and the variable data to be tested is sent;
the overtime response is that the to-be-debugged vehicle-mounted controller searches the to-be-tested variable data in the to-be-debugged vehicle-mounted controller memory according to the to-be-tested variable address and the length information within the preset time, and the to-be-tested variable data is not sent;
the negative response is that the vehicle-mounted controller to be debugged does not find variable data to be tested in the memory of the vehicle-mounted controller to be debugged according to the address and the length information of the variable to be tested within preset time;
and if the first response result is a forward response, determining the received variable data to be tested as target variable data, and displaying the target variable data.
5. The method for debugging software of a vehicle-mounted controller according to claim 1, wherein a debugging result of the vehicle-mounted controller to be debugged is determined according to a response result of the vehicle-mounted controller to be debugged, the response result is feedback after the vehicle-mounted controller receives address and length information of a variable to be tested, the response result further comprises a second response result, and the method comprises the following steps:
acquiring a second response result of the vehicle-mounted controller to be debugged, wherein the second response result comprises a forward response, a timeout response and a negative response; wherein, the liquid crystal display device comprises a liquid crystal display device,
the forward response is that the vehicle-mounted controller to be debugged searches variable data to be tested in a vehicle-mounted controller memory according to variable address and length information to be tested in a preset time, modifies the variable data to be tested into target variable data and sends an execution result;
the overtime response is that the to-be-debugged vehicle-mounted controller modifies the variable data to be tested into target variable data within preset time, but does not send an execution result;
the negative response is that the to-be-debugged vehicle-mounted controller does not modify variable data to be tested into target variable data within preset time;
and if the second response result is a forward response, receiving an execution result, wherein the execution result represents that the vehicle-end vehicle-mounted controller updates the target variable data to the memory address corresponding to the variable to be tested within a preset time.
6. The on-vehicle controller software debugging method according to claim 1, characterized in that the on-vehicle controller software debugging method to be debugged further comprises:
reading an abnormal log of the vehicle-mounted controller to be debugged through a unified diagnosis protocol, wherein the abnormal log comprises fault information records of abnormal moments of the vehicle-mounted controller to be debugged;
and analyzing fault information of the vehicle-mounted controller to be debugged according to the abnormal log.
7. The method for debugging software of an in-vehicle controller according to any one of claims 1 to 6, further comprising, before acquiring address and length information of a variable to be tested:
the to-be-debugged vehicle-mounted controller is connected through a local communication interface; or (b)
And the vehicle-mounted controller to be debugged is remotely connected through the vehicle cloud.
8. An in-vehicle controller software debug system, the in-vehicle controller software debug system comprising:
the first acquisition module is configured to acquire address and length information of a variable to be tested;
the service initiation module is configured to initiate a service request for debugging the variable to be tested;
the sending module is configured to send the address and length information of the variable to be tested to the vehicle-mounted controller to be debugged based on a communication protocol corresponding to the service request;
the determining module is configured to determine a debugging result of the vehicle-end vehicle-mounted controller to be debugged according to a response result of the vehicle-mounted controller to be debugged so as to debug the vehicle-mounted controller to be debugged, wherein the response result is feedback after the vehicle-mounted controller receives address and length information of a variable to be tested.
9. An electronic device, the electronic device comprising:
one or more processors;
storage means for storing one or more programs which, when executed by the one or more processors, cause the electronic device to implement the in-vehicle controller software debugging method of any of claims 1 to 7.
10. A computer-readable storage medium, having stored thereon a computer program which, when executed by a processor of a computer, causes the computer to perform the in-vehicle controller software debugging method of any one of claims 1 to 7.
CN202310292233.2A 2023-03-23 2023-03-23 Vehicle-mounted controller software debugging method and system, electronic equipment and storage medium Pending CN116483693A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310292233.2A CN116483693A (en) 2023-03-23 2023-03-23 Vehicle-mounted controller software debugging method and system, electronic equipment and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202310292233.2A CN116483693A (en) 2023-03-23 2023-03-23 Vehicle-mounted controller software debugging method and system, electronic equipment and storage medium

Publications (1)

Publication Number Publication Date
CN116483693A true CN116483693A (en) 2023-07-25

Family

ID=87212907

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310292233.2A Pending CN116483693A (en) 2023-03-23 2023-03-23 Vehicle-mounted controller software debugging method and system, electronic equipment and storage medium

Country Status (1)

Country Link
CN (1) CN116483693A (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117215958A (en) * 2023-10-11 2023-12-12 深圳市浩科智联科技有限公司 Vehicle-mounted application separation design software and test method thereof
CN117215958B (en) * 2023-10-11 2024-05-31 深圳市浩科智联科技有限公司 Vehicle-mounted application separation design software and test method thereof

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117215958A (en) * 2023-10-11 2023-12-12 深圳市浩科智联科技有限公司 Vehicle-mounted application separation design software and test method thereof
CN117215958B (en) * 2023-10-11 2024-05-31 深圳市浩科智联科技有限公司 Vehicle-mounted application separation design software and test method thereof

Similar Documents

Publication Publication Date Title
CN109740222B (en) Testing device and system for automobile networking scene
CN111538312B (en) Vehicle remote diagnosis method, system, equipment connector and vehicle connector
US11514731B2 (en) Method and system for remote vehicle diagnostics
CN111045416B (en) Method and device for analyzing CAN (controller area network) signal of whole vehicle by using diagnosis message
CN113608518B (en) Data generation method, device, terminal equipment and medium
CN113468070A (en) Consistency test method for vehicle-mounted Ethernet
CN111880508A (en) Automatic calibration and test method and device for T-box parameters
CN111506047A (en) Vehicle diagnosis method, device and storage medium
CN116483693A (en) Vehicle-mounted controller software debugging method and system, electronic equipment and storage medium
CN117041111A (en) Vehicle cloud function test method and device, electronic equipment and storage medium
CN116841874A (en) Test method and device for unified diagnosis service function, storage medium and electronic equipment
CN116339784A (en) Emergency method and device for failure in upgrading vehicle application, vehicle, equipment and medium
CN115022297B (en) Remote debugging method, device and system of vehicle-end controller and vehicle
CN115150300A (en) Management system and method for vehicle safety attack and defense
CN113934198A (en) Vehicle diagnosis method, vehicle diagnosis device, electronic device, and storage medium
CN114003018A (en) Vehicle diagnosis method and related device
CN115129605A (en) Data closed-loop automatic testing method and device, electronic equipment and storage medium
CN115542875A (en) Vehicle detection method based on SOA service and related equipment
CN115695237A (en) Vehicle-end network detection method and system, electronic equipment and readable storage medium
CN109542656B (en) Debugging diagnosis method and device for vehicle-mounted intelligent platform and computer storage medium
CN116828522A (en) Test method, test device, electronic equipment and computer readable storage medium
CN117762118A (en) Simulation test method and device for unmanned vehicle fault diagnosis system
CN115811488A (en) Internet of vehicles multi-protocol testing system and method
CN113960991A (en) Vehicle fault diagnosis system, method and device, system-on-chip and vehicle
CN116016239A (en) Service interface testing method, device, equipment and storage medium

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