Communication mode adjusting method and system

Abstract

The embodiment of the invention provides a communication mode adjusting method and system, and the method comprises the steps: responding to a received diagnosis request, entering a diagnosis communication mode, and transmitting a diagnosis communication request to a slave node which is determined according to the request information carried in the diagnosis request, the diagnostic communication request is used for indicating the slave node to enter a diagnostic communication mode; determining a message scheduling mode based on a response state of the slave node, the response state being used for indicating whether the slave node responds to the diagnostic communication request, the message scheduling mode comprising a diagnostic scheduling mode or an application scheduling mode; a communication mode is adjusted based on the message scheduling mode, and the communication mode comprises a diagnosis communication mode corresponding to the diagnosis scheduling mode or an application communication mode corresponding to the application scheduling mode. The technical problem that in the prior art, a vehicle network cannot give consideration to real-time performance and sudden fault processing requirements is solved.

Description

Technical Field

[0001] This application relates to the field of vehicle network communication technology, and more specifically, to a communication mode adjustment method and system. Background Technology

[0002] In the field of in-vehicle network communication technology, especially in the application of Local Interconnect Network (LIN), the coordinated control of diagnostic scheduling and application scheduling has always been an important component of automotive Electronic Control Unit (ECU) communication. LIN bus, as a low-speed, low-cost in-vehicle network communication solution, is widely used in auxiliary communication networks within vehicles, such as door control and seat adjustment. However, existing technologies have limitations in handling the switching between diagnostic and application scheduling on the LIN bus. For example, traditional LIN buses cannot simultaneously meet the requirements of real-time performance and handling sudden faults, thus limiting the effectiveness and reliability of the LIN bus under complex operating conditions.

[0003] There is currently no good solution to the above problems. Summary of the Invention

[0004] This application provides a communication mode adjustment method and system to at least solve the technical problem in the prior art that vehicle networks cannot simultaneously meet the requirements of real-time performance and handling of sudden faults.

[0005] According to one aspect of the embodiments of this application, a communication mode adjustment method is provided. The method includes: in response to receiving a diagnostic request, entering a diagnostic communication mode and sending a diagnostic communication request to a slave node, wherein the slave node determines, based on request information carried in the diagnostic request, that the diagnostic communication request is used to instruct the slave node to enter the diagnostic communication mode; determining a message scheduling mode based on the response status of the slave node, wherein the response status is used to indicate whether the slave node responds to the diagnostic communication request, and the message scheduling mode includes a diagnostic scheduling mode or an application scheduling mode; adjusting the communication mode based on the message scheduling mode, wherein the communication mode includes a diagnostic communication mode corresponding to the diagnostic scheduling mode or an application communication mode corresponding to the application scheduling mode.

[0006] Furthermore, before determining the message scheduling mode based on the response status of the slave node, the method further includes: in response to not receiving a response message from the slave node within a first time period, sending header information of a diagnostic communication request to the slave node according to a first sending frequency within a second time period, wherein the response message is used to indicate the slave node's response to the diagnostic communication request, and the start time of the second time period is later than or equal to the end time of the first time period; in response to not receiving a response message within the second time period, determining the response status as not responding to the diagnostic communication request.

[0007] Furthermore, before determining the message scheduling mode based on the response status of the slave node, the method further includes: in response to receiving a first response message from the slave node within a first time period or a second time period, starting a timer and sending header information of a diagnostic communication request to the slave node according to a second sending frequency within the time period, wherein the first response message is used to indicate that the slave node is in a busy state, and the time period is greater than or equal to the duration of the second time period; in response to receiving the first response message within the time period, updating the timer; sending header information to the slave node according to the second sending frequency within a new round of time period, until no second response message from the slave node is received within a third time period, determining the response status as a non-response to the diagnostic communication request, wherein the start time of the third time period is the time when the timer is started, the duration of the third time period is greater than the time period, and the second response message is used to indicate that the slave node has received the diagnostic communication request.

[0008] Furthermore, before determining the message scheduling mode based on the response status of the slave node, the method further includes: in response to receiving a second response message from the slave node within a first time period, a second time period, or a third time period, determining the response status as a response to a diagnostic communication request.

[0009] Furthermore, determining the message scheduling mode based on the response status of the slave node includes: if the response status indicates that the slave node has not responded to the diagnostic communication request, the message scheduling mode is determined to be the application scheduling mode; if the response status indicates that the slave node has responded to the diagnostic communication request, the message scheduling mode is determined to be the diagnostic scheduling mode.

[0010] Furthermore, the diagnostic request includes a first diagnostic request or a second diagnostic request. The first diagnostic request is a diagnostic request sent by an external diagnostic device, and the second diagnostic request is a diagnostic request for the controller local area network to switch to the local internet.

[0011] Furthermore, in response to receiving a diagnostic request, entering the diagnostic communication mode and sending a diagnostic communication request to the slave node includes: in response to receiving a second diagnostic request, entering the diagnostic communication mode and sending a diagnostic communication request to the slave node based on the protocol stack policy, wherein the protocol stack policy is used to indicate the sending order and sending time interval of the diagnostic communication request and header information, and the sending time interval corresponding to the slave node is determined according to the functional attributes of the slave node.

[0012] Furthermore, the communication mode adjustment method also includes: performing fault detection in the diagnostic communication mode and generating a fault diagnosis code, wherein the fault diagnosis code carries remarks information, which is used to indicate that the first node in the non-local interconnection network is not allowed to perform fault detection during the diagnostic communication mode.

