SOA-based regional controller configuration method and system, vehicle and medium

Abstract

The invention provides an SOA-based area controller configuration method and system, a vehicle and a medium, and the method comprises the steps: introducing a master controller into a vehicle SOA electronic and electrical architecture, carrying out the centralized maintenance of a unified configuration code table, and actively issuing a configuration instruction to each slave area controller; and single trusted source management and cooperative consistent deployment of software and hardware configuration of the whole vehicle are realized. The method effectively solves the problems of inconsistent multi-controller configuration, difficulty in tracing, complex maintenance and the like caused by traditional distributed configuration, not only supports dynamic enabling / disabling and cross-regional deployment of software components according to vehicle types or user requirements, but also remarkably improves the system integration efficiency, OTA upgrading reliability and diagnosis accuracy, and is suitable for large-scale popularization and application. Therefore, the flexibility, the expandability and the maintainability of a software-defined automobile framework are enhanced while the function safety is guaranteed.

Description

Technical Field

[0001] This invention relates to the field of area controller technology, and more particularly to an SOA-based area controller configuration method, system, vehicle, and medium. Background Technology

[0002] As automotive electronic and electrical architectures evolve towards "software-defined vehicles" and SOA (service-oriented architecture), vehicle functions are increasingly being implemented by numerous independently developable, deployable, and startable software components (SWC / APP). These components may be distributed across a central computing unit or multiple intelligent area controllers, and are dynamically enabled or disabled based on vehicle configuration or user needs. However, in existing technologies, each controller typically maintains its own independent configuration code, with inconsistent rules. When a function changes, the configurations of multiple controllers must be modified simultaneously, which is not only cumbersome and error-prone, but also makes it difficult to guarantee the consistency and traceability of configurations across the entire vehicle. Especially under the SOA architecture, software components can be flexibly deployed across controllers. The traditional controller-centric distributed configuration management approach can no longer meet the requirements of hardware-software decoupling, dynamic function allocation, and efficient OTA upgrades, resulting in high development costs, maintenance difficulties, and complex diagnostics. Summary of the Invention

[0003] This invention aims to solve the technical problems existing in the above-mentioned related technologies, and proposes a region controller configuration method, system, vehicle and medium based on SOA. It can centrally maintain a unified configuration code table through the main controller and actively distribute software and hardware configuration information to subordinate region controllers, realize the unique source management, dynamic deployment and consistency verification of the entire vehicle's functional configuration, and effectively improve the maintainability, flexibility and reliability of vehicle software under SOA architecture.

[0004] The solution to the technical problem of this invention is: This invention provides a SOA-based region controller configuration method, applied to a vehicle electronic and electrical architecture including a central computing unit and multiple intelligent region controllers, the method comprising: One of the central computing unit or the plurality of intelligent area controllers shall be designated as the master controller; The main controller maintains a unified configuration code table, which contains information on the vehicle's hardware equipment and the deployment information of software components. The software components are functional application modules that can be independently developed, deployed, and started / stopped under a service-oriented architecture. The main controller issues configuration instructions to the other intelligent area controllers according to the unified configuration code table. The configuration instructions are used to instruct each subordinate area controller to load the corresponding hardware configuration parameters and set the enable state of the corresponding software components. Each subordinate area controller activates or disables the corresponding software components and controls the working status of associated hardware devices based on the received configuration instructions.

[0005] Furthermore, the unified configuration code table includes a software component identifier, a deployment target controller identifier, and an enable status bit; the main controller sends the configuration instructions of the corresponding software component to the designated subordinate area controller according to the deployment target controller identifier, so that the same software component can be dynamically deployed in different intelligent area controllers according to vehicle model configuration or user needs.

[0006] Furthermore, when a fault is detected in the main controller, a preset intelligent area controller automatically takes over the main controller function of the main controller.

[0007] Furthermore, the main controller will synchronize the updated unified configuration code table to each subordinate area controller after any of the following events occur: vehicle power-on initialization is completed, OTA remote upgrade is completed, or a user function subscription request is received.

[0008] Furthermore, each subordinate area controller periodically or event-triggeredly reports its currently active software component list and associated hardware status to the main controller during operation. The main controller performs configuration consistency verification based on the reported information and generates a remote diagnostic report.

[0009] Furthermore, the software components include service-oriented functional modules from the power domain, chassis domain, body domain, or intelligent driving domain, and the deployment location and enabling status of the software components are uniformly managed by the unified configuration code table, supporting dynamic migration across regional controllers.

