A can / lin communication analysis method and device

Abstract

The application discloses a CAN / LIN communication analysis method, comprising the following steps: information collection, test script writing, script execution, CAN / LIN communication test and output of product internal state information. The application can simultaneously test multiple products by adopting two-way CAN and two-way LIN, supports user programming, can improve test efficiency, facilitates on-site debugging and product quick change requirements, is provided with an RS485 communication interface, can support control of external equipment or power supply, realizes automatic test requirements, can complete all tests without relying on other host equipment, facilitates quick deployment on a production line, is simultaneously provided with four-way PWM driving signal sources, can conveniently drive LED and brush DC motors, and is provided with eight output ports and eight input ports, all of which can be controlled through programming.

Description

Technical Field

[0001] This research belongs to the field of communication testing technology, and involves a CAN / LIN communication analysis method and device. Background Technology

[0002] With the continuous advancement of automotive electronics technology, the application of CAN and LIN communication technologies is becoming increasingly widespread, leading to a rapid increase in the demand for color codes for these two communication protocols. However, current testing tools on the market generally share a common limitation: they require the installation of dedicated host computer testing software to operate. This method affects the flexibility of product debugging and testing. Furthermore, most testing equipment cannot communicate with external variable programmable power supplies.

[0003] Regarding the external device collaboration capabilities of existing testing equipment, the vast majority of devices cannot establish an effective communication connection with external programmable power supplies. This makes it difficult for the test system to achieve coordinated control of power supply parameters and communication protocol testing. Even if a few tools are equipped with programmable power supply functions, they can only provide a very small current output, which cannot meet the power supply requirements under complex test scenarios. Furthermore, they cannot achieve flexible control of external programmable power supplies through secondary programming. This makes it difficult to complete the dynamic adjustment of power supply parameters and the synchronous verification of communication performance testing during the test process.

[0004] In terms of automated testing, the lack of collaborative communication capabilities with external devices and programmable control interfaces often necessitates manual intervention in aspects such as parameter setting, data acquisition, and status judgment during the testing process, making it impossible to build a fully automated testing loop. This semi-manual mode not only significantly reduces testing efficiency but also makes it susceptible to human error affecting the consistency and accuracy of test results.

[0005] Faced with increasingly complex testing scenarios and ever-increasing accuracy requirements, the overall performance of existing testing methods is no longer sufficient to meet practical needs. As the functions of automotive electronic systems become more diversified, the testing dimensions for CAN and LIN communication protocols are constantly expanding. However, the inherent deficiencies of traditional tools in terms of flexibility, collaboration, and automation make them inadequate in dealing with demands such as multi-parameter concurrent testing and dynamic scenario simulation, failing to provide comprehensive and efficient testing assurance for complex electronic systems. Summary of the Invention

[0006] The present invention aims to solve the problems of existing CAN / LIN communication test equipment, such as reliance on host computer software, lack of automation capabilities, and inability to effectively coordinate with external devices.

[0007] The objective of this invention can be achieved through the following technical solutions:

[0008] This invention discloses a CAN / LIN communication analysis method, comprising the following steps:

[0009] Information Acquisition: Completes LDF / DBC file parsing, obtains LIN / CAN message information, and performs device driver initialization.

[0010] Write test scripts: Based on the collected LIN / CAN message information and usage requirements, complete the test script writing;

[0011] Execution script: Performs communication tests on CAN / LIN products. During the test script execution, it acquires GPIO input status, PWM output control, external power supply control, and GPIO output status through multiple selections, one selection, or ignoring. This information is then fed back to the CAN / LIN communication test stage to assist in the communication testing of CAN / LIN products. This feedback mechanism optimizes communication efficiency by dynamically adjusting the CAN / LIN message transmission frequency through real-time monitoring of GPIO input status.

[0012] CAN / LIN Communication Test: Sending and receiving CAN / LIN message data generated during communication tests of CAN / LIN products, and parsing CAN / LIN message data;

[0013] Output product internal status information: Based on the parsed CAN / LIN message data, obtain the internal status parameters that characterize the actual operating status of the CAN / LIN product, including whether the CAN / LIN product can process the received commands, whether self-learning is normal, whether the internal voltage and temperature are normal, and the motor position information.

[0014] Preferably, the LIN / CAN message information includes message length, signal name in the message, signal size and signal offset position, and message delay time.

[0015] Preferably, the LIN / CAN message information is displayed on the screen in an array for easy real-time signal observation.

