Data processing method and related product

Abstract

The invention discloses a data processing method and related products, and the method comprises the steps: determining a target physical binding core and a target agent condition according to a target mapping code in an obtained target call request based on a target mapping description table; and processing the target call request through a target RTE interface in the first core or a target virtual interface in the second core according to the target physical binding core and the target proxy condition. Thus, dynamic decision-making of cross-core communication is achieved by introducing the target mapping description table, the RTE interface or the virtual interface is dynamically selected according to the target physical binding core and the target agent condition, and the resource utilization rate is increased; meanwhile, in addition, through the centralized management of the target mapping description table on the RTE interface, the interface configuration and expansion process is simplified, the development complexity is reduced, a dynamic updating rule is supported to adapt to the function iteration requirement, a fixed agent task or cross-core interlayer packaging is not needed, the communication efficiency is improved, and the resource occupation is optimized.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a data processing method and related products. Background Technology

[0002] As in-vehicle electronic and electrical architecture evolves from distributed control to centralized, domain-controlled, and central computing platforms, in-vehicle computing units have formed a multi-core heterogeneous structure. The M core is responsible for real-time control and safety-related tasks, such as vehicle chassis control and body signal processing; the A core handles non-real-time tasks, such as human-machine interaction, multimedia processing, AI algorithms, and vehicle-to-cloud communication. In a vehicle-to-cloud integrated architecture, the two must work closely together to meet the requirements of complex application scenarios.

[0003] However, the RTE (Run-Time Environment) interface is fixedly bound to a specific core (usually the M core) during the system initialization phase. The mapping relationship cannot be dynamically changed according to the running state, which reduces the dynamic migration capability and results in low resource utilization. At the same time, when the A core application accesses the M core control function, it has to go through a fixed proxy task or cross-core intermediate layer encapsulation, resulting in low communication efficiency and high resource consumption. Summary of the Invention

[0004] In view of the above problems, this application provides a data processing method and related products, which aim to improve communication efficiency and resource utilization.

[0005] The embodiments of this application disclose the following technical solutions:

[0006] In a first aspect, embodiments of this application provide a data processing method, the method comprising:

[0007] Obtain the target invocation request; wherein, the target invocation request includes the target mapping code;

[0008] Based on the target mapping description table, the target physical binding core and target proxy conditions are determined according to the target mapping code in the target call request. The target mapping description table is used to describe the mapping relationship of at least one runtime environment RTE interface in the first core. The target mapping description table includes at least one mapping record. The mapping record includes a mapping code, a physical binding core, and proxy conditions. The mapping code is obtained by encoding the interface information data of the corresponding RTE interface. There is a one-to-one correspondence between each mapping record in the at least one mapping record and each RTE interface in the at least one RTE interface. There is also a one-to-one correspondence between each mapping record in the at least one mapping record and each virtual interface in the at least one virtual interface in the second core.

[0009] Based on the target physical binding core and target proxy conditions, the target call request is processed through the target RTE interface in the first core or the target virtual interface in the second core.

[0010] Optionally, the target mapping description table may also be generated in the following manner:

[0011] Obtain interface information data for at least one RTE interface; the interface information data includes triplet identifiers and access attributes;

[0012] The triplet identifiers in the information data of each interface are compressed to determine the mapping code corresponding to each RTE interface.

[0013] Based on the access attributes in the information data of each interface, determine the physical binding core and proxy conditions corresponding to each RTE interface;

[0014] Construct a target mapping description table based on at least one mapping code, at least one physical binding core, and at least one proxy condition.

[0015] Optionally, based on the target physical binding core and target proxy conditions, the target invocation request is processed through the target RTE interface in the first core or the target virtual interface in the second core, including:

[0016] If the target physical binding core indicator is the first core, then determine whether the actual operating conditions meet the target proxy conditions;

[0017] If the actual operating conditions meet the target proxy conditions, the target call request will be processed through the target RTE interface or the target virtual interface.

[0018] If the actual operating conditions do not meet the target proxy conditions, the target call request will be processed through the target RTE interface.

[0019] Optionally, the target invocation request is processed through the target RTE interface or the target virtual interface, including:

[0020] Obtain the actual load value of the first core;

[0021] If the actual load value is greater than the preset load threshold, the target call request will be processed through the target virtual interface;

[0022] If the actual load value is less than or equal to the preset load threshold, the target call request will be processed through the RTE interface.

[0023] Secondly, embodiments of this application provide a data processing apparatus, the apparatus comprising:

[0024] The acquisition unit is used to acquire the target invocation request; wherein, the target invocation request includes the target mapping code;

[0025] The determining unit is used to determine the target physical binding core and target proxy conditions based on the target mapping code in the target call request, according to the target mapping description table. The target mapping description table describes the mapping relationship of at least one runtime environment RTE interface in the first core. The target mapping description table includes at least one mapping record. The mapping record includes a mapping code, a physical binding core, and proxy conditions. The mapping code is obtained by encoding the interface information data of the corresponding RTE interface. Each mapping record in the at least one mapping record has a one-to-one correspondence with each RTE interface in the at least one RTE interface. Each mapping record in the at least one mapping record has a one-to-one correspondence with each virtual interface in the at least one virtual interface in the second core.

[0026] The data processing unit is used to process target call requests through the target RTE interface in the first core or the target virtual interface in the second core, based on the target physical binding core and target proxy conditions.

[0027] Optionally, it also includes a generation unit for generating a target mapping description table in the following manner:

[0028] Obtain interface information data for at least one RTE interface; the interface information data includes triplet identifiers and access attributes;

[0029] The triplet identifiers in the information data of each interface are compressed to determine the mapping code corresponding to each RTE interface.

[0030] Based on the access attributes in the information data of each interface, determine the physical binding core and proxy conditions corresponding to each RTE interface;

[0031] Construct a target mapping description table based on at least one mapping code, at least one physical binding core, and at least one proxy condition.

[0032] Optionally, the data processing unit is used for:

[0033] If the target physical binding core indicator is the first core, then determine whether the actual operating conditions meet the target proxy conditions;

[0034] If the actual operating conditions meet the target proxy conditions, the target call request will be processed through the target RTE interface or the target virtual interface.

[0035] If the actual operating conditions do not meet the target proxy conditions, the target call request will be processed through the target RTE interface.

[0036] Optionally, the data processing unit is used for:

[0037] Obtain the actual load value of the first core;

[0038] If the actual load value is greater than the preset load threshold, the target call request will be processed through the target virtual interface;

[0039] If the actual load value is less than or equal to the preset load threshold, the target call request will be processed through the RTE interface.

[0040] Thirdly, embodiments of this application provide a control device, including a processor and a memory, wherein the memory is used to store programs, instructions or code, and the processor is used to execute the programs, instructions or code in the memory to perform the data processing method as described in the first aspect.

[0041] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program, which is loaded by a processor to execute the data processing method as described in the first aspect.

[0042] Beneficial effects:

[0043] The data processing method provided in this application embodiment determines the target physical binding core and target proxy conditions based on the target mapping code in the obtained target call request, according to the target mapping description table; and processes the target call request through the target RTE interface in the first core or the target virtual interface in the second core, according to the target physical binding core and target proxy conditions.

[0044] The target call request includes a target mapping code; the target mapping description table is used to describe the mapping relationship of at least one runtime environment RTE interface in the first core. The target mapping description table includes at least one mapping record. The mapping record includes a mapping code, a physical binding core, and proxy conditions. The mapping code is obtained by encoding the interface information data of the corresponding RTE interface. Each mapping record in the at least one mapping record has a one-to-one correspondence with each RTE interface in the at least one RTE interface. Each mapping record in the at least one mapping record has a one-to-one correspondence with each virtual interface in the at least one virtual interface in the second core.

[0045] Thus, by introducing a target mapping description table, dynamic decision-making for cross-core communication is achieved. The RTE interface or virtual interface is dynamically selected based on the target physical binding core and the target proxy conditions, thereby improving resource utilization. In addition, the centralized management of RTE interfaces through the target mapping description table simplifies the interface configuration and extension process, reduces development complexity, and supports dynamic rule updates to adapt to functional iteration needs. This eliminates the need for fixed proxy tasks or cross-core intermediate layer encapsulation, improving communication efficiency and optimizing resource consumption. Attached Figure Description

[0046] To more clearly illustrate the technical solutions 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.

[0047] Figure 1 A flowchart illustrating a data processing method provided in an embodiment of this application;

[0048] Figure 2 A schematic diagram of a data processing flow provided in an embodiment of this application;

[0049] Figure 3 This is a schematic diagram of the structure of a data processing device provided in an embodiment of this application;

[0050] Figure 4 This is a schematic diagram of the structure of a control device provided in an embodiment of this application. Detailed Implementation

[0051] As described above, the binding relationship between the RTE interface and the physical core (such as the M core and A core) in the relevant technologies is statically configured, and the execution position of the interface cannot be dynamically adjusted according to the real-time status of the system (such as load, power consumption, and scenario mode).

[0052] As an example, if an interface is fixedly bound to the M core, but the M core is currently overloaded (such as processing real-time control tasks), while the A core is idle, then the interface cannot be migrated to the A core for execution, resulting in the M core being overloaded and the A core being idle.

[0053] As an example, in low-power scenarios (such as when the vehicle is stationary), if all interfaces are still fixed to execute on the high-performance M core and cannot be switched to the low-power A core, energy consumption will increase.

[0054] As an example, when remotely controlling a cloud desktop, if critical interfaces (such as battery management) are fixedly bound to the M core, and the M core cannot respond in time due to network latency or computing pressure, it will cause the remote control to fail.

[0055] Therefore, it can be seen that the mapping relationship cannot be dynamically changed according to the running status, which reduces the dynamic migration capability and results in low resource utilization. At the same time, when the A core application accesses the M core control function, it has to go through a fixed proxy task or cross-core intermediate layer encapsulation, resulting in low communication efficiency and high resource consumption.

[0056] Based on this, embodiments of this application provide a data processing method and related products. The method includes: determining the target physical binding core and target proxy conditions based on the target mapping code in the obtained target call request according to the target mapping description table; and processing the target call request through the target RTE interface in the first core or the target virtual interface in the second core according to the target physical binding core and target proxy conditions.

[0057] The target call request includes a target mapping code; the target mapping description table is used to describe the mapping relationship of at least one runtime environment RTE interface in the first core. The target mapping description table includes at least one mapping record. The mapping record includes a mapping code, a physical binding core, and proxy conditions. The mapping code is obtained by encoding the interface information data of the corresponding RTE interface. Each mapping record in the at least one mapping record has a one-to-one correspondence with each RTE interface in the at least one RTE interface. Each mapping record in the at least one mapping record has a one-to-one correspondence with each virtual interface in the at least one virtual interface in the second core.

