Dynamic management methods, architecture, media, and computer programs for vehicular network devices

Abstract

The application relates to the technical field of Internet of Vehicles, in particular to a dynamic management method and architecture of a vehicle-mounted network device, a medium and a computer program, wherein the method comprises the following steps: receiving a function configuration requirement of a user; determining one or more target devices and a management operation of the one or more target devices according to the function configuration requirement; identifying a hardware management function domain server where the one or more target devices are located; and delivering the management operation of the one or more target devices to the hardware management function domain server, wherein the hardware management function domain server triggers the management operation of the target devices according to a network topology. Therefore, the problems that the dynamic management of hardware devices cannot be realized, the management cost is high, and power consumption is large and the like in the related art are solved.

Description

Technical Field

[0001] This application relates to the field of vehicle networking technology, and in particular to a dynamic management method, architecture, medium and computer program for in-vehicle network devices. Background Technology

[0002] With the increasing prevalence of "intelligentization, connectivity, electrification, and sharing" in automobiles, "software-defined vehicles" have become a trend, bringing car owners a plethora of new functions and features. To sell and promote these new functions and features, OEMs need to provide car owners with different pricing packages and support various consumer behaviors, such as software availability, trial use, cancellation, and periodic subscriptions.

[0003] However, if user A uses a subscription (e.g., annual plan), the optimal solution when the plan expires is to temporarily or partially shut down such devices. This can save energy, maximize driving range, and extend the lifespan of the devices. In practical applications, when the user's current plan does not use these in-vehicle network devices, these idle devices are still in working condition. Summary of the Invention

[0004] This application provides a dynamic management method, architecture, medium, and computer program for in-vehicle network devices to solve the problems of high management costs and high power consumption in related technologies, which cannot achieve dynamic management of hardware devices.

[0005] The first aspect of this application provides a dynamic management method for vehicular network devices. The method is applied to a hardware management server and includes the following steps: receiving a user's function configuration requirements; determining one or more target devices and management operations for one or more target devices based on the function configuration requirements, and identifying the hardware management function domain server where one or more target devices are located; and sending management operations for one or more target devices to the hardware management function domain server, wherein the hardware management function domain server triggers the management operations for the target devices according to the network topology.

[0006] Optionally, the hardware management server, the hardware management function domain server, and one or more target devices communicate using one or more of the following vehicular communication technologies: CAN, CANFD, LIN, FlexRay, and vehicular Ethernet.

[0007] Optionally, sending management operations for one or more target devices to the hardware management function domain server includes: sending management operations for one or more target devices to the gateway device, wherein the gateway device sends management operations for one or more target devices to the hardware management function domain server based on the vehicle's EEA (Electrical / Electronic Architecture) topology information.

[0008] A second aspect of this application provides a dynamic management method for vehicular network devices applied to a hardware management functional domain server, wherein the hardware management functional domain server for each functional domain is unique, and includes the following steps: receiving management operations for one or more target devices issued by the hardware management server; and triggering management operations for the target devices according to the network topology.

[0009] Optionally, the management operation of the target device is triggered according to the network topology, including: controlling the target device to perform the management operation, and / or performing the management operation when the vehicle is in the target state.

[0010] A third aspect of this application provides a hardware management server, including: a memory, a processor, and a computer program stored in the memory and executable on the processor. The processor executes the program to implement the dynamic management method for in-vehicle network devices as described in the above embodiments.

[0011] The fourth aspect of this application provides a hardware management function domain server, including: a memory, a processor, and a computer program stored in the memory and executable on the processor. The processor executes the program to implement the dynamic management method of the vehicle network device as described in the above embodiments.

[0012] A fifth aspect of this application provides a dynamic management architecture for an in-vehicle network device, including a hardware management server and a hardware management function domain server. The hardware management server receives user function configuration requirements, determines one or more target devices and management operations for one or more target devices based on the function configuration requirements, identifies the hardware management function domain server where one or more target devices are located, and sends management operations for one or more target devices to the hardware management function domain server. The hardware management function domain server receives management operations for one or more target devices sent by the hardware management server and triggers management operations for the target devices according to the network topology.

[0013] A sixth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which is executed by a processor to implement the dynamic management method for an in-vehicle network device as described in the above embodiments.

[0014] A seventh aspect of this application provides a computer program product having a computer program or instructions stored thereon. When the computer program or instructions are executed, they implement the dynamic management method for in-vehicle network devices as described in the above embodiments.

[0015] Therefore, this application has at least the following beneficial effects:

