Function transition method, apparatus, and intelligent drive device

Abstract

A function migration method (400 or 500) and apparatus (900), as well as an intelligent driving device (100), are provided. The function migration apparatus (900) is disposed in an in-vehicle domain controller, which includes a first zone and a second zone. The function migration apparatus (900) can generate first cross-domain call information, the first cross-domain call information indicating call information of a first sub-function of the first function for functions and / or data in the second zone, the first sub-function being located in the first zone (S401). The function migration apparatus (900) stores the first cross-domain call information, and the stored first cross-domain call information is used to migrate the first sub-function from the first zone to the second zone (S402). This method can be applied to an intelligent driving device, such as an intelligent vehicle or an electric vehicle, to solve the problems of difficulty in changing deployment due to large-granularity function migration and data redundancy caused by repeated deployment of the same function in multiple domains. This helps reduce the complexity of deploying domain controller functions and improve the efficiency of deploying functions.

Description

Technical Field

[0001] This application relates to the field of intelligent driving, and more specifically, to a function migration method and apparatus, as well as an intelligent driving device.

Background Art

[0002] In the field of intelligent vehicles, in order to improve the reliability and security of an intelligent vehicle control system, multiple functions of a domain controller are usually deployed in different domains. For example, functions with low function security requirements are deployed in a zone with a low security level (hereinafter abbreviated as a common domain), and functions with high function security requirements are deployed in a zone with a high security level (hereinafter abbreviated as a security domain). However, in the development stage, in order to improve efficiency, all functions are debugged in the common domain, and then functions with high security requirements are split from all functions and migrated to the security domain.

[0003] Developers or users can perform function splitting and migration based on service requirements. Due to horizontal dependencies between functions and downward dependencies between some functions, during function migration, functions having a dependency relationship with a function (referred to as a dependent function) may also need to be migrated to the security domain. However, some dependent functions cannot be called across the entire domain. Therefore, these dependent functions need to be repeatedly deployed in both the security domain and the common domain. When the granularity of function splitting and migration is large, repeated function deployment may cause significant data redundancy. In addition, after functions are migrated and deployed, if the function deployment cannot meet service requirements, the cost of changing the function deployment is high.

[0004] Considering this, there is an urgent need to develop a function migration solution that can facilitate changes in function deployment and reduce data redundancy. [Overview of the project] [Means for solving the problem]

[0005] This application provides a function migration method and apparatus, as well as an intelligent drive device, to solve the problems of difficulty in modifying deployments for coarse-grained function migrations and the data redundancy caused by repeated deployments of the same function across multiple domains. This helps reduce the complexity of function deployments in domain controllers in order to improve the efficiency of function deployments.

[0006] The methods provided in this application may be applied to intelligent drive devices. Intelligent drive devices may be vehicles in a broad sense, and may include means of transport (e.g., commercial vehicles, passenger cars, trucks, motorcycles, aircraft, trains, or ships), industrial vehicles (e.g., pallet trucks, trailers, or tractors), engineering vehicles (e.g., excavators, bulldozers, or cranes), agricultural devices (e.g., lawnmowers or harvesters), entertainment devices, or toy vehicles. The type of vehicle is not particularly limited in this application.

[0007] According to a first aspect, the present application provides a function transfer method. The method may be performed by an on-board domain controller of a vehicle, or by a chip located on the on-board domain controller. The on-board domain controller includes a first zone and a second zone. The method includes generating first cross-domain call information, the first cross-domain call information indicating call information of a first sub-function for a function and / or data in the second zone, the first sub-function belonging to a first function, and the first sub-function located in the first zone; and storing the first cross-domain call information, the stored first cross-domain call information being used to transfer the first sub-function from the first zone to the second zone.

[0008] In the technical solution described above, feature migration is performed at a small granularity, i.e., at the sub-function level. This avoids multi-domain deployments caused by feature migrations at a large granularity and helps reduce data redundancy caused by multi-domain deployments of the same feature. In addition, when stored first cross-domain call information is detected, it may be decided to migrate the first sub-function based on the stored first cross-domain call information. As a result, if the actual execution status of the feature deviates from the service requirements after the feature has been migrated and deployed (e.g., the actual security level of the feature does not reach the expected security level), the user can easily adjust the feature deployment (i.e., further sub-function migration or sub-function re-migration) by identifying the specific sub-function causing the deviation without having to re-analyze based on the service requirements. This helps reduce the complexity and labor costs of feature migration.

[0009] For example, the in-vehicle domain controller (sometimes abbreviated as domain controller) in this application may include an electronic control unit (ECU) of a vehicle, or an in-vehicle computing platform, which may include at least one of the following: an advanced driving domain controller (ADC), a mobile data center (MDC), a vehicle domain controller (VDC), and a chassis domain controller (CDC). Alternatively, the in-vehicle domain controller may further include another computing platform, such as an in-car application-server (ICAS) controller, a body domain controller (BDC), a special equipment system (SAS), a media graphics unit (MGU), a body super core (BSC), or an ADAS super core. This is not limited to the present application. ICAS may include at least one of the following: vehicle control server ICAS 1, intelligent driving server ICAS 2, intelligent cockpit server ICAS 3, and infotainment server ICAS 4.

[0010] For example, storing first cross-domain call information may include controlling the storage of first cross-domain call information. For instance, a module that controls sub-functions within an in-vehicle domain controller to perform cross-domain calls (e.g., a cross-domain call control module) may control the storage of first cross-domain call information, or a module that manages cache zones within an in-vehicle domain controller (e.g., a cache zone management module) may control the storage of first cross-domain call information.

[0011] For example, call information of a first sub-function for functions and / or data within a second zone may include information indicating that the cross-domain cost of the first sub-function is greater than or equal to a predetermined threshold.

[0012] For example, a call to a first subfunction for a function in a second zone may include a call to a subfunction of the first function in the second zone, or a call to another function deployed in the second zone, and a call to a first subfunction for data in the second zone may include a call to cross-domain shared data in the second zone.

[0013] Referring to the first aspect, in some implementations of the first aspect, generating first cross-domain call information includes recording cross-domain data of subfunctions in the first zone and the second zone in a first cache zone; retrieving the cross-domain data of the first subfunction from the first cache zone when the cross-domain data of the first subfunction satisfies specified service requirements; and generating first cross-domain call information based on the cross-domain data of the first subfunction and information about the services accessed by the first subfunction.

[0014] In the technical solution described above, a cross-domain cache zone is established, and by using the cross-domain cache zone, cross-domain calls for the migrated function (or sub-function) and / or migrated function (or sub-function) are implemented. As a result, the same function does not need to be deployed separately in multiple domains during function migration, which helps reduce data redundancy caused by multi-domain deployment of the same function. Furthermore, the recording and analysis of cross-domain data is implemented based on the cross-domain cache zone, and as a result, cross-domain call information can be generated to indicate to the user or in-vehicle domain controller to migrate the function when the cross-domain data of the function meets certain conditions. In addition, based on the solution described above, adaptive partitioning of sub-functions can be implemented based on actual service requirements (based on cross-domain data analysis) to reduce the workload caused by manual partitioning.

[0015] Referring to the first aspect, in some implementations of the first aspect, storing the first cross-domain call information includes storing the first cross-domain call information in a second cache zone.

[0016] For example, storing the first cross-domain call information may include controlling the storage of the first cross-domain call information in a second cache zone.

[0017] In some possible implementations, the first and second zones are zones with different security levels. For example, the security level of the first zone is higher than that of the second zone. When a sub-function in the first zone frequently needs to call functions and / or data in the second zone, and fast migration of the sub-function cannot be implemented due to service requirements (e.g., the sub-function requires a high security level), cross-domain calls of the sub-function may be implemented by using the first cache zone, which helps ensure the overall performance of the first function. In addition, if the cross-domain call information of the sub-function is stored in the second cache zone, it indicates that the sub-function is migrative and needs to be migrated. In this case, the sub-function can be controlled to migrate based on the cross-domain call information in the second cache zone. After the sub-function is migrated, the cross-domain call pressure is reduced, thus improving the overall performance of the first function.

[0018] In the technical solution described above, cross-domain call information stored in the second cache zone indicates the migration of sub-functions. After the sub-function migration, the cross-domain call pressure of sub-functions within the first function is reduced. Thus, the performance of the first function is improved while the security level or security requirements of the first function are guaranteed.

[0019] In some possible implementations, for each sub-function with cross-domain call requirements, the sub-function's cross-domain data is recorded in a first cache zone, and when the cross-domain data satisfies the corresponding specified service requirements of the sub-function, the cross-domain data is stored in a second cache zone. Furthermore, the in-vehicle domain controller calculates the cross-domain cost only for the cross-domain data of sub-functions stored in the second cache zone, and if the cross-domain cost corresponding to a sub-function (e.g., the first sub-function) is greater than or equal to a preset threshold, cross-domain call information for the sub-function is generated and stored in the second cache zone.

[0020] In some possible implementations, after the cross-domain data for sub-functions is stored in a second cache zone, the cross-domain data for sub-functions is removed from the first cache zone.

[0021] The technical solution described above involves setting up a first and second cache zone, which in turn manage the complex data streams generated during the cross-domain call process. The first cache zone is used to store cross-domain data for all sub-functions that need to be called across the entire domain, and the second cache zone is used to store cross-domain data for sub-functions that may need to be migrated. As a result, when determining which sub-functions need to be migrated, the in-vehicle domain controller only needs to consider whether the sub-function corresponding to the cross-domain data in the second cache zone needs to be migrated (for example, calculating the cross-domain cost of the corresponding sub-function based on the cross-domain data in the second cache zone), rather than having to determine individually whether each sub-function in a cross-migration needs to be migrated. This helps reduce the complexity of calculations during function migration.

[0022] Referring to the first aspect, in some implementations of the first aspect, the cross-domain data of the first sub-function includes at least one of the frequency, latency tolerance, and data volume of access to the second zone by the first sub-function.

[0023] With the technical solution described above, the cross-domain cache zone records cross-domain data, allowing users to analyze information such as how often and how much data sub-functions access shared data based on the cross-domain data, further providing a reliable basis for users to balance the security and performance of their functions.