[0016] Preferably, when parsing the LDF file, information collection also includes: obtaining the LIN protocol version parameter in the LDF file to provide a basis for verifying LIN messages;

[0017] The communication baud rate parameters are retrieved from the LDF file and used to initialize the LIN physical layer. Simultaneously, the communication baud rate parameters are saved into the LIN message information data.

[0018] Preferably, the LIN protocol version parameter uses LIN 1.3 or earlier, and classic checksum is used for message verification. If the LIN protocol version is 2.0 or later, enhanced checksum is used, but classic checksum is maintained for diagnostic messages. Classic checksum does not verify the message ID, only the data field. Enhanced checksum verifies both the message ID and the data field. The verification method is to perform binary addition with carry on each byte of the verification object (subtracting 255 whenever the result is greater than or equal to 256), and then inverting each bit of the final sum. This result is used as the checksum to be sent. The receiver performs the same binary addition with carry on the received data according to the checksum type, without inverting each bit of the final sum, and adds the final sum to the received checksum. If the result is 0xFF, the checksum is correct, which to a certain extent ensures the correctness of data transmission. Simultaneously, the LIN protocol version parameter is saved in the message information data.

[0019] Preferably, when testing LIN product components, corresponding LIN command messages are sent. After receiving the message, the LIN product component executes the corresponding command. To obtain the internal parameters of the LIN product component, the header of the LIN product component feedback message needs to be sent first, and then the LIN product component message data field is received. After the reception is completed, this message data is combined with the LDF file for data parsing to obtain the internal status and parameters of the component, and the corresponding signal values ​​are displayed on the screen to help users understand the actual status of the product.

[0020] Preferably, when testing CAN product components, corresponding CAN command messages are sent. Upon receiving the messages, the CAN product components execute the corresponding commands. When a feedback message is received from a CAN product component, it is parsed in conjunction with a DBC file to obtain the internal status parameters of the CAN product component, and the corresponding signal values ​​are displayed on the screen to help users understand the actual status of the product.

[0021] An electronic device includes a memory, a processor, and a PWM power supply, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the CAN / LIN communication analysis method.

[0022] Preferably, the electronic device is equipped with 8 input GPIO ports and 8 output GPIO ports, 2 CAN channels and 2 LIN channels, which, according to product testing needs, replace the PLC to provide corresponding process control signals and corresponding test result indications or status indications.

[0023] The electronic device is equipped with 4 PWM output signals, and the PWM power supply is available in 5V and 12V versions as needed. These PWM signals can provide PWM signal sources for LED lights, DC brushed motors, etc.

[0024] By employing the above technical solution, the present invention provides a CAN / LIN communication analysis method and device, which has at least the following beneficial effects:

[0025] This invention employs 2-channel CAN and 2-channel LIN, enabling simultaneous testing of multiple products. It supports user programming, allowing for easy completion of related functions through simple programming, thus improving testing efficiency and facilitating on-site debugging and rapid product changeover. It also features an RS485 communication interface, supporting control of external devices or power supplies to achieve automated testing. All tests can be completed without relying on other main control equipment, facilitating rapid deployment on production lines. Furthermore, it includes 4-channel PWM drive signal sources for convenient driving of LEDs and brushed DC motors, and features 8 output ports and 8 input ports, all of which can be controlled via programming.

[0026] By optimizing the collaborative communication capabilities of the equipment and setting up a standardized programmable control interface, this invention realizes fully automated operation of parameter setting, data acquisition, status judgment and other links in the test process. The entire test process can be completed without manual intervention. This improvement completely changes the drawbacks of the traditional semi-manual mode. It not only significantly improves test efficiency and reduces test result deviations caused by human operation errors, but also ensures the consistency and accuracy of test results in different batches and different scenarios, reduces labor costs and time costs, and provides reliable support for large-scale and high-frequency test needs.

[0027] Addressing the challenges of expanding testing dimensions for CAN and LIN communication protocols due to the diversification of automotive electronic system functions, this invention leverages its advantages in flexibility, collaboration, and automation to easily handle complex testing requirements such as multi-parameter concurrent testing and dynamic scenario simulation. Whether simulating dynamic scenarios like power fluctuations and communication load changes during vehicle operation, or conducting concurrent testing of multiple protocols and nodes, this solution provides stable and efficient testing assurance, offering comprehensive technical support for the research and verification of complex electronic systems and helping to improve the reliability and safety of automotive electronic systems. Attached Figure Description

