Complete vehicle self-adaptive platform service cabin integration method based on SOA and vehicle

Abstract

The invention provides a cabin integration method of whole vehicle self-adaption platform service based on SOA and a vehicle, and relates to the technical field of vehicle SOA service, the method comprises the following steps: deeply integrating functional components of a whole vehicle self-adaption platform into an Android operating system, and embedding a communication module into an Android hardware abstraction layer; the original biochemical deployment of the SOA service in the cabin domain is realized; meanwhile, an efficient and low-delay service calling interface is constructed by expanding a communication mechanism between Android native processes, so that the Android application can directly call the whole vehicle level SOA service, and the dependence of traditional cross-domain communication on a vehicle-mounted Ethernet and a central gateway is avoided; besides, processor core resources are dynamically allocated in combination with the function security level of the SOA service, so that the real-time performance and execution reliability of high-security-level tasks are guaranteed, and the overall resource utilization efficiency of the system is improved.

Description

Technical Field

[0001] This invention relates to the field of automotive SOA service technology, and more particularly to a cockpit integration method and vehicle based on SOA-based vehicle adaptive platform services. Background Technology

[0002] With the rapid development of intelligent vehicles, the increasing demands of users for personalized vehicle experiences and services, and the widespread application of new technologies such as high-performance chips, sensing technologies, and data intelligence, traditional distributed electronic and electrical architectures are struggling to meet the requirements of vehicle systems in terms of modularity, scalability, communication efficiency, and software iteration. Existing technologies typically employ a distributed architecture based on multiple independent ECUs connected via CAN / LIN buses. However, this architecture still suffers from drawbacks such as a large number of ECUs, complex wiring harnesses, high cross-domain communication latency, strong hardware-software coupling, long development and testing cycles, and high costs. Especially in service-oriented architecture (SOA), the high-performance chips built into the cockpit are used only for cockpit functions, while the central computing unit's chips handle vehicle-level adaptive platform services, resulting in redundant configuration of computing resources and increased hardware costs. Summary of the Invention

[0003] This invention aims to solve the technical problems existing in the above-mentioned related technologies, and proposes a cockpit integration method and vehicle based on SOA for whole vehicle adaptive platform services. It can efficiently integrate the functional components of the whole vehicle-level adaptive platform into the Android cockpit domain controller, reducing service response latency, hardware costs and system complexity.

[0004] The solution to the technical problem of this invention is as follows: This invention provides a cockpit integration method for a vehicle adaptive platform service based on SOA, applied to a cockpit domain controller equipped with an Android operating system, the method comprising: The functional components of the vehicle adaptive platform are integrated into the Android operating system; The communication module of the adaptive platform is embedded into the hardware abstraction layer of the Android operating system; Based on the native binding inter-process communication mechanism of the Android operating system, an adaptive platform service call interface is constructed to allow Android applications to call the SOA services provided by the functional components. Processor core resources are dynamically allocated based on the functional security level of the SOA service.

[0005] Furthermore, the functional components of the adaptive platform are used to provide vehicle SOA services, including at least one of safety monitoring services, data acquisition services, and remote diagnostic services.

[0006] Furthermore, when both the caller and the provider of the SOA service are located inside the cockpit domain controller, the service call is completed directly through the binding inter-process communication mechanism without going through the vehicle Ethernet or central gateway; when the service call involves other functional domains, SOA communication is carried out through the vehicle Ethernet via the communication module embedded in the hardware abstraction layer.

[0007] Furthermore, the adaptive platform functional component registers its service information, including service name, interface definition, and functional security level, with the local service registry when the Android operating system starts; the Android application obtains available services by querying the service registry and establishes a call connection.

[0008] Furthermore, the adaptive platform functional components run as independent user entities within the Android operating system and are allocated dedicated memory areas to achieve resource isolation from native Android applications.

[0009] Furthermore, the dynamic allocation of processor core resources based on functional safety level includes: when the functional safety level of an SOA service reaches a preset high security threshold, binding it to a dedicated processor core and suspending the execution of all non-security-related tasks on that core.

[0010] Furthermore, the preset high security threshold corresponds to a functional safety level of ASIL B or higher, and the non-security-related tasks include service tasks with a functional safety level of QM.

[0011] Furthermore, the strategy for dynamically allocating processor core resources is adjusted in real time by the Android operating system kernel of the cockpit domain controller based on the functional safety level of the currently running SOA service, and the original scheduling state is restored after the service exits.

[0012] Furthermore, the communication module embedded in the hardware abstraction layer reuses the underlying Ethernet driver of the Android operating system to achieve SOA communication with the assisted driving domain, chassis domain, power domain, and body domain.

