Vehicle-mounted application development data communication system and vehicle

Abstract

The invention relates to a vehicle-mounted application development data communication system and a vehicle, the system comprises a first application module, a second application module and a communication bus module, the first application module is used for deploying a vehicle-mounted cabin ecological application; the second application module is used for deploying a vehicle-mounted system-level application; the communication bus module is used for establishing communication connection between the upper ecological applications and between the upper ecological applications and the system application; the communication bus module comprises a service interconnection management unit used for executing registration, discovery and calling of application services; the computing unit is used for caching, packaging and transmitting processing data; the decision-making unit is used for carrying out service arbitration and response decision-making based on the application self-defined strategy and a preset system security strategy; and the security management unit is used for executing access control and security protection. Therefore, the problems of high development cost, strong system coupling and poor expansibility of communication among different applications in the current vehicle-mounted intelligent cabin are solved, efficient, safe and low-coupling data intercommunication among the vehicle-mounted applications is realized, and the expandability and safety of the system are improved.

Description

Technical Field

[0001] This application relates to the field of automotive software development technology, and in particular to an in-vehicle application development data communication system and vehicle. Background Technology

[0002] With the rapid development of the in-vehicle intelligent cockpit software ecosystem, diverse applications from different vendors, such as navigation, voice, and multimedia, are integrated into the cockpit. These applications have close data exchange and business collaboration needs. Currently, different applications typically communicate through point-to-point customized interfaces, resulting in high system coupling, high development costs, difficulties in upgrading and expanding, and a lack of a unified security control mechanism, leading to security risks such as weak identity authentication, chaotic permissions, and inconsistent protection standards.

[0003] In related technologies, such as the modular architecture based on Android, the focus is mainly on software and hardware isolation and interface standardization, but there is insufficient coverage of complex business data communication models between upper-layer applications, service governance, and multi-layer security protection. This makes it difficult to meet the requirements of intelligent cockpits for high security, high reliability, and high scalability communication buses, which urgently needs to be addressed. Summary of the Invention

[0004] This application provides a vehicle-mounted application development data communication system and vehicle to solve the problems of high development cost, strong system coupling, and poor scalability in communication between different applications in current vehicle-mounted smart cockpits. It realizes efficient, secure, and loosely coupled data interoperability between vehicle-mounted applications, and improves the scalability and security of the system.

[0005] The first aspect of this application provides a data communication system for developing vehicle applications, including:

[0006] The first application module is configured to deploy in-vehicle cockpit ecosystem applications, and the first application module includes at least one upper-layer ecosystem application. The second application module is configured to deploy in-vehicle system-level applications, and the second application module includes at least one system application. A communication bus module is connected between the first application module and the second application module. The communication bus module is configured to establish a communication connection between the upper-layer ecosystem applications and to establish a communication connection between the upper-layer ecosystem applications and the system application. The communication bus module includes: The Service Interconnection Management Unit is configured to perform application service registration, discovery, and invocation. The computing unit is configured to process data caching, encapsulation, and transmission; The decision-making unit is configured to make service arbitration and response decisions based on application-defined policies and preset system security policies. The security management unit is configured to perform access control and security protection.

[0007] Optionally, in some embodiments, the communication bus module interacts with the first application module and the second application module through a target unified SDK (Software Development Kit), which provides standardized interfaces for providing service connection, registration, query, invocation, and unregistration.

[0008] Optionally, in some embodiments, the service interconnection management unit is configured to: During service startup, the whitelist and permission policies in the system configuration file are loaded. Respond to the registration request from the application service provider and receive predefined service interface information, access whitelist, data security level, service priority and maximum concurrent capacity; Establish a service index based on process identifier, function type, and service tag, and manage service access nodes through a doubly linked list or queue structure.

[0009] Optionally, in some embodiments, the computing unit is configured to perform secondary packaging and compression processing on the transmitted data, cache the access data that meets the preset access frequency, and perform storage operations on the data that meets the preset persistent storage conditions.

[0010] Optionally, in some embodiments, the decision-making unit is configured to prioritize service call requests based on the application's custom access policy and the system-level preset security policy, and dynamically adjust the response order and resource allocation.

[0011] Optionally, in some embodiments, the security management unit supports discretionary access control and mandatory access control. The discretionary access control allows the application of custom access whitelists, priorities, security levels, and concurrency policies, while the mandatory access control forces the configuration of access whitelists, data permissions, and maximum secure concurrency at the system layer.

[0012] Optionally, in some embodiments, the communication bus module uses a layered data model for message passing, the data model including a basic type layer, a data message header layer, a service contract layer, a domain model layer, and a transmission format layer.

[0013] Optionally, in some embodiments, the upper-layer ecosystem applications of the first application module include at least one of map navigation applications, multimedia applications, voice assistant applications, and weather applications; The upper-layer ecosystem applications are configured to provide data services and functional interfaces, and there are data dependencies between the upper-layer ecosystem applications. The data dependencies include the map navigation application providing location data to the voice assistant application and the voice assistant application issuing control commands to the multimedia application.

[0014] Optionally, in some embodiments, the system applications of the second application module include at least one of a system desktop application, a vehicle settings application, an air conditioning service application, a vehicle configuration service application, and a sensor service application; The system application is configured to provide vehicle status data to the upper-layer ecosystem application. The vehicle status data includes at least one of the following: battery level data, fuel level data, vehicle location data, and air conditioning operation data. The system application can also receive control commands issued by the upper-layer ecosystem application.

