Automotive electronic control unit integration method and system

Abstract

The application provides an automobile electronic control unit integration method and system, and relates to the technical field of automobile electronics, which comprises collecting the functional requirements of each system of the automobile to build a functional requirement database, classifying, designing corresponding domain controllers, and building a layered software architecture in the domain controller; deploying the control algorithms of each functional type to the corresponding functional core of the domain controller according to the layered software architecture; dividing the security levels of each functional module in the domain controller based on the functional core, and isolating and communicating the security monitoring of each functional module according to different security levels. The running safety between the functional modules is ensured through the isolation and communication security monitoring mechanism based on the security level, so that the automobile electronic control unit can realize centralized management, consistent scheduling and stable and reliable collaborative control under higher system complexity, and overcome the problem of lack of unified management and collaborative mechanism in the existing decentralized electronic control unit architecture.

Description

Technical Field

[0001] This application relates to the technical field of automotive electronics, and in particular to methods and systems for integrating automotive electronic control units. Background Technology

[0002] With the continuous improvement of automotive electronics and intelligence, the powertrain control system, chassis control system, body control system, infotainment system, and intelligent driving system all rely on electronic control units (ECUs) for coordinated operation. Modern passenger and commercial vehicles often integrate numerous ECUs, and the communication frequency between different systems is constantly increasing, leading to increasingly stringent requirements for system real-time performance, data consistency, and functional safety. Against this backdrop, automotive electronic and electrical architecture is gradually evolving from a traditional distributed structure to a centralized and regional control structure to meet the growing trend of increasingly complex in-vehicle functions.

[0003] Among related technologies, a distributed electronic control unit (ECU) layout is frequently adopted. This involves configuring an independent ECU for each specific functional module, with these ECUs communicating via an onboard bus to achieve their respective functional control and cross-system collaboration. In this technical model, each ECU has its own processor, memory, and software program, enabling it to perform vehicle control, status monitoring, and some cross-module information exchange. This approach ensures independent operation of each system function, flexible system deployment, low coupling between hardware and software, and better supports the functional expansion needs of traditional vehicles.

[0004] Although independent configuration of electronic control units can enable autonomous operation of each system function, with the continuous increase in vehicle functions and the frequency of system interaction, the existing distributed architecture is difficult to guarantee the coordination of the overall control system. That is, it is difficult to form a unified management and coordination mechanism among multiple control units inside the vehicle, which makes it difficult to effectively improve system consistency and overall operating efficiency. Summary of the Invention

[0005] To overcome the lack of unified management and coordination mechanisms in existing distributed electronic control unit architectures, this application provides an integration method and system for automotive electronic control units.

[0006] On one hand, the present invention provides an integration method for automotive electronic control units, comprising: collecting functional requirements of various systems of the vehicle to construct a functional requirements database; classifying electronic control units according to functional types based on the functional requirements database to obtain functional division results; designing corresponding domain controllers based on the functional division results, and constructing a layered software architecture in the domain controllers; deploying control algorithms for each functional type to the corresponding functional cores of the domain controllers according to the layered software architecture; classifying the security levels of each functional module in the domain controllers based on the functional cores, and isolating and monitoring the communication security of each functional module according to different security levels.

[0007] Optionally, the step of collecting the functional requirements of various systems of the vehicle to construct a functional requirements database, and classifying electronic control units according to functional types based on the functional requirements database to obtain functional division results includes: collecting functional parameters and control signal types of various systems of the vehicle to construct a functional requirements database; classifying electronic control units into a first control unit, a second control unit, and a third control unit based on the real-time requirements of each system in the functional requirements database, and determining the real-time level based on the first control unit, the second control unit, and the third control unit; classifying the electronic control units in the first control unit, the second control unit, and the third control unit according to the control signal types of each system in the functional requirements database, merging electronic control units with similar control objects into the same functional type to obtain the control object type; calculating the total computing resource requirements of all electronic control units in each functional type, determining the number of processor cores and storage capacity specifications required for the corresponding functional type based on the total computing resource requirements to obtain hardware resource configuration parameters; and constructing functional division results based on the real-time level, the control object type, and the hardware resource configuration parameters.

[0008] Optionally, the step of calculating the total computing resource requirements of all electronic control units within each functional type, and determining the required number of processor cores and storage capacity specifications for the corresponding functional type based on the total computing resource requirements to obtain hardware resource configuration parameters includes: extracting the total computing resource requirements of each electronic control unit within each functional type from the functional requirement database; wherein the total computing resource requirements include unit computing power requirements and unit storage requirements; summing the unit computing power requirements of all electronic control units within the same functional type to obtain the total computing power requirements for each functional type; summing the unit storage requirements of all electronic control units within the same functional type to obtain the total storage requirements for each functional type; dividing the total computing power requirements by the processor core unit computing power benchmark value and rounding up according to a preset processor core unit computing power benchmark value to obtain the number of processor cores required for each functional type; determining the program storage capacity and data storage capacity based on the total storage requirements to obtain the storage capacity specifications for each functional type; and constructing hardware resource configuration parameters based on the number of processor cores and the storage capacity specifications for each functional type.

[0009] Optionally, the step of designing a corresponding domain controller based on the functional partitioning result and constructing a layered software architecture in the domain controller includes: selecting a multi-core processor chip according to the hardware resource configuration parameters in the functional partitioning result; wherein the multi-core processor chip includes a main control core and multiple functional cores; assigning computational priorities to each functional core according to the real-time level in the functional partitioning result; configuring storage modules based on the storage capacity specifications in the functional partitioning result, and configuring power management modules and communication interface modules according to the functional partitioning result; designing a corresponding domain controller using the multi-core processor chip, the computational priorities, the storage modules, the power management modules, and the communication interface modules; and constructing an operating system layer, a middleware layer, and an application layer in the domain controller to obtain a layered software architecture.

[0010] Optionally, the step of deploying the control algorithms of each functional type to the corresponding functional core of the domain controller according to the layered software architecture includes: encapsulating the control algorithms of each functional type into independent software components according to the application layer interface specification of the layered software architecture; and deploying the software components belonging to each functional type to the corresponding functional core according to the control object type of each functional type in the functional division result.

[0011] Optionally, the step of classifying the security levels of each functional module in the domain controller based on the functional core, and isolating and monitoring the communication security of each functional module according to different security levels, includes: obtaining a list of functional modules running on each functional core; performing a security integrity level assessment on each functional module in the list to obtain high-security-level and low-security-level functional modules; allocating independent memory address spaces for functional modules with different security levels, and setting memory access permissions through the memory protection unit at the hardware level of the domain controller; creating a security partition for the high-security-level functional modules, and using the security partition to isolate the high-security-level functional modules from the low-security-level functional modules in time and space; and monitoring data transmission between functional cores in real time, and when data is detected to be tampered with or accessed without authorization, blocking the corresponding communication link and sending a security alarm signal to the main control core.

[0012] Optionally, the step of creating a security partition for the high-security-level functional module and using the security partition to isolate the high-security-level functional module from the low-security-level functional module in time and space includes: enabling a virtualization management program at the operating system layer, and using the virtualization management program to create an independent virtual execution environment as a security partition for each high-security-level functional module; setting an independent memory page table for each security partition, mapping the virtual memory address of the security partition to a specific area of ​​physical memory through the memory page table, and setting an access control list in the virtualization management program to prohibit the low-security-level functional module from accessing the physical memory area corresponding to the security partition; allocating a fixed time window for each security partition, and within the time window allocated to a certain security partition, the virtualization management program transfers complete control of the processor to the current security partition, and forcibly suspends the execution of the current security partition at the end of the time window, switching to the time window of the next functional module.

