RTE interface design method and device, multi-core controller, vehicle and medium

Abstract

The invention relates to the technical field of vehicles, in particular to an RTE interface design method and device, a multi-core controller, a vehicle and a medium, and the method comprises the steps: obtaining the function demands of each application software configuration item SWC; determining a communication demand of each application SWC according to the function demand of each application SWC, and identifying a target SWC of which the communication demand satisfies a preset high demand condition in each application SWC; and designing a runtime environment RTE interface of the target SWC and RTE interfaces of other SWCs except the target SWC, deploying the designed target SWC in a master core of the multi-core controller, and deploying the other designed SWCs in slave cores of the multi-core controller. Therefore, the problem that extra load is generated by adding a function processing module on an RTE interface layer in the prior art, and the load cannot be solved when the number of interfaces is large is solved.

Description

Technical Field

[0001] The present application relates to the field of vehicle technology, and in particular to an RTE interface design method, device, multi-core controller, vehicle and medium. Background Art

[0002] Under the AUTOSAR architecture, system software is divided into APP (Application Software Layer), RTE (Runtime Environment), BSW (Basic Software Layer) and MCU (MicroControoler).

[0003] RTE is a specific implementation of the AUTOSAR virtual function bus for a specific ECU (Electronic Control Unit), supporting communication between AUTOSAR software components, between basic software, and between software components and basic software. As multiple functions are concentrated in the central controller, the communication interaction between functions is changed from communication between controllers under a distributed architecture to communication within the controller; at the same time, with the application of in-vehicle Ethernet, the load of the central controller is greatly increased, and even problems such as controller task scheduling timeout and reset may occur due to excessive load rate.

[0004] In the related technology, the processing method is generally to add a functional processing module for interface data at the RTE layer to reduce the controller load while meeting the Ethernet communication requirements. However, in actual development, increasing the number of RTE interfaces for cross-core communication will have a significant impact on the load. Summary of the invention

[0005] The present application provides an RTE interface design method, device, multi-core controller, vehicle and medium to solve the problem that related technologies generate additional load by adding functional processing modules to the RTE interface layer, and cannot solve the load problem when there are many interfaces.

[0006] The first aspect of the present application provides an RTE interface design method, comprising the following steps: obtaining the functional requirements of each SWC (Software Configuration Item); determining the communication requirements of each application SWC according to the functional requirements of each application SWC, and identifying the target SWC in each application SWC whose communication requirements meet the preset high demand conditions; designing the runtime environment RTE interface of the target SWC and the RTE interfaces of other SWCs other than the target SWC, and deploying the designed target SWC in the master core of a multi-core controller, and deploying the designed other SWCs in the slave cores of the multi-core controller.

[0007] Optionally, the master core is a core having a functional safety level greater than a first preset level and where the communication protocol stack is located, and the slave core is a core other than the master core.

[0008] Optionally, the RTE interface of the target SWC and the RTE interfaces of other SWCs include: a controller area network CAN communication RTE interface, an Ethernet communication RTE interface, an RTE interface between SWCs, and an RTE interface of basic software.

[0009] Optionally, the design rules of the RTE interfaces of the target SWC and other SWCs are the same, and the design rules include: the CAN communication RTE interface includes: struct type, message unit, all signals in the message and received E2E communication verification results; the Ethernet communication RTE receiving interface: struct type, interface matching the opponent controller sending end and sending server, service update flag interface and event-triggered or periodic plus event-triggered service interface; the RTE interface between SWCs includes: struct type; the RTE interface of the basic software includes, struct type, or, a type designed according to the AUTOSAR standard.

[0010] Optionally, when the SWCs in both the master core and the slave core need to receive part of the signals in the same message or service, or when part of the signals of the same sent message are provided by the master core and the other part of the signals are provided by the slave core SWC, the signal content that the slave core needs to receive or the signal content that needs to be sent by the slave core interacts with the basic software through the RTE interface of the master core SWC.

[0011] Optionally, the communication requirements include load requirements, safety requirements and delay requirements, and the preset high-demand conditions include at least one of the following: the load corresponding to the load requirement is greater than the preset load; the functional safety level corresponding to the safety requirement is greater than the preset level; the delay corresponding to the delay requirement is less than a preset duration.

