Power domain control software architecture and controller thereof

Abstract

The invention provides a power domain control software architecture and a controller thereof, the software architecture comprises an application layer developed based on an AUTOSAR standard, a runtime environment and a basic software layer, the application layer comprises a plurality of modularized software components, the software components package service logic functions of the controller to be integrated, the software components are provided with an AUTOSAR-based ARXML file definition interface, and the AUTOSAR-based ARXML file definition interface is used for defining the service logic functions of the controller to be integrated. According to the method, the interface compatibility can be improved, seamless integration of application layers across controllers can be realized, and the development parallelism is enhanced by kernel deployment of independently packaged software components according to the real-time performance of functions. The runtime environment generates an inter-core communication agent code, constructs a virtual bus and routes a service request of an application layer component to the basic software layer, and the basic software layer provides system-level service for the application layer through a virtual bus interface of the runtime environment, so that the application layer does not need to directly operate hardware, software and hardware decoupling is realized, and the service performance of the application layer is improved. And smooth realization of software fusion and integration is promoted.

Description

Technical Field

[0001] This specification relates to the field of domain controller technology, and in particular to a power domain control software architecture and its controller. Background Art

[0002] With the rapid development of the automotive industry toward intelligent and integrated features, vehicle electronic and electrical architectures continue to evolve, while the need to reduce vehicle costs and weight is becoming increasingly urgent. Against this backdrop, domain controller technology, with its efficient hardware integration capabilities, has gradually become the mainstream technology for automotive control systems. Numerous automotive OEMs and controller suppliers are increasing their investment in domain controller research and development. While domain controllers achieve hardware integration, software integration has also become a key step.

[0003] However, existing in-vehicle software architectures and technologies, when applied to power domain controllers (controllers that integrate at least two controllers, such as the VCU, BMS, and MCU, into a single piece of hardware), present numerous challenges that require urgent resolution. At the architectural design level, the existing discrete software architecture design concept is limited to the functional division of a single module and lacks support for the functional division and layout of multiple modules, making it difficult to meet the requirements for integrated power domain controller functionality. Furthermore, at the architectural compatibility level, each module in the discrete software architecture has its own corresponding software architecture. This makes software fusion and integration difficult due to compatibility issues between architectures.

[0004] These problems seriously restrict the performance improvement and function expansion of power domain controllers, and new technical solutions are urgently needed to solve them. Summary of the Invention

[0005] To overcome the problems existing in the related art, this specification provides a power domain control software architecture and its controller.

[0006] According to a first aspect of an embodiment of this specification, a power domain control software architecture is provided, wherein the software architecture includes an application layer, a runtime environment, and a basic software layer developed based on the AUTOSAR standard:

[0007] The application layer includes multiple modular software components, which define standardized interfaces based on the AUTOSAR ARXML configuration file, encapsulate the business logic functions of the controller to be integrated, and are deployed on different cores of the multi-core CPU;

[0008] The runtime environment generates a communication proxy code corresponding to the standardized interface based on the ARXML configuration file, constructs a virtual bus interaction interface for routing service requests of application layer components to the basic software layer, and distributes data responses of the basic software layer to application layer components;

[0009] The basic software layer is used to encapsulate hardware drivers and provide system-level services to the application layer through the virtual bus interface of the runtime environment.

[0010] According to a power domain control software architecture provided in this specification, the basic software layer includes a microcontroller abstraction layer;

[0011] The general function modules of the basic software layer are deployed on the main core of the multi-core CPU;

[0012] The complex drivers in the microcontroller abstraction layer are deployed on the same slave core as the corresponding software components based on functional similarity.

[0013] According to a power domain control software architecture provided in this specification, the CAN signal types defined by the ARXML file in the multi-core CPU include common signals and dedicated signals, and the inter-core communication adopts a core-split peak-shifting concurrent mechanism to send the CAN signal;

[0014] The master core is used to send signals corresponding to the software components on the master core and the common signals of the software components; the slave core is used to send the dedicated signals independently generated by the software components on the slave core.

[0015] According to a power domain control software architecture provided in this specification, the core-split peak-staggered concurrency mechanism includes:

[0016] The master core monitors the load of each slave core and dynamically adjusts the time window for the slave core to send signals, and the slave cores send signals in sequence according to the time window;

[0017] Among them, the higher the load, the longer the allocated sending time window.