[0028] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0029] Figure 1 This is a schematic diagram of the principle framework of the CAN / LIN communication analysis method in this invention;

[0030] Figure 2 This is a schematic diagram of a scenario in which the vehicle is actually tested in this invention;

[0031] Figure 3 This is a schematic diagram illustrating a scenario where an actual test is conducted on a single component in this invention;

[0032] Figure 4 This is a schematic diagram showing the interface and components of the testing equipment in this invention;

[0033] Figure 5 This is a diagram illustrating the message signal array in this invention. Detailed Implementation

[0034] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0035] Please refer to Figure 1 This embodiment proposes a CAN / LIN communication analysis method, which includes steps such as information acquisition, test script writing, script execution, CAN / LIN communication testing, and outputting product internal status information. The device has two CAN interfaces and two LIN interfaces, supports user programming, and can control external devices via RS485 to achieve automated testing. It is equipped with four PWM signal sources and 16 GPIO ports, capable of driving LEDs and brushed DC motors, making it suitable for rapid deployment on production lines. Details are as follows:

[0036] Information Acquisition: Completes LDF / DBC file parsing, obtains LIN / CAN message information, and performs device driver initialization.

[0037] Write test scripts: Based on the collected LIN / CAN message information and usage requirements (such as ambient light testing, motor testing, door handle product testing, etc.), complete the test script writing;

[0038] Execution script: Performs communication tests on CAN / LIN products. During the test script execution, operators can manually select multiple or one items, or ignore them, to perform the following operations: obtaining GPIO input status, PWM output control, controlling external power supply, and controlling GPIO output status. These operations are fed back to the CAN / LIN communication test stage to assist in the communication testing of CAN / LIN products. This feedback mechanism optimizes communication efficiency by dynamically adjusting the CAN / LIN message transmission frequency through real-time monitoring of GPIO input status.

[0039] CAN / LIN Communication Test: Sending and receiving CAN / LIN message data generated during communication tests of CAN / LIN products, and parsing CAN / LIN message data;

[0040] Output product internal status information: Based on the parsed CAN / LIN message data, obtain internal status parameters that characterize the actual operating status of the CAN / LIN product, including whether the CAN / LIN product can process the received commands, whether self-learning is normal, whether the internal voltage and temperature are normal, and the position information of the motor for motor-type products, etc.

[0041] This invention can load LDF / DBC files of vehicle components. When loading an LDF / DBC file, it first links to the LDF / DBC file stored on a USB drive or device, then parses it according to the LDF / DBC file format and saves it into the corresponding message information data, thus completing the signal acquisition of the message. The LIN / CAN message information includes the message ID, message length, signal name in the message, signal size and signal offset position, and message delay time. Subsequent reading or writing of this data is equivalent to reading or writing the message itself.

[0042] Please refer to Figure 5 As needed, users can click on the part before the message name. The signals in the message will be displayed on the screen in an array for easy real-time observation. For messages sent by this device, a pen icon indicates that the signal value can be edited; simply click to input the value using the keyboard. Once the signal value is set, the message will be updated immediately, sent to the bus, and displayed in the corresponding data field. For messages received by this device, when the device receives the corresponding message, it will display the data in the corresponding data field. As needed, you can click the icon before the message name. Use the icon to view the actual status of each signal value in the message.

[0043] When parsing an LDF file, information collection also includes: obtaining the LIN protocol version parameters from the LDF file to provide verification for LIN messages; obtaining the communication baud rate parameters from the LDF file to initialize the LIN physical layer; and saving the communication baud rate parameters into the message information data.

[0044] The LIN protocol version parameters used are LIN 1.3 and earlier versions, employing classic checksum verification. If the LIN protocol version is 2.0 or later, enhanced checksum verification is used. However, diagnostic messages retain classic checksum verification. Classic checksum verification only checks the data field, not the message ID. Enhanced checksum verification checks both the message ID and the data field. The verification method involves performing binary addition with carry on each byte of the checksum object (subtracting 255 whenever the result is greater than or equal to 256), and then inverting each bit of the final sum. This result is used as the checksum to be sent. The receiver performs the same binary addition with carry on the received data, without inverting each bit of the final sum, and adds this final sum to the received checksum. If the result is 0xFF, the checksum is correct, which to some extent ensures the correctness of data transmission. The LIN protocol version parameters are also saved in the message information data.