[0013] On the other hand, this application also provides an integrated system for automotive electronic control units, including: a data acquisition module for acquiring the functional requirements of various systems in the vehicle to construct a functional requirements database, classifying the electronic control units according to their functional types based on the functional requirements database to obtain functional division results; a design module for designing corresponding domain controllers based on the functional division results, and constructing a layered software architecture in the domain controllers; a deployment module for deploying control algorithms of various functional types to the corresponding functional cores of the domain controllers according to the layered software architecture; and a partitioning module for partitioning the security levels of various functional modules in the domain controllers based on the functional cores, and isolating and monitoring the communication security of each functional module according to different security levels.

[0014] The automotive electronic control unit integration method and system provided in this application have the following technical effects: by realizing unified collection and classification of electronic control units based on functional requirement database, driving domain controller design through functional partitioning results, realizing efficient deployment of control algorithms through layered software architecture, and ensuring operational safety between functional modules through isolation and communication security monitoring mechanisms based on security levels, the automotive electronic control unit can achieve centralized management, consistent scheduling, and stable and reliable collaborative control under higher system complexity, overcoming the problem of lack of unified management and collaborative mechanisms in the existing distributed electronic control unit architecture. Attached Figure Description

[0015] To more clearly illustrate the technical solutions and advantages in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 This is a flowchart illustrating the automotive electronic control unit integration method provided in an embodiment of the present invention; Figure 2 This is a schematic block diagram of the structure of the automotive electronic control unit integrated system provided in the embodiments of the present invention. Detailed Implementation

[0017] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0018] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or server that comprises a series of steps or sub-modules is not necessarily limited to those steps or sub-modules explicitly listed, but may include other steps or sub-modules not explicitly listed or inherent to such processes, methods, products, or devices.

[0019] The technical solution of the present invention will be further described below with reference to the accompanying drawings and specific embodiments.

[0020] like Figure 1 As shown in the example, this application provides a method for integrating automotive electronic control units. This method can achieve centralized scheduling and collaborative control of electronic control units by uniformly collecting, classifying, integrating, and managing the functional requirements of multiple automotive systems. Specifically, it includes the following steps: Step S1: Collect the functional requirements of various systems in the vehicle to build a functional requirements database. Based on the functional requirements database, classify the electronic control units according to their functional types to obtain the functional classification results.

[0021] The functional requirements database is defined to include the following fields: system identifier, electronic control unit identifier, controlled object type, control signal type, input / output signal specifications, real-time requirements, worst-case execution time estimate, unit computing power requirement, unit storage requirement, communication interface type, diagnostic requirements, and candidate functional safety levels. During functional requirements collection, static time analysis tools can be used to analyze the execution path of the control algorithm to obtain a worst-case execution time estimate. Simultaneously, by running example tasks on the target hardware platform, processor utilization and computing power requirements are measured to obtain the unit computing power requirement. After requirements collection, each electronic control unit is categorized into a first control unit, second control unit, or third control unit based on real-time requirements, and the results are written into the functional requirements database. Subsequently, based on the control object type, control signal type, and characteristics of input and output signals, the electronic control units are functionally clustered. Electronic control units with similar control objects or signal interaction relationships are grouped into the same functional type. Based on the clustering results, the total computing power requirement and total storage requirement for each functional type are calculated. Finally, a functional division result containing information such as functional type identifier, corresponding electronic control unit set, real-time level, control object type, total computing power requirement, and total storage requirement is formed.

[0022] In power systems, the functional requirements of engine control units, energy management control units, and torque control units all have high real-time requirements in the functional requirements database. Their controlled objects have close physical relationships, so they will be classified into power function types and marked in the functional division results as requiring high computing power and high storage capacity resource configurations.

[0023] Step S2: Design the corresponding domain controller based on the functional partitioning results, and build a layered software architecture in the domain controller.

[0024] Based on the requirements for computing power, storage, interface bandwidth, and real-time performance in the functional partitioning results, a suitable multi-core processor chip is selected. Different responsibilities are assigned to the main control core and functional cores within the domain controller. The main control core handles policy management and fault management, while the functional cores handle specific control tasks corresponding to their respective function types. Subsequently, based on the real-time performance and task density of each function type in the functional partitioning results, priorities and core affinity are set for the functional cores, ensuring that tasks corresponding to the first control unit run on the highest-priority functional core. During the design and construction phase, program storage and data storage areas also need to be allocated to the domain controller, access permissions set, and memory mapping structures defined. Simultaneously, power management and communication interface modules are configured to meet the CAN, CAN-FD, LIN, or Ethernet communication requirements of each function type. Scheduling parameters for time-sensitive networks are configured for Ethernet as needed. Based on the above hardware and resource preparations, a layered software architecture is further constructed within the domain controller. The architecture includes a driver layer, an operating system layer, a middleware layer, and an application layer. The operating system layer needs to support deterministic scheduling or time partitioning. The middleware layer provides cross-functional core communication, shared memory management, message queuing, and communication security monitoring functions. The application layer is used to load control algorithm software components and call the middleware interface downwards.

[0025] For example, in the domain controller corresponding to the power function type, a multi-core processor with multiple physical cores can be selected, and two of the higher-performance functional cores can be allocated to the power control task. The CAN-FD interface related to the power domain can be directly connected to the domain controller, so that the high real-time task of the power function type can be executed stably at a fixed cycle.

[0026] Step S3: Deploy the control algorithms of each functional type to the corresponding functional core of the domain controller according to the layered software architecture.

[0027] The control algorithm is encapsulated as an independent software component. Each component includes algorithm execution logic, data input / output interfaces, a status monitoring module, a parameter configuration table, and version information. Input / output data structures, message priorities, message IDs, and maximum allowable transmission delays are defined according to the interface specifications in the layered software architecture. Subsequently, based on the functional partitioning, control algorithms for different functional types are deployed to their corresponding functional cores. Execution cycles, priorities, and storage areas are set for each software component. A shared memory area and message queue mechanism are configured in the middleware layer to enable data exchange between different functional types via shared memory or message queues, and memory barriers are used to ensure data consistency. During algorithm deployment, static analysis and benchmark testing are conducted to verify the actual execution time and resource consumption of the algorithm components on the target functional cores, ensuring that the execution cycle and resource allocation structure meet real-time design requirements.

[0028] By encapsulating the traction control algorithm of the power function type into a "power traction component" and configuring it to perform tasks periodically, its inputs include vehicle speed and torque demand signals, and its output is the drive actuator control signal; this component is deployed on the power function core, reads vehicle speed data from the chassis function type through shared memory, and sends the operating status to the upper-level module through a message queue.

[0029] Step S4: Based on the functional core, classify the security levels of each functional module in the domain controller, and isolate and monitor the communication security of each functional module according to different security levels.

[0030] Based on the candidate security levels recorded in the functional requirements database and the task characteristics in the functional core, each functional module is classified according to functional safety standards. Independent memory regions, task execution contexts, and access control policies are allocated to modules of different levels, ensuring that higher-level modules are not affected by lower-level modules. Simultaneously, during cross-module communication, a communication security monitoring mechanism checks the integrity, timing, source legitimacy, and access permissions of messages. Abnormal communication behavior is blocked or reported when necessary. The execution status of the functional core is continuously monitored during operation to ensure that modules with higher security levels maintain a stable and controllable execution environment under various operating scenarios.

