Autosar-based can to lin diagnosis method, device and equipment and storage medium

Abstract

The application discloses an AUTOSAR-based CAN-to-LIN diagnosis method and device, equipment and a storage medium, and relates to the technical field of automobile gateway software diagnosis. The application comprises the following steps: after a gateway receives a CAN diagnosis message request sent by a diagnosis instrument, the CAN diagnosis message request transmitted through a CAN driver is received; message conversion is performed on the CAN diagnosis message request, and a LIN diagnosis message request is obtained; the LIN diagnosis message request is transmitted to a LIN driver, and a LIN diagnosis result fed back by the LIN driver according to the LIN diagnosis message request is received; message conversion is performed on the LIN diagnosis result, a CAN diagnosis result is obtained, and the CAN diagnosis result is transmitted to the diagnosis instrument through the CAN driver, so that the development cost of a LIN diagnosis host computer is saved, and CAN and LIN controller diagnosis functions are realized through a CAN host computer.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of automobile gateway software diagnosis, and particularly relates to a CAN-to-LIN diagnosis method and device based on AUTOSAR, equipment and a storage medium. BACKGROUND

[0002] Embedded controller software design involves software flashing upgrade and software configuration update. Vehicle-mounted controller communication is generally in CAN and LIN communication modes. When different controller diagnosis configuration updates are performed, because the CAN and LIN protocols are inconsistent, the diagnosis instrument and the vehicle need to be separately designed to adapt to the software communication protocol and hardware wiring harness for LIN diagnosis. The existing scheme basically adapts to LIN communication through the diagnosis instrument, and the hardware is designed, and CAN-to-LIN circuit design is performed at the hardware level, which is relatively costly.

[0003] The above content is only used to assist in understanding the technical solutions of the present application and does not represent the acknowledgement of the above content as prior art. SUMMARY

[0004] The main purpose of the present application is to provide a CAN-to-LIN diagnosis method and device based on AUTOSAR, equipment and a storage medium, aiming to solve the technical problem that the diagnosis instrument and the vehicle need to be separately designed to adapt to the software communication protocol and hardware wiring harness for LIN diagnosis.

[0005] To achieve the above purpose, the present application provides a CAN-to-LIN diagnosis method based on AUTOSAR, which comprises:

[0006] When the gateway receives a CAN diagnosis message request sent by the diagnosis instrument, the CAN diagnosis message request transmitted through the CAN driver is received;

[0007] The CAN diagnosis message request is converted into a LIN diagnosis message request;

[0008] The LIN diagnosis message request is transmitted to the LIN driver, and the LIN diagnosis result fed back by the LIN driver according to the LIN diagnosis message request is received;

[0009] The LIN diagnosis result is converted into a CAN diagnosis result, and the CAN diagnosis result is transmitted to the diagnosis instrument through the CAN driver.

[0010] In an embodiment, the step of receiving the CAN diagnosis message request transmitted through the CAN driver when the gateway receives the CAN diagnosis message request sent by the diagnosis instrument comprises:

[0011] When the gateway receives the CAN diagnosis message request sent by the diagnosis instrument, the CAN diagnosis message request is transmitted to the CAN transmission layer through the CAN interface layer;

[0012] The format checking result of the CAN diagnosis message request by the CAN transmission layer is obtained, and when the checking result is qualified, the CAN diagnosis message request transmitted by the CAN transmission layer is received.

[0013] In an embodiment, the step of converting the CAN diagnosis message request into a LIN diagnosis message request comprises:

[0014] The CAN diagnosis message request is stored in the receiving buffer, and the receiving buffer state is switched to the occupied state, and the session state of the receiving state machine is switched to the receiving performing state.

[0015] The session state of the sending state machine corresponding to the receiving state machine and the buffer state corresponding to the sending buffer corresponding to the receiving buffer are determined.

[0016] When the session state of the sending state machine corresponding to the receiving state machine is the idle state, and the buffer state corresponding to the sending buffer corresponding to the receiving buffer is the idle state, the CAN diagnosis request message is converted into a LIN diagnosis message request.

[0017] In an embodiment, the step of storing the CAN diagnosis message request in the receiving buffer, switching the receiving buffer state to the occupied state, and switching the session state of the receiving state machine to the receiving performing state comprises:

[0018] The frame type determined according to the frame judgment of the CAN transmission layer on the CAN diagnosis message request is used to determine the frame processing function;

[0019] The length and the use state of the receiving buffer are determined based on the frame processing function;

[0020] When the length of the receiving buffer is greater than the frame length of the CAN diagnosis message request, and the use state of the receiving buffer is the idle state, the CAN diagnosis message request is stored in the receiving buffer, the receiving buffer state is switched to the occupied state, and the session state of the receiving state machine is switched to the receiving performing state.

[0021] In an embodiment, the step of transmitting the LIN diagnosis message request to the LIN driver and receiving the LIN diagnosis result fed back by the LIN driver according to the LIN diagnosis message request comprises:

[0022] transmitting the LIN diagnosis message request to a LIN transport layer, and transmitting the LIN diagnosis message request to a LIN driver layer through the LIN transport layer, so that the LIN driver layer generates a LIN diagnosis result according to the LIN diagnosis message request;

