Automobile open system architecture, state management method and device

Abstract

The embodiment of the present application provides an automotive open system architecture, a state management method and a device, wherein a state management module is set at the application layer, and SWC can receive BSW and MCAL related information, and then aggregate it to the state management module through VFB for unified processing. That is, the state management function is implemented at the application layer, and the same events generated by different modules in BSW can be abstracted as one event in SWC, thereby shielding the event distinction of subdivided modules in BSW, and applied to smart cars and new energy vehicles. The architecture provided by the embodiment of the present application is easy to deploy and easy to implement.

Description

Technical Field

[0001] The present application relates to communication technology, and in particular to an automotive open system architecture, a state management method and a device. Background Art

[0002] The automotive open system architecture (AUTOSAR) has established an open standard for the basic software architecture of automobiles, which is widely used in automotive electronic control systems. In the AUTOSAR architecture, if an event occurs that causes the system state to change, state management is required.

[0003] Usually, the state management function is implemented in the basic software layer. When performing state management, if the event comes from the application, multiple interactions between the application layer and the basic software layer are required, which makes the implementation more complicated. If the event comes from the basic software layer, there are many subdivided modules in the basic software layer, and the events generated by each subdivided module need to be processed differently, making it difficult to implement state management deployment. Summary of the invention

[0004] The embodiments of the present application provide an automotive open system architecture, a state management method and a device to reduce the difficulty of implementing state management in the AUTOSAR architecture.

[0005] In the first aspect, the embodiment of the present application provides an automotive open system architecture, including: an application layer, an operating environment layer and a basic software layer; a state management module is set in the application layer; the application layer and the basic software layer communicate through the operating environment layer; the state management module is used to: receive events from the application layer or the basic software layer; when the event meets the judgment rule of the state management module, calculate the system state corresponding to the event; when the system state corresponding to the event is different from the current system state of the automotive open system, send state migration information including the system state corresponding to the event to one or more software components (softwarecomponent, SWC) in the automotive open system that need to perform state migration, and the state migration information is used to indicate that the one or more SWCs migrate the state to the system state corresponding to the event, and the state migration information is used to indicate that the one or more SWCs migrate the state to the system state corresponding to the event. In the embodiment of the present application, a state management module is set in the application layer in the AUTOSAR architecture, and the SWC can receive relevant information such as basic software (basic software, BSW) and microcontroller abstraction layer (microcontroller abstraction layer, MCAL), and then summarize it to the state management module for unified processing. That is, the state management function is implemented at the application layer. The same events generated by different modules in BSW can be abstracted into one event in SWC, thereby shielding the event differences between different modules of BSW, making it easy to deploy and implement.

[0006] In a possible design, the application layer and the basic software layer communicate via a virtual functional bus (VFB) of the operating environment layer, and the state management module is specifically used to distribute the state migration information to one or more software components SWCs that need to perform state migration via the VFB. The VFB can be used to isolate the upper application layer from the lower basic software layer, supporting the independence of software and hardware modules.

[0007] In a possible design, the state management module is further used to: receive state transition feedback information from the one or more SWCs, and the state transition feedback information is used to feedback the state transition of the one or more SWCs. In this way, the state management module can understand the state transition of the SWC, which is more conducive to state management.

[0008] In a possible design, the state management module includes a finite state machine submodule; the state management module is specifically used to: when the state of the finite state machine submodule is an idle state, modify the state of the finite state machine submodule to a running state; use the finite state machine submodule to calculate the system state corresponding to the event; when the system state corresponding to the event is different from the current system state of the automotive open system, use the finite state machine submodule to send the state migration information to the one or more SWCs; set the state of the finite state machine submodule to an idle state. In this way, the finite state machine submodule can process one event at a time to ensure the independence of a single update state.

[0009] In a possible design, the finite state machine submodule includes: a state migration pre-processing unit, a state migration calculation unit and a state migration post-processing unit; the state migration pre-processing unit is used to confirm that one or more SWCs that need state migration are in a state capable of executing state migration before sending the state migration information; the state migration calculation unit is used to calculate the system state corresponding to the event; the state migration post-processing unit is used to send the state migration information to the one or more SWCs. This can improve the efficiency of state migration.

[0010] In one possible design, the state management module includes an operating environment adaptation submodule and a state management context submodule; the operating environment adaptation submodule is used to adapt the operating environment layer; the state management context submodule is used to store the event when the state management module determines that the event is a legitimate event.