[0013] Furthermore, the communication mode adjustment method also includes: in diagnostic communication mode, in response to receiving fault detection information from a second node in a non-local interconnection network, processing the fault detection information to obtain a fault detection result, wherein the priority of the second node is higher than that of the first node, and the fault detection information includes cyclic redundancy check information and counter information; and sending the fault detection result to the second node.

[0014] According to another aspect of the embodiments of this application, a communication mode adjustment apparatus is also provided, comprising: a sending module, configured to enter a diagnostic communication mode in response to receiving a diagnostic request, and send a diagnostic communication request to a slave node, wherein the slave node determines, based on request information carried in the diagnostic request, that the diagnostic communication request is used to instruct the slave node to enter the diagnostic communication mode; a determining module, configured to determine a message scheduling mode based on the response status of the slave node, wherein the response status is used to indicate whether the slave node responds to the diagnostic communication request, and the message scheduling mode includes a diagnostic scheduling mode or an application scheduling mode; and an adjusting module, configured to adjust the communication mode based on the message scheduling mode, wherein the communication mode includes a diagnostic communication mode corresponding to the diagnostic scheduling mode, or an application communication mode corresponding to the application scheduling mode.

[0015] According to another aspect of the embodiments of this application, a communication mode adjustment system is also provided. The system includes: a master node, configured to execute the communication mode adjustment method in any of the above-mentioned embodiments; and a slave node, configured to receive a diagnostic communication request sent by the master node and send a response message to the master node based on the diagnostic communication request.

[0016] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored executable program, wherein, when the executable program is running, it controls the device where the computer-readable storage medium is located to perform the methods of various embodiments of this application.

[0017] According to another aspect of the embodiments of this application, a computer program product is also provided, including a computer program that, when executed by a processor, implements the methods of various embodiments of this application.

[0018] In this embodiment, upon receiving a diagnostic request, the system enters a diagnostic communication mode and sends a diagnostic communication request to the slave node. The slave node determines the diagnostic communication request based on the request information carried in the diagnostic request, which instructs the slave node to enter the diagnostic communication mode. Next, a message scheduling mode is determined based on the slave node's response status, where the response status indicates whether the slave node responds to the diagnostic communication request. The message scheduling mode includes either a diagnostic scheduling mode or an application scheduling mode. Finally, the communication mode is adjusted based on the message scheduling mode, which includes either the diagnostic communication mode corresponding to the diagnostic scheduling mode or the application communication mode corresponding to the application scheduling mode. This achieves dynamic priority switching and optimized resource allocation, thereby ensuring both real-time diagnostics and application continuity under complex operating conditions. This solves the technical problem in the prior art where vehicle networks cannot simultaneously meet the needs of real-time performance and handling sudden faults. Attached Figure Description

[0019] 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:

[0020] Figure 1 This is a flowchart of a communication mode adjustment method according to an embodiment of this application;

[0021] Figure 2 This is a schematic diagram of a communication mode adjustment device according to an embodiment of this application. Detailed Implementation

[0022] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0023] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0024] According to an embodiment of this application, an embodiment of a communication mode adjustment method is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0025] This method embodiment can be executed in an electronic device or similar computing device that includes memory and a processor. Taking operation on a computer terminal as an example, the computer terminal may include one or more processors (processors may include, but are not limited to, central processing units (CPUs), graphics processing units (GPUs), digital signal processing (DSP) chips, microcontroller units (MCUs), field-programmable gate arrays (FPGAs), neural network processors (NPUs), tensor processors (TPUs), artificial intelligence (AI) type processors, etc.) and memory for storing data. Optionally, the computer terminal may also include transmission devices, input / output devices, and display devices for communication functions. Those skilled in the art will understand that the above structural description is merely illustrative and does not limit the structure of the computer terminal. For example, the computer terminal may include more or fewer components than described above, or have a different configuration than described above.

[0026] The memory can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the communication mode adjustment method in this embodiment. The processor executes various functional applications and data processing by running the computer program stored in the memory, thereby implementing the aforementioned communication mode adjustment method. The memory may include high-speed random access memory (RAM) and non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to the mobile terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks (LANs), mobile communication networks, and combinations thereof.

[0027] The transmission device is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the mobile terminal's communication provider. In one example, the transmission device includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0028] Display devices can be, for example, touchscreen liquid crystal displays (LCDs) and touch displays (also referred to as "touchscreens" or "touch displays"). The LCD allows users to interact with the user interface of the mobile terminal. In some embodiments, the mobile terminal has a graphical user interface (GUI), which allows users to interact with the GUI through finger contact and / or gestures on a touch-sensitive surface. Optional human-computer interaction functions include: creating web pages, drawing, word processing, creating electronic documents, playing games, video conferencing, instant messaging, sending and receiving emails, call interfaces, playing digital video, playing digital music, and / or web browsing, etc. Executable instructions for performing the above human-computer interaction functions are configured / stored in one or more processor-executable computer program products or readable storage media.

[0029] This embodiment provides a method for adjusting communication modes. Figure 1 This is a flowchart of a communication mode adjustment method according to an embodiment of this application, such as... Figure 1 As shown, the process includes the following steps:

[0030] Step S10: In response to receiving a diagnostic request, enter the diagnostic communication mode and send a diagnostic communication request to the slave node. The slave node determines the diagnostic communication request based on the request information carried in the diagnostic request. The diagnostic communication request is used to instruct the slave node to enter the diagnostic communication mode.