[0016] This application embodiment allows for flexible management of target devices based on user functional configuration requirements. This enables the target device to be shut down promptly when needed, reducing power consumption and management costs, and simplifying the workload during development and production. Therefore, it solves the problems of high management costs and high power consumption inherent in related technologies, which cannot achieve dynamic management of hardware devices.

[0017] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0018] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein:

[0019] Figure 1 This is a flowchart of a dynamic management method for an in-vehicle network device according to an embodiment of this application;

[0020] Figure 2 This is an example diagram of the dynamic management architecture of an in-vehicle network device according to an embodiment of this application;

[0021] Figure 3 This is a flowchart of a single device management process according to one embodiment of this application;

[0022] Figure 4 This is a flowchart of multiple device management processes provided according to one embodiment of this application;

[0023] Figure 5 This is a flowchart of device partial function management according to an embodiment of this application;

[0024] Figure 6 This is an example diagram of a computing and communication architecture provided according to an embodiment of this application;

[0025] Figure 7 This is a schematic diagram of an electrical computing and communication architecture network according to an embodiment of this application;

[0026] Figure 8 A flowchart of a dynamic management method for an in-vehicle network device according to another embodiment of this application;

[0027] Figure 9 This is a block diagram illustrating the dynamic management of an in-vehicle network device according to an embodiment of this application. Detailed Implementation

[0028] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0029] The following description, with reference to the accompanying drawings, outlines a dynamic management method, architecture, medium, and computer program for an in-vehicle network device according to embodiments of this application. Addressing the problems mentioned in the background section, this application provides a dynamic management method for in-vehicle network devices. In this method, target devices are flexibly managed according to the user's functional configuration requirements, allowing for timely shutdown of target devices when services are not needed, thereby reducing power consumption and management costs, and simplifying the workload during development and production. This solves the problems of high management costs and high power consumption inherent in related technologies, which cannot achieve dynamic management of hardware devices.

[0030] Specifically, Figure 1 This is a flowchart illustrating a dynamic management method for an in-vehicle network device provided in an embodiment of this application.

[0031] like Figure 1 As shown, the dynamic management method for vehicle-mounted network devices is applied to a hardware management server and includes the following steps:

[0032] In step S101, the user's function configuration requirements are received.

[0033] Among them, the functional configuration requirement can be to activate, enable, or disable a certain device. For example, the user's functional configuration requirement can be to enable or disable one or more hardware devices.

[0034] In step S102, one or more target devices and management operations for one or more target devices are determined according to functional configuration requirements, and the hardware management function domain server where one or more target devices are located is identified.

[0035] The hardware management server, the hardware management function domain server, and one or more target devices communicate using one or more of the following vehicle communication technologies: CAN, CANFD, LIN, FlexRay, and vehicle Ethernet.

[0036] For ease of understanding, this application embodiment can be described in detail using the activation of a single hardware device as a user's functional configuration requirement. Assume that the hardware management server is deployed in a TBOX, and the vehicle adopts a centralized EEA architecture, such as... Figure 2 As shown, TBOX communicates with ECU-A and ECU-X through a centralized gateway;

[0037] 2. The owner's original autonomous driving package expires and a new autonomous driving package needs to be subscribed to, which requires re-enabling specific ECUs, such as LiDAR.

[0038] 3. The autonomous driving domain controller can wake up the LiDAR. For example... Figure 2 In this context, ECU-A is the autonomous driving domain controller, and ECU-X is the LiDAR.

[0039] Specifically, such as Figure 3 As shown, this application embodiment can determine the specific hardware of the vehicle that needs to be activated based on functional configuration requirements. For example, if it is necessary to reactivate the vehicle's LiDAR, this requirement is submitted to TBOX. The requirements include, but are not limited to: VIN (Vehicle Identification Number), the target device to be activated, where the VIN is globally unique. In this application embodiment, the device name of the target device can be LiDAR 1, such as... Figure 2 The ECU-X shown can have a hardware ID of 0x701. The hardware management function domain server where LiDAR 1 resides is ECU-A.

[0040] In step S103, management operations for one or more target devices are sent to the hardware management function domain server, wherein the hardware management function domain server triggers management operations for the target devices according to the network topology.

[0041] Based on the above embodiments, the target device is ECU-X, the hardware management function domain server is ECU-A, and the hardware management server is deployed on TBOX.

[0042] It is understood that, in this application embodiment, the request to activate the target device ECU-X can be sent to the gateway device, wherein the gateway device sends the activation operation of the target device ECU-X to ECU-A based on the topology information of the vehicle EEA. For example... Figure 3 As shown, it includes the following steps:

[0043] Step 31: TBOX issues activation for specific hardware requirements

[0044] The TBOX issues activation requests for specific hardware based on the EEA topology information. The TBOX then sends this activation request to the CGW (Central Gateway). If the vehicle supports other EEA architectures, the request is then issued to the next hop in the topology network according to the specific EEA architecture.

[0045] Step 32: CGW issues activation requirements for specific hardware.

[0046] The CGW issues activation requests for specific hardware based on the EEA topology information. The CGW then sends these activation requests to the ECU-A. If the vehicle supports other EEA architectures, the request is then issued to the next hop in the topology network according to the specific EEA architecture.

[0047] Step 33: ECU-A receives the request to activate the target device, and after ECU-A receives the request to activate the specific hardware configuration,

[0048] Save the corresponding information to ensure it remains effective after the next power-on cycle;

[0049] Step 34: ECU-A wakes up ECU-X

[0050] ECU-A wakes up ECU-X based on the network topology. Depending on the wake-up method of ECU-X, it can be achieved by directly supplying power to ECU-X to trigger an enable signal, or by network wake-up, among other methods.

[0051] In actual operation, ECU-X communicates with ECU-A independently. In fact, ECU-X can also be on the same CAN bus or a different CAN bus as long as ECU-A can wake up ECU-X; there are no specific limitations.

[0052] Step 35: ECU-X wake-up complete

[0053] After ECU-X is woken up, it sends CAN signals to surrounding ECUs by default.

[0054] Step 36: ECU-A confirms the activation requirement of the target device.

[0055] After receiving the signal from ECU-X, ECU-A determines that ECU-X has been woken up.

[0056] In summary, the dynamic management method for vehicle network devices in this application can activate a single target device. The above embodiments can also be extended to disable or enable a single target device. To avoid redundancy, these will not be elaborated here.

[0057] The following is combined Figure 4 and Figure 5 The dynamic management method for in-vehicle network devices according to embodiments of this application is further described. Among them, Figure 4 The process describes the requirement to activate multiple target devices. Figure 5 The process outlines the requirements for enabling certain functions of the target device, specifically:

[0058] I. Considering that some functions require the simultaneous activation of a group of hardware devices, let's assume:

[0059] 1. The hardware management server is deployed in TBOX. The whole vehicle adopts a centralized EEA architecture. TBOX communicates with ECU-A and ECU-X through a centralized gateway.

[0060] 2. The owner's original autonomous driving package expires and a new autonomous driving package needs to be subscribed to, which requires re-enabling the LiDAR and other devices, such as the two rear corner radars.

[0061] 3. The autonomous driving domain controller can wake up the LiDAR and other devices. Among them, Figure 2 In the ECU-A module, the autonomous driving domain controller is ECU-X, the lidar is ECU-Y, and the millimeter-wave radar is ECU-Y.

[0062] Specifically, such as Figure 4 As shown, it includes the following steps:

[0063] Step 41: Activate the target device of a specific vehicle according to the user's needs and submit the request to the vehicle cloud server. If it is necessary to reactivate the LiDAR and millimeter-wave radar of the specific vehicle, the message includes, but is not limited to: VIN, a set of hardware to be activated.

[0064] Step 42: The vehicle cloud server issues activation requests for specific hardware to the specific vehicle's TBOX.

[0065] The messages include, but are not limited to: hardware ID, a group of hardware devices to be activated, as shown in Table 1.

[0066] Table 1

[0067] Serial Number Hardware to be activated Hardware ID 1 LiDAR 1 0x701 2 Millimeter-wave radar 1 0x702 3 Millimeter-wave radar 2 0x703

[0068] Optionally, the TBOX records the activation requirement for specific hardware. If the vehicle supports commands for querying hardware status, the hardware can be found and it is in an active state.

[0069] Step 43: TBOX issues activation for specific hardware requirements

[0070] The TBOX issues activation requests for specific hardware based on the EEA topology information. According to the assumptions of this embodiment, this request is then sent to the CGW. Of course, if the vehicle supports other EEA architectures, the request is then issued to the next hop in the topology network according to the specific EEA architecture.

[0071] Step 44: CGW issues activation requirements for specific hardware.

[0072] The CGW issues activation requests for specific hardware based on the EEA topology information. According to the assumptions of this embodiment, this request is sent to the ECU-A or multiple hardware components. Of course, if the vehicle supports other EEA architectures, the request is then issued to the next hop of different hardware components in the topology network according to the specific EEA architecture.