[0058] Thus, by introducing a target mapping description table, dynamic decision-making for cross-core communication is achieved. The RTE interface or virtual interface is dynamically selected based on the target physical binding core and the target proxy conditions, thereby improving resource utilization. In addition, the centralized management of RTE interfaces through the target mapping description table simplifies the interface configuration and extension process, reduces development complexity, and supports dynamic rule updates to adapt to functional iteration needs. This eliminates the need for fixed proxy tasks or cross-core intermediate layer encapsulation, improving communication efficiency and optimizing resource consumption.

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

[0060] The collection and processing of relevant data (including but not limited to experimental data, test data, simulation data, user data, etc.) involved in this application shall strictly comply with the requirements of national laws and regulations when applied in the following embodiments, obtain the informed consent or separate consent of the subject obtaining the data information, and carry out data use and processing within the scope of laws and regulations and the authorization of the subject.

[0061] See Figure 1 The figure is a flowchart illustrating a data processing method provided in an embodiment of this application.

[0062] Combination Figure 1As shown, the data processing method provided in this application embodiment may include:

[0063] S11: Obtain the target call request.

[0064] The target invocation request includes the target mapping code.

[0065] A target call request refers to a request initiated by an external source (such as a cloud desktop, other cores or modules) that needs to be processed. A target call request may include, but is not limited to, information such as request type (such as data reading, control command), target interface identifier (such as interface ID or name), and parameters (such as data content, priority).

[0066] The target mapping code refers to a key field carried in the target call request, used to uniquely identify the target interface or service. The target mapping code can be the result of processing interface information, such as being generated through a hash algorithm or predefined encoding rules.

[0067] It should be understood that, in the embodiments of this application, the mapping code is used to quickly locate the interface or service corresponding to the request, avoiding fuzzy matching or traversal search, thus improving processing efficiency. At the same time, the external caller does not need to know the specific physical location of the interface or proxy rules; it only needs to initiate the request through the mapping code, reducing coupling.

[0068] S12: Based on the target mapping description table, determine the target physical binding core and target proxy conditions according to the target mapping code in the target invocation request.

[0069] The target mapping description table is used to describe the mapping relationship of at least one runtime environment RTE interface in the first core. The target mapping description table includes at least one mapping record, and the mapping record includes the mapping code, physical binding core and proxy conditions.

[0070] The RTE (Runtime Environment) interface is used to provide specific functions (such as data acquisition and control command issuance).

[0071] The mapping code is obtained by encoding the interface information data of the corresponding RTE interface.

[0072] Each mapping record in at least one mapping record has a one-to-one correspondence with each RTE interface in at least one RTE interface, and each mapping record in at least one mapping record has a one-to-one correspondence with each virtual interface in at least one virtual interface in the second core.

[0073] The Target Mapping Description Table (MDT) is a predefined configuration table used to describe the mapping relationships of all RTE interfaces in the first core.

[0074] Each mapping record corresponds to one RTE interface and contains three core fields:

[0075] Mapping code: Matches the target mapping code in the request, used for quick record lookup.

[0076] Physical binding core: Specifies the physical core (such as M core, A core) that the corresponding interface is currently bound to, which is the actual execution location of the interface.

[0077] The proxy condition defines the conditions under which interface tasks should be migrated to other cores (or executed on the current core) and proxied (e.g., high load, failure, security policy).

[0078] The one-to-one correspondence means that each mapping record uniquely corresponds to one RTE interface, ensuring the uniqueness of the interface configuration. Each mapping record also corresponds to a virtual interface in the second core. The virtual interface is a proxy or extension of the physical interface, used to support cross-core task migration.

[0079] It should be understood that, in this embodiment of the application, by centrally storing the mapping relationships of all RTE interfaces in the MDT, unified configuration, updates, and maintenance are facilitated, reducing management complexity. Simultaneously, through the mapping between physical cores and virtual interfaces, cross-core resource reuse is achieved, adapting to the collaborative needs of heterogeneous cores (such as high-performance M cores and low-power A cores) in vehicle-cloud integrated scenarios.

[0080] S13: Based on the target physical binding core and target proxy conditions, process the target call request through the target RTE interface in the first core or the target virtual interface in the second core.

[0081] It should be understood that processing cores can be dynamically selected based on real-time status to avoid resource idleness or overload caused by fixed binding; at the same time, the resources of high-priority cores (such as M cores) can be released through target proxy conditions to handle critical tasks (such as real-time control).

[0082] It should be understood that, in the embodiments of this application, dynamic decision-making for cross-core communication is achieved by introducing a target mapping description table. The RTE interface or virtual interface is dynamically selected based on the target physical binding core and the target proxy conditions, thereby improving resource utilization. In addition, the centralized management of the RTE interface through the target mapping description table simplifies the interface configuration and extension process, reduces development complexity, and supports dynamic rule updates to adapt to functional iteration requirements. This eliminates the need for fixed proxy tasks or cross-core intermediate layer encapsulation, thereby improving communication efficiency and optimizing resource consumption.

[0083] In one possible implementation of the data processing method provided in the above embodiments, the method further includes generating a target mapping description table in the following manner:

[0084] A1: Obtain interface information data for at least one RTE interface.

[0085] The interface information data includes triplet identifiers and access attributes.

[0086] Interface information data refers to the metadata used to describe each RTE interface, and contains two core fields:

[0087] The triplet identifier is used to describe the triplet information that uniquely identifies the interface, which may include, but is not limited to, interface type (such as data acquisition, control command), core (such as M core, A core), and interface function ID (such as sensor interface ID).