[0045] When sending a LIN message, first copy the message ID and data field into the transmission data buffer, then call the LIN message sending main function to send the LIN message onto the bus.

[0046] When sending a CAN message, first copy the message ID and data field into the transmission data buffer, then call the CAN message sending main function to send the CAN message onto the bus.

[0047] For LIN product testing, if this device only sends the header and needs to receive the data in the feedback message, it first sends the header and then immediately enters the data receiving state. Once the feedback message data has been received, it verifies the data. If the data verification is successful, a successful reception flag is set, indicating a message update task and a new message requiring processing. This updates the data field associated with the message on the screen. If needed, this can be done by clicking the button before the message name. The system retrieves the corresponding signal bit field from the relevant byte, assigns it to the LIN signal, and updates the signal value associated with the message on the screen. Users can also perform some logical applications based on the received message data.

[0048] When this device receives a CAN product feedback message, it will update the data field associated with that message on the screen. If needed, you can click on the area in front of the message name. The icon will extract the corresponding signal bit field from the byte, assign it to the CAN signal, and update the signal value associated with the message on the screen. Users can also perform some logical applications based on the received message data.

[0049] In this embodiment, the LIN message sending entry main function is:

[0050] voID mlinTask Func(u8 linx,mlinFrameMode_Def Task_t)