[0015] According to the vehicle application development data communication system provided in the embodiments of this application, a first application module is used to deploy vehicle cockpit ecosystem applications; a second application module is used to deploy vehicle system-level applications; a communication bus module is used to establish communication connections between upper-layer ecosystem applications and between upper-layer ecosystem applications and system applications; the communication bus module includes: a service interconnection management unit, used to perform application service registration, discovery, and invocation; a computing unit, used to process data caching, encapsulation, and transmission; a decision-making unit, used to perform service arbitration and response decisions based on application-defined policies and preset system security policies; and a security management unit, used to perform access control and security protection. This solves the problems of high development costs, strong system coupling, and poor scalability in communication between different applications in current vehicle intelligent cockpits, achieving efficient, secure, and loosely coupled data interoperability between vehicle applications, and improving the system's scalability and security.

[0016] This application also provides a vehicle that includes the in-vehicle application development data communication system described above.

[0017] According to the vehicle embodiment of this application, the above-mentioned vehicle application development data communication system solves the problems of high development cost, strong system coupling, and poor scalability in the communication between different applications in the current vehicle intelligent cockpit, and realizes efficient, safe, and loosely coupled data interoperability between vehicle applications, thereby improving the scalability and security of the system.

[0018] 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

[0019] 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: Figure 1 This is a block diagram of a data communication system for developing vehicle applications according to an embodiment of this application; Figure 2 This is a schematic diagram of a data communication system framework for developing in-vehicle applications based on a service bus, according to an embodiment of this application. Figure 3 This is a schematic diagram of the hierarchical structure of a data communication system for developing vehicle applications according to an embodiment of this application; Figure 4 This is a schematic diagram of the service bus call process of a data communication system for developing vehicle applications according to an embodiment of this application; Figure 5 A schematic diagram of a three-layer security protection system for a data communication system for vehicle applications according to an embodiment of this application; Figure 6 This is a schematic diagram of a data model for an in-vehicle application development data communication system according to an embodiment of this application. Detailed Implementation

[0020] 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.

[0021] Those skilled in the art will understand that the rapid development of in-vehicle intelligent cockpits faces the challenge of diversified, complex, and intelligent development requirements for ecosystem application software. The in-vehicle intelligent cockpit software industry has certain unique characteristics; most software requires collaboration to meet the diverse and intelligent needs of the cockpit ecosystem experience. Furthermore, many automakers have diverse software vendors, and the data and service capabilities of different vendors are not interoperable or shared. There are automaker-developed ecosystem applications, applications from specific vendor ecosystems, and applications from app stores. Therefore, data interoperability between different application software often relies on customized service interfaces for one-to-one cross-process access and sharing via SDKs, or on leveraging mature shared data or files to achieve access and sharing.

[0022] The existing data and service communication solutions between various vendors' application software still have many shortcomings, mainly in the following three aspects: (1) High development costs: Data communication between application software in each project needs to be achieved through one-to-one SDK adaptation interface, and some interfaces need to be redesigned and developed, resulting in extended development cycle and increased costs.

[0023] (2) Poor scalability: The high degree of coupling between application software data communication not only affects the overall replacement of supplier software, but also makes it difficult for new functional modules to be synchronized and upgraded and maintained in a timely manner among relevant parties.

[0024] (3) Poor security: Communication between different application software often lacks a unified and standardized identity verification, permission management, encrypted transmission and attack protection mechanism; even if there are some protection measures, they are mostly implemented independently with different standards, which can easily lead to unpredictable security risks.

[0025] To address the aforementioned issues, several technologies have been developed to improve the solutions. For example, the published CN119440478A, "An Android-based Vehicle Application Software Architecture System, Device, Vehicle Development Method and Medium," proposes a modular and reusable middleware design based on the Android platform, achieving isolation between the business layer and the hardware layer and forming standardized interfaces. However, this method focuses on modularity and reusability between software and hardware, with less attention paid to business data communication and security protection mechanisms between different application software. Furthermore, the modularity and reusability design involved in this method is not yet technically refined enough, especially in terms of the middleware architecture, which requires further refinement and improvement.

[0026] In summary, the existing technologies have not paid enough attention to the design and implementation of business data communication models and corresponding security protection mechanisms between different application software. Although the relevant technologies involve modular and reusable design, they are not refined enough at the technical level, especially in terms of the inter-component architecture, which lacks a systematic and refined framework design. This invention designs a framework system for data communication in vehicle application development based on a service bus. By standardizing service interface design, making services pluggable, and having a multi-layered security protection design concept, it can effectively reduce the workload of developing data communication interfaces between different application software, quickly expand new applications and new business interfaces, and effectively reduce the security risks of data communication between different application software.

[0027] The following description, with reference to the accompanying drawings, describes an in-vehicle application development data communication system and vehicle according to embodiments of this application.

[0028] Specifically, Figure 1 This is a block diagram illustrating a vehicle-mounted application development data communication system provided in an embodiment of this application.

[0029] like Figure 1 As shown, the vehicle-mounted application development data communication system includes: a first application module, a second application module, and a communication bus module.