[0010] On the other hand, this application provides an SOA-based area controller configuration system, including a central computing unit and multiple intelligent area controllers; One of the central computing unit or the plurality of intelligent area controllers is designated as the master controller, and the remaining intelligent area controllers are configured as subordinate area controllers. The main controller is configured to: maintain a unified configuration code table, which contains information on the vehicle's hardware equipment and the deployment information of software components, wherein the software components are functional application modules that can be independently developed, deployed, and started / stopped under a service-oriented architecture; and issue configuration instructions to each subordinate area controller to instruct it to load the corresponding hardware configuration parameters and set the enabling status of the corresponding software components. Each subordinate area controller is configured to activate or disable the corresponding software components and control the working status of associated hardware devices according to the received configuration instructions.

[0011] Furthermore, when a fault is detected in the main controller, a preset intelligent area controller automatically takes over the main controller function of the main controller.

[0012] On the other hand, this application provides a vehicle including the aforementioned SOA-based regional controller configuration system.

[0013] On the other hand, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the aforementioned SOA-based area controller configuration method.

[0014] The beneficial effects of this invention are as follows: This application provides a SOA-based regional controller configuration method. This method introduces a master controller in the vehicle's SOA electrical and electronic architecture to centrally maintain a unified configuration code table and actively issue configuration commands to each subordinate regional controller, achieving single-source trusted management and coordinated, consistent deployment of the vehicle's hardware and software configuration. This method effectively solves the problems of inconsistent multi-controller configurations, difficulty in traceability, and complex maintenance caused by traditional distributed configuration. It not only supports dynamic enabling / disabling of software components according to vehicle model or user needs and cross-regional deployment, but also significantly improves system integration efficiency, OTA upgrade reliability, and diagnostic accuracy. Thus, while ensuring functional safety, it enhances the flexibility, scalability, and maintainability of the software-defined vehicle architecture. This application also provides corresponding systems, vehicles, and media. The beneficial effects of the systems, vehicles, and media are the same as those of the above method and will not be elaborated upon 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 SOA-based region controller configuration method provided in this application; Figure 2 This is a structural diagram of the SOA-based regional controller configuration system 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 rapid development of intelligent, connected, and electrified vehicles, traditional distributed electrical and electronic architectures (EEA) are struggling to meet the increasing functional complexity, software iteration speed, and personalized user needs. The industry is accelerating its evolution towards a new generation of centralized electrical and electronic architectures with "centralized computing + regional control," and is widely adopting service-oriented architecture (SOA) to achieve hardware and software decoupling, functional service-based architecture, and software-defined vehicles (SDV).

[0023] Under this architecture, vehicle functions are no longer implemented by fixed ECUs (Electronic Control Units) through hard coding. Instead, they consist of hundreds or even thousands of independently developable, deployable, and start-stop software components (SWCs or Apps). These software components can be flexibly deployed in the Central Compute Unit or multiple Zone Controllers, depending on the vehicle platform, hardware configuration, or user subscription. For example, an "automatic parking" function might be completed collaboratively by a perception algorithm deployed in the intelligent driving zone controller, decision-making logic running in the central computing unit, and execution commands sent to the chassis zone controllers.

[0024] While this highly flexible architecture improves development efficiency and user experience, it also brings unprecedented configuration management challenges: How to ensure that all controllers on the same vehicle agree on key information such as "which hardware is present," "which software should be enabled," and "where the software is deployed"? How to avoid functional failures, security risks, or diagnostic difficulties caused by inconsistent configurations? Therefore, there is an urgent need for a unified, reliable, and traceable vehicle configuration management mechanism that can support the characteristics of SOA architecture.

[0025] Currently, vehicle configuration management primarily employs two technical solutions: First, a distributed function configuration based on external tools. During vehicle production or after-sales service, diagnostic equipment writes enable / disable flags to each regional controller. Each controller has all pre-configured function modules but is only activated according to the configuration. The configuration content is limited to function switches, and the software-controller binding relationship is fixed. Second, an FPGA-based transparent regional controller architecture simplifies the regional hardware through programmable logic devices, only implementing sensor data transmission and command forwarding. All decisions are made by the central computing unit, but this solution involves no software configuration or deployment management. Furthermore, in engineering practice, methods relying on static DBC / LDF files or vehicle configuration codes also exist. However, these methods solidify the mapping relationship during the development phase and cannot support later user selection or dynamic software migration.