[0024] Referring to the first aspect, in some implementations of the first aspect, prior to the step of generating first cross-domain call information, the method includes determining a first dependency of a first function, the first function comprising M subfunctions, the M subfunctions comprising the first subfunction, the first dependency indicating a call relationship between each of the M subfunctions and the second function, the first and second functions being deployed in a first zone, the first dependency being used to control that N of the M subfunctions are moved to a second zone, the security level of the second zone being higher than the security level of the first zone, M being an integer greater than 1, and N being an integer greater than or equal to 1.

[0025] In some possible implementations, all sub-functions other than N sub-functions within M sub-functions include a first sub-function. In this case, after N sub-functions have moved to a second zone based on the first dependency, the first sub-function may need to call functions and / or data within the second zone, and furthermore, first cross-domain call information may be generated.

[0026] In some possible implementations, N subfunctions include a first subfunction. In this case, the first cross-domain call information may be generated when the first dependency of the first function is determined.

[0027] In some possible implementations, the first dependency is associated with a function migration scenario. For example, if the first dependency indicates that the dependency between some sub - functions with low - security - level requirements and the first zone is complex, the function migration scenario may be to migrate the first function as a whole to the second zone and then migrate some sub - functions with low - security - level requirements back to the first zone. For example, among M sub - functions, sub - functions other than N sub - functions have low - security - level requirements, and the dependency between the sub - functions and the first zone is complex. In this case, the function migration scenario may be to migrate the first function to the second zone and then migrate the sub - functions other than N sub - functions among the M sub - functions back to the first zone.

[0028] In the above - mentioned technical solution, in order to show a specific scenario of function migration (that is, after the function is migrated as a whole, whether multiple sub - functions are migrated back to the initial deployment zone or one or more sub - functions of the function are migrated from the initial deployment zone to the migration destination zone), the dependency of the function to be migrated can be determined.

[0029] It should be noted that in this application, both the initial deployment zone and the migration destination zone are for the state where the first function does not perform function migration. In the process of migrating the first function, the zone to be migrated may be the zone where one or more sub - functions of the first function are migrated.

[0030] Referring to the first aspect, in some implementations of the first aspect, the method further includes migrating the first sub - function from the first zone to the second zone based on the first dependency and the first cross - domain call information.

[0031] For example, a first sub-function is migrated from a first zone to a second zone based on first cross-domain call information and the complexity level of the dependency of the first sub-function, as indicated by the first dependency. For example, the complexity level of the dependency of the first sub-function may be determined based on at least one of the following: the degree of complexity of the dependency between the first sub-function and functions in the first zone, the degree of complexity of the dependency between the first sub-function and data in the first zone, the degree of complexity of the dependency between the first sub-function and functions in the second zone, the degree of complexity of the dependency between the first sub-function and data in the second zone, and the difficulty of migrating the dependent functions of the first sub-function. The complexity may also be determined based on the amount of horizontally dependent functions, the amount of vertically dependent functions, etc.

[0032] In some possible implementations, the complexity levels described above may be further related to the service features implemented by the first sub-function.

[0033] In the technical solution described above, the migration of the first sub-function is controlled by referencing the first dependency and the first cross-domain call information. This helps to improve the match between the actual execution status of the first function and the service requirements in order to further reduce the number of function migrations.

[0034] In some possible implementations, the first cache zone is created based on the requirements of a first subfunction for calling a second zone within the first zone. In this case, the first cache zone may be deleted (or formatted) when the first subfunction migrates from the first zone to the second zone.

[0035] Referring to the first aspect, in some implementations of the first aspect, the method further includes marking a cross-domain call application programming interface and / or cross-domain data access pointer of a first subfunction by using a keyword, and generating a scheduling function based on the keyword, the scheduling function being used to coordinate the behavior of the first subfunction accessing a second zone.

[0036] In the technical solution described above, the first sub-function can perform cross-domain scheduling by using the scheduling function, implement cross-domain migration (or deployment) of the function, and isolate the code of the first sub-function. As a result, users do not need to manually modify the cross-domain scheduling function of the first sub-function, which helps reduce the manual workload.

[0037] According to a second embodiment, a function transfer device is provided. The device is located within an in-vehicle domain controller, which includes a first zone and a second zone. The device includes a generation unit and a storage unit, the generation unit configured to generate first cross-domain call information, the first cross-domain call information indicating call information of a first sub-function for a function and / or data in the second zone, the first sub-function belonging to a first function, the first sub-function located within the first zone, and the storage unit configured to store the first cross-domain call information, the stored first cross-domain call information used to transfer the first sub-function from the first zone to the second zone.

[0038] Referring to a second aspect, in some implementations of the second aspect, a storage unit includes a first cache zone, the device further includes a recording unit configured to record cross-domain data of subfunctions in the first zone and the second zone in the first cache zone, and a generation unit configured to retrieve the cross-domain data of the first subfunction from the first cache zone when the cross-domain data of the first subfunction satisfies specified service requirements, and to generate first cross-domain call information based on the cross-domain data of the first subfunction and information about services accessed by the first subfunction.

[0039] Referring to the second aspect, in some implementations of the second aspect, the storage unit further includes a second cache zone, the second cache zone being used to store the first cross-domain call information.

[0040] Referring to the second aspect, in some implementations of the second aspect, the cross-domain data of the first sub-function includes at least one of the frequency, latency tolerance, and data volume of access to the second zone by the first sub-function.

[0041] Referring to the second aspect, in some implementations of the second aspect, the device further includes a decision unit configured to determine a first dependency of a first function, the first function comprising M subfunctions, the M subfunctions comprising the first subfunction, the first dependency indicating a call relationship between each of the M subfunctions and the second function, the first and second functions being deployed in a first zone, the first dependency being used to control that N subfunctions within the M subfunctions are moved to a second zone, the security level of the second zone being higher than the security level of the first zone, M being an integer greater than 1, and N being an integer greater than or equal to 1.

[0042] Referring to the second aspect, in some implementations of the second aspect, the device further includes a migration unit configured to migrate a first sub-function from a first zone to a second zone based on a first dependency and first cross-domain call information.

[0043] Referring to the second aspect, in some implementations of the second aspect, the device further includes a marking unit configured to mark the cross-domain call application programming interface and / or cross-domain data access pointer of the first sub-function by using keywords, and a generation unit further configured to generate a scheduling function based on keywords, the scheduling function used to coordinate the behavior of the first sub-function to access the second zone.

[0044] According to a third aspect, a function transfer device is provided, the device including a memory configured to store computer programs, and a processor configured to execute the computer programs stored in the memory, thereby enabling the device to perform the method according to any possible implementation of the first aspect.

[0045] According to a fourth aspect, a domain controller is provided, which includes a device in any possible implementation of the second or third aspect.

[0046] According to the fifth aspect, an intelligent drive device is provided, which includes a device in any possible implementation form of the second or third aspect, or a domain controller in any possible implementation form of the fourth aspect.

[0047] Referring to the fifth aspect, in some implementations of the fifth aspect, the intelligent drive device is a vehicle.

[0048] According to the sixth aspect, a computer program product is provided, which includes computer program code. When the computer program code is executed on a computer, the computer becomes capable of performing methods according to any possible implementation of the first aspect.

[0049] It should be noted that computer program code may be stored entirely or partially in a first storage medium. The first storage medium may be encapsulated together with the processor or separately from the processor.

[0050] According to the seventh aspect, a computer-readable medium is provided which stores instructions. When the instructions are executed by a processor, the processor can implement the method according to any possible implementation of the first aspect.

[0051] According to the eighth aspect, a chip is provided, the chip including a circuit. The circuit is configured to perform the method of the first aspect by any possible implementation form. [Brief explanation of the drawing]

[0052] [Figure 1] This is a diagram illustrating a function migration scenario. [Figure 2] This is a functional block diagram of an intelligent drive device according to one embodiment of this application. [Figure 3(a)] This is a diagram of the system framework necessary for functional migration according to one embodiment of this application. [Figure 3(b)] This is a diagram of the system framework necessary for functional migration according to one embodiment of this application. [Figure 4] This is a schematic flowchart of a function transition method according to one embodiment of this application. [Figure 5] This is another schematic flowchart of a function transition method according to one embodiment of this application. [Figure 6] This is a diagram illustrating an application scenario for a function transition method according to one embodiment of this application. [Figure 7] This is another diagram illustrating an application scenario for a function transition method according to one embodiment of this application. [Figure 8A] This is another diagram illustrating an application scenario for a function transition method according to one embodiment of this application. [Figure 8B] This is another diagram illustrating an application scenario for a function transition method according to one embodiment of this application. [Figure 9] This is a block diagram of a function transfer device according to one embodiment of the present application. [Figure 10] Another block diagram of a function transfer device according to one embodiment of this application. [Modes for carrying out the invention]

[0053] In the description of embodiments of this application, unless otherwise specified, " / " means "or". For example, A / B can mean A or B. In this specification, "and / or" describes only the relationship between related subjects and indicates that three relationships may exist. For example, A and / or B can mean the following three cases: that only A exists, that both A and B exist, and that only B exists. In this application, "at least one" means one or more, and "plural" means two or more. At least one of the following items(parts) or similar expressions means any combination of these items, including any combination of singular items(parts) or plural items(parts). For example, at least one item(part) of a, b, or c may mean a, b, c, a and b, a and c, b and c, or a, b, and c, where a, b, and c may be singular or plural.

[0054] The prefixes "first," "second," etc., used in the embodiments of this application are merely intended to distinguish different subjects and do not impose any restrictions on the location, order, priority, quantity, or content of the described subjects. The use of prefixes such as ordinal numbers used to distinguish subjects described in the embodiments of this application does not constitute a limitation on the described subjects. For a description of the subject matter described, please refer to the contextual description in the claims or embodiments, and the use of such prefixes should not constitute a redundant limitation.

[0055] To facilitate understanding of the solutions in the embodiments of this application, the concepts presented herein are first explained.

[0056] 1. Function: A function can be understood as a function implemented through a software program. A software program may be divided into one or more function modules, each function module may complete a subfunction of the software program, and the whole, including one or more function modules, may implement the functionality of the entire software program. Function transitions in this application may include the transition of a software program and / or the transition of one or more function modules within a software program.