[0023] receiving the diagnosis result generated by the LIN driver layer according to the LIN diagnosis message request through the LIN transport layer.

[0024] In an embodiment, the step of converting the LIN diagnosis result into a CAN diagnosis result and transmitting the CAN diagnosis result to the diagnosis instrument through a CAN driver includes:

[0025] storing the LIN diagnosis result in a receiving buffer, switching a receiving buffer state to an occupied state, and switching a session state of a receiving state machine to a receiving processing state;

[0026] determining a session state of a sending state machine corresponding to the receiving state machine and a buffer state of a sending buffer corresponding to the receiving buffer;

[0027] when the session state of the sending state machine corresponding to the receiving state machine is an idle state and the buffer state of the sending buffer corresponding to the receiving buffer is an idle state, converting the LIN diagnosis result into a CAN diagnosis result, and transmitting the CAN diagnosis result to the diagnosis instrument through a CAN driver.

[0028] In an embodiment, the step of storing the LIN diagnosis result in a receiving buffer, switching a receiving buffer state to an occupied state, and switching a session state of a receiving state machine to a receiving processing state includes:

[0029] determining a frame processing function according to a frame type obtained by performing frame judgment on the LIN diagnosis result by a basic software layer mode management module;

[0030] determining a length and a use state of a receiving buffer based on the frame processing function;

[0031] when the length of the receiving buffer is greater than a frame length of the LIN diagnosis result and the use state of the receiving buffer is an idle state, storing the LIN diagnosis result in the receiving buffer, switching the receiving buffer state to the occupied state, and switching the session state of the receiving state machine to the receiving processing state.

[0032] In addition, to achieve the above object, the application further provides a CAN-to-LIN diagnosis device based on AUTOSAR, which comprises:

[0033] The message request module receives the CAN diagnosis message request transmitted through the CAN driver when the gateway receives the CAN diagnosis message request sent by the diagnostic instrument.

[0034] The message conversion module converts the CAN diagnosis message request into a LIN diagnosis message request.

[0035] The message transmission module transmits the LIN diagnosis message request to the LIN driver and receives the LIN diagnosis result fed back by the LIN driver according to the LIN diagnosis message request.

[0036] The result feedback module converts the LIN diagnosis result into a CAN diagnosis result and transmits the CAN diagnosis result to the diagnostic instrument through the CAN driver.

[0037] In addition, to achieve the above-mentioned purpose, the application further provides a CAN-to-LIN diagnosis device based on AUTOSAR, which comprises a memory, a processor, and a computer program stored in the memory and executable on the processor, and the computer program is configured to implement the steps of the CAN-to-LIN diagnosis method based on AUTOSAR.

[0038] In addition, to achieve the above-mentioned purpose, the application further provides a storage medium, which is a computer-readable storage medium, and the storage medium stores a computer program, and the computer program is executed by a processor to implement the steps of the CAN-to-LIN diagnosis method based on AUTOSAR.

[0039] In addition, to achieve the above-mentioned purpose, the application further provides a computer program product, which comprises a computer program, and the computer program is executed by a processor to implement the steps of the CAN-to-LIN diagnosis method based on AUTOSAR.

[0040] The one or more technical solutions provided by the application have at least the following technical effects: when the gateway receives the CAN diagnosis message request sent by the diagnostic instrument, the CAN diagnosis message request transmitted through the CAN driver is received; the CAN diagnosis message request is converted into a LIN diagnosis message request; the LIN diagnosis message request is transmitted to the LIN driver, and the LIN diagnosis result fed back by the LIN driver according to the LIN diagnosis message request is received; the LIN diagnosis result is converted into a CAN diagnosis result, and the CAN diagnosis result is transmitted to the diagnostic instrument through the CAN driver, which saves the development cost of the LIN diagnosis host computer and realizes the CAN and LIN controller diagnosis function through the CAN host computer. BRIEF DESCRIPTION OF DRAWINGS

[0041] The accompanying drawings, which are incorporated herein and constitute part of the specification, illustrate embodiments consistent with the application and, together with the description, serve to explain the principles of the application.

[0042] In order to more clearly illustrate the technical solutions of the embodiments of the present application or the prior art, the accompanying drawings required by the embodiments or prior art description will be briefly introduced as follows. Obviously, for those of ordinary skill in the art, the other drawings can also be obtained based on these drawings without any creative work.

[0043] Figure 1 A flowchart provided by the AUTOSAR-based CAN-to-LIN diagnosis method embodiment one of the present application;

[0044] Figure 2 A network node schematic diagram provided by the AUTOSAR-based CAN-to-LIN diagnosis method embodiment one of the present application;

[0045] Figure 3 A data transmission flowchart provided by the AUTOSAR-based CAN-to-LIN diagnosis method embodiment one of the present application;

[0046] Figure 4 A session state machine schematic diagram provided by the AUTOSAR-based CAN-to-LIN diagnosis method embodiment one of the present application;

[0047] Figure 5 A data transmission flowchart provided by the AUTOSAR-based CAN-to-LIN diagnosis method embodiment one of the present application;

[0048] Figure 6 A module structure schematic diagram of the AUTOSAR-based CAN-to-LIN diagnosis device of the embodiment of the present application;