[0018] According to a power domain control software architecture provided in this specification, the physical memory of the multi-core CPU has a shared memory area, the shared memory area is configured with global variables for storing cross-core data, and each core of the multi-core CPU can read and write the data in the shared memory area.

[0019] According to a power domain control software architecture provided in this specification, the inter-core communication includes:

[0020] After the core sending data writes the data to the shared memory area, an inter-core interrupt is triggered, and a read notification is sent to the core receiving the data;

[0021] The kernel controlling the receiving data responds to the read notification and reads the data in the shared memory area.

[0022] According to a power domain control software architecture provided in this specification, controlling the kernel receiving data to respond to the read notification and read the data in the shared memory area includes:

[0023] When multiple cores write data to the shared memory area simultaneously, controlling the core receiving the data to respond to the read notification according to the priority order of the inter-core interrupt;

[0024] The priority of the inter-core interrupt is dynamically adjusted according to the real-time requirements of the software component on the core sending the data.

[0025] According to a power domain control software architecture provided in this specification, the number of controllers to be integrated is determined according to the number of cores of the multi-core CPU.

[0026] According to the second aspect of the embodiments of this specification, a microcontroller unit is provided, including a microcontroller with a multi-core architecture and a power domain control software architecture as described in any of the above items. The microcontroller is connected to the microcontroller abstraction layer in the power domain control software architecture, and hardware is driven through the microcontroller abstraction layer for power domain control function integration.

[0027] According to a third aspect of the embodiments of this specification, a power domain controller is provided, comprising the microcontroller unit as described above.

[0028] According to a fourth aspect of the embodiments of this specification, a device is provided, including:

[0029] It includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements any of the power domain control software architectures described above.

[0030] According to a fifth aspect of the embodiments of this specification, a computer-readable storage medium is provided, including:

[0031] When the computer program is executed by a processor, it implements any of the power domain control software architectures described above.

[0032] The technical solutions provided by the embodiments of this specification may have the following beneficial effects:

[0033] In the embodiments of this specification, the software architecture includes an application layer, a runtime environment, and a basic software layer developed based on the AUTOSAR standard. The application layer includes multiple modular software components. The software components encapsulate the business logic functions of the controller to be integrated and have a SWC interface defined by an ARXML file based on AUTOSAR. This not only improves interface compatibility and enables seamless integration of the application layer of controllers across suppliers, but also independently encapsulated software components are deployed on different cores according to the real-time nature of their functions, enhancing development parallelism. The runtime environment generates inter-core communication proxy code, builds a virtual bus, and routes service requests from application layer components to the basic software layer. The basic software layer provides system-level services to the application layer through the virtual bus interface of the runtime environment. In this way, the application layer does not need to directly operate the hardware, achieving hardware and software decoupling and promoting the smooth implementation of software fusion and integration.

[0034] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the specification and, together with the description, serve to explain the principles of the specification.

[0036] Figure 1 This is a schematic diagram of a power domain control software architecture according to an exemplary embodiment of this specification.

[0037] Figure 2 This is a schematic diagram of the customized software bottom layer of a power domain control software architecture shown in this specification according to an exemplary embodiment.

[0038] Figure 3 This is another schematic diagram of a power domain control software architecture shown in this specification according to an exemplary embodiment.

[0039] Figure 4 This is a schematic diagram of inter-core communication in a power domain control software architecture according to an exemplary embodiment of the present specification.

[0040] Figure 5 This is another schematic diagram of inter-core communication in a power domain control software architecture according to an exemplary embodiment of this specification.

[0041] Figure 6 This specification shows a schematic diagram of multi-core concurrency of CAN signals in a power domain control software architecture according to an exemplary embodiment.

[0042] Figure 7 This is a schematic diagram of a device according to an exemplary embodiment of the present specification. DETAILED DESCRIPTION

[0043] Exemplary embodiments will be described in detail herein, with examples illustrated in the accompanying drawings. In the following description, when referring to the drawings, identical numerals in different figures represent identical or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments are not intended to represent all embodiments consistent with this specification. Rather, they are merely examples of apparatus and methods consistent with certain aspects of this specification, as detailed in the appended claims.

[0044] The terms used in this specification are for the purpose of describing specific embodiments only and are not intended to limit this specification. As used in this specification and the appended claims, the singular forms "a," "an," "the," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and / or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.