[0031] In this embodiment, the diagnostic request is a diagnostic request sent by a diagnostic instrument for Controller Area Network (CAN) to LIN conversion. Specifically, the diagnostic request includes a first diagnostic request or a second diagnostic request. The first diagnostic request is a diagnostic request sent by an external diagnostic device (e.g., a diagnostic instrument), and the second diagnostic request is a diagnostic request for CAN to LIN conversion.

[0032] Diagnostic communication mode is activated when the vehicle system detects a potential fault or requires maintenance. In diagnostic communication mode, the communication priority and scheduling strategy of the LIN bus are adjusted to ensure timely and efficient transmission of diagnostic information. Diagnostic communication mode typically has the following characteristics: High priority: Diagnostic messages have higher priority than regular application messages, ensuring priority use of bus resources during fault detection or maintenance. Real-time requirements: To quickly respond to fault detection or diagnostic commands, diagnostic communication mode needs to provide lower latency for timely acquisition and analysis of fault information. Periodic or event-driven communication: Depending on the diagnostic needs, communication can be periodic (sending diagnostic information periodically) or event-triggered (e.g., initiating diagnostics immediately when a fault occurs).

[0033] A diagnostic communication request is a specific command initiated by the master node (usually the node responsible for coordinating communication across the entire network) in diagnostic communication mode. Its purpose is to request slave nodes (other ECUs in the LIN network) to enter diagnostic communication mode. A diagnostic communication request typically includes the following information: Request type: Indicates that this is a diagnostic request rather than a regular application request. Slave node address: Specifies which slave node should enter diagnostic communication mode. Diagnostic service code: Describes the specific diagnostic service to be performed, such as reading fault codes, clearing fault memory, performing specific ECU tests, etc., which is not limited here. Parameter data: May include additional parameters required to perform the specific diagnostic service, such as fault codes, test sequences, etc., which is not limited here.

[0034] In response to receiving a diagnostic request, entering diagnostic communication mode and sending a diagnostic communication request to the slave node can be understood as follows: when the master node (usually the ECU responsible for LIN bus communication coordination) receives a diagnostic request, the master node will switch its communication mode to diagnostic communication mode and immediately send a diagnostic communication request to the specified slave node.

[0035] As can be seen, through this step, this application can quickly and intelligently switch between diagnostic communication and regular application communication, ensuring that possible faults can be detected and handled in a timely manner without affecting the normal operation of the vehicle, thereby improving the vehicle's maintenance efficiency and safety.

[0036] Step S12: Determine the message scheduling mode based on the response status of the slave node, wherein the response status is used to indicate whether the slave node responds to the diagnostic communication request, and the message scheduling mode includes diagnostic scheduling mode or application scheduling mode.

[0037] In this embodiment, the response status refers to the response status of the slave node to the diagnostic communication request sent by the master node. Specifically, the response status can include the following situations: (1) Response: When the slave node receives the diagnostic communication request from the master node, it can respond immediately or within a reasonable time, indicating that the slave node is ready to enter the diagnostic communication mode and perform the corresponding diagnostic service. (2) No response: If the master node does not receive any response from the slave node within the expected time after sending the diagnostic communication request, it is considered that the slave node is in a no-response state, which may be because the slave node is busy with another high-priority task, a fault, communication delay or other reasons and cannot respond immediately. (3) NRC 0x78: NRC 0x78 is a negative response code in the LIN protocol, indicating that the slave node is currently unable to respond to the request, which may be because the slave node is performing a task that cannot be interrupted, such as program refresh or computationally intensive operation.

[0038] Message scheduling mode refers to the strategy for arranging message transmission based on current communication needs and priorities in LIN bus communication. In this embodiment, message scheduling modes are divided into two types: diagnostic scheduling mode and application scheduling mode. Diagnostic scheduling mode is activated when fault diagnosis or emergency handling is required. In diagnostic scheduling mode, diagnostic messages have the highest priority, ensuring rapid and efficient acquisition and processing of diagnostic data. In diagnostic scheduling mode, bus resources are primarily allocated to diagnostic communication, potentially pausing or reducing the transmission frequency of regular application messages to ensure the real-time performance and integrity of diagnostics. Application scheduling mode is the mode during normal LIN bus operation, primarily handling the control and data exchange of daily vehicle functions. In application scheduling mode, application messages have a higher priority than diagnostic messages (unless there is an urgent diagnostic need), ensuring the smoothness of routine vehicle operation and user experience. Application scheduling mode allows for more flexible message transmission strategies to adapt to the real-time and periodic needs of different functions.

[0039] Determining the message scheduling mode based on the response status of slave nodes can be understood as dynamically adjusting the communication priority and scheduling strategy according to the slave nodes' responses to diagnostic communication requests. For example, when a slave node is detected to be unresponsive or sending an NRC 0x78, the master node may switch to application scheduling mode, waiting for a more suitable opportunity to attempt diagnosis; while when a slave node responds normally to the diagnostic request, it switches to diagnostic scheduling mode, prioritizing the processing of diagnostic tasks.

[0040] As can be seen, based on the response status of the slave node, the master node will dynamically adjust the message scheduling mode of the LIN bus to optimize communication efficiency and ensure the stability and reliability of the system under any circumstances, thereby improving the communication flexibility of the LIN bus and its ability to cope with sudden working conditions.

[0041] Step S14: Adjust the communication mode based on the message scheduling mode, wherein the communication mode includes the diagnostic communication mode corresponding to the diagnostic scheduling mode, or the application communication mode corresponding to the application scheduling mode.