[0088] Access attributes are used to define the access rules and constraints of an interface, and may include, but are not limited to:

[0089] Security levels (such as high, medium, and low) are used to determine whether the interface allows cross-core access or cloud desktop calls;

[0090] The load threshold describes the upper limit of CPU / memory usage on the core where the interface resides; exceeding this threshold triggers proxy migration.

[0091] Fault recovery strategies (such as automatic switching and manual intervention) are used to describe how to handle interface failures;

[0092] Priority indicates the execution priority of the interface task (e.g., real-time control tasks take precedence over log recording tasks).

[0093] It should be understood that the triplet identifier and access attributes can fully cover the functionality, location and constraints of the interface, providing complete information for subsequent steps.

[0094] A2: Compress the triplet identifiers in the information data of each interface to determine the mapping code corresponding to each RTE interface.

[0095] Compression processing refers to converting triplet identifiers (such as strings or structured data) into a more compact encoded form (such as hash values ​​or integer IDs) to generate a mapping code.

[0096] As an example, the triplet is identified as (data acquisition, M core, Sensor_001), and the compressed mapping code may be 0x1A3F (hash value) or 1001 (integer ID).

[0097] It should be understood that since the mapping code is usually shorter than the original triplet identifier (e.g., a 4-byte hash value vs. a string of tens of bytes), storage space can be reduced. At the same time, the mapping code, as the index key of the MDT, can speed up the location of the mapping record by the target mapping code (e.g., the time complexity of hash table lookup is O(1)), improving the efficiency of subsequent lookups.

[0098] A3: Based on the access attributes in the information data of each interface, determine the physical binding core and proxy conditions corresponding to each RTE interface.

[0099] Physical binding to a core means determining the default physical core to which an interface is bound based on the core and priority in the access attributes (e.g., a high-priority interface is bound to the M core, and a low-priority interface is bound to the A core).

[0100] Proxy conditions refer to the rules that trigger task migrations extracted from access attributes, for example:

[0101] Load conditions: When the CPU utilization of the core where the interface is located is > 80%, migrate to the virtual interface of the second core;

[0102] Security conditions: If the interface security level is "high", then execution is only allowed on the M core, and cross-core access is prohibited;

[0103] Fault conditions: If the interface fails to detect heartbeat three times in a row, it will automatically switch to the backup virtual interface.

[0104] It should be understood that dynamically binding cores through access attributes avoids the resource waste caused by fixed binding (such as low-priority interfaces occupying M cores). At the same time, proxy conditions support failover and load balancing, improving system resilience.

[0105] A4: Construct a target mapping description table based on at least one mapping code, at least one physical binding core, and at least one proxy condition.

[0106] It should be understood that, in this embodiment, by centrally storing the mapping relationships of all interfaces, unified configuration, updates, and maintenance are facilitated. Furthermore, when adding a new interface, only one mapping record needs to be added, without modifying the system architecture.

[0107] In one possible implementation of the data processing method provided in the above embodiments, step S13 may include:

[0108] C1: If the target physical binding core indicator is the first core, then determine whether the actual running conditions meet the target proxy conditions.

[0109] The target physical binding core refers to the default execution core of the interface obtained from the target mapping description table (MDT) (e.g., the first core is the M core and the second core is the A core).

[0110] Target agent conditions refer to the rules (such as load thresholds, security policies, and fault signals) defined in the MDT that trigger task migration.

[0111] It should be understood that by first determining the default execution core and then checking migration conditions, unnecessary proxy operations are avoided, reducing system overhead. At the same time, deciding whether to migrate tasks based on real-time operating conditions (such as load and security) improves resource utilization and system resilience.

[0112] C2: If the actual operating conditions meet the target proxy conditions, then the target call request will be processed through the target RTE interface or the target virtual interface.

[0113] It should be understood that when the actual operating conditions meet the proxy conditions (such as low M-core load), the system needs to decide whether to process the request through the target RTE interface (default interface) or the target virtual interface (proxy interface).

[0114] The target virtual interface refers to the logical interface created on the second core (such as core A) to proxy the tasks of the first core (such as migrating tasks to the virtual interface of core A when the load on core M is not high).

[0115] It should be understood that, in the embodiments of this application, tasks can be migrated from the first core to the second core through a virtual interface to avoid single-core overload and optimize resource utilization.

[0116] In one possible implementation, step C2 may include:

[0117] D1: Get the actual load value of the first core.

[0118] Actual load refers to real-time monitoring of load metrics such as CPU utilization and memory usage of the first core (e.g., M core). It should be understood that decisions can be made based on actual load values, avoiding resource waste or performance bottlenecks caused by static configuration.

[0119] D2: If the actual load value is greater than the preset load threshold, the target call request will be processed through the target virtual interface.

[0120] As an example, when the load on the first core exceeds a preset load threshold (e.g., 80%), the task is migrated to the virtual interface of the A core.

[0121] It should be understood that this can prevent the M core from experiencing task delays or loss due to excessive load. At the same time, the idle resources of the A core can be utilized to process tasks, improving the overall system throughput.

[0122] D3: If the actual load value is less than or equal to the preset load threshold, the target call request will be processed through the RTE interface.

[0123] It should be understood that when the first core is under normal load, tasks are processed directly through the default RTE interface. This avoids unnecessary task migration and reduces cross-core communication latency. Simultaneously, executing tasks on the default core reduces cache invalidation and memory access latency.

[0124] C3: If the actual operating conditions do not meet the target proxy conditions, the target call request will be processed through the target RTE interface.

