Multi-bus protocol network control method, device, equipment, storage medium and product

Abstract

This application discloses a multi-bus protocol network control method, apparatus, device, storage medium, and product, relating to the field of vehicle communication technology. The method includes: waking up the target protocol node and the target area controller when a wake-up source is detected on the target protocol node corresponding to a certain bus protocol in a regional control topology; determining whether cross-segment wake-up and cross-region wake-up are needed based on preset vehicle sleep wake-up conditions; if needed, determining other area controllers to be woken up across regions and target network segments to be woken up in other regions based on preset vehicle sleep wake-up conditions; and performing wake-up control. This application achieves multi-bus protocol multi-segment network collaborative control by simultaneously determining whether cross-segment and cross-region control of other area controllers and other network segments is needed when controlling a bus protocol node and an area controller, thereby determining all area controllers and network segments that need to be controlled according to requirements.

Description

Technical Field

[0001] This application relates to the field of vehicle communication technology, and in particular to a multi-bus protocol network control method, apparatus, device, storage medium and product. Background Technology

[0002] With the development of electronic and electrical architectures, the architecture topology has gradually evolved from centralized domain control to area control centered on a central computing platform. The area control topology consists of a central computing platform, area controllers, and various buses. The central computing platform and area controllers communicate via Ethernet bus, and various LIN / CAN / CANFD / Ethernet nodes are connected to the area controllers within that domain. The commonly used application layer protocol for Ethernet bus communication is SOME / IP. In this vehicle architecture topology, multiple different bus protocols exist (① Local Interconnect Network (LIN), ② Controller Area Network (CAN), ③ Controller Area Network with Flexible Data-Rate (CANFD), ④ Ethernet, Scalable service-oriented middleware over IP (SOME / IP)), inevitably requiring sleep and wake-up coordination among multiple subnets and multiple bus protocols. Therefore, how to achieve network collaborative control across multiple bus protocols and network segments is a problem that urgently needs to be solved. Summary of the Invention

[0003] The main purpose of this application is to provide a multi-bus protocol network control method, device, equipment, storage medium and product, which aims to solve the technical problem that the existing regional control topology cannot realize multi-bus protocol multi-segment network collaborative control.

[0004] To achieve the above objectives, this application proposes a multi-bus protocol network control method, the method comprising:

[0005] When the target protocol node corresponding to a certain bus protocol in the multiple bus protocols of the area control topology detects the activation of the wake-up source, the target protocol node and the target area controller where the target protocol node is located are woken up.

[0006] Determine whether the target area controller needs to perform cross-network segment wake-up based on the preset vehicle hibernation and wake-up conditions;

[0007] If cross-network segment wake-up is required, the target area controller is determined to be required to perform cross-region wake-up based on the preset vehicle sleep wake-up conditions.

[0008] If cross-region wake-up is required, other regional controllers to be woken up and target network segments to be woken up in other regions are determined according to the preset vehicle sleep wake-up conditions.

[0009] Wake up the other area controllers and the target network segment.

[0010] In one embodiment, after the step of determining whether the target area controller needs to perform cross-network segment wake-up based on preset vehicle sleep / wake-up conditions, the method further includes:

[0011] If cross-network segment wake-up is not required, then wake up the network segment where the target protocol node is located within the target area.

[0012] In one embodiment, after the step of determining whether the target area controller needs to perform cross-region wake-up based on the preset vehicle sleep / wake-up conditions if cross-network segment wake-up is required, the method further includes:

[0013] If cross-regional wake-up is not required, other network segments within the target area to be woken up across network segments are determined according to the preset vehicle sleep wake-up conditions.

[0014] In one embodiment, after the step of waking up the other area controllers and the target network segment, the method further includes:

[0015] When the target protocol node detects the release of the wake-up source, it determines whether the target area controller has been woken up across network segments;

[0016] If the target area controller is not woken up across network segments, then the protocol nodes of the woken-up network segments in the target area will be put into hibernation control.

[0017] In one embodiment, after the step of determining whether the target area controller is woken up across network segments when the target protocol node detects the release of the wake-up source, the method further includes:

[0018] If the target area controller is woken up across network segments, then determine whether the target area controller is woken up across regions.

[0019] If the target area controller is not woken up across areas, then the CAN / CANFD network segment within the target area is put into hibernation control through the first type of network management method;

[0020] When the CAN network management module in the target area transitions to a sleep-ready state, the LIN network segment in the target area is put into sleep mode using the second type of network management method.

[0021] The Ethernet network segments within the target area are put into hibernation control using a third type of network management method.

[0022] In one embodiment, after the step of determining whether the target area controller is woken up across network segments, the method further includes:

[0023] If the target area controller is woken up across regions, then the target area controller is put into hibernation control within the backbone network using the first type of network management method. The backbone network includes multiple area controllers.

[0024] When the state of the CAN network management module of the backbone network transitions to the sleep preparation state, the CAN / CANFD network segment in the target area is put into sleep control through the first type of network management method;

[0025] The hibernation control of the LIN network segment within the target area is implemented using the second type of network management method;

[0026] The Ethernet network segments within the target area are put into hibernation control using a third type of network management method.

[0027] Furthermore, to achieve the above objectives, this application also proposes a multi-bus protocol network control device, which includes:

[0028] The target protocol node wake-up module is used to wake up the target protocol node and the target area controller where the target protocol node is located when the target protocol node corresponding to a certain bus protocol in the multiple bus protocols of the area control topology detects the activation of the wake-up source.

[0029] The cross-network segment wake-up judgment module is used to determine whether the target area controller needs to be woken up across network segments based on the preset vehicle sleep wake-up conditions;

[0030] The cross-region wake-up judgment module is used to determine whether the target area controller needs to perform cross-region wake-up based on the preset vehicle sleep wake-up conditions if cross-network segment wake-up is required.

[0031] Other area determination module is used to determine other area controllers to be woken up across regions and target network segments to be woken up in other regions according to the preset vehicle sleep wake-up conditions if cross-region wake-up is required.

[0032] Other area wake-up modules are used to wake up the other area controllers and the target network segment.

[0033] In addition, to achieve the above objectives, this application also proposes a multi-bus protocol network control device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the multi-bus protocol network control method as described above.

[0034] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the multi-bus protocol network control method described above.

[0035] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the multi-bus protocol network control method described above.

[0036] This application provides a multi-bus protocol network control method. When a wake-up source is detected on a target protocol node corresponding to a specific bus protocol in a regional control topology, the method wakes up the target protocol node and the target regional controller where the target protocol node is located. Based on preset vehicle sleep / wake-up conditions, it determines whether cross-segment wake-up and cross-region wake-up are required. If necessary, it determines other regional controllers and target network segments within other regions to be woken up based on preset vehicle sleep / wake-up conditions, and then performs wake-up control. This application achieves multi-bus protocol, multi-segment network collaborative control by simultaneously determining whether cross-segment and cross-region control of other regional controllers and network segments is required while controlling a bus protocol node and a regional controller, thereby determining all regional controllers and network segments to be controlled according to demand. Attached Figure Description

[0037] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0038] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0039] Figure 1 This is a flowchart illustrating an embodiment of the multi-bus protocol network control method of this application.

[0040] Figure 2 This is a schematic diagram of the architecture of the region control topology in this application;

[0041] Figure 3 This is a schematic diagram illustrating the process of a LIN slave node waking up a LIN network segment in this application;

[0042] Figure 4 This is a schematic diagram of the Ethernet controller in this application;

[0043] Figure 5 This is a flowchart illustrating Embodiment 2 of the multi-bus protocol network control method of this application;

[0044] Figure 6 This is a schematic diagram of the cross-segment sleep process in the multi-bus protocol network control method of this application;

[0045] Figure 7 This is a schematic diagram of the cross-regional sleep process in the multi-bus protocol network control method of this application;

[0046] Figure 8 This is a schematic diagram of the module structure of the multi-bus protocol network control device according to an embodiment of this application;