[0049] Figure 7 A device structure schematic diagram of the hardware running environment involved in the AUTOSAR-based CAN-to-LIN diagnosis method in the embodiment of the present application.

[0050] The object implementation, functional features and advantages of the present application will be further explained with reference to the embodiments and the accompanying drawings. DETAILED DESCRIPTION

[0051] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of the present application, and are not used to limit the present application.

[0052] In order to better understand the technical solutions of the present application, the following will be described in detail in combination with the drawings and specific embodiments of the present application.

[0053] The main solution of the embodiment of the application is that when the gateway receives a CAN diagnosis message request sent by a diagnosis instrument, the CAN diagnosis message request transmitted through a CAN driver is received; the CAN diagnosis message request is converted into a LIN diagnosis message request; the LIN diagnosis message request is transmitted to a LIN driver, and a LIN diagnosis result fed back by the LIN driver according to the LIN diagnosis message request is received; the LIN diagnosis result is converted into a CAN diagnosis result, and the CAN diagnosis result is transmitted to the diagnosis instrument through the CAN driver.

[0054] In the embodiment, for convenience of description, the following describes an execution subject of identifying a CAN-to-LIN diagnosis device based on AUTOSAR.

[0055] Since there are differences in communication modes of different controllers on an automobile in the prior art, currently, the most common two protocols are CAN protocol and LIN protocol, and currently, real-time communication diagnosis of the two kinds of controllers needs to separately lead out CAN lines and LIN lines, and a diagnosis instrument device also needs to support CAN and LIN communication protocols, which increases the complexity of the controllers and is not conducive to controller line maintenance, thereby increasing the maintenance cost of the controllers.

[0056] The application provides a solution, which converts CAN protocol and LIN protocol through a software mode of a gateway controller, does not need to additionally increase hardware cost, has small cost, and is reliable.

[0057] From the above embodiment, it can be known that the application receives a CAN diagnosis message request transmitted through a CAN driver when the gateway receives a CAN diagnosis message request sent by a diagnosis instrument; converts the CAN diagnosis message request into a LIN diagnosis message request; transmits the LIN diagnosis message request to a LIN driver, and receives a LIN diagnosis result fed back by the LIN driver according to the LIN diagnosis message request; converts the LIN diagnosis result into a CAN diagnosis result, and transmits the CAN diagnosis result to the diagnosis instrument through the CAN driver, thereby saving LIN diagnosis host computer development cost and realizing CAN and LIN controller diagnosis functions through a CAN host computer.

[0058] It should be noted that the execution subject of the embodiment can be a computing service device with data processing, network communication and program running functions, such as a tablet computer, a personal computer, a mobile phone and the like, or an electronic device capable of realizing the above functions, a CAN-to-LIN diagnosis device based on AUTOSAR and the like. The following takes the CAN-to-LIN diagnosis device based on AUTOSAR as an example to describe the embodiment and each of the following embodiments.

[0059] Based on this, the embodiment of the application provides a CAN-to-LIN diagnosis method based on AUTOSAR, referring to Figure 1 , Figure 1 The flowchart of the first embodiment of the CAN-to-LIN diagnosis method based on AUTOSAR of the application is shown in the figure.

[0060] In this embodiment, the CAN-to-LIN diagnosis method based on AUTOSAR comprises steps S10-S40:

[0061] Step S10, when the gateway receives the CAN diagnosis message request sent by the diagnostic instrument, the CAN diagnosis message request transmitted through the CAN driver is received.

[0062] It should be noted that the diagnostic instrument and the gateway are connected through the OBD interface, and the diagnostic instrument can send the CAN diagnosis message to the gateway through the OBD interface, and can also receive the CAN diagnosis result transmitted from the gateway through the OBD interface.

[0063] In a specific implementation, referring to Figure 2 , Figure 2 The network node is shown in the figure. When diagnosing, the diagnostic instrument can be connected with the gateway through the OBD interface first, and the gateway and the LIN sensor perform data transmission through the LIN network segment, wherein the communication protocol between the diagnostic instrument and the gateway is the CAN protocol, and the data transmission between the gateway and the LIN sensor is the LIN protocol. Therefore, when diagnosing, the diagnostic instrument can transmit the diagnosis message request to the gateway when initiating the diagnosis message request, and the gateway can send the CAN diagnosis message request received by the gateway to the protocol data unit routing PDUR layer through the CAN driver (CAN DRV).

[0064] In a feasible implementation, the step of receiving the CAN diagnosis message request transmitted through the CAN driver when the gateway receives the CAN diagnosis message request sent by the diagnostic instrument comprises:

[0065] When the gateway receives the CAN diagnosis message request sent by the diagnostic instrument, the CAN diagnosis message request is transmitted to the CAN transmission layer through the CAN interface layer;

[0066] Obtaining the format checking result of the CAN transmission layer on the CAN diagnosis message request, and when the checking result is qualified, the CAN diagnosis message request transmitted through the CAN transmission layer is received.