[0125] It should be understood that when actual operating conditions do not meet the proxy conditions (such as normal M-core load and no security risks), tasks are processed directly through the default RTE interface. In this way, when there is no migration requirement, processing is done directly through the default interface, reducing decision-making latency. At the same time, unnecessary proxy condition checks are avoided, reducing system complexity.

[0126] Based on the data processing method provided in the above embodiments, this application also provides a data processing system, which mainly includes the following functional modules: Interface Abstraction & Mapping Module, Cross-core Communication Module, Dynamic Arbitration & Migration Module, Cloud-Vehicle Trust Control Module, and Context Awareness & Policy Engine.

[0127] It should be understood that the data processing system provided in this application embodiment can be used to implement the data processing method described in the above embodiments. The above five modules work together in the vehicle-side central computing unit and realize remote interface access and dynamic trust boundary management through the cloud desktop environment.

[0128] In one possible implementation, combining Figure 2 The data processing flow shown below will be described in detail for each module.

[0129] The Interface Abstraction and Mapping module is responsible for performing structured abstraction and mappable description of the original RTE interface on the M core (first core).

[0130] As an example, during the system initialization phase, all registered RTE interfaces in the M core are scanned, and their interface identifiers (Service ID, Instance ID, Method ID) and access attributes (real-time level, security level, context dependency) are extracted. Then, the interface information is written into the Mapping Descriptor Table (MDT). Furthermore, a corresponding virtual proxy is generated on the A core (second core) side, and a one-to-one correspondence is formed between the proxy and the M core interfaces through the mapping table. In this way, when the cloud desktop is accessed, the proxy interface can also be called through the mapping table, thereby realizing remote transparent access.

[0131] The Interface Descriptor Compression (Algorithm A1) algorithm uses layered hash encoding to compress and map the RTE interface triples (ServiceId, InstanceId, MethodId) into unique mapping codes, achieving high-speed indexing and low storage overhead. It also employs a layered hash and parallel index structure to achieve millisecond-level interface mapping lookup.

[0132] As an example, Algorithm A1 can transform the three identifiers of the RTE interface into a hierarchical, compressible, and hashable descriptor, compressing them into an "interface mapping code" (MappingCode). This allows for mapping at runtime by simply looking up an integer / fixed-length key. For instance, the inputs are ServiceId, InstanceId, and MethodId (which can be strings / hexadecimal), and the outputs can be MappingCode (fixed-length, reversible) and MappingEntry (containing the current execution core, permissions, version, and scene tag).

[0133] As an example, the execution steps of algorithm A1 can be:

[0134] Step 11: Layered coding.

[0135] First layer: Use a short hash for ServiceId or directly use the assigned integer ID;

[0136] The second layer: InstanceId is used for range-based encoding (such as vehicle series, stage, operating domain, etc. can be mapped in);

[0137] Third layer: MethodId is encoded in high-level code (to ensure that methods under the same Service do not conflict);

[0138] Step 12: Layer merging.

[0139] The three-layer code is concatenated in fixed bits, for example, 10 bits + 10 bits + 12 bits.

[0140] Step 13: Add version stamp.

[0141] To support interface upgrades, add a 1-2 bit version field.

[0142] Step 14: Write to the mapping table.

[0143] Using MappingCode as the key, write in "which core it is currently running on", "whether it is portable", and "security level".

[0144] Each time core A receives a call request, it can determine the call path through MappingCode. As an example, the interface on core M is 0x1020 / 1 / 0x1001, which is encoded as 0x35AF2. By looking up the table, we can find that: currently bound core = core M, security level = medium, and migrateable = yes. If it is subsequently migrated to core A, only this table entry needs to be updated, and the business code does not need to be modified.

[0145] The cross-core communication and execution module is responsible for enabling low-latency, secure data transmission and remote procedure calls (RPC) between the A core and the M core.

[0146] As an example, when an A-core application requests a certain RTE interface, the communication module determines the core currently bound to the interface based on the mapping table. If the interface mapping target is the M-core, the module sends the call request through shared memory or a lightweight message bus (such as RTP-Lite). After receiving the request, the M-core executes the task and returns the result. If the current scenario allows the A-core to proxy the execution, the cross-core communication and execution module triggers the migration logic.

[0147] The Core-Aware Scheduling Protocol (Algorithm A2) introduces a dual-channel latency optimization mechanism (the main channel is used for data calls, and the auxiliary channel is pre-allocated with acknowledgment signals) to achieve dynamic switching between synchronous and asynchronous calls.

[0148] As an example, Algorithm A2 can employ a "dual-channel + predictive receipt" cross-core call protocol: the main channel transmits the actual call data; the secondary channel only transmits lightweight receipts such as "received / busy / wait a moment / change to asynchronous"; allowing the initiating core (usually core A) to know as early as possible whether the other party is busy, thereby dynamically deciding "whether to block and wait for the result". As an example, the input can be an interface call request with MappingCode, and the output can be ① an immediate receipt (successfully accepted / please queue / change to asynchronous) ② the final business result.

[0149] As an example, the execution steps of algorithm A2 can be as follows: When core A initiates a call, it first determines the target physical binding core locally based on the MappingCode; sends the business data through the "main channel"; and simultaneously listens for lightweight receipts on the "secondary channel"; if the secondary channel quickly returns "queuing / core busy", core A adds this call to the asynchronous queue without blocking the main thread; if the secondary channel returns "can be executed immediately", core A remains synchronously waiting; the final result is still sent back through the main channel.