[0073] Step 45: ECU-A receives activation requirements for specific hardware.

[0074] Optionally, ECU-A can also save specific hardware activation requirements to ensure they remain effective after the next power-on cycle;

[0075] Step 46: ECU-A wakes up ECU-X and ECU-Y

[0076] ECU-A triggers the wake-up of ECU-X and ECU-Y based on the network topology. Depending on the wake-up method of ECU-X and ECU-Y, various wake-up methods can be used, such as directly supplying power to ECU-X and ECU-Y to trigger an enable signal, or network wake-up.

[0077] For vehicle safety, this step may require the vehicle to be stationary or to be activated and woken up after re-entering the power-on cycle.

[0078] Step 47: ECU-X and ECU-Y wake-up complete

[0079] After ECU-X and ECU-Y are woken up, they send signals to the surrounding ECUs by default.

[0080] Step 48: ECU-A confirms activation of specific hardware requirements.

[0081] After receiving the corresponding signal, ECU-A determines that ECU-X and ECU-Y have been awakened. Simultaneously, if necessary, it records the current state of ECU-X and ECU-Y.

[0082] II. Taking autonomous driving as an example, previously, driving used a vehicle domain controller and parking used a parking controller. Due to the rapid advancement of electronic technology, it is now gradually becoming common to use a single controller to perform different functions, such as the increasingly prevalent integrated driving and parking solution. For a separate driving and parking architecture, when the parking controller needs to be used or becomes ineffective, the method described in Embodiment 1 above is used, simultaneously enabling the parking controller and the corresponding sensors. However, for an integrated driving and parking controller, this embodiment requires defining a process for enabling the function.

[0083] Specifically, such as Figure 5 As shown, it includes the following steps:

[0084] Step 51: Based on the user's subscription requirements, disable the hardware configuration of a specific vehicle and submit the request to the vehicle cloud server. The message includes, but is not limited to: VIN, hardware to be disabled.

[0085] Step 52: The vehicle cloud server sends a message to the specific vehicle's TBOX indicating a failed hardware requirement. The message includes, but is not limited to:

[0086] The hardware ID, the hardware to be deactivated, and the function ID to be deactivated are shown in Table 2.

[0087] Table 2

[0088] Serial Number Hardware awaiting expiration Hardware ID Function ID 1 Traveling Wave Integrated Domain Controller 0x704 0x03

[0089] Step 53: The TBOX records the specific hardware requirement for failure. If the vehicle supports the command to query the hardware status, the hardware can be found through this command, and the hardware is in an active state.

[0090] Step 54: TBOX issues failure-specific hardware requirements

[0091] The TBOX issues a failure-specific hardware request based on the EEA topology information. According to the assumptions of this embodiment, this request is then sent to the CGW. Of course, if the vehicle supports other EEA architectures, the request is then issued to the next hop in the topology network according to the specific EEA architecture.

[0092] Step 55: CGW issues specific hardware failure requirements

[0093] The CGW issues failure-specific hardware requests based on the EEA topology information. According to the assumptions of this embodiment, the request is sent to the ECU-A or multiple hardware components. Of course, if the vehicle supports other EEA architectures, the request is then issued to the next hop of different hardware components in the topology network according to the specific EEA architecture.

[0094] Step 56: ECU-A receives specific hardware requirements for failure.

[0095] As the hardware to be disabled, ECU-A receives a failure command and the function to be disabled, and then disables the corresponding function according to the command, such as disabling the parking function. At this time, the driving function is not affected.

[0096] Optionally, after receiving a specific hardware configuration failure, ECU-A saves the corresponding information to ensure that it continues to be effective after the next power-on.

[0097] Step 57: ECU-A wakes up ECU-X and the corresponding ECU.

[0098] ECU-A triggers the wake-up of ECU-X and its corresponding ECUs based on the network topology. Depending on the wake-up method of ECU-X and its corresponding ECUs, various wake-up methods can be used, such as directly supplying power to ECU-X and its corresponding ECUs to trigger an enable signal, or network wake-up.

[0099] Step 58: ECU-X and its corresponding ECUs have been woken up.

[0100] After ECU-X and its corresponding ECU are woken up, they send signals to the surrounding ECUs by default.

[0101] Step 59: ECU-A confirms specific hardware requirements for failure.

[0102] After receiving the corresponding signal, ECU-A determines that the corresponding ECU has been awakened. Simultaneously, if necessary, it records the current state of the corresponding ECU.