[0011] In a possible design, the state management module is further used to: when there are multiple events from the application layer or the basic software layer, select one of the multiple events for processing, thereby avoiding event processing conflicts.

[0012] In a possible design, the state management module is specifically used to: when there are multiple events from the application layer or the basic software layer, select one of the multiple events for processing according to the priority of the multiple events; or, according to the order in which the multiple events are received, select one of the multiple events for processing using a first-in-first-out rule.

[0013] In a possible design, the SWC receiving interface of the state management module does not distinguish SWC differences, thereby simplifying the system interface design and saving the number of interfaces.

[0014] In a possible design, the events from the basic software layer are abstracted as events that do not distinguish between subdivided modules in the basic software layer, so that BSW differences can be shielded and state management can be easily implemented.

[0015] In a second aspect, an embodiment of the present application provides a state management method, comprising: receiving an event from the application layer or the basic software layer; when the event satisfies a judgment rule, calculating the system state corresponding to the event; when the system state corresponding to the event is different from the current system state of the automobile open system, sending state migration information including the system state corresponding to the event to one or more software components SWC in the automobile open system that need to perform state migration, wherein the state migration information is used to instruct the one or more SWCs to migrate the state to the system state corresponding to the event.

[0016] In a possible design, the state migration information including the system state corresponding to the event is sent to one or more software components SWC in the automotive open system that need to perform state migration, including: distributing the state migration information to the one or more software components SWC through a virtual function bus VFB.

[0017] In a possible design, it also includes: receiving state transition feedback information from the one or more SWCs, where the state transition feedback information is used to feedback state transition conditions of the one or more SWCs.

[0018] In one possible design, the calculating of the system state corresponding to the event includes: when the state of the finite state machine sub-module is an idle state, modifying the state of the finite state machine sub-module to a running state; using the finite state machine sub-module to calculate the system state corresponding to the event; when the system state corresponding to the event is different from the current system state of the automobile open system, sending state migration information including the system state corresponding to the event to one or more software components SWC in the automobile open system that need to perform state migration, including: when the system state corresponding to the event is different from the current system state of the automobile open system, using the finite state machine sub-module to send state migration information including the system state corresponding to the event to one or more SWCs in the automobile open system that need to perform state migration; setting the state of the finite state machine sub-module to an idle state.

[0019] In a possible design, the method further includes: confirming that the one or more SWCs requiring state migration are in a state capable of executing the state migration.

[0020] In a possible design, when the event satisfies a judgment rule, calculating the system state corresponding to the event includes: when the event is a legal event, calculating the system state corresponding to the event.

[0021] In a possible design, it also includes: when there are multiple events from the application layer or the basic software layer, selecting one of the multiple events for processing.

[0022] In one possible design, when there are multiple events from the application layer or the basic software layer, selecting one of the multiple events for processing includes: when there are multiple events from the application layer or the basic software layer, selecting one of the multiple events for processing according to the priorities of the multiple events; or selecting one of the multiple events for processing according to the order in which the multiple events are received using a first-in-first-out rule.

[0023] In a third aspect, an embodiment of the present application provides a state processing unit, which is used to execute the state management method described in any possible design of the second aspect to the second aspect.

[0024] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, in which a computer program or instruction is stored. When the computer program or instruction is run on a computer, the computer executes a state management method as described in any possible design of the second aspect to the second aspect.

[0025] In summary, unlike the conventional AUTOSAR architecture, in the AUTOSAR architecture of the embodiment of the present application, a state management module is set in the application layer, and SWC can receive BSW and MCAL related information, and then aggregate it to the state management module through VFB for unified processing. That is, the state management function is implemented in the application layer, and the same event generated by different modules in BSW can be abstracted as one event in SWC, thereby shielding the event distinction of subdivided modules in BSW, and easy to deploy and easy to implement. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] Figure 1 A schematic diagram of a typical automotive open system architecture;

[0027] Figure 2 A schematic diagram of an automotive open system architecture provided in an embodiment of the present application;

[0028] Figure 3 A schematic diagram of interfaces in an automotive open system architecture according to an embodiment of the present application;

[0029] Figure 4 A schematic diagram of the structure of a state management module in an embodiment of the present application;

[0030] Figure 5 A flowchart of a state management method provided in an embodiment of the present application. DETAILED DESCRIPTION