[0047] Figure 9 This is a schematic diagram of the device structure of the hardware operating environment involved in the multi-bus protocol network control method in the embodiments of this application.

[0048] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0049] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0050] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0051] The main solution of this application embodiment is as follows: when the target protocol node corresponding to a certain bus protocol in the multiple bus protocols of the area control topology detects the activation of the wake-up source, the target protocol node and the target area controller where the target protocol node is located are woken up; it is determined whether the target area controller needs to be woken up across network segments according to the preset vehicle hibernation wake-up conditions; if it needs to be woken up across network segments, it is determined whether the target area controller needs to be woken up across regions according to the preset vehicle hibernation wake-up conditions; if it needs to be woken up across regions, other area controllers to be woken up across regions and target network segments to be woken up in other regions are determined according to the preset vehicle hibernation wake-up conditions; the other area controllers and the target network segments are woken up.

[0052] With the development of electronic and electrical architectures, the architecture topology has gradually evolved from centralized domain control to area control centered on a central computing platform. The area control topology consists of a central computing platform, area controllers, and various buses. The central computing platform and area controllers communicate via Ethernet bus, and various LIN / CAN / CANFD / Ethernet nodes are connected to the area controllers within that domain. The commonly used application layer protocol for Ethernet bus communication is SOME / IP communication. In this vehicle architecture topology, the existence of multiple different bus protocols necessitates the coordination of sleep and wake-up operations across multiple subnets and bus protocols. Therefore, how to achieve network collaborative control across multiple bus protocols and network segments is a pressing problem that needs to be solved.

[0053] This application provides a solution that, when a wake-up source is detected on a target protocol node corresponding to a specific bus protocol in a regional control topology, wakes up the target protocol node and the target regional controller where the target protocol node is located; it then determines whether cross-network segment wake-up and cross-region wake-up are needed based on preset vehicle hibernation wake-up conditions; if so, it identifies other regional controllers to be woken up across regions and target network segments to be woken up within other regions based on preset vehicle hibernation wake-up conditions, and performs wake-up control. This application achieves multi-bus protocol, multi-network segment network collaborative control by simultaneously determining whether cross-network segment and cross-region control of other regional controllers and other network segments is needed while controlling a bus protocol node and a regional controller, thereby determining all regional controllers and network segments that need to be controlled according to requirements.

[0054] It should be noted that the execution subject of the method in this embodiment can be a vehicle architecture topology with multi-bus protocol network control, network communication and program execution functions; or it can be a car equipped with such a vehicle architecture topology.

[0055] Based on this, embodiments of this application provide a multi-bus protocol network control method, referring to... Figure 1 , Figure 1This is a flowchart illustrating the first embodiment of the multi-bus protocol network control method of this application.

[0056] In this embodiment, the multi-bus protocol network control method includes steps S10 to S50:

[0057] Step S10: When the target protocol node corresponding to a certain bus protocol in the multiple bus protocols of the area control topology detects the activation of the wake-up source, the target protocol node and the target area controller where the target protocol node is located are woken up.

[0058] It should be noted that this can be used as a reference. Figure 2 The architecture of the regional control topology in this application is described. The regional control topology consists of a central computing platform, regional controllers, and various buses (LIN / CAN / CANFD). In this application, the network management of the backbone network is the first level of network management, and the network management of the regional controllers and their respective subnets is the second level of network management. The backbone network mainly consists of a central computing platform and multiple regional controllers. The central computing platform and the regional controllers communicate via an Ethernet bus, and various LIN / CAN / CANFD / Ethernet nodes are connected to the regional controllers within that domain. The commonly used application layer protocol for Ethernet bus communication is SOME / IP communication. In this vehicle architecture topology, multiple different bus protocols exist (①LIN, ②CAN, ③CANFD, ④Ethernet bus, SOME / IP). Each bus protocol has different network management methods: The first type of network management method: CAN / CANFD network segment network management follows CAN's AUTOSAR network management for coordinated sleep and wake-up; The second type of network management method: LIN network segment network management follows LIN network management for coordinated sleep and wake-up; The third type of network management method: Ethernet network segment network management follows Ethernet network management for coordinated sleep and wake-up.