[0013] On the other hand, this application provides a vehicle including a cockpit domain controller, an assisted driving domain controller, a chassis domain controller, a powertrain domain controller, and a body domain controller. Each domain controller is interconnected through a central gateway and communicates based on SOA. The cockpit domain controller is equipped with an Android operating system and is configured to execute the aforementioned cockpit integration method for SOA-based vehicle adaptive platform services.

[0014] The beneficial effects of this invention are as follows: This application provides a cockpit integration method for vehicle adaptive platform services based on SOA. This method deeply integrates the functional components of the vehicle adaptive platform into the Android operating system and embeds its communication module into the Android hardware abstraction layer, realizing the native deployment of SOA services within the cockpit domain. Simultaneously, by extending the native inter-process communication mechanism of Android, a high-efficiency, low-latency service call interface is constructed, enabling Android applications to directly call vehicle-level SOA services, avoiding the dependence of traditional cross-domain communication on in-vehicle Ethernet and central gateways. Furthermore, by dynamically allocating processor core resources based on the functional safety level of SOA services, not only is the real-time performance and execution reliability of high-safety-level tasks guaranteed, but the overall resource utilization efficiency of the system is also improved. This solution significantly reduces service response latency, hardware costs, and system integration complexity, providing a highly compatible, highly secure, and highly flexible cockpit integration architecture for software-defined vehicles. This application also provides a corresponding vehicle, the beneficial effects of which are the same as those of the above method, and will not be elaborated further here.

[0015] Other features and advantages of this application will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the description, claims and drawings. Attached Figure Description

[0016] The accompanying drawings are provided to further understand the technical solutions of the present invention and constitute a part of the specification. They are used together with the embodiments of the present invention to explain the technical solutions of the present invention, and do not constitute a limitation on the technical solutions of the present invention.

[0017] Figure 1 This is a flowchart of the cockpit integration method for the SOA-based vehicle adaptive platform service provided in this application; Figure 2 This is the vehicle structure diagram provided in this application. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0019] The present application will be further described below with reference to the accompanying drawings and specific embodiments. The described embodiments should not be considered as limitations on the present application, and all other embodiments obtained by those skilled in the art without inventive effort are within the scope of protection of the present application.

[0020] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0021] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0022] With the deepening development of the "new four modernizations" trend in automobiles, the needs of the new generation of users for vehicles have undergone a fundamental transformation. Cars are evolving from traditional transportation tools into intelligent terminals integrating connected services, autonomous driving, data-driven operations, and personalized experiences. Users not only focus on basic driving performance but also expect vehicles to proactively understand their needs, provide customized services, and achieve seamless human-machine interaction. At the same time, new technologies such as high-performance chips, advanced sensing technologies, artificial intelligence, and big data processing are rapidly being integrated into automotive systems. This makes the traditional distributed electronic and electrical architecture, based on a large number of independent electronic control units interconnected via CAN or LIN buses, unable to meet the higher requirements of modern vehicles in terms of modularity, communication efficiency, software iteration speed, and system scalability.

[0023] Against this backdrop, Service-Oriented Architecture (SOA) based on in-vehicle Ethernet has become an inevitable direction for the evolution of vehicle electronic and electrical architecture. SOA is a design methodology that breaks down a software system into multiple loosely coupled service units that can be independently developed, deployed, and maintained. In the automotive field, SOA vehicle architecture, through standardized interfaces and communication protocols, enables different functional modules to dynamically discover, invoke on demand, and work collaboratively, thereby achieving a highly modular, reusable, and platform-independent system design. This architecture supports runtime service hot-swapping and seamless integration of heterogeneous components, significantly improving the flexibility and development efficiency of software-defined vehicles.

[0024] Current mainstream SOA (Service-Oriented Architecture) vehicle physical architectures generally adopt a domain-centralized design, dividing the vehicle's functions into several core domains, including a central computing unit, regional control units, intelligent communication terminals, cockpit domain controllers, and advanced autonomous driving controllers. The central computing unit, as the core of the vehicle, typically includes safety-critical microcontrollers for hard real-time control and service processors for hybrid real-time processing; while the cockpit domain generally uses high-performance system-on-a-chip (SoC), such as the Qualcomm 8295. It is worth noting that although the 8295 chip and the service processors in the central computing unit are highly similar in technical capabilities and core architecture, existing solutions still strictly separate their functions: the 8295 is only used for cockpit-related services, such as seat adjustment, air conditioning control, door lock operation, and new energy status display; while vehicle-level services, such as security monitoring, big data collection, log management, edge computing, and remote upgrades, are all deployed on the service processors in the central computing unit. This redundant configuration not only wastes hardware resources but also significantly increases the overall vehicle cost.