[0012] The second aspect of the present application provides an RTE interface design device, including: an acquisition module, used to acquire the functional requirements of each application software configuration item SWC; an identification module, used to determine the communication requirements of each application SWC according to the functional requirements of each application SWC, and identify the target SWC in each application SWC whose communication requirements meet the preset high demand conditions; a design module, used to design the runtime environment RTE interface of the target SWC and the RTE interfaces of other SWCs other than the target SWC, and deploy the designed target SWC in the main core of the multi-core controller, and deploy the designed other SWCs in the slave cores of the multi-core controller.

[0013] Optionally, the master core is a core having a functional safety level greater than a first preset level and where the communication protocol stack is located, and the slave core is a core other than the master core.

[0014] Optionally, the RTE interface of the target SWC and the RTE interfaces of other SWCs include: a controller area network CAN communication RTE interface, an Ethernet communication RTE interface, an RTE interface between SWCs, and an RTE interface of basic software.

[0015] Optionally, the deployment rules of the RTE interfaces of the target SWC and other SWCs are the same, and the deployment rules include: the CAN communication RTE interface includes: struct type, message unit, all signals in the message and the received E2E communication verification result; the Ethernet communication RTE receiving interface: struct type, interface matching the opponent controller sending end and sending server, service update flag interface and event-triggered or periodic plus event-triggered service interface; the RTE interface between SWCs includes: struct type; the RTE interface of the basic software includes, struct type, or, a type designed according to the AUTOSAR standard.

[0016] Optionally, when the SWCs in both the master core and the slave core need to receive part of the signals in the same message or service, or when part of the signals of the same sent message are provided by the master core and the other part of the signals are provided by the slave core SWC, the signal content that the slave core needs to receive or the signal content that needs to be sent by the slave core interacts with the basic software through the RTE interface of the master core SWC.

[0017] Optionally, the communication requirements include load requirements, safety requirements and delay requirements, and the preset high-demand conditions include at least one of the following: the load corresponding to the load requirement is greater than the preset load; the functional safety level corresponding to the safety requirement is greater than the preset level; the delay corresponding to the delay requirement is less than a preset duration.

[0018] A third aspect of the present application provides a multi-core controller, which includes a master core, a slave core, and RTE interfaces of the master core and the slave core, respectively. The RTE interface is designed based on the RTE interface design method of the above embodiment.

[0019] A fourth aspect of the present application provides a vehicle, comprising: a multi-core controller of the above embodiment.

[0020] The fifth aspect of the present application provides a computer-readable storage medium on which a computer program is stored. The program is executed by a processor to implement the RTE interface design method as described in the above embodiment.

[0021] Therefore, this application includes the following beneficial effects:

[0022] The embodiment of the present application can sort out the communication requirements of each SWC according to the functional requirements of each application SWC, deploy the SWC with high communication requirements in the main core where the communication protocol stack is located, and deploy the RTE interface of other SWCs in the slave core of the multi-core controller. According to the communication requirements of SWCs in other slave cores, a cross-core RTE interface is designed to reduce RTE, especially cross-core interface sorting, and reduce RTE interface cycle, so as to reduce the controller load and ensure the safe and stable operation of the software, while meeting the real-time and security requirements of the application SWC. Therefore, it is solved that the method of adding a functional processing module to the RTE interface layer in the related art will generate additional load and cannot solve the load problem when there are many interfaces.

[0023] Additional aspects and advantages of the present application will be given in part in the description below, and in part will become apparent from the description below, or will be learned through the practice of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] The above and / or additional aspects and advantages of the present application will become apparent and easily understood from the following description of the embodiments in conjunction with the accompanying drawings, in which:

[0025] Figure 1 A flowchart of an RTE interface design method provided according to an embodiment of the present application;

[0026] Figure 2 An example diagram of an RTE interface design provided according to an embodiment of the present application;

[0027] Figure 3 An example diagram of RTE interface design principles provided according to an embodiment of the present application;

[0028] Figure 4 This is an example diagram of an RTE interface design device provided according to an embodiment of the present application. DETAILED DESCRIPTION

[0029] The embodiments of the present application are described in detail below, and examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are intended to be used to explain the present application, and should not be construed as limiting the present application.

