Application processing method and device based on AUTOSAR, equipment and medium

Abstract

The embodiment of the invention relates to an application processing method and device based on AUTOSAR, equipment and a medium, and the method comprises the steps: receiving an application processing request of a vehicle, and obtaining a multi-core external graph corresponding to an application function; wherein the multi-core external graph comprises a plurality of physical cores and a configuration transfer relationship among check points included among the plurality of physical cores; determining an initial check point in the multi-core external graph; performing application function processing based on the initial check point and the configuration transfer relationship, and transferring the application function processing among the plurality of physical cores to obtain a global state of each physical core; and matching the global state of each physical core with a preset processing condition to obtain an application processing result. Therefore, logic monitoring of state transition can be realized for application function multi-physical core deployment, and the function security level of the application is improved while application function deployment diversity is realized.

Description

Technical Field

[0001] The present disclosure relates to the field of vehicle data technology, and in particular to an application processing method, device, equipment and medium based on the AUTOSAR automotive open system architecture. Background Art

[0002] With the continuous development of network and equipment technology, more and more application functions are available in vehicles to meet the different usage needs of users.

[0003] In practical applications, the Automotive Open System Architecture (AUTOSAR) defines a software architecture for controllers, which can separate the hardware and software of the device, put the functional model software and software components together, independently developed by different manufacturers, and then combined into a specific function through some automatic configuration process. In order to realize any application function on the vehicle, multiple threads need to work together to complete it, and usually multiple threads need to be deployed on multiple physical cores in the electronic control unit.

[0004] In related technologies, such as Figure 1 As shown, there are multiple physical cores on an electronic control unit (ECU) chip, such as Figure 1 In the physical core Core0 and physical core CoreN, each physical core deploys its own SE (Supervised Entity), such as Figure 1 In the example, Core0 includes monitored entities SE0 and SE1, and CoreN includes monitored entity SE2. In addition, the CP (Checkpoint) in each SE can only be deployed on the same physical core, for example Figure 1 The monitored entity SE0 includes checkpoints CP0-0, CP0-1, and CP0-2; the monitored entity SE1 includes checkpoints CP1-0, CP1-1, CP1-2, and CP1-3; the monitored entity SE2 includes checkpoints CP2-0, CP2-1, CP2-2, and CP2-3; a checkpoint can be understood as a point in the control flow of the monitored entity. Each SE has different local states, such as correct state, error state, etc. When an error occurs in the logical flow of a checkpoint in SE, the SE state will change, and the global state of the physical core will also change. Based on Figure 1 The logical supervision method means that the global states of multiple cores within the ECU are independent, and it is impossible to monitor the software functions implemented by the cooperation of multiple physical cores, resulting in poor application function security.

[0005] Therefore, if threads that can run independently must be deployed on one physical core in order to meet the requirements of application functional safety, the vehicle's operating performance will be affected and some vehicle application functions cannot be realized; if multiple threads are deployed on multiple physical cores in the electronic control unit, it will lead to the inability to form a logical supervision relationship between the threads deployed on multiple physical cores. Summary of the invention

[0006] In order to solve the above technical problems or at least partially solve the above technical problems, the present disclosure provides an application processing method, device, equipment and medium based on the AUTOSAR automobile open system architecture.

[0007] The embodiment of the present disclosure provides an AUTOSAR-based application processing method, comprising the following steps:

[0008] Receiving an application processing request of a vehicle, and obtaining a multi-core external graph corresponding to the application function; wherein the multi-core external graph includes: a plurality of physical cores, and a configuration transfer relationship between checkpoints included between the plurality of physical cores;

[0009] determining an initial checkpoint in the multi-core external graph;

[0010] Transferring application function processing between the plurality of physical cores based on the initial checkpoint and the configuration transfer relationship, and acquiring a global state of each of the physical cores;

[0011] The global state of each of the physical cores is matched with a preset processing condition to obtain an application processing result.

[0012] In an optional embodiment of the present disclosure, the AUTOSAR-based application processing method and the multi-core external graph construction method include:

[0013] Determine application function information of the application function;

[0014] Matching the application function information with the preset execution conditions to obtain multiple execution physical cores, and determining a monitored entity corresponding to each of the execution physical cores and a checkpoint corresponding to each of the monitored entities;

[0015] Determine the configuration transfer relationship between the checkpoints corresponding to each of the monitored entities and store it in the memory corresponding to each checkpoint;

[0016] The multi-core external graph is constructed based on the configuration transfer relationship.

[0017] In an optional embodiment of the present disclosure, the application function information is matched with a preset execution condition to obtain multiple execution physical cores, including:

[0018] Analyze the application function information to obtain multiple application sub-functions;

[0019] Obtaining execution priority information of each of the application sub-functions;

[0020] Acquire the processing priority information of the physical core from the execution condition;

[0021] In the case where the execution priority information of each of the application sub-functions matches the processing priority information of the physical core, the multiple execution physical cores are obtained.

[0022] In an optional embodiment of the present disclosure, the transferring of application function processing between the multiple physical cores based on the initial checkpoint and the configuration transfer relationship includes:

[0023] Determining a next checkpoint based on the configuration transfer relationship;

[0024] When there are multiple next checkpoints, obtaining current control parameters of the application;

[0025] When the current control parameters of the application match the preset transfer conditions, obtaining the next target checkpoint;

[0026] The initial checkpoint is controlled to transfer to the next target checkpoint, and the step of determining the next checkpoint based on the configuration transfer relationship is performed until the checkpoint transfer is completed.

[0027] In an optional embodiment of the present disclosure, the AUTOSAR-based application processing method, before controlling the initial checkpoint to transfer to the next target checkpoint, further includes:

[0028] The flow source address is obtained through the core communication information between physical cores;

[0029] Matching the flow source address with the configuration flow address in the configuration transfer relationship;

[0030] When the flow source address matches the configured flow address, the initial checkpoint is controlled to start transferring to the next target checkpoint.

[0031] In an optional embodiment of the present disclosure, obtaining the global state of each of the physical cores includes:

[0032] Match the transfer results of each checkpoint with the preset status conditions to obtain the status information of each monitored entity;