[0031] In the power function type, the power-related torque control module is set to the highest safety level. Its memory area and scheduling context are isolated from other tasks. At the same time, cross-domain communication requires data exchange through a secure channel with message authentication identifier.

[0032] In this embodiment, functional requirements of various automotive systems are collected, and a functional requirements database is constructed based on these requirements. The electronic control units (ECUs) are then categorized by function type according to this database to obtain functional partitioning results. After obtaining the functional partitioning results, corresponding domain controllers are designed based on these results, and a hierarchical software architecture is constructed within the domain controllers to enable them to perform hierarchical scheduling and management. Subsequently, control algorithms for each functional type are deployed to the corresponding functional cores within the domain controllers according to the hierarchical software architecture, allowing each functional core to undertake control tasks matching its functional type. Finally, based on each functional core, the security levels of each functional module within the domain controllers are divided, and the functional modules are isolated and monitored for communication security according to different security levels, ensuring that the control tasks remain in a safe state during operation, thereby completing the integration process of the automotive ECUs.

[0033] By adopting the above-mentioned automotive electronic control unit integration method, the functional requirements of various automotive systems can be constructed into a functional requirement database in a unified manner, thus providing a clear basis for the functional type classification of electronic control units. By designing domain controllers and constructing a hierarchical software architecture based on the functional classification results, the management, scheduling, and execution paths of control tasks can be made clearer and more consistent. By deploying the control algorithms of each functional type to the corresponding functional cores of the domain controllers, task conflicts between different functional types can be avoided, improving the efficiency of control task execution. At the same time, by classifying the security levels of each functional module based on the functional cores and implementing isolation and communication security monitoring, the overall safety and stability during operation can be significantly improved, enabling automotive electronic control units to maintain coordinated operation and reliability even under more complex vehicle functional requirements.

[0034] In another example, step S1 can preferably be the following example: Functional parameters and control signal types of various automotive systems are collected to construct a functional requirements database. Based on the real-time requirements of each system in the functional requirements database, electronic control units (ECUs) are classified into first, second, and third ECUs, and their real-time levels are determined accordingly. Specifically, the first ECU is an ECU with a real-time requirement of less than 10 milliseconds, the second ECU has a real-time requirement between 10 and 100 milliseconds, and the third ECU has a real-time requirement of more than 100 milliseconds.

[0035] The functional parameters and control signal types of each electronic control unit (ECU) are collected item by item according to a predefined functional requirements database field template. The functional requirements database field template includes, but is not limited to: system identifier, ECU identifier, controlled object type, control signal type, signal bit width, sampling frequency, maximum permissible delay of command / feedback signals, actual measured or estimated worst-case execution time (WCET_est), unit computing power requirement (in DMIPS or MIPS), unit program storage requirement and unit data storage requirement (in MB), communication interface type (CAN, CAN-FD, LIN, Ethernet, TSN), power consumption budget, diagnostic and redundancy requirements, and preliminary functional safety level candidates. For obtaining WCET_est, a two-step method is used: first, static time analysis tools, such as aiT or OTAWA, are used to perform static analysis on the control flow graph of the control algorithm to obtain the path-level upper bound of WCET; second, a representative workload is run on the target or equivalent processor to perform benchmark tests to obtain the average and peak execution times during runtime. The static analysis results are compared with the benchmark test results, and the more conservative one is adopted as WCET_est. For the unit computing power requirement, the task execution time measured on the target architecture using SPEC CPU or a custom micro-benchmark set can be converted to MIPS / DMIPS. Both peak and average computing power values ​​should be recorded for subsequent accumulation and margin calculations. After field filling, each electronic control unit (ECU) is classified into the first, second, or third ECU based on the maximum allowable latency and WCET_est, and a real-time level field is written to the functional requirements database for subsequent processing.

[0036] For example, the command response of the brake control unit is required to be no more than 5 milliseconds, and WCET_est is 1.8 milliseconds after static analysis and benchmark testing. Therefore, it is marked as real-time level = first control unit in the functional requirements database. The command response of the infotainment related unit is allowed to be 300 milliseconds and WCET_est is 50 milliseconds. Therefore, it is marked as real-time level = third control unit in the functional requirements database.

[0037] Based on the control signal types of each system in the functional requirements database, the electronic control units in the first control unit, second control unit, and third control unit are functionally classified. Electronic control units with similar control objects are merged into the same functional type to obtain the control object type. Among them, electronic control units related to the power system are merged into the power domain, electronic control units related to the chassis system are merged into the chassis domain, electronic control units related to the body system are merged into the body domain, and electronic control units related to the intelligent driving system are merged into the intelligent driving domain.

[0038] A feature vector is constructed for each electronic control unit (ECU). Features include the semantic encoding of the controlled object (e.g., engine, transmission, steering, braking, etc.), the encoding of the control signal type (analog, PWM, CAN message, Ethernet frame, etc.), the real-time performance level encoding, WCET_est, unit computing power requirement, and unit storage requirement. Then, a rule engine and hierarchical aggregation algorithm are applied to all feature vectors for functional clustering. The rule engine identifies explicit business mapping rules (e.g., all units that directly control drive actuators and are the first control unit in terms of real-time performance must be grouped into the powertrain or chassis domain). The hierarchical aggregation algorithm uses hierarchical agglomerative clustering and a weighted Euclidean distance of feature vectors as a similarity metric. Weights reflect the priority of real-time performance, controlled object semantics, and communication dependencies, ensuring that units with high real-time performance and communication coupling are preferentially grouped into the same functional type. After clustering, the clusters are fine-tuned based on the communication dependency analysis results: if there is a large amount of high-frequency / low-latency message interaction between two clusters, they are merged, or high-bandwidth, low-latency data channels are marked in the functional partitioning results. The functional clustering results are written back to the functional requirements database and a control object type field is generated.

[0039] For example, in the communication dependency analysis, there are a large number of CAN-FD message exchanges at the 0-5ms level between the engine control unit and the energy management unit. The clustering algorithm groups the two into the same cluster within the weighted distance threshold. The rule engine further confirms and merges them into the power domain based on the fact that both are actuator controls and the real-time performance is the first control unit.

[0040] The total computing resource requirements of all electronic control units within each functional type are calculated. Based on the total computing resource requirements, the number of processor cores and storage capacity required for the corresponding functional type are determined, thus obtaining the hardware resource configuration parameters.

[0041] The unit computing power requirement and unit storage requirement of all electronic control units within each functional type are extracted from the functional requirements database. The unit computing power requirement of all electronic control units within the same functional type is accumulated to obtain the total computing power requirement for that functional type, and the unit storage requirement of all electronic control units within the same functional type is accumulated to obtain the total storage requirement for that functional type. To map the total computing power requirement to the required number of processor cores, a preset benchmark value for processor core unit computing power needs to be determined first. This benchmark value is based on the single-core sustained computing power of the target multi-core chip (effective computing power considering actual scheduling and context switching overhead), and the single-core available computing power obtained from benchmark testing is used as the numerical input. The number of processor cores is calculated using the formula: Number of processor cores = (Total computing power requirement / Computing power baseline value of processor core unit) rounded up. Redundancy is then configured based on the real-time requirements: when the function type belongs to the first control unit, at least one redundant core is added to the initial number to meet failover and peak load conditions; when the function type belongs to the second control unit, zero or one redundant core is added to the initial number; when the function type belongs to the third control unit, the initial number of cores remains unchanged. For storage capacity, program storage capacity is allocated at a ratio of 40% to 60% based on the total storage requirements, and data storage capacity is allocated at a ratio of 40% to 60%. An additional 20% to 30% reserve space is added to both the allocated program storage capacity and data storage capacity to accommodate software upgrades and log / data expansion, ultimately resulting in the storage capacity specifications for each function type. After determining the number of processor cores and storage capacity specifications, these parameters, together with the real-time level of the function type and the type of controlled object, form hardware resource configuration parameters and are recorded in the function partitioning results. At the same time, the data interaction relationship and communication bandwidth requirements between each function type are marked in the function partitioning results for use in the domain controller design.