[0025] From an architectural evolution perspective, automotive electronic and electrical architecture has gradually transitioned from an early distributed structure containing dozens or even hundreds of electronic control units to a domain-centralized structure. The latter integrates control units with similar functions into a unified domain controller, such as dividing the entire vehicle into five functional domains: powertrain, chassis, body, cockpit, and autonomous driving, or further merging them into three domains: vehicle control domain, intelligent driving domain, and intelligent cockpit domain. This significantly reduces the number of controllers and wiring complexity, while improving communication bandwidth and software scalability. However, in the current SOA domain-centralized architecture, significant computing power silos still exist between the cockpit domain and the vehicle control domain: the surplus computing power of high-performance cockpit chips is not effectively utilized, and vehicle adaptive platform services are forced to be deployed on dedicated processors, leading to increasingly prominent problems such as system redundancy, high service call latency, and long development and integration cycles. Therefore, there is an urgent need for a new integration method that can efficiently integrate the vehicle adaptive platform service into the Android cockpit domain, achieve localized low-latency calls, and take into account functional safety and resource isolation, so as to truly unleash the potential of high-performance chips and drive the automotive electronic and electrical architecture to evolve towards higher integration, lower latency and better cost structure.

[0026] To address the issues of high latency, high cost, resource waste, and insufficient safety scheduling caused by the separation of cockpit domain and vehicle AP services in existing SOA vehicle architectures, this application proposes a cockpit integration method and vehicle based on SOA-based vehicle adaptive platform services. Its main technical features are: directly integrating the functional components of the AUTOSAR AP (such as safety monitoring, data acquisition, and remote diagnostics) into the cockpit domain controller running the Android operating system, and embedding the AP communication module into the Android Hardware Abstraction Layer (HAL); constructing an efficient service call interface by extending Android's native Binder inter-process communication mechanism, enabling Android applications to directly call vehicle-level SOA services locally, avoiding cross-domain network transmission; and dynamically allocating dedicated processor core resources based on the functional safety level of the SOA service (such as ASIL B and above), isolating and suspending non-safety-related tasks during high-safety task execution, thereby significantly reducing service response latency, hardware costs, and integration cycles while ensuring the real-time performance, security, and overall system resource utilization efficiency of critical services.

[0027] First, the cockpit integration method for the vehicle adaptive platform service based on SOA provided in this application will be described in detail below with reference to the accompanying drawings. It is applied to a cockpit domain controller equipped with an Android operating system. The cockpit domain controller is an integrated computing unit with a high-performance automotive SoC (such as Qualcomm SA8295) as its core and running the Android operating system. It is responsible for intelligent functions such as infotainment, human-machine interaction, and multi-screen collaboration in the vehicle cockpit. It also has rich hardware interfaces and network communication capabilities. It can be used as a caller or bearer of SOA services, providing a software and hardware foundation for the local integration and efficient scheduling of functional components of the vehicle adaptive platform (AP).

[0028] Reference Figure 1 The implementation process of the cockpit integration method for SOA-based vehicle adaptive platform services provided in this application includes, but is not limited to, the following steps.

[0029] Step S110: Integrate the functional components of the vehicle adaptive platform into the Android operating system.

[0030] In step S110, vehicle-level functional components (such as safety monitoring services, data acquisition services, and remote diagnostic services) that originally ran on the central computing unit (such as the AUTOSAR AP platform in the VDC) are directly deployed to the cockpit domain controller running the Android operating system, and managed and run as part of the Android system. This integration allows the cockpit domain to go beyond human-machine interaction and entertainment functions, enabling it to support vehicle SOA services. This breaks down the physical and logical isolation between the cockpit and vehicle control functions in the traditional architecture, laying the foundation for subsequent efficient localized invocation.

[0031] Step S120: Embed the communication module of the adaptive platform into the hardware abstraction layer of the Android operating system.

[0032] In step S120, the communication stack of the adaptive platform (such as the ara::com module) is embedded into the Hardware Abstraction Layer (HAL) of the Android system as a dynamic library, enabling it to directly access the underlying Ethernet driver and seamlessly interface with the vehicle network protocol stack. By embedding the communication module at the HAL layer, the stability and security boundaries of the Android system are preserved, while also giving it the ability to natively support SOA communication protocols (such as SOME / IP). This allows the cockpit domain controller to handle local inter-process communication and, when necessary, perform standardized cross-domain SOA interactions with other functional domains (such as the chassis domain and powertrain domain).

[0033] Step S130: Based on the native binding inter-process communication mechanism of the Android operating system, an adaptive platform service call interface is built to allow Android applications to call the SOA services provided by the functional components.

[0034] In step S130, the Android system's built-in Binder IPC (Binding Inter-Process Communication) mechanism is used to adapt and extend the interface to support the mapping and invocation of AUTOSAR AP service interfaces. Specifically, the interface definition (such as IDL) of the AP service is converted into Android AIDL format, and cross-process service requests and responses are implemented through the Binder driver. As a result, upper-layer Android applications can access SOA services provided by AP functional components directly and efficiently, just like calling local system services, without relying on network protocols or intermediate proxies, significantly improving invocation efficiency and simplifying the software architecture.