[0051] {

[0052] if(Lin Mode[linx] == Maste_Mode)

[0053] {

[0054] switch(Task_t)

[0055] {

[0056] case mNo Task:

[0057] break;

[0058] case mx Header:

[0059] mLin Task[linx]:mTx Header i

[0060] Lin sendBreak(linx);

[0061] break;

[0062] case mx Message:

[0063] mLin Task[linx]= mTx Message;

[0064] / ****calculate checksum**** /

[0065] Erm mDatallinxl[len mData[linx,+1] = lin checksum(linx, FrmmDatallinxl,len mDatallinx1);

[0066] Lin sendBreak(linx);

[0067] Break;

[0068] }

[0069] }

[0070] }

[0071] The Break field, synchronization signal, message ID, data field, and checksum are sent sequentially. After each transmission is completed, the interrupt function is entered. In the interrupt function, you only need to set the value of the next byte to be sent.

[0072] The main function for sending CAN messages is:

[0073] voID CAN TxMessageHandle(u8 *msg)

[0074] {

[0075] u8 i;

[0076] u8 mbox;

[0077] CAN ArbitrationControlField _Def CAN ACF;

[0078] CanTxMsg TxMessage;

[0079] CAN_ACF.Byte[O] = msg[l];

[0080] TxMessage.IDE = CAN ACF.Bits.IDE;

[0081] TxMessage.RTR = CAN ACF.Bits.RTR;

[0082] TxMessage.DLC = CAN ACF.Bits.dlc;

[0083] if(CAN _ACF.Bits.IDE == STANDARD_ID) (

[0085] TxMessage.StdID = (uint32_t) (msg[2]<<8) + (uint32_t) (msg[3]<<0); )

[0087] else(

[0088] TxMessage.ExtID = (uint32_t) (msg[2]<<24) + (uint32_t) (msg[3]<<16) +\

[0089] (uint32_t) (msg[4]<<8) + (uint32_t) (msg[5]<<0);

[0090] }

[0091] if(CAN ACF.Bits.RTR == DATA_FRAME)

[0092] {

[0093] if(CAN _ACF.Bits.IDE == STANDARD_ID)

[0094] {

[0095] for(i=0,i<TxMessage.DLC;i++){

[0096] TxMessage.Data[i] = msg[5+i];

[0097] }

[0098] }

[0099] Else{

[0100] for(i=O;i<TxMessage.DLC;i++){

[0101] TxMessage.Data[i] = msg[7+i];

[0102] }

[0103] }

[0104] }

[0105] if(CAN ACF.Bits.chanSel == 0)

[0106] {

[0107] mbox= CAN_Transmit (CAN1, &TxMessage);

[0108] }

[0109] else if(CAN _ACF.Bits.chanSel == 1)

[0110] {

[0111] mbox= CAN_Transmit(CAN2,TxMessage);

[0112] }

[0113] }

[0114] When a CAN message is written into the CAN transmit register, the hardware will complete the message transmission task.

[0115] like Figure 2 As shown, in a real-vehicle application test scenario: it can monitor messages on the CAN / LIN bus as needed, and display the signal values ​​on the screen after message parsing; it can record messages on the CAN / LIN bus and replay them for later detailed analysis; it can send diagnostic messages to obtain product information of product components, such as part numbers and software version numbers.

[0116] Please see Figure 3 When testing LIN product components, the corresponding LIN command messages are sent. After receiving the messages, the LIN product components execute the corresponding commands. To obtain the internal parameters of the LIN product components, the header of the LIN product component feedback message needs to be sent first, and then the LIN product component message data field is received. After the reception is completed, the message data is combined with the LDF file for data parsing to obtain the internal status parameters of the LIN product components, and the corresponding signal values ​​are displayed on the screen so that users can understand the actual status of the product.

[0117] Users can also monitor or record bus messages as needed, perform message playback or detailed message analysis, and understand the actual situation of the product during the testing process.

[0118] Users can also send diagnostic messages as needed to obtain product information of product components, such as part numbers, software version numbers, or other diagnostic services.

[0119] The product has an RS485 communication interface and supports the Modbus communication protocol. Users can write scripts to set the voltage and current of an external programmable power supply according to their actual needs. The command message for setting the external power supply includes the external power supply device address, the target register address, and the target voltage or current value. To retrieve the external power supply's parameters, a corresponding read command message can be sent to read its status parameters, thus determining whether the external power supply has been successfully set or its actual usage.

[0120] If it is necessary to test the product's operation under different voltages, the voltage and current can be adjusted according to time or events to achieve automated testing.

[0121] When testing CAN product components, corresponding CAN command messages are sent. Upon receiving the messages, the CAN product components execute the corresponding commands. When receiving feedback messages from the CAN product components, the system parses the data using the DBC file to obtain the internal status parameters of the CAN product components and displays the corresponding signal values ​​on the screen to help users understand the actual status of the product.

[0122] This embodiment also provides an electronic device, including a memory, a processor, and a PWM power supply, a computer program stored in the memory and executable on the processor, and the processor executing the computer program to implement the CAN / LIN communication analysis method proposed in this embodiment.

[0123] The electronic device is equipped with 8 input GPIO ports and 8 output GPIO ports, 2 CAN channels and 2 LIN channels. Depending on product testing needs, it replaces the PLC to provide corresponding process control signals and corresponding test result or status indicators. Furthermore, the electronic device is equipped with 4 PWM output signals, and the PWM power supply can be configured with either 5V or 12V. These PWM signals can provide PWM signal sources for LED lights, DC brushed motors, etc. The electronic device also features 2 CAN channels and 2 LIN channels.

[0124] like Figure 4 The diagram shown is a schematic representation of the interface and components of an electronic device, in which:

[0125] A is a capacitive touch screen: enabling monitoring and control of the device, and allowing users to interact with the device.

[0126] B is a schematic diagram of the device's rear panel interfaces, which includes the following port components:

[0127] DC power input terminal 1 provides operating power to the device, using a 2-pin terminal block, model: KF2EDGRC-5.08 2P.

[0128] External programmable power supply control terminal 2 communicates via RS485 and can be used to set the voltage and maximum current of the external power supply, as well as read the internal operating status of the external programmable power supply. It uses a 3-pin terminal block, model: KF2EDGRC-5.08 3P.

[0129] DB25 male terminal 3: Its internal pin function definitions are shown in Table 1:

[0130] Table 1 Internal Pin Function Definitions for DB25 Male Connector

[0131]

[0132] The device includes two CAN channels, two LIN channels, an external power input, and eight input ports.

[0133] C: Diagram of the front panel interface of the device, which includes the following port components:

[0134] DB15 male terminal 10: Its internal pin function definitions are shown in Table 2.

[0135] Table 2 Internal Pin Function Definitions for DB15 Male Connector

[0136]

[0137] Serial communication port 11 uses a USB Type-C terminal, which can be used with terminal software for necessary software debugging.

[0138] OTG interface 12, using USB Type-C terminal.

[0139] There are 13 USB ports, and there are 2 of them. Either one can be used to import LDF files or upgrade internal software.

[0140] Ethernet port 14 connects to the network for remote assistance operations.

[0141] D is a schematic diagram of the right side panel of the equipment, which includes the following components:

[0142] The 2-position DIP switch 4, ON indicates that a 120-ohm resistor is connected to the CAN bus of this device, and OFF indicates that a 120-ohm terminating resistor is not used.

[0143] 5. Power indicator light; 6. Lin1 working indicator light; 7. Lin0 working indicator light; 8. CAN1 working indicator light; 9. CAN0 working indicator light.

[0144] This equipment can test multiple products simultaneously, supports user programming, and allows for easy completion of related functions through simple programming. This improves testing efficiency, facilitates on-site debugging, and meets the needs of rapid product changeover. It also features an RS485 communication interface, enabling control of external devices or power supplies to achieve automated testing. All tests can be completed without relying on other main control equipment, facilitating rapid deployment on production lines. Furthermore, it has four PWM drive signal sources, easily driving LEDs and brushed DC motors, and features eight output ports and eight input ports, all of which can be controlled via programming.

[0145] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented in software, the above embodiments can be implemented, in whole or in part, as a computer program product. Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution.

[0146] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0147] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A CAN / LIN communication analysis method, characterized in that, The method is applied to CAN / LIN communication testing equipment, and the method includes the following steps: Information Acquisition: Complete LDF / DBC file parsing to obtain LIN / CAN message information; Write test scripts: Based on the collected LIN / CAN message information and usage requirements, complete the test script writing; Execution script: Perform communication tests on CAN / LIN products, and during the execution of the test script, obtain GPIO input status, PWM output control, control of external power supply, and control of GPIO output status by selecting multiple options, one option, or ignoring options. These are then fed back to the CAN / LIN communication test stage to assist in the communication test of CAN / LIN products. CAN / LIN Communication Test: Sending and receiving CAN / LIN message data generated during communication tests of CAN / LIN products, and parsing CAN / LIN message data; Output product internal status information: Based on the parsed CAN / LIN message data, obtain the internal status parameters that characterize the actual operating status of the CAN / LIN product, including whether the CAN / LIN product can process the received commands, whether self-learning is normal, whether the internal voltage and temperature are normal, and the motor position information; When testing LIN product components, send the corresponding LIN command messages. After receiving the messages, the LIN product components execute the corresponding commands. To obtain the internal parameters of the LIN product components, first send the header of the LIN product component feedback message, then start receiving the LIN product component message data field. After receiving, combine this message data with the LDF file to parse the data, obtain the internal status parameters of the LIN product components, and display the corresponding signal values ​​on the screen. When testing CAN product components, corresponding CAN command messages are sent. Upon receiving the messages, the CAN product components execute the corresponding commands. When a feedback message is received from a CAN product component, it is parsed in conjunction with the DBC file to obtain the internal status parameters of the CAN product component, and the corresponding signal values ​​are displayed on the screen.