[0150] As an example, during remote diagnostics of a parked vehicle, the number of requests from the cloud desktop to the A core and then to the M core may surge within a short period of time. With this protocol, the M core can immediately reply "Received, but needs to queue," so the A core will not think "packet lost / need to retry," nor will it fill up the A core's thread pool.

[0151] The dynamic arbitration and migration module is used to realize the dynamic execution migration and reuse of interfaces between the M core and the A core, ensuring system resource balance and service continuity.

[0152] As an example, the dynamic arbitration and migration module is used to monitor the resource utilization of the M core, the task queue length, and the power consumption status. When the load on the M core exceeds the threshold or enters a low-power mode, the interface migration mechanism is triggered. The execution agents of some non-real-time interfaces are migrated to the A core for execution, and the execution position is updated in the mapping table. When the M core recovers, it can automatically migrate back.

[0153] The Load-Aware Dynamic Rebinding (LADR) algorithm (Algorithm A3) continuously monitors the operating parameters of the M cores (CPU utilization, average task latency, priority distribution) and combines this with predictions of available resources on the A cores to calculate a migration priority vector. As an example, the calculation formula can be:

[0154] ;

[0155] in, For scene weights.

[0156] As an example, Algorithm A3 can continuously monitor the load and queues of the M-core and A-core; assign a dynamic migration score to each migrateable interface; interfaces with higher scores are migrated to the A-core first; it also supports migration back. As an example, the input can be the current CPU of the M-core, task queue length, interface call frequency, interface real-time level, security level, and current vehicle operating status (driving / parking); the output can be a migration candidate list and the mapping table entries to be updated.

[0157] As an example, algorithm A3 can perform the following steps:

[0158] (1) Sampling: Sample the running data of the M core and the statistics of interface calls once every cycle (e.g., 100ms).

[0159] (2) Scoring: For each interface "marked as portable", the scoring formula is as follows:

[0160] ;

[0161] Among them, the busier the M core is, the larger the Score is; the lower the security level, the easier it is to migrate; the current scenario is "parking / remote maintenance", so the Scene_Factor is high.

[0162] (3) Sort: Sort by score from highest to lowest.

[0163] (4) Migration: For the Top N interfaces, modify the mapping table, change the execution core to core A, and generate proxy execution instances in core A.

[0164] (5) Regression: When the M core recovers and the overall Score decreases, the regression is performed according to the reverse rule.

[0165] As an example, during driving, the scores of interfaces with high safety levels and strong real-time performance will be lowered by the coefficient and will hardly be migrated; during parking diagnostics, the scores of a large number of interfaces with low real-time performance will be raised and will be migrated to the A core or cloud proxy in batches.

[0166] The vehicle-cloud trust control and authorization module is used to establish a secure and adjustable trust boundary between the cloud desktop and the vehicle's multi-core system.

[0167] As an example, when the cloud desktop accesses the vehicle via VPN or V2X link, the module generates a temporary trust context and dynamically adjusts permissions based on the vehicle status (driving / parking / remote maintenance). If in "parking + remote diagnostics" mode, a temporary token can be granted to the A core to access the M core's diagnostic interface. In driving mode, the trust boundary is automatically tightened, allowing only local calls.

[0168] The Dynamic Trust Domain Transfer (DTDT) algorithm (Algorithm A4) can dynamically generate access whitelists and time tokens based on vehicle operating status, driving mode, and cloud desktop authentication information. For example, when the vehicle enters parking mode and cloud authentication is successful, the system triggers a trust boundary migration, opening some interface permissions from the M core to the A core or cloud desktop proxy.

[0169] As an example, Algorithm A4 can build a "trust domain state machine"; based on three dimensions—"vehicle operating status + cloud authentication status + sensitivity level of the requested interface"—it dynamically determines which layer of the current trust domain can be accessed; then, this "accessible layer" is written back into the permission field of the interface mapping table. As an example, the input can be vehicle status (P / N / R / D, parked, whether someone is present), cloud desktop authentication result (certificate, token, session ID), and the sensitivity level of the accessed interface; the output can be 1) the current valid trust domain level; 2) a list of accessible interfaces; and 3) the token's expiration date.

[0170] As an example, algorithm A4 can perform the following steps:

[0171] (1) Scene recognition: The vehicle enters the "parking + remote maintenance" mode;

[0172] (2) Verify upstream: The cloud desktop has passed the unified certification of the car manufacturer (such as KMS returning a signature certificate);

[0173] (3) Computation trust level: Scenario allowed + cloud trusted → Trust domain floated up one layer (from "local A core only" to "cloud → A core → some M cores");

[0174] (4) Refresh mapping: Write the RTE interfaces that can be accessed in this session into a "dynamic whitelist";

[0175] (5) Timed recycling: Once the vehicle leaves the parking area and starts driving, the state machine goes back, the whitelist is destroyed and the mapping is recycled.

[0176] The operational status perception and strategy decision-making module acts as the system's strategy hub, responsible for collecting vehicle operational status, network conditions, and computing power indicators to drive the decision-making and scheduling of the aforementioned modules.

[0177] As an example, the runtime status awareness and strategy decision-making module can collect real-time information such as M-core and A-core load, network bandwidth, vehicle speed, driving mode, and cloud connection status; predict the computing power fluctuation trend in the next 1 to 3 seconds based on the status model; and output arbitration decisions through the strategy engine to drive the actions of modules such as migration, mapping, and trust.

