Requirements on Mode Management, R22-11, CP, No.69
AUTOSARが、2022年の版、R22-11公開しました。公開行事の模様は
AUTOSAR R22-11 Release Event 20221208
下記URL順次確認中です。
要求/仕様（Requirement and Specification)
一覧
AUTOSAR R22-11 Classic Platform 一覧はこちら。
Classic Platform Release Overview, AUTOSAR R22-11, CP, No.0(2)
AUTOSAR R22-11 マラソン
Qiitaの記事の一覧は作成中です。
AUTOSAR R22-11 一覧（２）
Abstract Platformとの関係
Template, TypeはAbstract Platformで統一的に定義するとよい。
Template, Typeで、複数の文書を統合するとよい。
<この項は書きかけです。順次追記します。>
文書変更(Document Change)
• Rework of PNC related ComM and NM handling
• Removed "DRAFT"-tag from [SRS_ModeMgm_09249]
• Editorial Changes
用語(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
https://www.autosar.org/fileadmin/standards/foundation/22-11/AUTOSAR_TR_Glossary.pdf
[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
Countdown Calendar 2022
今年企画した6つのCountdown Calendarと、それぞれの記事一つをご紹介します。
AUTOSAR Countdown Calendar 2022
AUTOSAR References to ISO, IEC, ITU, IEEE, RFC and SEA etc.
Automotive Handbook Countdown Calendar 2022
Basic principles, ボッシュ自動車handbook(英語)11版まとめ<2>
2022 いいねをいただいた記事ランキング(O.K.版) Countdown Calendar 2022
2022年１月下旬 いいねをいただいた記事 16
CDCale(O.K.) Countdown Calendar 2022
「会議は15分未満」に。小耳にはさんだ話。
ABC language (O.K.版） Advent Calendar 2022
LLVMソースコードのコンパイルをしようと思ってハマった罠とそこから脱出するための努力
ABC maker(O.K版） Advent Calendar 2022
JAXA/IPA クリティカルソフトウェアワークショップ WOCS言語関連発表(改定版)
CountdownCalendar2022 報告
関連文書(Related document)
2023年1月 記事数一覧
年末100記事を30点に仕上げる。
2023 書き初め
「はじめてのCAN/CANFD 」 ベクタージャパン ＜エンジニア夏休み企画>【読書感想文】
三方良し Udemy 車載LAN入門講座 CAN通信編
詳解 車載ネットワーク CAN, CAN FD, LIN, CXPI, Ethernetの仕組みと設計のために(1) 著者 ＜エンジニア夏休み企画 読書感想文＞
詳解 車載ネットワーク CAN, CAN FD, LIN, CXPI, Ethernetの仕組みと設計のために(2)参考文献 ＜エンジニア夏休み企画>【読書感想文】
詳解 車載ネットワーク CAN、CAN FD、LIN、CXPI、Ethernetの仕組みと設計のために
R22-11 URL変更
Requirements on Mode Management, AUTOSAR 69, R22-11, CP, 20230421
＜この記事は個人の過去の経験に基づく個人の感想です。現在所属する組織、業務とは関係がありません。＞
文書履歴(document history)
ver. 0.01 初稿 20230109
ver. 0.02 ありがとう追記 20230607
最後までおよみいただきありがとうございました。
いいね 💚、フォローをお願いします。
Thank you very much for reading to the last sentence.
Please press the like icon 💚 and follow me for your happy life.