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.documentOwner="AUTOSAR GbR";admin.documentStatus="Draft";admin.documentTitle="Metamodel";admin.documentVersion="2.1.4";admin.partOfRelease="2.1";admin.revision="0018";xml.globalElement="true" Root element of an AUTOSAR description, also the root element in corresponding XML documents. admin.documentOwner="AUTOSAR GbR";admin.documentStatus="Draft";admin.documentTitle="Metamodel";admin.documentVersion="2.1.4";admin.partOfRelease="2.1";admin.revision="0018";xml.globalElement="true" Root element of an AUTOSAR description, also the root element in corresponding XML documents. admin.documentOwner="AUTOSAR GbR";admin.documentStatus="Draft";admin.documentTitle="Metamodel";admin.documentVersion="2.1.4";admin.partOfRelease="2.1";admin.revision="0018";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" <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" <language> represents the human language used within the file. Its primary use is to prompt the tools to switch to an appropriate language. This element is in accordance with the ISO 639-1 two letter language codes ( Codes for the Representation of Names of Languages http://www.loc.gov/standards/iso639-2/langcodes.html ). The most frequently used codes are given in : Most common language codes (alphabetical) Code * Language de * German en * English es * Spanish fr * French it * Italian jp * Japanese 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" 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" Use <docRevision> , to generate information on the corresponding document version. asam.harmonizedObject="DOC-REVISION";msr.id="type__DOC-REVISION_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 <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" 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" MultilanguageDataModelForParagraph msr.id="type__ml-data-model-1";msr.isMaster="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" 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 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> . 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> . 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" This element is a "Special Data" element. By using this element it is possible to extend the dtd with a "new" element tag. asam.harmonizedObject="SD";msr.id="type__SD_TYPE";msr.isGroupOnly="true" This element is a "Special Data" element. By using this element it is possible to extend the dtd with a "new" element tag. asam.harmonizedObject="SD";msr.id="type__SD_TYPE";msr.isGroupOnly="true" This is a container for one or several <sdg> (Special Data Group) elements. Special data groups (SDGs) are a standard extension mechanism for harmonized objects; they are used to store data for that no other element exists of the data model in a structured way. It could be considerd as a "well formed island" which allows to carry specific data even if the DTD itself does not expllicitly supports it. this prevents a process designer or a user to entirely switch to another technology if information musst be transferred whichis not explicitly supported. asam.harmonizedObject="ASAM-SDGS";msr.id="type__SDGS_TYPE" This is a container for one or several <sdg> (Special Data Group) elements. Special data groups (SDGs) are a standard extension mechanism for harmonized objects; they are used to store data for that no other element exists of the data model in a structured way. It could be considerd as a "well formed island" which allows to carry specific data even if the DTD itself does not expllicitly supports it. this prevents a process designer or a user to entirely switch to another technology if information musst be transferred whichis not explicitly supported. asam.harmonizedObject="ASAM-SDGS";msr.id="type__SDGS_TYPE" <sdg> (Special Data Group) is a backdoor used to handle elements that has not yet been defined in a DTD. The <sdg> is a containder for one or several <sd> that defines new elements and carries the information. Special Data should only be used moderately since all elements should be defined in the dtd. Thereby should SDG be considered as a temporary sollution when elements are missing. If a <sdgCaption> element is created along with a <shortName> it is possible to reference the <sdg> structure via a <xref>. asam.harmonizedObject="ASAM-SDG";msr.id="type__SDG_TYPE" <sdg> (Special Data Group) is a backdoor used to handle elements that has not yet been defined in a DTD. The <sdg> is a containder for one or several <sd> that defines new elements and carries the information. Special Data should only be used moderately since all elements should be defined in the dtd. Thereby should SDG be considered as a temporary sollution when elements are missing. If a <sdgCaption> element is created along with a <shortName> it is possible to reference the <sdg> structure via a <xref>. asam.harmonizedObject="ASAM-SDG";msr.id="type__SDG_TYPE" <sdg> (Special Data Group) is a backdoor used to handle elements that has not yet been defined in a DTD. The <sdg> is a containder for one or several <sd> that defines new elements and carries the information. Special Data should only be used moderately since all elements should be defined in the dtd. Thereby should SDG be considered as a temporary sollution when elements are missing. If a <sdgCaption> element is created along with a <shortName> it is possible to reference the <sdg> structure via a <xref>. asam.harmonizedObject="ASAM-SDG";msr.id="type__SDG_TYPE" 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" 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" MultiLanguagePlainText msr.id="type__ml-data-10" 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" 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: - In: The signal flow goes into the HW Element. The HW Element is the target for a signal. - Out: The signal flow goes from the HW Element away. The HW Element is the source of a signal. - InOut: Both, incoming and outgoing signal flows 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"). 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. 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. Abstract class to enable the collection of HW Elements. 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). 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. 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. 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. - Read Access: Read Access is available to all memory by default. The data is copied from the memory to another location. - Write Access: Possible only with RAM devices. Data is copied to the memory. - Erase Access: Data stored in specific memory areas is erased and the memory is transferred to a defined initial-state. The erase access is a complex process. The erase access is in many cases prerequisite of a program access. Used on EPROM, EEPROM and Flash. - Program Access: The transfer of data to PROM, EPROM, EEPROM or Flash. In the difference to write access the program access takes more time and is a more complex process to transfer the data. Data is copied to the memory. - Random Access: Data access is not sequenced in memory. Time restrictions are valid in order to address the appropriate memory location and getting the right to access this location with single access. The access time of single data is the important characteristic. - Sequenced Access: The wanted data can only be achieved by reading a defined sequence of data in advance. Typical examples are tapes, certain EEPROM or hardware implemented stacks. - Burst-Mode: A group of data is accessed. The data is stored in continuous addresses and is copied in continuous set of data transfer without an interruption. Access time for the overall data transfer is minimised. For the set-up of a burst mode time restrictions are valid in order to address the appropriate memory location and getting the right to access this location in burst-mode. Set-up time for burst-mode, transfer time of first byte, transfer time of last byte, transfer time for intermediate bytes of a burst and the number of bytes per burst-access are the characteristics of burst-mode access. Burst-mode is used to transfer great amount of data e.g. from a memory with slow access times to a memory with fast access time. Note: The access is denied during erasure and programming of Flash and EEPROM as some technologies do not allow a simultaneous read access to that specific memory area. Also during the simultaneous access of different subscribers on the same memory, array or byte the access is either denied or at least delayed. For example if the CPU and the DMA write to the same memory block. Describes the different possible kinds of access to the memory and the time these access takes. 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. Can be either electrical, optical or wireless. 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. Distinguish between different implementations. - Master: Defines the position within the ECU, as the main controlling unit. The master defines the schedules and controls the telegram traffic. - Slave: Reacts only on request from the master - Multi Master: The PU has to share the external Interface with other PU. No specific master is defined by hardware. 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. 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. A specialization of a Communication HW Port that is availabe for the inter ECU communication. 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 if a PLL or a divides is used to create 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. - Master: Defines the position within the ECU, as the main controlling unit. The master defines the schedules and controls the telegram traffic. - Slave: Reacts only on request from the master - Multi Master: The PU has to share the external Interface with other PU. No specific master is defined by hardware. 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 - Passive: HW Element does not have an influence on ECU electronics (Tri-State). - On: The HW Element supplies other electronics with power e.g. the switch is closed. - Off: HW Element does not supply other electronics with power e.g. the switch is open. - Other: The HW Element has a complex behaviour and must be described by other means. 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. Examples are: - High Side Switch (HS): Power supply is switched - Low Side Switch (LS): GND is switched - Half Bridge (HB): Both Power and GND can be switched exclusive - Full-Bridge (FB): Current direction in load can be alternated - Other: Different and complex functions can be included. Examples are Power ASICs that combine smart power devices within one package. Describe the way the element is reactivated after a self protection sequence was entered - Auto: The element is turned on automatically when the fault situation disappears - Re-Trigger: The element is turned on each time a new trigger is initiated. This new trigger must be initiated by SW. - Fold-Back: The element is turned on automatically or after a new activation trigger with a lower threshold. 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 - Auto: The element is turned on automatically when the fault situation disappears - Re-Trigger: The element is turned on each time a new trigger is initiated. This new trigger must be initiated by SW. - Fold-Back: The element is turned on automatically or after a new activation trigger with a lower threshold. 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. 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. There are several addressing modes possible. Typical attributes are: - Direct - Indirect - Absolute - Base + offset (relative) - Near / far - Pre/Post- Increment/decrement The addressing modes 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 and compiler strategies. The main advantage is available at the level of assembler programming or compiler optimization. The Enumeration is open. There are two kinds of architectures: - Harvard: A computer architecture in which program instructions are stored in different memory from data. Each type of memory is accessed via a separate bus, allowing instructions and data to be fetched in parallel. - Von Neumann: A computer architecture in which each successive operation can read or write any memory location, independent of the location accessed by the previous operation. 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. 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. 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 HW Port Type of a HW Port can be one of the following attributes - unspecified: The attribute is used as a placeholder in the iterative process or if a detailed specification of the HW Port is not required, for example a low-level driver supplied by the semiconductor manufacturer. - Data: Data is the part of the information processed later in the SW Application. - Control: Control is needed by the hardware and the basic SW Routines to manage the overall operation. The attributes Data and Control are defined in the HIS Specification. 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 - Stable: The actuator has a unique defined position after a reset or power down. E.g. a spring force the actuator back into a start position or there are means which give a position feedback like a potentiometer or switch. - Instable: The position of the actuator can not be specified after power on or reset or the position of the actuator can be changed by other means - Bi-stable: The actuator has two possible, defined positions after a reset or power down. E.g. the actuator is in one of the two possible end positions. Only one of them is signalled by a feedback, e.g. a switch. The second end position is simply to be determined as the inversion of the feedback. - Multi-stable: The actuator has more possible, defined positions after a reset or power down and they are signalled by appropriate feedback E.g. a door latch might consist of different stable states: pre-locked, locked, double locked, released, open from outside, open from inside, All this states are covered by a feedback, and the states can change in random manner after the wake-up or power-up of a car. 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). - Resistive: Heater, Lamp - Inductive: Coils, Motor - Capacitive: Extra SuperCAPS for bordnet stability 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. - Unidirectional: The actuator is only forced in one direction by SW. e.g. eject of a tape. The user or a other mechanical system is needed to chance the status of the actuator. Other example is a motor which has a circular movement always in one direction. SW can not alter this behaviour e.g. fan, wiper. - Bidirectional: The actuator can be moved forward and backward by software, e.g. window lift - Unidirectional with autoreset: The actuator is controlled only one direction by electrical means and SW. Bringing the actuator in to the default position other means are available. E.g. unlock of the trunk or gasoline flap with a motor which is brought into the initial position with a spring; a relay or a valve use the same mechanism. HW Element Actuator definition. 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 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. If the display can present numerical, alpha-numerical, semi-graphical or graphical objects. 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. - Raw: The information are transferred without any signal processing from the sensor to the according electronic. Possible spikes and noise is present on the line. In order to use this signal an appropriate signal processing have to be performed. - Filtered: The information passed some filter mechanism in order to remove noise and spikes from the signal. The signal can be in a discrete form, At least the limit e.g. the -3dB limit, must be available to the software if this limit is close to the used bandwidth, needed for the planed application. If more complex filter like bandpasses or notch filter are used the filter characteristic must be modelled and imported for the according SW-Component as well. - Debounced: The information was already processed by some electronics in order to get a clear and unique representation of the information. Debouncing is a sort of filter which suppress the noises and spikes which are generated by the bouncing when a switch is opened or closed. Debouncing is similar to Filtered, but the input is only represented by digital values instead of analogue values. Typical debouncing electronics are mono- flops or sampling , plus a majority encoder to represent a more stable signal. - Coded: The information is filtered and debounced, but furthermore represented in a digital encoded form. Examples are sensor connected via a serial communication bus like LIN to the ECU. It must be noted that the complexity of the ECU will have a concomitant effect on the complexity of the corresponding ECU SW abstraction. Generally the more complex the ECU electronics, the more complex the abstract interfaces will be for the user to configure. HW Element Sensor 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 In the context of a component there is no typed re-use of CalprmElementPrototype entities The existence of <swArraysize> turns the parent element into a multidimensional object. It is then possible to create arrays of variables, parameters etc. <swArraysize> should ** to imitate stereotypes such as curves or maps since these structures are stored in the DTD itself as own elements, refer to <swCalprmAxisSet> for a <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 parent element into a multidimensional object. It is then possible to create arrays of variables, parameters etc. <swArraysize> should ** to imitate stereotypes such as curves or maps since these structures are stored in the DTD itself as own elements, refer to <swCalprmAxisSet> for a <swCalprm>. Apart from that any array can be created. asam.useCase="MDX";msr.id="type__SW-ARRAYSIZE_TYPE";msr.isGroupOnly="true" 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 element is used by a Variable that actually is a part of an other Variable called Host Variable. The BIT-POSITION points out the starting point of the Variable in the Host Variable. msr.id="SW-BIT-REPRESENTATION_TYPE__BIT-POSITION";msr.tbdString="true";xml.sequenceOffset="20" Number of bits of a bit variable (described by <swBitRepresentation>), calculation based on the position specified by the parallel element <bitPosition> . 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" 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: akt. Temperatur V: akt. Geschwindigkeit eingeblendet im MCD-System zu Vergleichszwecken: SW-COMPARISON-VARIABLE Vs: Geschwindigkeitsschwelle über Temperatur tmot: Motortemperatur 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: akt. Temperatur V: akt. Geschwindigkeit eingeblendet im MCD-System zu Vergleichszwecken: SW-COMPARISON-VARIABLE Vs: Geschwindigkeitsschwelle über Temperatur tmot: Motortemperatur msr.id="type__SW-COMPARISON-VARIABLES_TYPE" Use <v> to enter a numerical value. xml.sequenceOffset="50";msr.id="SW-GENERIC-AXIS-PARAM-VALUE__V" This element describes the interdependencies of variables and parameters. These can be used for example, to treat virtual parameters. msr.id="type__SW-DATA-DEPENDENCY_TYPE" This element describes the formula with which the dependencies between the participating objects are defined. The formulae are texts which formulate first order arithmetical expressions. The following syntax is valid: 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 msr.id="SW-DATA-DEPENDENCY_TYPE__SW-DATA-DEPENDENCY-FORMULA";msr.tbdString="true";xml.sequenceOffset="30" This element describes the interdependencies of variables and parameters. These 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" This element indicates, that the data object (which is specified by the parent element) is a reference to another data object. The properties of the referred data object are described in the <swDataDefProps> contained in the <swPointer> . asam.useCase="MDX";msr.id="type__SW-POINTER_TYPE" This element indicates, that the data object (which is specified by the parent element) is a reference to another data object. The properties of the referred data object are described in the <swDataDefProps> contained in the <swPointer> . asam.useCase="MDX";msr.id="type__SW-POINTER_TYPE" This element denotes a variable which servers as a semaphore variable for a particular ressource which is specified in the surrounding <swDataDefProps> msr.id="type__SW-SEMAPHORE_TYPE" This element denotes a variable which servers as a semaphore variable for a particular ressource which is specified in the surrounding <swDataDefProps> msr.id="type__SW-SEMAPHORE_TYPE" 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 <SwCalprmMaxTextSize> in the parent element <SwCalprmText> . 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" This element references <swVariable> . asam.useCase="MDX";msr.id="type__SW-VARIABLE-REF_TYPE" This element references <swVariable> . asam.useCase="MDX";msr.id="type__SW-VARIABLE-REF_TYPE" This element describes all of the distinguishing characteristics of a data object (variable or parameter). <swDataDefProps> is used in every case, where characteristics of data objects must be given. It is inevitable that not all of the inputs are useful all of the time. Hence, the process definition or the DCI has the task of implementing limitations. The <swDataDefProps> describe the characteristics of all axes: * The characteristics of the argument axes (abscissas) are described in <swCalprmAxisSet> . * The characteristics of the value axis are described directly in <swDataDefProps> . asam.useCase="MDX";msr.id="type__SW-DATA-DEF-PROPS_TYPE";msr.isCond="true" Describes the applicability of parameters and variables. Valid values are: * NOT-ACCESSIBLE : The element will not appear in an ASAP file. * READ-ONLY : The element will only appear as read-only in an ASAP file. * READ-WRITE : Both read and write access. msr.id="SW-DATA-DEF-PROPS_TYPE__SW-CALIBRATION-ACCESS";msr.tbdString="true";xml.sequenceOffset="70" <swImplPolicy> 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. The contents of the element comprise of a key word which is to be declared in the process. Examples of possible values are * MEMORY_OPTIMIZED * CPU-OPTIMIZED * INPLACE * SINGLE-INSTANCE * MULTI-INSTANCE msr.id="SW-DATA-DEF-PROPS_TYPE__SW-IMPL-POLICY";msr.tbdString="true";xml.sequenceOffset="230" This element describes all of the distinguishing characteristics of a data object (variable or parameter). <swDataDefProps> is used in every case, where characteristics of data objects must be given. It is inevitable that not all of the inputs are useful all of the time. Hence, the process definition or the DCI has the task of implementing limitations. The <swDataDefProps> describe the characteristics of all axes: * The characteristics of the argument axes (abscissas) are described in <swCalprmAxisSet> . * The characteristics of the value axis are described directly in <swDataDefProps> . asam.useCase="MDX";msr.id="type__SW-DATA-DEF-PROPS_TYPE";msr.isCond="true" Through this element, a <swCalprm> is referenced. Through this element, a <swCalprm> is referenced. This element specifies an individual input parameter axis (abscissa). The following belongs to this: * Which axis is involved ( <swAxisIndex> ) * Whether the axis is integrated ( <swAxisIndividual>) or whether it is adopted from another parameter ( <swAxisGrouped> ). * Whether the axis can be applicated ( <swCalibrationAccess> ). * Which display format should be used for the axis ( <SW-DISPLAY-FORMAT> ). * Which base type should be used for the axis ( <SW-BASE-TYPE-REF> ). asam.useCase="MDX";msr.id="type__SW-CALPRM-AXIS_TYPE" <swAxisIndex> describes the index referring to the axis currently described, for which the contents is specified. The index satisfies the following convention: : : : : msr.id="SW-CALPRM-AXIS_TYPE__SW-AXIS-INDEX";msr.tbdString="true";xml.sequenceOffset="20" 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. 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 element specifies an individual input parameter axis (abscissa). The following belongs to this: * Which axis is involved ( <swAxisIndex> ) * Whether the axis is integrated ( <swAxisIndividual>) or whether it is adopted from another parameter ( <swAxisGrouped> ). * Whether the axis can be applicated ( <swCalibrationAccess> ). * Which display format should be used for the axis ( <SW-DISPLAY-FORMAT> ). * Which base type should be used for the axis ( <SW-BASE-TYPE-REF> ). asam.useCase="MDX";msr.id="type__SW-CALPRM-AXIS_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 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 characteristics of calibration parameters in the ECU. Calibration parameters are objects that are not adapted to the run time of the vehicle. Instead, they calibrated to a greater extent in the application phase. Variables are quite the opposite ( <swVariable> s), being objects that are manipulated during the run time of the software. For the most part, calibration parameters consist of: * Long and short names ( <longName>, <shortName> ) * Short description ( <desc> ) * Category ( <category> ), describing the basic structure of the parameter * Field parameter ( <swArraysize> ), in case the parameter an array * The technical characteristics ( <swDataDefProps>) These are identical to the technical characteristics of variables * Sub-structures simulated through the integration of <swCalprms> . * Comments ( <annotations> ), enabling notes to be passed on from one stage to the next, throughout the development process. * Additional information ( <addInfo>) in verbal form. Here, formal components can also be accommodated when SI -attributes are used. Allocation of <category> Value Conforms to ASAP * Meaning ** Remark VALUE * Characteristic value ** This represents a single value. CURVE_INDIVIDUAL * Characteristic ** This represents a curve with an embedded axis. MAP_INDIVIDUAL * Map ** This represents a map with embedded axes. CURVE_FIXED * Fixed characteristic ** This indicates a curve where the axes are calculated by the ECU program. The algorithm is fixed and therefore the axis-points can not be calibrated. The parameters of the algorithm may in some cases be specified by applying <swAxisGeneric> . MAP_FIXED * Fixed map ** This indicates a map where the axes are calculated by the ECU program. The algorithm is fixed and therefore the axis-points can not be calibrated. The parameters of the algorithm may in some cases be specified by applying <swAxisGeneric> . CURVE_GROUPED * Group characteristic ** This indicates a curve which uses the axis-points of another calibration parameter which is then referred to by <swCalprmRef> in <swAxisGrouped> . MAP_GROUPED * Group map ** This indicates a map which uses the axis-points of another calibration parameter which is then referred to by <swCalprmRef> in <swAxisGrouped> . ASCII * Characteristic text ** This indicates a parameter in text form (e.g. a message). STRUCTURE * Parameter structure ** This indicates a structure of calibration parameters. In this case, an embedded <swCalprm> should exist. VALUE_BLOCK * Characteristic values block ** This indicates a homogeneous parameter set which is handled as a block. Unlike structures or arrays, the components of a value block appear in the instance tree within one <swInstance> . AXIS_VALUES * Group datapoints ** This indicates the axis points of a calibration parameter, which are referenced in <SW-AXIS-GROUP> by a calibration parameter of the category MAP_GROUPED or CURVE_GROUPED . asam.useCase="MDX";msr.id="type__SW-CALPRM_TYPE";msr.isNamespace=" TeamMembe SwGenericAxisPara SwCalpr" This element specifies the characteristics of calibration parameters in the ECU. Calibration parameters are objects that are not adapted to the run time of the vehicle. Instead, they calibrated to a greater extent in the application phase. Variables are quite the opposite ( <swVariable> s), being objects that are manipulated during the run time of the software. For the most part, calibration parameters consist of: * Long and short names ( <longName>, <shortName> ) * Short description ( <desc> ) * Category ( <category> ), describing the basic structure of the parameter * Field parameter ( <swArraysize> ), in case the parameter an array * The technical characteristics ( <swDataDefProps>) These are identical to the technical characteristics of variables * Sub-structures simulated through the integration of <swCalprms> . * Comments ( <annotations> ), enabling notes to be passed on from one stage to the next, throughout the development process. * Additional information ( <addInfo>) in verbal form. Here, formal components can also be accommodated when SI -attributes are used. Allocation of <category> Value Conforms to ASAP * Meaning ** Remark VALUE * Characteristic value ** This represents a single value. CURVE_INDIVIDUAL * Characteristic ** This represents a curve with an embedded axis. MAP_INDIVIDUAL * Map ** This represents a map with embedded axes. CURVE_FIXED * Fixed characteristic ** This indicates a curve where the axes are calculated by the ECU program. The algorithm is fixed and therefore the axis-points can not be calibrated. The parameters of the algorithm may in some cases be specified by applying <swAxisGeneric> . MAP_FIXED * Fixed map ** This indicates a map where the axes are calculated by the ECU program. The algorithm is fixed and therefore the axis-points can not be calibrated. The parameters of the algorithm may in some cases be specified by applying <swAxisGeneric> . CURVE_GROUPED * Group characteristic ** This indicates a curve which uses the axis-points of another calibration parameter which is then referred to by <swCalprmRef> in <swAxisGrouped> . MAP_GROUPED * Group map ** This indicates a map which uses the axis-points of another calibration parameter which is then referred to by <swCalprmRef> in <swAxisGrouped> . ASCII * Characteristic text ** This indicates a parameter in text form (e.g. a message). STRUCTURE * Parameter structure ** This indicates a structure of calibration parameters. In this case, an embedded <swCalprm> should exist. VALUE_BLOCK * Characteristic values block ** This indicates a homogeneous parameter set which is handled as a block. Unlike structures or arrays, the components of a value block appear in the instance tree within one <swInstance> . AXIS_VALUES * Group datapoints ** This indicates the axis points of a calibration parameter, which are referenced in <SW-AXIS-GROUP> by a calibration parameter of the category MAP_GROUPED or CURVE_GROUPED . asam.useCase="MDX";msr.id="type__SW-CALPRM_TYPE";msr.isNamespace=" TeamMembe SwGenericAxisPara SwCalpr" Indicates the basic type how the object (measurement or calibration parameter) is handled within the ECU. asam.useCase="MDX";msr.id="type__BASE-TYPE_TYPE";msr.isMaster="true" describes the alignment of the memory object in bits msr.id="BASE-TYPE_directDefinition_TYPE__MEM-ALIGNMENT";msr.tbdString="true";xml.sequenceOffset="100" 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 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. The following is valid: * The algorithm to be used is specified as <swAxisType> in the data dictionary ** (reservation of keyword and specification of parameters). Thus when forming an axis, the algorithm is given through the appropriate reference ( <swAxisTypeRef> ). * The number of base points to be calculated is defined in <SW-NUMER-OF-AXIS-POINTS>. This element exists to enable the number of axis points to be stored explicitly, although it could also be described as <swGenericAxisParam> . * The calculated base points can be stored on a physical level in the element <swValuesPhys> , which means that it is not necessary for the required calculation algorithm to be implemented in every MCD system. * The calculated base points can be stored on a standardized level in the element <swValuesCoded> , which means that it is not necessary for the required calculation algorithm to be implemented in every MCD system. 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. The following is valid: * The algorithm to be used is specified as <swAxisType> in the data dictionary ** (reservation of keyword and specification of parameters). Thus when forming an axis, the algorithm is given through the appropriate reference ( <swAxisTypeRef> ). * The number of base points to be calculated is defined in <SW-NUMER-OF-AXIS-POINTS>. This element exists to enable the number of axis points to be stored explicitly, although it could also be described as <swGenericAxisParam> . * The calculated base points can be stored on a physical level in the element <swValuesPhys> , which means that it is not necessary for the required calculation algorithm to be implemented in every MCD system. * The calculated base points can be stored on a standardized level in the element <swValuesCoded> , which means that it is not necessary for the required calculation algorithm to be implemented in every MCD system. asam.useCase="MDX";msr.id="type__SW-AXIS-GENERIC_TYPE" Reserves names for specific axis calculation strategies. 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; the parameters ( <swGenericAxisParamTypes>) 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" Reserves names for specific axis calculation strategies. 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; the parameters ( <swGenericAxisParamTypes>) 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 a generic axis type which contains: * Plausibility checks can be specified ( <SW-DATA-CONSTR-REF> ). * 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" This element describes a specific parameter of a generic axis. For this parameter, the following must be specified: * The name of the parameter; implemented here through a reference ( <swGenericAxisParamTypeRef>) to a parameter defined on a corresponding axis type. This is contained in the sister element <swAxisTypeRef> of the corresponding <swGenericAxisParams> element. References can only be made to axis parameters, defined within the referenced axis type. * The value of the parameter, specified in the element <vf> . asam.useCase="MDX";msr.id="type__SW-GENERIC-AXIS-PARAM_TYPE" This element describes a specific parameter of a generic axis. For this parameter, the following must be specified: * The name of the parameter; implemented here through a reference ( <swGenericAxisParamTypeRef>) to a parameter defined on a corresponding axis type. This is contained in the sister element <swAxisTypeRef> of the corresponding <swGenericAxisParams> element. References can only be made to axis parameters, defined within the referenced axis type. * The value of the parameter, specified in the element <vf> . asam.useCase="MDX";msr.id="type__SW-GENERIC-AXIS-PARAM_TYPE" This element describes an axis integrated into a parameter (field etc.). The integration makes this individual to each parameter. The so-called group axis represents the counterpart to this. It is conceived as an independent parameter and is referenced by the respective parameters used ( <swCalprmRef> within <swAxisGrouped> ). The specification of this axis incorporates: * Possible input variables for the axis ( <swVariableRefs> ). It is possible to specify more than one variable. Here the following is valid: * The variable with the highest priority must be given first. It is used in the generation of the code and is also displayed first in the application system. * All variables referenced must be of the same physical nature. This is usually detected in that the conversion formulae affected refer back to the same ( <SI-UNIT> s). * This multiple referencing allows a base point distribution for more than one input variable to be used. One example of this are the temperature curves, which can depend both on the induction air temperature and the engine temperature. These variables can be displayed simultaneously by MCD systems (adjustment systems), enabling operating points to be shown in the curves. * a conversion formula ( <SW-COMPU-METHOD-REF> ) * a measuring unit ( <SW-UNIT-REF> ) * a bit representation ( <swBitRepresentation> ) * Maximum and minimum number of axis base points ( <swMaxAxisPoints>, <swMinAxisPoints> ) * Plausibility checks ( <SW-DATA-CONSTR-REF> ) * Generic axis characteristics ( <swAxisGeneric> ), in the event that such an axis is involved. The specifications <swVariableRefs>, <SW-COMPU-METHOD-REF>, <SW-UNIT-REF> 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> * <SW-COMPU-METHOD-REF> * <SW-UNIT-REF> 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 group axis represents the counterpart to this. It is conceived as an independent parameter and is referenced by the respective parameters used ( <swCalprmRef> within <swAxisGrouped> ). The specification of this axis incorporates: * Possible input variables for the axis ( <swVariableRefs> ). It is possible to specify more than one variable. Here the following is valid: * The variable with the highest priority must be given first. It is used in the generation of the code and is also displayed first in the application system. * All variables referenced must be of the same physical nature. This is usually detected in that the conversion formulae affected refer back to the same ( <SI-UNIT> s). * This multiple referencing allows a base point distribution for more than one input variable to be used. One example of this are the temperature curves, which can depend both on the induction air temperature and the engine temperature. These variables can be displayed simultaneously by MCD systems (adjustment systems), enabling operating points to be shown in the curves. * a conversion formula ( <SW-COMPU-METHOD-REF> ) * a measuring unit ( <SW-UNIT-REF> ) * a bit representation ( <swBitRepresentation> ) * Maximum and minimum number of axis base points ( <swMaxAxisPoints>, <swMinAxisPoints> ) * Plausibility checks ( <SW-DATA-CONSTR-REF> ) * Generic axis characteristics ( <swAxisGeneric> ), in the event that such an axis is involved. The specifications <swVariableRefs>, <SW-COMPU-METHOD-REF>, <SW-UNIT-REF> 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> * <SW-COMPU-METHOD-REF> * <SW-UNIT-REF> asam.useCase="MDX";msr.id="type__SW-AXIS-INDIVIDUAL_TYPE" A group axis is described in <swAxisGrouped>, as an alternative to <swAxisIndividual> . A group axis is specified using * the reference ( <swCalprmRef> ) to the parameter from which an axis should be imported, which is then to serve as a group axis * the index of the axis to be used ( <swAxisIndex>). This index should only be specified if the parameter under <swCalprmRef> contains more than one axis. It is standard practise for the axis index of parameters with more than one axis, to be set to 1, if data has not been assigned to <swAxisIndex> . * If SW-AXIS-INDEX is equal to 0, the interpolation result of the referenced parameter is used as a base point index. This means that the keyword CURVE_AXIS_REF can be supported. asam.useCase="MDX";msr.id="type__SW-AXIS-GROUPED_TYPE" A group axis is described in <swAxisGrouped>, as an alternative to <swAxisIndividual> . A group axis is specified using * the reference ( <swCalprmRef> ) to the parameter from which an axis should be imported, which is then to serve as a group axis * the index of the axis to be used ( <swAxisIndex>). This index should only be specified if the parameter under <swCalprmRef> contains more than one axis. It is standard practise for the axis index of parameters with more than one axis, to be set to 1, if data has not been assigned to <swAxisIndex> . * If SW-AXIS-INDEX is equal to 0, the interpolation result of the referenced parameter is used as a base point index. This means that the keyword CURVE_AXIS_REF can be supported. asam.useCase="MDX";msr.id="type__SW-AXIS-GROUPED_TYPE" This element specifies a short name for the context element. This label cannot be referenced in the same way as a <shortName> in connection with MSRSW (queries, external applications etc.). 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 class represents the rules how to contraint a particular data object. Such constraints are mainly limits but also monotony requirements. See ASAM-HDO for details. asam.harmonizedObject="ASAM-DATA-CONSTR";asam.useCase="MDX";msr.id="type__DATA-CONSTR_TYPE" This class represents the rules how to contraint a particular data object. Such constraints are mainly limits but also monotony requirements. See ASAM-HDO for details. asam.harmonizedObject="ASAM-DATA-CONSTR";asam.useCase="MDX";msr.id="type__DATA-CONSTR_TYPE" This element specifies the characteristics of variables (measurands) in the ECU. Variables are objects that are not adapted to the run time of the vehicle. Calibration parameters are quite the opposite ( <swCalprm> s), being objects that are manipulated during the run time of the software. For the most part, variables consist of: * Long and short labels ( <longName>, <shortName> ) * Short description ( <desc> ) * Category ( <category> ), describing the basic structure of the variables * Field size ( <swArraysize> ), in case the variable is executed as an array * The technical characteristics ( <swDataDefProps>) These are identical to the technical characteristics of parameters * Sub-structures simulated through the integration of <swVariables> . * Comments ( <annotations> ), enabling notes to be passed on from one stage to the next, throughout the development process. * Additional information ( <addInfo>) in verbal form. Here, formal components can also be accommodated when SI -attributes are used. asam.useCase="MDX";msr.id="type__SW-VARIABLE_TYPE";msr.isNamespace=" TeamMembe SwGenericAxisPara SwCalpr SwFeatureVarian SwInstanc SwInstanc SwServiceArg SwServiceRetur SwVariabl" This element specifies the characteristics of variables (measurands) in the ECU. Variables are objects that are not adapted to the run time of the vehicle. Calibration parameters are quite the opposite ( <swCalprm> s), being objects that are manipulated during the run time of the software. For the most part, variables consist of: * Long and short labels ( <longName>, <shortName> ) * Short description ( <desc> ) * Category ( <category> ), describing the basic structure of the variables * Field size ( <swArraysize> ), in case the variable is executed as an array * The technical characteristics ( <swDataDefProps>) These are identical to the technical characteristics of parameters * Sub-structures simulated through the integration of <swVariables> . * Comments ( <annotations> ), enabling notes to be passed on from one stage to the next, throughout the development process. * Additional information ( <addInfo>) in verbal form. Here, formal components can also be accommodated when SI -attributes are used. asam.useCase="MDX";msr.id="type__SW-VARIABLE_TYPE";msr.isNamespace=" TeamMembe SwGenericAxisPara SwCalpr SwFeatureVarian SwInstanc SwInstanc SwServiceArg SwServiceRetur SwVariabl" An address schematic <swAddrMethod> describes how variables or parameters are addressed in the ECU. Address methods can take the form of direct addressing or indirect addressing using a vector. The principle role of this element is the declaration of keywords (in the subelement <shortName>) for the address calculation process. The process itself is given a verbal description (in <swAddrMethodDesc>) rather than a formal one. However, a formal reference <swCpuMemSegRef> to the memory segment concerned is issued. In future versions further formal components may be added to this, if required. . This approach was adopted as the number of possible address schematics is relatively small. A complete formal description would create unnecessary work. asam.useCase="MDX";msr.id="type__SW-ADDR-METHOD_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 embedded. 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 embedded. 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 <swRecordLayoutRef> may reference other <swRecordLayout>s. ** <swRecordLayoutRef>, <swRecordLayoutV> and <swRecordLayoutGroup> ** 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 <swRecordLayoutGroup>. The sister elements on the right-hand side of the tree next to <swRecordLayoutGroupAxis> refer exactly to this axis number. 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 <swRecordLayoutGroup>. 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 <swRecordLayoutGroup> 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 <swRecordLayoutGroup> . 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 <swRecordLayoutRef> may reference other <swRecordLayout>s. ** <swRecordLayoutRef>, <swRecordLayoutV> and <swRecordLayoutGroup> ** for the modeled record layout. asam.useCase="MDX";msr.id="type__SW-RECORD-LAYOUT-GROUP_TYPE" This element specifies which values are stored for the current <swRecordLayoutGroup>. If no <SW-BASE-TYPE-REF> is present, the <SW-BASE-TYPE> 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 <SW-RECORD-V-INDEX>, 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 specifies the number of axes with values that are stored in the ECU. Refer to <swRecordLayoutV> for further details. msr.id="SW-RECORD-LAYOUT-V_TYPE__SW-RECORD-LAYOUT-V-AXIS";msr.tbdString="true";xml.sequenceOffset="40" The contents of this element describes the type of values to be stored. The following are permitted: : : : : : : : : : : : : 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 a <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 element specifies the filler character for the current record layout, in the form of hex digits. The element present parallel to this <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 <SW-BASE-TYPE-REF> is present, the <SW-BASE-TYPE> 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 <SW-RECORD-V-INDEX>, 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" Code syntax objects fix the representation of the variables and parameters in the program source file. These code syntax objects are defined centrally in <swCodeSyntaxes> and are connected to variables and parameters 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. It is possible however, to store a process-dependent micro syntax in <swCodeSyntaxDesc>, for example within <verbatim> and to label this through a suitable data assignment to the attribute SI . msr.id="type__SW-CODE-SYNTAX_TYPE" this class assignes data def properties to particular prototypes. This pattern is necessary, since the interrunnable Variable might be duplicated in case the software component referenced by the InternalBehavior is instantiated more than once on the same ecu. this class assignes data def properties to particular prototypes. This pattern is necessary, since the interrunnable Variable might be duplicated in case the software component referenced by the InternalBehavior is instantiated more than once on the same ecu. An assembly connector connects a p-port to an r-port. Unlike a delegation connector, assembly connectors are "real" in the sense that there will be some kind of physical representation (bus, shared memory, ...) they are mapped to. An assembly connector connects a p-port to an r-port. Unlike a delegation connector, assembly connectors are "real" in the sense that there will be some kind of physical representation (bus, shared memory, ...) they are mapped to. The base class for connectors between ports. Connectors have to be identifiable to allow references from the system constraint template. Aggregating component type to encapsulate and abstract subsystem functionality. Compositions contain instances of the component parts, as well as the connections between them. Aggregating component type to encapsulate and abstract subsystem functionality. Compositions contain instances of the component parts, as well as the connections between them. A ServiceConnectorPrototype connects an application component required-service port with the service port provided by the service component. They are only added to the model in ECU Configuration phase for the specific purpose of configuring services within an EcuSwComposition. A ServiceConnectorPrototype connects an application component required-service port with the service port provided by the service component. They are only added to the model in ECU Configuration phase for the specific purpose of configuring services within an EcuSwComposition. A delegation connector simply delegates one inner port (a port of a component that is used inside the composition) to a port of identical type that belongs directly to the composition (a port that is owned by the composition). Just as compositions they are solely for structuring the model and have no physical meanig. In particular, delegation ports cannot merge or dispatch data. A delegation connector simply delegates one inner port (a port of a component that is used inside the composition) to a port of identical type that belongs directly to the composition (a port that is owned by the composition). Just as compositions they are solely for structuring the model and have no physical meanig. In particular, delegation ports cannot merge or dispatch data. 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 Specifies the SWCs needs on the configuration of the Communication Manager for the "user" associated with this specific Service Port. maximum communication mode requested by the ComM user associated with this Service Port Specifies the SWCs needs on the configuration of the Communication Manager for the "user" associated with this specific Service Port. Annotation to a service port of an atomic SWC. It expresses the needs the SWC has on the configuration of the infrastructure (AUTOSAR Service, ECU abstraction or Complex Driver) to which it will be connected via this port. Allows the specification of port annotations not yet part of the software component template. Name of the annotation. Value of the annotation. Allows the specification of port annotations not yet part of the software component template. This attribute is only applicaple in SET operations. If it is enabled, the IoHwAbstraction layer will monitor the result of the opeation and issue an diagnostic signal. This means especially, that an additional client-server port has to be created. Tools can use this information to cross-check whether for each data-element in a SET operation with FailureMonitoring enabled an additional port is created This attribute is only applicaple in SET operations. If it is enabled, the IoHwAbstraction layer will monitor the result of the opeation and issue an diagnostic signal. This means especially, that an additional client-server port has to be created. Tools can use this information to cross-check whether for each data-element in a SET operation with FailureMonitoring enabled an additional port is created The ClientServer Port 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. RAW_DATA means that no modification of the signal has been applied.This is the default value DEBOUNCE_DATA means that the signal is a mean value WAIT_TIME_DATE means that the signal is delivered by a GET operation after a certain amount of time This attribute indicates to the connected Actuator Software component whether the data-element can be used to generate pulse test sequences using the IoHwAbstration 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 ClientServer Port 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. Specifies the SWCs needs on the configuration of an NVRAM block associated with this specific Service Port. 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 The needs for configuring callbacks can also be derived from the existence of additional ports required for that. The optional association of a RAM mirror block and/or a ROM default block with this NVRAM block is modeled by references from the corresponding elements of the InternalBehavior to this port annotation. 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. low: Data loss is uncritical medium: Data loss should be avoided high: Data loss is critical These requirements give only a relative indication, for example on the required degree of redundancy for storage. They do however not specify by which means (e.g. software or hardware) the reliability is actually achieved. Defines whether a NVRAM 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. true: If the current write access fails, the last data of this block is still available and stored on the non volatile medium. false: If the current write access fails, the current and/or last data of this block may be lost. 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 SWCs needs on the configuration of an NVRAM block associated with this specific Service Port. 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 The needs for configuring callbacks can also be derived from the existence of additional ports required for that. The optional association of a RAM mirror block and/or a ROM default block with this NVRAM block is modeled by references from the corresponding elements of the InternalBehavior to this port annotation. 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 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. Indicates whether the data element carries a minimum or maximum value, thereby limiting the current range of another value. 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 softwar component's runnable is transmitted to another software component whose runnable will use this value as a limit, e.g. the max.power which can be used by that component, or the current min. slip. Kind of processing applied to the data element. "raw" specifies that a signal is taken directly from the basic software modules, i.e. from the ECU abstraction layer. It indicates to a developer that the control algorithm in the software has to provide filters. "filtered" indicates that a raw signal has been manipulated by some application software components by using filters. "none" is specified if none of the previous two options apply. Annotation of a sender port, specifying properties of data elements that don't affect communication or generation of the RTE. The given attributes are assertions on the provided data. Specifies the SWCs needs on the configuration of the Watchdog Manager for the Supervised Entity (SE) associated with this specific Service Port. 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 SWCs needs on the configuration of the Watchdog Manager for the Supervised Entity (SE) associated with this specific Service Port. Base class for annotations of ports. Annotations are attributes that formally specify features and requirements of ports that have currently no influence on the generation of the RTE or the communication in general. The ModePrototype specifies the set of Modes (ModeDeclarationGroup) that is supported by a ComponentType. The ModePrototype 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 ports of a software component. This flag is set, if the port interface is to be used for comunication between an atomic software component and a component of the basic software (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. What the actual modes are and how they are named is covered by different WPs. A collection of Mode Declarations. What the actual modes are and how they are named is covered by different WPs. Communication attributes for both sender /server port (P-Port and sender-receiver interface). (0=unqueued) Length of call queue on the server side. The queue is implemented by the RTE. Communication attributes for both sender /server port (P-Port and sender-receiver interface). (0=unqueued) 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 reciving data (opposed to receiving events). 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 reciving data (opposed to receiving events). Communication attributes specific to reciving events. Length of queue for received events. Communication attributes specific to reciving events. Client specific communication attributes (R-Port and client-server interface). Client specific communication attributes (R-Port and client-server interface). Communication attributes for connectors between sender and receiver ports. Maximum allowed time (seconds) for date transfer via this connector. The time has to be measured from the moment, at which the information to be sent has been made available by the sending component at its P-Port until it is ready to be used by the receiving component at its R-Port. Minimum allowed time (seconds) for date transfer via this connector. The time has to be measured from the moment, at which the information to be sent has been made available by the sending component at its P-Port until it is ready to be used by the receiving component at its R-Port. Note that in many cases the minimum required time will be zero. Communication attributes for connectors between sender and receiver ports. Communication attributes for connectors between client and server ports. Communication attributes for connectors between client and server ports. 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 lower bounddary Value to specify the lower bounddary 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 lower bounddary Value to specify the lower bounddary Pass a message if its value is within a predefined boundary. min <= new_value <= max Pass a message once every N message occurrences. 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). Pass a message once every N message occurrences. 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). These errors are tracked by DET. They are not relevant for the production environment. Not further examined as of now. 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. 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 represents the so called computation method describing the method how to convert between a physical value and a numerical value. See ASAM-HDO specification for details. asam.harmonizedObject="ASAM-COMPU-METHOD";asam.useCase="MDX";msr.id="type__COMPU-METHOD_TYPE" This represents the so called computation method describing the method how to convert between a physical value and a numerical value. See ASAM-HDO specification for details. asam.harmonizedObject="ASAM-COMPU-METHOD";asam.useCase="MDX";msr.id="type__COMPU-METHOD_TYPE" 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 context element. This label cannot be referenced in the same way as a <shortName> in connection with MSRSW (queries, external applications etc.). msr.id="COMPU-SCALE_TYPE__SHORT-LABEL";msr.tbdString="true";xml.sequenceOffset="20" Use <unit> to enter the unit of a parameter. asam.harmonizedObject="ASAM-UNIT";asam.useCase="MDX";msr.id="type__UNIT_TYPE" Use <unit> to enter the unit of a parameter. 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 whether single or double precision is used. 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. Description of consumed resources by one implementation of a software component. Description of consumed resources by one implementation of a software component. 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. The objectFileSection provides additional information to the different sections in the object-file containing the implementation of the SW-C The alignment (typically 1, 2, 4,...) Is code stored in this section that needs to be executed. In some processor architectures code execution is only allowed from specific memory sections. This is the name of the section in the object-file The size in bytes of the section. Is it possible to write this section. The objectFileSection provides additional information to the different sections in the object-file containing the implementation of the SW-C 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. 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 stack memory usage of a software 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. Describes the heap memory usage of a SW-Component. 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. Flag, whether the component can be multiply instantiated. which 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 generated the signatures of calls for an atomic SWC type in order to communicate over a port (for calls into a runable as well as for calls from a runnable to the port). 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 generated the signatures of calls for an atomic SWC type in order to communicate over a port (for calls into a runable as well as for calls from a runnable to the port). This means that the runnable can enter/leave the referenced exclusive area through explicit API calls. This means that the runnable can enter/leave the referenced exclusive area through explicit API calls. The runnable entity runs inside the referenced exclusive area The runnable entity runs inside the referenced exclusive area Prevent runnables from being preempted by other runnables. Specifies all mappings concerning a single NVRAM block owned by an SWC instance. Note that the mapping is the same for all instances of an SWC type. For details see documentation of the associations. Specifies all mappings concerning a single NVRAM block owned by an SWC instance. Note that the mapping is the same for all instances of an SWC type. For details see documentation of the associations. 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 operation invoked by the client. The OperationINvokedEvent references the operation 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 mode switch point specifies that a runnable explicitly received a certain mode. A mode switch point specifies that a runnable explicitly received a certain mode. 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 data receive point allows a runnable to explicitly query for received information, thereby blocking write access to the same information only for a very brief period. A data receive point allows a runnable to explicitly query for received information, thereby blocking write access to the same information only for a very brief period. The presences of a DataReadAccess means that the runnable needs access to the DataElement in the rPort. The runnable will not modify the contents of the data but only read the information. The runnable expects that the contents of this data does NOT change during its entire execution. The presences of a DataReadAccess means that the runnable needs access to the DataElement in the rPort. The runnable will not modify the contents of the data but only read the information. The runnable expects that the contents of this data does NOT change during its entire execution. The presences of a DataWriteAccess means that the runnable will potentially modify the dataElement in the pPort. The runnable has free access to the data-element while it is running. The runnable has the responsibility to make sure that the data-element is in a consistent state when it returns. When using DataWriteAccess the new values of the data-element is not made available via the communication infrastrucure before the runnable returns (exits the "Running" state). The presences of a DataWriteAccess means that the runnable will potentially modify the dataElement in the pPort. The runnable has free access to the data-element while it is running. The runnable has the responsibility to make sure that the data-element is in a consistent state when it returns. When using DataWriteAccess the new values of the data-element is not made available via the communication infrastrucure before the runnable returns (exits the "Running" state). A data send point specifies that a runnable explicitly sends a certain data element. A data send point specifies that a runnable explicitly sends a certain data element. 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. Defines a memory-block that needs to be available for each instance of the SW-component. This is typically only useful when supportsMultipleInstantiation is TRUE. 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 when supportsMultipleInstantiation is TRUE. A generic code descriptor. The type of described code. A generic code descriptor. Compiler name (like gcc). Vendor of compiler. Exact version of compiler executable. 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. Description of an implementation for a single atomic software component. Optional: code generator used. Programming language the implementation was created in. 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. Description of an implementation for a single atomic software component. 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, ...). 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. 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. 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. An atomic software component is atomic in the sense that it cannot be further decomposed and distributed across multiple ECUs. An atomic software component is atomic in the sense that it cannot be further decomposed and distributed across multiple ECUs. 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 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 topology of the system. Since several systems may share the same topology, a reference to a system topology type is used to define which topology is used in the system. The topology of the system. Since several systems may share the same topology, a reference to a system topology type is used to define which topology is used in the system. A communication matrix defines frames that are transported on a specific communication system, with timing etc. The CommunicationMatrixInstance references to the communicationMatrixType that shall be used in the system. A communication matrix defines frames that are transported on a specific communication system, with timing etc. The CommunicationMatrixInstance references to the communicationMatrixType that shall be used in the system. A gateway is a functionality within an ECU that performs a frame or signal mapping function between two or more communication clusters. The GatewayInstance references to the GatewayType used in the system. A gateway is a functionality within an ECU that performs a frame or signal mapping function between two or more communication clusters. The GatewayInstance references to the GatewayType used in the system. System aggregates all elements that define a system constraint description or system configuration description. System is a PropertyContainer since we want to model variants as properties. For each dimension of variability, one property is added. System aggregates all elements that define a system constraint description or system configuration description. System is a PropertyContainer since we want to model variants as properties. For each dimension of variability, one property is added. 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 system communication defines all frames exchanged on any communication cluster, and their relation among each other. The system communication defines all frames exchanged on any communication cluster, and their relation among each other. A communication matrix defines frames that are transported on a specific communication system, with timing etc. The communication matrix is separated from the topology, since the same topology may be used with different communication matrices. The same communication matrix type may be reused in different systems. Reuse is however only possible if the systems reuse the same topology (i.e. system topology type) as well. A communication matrix defines frames that are transported on a specific communication system, with timing etc. The communication matrix is separated from the topology, since the same topology may be used with different communication matrices. The same communication matrix type may be reused in different systems. Reuse is however only possible if the systems reuse the same topology (i.e. system topology type) as well. 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. 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. Relative delay of the frame in seconds to its successor in the schedule table. Data frame which is sent over a communication medium. Each Frame can be identified per channel by an Identifier (ID). The Identifier (ID) of the data frame on the channel. In FlexRay each frame is identified by its slot id and communication cycle (attributes of AbsoluetlyScheduledTiming). The frameLength specifies the length of the payload section in bytes. A minimum delay time between transmissions in seconds. If a transmission is requested before the minimumDelayTime expires, the next transmission is postponed until the delay time expires. The minimum delay time for the next transmission starts the moment the previous transmission is confirmed. (OSEK COM) Data frame which is sent over a communication medium. Each Frame can be identified per channel by an Identifier (ID). A timing defines time behavior (e.g. Cyclic, Event Triggered) of a frame, PDU or a Signal. A timing defines time behavior (e.g. Cyclic, Event Triggered) of a frame, PDU or a Signal. A Condition can be formulated as a free text. If a FreeTextCondition is aggregated in a Timing, then the timing is only valid if the condition holds. Condition formulated as a free text. A Condition can be formulated as a free text. If a FreeTextCondition is aggregated in a Timing, then the timing is only valid if the condition holds. The PDU (Protocol Data Unit) is a collection of signals for transfer between nodes in a network. The PDU is sent within a frame over a communication medium. A PDU can contain multiplexed data. This parameter is necessary to describe the position of a PDU within a frame. Indication to the receivers that the corresponding PDU was updated by the sender. The AUTOSAR FlexRay Interface explicitly defines a location for the update bit in the Frame that aggregates this PDUPrototype. The PDU (Protocol Data Unit) is a collection of signals for transfer between nodes in a network. The PDU is sent within a frame over a communication medium. A PDU can contain multiplexed data. 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. The first communication cycle where the frame is sent The number of communication cycles (after the first cycle) whenever the frame is sent again. The FlexRay communication controller allows only determined values. 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. 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. Precondition that must be fulfilled by the system. If this precondition is not fulfilled the timing that aggregates this ActiveCondition is not active. If a timing is not active, the frame is either not sent at all (if no other active timing exists), or the frame is sent since another timing is active and all conditions are met in that timing. Precondition that must be fulfilled by the system. If this precondition is not fulfilled the timing that aggregates this ActiveCondition is not active. If a timing is not active, the frame is either not sent at all (if no other active timing exists), or the frame is sent since another timing is active and all conditions are met in that timing. System state that must rule that the referring timing is activated. This attribute describes the system state. Examples for values are: CLAMP_15, CLAMP_30, CLAMP_87, CLAMP_RADIO, CHANNEL_ACTIVE. (These values are only examples, they are not standardized by AUTOSAR) System state that must rule that the referring timing is activated. The frame description for the CAN Bus. Specification of a cyclic sending behavior, e.g. used on CAN buses. Specification of the repeating cycle in seconds whenever the frame described by this timing is sent. Specification of the time in seconds that is needed before the frame can be sent the first time. This starting time is relative to the StartCondition. Specification of a cyclic sending behavior, e.g. used on CAN buses. Condition that must be fulfilled by the system or some signals that the cycle is started. Condition that must be fulfilled by the system or some signals that the cycle is started. The Signal Trigger describes the signal state that must rule that the referring timing is executed. The attribute dataEventCondition defines the primary condition when the condition is fulfilled. It is a Boolean Condition. If this Condition is TRUE, then the referring timing can be executed. Specifies what operation on the data mapped to this signal will trigger the sending of a frame. onChange: send frame if data written changed compared to last value written onUpdate: send frame whenever data is written onNotDefault: send frame whenever value is different from default value The Signal Trigger describes the signal state that must rule that the referring timing is executed. The attribute dataEventCondition defines the primary condition when the condition is fulfilled. It is a Boolean Condition. If this Condition is TRUE, then the referring timing can be executed. Condition that must be fulfilled by the system or some signals that the cycle is stopped. Condition that must be fulfilled by the system or some signals that the cycle is stopped. Specification of a event driven sending behavior, e.g. used on CAN buses. The Frame is sent "numberOfRepeats" times separated by the repeatCycleTime. If numberOfRepeats = 1, then the frame is sent just once. The debounce Time must elapses before the frame can be sent the next time. Specification of the time in seconds that elapses before the frame can be sent the next time (Minimum repeat gap between two frames). This time is different to the minimumDelayTime, defined on the Frame Level. If a transmission is requested before the debounceTime expires, this request will be ignored. The next transmission will not be postponed. Number of times the frame is sent if the condition is met Specification of the repeating cycle in seconds that is used to repeat the frame. Specification of a event driven sending behavior, e.g. used on CAN buses. The Frame is sent "numberOfRepeats" times separated by the repeatCycleTime. If numberOfRepeats = 1, then the frame is sent just once. The debounce Time must elapses before the frame can be sent the next time. Condition (Event) that must be fulfilled to cause the frame to be sent. Condition (Event) that must be fulfilled to cause the frame to be sent. Frame slot for an event triggered frame. LIN Spec 2.0 defines: "An event triggered frame is used as a placeholder to allow multiple slave nodes to provide its response. This is useful when the signals involved are changed infrequently." The event triggered frame has an own frame id that is sent by the LIN master. The slaves may answer with one of the unconditional frames referenced. LIN Spec 2.0 defines: "If more than one unconditional frame is associated with one event triggered frame (which is the normal case) they shall all be of equal length, use the same checksum model (i.e. mixing LIN 1.3 and LIN 2.0 frames is incorrect) and, furthermore, they shall all be published by different slave tasks." Frame slot for an event triggered frame. LIN Spec 2.0 defines: "An event triggered frame is used as a placeholder to allow multiple slave nodes to provide its response. This is useful when the signals involved are changed infrequently." The event triggered frame has an own frame id that is sent by the LIN master. The slaves may answer with one of the unconditional frames referenced. LIN Spec 2.0 defines: "If more than one unconditional frame is associated with one event triggered frame (which is the normal case) they shall all be of equal length, use the same checksum model (i.e. mixing LIN 1.3 and LIN 2.0 frames is incorrect) and, furthermore, they shall all be published by different slave tasks." The frame description for the LIN Bus. The frame description for the LIN Bus. Unlike with other communication systems - as for example CAN - the Frame ID is not sufficient for the identification. On FlexRay the communication cycle is used with SlotID for frame identification. These attributes are described by the AbsolutelyScheduledTiming class. A GatewayEntry describes the information routing by references to the source and the destination PDUPrototype or ClusterSignal. There are two possible methods to route the data from one channel to another: SignalCopy and PDUCopy. xml.namePlural="GATEWAY-ENTRIES" Identify the gateway entry in the gateway table. May be used to define the ordering of the entries. A gateway is a functionality within an ECU that performs as a PDU or signal mapping function between two or more communication clusters. The same GatewayType may be reused in different systems. This is however only possible if the system topology and communication matrices that are referenced from the gateway are reused as well. A gateway is a functionality within an ECU that performs as a PDU or signal mapping function between two or more communication clusters. The same GatewayType may be reused in different systems. This is however only possible if the system topology and communication matrices that are referenced from the gateway are reused as well. PDUGatewayEntry describes the PDUCopy Method. In this case the PDU will be copied, i.e. the destination PDU will have the same content (signals) and structure (position and length of signals) as the PDU on the source channel. xml.namePlural="PDU-GATEWAY-ENTRIES" What to do if a timeout occurred: - useDefaultValue: The default value of the signal will be transmitted. The default Value is the value that is sent in the PDU when no actual or no valid value is available for the COM-Layer that could be sent. This/These values are defined in the SWC-T: InvalidValue, InitValue - useLastValue: The last sent value will be transmitted again. - dontSend: nothing will be transmitted Time in seconds. Is this value exceeded without that a value of the source is received, the action defined in actionOnTimeout is performed. PDUGatewayEntry describes the PDUCopy Method. In this case the PDU will be copied, i.e. the destination PDU will have the same content (signals) and structure (position and length of signals) as the PDU on the source channel. xml.namePlural="PDU-GATEWAY-ENTRIES" Specification of a sending behavior where the transmission order is predefined, e.g. used on LIN buses Relative delay of the frame in ms described by this timing to its predecessor in the schedule table. Relative position of the frame described by this timing in the schedule table Identifier of the schedule table containing the frame described by the referring timing on the triggering channel. Specification of a sending behavior where the transmission order is predefined, e.g. used on LIN buses Specification of a request driven sending behavior, e.g. used on CAN buses. 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. Specification of the time in seconds that is needed before the frame can be sent after the requests arrival. Specification of a request driven sending behavior, e.g. used on CAN buses. 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. SignalGatewayEntry describes the SignalCopy Method. In this case only one signal of the PDU will be copied to another PDU on the destination channel. The parameters on the destination channel like signal position will be defined through the PDU description of the destination PDU. I.e. the signal must be described in the source and the destination PDU. For each signal which should be copied, one entry in this table has to be created. If you want e.g. to create one PDU on the destination channel from two Signals of the source channel, you have to make two entries in the table. The Signal Gateway Trigger Condition is described by the usage of the SendCondition on an EventControlledFrame and the referring signal state. xml.namePlural="SIGNAL-GATEWAY-ENTRIES" What to do if a timeout occurred: - useDefaultValue: The default value of the signal will be transmitted. The default Value is the value that is sent in the frame when no actual or no valid value is available for the COM-Layer that could be sent. This/These values are defined in the SWC-T: InvalidValue; InitValue - useLastValue: The last sent value will be transmitted again. Time in seconds. Is this value exceeded without that a value of the source is received, the action defined in actionOnTimeout is performed. SignalGatewayEntry describes the SignalCopy Method. In this case only one signal of the PDU will be copied to another PDU on the destination channel. The parameters on the destination channel like signal position will be defined through the PDU description of the destination PDU. I.e. the signal must be described in the source and the destination PDU. For each signal which should be copied, one entry in this table has to be created. If you want e.g. to create one PDU on the destination channel from two Signals of the source channel, you have to make two entries in the table. The Signal Gateway Trigger Condition is described by the usage of the SendCondition on an EventControlledFrame and the referring signal state. xml.namePlural="SIGNAL-GATEWAY-ENTRIES" By use of sporadic frames, the LIN master may send different unconditional frames in a specific scheduling table position, depending on events that occurred. From LIN 2.0 specification: "If multiple sporadic frames are associated with the same frame slot (the normal case), the most prioritized of the sporadic frames (which has an updated signal) shall be transferred in the frame slot. If none of the sporadic frames associated with a frame slot has an updated signal the frame slot shall be silent." By use of sporadic frames, the LIN master may send different unconditional frames in a specific scheduling table position, depending on events that occurred. From LIN 2.0 specification: "If multiple sporadic frames are associated with the same frame slot (the normal case), the most prioritized of the sporadic frames (which has an updated signal) shall be transferred in the frame slot. If none of the sporadic frames associated with a frame slot has an updated signal the frame slot shall be silent." Frame slot for an unconditional frame. An unconditional frame is a signal-carrying frame that is always sent in its allocated frame slot. Frame slot for an unconditional frame. An unconditional frame is a signal-carrying frame that is always sent in its allocated frame slot. instanceRef.context="systemTopologyinstance" instanceRef.context="systemTopologyinstance" CAN specific attributes xml.namePlural="CAN-BUSES" The CAN bus supports 11-Bit ("Standard") and 29-Bit ("Extended") identifiers. This attributes constrains a CAN bus to the selected formats. On Extended- Addressing it is also possible to have 11-Bit and 29-Bit CAN-identifiers. Predefined values are "Standard" and "Extended". CAN specific attributes xml.namePlural="CAN-BUSES" CAN bus specific communication port attributes. A clock prescaler value Specifies the maximum acceptable variance (normally delay) in seconds from the nominal Processing Period of the call to execute the Bus Communication SW. The cause of the jitter may be interrupts from tasks in the CPU with higher priority. This requirement must be taken into account when scheduling the software in the CPU. Describes whether the transceiver communication port termination is on or off. TRUE: communication port is terminated FALSE: communication port is not terminated Describes whether the CAN communication port is CAN "2.0a" or "2.0b" compliant. Specifies the nominal time interval between two consecutive calls to execute the Bus Communication SW (the COM layer) for receiving. Unit: seconds. At the execution of the Bus Communication SW received frames are moved from receive buffers and their signal content made available to the application. 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 Specifies the nominal time interval between two consecutive calls to execute the Bus Communication SW (the COM layer) for sending. Unit: seconds. At the execution of the Bus Communication SW frames due for transmission are moved to the transmit buffers, and made available for arbitration on the bus (in the case of CAN). CAN bus specific communication port attributes. The ECU resource description describes the hardware properties of each ECU communication port. Some of these properties may be further restricted by more software related constraints. Therefore the communication port instance describes on one hand the real settings to that hardware and on the other hand some properties which are set by software only. The identifier for this communication port on the bus, which can be used as e.g. network management address. There must not be two identical communication port identifiers on the same communication cluster. Bus speed of this port in bits per second May the ECU be woken up on this communication port? TRUE: wake up is possible FALSE: wake up on bus is not supported Note: This flag may only be set to TRUE if the feature is supported by both hardware and basic software. The ECU resource description describes the hardware properties of each ECU communication port. Some of these properties may be further restricted by more software related constraints. Therefore the communication port instance describes on one hand the real settings to that hardware and on the other hand some properties which are set by software only. The connector is used to describe the bus interfaces of the ECU. Each connector has a reference to exactly one communication port. The communication port can be referenced by several connector 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 communication port. The connector is used to describe the bus interfaces of the ECU. Each connector has a reference to exactly one communication port. The communication port can be referenced by several connector 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 communication port. 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. 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. The unique address of the ECU within the car. Used e.g. for Onboard Diagnostic (OBD) addressing, general diagnostics, Network Management. Defines how the ECU is connected to power feed. Predefined values are Battery: the ECU is always connected to power Ignition: the ECU has power feed if ignition is on Accessory: the ECU has power feed if accessory is switched on. Other: other power feed mode, such as selective power feed, e.g. under control of another ECU, etc. The Processing Unit endianness is the byte order in which the CPU interprets multi-byte integers from memory. The byte ordering "Little Endian" (MostSignificantByteLast) and "Big Endian" (MostSignificantByteFirst) can be selected. 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. Specifies whether the ECU may be woken from sleep mode on internal events, e.g. by timer or similar device built into the ECU. TRUE: ECU may wake up on ECU internal event FALSE: ECU does not support this feature Note: This flag may only be set to TRUE if the feature is supported by both hardware and basic software. Specifies whether the ECU may be woken up on IO ports (other than communication ports - those are specified separately). TRUE: ECU may be woken up on IO ports (see ECU resource descriptions for details) FALSE: not supported Note: This flag may only be set to TRUE if the feature is supported by both hardware and basic software. 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. A Hub or an ECU. The optional parent-child references can be used for the description of tree topologies. Each element in the tree is appropriately indented to indicate its level in the hierarchy, and is connected to its parent and to the children. FlexRay specific attributes to the physical Medium The offset of the action point in networks 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 The duration of the cluster wide nominal macrotick. Unit: seconds The maximum error that a node may have after initialization. Unit: seconds Threshold concerning vClockCorrectionFailedCounter. Defines when the Communication Controller (CC) shall change from normal or passive state to hold state. Threshold concerning vClockCorrectionFailedCounter. Defines when the Communication Controller (CC) shall change from normal or passive state to hold state. 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 number of Minislots in the dynamic segment. The number of static slots in the static segment. 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 Duration of the Transmission Start Sequence. Unit: bit 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 physical Medium 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 to compensate for reception delays on channel A Value used to compensate for reception delays on channel B 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. 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 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. A hub connects several PhysicalMediumSegments together. Hubs are only used to describe the detailed bus topology of star and more complex topologies. They are not used on basic bus topologies. The type of hub. Predefined values are "ActiveHub", "PassiveHub" A hub connects several PhysicalMediumSegments together. Hubs are only used to describe the detailed bus topology of star and more complex topologies. They are not used on basic bus topologies. LIN bus specific communication port instance attributes. Diagnostic address of the LIN node. This attribute is only use for LIN 1.2 and LIN 1.3 slaves. function_id is a 16 bit number assigned to the product by the supplier to make it unique. Unique ID used e.g. for automatic configuration of LIN networks. The Node Address for Diagnostic (NAD) is not part of the LIN 1.2 and 1.3 specification. The NAD is only assigned to LIN slaves. The max_message_length property applies to the diagnostic transport layer only; it defines the maximum length of a diagnostic message in bits. Maximum jitter time of responding frames, only needed for LIN slaves. Unit is seconds. Specifies whether the LIN node is master or slave on the bus it is connected to with this communication port P2_min specifies the minimum time in seconds between a master request frame and the following slave response frame for the node to be able to prepare the response. The version of the protocol used. Predefined values for LIN are "1.2", "1.3", "2.0". ST_min specifies the minimum time in seconds between two slave response frames in a multi-PDU response, i.e. it only applies to the diagnostic transport layer. Unique supplier ID of the LIN slave. A unique ID is assigned to every member of the LIN consortium. It may be used for the automatic configuration of LIN 2.0 slave nodes. Lists all Service Identifier (SID) values that are supported by the node. Example: {0xb0, 0xb1, 0xb2} 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. The Variant ID is used for the product identification and is an 8 bit value specifying the variant. The variant ID shall be changed whenever the product is changed but with unaltered function. LIN bus specific communication port instance attributes. LIN sub-bus definition Maximum jitter time of responding frames, only needed for LIN slaves. Unit is seconds. LIN sub-bus definition 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. 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. A PhysicalMediumSegment defines a set of communicating ECUs, which has the property of providing the identical physical data representation (e.g. electrical potential) to the all connected hardware (ECUs or Hubs). A PhysicalChannel may be implemented by several segments, which are then connected via (active or passive) Hubs. A PhysicalMediumSegment may connect individual ECUs together (for bus topologies), or connects hub and ECU(s) etc. Each PhysicalChannel consists of at least one segment; CAN and LIN have normally only a single segment, FlexRay can consist of more than one segments. These segments are then connected with each other via one or more Hubs. Describes the number of physical wires/media used for data transmission. (E.g. single wire CAN has this value set to 1, LIN also 1) Type of the physical medium on this segment. A PhysicalMediumSegment defines a set of communicating ECUs, which has the property of providing the identical physical data representation (e.g. electrical potential) to the all connected hardware (ECUs or Hubs). A PhysicalChannel may be implemented by several segments, which are then connected via (active or passive) Hubs. A PhysicalMediumSegment may connect individual ECUs together (for bus topologies), or connects hub and ECU(s) etc. Each PhysicalChannel consists of at least one segment; CAN and LIN have normally only a single segment, FlexRay can consist of more than one segments. These segments are then connected with each other via one or more Hubs. The system topology, which may be reused in different systems. The system topology, which may be reused in different systems. UnspecifiedConnection may be used for proprietary bus systems, direct connections between I/O-ports of ECUs etc. The CommunicationCluster is the main element to describe the topological connection of communicating ECUs. All ECUs within a CommunicationCluster communicate within the same address range. A CommunicationCluster aggregates one or more physical channels. All physical channels that are aggregated by a communication cluster are synchronized with each other. Bus speed in bits per second The name of the protocol used. The version of the protocol used. A receiver of the cluster signal. Since different receivers can have different communication attribute values, a separate class is used per receiver. Timeout in seconds. If the timeout occurs without receiving the signal, the ECU shall take appropriate actions. A receiver of the cluster signal. Since different receivers can have different communication attribute values, a separate class is used per receiver. A transmitter of the cluster signal. Since different transmitters can have different communication attribute values, a separate class is used per transmitter. A transmitter of the cluster signal. Since different transmitters can have different communication attribute values, a separate class is used per transmitter. 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 (at least) one system signal defined for each data element sent or received by a SW component instance. If data has to be sent over gateways, there is still only one system signal representing this data. The representation of the data on the individual communication systems is done by the cluster signals. System signals can be defined independently of frames and PDUs. This allows a development methodology where the signals are defined first, and are assigned to frames in a later stage. 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. Boolean value that defines whether a UpdateIndicationBit has to be defined in the PDU that is associated with this SystemSignal. If this attribute is omitted, no UpdateIndication bit will be added to the PDU. The signalLength specifies the 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 (at least) one system signal defined for each data element sent or received by a SW component instance. If data has to be sent over gateways, there is still only one system signal representing this data. The representation of the data on the individual communication systems is done by the cluster signals. System signals can be defined independently of frames and PDUs. This allows a development methodology where the signals are defined first, and are assigned to frames in a later stage. 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. 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. A cluster signal represents the system signal on one specific communication cluster. The UpdateIndicationBit indicates to the receivers that the clusterSignal was updated by the sender. Length is always one bit. The UpdateIndicationBitPosition attribute describes the position of the update bit within the PDU. A cluster signal represents the system signal on one specific communication cluster. A multiplexer is used to define variable parts within a PDU that may carry different signals. The receivers of such a PDU can determine which signals 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 PDU. 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 PDU. It denotes the least significant bit for "Little Endian" and the most significant bit for "Big Endian" (see the description of the selectorFieldByteOrder attribute). A multiplexer is used to define variable parts within a PDU that may carry different signals. The receivers of such a PDU can determine which signals are transmitted by evaluating the selector field, which carries a unique selector code for each sub-part. A multiplexed PDU consists of a static part and a dynamic part, where the static part consists of zero or more signals and the dynamic part consists of the selector field and one or more signals. Each part of a multiplexed PDU, the static part and the different dynamic parts, are described as a SubPDU. The selector field is part of a multiplexed PDU. It consists of contiguous bits. The value of the selector field selects the layout of the multiplexed part of the PDU. This attribute is only valid for the dynamic part of the PDU. The position of the static and the dynamic part of the multiplexer in the PDU. The size of the SubPDU in bits. The size is limited by the PDUSize. A multiplexed PDU consists of a static part and a dynamic part, where the static part consists of zero or more signals and the dynamic part consists of the selector field and one or more signals. Each part of a multiplexed PDU, the static part and the different dynamic parts, are described as a SubPDU. PDUType defines the structure of a PDU. Boolean value that defines whether a UpdateIndicationBit has to be defined in the Frame that is associated with this PDUType. If this attribute is omitted, no UpdateIndication bit will be added to the Frame. The AUTOSAR FlexRay Interface explicitly defines a location for the update bit that relates to a PDU. The size of the PDU in bits. The size is limited by the frameLength. PDUType defines the structure of a PDU. The signal position defines which system signal is transmitted at which position within the aggregating PDU. The SignalPosition must be defined within a PDU or a SubPDU. This parameter defines the order of the bytes of the signal are packed into the PDU. 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 PDU (see the startPosition attribute description). This parameter is necessary to describe the position of a signal within a PDU or SubPDU. It denotes the least significant bit for "Little Endian" and the most significant bit for "Big Endian" packed signals within the PDU (see the description of the packingByteOrder attribute). Bits within the PDU 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 PDU is then determined by the definition of the packingByteOrder attribute of the signal. The signal position defines which system signal is transmitted at which position within the aggregating PDU. The SignalPosition must be defined within a PDU or a SubPDU. Estimations for the resource consumption for the basic software. Abstract class that generalizes BSWResourceEstimatin and RTEResourceEstimation. Used to define common aggregated elements. 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 Map software components to a specific ECU Estimations for the resource consumption for the AUTOSAR run time environment. Constraints in natural language that cannot be expressed with the other constraints. Constraints in natural language that cannot be expressed with the other constraints. 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. Possible option are IN (all IN and INOUT arguments) and OUT (all OUT and INOUT arguments) . 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 way (Signal Path) 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 way (Signal Path) 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 (Signal Path) a data element can take in the topology. 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 and not path B. This has an effect on the frame generation and the frame path. The PermissibleSignalPath describes the way (Signal Path) a data element can take in the topology. 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 and not path B. 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). Additional guidelines for the System Generator, which specific way a signal between two Software Components should take in the network without defining in which frame and with which timing it is transmitted. 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. 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. 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. 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. 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. 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. 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 in several signals (e.g. if the data is sent out to different receivers in different signals), one have to define several mappings. Mapping of a sender receiver communication data element with a primitive datatype to a signal. If the data element has to be transmitted in several signals (e.g. if the data is sent out to different receivers in different signals), one have to define several mappings. 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. 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. If the compositeType is a Record, the "RecordTypeMapping" will be used. If the compositeType is a Record, the "RecordTypeMapping" will be used. Description of the protocol elements. These may be frames, signals (which are in turn part of a frame) or signal groups. The direction in which the element is sent- s2r : Sender To Receiver (For Sender-Receiver Communication, e.g. data elements) r2s: Receiver To Sender (For Sender-Receiver Communication, e.g. Acknowledgements) c2s: Client to Server (For Client-Server Communication, "in" parameters) s2c Server to Client (For Client-Server Communication, "out" parameters) Description of the protocol elements. These may be frames, signals (which are in turn part of a frame) or signal groups. If the protocol instance uses frame instances as protocol elements, they are specified with this element. This is e.g. the case in protocol ISO 15765-2, where complete frames are used to exchange information between the communication partners. If the protocol instance uses frame instances as protocol elements, they are specified with this element. This is e.g. the case in protocol ISO 15765-2, where complete frames are used to exchange information between the communication partners. If the protocol instance uses signal groups as protocol elements, they are specified with this element. If the protocol instance uses signal groups as protocol elements, they are specified with this element. If the protocol instance uses signal instances (in a specific frame instance) as protocol elements, they are specified with this element. If the protocol instance uses signal instances (in a specific frame instance) as protocol elements, they are specified with this element. The protocol type description describes all necessary protocol parameters that are the same for all instances of the protocol and that are necessary to configure the protocol., This is e.g.. a generic definition of ISO 15765-2. The protocol type description describes all necessary protocol parameters that are the same for all instances of the protocol and that are necessary to configure the protocol., This is e.g.. a generic definition of ISO 15765-2. An instance of a communication protocol, used for exchanging information between specific communication partners. This might e.g. be an instance of ISO 15765-2 running between ECU A and ECU B. An instance of a communication protocol, used for exchanging information between specific communication partners. This might e.g. be an instance of ISO 15765-2 running between ECU A and ECU B. 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" 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". Attributes used by Configuration Parameters as well as References. Specifying the actual configuration class of a configuration parameter in the "vendor specific module definition" in which it is mandatory. String specifying if this configuration parameter is an AUTOSAR standardized configuration parameter or if the parameter is hardware- or vendor-specific. Common class used to express multiplicities in the definition of configuration parameters 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 Specifies in the "VendorSpecificModuleDefinition" whether changes on this parameter do affect other parameters in a later configuration step. Specifies in the "VendorSpecificModuleDefinition" whether changes on this parameter do affect other parameters in a later configuration step. 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. 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. 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. For these definitions there is no corresponding entry in the ECUC description. Instead, a calculation definition is given that defines how Configuration Editors and Generators can calculate the value from other values when needed to display/use the configuration item 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. Used to define the actual implemented configuration variant in a specific "vendor specific module definition", where it is mandatory. 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 ReferenceDef specifies that the implementation of the reference is done using a symbolic name defined by the referenced Container's shortName. 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. 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. 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. 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 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 InstanceReferenceDef). Used to represent a configuration value that has a parameter definition of type ConfigReference (used for all of its specializations excluding InstanceReferenceDef). Root element for the description of a single BSW module or a module cluster. Refers to the BSW Module Identifier defined by the AUTOSAR standard. Root element for the description of a single BSW module or a module cluster.