[0042] If the total computing power requirement after accumulation within a certain chassis domain is 18000 DMIPS, and the preset benchmark computing power of the processor core unit is 3000 DMIPS / core, then the initial number of processor cores is rounded up to (18000 / 3000) = 6 cores. If the chassis domain is determined to be the first control unit, then at least one redundant core is added on this basis, that is, the number of processor cores is 7. If the total storage requirement is 512MB, then the program storage can be allocated to 230MB (about 45%), the data storage can be allocated to 230MB (about 45%), and then 25% reserved space is added to each, resulting in a specification of approximately 288MB for program storage and approximately 288MB for data storage.

[0043] The functional partitioning results are constructed based on the real-time level, the type of controlled object, and the hardware resource configuration parameters. The functional partitioning results include the real-time level, the type of controlled object, and the hardware resource configuration parameters for each functional type.

[0044] All the above calculations and clustering results are summarized to generate the final functional partitioning document. This document must clearly list the identifier of each functional type, the corresponding set of electronic control units, the real-time level, the type of controlled object, the total computing power requirement, the total storage requirement, the number of processor cores, the program storage and data storage specifications, the recommended communication interface type and bandwidth requirements, the external interface mapping table, and the data exchange topology diagram between functional types. This functional partitioning result must be saved as an independent record in the functional requirements database and should include version information, a generation timestamp, and the parameter set used to reproduce the partitioning (e.g., clustering threshold, weighting coefficients, and processor baseline values). After the functional partitioning result is completed, a special review should be conducted on key functional types. The review content includes whether the resource margin meets the safety redundancy requirements, whether the communication bandwidth meets the peak interaction requirements, and whether the clustering quality meets the design goals. If the review finds any unmet requirements, the clustering weights or resource baseline values ​​should be adjusted retrospectively, and the functional partitioning result should be regenerated.

[0045] When the functional partitioning results indicate that the real-time level of the intelligent driving domain is marked as the second control unit, the type of controlled object is marked as intelligent driving, the number of processor cores is marked as 4 cores, the program storage is marked as 256MB, and the data storage is marked as 256MB, and it is indicated in the topology diagram that there needs to be an Ethernet TSN channel with a bandwidth of at least 10Mbps and a latency of less than 5ms between the intelligent driving domain and the power domain.

[0046] Furthermore, the step of calculating the total computing resource requirements of all electronic control units within each functional type, and determining the required number of processor cores and storage capacity specifications for the corresponding functional type based on the total computing resource requirements, to obtain hardware resource configuration parameters, can also be preferably: Extract the unit computing power requirement and unit storage requirement of each electronic control unit within each functional type from the functional requirements database. Accumulate the unit computing power requirement of all electronic control units within the same functional type to obtain the total computing power requirement of each functional type. Accumulate the unit storage requirement of all electronic control units within the same functional type to obtain the total storage requirement of each functional type.

[0047] The extraction and accumulation of unit computing power and unit storage requirements should clearly define the measurement caliber and units used. Peak DMIPS should be used as the cumulative benchmark for unit computing power requirements, while unit storage requirements should be distinguished between program storage and data storage and accumulated separately. After accumulation, a load factor should be applied to the total computing power requirement based on the timing characteristics of the functional type to reflect concurrency and scheduling overhead. The load factor can be in the range of 1.1 to 1.4 and adjusted according to the real-time level. A higher load factor should be used for the first control unit to reflect preemption and interrupt handling overhead. The total computing power requirement obtained after accumulation and load factor processing is used for subsequent core count calculations. For the total storage requirement, in addition to accumulation, file system overhead, log write requirements, and firmware upgrade space should also be considered, with 20% to 30% reserved space added. The calculation results of this step are written to the hardware resource configuration parameter field and archived and reviewed as part of the functional partitioning results.

[0048] For example, if the unit computing power requirements of five electronic control units within a certain functional type are extracted from the functional requirements database as 2000, 1500, 3000, 1000, and 2500 DMIPS respectively, and are accumulated to obtain 10000 DMIPS, and if the functional type is the first control unit, then a load factor of 1.3 is used, and the total computing power requirement is 13000 DMIPS. Then, based on the processor single-core benchmark of 3000 DMIPS, the initial number of cores is calculated as (13000 / 3000) = 5 cores, rounded up. Subsequently, at least one redundant core is added according to the real-time rules, and the final number is determined to be 6 cores.

[0049] Based on the preset processor core unit computing power benchmark value, the total computing power requirement is divided by the processor core unit computing power benchmark value and rounded up to obtain the number of processor cores required for each function type. The initial number of cores can also be redundantly configured according to the real-time level of the function type. When the function type belongs to the first control unit, at least one redundant core is added to the initial number of cores. When the function type belongs to the second control unit, zero or one redundant core is added to the initial number of cores. When the function type belongs to the third control unit, the initial number of cores remains unchanged.

[0050] The functional partitioning results should clearly state the source and measurement method of the benchmark computing power value of the processor core unit used. This benchmark value should be obtained by running a standardized micro-benchmark on the target chip or reference chip, and the benchmark test conditions (load type, temperature, frequency) should be noted. After the core count is calculated, simulation verification should be performed using a task scheduling simulation tool (such as SCHED_TEST or a self-developed simulation tool). The simulation verification items include verification of scheduling latency and deadline compliance under peak load, failover, and virtualization overhead scenarios. If the simulation fails, the core count needs to be adjusted or the task partitioning strategy needs to be modified.

[0051] For example, if the total computing power requirement is 15000 DMIPS and the benchmark computing power of the processor core unit is 3000 DMIPS / core, then the initial number of cores is rounded up (15000 / 3000) = 5 cores; if the function type is determined to be the first control unit, then the number of cores will be increased by at least 1 core as redundancy, and the final number will be 6 cores. The scheduling simulation will confirm that all hard real-time tasks still meet the deadline under resource failure scenarios.

[0052] The program storage capacity and data storage capacity are determined based on the total storage requirements. The program storage capacity is allocated according to 40% to 60% of the total storage requirements, and the data storage capacity is allocated according to 40% to 60% of the total storage requirements. An additional 20% to 30% of the reserved space is added to the program storage capacity and data storage capacity respectively to obtain the storage capacity specifications for each functional type.

[0053] Define the measurement criteria and partitioning strategies for program storage and data storage. Program storage is used to store executable images, static libraries, and verification information, while data storage is used for runtime caching, logs, and persistent data. First, divide the total storage requirements into program storage and data storage according to the selected proportion, and then reserve upgrade space and log space for each part respectively. After determining the storage capacity specifications, a memory mapping table needs to be created, and the physical or logical storage block address range, access permissions, and protection policies (such as read-only / executable bits) corresponding to each functional module should be recorded in the functional partitioning results. At the end of this step, the storage bandwidth needs to be evaluated to ensure that the storage subsystem will not become a performance bottleneck under peak access scenarios.