[0030] The first application module is configured to deploy in-vehicle cockpit ecosystem applications, and the first application module includes at least one upper-layer ecosystem application; the second application module is configured to deploy in-vehicle system-level applications, and the second application module includes at least one system application; a communication bus module is connected between the first application module and the second application module, and the communication bus module is configured to establish communication connections between upper-layer ecosystem applications and between upper-layer ecosystem applications and system applications. The communication bus module includes: a service interconnection management unit, configured to perform application service registration, discovery, and invocation; a computing unit, configured to process data caching, encapsulation, and transmission; a decision-making unit, configured to perform service arbitration and response decisions based on application-defined policies and preset system security policies; and a security management unit, configured to perform access control and security protection.

[0031] Optionally, in some embodiments, the upper-layer ecosystem applications of the first application module include at least one of a map navigation application, a multimedia application, a voice assistant application, and a weather application; the upper-layer ecosystem applications are configured to provide data services and functional interfaces, and there are data dependencies between the upper-layer ecosystem applications, including the map navigation application providing location data to the voice assistant application and the voice assistant application issuing control commands to the multimedia application.

[0032] Optionally, in some embodiments, the system applications of the second application module include at least one of a system desktop application, a vehicle settings application, an air conditioning service application, a vehicle configuration service application, and a sensor service application; the system applications are configured to provide vehicle status data to upper-layer ecosystem applications, the vehicle status data including at least one of battery data, fuel data, vehicle location data, and air conditioning operation data, and the system applications can receive control commands issued by upper-layer ecosystem applications.

[0033] Specifically, the first application module in this application embodiment is mainly responsible for the deployment and operation of the in-vehicle cockpit ecosystem application, which includes at least one upper-layer ecosystem application. The upper-layer ecosystem application provides specific service functions to users, such as map navigation, multimedia playback, voice assistant, and weather information. Complex data and service dependencies exist between these applications. For example, the map navigation application needs to provide real-time location data to the voice assistant to support voice interaction, while the voice assistant may issue play / pause control commands to the multimedia application.

[0034] The second application module is specifically designed for deploying in-vehicle system-level applications, which include at least one system application. These applications are usually closely related to the vehicle's underlying hardware or system services, such as the system desktop, vehicle settings, air conditioning control, vehicle configuration, and various sensor services. They are responsible for providing vehicle status data (such as battery level, fuel level, location information, air conditioning operating parameters, etc.) and can receive control commands from upper-level ecosystem applications, such as automatically adjusting the air conditioning mode based on the navigation status.

[0035] As the core hub of the system, the communication bus module connects the first application module and the second application module. Its main function is to establish and manage communication connections between various applications. The communication bus module not only enables data and service interoperability between upper-layer ecosystem applications, but also builds communication links between upper-layer ecosystem applications and system applications, thereby breaking down information silos between applications and supporting cross-level and cross-vendor collaborative work.

[0036] To achieve the above communication management, the communication bus module further includes the following four functional units: Service Interconnection Management Unit: Responsible for the full lifecycle management of application services, including service registration, discovery, and invocation. For example, when a voice assistant application needs to invoke a navigation and location service, this unit can assist it in discovering the registered location service interface and completing the invocation.

[0037] Computing Unit: Dedicated to data processing tasks, including secondary encapsulation and compression of transmitted data to optimize communication efficiency, caching of frequently accessed data to improve response speed, and performing storage operations on business data that needs to be persisted.

[0038] Decision-making unit: Based on the application's custom access policies (such as service priority, concurrency limits, etc.) and the system-level preset security policies, it arbitrates and schedules concurrent service requests, dynamically adjusts resource allocation and response order, and ensures the stability and fairness of the system in complex scenarios.

[0039] Security Management Unit: The core safeguard for system security, responsible for enforcing access control and comprehensive security protection. It supports both discretionary access control mechanisms (allowing applications to customize access policies) and mandatory access control mechanisms (enforced uniformly by the system), such as whitelist verification, communication token verification, data encryption, and anti-attack strategies, to ensure the security and reliability of the communication process.

[0040] Therefore, through the collaborative work of the communication bus module and its various functional units, this system has built a communication system between in-vehicle applications that supports service-oriented architecture, is secure and controllable, and is scalable, effectively improving the integration efficiency of the in-vehicle software ecosystem and the system security.

[0041] For example, the service bus-based in-vehicle application development data communication system framework proposed in this application includes: The upper application layer mainly includes upper-layer applications of the in-vehicle cockpit ecosystem, such as multimedia, voice, and maps, as well as the data or service interfaces provided by the applications.

[0042] The application communication bus layer includes the Service Manager, the Data and Computing Center, the Decision Control Center, and the Security Management Center.

[0043] The system application layer mainly includes system desktop applications, vehicle settings applications, air conditioning services, and vehicle configuration services.

[0044] In the above scheme, the uploaded application involves data access between different applications. For example, map navigation relies on voice interaction commands, system vehicle status data, location data, and data such as battery and fuel levels; multimedia relies on voice interaction commands, and the voice assistant relies on navigation status, multimedia playback status, real-time navigation and positioning data, and system vehicle data, and also issues various application control commands. Lower-level system applications also rely on upper-level navigation and positioning, voice commands, multimedia playback control, and other data and interfaces.

[0045] The following describes the detailed design of the application communication bus layer. The service interconnection management center of the application communication bus layer primarily handles the connection and destruction of various application services, as well as the registration, deregistration, lookup, management, and invocation of data or interface services. The data and computing center of the application communication bus layer is used for secondary data processing, caching, and transmission. The decision control center of the application communication bus layer mainly implements service arbitration and response strategies, combining application-defined strategies and system-level security policies for comprehensive decision-making. The security management center of the application communication bus layer mainly implements custom authentication, custom whitelist and system whitelist verification, communication token verification, data encryption, load balancing, attack prevention, service denial, and keep-alive mechanisms.