[0031] In order to facilitate the clear description of the technical solutions of the embodiments of the present application, in the embodiments of the present application, the words "first", "second" and the like are used to distinguish the same items or similar items with substantially the same functions and effects. For example, the first event and the second event are only used to distinguish different events, and their order of precedence is not limited. Those skilled in the art can understand that the words "first", "second" and the like do not limit the quantity and execution order, and the words "first", "second" and the like do not necessarily limit them to be different.

[0032] It should be noted that, in this application, words such as "exemplary" or "for example" are used to indicate examples, illustrations or descriptions. Any embodiment or design described as "exemplary" or "for example" in this application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary" or "for example" is intended to present related concepts in a specific way.

[0033] In the present application, "at least one" means one or more, and "plurality" means two or more. "And / or" describes the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone, where A and B can be singular or plural. The character " / " generally indicates that the previous and next associated objects are in an "or" relationship. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can mean: a, b, c, ab, ac, bc, or abc, where a, b, c can be single or multiple.

[0034] The method of the embodiment of the present application can be applied in an automotive electronic control system implemented based on the AUTOSAR system architecture concept.

[0035] The AUTOSAR architecture adopts a layered design. The operating environment layer is implemented as a virtual functional bus (VFB), which isolates the upper application layer from the lower basic software layer. It gets rid of the previous dependence on the hardware system during the software development and verification of the electronic control unit (ECU), and supports the independence of software and hardware modules.

[0036] VFB is an abstraction of the underlying basic software and network topology. It is a collection of all communication mechanisms provided by AUTOSAR. In the process of information data interaction, the application is modeled as a software component (SWC). When the system is configured, the software component will be mapped to the specified ECU, and the virtual connection between components will also be mapped to various actual transmission buses. Finally, the software component uses the pre-defined ports to achieve communication through VFB.

[0037] In the AUTOSAR architecture, SWCs do not communicate directly with each other. After the operating environment encapsulates the lower-level basic software, it provides the upper layer with the operating environment application programming interface (API) required for data communication, and then interacts using ports or sender-receiver communication or client-server communication.

[0038] For example, Figure 1 This is a schematic diagram of the common AUTOSAR system architecture. Figure 1 As shown in Figure 1, the AUTOSAR architecture is divided into three software layers at the highest level of abstraction: the application layer (also called the application layer), the runtime environment (RTE), and the basic software (BSW) layer running on the microcontroller.

[0039] RTE is a layer that provides communication services for application software (such as AUTOSAR software components and / or AUTOSAR sensor / actuator components). AUTOSAR software components can communicate with other components (such as internal and / or internal ECUs) or services through RTE. RTE can also be understood as the implementation of the VFB interface on a single ECU, or as the creation of objects in an object-oriented programming language.

[0040] BSW is further divided into services layer, ECU abstraction layer, microcontroller abstraction layer (MCAL) and complex drivers layer. These subdivided layers can be called subdivided modules of BSW, or subdivided layers of BSW, etc.

[0041] The Services layer is the highest layer of the basic software. The Services layer is further divided into system services, memory services, and communication services.

[0042] The ECU abstraction layer is further divided into onboard device abstraction, memory hardware abstraction, communication hardware abstraction, and I / O hardware abstraction.

[0043] Microcontroller abstraction layer is the lowest layer of BSW, which contains internal drivers, etc. Microcontroller abstraction layer is further divided into microcontroller drivers, memory drivers, communication drivers, and I / O drivers.

[0044] Complex drivers span from hardware to RTE. Their main task is to integrate non-standard functional modules with special purposes and embed these functions into the AUTOSAR basic software layer, so as to realize the specific functions and time requirements of complex sensors and actuators. Complex drivers are closely related to microcontrollers and ECU hardware. Their upper-level program interfaces are specified and implemented according to AUTOSAR; their lower-level program interfaces are restricted by standard interface programs. Complex drivers can realize the evaluation of complex sensors and the control of actuators, such as injection control, solenoid valve control, incremental position detection, etc.

[0045] BSW can be used to provide the following services. System: Provide standardized provisions (e.g. for operating systems, timers, and error memories), ECU-specific services (e.g. ECU status management, watchdog management), and library functions. Memory: Standardize access to internal and external memory (non-volatile memory). Communication: Standardize access to the vehicle network system, ECU communication system, and ECU internal software. Input / Output: Standardize access to sensors, actuators, and ECU peripherals.

