Requirements on Mode Management, No.69, 2021-11
AUTOSAR R21-11記事一覧はこちら。
AUTOSAR 21-11,160文書読んだ。2022年5月中に全部読み。
AUTOSAR 21-11, 62文書読んだ。2022年5月中に半分到達予定。
AUTOSAR R21-11(0) 仕様ダウンロード一覧。単語帳。参考文献資料作成
用語(terms)
| Term | Description |
|---|---|
| Active wake-up | Wake-up caused by the ECU e.g. by a sensor. |
| Alive indication | Indication that a supervised SW-C is alive - meaning active - provided from the SW-C itself to the Watchdog Manager [3]. |
| Application | Applications are used synonymous to a SW-C. A SW-C may span several atomic SW-Cs. AUTOSAR provides the element of a "composition" to formally group several atomic SW-Cs of an application. A composition is used to structure the description and does not affect the generated code. Note: The atomic SW-Cs in a composition can still be mapped to different ECUs. Application Modes are therefore ’local’ to an application but can be ’global’ to several ECUs. |
| Application Mode | An Application Mode is a mode that is not controlled and standardized by the Mode Managers in the BSW. The scope of an Application Mode is a limited number of SW-Cs that belongs to a logical Application. If a mode only affects one composition, it is an Application Mode. An Application Mode may be distributed across multiple ECUs or may be local to one ECU depending on the distribution of the SW-C belonging to that application. Examples: Normal Operation, Limp Home |
| Application Mode Manager | An Application Mode Manager is a SW-C therefore a priori not standardized. It collects environmental data and Mode Requests via application-specific (non-standardized) interfaces from other SW-Cs. It can switch Application Modes (that are not controlled and standardized by the Mode Managers in the BSW). It can also request modes from other Mode Managers, specifically from Mode Managers in the BSW. |
| BSW Mode | A BSW Mode is mode, which is controlled and standardized by the Mode Manager in the BSW. A BSW Mode is always local to one ECU. Examples: EcuM Modes, ComM Modes |
| BSW Mode Manager | [1] The BSW Mode Manager [1] is a BSW module that collects mode requests via a standardized interface and controls functionality of other BSW modules accordingly. Examples are: LIN Schedule Table Switching, Enabling/Disabling I-PDU Groups, ... |
| Communication mode | Related to a physical channel or to a user, it indicates if it is possible to send/receive, only receive, neither send nor receive. |
| Communication request | A communication request indicates a demand for communication from a given user (e.g. a runnable requiring an operational communication stack). However, it can neither be assumed that the request will be fulfilled within a certain time nor that it will be fulfilled at all. The demander itself has to make sure that communication is indeed established, by using query functions or callbacks. |
| ECU state | General term to indicate the states managed by the ECU State Manager [2]. They represent a structured model that extends the power modes of the ECU with states and transitions to support necessary activities of software to enter/leave these power modes. |
| Inoperation | An artificial word to describe the ECU when it is not operational, i.e. not running. It comprises all meanings of off, sleeping, frozen, etc. Using this definition is beneficial since it has no predefined meaning. |
| Low-power mode | All power modes except "on" (full power). |
| Mode | A mode is a certain set of states of the various state machines that are running in the vehicle that are relevant to a particular entity, e.g. a SW-C, a BSW module, an application, a whole vehicle In its lifetime, an entity changes between a set of mutually exclusive modes. These changes are triggered by environmental data, e.g. signal reception, operation invocation. |
| Mode Declaration Group | A Mode Declaration Group is defined in the Software Component Template and implemented by the RTE [7]. A Mode Declaration Group defines a number of mutually exclusive modes. There is no hierarchy of modes within a Mode Declaration Group. Each Mode Declaration Group describes only one aspect of the whole system. All modes of all Mode Declaration Groups on an ECU describe the abstract mode of the ECU. Similarly, all modes of all Mode Declaration Groups in a system describe the abstract mode of all ECUs in the system. (The mode is abstract because it cannot be physically accessed, it just exists conceptually). There is a standardized set of Mode Declaration Groups defined in the BSW, e.g. ComM, WdgM, EcuM. Each system designer is free to extend the number of Mode Declaration Groups and define his/her own modes in there. Only one Mode Manager is allowed to switch the mode of an instance of a Mode Declaration Group. (Limitation in VFB [8]) |
| Mode Manager | A Mode Manager is a role that can be taken by either a BSW module (and optionally additionally by an SW-C). The Mode Manager collects requests from Mode Requesters, arbitrates them and switches the mode of its Mode Declaration Group(s) accordingly. Examples of Mode Managers are: EcuM, ComM, WdgM and BswM Note: If a SW-C Mode Manager switches modes directly, the mode arbitration in the BSW Mode Manager [1] cannot resolve conflicts. Thus, it is recommended to use multi-level mode arbitration, of SW-C mode Manager and BSW Mode Manager [1] |
| Mode Port | A Mode Port is port that has a Sender-Receiver Interface which contains a Mode Declaration Group. Note: This is called Mode Port in SWS RTE [7] -> To distinguish it from Mode Request Ports, we should call it Mode Switch Port |
| Mode Request | A Mode Request is some information communicated to a Mode Manager that requests the Mode Manager to switch to a certain mode. For Mode Managers in the BSW the interface to send a Mode Request is a standardized client-server interface defined by the corresponding Mode Manager. Examples: Client-server interface ComM_UserRequest with operation RequestComMode(...). For Application Mode Managers the interface can be any client-server or sender-receiver interface defined by the Mode Manager. |
| Mode Request Port | A Mode Request Port is a port with the special semantics of requesting a mode from a Mode Manager. It can be a Client-Server or a Sender-Receiver Port. For Mode Managers in the BSW the Mode Request Port is standardized. Note: For EcuM, ComM and WdgM it is always a Provided Client-Server Port. For BswM it is a Required Sender-Receiver Ports. |
| Mode Requester | A Mode Requester is an entity that requests modes from a Mode Manager. |
| Mode Switch Port | Favored replacement of phrase Mode Port |
| Mode User | A Mode User is an entity that reacts on mode changes. |
| OFF state | ECU state. It denotes the unpowered ECU. Depending on the hardware design, the ECU can or cannot react to passive wake-up in this state (wakeability is not required in this state). |
| Passive wake-up | Wakeup initiated by another ECU and propagated (e.g. by bus or wakeup-line) to the ECU currently in focus. |
| Port Group | A Port Group is a logical group of ports that are needed to realize the same functionality in the Application. A port can be a member of multiple Port Groups. A Port Group can be used to request all associated communication resources and to inquire their state. Thereby, the Port Group also defines a mapping between Application Ports and Communication Resources. Thus, the purpose of a port group is to have an abstraction of the required communication resources of that functionality For example, an Application contains normal-operation functionality and limp-home functionality with reduced communication requirements. Then it is useful to define two Port Groups, A and B. A contains the ports that are necessary for the normal-operation functionality and B contains the ports for the limp-home functionality. Thereby, the Application can recognize the condition when the communication resources for normal operation are unavailable but are sufficient for limp home. Port Groups are defined on SW-C composition level, which means that they may be distributed on several ECUs. The requests and indications for the Port Groups shall however only affect the portion of the Port Group that is local to an ECU. If distributed control of Port Groups is needed it can be handled on "Application Mode Management" level (above the RTE [7]) using normal communication features. |
| Power mode | Hardware power mode of the ECU. Typically: on (full power), off, sleep, standby, etc... The last two items can take several forms depending on hardware capabilities (reduced clock, peripheral standby, etc.). |
| Program flow monitoring | Technique to detect errors that cause a divergence from the valid program sequence seen during valid execution of a program. |
| RUN state | ECU state. The ECU is fully functional, all BSW modules are initialized and application software components are able to run. |
| Shutdown target | The chosen low-power state (OFF, SLEEP) for the next shutdown. If the SLEEP state supports several sleep modes, the shutdown target shall indicate the chosen sleep mode. |
| Sleep mode | The term "mode" is related to the current availability of the ECU’s capabilities. "Sleep mode" is the overall abstracted term for a variety of low-power modes that could exist at different CPU’s, which have in common that they currently do not perform code-execution, but are still powered. |
| SLEEP state | ECU state. It is an energy saving state: no code is executed but power is still supplied, and if configured correctly, the ECU is wakeable. The SLEEP state provides a configurable set of sleep modes which typically are a trade off between power consumption and time to restart the ECU. |
| State/communication requestor | See User. |
| Supervised Entity | A supervised entity is a software entity which is included in the monitoring of the Watchdog Manager [3]. Each supervised entity has exactly one identifier. A supervised entity denotes a collection of checkpoints within a software component or basic software module. There may be zero, one or more supervised entities in a software component or basic software module. |
| User | Concept for requestors of the ECU State Manager [2] and of the Communication Manager [4]. A user may be a runnable entity, a SW-C/BSW or even a group of SW-Cs/BSWs, which acts as a single unit towards the ECU State Manager [2] and the Communication Manager [4]. |
| Vehicle Mode | A Vehicle Mode is a mode that is not controlled and standardized by the Mode Managers in the BSW. The scope of a Vehicle Mode is the whole vehicle. If a mode affects multiple compositions, it is a Vehicle Mode. A Vehicle Mode is by definition distributed across the whole vehicle. Example: Transport Mode, Power Saving Mode, Ignition On, Ignition Off |
| Vehicle Mode Manager | A Vehicle Mode Manager is a special kind of Application Mode Manager that switches Vehicle Modes. |
| Wake-up event | A physical event which causes a wake-up. A CAN message or a toggling IO line can be wake-up events. Similarly, the internal SW representation, e.g. an interrupt, may also be called a wake-up event. |
| Wake-up reason | The wake-up event being actually the cause of the current/ last wake-up. |
| Wake-up source | The peripheral or ECU component which deals with wake-up events is called a wake-up source. |
| BSW | Basic Software |
| BswM | Basic Software Mode Manager |
| ComM | Communication Manager [4] |
| DCM | Diagnostic Communication Manager [4] |
| DEM | Diagnostic Event Manager |
| EcuM | ECU State Manager [2] |
| FiM | Function Inhibition Manager |
| RE | Runnable Entity |
| SW-C | Software Component |
| WdgM | Watchdog Manager [3] |
英日
日本語は仮訳
T.B.D.
参考(reference)
[1] Specification of Basic Software Mode Manager
AUTOSAR_SWS_BSWModeManager
[2] Specification of ECU State Manager
AUTOSAR_SWS_ECUStateManager
[3] Specification of Watchdog Manager
AUTOSAR_SWS_WatchdogManager
[4] Specification of Communication Manager
AUTOSAR_SWS_COMManager
[5] Standardization Template
AUTOSAR_TPS_StandardizationTemplate
[6] Glossary
AUTOSAR_TR_Glossary
[7] Specification of RTE Software
AUTOSAR_SWS_RTE
[8] Virtual Functional Bus
AUTOSAR_EXP_VFB
[9] Layered Software Architecture
AUTOSAR_EXP_LayeredSoftwareArchitecture
[10] System Template
AUTOSAR_TPS_SystemTemplate
[11] Requirements on AUTOSAR Features
AUTOSAR_RS_Features
＜この記事は個人の過去の経験に基づく個人の感想です。現在所属する組織、業務とは関係がありません。＞
文書履歴(document history)
ver. 0.01 初稿 20220529