[0042] In this embodiment, the communication mode refers to the specific rules and priority configuration for message sending and receiving on the LIN bus. The communication mode is dynamically changed according to the current scheduling mode (application scheduling mode or diagnostic scheduling mode) to meet the communication needs in different scenarios. Specifically, the communication modes can be divided into two categories: (1) Diagnostic communication mode: When the LIN bus system recognizes a diagnostic request or encounters a situation requiring urgent diagnosis, the system will automatically switch to the diagnostic communication mode. In the diagnostic communication mode, the transmission and response of diagnostic messages become the highest priority tasks, ensuring that fault diagnosis and repair can be carried out quickly. (2) Application communication mode: Under normal operating conditions, the LIN bus system is in the application communication mode. The application communication mode is mainly used to support the daily function control and data exchange of the vehicle, such as window control, steering wheel adjustment, etc.

[0043] Adjusting the communication mode based on message scheduling can be understood as the LIN bus system dynamically switching communication modes according to the scheduling needs of current diagnostics or applications. For example, upon receiving a diagnostic request and determining to enter diagnostic scheduling mode, the system will immediately switch to diagnostic communication mode, prioritizing the processing of diagnostic-related messages; conversely, when the diagnostic process ends or no diagnostic request is received, the system will switch back to application communication mode to continue exchanging messages for routine functions.

[0044] As can be seen, through the dynamic adjustment mechanism of the above communication modes, the LIN bus can effectively manage the priority of communication tasks, ensuring that in complex application scenarios, it can respond to diagnostic needs in a timely manner and ensure the smooth operation of the vehicle's daily functions.

[0045] Based on the above steps, upon receiving a diagnostic request, the system enters a diagnostic communication mode and sends a diagnostic communication request to the slave node. The slave node determines the diagnostic communication mode based on the request information carried in the diagnostic request. Next, the message scheduling mode is determined based on the slave node's response status, which indicates whether the slave node has responded to the diagnostic communication request. The message scheduling mode includes either a diagnostic scheduling mode or an application scheduling mode. Finally, the communication mode is adjusted based on the message scheduling mode. This achieves dynamic priority switching and optimized resource allocation, thus ensuring both real-time diagnostics and application continuity under complex operating conditions. This solves the technical problem in existing technologies where vehicle networks cannot simultaneously meet the needs of real-time performance and handling sudden faults.

[0046] Furthermore, before determining the message scheduling mode based on the response status of the slave node, the communication mode adjustment method also includes the following execution steps:

[0047] Step S111: In response to not receiving a response message from the slave node within the first time period, send the header information of the diagnostic communication request to the slave node according to the first transmission frequency within the second time period. The response message is used to indicate the slave node's response to the diagnostic communication request. The start time of the second time period is later than or equal to the end time of the first time period.

[0048] Step S112: In response to the lack of a response message received within the second time period, the response status is determined to be "not responding to diagnostic communication request".

[0049] In this embodiment, the first time period refers to the waiting time after the master node sends a diagnostic communication request and expects to receive a response message from the slave node. For example, the first time period can be set to 500ms, but this is not a limitation.

[0050] The second time period is the interval during which the master node retryes sending diagnostic communication requests if no response message is received from the slave node. For example, the second time period can be set to 2 seconds, but this is not a limitation.

[0051] The first transmission frequency refers to the frequency at which the master node sends diagnostic request header information to the slave node within the second time period. For example, the first transmission frequency can be at regular time intervals, such as 10ms or 20ms, specifically set by the LIN bus scheduling table, and is not limited here.

[0052] The header information refers to the very beginning of a diagnostic communication request, containing basic information about the request, such as the request type and the target slave node encoding, used by the slave node to identify the nature of the communication request. For example, in LIN communication, the header information of a diagnostic request is typically a specific frame used to initiate the diagnostic communication process with the slave node; this is not a limitation here.

[0053] The response of not receiving a response message from the slave node within the first time period, and sending the header information of the diagnostic communication request to the slave node according to the first sending frequency in the second time period, can be understood as follows: after the master node sends the diagnostic communication request, if it fails to receive any response message from the expected slave node within the preset first time period, the master node will end the first time period and enter the second time period, and then start resending the header information of the diagnostic communication request according to the first sending frequency. In this way, by making multiple attempts, the probability of obtaining a response from the slave node is increased, thus ensuring the establishment of diagnostic communication.

[0054] If no response message is received within the second time period, the response status will be determined as "not responding to diagnostic communication request". This can be understood as follows: if the master node still has not received a response message from the slave node by the end of the second time period, the system will update the response status to "not responding to diagnostic communication request". That is, the slave node is unable to respond to the diagnostic communication request under the current conditions or status. This may be due to the slave node being in a long-term busy state, network failure, hardware failure or other unknown reasons, which are not limited here.

[0055] As can be seen, through the above response mechanism, the system can effectively identify and handle communication delays or node non-response issues encountered during diagnostic communication, thereby improving the reliability and efficiency of diagnostic communication and ensuring the stable and safe operation of automotive electronic systems.

[0056] Furthermore, before determining the message scheduling mode based on the response status of the slave node, the communication mode adjustment method also includes the following execution steps:

[0057] Step S113: In response to receiving a first response message from the slave node within a first time period or a second time period, start a timer and send header information of a diagnostic communication request to the slave node according to a second transmission frequency within the time period. The first response message is used to indicate that the slave node is in a busy state, and the time period is greater than or equal to the duration of the second time period.

[0058] Step S114: In response to receiving the first response message within the timeout period, update the timer;

[0059] Step S115: Within the new round of timing duration, send header information to the slave node according to the second sending frequency until no second response message is received from the slave node within the third time period. Determine the response status as no response to the diagnostic communication request. The start time of the third time period is the time when the timer is started. The duration of the third time period is longer than the timing duration. The second response message is used to indicate that the slave node has received the diagnostic communication request.