[0046] Among them, in the above AUTOSAR architecture, there is an ECU statemanager module in the system services layer of BSW, which can manage the ECU state based on ECU state manage. For example, after receiving an event message, the ECU state manager is configured to interact with other underlying modules of the ECU to achieve state processing.

[0047] That is, in the usual AUTOSAR architecture, the state management function is implemented in BSW. When performing state management, if the event comes from the application, multiple interactions between the application layer and the bottom layer are required, and the implementation is relatively complicated. If the event comes from the BSW layer, as mentioned above, the BSW layer has many subdivided modules, and the events generated by each module need to be processed differently, making it difficult for the BSW layer to support a large number of differentiated events.

[0048] Based on this, the embodiment of the present application sets a state management module in the application layer of the AUTOSAR architecture, and SWC can receive BSW and MCAL related information, and then summarize it to the state management module through VFB for unified processing. That is, the state management function is implemented in the application layer, and the same event generated by different modules in BSW can be abstracted as one event in SWC, so that the event difference between different modules of BSW can be shielded, and the deployment is easy and easy to implement.

[0049] For example, Figure 2 A schematic diagram of an automotive open system architecture according to an embodiment of the present application.

[0050] like Figure 2 As shown, in the embodiment of the present application, a state management module is set in the application layer, and the SWC can receive BSW and MCAL related information, and then summarize it to the state management module through VFB for unified processing.

[0051] For example, the subdivided modules in BSW (such as ECU abstraction layer, system service, and I / O driver, etc.) can interact with each SWC of the application layer through RTE; after each SWC obtains the relevant information in BSW, it can abstract events and interact with the state management module SWC through VFB to realize state management.

[0052] In a possible implementation, the events generated in BSW can be abstracted into events that do not distinguish between subdivision modules in BSW, so that BSW differences can be shielded, making state management easy to implement. For example, assuming a first event generated by a subdivision module service layer in BSW and a second event generated in a subdivision module ECU abstract layer in BSW, if the change in system state triggered by the first event is the same as the change in system state triggered by the second event, the first event and the second event can be abstracted into one event, which is only related to BSW and does not distinguish between the subdivision module service layer and the ECU abstract layer.

[0053] In one possible implementation, a concept similar to the BSW subdivision module event abstraction can be used to abstract the events generated by multiple sensors of the original equipment manufacturer (OEM) to achieve status management of multiple OEMs and multiple sensors. The embodiments of this application do not limit the specific application.

[0054] In a possible implementation, the receiving interface of the state management SWC may be designed to be indistinguishable from SWC differences, thereby streamlining the system interface design and saving the number of interfaces.

[0055] For example, Figure 3 This is a schematic diagram of an interface in an automotive open system architecture according to an embodiment of the present application.

[0056] The subdivided modules in BSW (such as ECU abstraction layer, system service layer and I / O driver layer) interact with SWC1 to SWCn of the application layer through RTE, where n can be a natural number. After each SWC obtains the relevant information of BSW, it can abstract events and send events to the state management module SWC through VFB. The state management module can determine whether the event is legal (legal can also be understood as the state management module can recognize the event). If the event is legal, the system state corresponding to the event can be calculated. If the system state corresponding to the event is different from the current system state of the automotive open system, the state migration information can be sent to one or more SWCs that need to perform state migration post-processing through VFB. The state migration information can include the system state corresponding to the time. Each SWC can interact with the subdivided modules in BSW that need to perform state migration (such as ECU abstraction layer, system service layer and I / O driver layer) through RTE to achieve state management of BSW.

[0057] Exemplarily, the system state corresponding to the current event may include a sleep state, an alarm state, or an operating state, etc. After sending state migration information containing the system state corresponding to the event to one or more SWCs in the vehicle open system that need to perform state migration post-processing, each SWC can perform state migration based on its own logic, so that the vehicle open system can switch to the system state corresponding to the current event.

[0058] In a possible implementation, when the state management module SWC receives multiple events, the state management module SWC may manage the multiple events through an internal first-in-first-out queue (fist input fist output, FIFO) to avoid event conflicts.

[0059] In one possible implementation, Figure 4 As shown, the state management module may include: a runtime environment adaptation submodule (or called an RTE adaptation submodule), a state management context submodule and a finite state machine submodule (also called a finite state machine).