[0059] This section explains the network management methods for different protocols. It should be noted that the first type of network management method uses AUTOSAR network management for CAN and CANFD network segments. This means that dedicated network management messages are used for transmitting network sleep and wake-up signals. The AUTOSAR CanNM network management message sleep / wake-up process switches between three modes: a) Bus Sleep Mode; b) Prepare Bus Sleep Mode; c) Network Mode. The Network Mode has three internal states: 1) Repeat Message State; 2) Normal Operation State; 3) Ready Sleep State. After the vehicle is powered off, there are controllers that need to be woken up to perform their functions; these can be called network management nodes. The first network management node to be woken up locally can be called the active node. When the wake-up source is maintained, the active node's CAN transceiver module sends its own network management messages on the bus; when the wake-up source is released, the active node's CAN transceiver module stops sending its own network management messages on the bus.

[0060] This section describes the second type of network management method, where the LIN subnet uses a master-slave network management architecture. The process of waking up a LIN subnet is as follows: In a LIN network in sleep mode, either the master node or a slave node can request to be woken up by sending a wake-up signal. The LIN slave node wake-up method involves the slave node detecting a valid wake-up source and sending a wake-up signal to the LIN network. After sending three consecutive wake-up signals, if no response is received from the master node, three more wake-up signals are sent, and so on, for a maximum of nine wake-up signals. If no packet is sent from the master node after three sets, the wake-up fails, and the node enters sleep mode. The interval between each wake-up signal is 150ms to 250ms, and the interval between each set of wake-up signals is 1.5s. The process of a LIN slave node waking up a LIN network segment can be found in [reference needed]. Figure 3The LIN master node wake-up method involves the master node detecting a valid wake-up source and sending a message header as a wake-up signal, typically a dominant status signal longer than 150µs. The process of putting a LIN subnet to sleep is described below. When the LIN network is in a wake-up state, and the wake-up source is released, the LIN subnet needs to enter sleep mode. Only the master node can send sleep commands. When a slave node detects the release of the wake-up source, it informs the master node via an application message, and the master node then initiates the sleep process for the LIN subnet. Specifically, the LIN master node sends a 0x3C message on the LIN subnet to notify all slave nodes to enter sleep mode. Upon receiving the sleep message, the slave node immediately enters sleep mode and then listens to the network and its local input interface.

[0061] This section describes the third type of network management method. The controller for Ethernet communication is mainly a central computing platform and a zone controller. The main modules are as follows: Figure 4 As shown. The network management of the Ethernet segment is consistent with the network sleep / wake-up mechanism of its CAN module. That is, after the CAN sleep / wake-up module of the controller detects a wake-up, it synchronously wakes up the Ethernet sleep / wake-up module to issue a wake-up command; conversely, after the CAN sleep / wake-up module of the controller detects a sleep state, it synchronously wakes up the Ethernet sleep / wake-up module to issue a sleep command. Specifically: when a CAN node enters Repeat Message State, the SOME / IP server on the Ethernet bus should immediately send OfferService, and the client should immediately send SubscribeEventgroup, thus initiating SOME / IP communication. When a CAN node enters Prepare Bus-Sleep Mode, the SOME / IP server on the Ethernet bus should immediately send StopOfferService, and the client should immediately send StopSubscribeEventgroup, thus ending SOME / IP communication.

[0062] It is understood that this embodiment describes the network wake-up process using multiple protocols. Locally triggered wake-up sources are generally concentrated at the actuator end, such as the controllers of LIN, CAN, and CANFD. The vehicle is powered off, and each ECU is in sleep mode. When a LIN slave node (i.e., the target protocol node) detects the activation of a locally triggered wake-up source, it wakes up according to the second network management method, sending a wake-up command in its LIN network segment, thereby waking up the LIN master node and the target area controller to which the LIN master node belongs.

[0063] Step S20: Determine whether the target area controller needs to be woken up across network segments based on the preset vehicle sleep wake-up conditions.