[0060] In this embodiment, the first response message refers to a feedback message sent by the slave node to the master node within a first or second time period, indicating that the slave node is currently busy and cannot immediately process the diagnostic communication request. In the LIN protocol, the first response message typically appears in the form of NRC 0x78, indicating that the slave node is busy with other tasks (such as performing a program refresh or processing computationally intensive work) and is temporarily unable to respond to the diagnostic request.

[0061] The timing duration is the time the master node starts timing after receiving the first response message, waiting for the slave node to complete its busy state and prepare to receive diagnostic requests. This timing duration is at least equal to the duration of the second time period, and may be longer, to give the slave node sufficient time to process internal tasks. For example, if the slave node responds with NRC 0x78, the master node will continuously send 3D (Communication Delimiter) header information and wait for 2 seconds. This 2 seconds can be understood as the initial value of the timing duration, which may be updated subsequently based on the slave node's continued busy state; this is not limited here.

[0062] The second transmission frequency refers to the frequency at which the master node sends diagnostic communication request header information to the slave node within the timed duration. Unlike the first transmission frequency, the second transmission frequency may differ in frequency to accommodate the busy state of the slave node. In this application, the second transmission frequency can be adjusted in real time according to the busy state and communication needs of the slave node. For example, while the slave node is continuously sending NRC 0x78, the master node may repeatedly send 3D header information at a slower frequency, waiting for the slave node's busy state to end; this is not limited here.

[0063] The third time period is a window in which the master node continues to send header information at the second sending frequency from the moment the timer starts until it is finally determined that the slave node is unable to respond to the diagnostic request. The duration of the third time period is longer than the timer duration, which is intended to give the system additional time to attempt to establish diagnostic communication and ensure that diagnostic opportunities are not missed due to brief communication delays or internal processing by the slave node.

[0064] The second response message is an acknowledgment message directly related to the diagnostic communication request, indicating that the slave node has successfully received and is ready to process the diagnostic request. The second response message indicates that the slave node is ready to accept further diagnostic communication instructions or data. The receipt of the second response message while the master node is continuously sending header information signifies that the slave node's busy state has ended and the diagnostic communication process can officially begin.

[0065] In response to receiving a first response message from the slave node within a first or second time period, the master node starts a timer and sends a diagnostic communication request header to the slave node at a second sending frequency within the timed period. This can be understood as follows: After the master node sends a diagnostic communication request, if it receives a first response message from the slave node within the first or second time period (typically NRC 0x78, indicating the slave node is currently busy and cannot respond immediately), the master node will start a timer. Within the timed period, the master node will continuously send the diagnostic communication request header to the slave node at a second sending frequency to reduce interference with the slave node while maintaining the continuity of attempts to establish communication with it.

[0066] In response to receiving the first response message within the timeout period, updating the timer can be understood as follows: if the master node receives the first response message again (NRC 0x78) within the already started timeout period, indicating that the slave node is still busy, the master node will reset the timer and start a new timeout period. By re-timing and continuously attempting communication, the likelihood of diagnosing communication establishment is increased.

[0067] Within the new timeout period, the master node sends header information to the slave node at the second sending frequency until no second response message is received from the slave node within the third timeout period. The response status is determined to be "not responding to diagnostic communication request". This can be understood as follows: after updating the timer and starting a new timeout period, the master node will continue to send header information of the diagnostic communication request to the slave node at the second sending frequency. This process may be repeated multiple times. If no second response message is received from the slave node until the third timeout period, it indicates that the slave node's response status is "not responding to diagnostic communication request".

[0068] For example, the Lin master node software needs to be set with a maximum waiting time, such as 30 minutes, which is not limited here.

[0069] As can be seen, through the above response mechanism, the LIN bus system can intelligently handle uncertainties and delays in the communication process, ensuring that even when the slave node encounters an internal busy state, it can attempt to establish diagnostic communication by dynamically adjusting the sending strategy, thereby improving the robustness and diagnostic efficiency of the entire system.

[0070] Furthermore, before determining the message scheduling mode based on the response status of the slave node, the communication mode adjustment method also includes the following execution steps:

[0071] Step S116: In response to receiving a second response message from the slave node within a first time period, a second time period, or a third time period, determine the response status as a response to a diagnostic communication request.

[0072] In this embodiment of the application, the response status of receiving the second response message from the slave node within the first time period, the second time period, or the third time period and determining the response status as responding to the diagnostic communication request can be understood as follows: when the master node receives the second response message from the slave node within any waiting period (the first time period, the second time period, or the third time period), the master node will determine the response status of the slave node as responding to the diagnostic communication request, indicating that the slave node has successfully received the diagnostic request from the master node.

[0073] It can be seen that by continuously monitoring the response status of slave nodes during multiple waiting periods and confirming the second response message in a timely manner, the system can manage the initiation and execution of diagnostic communication more intelligently and flexibly, thereby improving the overall reliability and efficiency of the network.

[0074] Further, in step S12, determining the message scheduling mode based on the response status of the slave node includes the following execution steps:

[0075] Step S121: If the response status indicates that the slave node has not responded to the diagnostic communication request, determine that the message scheduling mode is the application scheduling mode.

[0076] Step S122: If the response status indicates that the slave node is responding to the diagnostic communication request, determine the message scheduling mode as the diagnostic scheduling mode.