[0045] It should be understood that although the terms first, second, third, etc. may be used in this specification to describe various information, such information should not be limited to these terms. These terms are merely used to distinguish information of the same type from one another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information without departing from the scope of this specification. Depending on the context, the term "if" as used herein may be interpreted as "when," "when," or "in response to determining."

[0046] This specification provides a method, a power domain control software architecture, a device, and a computer-readable storage medium. The following describes the embodiments of this specification in detail with reference to the accompanying drawings. The features of the following embodiments and implementations may be combined with each other unless they conflict.

[0047] Domain controller technology, thanks to its efficient hardware integration capabilities, is gradually becoming a mainstream technology for automotive control systems. Many automotive OEMs and controller suppliers are increasing their investment in domain controller research and development. While domain controller hardware integration is crucial, software integration is also a key step. Functions previously implemented by multiple software packages across multiple controllers often require a single software package within a domain controller, posing a significant challenge. In terms of architectural design, existing discrete software architectures only consider the functional divisions of a single module and are unable to support the functional division and layout of multiple modules. Regarding architectural compatibility, each module in this discrete software architecture has its own unique software architecture, resulting in inconsistent architectural approaches. This often hinders software integration and integration due to incompatibility issues. Furthermore, in terms of communication and interaction, existing discrete software architectures only consider signal transmission and reception within a single module, with communication with other modules achieved through methods such as the CAN bus. This architecture cannot support the integration of multiple modules within a single piece of hardware, which also requires internal communication between the modules within the software.

[0048] In order to solve the above technical problems, this specification provides a method for dynamic domain control software architecture.

[0049] It aims to solve the problem of software being unable to be integrated into one when discrete software evolves to domain-converged software through a standard architecture without increasing any cost.

[0050] Currently, the complexity of in-vehicle software is relatively high, and it is basically developed in a modular and cooperative manner. Therefore, each development entity often has its own set of software architecture standards. A single module is developed using a separate architecture standard. This is feasible on a discrete system, but it is not feasible to integrate software on a power domain controller due to architecture compatibility issues.

[0051] AUTOSAR (AUTomotive Open System ARchitecture) is an open automotive electronic system architecture standard. By decoupling hardware and software and standardizing interfaces, it enables modularity, reusability, and portability of automotive electronic software. Therefore, the powertrain domain control software architecture is developed based on the AUTOSAR standard. The AUTOSAR-defined development process includes requirements analysis, SWC design, system configuration, code generation, and integration testing.

[0052] like Figure 1 As shown, Figure 1 This is a schematic diagram of a power domain control software architecture according to an exemplary embodiment of this specification.

[0053] The power domain control software architecture includes an application layer ASW, a runtime environment RTE, and a basic software layer BSW.

[0054] The division and deployment of domain fusion software functions is key to the software architecture. To ensure the continuity of the division of labor among module developers, the application layer of the controller to be integrated is divided into independent modules and packaged into independent collective components according to the AUTOSAR architecture. In other words, the application layer in the software architecture described in this specification includes multiple modular software components. Software components are modular software units in the software architecture that encapsulate the business logic functions of the controller to be integrated (such as torque calculation, battery management, etc.) and communicate with the underlying layer through standardized interfaces.

[0055] As an example, the controllers to be integrated refer to multiple controllers for fusion, which can be, but are not limited to, VCU, MCU, BMS, etc. It can be understood that the VCU, MCU, and BMS module application layer (ASW) in the original discrete system is further divided into independent modules and packaged into three composition components (Composition SWC) according to the AUTOSAR architecture, namely SWC_VCU, SWC_MCU, and SWC_BMS.

[0056] Each software component defines a standardized interface based on the AUTOSAR ARXML configuration file, unifying the interfaces between software components and layers, eliminating architectural differences between modules, and thus achieving seamless integration.

[0057] The Runtime Environment (RTE) is used to connect the application layer with the underlying basic communication framework and is responsible for data interaction between components. Based on the ARXML configuration file, the communication agent code corresponding to the standardized interface of each software component is generated, and a virtual bus abstraction is provided to shield the underlying hardware differences. In this way, the application layer can only rely on the virtual services provided by the RTE, without directly operating the hardware, to implement communication agents between SWCs and between SWCs and BSWs, and to achieve interface standardization. During the interaction process, the virtual bus interaction interface is used to route the service requests of the application layer components to the basic software layer, and distribute the data responses of the basic software layer to the application layer components. For example, the UTOSAR interface (such as Sender-Receiver) defines input and output, such as the RPort_BatteryStatus of SWC_VCU to receive battery data from the BMS.