[0103] It should be noted that, to ensure vehicle and personal safety, the ECU can, depending on its specific function, require the vehicle to be stationary or to re-enter a power-on cycle for hibernation or wake-up. Secondly, while the above embodiments use a centralized CGW as an example, the embodiments of this patent are also applicable to other EEA architectures, such as computing and communication architectures, such as... Figure 6 As shown, it includes: VIU (Vehicle Interface Unit), VDC (Vehicle Domain Controller), MDC (Mobile Data Center), and CDC (Cocktail Domain Controller).

[0104] Although Ethernet is used for transmission between VIUs, the ECUs connected to the VIUs still use CAN or CANFD as the transmission method. For example... Figure 7 As shown, the ECUs connected to VIU4 still use CAN and CANFD; even the connected ECU (ECU42) still connects to other ECUs (ECU421, ECU422).

[0105] Furthermore, the embodiments of this application also apply to simplifying ECU configuration files. Taking autonomous driving domain control as an example, configuration A has two more rear corner radars than configuration B. According to current practices, configuration A and configuration B require two separate configuration files; however, this application can use a single configuration file, and then add the two rear corner radars for configuration A during the production process, thereby simplifying the configuration.

[0106] The dynamic management method for vehicular network devices proposed in this application can flexibly manage target devices according to user functional configuration requirements, enabling timely shutdown of target devices when services are not needed, thereby reducing power consumption and management costs, and simplifying the workload in the development and production stages. This solves the problems of high management costs and high power consumption inherent in related technologies, which cannot achieve dynamic management of hardware devices.

[0107] The above embodiments focus on the dynamic management method of the vehicle network device of the present invention from the perspective of the hardware management server. The following embodiments will focus on the dynamic management method of the vehicle network device of the present invention from the perspective of the hardware management function domain server. Any details not covered in the embodiments can be referred to each other.

[0108] like Figure 8 As shown, the dynamic management method for the vehicle network device is applied to the hardware management function domain server and includes the following steps:

[0109] In step S201, management operations for one or more target devices are received from the hardware management server.

[0110] In step S202, management operations of the target device are triggered according to the network topology.

[0111] In one embodiment of this application, triggering a management operation of a target device according to the network topology includes: controlling the target device to perform a management operation, and / or performing a management operation when the vehicle is in a target state.

[0112] The dynamic management method for vehicular network devices proposed in this application can flexibly manage the hardware of target devices according to the user's functional configuration requirements. This allows the target device to be shut down promptly when services are not needed, thereby reducing power consumption and management costs, and simplifying the workload in the development and production stages. This solves the problems of high management costs and high power consumption inherent in related technologies, which cannot achieve dynamic management of hardware devices.

[0113] In addition, this application embodiment also provides a dynamic management architecture 90 for in-vehicle network devices, including: a hardware management server 901 and a hardware management function domain server 902.

[0114] The hardware management server 901 is used to receive the user's function configuration requirements, determine one or more target devices and management operations for one or more target devices based on the function configuration requirements, identify the hardware management function domain server 902 where one or more target devices are located, and send the management operations for one or more target devices to the hardware management function domain server 902; the hardware management function domain server 902 is used to receive the management operations for one or more target devices sent by the hardware management server 901, and trigger the management operations for the target devices according to the network topology.

[0115] like Figure 2 As shown, the hardware management server 901 can dynamically manage (such as enabling or disabling) in-vehicle network hardware devices based on customer needs; and broadcast or unicast the corresponding ECU dynamic information to the relevant ECU.

[0116] Input may include, but is not limited to:

[0117] 1) TBOX: OEMs can remotely manage hardware devices via the cloud;

[0118] 2) IHU: Input by the driver on the IHU;

[0119] 3) Combination keys: Input is made by the driver using keypads;

[0120] This logic function can be deployed in ECUs such as smart cockpit, TBOX, intelligent driving, and VCU. In terms of the number of devices, there is one and only one in the entire vehicle.

[0121] The hardware management function domain server 902 can receive management messages from the hardware management server, manage the vehicle network hardware devices in this function domain, such as enabling or disabling them; and record the status of this ECU to ensure that the configuration takes effect after the vehicle is powered on again.

[0122] This logic function can be deployed within any ECU that requires dynamic configuration support, or within ECUs such as smart cockpits, TBOX, intelligent driving systems, and VCUs. Each functional domain has one and only one hardware functional domain server.