[0067] In a specific implementation, referring to Figure 3 , Figure 3The data transmission flow direction chart is shown. When the gateway receives the CAN diagnosis message request sent by the diagnostic instrument, the CAN diagnosis request message can be transmitted to the CAN transmission layer (CAN TP) through the CAN interface layer (CANIF). The CAN TP layer checks the diagnosis message format and judges whether it conforms to the ISO14229 standard format. If it is incorrect, it is discarded and the error is recorded. If it is qualified, it is transmitted to the PDUR layer for processing. The CAN diagnosis message request transmitted through the CAN transmission layer is received.

[0068] In step S20, the CAN diagnosis message request is converted into a LIN diagnosis message request.

[0069] It should be noted that the LIN message sending is realized by a scheduling table, and the scheduling table switching is realized through the interface provided by the BswM of AUTOSAR. Two buffers are provided for CAN-LIN ID message conversion to temporarily store the received and sent data. A session state machine is designed for the session, and the state machine is divided into Rx and Tx two sub-state machines.

[0070] In a specific implementation, after the CAN terminal receives the corresponding message, the CAN-LIN diagnosis needs to complete a complete cycle of CAN-LIN diagnosis, which requires the PDUR layer to be able to perform message unpacking, analysis, packet assembly, software internal state machine switching, sending verification and other operations on the CAN diagnosis message request, and when performing message conversion, the frame type determined by the frame judgment of the CAN transmission layer on the CAN diagnosis message request is used to determine the frame processing function; the length and usage state of the receiving buffer are determined based on the frame processing function; when the length of the receiving buffer is greater than the frame length of the CAN diagnosis message request, and the usage state of the receiving buffer is an idle state, the CAN diagnosis message request is stored in the receiving buffer, and the receiving buffer state is switched to an occupied state, and the session state of the receiving state machine is switched to a receiving in progress state; the session state of the sending state machine corresponding to the receiving state machine and the buffer state corresponding to the sending buffer corresponding to the receiving buffer are determined; when the session state of the sending state machine corresponding to the receiving state machine is an idle state, and the buffer state corresponding to the sending buffer corresponding to the receiving buffer is an idle state, the CAN diagnosis request message is converted to obtain a LIN diagnosis message request. Specifically, the CAN TP judges the diagnosis frame type, and executes the corresponding frame processing function, the PDUR is routed to the complex driver for processing, the length and usage state of the receiving buffer are judged, the Rx session receiving state is changed to RX INPROGRESS, the receiving buffer is set to occupied, the unpacked data is reassembled, it is judged whether the current Tx session sending state is TX_IDLE and whether the sending buffer is in an idle state, the corresponding basic software layer mode management module BswM interface is called to switch the dispatch table to a diagnosis request dispatch, and at the same time, the Tx session state is switched to the in progress state TX INPROGRESS, the Rx session state is switched to the finished state RX FINISHED, the sending buffer is occupied, the LINTP_Transmit() function is called, the sending is successful, the Tx session state is switched to TX_IDLE, the Rx session state is switched to RX_IDLE, the receiving and sending buffers are released, and the conversion of the CAN diagnosis message request to obtain the LIN diagnosis message request is completed.

[0071] Step S30, transmitting the LIN diagnosis message request to the LIN driver, and receiving the LIN diagnosis result fed back by the LIN driver according to the LIN diagnosis message request.

[0072] In a specific implementation, the LIN diagnostic message request is transmitted to a LIN transmission layer, the LIN diagnostic message request is transmitted to a LIN driver layer through the LIN transmission layer, so that the LIN driver layer generates a LIN diagnostic result according to the LIN diagnostic message request; and the LIN diagnostic result generated by the LIN driver layer according to the LIN diagnostic message request is received through the LIN transmission layer.

[0073] In step S40, the LIN diagnostic result is converted into a CAN diagnostic result, and the CAN diagnostic result is transmitted to the diagnostic instrument through a CAN driver.

[0074] It should be noted that the LIN message sending is implemented through a scheduling table, and the scheduling table switching is implemented through an interface provided by BswM of AUTOSAR. Two buffers are provided for the CAN-LIN ID message conversion to temporarily store the received and sent data, and a session state machine is designed for the session, and the state machine is divided into Rx and Tx two sub-state machines.

