Implicit base class of all classes in metamodel. checksum calculated from the * attributes * aggregations and aggregated non-identifiables * references xml.attribute="true";xml.name="S" the timestamp of the creation or modification of an instance, its attributes, references or aggregated non-identifiables. xml.attribute="true";xml.name="T" AUTOSAR package, allowing to create top level packages to structure the contained ARElements. ARPackages are open sets, which means that in a file based description system, multiple files can be used to partially describe the contents of a package. This is an extended version of MSR's SW-SYSTEM. AUTOSAR package, allowing to create top level packages to structure the contained ARElements. ARPackages are open sets, which means that in a file based description system, multiple files can be used to partially describe the contents of a package. This is an extended version of MSR's SW-SYSTEM. Root element of an AUTOSAR description, also the root element in corresponding XML documents. admin.documentClassification="Auxiliary";admin.documentIdentificationNo="059";admin.documentOwner="AUTOSAR GbR";admin.documentResponsibility="AUTOSAR GbR";admin.documentStatus="Final";admin.documentTitle="Metamodel";admin.documentVersion="3.0.1";admin.partOfRelease="3.0";admin.revision="0002";xml.globalElement="true" Root element of an AUTOSAR description, also the root element in corresponding XML documents. admin.documentClassification="Auxiliary";admin.documentIdentificationNo="059";admin.documentOwner="AUTOSAR GbR";admin.documentResponsibility="AUTOSAR GbR";admin.documentStatus="Final";admin.documentTitle="Metamodel";admin.documentVersion="3.0.1";admin.partOfRelease="3.0";admin.revision="0002";xml.globalElement="true" Root element of an AUTOSAR description, also the root element in corresponding XML documents. admin.documentClassification="Auxiliary";admin.documentIdentificationNo="059";admin.documentOwner="AUTOSAR GbR";admin.documentResponsibility="AUTOSAR GbR";admin.documentStatus="Final";admin.documentTitle="Metamodel";admin.documentVersion="3.0.1";admin.partOfRelease="3.0";admin.revision="0002";xml.globalElement="true" Instances of this class can be referred to by their identifier (while adhering to namespace borders). Use <shortName> to generate a short name for the context element, which enables it to be ** . xml.enforceMinMultiplicity="true";xml.sequenceOffset="-100" This element assigns a category to the parent element. The category can be used by a semantic checker in post-processes to ensure that the parent object is defined correctly i.e. has the right number of elements for example. xml.sequenceOffset="-50" Instances of this class can be referred to by their identifier (while adhering to namespace borders). The purpose of this attribute is to provide a globally unique identifier for an instance of a metaclass. The values of this attribute should be globally unique strings prefixed by the type of identifier. For example, to include a DCE UUID as defined by The Open Group, the UUID would be preceded by "DCE:". The values of this attribute may be used to support merging of different AUTOSAR models. The form of the UUID (Universally Unique Identifier) is taken from a standard defined by the Open Group (was Open Software Foundation). This standard is widely used, including by Microsoft for COM (GUIDs) and by many companies for DCE, which is based on CORBA. The method for generating these 128-bit IDs is published in the standard and the effectiveness and uniqueness of the IDs is not in practice disputed. If the id namespace is omitted, DCE is assumed. An example is "DCE:2fac1234-31f8-11b4-a222-08002b34c003". xml.attribute="true" This class is a "Special Data" element. By using this element it is possible to extend the model with arbirtrary information. In this case the "role" is specified using gid. asam.harmonizedObject="SD";msr.id="type__SD_TYPE";msr.isGroupOnly="true" This attributes specifies an identifier. Gid comes from the SGML-Term "Generic Identifier" which is the element name in XML. The role of this attribute is the same as the name of an XML - element. msr.id="SD_TYPE__SD_TYPE__GID";xml.attribute="true" This class is a "Special Data" element. By using this element it is possible to extend the model with arbirtrary information. In this case the "role" is specified using gid. asam.harmonizedObject="SD";msr.id="type__SD_TYPE";msr.isGroupOnly="true" Sdg is a generic model which can be used to keep arbitrary information which is not explicitly modeled in the metamodel. Sdg can have various contets as defined by sdgContentsType. Special Data should only be used moderately since all elements should be defined in the metamodel. Thereby SDG should be considered as a temporary solution when no explicit model is available. If an sdgCaption is available, it is possible to establish a reference to the sdg structure. asam.harmonizedObject="ASAM-SDG";msr.id="type__SDG_TYPE" Sdg is a generic model which can be used to keep arbitrary information which is not explicitly modeled in the metamodel. Sdg can have various contets as defined by sdgContentsType. Special Data should only be used moderately since all elements should be defined in the metamodel. Thereby SDG should be considered as a temporary solution when no explicit model is available. If an sdgCaption is available, it is possible to establish a reference to the sdg structure. asam.harmonizedObject="ASAM-SDG";msr.id="type__SDG_TYPE" This attributes specifies an identifier. Gid comes from the SGML-Term "Generic Identifier" which is the element name in XML. The role of this attribute is the same as the name of an XML - element. msr.id="SDG_TYPE__SDG_TYPE__GID";xml.attribute="true" Sdg is a generic model which can be used to keep arbitrary information which is not explicitly modeled in the metamodel. Sdg can have various contets as defined by sdgContentsType. Special Data should only be used moderately since all elements should be defined in the metamodel. Thereby SDG should be considered as a temporary solution when no explicit model is available. If an sdgCaption is available, it is possible to establish a reference to the sdg structure. asam.harmonizedObject="ASAM-SDG";msr.id="type__SDG_TYPE" This is a class which allows to refer to any identifiable object. It could be modeled as an association to Identifiable. But for compatibility reasons to ASAM it is left as it is. This attributes specifies an identifier. Gid comes from the SGML-Term "Generic Identifier" which is the element name in XML. The role of this attribute is the same as the name of an XML - element. msr.id="SDG_TYPE__SDG_TYPE__GID";xml.attribute="true" This specifies the class of the referenced object. msr.id="SD_TYPE__SD_TYPE__ID-CLASS";xml.attribute="true" This is a class which allows to refer to any identifiable object. It could be modeled as an association to Identifiable. But for compatibility reasons to ASAM it is left as it is. MultiLanguageParagraph This is the content model of a multilinugal paragraph in a documentation. msr.id="type__ml-data-1" MultiLanguageParagraph This is the content model of a multilinugal paragraph in a documentation. msr.id="type__ml-data-1" MultiLanguagePlainText msr.id="type__ml-data-10" MultiLanguageOverviewParagraph This is the content of a multilingual paragraph in an overview item. msr.id="type__ml-data-2" MultiLanguageUnitNames msr.id="type__ml-data-3" MultiLanguageUnitNameVerbatim msr.id="type__ml-data-3p" MultiLanguageUnitNameVerbatim msr.id="type__ml-data-3p" MultilanguageLongName msr.id="type__ml-data-4" MultiLanguageVerbatim msr.id="type__ml-data-5" MultiLanguageVerbatim msr.id="type__ml-data-5" ParagraphInOneParticularLanguage This is the text for a paragraph in one particular language. The language is denoted in the attribute l. msr.id="type__L-1_TYPE";msr.isGroupOnly="true" ParagraphInOneParticularLanguage This is the text for a paragraph in one particular language. The language is denoted in the attribute l. msr.id="type__L-1_TYPE";msr.isGroupOnly="true" MixedContentForPlainText in one particular language. The language is dentoted in the attribute l. msr.id="type__L-10_TYPE";msr.isGroupOnly="true" MixedContentForPlainText in one particular language. The language is dentoted in the attribute l. msr.id="type__L-10_TYPE";msr.isGroupOnly="true" MixedContentForOverviewParagraph in one particular language. The language is dentoted in the attribute l. msr.id="type__L-2_TYPE";msr.isGroupOnly="true" MixedContentForOverviewParagraph in one particular language. The language is dentoted in the attribute l. msr.id="type__L-2_TYPE";msr.isGroupOnly="true" MixedContentForUnitNames in one particular language. The language is dentoted in the attribute l. msr.id="type__L-3_TYPE";msr.isGroupOnly="true" MixedContentForUnitNames in one particular language. The language is dentoted in the attribute l. msr.id="type__L-3_TYPE";msr.isGroupOnly="true" MixedContentForLongNames in one particular language. The language is dentoted in the attribute l. msr.id="type__L-4_TYPE";msr.isGroupOnly="true" MixedContentForLongNames in one particular language. The language is dentoted in the attribute l. msr.id="type__L-4_TYPE";msr.isGroupOnly="true" MixedContentForVerbatim in one particular language. The language is dentoted in the attribute l. msr.id="type__L-5_TYPE";msr.isGroupOnly="true" MixedContentForVerbatim in one particular language. The language is dentoted in the attribute l. msr.id="type__L-5_TYPE";msr.isGroupOnly="true" MultilanguageDataModelForPlainText msr.id="type__ml-data-model-10";msr.isMaster="true" MultilanguageDataModelForOverviewParagraph msr.id="type__ml-data-model-2";msr.isMaster="true" MultilanguageDataModelForUnitNames msr.id="type__ml-data-model-3";msr.isMaster="true" MultilanguageDataModelForLongNames msr.id="type__ml-data-model-4";msr.isMaster="true" MultilanguageDataModelForVerbatim msr.id="type__ml-data-model-5";msr.isMaster="true" MultilanguageDataModelForParagraph msr.id="type__ml-data-model-1";msr.isMaster="true" This element is the same as function here as in a HTML document i.e. it forces a line break. msr.id="type__BR_TYPE" This is an emphasized text. As a compromise it contains some rendering oriented attributes such as color and font. msr.id="type__E_TYPE";msr.isGroupOnly="true" Use <ft> , to create a footnote. msr.id="type__FT_TYPE";msr.isGroupOnly="true" Use <ie> to create an index that is to appear in the index directory. msr.id="type__IE_TYPE";msr.isGroupOnly="true" Use <std> to reference external standards within a paragraph element. msr.id="type__STD_TYPE" Use <tt> to format technical terms within the paragraph element. msr.id="type__TT_TYPE";msr.isGroupOnly="true" This element specifies the Uniform Resource Locator (URL) of the context contained in the <url> element. asam.harmonizedObject="URL";msr.id="type__URL_TYPE";msr.isGroupOnly="true" This is the url itself xml.roleElement="false";xml.roleWrapperElement="false";xml.typeElement="false";xml.typeWrapperElement="false" This element specifies the Uniform Resource Locator (URL) of the context contained in the <url> element. asam.harmonizedObject="URL";msr.id="type__URL_TYPE";msr.isGroupOnly="true" this denotes the mime type of the resource located by the url. msr.id="URL_TYPE__URL_TYPE__MIME-TYPE";xml.attribute="true" This element specifies the Uniform Resource Locator (URL) of the context contained in the <url> element. asam.harmonizedObject="URL";msr.id="type__URL_TYPE";msr.isGroupOnly="true" Use <xdoc> , to reference an external document. asam.harmonizedObject="XDOC";msr.id="type__XDOC_TYPE" Use <xfile> , to reference an external file. msr.id="type__XFILE_TYPE" This element describes the tool which was used to generate the corresponding <xfile> . Kept as a string. msr.id="XFILE_TYPE__TOOL";msr.tbdString="true";xml.sequenceOffset="50" This element describes the tool version which was used to generate the corresponding <xfile> . Kept as a string. msr.id="XFILE_TYPE__TOOL-VERSION";msr.tbdString="true";xml.sequenceOffset="60" Use <xfile> , to reference an external file. msr.id="type__XFILE_TYPE" Use <xref> , to generate cross-references within the document. msr.id="type__XREF_TYPE";msr.isGroupOnly="true" This element specifies a reference target which can be scattered throughout the text. msr.id="type__XREF-TARGET_TYPE" SingleLanguageParagraph This is the content model of a single language paragraph in a documentation. msr.id="type__sl-data-1";msr.isGroupOnly="true" SingleLanguagePlainText msr.id="type__sl-data-10";msr.isGroupOnly="true" SingleLanguageOverviewParagraph This is the model for a single language paragraph in an overview item. msr.id="type__sl-data-2";msr.isGroupOnly="true" SingleLanguageUnitName msr.id="type__sl-data-3";msr.isGroupOnly="true" SingleLanguageUnitNameVerbatim msr.id="type__sl-data-3p";msr.isGroupOnly="true" SingleLanguageUnitNameVerbatim msr.id="type__sl-data-3p";msr.isGroupOnly="true" SingleLanguageLongName msr.id="type__sl-data-4";msr.isGroupOnly="true" SingleLanguageVerbatim msr.id="type__sl-data-5";msr.isGroupOnly="true" SingleLanguageVerbatim msr.id="type__sl-data-5";msr.isGroupOnly="true" This class represents textual comments (called annotations) which relate to the object in which it is aggregated. These are intended for use during the development process, to transfer information from one stage of the development process to the next one. The approach is similar to the "yellow pads ..." This abstract class can be specialized in order to add some further formal properties. This element identifies the origin of the annotation. It is an arbitrary string since it can be an individual's name as well as the name of a tool or even the name of a process step. msr.id="ANNOTATION_TYPE__ANNOTATION-ORIGIN";msr.tbdString="true";xml.sequenceOffset="30" <remark> is used for comments e.g. on the specific calibration state. The remark can be a regular paragraph or a preformatted text. msr.id="type__REMARK_TYPE";msr.isGroupOnly="true" <remark> is used for comments e.g. on the specific calibration state. The remark can be a regular paragraph or a preformatted text. msr.id="type__REMARK_TYPE";msr.isGroupOnly="true" This is a plain annotation which does not have further formal data. msr.id="type__ANNOTATION_TYPE" <adminData> can be used to set administrative information for an element. This administration information is to be treated as metadata such as revision id or state of the file. There are basically four kinds of metadata * The language and/or used laguages. * Revision information covering e.g. revision number, state, release date, changes. Note that this information can be given in general as well as related to a particular company. * Document metadata specific for a company * Formatting controls that can affect layouts for example. * Revision information for the element. asam.harmonizedObject="ASAM-ADMIN-DATA";msr.id="type__ADMIN-DATA_TYPE" This attribute specifies the master language of the document or the document fragment. The master language is the one in which the document is maintained and from which the other languages are derived from. msr.id="ADMIN-DATA_TYPE__LANGUAGE";msr.tbdString="true";xml.sequenceOffset="20" <adminData> can be used to set administrative information for an element. This administration information is to be treated as metadata such as revision id or state of the file. There are basically four kinds of metadata * The language and/or used laguages. * Revision information covering e.g. revision number, state, release date, changes. Note that this information can be given in general as well as related to a particular company. * Document metadata specific for a company * Formatting controls that can affect layouts for example. * Revision information for the element. asam.harmonizedObject="ASAM-ADMIN-DATA";msr.id="type__ADMIN-DATA_TYPE" Use <docRevision> , to generate information on the corresponding document version. asam.harmonizedObject="DOC-REVISION";msr.id="type__DOC-REVISION_TYPE";xml.sequence.offset="20" Use revisionLabel, to enter the version number of the document, or the document section to which administrative is applied.. The syntax is free and refers to the configuration management plan respectively the version management tool being used. Therefore it is still kept as String. msr.id="DOC-REVISION_TYPE__REVISION-LABEL";xml.sequenceOffset="20" Use revisionLabelP1, to enter the version number of the ** of the document, or the document section to which administrative is applied.. The syntax is free and refers to the configuration management plan respectively the version management tool being used. This element is used, if the document or document section is the result of a merge process in which two branches are merged in to one new revision. msr.id="DOC-REVISION_TYPE__REVISION-LABEL-P1";msr.tbdString="true";xml.sequenceOffset="30" Use revisionLabelP1, to enter the version number of the ** of the document, or the document section to which administrative is applied.. The syntax is free and refers to the configuration management plan respectively the version management tool being used. This element is used, if the document or document section is the result of a merge process in which two branches are merged in to one new revision. msr.id="DOC-REVISION_TYPE__REVISION-LABEL-P2";msr.tbdString="true";xml.sequenceOffset="40" This specifies the time, when the object in question was released msr.id="DOC-REVISION_TYPE__DATE";xml.sequenceOffset="80" Use <docRevision> , to generate information on the corresponding document version. asam.harmonizedObject="DOC-REVISION";msr.id="type__DOC-REVISION_TYPE";xml.sequence.offset="20" Use <modification> to record what has changed in a document in comparison to its predecessor. asam.harmonizedObject="MODIFICATION";msr.id="type__MODIFICATION_TYPE" Use <modification> to record what has changed in a document in comparison to its predecessor. asam.harmonizedObject="MODIFICATION";msr.id="type__MODIFICATION_TYPE" Use <companyRevisionInfo> , to generate information on document version within the respective company. asam.harmonizedObject="COMPANY-REVISION-INFO";msr.id="type__COMPANY-REVISION-INFO_TYPE";xml.sequenceOffset="30" No filtering is performed so that the message always passes. Pass messages where the masked value has changed. (new_value&mask) !=(old_value&mask) new_value: current value of the message old_value: last value of the message (initialised with the initial value of the message, updated with new_value if the new message value is not filtered out) mask for old and new value Pass messages where the masked value has changed. (new_value&mask) !=(old_value&mask) new_value: current value of the message old_value: last value of the message (initialised with the initial value of the message, updated with new_value if the new message value is not filtered out) Pass messages whose masked value is not equal to a specific value x (new_value&mask) != x new_value: current value of the message mask for the new Value Value to compare with Pass messages whose masked value is not equal to a specific value x (new_value&mask) != x new_value: current value of the message Pass messages where the masked value has not changed. (new_value&mask) ==(old_value&mask) new_value: current value of the message old_value: last value of the message (initialised with the initial value of the message, updated with new_value if the new message value is not filtered out) mask for old and new value Pass messages where the masked value has not changed. (new_value&mask) ==(old_value&mask) new_value: current value of the message old_value: last value of the message (initialised with the initial value of the message, updated with new_value if the new message value is not filtered out) Pass messages whose masked value is equal to a specific value x (new_value&mask) == x new_value: current value of the message mask for the new Value Value to compare with Pass messages whose masked value is equal to a specific value x (new_value&mask) == x new_value: current value of the message The filter removes all messages. Pass messages which have changed. newValue != oldValue new_value: current value of the message old_value: last value of the message (initialised with the initial value of the message, updated with new_value if the new message value is not filtered out) Pass messages which have not changed. newValue == oldValue new_value: current value of the message old_value: last value of the message (initialised with the initial value of the message, updated with new_value if the new message value is not filtered out) Pass a message if its value has increased. new_value > old_value new_value: current value of the message old_value: last value of the message (initialised with the initial value of the message, updated with new_value if the new message value is not filtered out) Pass a message if its value has not decreased. new_value >= old_value new_value: current value of the message old_value: last value of the message (initialised with the initial value of the message, updated with new_value if the new message value is not filtered out) Pass a message if its value has decreased. new_value < old_value new_value: current value of the message old_value: last value of the message (initialised with the initial value of the message, updated with new_value if the new message value is not filtered out) Pass a message if its value has not increased. new_value <= old_value new_value: current value of the message old_value: last value of the message (initialised with the initial value of the message, updated with new_value if the new message value is not filtered out) Pass a message if its value is outside a predefined boundary. (min > new_value) OR (new_value > max) Value to specify the upper boundary Value to specify the lower boundary Pass a message if its value is outside a predefined boundary. (min > new_value) OR (new_value > max) Pass a message if its value is within a predefined boundary. min <= new_value <= max Value to specify the upper boundary Value to specify the lower boundary Pass a message if its value is within a predefined boundary. min <= new_value <= max Pass a message once every N message occurrences. Algorithm: occurrence % period == offset Start: occurrence = 0. Each time the message is received or transmitted, occurrence is incremented by 1 after filtering. Length of occurrence is 8 bit (minimum). specifies the initial number of messages to occur before the first message is passed specifies number of messages to occur before the message is passed again Pass a message once every N message occurrences. Algorithm: occurrence % period == offset Start: occurrence = 0. Each time the message is received or transmitted, occurrence is incremented by 1 after filtering. Length of occurrence is 8 bit (minimum). Prevents an executable entity running in the area from being preempted. Specifies the abstract needs on the configuration of the Communication Manager for one "user". Maximum communication mode requested by this ComM user Specifies the abstract needs on the configuration of the Communication Manager for one "user". This expresses the abstract needs that a Software Component or Basic Software Module has on the configuration of an AUTOSAR Service to which it will be connected. "Abstract needs" means, that the model abstracts from the Configuration Paramaters of the underlying Basic Software. Specifies the abstract needs on the configuration of the Diagnostic Communication Manager for one "user". Details are an expert task for AUTOSAR Release 4.0. Specifies the abstract needs on the configuration of the Diagnostic Event Manager for one diagnostic event. Its name can be regarded as a symbol identifying the diagnostic event from the viewpoint of the component or module which owns this class. Specifies the abstract needs on the configuration of the ECU State Manager for one "user". This class currently contains no attributes. Its name can be regarded as a symbol identifying the user from the viewpoint of the component or module which owns this class. Specifies the abstract needs on the configuration of the Function Inhibition Manager for one Function Identifier (FID). This class currently contains no attributes. Its name can be regarded as a symbol identifying the FID from the viewpoint of the component or module which owns this class. Specifies the abstract needs on the configuration of a single Nv block. number of data sets to be provided by the NVRAM manager for this block true: data of this block are write protected for normal operation (but protection can be disabled) false: no restriction Reliability against data loss on the non-volatile medium. Defines whether an Nv block shall be treated resistant to configuration changes (true) or not (false). For details how to handle initialization in the latter case, refer to the NVRAM specification. Defines whether the associated RAM mirror block shall be implictly restored during startup by the basic SW or not. Only relevant if a RAM mirror block (PerInstanceMemory) is associated with this port. Defines write protection after first write: true: This block is prevented from being changed/erased or being replaced with the default ROM data after first initialization by the SWC. false: No such restriction. Provides the amount of updates to this block from the application point of view. It has to be provided in "number of write access per year". Requires the priority of writing this block in case of concurrent requests to write other blocks. Specifies the abstract needs on the configuration of a single Nv block. Specifies the abstract needs on the configuration of the Watchdog Manager for one specific Supervised Entity (SE). true/false: supervision activation status of SE shall be enabled/disabled at start true: SWC shall be allowed to deactivate supervision of this SE false: not Expected cycle time of alive trigger of this SE (in seconds) Maximum cycle time of alive trigger of this SE (in seconds) Minimum cycle time of alive trigger of this SE (in seconds) Number of consecutive failed alive cycles for this SE which shall be tolerated until the supervision status of the SE is set to EXPIRED (see WdgM documentation for details). Note that this has to be recalculated w.r.t. the WdgMs own cycle time for ECU configuration. Specifies the abstract needs on the configuration of the Watchdog Manager for one specific Supervised Entity (SE). A generic code descriptor. The type of described code. A generic code descriptor. Specifies the compiler attributes. In case of source code this specifies requirements how the compiler shall be invoked. In case of object code this documents the used compiler settings. Compiler name (like gcc). Specifies the compiler options. Vendor of compiler. Exact version of compiler executable. Specifies the compiler attributes. In case of source code this specifies requirements how the compiler shall be invoked. In case of object code this documents the used compiler settings. General dependency, typically on the existence of another artifact. Specification during for which process step(s) this dependency is required. Dependency on the existence of a certain file. Dependency on the existence of a certain file. A specific file dependency: without the library that implementation cannot be used (compiled, linked, executed, ...). Maximum version compatible with implementation. If not set, there is limitation on the upper version. Minimum version compatible with implementation. A specific file dependency: without the library that implementation cannot be used (compiled, linked, executed, ...). Description of an implementation a single software component or module. Optional: code generator used. Programming language the implementation was created in. Major version number of this implementation. The numbering is vendor specific. Minor version number of this implementation. The numbering is vendor specific. Patch version number of this implementation. The numbering is vendor specific. Vendor ID of this Implementation according to the AUTOSAR vendor list Description of an implementation a single software component or module. Specifies the linker attributes used to decribe how the linker shall be invoked. Linker name. Specifies the linker options. Vendor of linker. Exact version of linker executable. Specifies the linker attributes used to decribe how the linker shall be invoked. Describes in which mode the hardware is operating while providing the ExecutionTime. Specifies additional information on the HardwareConfiguration. Specifies in which mode the processor is operating. Specifies the speed the processor is operating. Describes in which mode the hardware is operating while providing the ExecutionTime. Specifes the context the software is whose ExecutionTime is provided. Specifies the input vector which is used to provide the ExecutionTime. Specifies the state the software is in when the ExecutionTime is provided. Specifes the context the software is whose ExecutionTime is provided. Description of consumed resources by one implementation of a software. Description of consumed resources by one implementation of a software. The MemorySection provides descrition of the MemorySections used in the Implementation. The alignment (typically 1, 2, 4,...) This is the name of the section in the Implementation. Memory section type of the described MemorySection. The size in bytes of the section. The MemorySection provides descrition of the MemorySections used in the Implementation. The stack usage has been measured. The average stack usage measured. The maximum stack usage measured. The minimum stack usage measured. Description of the test pattern used to aquire the measured values. The stack usage has been measured. Describes the stack memory usage of a software. Rough estimation of the stack usage. Rough estimate of the stack usage. Rough estimation of the stack usage. Provides a formal worst case stack usage. Worst case stack consumption. Provides a formal worst case stack usage. Describes the heap memory usage of a SW-Component. The heap usage has been measured. The average heap usage measured. The maximum heap usage measured. The minimum heap usage measured. Description of the test pattern used to aquire the measured values. The heap usage has been measured. Rough estimation of the heap usage. Rough estimate of the heap usage. Rough estimation of the heap usage. Provides a formal worst case heap usage. Worst case heap consumption. Provides a formal worst case heap usage. Base class for several means how to describe the ExecutionTime of software. The required context information is provided through this class. Base class for several means how to describe the ExecutionTime of software. The required context information is provided through this class. Specifes in which hardware ProvidedMemorySegment the softwareMemorySection is located. Specifes in which hardware ProvidedMemorySegment the softwareMemorySection is located. Specifies the ExecutionTime which has been gathered using measurement means. Average MeasuredExecutionTime. Maximum MeasuredExecutionTime. Minumum MeasuredExecutionTime. Specifies the ExecutionTime which has been gathered using measurement means. Provides a description of a rough estimate on the ExecutionTime. Provides description on the rough estimate of the ExecutionTime. Provides a description of a rough estimate on the ExecutionTime. Specifies the ExecutionTime which has been gathered using simulation means. Average SimulatedExecutionTime. Maximum SimulatedExecutionTime. Minimum SimulatedExecutionTime. Specifies the ExecutionTime which has been gathered using simulation means. WorstCaseExecutionTime provides an analytic method for specifying the minimum and maximum execution time. Maximum WorstCaseExecutionTime. Minimum WorstCaseExecutionTime. WorstCaseExecutionTime provides an analytic method for specifying the minimum and maximum execution time. SwCodeSyntax objects fix the representation of data objects, e.g. variables and parameters, in the program source file. These code syntax objects are defined centrally in SwCodeSyntaxes and are connected to data objects by means of SwCodeSyntaxRef. The principle role of this element is the declaration of keywords (in the subelement ShortName) for the code generation procedure. The process itself is given a verbal description (in SwCodeSyntaxDesc) rather than a formal one. This approach was adopted as the number of possible code syntax schematics is relatively small. A complete formal description would create unnecessary work. msr.id="type__SW-CODE-SYNTAX_TYPE" Defines how the data objects (variables, calibration parameters etc.) are to be stored in the ECU memory. As an example, this definition specifies the sequence of axis points in the ECU memory. Iterations through axis values are stored within the subelements swRecordLayoutGroup . These subelements might be stored nested to support multidimensional data objects. asam.useCase="MDX";msr.id="type__SW-RECORD-LAYOUT_TYPE" Defines how the data objects (variables, calibration parameters etc.) are to be stored in the ECU memory. As an example, this definition specifies the sequence of axis points in the ECU memory. Iterations through axis values are stored within the subelements swRecordLayoutGroup . These subelements might be stored nested to support multidimensional data objects. asam.useCase="MDX";msr.id="type__SW-RECORD-LAYOUT_TYPE" Specifies how a record layout is set up. Using SwRecordLayoutGroup it recursively models iterations through axis values. The subelement swRecordLayoutGroupContentType may reference other SwRecordLayouts, SwRecordLayoutVs and SwRecordLayoutGroups for the modeled record layout. asam.useCase="MDX";msr.id="type__SW-RECORD-LAYOUT-GROUP_TYPE" The contents of this element specifies the axis number within a record layout group. msr.id="SW-RECORD-LAYOUT-GROUP_TYPE__SW-RECORD-LAYOUT-GROUP-AXIS";msr.tbdString="true";xml.sequenceOffset="30" This element attributes a symbolic name to the iterator of the superimposed record layout group. This can be referenced as a loop index beneath superimposed or subsequent SwRecordLayoutV elements. msr.id="SW-RECORD-LAYOUT-GROUP_TYPE__SW-RECORD-LAYOUT-GROUP-INDEX";msr.tbdString="true";xml.sequenceOffset="40" This element specifies the iterator index for the point in the axis from which a record layout group is commenced. Negative values are also possible, i.e. the value -4 counts from the fourth value from the end. msr.id="SW-RECORD-LAYOUT-GROUP_TYPE__SW-RECORD-LAYOUT-GROUP-FROM";msr.tbdString="true";xml.sequenceOffset="60" This element specifies the iterator index for a point in the axis up to which iteration for a record layout group takes place. Negative values are also possible, i.e. the value -4 counts up to the fourth value from the end. msr.id="SW-RECORD-LAYOUT-GROUP_TYPE__SW-RECORD-LAYOUT-GROUP-TO";msr.tbdString="true";xml.sequenceOffset="70" This element specifies the step width for the iterator index, which is used for a record layout group . msr.id="SW-RECORD-LAYOUT-GROUP_TYPE__SW-RECORD-LAYOUT-GROUP-STEP";msr.tbdString="true";xml.sequenceOffset="80" This element is used to denote the component to which the group in question applies. Thus, the record layout supports structured objects. This secures independence from the sequence of components, because they can be referred to via name. msr.id="SW-RECORD-LAYOUT-GROUP_TYPE__SW-RECORD-LAYOUT-COMPONENT";msr.tbdString="true";xml.sequenceOffset="90" Specifies how a record layout is set up. Using SwRecordLayoutGroup it recursively models iterations through axis values. The subelement swRecordLayoutGroupContentType may reference other SwRecordLayouts, SwRecordLayoutVs and SwRecordLayoutGroups for the modeled record layout. asam.useCase="MDX";msr.id="type__SW-RECORD-LAYOUT-GROUP_TYPE" This is the contents of a RecordLaoyut which is inserted for every iteration. Note that since this is atpMixed, multiple properties can be inserted for each iteration. asam.useCase="MDX";msr.id="special__SW-RECORD-LAYOUT-GROUP_content_TYPE";msr.isGroupOnly="true" This is the contents of a RecordLaoyut which is inserted for every iteration. Note that since this is atpMixed, multiple properties can be inserted for each iteration. asam.useCase="MDX";msr.id="special__SW-RECORD-LAYOUT-GROUP_content_TYPE";msr.isGroupOnly="true" This element specifies which values are stored for the current SwRecordLayoutGroup. If no baseType is present, the SwBaseType referenced initially in the father element SwRecordLayoutGroup is valid. The specification of swRecordLayoutVAxis gives the axis of the values to be stored in accordance with the current record layout SwRecordLayoutGroup. In swRecordLayoutVProp you are able to specify the type of values that are to be stored, e.g. number or value. Under swRecordLayoutVIndex, the symbolic values of the axes can be given, for which the value given under swRecordLayoutVProp is iterated. These symbolic values relate to the values given in swRecordLayoutGroupIndex. asam.useCase="MDX";msr.id="type__SW-RECORD-LAYOUT-V_TYPE" This attribute specifies the axis from which the value properties are used. msr.id="SW-RECORD-LAYOUT-V_TYPE__SW-RECORD-LAYOUT-V-AXIS";msr.tbdString="true";xml.sequenceOffset="40" The contents of this attribute describes the type of values to be stored in the record. msr.id="SW-RECORD-LAYOUT-V_TYPE__SW-RECORD-LAYOUT-V-PROP";msr.tbdString="true";xml.sequenceOffset="50" The symbolic value for iteration, or the symbolic values separated by white-spaces, refer to the symbolic values given in swRecordLayoutGroupIndex . The iterators are processed from left to right, in such a manner that they symbolize the loop index from the outside to the inside. An error has occurred if a parameter references a record layout which contains an swRecordLayoutVIndex with more components than the number of parameter axes. msr.id="SW-RECORD-LAYOUT-V_TYPE__SW-RECORD-LAYOUT-V-INDEX";msr.tbdString="true";xml.sequenceOffset="60" This attribute specifies the filler character for the current record layout, in the form of hex digits. The element present parallel to this in swRecordLayoutVProp must therefore have the contents FILL. msr.id="SW-RECORD-LAYOUT-V_TYPE__SW-RECORD-LAYOUT-V-FIX-VALUE";msr.tbdString="true";xml.sequenceOffset="80" This element specifies which values are stored for the current SwRecordLayoutGroup. If no baseType is present, the SwBaseType referenced initially in the father element SwRecordLayoutGroup is valid. The specification of swRecordLayoutVAxis gives the axis of the values to be stored in accordance with the current record layout SwRecordLayoutGroup. In swRecordLayoutVProp you are able to specify the type of values that are to be stored, e.g. number or value. Under swRecordLayoutVIndex, the symbolic values of the axes can be given, for which the value given under swRecordLayoutVProp is iterated. These symbolic values relate to the values given in swRecordLayoutGroupIndex. asam.useCase="MDX";msr.id="type__SW-RECORD-LAYOUT-V_TYPE" This element describes plausibility rules that go beyond the individual data object. E.g. the overrun shut-off engine speed must not be higher than the maximum engine speed. This plausibility rule is defined in exactly the same way as the contexts and dependencies of virtual characteristic variables and variables. msr.id="type__SW-RELATED-CONSTRS_TYPE" Describes how variables or parameters are addressed in the ECU. It contains a description of the addressing process and a reference to the concerned CPU memory segment. asam.useCase="MDX";msr.id="type__SW-ADDR-METHOD_TYPE" This is the absolute size of the basetype. In this case the BaseType is of fixed lenght. asam.useCase="MDX";msr.id="special__BASE-TYPE_absSize_TYPE" Describes the length of the data type specified in the container in bits. msr.id="BASE-TYPE_absSize_TYPE__BASE-TYPE-SIZE";msr.tbdString="true";xml.sequenceOffset="60" This is the absolute size of the basetype. In this case the BaseType is of fixed lenght. asam.useCase="MDX";msr.id="special__BASE-TYPE_absSize_TYPE" This BaseType is defined directly (as opposite to a derived BaseType) asam.useCase="MDX";msr.id="special__BASE-TYPE_directDefinition_TYPE" This specifies, how an object of the current BaseType is encode eg. in an ECU in a message sequence. msr.id="BASE-TYPE_directDefinition_TYPE__BASE-TYPE-ENCODING";msr.tbdString="true";xml.sequenceOffset="90" describes the alignment of the memory object in bits. E.g. "1" specifies, that the object in question is aligned to a byte while "32" specifies that it is aligned four byte. msr.id="BASE-TYPE_directDefinition_TYPE__MEM-ALIGNMENT";msr.tbdString="true";xml.sequenceOffset="100" This BaseType is defined directly (as opposite to a derived BaseType) asam.useCase="MDX";msr.id="special__BASE-TYPE_directDefinition_TYPE" This BaseType is defined by referring to anotherone. This indirect definition allows to create alias base types. asam.useCase="MDX";msr.id="special__BASE-TYPE_indirectDefinition_TYPE" This BaseType is defined by referring to anotherone. This indirect definition allows to create alias base types. asam.useCase="MDX";msr.id="special__BASE-TYPE_indirectDefinition_TYPE" This is the maximum size of a BaseType in case of a dynamic BaseType. asam.useCase="MDX";msr.id="special__BASE-TYPE_maxSize_TYPE" Describes the maximum length of the BaseType in bits msr.id="BASE-TYPE_maxSize_TYPE__MAX-BASE-TYPE-SIZE";msr.tbdString="true";xml.sequenceOffset="80" This is the maximum size of a BaseType in case of a dynamic BaseType. asam.useCase="MDX";msr.id="special__BASE-TYPE_maxSize_TYPE" This element specifies the byte order of the parent element. The byte order is defined with the attribute TYPE. Possible values are: * MOST-SIGNIFICANT-BYTE-FIRST * MOST-SIGNIFICANT-BYTE-LAST asam.harmonizedObject="BYTE-ORDER";msr.id="type__BYTE-ORDER_TYPE";msr.isGroupOnly="true" This element specifies the byte order of the parent element. The byte order is defined with the attribute TYPE. Possible values are: * MOST-SIGNIFICANT-BYTE-FIRST * MOST-SIGNIFICANT-BYTE-LAST asam.harmonizedObject="BYTE-ORDER";msr.id="type__BYTE-ORDER_TYPE";msr.isGroupOnly="true" This class is a collection of properties relevant for data objects under various aspects. One could consider this class as a "pattern of inheritance by aggregation". The properties can be applied to all objects of all classes in which SwDataDefProps is agrregated. Note that not all of the attributes or associated elements are useful all of the time. Hence, the process definition (e.g. expressed with an OCL or a Document Control Instance) MSR-DCI has the task of implementing limitations. SwDataDefProps covers various aspects: * Structure of the data element, is it a single value, a curve, or a map, but also the recordLayouts which specify, how such elements are mapped/converted to the DataTypes in the programming language (or in Autosar). This is mainly expressed by properties like swRecordLayout and swCalprmAxisSet * Implementation policy, mainly expressed by swImplPolicy, swVariableAccessImplPolicy, swAddrMethod * Access policy for the MDC system, mainly expressed by swCalibrationAccess * Semantics of the data element, mainly expressed by compuMethod and/or unit, dataConstr * Code generation policy provided by swCodeSyntax asam.useCase="MDX";msr.id="type__SW-DATA-DEF-PROPS_TYPE";msr.isCond="true" Specifies the read or write access by MCD tools for this data object. msr.id="SW-DATA-DEF-PROPS_TYPE__SW-CALIBRATION-ACCESS";msr.tbdString="true";xml.sequenceOffset="70" This property describes how a number is to be rendered e.g. in documents or in a measurement and calibration system. msr.id="SW-DATA-DEF-PROPS_TYPE__DISPLAY-FORMAT";msr.tbdString="true";xml.sequenceOffset="210" Implementation policy for this data object. msr.id="SW-DATA-DEF-PROPS_TYPE__SW-IMPL-POLICY";msr.tbdString="true";xml.sequenceOffset="230" In case of a swImplPolicy set to "message" the access policy can be refined here. msr.id="SW-DATA-DEF-PROPS_TYPE__SW-VARIABLE-ACCESS-IMPL-POLICY";msr.tbdString="true";xml.sequenceOffset="390" This class is a collection of properties relevant for data objects under various aspects. One could consider this class as a "pattern of inheritance by aggregation". The properties can be applied to all objects of all classes in which SwDataDefProps is agrregated. Note that not all of the attributes or associated elements are useful all of the time. Hence, the process definition (e.g. expressed with an OCL or a Document Control Instance) MSR-DCI has the task of implementing limitations. SwDataDefProps covers various aspects: * Structure of the data element, is it a single value, a curve, or a map, but also the recordLayouts which specify, how such elements are mapped/converted to the DataTypes in the programming language (or in Autosar). This is mainly expressed by properties like swRecordLayout and swCalprmAxisSet * Implementation policy, mainly expressed by swImplPolicy, swVariableAccessImplPolicy, swAddrMethod * Access policy for the MDC system, mainly expressed by swCalibrationAccess * Semantics of the data element, mainly expressed by compuMethod and/or unit, dataConstr * Code generation policy provided by swCodeSyntax asam.useCase="MDX";msr.id="type__SW-DATA-DEF-PROPS_TYPE";msr.isCond="true" The existence of SwArraysize turns the containing element into a multidimensional object. It is then possible to create arrays of variables, parameters etc. SwArraysize should not be used to imitate stereotypes such as curves or maps since these structures are modeled as separate elements, refer to SwCalprmAxisSet for an SwCalprm. Apart from that any array can be created. asam.useCase="MDX";msr.id="type__SW-ARRAYSIZE_TYPE";msr.isGroupOnly="true" Use <v> to enter a numerical value. xml.sequenceOffset="30";msr.id="SW-ARRAYSIZE_TYPE__V" The existence of SwArraysize turns the containing element into a multidimensional object. It is then possible to create arrays of variables, parameters etc. SwArraysize should not be used to imitate stereotypes such as curves or maps since these structures are modeled as separate elements, refer to SwCalprmAxisSet for an SwCalprm. Apart from that any array can be created. asam.useCase="MDX";msr.id="type__SW-ARRAYSIZE_TYPE";msr.isGroupOnly="true" Contains the value for the generic axis parameter. msr.id="special__SW-GENERIC-AXIS-PARAM-VALUE";msr.isGroupOnly="true" Use <v> to enter a numerical value. xml.sequenceOffset="50";msr.id="SW-GENERIC-AXIS-PARAM-VALUE__V" Contains the value for the generic axis parameter. msr.id="special__SW-GENERIC-AXIS-PARAM-VALUE";msr.isGroupOnly="true" This element indicates, that the data object (which is specified by the containing element) is a reference to another data object. The properties of the referred data object are described in the swDataDefProps contained by the SwPointer . asam.useCase="MDX";msr.id="type__SW-POINTER_TYPE" This element indicates, that the data object (which is specified by the containing element) is a reference to another data object. The properties of the referred data object are described in the swDataDefProps contained by the SwPointer . asam.useCase="MDX";msr.id="type__SW-POINTER_TYPE" This element describes the interdependencies of data objects, e.g. variables and parameters. It can be used for example to treat virtual parameters. msr.id="type__SW-DATA-DEPENDENCY_TYPE" This element describes the interdependencies of data objects, e.g. variables and parameters. It can be used for example to treat virtual parameters. msr.id="type__SW-DATA-DEPENDENCY_TYPE" This element specifies the elements used in a SwDataDependency. msr.id="type__SW-DATA-DEPENDENCY-ARGS_TYPE";msr.isGroupOnly="true" This element specifies the elements used in a SwDataDependency. msr.id="type__SW-DATA-DEPENDENCY-ARGS_TYPE";msr.isGroupOnly="true" The properties specific for a textual calibration parameter / variable. msr.id="type__SW-TEXT-PROPS_TYPE" Filler character for text parameter to pad up to the maximum length <SwMaxTextSize>. The filler character for texts which are shorter than the maximum permitted text length. The value will be interpreted according to the encoding specified in the associated base type of the data object., e.g. 0x30 (hex) represents the ASCII character zero as filler character and 0 (dez) represents an end of string as filler character. msr.id="SW-TEXT-PROPS_TYPE__SW-FILL-CHARACTER";msr.tbdString="true";xml.sequenceOffset="40" The properties specific for a textual calibration parameter / variable. msr.id="type__SW-TEXT-PROPS_TYPE" Description of the structure of a bit variable: Comprises of the bitPosition in a memory object (e.g. swHostVariable, which stands parallel to swBitRepresentation) and the numberOfBits . In this way, interrelated memory areas can be described. Non-related memory areas are not supported. asam.useCase="MDX";msr.id="type__SW-BIT-REPRESENTATION_TYPE" If the "bit data object" is hosted witin another data object (e.g. if the memory can be accessed via byte as well as bit adress), this attribute specifies the position of the data object. The count starts at zero (0). msr.id="SW-BIT-REPRESENTATION_TYPE__BIT-POSITION";msr.tbdString="true";xml.sequenceOffset="20" Number of bits allocated by a "bit data object" within its host data object. msr.id="SW-BIT-REPRESENTATION_TYPE__NUMBER-OF-BITS";msr.tbdString="true";xml.sequenceOffset="30" Description of the structure of a bit variable: Comprises of the bitPosition in a memory object (e.g. swHostVariable, which stands parallel to swBitRepresentation) and the numberOfBits . In this way, interrelated memory areas can be described. Non-related memory areas are not supported. asam.useCase="MDX";msr.id="type__SW-BIT-REPRESENTATION_TYPE" This class establishes a reference to a variable. It is mainly introduced by the reverse engineering tool. asam.useCase="MDX";msr.id="type__SW-VARIABLE-REF_TYPE" This class establishes a reference to a variable. It is mainly introduced by the reverse engineering tool. asam.useCase="MDX";msr.id="type__SW-VARIABLE-REF_TYPE" These variables can be used to display the value of a variable on the value axis of a calibration parameter (characteristic), that is currently displayed in the MCD-System. The purpose is to compare the appropriate result from the calibration parameter in question, with a value being calculated or taken from a sensor (the comparison variable). The sole purpose of this comparison-variable is to serve the calibration process. Screen representation of comparison variable Vs | | | | | | V _|______________|______________ | /----|------ | /-----/ | | / | |/ | |--------------|-------------- tx tmot tx: current temperature V: current speed as shown in the MCD system for comparison: this is the SwComparisonVariable Vs: speed characteristic over temperature tmot: motor temperature msr.id="type__SW-COMPARISON-VARIABLES_TYPE" These variables can be used to display the value of a variable on the value axis of a calibration parameter (characteristic), that is currently displayed in the MCD-System. The purpose is to compare the appropriate result from the calibration parameter in question, with a value being calculated or taken from a sensor (the comparison variable). The sole purpose of this comparison-variable is to serve the calibration process. Screen representation of comparison variable Vs | | | | | | V _|______________|______________ | /----|------ | /-----/ | | / | |/ | |--------------|-------------- tx tmot tx: current temperature V: current speed as shown in the MCD system for comparison: this is the SwComparisonVariable Vs: speed characteristic over temperature tmot: motor temperature msr.id="type__SW-COMPARISON-VARIABLES_TYPE" This element denotes a variable which servers as a semaphore for a particular resource which is specified in the surrounding data object, e.g. SwDataDefProps. msr.id="type__SW-SEMAPHORE_TYPE" This element denotes a variable which servers as a semaphore for a particular resource which is specified in the surrounding data object, e.g. SwDataDefProps. msr.id="type__SW-SEMAPHORE_TYPE" This element specifies the properties of calibration parameters in the ECU. Calibration parameters are adapted to the vehicle in the calibration phase. Variables are quite the opposite, they are manipulated during the normal operation of the software. The category of the calprm is used to specify particular shapes of calibration parameters (e.g. the categories as defined by ASAM MDX) asam.useCase="MDX";msr.id="type__SW-CALPRM_TYPE";msr.isNamespace=" TeamMembe SwGenericAxisPara SwCalpr" This element specifies the properties of calibration parameters in the ECU. Calibration parameters are adapted to the vehicle in the calibration phase. Variables are quite the opposite, they are manipulated during the normal operation of the software. The category of the calprm is used to specify particular shapes of calibration parameters (e.g. the categories as defined by ASAM MDX) asam.useCase="MDX";msr.id="type__SW-CALPRM_TYPE";msr.isNamespace=" TeamMembe SwGenericAxisPara SwCalpr" This element specifies an individual input parameter axis (abscissa). asam.useCase="MDX";msr.id="type__SW-CALPRM-AXIS_TYPE" Describes the index referring to the axis currently described, for which the contents is specified. msr.id="SW-CALPRM-AXIS_TYPE__SW-AXIS-INDEX";msr.tbdString="true";xml.sequenceOffset="20" This property specifies the category of a particular axis. msr.id="SW-CALPRM-AXIS_TYPE__CATEGORY";msr.tbdString="true";xml.sequenceOffset="30" Describes the applicability of parameters and variables. msr.id="SW-CALPRM-AXIS_TYPE__SW-CALIBRATION-ACCESS";msr.tbdString="true";xml.sequenceOffset="90" This property specifies how the axis values shall be displayed e.g. in documents or in measurement and calibration tools. msr.id="SW-CALPRM-AXIS_TYPE__DISPLAY-FORMAT";msr.tbdString="true";xml.sequenceOffset="100" This element specifies an individual input parameter axis (abscissa). asam.useCase="MDX";msr.id="type__SW-CALPRM-AXIS_TYPE" Container for the properties of a grouped axis. asam.useCase="MDX";msr.id="special__SW-CALPRM-AXIS_commonAxis_TYPE" Container for the properties of a grouped axis. asam.useCase="MDX";msr.id="special__SW-CALPRM-AXIS_commonAxis_TYPE" Container for the properties of an individual axis. asam.useCase="MDX";msr.id="special__SW-CALPRM-AXIS_individualAxis_TYPE" Container for the properties of an individual axis. asam.useCase="MDX";msr.id="special__SW-CALPRM-AXIS_individualAxis_TYPE" This element is used to record textual descriptions of axis values and is contained in ASAP1.4, for reasons of backward compatibility. In new systems, the application should be implemented via conversion formulae. msr.id="type__SW-CALPRM-VALUE-AXIS-LABELS_TYPE" This element specifies the input parameter axes (abscissas) of parameters (and variables, if these are used adaptively). asam.useCase="MDX";msr.id="type__SW-CALPRM-AXIS-SET_TYPE" This element specifies the input parameter axes (abscissas) of parameters (and variables, if these are used adaptively). asam.useCase="MDX";msr.id="type__SW-CALPRM-AXIS-SET_TYPE" This element defines an axis for the base points calculated in the ECU. The ECU is equipped with a fixed calculation algorithm. Parameters for the algorithm can be stored in the data component of the ECU. asam.useCase="MDX";msr.id="type__SW-AXIS-GENERIC_TYPE" This element defines an axis for the base points calculated in the ECU. The ECU is equipped with a fixed calculation algorithm. Parameters for the algorithm can be stored in the data component of the ECU. asam.useCase="MDX";msr.id="type__SW-AXIS-GENERIC_TYPE" This element describes a specific parameter of a generic axis. The name of the parameter is defined through a reference to a parameter type defined on a corresponding axis type. asam.useCase="MDX";msr.id="type__SW-GENERIC-AXIS-PARAM_TYPE" This element describes a specific parameter of a generic axis. The name of the parameter is defined through a reference to a parameter type defined on a corresponding axis type. asam.useCase="MDX";msr.id="type__SW-GENERIC-AXIS-PARAM_TYPE" This element describes a generic axis parameter type, namely: * Plausibility checks can be specified via dataConstr. * Textual description (desc), as a formal description is not of any use, due to the large variety of possibilities. * If this parameter contains structures, these can be simulated through the recursive use of swGenericAxisParamTypes. asam.useCase="MDX";msr.id="type__SW-GENERIC-AXIS-PARAM-TYPE_TYPE" Stands for a specific axis calculation strategy. No formal specification is given, due to the fact that it is possible to use arbitrary algorithms for calculating axis-points. Instead, the algorithm is described verbally but the parameters are specified formally with respect to their names and constraints. As a result, SwAxisType mainly reserves appropriate keywords. asam.useCase="MDX";msr.id="type__SW-AXIS-TYPE_TYPE";msr.isNamespace=" TeamMembe SwGenericAxisPara" Stands for a specific axis calculation strategy. No formal specification is given, due to the fact that it is possible to use arbitrary algorithms for calculating axis-points. Instead, the algorithm is described verbally but the parameters are specified formally with respect to their names and constraints. As a result, SwAxisType mainly reserves appropriate keywords. asam.useCase="MDX";msr.id="type__SW-AXIS-TYPE_TYPE";msr.isNamespace=" TeamMembe SwGenericAxisPara" This element describes an axis integrated into a parameter (field etc.). The integration makes this individual to each parameter. The so-called grouped axis represents the counterpart to this. It is conceived as an independent parameter (see class SwAxisGrouped). The attributes swVariableRefs, compuMethod and unit can exist in parallel, although physically speaking, only one is practical. This parallelism introduces flexibility into the development process, as axes can be described purely physically, without a conversion formula being available. The following priority exists: * swVariableRefs * compuMethod * unit asam.useCase="MDX";msr.id="type__SW-AXIS-INDIVIDUAL_TYPE" This element describes an axis integrated into a parameter (field etc.). The integration makes this individual to each parameter. The so-called grouped axis represents the counterpart to this. It is conceived as an independent parameter (see class SwAxisGrouped). The attributes swVariableRefs, compuMethod and unit can exist in parallel, although physically speaking, only one is practical. This parallelism introduces flexibility into the development process, as axes can be described purely physically, without a conversion formula being available. The following priority exists: * swVariableRefs * compuMethod * unit asam.useCase="MDX";msr.id="type__SW-AXIS-INDIVIDUAL_TYPE" An SwAxisGrouped is an axis which is shared between multiple calibration parameters. asam.useCase="MDX";msr.id="type__SW-AXIS-GROUPED_TYPE" An SwAxisGrouped is an axis which is shared between multiple calibration parameters. asam.useCase="MDX";msr.id="type__SW-AXIS-GROUPED_TYPE" Specialization of SwCalprmRefProxy which contains a reference to a calibration parameter in the MSR style. Specialization of SwCalprmRefProxy which contains a reference to a calibration parameter in the MSR style. Parent class for several kinds of references to a calibration parameter. Specialization of SwVariableRefProxy which is expressed by a SwVariable. Specialization of SwVariableRefProxy which is expressed by a SwVariable. This element specifies a variable in the ECU. Variables are not adapted to the vehicle in the calibration phase. They are manipulated during the normal operation of the software. Sub-structures are simulated through the aggregation of further swVariables . asam.useCase="MDX";msr.id="type__SW-VARIABLE_TYPE";msr.isNamespace=" TeamMembe SwGenericAxisPara SwCalpr SwFeatureVarian SwInstanc SwInstanc SwServiceArg SwServiceRetur SwVariabl" This element specifies a variable in the ECU. Variables are not adapted to the vehicle in the calibration phase. They are manipulated during the normal operation of the software. Sub-structures are simulated through the aggregation of further swVariables . asam.useCase="MDX";msr.id="type__SW-VARIABLE_TYPE";msr.isNamespace=" TeamMembe SwGenericAxisPara SwCalpr SwFeatureVarian SwInstanc SwInstanc SwServiceArg SwServiceRetur SwVariabl" This element specifies a short name for the scaleConstr. This can for example be used to create more specific messages of a constraint checker. The constraints cannot be associated in the metamodel, therefore shortLabel is somehow a substitute for shortName. msr.id="SCALE-CONSTR_TYPE__SHORT-LABEL";msr.tbdString="true";xml.sequenceOffset="20" Parameters or variables can reference plausibility checks. The assignment of data to <swConstrObjects> makes the reverse direction possible. In this way for example plausibility libraries stored in external files can be latched beneath the previous element <SW-DATA-CONSTRS> -element. msr.id="type__SW-CONSTR-OBJECTS_TYPE";msr.isGroupOnly="true" This element describes the implementation details of a class attribute which manifests itself as a calibration parameter. asam.useCase="MDX";msr.id="type__SW-CALPRM-IMPL_TYPE" This element describes the implementation details of a class attribute which manifests itself as a calibration parameter. asam.useCase="MDX";msr.id="type__SW-CALPRM-IMPL_TYPE" This element describes the prototype declaration of a class attribute, which is used as a calibration parameter. asam.useCase="MDX";msr.id="type__SW-CALPRM-PROTOTYPE_TYPE";msr.isCond="true" This element describes the prototype declaration of a class attribute, which is used as a calibration parameter. asam.useCase="MDX";msr.id="type__SW-CALPRM-PROTOTYPE_TYPE";msr.isCond="true" An SwClass stands for the type of a software entity, which defines data properties and (optionally) associated methods and can have multiple instances. There are various use cases. For example it can be used to define the implementation of variables and parameters originating in the instantiation of this class. A SwClass can optionally contain 1 to n SwClassAttrImpls, with each representing a particular class implemetation. A SwClass contains 0 to n SwClassAttr attributes, which is merely the list of data objects to be established by the instantiation of the class. This is one of the reasons why an SwInstanceTree is necessary. Furthermore it contains 0 to n SwClassMethods, each of which representing a particular class method. T Classes are instantiated within the data dictionaries, either globally or within a feature. Therefore an SwClassInstance in a DataDictionary contains a reference to an SwClass. This represents a particular instance of an SwClass. The contents of this element replaces the contents of the referenced SwClass, thus defining the particular implementation. asam.useCase="MDX";msr.id="type__SW-CLASS_TYPE" An SwClass stands for the type of a software entity, which defines data properties and (optionally) associated methods and can have multiple instances. There are various use cases. For example it can be used to define the implementation of variables and parameters originating in the instantiation of this class. A SwClass can optionally contain 1 to n SwClassAttrImpls, with each representing a particular class implemetation. A SwClass contains 0 to n SwClassAttr attributes, which is merely the list of data objects to be established by the instantiation of the class. This is one of the reasons why an SwInstanceTree is necessary. Furthermore it contains 0 to n SwClassMethods, each of which representing a particular class method. T Classes are instantiated within the data dictionaries, either globally or within a feature. Therefore an SwClassInstance in a DataDictionary contains a reference to an SwClass. This represents a particular instance of an SwClass. The contents of this element replaces the contents of the referenced SwClass, thus defining the particular implementation. asam.useCase="MDX";msr.id="type__SW-CLASS_TYPE" Defines the object-oriented class-attributes containing the prototypes: <swVariablePrototypes> which denote attributes within the classes that are variables, <swCalprmPrototypes> which denote attributes within the classes that are calibration parameters , <SW-SERVICE-PROTOTYPES> which denote attributes within the classes that are services and <swClassPrototypes> which denote attributes within the classes that are class instances themselves. asam.useCase="MDX";msr.id="type__SW-CLASS-ATTR_TYPE" Defines the object-oriented class-attributes containing the prototypes: <swVariablePrototypes> which denote attributes within the classes that are variables, <swCalprmPrototypes> which denote attributes within the classes that are calibration parameters , <SW-SERVICE-PROTOTYPES> which denote attributes within the classes that are services and <swClassPrototypes> which denote attributes within the classes that are class instances themselves. asam.useCase="MDX";msr.id="type__SW-CLASS-ATTR_TYPE" This element describes the prototype declaration of a class attribute, which appears in the form of a variable. asam.useCase="MDX";msr.id="type__SW-VARIABLE-PROTOTYPE_TYPE";msr.isCond="true" This element describes the prototype declaration of a class attribute, which appears in the form of a variable. asam.useCase="MDX";msr.id="type__SW-VARIABLE-PROTOTYPE_TYPE";msr.isCond="true" <swClassAttrInstanceImpl> is used to create an instance from a model (Models are defined with SW-CLASS) where some specifications shall be changed / overwritten. This implementation will then be a instance specific implementation (Classes are usually only implemented under <swClassImpls>). asam.useCase="MDX";msr.id="type__SW-CLASS-ATTR-INSTANCE-IMPL_TYPE" <swClassAttrInstanceImpl> is used to create an instance from a model (Models are defined with SW-CLASS) where some specifications shall be changed / overwritten. This implementation will then be a instance specific implementation (Classes are usually only implemented under <swClassImpls>). asam.useCase="MDX";msr.id="type__SW-CLASS-ATTR-INSTANCE-IMPL_TYPE" This element describes the implementation details of a class attribute which manifests itself as a variable. asam.useCase="MDX";msr.id="type__SW-VARIABLE-IMPL_TYPE" This element describes the implementation details of a class attribute which manifests itself as a variable. asam.useCase="MDX";msr.id="type__SW-VARIABLE-IMPL_TYPE" This element describes the implementation details of a class attribute which manifests itself as a class. asam.useCase="MDX";msr.id="type__SW-CLASS-IMPL_TYPE" This element describes the implementation details of a class attribute which manifests itself as a class. asam.useCase="MDX";msr.id="type__SW-CLASS-IMPL_TYPE" This element describes the prototype declaration of a class attribute, which appears in the form of a class. asam.useCase="MDX";msr.id="type__SW-CLASS-PROTOTYPE_TYPE";msr.isCond="true" Defines the particular instantiation of a referenced <swClass> . asam.useCase="MDX";msr.id="type__SW-CLASS-INSTANCE_TYPE" Defines the particular instantiation of a referenced <swClass> . asam.useCase="MDX";msr.id="type__SW-CLASS-INSTANCE_TYPE" Defines the object-oriented class-attributes: SW-VARIABLE-IMPLS which implement attributes that are variables, SW-CALPRM-IMPLS which implement attributes that are calibration parameters and SW-CLASS-IMPLS which implement attributes that are class instances themselves. asam.useCase="MDX";msr.id="type__SW-CLASS-ATTR-IMPL_TYPE" Defines the object-oriented class-attributes: SW-VARIABLE-IMPLS which implement attributes that are variables, SW-CALPRM-IMPLS which implement attributes that are calibration parameters and SW-CLASS-IMPLS which implement attributes that are class instances themselves. asam.useCase="MDX";msr.id="type__SW-CLASS-ATTR-IMPL_TYPE" This element is similar to <SW-INTERFACE-ACCESSED-ELEMENT-SET> but applies to <SW-SERVICE> . To some extent it is now possible to epress the access to interface elements * within a software component represented by ( <swFeature> ), which is the mainly a functional view * within a process represented by <SW-SERVICE>, which is more the dynamic view. These processes are part of compontents (represented by ownership and imports, which makes it possible to retrieve the functional view from the dynamic view (but ** vice versa). msr.id="type__SW-SERVICE-ACCESSED-ELEMENT-SET_TYPE";msr.isCond="true" Specifies the properties of a data object exchanged during the call of an SwService, e.g. an argument or a return value. asam.useCase="MDX";msr.id="type__SW-SERVICE-ARG_TYPE" Specifies the properties of a data object exchanged during the call of an SwService, e.g. an argument or a return value. asam.useCase="MDX";msr.id="type__SW-SERVICE-ARG_TYPE" tbd asam.useCase="MDX";msr.id="type__SW-SERVICE-IMPL_TYPE" Describes certain properties of the service implementation. asam.useCase="MDX";msr.id="type__SW-SERVICE-PROPS_TYPE" Reentrance enables or prohibits the service to be invoked again, before the service has finished and delivered a result. If the attribute is missing, then reentrance is prohibited. msr.id="SW-SERVICE-PROPS_TYPE__SW-SERVICE-REENTRANCE";msr.tbdString="true";xml.sequenceOffset="20" Enables the specification of an implementation strategy. In this way, the direction of the implementation to come, can be specified in advance in an earlier phase. msr.id="SW-SERVICE-PROPS_TYPE__SW-IMPL-POLICY";msr.tbdString="true";xml.sequenceOffset="40" Describes certain properties of the service implementation. asam.useCase="MDX";msr.id="type__SW-SERVICE-PROPS_TYPE" Describes a procedure call in the software. Depending on the usage, the description can contain properties of the function call (signature) and of its implementation as well. asam.useCase="MDX";msr.id="type__SW-SERVICE_TYPE";msr.isNamespace=" TeamMembe SwGenericAxisPara SwCalpr SwFeatureVarian SwInstanc SwInstanc SwServiceArg SwServiceRetur" Describes a procedure call in the software. Depending on the usage, the description can contain properties of the function call (signature) and of its implementation as well. asam.useCase="MDX";msr.id="type__SW-SERVICE_TYPE";msr.isNamespace=" TeamMembe SwGenericAxisPara SwCalpr SwFeatureVarian SwInstanc SwInstanc SwServiceArg SwServiceRetur" An AssemblyHWConnection is established between at least two HWPorts provided by different HWElements. The AssemblyHWConnection can only be established between HWPorts on the same hierarchical level. To connect accross hierarchical levels use the DelegationHWConnection. An AssemblyHWConnection is established between at least two HWPorts provided by different HWElements. The AssemblyHWConnection can only be established between HWPorts on the same hierarchical level. To connect accross hierarchical levels use the DelegationHWConnection. Abstract class to specify the ability to connect HWPorts. Is used to connect the HWPins of the HWPorts that are referenced by the HWConnection. Is used to connect the HWPins of the HWPorts that are referenced by the HWConnection. A HWPin is an elementary electrical interface of the HWElement. The HWPins of a HWPort can be clustered if there are some HWPins with the same behaviour. The general element HW Port is necessary to connect HW Elements and contains common elements for all different kind of HW Ports. HW Ports are required to be uniquely identifiable within the scope of a HW Element. This means to identify a specific HW Port it is necessary to prefix the HW Port name by the name of the HW Element (e.g."PU1/ADCPort3"). The direction of a HW Port defines signal flow in the point of view of the HW Element the HW Port belongs to. The following attributes are allowed: The general element HW Port is necessary to connect HW Elements and contains common elements for all different kind of HW Ports. HW Ports are required to be uniquely identifiable within the scope of a HW Element. This means to identify a specific HW Port it is necessary to prefix the HW Port name by the name of the HW Element (e.g."PU1/ADCPort3"). The General HW Element specifies definitions valid for all specific HW Elements. The Standby Current is the current in state OFF. For HW Elements the Standby Current consists of the current needed by the logic to stay in the state OFF and the leakage current of the HW Element. For big HW Elements the leakage current can be up to several 100 microA. Standby Current is used to determine which elements are necessary to be switch off, when the car itself is in a standby mode. This can be done automatically or by the user. The value for the Standby Current can be entered for each HW Element and HW Container respectively. The user has to take care about these values and decides about the entries necessary for the calculation of the complete standby current. On the other side the sum for all HW Elements grouped in a HW Container may have a bigger value than the value for the HW Container itself. In this case the values for the HW Elements represent the worst case for each HW Element. Unit: Ampere (A) The Signal Transformation defines the conversion of the signal attached to a HW Port (direction In) and a signal attached to a HW Port (direction Out). The Signal Transformation defines the conversion of the signal attached to a HW Port (direction In) and a signal attached to a HW Port (direction Out). Is used to connect HWPorts of a HWContainer with HWPorts of the contained HWElements. Is used to connect HWPorts of a HWContainer with HWPorts of the contained HWElements. Abstract class to enable the collection of HW Elements. A HW Container is a group of HW Elements on the same hierarchical level and is an abstraction of composite HW Elements. The HW Container is a specialisation of a HW Element and therefore the HW Container has all elements of a HW Element. The values of elements of the HW Elements grouped in a HW Container may differ from the values of the elements of the HW Container. The ECU provides information about an ECU and its internal hardware elements. The described hardware elements are related to some extent to basic software configuration and the AUTOSAR generation process. The ECU provides information about an ECU and its internal hardware elements. The described hardware elements are related to some extent to basic software configuration and the AUTOSAR generation process. Time information for ECU and PU startup. Time it takes to come from a completely powered down state to the HWInit state in seconds. Time it takes from the reset initiation to the HWInit state in seconds. Time information for ECU and PU startup. Specifies electrical ranges for different applications within the ECU Resource Template. Maximum Current Unit: A Maximum voltage Unit: V Minimum Current Unit: A Minimum voltage Unit: V Typical Current Unit: A Typical voltage Unit: V Specifies electrical ranges for different applications within the ECU Resource Template. Provides information on what extra bits are used for error detection and correction. How many error bits can be corrected. Unit: Bit How many bit errors can be reconginsed. Unit: Bit How many extra bits are used for ensuring error detection and correction. Unit: Bit Provides information on what extra bits are used for error detection and correction. Class describing minimum, maximum and typical frequencies. Maximum frequency. Unit: Herz Minimum frequency. Unit: Herz Typical frequency. Unit: Herz Class describing minimum, maximum and typical frequencies. In the current version of the ECU Resource Template the element SupportsSafety is optional. A HW Element uses this element if it provides a safety mechanism, otherwise this element is missing in the description of the HW Element. The ECU Resource Template provides the element SupportsSecurity storing the information about the supported security mechanism. In the current version of the ECU Resource Template the element SupportsSecurity is optional. A HW Element uses this element if it provides a security mechanism otherwise this element is missing in the description of the HW Element. General element to describe temperature ranges and need for cooling/heating. These attributes describe that there is an active cooling system required for this HW Element. These attributes describe that there is an active heating system required for this HW Element. It describes the temperature range (max) in which the HW Element can be operated. Unit: Kelvin (K) It describes the temperature range (min) in which the HW Element can be operated. Unit: Kelvin (K) It describes the temperature range (typical) in which the HW Element can be operated. Unit: Kelvin (K) The storage temperature defines maximum temperature the device is allowed to be stored. The HW Element is not in an operational state. Unit: Kelvin (K) The storage temperature defines minimum temperature the device is allowed to be stored. The HW Element is not in an operational state. Unit: Kelvin (K) General element to describe temperature ranges and need for cooling/heating. Description of a buffer. It is used to describe input and output buffers. Buffers can also be configurable direction. The amount of buffers with the attributes size and type. The size of the Buffer. Unit: Byte Either input, output or configurable buffer. Description of a buffer. It is used to describe input and output buffers. Buffers can also be configurable direction. The CCU is a special kind of a timer, which has the capability of counting and comparing external signals. The timer is equipped with some extra registers and comparators in order to measure time or frequency. A Capture and Compare peripheral can be configured to operate either in capture or compare mode. The CCU is a special kind of a timer, which has the capability of counting and comparing external signals. The timer is equipped with some extra registers and comparators in order to measure time or frequency. Common attributes shared by all timer peripherals Some timers have the possibility to detect signals from a quadrature rotating switch. There are two outputs signal from such a switch; the signals are 90 degrees phase shifted from each other. The rotation of the switch can then automatically be detected by a special function in a timer. For a timer the resolution defines the data width of the counter. Unit: Bits The threshold is the definition of a counter value. When the counter has reached this value some action is performed, e.g. an interrupt can be generated. General Element for all peripherals. Defines if the peripheral can be logically enabled or disabled. General Element for all peripherals. Describes the amount and the size of the communication filters. These can be used as acceptance or rejection filters. How many acceptance filters are availabe. Which bit-size do the filters have. Is it possible to provide wildcard identifires allowing to specify ranges for filtering. Describes the amount and the size of the communication filters. These can be used as acceptance or rejection filters. This port is directed from the peripheral to the ecu electronics and communication. An input or output can sometimes be programmed to invert the level of a signal. The peripheral device has the feature to issue a Power On event to the ECU. Example: Some CAN bus transceivers have a dedicated low power voltage regulator and a feature, which allows to turn on the main voltage regulator of the ECU by detecting a bus activity. Example: A wired-or connection of a termination KL30 and KL15 can fulfil this requirement. The peripheral device has the feature to issue a wake-up event to the processing unit. Example: HW Port with Key-Wake-Up on a PU is still active while the PU is in stop mode and only partially supplied with power. The Key-Wake-Up reacts on any changes at the input of the HW Port with the activation of the power supply, the activation of the clock system and later the resuming of the software, which has to process the input of the HW Port. This port is directed from the peripheral to the ecu electronics and communication. Abstract element to describe communication speed. This can be either a fixed value, a range or a list of allowed communication speed. The element defines the tolerance allowed for the interface. (E.g. K-Line or LIN +/- 2 % at 9.6 Kbd) Describes the physical medium the bus is working on. In most cases it is not relevant for the SW to know about it, only for compatibility checking. Specifies how many data lines (ground not included) are used for the physical layer. Some bus systems can be implemented with e.g. 1, 2 or 4 data lines. The element protocol name defines the exact standardised protocol name. Examples are: - ISO 11519 for low-speed CAN - IEEE 802.11g for W-LAN (54 Mbit/s at 2,5 GHz) - IEEE-1394a for Firewire-400 Describes the actual medium used for transmission. Describes the physical medium the bus is working on. In most cases it is not relevant for the SW to know about it, only for compatibility checking. Peripheral representing communication devices. The implemented architecture The Element Monitor specifies if the device supports listen only. In this mode the device is passive on the bus and no acknowledgement or other responds are transmitted. Is a timestamp for received frames available. Peripheral representing communication devices. The name and version of the communication protocol. This is the version number of the implementation of the protocol layer, e.g. - 2.0a, 2.0b for CAN. - 1.3, 2.0 for LIN. - 2.0 for USB. The name and version of the communication protocol. Fixed value for the communication speed. Unit: bits per second Fixed value for the communication speed. List of possible communication speed. Unit: bits per second List of possible communication speed. Range of communication speed. Unit: bits per second Unit: bits per second Range of communication speed. A specialization of a Communication HW Port that is availabe for the inter ECU communication. The simplest form is an array of directly coupled D-flip flops, which build up a shift register, with separate output from each stage, thus forming a time-register. A clock signal at the input increments the value of the register. Some cases uses some logic in combination of the shift register in order to form a special adopted representation of the information or to fulfil special requirements. Defines if the peripheral can automatically be reset during operation. The direction defines if the counter of a timer counts up, down or if it can be selected. single: The timer is counted from a defined start value to a defined end value and then stopped. continuous: The timer is counted from a defined start value to a defined end value and then restarted with the start value. free: The timer is counted always to the available maximum value of the timer structure, then a wrap around occurs and the timer starts again from the HW defined startpoint; e.g. a 16 bit Timer counts from 0(hex)....0FFFF(hex), then after the overflow again from 0(hex)....0FFFF(hex). The simplest form is an array of directly coupled D-flip flops, which build up a shift register, with separate output from each stage, thus forming a time-register. A clock signal at the input increments the value of the register. Some cases uses some logic in combination of the shift register in order to form a special adopted representation of the information or to fulfil special requirements. A form of interval timer, which is used to detect a possible malfunction of the processing unit. The timer is started as a countdown and has to be triggered within a specific time. Either the trigger only has to occur before the count-down runs out, or the trigger has to occur within a specific window before the timeout, therefore a trigger too early will also set off the watchdog. If the trigger is not correctly performed the watchdog will set off and will initiate an interrupt or perform a reset of the whole processing unit or ECU. The watchdog can be implemented in software or hardware and if the implementation is in hardware it can be integrated into the processing unit or connected externally. Depending on the complexity of the watchdog the interfacing is either a serial communication or some discrete I/O lines. Also the trigger itself can be just some digital peak or can be some calculated request-response mechanism. The actual handling of the watchdog has to be covered by some specific driver software. The watchdog will use at least an interrupt of the processing unit and also some peripheral connections for the control and set-up. To enable different operating modes of the processing unit and the ECU it is important to specify if the watchdog can be disabled (e.g. during flash programming). A Watchdog can be running in different modes. In normal mode must the watchdog be kicked within a certain maximum time. In the windowed mode there is also a lower limit of the time when the watchdog has to be kicked. In debug mode is the watchdog disabled. Sometimes it's also required that the watchdog can be disabled and enabled during software download. To ensure that this mode is not entered in normal operation there is often some kind of security procedure to enter the mode. The threshold is the definition of a counter value. When the counter has reached this value some action is performed, e.g. an interrupt can be generated. A form of interval timer, which is used to detect a possible malfunction of the processing unit. The timer is started as a countdown and has to be triggered within a specific time. Either the trigger only has to occur before the count-down runs out, or the trigger has to occur within a specific window before the timeout, therefore a trigger too early will also set off the watchdog. If the trigger is not correctly performed the watchdog will set off and will initiate an interrupt or perform a reset of the whole processing unit or ECU. The watchdog can be implemented in software or hardware and if the implementation is in hardware it can be integrated into the processing unit or connected externally. Depending on the complexity of the watchdog the interfacing is either a serial communication or some discrete I/O lines. Also the trigger itself can be just some digital peak or can be some calculated request-response mechanism. The actual handling of the watchdog has to be covered by some specific driver software. The watchdog will use at least an interrupt of the processing unit and also some peripheral connections for the control and set-up. To enable different operating modes of the processing unit and the ECU it is important to specify if the watchdog can be disabled (e.g. during flash programming). An ADC converts an analogue signal at an input pin to a digital value. The analogue signal are quantified to a maximum number of different levels defined by the resolution of the ADC. The Accuracy of the ADC is important for the overall functionality. Defines the action that is going to be performed when a limit is reached. - Clipping: Logical value is limited to minimal or maximal range of the value range. E.g. The max. resolution of an ADC is at 5V represented 0xFF; in case off clipping a voltage of 6V is also represented as 0xFF; - Undefined: Exceeding the resolution results in an undefined representation of the logical value. - Default: Exceeding the resolution results in a predefined default value. The default value might be a value, which report the status to the application e.g. as an error condition. - Other: A predefined function occur in order to prevent a undefined logical value. A typical application is a "Soft-Clipping" in a logarithmic form at the limit of the resolutions in audio applications. The according methods have to be specified in the signal description. An ADC converts an analogue signal at an input pin to a digital value. The analogue signal are quantified to a maximum number of different levels defined by the resolution of the ADC. The Accuracy of the ADC is important for the overall functionality. These are the common attributes for both, the ADC and the DAC. There is a number of different conversion error in an ADC or DAC like non-linearity and absolute error. The accuracy is defined as the total error and it can be expressed as a deviation from its nominal value by e.g. 0.5, 1.0, 1.5 or 2.0 LSB. ADC: The conversion time is the definition how long it takes for an ADC to convert an analogue signal to a digital value. DAC: The conversion time is the definition how long it takes for a DAC to convert a digital value to an analogue signal. An ADC or DAC can operate in continuous, single or sequential mode. In the continuous mode the conversion is automatically repeated after a completion. In single shot only one conversion is performed. For the sequential mode can a predefined number of different analogue channels be converted. Defines the design of a simple multiplexer used by an ADC. Example A 2:8-multiplexer has 2 input channels and 8 registers. M is the second value. Defines the design of a simple multiplexer used by an ADC. Example A 2:8-multiplexer has 2 input channels and 8 registers. N is the first value. For an Analogue to Digital Converter the resolution defines the number of different voltage levels, which are converted to a digital value. For example, an ADC with 10-bits resolution have the ability to convert an analogue value into 1024 different digital values. Unit: Bits The number of Bits used to store the digital value. The processing unit writes a digital value to a register of the DAC and the value is converted to an analogue value at a given pin. Digital Input/Output peripherals provide the capability to send/receive data in a digital manner. Each digital input has an electrical range. When the voltage is less than a specified level, the input is represents logical low '0'. On the opposite when the voltage is higher than a specified value the input represents logical high '1'. A digital I/O can usually be programmed to be either an input or output. It can also be programmed to logically invert the input or output. The maximum frequency of a digital input or output is related to how fast the PU can read or write to the digital I/O register. It's very common for a digital I/O to have different functionality. One example is when a timer has an external clock signal associated with a digital I/O. In this case the maximum frequency is defined by the performance of the timer counter and can be found in the electrical characteristic of the peripheral datasheet. A general digital input can be enabled to trigger an interrupt on a falling, rising or both edges of an input signal. A clock, compare or count input on a timer can be programmed to increase, decrease or store the timer value if a change on the input pin has occurred. The condition for this change can be programmed to trigger an event in the same manner as for a digital input. Digital Input/Output peripherals provide the capability to send/receive data in a digital manner. Each digital input has an electrical range. When the voltage is less than a specified level, the input is represents logical low '0'. On the opposite when the voltage is higher than a specified value the input represents logical high '1'. A digital I/O can usually be programmed to be either an input or output. It can also be programmed to logically invert the input or output. The maximum frequency of a digital input or output is related to how fast the PU can read or write to the digital I/O register. It's very common for a digital I/O to have different functionality. One example is when a timer has an external clock signal associated with a digital I/O. In this case the maximum frequency is defined by the performance of the timer counter and can be found in the electrical characteristic of the peripheral datasheet. Pulse Width Demodulation is the inverse method of PWM. Here the processing unit is trying to gather information about a signal. A PWD can detect rising and falling edges and call the software in order to calculate the pulse width. When a PWD have more than one input signal the frequency and phase between the signals can be obtained. A Pulse Width Demodulation peripheral can be configured to decode a two phase or a three phase input signals. Some timers have the possibility to detect signals from a quadrature rotating switch. There are two outputs signal from such a switch; the signals are 90 degrees phase shifted from each other. The rotation of the switch can then automatically be detected by a special function in a timer. Pulse Width Demodulation is the inverse method of PWM. Here the processing unit is trying to gather information about a signal. A PWD can detect rising and falling edges and call the software in order to calculate the pulse width. When a PWD have more than one input signal the frequency and phase between the signals can be obtained. Common elements for PWM, PWD and CCU. Defines the data width of the counter. Unit: Bits Pulse Width Modulation refers to a method of carrying information on a train of pulses, the information being encoded in the width of the pulses. The frequency is normally not changed. It's only relationship between the high and low level of the signal which are changed. A PWM interface is usually a part of a processing unit. It provides the capability to communicate with another system with an easy protocol. In order to avoid signal reflection and oscillation of the Technical Signal represen-tation the impedance on communication lines have to be defined and matched at the signal destination and the signal source. Some examples: A High-speed CAN network with a twisted pair cable works optimal with an overall impedance of 60 Ohms represented by a 120 Ohm resistor in the ECU at the begin-ning of the network and 120 Ohm in the ECU at the end of a linear network topology. For Low-speed CAN networks in many cases termination resistors of 820 Ohm each are distributed on several ECUs to get good balance between system scalability and signal integrity in real networks without a fixed network topology. The lower bandwidth can tolerate some impedance mismatch. For LIN networks recessive termination is used: The inactive bus signal level is defined by resistors tied to a defined voltage level. An important attribute for communication lines is the presence of a termination resistor and the value of this resistor. Switchable termination describes a technology were the termination resistors can be switched or changed by extra hardware and therefore is under control of software. Main scope of a switchable termination is to adopt the termination of an individual ECU to the network topology of a specific car, e. g modules for extra car options can use this method to be incorporated in a wide range of different car types. The active termination is described by the values for each termination value. E.g. 120, 820, 12k. No termination is represented by values greater than 100 k. The attributes value and switchable are exclusive to each other. To improve the signal integrity on communication busses with a differential electrical signal representation on the physical layer, common mode chokes are used. They suppress common mode DC noise on CAN, FlexRay and Ethernet networks. Depending on the network topology common mode chokes of an ECU have to be taken in to account when adding ECUs to a network during design phase. Typically chokes are used on CAN, FlexRay, LVDS. To improve the EMC behaviour of communication busses common dedicated EMC Filters are used. They suppress frequencies outside the range, which is needed for the communication of the specific bus E.g. some small capacitors in parallel to ground, resistors and inductivities in series are added to the bus lines in order to prevent the higher harmonics stimulated by the communication on the network The information about the termination is used with in the system configuration process, where the placement of an ECU within a car architecture is generated. Describe a technology were the termination is split in to individual resistors with a capacitive coupling to ground. This technology improves the signal quality. Describe the nominal Value of the termination resistor at the ECU as seen from the communication network. In order to avoid signal reflection and oscillation of the Technical Signal represen-tation the impedance on communication lines have to be defined and matched at the signal destination and the signal source. Some examples: A High-speed CAN network with a twisted pair cable works optimal with an overall impedance of 60 Ohms represented by a 120 Ohm resistor in the ECU at the begin-ning of the network and 120 Ohm in the ECU at the end of a linear network topology. For Low-speed CAN networks in many cases termination resistors of 820 Ohm each are distributed on several ECUs to get good balance between system scalability and signal integrity in real networks without a fixed network topology. The lower bandwidth can tolerate some impedance mismatch. For LIN networks recessive termination is used: The inactive bus signal level is defined by resistors tied to a defined voltage level. An important attribute for communication lines is the presence of a termination resistor and the value of this resistor. The clock delivers the time for the PU and other HW Elements on the ECU. Defines if the clock is adjustable from software. The short-term deviation of the nominal frequency to the real frequency. Jitter is influenced by the circuitry itself, voltage spikes etc. Jitter is critical for communication elements. PLL need/generate jitter for operation. Therefore communication interfaces should operate from an oscillator e.g. quartz directly or use only divider, not a PLL, as clock source. Using PLL for communication interfaces is a very common source for problems in ECU test and integration. The time the clock generation needs to deliver a stable and valid signal. The long-term deviation of the nominal frequency to the real frequency. Influenced by manufacturing, layout, temperature, external components and voltage. Tolerances are critical for timer application and time synchronisation. Defines the type of the clock signal. The clock delivers the time for the PU and other HW Elements on the ECU. The abstract class ECU Electronics HW Element contains all elements and attributes common for all kind of ECU Electronics. Defines if the ECU Electronic can be enabled and disabled. The Communication Transceiver has to transfer and receive the data through the physical link and is the implementation of the OSI layer 1. Communication Transceivers have additional links to the controller/PU to support wake-up feature, enabling/disabling and error indication. Distinguish between different implementations. The Communication Transceiver has to transfer and receive the data through the physical link and is the implementation of the OSI layer 1. Communication Transceivers have additional links to the controller/PU to support wake-up feature, enabling/disabling and error indication. Power Driver HW Element describes a group of electronic devices, which perform signal transformations with hardware devices. The main focus of the ECU Resource Template is the logical description of these elements, necessary for the system generation and relevant for the SW development. The device limits the maximum current conduction. The limit has to be specified. If this element does not occur the HW Element does not provide current limitation. Unit: Ampere The resistance in ON state can be used together with the current through this element to determine the static thermal power dissipation of the element itself and the ECU completely by summing up each element with power dissipation. As the heating up of an power element follows with an exponential delay, the ratio of on and off times is later needed in the system generation process. This information can give the first hint on critical issues of thermal design, but does not replace a complete static and dynamic verification of the thermal layout. Unit: Ohm Defines the general type of the element. Type is a most common naming for an element. Several sets of types exist. Type is mandatory for the usage of the ECU Resource Template. Describe the way the element is reactivated after a self protection sequence was entered Power Driver HW Element describes a group of electronic devices, which perform signal transformations with hardware devices. The main focus of the ECU Resource Template is the logical description of these elements, necessary for the system generation and relevant for the SW development. Describe the status which cause a notification to the controlling devices of an ECU, e.g. to the PU. The device detected a loss of ground situation. The device was forced off, in order to avoid damages by excessive currents. The device detected a too high current. The device detected a too high supply voltage. The device detected a too low curent. The device detected a too low supply voltage. The device detected open loads. This situation is reported to the controlling portion of an ECU, e.g. to the PU. The maximum allowed temperature was detected in the device. A protecting hardware has forced the device off. The device was forced off, in order to avoid damages by excessive currents. The device detected a short to battery situation. The device was forced off, in order to avoid damages by excessive currents. The device detected a short to ground situation. The device was forced off, in order to avoid damages by excessive currents. Describe the status which cause a notification to the controlling devices of an ECU, e.g. to the PU. The Power Driver HW Element / ASIC turns off by internal means in order to protect the device against severe damages. Is protected against loss of ground. Maximal current limits are exceeded. Maximal voltage limits are exceeded. Minimal current limits are exceeded. Minimal voltage limits are exceeded. Is protected against over-temperature. Is protected against reverse battery voltage. The Power Driver HW Element / ASIC turns off by internal means in order to protect the device against severe damages. Define the option of a Power Driver that the output of a Power Driver can be superposed by a PWM signal asserted by a HW Element e.g. a microprocessor. In most cases, the PWM signal is connected by a separate wire, even when the general control information are transmitted by a bus. It defines the upper limit at which the device can fulfil the PWM capability. EMC and power dissipation are increasing almost exponential with the PWM frequency. Choosing PWM frequencies be aware that some effects can cause secondary effects, which can create a audible noise for the user, e.g. a PWM dimmed lamp can be noticed by the driver. Unit: Hz Defines the characteristic, that a Power Driver has to be off at least a minimum time in order to assure the function. Unit: s Defines the characteristic, that a Power Driver has to be on at least a minimum time in order to assure the function. Unit: s Define the option of a Power Driver that the output of a Power Driver can be superposed by a PWM signal asserted by a HW Element e.g. a microprocessor. In most cases, the PWM signal is connected by a separate wire, even when the general control information are transmitted by a bus. The Power Supply HW Element provides information about the power source of the ECU. There can be multiple power supplies within one ECU. Define the capability assigned to the output of the Power Supply HW Element to maintain the output voltage stable for a certain time after the undervoltage status information is asserted. In the ECU Resource Template the Backup Capacity is described as time. The time is dependent from the current consumed by the HW Elements connected to the according output, the SW-functions controlling the ECU hardware and the implementation of the Power Supply HW Element itself. The time has to be calculated from the available capacitors or measured in the application. Example: For the energy storage for airbag applications capacitors stores energy for the airbag ignition for several seconds even the battery is completely disconnected. Example: A combined step up/step down DC/DC converter can deliver a stable 5V volt output even when the input has already dropped to 3V. The undervoltage status is already set at a Vbatt level of 6V. Unit: Ah This value defines the nominal output voltage, which is supplied as default after a reset occured. This attribute is only applicable at power supplies with a programmable output voltage. The maximum voltage that can be supplied. The minimum voltage that can be supplied. Status information that the on-chip temperature on the Power Supply Hardware Element exceed the maximal, defined limit. The power on reset is generated depending on the output voltage. Valid operation of the ECU and the connected HW Elements are only possible if the output voltage is stable and within the specified output voltage range. Therefore most of the Power Supply HW Elements contain a circuitry, which generate a output signal which indicates an instable or unspecified voltage at the output. Some Power Supply HW Elements offer the possibility to adjust the reset thresholds. The reset signal at the power-on reset is delayed by the Power Supply HW Element in order to enable the different ECU HW Elements to enter a stable and defined operation state when the reset signal is released. Unit: s Describe the way the element is reactivated after a self protection sequence was entered Describes the feature of the power supply to turn on the output voltage by an external event. In some cases this feature is coupled with other ECU internal HW elements e.g. transceivers and is the main feature used by the car specific power management. Different to other HW elements with this feature the power supply is the receiver of the signal, as more ECU function is only possible if the power supply is activated. Example: Philips CAN Transceivers have an output called INH, which allow together with some Voltage regulators with wake up capability to wake up the ECU at the presence of a CAN bus telegram. Example: The Wake up Capability is connected to the terminal KL15 (ignition), the ECU is waked up at the presence of KL15. The Power Supply HW Element provides information about the power source of the ECU. There can be multiple power supplies within one ECU. The Power Supply HW Port is used to model the power distribution within the ECU. If the direction is "in" the port is used to describe the power consumption of an HW Element. If the direction is "out" the port is used to describe a power source. The HW Connection between these two HW Ports can only be established between the Power Supply HW Port of the HW Element with direction "out" and a Power Supply HW Port of the Power Supply HW Element with direction "in". Defines if the Power Supply HW Port can be switched off and therefore the supplied HW Element is switched off as well. This feature allows to describe which parts of an ECU are able be disconnected from their power supply based on software interaction. If the Power Supply HW Port has the direction 'in' the supplied HW Element can be switched off. If the Power Supply HW Port has the direction 'out' the power supply can be switched off and therefore all supplied HW Elements are switched off as well (This is used to describe groups of HW Elements that can only be switched off together). When however the whole ECU is disconnected from power the switchable power supply is of course not valid anymore. The Power Supply HW Port is used to model the power distribution within the ECU. If the direction is "in" the port is used to describe the power consumption of an HW Element. If the direction is "out" the port is used to describe a power source. The HW Connection between these two HW Ports can only be established between the Power Supply HW Port of the HW Element with direction "out" and a Power Supply HW Port of the Power Supply HW Element with direction "in". The basic source for time in the ECU. Based on the oscillator the PU clock is generated, but also the communication and other peripherals need timing information (ADC, PWM, timer). Defines if the oscillator is adjustable from software. The short-term deviation of the nominal frequency to the real frequency. Jitter is influenced by the circuitry itself, voltage spikes etc. Jitter is critical for communication elements. Crystals and other oscillating elements have more than one resonant frequencies, which are usually odd harmonics to the basic, fundamental frequencies. For Automotive a basic requirement should be to use only fundamental mode only. Using overtone modes there is a risk, that the oscillator circuitry starts at the fundamental mode after a error in the start up routine. In order to reach an overtone mode the frequency of the fundamental mode, or lower overtones has to be passed during start up. There is a risk that the oscillator locks to this, lower frequency. Therefore Fundamental modes oscillatorts are not so critical for this issue. Fundamental quartz/crystals can reach up to 40 MHz today, above this frequency all quartz/crystals are running in the 3rd, 5th or higher overtone mode. The time the oscillator needs to deliver a stable and valid signal. The long-term deviation of the nominal frequency to the real frequency. Influenced by manufacturing, layout, temperature, external components and voltage. Tolerances are critical for timer application and time synchronisation. The basic source for time in the ECU. Based on the oscillator the PU clock is generated, but also the communication and other peripherals need timing information (ADC, PWM, timer). This port represents the drain of an interrupt request, i.e. the HWElement (in the majority of cases this will be a ProcessingUnit) to which this HWPort is attached is capable of accepting interrupt requests. Defines which hardware resource activate the interrupt. Typically any peripheral HW Element can activate an interrupt. E.g. CAN, SCI, SPI, Timer, ADC. Even simple digital I/O can activate an interrupt. Some microC have in this context dedicatated pins which act only as activation for interrupt. The connection from the according HW Element is made by the HW Port. Interrupt Latency: time passed from the occurrence of the interrupt request until the interrupt service routine is entered - HW: Register organisation; operations are necessary for context save. - SW: As SW can control the enabling/disabling of the interrupt SW determines a great part of the according time. - System: several constraints define the min/max times allowed for software to enable / disable interrupts. Defines if interrupts can be selected to be processed by the interrupt controller. Some processing units offer different interrupt levels. It describes the priority in which the incoming interrupts are handled. This port represents the drain of an interrupt request, i.e. the HWElement (in the majority of cases this will be a ProcessingUnit) to which this HWPort is attached is capable of accepting interrupt requests. This port represents the source of an interrupt request, i.e. the HWElement to which this port is attached is capable of raising interrupt requests. A MPU provides means where the memory access within a defined program flow of a PU is controlled. In case of a failure an exception routine e.g. interrupt is activated. A MPU is implemented as an independent hardware block in a device separate to the processing unit. A MPU does not perform any data manipulation, only in case of an error a change in the processor control flow is forced. The number of individual checked memory ranges is limited to the registers available for specifying the memory ranges. One individual memory range is in the following referenced as MPU Channel. In most cases the MPU consists of a set of registers, which do range checking of the addresses asserted by the program on the address bus as well as the access type to the according address. The checking of the address ranges is also coupled to the address range of the program, which runs under the control of the MPU. The MPU also can be coupled with one of the different processing elements of a device like the PU itself, a DMA or a Coprocessor. In order to have a broad usage of a MPU a specification of filter values is often allowed, so very user specific selection methods are possible. Typical use case for a MPU: A 3rd party software routine is allowed only to access a defined memory-area. Any access outside the defined memory area will be denied and control will be transferred to the supervising operating system. A error handling routine will be started. Defines the number of individual MPU channels are available. A MPU provides means where the memory access within a defined program flow of a PU is controlled. In case of a failure an exception routine e.g. interrupt is activated. A MPU is implemented as an independent hardware block in a device separate to the processing unit. A MPU does not perform any data manipulation, only in case of an error a change in the processor control flow is forced. The number of individual checked memory ranges is limited to the registers available for specifying the memory ranges. One individual memory range is in the following referenced as MPU Channel. In most cases the MPU consists of a set of registers, which do range checking of the addresses asserted by the program on the address bus as well as the access type to the according address. The checking of the address ranges is also coupled to the address range of the program, which runs under the control of the MPU. The MPU also can be coupled with one of the different processing elements of a device like the PU itself, a DMA or a Coprocessor. In order to have a broad usage of a MPU a specification of filter values is often allowed, so very user specific selection methods are possible. Typical use case for a MPU: A 3rd party software routine is allowed only to access a defined memory-area. Any access outside the defined memory area will be denied and control will be transferred to the supervising operating system. A error handling routine will be started. A ProcessingUnit describes the plain processor core. The identifier provides the actual type name of the processing unit. The addressing modes describe the options to access the data from the memory. The kind of architecture The name of the architecture (e.g. ARM, MIPS, PowerPC). The architecture type take influence to the performance index of a PU, but are not necessarily a main topic of software development, as some of the aspects are transparent to the user as the are handled with in the compiler. The last two types are slightly different as they require a detailed planning during system design, how the data must be prepared in order to use the features of an SIMD or MIMD very efficiently. Application like video processing use in general this features by their data format, as every pixel information is formed by the three basic colours and intensity, thus each pixel is represented by four different values, which have to be processed simultaneously. Direct Memory Access is a mechanism for off-loading a PU and having transfer directly between memory and peripherals without involving the PU. In most common PU the DMA mechanism is implemented with a specialised cell (DMA unit) that transfers data between a peripheral device and memory, independent of the processor. The DMA controller becomes the bus master and directs the reads or writes between itself and memory. A typical DMA transfer can be described in three steps: 1. The PU sets up the DMA transfer by supplying the identity of the periphery module, the operation to perform on that device, the memory address that is the source or the destination of the data to be transferred, and the number of bytes to transfer. 2. The DMA starts the operation on the periphery device and arbitrates for the bus. When the data is available, from the periphery device or memory, it transfers the data. The DMA unit supplies the memory address and initiates the next transfer. With this technique, a DMA unit can complete an entire transfer, which may be Kbytes of data, without bothering the PU. Many DMA units contain some memory to allow them to deal flexibly with delays either in transfer or those incurred while waiting to become bus master. 3. Once the DMA transfer is complete, the DMA unit interrupts the processor, which can then determine by interrogating the DMA unit or examining memory whether the entire operation completed successfully. During an active DMA transfer the PU cannot access the involved resources concurrently. Name of the technology used to implement this PU. Defines how many interrupts are allowed to be activated at one time. This entry is mainly defined by the size of the according stack as the data saving mechanism during interrupts and the data passing mechanism during function calls use the stack. The natural data size prvides information which data manipulations are optimized on this PU. The natural data size is typically the Data Register size. The PU is optimised for this data size. Typical natural data size is one of following (in bits): 8, 16, 32, 64, other (12, 20, 80) The attribute describes the typical length of the opcodes. In CISC machines the opcode size is variable due to the opcode itself. In RISC machines the opcode is by definition limited to a defined size. Type definition is used if the PU has more than one opcode set is incorporated. E.g. at the ARM architecture there is the ARM opcode set (size of 32 bit) and the Thumb opcode set (size of 16 bit). Code compression is a technology where the opcodes are stored in a compressed form and are automatically decompressed before execution. The following attributes are opcodes, which are not supported by all PUs. The support of this opcodes has an influence on the performance of the PU. - Bit-manipulation - Multiplication - Division - Multiply Accumulate - Floating-point Support In the future further opcodes may be possible. The special opcodes take important influence to the performance index of a PU, but are not main topic of the software development, as far as high level programming languages are used, due to the fact that these are covered by compiler settings, compiler strategies and software libraries where the direct usage or a SW emulation is available for almost any general use case. For some of these opcodes the main advantage is available only at the level of assembler programming or compiler optimization. A ProcessingUnit describes the plain processor core. The identifier provides the actual type name of the processing unit. This element provides a list of all supported data types and its according data sizes of the described PU. Examples: Boolean (1, 8 bit), Bit String / Bit Field (x bit), Character (8, 16 bit), Signed / unsigned integer (8, 16, 24, 32, 48, 64 bit), Single / double float (56, 64 bit), Fixed point (24 bit), Fractional, Packed (two values handled in one register) The size of the data type. Unit: Bit This element provides a list of all supported data types and its according data sizes of the described PU. Examples: Boolean (1, 8 bit), Bit String / Bit Field (x bit), Character (8, 16 bit), Signed / unsigned integer (8, 16, 24, 32, 48, 64 bit), Single / double float (56, 64 bit), Fixed point (24 bit), Fractional, Packed (two values handled in one register) The user available registers are a part of the programming model that consists of: Memory organisation and segmentation, Data types, Registers, Instruction format, Operand selection, Interrupts and exceptions. Basically the register model contains the registers that are interest to the applications programmer; these registers can be grouped into three basic categories: - General registers: These general-purpose registers are used primarily to contain operands for arithmetic and logical operations. - Segment registers: These special-purpose registers permit software designers to choose either a flat or segmented model of memory organisation. These registers determine, at any given time, which segments of memory are currently addressable. - Status and instruction registers: These special-purpose registers are used to record and alter certain aspects of the processor state. The register model is only valuable data for low level programming, e.g assembler programming. The register model, along with the available OP codes takes influence on the performance of the PU. The most general impact of the register model to software is number of registers which have to be handled during interrupts or function calls. Describes how many registers are available of the specified type. Describes the kind of register. The user available registers are a part of the programming model that consists of: Memory organisation and segmentation, Data types, Registers, Instruction format, Operand selection, Interrupts and exceptions. Basically the register model contains the registers that are interest to the applications programmer; these registers can be grouped into three basic categories: - General registers: These general-purpose registers are used primarily to contain operands for arithmetic and logical operations. - Segment registers: These special-purpose registers permit software designers to choose either a flat or segmented model of memory organisation. These registers determine, at any given time, which segments of memory are currently addressable. - Status and instruction registers: These special-purpose registers are used to record and alter certain aspects of the processor state. The register model is only valuable data for low level programming, e.g assembler programming. The register model, along with the available OP codes takes influence on the performance of the PU. The most general impact of the register model to software is number of registers which have to be handled during interrupts or function calls. Describes the different possible kinds of access to the memory and the time these access takes. The element access type describes the different possible kinds of access to the memory. Describes the different possible kinds of access to the memory and the time these access takes. This connection is used to connect Memory HWPort on the same hierarchical level (inside one HW Container). Defines the base address of the memory within the ECU template. The same base address might be defined multiple times according to the access type and the architecture. A base address is uniquely bound to a defined memory segment. When a PU stores data in a memory the ordering of the bytes can be done in two different ways. This storing scheme is normally fixed in the PU when more than one byte is stored in the memory. When the least significant byte is stored at the lowest address this architecture is called "mostSignificantByteLast" (aka little endian) and when the most significant byte is stored at the lowest address this is called "mostSignificantByteFirst" (aka big endian). Some CPU architectures like ARM and PowerPC can be configured to handle both little and big endian. This is called bi-endian. ByteOrder is very important when you communicate between different PUs or ECUs. A memory segment may be cacheable. This has to be defined in the description of the segment connection. The segment usage is defined in the linker memory map. Usually it is fixed within an operation mode but different operations modes have different memory usage. The element segment usage contains the following attributes. - Data: The attribute data is used for all kind of data: constant, variable, calibration, system initialisation, system configuration, etc. - Code: The attribute code is used for the program code itself. - Stack: Memory usable for a system or software stack is in some cases only available on limited number of segments within a PU. - Boot: The boot memory is used to store program and data for the start up or test of an ECU. Within the boot program the basic ECU initialisation is performed. Furthermore some system maintenance programs, like the set-up for flash programming or loading of data via communication interface, can be part of the boot program. Boot memory is in general not a subject of AUTOSAR SW. -- Boot sector: Boot sector is the location in memory, preferable Flash or ROM, where the boot program is stored. The location of the boot sector might be dependant on the PU architecture as reset and interrupt vectors must be accessible during boot. The boot sector should be separated from other user accessible Flash or implemented as ROM. In Flash the boot sector should have the appropriate array size, some few kilobyte and provide protection mechanism against unintended erasure or system manipulation. A system may have different boot sectors, one accessible only for testing the PU during the manufacturing and configuration of the PU, in factory test mode or some initial program mode, and a user boot mode. -- Mapping of boot sector: Mapping of the boot sector is useful to enhance the boot sequence and the release of the used resources during the boot phase at the later user mode, e.g. the use of reset vector and interrupt vector can be improved. This connection is used to connect Memory HWPort on the same hierarchical level (inside one HW Container). This connection is used to delegate a Memory HW Port to the outside of a HW Container. Typically this will used internally of a micro-controller. Describes one volatile memory segment. Some memory architectures are organised for bigger natural data size than accessed by the PU. In this case memory might not be used completely and some memory locations are left blank due to misalignment. The overall memory size is not used by code or data. Misalignment may be recovered by special mechanisms provided by hardware or software. In this case the access time will be increased. Certain PU architectures do not allow misalignment in code or data generally. Unit: Byte As memory holds the executable program as well as the according data, memory needs a level of quality and reliability according to the purpose of the ECU. In most applications today memory is the biggest homogeneous hardware block; therefore quality and reliability of memory have the biggest impact on ECU performance and availability. With the introduction of non-volatile memory and the use of huge DRAM memories the aspect of quality and reliability gains more importance. Despite all Zero-defect programs of the semiconductor suppliers a defect rate in the range of 1 to 5 ppm must be considered as given even for critical applications. Separate quality data for Endurance and Data retention can be available also. The biggest value for ppm rates is used as a quality factor. Unit: ppm A value that determines the amount of bytes within the memory segment. An ECU for AUTOSAR always contains at least one memory segment. Within a single ECU different memory types and access types can be used simultaneously. An ECU may consist of different parts that carry one or more memories. Segment size is defined in the terms of Bytes. The overall amount of memory is the sum of all available memory segments. For different types of memory only the sum of the same type gives a useful overall sum. Unit: Byte Separate memories are required for safety-relevant functions and redundancy requirements. Describes one volatile memory segment. Describes one non-volatile memory segment. Program and erase cycles are a stress to the memory cell, therefore endurance is characterised by the number of erase/program cycles the memory can survive exceeding the prescribed failure rate. Unit: No of cycles. Data retention time is the time between programming a sample of non-volatile memory and the observation of a prescribed failure rate when verifying the programmed pattern. The time is dependent on the chosen technology for the integrated memory cell. Unit: Years Additional to verify, all data are read back with a different set-up of the threshold of the sense amplifier of the programmed cell. With this method besides the logical correctness, the sufficient amount of electrical charges, which represents the stored data is checked. Furthermore the content of the memory and the correctness and the quality of the programming tools can be verified. Performing the margin read allow the prediction of the data retention. The feature of margin read is a characteristic of a memory, which is not available at all devices. Margin read is available for flash technology only. For an erasable memory it's usually the same size of the segment as for the segment size which can be erased at a time. If the size of an erasable segment is different shall the size of the erasable segment be entered in the table. Unit: Byte Some memory types have not the same segment size as in the case when data is written to the memory. For example, a specific flash memory you must write 128 bytes once even if the segment size is 16 kBytes. Unit: Byte Describes one non-volatile memory segment. The element defines the number of bits that can be transferred from the PU to the memory device or vice versa. The width of data bus are important characteristics. All technical characteristics of the memory are covered by the access time. Unit: Bit the type of port HW Element Actuator definition. Defines the way the actuator is seen after power on. On Bi-Stable or Multistable actuators the software has to know the status of this device after reset or Power On. Each actuator has a control input that determines its behaviour If there is a specific default value is available. E.g. Valve status = off; Defines the most typical electrical behaviour of the system. This information is necessary for the ECU generation process and for tools which check for later interaction of the different component. (avoid resonance's, planning of the ECU power management). Number of activation cycles the actuator is designed for. Defines the way the movement is controlled by AUTOSAR. Positional feedback can be provided by the actuator by the conglomeration of the requisite actuator and sensor primitives. HW Element Actuator definition. The common attributes for sensors and actuators. The sensor and actuators can be connected via a Peripheral HW Port, a Communication HW Port or a Power Driver HW Port. Defines the error in the representation of the Technical Signal in the data format This applies only if the Technical Signal is encoded before it is transferred to the ECU Electronics (e.g. via Communication Transceiver HW Port). Defines the granularity of the representation of the Technical Signal in the data format. This applies only if the Technical Signal is encoded before it is transferred to the ECU Electronics (e.g. via Communication Transceiver HW Port). Defines the general type of the sensor/actuator type is a most common naming for a sensor/actuator and is an open list and is not restricted to the following items. Several sets of types exist. Type is mandatory for the usage of the template - Sensor: Temperature, Pressure, Distance, Hall - Actuator: DC Motor, Valve, Relay, Display The Display HW element derives from HW Sensor Actuator and can be connected to a PU via a serial or parallel interface. For the parallel mode the display can be connected to the data bus and address bus of a PU or to a peripheral. The most common serial interface for displays are: - I2C - SPI The most common physical interface for high resolution displays are the LVDS interface (Low Voltage Differential Signalling). This interface has three different lines for colours (RGB) and additional lines for control signals. Defines whether the display has a background lighting. This eases the readability of the displays during bad daylight conditions. Defines the visibility of the display. If the display can present numerical, alpha-numerical, semi-graphical or graphical objects. If the display has an in-built character generator. Defines which character set that can be handled by the display. There is a number of standardised character sets like ISO-8859-1 or Unicode. If the display can show objects in monochrome, grey scale or in colour. Defines the ratio of the display resolution in horizontal versus vertical direction (e.g. 16 to 9). Defines the number of the smallest graphical elements which can be displayed in horizontal direction. Defines the number of the smallest graphical elements which can be displayed in vertical direction. Defines how long it takes for the display to show a changed element at -20 degree C. Defines the angle range where the display can be observed. The Display HW element derives from HW Sensor Actuator and can be connected to a PU via a serial or parallel interface. For the parallel mode the display can be connected to the data bus and address bus of a PU or to a peripheral. The most common serial interface for displays are: - I2C - SPI The most common physical interface for high resolution displays are the LVDS interface (Low Voltage Differential Signalling). This interface has three different lines for colours (RGB) and additional lines for control signals. HW Element Sensor definition. Defines the quality of the data received from a sensor. Depending on this information later processing on the signal has to be done in HW or SW. HW Element Sensor definition. In the context of a component there is no typed re-use of CalprmElementPrototype entities A ServiceConnectorPrototype connects a PortPrototype owned by an ComponentPrototype with the service PortPrototype owned by the ServiceComponentPrototype. A ServiceConnectorPrototype is only added to the model in ECU Configuration phase for the specific purpose of configuring services within an EcuSwComposition. A ServiceConnectorPrototype connects a PortPrototype owned by an ComponentPrototype with the service PortPrototype owned by the ServiceComponentPrototype. A ServiceConnectorPrototype is only added to the model in ECU Configuration phase for the specific purpose of configuring services within an EcuSwComposition. A CompositionType aggregates ComponentPrototypes (that in turn are typed by ComponentTypes) as well as ConnectorPrototypes for primarily connecting ComponentPrototypes among each others and towards the surface of the CompositionType. By this means hierarchical structures of software-components can be created. A CompositionType aggregates ComponentPrototypes (that in turn are typed by ComponentTypes) as well as ConnectorPrototypes for primarily connecting ComponentPrototypes among each others and towards the surface of the CompositionType. By this means hierarchical structures of software-components can be created. AssemblyConnectorPrototypes are exclusively used to connect ComponentPrototypes in the context of a CompositionType. AssemblyConnectorPrototypes are exclusively used to connect ComponentPrototypes in the context of a CompositionType. A delegation connector delegates one inner PortPrototype (a port of a component that is used inside the composition) to a outer PortPrototype of compatible type that belongs directly to the composition (a port that is owned by the composition). A delegation connector delegates one inner PortPrototype (a port of a component that is used inside the composition) to a outer PortPrototype of compatible type that belongs directly to the composition (a port that is owned by the composition). Role of a software component within a composition. Role of a software component within a composition. Annotation to a port used for calibration regarding a certain CalprmElement. Annotation to a port used for calibration regarding a certain CalprmElement. Annotation to a "delegated port" to specify the Signal Fan In or Signal Fan Out inside the Composition Type. Specify the Signal Fan In or Signal Fan Out inside the Composition Type Annotation to a "delegated port" to specify the Signal Fan In or Signal Fan Out inside the Composition Type. The IoHwAbstractionPort Annotation will only be used from a sensor- or an actuator component while interacting with the IoHwAbstraction layer In case of a SET operation, the age will be interpreted as Delay while in a GET operation (input) it specifies the Lifetime of the signal within the IoHwAbstraction Layer Specifies the maximum value of the Range the ECU-Signal is supposed to have Specifies the maximum value of the Range the ECU-Signal is supposed to have. This value is determined by an appropriate combination of the range, the unit as well as the data-elements type, i.e. (BswRangeMax-BswRangeMin) / (2^datatypelength - 1) This attribute is used to indicate what kind of filtering/debouncing has been put to the signal in the IoHwAbstraction layer. rawData means that no modification of the signal has been applied.This is the default value debounceData means that the signal is a mean value waitTimeData means that the signal is delivered by a GET operation after a certain amount of time This attribute indicates to the connected SensorActuatorSoftwareComponentType whether the DataElementPrototype can be used to generate pulse test sequences using the IoHwAbstraction layer These are either electrical units like Volts (V) or time units like milliseconds (ms). The unit is set according to the ECU Input signal class which is either analogue or modulation The IoHwAbstractionPort Annotation will only be used from a sensor- or an actuator component while interacting with the IoHwAbstraction layer This attribut indicates wheter the software component reading this value provides dedicated runnables to handle a wake-up call by the IoHwAbstraction layer. This feature is used for input signals only. Each time the level of the associated data-element changes a dedicated GET operation has to be invoked by the sensor software component, i.e. an appropriate runnable has to be started. Annotation of a receiver port, specifying properties of data elements that don't affect communication or generation of the RTE. The given attributes are requirements on the required data. The maximum allowed age of the signal since it was originally read by a sensor. This is a requirement specified on the receiver side. Annotation of a receiver port, specifying properties of data elements that don't affect communication or generation of the RTE. The given attributes are requirements on the required data. Annotation of a sender port, specifying properties of data elements that don't affect communication or generation of the RTE. Annotation of the data elements in a port that realizes a sender/receiver interface. Flag whether this data element was not measured directly but instead was calculated from possibly several other measured or calculated values. This min or max has not to be mismatched with the min- and max for data-value in a compu-method. For example, this annotation shows when the result of the calculation performed in a RunnableEntity owned by one AtomicSoftwareComponentType is transmitted to another AtomicSoftwareComponentType whose RunnableEntity will use this value as a limit, e.g. the max.power which can be used by that software-component, or the current min. slip. A constant array, which refers to its elements by index. A constant array, which refers to its elements by index. Boolean constant expression. The Boolean value. Boolean constant expression. Character constant description. The character value (a string of length 1). Character constant description. Instead of defining this constant inline, another constant is referenced. Instead of defining this constant inline, another constant is referenced. Specification of a constant that can be part of a package, i.e. it can be defined stand-alone. Specification of a constant that can be part of a package, i.e. it can be defined stand-alone. Constant integer value. The value. Constant integer value. An opaque literal. The string encodes an array of bytes in the following syntax "ae:05:fe" An opaque literal. Constant description for real values. The numeric value itself. Constant description for real values. A constant string. The string itself. A constant string. Use <v> to enter a numerical value. msr.id="type__V_TYPE" Value calculated via a system constant. This element is included in every case, where parameters should be generated from numerical values during compile time (not runtime!). Thus for example, the influence of the cylinder number on conversion formulae, can be introduced in a repeatable manner. asam.useCase="MDX";msr.id="type__VF_TYPE";msr.isGroupOnly="true" <vt> represents one particular textual value of the calibration item. asam.harmonizedObject="VT";asam.useCase="MDX";msr.id="type__VT_TYPE";msr.isGroupOnly="true" <vt> represents one particular textual value of the calibration item. asam.harmonizedObject="VT";asam.useCase="MDX";msr.id="type__VT_TYPE";msr.isGroupOnly="true" Use <v> to enter a numerical value. msr.id="COMPU-CONST_numericContent_TYPE__V";msr.tbdString="true";xml.sequenceOffset="50" This class represents a calculation formula as a simple arithmetical expression. string f(x): function to calculate the physical value from the binary, control unit internal value. The interpretation proceeds from left to right for operations of the same operation preferences. Operator preferences, such as power before product/quotient before sum/difference before shift left before shift right before logical AND before logical OR are taken into account. Brackets are allowed and should be used in order to exclude interpretation doubt. For more details refer to ASAM Harmonized Data Objects v1.1 Chapter 9.3.11. Note that this element is a mixed string since a future variant mechanism might use placeholdes to represent references to other objects of the metamodel. As of August 2007 within ASAM there are slightly different syntaxes. One from ASAM-HDO (GenericMath) and the one from SwDataDependency: The difference is mainly between available functions and operators. Nevertheless we use the same class for now. numeric_expression ::= ( "-"expression ) | ( expression ( "+" | "-" | "*" | "/" | "^") expression ) expression ::= ( number | variable | numeric_expression | ( "(" expression ")" ) | sinus_statement | cosinus_statement | sqrt_statement ) | expression {white-space} sinus_statement ::= "sin" "(" expression ")" cosinus_statement ::= "cos" "(" expression ")" sqrt_statement ::= "sqrt" "(" expression ")" number ::= integer_literal | float_literal variable ::= Any valid Object in question integer_literal ::= ( "1..9" { "0..9" } ) | ( "0" "x" "0..9a..f" { "0..9a..f" } ) float_literal ::= ( decimal_digits "." decimal_digits exponent_part ) | ( "." decimal_digits exponent_part ) | ( decimal_digits exponent_part ) decimal_digits ::= "0..9" { "0..9" } exponent_part ::= "e" "+" | "-" decimal_digits white-space ::= tabulator | blank | newline | carriage_return | {tabulator | blank | newline | carriage_return } tabulator ::= \t blank ::= " " newline ::= \n carriage_return ::= \c asam.harmonizedObject="ASAM-COMPU-GENERIC-MATH";msr.id="type__COMPU-GENERIC-MATH_TYPE";msr.isGroupOnly="true" Placeholder to describe an indicator of a language level for the mathematics e.g. INFORMAL, ASAMHDO. May be refined by particular usecases. msr.id="COMPU-GENERIC-MATH_TYPE__COMPU-GENERIC-MATH_TYPE__LEVEL";xml.attribute="true" This class represents a calculation formula as a simple arithmetical expression. string f(x): function to calculate the physical value from the binary, control unit internal value. The interpretation proceeds from left to right for operations of the same operation preferences. Operator preferences, such as power before product/quotient before sum/difference before shift left before shift right before logical AND before logical OR are taken into account. Brackets are allowed and should be used in order to exclude interpretation doubt. For more details refer to ASAM Harmonized Data Objects v1.1 Chapter 9.3.11. Note that this element is a mixed string since a future variant mechanism might use placeholdes to represent references to other objects of the metamodel. As of August 2007 within ASAM there are slightly different syntaxes. One from ASAM-HDO (GenericMath) and the one from SwDataDependency: The difference is mainly between available functions and operators. Nevertheless we use the same class for now. numeric_expression ::= ( "-"expression ) | ( expression ( "+" | "-" | "*" | "/" | "^") expression ) expression ::= ( number | variable | numeric_expression | ( "(" expression ")" ) | sinus_statement | cosinus_statement | sqrt_statement ) | expression {white-space} sinus_statement ::= "sin" "(" expression ")" cosinus_statement ::= "cos" "(" expression ")" sqrt_statement ::= "sqrt" "(" expression ")" number ::= integer_literal | float_literal variable ::= Any valid Object in question integer_literal ::= ( "1..9" { "0..9" } ) | ( "0" "x" "0..9a..f" { "0..9a..f" } ) float_literal ::= ( decimal_digits "." decimal_digits exponent_part ) | ( "." decimal_digits exponent_part ) | ( decimal_digits exponent_part ) decimal_digits ::= "0..9" { "0..9" } exponent_part ::= "e" "+" | "-" decimal_digits white-space ::= tabulator | blank | newline | carriage_return | {tabulator | blank | newline | carriage_return } tabulator ::= \t blank ::= " " newline ::= \n carriage_return ::= \c asam.harmonizedObject="ASAM-COMPU-GENERIC-MATH";msr.id="type__COMPU-GENERIC-MATH_TYPE";msr.isGroupOnly="true" This property specifies, how the physical value shall be displayed e.g. in documents or measurement and calibration tools. msr.id="COMPU-METHOD_TYPE__DISPLAY-FORMAT";msr.tbdString="true";xml.sequenceOffset="20" Use <v> to enter a numerical value. xml.sequenceOffset="30";msr.id="COMPU-NOMINATOR_DENOMINATOR_TYPE__V" This element specifies a short name for the particular scale. The name can for example be used to derive a programming language identifier. msr.id="COMPU-SCALE_TYPE__SHORT-LABEL";msr.tbdString="true";xml.sequenceOffset="20" This class represents a physical dimension. If the physical dimension of two units is identical a conversion between them is possible. The conversion between units is related to the definition of the physical dimension. asam.harmonizedObject="PHYSICAL-DIMENSION";asam.useCase="MDX";msr.id="type__PHYSICAL-DIMENSION_TYPE" The exponent of the physical dimension "length" msr.id="PHYSICAL-DIMENSION_TYPE__LENGTH-EXP";msr.tbdString="true";xml.sequenceOffset="20" The exponent of the physical dimension "mass" msr.id="PHYSICAL-DIMENSION_TYPE__MASS-EXP";msr.tbdString="true";xml.sequenceOffset="30" The exponent of the physical dimension "time" msr.id="PHYSICAL-DIMENSION_TYPE__TIME-EXP";msr.tbdString="true";xml.sequenceOffset="40" the exponent of the physical dimension "electric current" msr.id="PHYSICAL-DIMENSION_TYPE__CURRENT-EXP";msr.tbdString="true";xml.sequenceOffset="50" The exponent of the physical dimension "temperature" msr.id="PHYSICAL-DIMENSION_TYPE__TEMPERATURE-EXP";msr.tbdString="true";xml.sequenceOffset="60" The exponent of the physical dimension "quantity of substance" msr.id="PHYSICAL-DIMENSION_TYPE__MOLAR-AMOUNT-EXP";msr.tbdString="true";xml.sequenceOffset="70" The exponent of the physical dimension "luminous intensity" msr.id="PHYSICAL-DIMENSION_TYPE__LUMINOUS-INTENSITY-EXP";msr.tbdString="true";xml.sequenceOffset="80" This class represents a physical dimension. If the physical dimension of two units is identical a conversion between them is possible. The conversion between units is related to the definition of the physical dimension. asam.harmonizedObject="PHYSICAL-DIMENSION";asam.useCase="MDX";msr.id="type__PHYSICAL-DIMENSION_TYPE" This is a physical measurement unit. All units that might be defined should stem from SI units. In order to convert one unit into another factor and offset are defined. For the calculation from SI-unit to the defined unit the factor (factorSiToUnit ) and the offset (offsetSiToUnit ) are applied: unit = siUnit * factorSiToUnit + offsetSiToUnit For the calculation from a unit to SI-unit the reciprocal of the factor (factorSiToUnit ) and the negation of the offset (offsetSiToUnit ) are applied: siUnit = (unit - offsetSiToUnit) / factorSiToUnit asam.harmonizedObject="ASAM-UNIT";asam.useCase="MDX";msr.id="type__UNIT_TYPE" this is the factor for the convesion from and to siUnits. msr.id="UNIT_TYPE__FACTOR-SI-TO-UNIT";msr.tbdString="true";xml.sequenceOffset="30" this is the offset for the convesion from and to siUnits. msr.id="UNIT_TYPE__OFFSET-SI-TO-UNIT";msr.tbdString="true";xml.sequenceOffset="40" This is a physical measurement unit. All units that might be defined should stem from SI units. In order to convert one unit into another factor and offset are defined. For the calculation from SI-unit to the defined unit the factor (factorSiToUnit ) and the offset (offsetSiToUnit ) are applied: unit = siUnit * factorSiToUnit + offsetSiToUnit For the calculation from a unit to SI-unit the reciprocal of the factor (factorSiToUnit ) and the negation of the offset (offsetSiToUnit ) are applied: siUnit = (unit - offsetSiToUnit) / factorSiToUnit asam.harmonizedObject="ASAM-UNIT";asam.useCase="MDX";msr.id="type__UNIT_TYPE" The maximum number of elements that the array can contain. This datatype represents a set containing the logical value true and false java.instanceClass="java.lang.Boolean" A primitive datatype consists of a set of allowed values. This Datatype represents an array of exactly numberOfBits bits. It is called "opaque" because this array of bits should be transported "as is" by the AUTOSAR RTE. java.instanceClass="java.lang.String" The number of bits that are used to make up the opaque type. This Datatype represents an array of exactly numberOfBits bits. It is called "opaque" because this array of bits should be transported "as is" by the AUTOSAR RTE. java.instanceClass="java.lang.String" Abstract class for specifying a range from lower limit to upper limit. An element in a record. This represents a string of characters out of the character-set specified by the given encoding. The maxNumberOfChars is the maximal number of characters which can be stored within the String. The actual number of bytes that is required to represent the string can be calculated out of maxNumberOfChars and the encoding: bytes required to represent the string = maxNumberOfChars * (max bytes per character using the given encoding) + 1 (terminating null) java.instanceClass="java.lang.String" Specification of character encoding, e. g. ISO-8859-1. The maxNumberOfChars is the maximum number of characters that can be stored in the string. This represents a string of characters out of the character-set specified by the given encoding. The maxNumberOfChars is the maximal number of characters which can be stored within the String. The actual number of bytes that is required to represent the string can be calculated out of maxNumberOfChars and the encoding: bytes required to represent the string = maxNumberOfChars * (max bytes per character using the given encoding) + 1 (terminating null) java.instanceClass="java.lang.String" This data-type are the integers in the interval defined by the Range. java.instanceClass="java.lang.Integer" This represents a range of reals that can be represented by either the IEEE 754 "Single Precision" (encoding is "Single") or IEEE 754 "Double Precision" (encoding is "Double") arithmetic. Note that these standards include representations for +infinity, -infinity, QNaN and SNaN. When defining a RealType, one must indicate whether these special values are allowed or not. java.instanceClass="java.lang.Float" Denotes whether this data type permits for "not a number" being represented by the type xml.name="ALLOW-NAN" Denotes the precision of the RealType This represents a range of reals that can be represented by either the IEEE 754 "Single Precision" (encoding is "Single") or IEEE 754 "Double Precision" (encoding is "Double") arithmetic. Note that these standards include representations for +infinity, -infinity, QNaN and SNaN. When defining a RealType, one must indicate whether these special values are allowed or not. java.instanceClass="java.lang.Float" This represents a character belonging to the character-set specified in the encoding. The semantics are built-in into this datatype. java.instanceClass="java.lang.Character" Specification of character encoding, e.g. ISO-8859-1 This represents a character belonging to the character-set specified in the encoding. The semantics are built-in into this datatype. java.instanceClass="java.lang.Character" Base class for prototypical roles of a datatype. This is a user-defined error that is associated with an element of an AUTOSAR interface. It is specific for the particular functionality or service provided by the AUTOSAR software component. The RTE generator is forced to assign this value to the corresponding error symbol. Note that for error codes certain ranges are predefined (see RTE specification). This is a user-defined error that is associated with an element of an AUTOSAR interface. It is specific for the particular functionality or service provided by the AUTOSAR software component. The ModeDeclarationGroupPrototype specifies the set of Modes (ModeDeclarationGroup) that is supported by a ComponentType. The ModeDeclarationGroupPrototype specifies the set of Modes (ModeDeclarationGroup) that is supported by a ComponentType. An operation declared within the scope of a client/server interface. An operation declared within the scope of a client/server interface. An argument of an operation, much like a data element, but also carries direction information and is associated with a particular operation. An argument of an operation, much like a data element, but also carries direction information and is associated with a particular operation. Abstract base class for an interface that is either provided or required by a port of a software component. This flag is set, if the PortInterface is to be used for communication between an ApplicationSoftwareComponentType and a ServiceComponentType (namely an AUTOSAR Service, ECU abstraction or Complex Driver) located on the same ECU. Otherwise the flag is not set. A client/server interface declares a number of operations that can be invoked on a server by a client. A client/server interface declares a number of operations that can be invoked on a server by a client. A sender/receiver interface declares a number of data elements to be sent and received. A sender/receiver interface declares a number of data elements to be sent and received. A data element of a sender-receiver interface, supporting signal like communication patterns. Qualifies whether the content of the data element is queued. If it is queued, then the data element has "event" semantics, i.e. data elements are stored in a queue and all data elements are processed in "first in first out" order. If it is not queued, then the "last is best" semantics applies. Please note: Depending on the read access cycle to the data element some values might not be processed by the receiver. A data element of a sender-receiver interface, supporting signal like communication patterns. Declaration of one Mode. The name and semantics of a special mode is not defined in the metamodel. Collection of references to the Modes that disable the RTEEvent Collection of references to the Modes that disable the RTEEvent A collection of Mode Declarations. A collection of Mode Declarations. Communication attributes for both sender /server port (P-Port and sender-receiver interface). Length of call queue on the server side. The queue is implemented by the RTE. The value must be greater or equal to 0. Setting the value of queueLength to 0 implies non-queued communication. Communication attributes for both sender /server port (P-Port and sender-receiver interface). Requests acknowledgements that a mode switch has been proceeded successfully Number of seconds before an error is reported or in case of allowed redundancy, the value is sent again. Requests acknowledgements that a mode switch has been proceeded successfully Communication attributes for a sender port (P-Port and sender-receiver interface). Requests transmission acknowledgement that data has been sent successfully. Success/failure is reported via a SendPoint of a Runnable. Number of seconds before an error is reported or in case of allowed redundancy, the value is sent again. Requests transmission acknowledgement that data has been sent successfully. Success/failure is reported via a SendPoint of a Runnable. Communication attributes specific to distribution of data (P-Port, sender-receiver interface and data element carries "data" opposed to carrying an "event"). Flag whether the component can actively invalidate data. Communication attributes specific to distribution of data (P-Port, sender-receiver interface and data element carries "data" opposed to carrying an "event"). Communication attributes specific to distribution of events (P-Port, sender-receiver interface and data element carries an "event"). Communication attributes for a server port (P-Port and client-server interface). Length of call queue on the server side. The queue is implemented by the RTE. Communication attributes for a server port (P-Port and client-server interface). Receiver specific communication attributes (R-Port and sender-receiver interface). Communication attributes specific to unqueued receiving. Specify the amount of time (in seconds) after which the software component (via the RTE) needs to be notified if the corresponding data item have not been received according to the specified timing description. Specifies strategy of handling the reception of invalidValue. Time allowed for resynchronization of data values after current data is lost, e.g. after an ECU reset. Communication attributes specific to unqueued receiving. Communication attributes specific to queued receiving. Length of queue for received events. Communication attributes specific to queued receiving. Client specific communication attributes (R-Port and client-server interface). Client specific communication attributes (R-Port and client-server interface). Resources needed by the allocation of PerInstanceMemory for each SWC instance. Note that these resources are not covered by an ObjectFileSection, because they are supposed to be allocated by the RTE. Required alignment (1,2,4,...) of the referenced PerInstanceMemory Size (in bytes) of the reference perInstanceMemory Resources needed by the allocation of PerInstanceMemory for each SWC instance. Note that these resources are not covered by an ObjectFileSection, because they are supposed to be allocated by the RTE. Identify a specific RTE vendor. This information is potentially important at the time of integrating (in particular: linking) the application code with the RTE. The semantics is that (if the association exists) the corresponding code has been created to fit to the vendor-mode RTE provided by this specific vendor. Attempting to integrate the code with another RTE generated in vendor mode is in general not possible. The internal behavior of an atomic software component describes the RTE relevant aspects of a component, i.e. the runnable entities and the events they respond to. Indicate whether the corresponding software-component can be multiply instantiated on one ECU. In this case the attribute will result in an appropriate component API on programming language level (with or without instance handle). The internal behavior of an atomic software component describes the RTE relevant aspects of a component, i.e. the runnable entities and the events they respond to. The runnable entities are the smallest code-fragments that are provided by the component and are executed in the RTE. Runnables are for instance set up to respond to data reception or operation invocation on a server. Normally, this is FALSE. When this is TRUE, it is allowed that this runnable entity is invoked concurrently (even for one instance of the SW-C), which implies that it is the responsibility of the implementation of the runnable to take care of this form of concurrency. Specifies the time in seconds which two starts of a RunnableEntity are guaranteed to be separated. The symbol describing this runnable's entry point. This is considered the API of the runnable and is required during the RTE contract phase. The runnable entities are the smallest code-fragments that are provided by the component and are executed in the RTE. Runnables are for instance set up to respond to data reception or operation invocation on a server. Options how to generate the signatures of calls for an AtomicSoftwareComponentType in order to communicate over a PortPrototype (for calls into a RunnableEntity as well as for calls from a RunnableEntity to the PortPrototype). If set to true, the software-component is able to use the API reference for deriving a pointer to an object. true: Specifies an "indirect API" to be generated for the associated port, which means that the SWC is able to access the actions on a port via a pointer to an object representing a port. This allows e.g. iterating over ports in a loop. This option has no effect for PPorts of client/server interfaces. Options how to generate the signatures of calls for an AtomicSoftwareComponentType in order to communicate over a PortPrototype (for calls into a RunnableEntity as well as for calls from a RunnableEntity to the PortPrototype). The event is raised when the referenced mode have been received or an error occurs. The event is raised when the referenced mode have been received or an error occurs. This event is raised when an asynchronous server call is finished. This event is raised when an asynchronous server call is finished. The event is raised when the referenced data elements have been sent or an error occurs. The event is raised when the referenced data elements have been sent or an error occurs. The event is raised when the referenced data elements are received. The event is raised when the referenced data elements are received. This event is raised by the RTE when the Com layer detects and notifies an error concerning the reception of the referenced data element. This event is raised by the RTE when the Com layer detects and notifies an error concerning the reception of the referenced data element. TimingEvent references the runnable that need to be started in response to the TimingEvent Period of timing event in seconds. TimingEvent references the runnable that need to be started in response to the TimingEvent The OperationInvokedEvent references the OperationPrototype invoked by the client. The OperationInvokedEvent references the OperationPrototype invoked by the client. This defines a wait-point for which the runnable can wait. Time in seconds before the waitpoint times out and the blocking wait call returns with an error indicating the timeout. This defines a wait-point for which the runnable can wait. This event is listening to mode changes coming from the StateManager. Specifies if the event is activated on entering or exiting the referenced Mode. This event is listening to mode changes coming from the StateManager. Abstract base class for all RTE-related events A ModeSwitchPoint is required by a RunnableEntity owned a Mode Manager. Its semantics implies the ability to initiate a mode switch. A ModeSwitchPoint is required by a RunnableEntity owned a Mode Manager. Its semantics implies the ability to initiate a mode switch. When a runnable has a serverCallPoint, it has the possibility to invoke any of the operations of a specific rport of the component. Time in seconds before the server call times out and returns with an error message. It depends on the call type (synchronous or asynchronous) how this is reported. This means that the runnable will block for a response from the server. An asynchronous server call-point is used for asynchronous invocation of an operation prototype. It is associated with AsynchronousServerCallReturnsEvent, this RTEEvent notifies the completion of the required operation or a timeout, this event can be waited for or it can lead to the invocation of a runnable. IMPORTANT: a server-call-point cannot be used concurrently. Once the client runnable has made the invocation, the server-call-point cannot be used until the call returns (or an error occurs!) at which point the server call-point becomes available again... A DataReceivePoint allows a RunnableEntity to explicitly query for received information, thereby blocking write access to the same information only for a very brief period. A DataReceivePoint allows a RunnableEntity to explicitly query for received information, thereby blocking write access to the same information only for a very brief period. The presence of a DataReadAccess implies that a RunnableEntity needs access to a DataElementPrototype in an RPortPrototype. The RunnableEntity will not modify the contents of the data but only read the information. The RunnableEntity expects that the contents of this data does NOT change during the entire duration of its execution. The presence of a DataReadAccess implies that a RunnableEntity needs access to a DataElementPrototype in an RPortPrototype. The RunnableEntity will not modify the contents of the data but only read the information. The RunnableEntity expects that the contents of this data does NOT change during the entire duration of its execution. The presence of a DataWriteAccess means that the RunnableEntity will potentially modify the DataElementPrototype in the PPortPrototype. The RunnableEntity has free access to the DataElementPrototype while it is running. The RunnableEntity has the responsibility to make sure that the DataElementPrototype is in a consistent state when it returns. When using DataWriteAccess the new values of the DataElementPrototype is not made available via the communication infrastructure before the RunnableEntity returns (exits the "Running" state). The presence of a DataWriteAccess means that the RunnableEntity will potentially modify the DataElementPrototype in the PPortPrototype. The RunnableEntity has free access to the DataElementPrototype while it is running. The RunnableEntity has the responsibility to make sure that the DataElementPrototype is in a consistent state when it returns. When using DataWriteAccess the new values of the DataElementPrototype is not made available via the communication infrastructure before the RunnableEntity returns (exits the "Running" state). A DataSendPoint specifies that a RunnableEntity explicitly sends a certain DataElementPrototype. A DataSendPoint specifies that a RunnableEntity explicitly sends a certain DataElementPrototype. Implement state message semantics for establishing communication among runnables of the same component. Communication among RunnableEntities resembles the approaches taken for the communication among software components. The explicit communication corresponds to DataReceivePoint/DataSendPoint. The implicit communication resembles DataReadAccess/DataWriteAccess Implement state message semantics for establishing communication among runnables of the same component. This class specifies an assignment of a role to a particular P-Port. This port must contain a service which is inside of the component and called by outside entity in order to handle a particular issue (e.g. a communication event). This is often named as callback. This is the role of the assigned Port in the given context. The value must be a name of a PortInterface as standardized in the Software Specification of the related AUTOSAR Service. This class specifies an assignment of a role to a particular P-Port. This port must contain a service which is inside of the component and called by outside entity in order to handle a particular issue (e.g. a communication event). This is often named as callback. This class specifies an assignment of a role to a particular R-Port. This port must contain a service which is outside of the component and called by the component in order to handle a particular issue (e.g. a communication event). This is the role the assigned Port in given context. The value must be a name of a PortInterface as standardized in Software Specification of the related AUTOSAR Service. This class specifies an assignment of a role to a particular R-Port. This port must contain a service which is outside of the component and called by the component in order to handle a particular issue (e.g. a communication event). Specialization of the ComMgrUserNeeds for the case it is owned by a SoftwareComponentType. Specialization of the ComMgrUserNeeds for the case it is owned by a SoftwareComponentType. Specialization of the DiagnosticCommunicationNeeds for the case it is owned by a SoftwareComponentType. Specialization of the DiagnosticCommunicationNeeds for the case it is owned by a SoftwareComponentType. Specialization of the DiagnosticEventNeeds for the case it is owned by a SoftwareComponentType. It allows to navigate to all ports associated with this diagnostic event. Note that there may be further ports to communicate with the DEM Service (e.g. setting the operation cycle type) which are not included in this mapping because they are independent of the diagnisic event. Specialization of the DiagnosticEventNeeds for the case it is owned by a SoftwareComponentType. It allows to navigate to all ports associated with this diagnostic event. Note that there may be further ports to communicate with the DEM Service (e.g. setting the operation cycle type) which are not included in this mapping because they are independent of the diagnisic event. Specialization of the EcuStateMgrUserNeeds for the case it is owned by a SoftwareComponentType. It allows to navigate to all the ports which are used by this component to put requests for this "user". Note that there are further ports which a component can use to obtain various information from the ECU State Manager. These ports are not included in the mapping because they will be implemented as pure function calls which can be called independently of being a certain"user". Note that the AUTOSAR ECU State Manager does not support callbacks to services provided by users of ECU State Manger, therefore there is not property "callbackPort". Specialization of the EcuStateMgrUserNeeds for the case it is owned by a SoftwareComponentType. It allows to navigate to all the ports which are used by this component to put requests for this "user". Note that there are further ports which a component can use to obtain various information from the ECU State Manager. These ports are not included in the mapping because they will be implemented as pure function calls which can be called independently of being a certain"user". Note that the AUTOSAR ECU State Manager does not support callbacks to services provided by users of ECU State Manger, therefore there is not property "callbackPort". Specialization of the FunctionInhibitionNeeds for the case it is owned by a SoftwareComponentType. Note that the Function Inhibit Manger does not provide callbacks to services provided by software components. Therefoer there is no property "callbackPort". Specialization of the FunctionInhibitionNeeds for the case it is owned by a SoftwareComponentType. Note that the Function Inhibit Manger does not provide callbacks to services provided by software components. Therefoer there is no property "callbackPort". Specialization of NvBlockNeeds for the case it is owned by a SoftwareComponentType. It specifies all mappings to elements of the SoftwareComponentType concerning a single Nv block. Note that the mapping is the same for all instances of a SoftwareComponentType (because the code depends on it). Note that the block size is not specified here because - it can be derived from the associated PerInstanceMemory size (implementatiion specific) in case of implicit storage/restauration of the block - if can be derived from the array size passed via the correponding operations of the Service Interface in case of explicit storage/restauration of the block Specialization of NvBlockNeeds for the case it is owned by a SoftwareComponentType. It specifies all mappings to elements of the SoftwareComponentType concerning a single Nv block. Note that the mapping is the same for all instances of a SoftwareComponentType (because the code depends on it). Note that the block size is not specified here because - it can be derived from the associated PerInstanceMemory size (implementatiion specific) in case of implicit storage/restauration of the block - if can be derived from the array size passed via the correponding operations of the Service Interface in case of explicit storage/restauration of the block Specialization of SupervisedEntityNeeds for the case it is owned by a SoftwareComponentType. Specialization of SupervisedEntityNeeds for the case it is owned by a SoftwareComponentType. Defines a memory-block that needs to be available for each instance of the SW-component. This is typically only useful if supportsMultipleInstantiation is TRUE of if the component defines NVRAM access via permanent blocks. The "C"-type A definition of the type Defines a memory-block that needs to be available for each instance of the SW-component. This is typically only useful if supportsMultipleInstantiation is TRUE of if the component defines NVRAM access via permanent blocks. Each service in an ECU is represented by exactly one ServiceComponentPrototype. Instances of this class are only to be created in ECU Configuration phase for the specific purpose of the service configuration. Each service in an ECU is represented by exactly one ServiceComponentPrototype. Instances of this class are only to be created in ECU Configuration phase for the specific purpose of the service configuration. EcuSwComposition contains the complete Software Composition in an ECU, consisting both of application software components and service components. EcuSwComposition contains the complete Software Composition in an ECU, consisting both of application software components and service components. Component port providing a certain port interface. Component port providing a certain port interface. Base class for the ports of an AUTOSAR software component. Component port requiring a certain port interface. Component port requiring a certain port interface. ServiceComponentType is used for configuring services for a given ECU. Instances of this class are only to be created in ECU Configuration phase for the specific purpose of the service configuration. ServiceComponentType is used for configuring services for a given ECU. Instances of this class are only to be created in ECU Configuration phase for the specific purpose of the service configuration. The ApplicationSoftwareComponentType is used to represent the application software. The ComplexDeviceDriver Component is a special AtomicSoftwareComponent that has direct access to hardware on an ECUand which is therefore linked to a specific ECU or specific hardware. The ComplexDeviceDriver ComponentType introduces the possibility to link from the software representation to its hardware description provided by the ECU Resource Template. The ComplexDeviceDriver Component is a special AtomicSoftwareComponent that has direct access to hardware on an ECUand which is therefore linked to a specific ECU or specific hardware. The ComplexDeviceDriver ComponentType introduces the possibility to link from the software representation to its hardware description provided by the ECU Resource Template. The ECUAbstraction is a special AtomicSoftwareComponent that sits between a component that wants to access ECUperiphery and the Microcontroller Abstraction. The EcuAbstractionComponentType introduces the possibility to link from the software representation to its hardware description provided by the ECU Resource Template. The ECUAbstraction is a special AtomicSoftwareComponent that sits between a component that wants to access ECUperiphery and the Microcontroller Abstraction. The EcuAbstractionComponentType introduces the possibility to link from the software representation to its hardware description provided by the ECU Resource Template. The SensorActuatorSoftwareComponentType introduces the possibility to link from the software representation of a sensor/actuator to its hardware description provided by the ECU Resource Template. The SensorActuatorSoftwareComponentType introduces the possibility to link from the software representation of a sensor/actuator to its hardware description provided by the ECU Resource Template. Base class for AUTOSAR software components. The top level element of the System Description. The System description defines five major elements: Topology, Software, Communication, Mapping and Mapping Constraints. The System element directly aggregates the elements describing the Software, Mapping and Mapping Constraints; it contains a reference to an ASAM FIBEX description specifying Communication and Topology. The top level element of the System Description. The System description defines five major elements: Topology, Software, Communication, Mapping and Mapping Constraints. The System element directly aggregates the elements describing the Software, Mapping and Mapping Constraints; it contains a reference to an ASAM FIBEX description specifying Communication and Topology. The system mapping aggregates all mapping aspects (mapping of SW components to ECUs, mapping of data elements to signals, and mapping constraints). The system mapping aggregates all mapping aspects (mapping of SW components to ECUs, mapping of data elements to signals, and mapping constraints). The Top-level software composition, containing all software components in the System in a hierarchical structure. The contained ComponentPrototypes are fully specified by their ComponentTypes (including PortPrototypes, PortInterfaces, DataElementPrototypes, InternalBehavior etc.), and their ports are interconnected using ConnectorPrototypes. The Top-level software composition, containing all software components in the System in a hierarchical structure. The contained ComponentPrototypes are fully specified by their ComponentTypes (including PortPrototypes, PortInterfaces, DataElementPrototypes, InternalBehavior etc.), and their ports are interconnected using ConnectorPrototypes. In client server communication, the server may return any value within the application error range. In client server communication, the server may return any value within the application error range. In case of a server on one ECU with multiple clients on other ECUs, the client server communication shall use different unique COM signals and signal groups for each client to allow the identification of the client associated with each system signal. In case of a server on one ECU with multiple clients on other ECUs, the client server communication shall use different unique COM signals and signal groups for each client to allow the identification of the client associated with each system signal. The ArrayElement may be a primitive one or a composite one. If the element is primitive, it will be mapped to the "SystemSignal" (multiplicity 1). If the element is composite, there will be no mapping to the "SystemSignal" (multiplicity 0). In this case the "ArrayElementMapping" Element will aggregate the "TypeMapping" Element. In that way also the composite datatypes can be mapped to SystemSignals. Regardless whether composite or primitive array element is mapped the indexed array element always needs to be specified. The ArrayElement may be a primitive one or a composite one. If the element is primitive, it will be mapped to the "SystemSignal" (multiplicity 1). If the element is composite, there will be no mapping to the "SystemSignal" (multiplicity 0). In this case the "ArrayElementMapping" Element will aggregate the "TypeMapping" Element. In that way also the composite datatypes can be mapped to SystemSignals. Regardless whether composite or primitive array element is mapped the indexed array element always needs to be specified. Position of an element in an array. If the compositeType is an Array, the "ArrayTypeMapping" will be used. If the compositeType is an Array, the "ArrayTypeMapping" will be used. Mapping of an argument with a primitive datatype to a signal. Mapping of an argument with a primitive datatype to a signal. Mapping of a primitive record element to a SystemSignal. If the element is composite, there will be no mapping (multiplicity 0). In this case the "RecordElementMapping" Element will aggregate the "TypeMapping" Element. In that way also the composite datatypes can be mapped to SystemSignals. Regardless whether composite or primitive record element is mapped the record element always needs to be specified. Mapping of a primitive record element to a SystemSignal. If the element is composite, there will be no mapping (multiplicity 0). In this case the "RecordElementMapping" Element will aggregate the "TypeMapping" Element. In that way also the composite datatypes can be mapped to SystemSignals. Regardless whether composite or primitive record element is mapped the record element always needs to be specified. If the compositeType is a Record, the "RecordTypeMapping" will be used. If the compositeType is a Record, the "RecordTypeMapping" will be used. Mapping of client server operation arguments to signals of a signal group. Arguments with a primitive datatype will be mapped via the "ClientServerPrimitiveTypeMapping" element. Arguments with composite datatypes will be mapped via the "CompositeTypeMapping" element. Mapping of client server operation arguments to signals of a signal group. Arguments with a primitive datatype will be mapped via the "ClientServerPrimitiveTypeMapping" element. Arguments with composite datatypes will be mapped via the "CompositeTypeMapping" element. According to the COM Specification, signal groups without signals are allowed. These have a "signalLength" = 0. In this case there shall be an "update-bit" configured. According to the COM Specification, signal groups without signals are allowed. These have a "signalLength" = 0. In this case there shall be an "update-bit" configured. The purpose of sequence counters is to map a response to the correct request of a known client. The purpose of sequence counters is to map a response to the correct request of a known client. The ArrayElement may be a primitive one or a composite one. If the element is primitive, it will be mapped to the "SystemSignal" (multiplicity 1). If the element is composite, there will be no mapping to the "SystemSignal" (multiplicity 0). In this case the "ArrayElementMapping" Element will aggregate the "TypeMapping" Element. In that way also the composite datatypes can be mapped to SystemSignals. Regardless whether composite or primitive array element is mapped the indexed element always needs to be specified. The ArrayElement may be a primitive one or a composite one. If the element is primitive, it will be mapped to the "SystemSignal" (multiplicity 1). If the element is composite, there will be no mapping to the "SystemSignal" (multiplicity 0). In this case the "ArrayElementMapping" Element will aggregate the "TypeMapping" Element. In that way also the composite datatypes can be mapped to SystemSignals. Regardless whether composite or primitive array element is mapped the indexed element always needs to be specified. If the compositeType is an Array, the "ArrayTypeMapping" will be used. If the compositeType is an Array, the "ArrayTypeMapping" will be used. Mapping of a sender receiver communication data element with a composite datatype to a signal group. Mapping of a sender receiver communication data element with a composite datatype to a signal group. Mapping of a sender receiver communication data element with a primitive datatype to a signal. If the data element has to be transmitted to several receivers there is still exactly one mapping defined. In case of 1:n communication the DataElementPrototype in the ProvidePort of the ComponentPrototype is still mapped to only one SystemSignal. Mapping of a sender receiver communication data element with a primitive datatype to a signal. If the data element has to be transmitted to several receivers there is still exactly one mapping defined. In case of 1:n communication the DataElementPrototype in the ProvidePort of the ComponentPrototype is still mapped to only one SystemSignal. Mapping of a primitive record element to a SystemSignal. If the element is composite, there will be no mapping (multiplicity 0). In this case the "RecordElementMapping" Element will aggregate the "TypeMapping" Element. In that way also the composite datatypes can be mapped to SystemSignals. Regardless whether composite or primitive record element is mapped the record element always needs to be specified. Mapping of a primitive record element to a SystemSignal. If the element is composite, there will be no mapping (multiplicity 0). In this case the "RecordElementMapping" Element will aggregate the "TypeMapping" Element. In that way also the composite datatypes can be mapped to SystemSignals. Regardless whether composite or primitive record element is mapped the record element always needs to be specified. If the compositeType is a Record, the "RecordTypeMapping" will be used. If the compositeType is a Record, the "RecordTypeMapping" will be used. CAN specific attributes to the FrameTriggering The CAN protocol supports two types of frame formats. The standard frame format uses 11-bit identifiers and is defined in the CAN specification 2.0 A. Additionally the extended frame format allows 29-bit identifiers and is defined in the CAN specification 2.0 B. To describe a frames identifier on the communication system, usualy with a fixed identifierValue. CAN specific attributes to the FrameTriggering CAN specific attributes xml.namePlural="CAN-BUSES" It determines if bus load reduction for the respective NM channel is active or not. True: active False: inactive switch for enabling busload reduction support. It defines how long the NM shall stay in the Repeat Message State (in seconds) Network Timeout for NM-Messages. It denotes the time (in seconds) how long the NM shall stay in the Network Mode before transition into Prepare Bus-Sleep Mode shall take place. It shall be equal for all nodes in the cluster. Timeout for bus calm down phase. It denotes the time (in seconds) how long the NM shall stay in the Prepare Bus-Sleep Mode before transition into Bus-Sleep Mode shall take place. It shall be equal for all nodes in the cluster. CAN specific attributes xml.namePlural="CAN-BUSES" CAN bus specific communication port attributes. Number of samples. Possible values are 1 or 3. propagation Delay in seconds The number of quanta in the Synchronization Jump Width, SJW The number of quanta before the sampling point The number of quanta after the sampling point CAN bus specific communication port attributes. The communication cycle where the frame is send is described by the attribute "cycleCounter". The communication cycle where the frame described by this timing is sent. If a timing is given in this way the referencing cluster must specify the NUMBER-OF-CYCLES as upper bound and point of total repetition. This value is incremented at the beginning of each new cycle, ranging from 0 to 63, and is reset to 0 after a sequence of 64 cycles. The communication cycle where the frame is send is described by the attribute "cycleCounter". The communication cycle where the frame is send is described by the attributes baseCycle and cycleRepetition. The first communication cycle where the frame is sent. This value is incremented at the beginning of each new cycle, ranging from 0 to 63, and is reset to 0 after a sequence of 64 cycles. The number of communication cycles (after the first cycle) whenever the frame described by this timing is sent again. The communication cycle where the frame is send is described by the attributes baseCycle and cycleRepetition. Each frame in FlexRay is identified by its slot id and communication cycle. A description is provided by the usage of AbsolutelyScheduledTiming. In the static segment a frame can be sent multiple times within one communication cycle. For describing this case multiple AbsolutelyScheduledTimings have to be used. The main use case would be that a frame is sent twice within one communication cycle. In the static part the SlotID defines the slot in which the frame is transmitted. The SlotID also determines, in combination with FlexrayCluster::numberOfStaticSlots, whether the frame is sent in static or dynamic segment. In the dynamic part, the slot id is equivalent to a priority. Lower dynamic slot ids are all sent until the end of the dynamic segment. Higher numbers, which were ignored that time, have to wait one cycle and then must try again. minValue: 1 maxValue: 2047 Each frame in FlexRay is identified by its slot id and communication cycle. A description is provided by the usage of AbsolutelyScheduledTiming. In the static segment a frame can be sent multiple times within one communication cycle. For describing this case multiple AbsolutelyScheduledTimings have to be used. The main use case would be that a frame is sent twice within one communication cycle. FlexRay specific attributes to the FrameTriggering FlexRay specific attributes to the FrameTriggering FlexRay specific attributes to the physicalCluster The offset of the action point in networks Nominal bit time (= 1 / fx:SPEED). gdBit = cSamplesPerBit * gdSampleClockPeriod. Unit: seconds (gdBit) Bus Guardian Inter Slot Gap (ISG) part that follows a guarded schedule element. Unit macroticks Upper limit of the Collision Avoidance Symbol (CAS) acceptance window. Unit:bitDuration Lower limit of the Collision Avoidance Symbol (CAS) acceptance window. Unit:bitDuration The maximum number of times that a node in this cluster is permitted to attempt to start the cluster by initiating schedule synchronization Length of the cycle. Unit: seconds The duration of the dynamic slot idle phase in minislots. Upper limit for the start up and wake up listen timeout in the presence of noise. Expressed as a multiple of the cluster constant pdListenTimeout. Unit microticks number of macroticks which describe the distance between the static slot boundary and the closed macrotick boundary of the secondary time reference point using the initial configured macrotick length The number of macroticks in a communication cycle Duration of the cluster wide nominal macrotick, expressed in seconds The maximum error that a node may have after initialization. Unit: seconds Maximum propagation delay of a Cluster (in seconds). Threshold concerning vClockCorrectionFailedCounter. Defines the number of consecutive even/odd Cycle pairs with missing clock correction terms that will cause the protocol to transition from the POC:normal active or POC:normal passive state into the POC:halt state. Threshold concerning vClockCorrectionFailedCounter. Defines the number of consecutive even/odd Cycle pairs with missing clock correction terms that will cause the protocol to transition from the POC:normal active state to the POC:normal passive state. Minimum propagation delay of a Cluster (in seconds). The Offset of the action point within a minislot. Unit: macroticks The duration of a minislot (dynamic segment). Unit: macroticks. The duration of the network idle time in macroticks Length of the Network Management vector on a cluster. Unit: Bytes Total number of cycles until a temporal transmission pattern is repeated. The CycleCounter of an AbsolutelyScheduledTiming is evaluated against this parameter. number of Minislots in the dynamic segment. The number of static slots in the static segment. Cluster global magnitude of the maximum permissible offset correction value Unit: seconds (gOffsetCorrectionMax) Start of the offset correction phase within the Network Idle Time (NIT), expressed as the number of macroticks from the start of cycle. Unit: macroticks Globally configured payload length of a static frame. Unit: 16-bit WORDS. Sample clock period. Unit: seconds The duration of a slot in the static segment. Unit: macroticks The duration of the symbol window. Unit: macroticks The maximum number of sync nodes allowed in the cluster Number of bits in the Transmission Start Sequence [gdBits]. Number of bits used by the node to test the duration of the idle portion of a received wake up symbol. Unit:bitDuration Number of bits used by the node to test the LOW portion of a received wake up symbol. Unit:bitDuration Number of bits used by a node to test the overall duration of a received wake up symbol. Unit: gdBit Number of bits used by the node to transmit the idle part of a wake up symbol. Unit: gDbit Number of bits used by the node to transmit the LOW part of a wake up symbol. Unit:bitDuration FlexRay specific attributes to the physicalCluster FlexRay specific attributes to the CommunicationConnector Referenced channel used by the node to send a wakeup pattern. (pWakeupChannel) True: Channel A False: Channel B FlexRay specific attributes to the CommunicationConnector FlexRay bus specific communication port attributes. Expanded range of measured clock deviation allowed for startup frames during integration. Unit:microtick Boolean flag that controls the transition to the POC:halt state due to a clock synchronization errors. If set to true, the Communication Controller is allowed to transition to POC:halt. If set to false, the Communication Controller will not transition to the POC:halt state but will enter or remain in the normal POC (passive State). Number of consecutive even/odd cycle pairs that must have valid clock correction terms before the Communication Controller will be allowed to transition from the POC:normal passive state to POC:normal active state. If set to 0, the Communication Controller is not allowed to transition from POC:norm The cluster drift damping factor used in clock synchronization rate correction in microticks Value used by the receiver to calculate the difference between primary time reference point and secondary time reference point. Unit: Microticks (pDecodingCorrection) Value used to compensate for reception delays on channel A Unit: Microticks Value used to compensate for reception delays on channel B. Unit: Microticks Boolean flag that configures the Bus Guardian Schedule Monitoring Service to expect transmissions within the dynamic segment. Fixed amount added or subtracted to the calculated offset correction term to facilitate external offset correction, expressed in node-local microticks. Fixed amount added or subtracted to the calculated rate correction term to facilitate external rate correction, expressed in node-local microticks. ID of the slot used to transmit the startup frame, sync frame, or designated single slot frame. Flag indicating whether the Key Slot is used to transmit a startup frame. Flag indicating whether the Key Slot is used to transmit a sync frame. The number of the last minislot in which a transmission can start in the dynamic segment for the respective node Upper limit for the start up listen timeout and wake up listen timeout. Unit: Microticks Integer number of macroticks between the static slot boundary and the closest macrotick boundary of the secondary time reference point based on the nominal macrotick duration. (pMacroInitialOffset) Integer number of macroticks between the static slot boundary and the closest macrotick boundary of the secondary time reference point based on the nominal macrotick duration. (pMacroInitialOffset) Maximum drift offset in microticks between two nodes that operate with unsynchronized clocks over one communication cycle. Maximum payload length for the dynamic channel of a frame in 16 bit WORDS. Number of microticks between the closest macrotick boundary described by gMacroInitialOffset and the secondary time reference point. The parameter depends on pDelayCompensationA and therefore it has to be set independently for each channel. Number of microticks between the closest macrotick boundary described by gMacroInitialOffset and the secondary time reference point. The parameter depends on pDelayCompensationB and therefore it has to be set independently for each channel. The nominal number of microticks in a communication cycle Number of microticks per nominal macrotick that all implementations must support. Duration of a microtick. This attribute can be derived from samplePerMicrotick and gdSampleClockPeriod. Unit: seconds Magnitude of the maximum permissible offset correction value. Unit:microtick (pOffsetCorrectionOut) Magnitude of the maximum permissible rate correction value. Unit:Microticks (pRateCorrectionOut) Number of samples per microtick Flag indicating whether or not the node shall enter single slot mode following startup. Indicates that the node is a startup node (startup frame configured; connected to gChannels) The number of the static slot in which a sync frame shall be sent, if a sync frame shall be sent Number of repetitions of the Tx-wakeup symbol to be sent during the CC_WakeupSend state of this Node in the cluster FlexRay bus specific communication port attributes. Schedule entry for an Assign Frame Id master request. Schedule entry for an Assign Frame Id master request. A LIN specific extension of the common RelativelyScheduledTiming The extension describes the LIN specific assignment frames. Specification of a sending behavior where the transmission order is predefined, e.g. used on LIN buses Relative delay between this frame and the start of the successor frame in the schedule table in seconds. Relative position of the frame described by this timing in the schedule table Specification of a sending behavior where the transmission order is predefined, e.g. used on LIN buses The master task (in the master node) transmits frame headers based on a schedule table. The schedule table specifies the identifiers for each header and the interval between the start of a frame and the start of the following frame. Priority of the schedule table. The priority is used in the schedule table manager. The RUN_ONCE run mode schedules shall not have equal priority. Priority 0 is reserved for the NULL_SCHEDULE. Priority 255 is reserved for the RUN_CONTINUOUS run mode. The schedule table can be executed in two different modes. The master task (in the master node) transmits frame headers based on a schedule table. The schedule table specifies the identifiers for each header and the interval between the start of a frame and the start of the following frame. Lin specific attributes to the FrameTriggering Type of checksum that the frame is using. To describe a frames identifier on the communication system, usualy with a fixed identifierValue. Lin specific attributes to the FrameTriggering Schedule entry for an Assign NAD master request. The newly assigned NAD value (valid range 1..126) Schedule entry for an Assign NAD master request. A LIN specific extension of the common RelativelyScheduledTiming. The extension maps the LIN specific free data frames into SystemTemplate. The base type keeps scheduling for those free data frames applicable. A LIN specific extension of the common RelativelyScheduledTiming. The extension maps the LIN specific free data frames into SystemTemplate. The base type keeps scheduling for those free data frames applicable. Representing freely defined data. The integer Value of a freely defined data byte. Representing freely defined data. A LIN specific extension of the common FRAME to enable the usual frame handling of a placeholder frame that is substituted at runtime. Substitution frame must not declare signal instances nor multiplexers. The type of substitution. Substitution frames can either be used for event triggered or for sporadic frames. A LIN specific extension of the common FRAME to enable the usual frame handling of a placeholder frame that is substituted at runtime. Substitution frame must not declare signal instances nor multiplexers. Schedule entry for an Unassign Frame Id master request where the protected identifier is assigned the value 0x40. This will disable reception/transmission of a previously dynamically assigned frame identifier. Schedule entry for an Unassign Frame Id master request where the protected identifier is assigned the value 0x40. This will disable reception/transmission of a previously dynamically assigned frame identifier. LIN specific attributes LIN specific attributes Describing the properties of the refering ecu as a LIN master. Time base is mandatory for the master. It is not used for slaves. LIN 2.0 Spec states: "The time_base value specifies the used time base in the master node to generate the maximum allowed frame transfer time." The time base shall be specified AUTOSAR conform in seconds. timeBaseJitter is a mandatory attribute for the master and not used for slaves. LIN 2.0 Spec states: "The jitter value specifies the differences between the maximum and minimum delay from time base start point to the frame header sending start point (falling edge of BREAK signal)." The jitter shall be specified AUTOSAR conform in seconds. Describing the properties of the refering ecu as a LIN master. Describing the properties of the refering ecu as a LIN slave. To distinguish LIN slaves that are used twice or more within the same cluster. Version specifier for a communication protocol. Describing the properties of the refering ecu as a LIN slave. The default value consists of a number of elements. Each element is one byte long and the number of elements is specified by SduLength. The integer value of a freely defined data byte. This attribute specifies the byte position of the element within the default value The default value consists of a number of elements. Each element is one byte long and the number of elements is specified by SduLength. The entire source frame is mapped as it is onto the target frame (what in general is only possible inside of a common platform). In this case source and target frame should be the identical object. Each pair consists in a SOURCE and a TARGET referencing to a FrameTriggering. The Frame Mapping is not supported by the Autosar BSW. The existence is optional and has been incorporated into the System Template mainly for compatibility in order to allow interchange between FIBEX and AUTOSAR descriptions. The entire source frame is mapped as it is onto the target frame (what in general is only possible inside of a common platform). In this case source and target frame should be the identical object. Each pair consists in a SOURCE and a TARGET referencing to a FrameTriggering. The Frame Mapping is not supported by the Autosar BSW. The existence is optional and has been incorporated into the System Template mainly for compatibility in order to allow interchange between FIBEX and AUTOSAR descriptions. A gateway is an ECU that is connected to two or more clusters (channels, but not redundant), and performs a frame, Pdu or signal mapping between them. A gateway is an ECU that is connected to two or more clusters (channels, but not redundant), and performs a frame, Pdu or signal mapping between them. Arranges those signals that are transferred by the gateway from one channel to the other in pairs and defines the mapping between them. Each pair consists in a source and a target referencing to a ISignalToIPduMapping. Arranges those signals that are transferred by the gateway from one channel to the other in pairs and defines the mapping between them. Each pair consists in a source and a target referencing to a ISignalToIPduMapping. Arranges those IPdus that are transferred by the gateway from one channel to the other in pairs and defines the mapping between them. Arranges those IPdus that are transferred by the gateway from one channel to the other in pairs and defines the mapping between them. Source destination of the referencing mapping. Source destination of the referencing mapping. Default Value which will be distributed if no I-Pdu has been received since last sending. Default Value which will be distributed if no I-Pdu has been received since last sending. Target destination of the referencing mapping. Target destination of the referencing mapping. The CommunicationCluster is the main element to describe the topological connection of communicating ECUs. A cluster describes the ensemble of ECUs, which are linked by a communication medium of arbitrary topology (bus, star, ring, ...). The nodes within the cluster share the same communication protocol, which may be event-triggered, time-triggered or a combination of both. A CommunicationCluster aggregates one or more physical channels. All physical channels that are aggregated by a communication cluster are synchronized with each other. Maximal supported length in bytes for frames in this cluster. Enable/disable the node detection functionality. Enable/disable the source node identifier. switch for enabling support for repeat message The name of the protocol used. The version of the protocol used. channels speed in bits per second The CommunicationCluster is the main element to describe the topological connection of communicating ECUs. A cluster describes the ensemble of ECUs, which are linked by a communication medium of arbitrary topology (bus, star, ring, ...). The nodes within the cluster share the same communication protocol, which may be event-triggered, time-triggered or a combination of both. A CommunicationCluster aggregates one or more physical channels. All physical channels that are aggregated by a communication cluster are synchronized with each other. A physical channel is the transmission medium that is used to send and receive information between two communicating ECUs. Each CommunicationCluster has at least one physical channel. Bus systems like CAN and LIN only have exactly one PhysicalChannel. A FlexRay cluster may have more than one PhysicalChannels that may be used in parallel for redundant communication. An ECU is part of a cluster if it contains at least one controller that is connected to at least one channel of the cluster. A physical channel is the transmission medium that is used to send and receive information between two communicating ECUs. Each CommunicationCluster has at least one physical channel. Bus systems like CAN and LIN only have exactly one PhysicalChannel. A FlexRay cluster may have more than one PhysicalChannels that may be used in parallel for redundant communication. An ECU is part of a cluster if it contains at least one controller that is connected to at least one channel of the cluster. The connection between the referencing ECU and the referenced channel via the referenced controller. Connectors are used to describe the bus interfaces of the ECUs and to specify the sending/receiving behavior. Each CommunicationConnector has a reference to exactly one communicationController. The communicationController can be referenced by several CommunicationConnector elements. This is important for the FlexRay Bus. FlexRay communicates via two physical channels. But only one controller in an ECU is responsible for both channels. Thus, two connectors (for channel A and for channel B) must reference to the same controller. An ECUs NM address on the referenced channel. An ECUs TP address on the referenced channel. This represents the diagnostic Address. The connection between the referencing ECU and the referenced channel via the referenced controller. Connectors are used to describe the bus interfaces of the ECUs and to specify the sending/receiving behavior. Each CommunicationConnector has a reference to exactly one communicationController. The communicationController can be referenced by several CommunicationConnector elements. This is important for the FlexRay Bus. FlexRay communicates via two physical channels. But only one controller in an ECU is responsible for both channels. Thus, two connectors (for channel A and for channel B) must reference to the same controller. The communication controller is a dedicated hardware device by means of which hosts are sending frames to and receiving frames from the communication medium. May the ECU be woken up by this CAN Controller? TRUE: wake up is possible FALSE: wake up is not supported Note: This flag may only be set to TRUE if the feature is supported by both hardware and basic software. The communication controller is a dedicated hardware device by means of which hosts are sending frames to and receiving frames from the communication medium. ECUInstances are used to define the ECUs used in the topology. The type of the ECU is defined by a reference to an ECU specified with the ECU resource description. This ID is returned by a call to Com_GetConfigurationId() The COM scheduling time is used in order to be able to calculate the worst case bus timing. The processing period shall be specified AUTOSAR conform in seconds. An ECU specific ID for responses of diagnostic routines. unique PDURconfiguration identifier An ECU specific ID for responses of diagnostic routines. Specifies whether the ECU instance may be put to a "low power mode" TRUE: sleep mode is supported FALSE: sleep mode is not supported Note: This flag may only be set to TRUE if the feature is supported by both hardware and basic software. Driver support for wakeup over Bus. ECUInstances are used to define the ECUs used in the topology. The type of the ECU is defined by a reference to an ECU specified with the ECU resource description. Connectors reception or send port. The ECU communication relationships shall be fully described on each level (signal, Pdu and frame). For each signal, Pdu or Frame that is transmitted or received by the ECU an individual SignalPort, IPduPort or FramePort shall be created." communication Direction of the Connector Port (input or output Port). The FrameTriggering describes the instance of a frame sent on a channel and defines the manner of triggering (timing information) and identification of a frame on the channel, on which it is sent. For the same frame, if Frame Triggerings exist on more than one channel of the same cluster the fan-out/in is handled by the Bus interface. Data frame which is sent over a communication medium. This element describes the pure Layout of a frame sent on a channel. The used length (in bytes) of the referencing frame. Should not be confused with a static byte length reserved for each frame by some platforms (e.g. FlexRay). Data frame which is sent over a communication medium. This element describes the pure Layout of a frame sent on a channel. A PduToFrameMapping defines the composition of Pdus in each frame. Depending on its relation to entities such channels and clusters it can be unambiguously deduced whether a fan-out is handled by the Pdu router or the Bus Interface. This parameter defines the order of the bytes of the Pdu and the packing into the Frame. The byte ordering "Little Endian" (MostSignificantByteLast) and "Big Endian" (MostSignificantByteFirst) can be selected. The value of this attribute impacts the absolute position of the Pdu into the Frame (see the startPosition attribute description). This parameter is necessary to describe the bitposition of a Pdu within a Frame. It denotes the least significant bit for "Little Endian" and the most significant bit for "Big Endian" packed Pdu within the Frame (see the description of the packingByteOrder attribute). Bits within the Frame are counted as follows (see the OSEK COM v3.0.3 specification) : Bit 0 corresponds to Byte 0 Bit 0 Bit 1 corresponds to Byte 0 Bit 1 ..... Bit 8 corresponds to Byte 1 Bit 0 etc. Please note that the way the bytes will be actually sent on the bus does not impact this representation: they will always be seen by the software as a byte array. Note also that the absolute position of the Pdu in the Frame is then determined by the definition of the packingByteOrder attribute of the signal. Indication to the receivers that the corresponding I-Pdu was updated by the sender. This attribute describes the position of the update bit in the frame that aggregates this PDUToFrameMapping. Length is always one bit. A PduToFrameMapping defines the composition of Pdus in each frame. Depending on its relation to entities such channels and clusters it can be unambiguously deduced whether a fan-out is handled by the Pdu router or the Bus Interface. Connectors reception or send port on the referenced channel referenced by a FrameTriggering. The IPduTriggering describes on which channel the IPdu is transmitted. Depending on its relation to entities such channels and clusters it can be unambiguously deduced whether a fan-out is handled by the Pdu router or the Bus Interface. If the fan-out is specified between different clusters it shall be handled by the Pdu Router. If the fan-out is specified between different channels of the same cluster it shall be handled by the Bus Interface. The IPduTriggering describes on which channel the IPdu is transmitted. Depending on its relation to entities such channels and clusters it can be unambiguously deduced whether a fan-out is handled by the Pdu router or the Bus Interface. If the fan-out is specified between different clusters it shall be handled by the Pdu Router. If the fan-out is specified between different channels of the same cluster it shall be handled by the Bus Interface. AUTOSAR COM provides the possibility to define two different TRANSMISSION MODES for each I-PDU. The Transmission Mode of an I-PDU that is valid at a specific point in time is selected using the values of the signals that are mapped to this I-PDU. For each I-PDU a Transmission Mode Selector is defined. The Transmission Mode Selector is calculated by evaluating the conditions for a subset of signals (class TransmissionModeCondition in the System Template). The Transmission Mode Selector is defined to be true, if at least one Condition evaluates to true and is defined to be false, if all Conditions evaluate to false. Minimum Delay in seconds between successive transmissions of this I-PDU, independent of the Transmission Mode. AUTOSAR COM provides the possibility to define two different TRANSMISSION MODES for each I-PDU. The Transmission Mode of an I-PDU that is valid at a specific point in time is selected using the values of the signals that are mapped to this I-PDU. For each I-PDU a Transmission Mode Selector is defined. The Transmission Mode Selector is calculated by evaluating the conditions for a subset of signals (class TransmissionModeCondition in the System Template). The Transmission Mode Selector is defined to be true, if at least one Condition evaluates to true and is defined to be false, if all Conditions evaluate to false. An ISignalToIPduMapping describes the mapping of ISignals to SignalIPdus and defines the position of the ISignal within an SignalIPdu. This element does NOT describe signal or I-PDU fan-out. Every ISignal can only be mapped into one SignalIPdu. Several ISignalToIPduMappings to the same ISignal are only relevant when the ECU handles the signal gateway. If a mapping for the SystemSignalGroup is defined, only the UpdateIndicationBitPosition is relevant, and the startPosition shall be ignored. This parameter defines the order of the bytes of the signal and the packing into the SignalIPdu. The byte ordering "Little Endian" (MostSignificantByteLast) and "Big Endian" (MostSignificantByteFirst) can be selected. The value of this attribute impacts the absolute position of the signal into the SignalIPdu (see the startPosition attribute description). This parameter is necessary to describe the bitposition of a signal within an SignalIPdu. It denotes the least significant bit for "Little Endian" and the most significant bit for "Big Endian" packed signals within the IPdu (see the description of the packingByteOrder attribute). Bits within the IPdu are counted as follows (see the OSEK COM v3.0.3 specification) : Bit 0 corresponds to Byte 0 Bit 0 Bit 1 corresponds to Byte 0 Bit 1 ..... Bit 8 corresponds to Byte 1 Bit 0 etc. Please note that the way the bytes will be actually sent on the bus does not impact this representation: they will always be seen by the software as a byte array. Note also that the absolute position of the signal in the SignalIPdu is then determined by the definition of the packingByteOrder attribute of the signal. If a mapping for the SystemSignalGroup is defined, only the UpdateIndicationBitPosition is relevant, and the startPosition shall be ignored. The UpdateIndicationBit indicates to the receivers that the signal (or the signal group) was updated by the sender. Length is always one bit. The UpdateIndicationBitPosition attribute describes the position of the update bit within the SignalIPdu. An ISignalToIPduMapping describes the mapping of ISignals to SignalIPdus and defines the position of the ISignal within an SignalIPdu. This element does NOT describe signal or I-PDU fan-out. Every ISignal can only be mapped into one SignalIPdu. Several ISignalToIPduMappings to the same ISignal are only relevant when the ECU handles the signal gateway. If a mapping for the SystemSignalGroup is defined, only the UpdateIndicationBitPosition is relevant, and the startPosition shall be ignored. Signal of the Interaction Layer. The RTE supports a "signal fan-out" where the same System Signal is sent in different SignalIPdus to multiple receivers. The System Signal is unique per System. To support the RTE "signal fan-out" each SignalIPdu contains ISignals. If the same System Signal is to be mapped into several SignalIPdus there is one ISignal needed for each ISignalToIPduMapping. ISignals describe the Interface between the Precompile configured RTE and the potentially Postbuild configured Com Stack (see ECUC Parameter Mapping). In the case of the SystemSignalGroup an ISignal must be created for the SystemSignalGroup and for each SystemSignal contained in the SystemSignalGroup. If a mapping for the SystemSignalGroup is defined, only the UpdateIndicationBitPosition is relevant, and the startPosition shall be ignored. Signal of the Interaction Layer. The RTE supports a "signal fan-out" where the same System Signal is sent in different SignalIPdus to multiple receivers. The System Signal is unique per System. To support the RTE "signal fan-out" each SignalIPdu contains ISignals. If the same System Signal is to be mapped into several SignalIPdus there is one ISignal needed for each ISignalToIPduMapping. ISignals describe the Interface between the Precompile configured RTE and the potentially Postbuild configured Com Stack (see ECUC Parameter Mapping). In the case of the SystemSignalGroup an ISignal must be created for the SystemSignalGroup and for each SystemSignal contained in the SystemSignalGroup. If a mapping for the SystemSignalGroup is defined, only the UpdateIndicationBitPosition is relevant, and the startPosition shall be ignored. Connectors reception or send port on the referenced channel referenced by an IPduTriggering. The IPdu (Interaction Layer Protocol Data Unit) element is used to sum up the IPdus of AUTOSAR COM, DCM and IPduM. This Pdus are sent to the PduR. The size of the IPDU in bits. AUTOSAR COM fills not used areas of an IPDU with this bit-pattern. This attribute is mandatory to avoid undefined behavior. This byte-pattern will be repeated throughout the IPDU. A ISignalTriggering defines the manner of triggering of a ISignal on the channel, on which it is sent. ISignalTriggering should only be used for defining timing constraints. Com does not know of signals related to a specific cluster or channel. A ISignalTriggering defines the manner of triggering of a ISignal on the channel, on which it is sent. ISignalTriggering should only be used for defining timing constraints. Com does not know of signals related to a specific cluster or channel. Connectors reception or send port on the referenced channel referenced by an ISignalTriggering. Optional timeout value in seconds for the reception of the ISignal. In case the System Description doesn't use a complete Software Component Description (VFB View). This supports the inclusion of legacy system signals. If a full DataMapping exist for the SystemSignal this information may be available from a configured ReceiverComSpec, in this case the timeout value in ReceiverComSpec override this optional timeout specification. Connectors reception or send port on the referenced channel referenced by an ISignalTriggering. This is a PDU of the Transport Layer. The main purpose of the TP Layer is to segment and reassemble I-PDUs. Represents the I-PDU's handled by Dcm. Dynamic part of a multiplexed I-Pdu. Reserved space which is used to transport varying SignalIPdus at the same position, controlled by the corresponding selectorFieldCode. The selector field is part of a multiplexed IPdu. It consists of contiguous bits. The value of the selector field selects the layout of the multiplexed part of the IPdu. Dynamic part of a multiplexed I-Pdu. Reserved space which is used to transport varying SignalIPdus at the same position, controlled by the corresponding selectorFieldCode. There is one COM I-PDU for the static part and one COM I-PDU for each dynamic part of one MultiplexedIPdu, so the IPdu Multiplexer module always combines only two IPdus of Com. Data Length in bits. This parameter defines the order of the bytes of the SignalIPdu and the packing into the MultiplexedIPdu. The byte ordering "Little Endian" (MostSignificantByteLast) and "Big Endian" (MostSignificantByteFirst) can be selected. A SignalIPdus bit position relatively to the beginning of a multiplexed IPdu. Represents the I-PDU's handled by Com. The SignalIPdu assembled and disassembled in AUTOSAR COM consists of one or more signals. In case no multiplexing is performed this IPdu is routed to/from the Interface Layer. Represents the I-PDU's handled by Com. The SignalIPdu assembled and disassembled in AUTOSAR COM consists of one or more signals. In case no multiplexing is performed this IPdu is routed to/from the Interface Layer. The AUTOSAR COM Layer is able to start and to stop sending and receiving for a configurable group of I-Pdus during runtime. An I-Pdu group contains zero or more Com I-Pdus or I-Pdu groups. When an I-Pdu group containing one or more other I-Pdu groups is started the contained I-Pdu groups shall also be started. When an I-Pdu group containing one or more other I-Pdu groups is stopped the contained I-Pdu groups shall also be stopped. Only a two level hierarchy of I-Pdu groups is allowed. An I-Pdu group that is part of an I-Pdu group must not contain I-Pdu groups. The AUTOSAR COM Layer is able to start and to stop sending and receiving for a configurable group of I-Pdus during runtime. An I-Pdu group contains zero or more Com I-Pdus or I-Pdu groups. When an I-Pdu group containing one or more other I-Pdu groups is started the contained I-Pdu groups shall also be started. When an I-Pdu group containing one or more other I-Pdu groups is stopped the contained I-Pdu groups shall also be stopped. Only a two level hierarchy of I-Pdu groups is allowed. An I-Pdu group that is part of an I-Pdu group must not contain I-Pdu groups. Multiplexed PDU (i.e. NOT a COM I-PDU) aggregates one or several SignalIPdus. In case of multiplexing this IPdu is routed between the Pdu Multiplexer and the Interface Layer. A multiplexer is used to define variable parts within a IPdu that may carry different signals. The receivers of such a IPdu can determine which signalPdus are transmitted by evaluating the selector field, which carries a unique selector code for each sub-part. This parameter defines the byte order of the selector field. The byte ordering "Little Endian" (MostSignificantByteLast) and "Big Endian" (MostSignificantByteFirst) can be selected. The value of this attribute impacts the absolute position of the selector field into the IPdu. The size in bits of the selector field shall be configurable in a range of one bit and eight bits. This parameter is necessary to describe the position of the selector field within the IPdu. It denotes the least significant bit for "Little Endian" and the most significant bit for "Big Endian" (see the description of the selectorFieldByteOrder attribute). Multiplexed PDU (i.e. NOT a COM I-PDU) aggregates one or several SignalIPdus. In case of multiplexing this IPdu is routed between the Pdu Multiplexer and the Interface Layer. A multiplexer is used to define variable parts within a IPdu that may carry different signals. The receivers of such a IPdu can determine which signalPdus are transmitted by evaluating the selector field, which carries a unique selector code for each sub-part. Some parts/signals of the I-PDU may be the same regardless of the selector field. Such a part is called static part. Network Management I-Pdu The size of the NmPDU in bits. Defines the position of the control bit vector within the NM PDU (Bitpositon). Defines the bitposition of the source node identifier within the NM PDU. Defines the length in Bytes of the user data contained in the NM PDU. Network Management I-Pdu A signal group refers to a set of signals that must always be kept together. A signal group is used to guarantee the atomic transfer of AUTOSAR composite data types. A signal group refers to a set of signals that must always be kept together. A signal group is used to guarantee the atomic transfer of AUTOSAR composite data types. The system signal represents the communication system's view of data exchanged between SW components which reside on different ECUs. The system signals allow to represent this communication in a flattened structure, with exactly one system signal defined for each data element prototype sent and received by connected SW component instances. According to the COM Specification, signal groups without signals are allowed. These have a "signalLength" = 0. In this case there shall be an "update-bit" configured. Size of the signal in bits. The system signal represents the communication system's view of data exchanged between SW components which reside on different ECUs. The system signals allow to represent this communication in a flattened structure, with exactly one system signal defined for each data element prototype sent and received by connected SW component instances. According to the COM Specification, signal groups without signals are allowed. These have a "signalLength" = 0. In this case there shall be an "update-bit" configured. Maximum allowable deviation Maximum allowable deviation in duration (in seconds) Maximum allowable deviation Specification of a cyclic sending behavior. Number of repetitions the pdu is sent from the moment the stop condition has been met Specification of a cyclic sending behavior. The timeRange can be specified with the value attribute. Optionally a tolerance can be defined. Average value of a date (in seconds) The timeRange can be specified with the value attribute. Optionally a tolerance can be defined. Specification of a event driven sending behavior. The PDU is sent "numberOfRepeats" times separated by the repeatCycleTime. If numberOfRepeats = 1, then the Pdu is sent just once. Number of repetitions the pdu is sent from the moment the send condition has been breached. Specification of a event driven sending behavior. The PDU is sent "numberOfRepeats" times separated by the repeatCycleTime. If numberOfRepeats = 1, then the Pdu is sent just once. Maximum allowable deviation Maximum allowable deviation in percent Maximum allowable deviation Possibility to attach a condition to each signal within an I-PDU. If at least one condition evaluates to true, TRANSMISSION MODE True shall be used for this I-Pdu. In all other cases, the TRANSMISSION MODE FALSE shall be used. Possibility to attach a condition to each signal within an I-PDU. If at least one condition evaluates to true, TRANSMISSION MODE True shall be used for this I-Pdu. In all other cases, the TRANSMISSION MODE FALSE shall be used. AUTOSAR COM provides the possibility to define two different TRANSMISSION MODES (True and False) for each I-PDU. AUTOSAR COM provides the possibility to define two different TRANSMISSION MODES (True and False) for each I-PDU. If the COM Transmission Mode is false the timing is aggregated by the TransmissionModeIFalseTiming element. If the COM Transmission Mode is true the timing is aggregated by the SignalIPdu/IPduTiming element. COM supports the following Transmission Modes: Periodic (Cyclic Timing) Direct /n-times (EventControlledTiming) Mixed (Cyclic and EventControlledTiming are assigned) None (no timing is assigned) If the COM Transmission Mode is false the timing is aggregated by the TransmissionModeIFalseTiming element. If the COM Transmission Mode is true the timing is aggregated by the SignalIPdu/IPduTiming element. COM supports the following Transmission Modes: Periodic (Cyclic Timing) Direct /n-times (EventControlledTiming) Mixed (Cyclic and EventControlledTiming are assigned) None (no timing is assigned) Specification of a request driven sending behavior. Semantics of this communication mechanism is that basic software stores values but does not send it out until a frame requesting the information is received. Number of repetitions the frame is sent for a single request Specification of a request driven sending behavior. Semantics of this communication mechanism is that basic software stores values but does not send it out until a frame requesting the information is received. A connection channel represents an internal path for the transmission or reception of a Pdu via CanTp and describes the the sender and the receiver of this particular communication. The CanTp module routes a Pdu through the connection channel Declares which communication addressing mode is supported. The maximum number of N-PDUs the CanTp receiver allows the sender to send, before waiting for an authorization to continue transmission of the following N-PDUs. For further details on this parameter value see ISO 15765-2 specification. Note: For reasons of buffer length, the CAN Transport Layer can adapt the BS value within the limit of this maximum BS This attribute defines the minimum amount of time (separation Time) between two succeeding CFs. Specified in seconds. Specifies the communication type: true: 1:n communication (Functional) false: 1:1 communication (Physical) Defines if the receive frame uses padding or not. true: The N-PDU received uses padding for SF, FC and the last CF. (N-PDU length is always 8 bytes) false: The N-PDU received does not use padding for SF, CF and the last CF. (N-PDU length is dynamic) A connection channel represents an internal path for the transmission or reception of a Pdu via CanTp and describes the the sender and the receiver of this particular communication. The CanTp module routes a Pdu through the connection channel A channel is a group of connections sharing several properties. The FlexRay Transport Layer supports several channels. These channels can work concurrently, thus each of them requires its own state machine and management data structures and its own PDU-IDs. Type of Acknowledgement. Adressing Type of this connection: true: Two Bytes false: One Byte This specifies the maximum message length for the particular channel. This attribute defines the minimum amount of time (separation Time) between two succeeding CFs. Specified in seconds. This attribute defines whether segmentation within a 1:n connection is allowed or not. This parameter defines the time in seconds between the sending of two consecutive frames or between a consecutive frame and a flow control (for Transmit Cancellation) or between reception of an flow control or Acknowledgement Frame and sending of the next consecutive frame or a flow control (for Transmit Cancellation). This attribute states whether Transmit Cancellation is supported on this channel. A channel is a group of connections sharing several properties. The FlexRay Transport Layer supports several channels. These channels can work concurrently, thus each of them requires its own state machine and management data structures and its own PDU-IDs. A connection within a channel identifies the sender and the receiver of this particular communication. The FlexRayTp module routes a Pdu through this connection. A connection within a channel identifies the sender and the receiver of this particular communication. The FlexRayTp module routes a Pdu through this connection. A LinTP channel represents an internal path for the transmission or reception of a Pdu via LinTp and describes the the sender and the receiver of this particular communication. The LinTp module routes a Pdu through the connection channel A LinTP channel represents an internal path for the transmission or reception of a Pdu via LinTp and describes the the sender and the receiver of this particular communication. The LinTp module routes a Pdu through the connection channel Constraint that forces the mapping of all referenced SW component instances to the same ECU Constraint that forces the mapping of all referenced SW component instances to the same ECU Constraint that forces the two referenced SW components (called A and B in the following) not to be mapped to the same ECU. If a SW component (e.g. A) is a composition, none of the atomic SW components making up the A composition must be mapped together with any of the atomic SW components making up the B composition. Furthermore, A and B must be disjoint. Constraint that forces the two referenced SW components (called A and B in the following) not to be mapped to the same ECU. If a SW component (e.g. A) is a composition, none of the atomic SW components making up the A composition must be mapped together with any of the atomic SW components making up the B composition. Furthermore, A and B must be disjoint. Resource estimations for RTE and BSW of a single ECU instance. Resource estimations for RTE and BSW of a single ECU instance. Map software components to a specific ECU Instance. Map software components to a specific ECU Instance. The System Constraint Description has to describe dedicated and exclusive mapping of SW-Cs to one or more ECUs. Dedicated mapping means that the SW-C can only be mapped to the ECUs it is dedicated to. Exclusive Mapping means that the SW-C cannot be mapped to the ECUs it is excluded from. This attribute determines if dedicated or exclusive mapping is used. The System Constraint Description has to describe dedicated and exclusive mapping of SW-Cs to one or more ECUs. Dedicated mapping means that the SW-C can only be mapped to the ECUs it is dedicated to. Exclusive Mapping means that the SW-C cannot be mapped to the ECUs it is excluded from. Map instances of an AtomicSoftwareComponentType to a specific Implementation. Map instances of an AtomicSoftwareComponentType to a specific Implementation. The CommonSignalPath describes that two or more SwcToSwcSignals and/or SwcToSwcOperationArguments must take the same way (Signal Path) in the topology. The CommonSignalPath describes that two or more SwcToSwcSignals and/or SwcToSwcOperationArguments must take the same way (Signal Path) in the topology. The SwcToSwcOperationArguments describes the information (client server operation arguments, plus the operation identification, if required) that are exchanged between two SW Components from exactly one client to one server, or from one server back to one client. The direction attribute defines which direction is described. If direction == IN, all arguments sent from the client to the server are described by the SwcToSwcOperationArguments, in direction == OUT, it's the arguments sent back from server to client. direction addressed by this SwcToSwcClientServerOperation element. The SwcToSwcOperationArguments describes the information (client server operation arguments, plus the operation identification, if required) that are exchanged between two SW Components from exactly one client to one server, or from one server back to one client. The direction attribute defines which direction is described. If direction == IN, all arguments sent from the client to the server are described by the SwcToSwcOperationArguments, in direction == OUT, it's the arguments sent back from server to client. The SwcToSwcSignal describes the information (data element) that is exchanged between two SW Components. On the SWC Level it is possible that a SW Component sends one data element from one P-Port to two different SW Components (1:n Communication). The SwcToSwcSignal describes exactly the information which is exchanged between one P-Port of a SW Component and one R-Port of another SW Component. The SwcToSwcSignal describes the information (data element) that is exchanged between two SW Components. On the SWC Level it is possible that a SW Component sends one data element from one P-Port to two different SW Components (1:n Communication). The SwcToSwcSignal describes exactly the information which is exchanged between one P-Port of a SW Component and one R-Port of another SW Component. The ForbiddenSignalPath describes the physical channels which an element must not take in the topology. Such a signal path can be a constraint for the communication matrix, because such a path has an effect on the frame generation and the frame path. The ForbiddenSignalPath describes the physical channels which an element must not take in the topology. Such a signal path can be a constraint for the communication matrix, because such a path has an effect on the frame generation and the frame path. The PermissibleSignalPath describes the way a data element shall take in the topology. The path is described by ordered references to PhysicalChannels. If more than one PermissibleSignalPath is defined for the same signal/operation attributes, any of them can be chosen. Such a signal path can be a constraint for the communication matrix . This path describes that one data element should take path A (e.g. 1. Can channel, 2. Lin channel) and not path B (1. Can channel, FlexRay channel A). This has an effect on the frame generation and the frame path. The PermissibleSignalPath describes the way a data element shall take in the topology. The path is described by ordered references to PhysicalChannels. If more than one PermissibleSignalPath is defined for the same signal/operation attributes, any of them can be chosen. Such a signal path can be a constraint for the communication matrix . This path describes that one data element should take path A (e.g. 1. Can channel, 2. Lin channel) and not path B (1. Can channel, FlexRay channel A). This has an effect on the frame generation and the frame path. The SeparateSignalPath describes that two SwcToSwcSignals and/or SwcToSwcOperationArguments must not take the same way (Signal Path) in the topology (e.g. Redundancy). The SeparateSignalPath describes that two SwcToSwcSignals and/or SwcToSwcOperationArguments must not take the same way (Signal Path) in the topology (e.g. Redundancy). CommunicationControllerMapping specifies the CommunicationPeripheral hardware (defined in the ECU Resource Template) to realize the specified CommunicationController in a physical topology. CommunicationControllerMapping specifies the CommunicationPeripheral hardware (defined in the ECU Resource Template) to realize the specified CommunicationController in a physical topology. HWPortMapping specifies the ECUCommunicationPort hardware (defined in the ECU Resource Template) to realize the specified CommunicationConnector in a physical topology. HWPortMapping specifies the ECUCommunicationPort hardware (defined in the ECU Resource Template) to realize the specified CommunicationConnector in a physical topology. ECUMapping allows to assign an ECU hardware type (defined in the ECU Resource Template) to an ECUInstance used in a physical topology. ECUMapping allows to assign an ECU hardware type (defined in the ECU Resource Template) to an ECUInstance used in a physical topology. Contains the implementation specific information in addition to the generic specification (BswModuleDescription and BswBehavior). It is possible to have several different BswImplementations referring to the same BswBehavior. Major version number of AUTOSAR specification on which this implementation is based on. Minor version number of AUTOSAR specification on which this implementation is based on. Patch level version number of AUTOSAR specification on which this implementation is based on. In driver modules which can be instantiated several times on a single ECU, BSW00347 requires that the name of APIs is extended by the VendorId and a vendor specific name. This parameter is used to specify the vendor specific name. In total, the implementation specific name is generated as follows: <ModuleName>_<VendorId>_ <VendorApiInfix><Api name from SWS>. E.g. assuming that the VendorId of the implementor is 123 and the implementer chose a VendorApiInfix of "v11r456" a api name Can_Write defined in the SWS will translate to Can_123_v11r456Write. This attribute is mandatory for all modules with upper multiplicity > 1. It shall not be used for modules with upper multiplicity =1. Contains the implementation specific information in addition to the generic specification (BswModuleDescription and BswBehavior). It is possible to have several different BswImplementations referring to the same BswBehavior. Root element for the description of a single BSW module or BSW cluster. In case it describes a BSW module, the short name of this element equals the name of the BSW module. Refers to the BSW Module Identifier defined by the AUTOSAR standard. Root element for the description of a single BSW module or BSW cluster. In case it describes a BSW module, the short name of this element equals the name of the BSW module. This class collects the dependencies of a BSW module or cluster on a certain other BSW module in an abstract way. AUTOSAR identifier of the target module of which the dependencies are defined. This class collects the dependencies of a BSW module or cluster on a certain other BSW module in an abstract way. This class represents a single API entry (C-function prototype) into the BSW module or cluster. The name of the C-function is equal to the short name of this element with one exception: In case of multiple instances of a module on the same CPU, special rules for "infixes" apply, see description of class BswImplementation. the type of call associated with this service Specifies the excution context which is required (in case of entries into this module) or guaranteed (in case of entries called from this module) for this service. true: This calls a synchronous service, i.e. the service is completed when the call returns. false: The service (on semantical level) may not be complete when the call returns. Refers to the service identifier of the Standardized Interfaces of AUTOSAR basic software. This class represents a single API entry (C-function prototype) into the BSW module or cluster. The name of the C-function is equal to the short name of this element with one exception: In case of multiple instances of a module on the same CPU, special rules for "infixes" apply, see description of class BswImplementation. Specifies the behavior of a BSW module or a BSW cluster w.r.t. the code entities visible by the BSW Scheduler. It is possible to have several different BswBehaviors referring to the same BswModuleDescription. Specifies the behavior of a BSW module or a BSW cluster w.r.t. the code entities visible by the BSW Scheduler. It is possible to have several different BswBehaviors referring to the same BswModuleDescription. Defines an event which is used to trigger a schedulable entity of this BSW module or cluster. The event is local to the BSW module or cluster. The short name of the class instance is intended as an input to configure the required API of the BSW Scheduler. BSW module entity, which is designed for control by the BSW Scheduler. It implements a so-called "main" function. A cyclically recurring BSW event. The cyclic activity has to be implemented by the BSW Scheduler. Requirement for the cycle time (in seconds) by which this event is triggered. A cyclically recurring BSW event. The cyclic activity has to be implemented by the BSW Scheduler. BSW module entity, which is designed to be triggered by an interrupt. Category of the interrupt Allows a textual documentation of the intended interrupt source. BSW module entity, which is designed to be triggered by an interrupt. A BSW event, which can happen sporadically. The event is activated/cancelled by explicit calls from the module to the BSW Scheduler. There a two purposes for such an event: - cause a context switch, e.g. from an ISR context into a task context - implement a time delay Requirement for the delay time (in seconds) after which this event is triggered. The delay is counted from the activation of this event by a BswModuleEntitiy until the actual triggering of another BswModuleEntity associated by the event. A BSW event, which can happen sporadically. The event is activated/cancelled by explicit calls from the module to the BSW Scheduler. There a two purposes for such an event: - cause a context switch, e.g. from an ISR context into a task context - implement a time delay Specifies the smallest code fragment which can be described for a BSW module or cluster within AUTOSAR. Specifies the smallest code fragment which can be described for a BSW module or cluster within AUTOSAR. Representing a configuration value of definition type BooleanParamDef Stores the value of the Boolean parameter. Representing a configuration value of definition type BooleanParamDef Common class to all types of configuration values Abstract class to be used as common parent for all reference values in the ECU Configuration Description. Represents a Container definition in the ECU Configuration Description. Represents a Container definition in the ECU Configuration Description. This represents the anchor point of the ECU configuration description. This represents the anchor point of the ECU configuration description. Representing a configuration value of definition type EnumerationParamDef Stores the chosen literal. Representing a configuration value of definition type EnumerationParamDef Representing a configuration value of definition type FloatParamDef Stores the value of the Float parameter. Representing a configuration value of definition type FloatParamDef Representing a configuration value of definition type FunctionNameDef Representing a configuration value of definition type LinkerSymbolDef Representing a configuration value of definition type StringParamDef Stores the value of the String parameter. Representing a configuration value of definition type StringParamDef InstanceReference representation in the ECU Configuration. InstanceReference representation in the ECU Configuration. Representing a configuration value of definition type IntegerParamDef Stores the value of the Integer parameter. Representing a configuration value of definition type IntegerParamDef Used to represent a configuration value that has a parameter definition of type ConfigReference (used for all of its specializations excluding InstanceReferenceParamDef). Used to represent a configuration value that has a parameter definition of type ConfigReference (used for all of its specializations excluding InstanceReferenceParamDef). Head of the configuration of one Module. A Module can be a BSW module as well as the RTE and ECU Infrastructure. As part of tthe BSW module description, the ModuleConfiguration has two different roles: The recommendedConfiguration contains parameter values recommended by the BSW module vendor. The preconfiguredConfiguration contains values for those parameters which are fixed by the implementation and cannot be changed. These two ModuleConfigurations are used when the base ModuleConfiguration (as part of the base ECU configuration) is created to fill parameters with initial values. Specifies the ConfigurationVariant used for this ModuleConfiguration. Head of the configuration of one Module. A Module can be a BSW module as well as the RTE and ECU Infrastructure. As part of tthe BSW module description, the ModuleConfiguration has two different roles: The recommendedConfiguration contains parameter values recommended by the BSW module vendor. The preconfiguredConfiguration contains values for those parameters which are fixed by the implementation and cannot be changed. These two ModuleConfigurations are used when the base ModuleConfiguration (as part of the base ECU configuration) is created to fill parameters with initial values. Configuration parameter type for Boolean. allowed values are true and false. xml.sequenceOffset="0" Default value of the boolean configuration parameter. Configuration parameter type for Boolean. allowed values are true and false. xml.sequenceOffset="0" Used to define configuration containers that provide a choice between several ParamConfContainerDef. But in the actual ECU Configuration Description only one instance from the choice list will be present (depending on the multiplicites given). Used to define configuration containers that provide a choice between several ParamConfContainerDef. But in the actual ECU Configuration Description only one instance from the choice list will be present (depending on the multiplicites given). Base class used to gather common attributes of configuration container definitions. Specifies if the number of instances of this container may be changed post-build time. This parameter may only be set to true if all of the following conditions hold: - the container's upperMultiplicity > lowerMultiplicity - all parameters within the container and subContainers are post-build time changeable. If any of the aggregated parameters is either pre-compile time or link time this attribute is ignored and may be omitted. Common class used to express multiplicities in the definition of configuration parameters, references and containers. If not stated otherwise the default multiplicity is exactly one mandatory occurrence of the specified element. The lower multiplicity of the specified element. 0: optional 1: at least one occurence n: at least n occurrences The upper multiplicity of the specified element. 1: at most one occurrence m: at most m occurrences *: arbitrary number of occurrences Used to define configuration containers that can hierarchically contain other containers and/or parameter definitions. Specifies whether this container is used to define multiple configuration sets. Only one container in the whole ModuleDef shall have this enabled. Used to define configuration containers that can hierarchically contain other containers and/or parameter definitions. Attributes used by Configuration Parameters as well as References. String specifying if this configuration parameter is an AUTOSAR standardized configuration parameter or if the parameter is hardware- or vendor-specific. Specifies which ConfigurationClass this parameter has in the individual ConfigurationVariants. Specifies the ConfigurationClass for the given ConfigurationVariant. Specifies the ConfigurationVariant the ConfigurationClass is specified for. Specifies which ConfigurationClass this parameter has in the individual ConfigurationVariants. Specifies in the "VendorSpecificModuleDefinition" whether changes on this parameter do affect other parameters in a later configuration step. Specifies which affect do changes in this parameter have on other parameters. Specifies in the "VendorSpecificModuleDefinition" whether changes on this parameter do affect other parameters in a later configuration step. Specify alternative references where in the ECU Configuration description only one of the specified references will actually be used. Specify alternative references where in the ECU Configuration description only one of the specified references will actually be used. Derived value is of type Boolean Allows to define configuration items that are calculated based on the value of * other parameters values * elements (attributes /classes) defined in other AUTOSAR templates such as System template and SW component template. A calculation definition is given which defines how Configuration Editors and Generators can calculate the value from other values when needed to display/use the configuration item. The actual value is stored in the "value" attribute of the derived parameter. xml.sequenceOffset="40" Definition of the formula used to calculate the value of the configuration element. Definition of the languag used to specify the formula in attribute calculationFormula. Currentlfy, only informal definition of the formula is supported. Derived value is an Enumeration. Configuration parameter type for Enumeration. xml.sequenceOffset="0" Default value of the enumeration configuration parameter. This string nees to be one of the literals specified for this enumeration. Configuration parameter type for Enumeration. xml.sequenceOffset="0" Configuration parameter type for enumeration literals definition. Derived value is of type Float Configuration parameter type for Float. xml.sequenceOffset="0" Default value of the float configuration parameter. max value allowed for the parameter defined. min value allowed for the parameter defined. Configuration parameter type for Float. xml.sequenceOffset="0" Derived value is of type Integer. Configuration parameter type for Integer. xml.sequenceOffset="0" Default value of the integer configuration parameter. max value allowed for the parameter defined. min value allowed for the parameter defined. Configuration parameter type for Integer. xml.sequenceOffset="0" Derived value is of type String. Configuration parameter type for String. xml.sequenceOffset="0" Default value of the string configuration parameter. Configuration parameter type for String. xml.sequenceOffset="0" This represents the anchor point of an ECU Configuration Parameter Definition within the AUTOSAR templates structure. This represents the anchor point of an ECU Configuration Parameter Definition within the AUTOSAR templates structure. Used as the top-level element for configuration definition for Software Modules, including BSW and RTE as well as ECU Infrastructure. Specifies which ConfigurationVariants are supported by this software module. Used as the top-level element for configuration definition for Software Modules, including BSW and RTE as well as ECU Infrastructure. Specify a reference to an XML description of an entity desribed in another AUTOSAR template. The type in the AUTOSAR Metamodel to which' instance this reference is allowed to point to. Specify a reference to an XML description of an entity desribed in another AUTOSAR template. Configuration parameter type for Function Names like those used to specify callback functions. Configuration parameter type for Linker Symbol Names like those used to specify memory locations of variables and constants. Specify a reference to an XML description of an entity desribed in another AUTOSAR template using the INSTANCE REFERENCE semantics. The context in the AUTOSAR Metamodel to which' this reference is allowed to point to. The type in the AUTOSAR Metamodel to which' instance this reference is allowed to point to. Specify a reference to an XML description of an entity desribed in another AUTOSAR template using the INSTANCE REFERENCE semantics. Specify references within the ECU Configuration Description between parameter containers. Specify references within the ECU Configuration Description between parameter containers. This specialization of a ReferenceParamDef specifies that the implementation of the reference is done using a symbolic name defined by the referenced Container's shortName. Abstract class used to define the similarities of all ECU Configuration Parameter types defined as subclasses. Specifies that this parameter's value is used, together with the aggregating container, to derive a symbolic name definition. E.g.: #define "container_shortName" "this parameter's value".