WO2021196863A1 - 汽车开放系统架构、状态管理方法和装置 - Google Patents

汽车开放系统架构、状态管理方法和装置 Download PDF

Info

Publication number
WO2021196863A1
WO2021196863A1 PCT/CN2021/074632 CN2021074632W WO2021196863A1 WO 2021196863 A1 WO2021196863 A1 WO 2021196863A1 CN 2021074632 W CN2021074632 W CN 2021074632W WO 2021196863 A1 WO2021196863 A1 WO 2021196863A1
Authority
WO
WIPO (PCT)
Prior art keywords
state
event
layer
state transition
module
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/CN2021/074632
Other languages
English (en)
French (fr)
Inventor
崔祥友
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to EP21779494.0A priority Critical patent/EP4120082A4/en
Publication of WO2021196863A1 publication Critical patent/WO2021196863A1/zh
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/545—Interprogram communication where tasks reside in different layers, e.g. user- and kernel-space
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W50/00—Details of control systems for road vehicle drive control not related to the control of a particular sub-unit, e.g. process diagnostic or vehicle driver interfaces
    • B60W50/0098—Details of control systems ensuring comfort, safety or stability not otherwise provided for
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/542—Event management; Broadcasting; Multicasting; Notifications
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W50/00—Details of control systems for road vehicle drive control not related to the control of a particular sub-unit, e.g. process diagnostic or vehicle driver interfaces
    • B60W2050/0001—Details of the control system
    • B60W2050/0002—Automatic control, details of type of controller or control system architecture
    • B60W2050/0004—In digital systems, e.g. discrete-time systems involving sampling
    • B60W2050/0006—Digital architecture hierarchy
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/54—Indexing scheme relating to G06F9/54
    • G06F2209/541—Client-server
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/54—Indexing scheme relating to G06F9/54
    • G06F2209/544—Remote