[0057] For example, an in-vehicle domain controller is a vehicle route planning controller, and the function of the domain controller is route planning. In this application, the route planning function may be further divided into one or more subfunctions. For example, the route planning function may include one or more of the following: pre-determination subfunction, pre-pre-processing subfunction, route generation subfunction, obstacle handling subfunction, and track generation subfunction. Function migration may involve migrating the route planning function from a common domain to a security domain, migrating one or more subfunctions of the route planning function from a common domain to a security domain, or migrating one or more subfunctions of the route planning function from a security domain to a common domain.

[0058] It should be noted that multiple sub-functions of a single function may have different security level requirements. For example, for some sub-functions, the security level of the common domain may be sufficient to meet the security level requirements of the sub-functions, while for other sub-functions, the security level of the security domain may be required to meet the security level requirements of the sub-functions. Consequently, for the entire function, the security level of the security domain must meet the security level requirements of the function.

[0059] 2. Horizontal Dependency: Horizontal dependency indicates that there is an interaction relationship (also called a call relationship) between functions of a domain controller, or an interaction relationship between sub-functions of a domain controller function. Furthermore, functions that have a horizontal dependency on the function being migrated are called horizontally dependent functions.

[0060] 3. Vertical Dependencies: When a function needs to be called due to the implementation form of a domain controller function and / or subfunction, a vertical dependency exists between the function corresponding to the function and the domain controller function and / or subfunction. Furthermore, a function that has a vertical dependency on the function being migrated is called a vertically dependent function.

[0061] 4. Dependencies: Dependencies include horizontal dependencies and / or vertical dependencies.

[0062] 5. Service Requirements: Service requirements are the conditions necessary to implement a function and may include, for example, one or more of the following: security level requirements, load balancing requirements, and latency performance requirements.

[0063] 6. Cross-domain call: A call made by a function (or subfunction) deployed in a first zone to a function (or subfunction) and / or data in a second zone, where the first and second zones are different zones within a domain controller.

[0064] As mentioned above, in the field of intelligent vehicles, a multi-domain function deployment method is commonly used to improve the reliability and security of intelligent vehicle control systems. For example, functions with low security requirements are deployed in a common domain, while functions with high security requirements are deployed in a security domain. However, during the development phase, to improve efficiency, all functions are debugged in the common domain, and then functions with high security requirements are separated from the other functions and moved to the security domain.

[0065] In the current technological context, for small functions (e.g., functions with simple dependencies), static dependency analysis of functions is performed. After the dependencies are determined, partitioning is performed manually for the functions to be migrated, based on the security level requirements of the functions and the complexity of the dependencies. For large functions, the dependencies of functions are identified via hotspot paths, and some of the shared data access code for the hotspot paths is automatically generated using tools, and partitioning is performed for the functions to be migrated. There are horizontal dependencies between functions to be migrated and other functions, and vertical dependencies between functions and the underlying hardware. As a result, when a function is migrated from a common domain to a security domain, dependent functions may also need to be migrated to the security domain. Some dependent functions cannot be called across domains. Therefore, during function migration, dependent functions may need to be deployed to both the common domain and the security domain. In addition, after a function is migrated and deployed, the actual execution status of the function may differ from the service requirements. Therefore, in the process of actual development and deployment of functions for mass production of vehicles, function deployment may need to be adjusted multiple times based on the degree of agreement between the actual execution status of the function and the service requirements. In other words, before mass production of a vehicle can begin, multiple functional division and transition processes may need to be carried out.

[0066] The functional decomposition and migration scenario shown in Figure 1 is used as an example. Functional A is the functional that needs to be migrated, functional X is a functional that has a horizontal dependency on functional A, and functional B, C, or D is a functional that has a vertical dependency on functional A. In the current technological context, the functional decomposition and migration steps are as follows:

[0067] 1. Determine which functions (i.e., function A) need to be migrated from Zone 1 to Zone 2.

[0068] 2. Determine the horizontally dependent functions (i.e., function X) that have a horizontal dependency on the function to be migrated, and perform horizontal partitioning on the function to be migrated based on the horizontal dependencies.

[0069] 3. Determine whether the horizontal dependency feature supports cross-domain calls. If it does, modify the horizontal dependency feature's calls to be cross-domain calls. If it does not support cross-domain calls, remove the dependency between the horizontal dependency feature and the feature being migrated, or deploy the horizontal dependency feature to both Zone 1 and Zone 2.

[0070] 4. Determine the vertically dependent functions (i.e., functions B, C, or D) that have a vertical dependency on the function to be migrated, and perform a vertical partition on the function to be migrated based on that vertical dependency.

[0071] 5. Determine whether the vertically dependent feature supports cross-domain calls. If it does, modify the calls in the vertically dependent feature to be cross-domain calls. If it does not support cross-domain calls, remove the dependency between the vertically dependent feature and the feature being migrated, or deploy the vertically dependent feature to both Zone 1 and Zone 2.

[0072] 6. Migrate the functions to be migrated to Zone 2, determine whether the functions still need to be used in Zone 1, and if so, reserve the functions in Zone 1 as well.

[0073] If it is not possible to call all of functions A, B, C, D, and X across the entire domain, the set of functions must be deployed in both Zone 1 and Zone 2, with functions A, B, C, D, and X reserved in Zone 1, and the migrated functions A', B', C', D', and X' deployed in Zone 2. It should be understood that functions A', B', C', D', and X' are the same as functions A, B, C, D, and X, respectively.

[0074] The technical solutions described above have the following drawbacks. Firstly, the splitting and migration of functions is performed based on coarse-grained functions, i.e., routing functions, sensing functions, convergence functions, etc., are the targets for splitting and migration. During the splitting process, multiple split solutions coexist. As a result, after the functions have been migrated and deployed, the actual execution status of the functions may differ from the service requirements. In addition, when function execution deviates from the service requirements, the re-splitting and re-migration of functions consumes labor costs and lacks a reliable foundation. Secondly, if a function needs to serve two or more domains simultaneously, i.e., if one or more functions in two or more domains need to call the function, two or more sets of the same or similar function deployments need to be maintained simultaneously in those two or more domains. For some functions that do not need to be migrated (e.g., the functions to be migrated do not require the service requirements of the domains being migrated to), multi-domain deployment of these functions can result in significant data redundancy and a higher likelihood of errors during function development and deployment. In addition to these drawbacks, given the current technical context, the degree of splitting functions typically depends on the degree of trust in the functions when accessing shared data within the service flow. As the data flow generated by cross-domain calls becomes more complex, more data is shared, and the interaction between functional security and functional cross-domain access performance increases. However, this relationship cannot be inferred based on service requirements. As a result, it is difficult for users to balance functional security and functional performance during functional decomposition. Furthermore, the data used by each function is abstracted as a service and is a black box to the outside. Data can be shared within a function but cannot be shared externally (i.e., data cannot be shared between functions). Therefore, data sharing or multi-domain deployment must be considered during functional decomposition, resulting in a heavy workload during functional migration.

[0075] With this in mind, embodiments of this application provide a function migration method and apparatus, as well as an intelligent drive device. When a function is migrated from an initial deployment zone to a destination zone, the migration is performed in units of subfunctions within the function, and a cross-domain cache zone is set up to implement cross-domain calls of the function. In this way, the same function (or subfunction) does not need to be repeatedly deployed to two or more domains to solve the data redundancy problem caused by repeated deployments. Furthermore, the cross-domain call characteristics of a function are determined by using data in the cross-domain call process of the function recorded in the cross-domain cache zone, and the cross-domain call characteristics indicate further migrations of the function, for example, indicating that a subfunction of the function is migrated from the initial deployment zone to a destination zone, or that a subfunction of a function migrated to a destination zone is migrated back to the initial deployment zone, so that if the actual execution status of a function deviates from the service requirements after the function has been deployed, the function can be conveniently redeployed, which helps to improve function migration and deployment efficiency.

[0076] The following describes the technical solutions of the embodiments in this application with reference to the attached drawings.

[0077] Figure 2 is a functional block diagram of an intelligent drive device according to one embodiment of the present application. As shown in Figure 2, the intelligent drive device 100 may include a sensing system 120 and a computing platform 150. The sensing system 120 may include several types of sensors configured to sense information about the environment surrounding the intelligent drive device 100. For example, the sensing system 120 may include a positioning system. The positioning system may be a global positioning system (GPS), a Beidou system, or another positioning system. In another example, the sensing system 120 may further include one or more of an inertial measurement unit (IMU), a lidar, a millimeter-wave radar, an ultrasonic radar, and an imaging device. Millimeter-wave radar can be classified into long-range radar and medium- and short-range radar. Currently, the sensing range of LiDAR is approximately 80 to 150 meters, the sensing range of long-range millimeter-wave radar is approximately 1 to 250 meters, the sensing range of medium / short-range millimeter-wave radar is approximately 30 to 120 meters, the sensing range of camera is approximately 50 to 200 meters, and the sensing range of ultrasonic radar is approximately 0 to 5 meters.

[0078] Some or all of the functions of the intelligent drive device 100 may be controlled by the computing platform 150. The computing platform 150 may include processors 151-15n. A processor is a circuit having signal processing capabilities. In one implementation, a processor may be a circuit having instruction read and execute capabilities, such as a central processing unit (CPU), a microprocessor, a graphics processing unit (GPU) (which may be understood as a microprocessor), or a digital signal processor (DSP). In another implementation, a processor may implement specific functions based on the logic relationships of hardware circuits. The logic relationships of hardware circuits may be fixed or reconfigurable. For example, a processor may be a hardware circuit implemented by an application-specific integrated circuit (ASIC) or a programmable logic device (PLD), such as a field programmable gate array (FPGA). In a reconfigurable hardware circuit, the process by which the processor loads a configuration document and implements the hardware circuit configuration can be understood as the process by which the processor loads instructions and implements some or all of the functions of the unit. In addition, the processor may alternatively be a hardware circuit designed for artificial intelligence and can be understood as an ASIC, for example, a neural network processing unit (NPU), a tensor processing unit (TPU), or a deep learning processing unit (DPU). Furthermore, the computing platform 150 may further include memory, which is configured to store instructions.Some or all of the processors 151-15n can call instructions in memory to implement the corresponding functions.