[0046] Therefore, by constructing an application communication bus layer, data interconnection and interoperability between upper-layer applications, between upper-layer and system applications, and between application software from various vendors are achieved. This framework system enables the sharing of service capabilities, thereby effectively leveraging the collaborative effects between various applications to realize the ultimate intelligent and user-friendly experience of the in-vehicle cockpit. Based on this interconnection of data and service capabilities, customizable access policies, permission mechanisms, encryption / decryption mechanisms added to the transport layer, and load balancing and anti-attack strategies added to the system layer can effectively improve the efficiency of data and service access between application software, especially high concurrency capabilities. It also effectively solves the problems of high coupling and high development costs between application software, and enhances the security protection capabilities of data communication and service access.

[0047] Optionally, in some embodiments, the communication bus module interacts with the first application module and the second application module through the target unified SDK, which provides a standardized interface for providing service connection, registration, query, invocation and unregistration.

[0048] Specifically, the communication bus module establishes a standardized data interaction channel with the first and second application modules through a unified target SDK. This SDK encapsulates all the basic operation interfaces required for communication with the service bus, realizing the standardization and decoupling of behaviors such as application connection, service registration, query, invocation, and unregistration between the application and the bus.

[0049] The unified SDK provides a consistent access point and invocation method for all applications connected to the bus. For example, when a map navigation application (belonging to the first application module) needs to publish its location service to the bus, it can register the service on the bus by calling the service registration interface provided by the SDK and submitting the service description, access policy, and metadata according to a predefined data structure. Similarly, if a voice assistant application needs to use the location service, it does not need to establish a direct point-to-point connection with the map navigation application. Instead, it retrieves available services from the bus through the service query interface of the SDK, obtains the service handle, and then initiates a remote call through the service invocation interface to obtain real-time location data.

[0050] Furthermore, this SDK also includes management interfaces for service connection establishment and destruction, as well as unregistration. For example, when an application exits or a service goes offline, the service unregistration interface can be called to notify the bus to remove the corresponding service, ensuring the real-time nature and consistency of the service catalog. Through this unified interface abstraction, applications developed by different vendors do not need to be customized for each communication object; they only need to follow the same SDK interface specification to access the bus and achieve interoperability. This significantly reduces the complexity of system integration and maintenance, and also enhances the scalability and replaceability of the overall architecture.

[0051] Optionally, in some embodiments, the service interconnection management unit is configured to: load the whitelist and permission policies in the system configuration file during the service startup phase; respond to the registration request of the application service provider, receive predefined service interface information, access whitelist, data security level, service priority and maximum concurrent capacity; establish a service index based on process identifier, function type and service tag, and manage service access nodes through a doubly linked list or queue structure.

[0052] Specifically, during the service startup initialization phase, the service interconnection management unit first loads a pre-defined whitelist and permission policy from the system configuration file. This includes information such as the identifiers of application processes allowed to access the bus, the types of services that can be accessed, and the levels of access permissions, laying a security foundation for subsequent service access and control. When an application service provider (such as a navigation and positioning service) initiates a service registration request through a standardized interface, the service interconnection management unit receives and parses its predefined service description information. This includes: the unique identifier and calling specification of the service interface, a whitelist of applications allowed to access the service (e.g., limited to voice assistants and dashboard applications), data security level (e.g., distinguishing between public data and encrypted sensitive data), service priority (used for scheduling and prioritization in high-concurrency scenarios), and maximum concurrent capacity (e.g., a maximum of 100 requests per second). These parameters together constitute the metadata policy set published by the service on the bus.

[0053] To achieve efficient service discovery and invocation, the service interconnection management unit constructs a service index structure based on multi-dimensional features: distinguishing service sources by process identifiers, classifying and aggregating by function type (such as location services and media control), and further refining the labeling by service tags (such as real-time high-precision positioning and offline basic positioning). At the data structure level, service access nodes are organized using methods such as doubly linked lists or queues. For example, service nodes of the same function type are linked together in a list for easy traversal and querying; simultaneously, queues manage pending service requests, supporting sequential execution and priority scheduling. For instance, when a voice assistant requests vehicle location, this unit can quickly retrieve registered navigation application service nodes through the location service function type index and arrange request execution according to their concurrent queue status.

[0054] Optionally, in some embodiments, the computing unit is configured to perform secondary packaging and compression processing on the transmitted data, cache the access data that meets the preset access frequency, and perform storage operations on the data that meets the preset persistent storage conditions.

[0055] Specifically, the computing unit undertakes the core data processing and optimization responsibilities in the system. Its functions mainly cover three aspects: secondary packaging and compression of transmitted data, cache management of frequently accessed data, and storage execution of persistent data.

[0056] In terms of secondary packaging and compression of transmitted data, the computing unit is responsible for structured encapsulation and format conversion of the original business data to adapt to the unified communication protocol of the service bus. For example, when vehicle positioning data is transmitted from a navigation application to a voice assistant, the computing unit can encapsulate the original latitude, longitude, speed, direction, and other information into a standardized message packet containing a message header, payload data, and security context, and use compression algorithms such as GZIP or LZ4 to compress the message body to reduce network bandwidth consumption and improve transmission efficiency.