[0033] The state information of each monitored entity is matched with preset configuration information to obtain the global state of each physical core.

[0034] In an optional embodiment of the present disclosure, the AUTOSAR-based application processing method further includes:

[0035] Analyze the application processing result to obtain the current processing error number;

[0036] When the current number of processing errors is greater than a preset number threshold, generating a warning message and sending it to the target device;

[0037] Within a preset period, when the current number of processing errors is greater than 0 and less than or equal to the number threshold, the application processing request of the receiving vehicle is executed to obtain the multi-core external graph corresponding to the application function.

[0038] The present disclosure also provides an AUTOSAR-based application processing device, the device comprising:

[0039] A receiving and obtaining module, configured to receive an application processing request of a vehicle and obtain a multi-core external graph corresponding to an application function; wherein the multi-core external graph includes: a plurality of physical cores and a configuration transfer relationship between checkpoints included between the plurality of physical cores;

[0040] A first determination module, configured to determine an initial checkpoint in the multi-core external graph;

[0041] A transfer module, configured to transfer application function processing between the plurality of physical cores based on the initial checkpoint and the configuration transfer relationship;

[0042] A first acquisition module, used for acquiring a global state of each of the physical cores;

[0043] The second determination module is used to match the global state of each of the physical cores with a preset processing condition to obtain an application processing result.

[0044] An embodiment of the present disclosure also provides an electronic device, comprising: a processor; a memory for storing executable instructions of the processor; the processor is used to read the executable instructions from the memory and execute the instructions to implement the AUTOSAR-based application processing method provided in the embodiment of the present disclosure.

[0045] The embodiment of the present disclosure further provides a computer-readable storage medium, wherein the storage medium stores a computer program, and the computer program is used to execute the AUTOSAR-based application processing method provided by the embodiment of the present disclosure.

[0046] The technical solution provided by the embodiments of the present disclosure has the following advantages over the prior art: the AUTOSAR-based application processing solution provided by the embodiments of the present disclosure receives an application processing request from a vehicle and obtains a multi-core external graph corresponding to the application function; wherein the multi-core external graph includes: multiple physical cores, and configuration transfer relationships between checkpoints included between the multiple physical cores; determining the initial checkpoint in the multi-core external graph; transferring application function processing between multiple physical cores based on the initial checkpoint and the configuration transfer relationship, and obtaining the global state of each physical core; matching the global state of each physical core with the preset processing conditions to obtain the application processing result. Therefore, logical monitoring of state transfer can also be achieved for the multi-physical core deployment of application functions, achieving diversity in application function deployment while improving the functional safety level of the application. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] The above and other features, advantages and aspects of the embodiments of the present disclosure will become more apparent with reference to the following detailed description in conjunction with the accompanying drawings. Throughout the accompanying drawings, the same or similar reference numerals represent the same or similar elements. It should be understood that the drawings are schematic and the originals and elements are not necessarily drawn to scale.

[0048] Figure 1 An example diagram of an application logic supervision method provided by an embodiment of the present disclosure;

[0049] Figure 2 A flowchart of an AUTOSAR-based application processing method provided in an embodiment of the present disclosure;

[0050] Figure 3 A flowchart of another AUTOSAR-based application processing method provided in an embodiment of the present disclosure;

[0051] Figure 4 An example diagram of a multi-core external diagram provided for an embodiment of the present disclosure;

[0052] Figure 5 A schematic diagram of the structure of an AUTOSAR-based application processing device provided in an embodiment of the present disclosure;

[0053] Figure 6 A schematic diagram of the structure of an electronic device provided in an embodiment of the present disclosure. DETAILED DESCRIPTION

[0054] Embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although certain embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be construed as being limited to the embodiments described herein, which are instead provided for a more thorough and complete understanding of the present disclosure. It should be understood that the drawings and embodiments of the present disclosure are only for exemplary purposes and are not intended to limit the scope of protection of the present disclosure.

[0055] It should be understood that the various steps described in the method embodiments of the present disclosure may be performed in different orders and / or in parallel. In addition, the method embodiments may include additional steps and / or omit the steps shown. The scope of the present disclosure is not limited in this respect.

[0056] The term "including" and its variations used herein are open inclusions, i.e., "including but not limited to". The term "based on" means "based at least in part on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". The relevant definitions of other terms will be given in the following description.

[0057] It should be noted that the concepts such as "first" and "second" mentioned in the present disclosure are only used to distinguish different devices, modules or units, and are not used to limit the order or interdependence of the functions performed by these devices, modules or units.

[0058] It should be noted that the modifications of "one" and "plurality" mentioned in the present disclosure are illustrative rather than restrictive, and those skilled in the art should understand that unless otherwise clearly indicated in the context, it should be understood as "one or more".

[0059] The names of the messages or information exchanged between multiple devices in the embodiments of the present disclosure are only used for illustrative purposes and are not used to limit the scope of these messages or information.

[0060] In order to solve the problems described in the above background technology, an embodiment of the present disclosure provides an application processing method based on AUTOSAR, which is introduced below in conjunction with a specific embodiment.

[0061] Figure 2 The present invention provides a flowchart of an AUTOSAR-based application processing method, which can be executed by an AUTOSAR-based application processing device, wherein the device can be implemented by software and / or hardware and can generally be integrated in an electronic device. Figure 2 As shown, the method includes:

[0062] Step 101: Receive an application processing request of a vehicle and obtain a multi-core external graph corresponding to the application function; wherein the multi-core external graph includes: multiple physical cores, and configuration transfer relationships between checkpoints included between the multiple physical cores.

[0063] In the embodiments of the present disclosure, the user can send an application processing request through the application control on the vehicle, such as triggering the door opening control on the vehicle to send an application processing request; the application processing request can also be sent through an external device, such as triggering the door opening function on the mobile phone application to send an application processing request; the specific selection can be based on the actual application scenario, and the embodiments of the present disclosure do not impose specific restrictions on the method of receiving the application processing request of the vehicle.