[0035] Step S140: Dynamically allocate processor core resources based on the functional security level of the SOA service.

[0036] In step S140, a functional safety-aware resource scheduling strategy is introduced, adjusting the execution environment of each SOA service on a multi-core processor in real time based on its corresponding functional safety level (e.g., ASIL B, QM). When the safety level of a service reaches a preset high safety threshold, the system binds its task to a dedicated CPU core and suspends the execution of all non-safety-related tasks on that core; after the service ends, the original scheduling state is restored. This mechanism ensures that high-safety-critical tasks receive deterministic computing resource guarantees, effectively avoiding resource contention and interference with ordinary application tasks, and meeting the requirements of automotive functional safety standards for execution isolation and real-time performance.

[0037] In some embodiments of this application, the functional components of the adaptive platform are used to provide vehicle SOA services, including at least one of safety monitoring services, data acquisition services, and remote diagnostic services.

[0038] The safety monitoring service is used to detect abnormal or emergency events in vehicle operation in real time (such as collision warnings, brake failures, etc.) and trigger corresponding safety response mechanisms. The data acquisition service is responsible for aggregating operation logs, sensor data, and user behavior information from various domain controllers, providing basic data support for big data analysis, fault prediction, and OTA upgrades. The remote diagnostic service supports interaction with the cloud platform through the vehicle network channel to remotely read the vehicle's health status, analyze fault codes, and issue repair suggestions. Migrating these critical services, originally deployed in the central computing unit, to the cockpit domain controller not only expands the functional boundaries of the cockpit system, transforming it from a simple interactive terminal into an intelligent node with whole-vehicle service capabilities, but also creates the preconditions for efficient invocation of these services through local IPC, thereby improving the overall system response speed and service availability.

[0039] In some embodiments of this application, when both the caller and provider of the SOA service are located within the cockpit domain controller, the service call is completed directly through a bound inter-process communication mechanism, without going through the vehicle Ethernet or central gateway. Only when the service call involves other functional domains is SOA communication conducted via the vehicle Ethernet through a communication module embedded in the hardware abstraction layer.

[0040] Specifically, when the caller of an SOA service (such as an Android application) and the provider (such as an AP functional component integrated within the cockpit domain, like a safety monitoring or data acquisition module) are both located within the same cockpit domain controller, the system no longer uses the lengthy communication link of "via in-vehicle Ethernet → central gateway → target domain controller" found in traditional cross-domain architectures. Instead, it directly utilizes the native Binder IPC mechanism of the Android operating system to complete service calls. Since Binder is a kernel-level, zero-copy, low-latency local IPC mechanism, this approach can significantly reduce service response time from approximately 80ms in traditional solutions to around 8ms, greatly improving real-time performance while avoiding unnecessary occupation of in-vehicle network bandwidth and gateway processing overhead.

[0041] On the other hand, when service calls do require cross-domain collaboration (e.g., a cockpit application requests braking status from the chassis domain or battery information from the powertrain domain), the system initiates standard SOA communication by embedding it in the Android Hardware Abstraction Layer (HAL), interacting with the target domain controller via the in-vehicle Ethernet. This design ensures that external communication still follows the unified protocol specifications of the vehicle's SOA architecture (such as SOME / IP), maintaining system openness and compatibility. In summary, this mechanism implements a dual-mode communication strategy of "internal pass-through, external standard," maximizing the efficiency of local service calls while ensuring architectural consistency. It effectively solves the performance bottleneck problem caused by "all services using the network regardless of location" in traditional SOA architectures, and is one of the key technical paths for achieving low latency, high integration, and cost optimization in this application.

[0042] In some embodiments of this application, the adaptive platform functional component registers its service information, including service name, interface definition, and functional safety level, with the local service registry when the Android operating system starts. Android applications then query the service registry to obtain available services and establish connection points.

[0043] Specifically, during the Android operating system startup process, each AP functional component (such as security monitoring service, data acquisition service, etc.) will proactively register with the pre-set local service registry center within the system, submitting its key metadata information, including service name (used for unique identification), interface definition (describing the callable methods, parameters, and return types), and functional safety level (such as ASIL B or QM, used for subsequent resource scheduling decisions). This registration behavior transforms the originally statically bound service relationships into a dynamically discoverable service ecosystem.