[0054] If the total storage requirement is 1024MB, then the program storage and data storage are divided into 50% and 50% respectively, each with 512MB. Then, 25% of the space is reserved for each, so the final program storage is 640MB and the data storage is 640MB. A separate read-only area is allocated for the critical security module in the memory mapping table.

[0055] Hardware resource configuration parameters are constructed based on the real-time level, control object type, number of processor cores, and storage capacity specifications of each function type, and the data interaction relationship and communication bandwidth requirements between each function type are marked in the function division results.

[0056] The calculated number of processor cores, storage capacity specifications, and interface requirements are summarized into a standardized hardware resource configuration parameter file. This file must include recommended multi-core chip models or performance levels for each functional type, physical specifications for program and data storage of the main control core and functional cores, required communication interface types and port numbers, target communication bandwidth and latency values, and descriptions of power management and temperature constraints. The functional partitioning results should include a data interaction diagram and clearly define the minimum bandwidth and maximum allowable latency for each interaction link, for use in subsequent domain controller design and Ethernet / TSN flow table configuration. Upon completion, the hardware resource configuration parameters will be version-managed as part of the functional partitioning results, and used during design reviews for domain controller selection and hardware / software co-optimization.

[0057] For example, if the hardware resource configuration parameters of a certain function type indicate that the recommended multi-core chip performance level is "medium-high", with 1 main control core + 6 function cores, 512MB of program storage, 512MB of data storage, and external communication requires 2 CAN-FD channels and 1 Ethernet TSN channel, and the data interaction with adjacent function types requires a minimum bandwidth of 10Mbps and a one-way delay of no more than 5Ms.

[0058] In another example, step S2 can preferably be the following example: A multi-core processor chip is selected based on the hardware resource configuration parameters in the functional partitioning results; wherein, the multi-core processor chip includes one main control core and multiple functional cores, and the number of functional cores matches the number of processor cores determined in the functional partitioning results.

[0059] By reading the processor core count data marked for each function type in the functional partitioning results and converting this data into the core count requirement of a multi-core processor chip, and comparing it with the core count parameters of the available multi-core processor chips, a multi-core processor chip with a core count matching the processor core count, a main control core frequency of not less than 1GHz, and a functional core frequency of not less than 400MHz is selected. When selecting, the chip's power consumption index is required to meet the maximum power consumption limit required in the functional partitioning results, thereby ensuring that each functional core has the processing capability to meet the computing task execution requirements.

[0060] When the functional partitioning results determine that the power domain requires 3 processor cores, the chassis domain requires 2 processor cores, the body domain requires 1 processor core, and the intelligent driving domain requires 4 processor cores, a multi-core processor chip with 1 main control core and 10 functional cores can be selected. System management tasks are assigned to the main control core, and the 10 functional cores are mapped one-to-one according to the number of processor cores in the power domain, chassis domain, body domain, and intelligent driving domain, so that the number of functional cores is completely consistent with the number of processor cores.

[0061] Based on the real-time level in the functional division results, the operation priority is assigned to each functional core. The control tasks of the first control unit are assigned to the high-priority functional core, the control tasks of the second control unit are assigned to the medium-priority functional core, and the control tasks of the third control unit are assigned to the low-priority functional core.

[0062] By reading the real-time level of each function type in the function partitioning results, the real-time level is converted into a corresponding priority value. The smaller the priority value, the higher the priority. Priority register rules are set for each function core in the operating system layer. The function core responsible for the first control unit is set to a priority of 1, the function core responsible for the second control unit is set to a priority of 2, and the function core responsible for the third control unit is set to a priority of 3, so as to ensure that high real-time tasks can obtain execution resources first.

[0063] When the power domain belongs to the first control unit, the priority of the functional core corresponding to the power domain can be set to 1. When the chassis domain belongs to the second control unit, the priority of the functional core corresponding to the chassis domain can be set to 2. When the body domain and intelligent driving domain belong to the third control unit, the priority of the functional core corresponding to the body domain and intelligent driving domain can be set to 3. The priority scheduler in the operating system layer ensures that the high-priority cores have priority in execution during conflict scheduling.

[0064] Based on the storage capacity specifications in the functional partitioning results, the storage modules are configured, including program storage areas and data storage areas. Independent storage space is allocated for each functional type. Power management modules and communication interface modules are configured according to the functional partitioning results. The corresponding domain controllers are designed using multi-core processor chips, computing priorities, storage modules, power management modules, and communication interface modules. Among them, the power management module includes multiple power output channels, and the communication interface module includes CAN bus interface, LIN bus interface, and Ethernet interface.

[0065] Based on the storage capacity specifications of each functional type in the functional partitioning results, independent non-volatile storage and random access storage areas are allocated to the program storage area and data storage area respectively. Expansion space of no less than 30% of the total storage requirement is reserved for the first control unit, 20% for the second control unit, and 10% for the third control unit. Based on the communication bandwidth requirements in the functional partitioning results, a corresponding number of CAN bus interfaces, LIN bus interfaces, and Ethernet interfaces are configured for each functional type to ensure sufficient bandwidth for data exchange between functional types. The power management module is configured with independent power channels according to the power consumption requirements of each functional type, enabling separate power supply for each functional type.

[0066] When the storage capacity specification of the power domain is 200MB of program storage and 300MB of data storage, 200MB of program storage and 300MB of data storage can be allocated to the power domain, with an additional 150MB of reserved space. At the same time, the power domain is configured with 2 CAN bus interfaces, 1 Ethernet interface and an independent 5V / 3A power supply channel to meet the high bandwidth data interaction and high power consumption requirements of the power domain. The above configuration is combined with a multi-core processor chip to build a power domain controller.

[0067] A layered software architecture is obtained by building a driver layer, an operating system layer, a middleware layer, and an application layer in the domain controller. The driver layer is used to implement the low-level control of hardware resources, the operating system layer is used to implement task scheduling and resource management, the middleware layer is used to implement cross-core communication and data interaction, and the application layer is used to run control algorithms of various functional types.

[0068] By loading hardware adapter drivers inside the domain controller to build the driver layer, loading a real-time operating system that supports priority scheduling and multi-core management as the operating system layer, and building a middleware layer that supports shared memory mapping, message queue management and cross-core synchronization mechanisms on this basis, and providing standardized algorithm call interfaces for the application layer above the middleware layer, the complete configuration of the cross-layer structure is realized, enabling the domain controller to complete the complete workflow of hardware driver, task scheduling, data interaction and algorithm execution.

[0069] An RTOS that supports preemptive scheduling (such as FreeRTOS or AUTOSAR OS) can be used. CAN driver, LIN driver, Ethernet driver, and GPIO driver are loaded at the driver layer. The middleware layer is configured with a shared memory area size of 64KB to 256KB and a message queue depth of 128 messages. At the application layer, respective control algorithm execution interfaces are provided for the power domain, chassis domain, body domain, and intelligent driving domain to ensure the stable operation of control algorithms for each functional type.

[0070] In another example, step S3 can preferably be the following example: Based on the application layer interface specification of the layered software architecture, the control algorithms of each functional type are encapsulated into independent software components. Each software component includes an algorithm execution module, a data input / output interface, and a status monitoring module.

[0071] Based on the application layer interface specification in the layered software architecture, a unified input parameter structure, output parameter structure, and execution function interface are defined for the control algorithm. The control algorithm is then ported to a standardized software component framework, so that each software component has an independent algorithm execution module for executing the algorithm logic, an independent data input / output interface for exchanging data with the middleware layer, and a status monitoring module for real-time monitoring of the algorithm's running status and error codes, thereby ensuring the independent operation capability of the software components on different functional cores.