[0064] In the disclosed embodiment, the application processing request includes an application function identifier, that is, each application function identifier uniquely identifies an application function, such as a door opening function, a left front light turning on function, etc. After receiving the application processing request of the vehicle, the application function can be obtained based on the application processing request.

[0065] In the embodiments of the present disclosure, different application functions correspond to different multi-core external graphs. It is understandable that different multi-core external graphs are pre-built for different application functions when setting the application function, so that after determining the application function of the application processing request, the multi-core external graph corresponding to the application function can be queried. In some embodiments, the application function identifier is queried in a pre-stored database to obtain a matching multi-core external graph; in other embodiments, the application function identifier is queried in a mapping table to obtain a multi-core external graph identifier, and the corresponding multi-core external graph is directly called in the database based on the multi-core external graph identifier; wherein the multi-core external graph identifier can uniquely identify a multi-core external graph. The above two methods are only examples of obtaining a multi-core external graph corresponding to an application function, and the embodiments of the present disclosure do not specifically limit the method of obtaining a multi-core external graph corresponding to an application function.

[0066] In the disclosed embodiment, the multi-core external graph includes: multiple physical cores, and the configuration transfer relationship between the checkpoints included between the multiple physical cores; specifically, there are multiple physical cores on an ECU chip, such as 4 physical cores, 8 physical cores, etc., each physical core can run different threads at the same time, that is, multiple threads can be executed simultaneously to implement an application function, and each physical core can deploy its own monitored entity. The multi-core external graph includes multiple physical cores. Similarly, the multi-core external graph includes multiple monitored entities. The monitored entity includes all software entities monitored by the watchdog manager, and each monitored entity has only one identifier. The monitored entity represents a set of checkpoints within a software component or basic software module. There may be zero, one or more monitored entities in a software component or basic software module. The checkpoints owned by each monitored entity can only be deployed on the same physical core.

[0067] In the disclosed embodiment, there is a path between any two checkpoints in the multi-core external graph, i.e., a configuration transfer relationship, at least one checkpoint is an initial checkpoint, and a connection relationship is established between physical cores through the configuration transfer relationship between the two checkpoints; wherein the configuration transfer relationship includes relationship information such as the path from the current checkpoint to the next checkpoint, the start transfer condition, etc. Thus, by executing the transfer of each checkpoint in the multi-core external graph, the transfer of application function processing between multiple physical cores can be controlled to execute each thread to achieve the purpose of realizing the application function.

[0068] For example, the application function is to open the door, and a request to open the door is sent through a mobile phone application. The application function includes a network communication thread, a motor control thread, and a battery status thread, etc. These threads are distributed on different physical cores. The physical core includes a configuration transfer relationship between checkpoints. For example, the network communication thread is distributed on physical cores A1 and A2. According to the configuration transfer relationship between the checkpoints, the transfer from the initial checkpoint in physical core A1 to the checkpoint in physical core A2 can realize the transfer of physical core A1 to physical core A2 and realize the application function of the network communication thread at the same time, that is, receiving the request to open the door sent by the mobile phone application; the motor control thread is distributed on physical core B1. The configuration transfer relationship between the checkpoints, from the checkpoint in physical core A2 to the checkpoint in physical core B1, can realize the transfer of physical core A1 to physical core B1 and realize the function of controlling the battery status thread, that is, determining that the battery status is normal; and the control motor thread is distributed on physical cores C1 and C2. According to the configuration transfer relationship between the checkpoints, the transfer from the checkpoint in physical core B1 to the checkpoint in physical core C1, and from the checkpoint in physical core C1 to the checkpoint in physical core C2 can realize the transfer of physical core B1 to physical core C1, and the transfer of physical core C1 to physical core C2, and realize the function of controlling the motor thread, that is, the motor controls the door to open. Thus, by executing the transfer of each checkpoint in the multi-core external graph corresponding to the door opening, the transfer of the application function processing between multiple physical cores is controlled to execute each thread to achieve the purpose of opening the door.

[0069] Step 102: Determine an initial checkpoint in the multi-core external graph.

[0070] In the disclosed embodiment, the initial checkpoint refers to the starting point of the transfer between multiple physical cores. There are many ways to determine the initial checkpoint in the multi-core external graph. In a specific implementation, the previous checkpoint and the next checkpoint connected to each checkpoint are obtained based on the multi-core external graph, and the checkpoint with 0 previous checkpoints is obtained as the initial checkpoint.

[0071] Step 103: Based on the initial checkpoint and the configuration transfer relationship, the application function processing is transferred between multiple physical cores to obtain the global state of each physical core.

[0072] In the embodiments of the present disclosure, there are many ways to transfer between checkpoints based on the initial checkpoint and the configuration transfer relationship to control the transfer between multiple physical cores. In some implementations, the next checkpoint is determined based on the configuration transfer relationship. When the next checkpoint is 1, the initial checkpoint is controlled to transfer to the next checkpoint. When the next checkpoint is multiple, the current control parameters of the application are obtained, the current control parameters of the application are matched with the preset transfer conditions to obtain the next target checkpoint, the initial checkpoint is controlled to transfer to the next target checkpoint, the next checkpoint or the next target checkpoint is used as the new initial checkpoint, and the transfer between checkpoints is continued based on the new initial checkpoint and the configuration transfer relationship until the checkpoint transfer is completed to control the transfer of application function processing between multiple physical cores.

[0073] In other embodiments, the current application control state corresponding to the initial checkpoint is obtained, the next checkpoint matching the current application control state and the configuration transfer relationship is obtained, the initial checkpoint is controlled to transfer to the next checkpoint, and the step of determining the next checkpoint based on the configuration transfer relationship is performed until the checkpoint transfer is completed, that is, the next checkpoint is used as the new initial checkpoint, and the transfer between checkpoints is continued based on the new initial checkpoint and the configuration transfer relationship until the checkpoint transfer is completed to control the transfer between multiple physical cores.

[0074] In the disclosed embodiment, the global state of the physical core may include the correct state, error state, on state and off state of the physical core, etc., which are specifically set according to the application scenario. There are many ways to obtain the global state of each physical core. For example, after each checkpoint transfer is completed, the transfer result of the checkpoint is analyzed to obtain the state information of the monitored entity to which the checkpoint belongs. Each physical core determines the global state of each physical core based on the state information of all monitored entities and the pre-set configuration information; for another example, each physical core determines the state information of each monitored entity based on the transfer results of all checkpoints included, and directly determines the global state of each physical core based on the state information of each monitored entity.