[0075] In a specific implementation, after receiving the LIN diagnosis result, to complete a complete cycle of CAN-LIN diagnosis, a frame processing function needs to be determined according to a frame type obtained by performing frame judgment on the LIN diagnosis result by the basic software layer mode management module; the length and the use state of the receiving buffer are determined based on the frame processing function; when the length of the receiving buffer is greater than the frame length of the LIN diagnosis result and the use state of the receiving buffer is an idle state, the LIN diagnosis result is stored in the receiving buffer, and the receiving buffer state is switched to an occupied state, and the session state of the receiving state machine is switched to a receiving in progress state; when the session state of the sending state machine corresponding to the receiving state machine is an idle state and the buffer state corresponding to the sending buffer corresponding to the receiving buffer is an idle state, the LIN diagnosis result is converted into a CAN diagnosis result, and the CAN diagnosis result is transmitted to the diagnosis instrument through the CAN drive. The BswM interface is called to switch the schedule table to a diagnosis slave node response schedule, the LIN TP judges the diagnosis frame type, and the corresponding frame processing function is executed, the PDUR is routed to the complex drive for processing, the length and the use state of the receiving buffer are judged, the Rx session receiving state is changed to RX INPROGRESS, the receiving buffer is occupied, the unpacked data is recombined, the Rx state is switched to RX FINISHED, and whether the Tx session sending state is TX IDLE and whether the sending buffer is idle are judged, the corresponding BswM interface is called to switch the schedule table to an application message schedule, the Tx session state is switched to TX INPROGRESS, the sending buffer is occupied, the CANIf_Transmit() is called to send the CAN message of the corresponding ID to the CAN, after the sending is successful, the Tx session state is switched to TX IDLE, the Rx session state is switched to Rx_IDLE, and the receiving and sending buffers are released. Refer to Figure 4 , Figure 4 The figure is a session state machine schematic diagram. When the receiving state machine is in an idle state, data can be received and the state is updated to a receiving in progress state, after all the saving is completed, the receiving state machine can be updated to a finished state, and data extraction, an input data pointer and a data length can be received, data can be copied to the sending buffer and a processing result can be returned. At this time, when the sending state machine is in an idle state, a sending task can be started according to a transmission request, the state is updated to an in progress state, a sending state is executed, an ID, sending data are input, the LIN schedule table is switched, a schedule table switching result is returned, and the state of the sending state machine is reset.

[0076] Refer to Figure 5 , Figure 5The data transmission flow chart is as follows. When the diagnostic instrument sends a CAN diagnostic message request, the CAN driver receives the CAN diagnostic message request and forwards it to the CANIF. After the CANIF receives the CAN diagnostic message request, it can be forwarded to the CANTP. After the CANTP receives the CAN diagnostic message request, it classifies the frame type of the CAN diagnostic message request and transmits the result to the PDU Routing. It is determined whether the receiving buffer is occupied. If the receiving buffer is occupied, NOK is returned. If the receiving buffer is not occupied, it is further determined whether the buffer is overflowed. If the buffer is overflowed, NOK is returned. Otherwise, the receiving buffer is set to be occupied, the receiving state machine is updated, data copying is performed, the receiving state machine and the sending state machine are updated, the sending buffer is set to be occupied, the LIN scheduling table is switched, the diagnostic scheduling table is switched, the buffer is released, the receiving and sending state machines are reset to the initial state, the LIN diagnostic scheduling sends the LIN diagnostic message, the LIN driver sends, and the LIN scheduling is switched to the scheduling table.

[0077] The embodiment provides a CAN-to-LIN diagnostic method based on AUTOSAR. When a gateway receives a CAN diagnostic message request sent by a diagnostic instrument, the CAN diagnostic message request transmitted through a CAN driver is received. The CAN diagnostic message request is converted into a LIN diagnostic message request. The LIN diagnostic message request is transmitted to a LIN driver, and a LIN diagnostic result fed back by the LIN driver according to the LIN diagnostic message request is received. The LIN diagnostic result is converted into a CAN diagnostic result, and the CAN diagnostic result is transmitted to the diagnostic instrument through the CAN driver, thereby saving the development cost of a LIN diagnostic host computer, and realizing CAN and LIN controller diagnostic functions through the CAN host computer.

[0078] It should be noted that the above examples are only used for understanding the present application and do not constitute a limitation on the CAN-to-LIN diagnostic method based on AUTOSAR of the present application. More forms of simple transformation based on the technical concept are within the protection scope of the present application.

[0079] The present application also provides a CAN-to-LIN diagnostic device based on AUTOSAR. Please refer to Figure 6 The CAN-to-LIN diagnostic device based on AUTOSAR comprises:

[0080] The message request module 10 receives the CAN diagnostic message request transmitted through the CAN driver when the gateway receives the CAN diagnostic message request sent by the diagnostic instrument.

[0081] The message conversion module 20 is configured to convert the CAN diagnostic message request into a LIN diagnostic message request.

[0082] The message transmission module 30 is configured to transmit the LIN diagnosis message request to a LIN driver and receive LIN diagnosis results fed back by the LIN driver according to the LIN diagnosis message request.

[0083] The result feedback module 40 is configured to convert the LIN diagnosis results into CAN diagnosis results and transmit the CAN diagnosis results to the diagnosis instrument through a CAN driver.

[0084] In an embodiment, the message request module 10 is further configured to, when the gateway receives a CAN diagnosis message request sent by a diagnosis instrument, transmit the CAN diagnosis message request to a CAN transmission layer through a CAN interface layer; acquire a format checking result of the CAN diagnosis message request by the CAN transmission layer, and receive the CAN diagnosis message request transmitted by the CAN transmission layer when the checking result is qualified.

[0085] In an embodiment, the message conversion module 20 is further configured to store the CAN diagnosis message request in a receiving buffer, switch a state of the receiving buffer to an occupied state, and switch a session state of a receiving state machine to a receiving performing state; determine a session state of a sending state machine corresponding to the receiving state machine and a buffer state corresponding to a sending buffer corresponding to the receiving buffer; when the session state of the sending state machine corresponding to the receiving state machine is an idle state and the buffer state corresponding to the sending buffer corresponding to the receiving buffer is an idle state, convert the CAN diagnosis request message to obtain a LIN diagnosis message request.