[0072] For torque control algorithms in the power domain (such as PID-based control algorithms), they can be encapsulated as "power torque control software components". The algorithm execution module executes the PID calculation logic, the data input / output interface reads vehicle speed data from the shared memory area and outputs torque commands, and the status monitoring module records PID deviation values ​​in real time and outputs running status codes.

[0073] Based on the control object type of each function type in the functional division results, software components belonging to each function type are deployed to the corresponding functional cores. This includes deploying control algorithms belonging to the power domain to the functional core responsible for power control, control algorithms belonging to the chassis domain to the functional core responsible for chassis control, control algorithms belonging to the body domain to the functional core responsible for body control, and control algorithms belonging to the intelligent driving domain to the functional core responsible for intelligent driving. A shared memory area and message queue mechanism are established in the middleware layer. Data sharing between functional cores is achieved through the shared memory area, and control command transmission between functional cores is achieved through the message queue mechanism. The control algorithms deployed on each functional core are configured with task cycles and execution sequences. The execution cycle of the task is set according to the real-time level. The execution cycle of the control algorithm of the first control unit is set to 1 millisecond to 10 milliseconds, the execution cycle of the control algorithm of the second control unit is set to 10 milliseconds to 100 milliseconds, and the execution cycle of the control algorithm of the third control unit is set to 100 milliseconds to 1000 milliseconds. The control algorithms on each functional core are scheduled and managed by the task scheduler at the operating system layer to ensure that each control algorithm is executed in sequence according to the set task cycle and priority.

[0074] By parsing the control object type in the functional partitioning results, software components are bound to the corresponding functional cores, and shared memory address ranges, message queue identifiers, and maximum message sizes are allocated in the middleware layer. The task cycle is written into the task management table of the operating system layer according to the real-time level, and the execution start time, execution duration, and priority level are specified for each control algorithm. Periodic scheduling is achieved through the multi-core scheduling mechanism of the operating system layer to ensure that tasks do not have execution conflicts in a multi-core environment.

[0075] When the power domain belongs to the first control unit, the power domain software component can be deployed to functional core 0 with an execution cycle of 1 millisecond. The chassis domain software component can be deployed to functional core 1 with an execution cycle of 20 milliseconds. The body domain software component can be deployed to functional core 2 with an execution cycle of 200 milliseconds. The intelligent driving domain software component can be deployed to functional core 3 with an execution cycle of 800 milliseconds. A shared memory area A is created in the middleware layer for the power domain and chassis domain to share vehicle speed data. A message queue B is created for the intelligent driving domain to send control commands to the power domain, thereby realizing cross-functional collaborative control.

[0076] In another example, step S4 can preferably be the following example: Obtain a list of functional modules running on each functional core, and conduct a safety integrity level assessment on each functional module in the list according to automotive functional safety standards to obtain functional modules with different safety levels. Among them, functional modules with different safety levels include high-safety-level functional modules and low-safety-level functional modules. High-safety-level functional modules include ASIL-D and ASIL-C levels, and low-safety-level functional modules include ASIL-B, ASIL-A, and QM levels. ASIL-D level is the highest safety level, and QM level is the lowest safety level.

[0077] By scanning the list of software components deployed in each functional core of the domain controller, and combining the ISO 26262 standard, a risk assessment of the safety functions of each software component is conducted. This includes analyzing the impact of functional failure on the overall safety of the vehicle, the probability of failure, and the potential hazard level. Finally, a corresponding ASIL level is assigned to each functional module, and the corresponding safety level information of each module is recorded in the safety management database, providing a basis for subsequent safety isolation and communication management.

[0078] For example, the torque control software component in the powertrain domain is classified as ASIL-D based on risk assessment, and is therefore marked as a high-safety-level functional module; the steering assist software component in the chassis domain is classified as ASIL-C based, and is also a high-safety-level functional module; the lighting control software component in the body domain is classified as ASIL-A based, and is a low-safety-level functional module; and the entertainment information display module in the intelligent driving domain is classified as QM based, and is also a low-safety-level functional module.

[0079] Enable the memory protection unit at the hardware level of the domain controller to allocate independent memory address spaces for functional modules with different security levels. Set memory access permissions through the memory protection unit at the hardware level of the domain controller to prohibit functional modules with lower security levels from accessing the memory address space of functional modules with higher security levels.

[0080] By configuring the Memory Protection Unit (MPU) in the multi-core processor chip, an independent physical memory region is allocated to each high-security-level functional module, and a different physical memory region is allocated to low-security-level functional modules. At the same time, access control registers are set to prohibit the functional cores of low-security-level modules from accessing the memory regions of high-security-level modules, ensuring that high-security-level modules are not interfered with by the memory of low-security-level modules during operation.

[0081] Allocate physical memory from 0x20000000 to 0x2003FFFF to the ASIL-D level torque control module in the power domain, and allocate physical memory from 0x20040000 to 0x2005FFFF to the ASIL-A level lighting control module in the body domain. Set access permissions in the MPU register to prevent the lighting control module from accessing the memory area of ​​the torque control module.

[0082] A security partitioning mechanism is established at the operating system level to create security partitions for high-security-level functional modules. These security partitions isolate high-security-level functional modules from low-security-level functional modules in terms of time and space, ensuring that the operation of high-security-level functional modules is not affected by the failure of low-security-level functional modules.

[0083] By enabling the security partitioning function within the real-time operating system, an independent scheduling partition is created for each high-security-level functional module, with independent task queues and resource access tables configured. Low-security-level modules are assigned to different scheduling partitions, and the scheduling policy is strictly executed in the operating system scheduler according to partition priority, thus achieving complete isolation between high-security-level modules and low-security-level modules in terms of time slices and resource access.

[0084] Create partition P1 for ASIL-D level functional modules in the power domain, partition P2 for ASIL-C level functional modules in the chassis domain, partition P3 for ASIL-A level functional modules in the body domain, and partition P4 for the QM level infotainment module to ensure that P1, P2 and P3, P4 do not compete for resources during operating system scheduling.

[0085] The communication security monitoring module deployed in the middleware layer monitors the data transmission between functional cores in real time, performs integrity verification and identity authentication on the transmitted data, and blocks the corresponding communication link and sends a security alarm signal to the main control core when data is detected to be tampered with or accessed without authorization.

[0086] A communication security monitoring module is deployed in the middleware layer. It uses the CRC32 check algorithm to verify the integrity of data packets and adopts an identity authentication mechanism based on AES-128 encryption to authenticate the two communicating parties. When the data packet integrity verification fails or the identity authentication fails, the data link is immediately blocked through the interrupt mechanism, and a security alarm message is sent to the main control core through the CAN bus, including the functional module ID, fault type and timestamp information.

[0087] For example, when the power domain sends torque control commands to the chassis domain, the communication security monitoring module performs CRC32 verification on the data packets and verifies the message signature. If the verification fails, the middleware immediately blocks the data channel and sends an alarm to the main control core: Module ID = Power Domain, Fault Type = Data Tampering, Time = 12:30:15.

[0088] According to the fault management mechanism preset in the main control core, the health status information of each functional core is received. When a fault is detected in a functional core, the corresponding fault handling strategy is executed according to the security level of the faulty functional core. For faults of functional cores with high security level, a safe shutdown or switch to redundant backup is executed. For faults of functional cores with low security level, functional degradation or isolation is executed.