[0026] The aforementioned existing technologies reveal several shortcomings in the context of SOA and software-defined vehicles: First, configuration sources are scattered across multiple controllers, lacking a unified and reliable benchmark for the entire vehicle, which easily leads to inconsistencies in configuration between multiple controllers; second, the configuration granularity is limited to function-level switches, failing to express the core SOA requirement of "which controller the software component is deployed on," making it difficult to support dynamic migration of software across regions; third, configuration updates rely on external tool intervention and cannot be automatically synchronized during OTA upgrades or runtime, resulting in poor system coordination; furthermore, the lack of feedback and consistency verification mechanisms for configuration execution status leads to difficulties in fault diagnosis and low efficiency in remote operation and maintenance; finally, the traditional configuration code structure is rigid, requiring the reconstruction of coding rules and the upgrading of multiple controller software for new functions, resulting in poor scalability and difficulty in adapting to the rapidly iterating software ecosystem.

[0027] To address the aforementioned issues, this application proposes a region controller configuration method, system, vehicle, and medium based on an SOA architecture. Its main technical features are as follows: In an electronic and electrical architecture comprised of a central computing unit and multiple intelligent region controllers, a master controller (which can be the central computing unit or a specific region controller) is designated to centrally maintain a unified configuration code table covering vehicle hardware equipment information and software component deployment information. This configuration code table not only includes the enabling status of software components but also specifies their target deployment locations, supporting the dynamic allocation of the same software component to different region controllers based on vehicle model or user needs. The master controller proactively issues configuration instructions to each subordinate region controller, guiding them to load hardware parameters and activate corresponding software functions. Simultaneously, it receives operational status feedback to achieve configuration consistency verification and remote diagnostics, thereby constructing a full lifecycle configuration governance system of "unique configuration source—proactive distribution—closed-loop verification," effectively solving the key challenges of fragmented, untraceable, and difficult-to-coordinate hardware and software configurations under the SOA architecture.

[0028] First, the SOA-based region controller configuration method provided in this application will be described in detail below with reference to the accompanying drawings. This method is applied to a vehicle electronic and electrical architecture including a central computing unit and multiple intelligent region controllers. The central computing unit, as the core of vehicle control and decision-making, is responsible for high-level function fusion and service scheduling. Multiple intelligent region controllers are distributed according to physical regions (e.g., front compartment, left / right cockpit, rear), each managing sensors, actuators, and local functional modules within its respective region. In this architecture, software functions exist as service-oriented components (SWC / APP) and can be flexibly deployed on the central or any region controller. This application introduces a master controller role into this architecture to uniformly maintain and distribute the vehicle's hardware and software configuration information, achieving centralized control and dynamic configuration of distributed software components, and providing a reliable, consistent, and scalable configuration foundation for software-defined vehicles.

[0029] Reference Figure 1 The implementation process of the SOA-based region controller configuration method provided in this application includes, but is not limited to, the following steps.

[0030] Step S110: Designate one of the central computing unit or multiple intelligent area controllers as the master controller.

[0031] In step S110, a single responsible entity for configuration management within the entire vehicle's electronic and electrical architecture is established. This is achieved by designating one of the central computing unit or multiple intelligent area controllers as the master controller, providing a logical center for the unified maintenance and distribution of configuration information, thus avoiding conflicts and inconsistencies caused by multi-point configuration. This master controller can be a default designated area controller or dynamically selected based on system policies. Its core significance lies in constructing a "one master, multiple slaves" configuration collaborative topology, laying the organizational foundation for centralized governance of the entire vehicle's configuration.

[0032] Furthermore, when a specific intelligent area controller is designated as the main controller, the central computing unit is a managed node within the configuration system. It must obey the configuration instructions of the main controller while continuing to perform its core function as the vehicle service scheduling center. The two entities work collaboratively, with their responsibilities separated, to jointly support a flexible, reliable, and scalable vehicle software ecosystem under the SOA architecture.

[0033] Step S120: The main controller maintains a unified configuration code table.

[0034] The unified configuration code table includes information on the vehicle's hardware equipment and the deployment information of software components. The software components are functional application modules that can be independently developed, deployed, and started / stopped under a service-oriented architecture.