[0064] It should be understood that the application processing module of the target area controller determines, based on the vehicle's preset sleep / wake-up conditions, whether cross-network segment wake-up is required or whether wake-up within the local subnet is sufficient to achieve the function. This determines whether to perform a first-level network management wake-up or a second-level network management wake-up.

[0065] In one possible implementation, step S20 may be followed by step S21:

[0066] Step S21: If cross-network segment wake-up is not required, then wake up the network segment where the target protocol node is located in the target area.

[0067] Understandably, if cross-network segment wake-up is not required, only the LIN module of the network segment where the target protocol node in the target area is located will be woken up, and communication will be carried out in that LIN network segment.

[0068] Step S30: If cross-network segment wake-up is required, determine whether the target area controller needs to be woken up across regions based on the preset vehicle sleep wake-up conditions.

[0069] It should be understood that if cross-network segment wake-up is required, the target area controller can be further determined based on the preset vehicle sleep wake-up conditions to determine whether cross-region wake-up is required.

[0070] In one possible implementation, step S31 may be included after step S30:

[0071] Step S31: If cross-regional wake-up is not required, determine other network segments within the target area to be woken up across network segments according to the preset vehicle sleep wake-up conditions.

[0072] Understandably, if cross-regional wake-up is not required, only cross-segment wake-up is needed. If a second-level wake-up within the local domain is required, the local controller will perform wake-up on each of the LIN, CAN, and CANFD network segments within that domain. CAN / CANFD uses the first type of network management method for wake-up; LIN uses the second type of network management method; and Ethernet uses the third type of network management method.

[0073] Step S40: If cross-region wake-up is required, determine other regional controllers to be woken up across regions and target network segments to be woken up in other regions according to the preset vehicle sleep wake-up conditions.

[0074] Understandably, if cross-domain wake-up is still required, a first-level wake-up is necessary, with the area controller acting as the active node for this first-level wake-up. Wake-up is performed using the first type of network management method on the backbone network. As the active node for the first-level wake-up, the area controller sends network management messages on the backbone network. Other area controllers on the backbone network filter according to the vehicle's preset sleep / wake-up conditions. Filtering can be done using hardware transceivers or software applications. This method has broader requirements for the transceivers of the area controller's signals and is more widely applicable. After filtering, other area controllers determine whether a wake-up of their own domain controller is needed, whether a second-level wake-up within their domain is required, and which subnets to wake up.

[0075] Step S50: Wake up the other area controllers and the target network segment.

[0076] It should be understood that if it is determined that other area controllers need to be woken up, then each LIN, CAN, and CANFD network segment within that area controller will be woken up. CAN / CANFD uses the first type of network management method for wake-up; LIN uses the second type of network management method for wake-up; and Ethernet uses the third type of network management method for wake-up.

[0077] This embodiment provides a multi-bus protocol network control method. When a wake-up source is detected on a target protocol node corresponding to a specific bus protocol in a regional control topology, the target protocol node and the target regional controller where the target protocol node is located are woken up. Based on preset vehicle sleep / wake-up conditions, it is determined whether cross-segment wake-up and cross-region wake-up are required. If necessary, other regional controllers to be woken up across regions and target network segments to be woken up within other regions are determined based on preset vehicle sleep / wake-up conditions, and wake-up control is performed. This application achieves multi-bus protocol, multi-segment network collaborative control by simultaneously determining whether cross-segment and cross-region control of other regional controllers and other network segments is required while controlling a bus protocol node and a regional controller, thereby determining all regional controllers and network segments that need to be controlled according to requirements.

[0078] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in Embodiment 1 above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 5 After step S50, the multi-bus protocol network control method further includes steps S60 to S70:

[0079] Step S60: When the target protocol node detects the release of the wake-up source, it determines whether the target area controller has been woken up across network segments.

[0080] It is understood that this embodiment describes the sleep strategy for multi-bus protocol networks. Locally triggered wake-up sources are generally concentrated at the various actuator ends, such as the controllers for LIN, CAN, and CANFD. When the vehicle is powered off, some ECUs wake up according to the multi-protocol network and detect the release of the locally triggered wake-up source via the LIN slave node. When the target protocol node detects the release of the wake-up source, it determines whether the target area controller has been woken up across network segments.