[0075] Step 104: Match the global state of each physical core with the preset execution condition to obtain the application processing result.

[0076] Among them, the execution conditions are set in advance. For example, if the global status of all physical cores is a correct status, the application processing result is determined to be the realization of the application function; for another example, if the global status of one or more target physical cores among all physical cores is a correct status, the application processing result is determined to be the realization of the application function; for another example, if the global status of one or more target physical cores among all physical cores is an error status, the application processing result is determined to be the inability to realize the application function, etc. The specific settings are selected according to the application scenario.

[0077] In the disclosed embodiment, the global state of the physical core may include the correct state, error state, on state and off state of the physical core, etc. It can be understood that multiple threads corresponding to the application function are executed by multiple physical cores. After obtaining the global state of each physical core, the global state of each physical core is matched with the preset execution conditions to obtain the application processing result. For example, the global state of all physical cores is the correct state, indicating that the application processing result is to realize the application function, such as executing the door opening function. Currently, the corresponding result conditions can also be set according to the needs of the application scenario. For example, if there are 4 physical cores and the global state of all or 3 physical cores is the correct state, the application processing result is determined to realize the application function, etc. Different weights can also be assigned according to the importance of the execution threads of each physical core and the application processing result can be determined in combination with the global state of each physical core.

[0078] The AUTOSAR-based application processing solution provided by the embodiment of the present disclosure receives the application processing request of the vehicle and obtains the multi-core external graph corresponding to the application function; wherein the multi-core external graph includes: multiple physical cores, and the configuration transfer relationship between the checkpoints included between the multiple physical cores; determines the initial checkpoint in the multi-core external graph; transfers the application function processing between the multiple physical cores based on the initial checkpoint and the configuration transfer relationship, and obtains the global state of each physical core; matches the global state of each physical core with the preset processing conditions to obtain the application processing result. Therefore, the logical monitoring of state transfer can also be realized for the multi-physical core deployment of the application function, realizing the diversity of application function deployment while improving the functional safety level of the application.

[0079] Figure 3 This is a flow chart of another AUTOSAR-based application processing method provided by the embodiment of the present disclosure. This embodiment further optimizes the AUTOSAR-based application processing method based on the above embodiment. Figure 3 As shown, the application function is executed by at least two physical cores in the electronic control unit, and the method includes:

[0080] Step 201, determine the application function information of the application function, match the application function information with the preset execution conditions, obtain multiple execution physical cores, and determine the monitored entity corresponding to each execution physical core and the checkpoint corresponding to each monitored entity.

[0081] Step 202: Determine the configuration transfer relationship between the checkpoints corresponding to each monitored entity and store it in the memory corresponding to each checkpoint, and construct a multi-core external graph based on the configuration transfer relationship.

[0082] In the disclosed embodiment, different application functions correspond to different application function information. For example, when turning on the headlight A, the application function information includes the headlight status, battery status and other application function information. These application function information can be executed by different execution physical cores. Therefore, multiple execution physical cores are determined according to the application function information, and the monitored entity corresponding to each execution physical core and the checkpoint corresponding to each monitored entity are determined. In order to control the transfer between multiple physical cores to execute each thread to achieve the purpose of realizing the application function, the transfer relationship between the checkpoints corresponding to each monitored entity can be configured, that is, the configuration transfer relationship between the checkpoints corresponding to each monitored entity is determined, and the configuration transfer relationship is stored in the memory corresponding to each checkpoint, and a multi-core external graph is constructed based on the configuration transfer relationship.

[0083] The execution condition can be set according to the application scenario, such as the execution priority of the physical core. In a specific embodiment, the application function information is analyzed, multiple application sub-functions are obtained, the execution priority information of each application sub-function is obtained, the processing priority information of the physical core is obtained from the execution condition, and when the execution priority information of each application sub-function matches the processing priority information of the physical core, multiple execution physical cores are obtained.

[0084] For example, to turn on headlight A, the application function information is the headlight status. The headlight status is analyzed to obtain multiple application sub-functions, such as the headlight switch sub-function, the headlight brightness sub-function, etc. The execution priority information of each application sub-function is obtained. For example, the priority of the headlight switch sub-function is higher than that of the headlight brightness sub-function. Then, the processing priority information of the physical core is obtained from the execution condition. For example, the priority of physical core 1 is higher than that of physical core 2. Thus, physical core 1 is used as the execution physical core of the headlight switch sub-function, and physical core 2 is used as the execution physical core of the headlight brightness sub-function. Therefore, the execution priority of the application sub-function is matched with the execution physical core of the corresponding processing priority, so as to further ensure the application function processing efficiency and meet the user's usage needs.

[0085] In this way, the multi-core external graph corresponding to the application function can be obtained, and when the application processing request corresponding to the application function is subsequently processed, the transfer of each checkpoint in the multi-core external graph corresponding to the application function can be executed, and the transfer between multiple physical cores can be controlled to execute each thread to achieve the purpose of realizing the application function.

[0086] Step 203: Receive an application processing request from the vehicle, and obtain a multi-core external graph corresponding to the application function; wherein the multi-core external graph includes: multiple physical cores, and configuration transfer relationships between the multiple physical cores, including between checkpoints.

[0087] It should be noted that step 203 is the same as step 101. For details, please refer to the detailed description of step 101, which will not be described in detail here.

[0088] Step 204, determine the initial checkpoint in the multi-core external graph, and when there are multiple next checkpoints, obtain the current control parameters of the application, and obtain the next target checkpoint when the current control parameters of the application match the preset transfer conditions.

[0089] Step 205: Control the initial checkpoint to transfer to the next target checkpoint, and execute the step of determining the next checkpoint based on the configuration transfer relationship until the checkpoint transfer is completed.