[0035] In step S120, a single trusted data source covering the entire vehicle's hardware and software status is established. This unified configuration code table maintained by the main controller not only records the actual hardware equipment list installed in the vehicle (such as whether an electric tailgate or seat heating module exists), but also defines in detail the deployment goals and operating strategies of each software component. In particular, these software components, as functional application modules under the SOA architecture, possess the characteristics of independent development, flexible deployment, and on-demand start / stop. By integrating hardware and software configuration information into the same table, a unified hardware and software configuration expression is achieved, providing a complete basis for subsequent accurate issuance of configuration commands.

[0036] In step S130, the main controller sends configuration instructions to the other intelligent area controllers according to the unified configuration code table. The configuration instructions are used to instruct each subordinate area controller to load the corresponding hardware configuration parameters and set the enable status of the corresponding software components.

[0037] In step S130, the static configuration information in the unified configuration code table is converted into executable control commands and actively pushed to each subordinate area controller. After parsing the configuration code table, the master controller generates a unique configuration instruction for each subordinate area controller, explicitly informing it which hardware-related configuration parameters (such as I / O mapping, driver parameters, etc.) should be loaded, and which locally deployed software components should be enabled or disabled. This proactive distribution mechanism replaces the traditional method of relying on external tools or passive reading, ensuring that configuration information can be delivered to the target node in a timely, accurate, and targeted manner. It is a key execution step for achieving centralized configuration management and control.

[0038] In step S140, each slave area controller activates or disables the corresponding software components and controls the working status of the associated hardware devices according to the received configuration instructions.

[0039] In step S140, the configuration instructions are actually executed on the terminal nodes. After receiving the configuration instructions from the master controller, each slave area controller adjusts its local software environment according to the instructions—activating enabled software components and disabling disabled components; simultaneously, it initializes or switches the operating modes of relevant hardware devices (such as relays, motor drives, and sensor interfaces) according to hardware configuration parameters. This process directly determines whether the vehicle functions are available and their behavior, and is the final step in the entire configuration method from "planning" to "implementation," ensuring that the overall vehicle functional status is strictly consistent with the unified configuration code table.

[0040] In some embodiments of this application, the unified configuration code table includes a software component identifier, a deployment target controller identifier, and an enable status bit. First, the software component identifier is used to uniquely identify a service-oriented functional module (such as "seat memory APP" or "charging port cover control SWC"), ensuring that the configuration object is clear and unambiguous. Second, the deployment target controller identifier clearly specifies which specific intelligent area controller (e.g., VIU-ML, VIU-R, or central computing unit) the software component should actually run on, thereby mapping abstract functional requirements to physical execution nodes. Finally, the enable status bit controls whether the component is activated on the target controller, enabling on-demand start and stop.

[0041] The combination of these three elements enables the unified configuration code table to not only record "whether a certain function exists," but also to accurately express the core deployment semantics under the SOA architecture: "who executes this function and whether it is currently enabled." Based on this, the master controller can accurately send configuration commands to the designated slave area controllers according to the deployment target controller identifier, instead of broadcasting them to all nodes. This improves communication efficiency and avoids the risk of irrelevant controllers misprocessing configuration information.

[0042] In some embodiments of this application, the main controller sends configuration instructions for the corresponding software component to the designated subordinate area controller according to the deployment target controller identifier, so that the same software component can be dynamically deployed in different intelligent area controllers according to vehicle model configuration or user needs.

[0043] Specifically, the above settings allow the same software component to be dynamically deployed in different intelligent area controllers based on different vehicle configurations (e.g., high-end / low-end) or user-personalized subscriptions (e.g., paying for a service). For example, a "rear window defroster" function might be deployed in the rear area controller (VIU-R) in a high-end model, while in a mid-range model where the rear controller is removed, it can be redeployed to the left cabin area controller (VIU-ML). This flexibility in deployment location requires no modification to the software code or hardware platform; it can be achieved simply by adjusting the "deployment target controller identifier" in the unified configuration code table. This truly embodies the core concepts of software-hardware decoupling and software-defined vehicles, significantly improving the versatility, scalability, and development efficiency of the electronic and electrical architecture.

[0044] In some embodiments of this application, when a fault is detected in the main controller, a preset intelligent area controller automatically takes over the main controller function.

