Specification of RTE Software, No.84, 2021-11
AUTOSAR R21-11記事一覧はこちら。
AUTOSAR 21-11,200文書読んだ。2022年5月に全部到達。
AUTOSAR R21-11(0) 仕様ダウンロード一覧。単語帳。参考文献資料作成
用語(terms)
| Term | Description |
|---|---|
| application mode manager | An application mode manager is an AUTOSAR softwarecomponent that provides the service of switching modes. The modes of an application mode manager do not have to be standardized. |
| ASCR runnable | A Runnable Entity that is triggered by at least one AsynchronousServerCallReturnsEvent. |
| associated Local Software Cluster Communication Plug- | In The Local Software Cluster Communication Plug-In which is assigned to a communication graph, ExclusiveArea, mode machine instance or distributed shared mode group and therefore handles all accesses via RTE APIs, SchM APIs or RTE internal code. |
| associated Cross Software Cluster Communication Plug | -In The Cross Software Cluster Communication Plug-In which is assigned to a communication graph, mode machine instance and therefore handles all accesses via RTE APIs or RTE internal code. |
| AutosarDataPrototype implementation | Definitions and declarations for non automatic1 memory objects which are allocated by the RTE and implementing AutosarDataPrototypes or their belonging status handling. 1.declaration with no static or external specifier defines an automatic variable |
| BswSchedulableEntity activation | The activation of a BswSchedulableEntity is defined as the activation of the task/ISR2 that contains the BswSchedulableEntity and eventually includes setting a flag that tells the glue code in the task/ISR2 which BswSchedulableEntity is to be executed. |
| BswSchedulableEntity start | A BswSchedulableEntity is started by the calling the Cfunction that implements the BswSchedulableEntity from within a started task/ISR2. |
| ’C’ typed PerInstanceMemory | ’C’ typed PerInstanceMemory is defined with the class PerInstanceMemory. The type of the memory is defined with a ’C’ typedef in the attribute typeDefinition. |
| client | A client is defined as one ClientServerOperation in one RPortPrototype of one Software Component instance. For the definition of the client neither the number of ServerCallPoints nor RunnableEntity accesses to the ServerCallPoint are relevant. A Software Component instance can appear as several clients to the same server if it defines ServerCallPoints for several PortPrototypes of the same PortInterface’s ClientServerOperation. |
| CodeGenerationTime variability | Variability defined with an VariationPoint or AttributeValueVariationPoint with latest bindingTime CodeGenerationTime. |
| coherent implicit data access | An implicit read access or an implicit write access which belongs to coherency group. Therefore it is referenced by a RteVariableReadAccessRef or RteVariableWriteAccessRef belonging to a RteImplicitCommunication container which RteCoherentAccess parameter is set to true. |
| coherent implicit read access | An implicit read access which belongs to coherency group. Therefore it is referenced by a RteVariableReadAccessRef belonging to a RteImplicitCommunication container which RteCoherentAccess parameter is set to true. |
| coherent implicit write access | An implicit write access which belongs to coherency group. Therefore it is referenced by a RteVariableReadAccessRef or RteVariableWriteAccessRef belonging to a RteImplicitCommunication container which RteCoherentAccess parameter is set to true. |
| common mode machine instance | A ‘common mode machine instance’ is a special ‘mode machine instance’ shared by BSW Modules and SW-Cs: The RTE Generator creates only one mode machine instance if a ModeDeclarationGroupPrototype instantiated in a port of a software-component is synchronized (synchronizedModeGroup of a SwcBswMapping) with a providedModeGroup ModeDeclarationGroupPrototype of a Basic Software Module instance. The related mode machine instance is called common mode machine instance. |
| Communication Graph | The sum of all AbstractAccessPoints to elements of PortInterfaces instantiated in PortPrototypes which are connected to each other, or the sum of all accesses from BswModuleEntitys to interface elements in a BswModuleDescriptions connected to each other. Data Communication Graph The sum of all VariableAccesses to VariableDataPrototypes instantiated in PortPrototypes which are connected to each other, or the sum of all VariableAccesses to VariableDataPrototypes in the InternalBehavior, or the sum of all BswVariableAccesses to VariableDataPrototypes in BswModuleDescriptions connected to each other. |
| Parameter Communication Graph | The sum of all ParameterAccesses to ParameterDataPrototypes instantiated in PortPrototypes which are connected to each other, or the sum of all ParameterAccesses to ParameterDataPrototypes in the InternalBehavior. |
| Client Server Communication Graph | The sum of all ServerCallPoints to operations instantiated in PortPrototypes which are connected to each other inclusive the belonging server runnable. |
| Trigger Communication Graph | The sum of all ExternalTriggeringPoints for triggers instantiated in PortPrototypes which are connected to each other inclusive the belonging triggered runnable. |
| Mode Communication Graph | The sum of all ModeAccessPoints and ModeSwitchPoints to ModeDeclarationGroupPrototypes instantiated in PortPrototypes which are connected to each other, or the sum of all managedModeGroups and accessedModeGroups to ModeDeclarationGroupPrototypes in BswModuleDescriptions connected to each other. |
| copy semantic | Copy semantic means, that the accessing entities are able to read or write the "copied" data from their execution context in a non concurrent and non preempting manner. If all accessing entities are in the same preemption area this might not require a real physical data copy. |
| core local mode user group | In the case that mode users belong to different partitions which in turn are scheduled on different micro controller cores the overall mode machine instance needs to be distributed cross core. Thereby some restrictions are only applicable between the mode users executed on the same micro controller core. All mode users of the same mode manager which belong to EcucPartition which in turn belong to OsApplications referring to the same EcucCoreDefinition are belonging to the same core local mode user group. |
| data semantic | When data is distributed, the last received value is of interest (last-is-best semantics). Therefore the software implementation policy, stated in the swImplPolicy attribute of the SwDataDefProps, shouldn’t be ’queued’. |
| event semantic | When events are distributed the whole history of received events is of interest, hence they must be queued on receiver side. Therefore the software implementation policy, stated in the swImplPolicy attribute of the SwDataDefProps, will have the value ’queued’(corresponding to event distribution with a queue). |
| execution-instance | An execution-instance of an ExecutableEntity is one instance or call context of an ExecutableEntity with respect to concurrent execution, see section 4.2.3. |
| hard error runnable | A Runnable Entity that is triggered by at least by one TransformerHardErrorEvent. |
| implicit read access | VariableAccess aggregated in the role dataReadAccess to a VariableDataPrototype |
| implicit write access | VariableAccess aggregated in the role dataWriteAccess to a VariableDataPrototype |
| incoherent implicit data access | An implicit read access or an implicit write access which does not belong to a coherency group. Therefore it is NOT referenced by any RteVariableReadAccessRef or RteVariableWriteAccessRef belonging to a RteImplicitCommunication container which RteCoherentAccess parameter is set to true. |
| incoherent implicit read access | An implicit read access which does not belong to a coherency group. Therefore it is NOT referenced by any RteVariableReadAccessRef belonging to a RteImplicitCommunication container which RteCoherentAccess parameter is set to true. |
| incoherent implicit write access | An implicit write access which does not belong to a coherency group. Therefore it is NOT referenced by any RteVariableWriteAccessRef belonging to a RteImplicitCommunication container which RteCoherentAccess parameter is set to true. |
| inter-ECU communication | The communication between ECUs, typically using COM is called inter-ECU communication in this document. |
| inter-partition communication | The communication within one ECU but between different partitions, represented by different OS applications, is called inter- -partition communication in this document. It may involve the use of OS mechanisms like IOC or trusted function calls. The partitions can be located on different cores or use different memory sections of the ECU. |
| intra-ECU communication | The communication within one ECU is called intra-ECU communication in this document. It is a super set of inter-partition communication and intra-partition communication. |
| intra-partition communication | The communication within one partition of one ECU is called intra-partition communication. In this case, RTE can make use of internal buffers and queues for communication. |
| invalidateable | Invalidateable VariableDataPrototypes are VariableDataPrototypes that have an invalidValue. |
| ISR body | The definition of the task function using the macro ISR. |
| ISR2 | An interrupt service routine of category 2. |
| LinkTime variability | Variability defined with an VariationPoint or AttributeValueVariationPoint with latest bindingTime LinkTime. |
| mode disabling | When a ‘mode disabling’ is active, RTE and Basic Software Scheduler disables the activation of mode disabling dependent ExecutableEntitys. The ‘mode disabling’ is active during the mode that is referenced in the mode disabling dependency and during the transitions that enter and leave this mode. See also section 4.4.1. |
| mode disabling dependency | A RTEEvent (respectively a BswEvent) that starts a RunnableEntity (respectively a BswSchedulableEntity) can contain a disabledMode (respectively disabledInMode) association which references a ModeDeclaration. This association is called mode disabling dependency in this document. |
| mode disabling dependent ExecutableEntity | A mode disabling dependent RunnableEntity or a BswSchedulableEntity is triggered by an RTEEvent respectively a BswEvent with a mode disabling dependency. RTE and Basic Software Scheduler prevent the activation of those RunnableEntity or BswSchedulableEntity by the RTEEvent / BswEvent, when the corresponding mode disabling is active. See also section 4.4.1. |
| mode machine instance | The instances of mode machines or ModeDeclarationGroups are defined by the ModeDeclarationGroupPrototypes of the mode managers. Since a mode switch is not executed instantaneously, The RTE or Basic Software Scheduler has to maintain it’s own states. For each mode manager’s ModeDeclarationGroupPrototype, RTE or Basic Software Scheduler has one state machine. This state machine is called mode machine instance. For all mode users of the same mode manager’s ModeDeclarationGroupPrototype, RTE and Basic Software Scheduler uses the same mode machine instance. See also section 4.4.2. |
| mode manager | Entering and leaving modes is initiated by a mode manager. A mode manager is either a software component that provides a p-port typed by a ModeSwitchInterface or a BSW module which defines in its BswModuleDescription a ModeDeclarationGroupPrototype in the role providedModeGroup. See also section 4.4.2. |
| ModeSwitchAck ExecutableEntity | A RunnableEntity or a BswSchedulableEntity that is triggered by a ModeSwitchedAckEvent respectively a BswModeSwitchedAckEvent connected to the mode manager’s ModeDeclarationGroupPrototype. It is called ModeSwitchAck ExecutableEntity. See also section 4.4.1. |
| mode switch notification | The communication of a mode switch from the mode manager to the mode user using either the ModeSwitchInterface or providedModeGroup and requiredModeGroup ModeDeclarationGroupPrototypes is called mode switch notification. |
| mode switch port | The port for receiving (or sending) a mode switch notification. For this purpose, a mode switch port is typed by a ModeSwitchInterface. |
| mode user | An AUTOSAR SW-C or AUTOSAR Basic Software Module that depends on modes is called a mode user. The dependency can occur through a SwcModeSwitchEvent/BswModeSwitchEvent, a ModeAccessPoint for a provided/required mode switch port, or a accessedModeGroup for a providedModeGroup/requiredModeGroup ModeDeclarationGroupPrototype. See also section 4.4.1. |
| NvBlockSwComponent | NvBlockSwComponent is a SwComponentPrototype typed an NvBlockSwComponentType. |
| on-entry ExecutableEntity | A RunnableEntity or a BswSchedulableEntity that is triggered by a SwcModeSwitchEvent respectively a BswModeSwitchEvent with ModeActivationKind ‘entry’ is triggered on entering the mode. It is called on-entry ExecutableEntity. See also section 4.4.1. |
| on-exit ExecutableEntity | A RunnableEntity or a BswSchedulableEntity that is triggered by a SwcModeSwitchEvent respectively a BswModeSwitchEvent with ModeActivationKind ‘exit’ is triggered on exiting the mode. It is called on-exit ExecutableEntity. See also section 4.4.1. |
| on-transition ExecutableEntity | A RunnableEntity or a BswSchedulableEntity that is triggered by a SwcModeSwitchEvent respectively a BswModeSwitchEvent with ModeActivationKind ‘transition’ is triggered on a transition between the two specified modes. It is called ontransition ExecutableEntity. See also section 4.4.1. |
| post-build variability | Variability defined with an VariationPoint having an postBuildVariantCriterion |
| pre-build variability | Variability defined with an VariationPoint or AttributeValueVariationPoint with latest bindingTime SystemDesignTime, CodeGenerationTime, PreCompileTime or LinkTime. |
| PreCompileTime variability | Variability defined with an VariationPoint or AttributeValueVariationPoint with latest bindingTime PreCompileTime. preemption area A preemption area defines a set of tasks which are scheduled cooperatively. Therefore tasks of one preemption area are preempting each other only at dedicated schedule points. A schedule point is not allowed to occur during the execution of a RunnableEntity. |
| primitive data type | Primitive data types are the types implemented by a boolean, integer (up to 32 bits), floating point, or opaque type (up to 32 bits). |
| RIPS FlatInstanceDescriptor | FlatInstanceDescriptor with rtePluginProps referencing a Communication Graph. |
| RP enabler flag | A Boolean flag to permit run-time enabling/disabling bypass. |
| RP event id | Identifier for bypassed event; passed as parameter to RP service function. |
| RP global buffer | A buffer read/written by RP. The RP global buffer is conceptually separated from the RTE managed buffer holding the variable data prototype value. |
| RP global measurement buffer | A buffer used by RP to store the original variable data prototype value for subsequent measurement purposes before replacement by the RP generated value. |
| RP runnable disabler flag | A Boolean flag to permit conditional RunnableEntity execution. When conditional execution is configured the runnable is executed if the flag is FALSE. |
| RP service component | An AUTOSAR or vendor specific BSW module providing an RP service, e.g. “XCP on CAN” or “XCP on Ethernet”. |
| RP service profile | A definition of a service combining the symbol of the function providing the service and the permitted range of RP service point ids. |
| RP service function | An invocation of a function provided by a RP service component where data is sampled and/or stimulated. |
| RP service point | A location where one or more RP service functions provided by a RP service component are invoked. |
| RP service point id | Integer identifier for RP service point. |
| RP service invocation wrapper | A “wrapper” function created by the RTE that is responsible for invoking the RP RP service function(s). The indirection thus introduced enables a post-build tool to replace the invocation of the RTE generated function with arbitrary functionality. |
| RP stimulation enabler flag | A Boolean flag to permit conditional RP stimulation. |
| RTE event identifier | Integer identifier used by RP to identify RTE event associated with an RP service point. |
| Applicative Software Cluster | The Software Cluster which mainly contains software components and only selected BSW modules (e.g. a Service module, transformers, etc.) |
| Host Software Cluster | The Software Cluster which contains major part of the BSW and especially the micro controller dependent lower layer BSW Modules, e.g. OS and MCAL. |
| RTE Implementation Plug-In | A RTE Implementation Plug-In is a part of the overall RTE implementation which is not provided by the RTE Generator but from an additional source (e.g. a Plug-In Generator or a manually implemented source code). |
| RTE Implementation Plug-In Service | A RTE Implementation Plug-In Service is a single entry point into the RTE Implementation Plug-In implementing a low level service for the RTE. For instance access to a specific buffer. |
| Local Software Cluster Communication Plug-In | A Local Software Cluster Communication Plug-In is an RTE Implementation Plug-In which handles the communication locally inside a Software Cluster. This includes the Transformer handling if a DataMapping exist for the according Communication Graph |
| Cross Software Cluster Communication Plug-In | A Cross Software Cluster Communication Plug-In is an RTE Implementation Plug-In which handles the communication towards other Software Cluster. This includes the Transformer handling if intra ECU transformation is configured. |
| RIPS | The acronym RIPS stands for RTE Implementation Plug- -In Service and the related API infix Rips is derived from this. |
| RIPS FlatInstanceDescriptor | A FlatInstanceDescriptor which assigns the communication graph with an RTE Implementation Plug-In |
| runnable activation | The activation of a runnable is linked to the RTEEvent that leads to the execution of the runnable. It is defined as the incident that is referred to by the RTEEvent. E. g., for a timing event, the corresponding runnable is activated, when the timer expires, and for a data received event, the runnable is activated when the data is received by the RTE. |
| runnable start | A runnable is started by the calling the C-function that implements the runnable from within a started task/ISR2. |
| server | A server is defined as one RunnableEntity which is the target of an OperationInvokedEvent. Call serialization is on activation of RunnableEntity. |
| server ExecutableEntity | A server that is triggered either by an OperationInvokedEvent or by an BswOperationInvokedEvent. In certain situations, RTE can implement the client server communication as a simple function call. |
| server runnable | A server that is triggered by an OperationInvokedEvent. It has a mixed behavior between a runnable and a function call. In certain situations, RTE can implement the client server communication as a simple function call. |
| SystemDesignTime variability | Variability defined with an VariationPoint or AttributeValueVariationPoint with latest bindingTime SystemDesignTime. |
| Task body | The definition of the task function using the macro TASK. |
| trigger emitter | A trigger emitter has the ability to release triggers which in turn are activating triggered ExecutableEntitys. trigger emitter are described by the meta model with provide trigger ports, Trigger in role releasedTrigger, InternalTriggeringPoints and BswInternalTriggeringPoints. trigger port A PortPrototype which is typed by an TriggerInterface |
| trigger sink | A trigger sink relies on the activation of Runnable Entities or Basic Software Schedulable Entities if a particular Trigger is raised. A trigger sink has a dedicated require trigger port(s) or / and requiredTrigger Trigger(s) to communicate to the trigger source(s). |
| trigger source | A trigger source administrate the particular Trigger and informs the RTE or Basic Software Scheduler if the Trigger is raised. A trigger source has dedicated provide trigger port(s) or / and releasedTrigger Trigger(s) to communicate to the trigger sink(s). |
| triggered BswSchedulableEntity | A BswSchedulableEntity that is triggered at least by one BswExternalTriggerOccurredEvent or BswInternalTriggerOccurredEvent. In particular cases, the Trigger Event Communication or the Inter Basic Software Schedulable Entity Triggering is implemented by Basic Software Scheduler as a direct or trusted function call of the triggered ExecutableEntity by the triggering ExecutableEntity. |
| triggered ExecutableEntity | A Runnable Entity or a Basic Software Schedulable Entity that is triggered at least by one ExternalTriggerOccurredEvent / BswExternalTriggerOccurredEvent or InternalTriggerOccurredEvent / BswInternalTriggerOccurredEvent. In particular cases, the Trigger Event Communication or the Inter Runnable Triggering is implemented by RTE or Basic Software Scheduler as a direct or trusted function call of the triggered ExecutableEntity by the triggering ExecutableEntity. |
| triggered runnable | A Runnable Entity that is triggered at least by one ExternalTriggerOccurredEvent or InternalTriggerOccurredEvent. In particular cases, the Trigger Event Communication or the Inter Runnable Triggering is implemented by RTE as a direct or trusted function call of the triggered runnable by the triggering runnable. |
| unconnected port | An unconnected port is a RPortPrototype or PPortPrototype referenced by no AssemblySwConnectors and/or DelegationSwConnectors, or with at least no DataMapping of any of the elements in the port interface. Hint: PRPortPrototypes are always treated as connected ports. (See [SWS_Rte_06030]) |
| direct function call | A direct function call is a function call that is not performed via other means than pure RTE code. Typically, this is a C function call in an OsTask, OsIsr or RTE API (see 5.6). |
| trusted function call | A trusted function call is a function call that is performed via the CallTrustedFunction() API of the OS. This is usually necessary to achieve a direct function call like behavior when crossing partition boundaries. |
英日
日本語は仮訳
T.B.D.
参考(reference)
[1] Virtual Functional Bus
AUTOSAR_EXP_VFB
[2] Software Component Template
AUTOSAR_TPS_SoftwareComponentTemplate
[3] Specification of Communication
AUTOSAR_SWS_COM
[4] Specification of Operating System
AUTOSAR_SWS_OS
[5] Specification of ECU Configuration
AUTOSAR_TPS_ECUConfiguration
[6] Methodology for Classic Platform
AUTOSAR_TR_Methodology
[7] Specification of ECU State Manager
AUTOSAR_SWS_ECUStateManager
[8] System Template
AUTOSAR_TPS_SystemTemplate
[9] Basic Software Module Description Template
AUTOSAR_TPS_BSWModuleDescriptionTemplate
[10] Generic Structure Template
AUTOSAR_TPS_GenericStructureTemplate
[11] Glossary, AUTOSAR_TR_Glossary
https://www.autosar.org/fileadmin/standards/foundation/21-11/AUTOSAR_TR_Glossary.pdf
[12] General Requirements on Basic Software Modules
AUTOSAR_SRS_BSWGeneral
[13] Requirements on Runtime Environment
AUTOSAR_SRS_RTE
[14] Specification of Timing Extensions
AUTOSAR_TPS_TimingExtensions
[15] Layered Software Architecture
AUTOSAR_EXP_LayeredSoftwareArchitecture
[16] Specification of ECU Resource Template
AUTOSAR_TPS_ECUResourceTemplate
[17] Specification of Large Data COM
AUTOSAR_SWS_LargeDataCOM
[18] Specification of I/O Hardware Abstraction
AUTOSAR_SWS_IOHardwareAbstraction
[19] Requirements on Operating System
AUTOSAR_SRS_OS
[20] Requirements on Communication
AUTOSAR_SRS_COM
[21] ASAM MCD 2MC ASAP2 Interface Specification
http://www.asam.net ASAP2-V1.51.pdf
[22] Specification of NVRAM Manager
AUTOSAR_SWS_NVRAMManager
[23] Collection of blueprints for AUTOSAR M1 models
AUTOSAR_MOD_GeneralBlueprints
[24] Specification of COM Based Transformer
AUTOSAR_SWS_COMBasedTransformer
[25] Guide to BSW Distribution
AUTOSAR_EXP_BSWDistributionGuide
[26] Specification of Default Error Tracer
AUTOSAR_SWS_DefaultErrorTracer
[27] General Specification of Transformers
AUTOSAR_ASWS_TransformerGeneral
[28] Guidelines for the use of the C language in critical systems, ISBN 978-1-906400-10-1 MISRA_C_2012.pdf
[29] Specification of Memory Mapping
AUTOSAR_SWS_MemoryMapping
[30] General Specification of Basic Software Modules
AUTOSAR_SWS_BSWGeneral
[31] Specification of Compiler Abstraction
AUTOSAR_SWS_CompilerAbstraction
[32] Specification of Standard Types
AUTOSAR_SWS_StandardTypes
[33] Specification of Bit Handling Routines
AUTOSAR_SWS_BFXLibrary
[34] Specification of Software Cluster Connection module
AUTOSAR_SWS_SoftwareClusterConnection
[35] Collection of constraints on AUTOSAR M1 models
AUTOSAR_TR_AutosarModelConstraints