[0081] Step S70: If the target area controller is not woken up across network segments, then the protocol nodes of the woken-up network segments in the target area are put into hibernation control.

[0082] It should be understood that if the currently awakened area controller is not cross-segment, i.e., only within the local LIN network segment, then the master node of that LIN network segment will take the lead in completing the hibernation process for that LIN network segment. The LIN master node will control hibernation according to the second type of network management method.

[0083] In one feasible implementation, after step S60, steps S61 to S64 may also be included:

[0084] Step S61: If the target area controller is woken up across network segments, then determine whether the target area controller is woken up across regions.

[0085] Step S62: If the target area controller is not woken up across areas, then the CAN / CANFD network segment within the target area is put into hibernation control through the first type of network management method.

[0086] Understandably, if the target area controller is woken up by a cross-network segment but not by a cross-region, meaning it is currently woken up by the local LIN network segment but not by a cross-region, then the area controller will use the first type of network management method to hibernate within the CAN / CANFD subnets of that domain, i.e., it will stop sending its respective network management messages. The process for cross-segment hibernation can be found in [reference needed]. Figure 6 .

[0087] Step S63: When the state of the CAN network management module in the target area transitions to the sleep preparation state, the LIN network segment in the target area is put into sleep control through the second type of network management method.

[0088] It should be understood that when the CAN network management module in this domain transitions to PrepareSleepState, it uses the second type of network management to sleep in the LIN network segment of this area. That is, it sends a message 0x3C in the LIN subnet to notify all slave nodes to enter sleep mode. The slave node that receives the sleep message immediately enters sleep mode and then listens to the network and its local input interface.

[0089] Step S64: Implement hibernation control for the Ethernet network segment within the target area using the third type of network management method.

[0090] It should be understood that when the state of the CAN network management module in this domain transitions to PrepareSleepState, the third type of network management method is used for sleep control in the Ethernet subnet segment of this region.

[0091] In one feasible implementation, steps S65 to S68 may be included after step S61:

[0092] Step S65: If the target area controller is woken up across regions, then the target area controller is put into hibernation control within the backbone network using the first type of network management method. The backbone network includes multiple area controllers.

[0093] Understandably, if the currently awakened network includes the local LIN network segment, crosses network segments within the same domain, and crosses other network segments in other regions, then the area controller will use the first type of network management method to hibernate on the backbone network, i.e., stop sending network management messages. The process for cross-regional hibernation can be found in [reference needed]. Figure 7 .

[0094] Step S66: When the state of the CAN network management module of the backbone network transitions to the sleep preparation state, the CAN / CANFD network segment in the target area is put into sleep control through the first type of network management method.

[0095] It is understandable that when the network management module of the backbone network CAN transitions to PrepareSleepState, the CAN / CANFD subnet segment in this area will adopt the first type of network management mode to hibernate, that is, immediately stop sending network management messages.

[0096] Step S67: Implement hibernation control for the LIN network segment within the target area using the second type of network management method.

[0097] Understandably, when the CAN network management module of the backbone network transitions to PrepareSleepState, it uses the second type of network management to sleep in the local LIN network segment. This involves sending 0x3C in the LIN subnet to notify all slave nodes to enter sleep mode. Upon receiving the sleep message, the slave node immediately enters sleep mode and then listens to the network and its local input interface.

[0098] Step S68: Implement hibernation control for the Ethernet network segment within the target area using the third type of network management method.

[0099] It is understandable that when the CAN network management module transitions to PrepareSleepState, it will use the third type of network management to hibernate in the Ethernet subnet segment of this region.

[0100] In this embodiment, when the target protocol node detects the release of the wake-up source, it determines whether the target area controller has been woken up across network segments and across regions. If it has not been woken up across network segments, the protocol nodes of the woken-up network segments in the target area are put into hibernation control. When woken up across network segments, hibernation control is implemented for multiple protocol network segments using three different network management methods. When woken up across regions, hibernation control is implemented for multiple protocol network segments within the backbone network using three different network management methods, thereby enabling coordinated hibernation control after multiple protocol networks are woken up.