[0045] Specifically, a fault-tolerance and automatic switching mechanism for the main controller function is introduced: when the system detects a failure in the main controller (such as communication interruption, software crash, or hardware failure), a pre-configured intelligent area controller (such as the front cabin or cockpit area controller) can automatically take over all the functions of the main controller, including continuing to maintain the unified configuration code table, issuing configuration commands to other subordinate controllers, and receiving status feedback. This mechanism ensures that even in the extreme case of main controller failure, the vehicle's configuration management system can still maintain basic operation, preventing the loss of the main controller from causing chaos in the vehicle's functional configuration, loss of control of software components, or malfunction of critical hardware.

[0046] The aforementioned settings effectively enhance the availability, robustness, and functional safety level of the entire configuration system. In traditional solutions, if the main controller node fails, the distributed regional controllers often operate independently, unable to synchronously update or verify the configuration status, which can easily lead to functional abnormalities or even security risks. This application, however, achieves seamless migration of the main controller role through a pre-defined takeover strategy, ensuring the orderly operation of the distributed software system under SOA architecture in abnormal conditions, especially meeting the stringent requirements of high-level intelligent electric vehicles for high reliability and fault degradation capabilities. Furthermore, this mechanism requires no manual intervention or external tools, being entirely autonomously completed by the onboard system, demonstrating a high degree of intelligence and self-healing capability.

[0047] In some embodiments of this application, the main controller synchronizes the updated unified configuration code table to each subordinate area controller after any of the following events occur: vehicle power-on initialization is completed, OTA remote upgrade is completed, or a user function subscription request is received.

[0048] In some embodiments of this application, each subordinate area controller periodically or event-triggeredly reports its currently active software component list and associated hardware status to the main controller during operation. The main controller performs configuration consistency verification based on the reported information and generates a remote diagnostic report.

[0049] Specifically, traditional configuration methods typically end the process after issuing commands, failing to verify whether the slave controller has correctly loaded and activated the target software components, or whether the hardware devices have responded as expected. This solution, however, requires each slave area controller to proactively report its actual operating status during operation—including a list of currently activated software components (such as SWC_ID, version number, and operating status) and the working status of associated hardware (such as relay on / off status, motor current, and sensor online status). This reporting can be done through periodic polling (e.g., every 10 seconds) or event-triggered reporting (e.g., immediate reporting upon software start / stop, hardware failure, or configuration change), balancing real-time performance with communication load balancing.

[0050] Secondly, the main controller performs configuration consistency verification based on this reported information, which is a crucial step in ensuring system reliability. The main controller compares its maintained unified configuration code table (i.e., the "expected state") with the actual operating states reported by each subordinate controller (i.e., the "actual state") to determine if there are any discrepancies. For example, a software component may be set to "enabled" in the configuration table but not appear in the reported list; or a hardware device may be reported as abnormally powered on when it should be in a disabled state. Once an inconsistency is detected, the main controller can immediately trigger reconfiguration, alarm, or security degradation strategies to prevent functional failures or security vulnerabilities caused by configuration drift or execution failures.

[0051] Finally, the main controller generates a remote diagnostic report, which structurally encapsulates information such as configuration status, deviation records, and hardware health, making it available for use by the cloud platform, after-sales system, or user app. This not only greatly enhances the vehicle's remote diagnostic and predictive maintenance capabilities but also provides precise data support for scenarios such as OTA upgrade verification, user function subscription verification, and root cause analysis. For example, after an OTA update pushes a new feature, the diagnostic report can confirm that all relevant regional controllers have successfully deployed and enabled the new software component, without relying on user feedback or in-store inspection.

[0052] In summary, the above settings, by constructing a complete closed loop of "deployment-execution-feedback-verification-diagnosis", extend configuration management from the static initialization stage to the entire lifecycle operation stage, significantly enhancing the observability, controllability, and maintainability of distributed systems under the SOA architecture. This is an indispensable technical pillar for realizing highly reliable software-defined vehicles.

[0053] In some embodiments of this application, software components include service-oriented functional modules from the powertrain domain, chassis domain, body domain, or intelligent driving domain. The deployment location and enabling state of these software components are uniformly managed by a unified configuration code table, supporting dynamic migration across regional controllers and breaking the strong binding between functions and physical controllers in traditional automotive electronic architectures. These software logics, originally belonging to specific functional domains, are abstracted into service units that can be independently developed, deployed, and started / stopped, no longer limited by fixed hardware carriers. By unifying the functions of each domain into a service-oriented system, the vehicle software architecture achieves true software-hardware decoupling, providing a foundation for flexible combination of functions and cross-domain collaboration.