[0086] In an embodiment, the message conversion module 20 is further configured to determine a frame processing function according to a frame type obtained by frame judgment of the CAN transmission layer on the CAN diagnosis message request; determine a length and a use state of a receiving buffer based on the frame processing function; when the length of the receiving buffer is greater than a frame length of the CAN diagnosis message request and the use state of the receiving buffer is an idle state, store the CAN diagnosis message request in the receiving buffer and switch a state of the receiving buffer to an occupied state, and switch a session state of a receiving state machine to a receiving performing state.

[0087] In an embodiment, the message transmission module 30 is further configured to transmit the LIN diagnosis message request to a LIN transmission layer, transmit the LIN diagnosis message request to a LIN driver layer through the LIN transmission layer, so that the LIN driver layer generates LIN diagnosis results according to the LIN diagnosis message request; and receive the diagnosis results generated by the LIN driver layer according to the LIN diagnosis message request through the LIN transmission layer.

[0088] In an embodiment, the result returning module 40 is further configured to store the LIN diagnostic result into a receiving buffer, switch a state of the receiving buffer to an occupied state, and switch a session state of a receiving state machine to a receiving performing state; determine a session state of a sending state machine corresponding to the receiving state machine and a buffer state of a sending buffer corresponding to the receiving buffer; when the session state of the sending state machine corresponding to the receiving state machine is an idle state and the buffer state of the sending buffer corresponding to the receiving buffer is an idle state, perform packet conversion on the LIN diagnostic result to obtain a CAN diagnostic result, and transmit the CAN diagnostic result to the diagnostic instrument through a CAN driver.

[0089] In an embodiment, the result returning module 40 is further configured to determine a frame processing function according to a frame type obtained by performing frame judgment on the LIN diagnostic result by the basic software layer mode management module; determine a length and a use state of a receiving buffer based on the frame processing function; when the length of the receiving buffer is greater than a frame length of the LIN diagnostic result and the use state of the receiving buffer is an idle state, store the LIN diagnostic result into the receiving buffer, and switch a state of the receiving buffer to an occupied state, and switch a session state of a receiving state machine to a receiving performing state.

[0090] The CAN-to-LIN diagnostic device based on AUTOSAR provided in the application adopts the CAN-to-LIN diagnostic method based on AUTOSAR in the above embodiments, and can solve the technical problem that the software communication protocol and the hardware wire harness for adapting LIN diagnosis need to be designed separately for the diagnostic instrument and the whole vehicle. Compared with the prior art, the CAN-to-LIN diagnostic device based on AUTOSAR provided in the application has the same beneficial effects as the CAN-to-LIN diagnostic method based on AUTOSAR provided in the above embodiments, and other technical features in the CAN-to-LIN diagnostic device based on AUTOSAR are the same as the features disclosed in the above method embodiments, which will not be described here.

[0091] The application provides a CAN-to-LIN diagnostic device based on AUTOSAR, which comprises at least one processor and a memory in communication connection with the at least one processor; the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the CAN-to-LIN diagnostic method based on AUTOSAR in the above embodiment one.

[0092] Reference will be made to the drawings below Figure 7This document illustrates a structural schematic diagram of an AUTOSAR-based CAN-to-LIN diagnostic device suitable for implementing embodiments of this application. The AUTOSAR-based CAN-to-LIN diagnostic device in this application embodiment may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital radio receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), and in-vehicle terminals (e.g., in-vehicle navigation terminals), as well as fixed terminals such as digital TVs and desktop computers. Figure 7 The AUTOSAR-based CAN-to-LIN diagnostic device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments in this application.

[0093] like Figure 7 As shown, the AUTOSAR-based CAN-to-LIN diagnostic device may include a processing unit 1001 (e.g., a central processing unit, graphics processor, etc.), which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1002 or a program loaded from storage device 1003 into random access memory (RAM) 1004. RAM 1004 also stores various programs and data required for the operation of the AUTOSAR-based CAN-to-LIN diagnostic device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via bus 1005. Input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the AUTOSAR-based CAN-to-LIN diagnostic device to exchange data with other devices wirelessly or via wired communication. Although the figure shows an AUTOSAR-based CAN-to-LIN diagnostic device with various systems, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems can be implemented alternatively.

[0094] In particular, according to the embodiments disclosed in the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present application include a computer program product comprising a computer program carried on a computer readable medium, the computer program containing program codes for executing the method shown in the flowchart. In such embodiments, the computer program can be downloaded and installed from a network through a communication device, or installed from the storage device 1003, or installed from the ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiments disclosed in the present application are executed.

[0095] The AUTOSAR-based CAN-to-LIN diagnostic device provided by the present application adopts the AUTOSAR-based CAN-to-LIN diagnostic method in the above embodiments, and can solve the technical problem that the software communication protocol and the hardware wire harness of the diagnostic instrument and the whole vehicle need to be designed separately to adapt to LIN diagnosis. Compared with the prior art, the AUTOSAR-based CAN-to-LIN diagnostic device provided by the present application has the same beneficial effects as the AUTOSAR-based CAN-to-LIN diagnostic method provided by the above embodiments, and other technical features in the AUTOSAR-based CAN-to-LIN diagnostic device are the same as the features disclosed in the above embodiment method, which will not be repeated here.