[0030] The following describes the RTE interface design method, device, multi-core controller, vehicle and storage medium of the embodiment of the present application with reference to the accompanying drawings. In response to the problems mentioned in the above background technology, the present application provides an RTE interface design method, in which, according to the functional requirements of each application SWC, the communication requirements of each SWC are sorted out, and the SWC with high communication requirements is deployed in the main core where the communication protocol stack is located, and the RTE interface of other SWCs is deployed in the slave core of the multi-core controller. The cross-core RTE interface is designed according to the communication requirements of the SWC in other slave cores, so as to reduce the RTE, especially the cross-core interface sorting, and reduce the RTE interface cycle, so as to reduce the controller load and ensure the safe and stable operation of the software, while meeting the real-time and security of the application SWC. Thus, it is solved that the method of adding a functional processing module to the RTE interface layer in the related technology will generate additional load and cannot solve the load problem when there are many interfaces.

[0031] Specifically, Figure 1 A flowchart of an RTE interface design method provided in an embodiment of the present application.

[0032] like Figure 1 As shown, the RTE interface design method includes the following steps:

[0033] In step S101, the functional requirements of each application software configuration item SWC are obtained.

[0034] The embodiment of the present application can first obtain the functional requirements of each application software configuration item SWC, determine the content of the signal to be sent and received according to the functional requirements of the application SWC, and determine whether to use CAN communication or Ethernet communication according to the real-time requirements of the signal.

[0035] In step S102, the communication requirements of each application SWC are determined according to the functional requirements of each application SWC, and the target SWCs whose communication requirements meet the preset high demand conditions are identified among the application SWCs.

[0036] Among them, the communication requirements include load requirements, safety requirements and delay requirements, and the preset high demand conditions include at least one of the following: the load corresponding to the load requirement is greater than the preset load; the functional safety level corresponding to the safety requirement is greater than the preset level; the delay corresponding to the delay requirement is less than the preset duration. Among them, the preset load, preset duration and preset level can be set according to actual conditions, such as the functional safety requirement level C or D signal needs to use CAN communication; the communication rate requirement is 20ms and less than 20ms to use CAN communication; other demand signals reasonably use CAN communication or Ethernet communication according to the situation of the opponent controller.

[0037] In step S103, the runtime environment RTE interface of the target SWC and the RTE interfaces of other SWCs other than the target SWC are designed, and the designed target SWC is deployed in the master core of the multi-core controller, and the designed other SWCs are deployed in the slave cores of the multi-core controller.

[0038] It is understandable that if Figure 2 As shown, the embodiment of the present application can sort out the communication requirements of each SWC according to the functional requirements of each application SWC, and further determine the deployment of SWC in the multi-core controller. That is, the SWC with high communication requirements is deployed in the main core where the communication protocol stack is located, and the RTE interface of other SWCs other than the target SWC in each application SWC is deployed in the slave core of the multi-core controller. The cross-core RTE interface is designed according to the communication requirements of the SWC in other slave cores, so as to reduce the RTE, especially the cross-core interface combing, and reduce the RTE interface cycle under the premise of meeting the real-time and security of the application SWC, so as to reduce the controller load and ensure the safe and stable operation of the software. Among them, the main core is a core with a functional safety level greater than the first preset level and where the communication protocol stack is located, and the slave core is a core other than the main core. The first preset level can be set according to the actual situation and is not specifically limited. In addition to the reserved load that the program can run stably, the application SWC with more CAN communication signal requirements is preferentially deployed in the main core, and other SWCs are deployed to the slave core according to the functional safety requirements and load conditions.

[0039] In one embodiment of the present application, the design rules of the RTE interfaces of the target SWC and other SWCs are the same, and the deployment rules include: the CAN communication RTE interface includes: struct type, message unit, all signals in the message and received E2E communication verification results; Ethernet communication RTE receiving interface: struct type, interface matching the opponent controller sending end and sending server, service update flag interface and event-triggered or periodic plus event-triggered service interface; the RTE interface between SWCs includes: struct type; the RTE interface of the basic software includes, struct type, or, a type designed according to the AUTOSAR standard.

[0040] It is understandable that if Figure 3 As shown in the figure, the SWC interfaces used in the main core mainly include the CAN communication RTE interface, the Ethernet communication RTE interface, the RTE interface between SWCs, and the RTE interface between the basic software and the communication. The SWC interfaces used in the slave core also include the CAN communication RTE interface, the Ethernet communication RTE interface, the RTE interface between SWCs, and the RTE interface between the basic software and the communication. The design principles are the same, as follows:

[0041] 1. The CAN communication RTE interface is designed in the form of struct, with messages as units. The interface members include all signals in the message. The receiving interface should also include the E2E communication verification results, so that the application SWC can identify and handle faults based on the interface;

[0042] 2. The Ethernet communication RTE receiving interface follows the design of the opponent controller's sending end, and a service update flag (updatebit) interface needs to be added for service update status and communication fault judgment; the Ethernet communication RTE sending interface is designed according to the sending service type, and event-triggered (onchange) or cycle plus event-triggered (cycle+onchange) services will be designed as separate service interfaces; for cycle type (cycle) services, multiple services are combined according to functional division and the receiver's situation and designed into a struct form, that is, cycle services with the same function or sent to the same opponent controller can be designed as a struct type RTE interface.

[0043] 3. The RTE interface between SWCs, especially the RTE interface between cross-core SWCs, is designed in struct form, which helps to reduce the number of interfaces and reduce the system load.

[0044] 4. The interfaces between SWC and basic software other than communication should be designed according to the AUTOSAR standard requirements. If there are no special requirements, it is recommended to use the struct type.

[0045] Furthermore, when the SWCs in both the master core and the slave core need to receive part of the signals in the same message or service, or when part of the signals of the same sent message are provided by the master core and the other part of the signals are provided by the slave core SWC, the signal content that the slave core needs to receive or the signal content that needs to be sent is transmitted through the RTE interface between the master core and the slave core, and interacts with the basic software through the RTE interface of the master core SWC, which can reduce the number of RTE interfaces across the core SWCs and the number of RTE interfaces between the application and the basic software.

[0046] The following embodiment of the present application can take the power domain controller software as an example to introduce the specific example of the RTE interface design of the embodiment of the present application in the multi-core controller. The power domain control software generally includes driving control function, high-voltage power supply management function, and thermal management control function. In the embodiment of the present application, each function corresponds to a SWC, that is, a total of three application SWCs, the driving SWC functional safety level ASILD, the high-voltage SWC functional safety level ASILB, and the thermal management SWC functional safety level QM. The power domain controller adopts the Classic AUTOSAR architecture, with a total of four cores, of which core0 is the master core where the basic software communication protocol stack is located, and the other cores are slave cores, of which core0 and core1 meet the functional safety ASILD requirements, and the functional safety level of core2 and core3 is QM as follows:

[0047] 1) The driving SWC mainly interacts with the motor and chassis-related controllers, with a functional safety level of ASILD, a high signal function safety level, and a short communication interaction cycle, using CAN communication; in addition to communicating with high-voltage related controllers such as BMS and DCDC, the high-voltage SWC also interacts with controllers such as instruments and TBOX. The communication method is mainly determined based on the situation of the opponent controller: CAN communication is still used with high-voltage related controllers, and Ethernet communication is used with controllers such as instruments and TBOX; the thermal management SWC communication also determines the communication method based on the situation of the opponent controller, communicating with thermal management accessories through CAN, and communicating with the air conditioner through Ethernet.

[0048] 2) The driving SWC and other controllers mainly use CAN communication, and the number of interactive messages is large, so the driving SWC is deployed in core0; since the main functions of the basic software are deployed in core0, considering the program running stability and future function expansion, the core0 load is not enough to support the deployment of other application SWCs. The high-voltage SWC has functional safety requirements, so this SWC is deployed in core1. Since core1 has sufficient load space and in order to reduce the number of cross-core interfaces, the thermal management SWC is also deployed in core1.

[0049] 3) Driving SWC RTE interface includes CAN communication RTE interface, SWC inter-RTE interface, diagnostic RTE interface and NVMRTE interface:

[0050] 3.1 Driving SWC CAN communication RTE interface is used to receive and send interactive signals with the motor controller and chassis controller. The RTE interface is designed in struct form. Each interface corresponds to a message. The struct members in the receiving message interface include not only the signal content in the message, but also the E2E communication verification results;

[0051] 3.2 There are two types of RTE interfaces between the driving SWC and the high-voltage SWC and thermal management SWC. One type is the routing signal interface. The driving SWC forwards the motor and chassis controller signals that the high-voltage and thermal management functions need to receive to the corresponding SWC. There is one interface between every two SWCs. The interface type is struct, which reduces the number of interfaces. The other type is the internal logic interaction signal. There is one interface between every two SWCs. The interface type is struct.