[0060] Exemplarily, the runtime environment adaptation submodule may be used to adapt the runtime environment layer so that the state management module can communicate with the RTE.

[0061] Exemplarily, the state management context submodule can be used to manage context and store events that meet the judgment rules of the state management module. Events that meet the judgment rules can be legal events that the state management module can identify, etc., which are not specifically limited in the embodiments of the present application.

[0062] Exemplarily, the finite state machine submodule can be a mathematical model that represents a finite number of states and behaviors such as transitions and actions between these states. For example, a finite state machine can have the following characteristics: events can be described by states, and at any time, events are always in one state. By triggering certain behaviors of the event, the event can be caused to transition from one state to another. There are rules for event state changes. State A can be transformed to B, B can be transformed to C, but A may not be transformed to C.

[0063] In a possible implementation, the finite state machine submodule may have two states: an idle state and a running state. When the finite state machine submodule processes an event, the state of the finite state machine submodule may be a running state. When the finite state machine submodule is idle, the state of the finite state machine submodule may be an idle state. For example, each time an event is updated, the finite state machine submodule switches the state from an idle state (for example, the idle state can be represented by idle) to a running state (for example, the running state can be represented by running) and performs state migration processing. After the processing is completed, the finite state machine submodule switches back to the idle state. In this way, the finite state machine submodule can process one event at a time to ensure the independence of the single update state.

[0064] In a possible implementation, the finite state machine submodule can be further divided into a state migration pre-processing unit, a state migration calculation unit, and a state migration post-processing unit. The state migration pre-processing unit is used to confirm that the SWC that needs state migration is in a state that can execute state migration before sending state migration information. The state migration calculation unit is used to calculate the system state corresponding to the event. The state migration post-processing unit is used to send state migration information, for example, to notify the module that needs state migration, and then each module can execute state migration separately to improve the efficiency of state migration.

[0065] For example, when the radar in the vehicle is running, it is found that the temperature of the radar is too high. Continuing to run will cause a malfunction, and an overtemperature event will be generated to remind the finite state machine sub-module that it needs to rest. This event needs to trigger the finite state machine sub-module to change the radar to the sleep state. The state transition calculation unit calculates the state that the radar needs to migrate to when entering the sleep state. However, because the radar is executing a task, the state transition pre-processing unit can monitor the radar to complete the current task. After that, the state transition post-processing unit notifies other modules of the state transition information, and each module migrates to a new state according to its own situation.

[0066] For example, Figure 5 A state management method is shown.

[0067] S1: Initialize the state management module.

[0068] Exemplarily, when the vehicle is powered on, the context global variables, flags, and registration functions of each module in the state management module may be initialized.

[0069] S2: The state management module adapts to RTE.

[0070] Exemplarily, the RTE interface may be encapsulated in the application layer so that the RTE interface can be called by a state management module or the like.

[0071] S3: The finite state machine in the state management module is initialized to the idle state.

[0072] S4: The state management module receives the update state event message transmitted from other SWCs.

[0073] Exemplarily, the state management module may receive a message from the application layer or the basic software layer through the SWC, wherein the message includes an event.

[0074] In a possible implementation, if multiple events are received, one of the multiple events may be selected for processing according to their priorities, for example, an event with the highest priority may be selected for processing, or one of the multiple events may be selected for processing according to the order in which the multiple events are received using a first-in-first-out rule. This may avoid conflicts in the processing of multiple events.

[0075] S5: The state management module determines whether the event is legal.

[0076] Exemplarily, if the state management module can identify the event, the event can be considered legal, and S6 and subsequent steps are executed. If the state management module cannot identify the event, the event can be considered illegal, and S13 and subsequent steps are executed.

[0077] S6: The state management context submodule in the state management module stores the legal event.

[0078] S7: Determine whether the finite state machine state in the state management module is an idle state.

[0079] Exemplarily, the state parameter of the finite state machine can be read, and whether the state of the finite state machine in the state management module is an idle state can be determined based on the state parameter. For example, if the state parameter is idle, it can be determined that the state of the finite state machine in the state management module is an idle state.

[0080] If the finite state machine state is the idle state, S8 and subsequent steps may be executed. If the finite state machine state is not the idle state, S13 and subsequent steps may be executed.

[0081] S8: Set the finite state machine state to the running state.

[0082] Exemplarily, the state parameter of the finite state machine may be set to a parameter for indicating a running state, for example, the state parameter of the finite state machine may be set to running.