[0044] Subsequently, when an Android application needs to call a vehicle-level SOA service, it doesn't need to hardcode service implementation details or rely on fixed addresses. Instead, it queries the local service registry to obtain the list of currently available services, their interface specifications, and security attributes in real time. Based on this information, the application can dynamically construct a call connection (e.g., through a Binder interface proxy) to achieve secure and compliant access to the target service. This mechanism not only significantly improves the system's flexibility and scalability—new services can be "hot-swapped" without modifying the application code, and old services can be smoothly replaced—but also, because the service information includes functional safety levels, it provides the necessary input for dynamic allocation of processor core resources based on security levels in subsequent steps. Furthermore, this design fully aligns with the core concepts of SOA architecture: "service autonomy, interface standards, and runtime binding," enabling the Android cockpit system to truly possess the ability to support vehicle-level services, rather than merely being a passive user interface terminal.

[0045] In some embodiments of this application, the adaptive platform functional components run as independent user entities within the Android operating system and are allocated dedicated memory areas to achieve resource isolation from native Android applications. Through operating system-level permission and memory isolation mechanisms, the operational security, stability, and reliability of the vehicle adaptive platform (AP) functional components integrated into the Android cockpit domain controller are ensured, preventing resource conflicts or mutual interference between them and ordinary native Android applications.

[0046] Specifically, in the Android operating system, each process runs by default as a specific Linux user and is protected by SELinux, the UID / GID permission model, and the Memory Management Unit (MMU). This application requires that AP functional components (such as critical services like security monitoring and remote diagnostics) be started with an independent user identity (i.e., a UID different from that of system applications or third-party apps). This means that their processes have an independent security context at the kernel level and cannot be directly accessed or manipulated by other unauthorized applications.

[0047] Simultaneously, the system allocates dedicated memory regions for these AP components, including independent stack space, shared memory segments, and possible DMA buffers, ensuring that their data storage and processing do not share the same physical or virtual memory pages with entertainment or HMI applications. This isolation not only prevents critical service anomalies caused by ordinary application crashes, memory leaks, or malicious behavior, but also prevents data from high-security tasks from being illegally read or tampered with, thereby meeting the functional safety standards (such as ISO 26262) requirements for fault isolation and freedom from interference.

[0048] More importantly, without changing the overall architecture of the Android system, this design utilizes its native security mechanisms to achieve the co-platform deployment of "security-critical services" and "non-security applications". This fully utilizes the computing resources of the high-performance cockpit SoC while maintaining the necessary boundaries between software of different security levels. It provides a feasible path for carrying ASIL B and above level services on a general operating system, which is the key technical guarantee for achieving a balance between high security and high integration in this application.

[0049] In some embodiments of this application, processor core resources are dynamically allocated based on functional safety levels. This includes binding a SOA service to a dedicated processor core when its functional safety level reaches a preset high security threshold, and suspending the execution of all non-security-related tasks on that core. The core function of this design is to construct a security-aware real-time execution environment assurance mechanism. By scheduling high-security-level SOA services (such as security monitoring and emergency diagnostics) to run on dedicated CPU cores and forcibly suspending other tasks originally running on those cores, the system can effectively eliminate uncertainties such as resource contention, cache pollution, and scheduling delays caused by multi-task concurrency, thereby ensuring that critical services have predictable execution times and complete exclusive access to computing resources. This "core isolation + task freezing" strategy is a key means of achieving high functional safety integrity (such as meeting the interference-free requirements of ASIL B and above in ISO 26262), enabling the cockpit domain controller to reliably support safety-critical functions on a general-purpose operating system platform.

[0050] In some embodiments of this application, a preset high security threshold corresponds to a functional safety level of ASIL B or higher, and non-safety-related tasks include service tasks with a functional safety level of QM. This setting provides clear and standardized trigger boundaries and object definitions for dynamic resource scheduling. According to the ISO 26262 standard, ASIL B represents a medium safety risk level, typically involving scenarios that may cause minor personal injury, and its development must meet strict verification and fault tolerance requirements; while QM (Quality Management) indicates that the function has no specific safety requirements, only needs to follow conventional quality management processes, typically such as in-cabin entertainment tasks like music playback and UI animations. Anchoring the "high security threshold" to ASIL B not only conforms to the industry's general recognition of safety-critical functions, but also avoids the waste of resources caused by over-protecting low-risk services; at the same time, clearly classifying QM tasks as "non-safety-related tasks" allows the system to accurately identify and suspend which loads when executing high-safety services, thereby maintaining the clarity of scheduling logic and engineering feasibility while ensuring safety.

[0051] In some embodiments of this application, the strategy for dynamically allocating processor core resources is adjusted in real time by the Android operating system kernel of the cockpit domain controller based on the functional safety level of the currently running SOA service, and the original scheduling state is restored after the service exits.