[0123] In addition, such as Figure 2 The hardware management client shown can receive management messages from the hardware management domain server, locally enable or disable in-vehicle network hardware devices (e.g., enable or disable), and record the status of this ECU to ensure the configuration takes effect the next time the vehicle is powered on. This logic function can be deployed in any ECU that needs to support dynamic configuration. Simultaneously, the hardware management domain server and hardware management client can be deployed within a single ECU, such as a domain controller.

[0124] The above logical functions can communicate with each other using vehicle communication technologies such as CAN, CANFD, LIN, FlexRay, and vehicle Ethernet. Figure 2 The communication method described is merely an example and is not specifically limited.

[0125] This application also provides a hardware management server, including: a memory, a processor, and a computer program stored in the memory and executable on the processor. The processor executes the program to implement a dynamic management method for in-vehicle network devices applied to the hardware management server as described in the above embodiments.

[0126] This application also provides a hardware management function domain server, including: a memory, a processor, and a computer program stored on the memory and executable on the processor. The processor executes the program to implement a dynamic management method for in-vehicle network devices applied to the hardware management function domain server as described in the above embodiments.

[0127] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the above-described dynamic management method for in-vehicle network devices.

[0128] This application also provides a computer program product that stores a computer program or instructions thereon. When the computer program or instructions are executed, they implement the dynamic management method of the vehicle network device as described in the above embodiments.

[0129] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0130] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "N" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0131] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more N executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.

[0132] It should be understood that the various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, the N steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (FPGAs), field-programmable gate arrays (FPGAs), etc.

[0133] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0134] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.

Claims

1. A method for dynamic management of in-vehicle network devices, characterized by, The method is applied to a hardware management server, and comprises the following steps: receiving a functional configuration requirement of a user; determining one or more target devices and management operations of the one or more target devices according to the functional configuration requirement, and identifying a hardware management functional domain server where the one or more target devices are located; downloading the management operations of the one or more target devices to the hardware management functional domain server, wherein the hardware management functional domain server triggers the management operations of the target devices according to a network topology; the downloading of the management operations of the one or more target devices to the hardware management functional domain server comprises downloading the management operations of the one or more target devices to a gateway device, wherein the gateway device sends the management operations of the one or more target devices to the hardware management functional domain server according to topology information of a vehicle EEA.

2. The method of claim 1, wherein, The hardware management server, the hardware management functional domain server and the one or more target devices communicate with each other in one or more of the following manners: CAN, CANFD, LIN, FlexRay and vehicle-mounted Ethernet.

3. A method of dynamic management of in-vehicle network devices, characterized by, The method is applied to a hardware management functional domain server, wherein hardware management functional domain servers of different functional domains are unique, and comprises the following steps: receiving management operations of one or more target devices downloaded by a hardware management server; wherein the hardware management server downloads the management operations of the one or more target devices to a gateway device, and the gateway device sends the management operations of the one or more target devices to the hardware management functional domain server according to topology information of a vehicle EEA; triggering the management operations of the target devices according to a network topology.

4. The dynamic management method of the in-vehicle network device according to claim 3, characterized by, The triggering of the management operations of the target devices according to the network topology comprises: controlling the target devices to execute the management operations, and / or executing the management operations when the vehicle is in a target state.

5. A hardware management server, characterized by comprise: a memory, a processor and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the dynamic management method of the vehicle-mounted network device according to any one of claims 1 to 4.

6. A hardware management function domain server, characterized by, comprise: a memory, a processor and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the dynamic management method of the vehicle-mounted network device according to any one of claims 1 to 4.

7. A dynamic management architecture for in-vehicle network devices, characterized by, comprise: a hardware management server and a hardware management functional domain server; the hardware management server is configured to receive a functional configuration requirement of a user, determine one or more target devices and management operations of the one or more target devices according to the functional configuration requirement, identify a hardware management functional domain server where the one or more target devices are located, and download the management operations of the one or more target devices to a gateway device, wherein the gateway device sends the management operations of the one or more target devices to the hardware management functional domain server according to topology information of a vehicle EEA. The hardware management function domain server is configured to receive a management operation of one or more target devices issued by the hardware management server, and trigger the management operation of the target devices according to a network topology.

8. A computer readable storage medium having stored thereon a computer program, characterized in that, The program is executed by a processor to implement the dynamic management method of the vehicle-mounted network device according to any one of claims 1-4.

9. A computer program product having stored thereon a computer program or instructions, characterized in that, The computer program or instructions are executed to implement the dynamic management method of the vehicle-mounted network device according to any one of claims 1-4.

Images