[0096] It should be understood that various parts of the present application can be realized by hardware, software, firmware or a combination thereof. In the description of the above embodiments, specific features, structures, materials or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0097] The above describes only the specific implementation of the present application, but the protection scope of the present application is not limited thereto, and any person skilled in the art can easily think of changes or replacements within the technical scope disclosed in the present application, which should be covered within the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

[0098] The present application provides a computer readable storage medium having stored thereon computer readable program instructions (i.e., computer programs) for executing the AUTOSAR-based CAN-to-LIN diagnostic method in the above embodiments.

[0099] The computer readable storage medium provided in the application may be, for example, a U disk, but is not limited to an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, system, or device, or any combination of the above. More specific examples of the computer readable storage medium may include, but are not limited to, an electrical connection with one or more conductive wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the embodiment, the computer readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, system, or device. The program code contained on the computer readable storage medium can be transmitted by any suitable medium, including but not limited to an electrical wire, an optical cable, an RF (Radio Frequency), and the like, or any suitable combination of the above.

[0100] The computer readable storage medium described above can be contained in the AUTOSAR-based CAN-to-LIN diagnostic device, or can exist separately without being assembled into the AUTOSAR-based CAN-to-LIN diagnostic device.

[0101] The computer readable storage medium described above carries one or more programs, which, when executed by the AUTOSAR-based CAN-to-LIN diagnostic device, cause the AUTOSAR-based CAN-to-LIN diagnostic device to:

[0102] When the gateway receives the CAN diagnostic message request sent by the diagnostic instrument, the CAN diagnostic message request transmitted by the CAN driver is received;

[0103] The CAN diagnostic message request is converted into a LIN diagnostic message request;

[0104] The LIN diagnostic message request is transmitted to the LIN driver, and the LIN diagnostic result fed back by the LIN driver according to the LIN diagnostic message request is received;

[0105] The LIN diagnostic result is converted into a CAN diagnostic result, and the CAN diagnostic result is transmitted to the diagnostic instrument through the CAN driver.

[0106] Computer program code for carrying out operations of the present application can be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code can execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computer (for example, through the Internet using an Internet Service Provider).

[0107] The flow diagrams and the block diagrams in the drawings are illustrations of architectures, functionalities, and operations of possible implementations of systems, methods, and computer program products according to various embodiments of the present application. In this regard, each block in the flow diagrams or block diagrams can represent a module, a segment, or a 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 blocks can 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

[0108] The modules involved in the embodiments of the present application can be implemented in the form of software or in the form of hardware. In some cases, the name of the module does not constitute a limitation on the module itself.

[0109] The readable storage medium provided by the present application is a computer readable storage medium, which stores computer readable program instructions (i.e., a computer program) for executing the above-mentioned AUTOSAR-based CAN-to-LIN diagnosis method, and can solve the technical problem that the current diagnosis instrument and the whole vehicle need to be designed separately to adapt to the software communication protocol and the hardware wire harness of LIN diagnosis. Compared with the prior art, the computer readable storage medium provided by the present application has the same beneficial effects as the AUTOSAR-based CAN-to-LIN diagnosis method provided by the above-mentioned embodiments, and will not be described here.

[0110] The application also provides a computer program product comprising a computer program which, when executed by a processor, implements the steps of the AUTOSAR-based CAN-to-LIN diagnosis method as described above.

[0111] The computer program product provided by the application can solve the technical problem that the software communication protocol and the hardware wire harness of the diagnosis instrument and the whole vehicle need to be designed separately to adapt to LIN diagnosis. Compared with the prior art, the beneficial effects of the computer program product provided by the application are the same as those of the AUTOSAR-based CAN-to-LIN diagnosis method provided by the above-described embodiments, and are not described herein.

[0112] The above only describes some embodiments of the application, and does not limit the patent scope of the application. Any equivalent structural transformation, direct / indirect application in other related technical fields, or the like made by using the content of the specification and drawings within the technical concept of the application is included in the patent protection scope of the application.

Claims

1. An AUTOSAR-based CAN-to-LIN diagnostic method, characterized in that, The AUTOSAR-based CAN-to-LIN diagnosis method comprises the following steps: When the gateway receives a CAN diagnosis message request sent by a diagnosis instrument, the gateway receives the CAN diagnosis message request transmitted through a CAN driver; The CAN diagnosis message request is converted into a LIN diagnosis message request; The LIN diagnosis message request is transmitted to a LIN driver, and a LIN diagnosis result fed back by the LIN driver according to the LIN diagnosis message request is received; The LIN diagnosis result is converted into a CAN diagnosis result, and the CAN diagnosis result is transmitted to the diagnosis instrument through the CAN driver; The step of converting the CAN diagnosis message request into the LIN diagnosis message request comprises the following steps: The CAN diagnosis message request is stored in a receiving buffer, and a state of the receiving buffer is switched to an occupied state, and a session state of a receiving state machine is switched to a receiving state; A session state of a sending state machine corresponding to the receiving state machine and a buffer state corresponding to a sending buffer corresponding to the receiving buffer are determined; When the session state of the sending state machine corresponding to the receiving state machine is an idle state, and the buffer state corresponding to the sending buffer corresponding to the receiving buffer is also an idle state, the CAN diagnosis request message is converted into the LIN diagnosis message request.