[0058] The basic software layer encapsulates hardware drivers and provides system-level services to the application layer via the runtime environment's virtual bus interface. Software components in the application layer indirectly invoke services in the basic software layer via the runtime environment's virtual bus interface. Data generated by the basic software layer is transmitted to the upper layer via the runtime environment's interface, enabling information exchange between the application layer and the basic software layer.

[0059] In some embodiments, the basic software layer includes a services layer, an ECU abstraction layer, and a microcontroller abstraction layer (MCAL). The services layer provides system-level services (such as diagnostics, communication, and encryption); the ECU abstraction layer creates standardized ECU hardware interfaces (such as CAN, LIN, and ADC); and the MCAL layer directly drives hardware (such as GPIO, PWM, and ADC drivers). Through the MCAL and ECU abstraction layer, software is decoupled from the chip / hardware.

[0060] The current standard AUTOSAR underlying architecture, although it has the advantages of modularity and standardization, also has interdependencies between modules. This will result in some modules not being able to be developed in parallel during the underlying software development process, and the next module can only be developed after the previous module is completed. Therefore, in addition to the MCAL part adopting the standard AUTOSAR design, this solution also designs customized OS and BSW solutions. Figure 2 As shown, Figure 2 This specification shows a customized software bottom-level diagram of a power domain control software architecture according to an exemplary embodiment, which realizes the decoupling between standard AUTOSAR modules and the parallel development of each bottom-level module. Customized C-BSW includes service interface abstraction: splitting the functions of standard BSW modules (such as COM, DCM) into independent service interfaces. It also includes a lightweight communication layer for setting shared memory areas, as well as ARXML interface definitions. Through the static scheduling and inter-core interrupt optimization of the customized operating system (C-OS), as well as the module decoupling and lightweight communication layer design of the customized basic software (C-BSW), the periodic and stable execution of hardware tasks is ensured, and parallel development is promoted. Through hardware acceleration, interface abstraction and tool chain automation, a solid foundation is provided for the efficient integration of power domain control software. This part will be explained in detail later.

[0061] like Figure 3 As shown, Figure 3 This is another schematic diagram of a power domain control software architecture shown in this specification according to an exemplary embodiment.

[0062] In some embodiments, multiple control software components are integrated into a single software package and deployed on a single CPU. To ensure the continuity of developer work, different software components are deployed on different cores of a multi-core CPU. For example, after defining the interface using ARXML, Team A can develop SWC_VCU and Team B can develop SWC_MCU, requiring only a final integration verification.

[0063] Compared with the traditional solution, in which the VCU, MCU, and BMS run on independent ECUs, with each ECU occupying a single-core MCU, this integration reduces the number of CPUs and reduces the software that needs to be developed and maintained from multiple to one, significantly improving costs and efficiency and reducing development conflicts.

[0064] It should be noted that the number of cores in a multi-core CPU determines the number of controllers to be integrated.

[0065] Furthermore, the common functional modules of the basic software layer are deployed on the master core of the multi-core CPU. These common functional modules include, but are not limited to, CAN drivers, diagnostic services, and OS scheduling, responsible for hardware resource management and cross-core coordination. Complex drivers in the MCAL layer are deployed on the same slave core as corresponding software components based on functional similarity. This includes, but is not limited to, running power domain software and motor control algorithms.

[0066] In some embodiments, due to the adoption of the AUTOSAR architecture and split-core layout, multiple components communicate with each other and with the underlying layer through the RTE layer.

[0067] like Figure 4 As shown, Figure 4 This is a schematic diagram of inter-core communication in a power domain control software architecture according to an exemplary embodiment of the present specification.

[0068] For example, a multi-core MCU is used, the main core (Core 0) runs BSW, and the other cores run SWC software components, and the cores interact through RTE. In the AUTOSAR-based power domain control architecture, the core data sent by SWC_VCU (vehicle controller software component) to SWC_MCU (motor controller software component) is the torque request value. The specific process is: the VCU calculates the torque request value according to the algorithm based on the driver input (such as accelerator pedal position), vehicle status (vehicle speed, battery power) and control strategy (such as energy management), indicating the target torque that the motor should output. It is sent to the main core BSW through RTE, and BSW forwards the request to the SWC_MCU of the slave core. After receiving the torque request, SWC_MCU calls the PWM driver of MCAL to control the motor output. At the same time, the actual torque value is fed back to the VCU through the RTE reverse interface to achieve closed-loop control.