[0052] This mechanism achieves closed-loop, adaptive, and reversible resource management, representing the core innovation of this application in implementing Mixed-Criticism System (MCS) scheduling on the general Android platform. With the Android kernel directly responsible for scheduling decisions, there's no need for an additional hypervisor or independent security OS, reducing system complexity and hardware dependency. Simultaneously, the kernel can perceive changes in service security attributes in real time, immediately building a dedicated execution environment upon service startup and automatically releasing resources and restoring the original task queue after service completion, ensuring that overall system performance is not affected in the long term. This dynamic strategy of "on-demand activation and immediate recycling" not only meets the deterministic execution requirements of high-security services but also maximizes the computing power of multi-core SoCs, balancing security, real-time performance, and energy efficiency, providing a feasible path for efficient and safe integration in software-defined vehicles.

[0053] In some embodiments of this application, the communication module embedded in the hardware abstraction layer reuses the underlying Ethernet driver of the Android operating system to realize SOA communication with the assisted driving domain, chassis domain, power domain and body domain, thereby enabling standardized network communication between the Android cockpit system and other functional domains of the vehicle, while avoiding redundant development of underlying drivers and improving system integration efficiency and stability.

[0054] Traditionally, the Android operating system is primarily geared towards consumer electronics scenarios, and its Ethernet drivers are typically used for Wi-Fi or cellular network backhaul, without native support for automotive SOA communication protocols (such as SOME / IP). This application, however, embeds the communication module of the Adaptive Platform (AP) (such as the ara::com stack of the AUTOSAR AP) into Android's Hardware Abstraction Layer (HAL) and directly reuses the system's existing underlying Ethernet driver. This allows the cockpit domain controller to efficiently access the automotive Ethernet physical interface without modifying the kernel or introducing an additional network stack.

[0055] This reuse mechanism not only significantly reduces software development complexity and certification costs, but also ensures the reliability and performance consistency of communication paths—because the underlying drivers have been fully verified and optimized by chip manufacturers. More importantly, it enables the cockpit system, which was originally limited to local service calls, to have complete cross-domain SOA interaction capabilities: when the cockpit application needs to obtain perception data from the assisted driving domain, vehicle status from the chassis domain, battery information from the powertrain domain, or door lock status from the body domain, it can encapsulate standard SOA requests through this communication module, send them to the corresponding domain controller via the vehicle Ethernet, and receive structured responses. Thus, the cockpit domain can act as a carrier of local AP services, as well as a peer communication node in the vehicle SOA network, truly integrating into a unified service architecture and laying the communication foundation for realizing full-domain collaborative intelligence (such as scenario-based HMI linkage based on vehicle status).

[0056] Secondly, refer to Figure 2 This application provides a vehicle that integrates the aforementioned SOA-based vehicle adaptive platform service cockpit integration method into the complete vehicle electronic and electrical architecture, thereby constructing a highly integrated, highly collaborative, and cost-optimized intelligent vehicle system.

[0057] The vehicle includes a cockpit domain controller, an advanced driver assistance system (ADAS) domain controller, a chassis domain controller, a powertrain domain controller, and a body domain controller. These domain controllers are interconnected via a central gateway and communicate based on Service-Oriented Architecture (SOA). The cockpit domain controller runs on an Android operating system and is configured to execute the aforementioned SOA-based vehicle adaptive platform service cockpit integration method.

[0058] Specifically, these domain controllers are interconnected through a central gateway and uniformly adopt a service-oriented architecture (SOA) for cross-domain communication, which aligns with the current technological trend of automotive electronics evolving towards domain centralization and even centralized computing. Based on this architecture, it is particularly emphasized that the cockpit domain controller runs on the Android operating system and is configured to execute the integration method proposed in this application. This means that the cockpit is no longer merely a human-machine interface terminal, but has been upgraded to an intelligent node with vehicle-level service carrying and scheduling capabilities.

[0059] By deploying the cockpit integration method of this application in the vehicle, AP functional components (such as safety monitoring, data acquisition, and remote diagnostics) that originally needed to be processed by a central computing unit (such as VDC) can run directly within the cockpit domain controller, utilizing the surplus computing power of its high-performance SoC (such as Qualcomm SA8295). Simultaneously, thanks to technologies such as local Binder IPC calls, HAL layer communication module embedding, service registration and discovery mechanisms, and functional safety-aware kernel resource scheduling, the vehicle can significantly reduce cross-domain communication latency, decrease reliance on dedicated security MCUs, compress hardware BOM costs, and shorten the vehicle software integration and testing cycle, while ensuring the real-time performance and isolation of high-security services. Therefore, this vehicle design not only demonstrates the engineering feasibility of the technical solution of this application but also showcases its system-level benefits in actual products—that is, achieving a new generation of intelligent vehicle architecture characterized by "one chip, multiple functions, software and hardware collaboration, and full-domain service integration" without sacrificing functional safety and communication standards.