[0079] The intelligent drive device 100 may include an advanced driving assistance system (ADAS). The ADAS acquires information about the intelligent drive device's surroundings by using multiple sensors on the intelligent drive device (including, but not limited to, lidar, millimeter-wave radar, imaging devices, ultrasonic sensors, global positioning systems, and inertial measurement units), analyzes and processes the acquired information to implement functions such as obstacle sensing, target recognition, intelligent drive device positioning, route planning, and driver monitoring / warning, thereby improving the driving safety, automation, and comfort of the intelligent drive device.

[0080] In terms of logical functionality, ADAS systems generally include three main functional modules: a sensing module, a decision-making module, and an execution module. The sensing module senses the environment around the vehicle via sensors and inputs the corresponding real-time data to the decision-making module. Sensing modules mainly include on-board cameras, ultrasonic radar, millimeter-wave radar, and lidar. The decision-making module makes corresponding decisions based on the information acquired by the sensing module, using computing devices and algorithms. After receiving a decision signal from the decision-making module, the execution module performs the corresponding action, such as driving, changing lanes, steering, braking, or issuing warnings.

[0081] At different intelligent driving levels (L0-L5), ADAS can implement different levels of automated driving assistance based on information acquired through the use of artificial intelligence algorithms and multiple sensors. The intelligent driving levels (L0-L5) described above are based on the rating criteria of the Society of Automotive Engineers (SAE). Level L0 represents no automation, Level L1 represents driving assistance, Level L2 represents partial automation, Level L3 represents conditional automation, Level L4 represents high automation, and Level L5 represents full automation. At levels L1 through L3, the task of monitoring and responding to road conditions is completed jointly by the driver and the system, and the driver needs to take over dynamic driving tasks. Levels L4 and L5 allow the driver to be completely relegated to passenger duty. Currently, the functions that can be implemented by ADAS include, but are not limited to, adaptive cruise control, automatic emergency braking, automatic parking, blind spot monitoring, traffic warning / braking at intersections ahead, traffic warning / braking at intersections behind, preceding vehicle collision warning, lane departure warning, lane keeping assist, following vehicle collision avoidance warning, traffic sign recognition, traffic congestion assistance, and highway assistance. It should be understood that the above functions may have specific modes at different intelligent driving levels (L0 to L5). Higher intelligent driving levels indicate more intelligent corresponding modes, requiring higher precision in sensing algorithms and higher precision in planning and control algorithms.

[0082] In some possible implementations, functional modules within an ADAS, or functions (or other services) that can be implemented by the ADAS, may require different security levels. For example, some functions may require a high level of security. Therefore, during ADAS development, all functions are debugged within a common domain, and then functions with high security requirements are separated and moved to a separate security domain.

[0083] One embodiment of this application provides a function migration method, in which the function migration is performed by using one subfunction as a migration unit based on the dependencies of subfunctions within the function. After the time of migration, multiple subfunctions of the function may be deployed into two or more domains. Thus, a subfunction may need to call a subfunction of a function in another domain, and / or call another function and data in another domain. Figures 3(a) and 3(b) illustrate the system framework required for function migration according to one embodiment of this application to implement cross-domain calls and illustrate further function migration.

[0084] In Figure 3(a) (hereinafter referred to as Figure 3a), sub-functions 3-5 of Function 1 are migrated from the initial deployment zone of Function 1 (Zone 1) to the destination zone of the domain controller (Zone 2). After sub-functions 3-5 are migrated to Zone 2, they need to call functions and / or data within Zone 1. Therefore, the cross-domain call control module 301 and the cache zone management module 302 are located in Zone 2. In addition, the cross-domain second cache module 303 and the cross-domain first cache module 304 are located there. For sub-functions located in Zone 2 that need to call functions and / or data within Zone 1, the cache zone management module 302 configures a cross-domain cache zone within the first cache module 304 that will be used for cross-domain calls of the sub-functions. Furthermore, the cross-domain call control module 301 controls the sub-functions to execute cross-domain calls. In addition, the cross-domain cache zone configured for a sub-function within the first cache module 304 records the sub-function's cross-domain data, and when the cross-domain data satisfies pre-configured conditions, the cross-domain data is stored in the second cache module 303. Based on the sub-function's cross-domain data stored in the second cache module 303, the cache zone management module 302 determines and stores the sub-function's cross-domain call information and indicates that the sub-function should be moved back from zone 2 to zone 1. Note that after the sub-function is returned to zone 1, the cache zone management module 302 can delete the cross-domain cache zone configured for the sub-function in the first cache module 304.

[0085] In Figure 3(b) (hereinafter referred to as Figure 3b), subfunctions 3-5 of function 1 are migrated from the initial deployment zone of function 1 (zone 1) to the destination zone of the domain controller (zone 2). After subfunctions 3-5 are migrated, subfunction 1 and / or subfunction 2 in zone 1 need to call functions and / or data in zone 2. Therefore, the cross-domain call control module 305 and the cache zone management module 306 are located in zone 1. For subfunctions in zone 1 that need to call functions and / or data in zone 2, the cache zone management module 306 sets up a cross-domain cache zone in the first cache module 304 that will be used for cross-domain calls of the subfunctions. Furthermore, the cross-domain call control module 305 controls the subfunctions to execute cross-domain calls. In addition, the cross-domain cache zone set up for the subfunctions in the first cache module 304 records the cross-domain data of the subfunctions, and when the cross-domain data satisfies pre-configured conditions, the cross-domain data is stored in the second cache module 303. The cache zone management module 306 determines and stores the cross-domain call information of a sub-function based on the cross-domain data of the sub-function stored in the second cache module 303, and indicates that the sub-function should be moved from zone 1 to zone 2. Note that after the sub-function has been moved to zone 2, the cache zone management module 306 can delete the cross-domain cache zone set up in the first cache module 304 for the sub-function.

[0086] It can be understood that the first cache module 304 may include one or more cross-domain cache zones.

[0087] In some possible implementations, the second cache module 303 also includes one or more cross-domain cache zones. For example, for a sub-function that has cross-domain call requirements, the cache zone management module 302 may configure the second cache module 303 to use the cross-domain cache zone for the sub-function's cross-domain calls.

[0088] For example, Function 1 may be any of the following functions: route planning function, sensing function, fusion function, etc. For example, Function 1 may be a route planning function, and Subfunctions 1 to 5 may be a pre-determined processing subfunction, a pre-pre-processing subfunction, a route generation subfunction, an obstacle handling subfunction, and a trajectory generation subfunction, respectively. Zone 1 and Zone 2 may be the common domain and security domain mentioned in the embodiments described above, respectively. Alternatively, Zone 1 and Zone 2 may be other zones that satisfy different service requirements, respectively. This is not particularly limited to the embodiments of this application.

[0089] For example, the cross-domain call control module 301 (and / or cross-domain call control module 305) shown in Figures 3(a) and 3(b) may be implemented by a client-server (C / S) structure or in another form.

[0090] It should be understood that the system architectures shown in Figures 3(a) and 3(b) are merely illustrative examples. During a particular implementation, the system described above may include more or fewer modules or nodes, and modules or nodes may be added or removed based on the actual situation. For example, the first cache module 304 and the second cache module 303 may be combined into a single cache module. In addition, in Figures 3(a) and 3(b), two zones, namely Zone 1 and Zone 2, are used as illustrative examples. During a particular implementation, the domain controller may include more zones, and the first cache module 304 and the second cache module 303 may be further deployed across multiple domains.

[0091] In some possible implementations, the system architectures shown in Figures 3(a) and 3(b) can be applied to the following two scenarios.

[0092] Scenario 1: The security level of Zone 2 is higher than that of Zone 1, and Function 1 is migrated from Zone 1 to Zone 2. However, the dependent functions of Function 1 do not require a higher security level. Therefore, the dependent functions of Function 1 are not migrated to Zone 2. In this case, some of the subfunctions of Function 1 need to call functions and / or data within Zone 1.

[0093] Second scenario: Zone 2 has a higher security level than Zone 1, and some sub-functions of Function 1 are migrated from Zone 1 to Zone 2. Some sub-functions of Function 1 located in Zone 1 need to call functions and / or data in Zone 2, or some sub-functions of Function 1 located in Zone 2 need to call functions and / or data in Zone 1.

[0094] Figure 4 is a schematic flowchart of a function transition method according to one embodiment of the present application. Method 400 may be performed by an in-vehicle domain controller or by a chip used in the in-vehicle domain controller. For example, the in-vehicle domain controller may include the computing platform 150 shown in Figure 2. In this case, the method may be performed by the computing platform 150. Alternatively, the method may be performed by the cross-domain call control module 301 and / or the cache zone management module 302 shown in Figures 3(a) and 3(b), or by the cross-domain call control module 305 and / or the cache zone management module 306, or by the cross-domain call control module 301, the first cache module 304, and the second cache module 303, or by the cross-domain call control module 305, the first cache module 304, and the second cache module 303. The following describes Method 400 using an example in which the method is performed by an in-vehicle domain controller. The in-vehicle domain controller includes a first zone and a second zone. Method 400 may include S401 and S402.

[0095] S401: Generates first cross-domain call information, which indicates call information for a first sub-function about a function and / or data in a second zone, the first sub-function belongs to the first function, and the first sub-function is located in the first zone.

[0096] For example, the first zone is the initial deployment zone for the first function, and the second zone is the migration zone for the first function or at least some of its subfunctions. For example, the first zone may be the common domain in the embodiment described above, and the second zone may be the security domain in the embodiment described above. In another example, the first zone may be Zone 1 in the embodiment described above, and the second zone may be Zone 2 in the embodiment described above.

[0097] For example, the first zone is a zone to which at least part of the first function or a sub-function of the first function is migrated, and the second zone is the initial deployment zone for the first function. For example, the first zone may be the security domain in the embodiment described above, and the second zone may be the common domain in the embodiment described above. In another example, the first zone may be zone 2 in the embodiment described above, and the second zone may be zone 1 in the embodiment described above.

[0098] In some possible implementations, the first and second zones may alternatively be other zones that can each meet different service requirements in the in-vehicle domain controller.

[0099] For example, the first function could be function 1 in the embodiments described above, or the first function could be another function that needs to be migrated, and the first subfunction could be one or more of subfunctions 1 to 5 in the embodiments described above, or another subfunction that is within the first function and needs to call functions and / or data in the second zone across the entire domain.