2. The method of claim 1, wherein, The step of receiving the CAN diagnosis message request transmitted through the CAN driver when the gateway receives the CAN diagnosis message request sent by the diagnosis instrument comprises the following steps: When the gateway receives the CAN diagnosis message request sent by the diagnosis instrument, the CAN diagnosis message request is transmitted to a CAN transmission layer through a CAN interface layer; A format checking result of the CAN diagnosis message request by the CAN transmission layer is obtained, and when the checking result is qualified, the CAN diagnosis message request transmitted through the CAN transmission layer is received.

3. The method of claim 2, wherein, The step of storing the CAN diagnosis message request in the receiving buffer, switching the state of the receiving buffer to the occupied state, and switching the session state of the receiving state machine to the receiving state comprises the following steps: A frame type is determined according to a frame judgment result of the CAN diagnosis message request by the CAN transmission layer; A length and a use state of the receiving buffer are determined based on the frame processing function; When the length of the receiving buffer is greater than a frame length of the CAN diagnosis message request, and the use state of the receiving buffer is an idle state, the CAN diagnosis message request is stored in the receiving buffer, the state of the receiving buffer is switched to the occupied state, and the session state of the receiving state machine is switched to the receiving state.

4. The method of claim 1, wherein, The step of transmitting the LIN diagnosis message request to the LIN driver and receiving the LIN diagnosis result fed back by the LIN driver according to the LIN diagnosis message request comprises the following steps: transmitting the LIN diagnosis message request to a LIN transmission layer, and transmitting the LIN diagnosis message request to a LIN driver layer through the LIN transmission layer, so that the LIN driver layer generates a LIN diagnosis result according to the LIN diagnosis message request; receiving the diagnosis result generated by the LIN driver layer according to the LIN diagnosis message request through the LIN transmission layer.

5. The method of claim 1, wherein, The step of converting the LIN diagnosis result into a message to obtain a CAN diagnosis result, and transmitting the CAN diagnosis result to the diagnosis instrument through a CAN driver includes: storing the LIN diagnosis result in a receiving buffer, switching a receiving buffer state to an occupied state, and switching a session state of a receiving state machine to a receiving performing state; determining a session state of a sending state machine corresponding to the receiving state machine and a buffer state corresponding to a sending buffer corresponding to the receiving buffer; when the session state of the sending state machine corresponding to the receiving state machine is an idle state and the buffer state corresponding to the sending buffer corresponding to the receiving buffer is an idle state, converting the LIN diagnosis result into a message to obtain a CAN diagnosis result, and transmitting the CAN diagnosis result to the diagnosis instrument through a CAN driver.

6. The method of claim 5, wherein, The step of storing the LIN diagnosis result in a receiving buffer, switching a receiving buffer state to an occupied state, and switching a session state of a receiving state machine to a receiving performing state includes: determining a frame processing function according to a frame type obtained by performing frame judgment on the LIN diagnosis result by a basic software layer mode management module; determining a length and a use state of a receiving buffer based on the frame processing function; when the length of the receiving buffer is greater than a frame length of the LIN diagnosis result and the use state of the receiving buffer is an idle state, storing the LIN diagnosis result in the receiving buffer, switching the receiving buffer state to the occupied state, and switching the session state of the receiving state machine to the receiving performing state.

7. An AUTOSAR-based CAN-to-LIN diagnostic device, characterized by The device includes: a message request module configured to receive a CAN diagnosis message request transmitted through a CAN driver when a gateway receives the CAN diagnosis message request issued by a diagnosis instrument; a message conversion module configured to convert the CAN diagnosis message request into a LIN diagnosis message request; a message transmission module configured to transmit the LIN diagnosis message request to a LIN driver, and receive a LIN diagnosis result fed back by the LIN driver according to the LIN diagnosis message request; a result feedback module configured to convert the LIN diagnosis result into a CAN diagnosis result, and transmit the CAN diagnosis result to the diagnosis instrument through a CAN driver; The step of converting the CAN diagnosis message request into a LIN diagnosis message request includes: storing the CAN diagnosis message request in a receiving buffer, switching a receiving buffer state to an occupied state, and switching a session state of a receiving state machine to a receiving performing state; determining a session state of a sending state machine corresponding to the receiving state machine and a buffer state of a sending buffer corresponding to the receiving buffer; when the session state of the sending state machine corresponding to the receiving state machine is an idle state and the buffer state of the sending buffer corresponding to the receiving buffer is an idle state, performing message conversion on the CAN diagnostic request message to obtain a LIN diagnostic message request.

8. An AUTOSAR-based CAN-to-LIN diagnostic device, characterized by The device comprises a memory, a processor, and a computer program stored on the memory and executable on the processor, and the computer program is configured to implement the steps of the AUTOSAR-based CAN-to-LIN diagnostic method according to any one of claims 1 to 6.

9. A storage medium, characterized by The storage medium is a computer-readable storage medium, and the storage medium stores a computer program, and the computer program is executed by a processor to implement the steps of the AUTOSAR-based CAN-to-LIN diagnostic method according to any one of claims 1 to 6.

Images