[0052] 3.3 Driving SWC diagnosis and NVMRTE interface directly call the standard interface provided by the basic software.

[0053] 4) High-voltage SWCRTE interface includes CAN communication RTE interface, Ethernet communication RTE interface, RTE interface between SWCs, diagnostic RTE interface, and NVMRTE interface:

[0054] 4.1 The high-voltage SWC CAN communication RTE interface is used to receive and send interactive signals with high-voltage controllers such as BMS, DCDC, and Charger. The RTE interface is designed in struct form. Each interface corresponds to a message. The struct members in the receiving message interface include not only the signal content in the message, but also the E2E communication verification results;

[0055] 4.2 The high-voltage SWC Ethernet RTE interface is used to receive and send interactive signals with the instrument controller and the TBOX controller; the definition of the receiving service interface is implemented according to the definition of the counterpart, and the corresponding updatebit interface needs to be added for timeout and signal reception status judgment; the high-voltage SWC sends status services such as charging status, high-voltage power-on status or continuous physical quantities such as high-voltage voltage values, which need to be defined as periodic, and multiple periodic signals are combined into a struct form and sent to the outside through an RTE interface; the high-voltage SWC sends instruction services defined as cycle+onchg type, such as charging indicator light control instructions, and the cycle period can be set to 1s, which can reduce the load and ensure reliability; the high-voltage SWC sends feedback services defined as onchg type, such as feedback after receiving the user's timed charging setting instructions, and continuously sends 3 frames each time the service value changes, and the period of each frame is designed to be 100ms or 1s according to the requirements;

[0056] 4.3 The RTE interface design method between the high-voltage SWC and the driving SWC and thermal management SWC is the same as described in 3.2;

[0057] 4.4 High voltage SWC diagnosis and NVM RTE interface directly call the basic software to provide a standard interface.

[0058] 5) Thermal management SWCRTE interface includes CAN communication interface, Ethernet communication interface, interface between SWCs, diagnostic interface, and NVM interface:

[0059] 5.1 The thermal management SWCCAN communication interface is used to receive and send interactive signals with controllers such as water pumps, water valves, and fans. The RTE interface is designed in struct form. Each interface corresponds to a message. The struct members in the receiving message interface include not only the signal content in the message, but also the E2E communication verification results;

[0060] 5.2 The Ethernet interface of the thermal management SWC is used to receive and send interactive signals with the air-conditioning controller; the definition of the receiving service interface is implemented according to the definition of the counterpart, and the corresponding updatebit interface needs to be added for timeout and signal reception status judgment; the status services sent by the thermal management SWC, such as the battery heating status or continuous physical quantities such as the battery water channel temperature, need to be defined as periodic, and multiple status signals are combined into a struct form and sent to the outside through an RTE interface; the instruction services sent by the thermal management SWC are defined as the cycle+onchg type, such as the cooling control instruction, and the cycle period can be set to 1s, which can reduce the load and ensure reliability at the same time; the feedback services sent by the thermal management SWC are defined as the onchg type, such as feedback after receiving the request to start the high-voltage heater, and 3 frames are continuously sent each time a change occurs, and the period of each frame is designed to be 100ms or 1s according to the requirements;

[0061] 5.3 The RTE interface design method between the thermal management SWC and the high-voltage SWC and driving SWC is the same as described in 3.2;

[0062] 5.4 Thermal management SWC diagnosis and NVMRTE interface directly call the basic software to provide a standard interface.

[0063] According to the RTE interface design method proposed in the embodiment of the present application, according to the functional requirements of each application SWC, the communication requirements of each SWC are sorted out, and the SWC with high communication requirements is deployed in the main core where the communication protocol stack is located. According to the communication requirements of SWC in other slave cores, the cross-core RTE interface is designed to reduce the RTE, especially the cross-core interface sorting, and reduce the RTE interface cycle, so as to reduce the controller load and ensure the safe and stable operation of the software. In this way, the problem that the method of adding functional processing modules to the RTE interface layer in the related technology will generate additional load and cannot solve the load problem when there are many interfaces is solved.

[0064] Next, the RTE interface design device proposed according to the embodiment of the present application is described with reference to the accompanying drawings.

[0065] Figure 4It is a block diagram of the RTE interface design device of an embodiment of the present application.

[0066] like Figure 4 As shown, the RTE interface design device 10 includes: an acquisition module 100 , an identification module 200 and a design module 300 .