[0090] In the disclosed embodiment, the configuration transfer relationship includes transfer information such as the connection relationship between two checkpoints and the flow source address. The initial checkpoint can determine the next checkpoint based on the configuration transfer relationship. When there are multiple next checkpoints, the current control parameters of the application are obtained, the current control parameters of the application are matched with the preset transfer conditions to obtain the next target checkpoint, the initial checkpoint is controlled to transfer to the next target checkpoint, the next checkpoint or the next target checkpoint is used as the new initial checkpoint, and the step of determining the next checkpoint based on the configuration transfer relationship is executed until the checkpoint transfer is completed, that is, the transfer between checkpoints is continued based on the new initial checkpoint and the configuration transfer relationship until the checkpoint transfer is completed to control the transfer of application function processing between multiple physical cores, thereby achieving the purpose of the application function.

[0091] When there are multiple next checkpoints, obtain the current control parameters of the application. For example, if the application function is to turn on the lights, obtain the current lighting parameters of the vehicle as the application control parameters, and the transfer conditions are preset. For example, if the next checkpoints are checkpoint 1 and checkpoint 2, and the current control parameter is X, then transfer to checkpoint 1; if the current control parameter is Y, then transfer to checkpoint 2. The specific settings are based on the application scenario. Therefore, the next target checkpoint is determined based on the current control parameters of the application and the preset transfer conditions, and the initial checkpoint is controlled to transfer to the next target checkpoint until the checkpoint transfer is completed to achieve the transfer between multiple physical cores, thereby achieving the purpose of the application function.

[0092] In some embodiments, when the initial checkpoint is transferred to the next target checkpoint, the initial checkpoint is disconnected and transferred to the other next checkpoint.

[0093] Continuing with the above example, when the current control parameter is X, while transferring to checkpoint 1, the initial checkpoint is prohibited from transferring to checkpoint 2, further improving application security.

[0094] In some embodiments, the control initial checkpoint obtains the flow source address through the core communication information between the physical cores, and when the flow source address is matched with the configuration flow address in the configuration transfer relationship, the control initial checkpoint starts to transfer to the next target checkpoint.

[0095] In the disclosed embodiment, the physical cores can communicate with each other and thus can send core communication information to each other. Therefore, after the initial checkpoint obtains the flow source address through the core communication information between the physical cores, the flow source address is matched with the configuration flow address in the configuration transfer relationship. When the flow source address and the configuration flow address match, the initial checkpoint is controlled to start transferring to the next target checkpoint. That is to say, the checkpoint flow is performed when the flow source address is detected and matches the configuration flow address in the configuration transfer relationship, thereby further improving the effectiveness of the transfer and thus improving the security of the application performance.

[0096] Step 206: Match the transfer result of each checkpoint with the preset state condition to obtain the state information of each monitored entity, and match the state information of each monitored entity with the preset configuration information to obtain the global state of each physical core.

[0097] In an embodiment of the present disclosure, each physical core includes one or more monitored entities, each monitored entity includes one or more checkpoints, and the transfer results between the checkpoints included in each monitored entity determine the status information of each monitored entity. Status conditions are set in advance. For example, if the transfer result between all checkpoints included in the monitored entity is a transfer error, the status information of the monitored entity is an error status; for example, if the transfer result between one or more target checkpoints included in the monitored entity is a transfer error, the status information of the monitored entity is an error status, etc., the specific settings are selected according to the application scenario.

[0098] In the embodiments of the present disclosure, the status information of the monitored entities included in each physical core and the preset configuration information determine the global status of each physical core; wherein the configuration information can be set according to the application scenario requirements, for example, all the monitored entities included in the physical core are in the correct status, and the global status of the physical core is the correct status; for example, eighty percent of the monitored entities included in the physical core are in the correct status, and the global status of the physical core is the correct status. The specific setting is based on the application performance requirements, and the embodiments of the present disclosure do not impose specific limitations.

[0099] Step 207: match the global state of each physical core with the preset processing conditions to obtain the application processing result, analyze the application processing result, obtain the current number of processing errors, and when the current number of processing errors is greater than the preset number threshold, generate an early warning message and send it to the target device. Within the preset period, when the current number of processing errors is greater than 0 and less than or equal to the number threshold, execute the application processing request of the receiving vehicle and obtain the multi-core external map corresponding to the application function.

[0100] In the disclosed embodiment, the global state of the physical core may include the correct state, error state, on state and off state of the physical core, etc. It can be understood that the multiple threads corresponding to the application function are executed by multiple physical cores, that is, the global state of all physical cores is a correct state, indicating that the application processing result is to realize the application function, such as executing the door opening function. Currently, the corresponding result conditions can also be set according to the application scenario. For example, if there are 4 physical cores, and the global state of all or 3 physical cores is a correct state, then the application processing result is determined to be the realization of the application function, etc. Different weights can also be assigned according to the importance of the execution threads of each physical core and the application processing result can be determined in combination with the global state of each physical core.

[0101] In the disclosed embodiment, after obtaining the application processing result, the application processing result is analyzed to obtain the current number of processing errors. When the current number of processing errors is greater than a preset number threshold, a warning message is generated and sent to the target device. Within a preset period, when the current number of processing errors is greater than 0 and less than or equal to the number threshold, the application processing request is repeatedly executed, wherein the current number of processing errors refers to the accumulated number of errors in response to the same application processing request. The number threshold can be selected and set according to the needs of the application scenario, and the period can also be set as needed to meet the personalized needs of different users, thereby further meeting the user's needs for application processing diversity.

[0102] As an example scenario, a complete application function is allowed to be split into multiple physical cores, and a monitored entity SE and a checkpoint CP are deployed for the application function on each physical core. By configuring the transfer relationship, the applications of each physical core have a transfer relationship.

[0103] like Figure 4 As shown, the threads of application functions are distributed on multiple physical cores of an ECU chip, such as Figure 4 In the physical core Core0, physical core Core1 and physical core CoreN, each physical core deploys its own SE, such as Figure 4 In the example, Core0 includes monitored entity SE0, Core1 includes monitored entity SE1, and CoreN includes monitored entity SE2. In addition, the CPs in each SE can only be deployed on the same physical core, for example Figure 4 The monitored entity SE0 includes checkpoints CP0-0, CP0-1 and CP0-2, the monitored entity SE1 includes checkpoints CP1-0, CP1-1, CP1-2 and CP1-3, and the monitored entity SE2 includes checkpoints CP2-0, CP2-1, CP2-2 and CP2-3.