[0101] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the multi-bus protocol network control method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0102] This application also provides a multi-bus protocol network control device; please refer to [reference needed]. Figure 8 The multi-bus protocol network control device includes:

[0103] The target protocol node wake-up module 10 is used to wake up the target protocol node and the target area controller where the target protocol node is located when the target protocol node corresponding to a certain bus protocol in the multiple bus protocols of the area control topology detects the activation of the wake-up source.

[0104] The cross-network segment wake-up judgment module 20 is used to determine whether the target area controller needs to perform cross-network segment wake-up based on the preset vehicle hibernation wake-up conditions;

[0105] The cross-region wake-up judgment module 30 is used to determine whether the target area controller needs to perform cross-region wake-up based on the preset vehicle sleep wake-up conditions if cross-network segment wake-up is required.

[0106] Other area determination module 40 is used to determine other area controllers to be woken up across regions and target network segments to be woken up in other regions according to the preset vehicle sleep wake-up conditions if cross-region wake-up is required.

[0107] Other area wake-up module 50 is used to wake up the other area controller and the target network segment.

[0108] The multi-bus protocol network control device provided in this application, employing the multi-bus protocol network control method described in the above embodiments, can solve the technical problem. Compared with the prior art, the beneficial effects of the multi-bus protocol network control device provided in this application are the same as those of the multi-bus protocol network control method described in the above embodiments, and other technical features in the multi-bus protocol network control device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0109] This application provides a multi-bus protocol network control device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the multi-bus protocol network control method in Embodiment 1 above.

[0110] The following is for reference. Figure 9 This document illustrates a structural schematic diagram of a multi-bus protocol network control device suitable for implementing embodiments of this application. The multi-bus protocol network control device in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), and in-vehicle terminals (e.g., in-vehicle navigation terminals), as well as fixed terminals such as digital TVs and desktop computers. Figure 9 The multi-bus protocol network control device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0111] like Figure 9As shown, the multibus protocol network control device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the multibus protocol network control device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows the multibus protocol network control device to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows multibus protocol network control devices with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0112] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0113] The multi-bus protocol network control device provided in this application, employing the multi-bus protocol network control method described in the above embodiments, can solve the technical problems of multi-bus protocol network control. Compared with the prior art, the beneficial effects of the multi-bus protocol network control device provided in this application are the same as those of the multi-bus protocol network control method described in the above embodiments, and other technical features of this multi-bus protocol network control device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

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

[0115] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations 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. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0116] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the multi-bus protocol network control method described in the above embodiments.

[0117] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0118] The aforementioned computer-readable storage medium may be included in a multi-bus protocol network control device; or it may exist independently and not assembled into a multi-bus protocol network control device.

[0119] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0120] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0121] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0122] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described multi-bus protocol network control method, thereby solving the technical problem. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as the beneficial effects of the multi-bus protocol network control method provided in the above embodiments, and will not be repeated here.

[0123] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the multibus protocol network control method described above.

[0124] The computer program product provided in this application can solve the technical problem. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the multi-bus protocol network control method provided in the above embodiments, and will not be repeated here.