[0069] Typically, inter-core communication uses a FIFO (File-in-First-Or-Output) approach. The sending core writes data into the FIFO buffer, and the receiving core reads data from it. The FIFO buffer's queue size is fixed, and when the data volume exceeds the buffer's capacity, multiple memory copies are required. Furthermore, under high load, the queue may become full or empty, leading to task blocking or data loss, reducing communication efficiency.

[0070] In some embodiments, as Figure 5 As shown, Figure 5 This is another schematic diagram of inter-core communication in a power domain control software architecture according to an exemplary embodiment of this specification.

[0071] A shared memory area is created within the physical memory of a multi-core CPU. This shared memory area is configured with global variables for storing cross-core data. Each core of the multi-core CPU can read and write data in this shared memory area. Global variables are used to define structures containing torque request values, timestamps, checksums, and more. In other words, the SWC_VCU, SWC_MCU, and SWC_BMS are assigned to different cores, and data exchange is coordinated through shared memory.

[0072] The specific inter-core communication process is as follows:

[0073] After the core sending data writes the data to the shared memory area, an inter-core interrupt is triggered, and a read notification is sent to the core receiving the data;

[0074] The kernel controlling the receiving data responds to the read notification and reads the data in the shared memory area.

[0075] The inter-core interrupts described in this specification are signals sent between cores to notify events or data availability.

[0076] When sending core A (CoreA) needs to send data to receiving core B (CoreB), it writes the data to a shared memory area, triggering an inter-core interrupt (IPI). Receiving core B immediately responds to the interrupt and reads the data, eliminating the need for an intermediate buffer and significantly reducing transmission latency. Furthermore, when receiving core B feeds the actual data back to the sending core, it writes the data to another shared memory area, allowing sending core A to read and perform closed-loop corrections. This achieves μs-level latency through shared memory, meeting the stringent requirements of power domain control.

[0077] In this solution, data in the shared memory area is directly read, which reduces the protocol stack overhead, making inter-core communication more direct and faster when transmitting large amounts of data, reducing the number of data copies, improving transmission efficiency, and avoiding congestion caused by multi-core competition.

[0078] Furthermore, controlling the kernel for receiving data to respond to the read notification and read the data in the shared memory area includes:

[0079] When multiple cores write data to the shared memory area simultaneously, controlling the core receiving the data to respond to the read notification according to the priority order of the inter-core interrupt;

[0080] The priority of the inter-core interrupt is dynamically adjusted according to the real-time requirements of the software component on the core sending the data.

[0081] When multiple cores write data to shared memory simultaneously, multi-core communication may encounter resource contention and latency issues. Therefore, a rule is needed to ensure orderly communication. This specification proposes a dynamic interrupt priority adjustment mechanism for shared memory communication in a multi-core system, flexibly scheduling interrupt processing and ensuring orderly communication. The priority is dynamically determined by the real-time requirements of the software component (SWC) on the core sending the data.

[0082] Specifically, multiple cores write data to shared memory at the same time, and the core receiving the data responds to the read request according to the priority order of the inter-core interrupts. This means that the system can flexibly schedule the interrupt processing order according to the urgency of the task, ensuring that high-real-time tasks (such as motor control instructions) are processed first, thereby reducing the delay of key operations and improving overall efficiency.

[0083] In a multi-module fusion software architecture, the integration of multiple control modules (such as the engine, motor, and transmission) into a single domain controller significantly increases the number of CAN signals that need to be sent out. The traditional approach of centrally processing all CAN signal transmissions on a single master core faces the following problems:

[0084] Signal congestion: A large number of signals are concentrated on a single core for processing, which can easily lead to bus arbitration conflicts and increase transmission delays. Single-core overload: The main core needs to handle signal encapsulation, protocol stack operations, and scheduling, and CPU utilization may exceed 80%, affecting real-time performance.

[0085] To solve the above problems, this solution adopts a multi-core signal staggered concurrent communication method.

[0086] like Figure 6 As shown, Figure 6 This specification shows a schematic diagram of multi-core concurrency of CAN signals in a power domain control software architecture according to an exemplary embodiment.

[0087] The core-divided and peak-staggered concurrency mechanism includes:

[0088] The master core monitors the load of each slave core and dynamically adjusts the time window for the slave core to send signals, and the slave cores send signals in sequence according to the time window;

[0089] Among them, the higher the load, the longer the allocated sending time window.