[0104] Specifically, Figure 4 As shown, the configuration transfer relationship is defined as follows: when the thread of Core1 runs to CP1-0, it indicates the start of multi-physical core transfer. At this time, the thread of Core1 is only allowed to run to CP1-1 or CP1-2. When the thread of Core1 runs to CP1-1, the thread of Core0 is allowed to run to CP0-0. Figure 4 The transfer relationship in the specification states that CP0-0 passes through CP0-1, CP0-2, and CP1-3, marking the end of the cross-physical core transfer.

[0105] After the checkpoint transfer begins, all checkpoints in the multi-core external graph are monitored by the program. For example, when CP1-1 of Core0 arrives, the thread of CoreN runs to CP2-0. At this time, CoreN itself will report the status to all physical cores in the multi-core external graph, indicating the failure of this multi-core external graph transfer.

[0106] In order to reduce the communication between physical cores and the number of times each physical core queries all checkpoints, the open transfer point on each physical core can be marked. For example, only when CP1-1 arrives (that is, the flow source address is detected), the thread of Core0 is allowed to have a checkpoint arrive, otherwise it must be an illegal transfer. When Core1's CP1-1 flows to CP1-2, Core0 closes the open transfer, prohibiting any transfer point on SE0 on Core0 from arriving, while SE2 on CoreN is allowed to transfer.

[0107] Therefore, through such reasonable configuration, by sacrificing a small part of memory and appropriately adding additional information to explain the transfer relationship, it is prevented that each physical core needs to poll the checkpoint status on all physical cores when processing multiple physical cores.

[0108] At the same time, when an error occurs in the flow relationship, all SEs contained in the multi-core external graph will report an error at the same time. At this time, the status information of the SE included in each physical core will report an error, and the global state on each physical core will calculate the global state of the current physical core based on its own configuration information. Among them, each physical core can handle errors independently of each other.

[0109] Therefore, for application performance with extremely high computing power requirements, the corresponding sub-modules can be run on multiple cores and their overall program flow can be monitored.

[0110] For application functions with multi-core deployment requirements, overall logical supervision cannot be achieved, and logical supervision within the core can only be achieved on each physical core respectively. In addition, in order to achieve functional safety applications, the application function can only be deployed on a single core, resulting in poor running performance. The AUTOSAR-based application processing method of the embodiment of the present disclosure determines application function information of the application function, matches the application function information with preset execution conditions, obtains multiple execution physical cores, and determines the monitored entity corresponding to each execution physical core and the checkpoint corresponding to each monitored entity, determines the configuration transfer relationship between the checkpoints corresponding to each monitored entity and stores them in the memory corresponding to each checkpoint, constructs a multi-core external graph based on the configuration transfer relationship, receives an application processing request of the vehicle, and obtains the multi-core external graph corresponding to the application function; wherein the multi-core external graph includes: multiple physical cores, and the configuration transfer relationship between the multiple physical cores including the checkpoints, determines the initial checkpoint in the multi-core external graph, determines the next checkpoint based on the configuration transfer relationship, and stores the configuration transfer relationship between the checkpoints in the next checkpoint. When there are multiple checkpoints, the current control parameters of the application are obtained, the current control parameters of the application are matched with the preset transfer conditions, the next target checkpoint is obtained, the initial checkpoint is controlled to transfer to the next target checkpoint, the next checkpoint or the next target checkpoint is used as the new initial checkpoint, and the transfer between the checkpoints is continued based on the new initial checkpoint and the configuration transfer relationship until the checkpoint transfer is completed to control the transfer of the application function processing between multiple physical cores, the transfer results of each checkpoint are matched with the preset state conditions, the state information of each monitored entity is obtained, the state information of each monitored entity is matched with the preset configuration information, the global state of each physical core is obtained, the global state of each physical core is matched with the preset processing conditions, the application processing results are obtained, the application processing results are analyzed, the current processing error number is obtained, when the current processing error number is greater than the preset number threshold, an early warning message is generated and sent to the target device, and within the preset period, when the current processing error number is greater than 0 and less than or equal to the number threshold, the application processing request is repeatedly executed. In this way, the application function can realize cross-core deployment and logic flow monitoring, and improve the functional safety level of the application.

[0111] Figure 5 The schematic diagram of the structure of an AUTOSAR-based application processing device provided in an embodiment of the present disclosure is shown in FIG. 1 , which can be implemented by software and / or hardware and can generally be integrated into an electronic device. Figure 5 As shown, the device comprises:

[0112] The receiving and obtaining module 301 is used to receive an application processing request of a vehicle and obtain a multi-core external graph corresponding to the application function; wherein the multi-core external graph includes: a plurality of physical cores and configuration transfer relationships between the plurality of physical cores including checkpoints;

[0113] A first determination module 302, configured to determine an initial checkpoint in the multi-core external graph;

[0114] A transfer module 303, configured to transfer application function processing between the multiple physical cores based on the initial checkpoint and the configuration transfer relationship;

[0115] A first acquisition module 304 is used to acquire the global state of each of the physical cores;

[0116] The second determination module 305 is used to match the global state of each of the physical cores with a preset processing condition to obtain an application processing result.

[0117] In an optional embodiment of the present disclosure, the device further includes:

[0118] A third determining module, used to determine application function information of the application function;

[0119] A fourth determination module, used for matching the application function information with a preset execution condition to obtain a plurality of execution physical cores;

[0120] A fifth determination module, configured to determine a monitored entity corresponding to each of the execution physical cores and a checkpoint corresponding to each of the monitored entities;

[0121] Determine a storage module, used to determine the configuration transfer relationship between the checkpoints corresponding to each of the monitored entities and store it in the memory corresponding to each checkpoint;

[0122] A construction module is used to construct the multi-core external graph based on the configuration transfer relationship.

[0123] In an optional embodiment of the present disclosure, the fourth determining module is specifically configured to:

[0124] Analyze the application function information to obtain multiple application sub-functions;

[0125] Obtaining execution priority information of each of the application sub-functions;

[0126] Acquire the processing priority information of the physical core from the execution condition;

[0127] In the case where the execution priority information of each of the application sub-functions matches the processing priority information of the physical core, the multiple execution physical cores are obtained.

[0128] In an optional embodiment of the present disclosure, the transfer module 303 is specifically configured to:

[0129] Determining a next checkpoint based on the configuration transfer relationship;

[0130] When there are multiple next checkpoints, obtaining current control parameters of the application;

[0131] When the current control parameters of the application match the preset transfer conditions, obtaining the next target checkpoint;

[0132] The initial checkpoint is controlled to transfer to the next target checkpoint, and the step of determining the next checkpoint based on the configuration transfer relationship is performed until the checkpoint transfer is completed.

[0133] In an optional embodiment of the present disclosure, the device further includes:

[0134] The initial checkpoint obtains the flow source address through the core communication information between the physical cores;

[0135] Matching is performed based on the flow source address and the configuration flow address in the configuration transfer relationship;

[0136] When the flow source address and the configured flow address are matched, the initial checkpoint is controlled to start transferring to the next target checkpoint.

[0137] In an optional embodiment of the present disclosure, the first acquisition module 304 is configured to:

[0138] Match the transfer results of each checkpoint with the preset status conditions to obtain the status information of each monitored entity;

[0139] The state information of each monitored entity is matched with preset configuration information to obtain the global state of each physical core.

[0140] In an optional embodiment of the present disclosure, the device further includes:

[0141] A fifth determination module, configured to analyze the application processing result to obtain a current processing error number;

[0142] A generating module, used for generating a warning message and sending it to a target device when the number of current processing errors is greater than a preset number threshold;

[0143] The execution module is used to execute the application processing request of the received vehicle and obtain the multi-core external map corresponding to the application function when the current processing error number is greater than 0 and less than or equal to the number threshold within a preset period.

[0144] The AUTOSAR-based application processing device provided in the embodiments of the present disclosure can execute the AUTOSAR-based application processing method provided in any embodiment of the present disclosure, and has the corresponding functional modules and beneficial effects of the execution method.

[0145] In order to implement the above embodiments, the present disclosure also proposes a computer program product, including a computer program / instruction, which implements the AUTOSAR-based application processing method in the above embodiments when the computer program / instruction is executed by a processor.

[0146] Figure 6 A schematic diagram of the structure of an electronic device provided in an embodiment of the present disclosure.

[0147] The following specific reference Figure 6 , which shows a schematic diagram of the structure of an electronic device 400 suitable for implementing the embodiment of the present disclosure. The electronic device 400 in the embodiment of the present disclosure may include, but is not limited to, mobile terminals such as mobile phones, notebook computers, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 6 The electronic device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present disclosure.

[0148] like Figure 6 As shown, the electronic device 400 may include a processor (e.g., a central processing unit, a graphics processing unit, etc.) 401, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 402 or a program loaded from a memory 408 to a random access memory (RAM) 403. In the RAM 403, various programs and data required for the operation of the electronic device 400 are also stored. The processor 401, the ROM 402, and the RAM 403 are connected to each other via a bus 404. An input / output (I / O) interface 405 is also connected to the bus 404.

[0149] Typically, the following devices may be connected to the I / O interface 405: an input device 406 including, for example, a touch screen, a touch pad, a keyboard, a mouse, a camera, a microphone, an accelerometer, a gyroscope, etc.; an output device 407 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; a memory 408 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 409. The communication device 409 may allow the electronic device 400 to communicate with other devices wirelessly or by wire to exchange data. Although Figure 6The electronic device 400 is shown with various devices, but it should be understood that it is not required to implement or possess all the devices shown. More or fewer devices may be implemented or possessed instead.

[0150] In particular, according to an embodiment of the present disclosure, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present disclosure includes a computer program product, which includes a computer program carried on a non-transitory computer-readable medium, and the computer program contains program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from the network through the communication device 409, or installed from the memory 408, or installed from the ROM 402. When the computer program is executed by the processor 401, the above-mentioned functions defined in the AUTOSAR-based application processing method of the embodiment of the present disclosure are executed.

[0151] It should be noted that the computer-readable medium disclosed above may be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present disclosure, a computer-readable storage medium may be any tangible medium containing or storing a program that may be used by or in combination with an instruction execution system, device or device. In the present disclosure, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, in which a computer-readable program code is carried. This propagated data signal may take a variety of forms, including but not limited to an electromagnetic signal, an optical signal, or any suitable combination of the above. The computer readable signal medium may also be any computer readable medium other than a computer readable storage medium, which may send, propagate or transmit a program for use by or in conjunction with an instruction execution system, apparatus or device. The program code contained on the computer readable medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (radio frequency), etc., or any suitable combination of the above.

[0152] In some embodiments, the client and the server may communicate using any currently known or future developed network protocol such as HTTP (Hyper Text Transfer Protocol), and may be interconnected with any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network ("LAN"), a wide area network ("WAN"), an internet (e.g., the Internet), and a peer-to-peer network (e.g., an ad hoc peer-to-peer network), as well as any currently known or future developed network.

[0153] The computer-readable medium may be included in the electronic device, or may exist independently without being installed in the electronic device.

[0154] The computer-readable medium carries one or more programs. When the one or more programs are executed by the electronic device, the electronic device:

[0155] The electronic device may be written in one or more programming languages ​​or a combination thereof to write computer program code for performing the operations of the present disclosure, including but not limited to object-oriented programming languages, such as Java, Smalltalk, C++, and conventional procedural programming languages, such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0156] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present disclosure. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some implementations as replacements, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0157] The units involved in the embodiments described in the present disclosure may be implemented by software or hardware, wherein the name of a unit does not, in some cases, limit the unit itself.

[0158] The functions described above herein may be performed at least in part by one or more hardware logic components. For example, without limitation, exemplary types of hardware logic components that may be used include: field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on chips (SOCs), complex programmable logic devices (CPLDs), and the like.