[0178] The Context Fusion Policy Engine (CFPE) (Algorithm A5) integrates multi-dimensional contextual information (running load, vehicle speed, cloud connection latency, etc.) and uses a multi-objective optimization model to calculate global policy priorities. For example, when the vehicle speed is >5km / h and the load on the M core is <60%, the system prioritizes migrating the interface back to the M core; when the cloud latency is <50ms and the load on the M core is >80%, execution is migrated to the A core.

[0179] As an example, algorithm A5 can unify the "vehicle's running context", "cloud connection context", and "multi-core resource context" into a single context view; calculate a "risk / cost / benefit" score for each context; perform a multi-objective optimization, and output the "strategy combination that should be activated at the current moment".

[0180] As an example, the input could be:

[0181] Vehicle: speed, gear, whether it is autonomous driving, manned / unmanned;

[0182] Resources: M / A core CPU, memory, interface queue length;

[0183] Network: Cloud RTT, packet loss, whether it uses the car manufacturer's private network;

[0184] Security: Current session trustworthiness, certificate remaining time.

[0185] Correspondingly, the output can be whether interface migration is allowed; whether trust domain floating is allowed; whether cloud desktops are allowed to directly access the A core; and the effective time for migration / authorization.

[0186] As an example, algorithm A5 can perform the following steps:

[0187] (1) Context acquisition: Environmental data is acquired at a frequency of 100~500ms;

[0188] (2) Indicator normalization: Convert vehicle speed, delay, CPU, etc. into evaluation values ​​in the range of 0 to 1;

[0189] (3) Multi-objective scoring:

[0190] ;

[0191] Among them, while driving: α, β↑, leaning towards safety and real-time; while parked: γ, δ↑, leaning towards resource utilization and cloud accessibility.

[0192] Among them, the corresponding "strategy template" (such as driving strategy, remote maintenance strategy, diagnosis strategy, resource alarm strategy) is selected according to the range in which the score falls; if the dynamic arbitration module gets "allow migration = yes"; the trust module gets "trust domain = medium"; and the cross-core communication module gets "allow asynchronous = yes".

[0193] As an example, with current vehicle speed = 0, cloud RTT = 30ms, M-core load = 85%, and security level = enterprise network, the engine will output: Allow A3 migration, allow A4 trust escalation, and allow A2 to run asynchronously; with current vehicle speed = 60km / h and cloud RTT = 120ms, the output will be: Prohibit A4 trust escalation, and only allow local M-core execution.

[0194] Based on the data processing method provided in the above embodiments, see [link to relevant documentation]. Figure 3 This application also provides a schematic diagram of the structure of a data processing device.

[0195] Combination Figure 3 As shown, the data processing apparatus 30 provided in this embodiment includes:

[0196] The acquisition unit 31 is used to acquire the target invocation request; wherein, the target invocation request includes the target mapping code;

[0197] The determining unit 32 is used to determine the target physical binding core and target proxy conditions based on the target mapping code in the target call request, according to the target mapping description table. The target mapping description table is used to describe the mapping relationship of at least one runtime environment RTE interface in the first core. The target mapping description table includes at least one mapping record. The mapping record includes a mapping code, a physical binding core, and proxy conditions. The mapping code is obtained by encoding the interface information data of the corresponding RTE interface. Each mapping record in the at least one mapping record has a one-to-one correspondence with each RTE interface in the at least one RTE interface. Each mapping record in the at least one mapping record has a one-to-one correspondence with each virtual interface in the at least one virtual interface in the second core.

[0198] The data processing unit 33 is used to process the target call request through the target RTE interface in the first core or the target virtual interface in the second core, based on the target physical binding core and the target proxy conditions.

[0199] Optionally, it also includes a generation unit for generating a target mapping description table in the following manner:

[0200] Obtain interface information data for at least one RTE interface; the interface information data includes triplet identifiers and access attributes;

[0201] The triplet identifiers in the information data of each interface are compressed to determine the mapping code corresponding to each RTE interface.

[0202] Based on the access attributes in the information data of each interface, determine the physical binding core and proxy conditions corresponding to each RTE interface;

[0203] Construct a target mapping description table based on at least one mapping code, at least one physical binding core, and at least one proxy condition.

[0204] Optionally, the data processing unit 33 is used for:

[0205] If the target physical binding core indicator is the first core, then determine whether the actual operating conditions meet the target proxy conditions;

[0206] If the actual operating conditions meet the target proxy conditions, the target call request will be processed through the target RTE interface or the target virtual interface.

[0207] If the actual operating conditions do not meet the target proxy conditions, the target call request will be processed through the target RTE interface.

[0208] Optionally, the data processing unit 33 is used for:

[0209] Obtain the actual load value of the first core;

[0210] If the actual load value is greater than the preset load threshold, the target call request will be processed through the target virtual interface;

[0211] If the actual load value is less than or equal to the preset load threshold, the target call request will be processed through the RTE interface.

[0212] It should be noted that the data processing apparatus provided in this application embodiment has the same beneficial effects as the data processing method provided in the above embodiments, and therefore will not be described again.

[0213] In one possible implementation, see Figure 4 The figure is a schematic diagram of a control device provided in an embodiment of this application.

[0214] The control device may include a memory 411 and a processor 412. For example... Figure 4 As shown, the memory can be random access memory (RAM), flash memory, read-only memory (ROM), EPROM, non-volatile read-only memory (Electronic Programmable ROM), registers, hard disks, removable disks, etc.