[0060] In some embodiments of this application, based on the Qualcomm SA8295 high-performance cockpit SoC, the efficient integration of the vehicle adaptive platform service into the Android system is achieved through three core technologies: architecture fusion, communication passthrough, and dynamic deployment. Specifically, firstly, the communication module (ara::com) of the AUTOSAR AP is compiled into a dynamic library of the Android Hardware Abstraction Layer (HAL) and embedded into the Android system framework; secondly, the native Binder inter-process communication mechanism is extended, and the AUTOSAR Interface Definition Language (IDL) is mapped to the Android AIDL interface, enabling cockpit applications to directly call lightweight AP software components (SWC) such as safety monitoring, data acquisition, and remote diagnostics through Binder, without the need for cross-domain SOME / IP communication via the central gateway and vehicle Ethernet; simultaneously, an SOA resource manager is added to the Android system to dynamically allocate CPU core resources according to the functional safety level of the service (such as ASIL B), for example, binding the safety monitoring module to a large core and suspending non-critical tasks to ensure the real-time performance and isolation of high-security services. The entire call chain implements a local pass-through path of "Android application → Binder IPC → AP COM module → SWC → underlying actuator", which fully releases the excess computing power of the cockpit SoC and provides an innovative implementation paradigm of high integration, low latency and low cost for software-defined vehicles.

[0061] In summary, the cockpit integration method and vehicle based on SOA-based vehicle adaptive platform services provided in this application have the following technical effects.

[0062] This application embodiment achieves localized deployment of vehicle-level services within the cockpit by directly integrating AP functional components (such as safety monitoring, data acquisition, and remote diagnostics) into the Android cockpit domain controller and embedding its communication module into the Hardware Abstraction Layer (HAL). The service call interface, built based on an extended Binder IPC mechanism, allows Android applications to bypass the vehicle Ethernet and central gateway, directly and efficiently calling local SOA services, reducing the measured response latency from 80ms to 8ms. Simultaneously, the system introduces a functional safety level-driven dynamic kernel resource scheduling strategy—when a service reaches ASIL B or higher, it is bound to a dedicated CPU core, and QM-level non-safe tasks on that core are suspended. The system automatically restores its original state after the service ends, thereby achieving spatiotemporal isolation and deterministic execution of high-safety tasks on the general Android platform.

[0063] Furthermore, this method supports runtime dynamic discovery and connection through a service registry center. Combined with the design of independent user identities and dedicated memory areas, it ensures resource isolation and operational security between AP components and native Android applications. The HAL layer communication module reuses the underlying Android Ethernet driver, ensuring efficient local calls while seamlessly integrating with other functional domains such as assisted driving, chassis, powertrain, and body, maintaining consistency in vehicle SOA communication. When applied to the entire vehicle, this solution reduces the VDC chip from 6 cores to 4 cores, lowers the hardware cost per vehicle by 28%, and shortens the integration testing cycle by 75%, significantly improving system integration, security, and economy. It provides a high-performance, highly reliable, and low-cost new path for cockpit integration in software-defined vehicles.

[0064] It should be noted that in all specific embodiments of this application, all data processing activities related to user identity or personal characteristics, such as user information, user behavior data, historical data, and location information, will be conducted in accordance with the principles of legality, legitimacy, and necessity. All data collection, use, storage, and processing will be subject to compliance with applicable national and regional laws, regulations, and industry standards, and informed consent from users will be obtained in a clear and explicit manner before processing. For the processing of sensitive personal information, separate consent from users will be obtained through prominent means such as pop-up prompts and independent confirmation pages. If any processing conflicts with laws and regulations, the laws and regulations will prevail, and necessary data processing will only be carried out within the scope permitted by laws and regulations, ensuring that all data-based applications, analyses, and technical implementations are conducted within the scope permitted by laws and regulations.

[0065] In some alternative embodiments, the functions / operations mentioned in the block diagrams may not occur in the order shown in the operation diagrams. For example, depending on the functions / operations involved, two consecutively shown blocks may actually be executed substantially simultaneously, or the blocks may sometimes be executed in reverse order. Furthermore, the embodiments presented and described in the flowcharts of this application are provided by way of example to provide a more comprehensive understanding of the technology. The disclosed methods are not limited to the operations and logic flows presented herein. Alternative embodiments are contemplated in which the order of various operations is changed and sub-operations described as part of a larger operation are executed independently.

[0066] Furthermore, although this application is described in the context of functional modules, it should be understood that, unless otherwise stated, one or more of the functions and / or features may be integrated into a single physical device and / or software module, or one or more functions and / or features may be implemented in a separate physical device or software module. It is also understood that a detailed discussion of the actual implementation of each module is unnecessary for understanding this application. Rather, given the properties, functions, and internal relationships of the various functional modules in the apparatus disclosed herein, the actual implementation of the module will be understood within the scope of ordinary skill of an engineer. Therefore, those skilled in the art can implement the application set forth in the claims using ordinary skill. It is also understood that the specific concepts disclosed are merely illustrative and are not intended to limit the scope of this application, which is determined by the full scope of the appended claims and their equivalents.

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