[0077] In this embodiment of the application, if the response status indicates that the slave node has not responded to the diagnostic communication request, determining the message scheduling mode as the application scheduling mode can be understood as follows: when the slave node's response status is that it has not responded to the diagnostic communication request, the system sets the message scheduling mode to the application scheduling mode. That is, the system will prioritize the processing of regular application message scheduling rather than continuously attempting diagnostic communication, thereby ensuring that the daily functions of the vehicle are not affected and that communication resources can be effectively allocated to application needs under normal operation.

[0078] If the response status indicates that the slave node is responding to the diagnostic communication request, determining the message scheduling mode as the diagnostic scheduling mode can be understood as follows: when the system detects that the slave node's response status indicates that it is responding to the diagnostic communication request, that is, the slave node is ready or has started processing diagnostic communication, the system will determine the message scheduling mode as the diagnostic scheduling mode. In other words, the system will shift the priority to diagnostic communication, ensuring that all resources and scheduling strategies are focused on completing the diagnostic task, including but not limited to adjusting message priorities and reserving diagnostic time slots, in order to achieve fault diagnosis and status checks of the slave node. No restrictions are imposed here.

[0079] As can be seen, through the above steps, the master node can intelligently switch between application scheduling mode and diagnostic scheduling mode by monitoring and parsing the response status of the slave nodes, thereby rationally allocating network resources, avoiding invalid diagnostic communication attempts when the slave nodes are not ready, reducing resource waste, and ensuring that the system can maintain high efficiency and stability under complex working conditions, balancing diagnostic needs and application needs.

[0080] Further, in step S10, in response to receiving a diagnostic request, entering the diagnostic communication mode and sending a diagnostic communication request to the slave node includes the following execution steps:

[0081] Step S101: In response to receiving the second diagnostic request, enter the diagnostic communication mode and send a diagnostic communication request to the slave node based on the protocol stack policy. The protocol stack policy is used to indicate the sending order and sending time interval of the diagnostic communication request and header information. The sending time interval corresponding to the slave node is determined according to the functional attributes of the slave node.

[0082] In this embodiment, the protocol stack strategy defines the sending order of diagnostic communication requests (3C (Communication Command) requests) and header information (3D header information). Specifically, when the system responds to receiving a second diagnostic request, it enters diagnostic communication mode and begins sending 3C requests. Subsequently, based on the expectation that the slave node may return to a busy state, the protocol stack strategy instructs the master node to continuously send 3D header information even if no response is received. This aims to ensure that even if the slave node is temporarily unable to respond, the master node can maintain the communication connection with the slave node through continuous header information sending, creating conditions for subsequent diagnostic communication. No restrictions are imposed here.

[0083] For example, the time interval between the master node sending the 3C request and the master node sending the first 3D header is in the range of 15ms to 20ms, and there is no limit here.

[0084] The protocol stack strategy specifies the frequency and duration for subsequent 3D header information transmission after the master node sends a 3C request and upon receiving the first NRC 0x78 response message. For example, if no response is received from the slave node within the first time period, the master node will continuously transmit the 3D header information at the first transmission frequency during the second time period; if an NRC 0x78 response is received during the second time period, the master node will continuously transmit the 3D header information at the second transmission frequency for the specified duration until the slave node completes its internal tasks and is ready to receive diagnostic communication, without any restrictions on this.

[0085] The functional attributes of a slave node determine its responsiveness in diagnostic communication. Therefore, the protocol stack strategy includes a mechanism to adjust the transmission time interval for different slave nodes. For example, for slave nodes that require longer processing times (such as when refreshing a program or performing complex calculations), the strategy may set a longer timing duration and a slower transmission frequency to suit the internal processing needs of the slave node and avoid invalid or interfering communication. This is not restricted here.

[0086] In response to receiving the second diagnostic request, entering diagnostic communication mode and sending diagnostic communication requests to slave nodes based on protocol stack policies can be understood as the master node switching to diagnostic communication mode after recognizing and confirming the second diagnostic request. In diagnostic communication mode, the master node will send diagnostic communication requests to slave nodes according to protocol stack policies.

[0087] As can be seen, through this response strategy, the LIN bus system can flexibly and intelligently manage diagnostic communication during vehicle operation, improving diagnostic efficiency and network communication reliability.

[0088] Furthermore, the communication mode adjustment method also includes the following execution steps:

[0089] Fault detection is performed in diagnostic communication mode, and a fault diagnosis code is generated. The fault diagnosis code carries a note that indicates that the first node in the non-local interconnection network is not allowed to perform fault detection during diagnostic communication mode.

[0090] In this embodiment, the fault diagnosis code refers to a code generated by the master node or a specific ECU during fault detection in the diagnostic communication mode of the LIN bus. The fault diagnosis code is used to record and represent the specific fault conditions found in the vehicle's electronic system, including the nature of the fault, the location of the fault, and the possible causes, which are not limited here.

[0091] The first node refers to an ECU or other type of network device in a non-LIN network. Specifically, the first node is usually one of the nodes located in a CAN network.

[0092] In diagnostic communication mode, fault detection and generation of fault diagnosis codes can be understood as follows: based on the response of the slave node, the master node or diagnostic tool will analyze the status of the ECU. If a fault or abnormality is detected, the system will generate a fault diagnosis code. The fault diagnosis code contains specific information about the fault, such as the fault type, the location of the fault, and the priority of the fault, which are not limited here.

[0093] For example, suppose a LIN network is performing fault detection on a certain ECU. To ensure the accuracy and efficiency of the diagnostic process, annotation information will be embedded in the generated fault diagnosis code, instructing all non-LIN first nodes to temporarily stop fault self-checks or reduce communication activity. For instance, if the airbag ECU is undergoing in-depth diagnostics via the LIN bus, the annotation information will inform non-LIN first nodes such as the engine ECU and transmission ECU not to perform proactive fault detection or restrict their communication until the diagnostics are complete, in order to avoid communication conflicts and ensure the centralized and effective use of diagnostic resources. No restrictions are imposed here.