[0083] If a new event is received subsequently, because the finite state machine is in the running state, the processing of the new event will not be executed, thus avoiding event processing conflicts.

[0084] S9: The state management module performs state migration calculations.

[0085] Exemplarily, the state management module can calculate the system state corresponding to the event. The embodiments of the present application do not limit the specific calculation process and content.

[0086] S10: The status management module determines whether the system status has changed.

[0087] In a possible implementation, the occurrence of the event will not cause a change in the system state, and even if the event occurs, there is no need to perform state migration, so S13 and subsequent steps can be executed.

[0088] In a possible implementation, the occurrence of an event may cause a change in the system state. For example, the system state obtained in the migration calculation is different from the current system state. S11 and subsequent steps may be executed.

[0089] S11: The state management module performs pre-state migration processing.

[0090] Exemplarily, the state management module may detect whether the module that needs to perform state migration has the conditions to perform state migration.

[0091] S12: The state management module sends state transition information.

[0092] Exemplarily, the state management module may use VFB to send state migration information to the modules that need to perform state migration, and each module may perform its own state migration.

[0093] In a possible implementation, the state management module may also receive system state migration feedback from one or more SWCs, so as to obtain the results of state migration executed by each module.

[0094] S13: Set the finite state machine state to an idle state.

[0095] In the embodiment of the present application, there are optional steps in the above steps S1-S13, which can be selected according to the actual application scenario.

[0096] In summary, unlike the conventional AUTOSAR architecture, in the AUTOSAR architecture of the embodiment of the present application, a state management module is set in the application layer, and SWC can receive BSW and MCAL related information, and then aggregate it to the state management module through VFB for unified processing. That is, the state management function is implemented in the application layer, and the same event generated by different modules in BSW can be abstracted as one event in SWC, thereby shielding the event distinction of subdivided modules in BSW, and easy to deploy and easy to implement.

[0097] In a possible implementation, the present application embodiment provides a state processing unit, which is used to execute Figure 5 The state management method described in the corresponding embodiments and any possible designs.

[0098] In a possible implementation, the present application provides a computer-readable storage medium, in which a computer program or instruction is stored. When the computer program or instruction is executed on a computer, the computer executes Figure 5 The state management method described in the corresponding embodiments and any possible designs.

[0099] The embodiments of the present application are described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processing unit of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processing unit of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0100] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0101] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process in the computer or other programmable device. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0102] In the several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0103] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0104] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of hardware plus software functional units.

[0105] The above-mentioned integrated unit implemented in the form of a software functional unit can be stored in a computer-readable storage medium. The above-mentioned software functional unit is stored in a storage medium, including a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) or a processor to perform some steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), disk or optical disk and other media that can store program code.

Claims

1. An automotive open system architecture, comprising an application layer, an operating environment layer and a basic software layer, characterized in that: The application layer is provided with a state management module; the application layer communicates with the basic software layer through the operating environment layer; The state management module is used for: receiving an event from the application layer or the basic software layer; the event from the basic software layer is: an event that is abstracted without distinguishing the subdivided modules in the basic software layer; When the event satisfies the judgment rule of the state management module, calculating the system state corresponding to the event; When the system state corresponding to the event is different from the current system state of the automobile open system, state migration information including the system state corresponding to the event is sent to one or more software components SWC in the automobile open system that need to perform state migration, and the state migration information is used to instruct the one or more SWCs to migrate the state to the system state corresponding to the event.

2. The automotive open system architecture according to claim 1, characterized in that: The application layer communicates with the basic software layer via the virtual function bus VFB of the operating environment layer, and the state management module is specifically used for: The state migration information is distributed to one or more SWCs that need to perform state migration through the VFB.

3. The automotive open system architecture according to claim 2, characterized in that: The state management module is also used for: State transition feedback information is received from the one or more SWCs, where the state transition feedback information is used to feed back state transition conditions of the one or more SWCs.

4. The automotive open system architecture according to any one of claims 1 to 3, characterized in that: The state management module includes a finite state machine submodule; the state management module is specifically used for: When the state of the finite state machine submodule is an idle state, modifying the state of the finite state machine submodule to a running state; Utilizing the finite state machine submodule to calculate the system state corresponding to the event; When the system state corresponding to the event is different from the current system state of the automobile open system, using the finite state machine submodule to send the state transition information to the one or more SWCs; The state of the finite state machine submodule is set to an idle state.