[0057] Regarding the caching management of frequently accessed data, the computing unit automatically identifies hot data based on a preset access frequency threshold (such as the number of requests per unit time) and stores it in a high-speed cache. For example, real-time vehicle battery information may be frequently queried by multiple applications such as multimedia, dashboard, and remote services. The computing unit can cache this data after the first acquisition, and subsequent requests will be directly responded to by the cache, significantly reducing repeated access to the underlying data source and improving the overall system response speed and concurrent processing capabilities.

[0058] Regarding the storage and execution of persistent data, the computing unit writes specific data to persistent storage media based on preset business rules and storage conditions (such as data importance, retention period, compliance requirements, etc.). For example, data such as vehicle fault diagnosis codes, key operation logs, or user travel trajectories, which have audit analysis, fault traceability, or compliance retention value, will be extracted by the computing unit from temporary caches or communication links, formatted, and stored in a database or file system to ensure the long-term traceability and reliability of the data.

[0059] Thus, through the three processing mechanisms mentioned above, the computing unit achieves systematic optimization of data transmission, access, and storage, improving communication efficiency and response performance while ensuring the integrity, availability, and security of data in the complex in-vehicle environment.

[0060] Optionally, in some embodiments, the decision-making unit is configured to prioritize service call requests based on application-defined access policies and system-level preset security policies, and dynamically adjust the response order and resource allocation.

[0061] Specifically, the decision-making unit, as the scheduling core of the communication bus system, primarily functions to intelligently arbitrate and dynamically allocate resources for concurrent service call requests based on multi-layered policy configurations. The decision-making unit comprehensively considers two types of policy inputs: one is application-defined access policies, i.e., access control rules (such as whitelists, priority weights, maximum concurrency, service level agreements, etc.) defined by each application when publishing services; the other is system-level preset security policies, i.e., global security rules and resource management policies uniformly enforced by the system (such as system-level whitelists, mandatory access permissions, security concurrency thresholds, critical service protection rules, etc.).

[0062] In actual operation, when multiple service requests are initiated simultaneously (e.g., a voice assistant requests navigation services, a multimedia application requests vehicle status data, and the system desktop requests weather updates), the decision-making unit will parse and prioritize the requests through a policy engine. Based on preset arbitration algorithms (such as priority-based weighted queues, service level assurance mechanisms, and system security awareness), it will determine the order of service responses and the allocation ratio of computing resources. For example, if the system-level policy stipulates that vehicle safety-related services (such as battery status queries) have the highest priority, the decision-making unit will prioritize scheduling and allocating resources to process the battery status query request, even if the multimedia playback control request arrives first. Simultaneously, if the frequency of requests initiated by a certain application (such as a third-party ecosystem application) exceeds its custom or system-defined concurrency limit, the decision-making unit will trigger a rate-limiting mechanism, dynamically delaying or rejecting the request, and recording abnormal behavior for security auditing.

[0063] Thus, through this policy-based dynamic arbitration and resource adaptive allocation mechanism, the decision-making unit can ensure the real-time response of high-priority services while achieving optimized utilization of system resources and stable and controllable overall service quality.

[0064] Optionally, in some embodiments, the security management unit supports discretionary access control and mandatory access control. Discretionary access control allows the application of custom access whitelists, priorities, security levels, and concurrency policies, while mandatory access control forces the configuration of access whitelists, data permissions, and maximum secure concurrency at the system level.

[0065] Specifically, the security management unit of this system integrates and supports two complementary access control mechanisms: discretionary access control and mandatory access control. Together, they form a hierarchical and configurable security policy system to address the complex security and access control needs in the vehicle environment.

[0066] Discretionary access control mechanisms grant applications the permission to customize their access control policies based on their own business logic and security considerations when publishing or providing data services. Specifically, applications can independently define the following policy parameters: (1) Access whitelist: Specifies the list of specific applications that are allowed to call this service or access specific data; (2) Service Priority: Set the response priority of this service according to the importance of the business; (3) Security level: Set the encryption strength and integrity verification level for service interfaces or data transmission; (4) Concurrency strategy: Limit the maximum number of accesses or concurrent connections allowed per unit time.

[0067] For example, when a navigation application publishes real-time location services to the bus, it can independently set it to allow only two applications, the voice assistant and the vehicle dashboard, to access the service, set the service priority to high, and limit the maximum number of accesses per second to 50, thereby achieving fine-grained self-protection while opening up functions.

[0068] Furthermore, mandatory access control mechanisms This is implemented uniformly at the system level, independent of specific application intentions, and enforces a global security policy on all data interactions via the communication bus. This mechanism typically includes: (1) System-level access whitelist: Forces only applications or processes that have passed system authentication to access the bus service; (2) Data access control: Implement tiered access permissions based on the sensitivity of the data (such as vehicle control commands, user privacy information); (3) Maximum safe concurrency: Set a global or service-level concurrency limit at the system level to prevent resource overload or denial-of-service attacks.

[0069] For example, the system can stipulate that services involving vehicle braking or power control can only be accessed by applications that have been signed and certified by the vehicle manufacturer; all personally identifiable information transmitted through the bus must be encrypted with high strength; and a system-level upper limit is set for the overall concurrent connection number of the bus, so that even if a single application allows higher concurrency, this system upper limit will be used as the standard, thereby ensuring the stability and safety baseline of the entire vehicle system.