[0089] The main control core periodically polls the health status registers of each functional core and collects heartbeat signals. When a functional core fails to respond within three consecutive heartbeat cycles, the system searches the health status database for the safety level of the functional module it is running and executes corresponding handling strategies: for ASIL-D and ASIL-C level functional modules, the redundant backup core is activated and the faulty core is isolated and powered off; for ASIL-B, ASIL-A, and QM level modules, the function execution frequency is reduced or some non-critical functions are suspended to isolate the impact of the fault.

[0090] When a chassis domain functional core fails, and the steering assist software component it is running is detected to be at ASIL-C level, the main control core immediately switches to the pre-configured redundant functional core and performs initial loading, while sending system status logs; when the intelligent driving domain QM level entertainment module fails, only the UI refresh function of that module is suspended without affecting the operation of other modules.

[0091] Furthermore, the preferred step of creating security partitions for high-security-level functional modules and using these partitions to isolate high-security-level functional modules from low-security-level functional modules in time and space is as follows: A virtualization manager is enabled at the operating system level. The virtualization manager creates an independent virtual execution environment as a security partition for each high-security functional module. Each security partition is allocated independent virtual processor resources and virtual memory resources.

[0092] By loading a virtualization management program at the operating system level, an independent virtual machine instance is created for each ASIL-D or ASIL-C level functional module. Each virtual machine instance is bound to a dedicated virtual CPU core and virtual memory region, and an independent interrupt vector table and task queue are configured. This enables the virtual execution environment to have complete control and isolation over high-security modules, while ensuring that interrupts and memory are not shared between virtual machines.

[0093] For example, the ASIL-D level torque control module in the power domain creates a virtual machine VM1 in the virtualization management program, allocating 2 virtual CPU cores and 128MB of virtual memory; the ASIL-C level steering assist module in the chassis domain creates a virtual machine VM2, allocating 1 virtual CPU core and 64MB of virtual memory.

[0094] Configure memory isolation policies in the virtualization management program, set up independent memory page tables for each security partition, map the virtual memory address of the security partition to a specific area of ​​physical memory through the memory page tables, and set up access control lists in the virtualization management program to prohibit low-security functional modules from accessing the physical memory area corresponding to the security partition, thereby achieving space isolation.

[0095] In the virtualization management program, an independent page table is created for each security partition, mapping the virtual memory range of the security partition to a pre-allocated physical memory block. The access control list explicitly specifies the list of allowed module IDs, prohibiting other modules from accessing the physical memory block, thus achieving spatial isolation of physical memory.

[0096] For example, the VM1 page table maps virtual addresses 0x00000000-0x07FFFFFF to physical memory 0x20000000-0x27FFFFFF, allowing access only to the power domain module; the VM2 page table maps virtual addresses 0x00000000-0x03FFFFFF to physical memory 0x28000000-0x2BFFFFFF, allowing access only to the chassis domain module.

[0097] Configure a time-slicing scheduling mechanism in the virtualization hypervisor, allocate a fixed time window to each security partition. Within the time window allocated to a security partition, the virtualization hypervisor transfers complete control of the processor to the current security partition and forcibly suspends the execution of the current security partition at the end of the time window, switching to the time window of the next functional module. This ensures that functional modules with different security levels do not compete for processor resources at the same time, thus achieving time isolation.

[0098] The virtualization management program controls the execution of each security partition through a global clock and a time-slice scheduling table. Each security partition is allocated a fixed millisecond-level time window. When the time window ends, the current partition is suspended through a hardware interrupt, and the CPU control is switched to the next security partition, so as to realize the time-slice rotation execution of the multi-functional module.

[0099] If VM1 is allocated a 5-millisecond time window to execute and VM2 is allocated a 3-millisecond time window to execute, the virtualization hypervisor will rotate CPU control in turn according to the time slice table to ensure that VM1 and VM2 do not use processor resources at the same time.

[0100] Inter-level communication interfaces are set up in the virtualization management program. These interfaces employ a unidirectional data channel mechanism, allowing only low-security-level functional modules to send data requests to the security partitions of high-security-level functional modules. When a high-security-level functional module's security partition sends data to a low-security-level functional module, the data must undergo data filtering and integrity verification by the virtualization management program. An independent watchdog timer is configured for each security partition. The watchdog timer periodically monitors the operating status of the functional modules within that security partition. When a functional module within a security partition fails to respond within a preset time, the watchdog timer sends a partition fault signal to the virtualization management program. The virtualization management program then performs an isolation restart operation on that security partition without affecting the normal operation of other functional modules.

[0101] A one-way data channel is created between security partitions through the virtualization management program. Communication requests from low-security modules are passed to high-security modules after authentication and data integrity verification within the virtualization management program. Data sent by high-security modules must be filtered by the virtualization management program. At the same time, an independent watchdog timer is started for each security partition, which checks the task heartbeat signal in the partition at set intervals (e.g., 10 milliseconds). If no valid heartbeat is detected, an isolation restart operation is triggered, which only restarts the virtual machine instance of that security partition and does not affect the normal operation of other partitions.

[0102] For example, if the low-security entertainment module of VM4 sends a data request to the ASIL-D level module of the power domain of VM1, the virtualization management program will allow the transmission after performing AES-128 encryption verification and CRC32 integrity check on the request; when VM1 sends data to VM4, it first goes through the security filtering of the virtualization management program. If the VM1 watchdog timer detects that VM1 has not responded within 10 milliseconds, the virtualization management program will only isolate and restart VM1, without affecting the normal operation of the chassis domain of VM2 and the body domain of VM3.

[0103] like Figure 2As shown, this application also provides an automotive electronic control unit integration system 10, which includes a data acquisition module 11, a design module 12, a deployment module 13, and a partitioning module 14, as detailed below: The data acquisition module 11 is used to collect the functional requirements of various systems of the vehicle to build a functional requirements database. Based on the functional requirements database, the electronic control units are classified according to their functional types to obtain the functional classification results.

[0104] The acquisition module 11 collects the functional requirements and control signal types of various automotive systems in a unified manner, constructs a functional requirement database, and classifies electronic control units into hard real-time, soft real-time and non-real-time categories based on real-time requirements. At the same time, combined with the functional object type, the electronic control units are merged into functional types such as power domain, chassis domain, body domain and intelligent driving domain, thus forming a functional division result.

[0105] Design module 12 is used to design the corresponding domain controller based on the functional partitioning results, and to build a layered software architecture in the domain controller.

[0106] Based on the functional partitioning results, the design module 12 selects a multi-core processor chip and configures the number of functional cores and computational priority. At the same time, it configures the storage module, communication interface module and power management module, builds a domain controller and establishes a layered software architecture in the domain controller, including the driver layer, operating system layer, middleware layer and application layer, to provide the underlying hardware control, task scheduling, cross-core communication and algorithm execution environment for the operation of control algorithms of various functional types.

[0107] Deployment module 13 is used to deploy control algorithms of various functional types to the corresponding functional cores of the domain controller according to the layered software architecture.

[0108] The deployment module 13 encapsulates the control algorithms of each functional type into software components and deploys them to the corresponding functional cores according to the functional division results. It configures shared memory areas and message queues to realize data sharing and instruction transmission between cores, sets task cycles and execution sequences according to real-time levels, and uses the operating system scheduler to ensure that the control algorithms are executed according to priority and cycle.