[0094] As can be seen, this step enhances the coordination capabilities and fault detection accuracy of the in-vehicle network. Through intelligent scheduling and resource management, it avoids network congestion and errors that may result from simultaneous diagnosis or communication of multiple systems. Furthermore, this application ensures that when diagnosing critical systems, other non-critical systems will not cause further problems due to misoperation. In other words, this application improves the diagnostic efficiency and communication stability of the in-vehicle network under complex operating conditions by adding annotation information to the fault diagnosis code.

[0095] Furthermore, the communication mode adjustment method also includes the following execution steps:

[0096] In diagnostic communication mode, in response to receiving fault detection information from a second node in a non-local interconnection network, the fault detection information is processed to obtain a fault detection result. The second node has a higher priority than the first node. The fault detection information includes cyclic redundancy check information and counter information.

[0097] The fault detection results are sent to the second node.

[0098] In this embodiment, the second node refers to an ECU or other network device within a non-local interconnect network (i.e., a non-LIN network). The second node has a higher priority in the vehicle network architecture than the first node in the LIN network. For example, the second node may include critical safety system ECUs (such as anti-lock braking systems, electronic stability programs), engine control modules, or vehicle powertrain management units, etc., without limitation.

[0099] Fault detection information refers to data packets generated by the second node in diagnostic communication mode and sent to the master node of the LIN network. These packets are used to request or provide key parameters and status information required for fault detection. For example, fault detection information mainly includes Cyclic Redundancy Check (CRC) information and counter information. CRC is an error detection code used to verify the integrity of data transmission. During diagnosis, the second node can send CRC information to ensure that the data it sends to the LIN network has not been erroneously transmitted. Counter information typically reflects the number of operations or events that have occurred since the last fault detection, helping the master node assess the second node's operational status and determine if frequent errors or anomalies exist.

[0100] Fault detection results refer to the conclusions drawn by the master node in a LIN network after receiving fault detection information sent by a second node, through processing and analysis. Fault detection results may include the health status of the second node, the specific type of fault, the severity of the fault, and possible causes of the fault, etc., without limitation here.

[0101] In diagnostic communication mode, in response to receiving fault detection information from a second node in a non-local interconnection network, the fault detection information is processed to obtain the fault detection result. This can be understood as follows: if the master node of the LIN bus receives fault detection information sent by the second node in diagnostic communication mode, the master node will perform in-depth processing and analysis of the fault detection information and generate a fault detection result.

[0102] Sending the fault detection results to the second node can be understood as the LIN master node, after processing the fault detection information, feeding back the obtained fault detection results to the second node.

[0103] It can be seen that by finely processing fault detection information, not only can the accuracy of fault detection be improved, but also resource allocation can be optimized, communication latency reduced, and the stability and security of the entire vehicle electronic system enhanced in multi-network collaborative scenarios.

[0104] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0105] According to an embodiment of this application, a communication mode adjustment device is provided. It should be noted that the device can be used to perform the above-described communication mode adjustment method.

[0106] Figure 2 This is a schematic diagram of a communication mode adjustment device according to an embodiment of this application, such as... Figure 2 As shown, the communication mode adjustment device 200 includes: a sending module 201, configured to enter a diagnostic communication mode in response to receiving a diagnostic request and send a diagnostic communication request to a slave node, wherein the slave node determines the diagnostic communication request based on the request information carried in the diagnostic request, and the diagnostic communication request is used to instruct the slave node to enter the diagnostic communication mode; a determining module 202, configured to determine a message scheduling mode based on the response status of the slave node, wherein the response status is used to indicate whether the slave node responds to the diagnostic communication request, and the message scheduling mode includes a diagnostic scheduling mode or an application scheduling mode; and an adjusting module 203, configured to adjust the communication mode based on the message scheduling mode, wherein the communication mode includes a diagnostic communication mode corresponding to the diagnostic scheduling mode or an application communication mode corresponding to the application scheduling mode.

[0107] It should be noted that the above modules can be implemented by software or hardware. For the latter, they can be implemented in the following ways, but are not limited to: all the above modules are located in the same processor; or, the above modules are located in different processors in any combination.

[0108] Embodiments of this application also provide a communication mode adjustment system, the system comprising: a master node, configured to execute the communication mode adjustment method described in any of the preceding embodiments; and a slave node, configured to receive a diagnostic communication request sent by the master node and send a response message to the master node based on the diagnostic communication request.

[0109] Optionally, in this embodiment, the processor can be configured to perform the following steps via a computer program:

[0110] Step S10: In response to receiving a diagnostic request, enter the diagnostic communication mode and send a diagnostic communication request to the slave node. The slave node determines the diagnostic communication request based on the request information carried in the diagnostic request. The diagnostic communication request is used to instruct the slave node to enter the diagnostic communication mode.

[0111] Step S12: Determine the message scheduling mode based on the response status of the slave node, wherein the response status is used to indicate whether the slave node responds to the diagnostic communication request, and the message scheduling mode includes diagnostic scheduling mode or application scheduling mode.

[0112] Step S14: Adjust the communication mode based on the message scheduling mode, wherein the communication mode includes the diagnostic communication mode corresponding to the diagnostic scheduling mode, or the application communication mode corresponding to the application scheduling mode.