[0070] Thus, through the combination of the two mechanisms mentioned above, the system respects the flexibility and autonomy of application services, while establishing a unified and reliable security baseline for the vehicle communication environment through mandatory constraints at the system layer, achieving an effective balance between flexibility and security.

[0071] Optionally, in some embodiments, the communication bus module uses a layered data model for message passing, the data model including a basic type layer, a data message header layer, a service contract layer, a domain model layer, and a transmission format layer.

[0072] Specifically, the communication bus module used in this system introduces a structured, layered data model during message transmission. This model is divided from bottom to top into a basic type layer, a data message header layer, a service contract layer, a domain model layer, and a transmission format layer. Each layer has a clear division of labor and is encapsulated at each level to jointly ensure the consistency, interpretability, and transmission efficiency of data in cross-application communication.

[0073] The basic type layer, as the cornerstone of the data model, defines the basic data types and their composite structures used in communication. For example, this layer may contain primitive types such as integers, floating-point numbers, and booleans, and encapsulate geographic information fields such as latitude, longitude, and altitude, providing a unified and typed data representation foundation for upper-layer data.

[0074] The data message header layer sits above the base type layer, adding general metadata and control information to each message. Its structure typically includes fields such as a unique message identifier, sender and receiver application identifiers, a timestamp, priority, and security context. For example, in a vehicle status reporting message, this layer can identify the message source as the vehicle controller, the target application as the dashboard service, and carry corresponding timestamps and security verification information to support message routing, scheduling, and security verification.

[0075] Building upon the message header layer, the service contract layer further encapsulates parameters and conventions related to specific service interfaces. This layer explicitly defines the request and response structures for service calls, including service name, input and output parameters, timeout settings, and retry strategies. For example, for the vehicle location retrieval service, in addition to the message header, it encapsulates location query parameters, timeout duration, and allowed retries, forming a standardized interface description for inter-service communication.

[0076] The domain model layer is geared towards specific business domains, semantically organizing and modeling data. This layer aggregates basic types and service contracts to construct domain objects with business meaning. For example, a "Vehicle Status" domain model can be defined, which integrates fields such as vehicle identification number, real-time geographical location, power status, air conditioning status, and media playback status to fully represent the comprehensive status of a vehicle at a given moment, facilitating direct understanding and processing by business applications.

[0077] The transport format layer, located at the top of the model, is responsible for defining the serialization format, compression method, and size limits of messages during network transmission. This layer typically supports multiple mainstream formats to adapt to different scenarios. For example, it can be configured with Protocol Buffers for high performance and compact coding, or JSON format for improved readability and interoperability. It also supports compression algorithms such as GZIP and LZ4 to achieve a balance between transmission efficiency and resource consumption, and can prevent transmission overload by setting a maximum message size.

[0078] Thus, through the organic combination of the above five-layer model, the communication bus module realizes a complete encapsulation and parsing process from raw data to business semantics and then to transmission entities. This design not only enhances the system's ability to express complex data structures and its type safety, but also improves the model's adaptability and maintainability through layered decoupling, providing a solid data architecture foundation for efficient, reliable, and secure service communication between heterogeneous in-vehicle applications.

[0079] To enable those skilled in the art to understand the in-vehicle application development data communication system of this application more clearly and intuitively, a detailed description is provided below in conjunction with the accompanying drawings.

[0080] like Figure 2 As shown, the in-vehicle application development data communication system based on the service bus can be divided into three parts: the application software module, the application software data communication service bus module, and the SDK connecting the two.

[0081] The application software section includes upper-layer ecosystem applications for the vehicle cockpit software, including but not limited to map navigation, multimedia music and video, voice assistants, and weather applications. It also includes system applications for the vehicle cockpit, including but not limited to the system desktop, vehicle settings, vehicle configuration, air conditioning, and sensor services. There are extensive data and interface dependencies between these applications. For example, detailed navigation and positioning information needs to be provided to applications such as voice interaction, weather, system desktop cards, and intelligent driving SR. Voice interaction commands need to be frequently issued to various applications to perform human-machine interaction.

[0082] The application software data communication service bus is divided into a Service Interconnection Management Center, a Data and Computing Center, a Decision Control Center, and a Security Management Center. The Service Interconnection Management Center handles connection destruction, data and interface service registration / unregistration, caching, lookup, and invocation between applications through cross-application process communication. Applications no longer individually interface with data and interface services; instead, they share a common service bus, adopting a pluggable and customizable service strategy. The Data and Computing Center performs targeted data processing based on specific data requirements—some requiring persistence, some requiring efficient caching and access, and some requiring secondary packaging and compression for easier transmission. The Decision Control Center sets service access priority arbitration, combining the custom access policies and priorities of each application software with the system-level access policies to make comprehensive decisions. The Security Management Center includes security verification, data encryption, load balancing, attack prevention, and a service denial-of-connection keep-alive mechanism.

[0083] The connection between the application software module and the application software data communication service bus module is managed uniformly by encapsulating a common SDK. Through the common service connection destruction interface, application data and services are uniformly registered, queried, called and unregistered interfaces to realize data interaction between various application terminals and the public service bus terminal.

[0084] like Figure 3As shown, the hierarchical structure of the data communication system for vehicle application development is described. The data service layer provides standardized data interfaces such as location services, vehicle services, and multimedia services; the core of the unified data service bus contains a service registration center, which is responsible for service registration and discovery; and the security control layer ensures the security and controllability of the communication process.