[0100] For example, if the first function is function 1 shown in Figure 3a, the first zone is zone 2 shown in Figure 3a, and the second zone is zone 1 shown in Figure 3a, then the first sub-function may be at least one of sub-functions 3 to 5.

[0101] In another example, if the first function is function 1 shown in Figure 3b, the first zone is zone 1 shown in Figure 3b, and the second zone is zone 2 shown in Figure 3b, then the first sub-function may be sub-function 1 and / or sub-function 2.

[0102] In some possible implementations, the first sub-function may be a service unit (or service segment) obtained through a division within the first function based on actual service requirements. For example, the first sub-function may be a service unit.

[0103] For example, call information for a first sub-function to a function in a second zone may include call information for a first sub-function to a sub-function of the first function in the second zone, or it may include call information for another dependent function of the first function in the second zone. Call information for data in a second zone may include call information for cross-domain shared data in the second zone.

[0104] In some possible implementations, the first cross-domain call information may indicate that the cross-domain cost of the first sub-function is greater than or equal to a preset threshold. If the cross-domain cost of the first sub-function is greater than or equal to a preset threshold, it indicates that the cross-domain calls of the first sub-function may cause security and / or performance degradation of the in-vehicle domain controller. Therefore, the first sub-function needs to be migrated from the first zone to the second zone. For example, the cross-domain cost may be determined based on at least one of the following: the frequency, data volume, and latency tolerance of the calls made by the first sub-function to the second zone, the amount of cross-domain calls made by the first sub-function, the migration priority of the first sub-function, and the cohesion coefficient of the first sub-function. The amount of cross-domain calls made by the first sub-function may be understood as the amount of functions (and / or sub-functions) called by the first sub-function across the entire domain. The cohesion coefficient of the first sub-function may be understood as the degree of close coordination between the first sub-function and other sub-functions of the first function, or as the degree of dependence of the first sub-function on other sub-functions of the first function, where other sub-functions of the first function include sub-functions located in the first zone and / or sub-functions located in the second zone. The migration priority of the first sub-function may be set by the user or determined based on the dependencies of the first sub-function and / or the security level requirements of the first sub-function. For example, if there are complex dependencies between the first sub-function and sub-functions in the second zone, and / or if the security level requirements of the first sub-function are high, the first sub-function will have a high migration priority.

[0105] For example, the cross-domain cost of the i-th sub-function may be determined according to the following formula. cost cross-domain i =β0α1+β1α2+β2α3+β3α4+β4α5+β5α6(1)

[0106] Here, α1 to α6 represent the frequency, data volume, and latency tolerance of the i-th subfunction calling the second zone, the cross-domain call volume of the i-th subfunction, the transition priority of the i-th subfunction, and the cohesion coefficient score of the i-th subfunction, respectively, while β0 to β5 are the weights of α1 to α6.

[0107] For example, the pre-set threshold may be 1, or it may be a different threshold. This is not particularly limited to the embodiments of this application.

[0108] In some possible implementations, cross-domain data for sub-functions within the first and second zones is recorded in the first cache zone, and when the cross-domain data for the first sub-function satisfies specified service requirements, the cross-domain data for the first sub-function is retrieved from the first cache zone, and the first cross-domain call information is generated based on the cross-domain data for the first sub-function and information about the services accessed by the first sub-function.

[0109] For example, cross-domain data of sub-functions within the first and second zones may include data generated when a sub-function in the first zone calls a function and / or data in the second zone, and / or data generated when a sub-function in the second zone calls a function and / or data in the first zone.

[0110] For example, cross-domain data of sub-functions within the first and second zones includes cross-domain data of the first sub-function, and the cross-domain data of the first sub-function may include at least one of the frequency, latency tolerance, and data volume of access to the second zone by the first sub-function.

[0111] Note that "services accessed by the first sub-function" may include services corresponding to functions called by the first sub-function, and "accessing the second zone by the first sub-function" may include the first sub-function calling functions and / or data within the second zone.

[0112] For example, a specified service requirement may include at least one of the following: the cross-domain call frequency of the first sub-function is greater than or equal to a pre-set frequency; the security level required by the first sub-function is less than or equal to a pre-set level; the amount of cross-domain call data of the first sub-function is greater than or equal to a pre-set data amount; the migration priority of the first sub-function is greater than or equal to a pre-set priority threshold; the delay tolerance of the first sub-function is greater than or equal to a pre-set tolerance; and the amount of cross-domain calls of the first sub-function is greater than or equal to a pre-set amount.

[0113] In some possible implementations, the cross-domain data for the first sub-function is retrieved from the first cache zone when one of the above conditions is met. For example, if the cross-domain call frequency of the first sub-function is greater than or equal to a preset frequency, the cross-domain data for the first sub-function is retrieved from the first cache zone. Alternatively, if some of the above conditions are met, the cross-domain data for the first sub-function is retrieved from the first cache zone. For example, if the cross-domain call frequency of the first sub-function is greater than or equal to a preset frequency, and the security level required by the first sub-function is less than or equal to a preset level, the cross-domain data for the first sub-function is retrieved from the first cache zone. Furthermore, the first cross-domain call information is generated based on information about the services accessed by the first sub-function and the cross-domain data of the first sub-function. For example, based on information about the services accessed by the first sub-function, specific values ​​for β0 to β5 in equation (1), which is obtained when the cross-domain cost is calculated, are determined. Furthermore, the cross-domain cost is calculated based on the determined weights of the items in the cross-domain data, and the first cross-domain call information is generated if the cross-domain cost is greater than or equal to a predetermined threshold.

[0114] For example, the first cache zone may be a cache zone within the first cache module 304 shown in Figure 3a or Figure 3b.

[0115] In some possible implementations, cross-domain data recorded in the first cache zone may be handled by using a cache replacement algorithm. For example, if cross-domain data for a sub-function occurs infrequently, the cross-domain data for that sub-function in the first cache zone is erased. For example, cache replacement algorithms may include, but are not limited to, first-in, first-out (FIFO), least-recently-used (LRU), and least-frequently-used (LFU) algorithms.

[0116] In some possible implementations, retrieving cross-domain data for a first sub-function from a first cache zone may involve retrieving cross-domain data for a first sub-function from a first cache zone by using a second cache zone.

[0117] For example, when the cross-domain data of the first sub-function satisfies the specified service requirements, the cross-domain data of the first sub-function is stored in the second cache zone, and the cross-domain data of the first sub-function in the first cache zone is deleted.

[0118] For example, the second cache zone may be a cache zone within the second cache module 303 shown in Figure 3a or Figure 3b.

[0119] S402: Stores the first cross-domain call information, and the stored first cross-domain call information is used to transfer the first sub-function from the first zone to the second zone.

[0120] In some possible implementations, storing the first cross-domain call information may include controlling the storage of the first cross-domain call information. For example, the cross-domain call control module 301 in Figure 3a or the cross-domain call control module 305 in Figure 3b can control the storage of the first cross-domain call information.

[0121] In some possible implementations, storing the first cross-domain call information may include storing the first cross-domain call information in a second cache zone. For example, the cache zone management module 302 in Figure 3a or the cache zone management module 306 in Figure 3b may write the first cross-domain call information to a cache zone in the second cache module 303.

[0122] In some possible implementations, the cross-domain cost is calculated for each sub-function of a cross-domain call. If the cross-domain cost of a sub-function exceeds a pre-set threshold, the cross-domain call information corresponding to the sub-function is generated and stored.

[0123] In some possible implementations, for each sub-function of a cross-domain call, the sub-function's cross-domain data is recorded in a first cache zone, and when the cross-domain data satisfies the corresponding specified service requirements, the sub-function's cross-domain data is stored in a second cache zone. In this case, the in-vehicle domain controller calculates the cross-domain cost only for the sub-function's cross-domain data stored in the second cache zone, and if the sub-function's cross-domain cost is greater than or equal to a preset threshold, the cross-domain call information corresponding to the sub-function is generated and stored.

[0124] In some possible implementations, the stored first cross-domain call information may take the form of a list of items to be migrated. For example, if the cross-domain cost of a first sub-function is greater than or equal to a pre-set threshold, the relevant information for the first sub-function is stored in the list of items to be migrated to indicate that the first sub-function needs to be migrated from the first zone to the second zone. For example, the relevant information for the first sub-function may include the cross-domain call application programming interface and / or cross-domain data access pointer for the first sub-function, or it may include information used to determine the cross-domain call application programming interface and / or cross-domain data access pointer for the first sub-function.

[0125] In some possible implementations, the method further includes marking a cross-domain call application programming interface and / or cross-domain data access pointer of a first subfunction by using a keyword, and generating a scheduling function based on the keyword, the scheduling function being used to coordinate the behavior of the first subfunction accessing a second zone.

[0126] It can be understood that the cross-domain call application programming interface and / or cross-domain data access pointer of the first sub-function is used by the first sub-function to implement cross-domain calls.

[0127] For example, the use of scheduling functionality to coordinate the behavior of a first sub-function accessing a second zone may include using scheduling functionality to implement cross-domain calls that are executed after the first sub-function has migrated, and / or using scheduling functionality to coordinate the priority of cross-domain calls used after the first sub-function has migrated. For example, cross-domain call priority may indicate the priority of calls made by the first sub-function across the domain to other functions and / or data.

[0128] For example, scheduling functionality is implemented using the Dispatcher function.

[0129] For example, when a first sub-function needs to be moved from a first zone to a second zone, the scheduling function delivers the code corresponding to the dependencies of the first sub-function for execution from the first zone to the second zone.

[0130] In some possible implementations, when stored first cross-domain call information is found, for example, when the relevant information for the first sub-function is found in the list of items to be migrated, the keyword is used to mark the cross-domain call application programming interface and / or cross-domain data access pointer of the first sub-function, and the scheduling function is generated based on the keyword.

[0131] In some possible implementations, the first sub-function is migrated from the first zone to the second zone based on the stored first cross-domain call information.