[0054] More importantly, the deployment location (i.e., which controller it runs on) and enabling status (enabled or disabled) of these software components are centrally managed by a unified configuration code table, supporting dynamic migration between different intelligent area controllers based on vehicle configuration, hardware resources, or user needs. For example, the same functional module can be deployed in the central computing unit in a high-end model to utilize its computing power, while in a low-end model it can be migrated to an area controller; when users subscribe to new features later, the software can also be remotely activated and its location reassigned by updating the configuration code table. This dynamic deployment mechanism driven by unified configuration, without modifying code or replacing hardware, significantly improves platform versatility, development efficiency, and user experience, and is a key path for implementing the software-defined vehicle concept.

[0055] Secondly, refer to Figure 2 This application provides an SOA-based area controller configuration system, including a central computing unit and multiple intelligent area controllers. The system uses a central computing unit as its core, connected to multiple intelligent area controllers (such as controllers 1, 2 to N) via high-speed communication. Each intelligent area controller manages its corresponding sensors, actuators, and controllers, achieving local control within its area. This architecture separates global decision-making from area execution, improving the system's flexibility, scalability, and reliability.

[0056] As the core computing platform of the vehicle's electronic and electrical architecture, the central computing unit undertakes tasks such as high-level function integration, service scheduling, and global decision-making. In the configuration system of this application, it works in collaboration with the intelligent area controller to provide powerful computing support and a global perspective for unified configuration management, and is a key hardware foundation for realizing a centralized software-defined vehicle architecture.

[0057] One of the central computing unit or multiple intelligent area controllers is designated as the master controller, and the remaining intelligent area controllers are configured as slave area controllers. These multiple intelligent area controllers are distributed according to the vehicle's physical areas (e.g., front compartment, left / right cabin, rear), and are responsible for managing the connection and control of sensors, actuators, and local functional modules within their respective areas. They constitute a network of execution terminals for configuration commands, capable of receiving and executing configurations as slave nodes, and also assuming the role of master controller under specific conditions, providing the system with distributed control capabilities and regional autonomy.

[0058] The main controller is configured to maintain a unified configuration code table, which contains information on the vehicle's hardware and the deployment of software components. These software components are functional application modules that can be independently developed, deployed, and started / stopped under a service-oriented architecture. It also issues configuration commands to each subordinate regional controller, instructing them to load the corresponding hardware configuration parameters and set the enabling status of the relevant software components. By centrally managing the configuration source and leading the distribution process, the main controller ensures the consistency, traceability, and dynamic adjustability of the vehicle's hardware and software configurations, serving as the "sole trusted source" and coordination hub of the entire configuration system.

[0059] Each subordinate area controller is configured to activate or disable the corresponding software components and control the working status of associated hardware devices according to the received configuration instructions.

[0060] Slave area controllers are intelligent area controllers other than the master controller. Their function is to receive configuration commands from the master controller and activate or disable locally deployed software components accordingly, while controlling the working status of associated hardware devices. As the final executor of configuration policies, slave area controllers transform abstract configuration information into concrete functional behaviors, ensuring that the actual operating status of the vehicle is strictly aligned with the unified configuration code table, achieving precise implementation from configuration to function.

[0061] In some embodiments of this application, when a fault is detected in the main controller, a preset intelligent area controller automatically takes over the main controller function.

[0062] Specifically, when a failure of the main controller is detected, the system can automatically take over the main controller's functions through a preset intelligent area controller, seamlessly continuing key tasks such as maintaining the unified configuration code table, distributing configuration commands, and monitoring status. This ensures the consistency of the vehicle's configuration and the orderly operation of its functions even in the extreme case of the main controller node failure, significantly enhancing the fault tolerance, availability, and functional safety of the entire configuration system.

[0063] Furthermore, embodiments of this application provide a vehicle including the aforementioned SOA-based regional controller configuration system.

[0064] Furthermore, embodiments of this application provide a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the aforementioned SOA-based region controller configuration method.

[0065] In summary, the SOA-based regional controller configuration method, system, vehicle, and medium provided in this application have the following technical effects.