[0067] Among them, the acquisition module 100 is used to obtain the functional requirements of each application software configuration item SWC; the identification module 200 is used to determine the communication requirements of each application SWC according to the functional requirements of each application SWC, and identify the target SWC in each application SWC whose communication requirements meet the preset high demand conditions; the design module 300 is used to design the runtime environment RTE interface of the target SWC and the RTE interface of other SWCs other than the target SWC, and deploy the designed target SWC in the main core of the multi-core controller, and deploy the designed other SWCs in the slave core of the multi-core controller.

[0068] In one embodiment of the present application, the master core is a core having a functional safety level greater than a first preset level and where the communication protocol stack is located, and the slave core is a core other than the master core.

[0069] In one embodiment of the present application, optionally, the RTE interface of the target SWC and the RTE interfaces of other SWCs include: a controller area network CAN communication RTE interface, an Ethernet communication RTE interface, an RTE interface between SWCs, and an RTE interface of basic software.

[0070] In one embodiment of the present application, the design rules of the RTE interfaces of the target SWC and other SWCs are the same, and the deployment rules include: the CAN communication RTE interface includes: struct type, message unit, all signals in the message and received E2E communication verification results; Ethernet communication RTE receiving interface: struct type, interface matching the opponent controller sending end and sending server, service update flag interface and event-triggered or periodic plus event-triggered service interface; the RTE interface between SWCs includes: struct type; the RTE interface of the basic software includes, struct type, or, a type designed according to the AUTOSAR standard.

[0071] In one embodiment of the present application, when the SWCs in both the master core and the slave core need to receive part of the signals in the same message or service, or when part of the signals of the same sent message are provided by the master core and the other part of the signals are provided by the slave core SWC, the signal content that the slave core needs to receive or the signal content that needs to be sent by the slave core interacts with the basic software through the RTE interface between the master core and the slave core.

[0072] In one embodiment of the present application, communication requirements include load requirements, safety requirements and delay requirements, and the preset high demand conditions include at least one of the following: the load corresponding to the load requirement is greater than the preset load; the functional safety level corresponding to the safety requirement is greater than the preset level; the delay corresponding to the delay requirement is less than the preset duration.

[0073] It should be noted that the aforementioned explanation of the RTE interface design method embodiment is also applicable to the RTE interface design device of this embodiment, and will not be repeated here.

[0074] According to the RTE interface design device proposed in the embodiment of the present application, according to the functional requirements of each application SWC, the communication requirements of each SWC are sorted out, and the SWC with high communication requirements is deployed in the main core where the communication protocol stack is located. According to the communication requirements of SWC in other slave cores, the cross-core RTE interface is designed, so as to reduce the RTE, especially the cross-core interface sorting, and reduce the RTE interface cycle under the premise of meeting the real-time and security of the application SWC, so as to reduce the controller load and ensure the safe and stable operation of the software. Therefore, it is solved that the method of adding functional processing modules to the RTE interface layer in the related technology will generate additional load and cannot solve the load problem when there are many interfaces.

[0075] In addition, an embodiment of the present application also provides a multi-core controller, which includes a master core, a slave core, and an RTE interface deployed on the master core and the slave core, and the RTE interface is designed based on the RTE interface design method of the above embodiment.

[0076] An embodiment of the present application also provides a vehicle, comprising the multi-core controller of the above embodiment.

[0077] An embodiment of the present application also provides a computer-readable storage medium on which a computer program is stored. When the program is executed by a processor, the above RTE interface design method is implemented.

[0078] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" etc. means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present application. In this specification, the schematic representations of the above terms are not necessarily directed to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or N embodiments or examples in a suitable manner. In addition, those skilled in the art may combine and combine the different embodiments or examples described in this specification and the features of the different embodiments or examples, without contradiction.

[0079] In addition, the terms "first" and "second" are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include at least one of the features. In the description of this application, "N" means at least two, such as two, three, etc., unless otherwise clearly and specifically defined.

[0080] Any process or method description in a flowchart or otherwise described herein may be understood to represent a module, fragment or portion of code comprising one or N executable instructions for implementing the steps of a custom logical function or process, and the scope of the preferred embodiments of the present application includes alternative implementations in which functions may not be performed in the order shown or discussed, including performing functions in a substantially simultaneous manner or in reverse order depending on the functions involved, which should be understood by technicians in the technical field to which the embodiments of the present application belong.