[0109] The partitioning module 14 is used to partition the security levels of each functional module in the domain controller based on the functional core, and to isolate and monitor the communication security of each functional module according to different security levels.

[0110] By dividing module 14, a list of functional modules running in each functional core is obtained, and the security level of each functional module is evaluated in accordance with the ISO 26262 safety standard. High-security-level functional modules and low-security-level functional modules are strictly isolated in memory, processor time and virtual execution environment to achieve security partitioning in time and space. At the same time, a communication security monitoring module is deployed to perform data integrity verification and identity authentication. Through the fault management mechanism of the main control core, redundant switching, function degradation or isolation processing is performed on the functional core that fails, to ensure that the vehicle electronic control system can achieve centralized scheduling, collaborative control and safe and reliable operation among various functional types.

[0111] It should be noted that the order of the embodiments described above is merely for descriptive purposes and does not represent the superiority or inferiority of the embodiments. Furthermore, the above description focuses on specific embodiments of this application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps described in the claims can be performed in a different order than that shown in the embodiments and still achieve the desired results. Additionally, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired results. In some implementations, multitasking and parallel processing are also possible or may be advantageous.

[0112] The various embodiments in this application are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the device, equipment, and storage medium embodiments are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0113] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware, or by a program instructing the relevant hardware to implement them. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0114] The above are merely preferred embodiments of this application and are not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for integrating an automotive electronic control unit, characterized in that, include: Functional parameters and control signal types of various automotive systems are collected to construct a functional requirements database. Based on the real-time requirements of each system in the functional requirements database, electronic control units (ECUs) are categorized into a first control unit, a second control unit, and a third control unit, respectively. Real-time levels are determined based on these three control units. The ECUs within the first, second, and third control units are functionally classified according to the control signal types of each system in the functional requirements database. ECUs with similar control objects are grouped into the same functional type to obtain control object types. The total computational resource requirements of all ECUs within each functional type are calculated. Based on these total computational resource requirements, the required number of processor cores and storage capacity for the corresponding functional type are determined to obtain hardware resource configuration parameters. Finally, a functional partitioning result is constructed based on the real-time levels, the control object types, and the hardware resource configuration parameters. Based on the functional partitioning results, design the corresponding domain controller and build a layered software architecture in the domain controller; Based on the layered software architecture, the control algorithms for each functional type are deployed to the corresponding functional cores of the domain controller; Based on the core functionality, the security levels of each functional module in the domain controller are divided, and each functional module is isolated and its communication security is monitored according to different security levels.

2. The automotive electronic control unit integration method according to claim 1, characterized in that, The steps of calculating the total computing resource requirements of all electronic control units within each functional type, determining the number of processor cores and storage capacity required for the corresponding functional type based on the total computing resource requirements, and obtaining hardware resource configuration parameters include: Extract the total computing resource requirements of each electronic control unit within each functional type from the functional requirements database; wherein, the total computing resource requirements include the unit computing power requirement and the unit storage requirement. The unit computing power requirement of all electronic control units within the same functional type is accumulated to obtain the total computing power requirement of each functional type. The unit storage requirement of all electronic control units within the same functional type is accumulated to obtain the total storage requirement of each functional type. Based on the preset processor core unit computing power benchmark value, the total computing power requirement is divided by the processor core unit computing power benchmark value and rounded up to obtain the number of processor cores required for each function type. Based on the total storage requirements, the program storage capacity and data storage capacity are determined, and the storage capacity specifications for each functional type are obtained. Hardware resource configuration parameters are constructed based on the number of processor cores and the storage capacity specifications for each functional type.

3. The automotive electronic control unit integration method according to claim 1, characterized in that, The steps of designing the corresponding domain controller based on the functional partitioning results and building a layered software architecture in the domain controller include: A multi-core processor chip is selected based on the hardware resource configuration parameters in the functional partitioning results; wherein, the multi-core processor chip includes a main control core and multiple functional cores; Based on the real-time performance level in the functional division results, assign computational priorities to each functional core. Based on the storage capacity specifications in the functional partitioning results, configure the storage module, and configure the power management module and communication interface module according to the functional partitioning results. Design the corresponding domain controller using the multi-core processor chip, the computing priority, the storage module, the power management module, and the communication interface module. An operating system layer, a middleware layer, and an application layer are constructed in the domain controller to obtain a layered software architecture.

4. The automotive electronic control unit integration method according to claim 3, characterized in that, The step of deploying control algorithms for each functional type to the corresponding functional core of the domain controller according to the layered software architecture includes: Based on the application layer interface specification of the layered software architecture, the control algorithms for each functional type are encapsulated into independent software components. Based on the control object type of each function type in the functional division results, the software components belonging to each function type are deployed to the corresponding functional core.

5. The automotive electronic control unit integration method according to claim 3, characterized in that, The steps of classifying the security levels of each functional module in the domain controller based on the functional core, and isolating and monitoring the communication security of each functional module according to different security levels, include: Obtain a list of functional modules running on each functional core, and perform a security integrity level assessment on each functional module in the list to obtain functional modules with high security level and low security level. Independent memory address spaces are allocated to functional modules with different security levels, and memory access permissions are set through the memory protection unit at the hardware level of the domain controller. A security partition is created for the high-security-level functional module, and the security partition is used to isolate the high-security-level functional module from the low-security-level functional module in time and space. The system monitors data transmission between functional cores in real time. When data is detected to be tampered with or accessed without authorization, the system blocks the corresponding communication link and sends a security alarm signal to the main control core.

6. The automotive electronic control unit integration method according to claim 5, characterized in that, The step of creating a security partition for the high-security-level functional module, and using the security partition to isolate the high-security-level functional module from the low-security-level functional module in time and space, includes: A virtualization management program is enabled at the operating system layer, and the virtualization management program creates an independent virtual execution environment as a security partition for each high-security functional module. An independent memory page table is set up for each security partition. The virtual memory address of the security partition is mapped to a specific area of ​​physical memory through the memory page table. An access control list is set in the virtualization management program to prohibit the low-security-level functional modules from accessing the physical memory area corresponding to the security partition. A fixed time window is assigned to each of the security partitions. Within the time window assigned to a security partition, the virtualization management program transfers complete control of the processor to the current security partition and forcibly suspends the execution of the current security partition at the end of the time window, switching to the time window of the next functional module.

7. An integrated system for automotive electronic control units, characterized in that, include: The data acquisition module is used to collect functional parameters and control signal types of various automotive systems to construct a functional requirements database. Based on the real-time requirements of each system in the functional requirements database, electronic control units (ECUs) are classified into a first control unit, a second control unit, and a third control unit, respectively, and the real-time level is determined according to the first, second, and third control units. The ECUs within the first, second, and third control units are functionally classified according to the control signal types of each system in the functional requirements database. ECUs with similar control objects are grouped into the same functional type to obtain the control object type. The total computing resource requirements of all ECUs within each functional type are calculated, and the number of processor cores and storage capacity required for the corresponding functional type are determined based on the total computing resource requirements to obtain hardware resource configuration parameters. The functional division results are constructed based on the real-time performance level, the type of controlled object, and the hardware resource configuration parameters. The design module is used to design the corresponding domain controller based on the functional partitioning results, and to build a layered software architecture in the domain controller; The deployment module is used to deploy control algorithms of various functional types to the corresponding functional cores of the domain controller according to the layered software architecture. The partitioning module is used to partition the security levels of each functional module in the domain controller based on the functional core, and to isolate and monitor the communication security of each functional module according to different security levels.

Images