Definitions

  • This application relates to communication technology, and in particular to an automobile open system architecture, state management method and device.
  • Automotive open system architecture (AUTOSAR) establishes an open standard for the basic software architecture of automobiles, which are mostly 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.
  • the state management function is implemented in the basic software layer.
  • state management if the event comes from the application, multiple interactions between the application layer and the basic software layer are required, which is more complicated to implement; if the event comes from the basic software layer, There are many subdivision modules in the basic software layer, and the events generated by each subdivision module need to be processed differently, which makes it difficult to implement state management deployment.
  • the embodiments of the present application provide an automobile open system architecture, a state management method and device, so as to reduce the difficulty of implementing state management in the AUTOSAR architecture.
  • an embodiment of the present application provides an open system architecture for an automobile, including: an application layer, an operating environment layer, and a basic software layer; the application layer is provided with a state management module; the application layer and the The basic software layers communicate through the operating environment layer; the state management module is used to: receive an event from the application layer or the basic software layer; when the event meets the judgment rule of the state management module In the case of calculating the system state corresponding to the event; in the case that the system state corresponding to the event is different from the current system state of the automobile open system, one or more of the state transitions to the automobile open system are required
  • a software component (SWC) issues state transition information including the system state corresponding to the event, and the state transition information is used to indicate the transition state of the one or more SWCs to the system state corresponding to the event.
  • the state transition information is used to indicate the transition state of the one or more SWCs to the system state corresponding to the event.
  • a state management module is set at the application layer in the AUTOSAR architecture.
  • the SWC can receive basic software (basic software, BSW) and microcontroller abstraction layer (microcontroller abstraction layer, MCAL) and other related information, and then summarize it to the state
  • BSW basic software
  • MCAL microcontroller abstraction layer
  • the management module performs unified processing. That is, the status management function is implemented at the application layer.
  • the same event generated by different modules in the BSW can be abstracted as an event in the SWC, which can shield the event difference of different modules in the BSW, and the deployment is easy and easy to implement.
  • the application layer and the basic software layer communicate through a virtual functional bus (VFB) of the operating environment layer, and the state management module is specifically configured to:
  • the VFB distributes the state transition information to one or more software components SWC that need to perform state transition.
  • VFB can isolate the upper application layer and the lower basic software layer, and support the independence of software and hardware modules.
  • the state management module is further configured to: receive state transition feedback information from the one or more SWCs, and the state transition feedback information is used to feed back the state transition of the one or more SWCs Condition. In this way, the state management module can understand the state transition of SWC, which is more conducive to state management.
  • the state management module includes a finite state machine sub-module; the state management module is specifically configured to: when the state of the finite state machine sub-module is an idle state, modify the finite state machine sub-module
  • the state of the module is the running state; the finite state machine sub-module is used 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, the finite state machine is used
  • the module delivers the state transition information to the one or more SWCs; and sets the state of the finite state machine submodule to an idle state. This allows the finite state machine sub-module to process one event at a time, ensuring the independence of a single update state.
  • the finite state machine sub-module includes: a state transition pre-processing unit, a state transition calculation unit, and a state transition post-processing unit; the state transition pre-processing unit is used to before issuing the state transition information , Confirming that one or more SWCs that require state transition are in a state capable of performing state transition; the state transition calculation unit is used to calculate the system state corresponding to the event; the state transition processing unit is used to send the one or Multiple SWCs deliver the state transition information. This can improve the efficiency of state transition.
  • the state management module includes an operating environment adapting submodule and a state management context submodule; the operating environment adapting submodule is used to adapt the operating environment layer; the state management context The sub-module is configured to store the event when the state management module determines that the event is a legal event.
  • the state management module is specifically used to select one of the multiple events when the number of events from the application layer or the basic software layer is multiple. To process. This can avoid event handling conflicts.
  • the state management module is specifically further configured to: in the case that the number of events from the application layer or the basic software layer is more than Select one of the multiple events for processing; 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.
  • the SWC receiving interface of the state management module does not distinguish between SWC differences. This can simplify the system interface design and save the number of interfaces.
  • the events from the basic software layer are abstracted as events that do not distinguish the subdivision modules in the basic software layer. This can shield BSW differences, making state management easy to implement.
  • an embodiment of the present application provides a state management method, including: receiving an event from the application layer or the basic software layer; in the case that the event satisfies the judgment rule, calculating the state corresponding to the event System state; in the case that the system state corresponding to the event is different from the current system state of the open automobile system, the SWC is issued to one or more software components that need to perform state transition in the open automobile system including the corresponding event.
  • the state transition information of the system state of the system state, the state transition information is used to indicate the transition state of the one or more SWCs to the system state corresponding to the event.
  • the sending of state transition information including the system state corresponding to the event to the one or more software components SWC that need to perform state transition in the automobile open system includes: via a virtual function bus The VFB distributes the state transition information to the one or more software components SWC.
  • the method further includes: receiving state transition feedback information from the one or more SWCs, where the state transition feedback information is used to feed back the state transition status of the one or more SWCs.
  • the calculating the system state corresponding to the event includes: when the state of the finite state machine submodule is idle, modifying the state of the finite state machine submodule to the running state;
  • the finite state machine sub-module calculates the system state corresponding to the event; in the case that the system state corresponding to the event is different from the current system state of the automobile open system, to one of the automobile open systems that needs to undergo state transition Or multiple software components
  • SWC issuing state transition information including the system state corresponding to the event, including: using the finite state machine when the system state corresponding to the event is different from the current system state of the automobile open system
  • the module issues state transition information including the system state corresponding to the event to one or more SWCs in the open automobile system that need to perform state transition; and sets the state of the finite state machine submodule to an idle state.
  • it further includes: confirming that the one or more SWCs that require state transition are in a state that can perform state transition.
  • calculating the system state corresponding to the event includes: in the case that the event is a legal event, calculating the system corresponding to the event state.
  • it further includes: in a case where there are multiple events from the application layer or the basic software layer, selecting one of the multiple events for processing.
  • selecting one of the multiple events for processing includes: In the case that the number of events in the application layer or the basic software layer is multiple, one of the multiple events is selected for processing according to the priority of the multiple events; or, according to the receipt of the multiple events
  • the sequence of events adopts a first-in first-out rule to select one of the multiple events for processing.
  • an embodiment of the present application provides a state processing unit, which is configured to execute the state management method described in any one of the possible designs from the second aspect to the second aspect.
  • the embodiments of the present application provide a computer-readable storage medium.
  • the computer-readable storage medium stores a computer program or instruction.
  • the computer program or instruction When the computer program or instruction is run on a computer, the computer executes the operations as described in the second aspect to the first aspect.
  • the 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 unification deal with. That is, the state management function is implemented in the application layer.
  • the same event generated by different modules in the BSW can be abstracted as an event in the SWC, which can shield the event difference of the subdivision modules in the BSW, and it is easy to deploy and implement.
  • Figure 1 is a schematic diagram of a usual open system architecture of a car
  • FIG. 2 is a schematic diagram of the architecture of an automobile open system provided by an embodiment of the application.
  • FIG. 3 is a schematic diagram of interfaces in the automotive open system architecture of an embodiment of the application.
  • FIG. 4 is a schematic structural diagram of a state management module according to an embodiment of the application.
  • FIG. 5 is a schematic flowchart of a state management method provided by an embodiment of the application.
  • words such as “first” and “second” are used to distinguish the same items or similar items that have substantially the same function and effect.
  • the first event and the second event are only for distinguishing different events, and the sequence of the events is not limited.
  • words such as “first” and “second” do not limit the quantity and order of execution, and words such as "first” and “second” do not limit the difference.
  • At least one refers to one or more, and “multiple” refers to two or more.
  • “And/or” describes the association relationship of the associated objects, indicating that there can be three relationships, for example, A and/or B, which can mean: A alone exists, A and B exist at the same time, and B exists alone, where A, B can be singular or plural.
  • the character “/” generally indicates that the associated objects before and after are in an “or” relationship.
  • the following at least one item (a)” or similar expressions refers to any combination of these items, including any combination of a single item (a) or a plurality of items (a).
  • at least one of a, b, or c can mean: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple .
  • the method of the embodiment of the present application can be applied to an automobile electronic control system implemented based on the AUTOSAR system architecture idea.
  • the AUTOSAR architecture adopts a hierarchical design.
  • the operating environment layer is used as the implementation of the virtual functional bus (VFB), which isolates the upper application layer from the lower basic software layer, and gets rid of the previous electronic control unit (ECU). )
  • VFB virtual functional bus
  • ECU electronice control unit
  • 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 and data interaction, applications are modeled as software components (SWC). When the system is configured, the software components are mapped to the designated ECU, and the virtual connections between the components are also mapped to various actual transmission buses. Finally, the software component uses a pre-defined port to communicate through the VFB.
  • SWC software components
  • the upper layer provides the operating environment application programming interface (application programming interface, API) required for data communication, and then uses the port or Send-receive (Sender-Receiver) communication or client-server (Client-Server) communication and other ways to interact.
  • application programming interface application programming interface
  • Fig. 1 is a schematic diagram of a general AUTOSAR system architecture.
  • the AUTOSAR architecture is divided into three software layers at the highest abstraction level: application layer (application layer, also called application layer), runtime environment layer (runtime environment, RTE) and microcontroller ( The basic software (BSW) layer running on the microcontroller).
  • application layer application layer, also called application layer
  • runtime environment layer runtime environment, RTE
  • microcontroller The basic software (BSW) layer running on the microcontroller.
  • BSW basic software
  • 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 realization of the VFB interface on a single ECU, and it can also be understood as the creation of objects in an object-oriented programming language.
  • BSW is further divided into services layer (services layer), ECU abstraction layer (ECU abstraction layer), microcontroller abstraction layer (MCAL) and complex driver (complex drivers) layer.
  • services layer service layer
  • ECU abstraction layer ECU abstraction layer
  • MCAL microcontroller abstraction layer
  • complex driver complex drivers
  • Services layer is the highest layer of basic software. Services layer is further divided into system services (system services), memory services (memory services) and communication services (communication services).
  • system services system services
  • memory services memory services
  • communication services communication services
  • ECU abstraction layer is further divided into onboard device abstraction, memory hardware abstraction, communication hardware abstraction, and I/O hardware abstraction.
  • the Microcontroller abstraction layer is at the bottom of the BSW, which contains internal drivers and so on. Microcontroller abstraction layer is further divided into microcontroller drivers, memory drivers, communication drivers, and I/O drivers.
  • Complex drivers span from hardware to RTE.
  • the main task is to integrate non-standard functional modules with special purposes, and embed this part of the functions into the AUTOSAR basic software layer, so as to realize the specific functions and time requirements for processing complex sensors and actuators.
  • the complex driver is closely related to the microcontroller and ECU hardware.
  • the upper-level program interface is specified and implemented according to AUTOSAR; the lower-level program interface is restricted by the standard interface program.
  • Complex drives can realize the evaluation of complex sensors and the control of actuators, such as fuel injection control, solenoid valve control, incremental position detection, etc.
  • BSW can be specifically used to provide the following services.
  • System Provides standardized regulations (for example, operating systems, timers, and error memory), ECU-specific services (for example, ECU status management, watchdog management) and library functions.
  • Memory Standardize access to internal and external memory (non-volatile memory).
  • Communication Standardize access to automotive network systems, ECU communication systems, and ECU internal software.
  • Input/Output Standardize access to sensors, actuators, and ECU peripherals.
  • an ECU state manager module in the system services layer of the BSW, which can perform ECU state management based on the ECU state manager. For example, after receiving the event message, configure the ECU state manager to interact with other underlying modules of the ECU to achieve state processing.
  • the state management function is implemented in the BSW.
  • state management if the event comes from the application, multiple interactions between the application layer and the bottom layer are required, which is more complicated to implement; if the event comes from the BSW layer, as above More subdivided modules are set in the BSW layer, and the events generated by each module need to be processed differently, making it difficult to support a large number of differentiated events in the BSW layer.
  • the application layer in the AUTOSAR architecture sets a state management module, and the 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 status management function is implemented in the application layer.
  • the same event generated by different modules in the BSW can be abstracted as an event in the SWC, which can shield the event difference of different modules in the BSW, and is easy to deploy and implement.
  • FIG. 2 is a schematic diagram of an automotive open system architecture according to an embodiment of the application.
  • the 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.
  • the subdivision modules in the BSW can interact with each SWC of the application layer through RTE; after each SWC obtains the relevant information in the BSW, it can be abstracted Event, and interact with state management module SWC through VFB to realize state management.
  • the events generated in the BSW can be abstracted into events that do not distinguish the subdivision modules in the BSW, so that the differences in the BSW can be shielded, and the state management can be easily implemented. For example, suppose that the first event generated by the service layer of the subdivision module in BSW and the second event generated by the ECU abstraction layer of the subdivision module in BSW. If the change of the system status is the same, the first event and the second event can be abstracted into one event, which is only related to the BSW, and does not distinguish between the subdivision module service layer and the ECU abstraction layer.
  • a concept similar to the event abstraction of the BSW subdivision module can also be used to abstract the original equipment manufacturing (OEM) collection of events generated by multiple sensors to achieve multiple OEMs and multiple sensor states. Management, the embodiments of this application do not limit specific applications.
  • OEM original equipment manufacturing
  • the receiving interface of the state management SWC can be designed to not distinguish between SWC differences, thereby simplifying the system interface design and saving the number of interfaces.
  • FIG. 3 is a schematic diagram of interfaces in an automotive open system architecture according to an embodiment of the application.
  • the subdivision modules in the BSW (such as the ECU abstraction layer, the system service layer and the I/O drive layer) interact with SWC1 to SWCn of the application layer through RTE.
  • n can be a natural number.
  • each SWC obtains the relevant information of the BSW, it can Abstract the event and send the event to the state management module SWC through the VFB.
  • the state management module can determine whether the event is legal (legitimate can also be understood as the state management module can identify 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 car open system, the state transition information can be sent to one or more SWCs that need post-state transition processing through the VFB, and the state transition information can include the time corresponding Each SWC can interact with the subdivision modules (such as ECU abstraction layer, system service layer and I/O driver layer) that need to perform state transition in the BSW through RTE to realize the state management of the BSW.
  • the subdivision modules such as ECU abstraction layer, system service layer and I/O driver layer
  • the system state corresponding to the current event may include the dormant state, the alarm state, or the running state, etc.
  • the state of the system state corresponding to the event is issued to one or more SWCs in the vehicle open system that need to be processed after the state transition. After the information is migrated, each SWC can perform state transition based on its own logic, so that the vehicle open system can switch to the system state corresponding to the current event.
  • the state management module SWC when the state management module SWC receives multiple events, the state management module SWC can manage the multiple events through an internal first-in first-out queue (FIFO) to avoid event conflicts.
  • FIFO first-in first-out queue
  • the state management module may include: an operating environment adaptation sub-module (or called RTE adaptation sub-module), a state management context sub-module, and a finite state machine sub-module (or Called a finite state machine).
  • an operating environment adaptation sub-module or called RTE adaptation sub-module
  • a state management context sub-module or Called a finite state machine.
  • the operating environment adaptation sub-module may be used to adapt the operating environment layer, so that the state management module can communicate with the RTE.
  • the state management context sub-module may be used to manage the context and store events that meet the judgment rules of the state management module.
  • the event that meets the judgment rule may be a legal event that can be identified by the state management module, etc., which is not specifically limited in the embodiment of the present application.
  • the finite state machine sub-module may be a mathematical model that represents a finite number of states and behaviors such as transitions and actions between these states.
  • a finite state machine can have the following characteristics: it can use states to describe events, and at any time, the event is always in a state. By triggering certain behaviors of the event, it can cause the event to transition from one state to another. .
  • the finite state machine submodule may have two states: an idle state and an operating state.
  • the state of the finite state machine submodule may be an operating state.
  • the finite state machine submodule can be an idle state.
  • the finite state machine sub-module switches the state from the idle state (for example, the idle state can be represented by idle) to the running state (for example, the running state can be represented by running) and performs state migration processing. The processing is limited after completion.
  • the state machine submodule switches back to the idle state. This allows the finite state machine sub-module to process one event at a time, ensuring the independence of a single update state.
  • the finite state machine sub-module can be further divided into a pre-state transition processing unit, a state transition calculation unit, and a post-state transition processing unit.
  • the pre-state transition processing unit is used to confirm that the SWC that needs state transition is in a state capable of executing state transition before issuing the state transition information.
  • the state transition calculation unit is used to calculate the system state corresponding to the event.
  • the post-state transition processing unit is used to issue state transition information, for example, it can notify the modules that need to perform state transition, and then each module can perform state transition separately to improve the efficiency of state transition.
  • the state transition calculation unit calculates the state that the radar needs to transition to enter the sleep state, but because the radar is performing tasks, the processing unit can monitor the radar to execute the current task before the state transition, and then the processing unit will notify other modules of the state after the state transition Migration information, each module migrates to a new state according to its own situation.
  • FIG. 5 shows a state management method
  • the context global variables, flag bits, and registration functions of each module in the state management module can be initialized.
  • S2 The state management module adapts to RTE.
  • the RTE interface can be encapsulated in the application layer, so that the RTE interface can be called by the state management module and the like.
  • S3 The finite state machine in the state management module is initialized to an idle state.
  • the state management module receives the update state event message from other SWCs.
  • the state management module may receive messages from the application layer or the basic software layer through the SWC, and the messages include events.
  • one of the multiple events can be selected for processing according to the priority of the multiple events. For example, the event with the highest priority can be selected for processing, or according to the received To the sequence of multiple events, use the first-in-first-out rule to select one of the multiple events for processing. This can avoid the conflicts of multiple event handling.
  • S5 The state management module judges whether the event is legal.
  • the state management module can identify the event, the event can be considered legal and execute S6 and subsequent steps. If the state management module cannot identify the event, the event can be considered illegal and execute S13 and subsequent steps.
  • S6 The state management context sub-module in the state management module stores the legal event.
  • S7 Determine whether the state of the finite state machine in the state management module is an idle state.
  • the state parameters 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 is determined according to the state parameters. 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 the idle state.
  • the state parameter of the finite state machine may be set as a parameter used to indicate the operating state, for example, the state parameter of the finite state machine may be set to running.
  • S9 The state management module performs state transition calculations.
  • the state management module may calculate the system state corresponding to the event, and the embodiment of the present application does not limit the specific calculation process and content.
  • S10 The state management module judges whether the system state has changed.
  • the occurrence of the event will not lead to a change in the system state, even if the event occurs, no state transition is required, and S13 and subsequent steps can be executed.
  • the occurrence of events will cause the system state to change.
  • the system state obtained in the migration calculation is different from the current system state, and S11 and subsequent steps can be executed.
  • S11 The state management module executes pre-processing for state transition.
  • the state management module can detect whether the module that needs to perform the state transition has the conditions to perform the state transition.
  • S12 The state management module issues state transition information.
  • the state management module can use the VFB to deliver state transition information to the modules that need to perform state transition, and each module can perform its own state transition.
  • the state management module may also receive system state transition feedback from one or more SWCs, so that the results of the state transition can be executed by each module.
  • the 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 unification deal with. That is, the state management function is implemented in the application layer.
  • the same event generated by different modules in the BSW can be abstracted as an event in the SWC, which can shield the event difference of the subdivision modules in the BSW, and is easy to deploy and implement.
  • an embodiment of the present application provides a state processing unit, and the state processing unit is configured to execute the state management method described in the embodiment corresponding to FIG. 5 and any possible design.
  • an embodiment of the present application provides a computer-readable storage medium.
  • the computer-readable storage medium stores a computer program or instruction.
  • the computer program or instruction runs on the computer, the computer executes FIG. 5
  • FIG. 5 The state management method described in the corresponding embodiment and any possible design.
  • These computer program instructions can be provided to the processing unit of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing equipment to generate a machine, so that the instructions executed by the processing unit of the computer or other programmable data processing equipment are generated It is a device that realizes the functions specified in one process or multiple processes in the flowchart and/or one block or multiple blocks in the block diagram.
  • These computer program instructions can also be stored in a computer-readable memory that can guide a computer or other programmable data processing equipment to work in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture including the instruction device.
  • the device implements the functions specified in one process or multiple processes in the flowchart and/or one block or multiple blocks in the block diagram.
  • These computer program instructions can also be loaded on a computer or other programmable data processing equipment, so that a series of operation steps are executed on the computer or other programmable equipment to produce computer-implemented processing, so as to execute on the computer or other programmable equipment.
  • the instructions provide steps for implementing the functions specified in one process or multiple processes in the flowchart and/or one block or multiple blocks in the block diagram.
  • the disclosed device and method may be implemented in other ways.
  • the device embodiments described above are only illustrative.
  • the division of the units is only a logical function division, and there may be other divisions in actual implementation, for example, multiple units or components may be combined or It can be integrated into another system, or some features can be ignored or not implemented.
  • the displayed or discussed mutual coupling or direct coupling or communication connection may be indirect coupling or communication connection through some interfaces, devices or units, and may be in electrical, mechanical or other forms.
  • the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the objectives of the solutions of the embodiments.
  • the functional units in the various embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units may be integrated into one unit.
  • the above-mentioned integrated unit can be realized in the form of hardware, or in the form of hardware plus software functional unit.
  • the above-mentioned integrated unit implemented in the form of a software functional unit may be stored in a computer readable storage medium.
  • the above-mentioned software functional unit is stored in a storage medium, and includes several instructions to make a computer device (which can be a personal computer, a server, or a network device, etc.) or a processor to execute the method described in each embodiment of the present application. Part of the steps.
  • the aforementioned storage media include: U disk, mobile hard disk, read-only memory (read-only memory, ROM), random access memory (random access memory, RAM), magnetic disks or optical disks and other media that can store program codes. .

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Automation & Control Theory (AREA)
  • Human Computer Interaction (AREA)
  • Transportation (AREA)
  • Mechanical Engineering (AREA)
  • Multimedia (AREA)
  • Stored Programmes (AREA)

Abstract

本申请实施例提供一种汽车开放系统架构、状态管理方法和装置，在应用程序层设置状态管理模块，SWC可以接收BSW及MCAL相关信息，进而通过VFB汇总到状态管理模块进行统一处理。即状态管理功能在应用程序层实现，BSW中不同模块产生的相同事件可以在SWC中可以抽象为一个事件，从而可以屏蔽BSW中细分模块的事件区别，应用在智能汽车、新能源汽车上，本申请实施例提供的架构部署容易且容易实现。

Description

汽车开放系统架构、状态管理方法和装置
本申请要求于2020年03月31日提交中国专利局、申请号为202010247380.4、申请名称为“汽车开放系统架构、状态管理方法和装置”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及通信技术，尤其涉及一种汽车开放系统架构、状态管理方法和装置。
背景技术
汽车开放系统架构(automotive open system architecture，AUTOSAR)建立了汽车基础软件架构的开放式标准，较多的应用于汽车电子控制系统中。在AUTOSAR架构中，如果有事件发生后导致系统状态改变，需要进行状态管理。
通常的，状态管理功能在基础软件层实现，在进行状态管理时，如果事件来自于应用程序，需要应用程序层与基础软件层的多次交互，实现较为复杂；如果事件来自于基础软件层，基础软件层中有较多的细分模块，各细分模块产生的事件需要差异化处理，使得实现状态管理的部署较难。
发明内容
本申请实施例提供一种汽车开放系统架构、状态管理方法和装置，以降低AUTOSAR架构中状态管理的实现难度。
第一方面，本申请实施例提供一种汽车开放系统架构，包括：应用程序层、运行环境层和基础软件层；所述应用程序层中设置有状态管理模块；所述应用程序层与所述基础软件层之间通过所述运行环境层通信；所述状态管理模块用于：接收来自所述应用程序层或所述基础软件层的事件；在所述事件满足所述状态管理模块的判断规则的情况下，计算所述事件对应的系统状态；在所述事件对应的系统状态与汽车开放系统当前的系统状态不同的情况下，向所述汽车开放系统中需要进行状态迁移的一个或多个软件组件(software component，SWC)下发包括所述事件对应的系统状态的状态迁移信息，所述状态迁移信息用于指示所述一个或多个SWC迁移状态到所述事件对应的系统状态，所述状态迁移信息用于指示所述一个或多个SWC迁移状态到所述事件对应的系统状态。本申请实施例在AUTOSAR架构中的应用程序层设置状态管理模块，SWC可以接收基本软件(basic software，BSW)及微控制器抽象层(microcontroller abstraction layer，MCAL)等的相关信息，进而汇总到状态管理模块进行统一处理。即状态管理功能在应用程序层实现，BSW中不同模块产生的相同事件可以在SWC中可以抽象为一个事件，从而可以屏蔽BSW不同模块的事件区别，部署容易且容易实现。
在一种可能的设计中，所述应用程序层与所述基础软件层之间通过所述运行环境层的虚拟功能总线(virtual functional bus，VFB)通信，所述状态管理模块具体用于： 通过所述VFB向需要进行状态迁移的一个或多个软件组件SWC分发所述状态迁移信息。利用VFB可以隔离上层的应用程序层与下层的基础软件层，支持软件和硬件模块的独立性。
在一种可能的设计中，所述状态管理模块还用于：从所述一个或多个SWC接收状态迁移反馈信息，所述状态迁移反馈信息用于反馈所述一个或多个SWC的状态迁移情况。这样状态管理模块可以了解SWC的状态迁移情况，更利于状态管理。
在一种可能的设计中，所述状态管理模块包括有限状态机子模块；所述状态管理模块具体用于：在所述有限状态机子模块的状态为空闲状态的情况下，修改所述有限状态机子模块的状态为运行状态；利用所述有限状态机子模块计算所述事件对应的系统状态；在所述事件对应的系统状态与汽车开放系统当前的系统状态不同的情况下，利用所述有限状态机子模块向所述一个或多个SWC下发所述状态迁移信息；将所述有限状态机子模块的状态设置为空闲状态。这样可以使得有限状态机子模块每次处理一个事件，保证单次更新状态的独立性。
在一种可能的设计中，所述有限状态机子模块包括：状态迁移前处理单元、状态迁移计算单元和状态迁移后处理单元；所述状态迁移前处理单元用于在下发所述状态迁移信息之前，确认需要状态迁移的一个或多个SWC处于能执行状态迁移的状态；所述状态迁移计算单元用于计算所述事件对应的系统状态；所述状态迁移后处理单元用于向所述一个或多个SWC下发所述状态迁移信息。这样可以提升状态迁移的效率。
在一种可能的设计中，所述状态管理模块包括运行环境适配子模块和状态管理上下文子模块；所述运行环境适配子模块用于适配所述运行环境层；所述状态管理上下文子模块用于在所述状态管理模块判断所述事件为合法事件的情况下，存储所述事件。
在一种可能的设计中，所述状态管理模块具体还用于：在来自所述应用程序层或所述基础软件层的事件的数量为多个的情况下，在多个事件中选择其中一个进行处理。从而可以避免事件处理冲突。
在一种可能的设计中，所述状态管理模块具体还用于：在来自所述应用程序层或所述基础软件层的事件的数量为多个的情况下，根据多个事件的优先级在所述多个事件中选择其中一个进行处理；或，根据接收到所述多个事件的顺序，采用先进先出的规则在所述多个事件中选择其中一个进行处理。
在一种可能的设计中，所述状态管理模块的SWC接收接口不区分SWC差异。从而可以精简系统接口设计，节省接口数量。
在一种可能的设计中，来自所述基础软件层的事件为：抽象为不区分所述基础软件层中的细分模块的事件。从而可以屏蔽BSW差异，使得状态管理易于实现。
第二方面，本申请实施例提供一种状态管理方法，包括：接收来自所述应用程序层或所述基础软件层的事件；在所述事件满足判断规则的情况下，计算所述事件对应的系统状态；在所述事件对应的系统状态与汽车开放系统当前的系统状态不同的情况下，向所述汽车开放系统中需要进行状态迁移的一个或多个软件组件SWC下发包括所述事件对应的系统状态的状态迁移信息，所述状态迁移信息用于指示所述一个或多个SWC迁移状态到所述事件对应的系统状态。
在一种可能的设计中，所述向所述汽车开放系统中需要进行状态迁移的一个或多 个软件组件SWC下发包括所述事件对应的系统状态的状态迁移信息，包括：通过虚拟功能总线VFB向所述一个或多个软件组件SWC分发所述状态迁移信息。
在一种可能的设计中，还包括：从所述一个或多个SWC接收状态迁移反馈信息，所述状态迁移反馈信息用于反馈所述一个或多个SWC的状态迁移情况。
在一种可能的设计中，所述计算所述事件对应的系统状态，包括：在有限状态机子模块的状态为空闲状态的情况下，修改所述有限状态机子模块的状态为运行状态；利用所述有限状态机子模块计算所述事件对应的系统状态；所述在所述事件对应的系统状态与汽车开放系统当前的系统状态不同的情况下，向所述汽车开放系统中需要进行状态迁移的一个或多个软件组件SWC下发包括所述事件对应的系统状态的状态迁移信息，包括：在所述事件对应的系统状态与汽车开放系统当前的系统状态不同的情况下，利用所述有限状态机子模块向所述汽车开放系统中需要进行状态迁移的一个或多个SWC下发包括所述事件对应的系统状态的状态迁移信息；将所述有限状态机子模块的状态设置为空闲状态。
在一种可能的设计中，还包括：确认所述需要状态迁移的一个或多个SWC处于能执行状态迁移的状态。
在一种可能的设计中，所述在所述事件满足判断规则的情况下，计算所述事件对应的系统状态，包括：在所述事件为合法事件的情况下，计算所述事件对应的系统状态。
在一种可能的设计中，还包括：在来自所述应用程序层或所述基础软件层的事件的数量为多个的情况下，在多个事件中选择其中一个进行处理。
在一种可能的设计中，所述在来自所述应用程序层或所述基础软件层的事件的数量为多个的情况下，在多个事件中选择其中一个进行处理，包括：在来自所述应用程序层或所述基础软件层的事件的数量为多个的情况下，根据多个事件的优先级在所述多个事件中选择其中一个进行处理；或，根据接收到所述多个事件的顺序，采用先进先出的规则在所述多个事件中选择其中一个进行处理。
第三方面，本申请实施例提供一种状态处理单元，状态处理单元用于执行第二方面至第二方面的任意一种可能的设计中描述的状态管理方法。
第四方面，本申请实施例提供一种计算机可读存储介质，计算机可读存储介质中存储有计算机程序或指令，当计算机程序或指令在计算机上运行时，使得计算机执行如第二方面至第二方面的任意一种可能的设计中描述的状态管理方法。
综上所述，与通常的AUTOSAR架构不同的是，本申请实施例的AUTOSAR架构中，在application layer设置状态管理模块，SWC可以接收BSW及MCAL相关信息，进而通过VFB汇总到状态管理模块进行统一处理。即状态管理功能在application layer实现，BSW中不同模块产生的相同事件可以在SWC中可以抽象为一个事件，从而可以屏蔽BSW中细分模块的事件区别，部署容易且容易实现。
附图说明
图1为通常的汽车开放系统架构示意图；
图2为本申请实施例提供的一种汽车开放系统架构示意图；
图3为本申请实施例的汽车开放系统架构中的接口示意图；
图4为本申请实施例的一种状态管理模块结构示意图；
图5为本申请实施例提供的一种状态管理方法的流程示意图。
具体实施方式
为了便于清楚描述本申请实施例的技术方案，在本申请的实施例中，采用了“第一”、“第二”等字样对功能和作用基本相同的相同项或相似项进行区分。例如，第一事件和第二事件仅仅是为了区分不同的事件，并不对其先后顺序进行限定。本领域技术人员可以理解“第一”、“第二”等字样并不对数量和执行次序进行限定，并且“第一”、“第二”等字样也并不限定一定不同。
需要说明的是，本申请中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其他实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。
本申请中，“至少一个”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B的情况，其中A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指的这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a，b，或c中的至少一项(个)，可以表示：a，b，c，a-b，a-c，b-c，或a-b-c，其中a，b，c可以是单个，也可以是多个。
本申请实施例的方法可以应用在基于AUTOSAR系统架构思想实现的汽车电子控制系统中。
AUTOSAR架构采用分层设计，运行环境层作为虚拟功能总线(virtual functional bus，VFB)的实现，隔离了上层的应用程序层与下层的基础软件层，摆脱了以往电子控制单元(electronic control unit，ECU)软件开发验证时对硬件系统的依赖，支持软件和硬件模块的独立性。
VFB是底层基础软件与网络拓扑结构的抽象，是AUTOSAR提供的所有通信机制的集合，在信息数据交互的过程中，应用程序被建模为软件组件(software component，SWC)。当系统进行配置时，软件组件就会被映射到指定ECU上，组件间的虚拟连接也被映射到了各种实际传输的总线上。最后软件组件利用预先定义好的端口，通过VFB来实现通信。
在AUTOSAR架构中，各SWC之间不直接进行通信，由运行环境封装好下层基础软件后，为上层提供数据通信所需的运行环境应用程序编程接口(application programming interface，API)，再使用端口或者发送-接收(Sender-Receiver)通信或客户端-服务端(Client-Server)通信等的方式进行交互。
示例性的，图1为通常的AUTOSAR系统架构示意图。如图1所示，AUTOSAR架构在最高抽象级别上分为三个软件层：应用程序层(application layer，也可以称为应用层)、运行环境层(runtime environment，RTE)和在微控制器(microcontroller) 上运行的基本软件(basic software，BSW)层。
RTE是为应用软件(例如AUTOSAR软件组件和/或AUTOSAR传感器/执行器组件)提供通信服务的层。AUTOSAR软件组件可以通过RTE与其他组件(例如内部和/或内部ECU)或服务进行通信。RTE也可以理解为单个ECU上对VFB接口的实现，也可以理解为是面向对象的编程语言中对象的创建。
BSW进一步划分为服务层(services layer)、ECU抽象层(ECU abstraction layer)、微控制器抽象层(microcontroller abstraction layer，MCAL)和复杂驱动(complex drivers)层。这些细分的层可以称为BSW的细分模块，或可以称为BSW的细分层等。
Services layer是基础软件的最高层。Services layer进一步划分为系统服务(system services)、存储器服务(memory services)和通信服务(communication services)。
ECU abstraction layer进一步划分为板载设备抽象(onboard device abstraction)、存储器硬件抽象(memory hardware abstraction)、通信硬件抽象(communication hardware abstraction)和I/O硬件抽象(I/O hardware abstraction)。
Microcontroller abstraction layer在BSW的最底层，它包含内部驱动等。Microcontroller abstraction layer进一步划分为微控制器驱动(microcontroller drivers)、存储器驱动(memory drivers)、通信驱动(communication drivers)、以及I/O驱动(I/O drivers)。
Complex drivers从硬件跨越到RTE，主要任务是整合具有特殊目的的非标准功能模块，将该部分功能嵌入到AUTOSAR基础软件层中，从而实现处理复杂传感器以及执行器的特定功能和时间要求。复杂驱动程序跟单片机和ECU硬件紧密相关。其上层程序接口是根据AUTOSAR指定并且实施的；其下层程序接口受标准接口程序的限制。复杂驱动可以实现对复杂传感器的评估和执行器的控制，比如喷油控制，电磁阀控制，增量位置检测等。
BSW具体可以用于提供下述服务。系统：提供标准化的规定(例如针对操作系统、定时器以及错误存储器)、ECU特定的服务(例如ECU状态管理、看门狗管理)和库函数等。内存：对内部和外部的内存(非易失性存储器)的访问入口进行标准化。通信：对汽车网络系统、ECU通信系统以及ECU内部软件的访问入口进行标准化。输入/输出：对传感器、执行器以及ECU外设的访问入口进行标准化。
其中，在上述AUTOSAR架构中，BSW中的system services层中有ECU state manager模块，可以基于ECU state manage进行ECU状态管理。例如，在接收到事件消息后，通过配置ECU state manager等对ECU其他底层模块进行交互，实现状态处理。
即通常的AUTOSAR架构中，状态管理功能在BSW实现，在进行状态管理时，如果事件来自于应用程序，需要应用程序层与底层的多次交互，实现较为复杂；如果事件来自于BSW层，如上所述BSW层中设置了较多细分的模块，各模块产生的事件需要差异化处理，使得BSW层中难以支持数量较大的差异化事件。
基于此，本申请实施例在AUTOSAR架构中的application layer设置状态管理模块，SWC可以接收BSW及MCAL相关信息，进而通过VFB汇总到状态管理模块进行统一处理。即状态管理功能在application layer实现，BSW中不同模块产生的相同事件 可以在SWC中可以抽象为一个事件，从而可以屏蔽BSW不同模块的事件区别，部署容易且容易实现。
示例性的，图2为本申请实施例的一种汽车开放系统架构示意图。
如图2所示，本申请实施例中，在application layer设置状态管理模块，SWC可以接收BSW及MCAL相关信息，进而通过VFB汇总到状态管理模块进行统一处理。
示例性的，BSW中的细分模块(例如ECU abstraction layer、system service以及I/O driver等)，可以通过RTE与application layer的各SWC进行交互；各SWC获取BSW中的相关信息后，可以抽象事件，并通过VFB与状态管理模块SWC进行交互，实现状态管理。
一种可能的实现方式中，BSW中产生的事件可以抽象为不区分BSW中的细分模块的事件，从而可以屏蔽BSW差异，使得状态管理易于实现。例如，假设BSW中的细分模块服务层产生的第一事件，BSW中的细分模块ECU抽象层中产生的第二事件，如果第一事件所触发的系统状态的改变与第二事件所触发的系统状态的改变相同，则可以将第一事件和第二事件抽象为一个事件，该一个事件只与BSW相关，不区分细分模块服务层和ECU抽象层。
一种可能的实现方式中，也可以采用与BSW细分模块事件抽象类似的构思将原始设备制造(original equipment manufacture，OEM)集多种传感器产生的事件抽象，实现对多OEM及多种传感器状态管理，本申请实施例对具体的应用不作限定。
一种可能的实现方式中，状态管理SWC的接收接口可以设计为不区分SWC差异，从而可以精简系统接口设计，节省接口数量。
示例性的，图3为本申请实施例的一种汽车开放系统架构中的接口示意图。
BSW中的细分模块(例如ECU抽象层、系统服务层和I/O驱动层)，通过RTE与应用程序层的SWC1至SWCn交互，n可以为自然数，各SWC获取BSW的相关信息后，可以抽象事件，并通过VFB向状态管理模块SWC发送事件，状态管理模块可以判断事件是否合法(合法也可以理解为状态管理模块能够识别该事件)，如果事件合法，则可以计算该事件对应的系统状态，如果该事件对应的系统状态与汽车开放系统当前的系统状态不同，则可以通过VFB向需要进行状态迁移后处理的一个或多个SWC下发状态迁信息，状态迁移信息中可以包括该时间对应的系统状态，各SWC可以通过RTE与BSW中需要进行状态迁移的细分模块(例如ECU抽象层、系统服务层和I/O驱动层)交互，实现对BSW的状态管理。
示例性的，当前事件对应的系统状态可以包括休眠状态、报警状态或运行状态等，向车辆开放系统中需要进行状态迁移后处理的一个或多个SWC下发包含该事件对应的系统状态的状态迁移信息后，各SWC可以基于自身的逻辑进行状态迁移，使得车辆开放系统可以切换到当前事件对应的系统状态。
一种可能的实现方式中，在状态管理模块SWC接收到多条事件时，状态管理模块SWC可以通过内部的先进先出队列(fist input fist output，FIFO)管理多条事件，避免事件冲突。
一种可能的实现方式中，如图4所示，状态管理模块可以包括：运行环境适配子模块(或称为RTE适配子模块)、状态管理上下文子模块和有限状态机子模块(也可 以称为有限状态机)。
示例性的，运行环境适配子模块可以用于适配运行环境层，使得状态管理模块可以与RTE进行通信。
示例性的，状态管理上下文子模块可以用于管理上下文，以及存储满足状态管理模块的判断规则的事件。满足判断规则的事件可以是状态管理模块能够识别的合法事件等，本申请实施例对此不做具体限定。
示例性的，有限状态机子模块可以是表示有限个状态以及在这些状态之间的转移和动作等行为的数学模型。例如，有限状态机可以有以下特点：可以用状态来描述事件，并且任一时刻，事件总是处于一种状态通过触发事件的某些行为，可以导致事件从一种状态过渡到另一种状态。事件状态变化是有规则的，A状态可以变换到B，B可以变换到C，A却不一定能变换到C。
一种可能的实现方式中，有限状态机子模块可以有空闲状态和运行状态两种状态，在有限状态机子模块处理事件时，有限状态机子模块的状态可以为运行状态。在有限状态机子模块空闲时，有限状态机子模块的状态可以为空闲状态。例如，每次有事件更新时，有限状态机子模块将状态由空闲状态(例如空闲状态可以用idle表示)切换为运行状态(例如运行状态可以用running表示)并进行状态迁移处理，处理完成后有限状态机子模块切换回空闲状态。这样可以使得有限状态机子模块每次处理一个事件，保证单次更新状态的独立性。
一种可能的实现方式中，有限状态机子模块可以进一步划分为状态迁移前处理单元、状态迁移计算单元和状态迁移后处理单元。状态迁移前处理单元用于在下发状态迁移信息之前，确认需要状态迁移的SWC处于能执行状态迁移的状态。状态迁移计算单元用于计算事件对应的系统状态。状态迁移后处理单元用于下发状态迁移信息，例如，可以通知需要进行状态迁移的模块，进而各模块可以分别执行状态迁移，提升状态迁移的效率。
例如，车辆中的雷达正在运行时，发现雷达温度过高，继续运行会有故障，会产生用于提醒有限状态机子模块需要休息的温度过高事件，该事件需要触发有限状态机子模块将雷达修改为睡眠状态，状态迁移计算单元计算雷达进入睡眠状态需要迁移的状态，但是因为雷达中正在执行任务，状态迁移前处理单元可以监控雷达把当前任务执行完，之后状态迁移后处理单元通知其他模块状态迁移信息，各模块各自根据自身情况迁移到新的状态。
示例性的，图5示出了一种状态管理方法。
S1：状态管理模块初始化。
示例性的，可以在车辆上电时，初始化状态管理模块中的上下文全局变量、标志位以及各模块的注册函数等。
S2：状态管理模块适配RTE。
示例性的，可以在应用层中封装RTE接口，使得RTE接口可以被状态管理模块等调用。
S3：状态管理模块中的有限状态机初始化为空闲状态。
S4：状态管理模块接收来自其他SWC传递的更新状态事件消息。
示例性的，状态管理模块可以通过SWC接收来自应用程序层或基础软件层的消息，消息中包括事件。
一种可能的实现方式中，如果接收到多个事件，可以根据多个事件的优先级在多个事件中选择其中一个进行处理，例如，可以选择优先级最高的一个事件进行处理，或者根据接收到多个事件的顺序，采用先进先出的规则在多个事件中选择其中一个进行处理。从而可以避免多个事件处理的冲突。
S5：状态管理模块判断事件是否合法。
示例性的，如果状态管理模块能够识别该事件，可以认为该事件合法，执行S6及后续步骤，如果状态管理模块不能识别该事件，可以认为该事件不合法，执行S13及后续步骤。
S6：状态管理模块中的状态管理上下文子模块存储该合法事件。
S7：判断状态管理模块中的有限状态机状态是否为空闲状态。
示例性的，可以读取有限状态机的状态参数，依据状态参数判断状态管理模块中的有限状态机状态是否为空闲状态。例如，如果状态参数为idle，可以判断状态管理模块中的有限状态机状态是为空闲状态。
如果有限状态机状态为空闲状态，可以执行S8及后续步骤，如果有限状态机状态不为空闲状态，可以执行S13及后续步骤。
S8：将有限状态机状态置为运行状态。
示例性的，可以将有限状态机的状态参数置为用于表示运行状态的参数，例如可以将有限状态机的状态参数置为running。
后续如果接收到新的事件，因为有限状态机状态为运行状态，则不会执行对新的事件的处理，可以避免事件处理的冲突。
S9：状态管理模块执行状态迁移计算。
示例性的，状态管理模块可以计算事件对应的系统状态，本申请实施例对具体的计算过程和内容不作限定。
S10：状态管理模块判断系统状态是否发生变化。
一种可能的实现方式中，事情的发生不会导致系统状态的变化，即使该事件发生也不需要进行状态迁移，则可以执行S13及后续步骤。
一种可能的实现方式中，事情的发生会导致系统状态的变化，例如迁移计算中得到的系统状态与当前的系统状态不同，可以执行S11及后续步骤。
S11：状态管理模块执行状态迁移前处理。
示例性的，状态管理模块可以检测需要执行状态迁移的模块是否具备执行状态迁移的条件。
S12：状态管理模块下发状态迁移信息。
示例性的，状态管理模块可以利用VFB向需要进行状态迁移的模块下发状态迁移信息，各模块可以执行各自的状态迁移。
一种可能的实现方式中，状态管理模块还可以从一个或多个SWC接收系统状态迁移反馈，从而可以或去各模块执行状态迁移的结果。
S13：将有限状态机状态置为空闲状态。
本申请实施例中，上述S1-S13的步骤中存在可选的步骤，可以根据实际的应用场景适应选择。
综上所述，与通常的AUTOSAR架构不同的是，本申请实施例的AUTOSAR架构中，在application layer设置状态管理模块，SWC可以接收BSW及MCAL相关信息，进而通过VFB汇总到状态管理模块进行统一处理。即状态管理功能在application layer实现，BSW中不同模块产生的相同事件可以在SWC中可以抽象为一个事件，从而可以屏蔽BSW中细分模块的事件区别，部署容易且容易实现。
一种可能的实现方式中，本申请实施例提供一种状态处理单元，状态处理单元用于执行图5对应的实施例及任意一种可能的设计中描述的状态管理方法。
一种可能的实现方式中，本申请实施例提供一种计算机可读存储介质，计算机可读存储介质中存储有计算机程序或指令，当计算机程序或指令在计算机上运行时，使得计算机执行图5对应的实施例及任意一种可能的设计中描述的状态管理方法。
本申请实施例是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理单元以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理单元执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成 的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。
上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本申请各个实施例所述方法的部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(read-only memory，ROM)、随机存取存储器(random access memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

Claims (21)

  1. 一种汽车开放系统架构，所述汽车开放系统架构包括应用程序层、运行环境层和基础软件层，其特征在于，所述应用程序层中设置有状态管理模块；所述应用程序层与所述基础软件层之间通过所述运行环境层通信；
    所述状态管理模块用于：
    接收来自所述应用程序层或所述基础软件层的事件；
    在所述事件满足所述状态管理模块的判断规则的情况下，计算所述事件对应的系统状态；
    在所述事件对应的系统状态与汽车开放系统当前的系统状态不同的情况下，向所述汽车开放系统中需要进行状态迁移的一个或多个软件组件SWC下发包括所述事件对应的系统状态的状态迁移信息，所述状态迁移信息用于指示所述一个或多个SWC迁移状态到所述事件对应的系统状态。
  2. 根据权利要求1所述的汽车开放系统架构，其特征在于，所述应用程序层与所述基础软件层之间通过所述运行环境层的虚拟功能总线VFB通信，所述状态管理模块具体用于：
    通过所述VFB向需要进行状态迁移的一个或多个SWC分发所述状态迁移信息。
  3. 根据权利要求2所述的汽车开放系统架构，其特征在于，所述状态管理模块还用于：
    从所述一个或多个SWC接收状态迁移反馈信息，所述状态迁移反馈信息用于反馈所述一个或多个SWC的状态迁移情况。
  4. 根据权利要求1-3任一项所述的汽车开放系统架构，其特征在于，所述状态管理模块包括有限状态机子模块；所述状态管理模块具体用于：
    在所述有限状态机子模块的状态为空闲状态的情况下，修改所述有限状态机子模块的状态为运行状态；
    利用所述有限状态机子模块计算所述事件对应的系统状态；
    在所述事件对应的系统状态与汽车开放系统当前的系统状态不同的情况下，利用所述有限状态机子模块向所述一个或多个SWC下发所述状态迁移信息；
    将所述有限状态机子模块的状态设置为空闲状态。
  5. 根据权利要求4所述的汽车开放系统架构，其特征在于，所述有限状态机子模块包括：状态迁移前处理单元、状态迁移计算单元和状态迁移后处理单元；
    所述状态迁移前处理单元用于在下发所述状态迁移信息之前，确认需要状态迁移的一个或多个SWC处于能执行状态迁移的状态；
    所述状态迁移计算单元用于计算所述事件对应的系统状态；
    所述状态迁移后处理单元用于向所述一个或多个SWC下发所述状态迁移信息。
  6. 根据权利要求1-5任一项所述的汽车开放系统架构，其特征在于，所述状态管理模块包括运行环境适配子模块和状态管理上下文子模块；
    所述运行环境适配子模块用于适配所述运行环境层；
    所述状态管理上下文子模块用于在所述状态管理模块判断所述事件为合法事件的 情况下，存储所述事件。
  7. 根据权利要求1-6任一项所述的汽车开放系统架构，其特征在于，所述状态管理模块具体还用于：
    在来自所述应用程序层或所述基础软件层的事件的数量为多个的情况下，在多个事件中选择其中一个进行处理。
  8. 根据权利要求7所述的汽车开放系统架构，其特征在于，所述状态管理模块具体还用于：
    在来自所述应用程序层或所述基础软件层的事件的数量为多个的情况下，根据多个事件的优先级在所述多个事件中选择其中一个进行处理；或，
    根据接收到所述多个事件的顺序，采用先进先出的规则在所述多个事件中选择其中一个进行处理。
  9. 根据权利要求1-8任一项所述的汽车开放系统架构，其特征在于，所述状态管理模块的SWC接收接口不区分SWC差异。
  10. 根据权利要求1-9任一项所述的汽车开放系统架构，其特征在于，来自所述基础软件层的事件为：抽象为不区分所述基础软件层中的细分模块的事件。
  11. 一种状态管理方法，其特征在于，包括：
    接收来自所述应用程序层或所述基础软件层的事件；
    在所述事件满足判断规则的情况下，计算所述事件对应的系统状态；
    在所述事件对应的系统状态与汽车开放系统当前的系统状态不同的情况下，向所述汽车开放系统中需要进行状态迁移的一个或多个软件组件SWC下发包括所述事件对应的系统状态的状态迁移信息，所述状态迁移信息用于指示所述一个或多个SWC迁移状态到所述事件对应的系统状态。
  12. 根据权利要求11所述的方法，其特征在于，所述向所述汽车开放系统中需要进行状态迁移的一个或多个软件组件SWC下发包括所述事件对应的系统状态的状态迁移信息，包括：
    通过虚拟功能总线VFB向所述一个或多个软件组件SWC分发所述状态迁移信息。
  13. 根据权利要求12所述的方法，其特征在于，还包括：
    从所述一个或多个SWC接收状态迁移反馈信息，所述状态迁移反馈信息用于反馈所述一个或多个SWC的状态迁移情况。
  14. 根据权利要求11-13任一项所述的方法，其特征在于，所述计算所述事件对应的系统状态，包括：
    在有限状态机子模块的状态为空闲状态的情况下，修改所述有限状态机子模块的状态为运行状态；
    利用所述有限状态机子模块计算所述事件对应的系统状态；
    所述在所述事件对应的系统状态与汽车开放系统当前的系统状态不同的情况下，向所述汽车开放系统中需要进行状态迁移的一个或多个SWC下发包括所述事件对应的系统状态的状态迁移信息，包括：
    在所述事件对应的系统状态与汽车开放系统当前的系统状态不同的情况下，利用所述有限状态机子模块向所述汽车开放系统中需要进行状态迁移的一个或多个SWC 下发包括所述事件对应的系统状态的状态迁移信息；
    将所述有限状态机子模块的状态设置为空闲状态。
  15. 根据权利要求14所述的方法，其特征在于，还包括：
    确认所述需要状态迁移的一个或多个SWC处于能执行状态迁移的状态。
  16. 根据权利要求11-15任一项所述的方法，其特征在于，所述在所述事件满足判断规则的情况下，计算所述事件对应的系统状态，包括：
    在所述事件为合法事件的情况下，计算所述事件对应的系统状态。
  17. 根据权利要求11-16任一项所述的方法，其特征在于，还包括：
    在来自所述应用程序层或所述基础软件层的事件的数量为多个的情况下，在多个事件中选择其中一个进行处理。
  18. 根据权利要求17所述的方法，其特征在于，所述在来自所述应用程序层或所述基础软件层的事件的数量为多个的情况下，在多个事件中选择其中一个进行处理，包括：
    在来自所述应用程序层或所述基础软件层的事件的数量为多个的情况下，根据多个事件的优先级在所述多个事件中选择其中一个进行处理；或，
    根据接收到所述多个事件的顺序，采用先进先出的规则在所述多个事件中选择其中一个进行处理。
  19. 一种状态处理单元，其特征在于，所述状态处理单元用于执行如权利要求11-18任一项所述的状态管理方法。
  20. 一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有指令，当所述指令被运行时，实现上述权利要求11-18任一项所述的状态管理方法。
  21. 一种计算机程序产品，其特征在于，包括计算机程序，所述计算机程序在被处理器执行时实现权利要求11-18任一项所述的状态管理方法。
PCT/CN2021/074632 2020-03-31 2021-02-01 汽车开放系统架构、状态管理方法和装置 Ceased WO2021196863A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP21779494.0A EP4120082A4 (en) 2020-03-31 2021-02-01 AUTOMOTIVE OPEN SYSTEM ARCHITECTURE, STATE MANAGEMENT METHOD AND APPARATUS

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202010247380.4A CN113467962B (zh) 2020-03-31 2020-03-31 汽车开放系统架构、状态管理方法和装置
CN202010247380.4 2020-03-31

Publications (1)

Publication Number Publication Date
WO2021196863A1 true WO2021196863A1 (zh) 2021-10-07

Family

ID=77865805

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/074632 Ceased WO2021196863A1 (zh) 2020-03-31 2021-02-01 汽车开放系统架构、状态管理方法和装置

Country Status (3)

Country Link
EP (1) EP4120082A4 (zh)
CN (1) CN113467962B (zh)
WO (1) WO2021196863A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114675822A (zh) * 2022-02-28 2022-06-28 阿尔特汽车技术股份有限公司 Autosar软件组件开发方法、装置、设备及存储介质
CN119902796A (zh) * 2025-01-08 2025-04-29 重庆长安汽车股份有限公司 汽车的软件架构、汽车软件代码的生成方法及装置

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117461024A (zh) * 2022-05-23 2024-01-26 华为技术有限公司 一种汽车开放系统架构模型构建方法及装置
CN115474226B (zh) * 2022-08-11 2024-04-09 广州汽车集团股份有限公司 异常检测方法、装置以及车辆
CN116112578A (zh) * 2023-02-14 2023-05-12 阿尔特汽车技术股份有限公司 一种AutoSAR的BSW系统LIN信号设计方法及系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101332816A (zh) * 2008-06-11 2008-12-31 山东大学 开放式汽车机械式自动变速器电控系统
JP2012155682A (ja) * 2011-01-28 2012-08-16 Denso Corp 組み込みシステム用のプラットフォーム、アプリケーション、該プラットフォームと該アプリケーションを備える制御プログラム、電子装置、及び、アプリケーションの更新方法
US20130103379A1 (en) * 2011-10-20 2013-04-25 Electronics And Elecommunications Research Institute Apparatus and method for verifying interoperability between application software and autosar service
CN103676925A (zh) * 2012-09-18 2014-03-26 日立汽车系统株式会社 车辆控制装置及车辆控制系统
CN111769311A (zh) * 2020-06-30 2020-10-13 上海捷氢科技有限公司 一种氢燃料电池控制系统

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102007062114A1 (de) * 2007-12-21 2009-07-23 Opensynergy Gmbh Kraftfahrzeug-Steuervorrichtung
KR102109125B1 (ko) * 2014-12-11 2020-05-12 현대자동차주식회사 Ａｕｔｏｓａｒ 기반 차량 ｅｃｕ 상태 관리 방법

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101332816A (zh) * 2008-06-11 2008-12-31 山东大学 开放式汽车机械式自动变速器电控系统
JP2012155682A (ja) * 2011-01-28 2012-08-16 Denso Corp 組み込みシステム用のプラットフォーム、アプリケーション、該プラットフォームと該アプリケーションを備える制御プログラム、電子装置、及び、アプリケーションの更新方法
US20130103379A1 (en) * 2011-10-20 2013-04-25 Electronics And Elecommunications Research Institute Apparatus and method for verifying interoperability between application software and autosar service
CN103676925A (zh) * 2012-09-18 2014-03-26 日立汽车系统株式会社 车辆控制装置及车辆控制系统
CN111769311A (zh) * 2020-06-30 2020-10-13 上海捷氢科技有限公司 一种氢燃料电池控制系统

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
P.R., DHANAMJAYAN ET AL.: "ECU State Manager Module Development and Design for Automotive Platform Software Based on AUTOSAR 4.0", INTERNATIONAL JOURNAL OF TECHNICAL RESEARCH AND APPLICATIONS, vol. 3, no. 4, July 2015 (2015-07-01), XP055855177, ISSN: 2320-8163 *
See also references of EP4120082A4
YANG, ZHENYU: "Design and Implementation of ECU State Manager Based on the Specifications of AUTOSAR", THESIS SHANDONG UNIVERSITY OF SCIENCE AND TECHNOLOGY, 16 May 2013 (2013-05-16), CN, pages 1 - 66, XP009531273, DOI: 10.7666/d.D301886 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114675822A (zh) * 2022-02-28 2022-06-28 阿尔特汽车技术股份有限公司 Autosar软件组件开发方法、装置、设备及存储介质
CN119902796A (zh) * 2025-01-08 2025-04-29 重庆长安汽车股份有限公司 汽车的软件架构、汽车软件代码的生成方法及装置

Also Published As

Publication number Publication date
EP4120082A1 (en) 2023-01-18
EP4120082A4 (en) 2023-05-03
CN113467962A (zh) 2021-10-01
CN113467962B (zh) 2025-05-06

Similar Documents

Publication Publication Date Title
WO2021196863A1 (zh) 汽车开放系统架构、状态管理方法和装置
Mubeen et al. Support for end-to-end response-time and delay analysis in the industrial tool suite: Issues, experiences and a case study
US8065126B2 (en) GUI-facilitated change management for vehicle electrical/electronic architecture design
CN106096126B (zh) 一种基于SysML/MARTE的信息物理融合系统的建模方法
US20100031212A1 (en) Complexity management for vehicle electrical/electronic architecture design
JPH03126158A (ja) スケジユーリング方法及び装置
US20110296435A1 (en) Message-based modeling
US20200159570A1 (en) Executable Component Interface and Controller
US5634056A (en) Run time dependency management facility for controlling change propagation utilizing relationship graph
JP5224957B2 (ja) シミュレーション方法、システム及びプログラム
US12073197B2 (en) Systems and methods for generating service access points for RTE services in code or other RTE service information for use with the code
US8281316B2 (en) Event direction detector and method thereof
US7739690B2 (en) Meta-container for model-based distributed applications
Wild et al. An architecture-centric approach towards the construction of dependable automotive software
EP3853739A1 (en) Modifying a configuration of a port hub
Zeng et al. Design space exploration of automotive platforms in metropolis
CN113302589A (zh) 协调部件接口控制框架
CN117475530A (zh) 一种车辆诊断方法、系统及设备
CN118443075A (zh) 状态驱动微值架构
CN101719173B (zh) 一种面向对象的并行碰撞检测方法、装置及系统
KR102677211B1 (ko) 디지털 트윈 시스템에서 추상 디지털 사물 클래스를 기반으로 디지털 사물을 생성하는 방법
CN114936020A (zh) 数据处理方法、装置、存储介质及服务器
JP7672179B1 (ja) 信号追跡観察方法及びシステム、コンピュータ読み取り可能な記憶媒体及び電子機器
CN121858170A (zh) 用于电子控制单元ecu的活动激活方法
Wang et al. Study on complex event processing for cps: An event model perspective

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21779494

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2021779494

Country of ref document: EP

Effective date: 20221014

NENP Non-entry into the national phase

Ref country code: DE