[0215] The memory 411 can store computer instructions. When the computer instructions stored in the memory 411 are executed by the processor 412, the processor 412 can be used to execute the investment decision generation method. The memory 411 can also store data.

[0216] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this application is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape) or a semiconductor medium (e.g., solid-state disk (SSD)).

[0217] This application also provides a readable storage medium for storing the methods provided in the above embodiments. Examples include random access memory (RAM), flash memory, read-only memory (ROM), EPROM, non-volatile read-only memory (EPROM), registers, hard disks, removable disks, or any other form of storage medium in the art.

[0218] In the embodiments of this application, the terms "first" and "second" (if they exist) are used only as name identifiers and do not represent the order of first and second.

[0219] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. Regarding the methods disclosed in the embodiments, since they correspond to the product embodiments disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the description of the product embodiments.

[0220] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A data processing method, characterized in that, The method includes: Obtain the target invocation request; wherein, the target invocation request includes the target mapping code; Based on the target mapping description table, the target physical binding core and target proxy conditions are determined according to the target mapping code in the target call request; wherein, the target mapping description table is used to describe the mapping relationship of at least one runtime environment RTE interface in the first core, the target mapping description table includes at least one mapping record, the mapping record includes a mapping code, a physical binding core and proxy conditions, the mapping code is obtained by encoding the interface information data of the corresponding RTE interface, each of the at least one mapping record has a one-to-one correspondence with each of the at least one RTE interface, and each of the at least one mapping record has a one-to-one correspondence with each of the at least one virtual interface in the second core; Based on the target physical binding core and the target proxy conditions, the target call request is processed through the target RTE interface in the first core or the target virtual interface in the second core.

2. The data processing method according to claim 1, characterized in that, This also includes generating the target mapping description table in the following ways: Obtain interface information data for at least one of the RTE interfaces; the interface information data includes a triplet identifier and access attributes; The triplet identifiers in each of the interface information data are compressed to determine the mapping code corresponding to each of the RTE interfaces. Based on the access attributes in the information data of each interface, determine the physical binding core and proxy conditions corresponding to each RTE interface; The target mapping description table is constructed based on at least one of the mapping codes, at least one of the physical binding cores, and at least one of the proxy conditions.

3. The data processing method according to claim 1, characterized in that, The step of processing the target call request through the target RTE interface in the first core or the target virtual interface in the second core, based on the target physical binding core and the target proxy conditions, includes: If the target physical binding core is indicated as the first core, then determine whether the actual operating conditions meet the target proxy conditions; If the actual operating conditions meet the target proxy conditions, the target call request is processed through the target RTE interface or the target virtual interface; If the actual operating conditions do not meet the target proxy conditions, the target call request will be processed through the target RTE interface.

4. The data processing method according to claim 3, characterized in that, The process of processing the target call request through the target RTE interface or the target virtual interface includes: Obtain the actual load value of the first core; If the actual load value is greater than the preset load threshold, the target call request is processed through the target virtual interface; If the actual load value is less than or equal to the preset load threshold, the target call request is processed through the RTE interface.

5. A data processing apparatus, characterized in that, The device includes: An acquisition unit is used to acquire a target invocation request; wherein the target invocation request includes a target mapping code; The determining unit is configured to determine the target physical binding core and target proxy conditions based on the target mapping code in the target call request, according to the target mapping description table; wherein, the target mapping description table is used to describe the mapping relationship of at least one runtime environment RTE interface in the first core, the target mapping description table includes at least one mapping record, the mapping record includes a mapping code, a physical binding core and proxy conditions, the mapping code is obtained by encoding the interface information data of the corresponding RTE interface, each of the at least one mapping record has a one-to-one correspondence with each of the at least one RTE interface, and each of the at least one mapping record has a one-to-one correspondence with each of the at least one virtual interface in the second core; The data processing unit is used to process the target call request through the target RTE interface in the first core or the target virtual interface in the second core, based on the target physical binding core and the target proxy conditions.

6. The data processing apparatus according to claim 5, characterized in that, It also includes a generation unit for generating the target mapping description table in the following manner: Obtain interface information data for at least one of the RTE interfaces; the interface information data includes a triplet identifier and access attributes; The triplet identifiers in each of the interface information data are compressed to determine the mapping code corresponding to each of the RTE interfaces. Based on the access attributes in the information data of each interface, determine the physical binding core and proxy conditions corresponding to each RTE interface; The target mapping description table is constructed based on at least one of the mapping codes, at least one of the physical binding cores, and at least one of the proxy conditions.

7. The data processing apparatus according to claim 5, characterized in that, The data processing unit is used for: If the target physical binding core is indicated as the first core, then determine whether the actual operating conditions meet the target proxy conditions; If the actual operating conditions meet the target proxy conditions, the target call request is processed through the target RTE interface or the target virtual interface; If the actual operating conditions do not meet the target proxy conditions, the target call request will be processed through the target RTE interface.

8. The data processing apparatus according to claim 7, characterized in that, The data processing unit is used for: Obtain the actual load value of the first core; If the actual load value is greater than the preset load threshold, the target call request is processed through the target virtual interface; If the actual load value is less than or equal to the preset load threshold, the target call request is processed through the RTE interface.

9. A control device, characterized in that, It includes a processor and a memory, the memory being used to store programs, instructions, or code, and the processor being used to execute the programs, instructions, or code in the memory to perform the data processing method as described in any one of claims 1-4.

10. A computer-readable storage medium, characterized in that, The system contains a computer program that is loaded by a processor to execute the data processing method as described in any one of claims 1-4.

Images