[0159] In the context of the present disclosure, a machine-readable medium may be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, device, or equipment. A machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or equipment, or any suitable combination of the foregoing. A more specific example of a machine-readable storage medium may include an electrical connection based on one or more lines, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0160] According to one or more embodiments of the present disclosure, the present disclosure provides an electronic device, including:

[0161] processor;

[0162] a memory for storing instructions executable by the processor;

[0163] The processor is used to read the executable instructions from the memory and execute the instructions to implement any AUTOSAR-based application processing method provided in the present disclosure.

[0164] According to one or more embodiments of the present disclosure, the present disclosure provides a computer-readable storage medium, wherein the storage medium stores a computer program, wherein the computer program is used to execute any AUTOSAR-based application processing method provided by the present disclosure.

[0165] The above description is only a preferred embodiment of the present disclosure and an explanation of the technical principles used. Those skilled in the art should understand that the scope of disclosure involved in the present disclosure is not limited to the technical solutions formed by a specific combination of the above technical features, but should also cover other technical solutions formed by any combination of the above technical features or their equivalent features without departing from the above disclosed concept. For example, the above features are replaced with the technical features with similar functions disclosed in the present disclosure (but not limited to) by each other to form a technical solution.

[0166] In addition, although each operation is described in a specific order, this should not be understood as requiring these operations to be performed in the specific order shown or in a sequential order. Under certain circumstances, multitasking and parallel processing may be advantageous. Similarly, although some specific implementation details are included in the above discussion, these should not be interpreted as limiting the scope of the present disclosure. Some features described in the context of a separate embodiment can also be implemented in a single embodiment in combination. On the contrary, the various features described in the context of a single embodiment can also be implemented in multiple embodiments individually or in any suitable sub-combination mode.

[0167] Although the subject matter has been described in language specific to structural features and / or methodological logical actions, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. On the contrary, the specific features and actions described above are merely example forms of implementing the claims.

Claims

1. An application processing method based on AUTOSAR, characterized in that: The following steps are involved: Receiving an application processing request of a vehicle, and obtaining a multi-core external graph corresponding to the application function; wherein the multi-core external graph includes: a plurality of physical cores, and configuration transfer relationships between the plurality of physical cores including between checkpoints; determining an initial checkpoint in the multi-core external graph; Transferring application function processing between the plurality of physical cores based on the initial checkpoint and the configuration transfer relationship, and acquiring a global state of each of the physical cores; The global state of each of the physical cores is matched with a preset processing condition to obtain an application processing result.

2. The AUTOSAR-based application processing method according to claim 1, characterized in that: The method for constructing the multi-core external graph includes: Determine application function information of the application function; Matching the application function information with the preset execution conditions to obtain multiple execution physical cores, and determining a monitored entity corresponding to each of the execution physical cores and a checkpoint corresponding to each of the monitored entities; Determine the configuration transfer relationship between the checkpoints corresponding to each of the monitored entities and store it in the memory corresponding to each checkpoint; The multi-core external graph is constructed based on the configuration transfer relationship.

3. The AUTOSAR-based application processing method according to claim 2, characterized in that: The application function information is matched with the preset execution conditions to obtain multiple execution physical cores, including: Analyze the application function information to obtain multiple application sub-functions; Obtaining execution priority information of each of the application sub-functions; Acquire the processing priority information of the physical core from the execution condition; In the case where the execution priority information of each of the application sub-functions matches the processing priority information of the physical core, the multiple execution physical cores are obtained.

4. The AUTOSAR-based application processing method according to claim 1, characterized in that: The transferring of application function processing between the multiple physical cores based on the initial checkpoint and the configuration transfer relationship includes: Determining a next checkpoint based on the configuration transfer relationship; When there are multiple next checkpoints, obtaining current control parameters of the application; When the current control parameters of the application match the preset transfer conditions, obtaining the next target checkpoint; The initial checkpoint is controlled to transfer to the next target checkpoint, and the step of determining the next checkpoint based on the configuration transfer relationship is performed until the checkpoint transfer is completed.

5. The AUTOSAR-based application processing method according to claim 4, characterized in that: Before controlling the initial checkpoint to transfer to the next target checkpoint, the method further includes: The flow source address is obtained through the core communication information between physical cores; Matching the flow source address with the configuration flow address in the configuration transfer relationship; When the flow source address matches the configured flow address, the initial checkpoint is controlled to start transferring to the next target checkpoint.

6. The AUTOSAR-based application processing method according to claim 1, characterized in that: The obtaining of the global state of each of the physical cores comprises: Match the transfer results of each checkpoint with the preset status conditions to obtain the status information of each monitored entity; The state information of each monitored entity is matched with preset configuration information to obtain the global state of each physical core.

7. The AUTOSAR-based application processing method according to claim 1, characterized in that: Also includes: Analyze the application processing result to obtain the current processing error number; When the current number of processing errors is greater than a preset number threshold, generating a warning message and sending it to the target device; Within a preset period, when the current number of processing errors is greater than 0 and less than or equal to the number threshold, the application processing request of the receiving vehicle is executed to obtain the multi-core external graph corresponding to the application function.

8. An AUTOSAR-based application processing device, characterized in that: include: A receiving and obtaining module, configured to receive an application processing request of a vehicle and obtain a multi-core external graph corresponding to an application function; wherein the multi-core external graph includes: a plurality of physical cores, and configuration transfer relationships between the plurality of physical cores, including between checkpoints; A first determination module, configured to determine an initial checkpoint in the multi-core external graph; A transfer module, configured to transfer application function processing between the plurality of physical cores based on the initial checkpoint and the configuration transfer relationship; A first acquisition module, used for acquiring a global state of each of the physical cores; The second determination module is used to match the global state of each of the physical cores with a preset processing condition to obtain an application processing result.

9. An electronic device, characterized in that: The electronic device comprises: processor; a memory for storing instructions executable by the processor; The processor is used to read the executable instructions from the memory and execute the executable instructions to implement the AUTOSAR-based application processing method described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and the computer program is used to execute the AUTOSAR-based application processing method according to any one of claims 1 to 7.

Images