[0132] According to the function migration method provided in this embodiment of the present application, a cross-domain cache zone is established, and cross-domain calls of the function to be migrated and / or the migrated function are implemented using the cross-domain cache zone, thereby eliminating the need for multi-domain deployment to be performed during function migration in order to help reduce data redundancy caused by multi-domain deployment of the function. Furthermore, the recording and analysis of cross-domain data are implemented based on the cross-domain cache zone, and as a result, when the cross-domain data of the function meets certain conditions, cross-domain call information can be generated to indicate that the function should be migrated. In addition, embodiments of the present application propose the concept of sub-functions of the function to be migrated. Cross-domain calls and migration instructions are performed at a smaller granularity than the function, i.e., sub-functions, and as a result, if the actual execution status of the function may deviate from the service requirements after the function has been migrated and deployed, it becomes easier to adjust the function deployment (i.e., whether the sub-function is further migrated or the sub-function is re-migrated), which helps reduce the complexity and cost of function migration.

[0133] Figure 5 is a schematic flowchart of a function transition method 500 according to one embodiment of the present application. Method 500 is an extension of Method 400. For example, Method 500 may be executed in parallel with Method 400 or after Method 400. For example, the method may be executed by an in-vehicle domain controller or by a chip used in an in-vehicle domain controller. The following describes Method 500 using an example in which the method is executed by an in-vehicle domain controller. Method 500 may include steps S501 and S502.

[0134] S501: Determine the first dependency of the first function, the first function includes M subfunctions, the M subfunctions include the first subfunction, the first dependency indicates a call relationship between each of the M subfunctions and the second function, and the first and second functions are deployed in the first zone of the in-vehicle domain controller.

[0135] In some possible implementations, the first dependency is used to control whether N sub-functions within M sub-functions move to the second zone, where M is an integer greater than 1 and N is an integer greater than or equal to 1.

[0136] For example, the first zone and the second zone may be the zones in the embodiments described above. For example, the first zone is the initial deployment zone for the first function, and the second zone is the destination zone for the first function or a sub-function of the first function.

[0137] In some possible implementations, the security level of the second zone is higher than that of the first zone.

[0138] The "security level" of a zone can be understood as the level of security that can be provided (or implemented) within that zone. For example, the security level of a security domain is higher than the security level of a common domain.

[0139] For example, the first function may be the first function in the embodiment described above, or the first function may be another function that needs to be migrated, and the first subfunction may be the first subfunction in the embodiment described above.

[0140] For example, the second function includes horizontally dependent and / or vertically dependent functions of the first function (or M sub-functions).

[0141] For example, if it is determined that the first function is a function to be migrated (i.e., a function that needs to be migrated from the first zone to the second zone), then the first dependency of the first function is determined.

[0142] In another example, if some of the subfunctions of the first function are moved to the second zone (the remaining subfunctions of the first function are still deployed in the first zone, and the remaining subfunctions include M subfunctions), and the first cross-domain call information is detected, the first dependency of the first function is determined. Note that in the above case, the deployment of the first function to the first zone of the in-vehicle domain controller includes the deployment of the remaining subfunctions of the first function to the first zone.

[0143] For example, determining the first dependency of a first function can be divided into two steps: first, determining the dependencies of the first function; and second, determining the dependencies of each subfunction of the first function. Dependencies may include horizontal and vertical dependencies.

[0144] Using an example where the first function is a radar detection function that provides autonomous driving control, a method for determining the dependencies of the first function is described. Functions that are horizontally dependent on the first function include radar sensor functions, fused position functions, and sensor fusion functions, and functions that are vertically dependent on the first function include base function A and base function B, with base function A being assumed to further depend on base function C and base function D. Based on the autonomous driving development framework middleware, the horizontally dependent functions of the first function (i.e., functions that are horizontally dependent on the first function) may be determined by using tools such as Topic Monitor, RefGraph, and RosGraph, and the vertically dependent functions of the first function (i.e., functions that are vertically dependent on the first function) may be determined by using the dynamic link library dependency scanning method and depth first search (DFS) algorithm. Furthermore, the dependencies of the first function may be recorded in the form of a table. For example, Table 1 shows the dependencies of the radar detection function determined by the method described above.

[0145] [Table 1]

[0146] Using an example where the first function is a radar detection function that provides automated driving control, a method for determining the dependencies of each subfunction of the first function is described. Assume that the radar detection function includes several subfunctions, such as a data preprocessing subfunction, a data smoothing subfunction, a road processing subfunction, and a track planning subfunction. There is a horizontal dependency between the road processing subfunction and each of the data preprocessing subfunction and the track planning subfunction, and a vertical dependency between the road processing subfunction and base function A. There is a horizontal dependency between the data preprocessing subfunction and each of the data smoothing subfunction and the fused position function, and there is a vertical dependency between the data preprocessing subfunction and each of base function A, base function B, and base function C. In this case, the dependencies of the subfunctions of the first function can be determined by the method described above. Furthermore, the dependencies of the subfunctions of the first function may be recorded in the form of a table. For example, Table 2 shows the dependencies of the subfunctions of the radar detection function determined by the method described above.

[0147] [Table 2]

[0148] In some possible implementations, after the first dependency is determined, the first dependency is output to indicate the transition of the first function.

[0149] S502: Based on the first dependency and the first cross-domain call information, migrate the first sub-function from the first zone to the second zone.

[0150] In some possible implementations, the first sub-function is moved from the first zone to the second zone based on the first cross-domain call information and the complexity level of the dependencies of the first sub-function, as indicated by the first dependencies.

[0151] The complexity level of the dependencies of the first sub-function may include at least one of the following: the complexity level of dependencies between the first sub-function and functions in the first zone; the complexity level of dependencies between the first sub-function and data in the first zone; the complexity level of dependencies between the first sub-function and functions in the second zone; and the complexity level of dependencies between the first sub-function and data in the second zone. For example, the complexity level may be determined based on the amount of horizontally dependent functions, the amount of vertically dependent functions, etc.

[0152] In certain implementations, it is not necessary for all operations shown in Figure 5 to be performed. For example, only S501 may be performed. Note that if the in-vehicle domain controller performs only S501, the operation to migrate the first sub-function from the first zone to the second zone may be performed by the user.

[0153] According to the function migration method provided in this embodiment of the present application, function dependencies can be determined, and based on the dependencies, or based on the dependencies and first cross-domain call information, the first sub-function is migrated from the first zone to the second zone, thereby reducing the workload of manually migrating functions. In addition, the migration of the first sub-function is controlled based on the dependencies and first cross-domain call information. This further helps to improve the degree of agreement between the actual execution status of the first function and the service requirements in order to further reduce the number of function migrations.

[0154] Figure 6 is a diagram illustrating an application scenario of a function transition method according to one embodiment of this application.

[0155] In one example, as shown in Figure 6(a), if Zone 1 is the first zone in Method 400, Zone 2 is the second zone in Method 400, and Subfunction 2 in Zone 1 is the first subfunction in Method 400, then when Subfunction 2 in Zone 1 calls a function and / or data in Zone 2, first cross-domain call information can be generated and stored. Furthermore, Subfunction 2 is migrated from Zone 1 to Zone 2 based on the stored cross-domain call information. It should be understood that after Subfunction 2 has migrated from Zone 1 to Zone 2, it does not need to be deployed back to Zone 1.

[0156] In another example, as shown in Figure 6(b), if Zone 2 is the first zone in Method 400, Zone 1 is the second zone in Method 400, and Subfunction 3 in Zone 2 is the first subfunction in Method 400, then when Subfunction 3 in Zone 2 calls a function and / or data in Zone 1, first cross-domain call information can be generated and stored. Furthermore, Subfunction 3 is migrated from Zone 2 to Zone 1 based on the stored cross-domain call information. It should be understood that after Subfunction 3 has migrated from Zone 2 to Zone 1, Subfunction 3 does not need to be deployed back to Zone 2.

[0157] For example, as shown in Figure 6(a) or (b), Zone 1 may be a common domain, Zone 2 may be a security domain, or Zone 1 and Zone 2 may be other domains that can each satisfy different service requirements.

[0158] Figure 7 is another diagram illustrating an application scenario of the function migration method according to one embodiment of the present application. As shown in Figure 7, functions X, A, B, C, and D are originally deployed in a common domain. Function A is a function that needs to be migrated from the common domain to the security domain (i.e., the first function), function X is a function that has a horizontal dependency on function A, and functions B, C, and D are base functions that have a vertical dependency on function A. In addition, of functions B, C, D, and X, only function C needs to satisfy security requirements (i.e., needs to be migrated to the security domain). In this case, according to the function migration method provided in this embodiment of the present application, only the functions that have security requirements (i.e., functions A and C) can be migrated to the security domain. After migration, functions A and C can call functions and / or data in the common domain by using a cross-domain cache zone. For example, if, after the function has been migrated, function A' in the security domain needs to call functions D and X in the common domain, this may be implemented by using a cross-domain cache zone.

[0159] In some possible implementations, some sub-functions of function A may be migrated to the security domain, while the remaining sub-functions are reserved in the common domain. After the function migration, some sub-functions of function A may be reserved in function A', and some sub-functions may be reserved in function A. Alternatively, function A as a whole may be migrated to the security domain. After the function migration, function A is no longer deployed in the common domain, and function A' in the security domain is the same function as function A. Note that the above two cases are also applicable to function C.

[0160] Figure 7 shows that, according to the function migration method provided in this application, when a function to be migrated is migrated to a destination zone, if the dependent functions of the function to be migrated (including horizontally dependent functions and / or vertically dependent functions) do not need to meet the service requirements provided by the destination zone, such as security level restrictions (for example, functions B, D, and X do not require the security levels provided by the security domain), then the dependent functions do not need to be migrated to the destination zone, which helps to avoid unnecessary multi-domain deployments and reduce data redundancy.

[0161] Figures 8A and 8B illustrate another scenario of application of a function migration method according to one embodiment of the present application. As shown in Figures 8A and 8B, if a first function deployed in a common domain needs to be migrated to a second zone, the first function (or a portion of a subfunction of the first function) can be migrated by performing steps 801 to 806. The function migration methods 400 and 500 provided in the present application may be applied to 802', 804, and 805.

[0162] 801: The user determines which functions to migrate in the in-vehicle controller.

[0163] For example, the functions to be migrated may include the first function in the embodiments described above. The functions to be migrated may be determined based on service requirements, such as security level requirements, load balancing requirements, or latency performance requirements for the functions.