[0090] Different software components are deployed on different cores, and when communicating, the cores send corresponding signals. Specifically, in the multi-core CPU, the CAN signal types defined by the ARXML file include shared signals and dedicated signals, and the inter-core communication uses a core-by-core staggered concurrent mechanism to send the CAN signals;

[0091] The master core is used to send the signals corresponding to the software components on the master core and the common signals of each software component to ensure global synchronization. The slave core is used to send the dedicated signals independently generated by the software components on the slave core to distribute the load.

[0092] During communication, the master core sends common signals within a fixed time window (e.g., t1-t2) and coordinates the transmission timing of the slave cores. The slave cores then send dedicated signals sequentially within their assigned time windows (e.g., t3-t4, t5-t6). This avoids signal congestion and single-core overload issues that arise when multiple outgoing signals are consolidated into one core.

[0093] Furthermore, the master core monitors the load of each slave core and dynamically expands the sending window of the most loaded core. This allows urgent signals (such as collision warnings) to be sent first, preempting the current window. This effectively resolves CAN bus congestion and single-core performance bottlenecks in multi-module integration scenarios.

[0094] In other embodiments, if a new functional module is added to the current power domain control software architecture, it is only necessary to define the ARXML interface and allocate it to the idle core without reconstructing the entire architecture.

[0095] Specifically, new functions (such as GCU generator control) can be encapsulated as SWC_GCU, integrated into the current software architecture through RTE, and core resources are dynamically allocated according to functional requirements.

[0096] It should be noted that the controllers to be integrated are not limited to the software integration of VCU, MCU, and BMS. Other controllers (such as GCU, DCDC, OBC, BDCAC, SDCAC, TMS, CCU, etc.) can all be integrated and deployed according to the above software architecture.

[0097] The number of fusion objects can be freely increased or decreased, from a single control unit to multiple control unit fusion (one ECU APPL is arranged according to one MCU core, and the maximum number of fusion objects depends on the number of MCU cores), which reflects the flexibility and wide scalability of the software architecture of this solution.

[0098] Through the above-mentioned architectural design, the software fusion and integration of power domain control can be realized, solving the problem that the software cannot be integrated into one when evolving from discrete to domain centralized.

[0099] This specification provides a power domain control software architecture, equipment, and computer-readable storage medium. The software architecture includes an application layer, a runtime environment, and a basic software layer developed based on the AUTOSAR standard. The application layer includes multiple modular software components. The software components encapsulate the business logic functions of the controller to be integrated and have a SWC interface defined in an ARXML file based on AUTOSAR. This not only improves interface compatibility and enables seamless integration of the application layer of controllers across suppliers, but also independently encapsulated software components are deployed in different cores according to the real-time performance of the functions, thereby enhancing development parallelism. The runtime environment generates inter-core communication proxy code, builds a virtual bus, and routes service requests from application layer components to the basic software layer. The basic software layer provides system-level services to the application layer through the virtual bus interface of the runtime environment. In this way, the application layer does not need to directly operate the hardware, achieving hardware and software decoupling and promoting the smooth implementation of software fusion and integration.

[0100] Based on the above-mentioned power domain control software architecture, this description provides a microcontroller unit, including a microcontroller with a multi-core architecture and the above-mentioned power domain control software architecture. The microcontroller is connected to the microcontroller abstraction layer in the power domain control software architecture, and hardware is driven through the microcontroller abstraction layer for power domain control function integration.

[0101] This specification also provides a power domain controller, including the above-mentioned power domain control software architecture.

[0102] The implementation process of the functions and effects of the above-mentioned power domain control software architecture is specifically described in the implementation process of the corresponding steps in the above-mentioned method, which can achieve the same technical effect and will not be repeated here.

[0103] Figure 7 An example of a physical structure diagram of an electronic device is shown below. Figure 7 As shown, the electronic device may include: a processor 810, a communications interface 820, a memory 830, and a communication bus 840, wherein the processor 810, the communications interface 820, and the memory 830 communicate with each other via the communication bus 840. The processor 810 may call the logic instructions in the memory 830 to execute the power domain control software architecture.

[0104] In addition, the logic instructions in the above-mentioned memory 830 can be implemented in the form of a software functional unit and can be stored in a computer-readable storage medium when sold or used as an independent product. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or the part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0105] On the other hand, the present application also provides a computer program product, which includes a computer program, which can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can execute the power domain control software architecture provided by the above methods.