[0068] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequential list of executable programs for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, a program execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can retrieve and execute a program from or in conjunction with such a program execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can mean any means that can contain, store, communicate, propagate, or transmit a program for use by or in conjunction with a program execution system, apparatus, or device.

[0069] More specific examples (a non-exhaustive list) of computer-readable media include: electrical connections (electronic devices) having one or more wires, portable computer disk drives (magnetic devices), 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). Additionally, computer-readable media can even be paper or other suitable media on which programs can be printed, for example, by optically scanning the paper or other media, then editing, interpreting, or, if necessary, processing it in a suitable manner to obtain the program electronically, and then storing it in computer memory.

[0070] It should be understood that various parts of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable program 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.

[0071] In the foregoing description of this specification, the reference to terms such as "one embodiment / implementation," "another embodiment / implementation," or "certain embodiments / implementations," etc., indicates that a specific feature, structure, material, or characteristic described in connection with an embodiment or example is included in an embodiment or example of the present invention. 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.

[0072] Although embodiments of the invention have been shown and described, those skilled in the art will understand that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the claims and their equivalents.

[0073] The above is a detailed description of the preferred embodiments of the present invention. However, the present invention is not limited to the embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of the present invention. All such equivalent modifications or substitutions are included within the scope defined by the claims of the present invention.

Claims

1. A cockpit integration method for a SOA-based whole-vehicle adaptive platform service, characterized in that, The method is applied to a cockpit domain controller carrying an Android operating system, and comprises the following steps: integrating function components of a whole vehicle adaptive platform into the Android operating system; embedding a communication module of the adaptive platform into a hardware abstraction layer of the Android operating system; extending a native binding inter-process communication mechanism of the Android operating system, constructing an adaptive platform service calling interface, and calling SOA services provided by the function components by an Android application program; dynamically allocating processor core resources according to a functional safety level of the SOA services.

2. The SOA-based vehicle adaptive platform service cockpit integration method of claim 1, wherein, The function components of the adaptive platform are used to provide whole vehicle SOA services, including at least one of a safety monitoring service, a data acquisition service, and a remote diagnosis service.

3. The SOA-based vehicle adaptive platform service cabin integration method of claim 1, wherein, When a caller and a provider of the SOA services are both located inside the cockpit domain controller, service calling is directly completed by the binding inter-process communication mechanism without passing through a vehicle-mounted Ethernet or a central gateway; when service calling involves other function domains, SOA communication is performed through the communication module embedded in the hardware abstraction layer via the vehicle-mounted Ethernet.

4. The SOA-based vehicle adaptive platform service cabin integration method of claim 1, wherein, The adaptive platform function components register service information, including a service name, an interface definition, and a functional safety level, to a local service registration center when the Android operating system is started; an Android application program acquires available services by querying the service registration center and establishes a calling connection.

5. The SOA-based vehicle adaptive platform service cabin integration method of claim 1, wherein, The adaptive platform function components run in the Android operating system as independent user identities and are allocated exclusive memory areas to realize resource isolation from Android native application programs.

6. The SOA-based vehicle adaptive platform service cabin integration method of claim 1, wherein, The dynamic allocation of processor core resources according to the functional safety level comprises the following steps: when the functional safety level of the SOA services reaches a preset high safety threshold, the SOA services are bound to a dedicated processor core, and execution of all non-safety related tasks on the core is suspended.

7. The SOA-based vehicle adaptive platform service cabin integration method of claim 6, wherein, The preset high safety threshold corresponds to a functional safety level of ASIL B or above, and the non-safety related tasks include service tasks with a functional safety level of QM.

8. The SOA-based vehicle adaptive platform service cabin integration method of claim 1, wherein, The strategy of the dynamic allocation of processor core resources is adjusted in real time by an Android operating system kernel of the cockpit domain controller according to the functional safety level of currently running SOA services, and the original scheduling state is restored after the services exit.

9. The SOA-based vehicle adaptive platform service cabin integration method of claim 1, wherein, The communication module embedded in the hardware abstraction layer reuses an underlying Ethernet driver of the Android operating system to realize SOA communication with an assisted driving domain, a chassis domain, a power domain, and a vehicle body domain.

10. A vehicle characterized by comprising: The system comprises a cockpit domain controller, an assisted driving domain controller, a chassis domain controller, a power domain controller, and a vehicle body domain controller, the domain controllers are interconnected through a central gateway and communicate based on SOA; the cockpit domain controller carries an Android operating system and is configured to execute the cockpit integration method of the whole vehicle adaptive platform service based on SOA according to any one of claims 1 to 9.

Images