[0085] Each application in the application layer (such as application A, application B, etc.) first initiates a service request to the bus through standardized calls; after the request is verified and routed by the secure route, it arrives at the corresponding data service (such as the location service); after the data service processes the request, it encapsulates the data and returns the encapsulation result to the application that initiated the call through the bus, thus completing a complete service call.

[0086] like Figure 4 As shown, the service bus call process steps for the vehicle application development data communication system are as follows: Service startup and connection. The service bus process is prioritized as a system-level process and starts by reading the whitelist and permission configuration from the system-level configuration file, and then starting the service interconnection management center and the sub-service security management center.

[0087] Service publishing. Application service providers connect to the service bus process through the service bus SDK and, through the public service registration interface, define the whitelist, data security level, service interface priority, and maximum capacity of the service in accordance with the DAC (Discretionary Access Control) principle, and publish data interfaces and functional service interfaces in the bus process.

[0088] Service storage, retrieval, and concurrent access. The service bus process receives services published by applications, builds a service index (based on process, function, and service tags), and constructs service access nodes using data structures such as doubly linked lists and queues.

[0089] Concurrent access and invocation of services. Application service consumers connect to the service bus process through the service bus SDK, obtain remote service handles through the public service lookup interface, and access and invoke the specified service interfaces in a high-concurrency manner through the service bus's message queue and service queue mechanism to obtain the corresponding data and service capabilities.

[0090] Service destruction and attack prevention through access denial. Application service providers can use the service bus SDK to take certain data and services offline, enabling plug-and-play service capabilities, and can also completely exit and destroy the service. The service bus process promptly denies access to application service consumers that are unreasonable, such as access that does not comply with whitelists and permission policies, or abnormally high-frequency access. The service bus process can also monitor load capacity in real time and achieve load balancing scheduling of service access through service queue structures, priority sorting algorithms, and other capabilities.

[0091] like Figure 5 The security protection model for in-vehicle application development data communication systems has a three-layer structure and two access mechanisms. The three-layer security protection structure includes: Application-layer protection. When applications publish services on the data communication bus, they can customize access whitelists, access passwords, data security levels, and the total concurrency of service interfaces within a certain period of time. This can serve as the first layer of security protection, while data access permissions and data integrity verification serve as the second layer of protection.

[0092] Bus layer protection. The data communication bus layer further strengthens access control through whitelists at the application layer and whitelists forcibly added at the system layer. Secondary encryption and decryption during data transmission are common data transmission protection methods. In addition, message queues are used to achieve high-concurrency access and load balancing. Anti-attack strategies are formulated by using the maximum concurrent access limit imposed by the system and the total concurrent access limit defined by the application layer service within a certain period of time. Rate limiting limits the potential security risks caused by abnormally high-frequency access.

[0093] System-level protection. The system layer adds a whitelist and permission restrictions to enforce data communication and service capabilities, providing an access enforcement policy for the main thread. Each application process and bus process are naturally isolated and do not affect each other.

[0094] The two access mechanisms include: Discretionary Access Control (DAC) mechanism. Application-layer published services can customize access whitelists, priorities, security levels, concurrency policies, etc.

[0095] Enforced Access Control (MAC) mechanisms. At the system level, enhanced access security can be achieved by adding access whitelists, data permissions, directory access permissions, and maximum secure concurrency limits.

[0096] like Figure 6 The data model design for the in-vehicle application development data communication system is divided into 5 levels: BaseDataTypes.

[0097] Data structure example: struct PrimitiveTypes { int32 int_value; / / 1, basic value float float_value; / / 2, floating-point value string text; / / 3. Text data byte binary; / / 4, binary data bool flag; / / 5, Boolean value } struct GeoLocation { / / Composite basic type, geolocation double latitude; / / 1, latitude double longitude; / / 2, longitude float altitude; / / 3, altitude } Data message headers.

[0098] Data structure example: struct StandardHeader { string message_id; / / 1. Unique identifier for the message string source_app; / / 2, sender identifier string target_app; / / 3. Receiver identifier int64 timestamp; / / 4, Send timestamp int32 priority; / / 5, priority level SecurityContext security; / / 6. Security Context } Service Contracts layer.

[0099] Data structure example: struct LocationService { StandardHeader header; / / 1. Contains message header GeoLocation location; / / 2, includes basic types int32 timeout_ms; / / 3. Timeout setting int32 retry_count; / / 4, the number of retries } Domain Models layer.

[0100] Data structure example: struct VehicleStatus { / / Vehicle state domain model string vin; / / 1. Vehicle Identification Code GeoLocation location; / / 2, using basic types PowerStatus power; / / 3, Power Status ClimateStatus climate; / / 4, Air Conditioning Status MediaStatus media; / / 5. Media Status / / Business-specific fields float battery_level; / / 6, battery percentage } TransportFormats layer.