[0081] It should be understood that the various parts of the present application can be implemented in hardware, software, firmware or a combination thereof. In the above-mentioned embodiments, the steps or methods can be implemented in software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented by any one of the following technologies known in the art or their combination: a discrete logic circuit having a logic gate circuit for implementing a logic function on a data signal, a dedicated integrated circuit having a suitable combination of logic gate circuits, a programmable gate array, a field programmable gate array, etc.

[0082] A person of ordinary skill in the art may understand that all or part of the steps carried by the method for implementing the above-mentioned embodiment may be completed by instructing related hardware through a program, and the above-mentioned program may be stored in a computer-readable storage medium, which, when executed, includes one of the steps of the method embodiment or a combination thereof.

[0083] Although the embodiments of the present application have been shown and described above, it can be understood that the above embodiments are exemplary and cannot be understood as limitations on the present application. Ordinary technicians in this field can change, modify, replace and modify the above embodiments within the scope of the present application.

Claims

1. A RTE interface design method, characterized in that: The following steps are involved: Obtain the functional requirements of each application software configuration item SWC; Determine the communication requirements of each application SWC according to the functional requirements of each application SWC, and identify the target SWC whose communication requirements meet the preset high demand condition among the application SWCs; Design the runtime environment RTE interface of the target SWC and the RTE interfaces of other SWCs other than the target SWC, deploy the designed target SWC in the master core of the multi-core controller, and deploy the designed other SWCs in the slave cores of the multi-core controller.

2. The RTE interface design method according to claim 1, characterized in that: The master core is a core whose functional safety level is greater than a first preset level and where a communication protocol stack is located, and the slave core is a core other than the master core.

3. The RTE interface design method according to claim 1, characterized in that: The RTE interface of the target SWC and the RTE interface of the other SWCs include: a controller area network CAN communication RTE interface, an Ethernet communication RTE interface, an RTE interface between SWCs, and an RTE interface of basic software.

4. The RTE interface design method according to claim 3, characterized in that: The design rules of the RTE interface of the target SWC and the other SWCs are the same, and the design rules include: The CAN communication RTE interface includes: struct type, message unit, all signals in the message and received E2E communication verification results; The Ethernet communication RTE receiving interface: struct type, interface matching the opponent controller sending end and sending server, service update flag interface and event-triggered or periodic plus event-triggered service interface; The RTE interface between the SWCs includes: struct type; The RTE interface of the basic software includes a struct type, or a type designed according to the AUTOSAR standard.

5. The RTE interface design method according to claim 3, characterized in that: When the SWCs in the master core and the slave core both need to receive part of the signals in the same message or service, or part of the signals of the same sent message are provided by the master core and the other part of the signals are provided by the slave core SWC, the signal content that the slave core needs to receive or the signal content that needs to be sent by the slave core is transmitted through the RTE interface between the master core and the slave core, and interacts with the basic software through the RTE interface of the master core SWC.

6. The RTE interface design method according to claim 1, characterized in that: The communication requirements include load requirements, security requirements, and delay requirements, and the preset high demand conditions include at least one of the following: The load corresponding to the load demand is greater than the preset load; The functional safety level corresponding to the safety requirement is greater than the preset level; The delay corresponding to the delay requirement is less than the preset duration.

7. An RTE interface design device, characterized in that: include: The acquisition module is used to obtain the functional requirements of each application software configuration item SWC; An identification module, used to determine the communication requirements of each application SWC according to the functional requirements of each application SWC, and identify the target SWC whose communication requirements meet the preset high demand condition among the application SWCs; The design module is used to design the runtime environment RTE interface of the target SWC and the RTE interface of other SWCs other than the target SWC, and deploy the designed target SWC in the main core of the multi-core controller and deploy the designed other SWCs in the slave cores of the multi-core controller.

8. A multi-core controller, characterized in that: The multi-core controller includes a master core, a slave core, and respective RTE interfaces of the master core and the slave core, wherein the RTE interface is designed based on the RTE interface design method according to any one of claims 1 to 6.

9. A vehicle, characterized in that: Includes the multi-core controller as described in claim 8.

10. A computer-readable storage medium having a computer program or instruction stored thereon, characterized in that: When the computer program or instruction is executed, the RTE interface design method described in any one of claims 1 to 6 is implemented.

Images