5. The automotive open system architecture according to claim 4, characterized in that: The finite state machine submodule includes: a state migration pre-processing unit, a state migration calculation unit and a state migration post-processing unit; The state transition pre-processing unit is used to confirm that one or more SWCs that need state transition are in a state capable of executing state transition before sending the state transition information; The state transition calculation unit is used to calculate the system state corresponding to the event; The state transition post-processing unit is used to send the state transition information to the one or more SWCs.

6. The automotive open system architecture according to any one of claims 1 to 3 and 5, characterized in that: The state management module includes an operating environment adaptation submodule and a state management context submodule; The operating environment adaptation submodule is used to adapt the operating environment layer; The state management context submodule is used for storing the event when the state management module determines that the event is a legal event.

7. The automotive open system architecture according to any one of claims 1 to 3 and 5, characterized in that: The state management module is also specifically used for: When there are plural events from the application layer or the basic software layer, one of the plural events is selected for processing.

8. The automotive open system architecture according to claim 7, characterized in that: The state management module is also specifically used for: In the case where there are multiple events from the application layer or the basic software layer, one of the multiple events is selected for processing according to the priorities of the multiple events; or, According to the order in which the multiple events are received, one of the multiple events is selected for processing using a first-in-first-out rule.

9. The automotive open system architecture according to any one of claims 1-3, 5, and 8, characterized in that: The SWC receiving interface of the state management module does not distinguish SWC differences.

10. A state management method, applied to a state management module, characterized in that: The state management module is arranged in an application layer in an open system architecture of an automobile, and the open system architecture of an automobile further comprises an operating environment layer and a basic software layer. The method comprises: receiving an event from the application layer or the basic software layer; the event from the basic software layer is: an event that is abstracted without distinguishing the subdivided modules in the basic software layer; When the event satisfies the judgment rule, calculating the system state corresponding to the event; When the system state corresponding to the event is different from the current system state of the automobile open system, state migration information including the system state corresponding to the event is sent to one or more software components SWC in the automobile open system that need to perform state migration, and the state migration information is used to instruct the one or more SWCs to migrate the state to the system state corresponding to the event.

11. The method according to claim 10, characterized in that The sending of the state migration information including the system state corresponding to the event to one or more software components SWCs that need to migrate the state in the automobile open system includes: The state migration information is distributed to the one or more software components SWC via a virtual function bus VFB.

12. The method according to claim 11, characterized in that Also includes: State transition feedback information is received from the one or more SWCs, where the state transition feedback information is used to feed back state transition conditions of the one or more SWCs.

13. The method according to any one of claims 10 to 12, characterized in that: The calculating the system state corresponding to the event includes: When the state of the finite state machine submodule is an idle state, modifying the state of the finite state machine submodule to a running state; Utilizing the finite state machine submodule to calculate the system state corresponding to the event; When the system state corresponding to the event is different from the current system state of the automobile open system, sending state migration information including the system state corresponding to the event to one or more SWCs in the automobile open system that need to migrate their state includes: When the system state corresponding to the event is different from the current system state of the automobile open system, using the finite state machine submodule to send state migration information including the system state corresponding to the event to one or more SWCs in the automobile open system that need to perform state migration; The state of the finite state machine submodule is set to an idle state.

14. The method according to claim 13, characterized in that Also includes: It is confirmed that the one or more SWCs requiring state migration are in a state capable of executing the state migration.

15. The method according to any one of claims 10-12 and 14, characterized in that: When the event satisfies the judgment rule, calculating the system state corresponding to the event includes: In the case that the event is a legal event, a system state corresponding to the event is calculated.

16. The method according to any one of claims 10-12 and 14, characterized in that: Also includes: When there are plural events from the application layer or the basic software layer, one of the plural events is selected for processing.

17. The method according to claim 16, characterized in that When there are multiple events from the application layer or the basic software layer, selecting one of the multiple events for processing includes: In the case where there are multiple events from the application layer or the basic software layer, one of the multiple events is selected for processing according to the priorities of the multiple events; or, According to the order in which the multiple events are received, one of the multiple events is selected for processing using a first-in-first-out rule.

18. A state processing unit, characterized in that: The state processing unit is used to execute the state management method as described in any one of claims 10-17.

19. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores instructions, and when the instructions are executed, the state management method described in any one of claims 10 to 17 is implemented.

Images