[0066] This application embodiment establishes a master controller within the vehicle's electronic and electrical architecture, which centrally maintains a unified configuration code table covering the deployment information of all vehicle hardware and software components. This achieves single-source, trusted management of all vehicle configuration information, fundamentally solving the problems of dispersed configurations, inconsistent rules, and difficulty in coordination among multiple controllers in traditional solutions. The master controller proactively issues configuration commands to subordinate regional controllers, supporting dynamic deployment and on-demand start / stop of software components across regions based on vehicle model or user needs. This significantly improves the flexibility and platform versatility of software-defined functions under the SOA architecture. Simultaneously, through status reporting from subordinate controllers and configuration consistency verification by the master controller, a closed-loop configuration governance system of "issue-execution-feedback-diagnosis" is constructed, effectively ensuring the accuracy of function activation and the reliability of system operation. Furthermore, the master controller supports automatic takeover by preset regional controllers in the event of a central computing unit failure, further enhancing the system's high availability and functional safety level. Overall, this solution significantly reduces the development and maintenance costs of multiple vehicle models, improves OTA upgrade efficiency and remote diagnostic capabilities, and provides a solid, scalable, and highly reliable configuration management foundation for software-defined vehicles.

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

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

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

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

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

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

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

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

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

[0076] 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 method for configuring a region controller based on SOA, characterized in that, The method, applied to a vehicle electronic and electrical architecture including a central computing unit and multiple intelligent regional controllers, comprises: One of the central computing unit or the plurality of intelligent area controllers shall be designated as the master controller; The main controller maintains a unified configuration code table, which contains information on the vehicle's hardware equipment and the deployment information of software components. The software components are functional application modules that can be independently developed, deployed, and started / stopped under a service-oriented architecture. The main controller issues configuration instructions to the other intelligent area controllers according to the unified configuration code table. The configuration instructions are used to instruct each subordinate area controller to load the corresponding hardware configuration parameters and set the enable state of the corresponding software components. Each subordinate area controller activates or disables the corresponding software components and controls the working status of associated hardware devices based on the received configuration instructions.

2. The SOA-based region controller configuration method according to claim 1, characterized in that, The unified configuration code table includes a software component identifier, a deployment target controller identifier, and an enable status bit. The main controller sends the configuration instructions of the corresponding software component to the designated subordinate area controller according to the deployment target controller identifier, so that the same software component can be dynamically deployed in different intelligent area controllers according to vehicle model configuration or user needs.

3. The SOA-based region controller configuration method according to claim 1, characterized in that, When a fault is detected in the main controller, a preset intelligent area controller automatically takes over the main controller function.

4. The SOA-based region controller configuration method according to claim 1, characterized in that, The main controller will synchronize the updated unified configuration code table to each subordinate area controller after any of the following events occur: vehicle power-on initialization is completed, OTA remote upgrade is completed, or a user function subscription request is received.

5. The SOA-based region controller configuration method according to claim 1, characterized in that, During operation, each subordinate area controller periodically or event-triggeredly reports its currently active software component list and associated hardware status to the main controller. The main controller performs configuration consistency verification based on the reported information and generates a remote diagnostic report.

6. The SOA-based region controller configuration method according to claim 1, characterized in that, The software components include service-oriented functional modules from the power domain, chassis domain, body domain, or intelligent driving domain, and the deployment location and enabling status of the software components are uniformly managed by the unified configuration code table, supporting dynamic migration across regional controllers.

7. A SOA-based regional controller configuration system, characterized in that, Includes a central computing unit and multiple intelligent area controllers; One of the central computing unit or the plurality of intelligent area controllers is designated as the master controller, and the remaining intelligent area controllers are configured as subordinate area controllers. The main controller is configured to: maintain a unified configuration code table, which contains information on the vehicle's hardware equipment and the deployment information of software components, wherein the software components are functional application modules that can be independently developed, deployed, and started / stopped under a service-oriented architecture; and issue configuration instructions to each subordinate area controller to instruct it to load the corresponding hardware configuration parameters and set the enabling status of the corresponding software components. Each subordinate area controller is configured to activate or disable the corresponding software components and control the working status of associated hardware devices according to the received configuration instructions.

8. The SOA-based regional controller configuration system according to claim 7, characterized in that, When a fault is detected in the main controller, a preset intelligent area controller automatically takes over the main controller function.

9. A vehicle, characterized in that, Includes the SOA-based regional controller configuration system as described in claim 7 or 8.

10. A computer-readable storage medium having a computer program stored thereon, the computer program, when executed by a processor, implementing the SOA-based region controller configuration method as described in any one of claims 1 to 6.

Images