[0164] 802: The user determines the dependencies of the features to be migrated.

[0165] In some possible implementations, the dependencies of the functions to be migrated may alternatively be determined by the in-vehicle domain controller (as shown in 802'). Furthermore, the in-vehicle domain controller informs the user of the dependencies of the functions to be migrated.

[0166] For example, see the description in Method 500 for a method for determining the dependencies of the functions to be migrated. Further details are not provided herein.

[0167] 803: The user performs the initial migration, moving the functions to be migrated from the initial deployment zone to the destination zone.

[0168] For example, the initial deployment zone may include zone 1 in the above-described embodiment, and the destination zone may include zone 2 in the above-described embodiment.

[0169] In some possible implementations, the initial migration may be determined by the user based on dependencies and the size of the functionality to be migrated.

[0170] For example, the initial migration method may include the following two methods: a first method in which the entire function to be migrated is migrated to the destination zone, and a second method in which some of the sub-functions of the function to be migrated are migrated to the destination zone.

[0171] For example, when the capacity of the function to be migrated is small, for instance, when the function to be migrated includes a small number of sub-functions, and some of the sub-functions of the function to be migrated do not require service requirements provided by the destination zone (e.g., do not need to meet security requirements), and there are complex dependencies between some of the sub-functions and the functions in the initial deployment zone, the initial migration of the function to be migrated can be implemented in the first manner.

[0172] In another example, when the size of the functionality to be migrated is large and migrating the functionality as a whole is not appropriate, the initial migration of the functionality can be implemented using the second method.

[0173] 804: For sub-functions that have cross-domain call requirements, the in-vehicle domain controller records the cross-domain data of the sub-function.

[0174] For example, a sub-function having cross-domain call requirements may be a sub-function deployed in the initial deployment zone, or a sub-function migrated to the destination zone. Cross-domain data may be the cross-domain data in the embodiments described above.

[0175] For example, a subfunction having cross-domain call requirements is used as an example, being the first subfunction in the embodiments described above. For a specific method for recording the cross-domain data of a subfunction by the in-vehicle domain controller, see the description in Method 400 above. Further details are again not described herein.

[0176] 805: The in-vehicle domain controller determines, based on the cross-domain data of each subfunction that has cross-domain call requirements, which subfunctions need to be migrated to the destination zone and / or which subfunctions need to be returned from the destination zone.

[0177] In some possible implementations, cross-domain call information is generated and stored for sub-functions that need to be migrated to the target zone and / or sub-functions that need to be migrated from the target zone to the initial deployment zone. This stored cross-domain call information is then used to migrate the sub-functions to the target zone or to migrate them back from the target zone to the initial deployment zone.

[0178] For example, see the description of Method 400 for a specific method for generating and storing cross-domain call information based on cross-domain data. Further details are not described herein.

[0179] Furthermore, the in-vehicle domain controller notifies the user of information regarding subfunctions that need to be migrated to the destination zone and / or subfunctions that need to be migrated back from the destination zone (e.g., cross-domain call information). For example, information regarding subfunctions may be notified to the user by using the execution log of the in-vehicle domain controller, or by other means.

[0180] 806: The user adjusts the deployment of sub-functions.

[0181] For example, a user might perform sub-function migrations based on information about sub-functions that need to be migrated to a destination zone and / or sub-functions that need to be migrated back from a destination zone, in order to coordinate the deployment of sub-functions, for example, by performing sub-function migrations based on cross-domain call information.

[0182] In some possible implementations, the in-vehicle domain controller can also perform sub-function migrations to coordinate the deployment of sub-functions.

[0183] In some possible implementations, after the subfunction deployment is coordinated, 804-806 continues to be executed until the subfunction no longer needs to be migrated (for example, until stored cross-domain call information can no longer be detected), i.e., until the migration step is complete.

[0184] After the migration is completed using the function migration method provided in this application, some sub-functions of the migrated function may still have cross-domain call requirements, but it should be noted that the cross-domain calls of these sub-functions will meet the service requirements. For example, the frequency, data volume, and latency tolerance of the cross-domain calls will all be lower than the specified service requirements and will meet the performance and security requirements of the migrated function.

[0185] Before migration, it may be understood that, because the migrated functionality does not have cross-domain call requirements, there may be no cross-domain cache zones corresponding to the migrated functionality within the in-vehicle domain controller. After the migration is complete, for some sub-functionalities that do have cross-domain call requirements, cross-domain cache zones used for cross-domain calls of those sub-functionalities may be configured on the in-vehicle domain controller.

[0186] It should be noted that the function migration method provided in this application is applicable to scenarios in which functions are migrated across two or more cross-domains of a single in-vehicle domain controller, and is further applicable to scenarios in which the initial deployment zone and the destination zone of the functions to be migrated are separated by hardware.

[0187] In the various embodiments of this application, unless otherwise specified or unless there is a logical inconsistency, the terminology and / or descriptions in all embodiments are consistent and may be referenced to one another, and technical features in different embodiments may be combined on the basis of their internal logical relationships to form a new embodiment.

[0188] The above describes in detail the method provided in the embodiments of this application with reference to Figures 1 to 8A and 8B. Hereafter, the apparatus provided in the embodiments of this application will be described in detail with reference to Figures 9 and 10. It should be understood that the description of the apparatus embodiments corresponds to the description of the method embodiments. Therefore, for matters not described in detail, please refer to the method embodiments. For brevity, further details are not described herein.

[0189] Figure 9 is a block diagram of a function transfer device 900 according to one embodiment of the present application. The device 900 includes a generation unit 910 and a storage unit 920.

[0190] The apparatus 900 may include units configured to perform the method shown in Figure 4. In addition, the units within the apparatus 900 are each used to implement the corresponding steps of the embodiment of the method shown in Figure 4.

[0191] If the device 900 is configured to perform method 400 of Figure 4, the generation unit 910 may be configured to perform S401 of method 400, and the storage unit 920 may be configured to perform S402 of method 400.

[0192] Specifically, the generation unit 910 is configured to generate first cross-domain call information, which indicates call information for a first sub-function about a function and / or data in a second zone of the in-vehicle domain controller, the first sub-function belonging to a first function, and the first sub-function located in a first zone of the in-vehicle domain controller. The storage unit 920 is configured to store the first cross-domain call information, which is used to transfer the first sub-function from the first zone to the second zone.

[0193] Optionally, the storage unit includes a first cache zone, and the device 900 further includes a recording unit configured to record cross-domain data of sub-functions in the first zone and the second zone in the first cache zone, and the generation unit is configured to retrieve the cross-domain data of the first sub-function from the first cache zone when the cross-domain data of the first sub-function satisfies specified service requirements, and to generate first cross-domain call information based on the cross-domain data of the first sub-function and information about services accessed by the first sub-function.

[0194] Optionally, the memory unit 920 further includes a second cache zone, which is used to store the first cross-domain call information.

[0195] Optionally, the cross-domain data of the first sub-function includes at least one of the following: the frequency of access to the second zone by the first sub-function, latency tolerance, and data volume.

[0196] Optionally, the device 900 further includes a decision unit configured to determine a first dependency of a first function, the first function comprising M subfunctions, the M subfunctions comprising the first subfunction, the first dependency indicating a call relationship between each of the M subfunctions and the second function, the first and second functions being deployed in a first zone, the first dependency being used to control that N subfunctions within the M subfunctions are moved to a second zone, the security level of the second zone being higher than the security level of the first zone, M being an integer greater than 1, and N being an integer greater than or equal to 1.

[0197] Optionally, the device 900 further includes a migration unit configured to migrate a first sub-function from a first zone to a second zone based on a first dependency and first cross-domain call information.

[0198] Optionally, the device 900 further includes a marking unit configured to mark the cross-domain call application programming interface and / or cross-domain data access pointer of a first sub-function by using keywords, and a generation unit 910 further configured to generate a scheduling function based on keywords, the scheduling function being used to coordinate the behavior of the first sub-function to access a second zone.

[0199] For example, the generation unit 910 and the storage unit 920 may be located on the computing platform 150 shown in Figure 2. The generation unit 910 can be located in the cross-domain call management module 301 and / or the cross-domain call control module 305 shown in Figures 3(a) and 3(b). The storage unit 920 is located in the second cache module 303 shown in Figures 3(a) and 3(b). For example, the recording unit may be located on the computing platform 150 shown in Figure 2, or in the cache zone management module 302 or cache zone management module 306 shown in Figures 3(a) and 3(b). For example, the acquisition unit, decision unit, migration unit, and marking unit may be located on the computing platform 150 shown in Figure 2, or in the cross-domain call control module 301 and / or the cross-domain call control module 305 shown in Figures 3(a) and 3(b).

[0200] It should be understood that the division of the device into units described above is merely a logical functional division. In actual implementations, all or part of the units may be integrated into a single physical entity or physically separated. In addition, units within the device may be implemented in the form of software called by a processor. For example, the device includes a processor, the processor is connected to memory, the memory stores instructions, and the processor calls the instructions stored in memory to implement one of the methods described above or to implement the functionality of the units within the device. The processor is, for example, a general-purpose processor, e.g., a CPU or microprocessor, and the memory is either in-device memory or external memory. Alternatively, units within the device may be implemented in the form of hardware circuits, and some or all of the functionality of the units may be implemented by designing hardware circuits. Hardware circuits may be understood as one or more processors. For example, in one implementation, the hardware circuit is an ASIC, and some or all of the functionality of the units is implemented by designing the logical relationships between the components in the circuit. As another example, in another implementation, the hardware circuit may be implemented by using a PLD. An FPGA is used as an example, and an FPGA may contain a large number of logic gate circuits, and the connections between the logic gate circuits are configured using a configuration file to implement some or all of the functions of a unit. All units of the device may be implemented in the form of software called by a processor, or in the form of hardware circuits, or some units may be implemented in the form of software called by a processor, and the remaining units may be implemented in the form of hardware circuits.

[0201] The units within the device may consist of one or more processors (or processing circuits) that implement the method described above, such as a CPU, GPU, NPU, TPU, DPU, microprocessor, DSP, ASIC, FPGA, or a combination of at least two of these processor forms.

[0202] In addition, all or part of the device units may be integrated or implemented independently. In one implementation configuration, the units may be integrated together and implemented in the form of a system-on-a-chip (SOC). The SOC may include at least one processor configured to implement one of the methods described above or to implement the functions of the units in the device. The type of at least one processor may be different and may include, for example, a CPU and an FPGA, a CPU and an artificial intelligence processor, or a CPU and a GPU.

[0203] In certain implementations, the operations performed by the generation unit 910 may also be performed by a processor, which controls the storage of the associated data and / or information in the storage unit 920. In addition, the operations performed by the generation unit 910, the decision unit, the transition unit, and the marking unit may be performed by the same processor or by different processors. During certain implementations, one or more processors may be processors located on the computing platform 150 shown in Figure 2, or the device 900 may be a chip located on the intelligent drive device 100.

[0204] Figure 10 is a block diagram of a function transition device according to one embodiment of the present application. The function transition device 1000 shown in Figure 10 may include a processor 1010, a transceiver 1020, and a memory 1030. The processor 1010, the transceiver 1020, and the memory 1030 are connected via an internal connection path. The memory 1030 is configured to store instructions. The processor 1010 is configured to execute instructions stored in the memory 1030 to implement the function transition method in the embodiment described above. Optionally, the memory 1030 may be coupled to the processor 1010 via an interface, or may be integrated with the processor 1010.

[0205] It should be noted that transceiver 1020 may include, but is not limited to, an input / output interface transceiver device for implementing communication between device 1000 and another device or communication network.

[0206] Memory 1030 may be read-only memory (ROM), a static storage device, a dynamic storage device, or random access memory (RAM).

[0207] The transceiver 1020, for example, but not limited to, a transceiver-type transceiver device, implements communication between device 1000 and another device or communication network, and receives / transmits data / information used to implement the function transition method in the embodiments described above.

[0208] During a particular implementation, the device 1000 may be located on the computing platform 150 shown in Figure 2, or it may be located on the cross-domain call control module 301 and / or cross-domain call control module 305 shown in Figures 3(a) and 3(b).

[0209] One embodiment of this application further provides a domain controller, which includes device 900 or device 1000.

[0210] One embodiment of this application further provides an intelligent drive device, which may include device 900 or device 1000, or further include the domain controller described above.

[0211] In some possible implementations, the intelligent drive device may be a vehicle.

[0212] One embodiment of this application further provides a computer program product, which includes computer program code. When the computer program code is executed on a computer, the computer becomes capable of implementing the function transition method in the above-described embodiment of this application.

[0213] One embodiment of this application further provides a computer-readable storage medium. The computer-readable medium stores computer instructions. When the computer instructions are executed on a computer, the computer can implement the function transition method in the above-described embodiment of this application.

[0214] One embodiment of the present application further provides a chip including a circuit configured to perform the function transition method in the above-described embodiment of the present application.

[0215] In implementation forms, the steps in the method described above may be implemented by using hardware integrated logic circuits within a processor or by using instructions in software form. The methods disclosed with reference to embodiments of this application may be performed directly by a hardware processor or by a combination of hardware and software modules within the processor. The software modules may be located in mature storage media in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. The storage media is located in memory, and the processor reads the information in memory and, in combination with the processor's hardware, completes the steps in the method described above. To avoid repetition, further details are not described here.

[0216] For the sake of convenient and concise explanation, it will be readily apparent to those skilled in the art that detailed operating processes of the above-described systems, apparatus, and units should be referred to by the corresponding processes in the embodiments of the methods described above. Further details are not described herein.

[0217] In the various embodiments provided in this application, it should be understood that the disclosed systems, apparatus, and methods may be implemented in other ways. For example, the embodiments of the apparatus described above are merely examples. For example, the division of units is merely a logical functional division, and other divisions may exist between actual implementations. For example, multiple units or components may be coupled or integrated into another system, or some features may be ignored or not performed. In addition, the mutual coupling, direct coupling, or communication connection shown or described may be implemented through some interfaces. Indirect coupling or communication connection between apparatus or units may be implemented electrically, mechanically, or in other ways.

[0218] Units described as separate parts may or may not be physically separate, and parts shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the units may be selected based on the actual requirements for achieving the objectives of the solution of the embodiment.

[0219] In addition, the functional units in the embodiments of this application may be integrated into a single processing unit, each unit may exist physically independently, or two or more units may be integrated into a single unit.

[0220] The above description represents only a specific implementation of this application and does not limit the scope of protection. Any modifications or substitutions readily conceivable by a person skilled in the art within the scope of the technical scope disclosed herein shall fall within the scope of protection. Accordingly, the scope of protection of this application shall be subject to the scope of protection of the claims. [Explanation of symbols]

[0221] 100 Intelligent Drive Devices 120 Sensing Systems 150 Computing Platforms 151~15n processor 301 Cross-Domain Call Control Module 302 Cache Zone Management Module 303 Second cache module 304 First cache module 305 Cross-Domain Call Control Module 306 Cache Zone Management Module 900 Function Transfer Device 910 Generation Units 920 memory units 1000 Function Transfer Device 1010 Processor 1020 Transceiver 1030 memory

Claims

1. A function migration method, the method being performed by an in-vehicle domain controller, the in-vehicle domain controller including a first zone and a second zone, and the method is A step of generating first cross-domain call information, wherein the first cross-domain call information indicates call information of a first sub-function for a function and / or data within the second zone, the first sub-function belongs to the first function, and the first sub-function is located within the first zone. A step of storing the first cross-domain call information, wherein the stored first cross-domain call information is used to move the first sub-function from the first zone to the second zone. Methods that include...

2. The step of generating the first cross-domain call information is: The steps include recording cross-domain data of sub-functions within the first zone and the second zone in the first cache zone, When the cross-domain data of the first sub-function satisfies the specified service requirements, the steps include: obtaining the cross-domain data of the first sub-function from the first cache zone; The steps include generating the first cross-domain call information based on the cross-domain data of the first sub-function and information about the services accessed by the first sub-function, The method according to claim 1, including the method described in claim 1.

3. The step of storing the first cross-domain call information is: The method according to claim 2, further comprising the step of storing the first cross-domain call information in a second cache zone.

4. The method according to claim 2, wherein the cross-domain data of the first sub-function includes at least one of the frequency, latency tolerance, and data volume of access to the second zone by the first sub-function.

5. Prior to the step of generating the first cross-domain call information, the method: A step of determining a first dependency of the first function, wherein the first function comprises M subfunctions, the M subfunctions each comprise the first subfunction, the first dependency represents a call relationship between each of the M subfunctions and the second function, and the first and second functions are configured to be deployed in the first zone, The method according to claim 1, wherein the first dependency is used to control that N of the M subfunctions are migrated to the second zone, the security level of the second zone is higher than the security level of the first zone, M is an integer greater than 1, and N is an integer greater than or equal to 1.

6. The aforementioned method, The method according to claim 5, further comprising the step of migrating the first sub-function from the first zone to the second zone based on the first dependency and the first cross-domain call information.

7. The aforementioned method, The steps include marking the cross-domain call application programming interface and / or cross-domain data access pointer of the first sub-function by using a keyword, A step of generating a scheduling function based on the aforementioned keyword, wherein the scheduling function is used to coordinate the behavior of accessing the second zone by the first sub-function, The method according to claim 1, further comprising:

8. A function transfer device, wherein the device is located in an in-vehicle domain controller, the in-vehicle domain controller includes a first zone and a second zone, and the device comprises a generation unit and a storage unit. The generation unit generates first cross-domain call information, the first cross-domain call information indicates call information of a first sub-function for functions and / or data within the second zone, the first sub-function belongs to a first function, and the first sub-function is configured to be located within the first zone. The device is configured such that the storage unit stores the first cross-domain call information, and the stored first cross-domain call information is used to transfer the first sub-function from the first zone to the second zone.

9. The storage unit includes a first cache zone, and the device further comprises a recording unit. The recording unit is configured to record cross-domain data of sub-functions within the first zone and the second zone in the first cache zone. The apparatus according to claim 8, wherein the generation unit is particularly configured to retrieve the cross-domain data of the first subfunction from the first cache zone when the cross-domain data of the first subfunction satisfies specified service requirements, and to generate the first cross-domain call information based on the cross-domain data of the first subfunction and information about the services accessed by the first subfunction.

10. The apparatus according to claim 9, wherein the storage unit further includes a second cache zone, the second cache zone being used to store the first cross-domain call information.

11. The apparatus according to claim 9, wherein the cross-domain data of the first subfunction includes at least one of the frequency, latency tolerance, and data volume of access to the second zone by the first subfunction.

12. The apparatus further comprises a decision unit, the decision unit is The first dependency of the first function is determined, the first function comprises M subfunctions, the M subfunctions comprise the first subfunction, the first dependency indicates a call relationship between each of the M subfunctions and the second function, and the first and second functions are configured to be deployed in the first zone. The apparatus according to claim 8, wherein the first dependency is used to control that N of the M subfunctions are migrated to the second zone, the security level of the second zone is higher than the security level of the first zone, M is an integer greater than 1, and N is an integer greater than or equal to 1.

13. The apparatus further comprises a transition unit, the transition unit is The apparatus according to claim 12, configured to migrate the first sub-function from the first zone to the second zone based on the first dependency and the first cross-domain call information.

14. The apparatus further comprises a marking unit, The marking unit is configured to mark the cross-domain call application programming interface and / or cross-domain data access pointer of the first sub-function by using keywords. The apparatus according to claim 8, wherein the generation unit generates a scheduling function based on the keyword, and the scheduling function is further configured to be used to coordinate the behavior of accessing the second zone by the first sub-function.

15. A function transfer device, Memory configured to store computer programs, A processor configured to execute the computer program stored in the memory, thereby enabling the device to perform the method described in claim 1, A function transfer device equipped with the following features.

16. A domain controller comprising the device described in claim 8.

17. An intelligent drive device comprising the domain controller described in claim 16 or the device described in claim 8.

18. The intelligent drive device according to claim 17, wherein the intelligent drive device is a vehicle.

19. A computer-readable storage medium, wherein the computer-readable storage medium stores instructions, and when the instructions are executed by a processor, the processor is enabled to implement the method according to claim 1.

20. A chip comprising a circuit, wherein the circuit is configured to perform the method according to claim 1.

Images