[0101] Data structure example: struct SerializationConfig { enum Format { PROTOBUF = 0; / / Protocol Buffers (default) JSON = 1; / / JSON format MESSAGE_PACK = 2; / / MessagePack } Format format = 1; enum Compression { NONE = 0; GZIP = 1; / / GZIP compression LZ4 = 2; / / LZ4 fast compression } Compression compression? int32 max_size; / / Maximum message size limit } This invention uses a service bus-based data communication framework system for in-vehicle applications as an example. Obviously, a communication framework system specification that conforms to the integration of data interconnection, service capability sharing, and security assurance between in-vehicle applications in intelligent cockpits can be constructed based on this method. Based on this, the communication framework for vehicle-cloud data integration and vehicle-cloud distributed service capabilities can be extended. All changes, modifications, substitutions, and variations implemented based on the in-vehicle application data communication service bus framework provided by this invention are considered to be within the scope of protection of this invention.

[0102] According to the vehicle application development data communication system proposed in this application embodiment, a first application module is used to deploy vehicle cockpit ecosystem applications; a second application module is used to deploy vehicle system-level applications; a communication bus module is used to establish communication connections between upper-layer ecosystem applications and between upper-layer ecosystem applications and system applications; the communication bus module includes: a service interconnection management unit, used to perform application service registration, discovery, and invocation; a computing unit, used to process data caching, encapsulation, and transmission; a decision-making unit, used to perform service arbitration and response decisions based on application-defined policies and preset system security policies; and a security management unit, used to perform access control and security protection. This solves the problems of high development costs, strong system coupling, and poor scalability in communication between different applications in current vehicle intelligent cockpits, achieving efficient, secure, and loosely coupled data interoperability between vehicle applications, and improving the system's scalability and security.

[0103] This application also provides a vehicle that includes the in-vehicle application development data communication system described above.

[0104] According to the vehicle embodiment of this application, the above-mentioned vehicle application development data communication system solves the problems of high development cost, strong system coupling, and poor scalability in the communication between different applications in the current vehicle intelligent cockpit, and realizes efficient, safe, and loosely coupled data interoperability between vehicle applications, thereby improving the scalability and security of the system.

[0105] 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.

[0106] 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.

[0107] 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.

[0108] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Alternatively, the computer-readable medium may be paper or other suitable media on which the program can be printed, since the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in a computer memory.

[0109] 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 (PGAs), field-programmable gate arrays (FPGAs), etc.

[0110] 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.

[0111] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.

[0112] The storage medium mentioned above can be a read-only memory, a disk, or an optical disk, etc. 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 data communication system for vehicle application development, characterized in that, include: The first application module is configured to deploy in-vehicle cockpit ecosystem applications, and the first application module includes at least one upper-layer ecosystem application. The second application module is configured to deploy in-vehicle system-level applications, and the second application module includes at least one system application. A communication bus module is connected between the first application module and the second application module. The communication bus module is configured to establish a communication connection between the upper-layer ecosystem applications and to establish a communication connection between the upper-layer ecosystem applications and the system application. The communication bus module includes: The Service Interconnection Management Unit is configured to perform application service registration, discovery, and invocation. The computing unit is configured to process data caching, encapsulation, and transmission; The decision-making unit is configured to make service arbitration and response decisions based on application-defined policies and preset system security policies. The security management unit is configured to perform access control and security protection.

2. The system according to claim 1, characterized in that, The communication bus module interacts with the first application module and the second application module through the target unified SDK. The target unified SDK is used to provide standardized interfaces for service connection, registration, query, invocation and unregistration.

3. The system according to claim 1, characterized in that, The service interconnection management unit is configured as follows: During service startup, the whitelist and permission policies in the system configuration file are loaded. Respond to the registration request from the application service provider and receive predefined service interface information, access whitelist, data security level, service priority and maximum concurrent capacity; Establish a service index based on process identifier, function type, and service tag, and manage service access nodes through a doubly linked list or queue structure.

4. The system according to claim 1, characterized in that, The computing unit is configured to perform secondary packaging and compression processing on the transmitted data, cache the access data that meets the preset access frequency, and perform storage operations on the data that meets the preset persistent storage conditions.

5. The system according to claim 1, characterized in that, The decision-making unit is configured to prioritize service call requests based on the application's custom access policy and the system-level preset security policy, and dynamically adjust the response order and resource allocation.

6. The system according to claim 1, characterized in that, The security management unit supports discretionary access control and mandatory access control. The discretionary access control mechanism allows the application of custom access whitelists, priorities, security levels, and concurrency policies. The mandatory access control mechanism forces the configuration of access whitelists, data permissions, and maximum security concurrency at the system level.

7. The system according to claim 1, characterized in that, The communication bus module uses a layered data model for message passing. The data model includes a basic type layer, a data message header layer, a service contract layer, a domain model layer, and a transmission format layer.

8. The system according to claim 1, characterized in that, The upper-layer ecosystem applications of the first application module include at least one of map navigation applications, multimedia applications, voice assistant applications, and weather applications; The upper-layer ecosystem applications are configured to provide data services and functional interfaces, and there are data dependencies between the upper-layer ecosystem applications. The data dependencies include the map navigation application providing location data to the voice assistant application and the voice assistant application issuing control commands to the multimedia application.

9. The system according to claim 1, characterized in that, The system applications of the second application module include at least one of the following: system desktop application, vehicle settings application, air conditioning service application, vehicle configuration service application, and sensor service application; The system application is configured to provide vehicle status data to the upper-layer ecosystem application. The vehicle status data includes at least one of the following: battery level data, fuel level data, vehicle location data, and air conditioning operation data. The system application can also receive control commands issued by the upper-layer ecosystem application.

10. A vehicle, characterized in that, The vehicle includes: an in-vehicle application development data communication system as described in any one of claims 1-9 above.

Images