[0113] Embodiments of this application also provide a computer-readable storage medium including a stored executable program, wherein, when the executable program is running, it controls the device where the computer-readable storage medium is located to perform the methods of various embodiments of this application.

[0114] Optionally, in this embodiment, the storage medium may be configured to store a computer program for performing the following steps:

[0115] Step S10: In response to receiving a diagnostic request, enter the diagnostic communication mode and send a diagnostic communication request to the slave node. The slave node determines the diagnostic communication request based on the request information carried in the diagnostic request. The diagnostic communication request is used to instruct the slave node to enter the diagnostic communication mode.

[0116] Step S12: Determine the message scheduling mode based on the response status of the slave node, wherein the response status is used to indicate whether the slave node responds to the diagnostic communication request, and the message scheduling mode includes diagnostic scheduling mode or application scheduling mode.

[0117] Step S14: Adjust the communication mode based on the message scheduling mode, wherein the communication mode includes the diagnostic communication mode corresponding to the diagnostic scheduling mode, or the application communication mode corresponding to the application scheduling mode.

[0118] Embodiments of this application also provide a computer program product, including a computer program that, when executed by a processor, implements the methods of various embodiments of this application.

[0119] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0120] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0121] 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; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0122] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0123] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0124] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A communication mode adjustment method, characterized in that, The method includes: In response to receiving a diagnostic request, the system enters a diagnostic communication mode and sends a diagnostic communication request to the slave node, wherein the slave node determines the diagnostic communication mode based on the request information carried in the diagnostic request, and the diagnostic communication request is used to instruct the slave node to enter the diagnostic communication mode. The message scheduling mode is determined based on the response status of the slave node, wherein the response status is used to indicate whether the slave node responds to the diagnostic communication request, and the message scheduling mode includes a diagnostic scheduling mode or an application scheduling mode. The communication mode is adjusted based on the message scheduling mode, wherein the communication mode includes the diagnostic communication mode corresponding to the diagnostic scheduling mode, or the application communication mode corresponding to the application scheduling mode.

2. The method according to claim 1, characterized in that, Before determining the message scheduling mode based on the response status of the slave node, the method further includes: In response to not receiving a response message from the slave node within a first time period, the header information of the diagnostic communication request is sent to the slave node according to a first sending frequency within a second time period. The response message is used to indicate the slave node's response to the diagnostic communication request. The start time of the second time period is later than or equal to the end time of the first time period. If no response message is received within the second time period, the response status is determined to be "not responding to the diagnostic communication request".

3. The method according to claim 1, characterized in that, Before determining the message scheduling mode based on the response status of the slave node, the method further includes: In response to receiving a first response message from the slave node within a first time period or a second time period, a timer is started, and within the time period, the header information of the diagnostic communication request is sent to the slave node according to a second sending frequency, wherein the first response message is used to indicate that the slave node is in a busy state, and the time period is greater than or equal to the duration of the second time period; In response to receiving the first response message within the said timing duration, update the timer; Within the new round of the aforementioned timing duration, the header information is sent to the slave node according to the second transmission frequency until the second response message from the slave node is not received within the third time period. The response status is determined to be a non-response to the diagnostic communication request. The start time of the third time period is the time when the timer is started, and the duration of the third time period is greater than the timing duration. The second response message is used to indicate that the slave node has received the diagnostic communication request.

4. The method according to claim 1, characterized in that, Before determining the message scheduling mode based on the response status of the slave node, the method further includes: Upon receiving a second response message from the slave node within a first time period, a second time period, or a third time period, the response status is determined to be in response to the diagnostic communication request.

5. The method according to claim 1, characterized in that, The process of determining the message scheduling mode based on the response status of the slave node includes: If the response status indicates that the slave node has not responded to the diagnostic communication request, the message scheduling mode is determined to be the application scheduling mode. If the response status indicates that the slave node is responding to the diagnostic communication request, then the message scheduling mode is determined to be the diagnostic scheduling mode.

6. The method according to claim 1, characterized in that, The diagnostic request includes a first diagnostic request or a second diagnostic request. The first diagnostic request is a diagnostic request sent by an external diagnostic device, and the second diagnostic request is a diagnostic request for switching from a controller area network to a local interconnect network.

7. The method according to claim 6, characterized in that, The step of responding to receiving a diagnostic request, entering diagnostic communication mode, and sending a diagnostic communication request to the slave node includes: In response to receiving the second diagnostic request, the system enters the diagnostic communication mode and sends the diagnostic communication request to the slave node based on the protocol stack policy. The protocol stack policy is used to indicate the sending order and time interval of the diagnostic communication request and header information. The sending time interval corresponding to the slave node is determined according to the functional attributes of the slave node.

8. The method according to any one of claims 1-7, characterized in that, The method further includes: Fault detection is performed in the diagnostic communication mode, and a fault diagnosis code is generated. The fault diagnosis code carries remarks information, which is used to indicate that the first node in the non-local interconnection network is not allowed to perform fault detection during the diagnostic communication mode.

9. The method according to claim 8, characterized in that, The method further includes: In the diagnostic communication mode, in response to receiving fault detection information from a second node in a non-local interconnection network, the fault detection information is processed to obtain a fault detection result, wherein the priority of the second node is higher than that of the first node, and the fault detection information includes cyclic redundancy check information and counter information. The fault detection results are sent to the second node.

10. A communication mode adjustment system, characterized in that, The system includes: The master node is used to execute the communication mode adjustment method as described in any one of claims 1 to 9; The slave node is used to receive diagnostic communication requests sent by the master node and send response messages to the master node based on the diagnostic communication requests.

Images