Vehicle-mounted application system, implementation method, storage medium and vehicle-mounted equipment
By containerizing the on-board functional modules and dynamically adjusting the communication strategy, the cost problems and low security problems caused by high hardware redundancy in the prior art are solved, and the safety and stability of the on-board safety system are improved while controlling the hardware costs.
Patent Information
- Application Number
- CN202411969259.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-12-30
- Publication Date
- 2025-05-30
AI Technical Summary
When existing on-board safety technologies achieve high safety performance, the hardware redundancy is high, resulting in higher overall system costs; while systems without hardware redundancy have low security levels that can be achieved, making it difficult to make a trade-off between security and hardware costs.
By containerizing the functional modules, the software and hardware are decoupled, and the overall system cost is reduced; at the same time, through real-time analysis of the container monitoring and management module and querying communication topology information, communication strategies are dynamically adjusted to improve the security of the system.
It realizes the improvement of the safety of the on-board safety system while controlling hardware costs, reduces potential security risks, and improves the stability and fault tolerance of the system.
Smart Images

Figure CN120066674A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of vehicle safety technologies, and particularly relates to a vehicle-mounted application system, an implementation method, a storage medium, and a vehicle-mounted device. Background Art
[0002] Safety is the primary consideration in the design and development process of an autonomous driving system. While achieving a high level of safety, it is also necessary to consider the control of hardware costs to ensure the popularity and sustainability of the vehicle-mounted system.
[0003] However, in existing solutions, when achieving high safety performance, the redundancy of hardware is also relatively high, which in turn leads to a relatively high overall cost of the system; for systems without hardware redundancy and with lower costs, the achievable safety level is not high. It can be seen that the current vehicle safety technologies cannot well balance between safety and hardware costs. Summary of the Invention
[0004] To solve the above technical problems, this application provides a vehicle-mounted application system, an implementation method, a storage medium, and a vehicle-mounted device.
[0005] Specifically, this application provides a vehicle-mounted application system. The vehicle-mounted application includes multiple functional modules, and each functional module runs independently in a container; wherein, the vehicle-mounted application system at least includes:
[0006] A container monitoring and management module, configured to analyze the connection relationships between the various functional modules, as well as the deployment relationships of the containers in the current vehicle-mounted device, so as to obtain the communication topology information between the containers according to the connection relationships and the deployment relationships.
[0007] A container communication module, configured to receive container communication data, and query the corresponding communication topology information based on the container communication data, so as to transmit the container communication data to the corresponding container according to the queried communication topology information and the current load balancing policy.
[0008] In the above technical solution, by containerizing the workload (i.e., the functional module), enabling the function to be deployed on different systems, the decoupling of software and hardware is achieved, and to a certain extent, the overall cost of the system is reduced; the containerization technology reduces potential security risks by isolating the operating environments of different functional modules. A security vulnerability in one functional module is not easily transmitted to other modules or the entire system, and through the real-time analysis of the container monitoring and management module and the query of the communication topology information, the system can dynamically adjust the communication strategy, further improving the security of the system.
[0009] Further, the vehicle-mounted application system further includes a container runtime module; the container runtime module is used to provide a running environment for running each container, at least including creating a container process corresponding to the container and allocating system resources.
[0010] In the above technical solution, the container runtime module can dynamically allocate system resources (such as CPU, memory, storage, etc.) according to the actual needs of each container, avoiding resource waste, and the resource allocation of each container is independent. The high resource occupancy of one container will not affect the operation of other containers, thus improving the stability and reliability of the system; the container runtime module is responsible for creating and managing container processes, simplifying the management of the container lifecycle.
[0011] Further, the container monitoring and management module is further used to deploy the obtained communication topology information to the container communication module.
[0012] In the above technical solution, the container monitoring and management module obtains communication topology information by analyzing the connection relationship between functional modules and the deployment relationship of containers, and deploys it to the container communication module, which enables the container communication module to dynamically adjust the communication path according to the latest topology information, ensuring the efficiency and reliability of data transmission.
[0013] Further, a Watchdog API is configured in each container; the container monitoring and management module is further used to receive the heartbeat signal sent by the Watchdog API to monitor the running state of the container based on the heartbeat signal.
[0014] In the above technical solution, the heartbeat signal is a health indicator of the running state of the container. By regularly receiving these heartbeat signals, the container monitoring and management module can understand the running situation of each container in real time, ensuring that the system is in the best state; if a certain container fails to send a heartbeat signal on time, the container monitoring and management module can immediately detect the abnormality and quickly take countermeasures.
[0015] Further, the container monitoring and management module is further used to monitor the execution status of the container process and system resources to monitor the running state of the container based on the execution status.
[0016] In the above technical solution, in addition to the heartbeat signal, the container monitoring and management module can also directly monitor the container process and system resources to deeply understand the running environment and resource usage of the container, and then capture signs of faults.
[0017] Further, the container monitoring and management module is further used to, when monitoring that the running state of any container is an abnormal state, adjust the corresponding communication topology information based on the abnormal state.
[0018] In the above technical solution, when the container monitoring and management module detects that a certain container is in an abnormal state, it can immediately isolate the container to prevent the abnormality from spreading to other containers and reduce the impact on the overall stability of the system; by adjusting the communication topology information, the container monitoring and management module can reconfigure the communication path to ensure that even if a key container fails, the system can still continue to operate normally through the remaining communication paths, improving the fault tolerance of the system.
[0019] Furthermore, the container monitoring and management module is also used to operate on the containers; the operations at least include creating corresponding containers based on the functional modules, and starting or stopping the corresponding containers based on the operation instructions issued by the vehicle-mounted applications.
[0020] In the above technical solution, the container monitoring and management module can dynamically create corresponding containers according to the requirements of the functional modules to ensure that each functional module has a dedicated and independent operating environment, avoiding resource conflicts and interference; according to the operation instructions of the vehicle-mounted applications, the container monitoring and management module can dynamically start or stop the containers to ensure the efficient use of system resources and avoid unnecessary resource waste.
[0021] Based on the same concept, the present application also provides a method for implementing a vehicle-mounted application system. The implementation method is applied to the vehicle-mounted application system and includes the following steps:
[0022] Analyze the connection relationships between the various functional modules and the deployment relationships of the containers in the current vehicle-mounted device through the container monitoring and management module, so as to obtain the communication topology information between the containers according to the connection relationships and the deployment relationships. (S1)
[0023] Receive container communication data through the container communication module and query the corresponding communication topology information based on the container communication data. (S2)
[0024] And transmit the container communication data to the corresponding container through the container communication module according to the queried communication topology information and the current load balancing strategy. (S3)
[0025] In the above technical solution, by analyzing the connection relationships between the functional modules and the container deployment relationships, the system can dynamically generate and update the communication topology information to ensure the real-time performance and flexibility of the communication path. Even if changes in container deployment (such as adding or removing containers) occur during the operation of the vehicle-mounted device, the communication topology can quickly adapt to maintain the communication efficiency of the system; the container communication module can query the corresponding communication topology information according to the received container communication data to ensure that the data can be accurately transmitted to the target container. This accurate data distribution mechanism avoids data loss or incorrect transmission and enhances the stability of the system.
[0026] In addition, containerizing functional modules can reduce the overall cost of the system and, by isolating the operating environments of different functional modules, reduce potential security risks.
[0027] Based on the same concept, the present application also provides a storage medium storing a computer program, wherein the computer program is configured to execute the implementation method of the in-vehicle application system when running.
[0028] Based on the same concept, the present application also provides an in-vehicle device, which is at least deployed with an in-vehicle application system to achieve secure data transmission between in-vehicle applications through the implementation method of the in-vehicle application system.
[0029] Compared with the prior art, the beneficial effects of the present application are as follows:
[0030] The in-vehicle application system of the present application at least includes a container monitoring and management module and a container communication module; the container monitoring and management module is used to analyze the connection relationships between various functional modules and the deployment relationships of each container in the current in-vehicle device, so as to obtain the communication topology information between each container according to the connection relationships and the deployment relationships; the container communication module is used to receive container communication data and query the corresponding communication topology information based on the container communication data, so as to transmit the container communication data to the corresponding container according to the queried communication topology information and the current load balancing strategy. By containerizing functional modules, the present application realizes the decoupling of software and hardware, reduces the overall system cost; containerization technology reduces potential security risks by isolating the operating environments of different functional modules, and this system can dynamically adjust communication strategies to further improve the security of the system. BRIEF DESCRIPTION OF THE DRAWINGS
[0031] Figure 1 It is a framework diagram of the in-vehicle application system described in the present application.
[0032] Figure 2 It is a schematic diagram of communication topology information in a normal operation scenario described in the present application.
[0033] Figure 3 It is a load balancing diagram at time t1 in a normal operation scenario described in the present application.
[0034] Figure 4 It is a load balancing diagram at time t2 in a normal operation scenario described in the present application.
[0035] Figure 5 It is a schematic diagram of adjusted communication topology information in an abnormal state described in the present application.
[0036] Figure 6 It is a load balancing diagram at time t1 in an abnormal state described in the present application.
[0037] Figure 7 This is the load balancing diagram at time t2 under abnormal conditions described in this application.
[0038] Figure 8 This is the flowchart of the implementation method of the vehicle-mounted application system described in this application. Detailed implementation manners
[0039] The following further describes in detail a vehicle-mounted application system, an implementation method, a storage medium, and a vehicle-mounted device of this application in combination with specific embodiments and the accompanying drawings.
[0040] Please refer to Figure 1 , this application provides a vehicle-mounted application system. The vehicle-mounted application includes multiple functional modules, and each functional module runs independently in a container; wherein, the vehicle-mounted application system at least includes:
[0041] A container monitoring and management module, which is used to analyze the connection relationships between various functional modules and the deployment relationships of each container in the current vehicle-mounted device, so as to obtain the communication topology information between the containers according to the connection relationships and the deployment relationships.
[0042] A container communication module, which is used to receive container communication data, query the corresponding communication topology information based on the container communication data, and transmit the container communication data to the corresponding container according to the obtained communication topology information and the current load balancing strategy.
[0043] In some embodiments, the vehicle-mounted application system is deployed in multiple vehicle-mounted devices, such as intelligent driving hardware and intelligent cockpit hardware; taking the intelligent driving hardware as an example, assume that the applications thereon are provided with functional module 1 (such as an environment perception module, and its corresponding container communication data such as the environmental data around the vehicle), and functional module 2 (such as a path planning and decision-making module); it is determined whether redundant configuration is required according to the input-output relationship of the functional modules (that is, the connection relationship), for example, functional module 2 is deployed in the intelligent cockpit hardware at the same time. Among them, each functional module in each hardware corresponds to a container. For example, functional module 1 and functional module 2 in the intelligent driving hardware correspond to container 1 and container 2 respectively, and functional module 2 of the intelligent cockpit hardware corresponds to container 3.
[0044] In addition, it should be noted that whether redundant configuration is required for the functional modules is determined based on the functional safety requirements of the modules. And the number of the functional modules can be set and adjusted by those skilled in the art according to actual application requirements, and is not limited thereto.
[0045] Furthermore, according to the input-output relationship of the above functional modules and the deployment relationships of each container, the communication topology information as Figure 2 shown is obtained.
[0046] Furthermore, the load balancing strategies such as equal distribution, distribution according to a certain ratio, dynamic ratio distribution, etc. Those skilled in the art can select and set the strategy according to actual application requirements. Assume that in a normal operation scenario, Function Module 2 runs normally on both hardwares; as Figure 3 shown, at time t1, the container communication module sends the container communication data output by Function Module 1 to Function Module 2 running in Container 2 based on the current communication topology information; as Figure 4 shown, at time t2, the container communication module sends the container communication data output by Function Module 1 to Function Module 2 running in Container 3.
[0047] Furthermore, the vehicle-mounted application system further includes a container runtime module; the container runtime module is used to provide a running environment for each container, at least including creating a container process corresponding to the container and allocating system resources.
[0048] In some embodiments, when creating a container process for Function Module 1, an independent file system and process space are allocated, and container processes are respectively created for Function Module 2 in Container 2 and Container 3. And, according to the requirements of the function module, CPU, memory, storage, etc. are correspondingly allocated to ensure that each container obtains sufficient resource support and avoid resource competition.
[0049] In the above technical solution, the container runtime module can dynamically allocate system resources according to the actual needs of each container, avoid resource waste, and the resource allocation of each container is independent. The high resource occupancy of one container will not affect the operation of other containers, thus improving the stability and reliability of the system; the container runtime module is responsible for creating and managing container processes, simplifying the management of the container life cycle.
[0050] Furthermore, the container monitoring and management module is also used to deploy the obtained communication topology information to the container communication module.
[0051] In some embodiments, the container monitoring and management module deploys the communication topology information to the container communication module through an API interface, so that the container communication module transmits data based on the currently deployed communication topology information.
[0052] In the above technical solution, the container monitoring and management module obtains the communication topology information by analyzing the connection relationship between function modules and the deployment relationship of containers, and deploys it to the container communication module, which enables the container communication module to dynamically adjust the communication path according to the latest topology information, ensuring the efficiency and reliability of data transmission.
[0053] Further, a Watchdog API is configured in each container; the container monitoring and management module is further configured to receive the heartbeat signal sent by the Watchdog API to monitor the running status of the container based on the heartbeat signal.
[0054] In some embodiments, the Watchdog API is integrated into the startup script or application of the container, and the sending frequency of the heartbeat signal is set (for example, sent once every 10 seconds); wherein, the heartbeat signal may include the basic running status of the container (such as CPU, memory, network, etc.) so that the monitoring and management module can perform more detailed analysis.
[0055] Further, the container monitoring and management module starts a background service dedicated to receiving and processing the heartbeat signals from each container; the heartbeat signals can be received in a polling or event-driven manner and stored in memory or persistent storage; the container monitoring and management module is provided with a timeout mechanism. If the heartbeat signal of a certain container is not received within a predetermined time (such as 30 seconds), it is considered that the container has an exception.
[0056] In the above technical solution, the heartbeat signal is a health indicator of the running status of the container. By regularly receiving these heartbeat signals, the container monitoring and management module can understand the running situation of each container in real time to ensure that the system is in the best state; if a certain container fails to send the heartbeat signal on time, the container monitoring and management module can immediately detect the exception and quickly take countermeasures.
[0057] Further, the container monitoring and management module is further configured to monitor the execution status of the container process and system resources to monitor the running status of the container based on the execution status.
[0058] In other embodiments, in addition to the monitoring method of the heartbeat signal, it is also possible to periodically detect whether the container processes in Container 1, Container 2, and Container 3 exist, and collect their usage conditions such as CPU and memory; comprehensively analyze the process and / or resource monitoring data to confirm whether all containers are in a healthy running state.
[0059] For example, when the container monitoring and management module discovers that the container process of Container 2 suddenly stops, or the system CPU usage rate continuously exceeds 90%, it is determined at this time that Container 2 has a fault.
[0060] In the above technical solution, in addition to the heartbeat signal, the container monitoring and management module can also directly monitor the container process and system resources to deeply understand the running environment and resource usage conditions of the container, and then capture signs of faults.
[0061] Further, the container monitoring and management module is further configured to, when the running state of any container is detected to be an abnormal state, adjust the corresponding communication topology information based on the abnormal state.
[0062] In some embodiments, when it is detected that there is an abnormal container based on any one of the above two monitoring methods, it is necessary to adjust the communication topology information corresponding to the container in an abnormal state. Suppose the container monitoring and management module detects that container 2 in which function module 2 runs on the intelligent driving hardware is abnormal. At this time, it is necessary to notify the abnormal state to the container communication module, so that the container communication module adjusts the communication topology information. The adjusted communication topology information is as Figure 5 shown.
[0063] At this time, as Figure 6 and Figure 7 shown, at any time t1 and t2, the container communication module sends the container communication data of function module 1 to function module 2 running in container 3. In this case, the intelligent driving hardware realizes redundant safety by using the intelligent cockpit hardware.
[0064] In addition, it should be noted that the container communication module sends the container communication data to the corresponding container by calling the interface of its communication layer. For example, for the DDS communication layer, it filters out the containers that do not need to be sent by calling the DDS communication layer Filter interface.
[0065] In other embodiments, the MQTT communication layer can also be used. For example, container 1 is used as the publisher and sends data to the specified topic through MQTT. Container 2 and container 3 are used as subscribers and subscribe to the corresponding topics through MQTT. When subscribing, wildcard topics are used for filtering to only receive the data of interest. Among them, the container communication module manages the subscription and publication relationships of each container and dynamically adjusts the subscribed and published topics according to the communication topology information.
[0066] In the above technical solution, when the container monitoring and management module detects that a certain container is in an abnormal state, the container can be immediately isolated to prevent the abnormality from spreading to other containers and reduce the impact on the overall stability of the system. By adjusting the communication topology information, the container monitoring and management module can reconfigure the communication path to ensure that even if a certain key container fails, the system can still continue to run normally through the remaining communication paths, improving the fault tolerance of the system.
[0067] Further, the container monitoring and management module is further configured to operate on the container; the operation at least includes creating a corresponding container based on the function module, and starting or stopping the corresponding container based on the operation instruction issued by the vehicle-mounted application.
[0068] In some embodiments, for example, the container monitoring and management module obtains the requirements for creating a container from the functional module, including the container image, environment variables, network configuration, etc. Through interfaces such as Docker API or Kubernetes API, it calls the interface for creating a container. After the container is created, it verifies whether the container configuration meets the requirements and records the creation log.
[0069] Among them, Docker API and Kubernetes API provide powerful container management functions and are suitable for different application scenarios. Docker API is suitable for container management in a single-machine or small-cluster environment, while Kubernetes API is suitable for container orchestration and management in large-scale distributed clusters. Those skilled in the art can select them according to actual application requirements to flexibly manage the container lifecycle and meet the requirements of high reliability and real-time performance of the in-vehicle application system.
[0070] The container monitoring and management module receives the start instruction issued by the in-vehicle application, obtains the ID or name of the container to be started, and through Docker API or Kubernetes API, calls the interface for starting the container; during the container startup process, it monitors the startup status of the container to ensure that the container is successfully started and records the startup log.
[0071] The container monitoring and management module receives the stop instruction issued by the in-vehicle application, obtains the ID or name of the container to be stopped, and through Docker API or Kubernetes API, calls the interface for stopping the container; during the container stop process, it monitors the stop status of the container to ensure that the container is successfully stopped and records the stop log.
[0072] In the above technical solution, the container monitoring and management module can dynamically create corresponding containers according to the requirements of the functional module, ensuring that each functional module has a dedicated and independent running environment, avoiding resource conflicts and interference; according to the running instructions of the in-vehicle application, the container monitoring and management module can dynamically start or stop the container, ensuring the efficient use of system resources and avoiding unnecessary resource waste.
[0073] Based on the same concept, please refer to Figure 8 , this application also provides an implementation method for an in-vehicle application system. The implementation method is applied to the in-vehicle application system and includes the following steps:
[0074] S1: Analyze the connection relationship between each functional module and the deployment relationship of each container in the current in-vehicle device through the container monitoring and management module, so as to obtain the communication topology information between each container according to the connection relationship and the deployment relationship.
[0075] In some embodiments, taking in-vehicle devices including intelligent driving hardware and intelligent cockpit hardware as an example, on the intelligent driving hardware, function module 1 and function module 2 are set for the applications thereon. Based on functional safety requirements, function module 2 is redundantly set on the intelligent cockpit hardware; each function module in the hardware corresponds to a container. For example, function module 1 and function module 2 in the intelligent driving hardware respectively correspond to container 1 and container 2, and function module 2 of the intelligent cockpit hardware corresponds to container 3.
[0076] Among them, the corresponding communication topology information can be obtained according to the connection relationship of the above function modules and the deployment relationship of each container.
[0077] S2: Receive container communication data through the container communication module, and query the corresponding communication topology information based on the container communication data.
[0078] In some embodiments, the container monitoring and management module deploys the communication topology information into the container communication module, and the communication topology information can be adjusted in real time according to the abnormal state. Therefore, the topology information in the container communication module is dynamic.
[0079] Among them, the container communication module receives the container communication data sent by the container from the communication layer, and then queries the communication topology information stored in the current container communication module.
[0080] Assume that the function module corresponding to the current container is the environmental perception module, and the container communication data is, for example, the environmental data around the vehicle collected from in-vehicle sensors (such as cameras, radars, lidars, etc.).
[0081] S3: Transmit the container communication data to the corresponding container through the container communication module according to the communication topology information obtained by query and the current load balancing strategy.
[0082] In some embodiments, the container communication module determines which container to send the container communication data to based on the communication topology information obtained by query and in cooperation with the current load balancing strategy; among them, call the interface of the communication layer to send the data to the corresponding container.
[0083] In the above technical solution, by analyzing the connection relationship between function modules and the container deployment relationship, the system can dynamically generate and update the communication topology information to ensure the real-time performance and flexibility of the communication path. Even when container deployment changes (such as adding or removing containers) occur during the operation of the in-vehicle device, the communication topology can quickly adapt to maintain the communication efficiency of the system; the container communication module can query the corresponding communication topology information according to the received container communication data to ensure that the data can be accurately transmitted to the target container. This accurate data distribution mechanism avoids data loss or incorrect transmission and enhances the stability of the system.
[0084] In addition, containerizing functional modules can reduce the overall cost of the system and, by isolating the operating environments of different functional modules, reduce potential security risks.
[0085] Based on the same concept, the present application also provides a storage medium storing a computer program, wherein the computer program is configured to execute the implementation method of the in-vehicle application system when running.
[0086] In some embodiments, the storage medium stores a number of computer programs for causing an in-vehicle device to execute all or part of the steps of the methods described in various embodiments of the present application.
[0087] The medium may include various media capable of storing program codes, such as a USB flash drive, a portable hard disk, a read-only memory, a random access memory, a magnetic disk, or an optical disc.
[0088] Based on the same concept, the present application also provides an in-vehicle device at least deployed with an in-vehicle application system to achieve secure data transmission between in-vehicle applications through the implementation method of the in-vehicle application system.
[0089] In summary, the present application provides an in-vehicle application system, an implementation method, a storage medium, and an in-vehicle device; the in-vehicle application system at least includes a container monitoring and management module and a container communication module; the container monitoring and management module is used to analyze the connection relationships between various functional modules and the deployment relationships of each container in the current in-vehicle device, so as to obtain the communication topology information between the containers according to the connection relationships and the deployment relationships; the container communication module is used to receive container communication data and query the corresponding communication topology information based on the container communication data, so as to transmit the container communication data to the corresponding container according to the queried communication topology information and the current load balancing policy. The present application realizes the decoupling of software and hardware by containerizing functional modules, reduces the overall system cost; the containerization technology reduces potential security risks by isolating the operating environments of different functional modules, and this system can dynamically adjust communication policies to further improve the security of the system.
[0090] Although example embodiments have been described herein with reference to the accompanying drawings, it should be understood that the above example embodiments are merely exemplary and are not intended to limit the scope of the present application thereto. Those of ordinary skill in the art can make various changes and modifications therein without departing from the scope and spirit of the present application. All such changes and modifications are intended to be included within the scope of the present application as claimed by the appended claims.
[0091] Those of ordinary skill in the art can realize that the units and algorithm steps of the examples described in combination with the embodiments disclosed herein can be implemented by electronic hardware, or by a combination of computer software and electronic hardware. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Professional technicians can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of this application.
[0092] In several embodiments provided by this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed.
[0093] Each component embodiment of this application can be implemented in hardware, or in software modules running on one or more processors, or in a combination thereof. Those skilled in the art should understand that a microprocessor or a digital signal processor (DSP) can be used in practice to implement some or all of the functions of some modules according to the embodiments of this application. This application can also be implemented as a device program (such as a computer program and a computer program product) for executing part or all of the methods described herein. Such a program for implementing this application can be stored on a computer-readable medium, or can be in the form of one or more signals. Such signals can be downloaded from an Internet website, or provided on a carrier signal, or provided in any other form.
[0094] It should be noted that in this text, relational terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the term "comprising", "including" or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements not only includes those elements, but also includes other elements not expressly listed, or also includes elements inherent to such process, method, article or device. Without further limitation, an element defined by the statement "including one..." does not exclude the existence of additional identical elements in the process, method, article or device including the said element.
[0095] Although the description of the present application is made in connection with the above specific embodiments, it will be apparent to those skilled in the art that many substitutions, modifications, and variations can be made in light of the above disclosure. Accordingly, all such alternatives, improvements, and variations are intended to be included within the spirit and scope of the appended claims.
Claims
1. A vehicle-mounted application system, characterized in that: The vehicle-mounted application includes multiple functional modules, each of which runs independently in a container; wherein the vehicle-mounted application system includes at least: A container monitoring and management module, used to analyze the connection relationship between various functional modules and the deployment relationship of various containers in the current vehicle-mounted device, so as to obtain the communication topology information between various containers according to the connection relationship and the deployment relationship; The container communication module is used to receive container communication data and query corresponding communication topology information based on the container communication data, so as to transmit the container communication data to the corresponding container according to the communication topology information obtained by the query and the current load balancing strategy.
2. The vehicle-mounted application system according to claim 1, characterized in that: The vehicle-mounted application system also includes a container runtime module; The container runtime module is used to provide an operating environment for running each container, including at least creating a container process corresponding to the container and allocating system resources.
3. The vehicle-mounted application system according to claim 1, characterized in that: The container monitoring and management module is further used to deploy the acquired communication topology information to the container communication module.
4. The vehicle-mounted application system according to claim 1, characterized in that: Each container is configured with a Watchdog API; the container monitoring management module is also used to receive a heartbeat signal sent by the Watchdog API to monitor the running status of the container based on the heartbeat signal.
5. The vehicle-mounted application system according to claim 2, characterized in that: The container monitoring management module is further used to monitor the execution status of the container process and system resources, so as to monitor the running status of the container based on the execution status.
6. The vehicle-mounted application system according to any one of claims 4 or 5, characterized in that: The container monitoring and management module is further configured to adjust corresponding communication topology information based on the abnormal state when the running state of any container is monitored to be an abnormal state.
7. The vehicle-mounted application system according to claim 1, characterized in that: The container monitoring and management module is also used to operate the container; The operation at least includes creating a corresponding container based on the functional module, and starting or stopping the corresponding container based on a running instruction issued by the in-vehicle application.
8. A method for implementing a vehicle-mounted application system, characterized in that: The implementation method is applied to the vehicle-mounted application system as claimed in claim 1, comprising the following steps: Analyzing the connection relationship between each functional module and the deployment relationship of each container in the current vehicle-mounted device through the container monitoring management module, so as to obtain the communication topology information between each container according to the connection relationship and the deployment relationship; (S1) receiving container communication data through the container communication module, and querying the corresponding communication topology information based on the container communication data; (S2) And, the container communication module transmits the container communication data to the corresponding container according to the communication topology information obtained by the query and the current load balancing strategy. (S3).
9. A storage medium, characterized in that: The storage medium stores a computer program, wherein the computer program is configured to execute the implementation method of the vehicle-mounted application system as claimed in claim 8 when running.
10. A vehicle-mounted device, characterized in that: The vehicle-mounted device is at least deployed with a vehicle-mounted application system to realize secure data transmission between vehicle-mounted applications through the implementation method of the vehicle-mounted application system as claimed in claim 8.
Citation Information
Cited By
In-vehicle application system, and implementation method
WO2026144054A1