2. The CAN / LIN communication analysis method according to claim 1, characterized in that, The LIN / CAN message information includes message length, signal name in the message, signal size and signal offset position, and message delay time.

3. The CAN / LIN communication analysis method according to claim 2, characterized in that, The LIN / CAN message information is displayed on the screen in an array.

4. The CAN / LIN communication analysis method according to claim 1, characterized in that, When parsing the LDF file, information collection also includes: Retrieve the LIN protocol version parameter from the LDF file; The communication baud rate parameters are obtained from the LDF file, used to initialize the LIN physical layer, and saved to the data in the message information.

5. The CAN / LIN communication analysis method according to claim 4, characterized in that, The LIN protocol version parameter used is LIN 1.3 and earlier versions. Classic check is used for message verification. If the LIN protocol version is 2.0 or later, enhanced check is used for message verification. Classic check is maintained for diagnostic messages. Classic check does not check the message ID, but only the data field of the message. Enhanced checksum verification verifies both the message ID and the data field. The verification method is as follows: perform binary addition with carry on each byte of the checksum object, and invert the last bit of the sum. Use this result as the checksum to be sent. The receiver performs the same binary addition with carry on the received data according to the checksum type, without inverting the last bit of the sum, and adds the last sum to the received checksum. If the result is 0xFF, the checksum is correct.

6. An electronic device, characterized in that, The system includes a memory, a processor, and a PWM power supply, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the CAN / LIN communication analysis method as described in any one of claims 1 to 5.

7. The electronic device according to claim 6, characterized in that, The electronic device is equipped with 8 input GPIO ports and 8 output GPIO ports, 2 CAN channels and 2 LIN channels, which replace the PLC to provide corresponding process control signals and corresponding test result indications or status indications. The electronic device is equipped with 4 PWM output signals. The PWM power supply is available in 5V and 12V versions. The 4 PWM output signals are LED lights, and the PWM signal source is provided through a DC brushed motor.

Images