[0125] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A multi-bus protocol network control method, characterized in that, The method includes: When the target protocol node corresponding to a certain bus protocol in the multiple bus protocols of the area control topology detects the activation of the wake-up source, the target protocol node and the target area controller where the target protocol node is located are woken up. Determine whether the target area controller needs to perform cross-network segment wake-up based on the preset vehicle hibernation and wake-up conditions; If cross-network segment wake-up is required, the target area controller is determined to be required to perform cross-region wake-up based on the preset vehicle sleep wake-up conditions. If cross-region wake-up is required, other regional controllers to be woken up and target network segments to be woken up in other regions are determined according to the preset vehicle sleep wake-up conditions. Wake up the other area controllers and the target network segment; After the step of waking up the other area controllers and the target network segment, the method further includes: When the target protocol node detects the release of the wake-up source, it determines whether the target area controller has been woken up across network segments; If the target area controller is woken up across network segments, then determine whether the target area controller is woken up across regions. If the target area controller is not woken up across areas, then the CAN / CANFD network segment within the target area is put into hibernation control through the first type of network management method; When the CAN network management module in the target area transitions to a sleep-ready state, the LIN network segment in the target area is put into sleep mode using the second type of network management method. The Ethernet network segments within the target area are put into hibernation control using a third type of network management method; If the target area controller is woken up across regions, then the target area controller is put into hibernation control within the backbone network using the first type of network management method. The backbone network includes multiple area controllers. When the state of the CAN network management module of the backbone network transitions to the sleep preparation state, the CAN / CANFD network segment in the target area is put into sleep control through the first type of network management method; The hibernation control of the LIN network segment within the target area is implemented using the second type of network management method; The Ethernet network segments within the target area are put into hibernation control using a third type of network management method.

2. The method as described in claim 1, characterized in that, After the step of determining whether the target area controller needs to perform cross-network segment wake-up based on preset vehicle sleep / wake-up conditions, the method further includes: If cross-network segment wake-up is not required, then wake up the network segment where the target protocol node is located within the target area.

3. The method as described in claim 1, characterized in that, If cross-network segment wake-up is required, the step of determining whether the target area controller needs to perform cross-area wake-up based on the preset vehicle sleep-wake conditions further includes: If cross-regional wake-up is not required, other network segments within the target area to be woken up across network segments are determined according to the preset vehicle sleep wake-up conditions.

4. The method as described in claim 1, characterized in that, After the step of waking up the other area controllers and the target network segment, the method further includes: When the target protocol node detects the release of the wake-up source, it determines whether the target area controller has been woken up across network segments; If the target area controller is not woken up by a cross-network segment, then the protocol nodes of the woken-up network segment in the target area will be put into hibernation control.

5. A multi-bus protocol network control device, characterized in that, The multi-bus protocol network control device includes: The target protocol node wake-up module is used to wake up the target protocol node and the target area controller where the target protocol node is located when the target protocol node corresponding to a certain bus protocol in the multiple bus protocols of the area control topology detects the activation of the wake-up source. The cross-network segment wake-up judgment module is used to determine whether the target area controller needs to be woken up across network segments based on the preset vehicle sleep wake-up conditions; The cross-region wake-up judgment module is used to determine whether the target area controller needs to perform cross-region wake-up based on the preset vehicle sleep wake-up conditions if cross-network segment wake-up is required. Other area determination module is used to determine other area controllers to be woken up across regions and target network segments to be woken up in other regions according to the preset vehicle sleep wake-up conditions if cross-region wake-up is required. Other area wake-up modules are used to wake up the other area controllers and the target network segment; The other area wake-up module is also used to determine whether the target area controller is woken up across network segments when the target protocol node detects the release of the wake-up source; if the target area controller is woken up across network segments, then determine whether the target area controller is woken up across regions. The other area wake-up module is further configured to, if the target area controller is not woken up across areas, perform sleep control on the CAN / CANFD network segment within the target area using a first type of network management method; when the state of the CAN network management module within the target area transitions to a sleep-ready state, perform sleep control on the LIN network segment within the target area using a second type of network management method; and perform sleep control on the Ethernet network segment within the target area using a third type of network management method. The other area wake-up module is also used to perform sleep control on the target area controller within the backbone network using the first type of network management method if the target area controller is woken up across areas, and the backbone network includes multiple area controllers; The other area wake-up module is also used to control the CAN / CANFD network segment in the target area to sleep using the first type of network management method when the state of the network management module of the backbone network transitions to the sleep preparation state; to control the LIN network segment in the target area to sleep using the second type of network management method; and to control the Ethernet network segment in the target area to sleep using the third type of network management method.

6. A multi-bus protocol network control device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the multibus protocol network control method as described in any one of claims 1 to 4.

7. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the multi-bus protocol network control method as described in any one of claims 1 to 4.

8. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the multibus protocol network control method as described in any one of claims 1 to 4.

Images