[0106] On the other hand, the present application also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, is implemented to execute the power domain control software architecture provided by the above methods.

[0107] The foregoing description of this specification describes specific embodiments. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that described in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require the specific order shown or the sequential order to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0108] Other embodiments of the present invention will readily occur to those skilled in the art upon consideration of the present invention and practice of the invention claimed herein. This specification is intended to cover any variations, uses, or adaptations of the present invention that follow the general principles of this specification and include common knowledge or customary techniques in the art not claimed herein. The description and examples are to be considered as exemplary only, with the true scope and spirit of the present invention being indicated by the following claims.

[0109] It should be understood that the present description is not limited to the exact structure that has been described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present description is limited only by the appended claims.

[0110] The above description is only a preferred embodiment of this specification and is not intended to limit this specification. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of this specification should be included in the scope of protection of this specification.

Claims

1. A power domain control software architecture, characterized by: The software architecture includes the application layer, runtime environment, and basic software layer developed based on the AUTOSAR standard: The application layer includes multiple modular software components, which define standardized interfaces based on the AUTOSAR ARXML configuration file, encapsulate the business logic functions of the controller to be integrated, and are deployed on different cores of the multi-core CPU; The runtime environment generates a communication proxy code corresponding to the standardized interface based on the ARXML configuration file, constructs a virtual bus interaction interface for routing service requests of application layer components to the basic software layer, and distributes data responses of the basic software layer to application layer components; The basic software layer is used to encapsulate hardware drivers and provide system-level services to the application layer through the virtual bus interface of the runtime environment.

2. The power domain control software architecture according to claim 1, characterized in that: The basic software layer includes a microcontroller abstraction layer; The general function modules of the basic software layer are deployed on the main core of the multi-core CPU; The complex drivers in the microcontroller abstraction layer are deployed on the same slave core as the corresponding software components based on functional similarity.

3. The power domain control software architecture according to claim 2, characterized in that: The CAN signal types defined in the ARXML file in the multi-core CPU include common signals and dedicated signals, and the inter-core communication adopts a core-split peak-shifting concurrent mechanism to send the CAN signals; The master core is used to send signals corresponding to the software components on the master core and the common signals of the software components; the slave core is used to send the dedicated signals independently generated by the software components on the slave core.

4. The power domain control software architecture according to claim 3, characterized in that: The core-divided and peak-staggered concurrency mechanism includes: The master core monitors the load of each slave core and dynamically adjusts the time window for the slave core to send signals, and the slave cores send signals in sequence according to the time window; Among them, the higher the load, the longer the allocated sending time window.

5. The power domain control software architecture according to claim 1, characterized in that: The physical memory of the multi-core CPU has a shared memory area, the shared memory area is configured with global variables for storing cross-core data, and each core of the multi-core CPU can read and write data in the shared memory area.

6. The power domain control software architecture according to claim 5, characterized in that: Inter-core communication includes: After the core sending data writes the data to the shared memory area, an inter-core interrupt is triggered, and a read notification is sent to the core receiving the data; The kernel controlling the receiving data responds to the read notification and reads the data in the shared memory area.

7. The power domain control software architecture according to claim 6, characterized in that: Controlling the kernel receiving the data to respond to the read notification and read the data in the shared memory area includes: When multiple cores write data to the shared memory area simultaneously, controlling the core receiving the data to respond to the read notification according to the priority order of the inter-core interrupt; The priority of the inter-core interrupt is dynamically adjusted according to the real-time requirements of the software component on the core sending the data.

8. The power domain control software architecture according to claim 1, characterized in that: The number of controllers to be integrated is determined according to the number of cores of the multi-core CPU.

9. A microcontroller unit, characterized in that A microcontroller comprising a multi-core architecture and a power domain control software architecture as described in any one of claims 1 to 8, wherein the microcontroller is connected to the microcontroller abstraction layer in the power domain control software architecture, and is hardware-driven through the microcontroller abstraction layer for power domain control function integration.

10. A power domain controller, characterized in that: Comprising the microcontroller unit according to claim 9.

11. A computer device, characterized in that: It includes a memory, a processor and a vehicle control program stored in the memory and executable on the processor. When the processor executes the vehicle control program, it implements the steps of the power domain control software architecture as described in any one of claims 1 to 8.

12. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a vehicle control program, which, when executed, implements the steps of the power domain control software architecture according to any one of claims 1 to 8.

Images