Actor represents a type of role played by an entity that interacts with the UseCase, e.g. by exchanging signals and data, but which is external to the subject, i.e., in the sense that an instance of an Actor is not a part of the instance of its corresponding subject. Actors may represent roles played by human users, external hardware, or other subjects. Note that an Actor does not necessarily represent a specific physical entity but merely a particular facet (i.e., "role") of some entity that is relevant to the specification of its associated UseCases. Thus, a single physical instance may play the role of several different Actors and, conversely, a given Actor may be played by multiple different instances. Since an Actor is external to the subject, it is typically defined in the same classifier or package that incorporates the subject classifier. Semantics: The Actor element represents entities that interacts with a UseCase. The Actuator is the element that represents electrical actuators, such as valves, motors, lamps, brake units, etc. Non-electrical actuators such as the engine, hydraulics, etc. are considered part of the plant model (environment). Plant models are not part of the Hardware Design Architecture. Semantics: The Actuator metaclass represents the physical and electrical aspects of actuator hardware. The logical aspect is represented by a HardwareFunctionType associated with the Actuator. Notation: Actuator is shown as a solid-outline rectangle with double vertical borders. The rectangle contains the name, and its ports or port groups on the perimeter. Different tolerances on over-/undersampling can be identified when the solution has been modeled. An age constraint is of interest in control engineering when looking back through the system. In case of over- or undersampling, a one-to-one relation is not possible between the occurrences of stimuli and responses of the associated event chain. Thus, the age constraint defines the semantic of which delay must be constrained. The attribute upper is applicable in worst-case analysis. The attribute lower is applicable in best-case analysis. Semantics: AgeTimingConstraint characterizes the age of the stimulus event compared to the response event. The Allocation element contains function allocations. It can bundle function allocations that belong together, e.g., all function allocations for a simulation. Semantics: The Allocation element contains function allocations, i.e., it can bundle function allocations that belong together. Extension: Class The Allocation element contains function allocations. It can bundle function allocations that belong together, e.g., all function allocations for a simulation. Semantics: The Allocation element contains function allocations, i.e., it can bundle function allocations that belong together. Extension: Class The AnalysisFunctionPrototype represents references to the occurrence of the AnalysisFunctionType that types it when it acts as a part. The AnalysisFunctionPrototype is typed by an AnalysisFunctionType. Semantics: The AnalysisFunctionPrototype represents an occurrence of the AnalysisFunctionType that types it. Extension: UML Property, specialization of SysML::BlockProperty The AnalysisFunctionPrototype represents references to the occurrence of the AnalysisFunctionType that types it when it acts as a part. The AnalysisFunctionPrototype is typed by an AnalysisFunctionType. Semantics: The AnalysisFunctionPrototype represents an occurrence of the AnalysisFunctionType that types it. Extension: UML Property, specialization of SysML::BlockProperty The AnalysisFunctionType is a concrete FunctionType and therefore inherits the elementary function properties from the abstract metaclass FunctionType. The AnalysisFunctionType is used to model the functional structure on AnalysisLevel. The syntax of AnalysisFunctionTypes is inspired from the type-prototype pattern used by AUTOSAR. The AnalysisFunctions may interact with other AnalysisFunctions (i.e., also FunctionalDevices) through their FunctionPorts. Furthermore, an AnalysisFunction may be decomposed into AnalysisFunctions the contained parts that are AnalysisFunctionPrototypes. This allows the functionalities provided by the parent AnalysisFunction to be broken up hierarchically into subfunctionalities. A FunctionBehavior may be associated with each AnalysisFunction. In the case where the AnalysisFunction is decomposed, the behavior is a specification for the composed behavior of the parts. Semantics: The AnalysisFunctionType represents a node in a tree structure corresponding to the functional decomposition of a top level AnalysisFunction. The AnalysisFunction represents the analysis function used to describe the functionalities provided by a vehicle on the AnalysisLevel. At the AnalysisLevel, AnalysisFunctions are defined and structured according to the functional requirements, i.e., the functionalities provided to the user. Constraints: [1] AnalysisFunctionTypes may only be used on AnalysisLevel. Extension: UML Class, specialization of SysML::Block The AnalysisFunctionType is a concrete FunctionType and therefore inherits the elementary function properties from the abstract metaclass FunctionType. The AnalysisFunctionType is used to model the functional structure on AnalysisLevel. The syntax of AnalysisFunctionTypes is inspired from the type-prototype pattern used by AUTOSAR. The AnalysisFunctions may interact with other AnalysisFunctions (i.e., also FunctionalDevices) through their FunctionPorts. Furthermore, an AnalysisFunction may be decomposed into AnalysisFunctions the contained parts that are AnalysisFunctionPrototypes. This allows the functionalities provided by the parent AnalysisFunction to be broken up hierarchically into subfunctionalities. A FunctionBehavior may be associated with each AnalysisFunction. In the case where the AnalysisFunction is decomposed, the behavior is a specification for the composed behavior of the parts. Semantics: The AnalysisFunctionType represents a node in a tree structure corresponding to the functional decomposition of a top level AnalysisFunction. The AnalysisFunction represents the analysis function used to describe the functionalities provided by a vehicle on the AnalysisLevel. At the AnalysisLevel, AnalysisFunctions are defined and structured according to the functional requirements, i.e., the functionalities provided to the user. Constraints: [1] AnalysisFunctionTypes may only be used on AnalysisLevel. Extension: UML Class, specialization of SysML::Block The AnalysisLevel represents the vehicle electrical/electronic system in terms of its abstract functional definition. It includes the functional analysis architecture (FAA), which represents the functional structure. Semantics: AnalysisLevel represents the vehicle electrical/electronic system in terms of its abstract functional definition. It defines the logical functionality and a logical decomposition of functionality down to the appropriate granularity. Notation: The Analysis Architecture is shown as a solid-outline rectangle containing the name, with its ports or port groups on the perimeter. Contained entities may be shown with their connectors (White-box view). Extension: Class The AnalysisLevel represents the vehicle electrical/electronic system in terms of its abstract functional definition. It includes the functional analysis architecture (FAA), which represents the functional structure. Semantics: AnalysisLevel represents the vehicle electrical/electronic system in terms of its abstract functional definition. It defines the logical functionality and a logical decomposition of functionality down to the appropriate granularity. Notation: The Analysis Architecture is shown as a solid-outline rectangle containing the name, with its ports or port groups on the perimeter. Contained entities may be shown with their connectors (White-box view). Extension: Class The Anomaly metaclass represents a Fault that may occur internally in an ErrorModel or be propagated to it, or a Failure that is propagated out of an Error Model. The anomaly may represent different Faults or Failures depending on the range of its EADatatype. Typically, the EADatatype is an Enumeration, for example: BrakeAnomaly: - BrakePressureTooLow Semantics="brake pressure is below 20% of requested value" - Omission Semantics="brake pressure is below 10% of maximal brake pressure" - Comission Semantics="brake pressure exceeds requested value with more than 10% of maximal brake pressure" Semantics may also be a more formal expression defining in the type of the nominal datatype what value range is considered a fault. This depends on the user and tooling available. Semantics: An anomaly refers to a condition that deviates from expectations based on requirements specifications, design documents, user documents, standards, etc., or from someone's perceptions or experiences (ISO26262). The set of available faults or failures represented by the Anomaly is defined by its EADatatype, typically an enumeration type like {omission, commission}. It is an abstract class further specialized with metaclasses for different types of fault/failure. Extension: (UML::Part) A description of the Anomaly The Arbitrary Event Model describes whether an event occurs occasionally, singly, irregularly or randomly. The primary purpose of this event model is to abstract event occurrences captured by data acquisition tools (background debugger, trace analyzer, etc.) during the operation of a system. Constraints: [1] The number of elements in the sets minimum inter-arrival time and maximum inter-arrival time must be the same. Rationale: Consistent specification of arrival times. Semantics: ArbitraryEventConstraint characterizes the occurrence pattern of the associated Event. minimumInterArrivalTime and maximumInterArrivalTime defines the timing constraints for the pattern. The Arbitrary Event Model describes whether an event occurs occasionally, singly, irregularly or randomly. The primary purpose of this event model is to abstract event occurrences captured by data acquisition tools (background debugger, trace analyzer, etc.) during the operation of a system. Constraints: [1] The number of elements in the sets minimum inter-arrival time and maximum inter-arrival time must be the same. Rationale: Consistent specification of arrival times. Semantics: ArbitraryEventConstraint characterizes the occurrence pattern of the associated Event. minimumInterArrivalTime and maximumInterArrivalTime defines the timing constraints for the pattern. A collection of products to document an architecture. [IEEE 1471] A collection of products to document an architecture. [IEEE 1471] A view may consist of one or more architectural models. Each such architectural model is developed using the methods established by its associated architectural viewpoint. An architectural model may participate in more than one view. [IEEE 1471] A view may consist of one or more architectural models. Each such architectural model is developed using the methods established by its associated architectural viewpoint. An architectural model may participate in more than one view. [IEEE 1471] The fundamental organization of a system embodied by its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution. [IEEE 1471] The fundamental organization of a system embodied by its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution. [IEEE 1471] A classifier classifies M0 instances according to their features. Or: a classifier is something that has instances - an M1 classifier has M0 instances. An M0 instance of a classifier may be represented as a tree rooted at that instance, where under each node come the subrtees representing the instances which act as features under that node. An instance ref specifies a navigation path from any M0 tree-instance of the base (which is a classifier) to a leaf (which is an instance of the target). A prototype is a typed feature. A prorotype in a classifier indicates that instances of that classifier will have a feature, and the structure of that feature is given by the its type. An instance of that type will play the role indicated by the feature in the owning classifier. A feature is not an instance but an indication of an instance-to-be. The BasicSoftwareFunctionType allow for the representation of a layered architecture of functionality on the DesignLevel. A BasicSoftwareFunctionType then represents a function in the service layer. Semantics: The BasicSoftwareFunctionType is an abstraction of the middleware. Extension: UML Class, specialization of SysML::Block Behavior is a container of FunctionBehaviors. It enables grouping of the behaviors assigned to functions in a particular context on which TraceableSpecifications can be applied. This can take any appropriate form depending on the language implementation (for instance in a UML implementation it could be a Package). The collection of functional behaviors can be performed across the EAST-ADL abstraction levels. Semantics: This element has the same role and semantics as Context, but for behavioral aspects. Behavior is a container of FunctionBehaviors. It enables grouping of the behaviors assigned to functions in a particular context on which TraceableSpecifications can be applied. This can take any appropriate form depending on the language implementation (for instance in a UML implementation it could be a Package). The collection of functional behaviors can be performed across the EAST-ADL abstraction levels. Semantics: This element has the same role and semantics as Context, but for behavioral aspects. Behavior constraints specify the behaviors to be fulfilled by a vehicle feature, a system artifact, or an environment entity. In particular, for system artifacts and environment entities, the behaviors under constraint include their function behaviors and function triggers. For functional requirements and operation situations, the introduction of behavior constraints allows the related textual descriptions in the requirement model to be refined through the existing requirement refine relationship. The refinements in terms of behavior constraints provide declarations of behavior elements, including the expected parameters, states and transitions, of one or multiple functional requirements. This facilitates the analysis and validation of requirements in regards to the semantics and consistency of textual descriptions, and thereby the reuse and management of requirements and their implied behaviors. BehaviorConstraint is an EAElement. It is further specialized by ParameterConstraint, StateMachineConstraint, and ComputationConstraint. Constraints: A behavior constraint references at least one vehicle feature, mode, function behavior, function trigger, or error behavior definition. Semantics: Behavior constraints refine textual requirements and provide additional information for defining and managing behavior information in EAST-ADL and external models. The motivation for attributing features and variable elements with binding times is that binding times encapsulate important information about the variability under view. Variability that must be bound (determined, decided) very early in the system development may not be visible in one single feature model but only in comparison with different feature models in the context of multi-level feature trees; late bound variability is variability providing the driver with choices for current equipment configuration. Binding times are important because they describe if the variability must be decided during system development or if the variability is determined by a customer or if the variability itself is part of the product features that are sold to the customer. Possible binding times are: - SystemDesignTime - CodeGenerationTime - PreCompileTime - LinkTime - PostBuild - Runtime Note that a binding time is never a particular point in time such as April 2nd, 2011, but always a certain stage in the overall development, production and shipment process as represented by the above values. Each feature must have a binding time (association requiredBindingTime) and may have one further binding time (association actualBindingTime). The required binding time describes the binding time that the feature is intended to have. But due to technical conditions it may occur that the actually realized binding time of the feature differs from the originally intended binding time. In this case one has to provide information about the actual binding time. In the rationale it must be described by what the required binding time is motivated by and what the reasons are for a (different) actual binding time. Semantics: See description. Extension: Class. The kind of the binding time, see enumeration BindingTimeKind for specification of binding times. The motivation for attributing features and variable elements with binding times is that binding times encapsulate important information about the variability under view. Variability that must be bound (determined, decided) very early in the system development may not be visible in one single feature model but only in comparison with different feature models in the context of multi-level feature trees; late bound variability is variability providing the driver with choices for current equipment configuration. Binding times are important because they describe if the variability must be decided during system development or if the variability is determined by a customer or if the variability itself is part of the product features that are sold to the customer. Possible binding times are: - SystemDesignTime - CodeGenerationTime - PreCompileTime - LinkTime - PostBuild - Runtime Note that a binding time is never a particular point in time such as April 2nd, 2011, but always a certain stage in the overall development, production and shipment process as represented by the above values. Each feature must have a binding time (association requiredBindingTime) and may have one further binding time (association actualBindingTime). The required binding time describes the binding time that the feature is intended to have. But due to technical conditions it may occur that the actually realized binding time of the feature differs from the originally intended binding time. In this case one has to provide information about the actual binding time. In the rationale it must be described by what the required binding time is motivated by and what the reasons are for a (different) actual binding time. Semantics: See description. Extension: Class. The business opportunity represents a brief description of the business opportunity being met by developing the electrical/electronic system which establishes traceability from artifacts created later, for example to provide rationales to design decisions or trade-off analysis. This attribute holds a brief description of the business opportunity being met by developing the electrical/electronic system. This redefines the text attribute in TraceableSpecification. The business opportunity represents a brief description of the business opportunity being met by developing the electrical/electronic system which establishes traceability from artifacts created later, for example to provide rationales to design decisions or trade-off analysis. Claim represents a statement, the truth of which needs to be confirmed. Claim has associations to the strategy for goal decomposition and to supported arguments. It also holds associations to the evidences for the SafetyCase. Semantics: Goal-based development provides the claim what should be achieved. Goal is what the argument must show to be true. Claim represents a statement, the truth of which needs to be confirmed. Claim has associations to the strategy for goal decomposition and to supported arguments. It also holds associations to the evidences for the SafetyCase. Semantics: Goal-based development provides the claim what should be achieved. Goal is what the argument must show to be true. The clamp connector connects ports across function boundaries and containment hierarchies. It is used to connect from an EnvironmentModel to the FunctionalAnalysisArchitecture, the FunctionalDesignArchitecture, the autosarSystem or another EnvironmentModel. Typically, the EnvironmentModel contains physical ports, which restrict the valid ports in the FunctionalAnalysisArchitecture to those on FunctionalDevices and in the FunctionalDesignArchitecture to those on HardwareFunctions. In case the connection concerns logical interaction, this restriction does not apply. The ClampConnector is always an assembly connector, never a delegation connector. Semantics: ClampConnectors represents the interaction link between a functional model of the EE Architecture and the functional model of the plant. Constraints: [1] Can connect two FunctionFlowPorts of different direction. [2] Can connect two ClientServerPorts of different kind. [3] Can connect two FunctionFlowPorts with direction inout. [4] Cannot connect ports in the same SystemModel. The clamp connector connects ports across function boundaries and containment hierarchies. It is used to connect from an EnvironmentModel to the FunctionalAnalysisArchitecture, the FunctionalDesignArchitecture, the autosarSystem or another EnvironmentModel. Typically, the EnvironmentModel contains physical ports, which restrict the valid ports in the FunctionalAnalysisArchitecture to those on FunctionalDevices and in the FunctionalDesignArchitecture to those on HardwareFunctions. In case the connection concerns logical interaction, this restriction does not apply. The ClampConnector is always an assembly connector, never a delegation connector. Semantics: ClampConnectors represents the interaction link between a functional model of the EE Architecture and the functional model of the plant. Constraints: [1] Can connect two FunctionFlowPorts of different direction. [2] Can connect two ClientServerPorts of different kind. [3] Can connect two FunctionFlowPorts with direction inout. [4] Cannot connect ports in the same SystemModel. Comment represents a textual annotation. Semantics: Comment represents a textual annotation that applies to the containing or associated element. Extension: Comment Specifies a string that is the comment. Comment represents a textual annotation. Semantics: Comment represents a textual annotation that applies to the containing or associated element. Extension: Comment CommunicationHardwarePin represents an electrical connection point that can be used to define how the wire harness is logically defined. Semantics: The CommunicationHardwarePin represents the hardware connection point of a communication bus. Depending on modeling style, one or two pins may be defined for a dual-wire bus. Notation: CommunicationHardwarePin is shown as a solid square with a C inside. Its name may appear outside the square. A CompositeDatatype represents a non-scalar datatype. Take as an example a CompositeDatatype "MyCountries" that can refer, e.g., to an Enumeration "CountryEnumeration" {USA, Canada, Japan, EU} via two EADatatypePrototypes (record variables): FirstCountry and SecondCountry. Then an attribute typed by this CompositeDatatype "MyCountries" may have a value like: (EU (identified as FirstCountry), Japan (identified as SecondCountry)). Semantics: A CompositeDatatype represents a non-scalar datatype. The contained datatypePrototypes act as record variables to identify the ordered datatype instances of the tuple (the CompositeDatatype). Notation: The datatype CompositeDatatype is denoted using the rectangle symbol with keyword «Datatype CompositeDatatype». Extension: UML Datatype A CompositeDatatype represents a non-scalar datatype. Take as an example a CompositeDatatype "MyCountries" that can refer, e.g., to an Enumeration "CountryEnumeration" {USA, Canada, Japan, EU} via two EADatatypePrototypes (record variables): FirstCountry and SecondCountry. Then an attribute typed by this CompositeDatatype "MyCountries" may have a value like: (EU (identified as FirstCountry), Japan (identified as SecondCountry)). Semantics: A CompositeDatatype represents a non-scalar datatype. The contained datatypePrototypes act as record variables to identify the ordered datatype instances of the tuple (the CompositeDatatype). Notation: The datatype CompositeDatatype is denoted using the rectangle symbol with keyword «Datatype CompositeDatatype». Extension: UML Datatype Computation constraints define required computation activities and the paths of quantities across such activities. Constraints: A computation constraint contains at least one transformation or one flow definition. Semantics: Computation constraints refine textual requirements and provide detailed specifications about the computations to be supported. Computation constraints define required computation activities and the paths of quantities across such activities. Constraints: A computation constraint contains at least one transformation or one flow definition. Semantics: Computation constraints refine textual requirements and provide detailed specifications about the computations to be supported. ConfigurableContainer is a marker class that marks an element identified by association configurableElement as a configurable container of some variable content, i.e. VariableElements and other, lower-level ConfigurableContainers. In order to describe the contained variability to the outside world and to allow configuration of it, the ConfigurableContainer can have a public feature model and an internal configuration decision model not visible from the outside, called "internal binding". In addition, the ConfigurableContainer can be used to extend the EAST-ADL variability approach to other languages and standards by pointing from the ConfigurableContainer to the respective (non EAST-ADL) element with association configurableElement. This provides the public feature model and the ConfigurationDecisionModel to that non EAST-ADL element. The variable content of a ConfigurableContainer is defined as all VariableElements and all other ConfigurableContainers that are directly or indirectly contained in the Identifiable denoted by association configurableElement. Instead of 'variable content' the term 'internal variability' may be used. Note that, according to this rule, the containment between a ConfigurableContainer and its variable content, i.e. its contained VariableElements and lower-level ConfigurableContainers, is not directly defined between these meta-classes. Instead, the containment is defined by the Identifiable pointed to by association configurableElement. For example, consider a FunctionType "WiperSystem" containing two FunctionPrototypes "front" and "rear" both typed by FunctionType "WiperMotor"; to make the wiper system configurable and the rear wiper motor optional, a ConfigurableContainer is created that points to FunctionType "WiperSystem" (with association configurableElement) and a VariableElement is created that points to FunctionPrototype "rear" (with association optionalElement); the containment between the ConfigurableContainer and the VariableElement is therefore not explicitly defined between these classes but instead only between FunctionType "WiperSystem" and "FunctionPrototype" rear. In addition, the variability-related visibility of "rear" can be changed with PrivateContent: by default the variability of "rear" will be public and visible for direct configuration from the outside of its containing ConfigurableContainer, i.e. "WiperSystem"; by defining a PrivateContent marker object pointing to the FunctionPrototype "rear", this can be changed to private and this variability will not be visible from the outside of "WiperSystem". Constraints: [1] Identifies one FunctionType or one HardwareComponentType. [2] The publicFeatureModel is only allowed to contain Features (no VehicleFeatures). Semantics: Marks the element identified by association configurableElement as a configurable container of variable content (i.e. it contains VariableElements and/or other, lower-level ConfigurableContainers) and optionally provides a public feature model and an internal configuration decision model for it, thus providing configurability support for them. Extension: Class ConfigurableContainer is a marker class that marks an element identified by association configurableElement as a configurable container of some variable content, i.e. VariableElements and other, lower-level ConfigurableContainers. In order to describe the contained variability to the outside world and to allow configuration of it, the ConfigurableContainer can have a public feature model and an internal configuration decision model not visible from the outside, called "internal binding". In addition, the ConfigurableContainer can be used to extend the EAST-ADL variability approach to other languages and standards by pointing from the ConfigurableContainer to the respective (non EAST-ADL) element with association configurableElement. This provides the public feature model and the ConfigurationDecisionModel to that non EAST-ADL element. The variable content of a ConfigurableContainer is defined as all VariableElements and all other ConfigurableContainers that are directly or indirectly contained in the Identifiable denoted by association configurableElement. Instead of 'variable content' the term 'internal variability' may be used. Note that, according to this rule, the containment between a ConfigurableContainer and its variable content, i.e. its contained VariableElements and lower-level ConfigurableContainers, is not directly defined between these meta-classes. Instead, the containment is defined by the Identifiable pointed to by association configurableElement. For example, consider a FunctionType "WiperSystem" containing two FunctionPrototypes "front" and "rear" both typed by FunctionType "WiperMotor"; to make the wiper system configurable and the rear wiper motor optional, a ConfigurableContainer is created that points to FunctionType "WiperSystem" (with association configurableElement) and a VariableElement is created that points to FunctionPrototype "rear" (with association optionalElement); the containment between the ConfigurableContainer and the VariableElement is therefore not explicitly defined between these classes but instead only between FunctionType "WiperSystem" and "FunctionPrototype" rear. In addition, the variability-related visibility of "rear" can be changed with PrivateContent: by default the variability of "rear" will be public and visible for direct configuration from the outside of its containing ConfigurableContainer, i.e. "WiperSystem"; by defining a PrivateContent marker object pointing to the FunctionPrototype "rear", this can be changed to private and this variability will not be visible from the outside of "WiperSystem". Constraints: [1] Identifies one FunctionType or one HardwareComponentType. [2] The publicFeatureModel is only allowed to contain Features (no VehicleFeatures). Semantics: Marks the element identified by association configurableElement as a configurable container of variable content (i.e. it contains VariableElements and/or other, lower-level ConfigurableContainers) and optionally provides a public feature model and an internal configuration decision model for it, thus providing configurability support for them. Extension: Class ConfigurationDecision represents a single, atomized rule on how to configure the target feature model(s) of the containing ConfigurationDecisionModel, depending on a given configuration of the source feature model(s). Two examples are: "all North American (USA+Canada) cars except A-Class have cruise control" (one ConfigurationDecision) or "all Canadian cars have adaptive cruise control" (another ConfigurationDecision). All ConfigurationDecisions within a single ConfigurationDecisionModel then specify how the target feature model(s) are to be configured depending on the configuration of the source feature model(s). Example: Lets assume we have two FeatureModels: FM1 and FM2. FM1 has possible end-customer decisions like USA, Canada, EU, Japan and A-Class, C-Class, etc. FM2 has another possible end-customer decision such as CruiseControl, AdaptiveCruiseControl, RearWiper, RainSensor. End-customer decisions in FM2 describe possible technical features of the delivered products. By way of a set of ConfigurationDecisions it is now possible to define the configuration of FM2 (i.e. if there is a RainSensor, etc.) dependent on a configuration of FM1. In other words, with a ConfigurationDecision we can express something like: "If USA is selected in FM1 AND A-Class is not selected in FM1, then CruiseControl will be selected in FM2". The two most important constituents of a ConfigurationDecision are its 'criterion' and 'effect'. The effect is a list of things to select and deselect in the target configuration(s), whereas the criterion formulates a condition on the source configuration(s) under which this ConfigurationDecision's effect will actually be applied to the target configuration(s). In the first example above, the criterion would be "USA &amp; not A-Class" and the effect would be "CruiseControl[+]". Semantics: The ConfigurationDecision excludes or includes Features based on a given criterion. The elements of the criterion and effect attributes may be identified through the target and the source in the selectionCriterion. The criterion and effect attributes can contain a VSL expression with qualified names of the identified elements. Constraints: [1] Attribute "criterion" or association "selectionCriterion" (or both) must be defined. Extension: Class The criterion is a logical expression on the source configuration(s) that states under which condition the 'effect' will be applied to the target configuration(s). This attribute adheres to the syntax and semantics of the VSL language. Note that association "selectionCriterion" provides an alternative means for defining such an expression in the form of an AUTOSAR mixed string expression. If both "criterion" and "selectionCriterion" are defined, they are assumed to be semantically equivalent and a tool may choose which one to use for variability and configuration management. States which Features are included/selected by the ConfigurationDecision in case the logical expression in 'criterion' evaluates to true. Each of these Features needs to be defined in one of the target feature models of the containing ConfigurationDecisionModel. This attribute adheres to the syntax and semantics of the VSL language. The Features are documented as a comma-separated list of strings. Each string has the form &lt;Name of FeatureModel&gt;#&lt;Name of Feature&gt;. If a string is unique in all the source and target FeatureModels of the ConfigurationDecisionModel containing this ConfigurationDecision, then the first part (the FeatureModel name and the #-separator) can be omitted. If a Feature name is not unique in a single FeatureModel, then a dot-notation may be used to prepend the name(s) of predecessors in order to identify the Feature. Configuring a cloned feature does not mean selecting or deselecting it but instead instances of the cloned feature are created. Each such instance is provided with a name, which thus becomes a part of the configuration (not the feature model). If several instances are created for a single cloned feature, then the name is used to identify these instances. For example, consider a cloned feature Wiper with cardinality [*]. A first configuration decision might create an instance called "front" and a second might create another named "rear"; a third configuration decision creating or otherwise referring to an instance called "front" will denote the same instance as the first configuration decision. The name space for these instance names is a particular feature configuration. As an example for the syntax and semantics of the effect attribute, assume there are two FeatureModels called FMa and FMb and they both contain the Features Wiper and ClimateControl. In FMa (but not in FMb), Wiper and ClimateControl are both refined into the child features Simple and Advanced. In addition, the wiper in FMa has a RainSensor. To denote the RainSensor in FMa you can state: FMa#Wiper.RainSensor or simply write: RainSensor This is sufficient here, because the name of Feature RainSensor is unique within FMa and within all FeatureModels referenced by the ConfigurationDecisionModel. In contrast, to denote the advanced version of the climate control in FMa you can specify: FMa#ClimateControl.Advanced or simply: ClimateControl.Advanced but merely stating "Advanced" would not suffice because there are two features with that name. Finally, to denote the wiper of feature model FMb you write: FMb#Wiper Setting the attribute isEquivalence to true means that the features referred to in the ConfigurationDecision's effect are exclusively configured by this ConfigurationDecision (i.e. no other ConfigurationDecision in the same ConfigurationDecisionModel may refer to these features). This means that this ConfigurationDecision is the ONLY way in which these features can be selected and therefore the usual logical implication that a ConfigurationDecision represents is turned into a logical equivalence, hence the name: the effect is applied to the target configurations if and only if the specified criterion holds. When setting this attribute to true, the modeler can state that the target-side features in this ConfigurationDecision's effect are exclusively configured by this ConfigurationDecision, i.e. no other ConfigurationDecision may influence these target-side features. ConfigurationDecision represents a single, atomized rule on how to configure the target feature model(s) of the containing ConfigurationDecisionModel, depending on a given configuration of the source feature model(s). Two examples are: "all North American (USA+Canada) cars except A-Class have cruise control" (one ConfigurationDecision) or "all Canadian cars have adaptive cruise control" (another ConfigurationDecision). All ConfigurationDecisions within a single ConfigurationDecisionModel then specify how the target feature model(s) are to be configured depending on the configuration of the source feature model(s). Example: Lets assume we have two FeatureModels: FM1 and FM2. FM1 has possible end-customer decisions like USA, Canada, EU, Japan and A-Class, C-Class, etc. FM2 has another possible end-customer decision such as CruiseControl, AdaptiveCruiseControl, RearWiper, RainSensor. End-customer decisions in FM2 describe possible technical features of the delivered products. By way of a set of ConfigurationDecisions it is now possible to define the configuration of FM2 (i.e. if there is a RainSensor, etc.) dependent on a configuration of FM1. In other words, with a ConfigurationDecision we can express something like: "If USA is selected in FM1 AND A-Class is not selected in FM1, then CruiseControl will be selected in FM2". The two most important constituents of a ConfigurationDecision are its 'criterion' and 'effect'. The effect is a list of things to select and deselect in the target configuration(s), whereas the criterion formulates a condition on the source configuration(s) under which this ConfigurationDecision's effect will actually be applied to the target configuration(s). In the first example above, the criterion would be "USA &amp; not A-Class" and the effect would be "CruiseControl[+]". Semantics: The ConfigurationDecision excludes or includes Features based on a given criterion. The elements of the criterion and effect attributes may be identified through the target and the source in the selectionCriterion. The criterion and effect attributes can contain a VSL expression with qualified names of the identified elements. Constraints: [1] Attribute "criterion" or association "selectionCriterion" (or both) must be defined. Extension: Class ConfigurationDecisionFolder represents a grouping for ConfigurationDecisions. Semantics: ConfigurationDecisionFolder is a grouping entity for ConfigurationDecisions. Extension: Class ConfigurationDecisionFolder represents a grouping for ConfigurationDecisions. Semantics: ConfigurationDecisionFolder is a grouping entity for ConfigurationDecisions. Extension: Class A ConfigurationDecisionModel defines how to configure m target feature models, depending on a given configuration of n source feature models, thus establishing a configuration-related link from the n source feature models to the m target feature models (also called configuration link). With the information captured in a ConfigurationDecisionModel it is then possible to transform a given set of source configurations (one for every source feature model) into corresponding target configurations (one for every target feature model). For example, a ConfigurationDecisionModel can capture information such as "if feature 'S-Class' is selected in the source feature model, then select feature 'RainSensor' in the target feature model" or "if feature 'USA' is selected in the source feature model, then select feature 'CupHolder' in the target feature model". Note that in principle all ConfigurationDecisionModels have source / target feature models. However, they are only defined explicitly for those used on vehicle level; for ConfigurationDecisionModels used as an internal binding on FunctionTypes, the source and target feature models are defined implicitly (cf. metaclass InternalBinding). In addition, in the special case of FeatureConfiguration there is by definition no source and only a single target feature model, which is defined explicitly (cf. metaclass FeatureConfiguration). The configuration information captured in a ConfigurationDecisionModel is represented by ConfigurationDecisions, each of which captures a single, atomized rule on how to configure the target feature model(s) depending on a given configuration of the source feature model(s). Semantics: See description. Extension: Class ConfigurationDecisionModelEntry is the abstract base class for all content of a ConfigurationDecisionModel. Semantics: See description. Extension: Class If active==TRUE then the ConfigurationDecisionModelEntry is actually applied when transforming source into target configurations; otherwise it will be ignored. With this attribute, configuration decisions can (temporarily) be disabled without having to delete them from the model. If this is set to FALSE for a ConfigurationDecisionFolder, then the entire contents of this folder are deactivated, no matter to what value their isActive-attribute is set. ContainerConfiguration defines an actual configuration of the variable content of a ConfigurableContainer, in particular the selection or deselection of contained VariableElements and the configuration of the public feature models of other contained ConfigurableContainers. For more details on the variable content of a ConfigurableContainer refer to the documentation of meta-class ConfigurableContainer. The ContainerConfiguration inherits from ConfigurationDecisionModel even though it does not define a configuration link between feature models, similar to FeatureConfiguration. For more information on this, refer to the documentation of meta-class FeatureConfiguration. The source and target feature models of a ContainerConfiguration are defined implicitly: it always has zero source feature models (as explained for FeatureConfiguration) and its target feature models can be deduced from the ConfigurableContainer being configured by applying the same rules as defined for InternalBinding. Semantics: The ContainerConfiguration specifies a concrete configuration of the variable content of a ConfigurableContainer. Extension: Class ContainerConfiguration defines an actual configuration of the variable content of a ConfigurableContainer, in particular the selection or deselection of contained VariableElements and the configuration of the public feature models of other contained ConfigurableContainers. For more details on the variable content of a ConfigurableContainer refer to the documentation of meta-class ConfigurableContainer. The ContainerConfiguration inherits from ConfigurationDecisionModel even though it does not define a configuration link between feature models, similar to FeatureConfiguration. For more information on this, refer to the documentation of meta-class FeatureConfiguration. The source and target feature models of a ContainerConfiguration are defined implicitly: it always has zero source feature models (as explained for FeatureConfiguration) and its target feature models can be deduced from the ConfigurableContainer being configured by applying the same rules as defined for InternalBinding. Semantics: The ContainerConfiguration specifies a concrete configuration of the variable content of a ConfigurableContainer. Extension: Class Context represents a simple and practical way to allocate TraceableSpecifications to a specific EAST-ADL model context, and to let this specific model context own Relationships. Semantics: See Relationship and TraceableSpecification. Extension: The ADLContext stereotype is an abstract stereotype which extends UML2 metaclass Element DelayConstraints give bounds on system timing attributes, i.e. end-to-end delays, periods, etc. A DelayConstraint can specify one or several of an upper bound, a lower bound or a nominal value and jitter. For example, [lower=10, upper=20, nominal=15] means a nominal value of 15 +/- 5. This is equivalent to [nominal=15, jitter=10], i.e. the nominal value varies by +/- 5 around 15. Note that the nominal value may also vary asymmetrically, e.g. [lower=10, nominal=12, upper=20]. Defining [nominal=15], without upper/lower or jitter, denotes an exact value of 15 without variations. The bound will be measured in a given unit, see TimeDuration. Constraints: [1] Exactly one of the following combinations of upper, lower, jitter, and nominal shall be specified: {upper, lower}, {upper, lower, jitter}, {upper}, {lower}, {nominal, jitter}. Any combination may in addition have a nominal parameter. If nominal is defined, it shall be in the range [lower ... upper]. Rationale: At least one value is necessary to describe a reasonable DelayConstraint, and the given combinations are sufficient to describe all possible variations. Semantics: lower (from TimingConstraint) denotes the minimum value of the actual delay. upper (from TimingConstraint) denotes the maximum value of the actual delay. Delay variation at runtime is constrained by means of the jitter value such that the maximal actual delay-minimum actual delay is less than jitter. If only {upper, lower} are specified, nominal is assumed to be (lower + (upper - lower) / 2) If only upper is defined, lower is assumed to be zero, nominal=upper If only lower is defined, upper is assumed to be infinity and nominal=lower If no jitter is defined jitter is assumed to be upper-lower. If {nominal, jitter} is defined, lower=nominal-jitter/2, upper=nominal+jitter/2. The possible variations and interpretations are shown in the following table. 'L' denotes 'Lower, 'U' denotes 'Upper', 'N' denotes 'Nominal', and 'J' denotes 'Jitter'. L | U | N | J | Lower | Upper | Nominal | Jitter ---------------------------------------------------------------------------------------------------------------------------- | | | | n/a | n/a | n/a | n/a | | | X | 0 | L + J | n/a | <value> | | X | | 0 | infinite | <value> | 0 | | X | X | N - ½ J | N + ½ J | <value> | <value> | X | | | 0 | <value> | L + ½ (U - L) | U - L | X | | X | 0 | <value> | L + ½ (U - L) | <value> | X | X | | 0 | <value> | <value> | U - L | X | X | X | 0 | <value> | <value> | <value> X | | | | <value> | infinite | n/a | 0 X | | | X | <value> | infinite | n/a | <value> X | | X | | <value> | infinite | <value> | 0 X | | X | X | <value> | N + ½ J | <value> | <value> X | X | | | <value> | <value> | L + ½ (U - L) | U - L X | X | | X |<value> | <value> | L + ½ (U - L) | <value> X | X | X | | <value> | <value> | <value> | U - L(1) X | X | X | X | <value> | <value> | <value> | <value> (1) In case of symmetric jitter. Otherwise asymmetric jitter. Extension: abstract, no extension The collection of dependability related information. This includes safety requirements, safety cases, safety constraints, and error modeling. This collection can be used across the EAST-ADL abstraction levels. Semantics: Dependability is a container element that collects elements related to dependabilty. It is possible to have several Dependability elements to organize related dependability information in dedicated containers. The collection of dependability related information. This includes safety requirements, safety cases, safety constraints, and error modeling. This collection can be used across the EAST-ADL abstraction levels. Semantics: Dependability is a container element that collects elements related to dependabilty. It is possible to have several Dependability elements to organize related dependability information in dedicated containers. The DeriveRequirement is a relationship metaclass, which signifies a dependency relationship between two sets of Requirements, showing the relationship when a set of derived client Requirement (client requirement) is derived from a set of Requirements (supplier requirement). Semantics: The DeriveRequirement metaclass signifies a derived/derived by relationship between Requirements, where the modification of the supplier Requirement may impact the derived client Requirement. Notation: A DeriveRequirement relationship is shown as a dashed arrow between two Requirements. The Requirement at the tail of the arrow (the derived Requirement) depends on the Requirement at the arrowhead (the Requirement derived from). Extension: To specialize SysML DeriveReqt, which specializes UML2 stereotype Trace, which extends Dependency. Temporary change in the profile (to overcome bug in Eclipse/UML2 concerning standard stereotypes) - added extension towards Dependency - removed generalization link towards SysML::DeriveReqt TODO: Move to Requirement package The DeriveRequirement is a relationship metaclass, which signifies a dependency relationship between two sets of Requirements, showing the relationship when a set of derived client Requirement (client requirement) is derived from a set of Requirements (supplier requirement). Semantics: The DeriveRequirement metaclass signifies a derived/derived by relationship between Requirements, where the modification of the supplier Requirement may impact the derived client Requirement. Notation: A DeriveRequirement relationship is shown as a dashed arrow between two Requirements. The Requirement at the tail of the arrow (the derived Requirement) depends on the Requirement at the arrowhead (the Requirement derived from). Extension: To specialize SysML DeriveReqt, which specializes UML2 stereotype Trace, which extends Dependency. Temporary change in the profile (to overcome bug in Eclipse/UML2 concerning standard stereotypes) - added extension towards Dependency - removed generalization link towards SysML::DeriveReqt TODO: Move to Requirement package The DesignFunctionPrototype represents references to the occurrence of the DesignFunctionType that types it when it acts as a part. The DesignFunctionPrototype is typed by a DesignFunctionType . Semantics: The DesignFunctionPrototype represents an occurrence of the DesignFunctionType that types it. Extension: UML Property, specialization of SysML::BlockProperty The DesignFunctionPrototype represents references to the occurrence of the DesignFunctionType that types it when it acts as a part. The DesignFunctionPrototype is typed by a DesignFunctionType . Semantics: The DesignFunctionPrototype represents an occurrence of the DesignFunctionType that types it. Extension: UML Property, specialization of SysML::BlockProperty The DesignFunctionType is a concrete FunctionType and therefore inherits the elementary function properties from the abstract metaclass FunctionType. The DesignFunctionType is used to model the functional structure on DesignLevel. The syntax of DesignFunctionTypes is inspired by the type-prototype pattern used by AUTOSAR. The DesignFunctions may interact with other DesignFunctions (i.e., also BasicSoftwareFunctions, HardwareFunctions, and LocalDeviceManagers) through their FunctionPorts. Furthermore, a DesignFunction may be decomposed into the contained parts that are DesignFunctionPrototypes. This allows the functionalities provided by the parent DesignFunction to be broken up hierarchically into subfunctionalities. Execution time constraints on the DesignFunctionType can be expressed by ExecutionTimeConstraints, see the Timing package. If two or more occurrences of an elementary Function are allocated on the same ECU, the code will be placed on the ECU only once (so these occurrences will use the same code but separate memory areas for data). Semantics: The DesignFunctionType represents a node in a tree structure corresponding to the functional decomposition of a top level DesignFunction. The DesignFunction represents the design function used to describe the functionalities provided by a vehicle on the DesignLevel. At the DesignLevel, DesignFunctions are defined and structured according to the functional and hardware system design. Constraints: [1] DesignFunctionTypes may only be used on DesignLevel. Extension: UML Class, specialization of SysML::Block The DesignFunctionType is a concrete FunctionType and therefore inherits the elementary function properties from the abstract metaclass FunctionType. The DesignFunctionType is used to model the functional structure on DesignLevel. The syntax of DesignFunctionTypes is inspired by the type-prototype pattern used by AUTOSAR. The DesignFunctions may interact with other DesignFunctions (i.e., also BasicSoftwareFunctions, HardwareFunctions, and LocalDeviceManagers) through their FunctionPorts. Furthermore, a DesignFunction may be decomposed into the contained parts that are DesignFunctionPrototypes. This allows the functionalities provided by the parent DesignFunction to be broken up hierarchically into subfunctionalities. Execution time constraints on the DesignFunctionType can be expressed by ExecutionTimeConstraints, see the Timing package. If two or more occurrences of an elementary Function are allocated on the same ECU, the code will be placed on the ECU only once (so these occurrences will use the same code but separate memory areas for data). Semantics: The DesignFunctionType represents a node in a tree structure corresponding to the functional decomposition of a top level DesignFunction. The DesignFunction represents the design function used to describe the functionalities provided by a vehicle on the DesignLevel. At the DesignLevel, DesignFunctions are defined and structured according to the functional and hardware system design. Constraints: [1] DesignFunctionTypes may only be used on DesignLevel. Extension: UML Class, specialization of SysML::Block The DesignLevel represents the vehicle electrical/electronic system on the design abstraction level. It includes primarily the Functional Design Architecture (FDA), and the HardwareDesignArchitecture (HDA). FDA represents a top level Function. It is supposed to implement all the functionalities of a vehicle, as specified by a FAA or a Vehicle level (if no FAA has been defined during the process). The design level in EAST-ADL includes the design architecture containing the functional specification and hardware architecture of the vehicle electrical/electronic system. The design architecture includes the FDA representing a decomposition of functionalities analyzed on the analysis level. The decomposition has the purpose of making it possible to meet constraints regarding non-functional properties such as allocation, efficiency, reuse, or supplier concerns. There is an n-to-m mapping between entities of the design level and the ones on the analysis level. Non-transparent infrastructure functionality such as mode changes and error handling are also represented at the design level, such that their impact on applications' behaviors can be estimated. The FDA parts are typed by DesignFunctionTypes and e.g. LocalDeviceManagers. The view of the HardwareArchitecture facilitates the realization of LocalDeviceManager as sensor/actuator HW elements. The HDA is the hardware design from a system perspective. The HDA has two purposes: 1) It shows the physical entities and how they are connected. 2) It is an allocation target for the Functions of the FDA. The HDA represents the hardware architecture of the embedded system. Its contained HW elements represent the physical aspects of the hardware entities and how they are connected. HardwareFunctionTypes associated to HW components represent the logical behavior of the contained HW elements. Semantics: The DesignLevel is the representation of the vehicle electrical/electronic system on the design abstraction level. It corresponds to the design of logical functions and boundaries extended in regards to resource commitment. Notation: The DesignLevel is shown as a solid-outline rectangle containing the name, with its ports or port groups on the perimeter. Contained entities may be shown with their connectors and allocations (White-box view). Extension: Class The DesignLevel represents the vehicle electrical/electronic system on the design abstraction level. It includes primarily the Functional Design Architecture (FDA), and the HardwareDesignArchitecture (HDA). FDA represents a top level Function. It is supposed to implement all the functionalities of a vehicle, as specified by a FAA or a Vehicle level (if no FAA has been defined during the process). The design level in EAST-ADL includes the design architecture containing the functional specification and hardware architecture of the vehicle electrical/electronic system. The design architecture includes the FDA representing a decomposition of functionalities analyzed on the analysis level. The decomposition has the purpose of making it possible to meet constraints regarding non-functional properties such as allocation, efficiency, reuse, or supplier concerns. There is an n-to-m mapping between entities of the design level and the ones on the analysis level. Non-transparent infrastructure functionality such as mode changes and error handling are also represented at the design level, such that their impact on applications' behaviors can be estimated. The FDA parts are typed by DesignFunctionTypes and e.g. LocalDeviceManagers. The view of the HardwareArchitecture facilitates the realization of LocalDeviceManager as sensor/actuator HW elements. The HDA is the hardware design from a system perspective. The HDA has two purposes: 1) It shows the physical entities and how they are connected. 2) It is an allocation target for the Functions of the FDA. The HDA represents the hardware architecture of the embedded system. Its contained HW elements represent the physical aspects of the hardware entities and how they are connected. HardwareFunctionTypes associated to HW components represent the logical behavior of the contained HW elements. Semantics: The DesignLevel is the representation of the vehicle electrical/electronic system on the design abstraction level. It corresponds to the design of logical functions and boundaries extended in regards to resource commitment. Notation: The DesignLevel is shown as a solid-outline rectangle containing the name, with its ports or port groups on the perimeter. Contained entities may be shown with their connectors and allocations (White-box view). Extension: Class DeviationAttributeSet specifies the set of rules of allowed deviations from the reference model in a referring model. These rules are important, because they make sure that the different FeatureModels, referring to one reference model, follow specific rules for deviation, so a later integration into one FeatureModel may be possible. Semantics: See description. Extension: DataType This rule sets whether and how the VehicleFeature attributes may be changed. Allowed values: no, append, yes. This rule sets whether and how the VehicleFeature cardinality (i.e. variability of the VehicleFeature) may be changed. Allowed values: no, subset, yes. This rule sets whether and how the VehicleFeature description may be changed. Allowed values: no, append, yes. This rule sets whether and how the VehicleFeature name may be changed. Allowed values: no, append, yes. This rule sets whether and how the VehicleFeature may be moved to another place in the feature diagram. Allowed values: no, subtree, yes. This rule sets if the reference feature may have a child without a corresponding referring feature among the children of the referring feature. Allowed values: no, subtree, yes. This rule sets whether and how adding may be done of a child feature (without a corresponding feature in the reference model). Allowed values: no, yes. This rule sets whether and how the immediate child features of the VehicleFeature are allowed to be regrouped (i.e. creation or deletion of FeatureGroups below the respective VehicleFeature). Allowed values: no, widen, yes. This rule sets if the feature in the referring model (compared to the reference model) may be deleted. Allowed values: no, yes. DeviationAttributeSet specifies the set of rules of allowed deviations from the reference model in a referring model. These rules are important, because they make sure that the different FeatureModels, referring to one reference model, follow specific rules for deviation, so a later integration into one FeatureModel may be possible. Semantics: See description. Extension: DataType A EABoolean value denotes a logical condition that is either 'true' or 'false'. Semantics: EABoolean is the primitive type that holds two literals: true, false. Notation: The datatype EABoolean is denoted using the rectangle symbol with keyword «Datatype Boolean». Extension: UML Boolean The EADatatypePrototype represents a typed variable. An example is a composite datatype ColorValue with parts R, G, and B of type integer. ColorValue would contain three prototypes only to be able to reference the record parts by name. Semantics: The EADatatypePrototype represents a typed variable. It acts as an appearance of a datatype. Extension: Class The EADatatypePrototype represents a typed variable. An example is a composite datatype ColorValue with parts R, G, and B of type integer. ColorValue would contain three prototypes only to be able to reference the record parts by name. Semantics: The EADatatypePrototype represents a typed variable. It acts as an appearance of a datatype. Extension: Class The EAElement is an abstract metaclass that represents an arbitrary named entity in the domain model. It specializes AUTOSAR Identifiable which has the shortName attribute used for identification of the element within the namespace in which it is defined. The abbreviation EA in the name of this metaclass is short for EAST-ADL. Semantics: Also the EAElement can be used to extend the EAST-ADL approach to other languages and standards by adding a generalize relation from the respective (non EAST-ADL) element to the EAElement. Extension: The ADLEntity stereotype is an abstract stereotype which extends UML2 metaclass NamedElement. The ADLEntity stereotype thus includes the name property from UML2 metaclass:NamedElement. The stereotype representation of this metaclass may be concrete to allow for application on instances from other domain models. Optional descriptive name of the EAElement, this name does not have the length restrictions as found for the AUTOSAR Identfiable shortName. An instance of EAFloat is an element from the set of real numbers. The value must comply with IEEE 754 and is limited to what can be expressed by a 64 bit binary representation. Semantics: EAFloat has the semantics of the Float datatype as defined by IEEE Standard for Floating-Point Arithmetic (IEEE 754). Notation: The datatype EAFloat is denoted using the rectangle symbol with keyword «Datatype Float». Extension: UML Datatype The maximal value of the range. The minimum value of the range. An instance of EAFloat is an element from the set of real numbers. The value must comply with IEEE 754 and is limited to what can be expressed by a 64 bit binary representation. Semantics: EAFloat has the semantics of the Float datatype as defined by IEEE Standard for Floating-Point Arithmetic (IEEE 754). Notation: The datatype EAFloat is denoted using the rectangle symbol with keyword «Datatype Float». Extension: UML Datatype An instance of EAInteger is an element in the set of integer numbers (..., -2, -1, 0, 1, 2, ...). Semantics: An instance of EAInteger is an element in the set of integer numbers (..., -2, -1, 0, 1, 2, ...). Notation: The datatype EAInteger is denoted using the rectangle symbol with keyword «Datatype Integer». Extension: UML Datatype The maximal value of the range. The minimum value of the range. An instance of EAInteger is an element in the set of integer numbers (..., -2, -1, 0, 1, 2, ...). Semantics: An instance of EAInteger is an element in the set of integer numbers (..., -2, -1, 0, 1, 2, ...). Notation: The datatype EAInteger is denoted using the rectangle symbol with keyword «Datatype Integer». Extension: UML Datatype Used for organization of the packageable elements in the model. Semantics: EAPackages can be organized hierarchically, where each level may contain a number of EAPackageableElements. Used for organization of the packageable elements in the model. Semantics: EAPackages can be organized hierarchically, where each level may contain a number of EAPackageableElements. A string is a sequence of characters in some suitable character set used to display information about the model. Character sets may include non-Roman alphabets and characters. An instance of EAString defines a piece of text. The semantics of the string itself depends on its purpose. It can be a comment, computational language expression, OCL expression, etc. It is used for String attributes and String expressions in the metamodel. Semantics: EAString is the primitive type that defines a sequence of characters in some suitable character set used to display information. Notation: The datatype EAString is denoted using the rectangle symbol with keyword «Datatype String». Extension: UML String The root element of an exchanged XML file which contains an EAST-ADL model. Semantics: EAXML represents the root element of an EAST-ADL XML file. admin.documentVersion="2012-03-30";autosar.documentVersion="4.0";xml.globalElement="true" The root element of an exchanged XML file which contains an EAST-ADL model. Semantics: EAXML represents the root element of an EAST-ADL XML file. admin.documentVersion="2012-03-30";autosar.documentVersion="4.0";xml.globalElement="true" The root element of an exchanged XML file which contains an EAST-ADL model. Semantics: EAXML represents the root element of an EAST-ADL XML file. admin.documentVersion="2012-03-30";autosar.documentVersion="4.0";xml.globalElement="true" An enumeration is a datatype whose values are enumerated in the model as enumeration literals. Enumeration is a kind of datatype, whose instances may be any of a number of user-defined enumeration literals. Semantics: Enumeration is a kind of datatype, whose instances may be any number &gt; 1 of user-defined enumeration literals. Enumerations contain at least two literals, otherwise it would be a constant. The contained literals need to be ordered. Notation: The datatype Enumeration is denoted using the rectangle symbol with keyword «Datatype Enumeration». Extension: UML Enumeration An enumeration is a datatype whose values are enumerated in the model as enumeration literals. Enumeration is a kind of datatype, whose instances may be any of a number of user-defined enumeration literals. Semantics: Enumeration is a kind of datatype, whose instances may be any number &gt; 1 of user-defined enumeration literals. Enumerations contain at least two literals, otherwise it would be a constant. The contained literals need to be ordered. Notation: The datatype Enumeration is denoted using the rectangle symbol with keyword «Datatype Enumeration». Extension: UML Enumeration An enumeration literal is a user-defined data value for an enumeration. Semantics: An EnumerationLiteral defines an element of the run-time extension of an enumeration data type. An EnumerationLiteral has a name (inherited from EAElement) that can be used to identify it within its Enumeration datatype. The EnumerationLiteral name is scoped and must therefore be unique within its Enumeration. The run-time values corresponding to EnumerationLiterals can be compared for equality. Notation: An EnumerationLiteral is typically shown as a name, one per line, in the compartment of the Enumeration notation. Extension: UML EnumerationLiteral The EnumerationValueType is a specific ValueType applicable for Enumerations. It provides the possibility to describe semantics of the baseEnumeration's literals and the information, if multiple values of the baseEnumeration may be selected or not. Semantics: The EnumerationValueType adds the ability to describe semantics of the baseEnumeration's literals and if multiple values of the baseEnumeration may be selected or not. Notation: The datatype EnumerationValueType is denoted using the rectangle symbol with keyword «Datatype EnumerationValueType». Extension: UML Datatype, SysML ValueType This boolean attribute is true, if multiple enumeration values can be selected. It is false, if only one enumeration value is allowed to be selected. The specific semantics for each literal of the baseEnumeration. The EnumerationValueType is a specific ValueType applicable for Enumerations. It provides the possibility to describe semantics of the baseEnumeration's literals and the information, if multiple values of the baseEnumeration may be selected or not. Semantics: The EnumerationValueType adds the ability to describe semantics of the baseEnumeration's literals and if multiple values of the baseEnumeration may be selected or not. Notation: The datatype EnumerationValueType is denoted using the rectangle symbol with keyword «Datatype EnumerationValueType». Extension: UML Datatype, SysML ValueType The collection of the environment functional descriptions. This collection can be done across the EAST-ADL abstraction levels. An environment model can contain functionPrototypes given by either AnalysisFunction or DesignFunction. The environment model does not have abstraction levels as in the system model (e.g., analysisLevel, designLevel). A functionPrototype of the environment model can have interactions with FAA FunctionalDevice and an FDA HardwareFunction through the ClampConnector. Semantics: Environment is a container element for the entities surrounding the EE architecture and their connections to the EE architecture. The function hierarchy of the Environment interacts with the EE System through Clamp Connectors connected to the SystemModel's functions. The collection of the environment functional descriptions. This collection can be done across the EAST-ADL abstraction levels. An environment model can contain functionPrototypes given by either AnalysisFunction or DesignFunction. The environment model does not have abstraction levels as in the system model (e.g., analysisLevel, designLevel). A functionPrototype of the environment model can have interactions with FAA FunctionalDevice and an FDA HardwareFunction through the ClampConnector. Semantics: Environment is a container element for the entities surrounding the EE architecture and their connections to the EE architecture. The function hierarchy of the Environment interacts with the EE System through Clamp Connectors connected to the SystemModel's functions. ErrorBehavior represents the descriptions of failure logics or semantics that the target element identified by the ErrorModelType exhibits. Typically the target is a system, a function, a software component, or a hardware device. Each ErrorBehavior description relates the occurrences of internal faults and incoming external faults to failures. The faults and failures that the errorBehavior propagates to and from the target element are declared through the ports of the error model. Semantics: ErrorBehavior defines the error propagation logic of its containing ErrorModelType. The ErrorBehavior description represents the error propagations from internal faults or incoming faults to external failures. Faults are identified by the internalFault and externalFault associations respectively. The propagated failures are identified by the externalFailure association. The ErrorBehavior is defined in the failureLogic string, either directly or as a URL referencing an external specification. The failureLogic can be based on different formalisms, depending on the analysis techniques and tools available. This is indicated by its type:ErrorBehaviorKind attribute. The failureLogic attribute contains the actual failure propagation logic. Extension: UML:Behavior The specification of error behavior based on an external formalism or the path to the file containing the external specification. The type of formalism applied for the error behavior description. ErrorBehavior represents the descriptions of failure logics or semantics that the target element identified by the ErrorModelType exhibits. Typically the target is a system, a function, a software component, or a hardware device. Each ErrorBehavior description relates the occurrences of internal faults and incoming external faults to failures. The faults and failures that the errorBehavior propagates to and from the target element are declared through the ports of the error model. Semantics: ErrorBehavior defines the error propagation logic of its containing ErrorModelType. The ErrorBehavior description represents the error propagations from internal faults or incoming faults to external failures. Faults are identified by the internalFault and externalFault associations respectively. The propagated failures are identified by the externalFailure association. The ErrorBehavior is defined in the failureLogic string, either directly or as a URL referencing an external specification. The failureLogic can be based on different formalisms, depending on the analysis techniques and tools available. This is indicated by its type:ErrorBehaviorKind attribute. The failureLogic attribute contains the actual failure propagation logic. Extension: UML:Behavior The ErrorModelPrototype is used to define hierarchical error models allowing additional detail or structure to be described in the error model of a particular target. A hierarchal structure can also be defined when several ErrorModels are integrated into a larger ErrorModel representing a system integrated from several targets. Typically the target is a system/subsystem, a function, a software component, or a hardware device. Semantics: An ErrorModelPrototype represents an occurrence of the ErrorModelType that types it. Extension: (See ADLFunctionPrototype) The ErrorModelPrototype is used to define hierarchical error models allowing additional detail or structure to be described in the error model of a particular target. A hierarchal structure can also be defined when several ErrorModels are integrated into a larger ErrorModel representing a system integrated from several targets. Typically the target is a system/subsystem, a function, a software component, or a hardware device. Semantics: An ErrorModelPrototype represents an occurrence of the ErrorModelType that types it. Extension: (See ADLFunctionPrototype) ErrorModelType and ErrorModelPrototype support the hierarchical composition of error models based on the type-prototype pattern also adopted for the nominal architecture composition. The purpose of the error models is to represent information relating to the anomalies of a nominal model element. An ErrorModelType represents the internal faults and fault propagations of the nominal element that it targets. Typically the target is a system/subsystem, a function, a software component, or a hardware device. ErrorModelType inherits the abstract metaclass TraceableSpecification, allowing the ErrorModelType to be referenced from its design context in a similar way as requirements, test cases and other specifications. Constraints: An ErrorModelType without part shall have one errorBehaviorDescription Semantics: The ErrorModelType represents a specification of the faults and fault propagations of its target element. Both types and prototypes may be targets, and the following cases are relevant: - One nominal type: The ErrorModelType represents the identified nominal type wherever this nominal type is instantiated. - Several nominal types: The ErrorModelType represents the identified nominal types individually, i.e. the same error model applies to all nominal types and is reused. - One nominal prototype: The ErrorModelType represents the identified nominal prototype whenever its context, i.e. its top-level composition is instantiated. - Several nominal prototypes with instanceref: The ErrorModelType represents the identified set of nominal prototypes (together) whenever their context, i.e. their top-level composition, is instantiated. The fault propagation of an errorModelType is defined by its contained parts, the ErrorModelPrototypes and their connections. In case it contains both parts and an errorBehaviorDescription, the errorBehaviorDescription shall be consistent with the parts. FaultFailurePropagationLinks define valid propagation paths in the ErrorModelType. In case the contained FaultInPorts and FailureOutPorts reference nominal ports, the connectivity of the nominal model may serve as a pattern for connecting ports in the ErrorModelType. The ErrorModelType contains internalFaults and externalFaults, representing faults that are either propagated to externalFailures or masked, according to the definition of its fault propagation. A processFault represents a flaw introduced during design, and may lead to any of the failures represented by the ErrorModelType. A processFault therefore has a direct propagation to all failures and cannot be masked. Extension: (see ADLTraceableSpecfication) ErrorModelType and ErrorModelPrototype support the hierarchical composition of error models based on the type-prototype pattern also adopted for the nominal architecture composition. The purpose of the error models is to represent information relating to the anomalies of a nominal model element. An ErrorModelType represents the internal faults and fault propagations of the nominal element that it targets. Typically the target is a system/subsystem, a function, a software component, or a hardware device. ErrorModelType inherits the abstract metaclass TraceableSpecification, allowing the ErrorModelType to be referenced from its design context in a similar way as requirements, test cases and other specifications. Constraints: An ErrorModelType without part shall have one errorBehaviorDescription Semantics: The ErrorModelType represents a specification of the faults and fault propagations of its target element. Both types and prototypes may be targets, and the following cases are relevant: - One nominal type: The ErrorModelType represents the identified nominal type wherever this nominal type is instantiated. - Several nominal types: The ErrorModelType represents the identified nominal types individually, i.e. the same error model applies to all nominal types and is reused. - One nominal prototype: The ErrorModelType represents the identified nominal prototype whenever its context, i.e. its top-level composition is instantiated. - Several nominal prototypes with instanceref: The ErrorModelType represents the identified set of nominal prototypes (together) whenever their context, i.e. their top-level composition, is instantiated. The fault propagation of an errorModelType is defined by its contained parts, the ErrorModelPrototypes and their connections. In case it contains both parts and an errorBehaviorDescription, the errorBehaviorDescription shall be consistent with the parts. FaultFailurePropagationLinks define valid propagation paths in the ErrorModelType. In case the contained FaultInPorts and FailureOutPorts reference nominal ports, the connectivity of the nominal model may serve as a pattern for connecting ports in the ErrorModelType. The ErrorModelType contains internalFaults and externalFaults, representing faults that are either propagated to externalFailures or masked, according to the definition of its fault propagation. A processFault represents a flaw introduced during design, and may lead to any of the failures represented by the ErrorModelType. A processFault therefore has a direct propagation to all failures and cannot be masked. Extension: (see ADLTraceableSpecfication) An Event (E) denotes a distinct form of state change in a running system, taking place at distinct points in time called occurrences of the event. An event may also report a [current] state. In that case, the event occurs periodically. For example, the "driver door has been opened" is an event indicating a state change; whereas the "driver door is open" is an event reporting a state. A running system can be observed by identifying certain forms of state changes to watch for, and for each such observation point, noting the times when changes occur. This notion of observation also applies to a hypothetical predicted run of a system or a system model from a timing perspective; the only information that needs to be in the output of such a prediction is a sequence of times for each observation point, indicating the times that each event is predicted to occur. The occurrence of an event either stimulates an execution, or is caused by an execution [as a response to another event that occurred before]. In the first case the event is called Stimulus (S) and in the latter case it is called Response (R). Stimuli always precede responses; and responses always succeed stimuli. An event occurs instantaneously, which means that an event occurs at an instant of time without any duration. In addition, an event can appear any number of times and the subsequent occurrences may follow a specific pattern, like periodic, sporadic, or in sudden bursts. Each of these occurrences has a unique time instant. The distinction between an event and its occurrence is usually obvious from the considered context (causal and temporal). The event is not defined by its occurrences, but rather by a description expressing its purpose. Constraints: [1] In the case that the event reports a [current] state (isStateChange is FALSE), the event must have a periodic event model [or a pattern model]. Rationale: The [current] state shall be reported consistently and periodically. Semantics: Event is abstract. Semantics is defined on the specializations. This attribute indicates whether the event reports a state change or a [current] state. If the boolean value is TRUE, then the event reports a state change (no over-/undersampling). If the boolean value is FALSE, then the event reports a [current] state. By default, the value of this attribute is TRUE. Event chains describe the temporal behavior of a number of steps to be taken to respond to one or more events. [An event chain is also used to express that a temporal requirement/constraint is imposed on these steps (-> requirement).] Such events could be observed in a given system and are categorized into stimuli and responses. Event chains can refer to other event chains which are then called event chain segments and strands. Segments are sequential event chains refining an EventChain, while strands define parallel event chains that refine an EventChain. An EventChain can be both a segment and a strand at the same time. An event chain respectively event chain segment can be atomic which means it is not refined to other event chains. Constraints: [1] The cardinality of strand shall be either 0 or greater than 1. Rationale: Only values > 1 express true parallelism. Semantics: An EventChain references two groups of events: stimulus and response. The semantics are that each event in the stimulus group somehow causes, or at least affects the value of all events in the response group. However, since questions about causality and value influence clearly involve the semantics of the underlying structural model, this aspect of an EventChain is semantically outside its scope. Instead, delay constraint semantics are defined solely in terms of the times at which the stimulus and response events occur, irrespective of whether there actually exists a causal connection between these events in the structural model. Event chains describe the temporal behavior of a number of steps to be taken to respond to one or more events. [An event chain is also used to express that a temporal requirement/constraint is imposed on these steps (-> requirement).] Such events could be observed in a given system and are categorized into stimuli and responses. Event chains can refer to other event chains which are then called event chain segments and strands. Segments are sequential event chains refining an EventChain, while strands define parallel event chains that refine an EventChain. An EventChain can be both a segment and a strand at the same time. An event chain respectively event chain segment can be atomic which means it is not refined to other event chains. Constraints: [1] The cardinality of strand shall be either 0 or greater than 1. Rationale: Only values > 1 express true parallelism. Semantics: An EventChain references two groups of events: stimulus and response. The semantics are that each event in the stimulus group somehow causes, or at least affects the value of all events in the response group. However, since questions about causality and value influence clearly involve the semantics of the underlying structural model, this aspect of an EventChain is semantically outside its scope. Instead, delay constraint semantics are defined solely in terms of the times at which the stimulus and response events occur, irrespective of whether there actually exists a causal connection between these events in the structural model. An EventConstraint describes the basic characteristics of the way an event occurs over time. Semantics: EventConstraint characterizes the occurrence pattern of its associated event. The further semantics is defined on the specializations. An event of a Function refers to the triggering of the Function, i.e., when the input data is consumed, data transformation is performed on that input data by the function, and output data is produced. It can be used in conjunction with FunctionTrigger to define a time-driven triggering for a function. In this case the FunctionTrigger points to the EventFunction of the function and defines a triggerPolicy set to TIME. The timing constraint associated to the EventFunction provides information about the period. Compare categories of AUTOSAR runnables: 1a triggering only on start and finish (this type of event) 1b triggering allowed anytime during the execution (events on ports, see EventFunctionFlowPort). Semantics: The EventFunction refers to the triggering event of a referenced functionType or function (prototype). Triggering is the time when the function consumes data. Constraints: [1] An EventFunction either identifies a FunctionType or a FunctionPrototype as its target function. An event of a Function refers to the triggering of the Function, i.e., when the input data is consumed, data transformation is performed on that input data by the function, and output data is produced. It can be used in conjunction with FunctionTrigger to define a time-driven triggering for a function. In this case the FunctionTrigger points to the EventFunction of the function and defines a triggerPolicy set to TIME. The timing constraint associated to the EventFunction provides information about the period. Compare categories of AUTOSAR runnables: 1a triggering only on start and finish (this type of event) 1b triggering allowed anytime during the execution (events on ports, see EventFunctionFlowPort). Semantics: The EventFunction refers to the triggering event of a referenced functionType or function (prototype). Triggering is the time when the function consumes data. Constraints: [1] An EventFunction either identifies a FunctionType or a FunctionPrototype as its target function. Event that refers to the triggering of the Function at a client/server port, i.e., when the input data is sent / received, or when the output data is produced / received. Constraints: [1] eventKind is sentRequest or receivedResponse for a FunctionClientServerPort of type client. Rationale: Only these values make sense for client ports. [2] eventKind is receivedRequest or sentResponse for a FunctionClientServerPort of type server. Rationale: Only these values make sense for server ports. Semantics: EventFunctionClientServerPort refers to the time when data is sent or received at the ClientServerPort. Event that refers to the triggering of the Function at a client/server port, i.e., when the input data is sent / received, or when the output data is produced / received. Constraints: [1] eventKind is sentRequest or receivedResponse for a FunctionClientServerPort of type client. Rationale: Only these values make sense for client ports. [2] eventKind is receivedRequest or sentResponse for a FunctionClientServerPort of type server. Rationale: Only these values make sense for server ports. Semantics: EventFunctionClientServerPort refers to the time when data is sent or received at the ClientServerPort. Event that refers to the triggering of the Function at a flow port, i.e., when data is sent or received. Semantics: EventFunctionFlowPort refers to the time when data is sent or received at the FunctionFlowPort. Event that refers to the triggering of the Function at a flow port, i.e., when data is sent or received. Semantics: EventFunctionFlowPort refers to the time when data is sent or received at the FunctionFlowPort. ExecutionTimeConstraint expresses the execution time of a function under the assumption of a nominal CPU that executes 1 "function second" per second. Function allocation will decide the actual execution time by multiplication with the relative speed of the host CPU. Example: The ECU is 20% faster than a standard ECU (e.g. in a certain context, execution times are given assuming a nominal speed of 100 MHz; Our CPU is then 120 MHz) The function is activated by a time trigger or a port trigger. The function starts execution some time after activation, depending on e.g. interference and/or blocking from other functions on the same resource. Immediately on start, the function reads input data on all ports. Functions write data at the latest when the execution time has elapsed (which is after the execution time plus any blocking and interference time). Constraints: [1] An ExecutionTimeConstraint either identifies a FunctionType or a FunctionPrototype as its target function. [2] variation shall be a value between 0 and upper-lower. Semantics: lower (from TimingConstraint) denotes the minimal best case execution time. upper (from TimingConstraint) denotes the maximal worst case execution time. variation denotes the allowed variation in execution time, i.e. maximal minimal execution time. Example: lower=5 upper=10 variation=2 best case execution time of 6 and worst case of 7 is within this constraint best case execution time of 6 and worst case of 9 violates this constraint If a measured value is characterized, variation is not used, as it is always upper-lower, e.g. lower=6 and upper=9 above. In this example, the ExecutionTimeConstraint would be a Realization of a VVActualOutcome. ExecutionTimeConstraint expresses the execution time of a function under the assumption of a nominal CPU that executes 1 "function second" per second. Function allocation will decide the actual execution time by multiplication with the relative speed of the host CPU. Example: The ECU is 20% faster than a standard ECU (e.g. in a certain context, execution times are given assuming a nominal speed of 100 MHz; Our CPU is then 120 MHz) The function is activated by a time trigger or a port trigger. The function starts execution some time after activation, depending on e.g. interference and/or blocking from other functions on the same resource. Immediately on start, the function reads input data on all ports. Functions write data at the latest when the execution time has elapsed (which is after the execution time plus any blocking and interference time). Constraints: [1] An ExecutionTimeConstraint either identifies a FunctionType or a FunctionPrototype as its target function. [2] variation shall be a value between 0 and upper-lower. Semantics: lower (from TimingConstraint) denotes the minimal best case execution time. upper (from TimingConstraint) denotes the maximal worst case execution time. variation denotes the allowed variation in execution time, i.e. maximal minimal execution time. Example: lower=5 upper=10 variation=2 best case execution time of 6 and worst case of 7 is within this constraint best case execution time of 6 and worst case of 9 violates this constraint If a measured value is characterized, variation is not used, as it is always upper-lower, e.g. lower=6 and upper=9 above. In this example, the ExecutionTimeConstraint would be a Realization of a VVActualOutcome. Extend represents the specification that the behavior of a UseCase may be extended by the behavior of another (usually supplementary) UseCase. The extension takes place at one or more specific ExtensionPoints defined in the extended UseCase. Note, however, that the extended UseCase is defined independently of the extending UseCase and is meaningful independently of the extending UseCase. On the other hand, the extending UseCase typically defines behavior that may not necessarily be meaningful by itself. Instead, the extending UseCase defines a set of modular behavior increments that augment an execution of the extended UseCase under specific conditions. Note that the same extending UseCase can extend more than one UseCases. Furthermore, an extending UseCase may itself be extended. Semantics: An Extension relation identifies an extension UseCase which extends an extendedCase UseCase. Extend represents the specification that the behavior of a UseCase may be extended by the behavior of another (usually supplementary) UseCase. The extension takes place at one or more specific ExtensionPoints defined in the extended UseCase. Note, however, that the extended UseCase is defined independently of the extending UseCase and is meaningful independently of the extending UseCase. On the other hand, the extending UseCase typically defines behavior that may not necessarily be meaningful by itself. Instead, the extending UseCase defines a set of modular behavior increments that augment an execution of the extended UseCase under specific conditions. Note that the same extending UseCase can extend more than one UseCases. Furthermore, an extending UseCase may itself be extended. Semantics: An Extension relation identifies an extension UseCase which extends an extendedCase UseCase. ExtensionPoint represents a feature of a UseCase that identifies a point where the behavior of a UseCase can be augmented with elements of another (extending) UseCase. Semantics: ExtensionPoint identifies the point where the useCase UseCase ca be extended. The FailureOutPort represents a propagation point for failures that propagate out from the containing ErrorModelType.The EADatatype of the FailureOutPort defines the range of valid failures. Constraints: [1] The direction of the nominal port must be 'out'. Semantics: The value range of a FailureOutPort represents failures that can propagate to FaultInPorts in other ErrorModels. The value range is defined by the FailureOutPort's EADatatype. If nominal Ports HWTargets or FunctionTargets are referenced, the failures of the FailureOutPort correspond to data on these nominal ports. Extension: UML::Port The FaultFailure represents a certain fault or failure on its referenced Anomaly. The faultFailureValue specifies the value of the Anomaly that the FaultFailure corresponds to, i.e. one of the possible values of the Anomaly. Semantics: A FaultFailure is defined as a certain value, faultFailureValue, occurring at the referenced Anomaly. The FaultFailure represents a certain fault or failure on its referenced Anomaly. The faultFailureValue specifies the value of the Anomaly that the FaultFailure corresponds to, i.e. one of the possible values of the Anomaly. Semantics: A FaultFailure is defined as a certain value, faultFailureValue, occurring at the referenced Anomaly. Abstract port for Faults and Failures. Semantics: FaultFailurePort is abstract. Semantics is defined on its specializations. The FaultFailurePropagationLink metaclass represents the links for the propagations of faults/failures across system elements. In particular, it defines that one error model provides the faults/failures that another error model receives. A fault/failure link can only be applied to compatible ports, either for fault/failure delegation within an error model or for fault/failure transmission across two error models. A FaultFailurePropagationLink can only connect fault/failure ports that have compatible types. Constraints: [1] Only compatible fromPort-toPort pairs may be connected. [2] Two fault/failure ports are compatible if the EADatatype of the fromPort represents a subset of the Fault/Failure set represented by the toPort’s EADatatype. Semantics: The FaultFailurePropagationLink defines a Failure propagation path, from the fromPort on one error model to the toPort of another error model. Extension: UML::Connector The FaultFailurePropagationLink metaclass represents the links for the propagations of faults/failures across system elements. In particular, it defines that one error model provides the faults/failures that another error model receives. A fault/failure link can only be applied to compatible ports, either for fault/failure delegation within an error model or for fault/failure transmission across two error models. A FaultFailurePropagationLink can only connect fault/failure ports that have compatible types. Constraints: [1] Only compatible fromPort-toPort pairs may be connected. [2] Two fault/failure ports are compatible if the EADatatype of the fromPort represents a subset of the Fault/Failure set represented by the toPort’s EADatatype. Semantics: The FaultFailurePropagationLink defines a Failure propagation path, from the fromPort on one error model to the toPort of another error model. Extension: UML::Connector The FaultInPort represents a propagation point for faults that propagate to the containing ErrorModelType. The EADatatype of the FaultInPort defines the range of valid failures. Constraints: [1] The direction of the nominal port must be 'in'. Semantics: The value range of a FaultInPort represents faults propagated from a FailureOutPort in another ErrorModel. The value range is defined by the FaultInPort's EADatatype. If nominal Ports HWTarget or FunctionTarget are referenced, the faults on the FaultInPort correspond to data on these nominal ports. Extension: UML::Port A Feature represents a characteristic or trait of some object of consideration. The actual object of consideration depends on the particular purpose of the feature's containing feature model. Example 1: The core technical feature model on vehicle level defines the technical properties of the complete system, i.e., vehicle. So its object of consideration is the vehicle as a whole and therefore its features represent characteristics or traits of the vehicle as a whole. Example 2: The public feature model of some function F in the FDA defines the features of this particular software function. So its object of consideration is function F and therefore its features represent characteristics or traits of this function F. Semantics: Feature is a (non)functional characteristic, constraint or property that can be present or not in a (vehicle) product line. Extension: Class Specifies the Feature's cardinality stating how often this feature may be selected during configuration. Typical cardinalities include: - A cardinality of 0..1 means that this Feature is optional, i.e. it can be selected or deselected during configuration. - A cardinality of 1 means that this Feature is mandatory, i.e. it cannot be deselected but is always present in a configuration if its parent feature is present; mandatory root features are present in all configurations. - A cardinality of 0 means that this Feature is abstract, i.e. it cannot be selected and is never present in any configuration. This can be used to completely disable a feature and, in the case of non-leaf features, the whole subtree below it, for example to tentatively remove a subtree without (yet) deleting it completely from the model. - A cardinality with an upper bound greater than 1 or * (infinite), such as [0..2], [1..*], or [2..8], means that this Feature is cloned, i.e. it may be selected more than once during configuration. If such a feature is actually selected more than once in a particular configuration, then its entire subtree may be configured differently for each selection. Cloned features are in fact instantiated during configuration and each instance is provided with a name. Note that using cloned features, i.e. features with cardinality having an upper bound greater than 1, has far-reaching consequences for how Features are applied. If this is not desired/needed in a certain project, cardinalities >1 can be prohibited by specifying an appropriate complianceLevel in the FeatureModel. As a general guideline, cloned features should be avoided as far as possible. In some situations, however, they can prove extremely useful and elegant. For example, consider the feature model of a wiper system; in order to allow for an extremely flexible configuration of the interval modes, a single parameterized cloned feature can be used: "IntervalMode[2..*] : Float". With this single cloned feature, any number of intervals can be created (but at least 2) and for each interval a precise duration in sec can be configured; without cloned features, this degree of flexibility could not easily be achieved. A Feature represents a characteristic or trait of some object of consideration. The actual object of consideration depends on the particular purpose of the feature's containing feature model. Example 1: The core technical feature model on vehicle level defines the technical properties of the complete system, i.e., vehicle. So its object of consideration is the vehicle as a whole and therefore its features represent characteristics or traits of the vehicle as a whole. Example 2: The public feature model of some function F in the FDA defines the features of this particular software function. So its object of consideration is function F and therefore its features represent characteristics or traits of this function F. Semantics: Feature is a (non)functional characteristic, constraint or property that can be present or not in a (vehicle) product line. Extension: Class FeatureConfiguration defines an actual configuration of a FeatureModel, in particular the selection or deselection of optional features, values for selected parameterized features, and instance creations for cloned features. Note that configurations of feature models are realized as a specialization of metaclass ConfigurationDecisionModel. This is possible because a ConfigurationDecisionModel also captures the configuration, i.e., of its target feature model(s); while in the standard case of ConfigurationDecisionModel this target-side configuration depends on a given configuration of source feature model(s), here we simply define a "constant" target-side configuration without considering any source configurations. Therefore, the FeatureConfiguration meta-class has additional constraints compared to the super-class ConfigurationDecisionModel: the FeatureConfiguration has no source FeatureModel and only a single target FeatureModel, which serves as the FeatureModel being configured, explicitly defined through association 'configuredFeatureModel'. And since there is no source feature model to which the criterion can refer, all ConfigurationDecisions in a FeatureConfiguration must have "true" as their criterion. Semantics: The FeatureConfiguration specifies a concrete configuration of a feature model, in particular which Features of this FeatureModel are selected or deselected. Extension: Class Constraint: [1] Attribute criterion of all ConfigurationDecisions in a FeatureConfiguration must be set to "true". FeatureConfiguration defines an actual configuration of a FeatureModel, in particular the selection or deselection of optional features, values for selected parameterized features, and instance creations for cloned features. Note that configurations of feature models are realized as a specialization of metaclass ConfigurationDecisionModel. This is possible because a ConfigurationDecisionModel also captures the configuration, i.e., of its target feature model(s); while in the standard case of ConfigurationDecisionModel this target-side configuration depends on a given configuration of source feature model(s), here we simply define a "constant" target-side configuration without considering any source configurations. Therefore, the FeatureConfiguration meta-class has additional constraints compared to the super-class ConfigurationDecisionModel: the FeatureConfiguration has no source FeatureModel and only a single target FeatureModel, which serves as the FeatureModel being configured, explicitly defined through association 'configuredFeatureModel'. And since there is no source feature model to which the criterion can refer, all ConfigurationDecisions in a FeatureConfiguration must have "true" as their criterion. Semantics: The FeatureConfiguration specifies a concrete configuration of a feature model, in particular which Features of this FeatureModel are selected or deselected. Extension: Class Constraint: [1] Attribute criterion of all ConfigurationDecisions in a FeatureConfiguration must be set to "true". Captures a constraint on the containing feature model's configuration which is too complex to be expressed by way of a FeatureLink. In general, all constraints that can be expressed by a FeatureLink can also be expressed by a FeatureConstraint, but not vice versa. Semantics: See description. The actual constraint. This is a logic expression in VSL like the criterion of a ConfigurationDecision. For the constraint to be met this expression always has to evaluate to true. For example, to express a mutual exclusion of two features, use the expression "! (Radar & RainSensor)". However, note that this particular constraint could also be formulated as a FeatureLink with type "excludes". Captures a constraint on the containing feature model's configuration which is too complex to be expressed by way of a FeatureLink. In general, all constraints that can be expressed by a FeatureLink can also be expressed by a FeatureConstraint, but not vice versa. Semantics: See description. FeatureFlaw denotes an abstract failure of a set of items, i.e. an inability to fulfill one or several of its requirements. Semantics: FeatureFlaw represents functional anomalies derivable from each foreseeable source. nonFulfilledRequirements identifies those requirements that correspond to the FeatureFlaw. Extension: UML::Class FeatureFlaw denotes an abstract failure of a set of items, i.e. an inability to fulfill one or several of its requirements. Semantics: FeatureFlaw represents functional anomalies derivable from each foreseeable source. nonFulfilledRequirements identifies those requirements that correspond to the FeatureFlaw. Extension: UML::Class FeatureGroup is a specialization of the FeatureTreeNode, enabling grouping of several Features. Semantics: FeatureGroup is a grouping entity for sibling Features to reflect variability for a set of Features. Extension: Class The cardinality of the FeatureGroup, specifies how the grouped features, in featureGroup, can be combined. For example, a FeatureGroup owning the two Features A and B, and with a cardinality of [1], means that A and B are alternatives, but only one of them can be chosen. Mandatory features among the child features count as 1 and for cloned features all instances created in the configuration count. FeatureGroup is a specialization of the FeatureTreeNode, enabling grouping of several Features. Semantics: FeatureGroup is a grouping entity for sibling Features to reflect variability for a set of Features. Extension: Class A FeatureLink resembles a Relationship between two Features referred to as 'start' and 'end' feature (such as "feature S requires feature E" or "S excludes E"). The type of the FeatureLink specifies the precise semantics of the relationship. There are several predefined types, for example "needs" states that S requires E. In addition, user-defined types are allowed as well. For user-defined types, attribute 'customType' provides a unique identifier of the custom link type and attribute 'isBidirectional' states whether the link is uni- or bidirectional. FeatureLinks are similar to FeatureConstraints but much more restricted. The rationale for having FeatureLinks in addition to FeatureConstraints is that in many cases FeatureLinks are sufficient and tools can deal with them more easily and appropriately (e.g. they can easily be presented visually as arrows in a diagram). Semantics: The FeatureLink is a relationship between Features that may constrain the selection of Features involved in the relationship. Constraints: [1] The start and end Features of a FeatureLink must be contained in the FeatureModel that contains the FeatureLink. Extension: AssociationClass The custom type of this FeatureLink identified by a String value. This attribute's value is ignored if attribute 'kind' is set to some other value than 'custom'. Each company or project can decide to use additional link types by defining unique key-words for them. In cases where FeatureModels are shared with third parties (other departments, companies, etc.) a globally unique type string must be used. Follow the instructions for finding globally unique keys for user attributes (cf. documentation of metaclass UserAttributeValue). Tells whether the FeatureLink is bidirectional or unidirectional. For predefined kinds, such as "needs", "mandatoryAlternative", etc., this attribute will be ignored and the kind determines whether the link is bidirectional or not (as defined in the documentation of attribute 'type', below). For custom kinds, this attribute may be provided to explicitly state the link's direction. If this attribute is not provided in case of a custom link type, then the link is assumed to be unidirectional. The kind determines the precise semantics of the relation between the FeatureLink's start and end feature. There are 5 predefined kinds as defined by enumeration VariabilityDependencyKind and in the case of kind 'custom' the attribute customType can be used to define a custom feature link type. A FeatureLink resembles a Relationship between two Features referred to as 'start' and 'end' feature (such as "feature S requires feature E" or "S excludes E"). The type of the FeatureLink specifies the precise semantics of the relationship. There are several predefined types, for example "needs" states that S requires E. In addition, user-defined types are allowed as well. For user-defined types, attribute 'customType' provides a unique identifier of the custom link type and attribute 'isBidirectional' states whether the link is uni- or bidirectional. FeatureLinks are similar to FeatureConstraints but much more restricted. The rationale for having FeatureLinks in addition to FeatureConstraints is that in many cases FeatureLinks are sufficient and tools can deal with them more easily and appropriately (e.g. they can easily be presented visually as arrows in a diagram). Semantics: The FeatureLink is a relationship between Features that may constrain the selection of Features involved in the relationship. Constraints: [1] The start and end Features of a FeatureLink must be contained in the FeatureModel that contains the FeatureLink. Extension: AssociationClass FeatureModel denotes a model owning Features. The FeatureModel can be used to describe variability and commonality of a specified electrical/electronic system at any abstraction level in the SystemModel. The FeatureModel can be used either to describe the variability within a particular Function or to describe the overall variability of a vehicle (cf. VehicleLevel). The FeatureModel describing internal variability of a FunctionType refers to the VehicleLevel by a «realizes» link (informative). Note, however, that a FeatureModel per definition does not always have to define variability. If a feature model contains only mandatory features, then its purpose is completely unrelated to variability. The features in such a FeatureModel could serve, for example, as invariant "coarse-grained requirements". The most important example is the core technical feature model on vehicle level which is also used for SystemModels that do not contain any variability at all. However, most uses of feature models in EAST-ADL are primarily motivated by variability definition and management. A public, local FeatureModel of an artifact element realizes a VehicleFeature of the VehicleLevel. Semantics: The FeatureModel has no specific semantics. Further subclasses of FeatureModel will add semantics appropriate to the concept they represent. Extension: Package FeatureModel denotes a model owning Features. The FeatureModel can be used to describe variability and commonality of a specified electrical/electronic system at any abstraction level in the SystemModel. The FeatureModel can be used either to describe the variability within a particular Function or to describe the overall variability of a vehicle (cf. VehicleLevel). The FeatureModel describing internal variability of a FunctionType refers to the VehicleLevel by a «realizes» link (informative). Note, however, that a FeatureModel per definition does not always have to define variability. If a feature model contains only mandatory features, then its purpose is completely unrelated to variability. The features in such a FeatureModel could serve, for example, as invariant "coarse-grained requirements". The most important example is the core technical feature model on vehicle level which is also used for SystemModels that do not contain any variability at all. However, most uses of feature models in EAST-ADL are primarily motivated by variability definition and management. A public, local FeatureModel of an artifact element realizes a VehicleFeature of the VehicleLevel. Semantics: The FeatureModel has no specific semantics. Further subclasses of FeatureModel will add semantics appropriate to the concept they represent. Extension: Package Statement of the paths of quantities in a computation. A flow connecting the input and output parameters of a system represents an end-to-end flow of the system. Constraints: A flow has at least one source and one sink parameter. Semantics: A flow specifies the relationship between some parameters (the source) and other parameters (the sink), where the second group of parameters is a consequence of the first group. It defines the causality of these parameters. Statement of the paths of quantities in a computation. A flow connecting the input and output parameters of a system represents an end-to-end flow of the system. Constraints: A flow has at least one source and one sink parameter. Semantics: A flow specifies the relationship between some parameters (the source) and other parameters (the sink), where the second group of parameters is a consequence of the first group. It defines the causality of these parameters. FunctionAllocation represents an allocation constraint binding an AllocateableElement (computation functions or communication connectors) on an AllocationTarget (computation or communication resource). Semantics: AllocationTarget is specialized by HardwareComponentPrototype in the HardwareModeling package and AllocateableElement is specialized by the concrete elements DesignFunctionPrototype and FunctionConnector in the FunctionModeling package. Notation: A FunctionAllocation is shown as a dependency (dashed line) with an "allocation" keyword attached to it. Extension: Class, specializesDesignConstraint target to AUTOSAR::ECUResourceTemplate::ECU allocatedAutosarComponent to AUTOSAR::Components::ClientPort ToDo: Cf. AUTOSAR SWMapping::MappingConstraint FunctionAllocation represents an allocation constraint binding an AllocateableElement (computation functions or communication connectors) on an AllocationTarget (computation or communication resource). Semantics: AllocationTarget is specialized by HardwareComponentPrototype in the HardwareModeling package and AllocateableElement is specialized by the concrete elements DesignFunctionPrototype and FunctionConnector in the FunctionModeling package. Notation: A FunctionAllocation is shown as a dependency (dashed line) with an "allocation" keyword attached to it. Extension: Class, specializesDesignConstraint target to AUTOSAR::ECUResourceTemplate::ECU allocatedAutosarComponent to AUTOSAR::Components::ClientPort ToDo: Cf. AUTOSAR SWMapping::MappingConstraint FunctionBehavior represents the behavior of a particular FunctionType - referred to by the association to FunctionType. What is meant by behavior is a transfer function performing some data computation (in case of FlowPort interaction) or an operation that can be called by another function (in case of ClientServer interaction). The representation property indicates the kind of representation used to describe the behavior (see FunctionBehaviorKind). The representation itself (e.g., defined in an external model file) is identified by a URL String in the path property. If the representation is provided in the same model file as the system itself, the path property is not used. It is merely a placeholder for the purpose of containing information about and links to the external behavioral model. FunctionBehavior may refer to execution modes by the association to the element Mode. This is not mandatory; however, when provided, the relation indicates the list of execution Modes in which the FunctionBehavior can potentially be executed (see element Mode). The triggering of a FunctionBehavior is unknown to the behavior. It is defined by FunctionTriggers (see this element). Note that the association between FunctionBehavior and FunctionType is specified as a one-way navigable link from FunctionBehavior to FunctionType: what this means is that the EAST-ADL language specification does not require a FunctionType be aware of the FunctionBehavior it is assigned to. Only the navigation from behavior to function is mandatory; the implementation of a reverse link might however be provided depending on the tool support. Although each FunctionBehavior can refer to at most one FunctionType, note that several FunctionBehaviors can refer to the same FunctionType. In this case, when a FunctionType has several behaviors, only one behavior shall be active at any given time instant, i.e., no concurrent behaviors are allowed in EAST-ADL functions. For instance we cannot have one active behavior in Simulink and one in Modelica. Both can be referenced in the same function, but at any given time, only one is executable. Conditions such as modes and variability must prevent two behaviors being potentially active at the same time. Note also that FunctionBehaviors are assigned to FunctionTypes and not to FunctionPrototypes. This means that among a set of FunctionPrototypes, which share the same type, behaviors are also shared. However when a FunctionBehavior refer to Modes, which are referred to by different FunctionTriggers, different triggering conditions can be provided among a set of FunctionPrototypes for the same set of behaviors - see FunctionTrigger. In the case where the identified FunctionType is decomposed into parts, the behavior is a specification for the composed behavior of the FunctionType. Semantics: The semantics of FunctionBehavior follows the semantics of the behavioral representation/tool used (for instance SIMULINK, ASCET, etc.). However, in relation to the EAST-ADL model, the FunctionBehavior has synchronous execution semantics: 1. Read inputs from input ports 2. Execute behavior with fixed inputs (run to completion) 3. Provide outputs to output ports The data transfer between the EAST-ADL ports and the FunctionBehavior is representation/tool-specific and considered part of the execution of the FunctionBehavior. Notation: FunctionBehavior appears as a solid-outline rectangle with "Behavior" at the top right. The rectangle contains the name. Extension: Behavior The path to the file or model entity containing the behavior. The type of representation used to describe the behavior. FunctionBehavior represents the behavior of a particular FunctionType - referred to by the association to FunctionType. What is meant by behavior is a transfer function performing some data computation (in case of FlowPort interaction) or an operation that can be called by another function (in case of ClientServer interaction). The representation property indicates the kind of representation used to describe the behavior (see FunctionBehaviorKind). The representation itself (e.g., defined in an external model file) is identified by a URL String in the path property. If the representation is provided in the same model file as the system itself, the path property is not used. It is merely a placeholder for the purpose of containing information about and links to the external behavioral model. FunctionBehavior may refer to execution modes by the association to the element Mode. This is not mandatory; however, when provided, the relation indicates the list of execution Modes in which the FunctionBehavior can potentially be executed (see element Mode). The triggering of a FunctionBehavior is unknown to the behavior. It is defined by FunctionTriggers (see this element). Note that the association between FunctionBehavior and FunctionType is specified as a one-way navigable link from FunctionBehavior to FunctionType: what this means is that the EAST-ADL language specification does not require a FunctionType be aware of the FunctionBehavior it is assigned to. Only the navigation from behavior to function is mandatory; the implementation of a reverse link might however be provided depending on the tool support. Although each FunctionBehavior can refer to at most one FunctionType, note that several FunctionBehaviors can refer to the same FunctionType. In this case, when a FunctionType has several behaviors, only one behavior shall be active at any given time instant, i.e., no concurrent behaviors are allowed in EAST-ADL functions. For instance we cannot have one active behavior in Simulink and one in Modelica. Both can be referenced in the same function, but at any given time, only one is executable. Conditions such as modes and variability must prevent two behaviors being potentially active at the same time. Note also that FunctionBehaviors are assigned to FunctionTypes and not to FunctionPrototypes. This means that among a set of FunctionPrototypes, which share the same type, behaviors are also shared. However when a FunctionBehavior refer to Modes, which are referred to by different FunctionTriggers, different triggering conditions can be provided among a set of FunctionPrototypes for the same set of behaviors - see FunctionTrigger. In the case where the identified FunctionType is decomposed into parts, the behavior is a specification for the composed behavior of the FunctionType. Semantics: The semantics of FunctionBehavior follows the semantics of the behavioral representation/tool used (for instance SIMULINK, ASCET, etc.). However, in relation to the EAST-ADL model, the FunctionBehavior has synchronous execution semantics: 1. Read inputs from input ports 2. Execute behavior with fixed inputs (run to completion) 3. Provide outputs to output ports The data transfer between the EAST-ADL ports and the FunctionBehavior is representation/tool-specific and considered part of the execution of the FunctionBehavior. Notation: FunctionBehavior appears as a solid-outline rectangle with "Behavior" at the top right. The rectangle contains the name. Extension: Behavior The FunctionClientServerInterface is used to specify the operations in FunctionClientServerPorts. Semantics: The operations of the FunctionClientServerInterface are required or provided through the FunctionClientServerPorts typed by the FunctionClientServerInterface. Extension: UML Interface The FunctionClientServerInterface is used to specify the operations in FunctionClientServerPorts. Semantics: The operations of the FunctionClientServerInterface are required or provided through the FunctionClientServerPorts typed by the FunctionClientServerInterface. Extension: UML Interface The FunctionClientServerPort is a FunctionPort for client-server interaction. A number of FunctionClientServerPorts of clientServerType "client" can be connected to one FunctionClientServerPort of clientServerType "server", i.e. when connected the multiplicity for the connection is n to 1 for client and server. Semantics: The FunctionClientServerPort is a FunctionPort for client-server interaction. FunctionClientServerPorts are single buffer overwrite and nonconsumable. Constraints: [1] A FunctionClientServerPort of clientServerType "client" can only be connected to one FunctionClientServerPort of clientServerType "server". Extension: UML Port The FunctionClientServerPort is a FunctionPort for client-server interaction. A number of FunctionClientServerPorts of clientServerType "client" can be connected to one FunctionClientServerPort of clientServerType "server", i.e. when connected the multiplicity for the connection is n to 1 for client and server. Semantics: The FunctionClientServerPort is a FunctionPort for client-server interaction. FunctionClientServerPorts are single buffer overwrite and nonconsumable. Constraints: [1] A FunctionClientServerPort of clientServerType "client" can only be connected to one FunctionClientServerPort of clientServerType "server". Extension: UML Port The FunctionConnector indicates that the connected FunctionPorts exchange signals or client-server requests/responses. A FunctionConnector used to connect ports of parts within an AnalysisFunctionType or DesignFunctionType are called assembly connecors. A FunctionConnector between a port of a part and a port of the AnalysisFunctionType or DesignFunctionType itself is called a delegation connector. Semantics: The FunctionConnector connects a pair of FunctionFlowPorts or FunctionClientServerPorts. If two FunctionFlowPorts are connected, data elements of the type of the output FunctionFlowPort flow from the output FunctionFlowPort to the input FunctionFlowPort. If FunctionClientServerPorts are connected, the client calls the server according to the operations of the interfaces. The FunctionPrototype with the connected port has to be identified by the FunctionConnector as well. The FunctionConnector is normally routed according to the hardware topology and the allocation of source and destination. If there are redundant paths, a FunctionAllocation may be used to prescribe allocation. Constraints: [1] Can connect two FunctionFlowPorts of different directions when this is an assembly FunctionConnector. [2] Can connect two FunctionFlowPorts of the same direction when this is a delegation FunctionConnector. [3] Can connect two ClientServerPorts of different kinds when this is an assembly FunctionConnector. [4] Can connect two ClientServerPorts of the same kind when this is a delegation FunctionConnector. [5] Can connect two FunctionFlowPorts with direction inout. Notation: FunctionConnector is shown as a solid line Extension: UML Connector The FunctionConnector indicates that the connected FunctionPorts exchange signals or client-server requests/responses. A FunctionConnector used to connect ports of parts within an AnalysisFunctionType or DesignFunctionType are called assembly connecors. A FunctionConnector between a port of a part and a port of the AnalysisFunctionType or DesignFunctionType itself is called a delegation connector. Semantics: The FunctionConnector connects a pair of FunctionFlowPorts or FunctionClientServerPorts. If two FunctionFlowPorts are connected, data elements of the type of the output FunctionFlowPort flow from the output FunctionFlowPort to the input FunctionFlowPort. If FunctionClientServerPorts are connected, the client calls the server according to the operations of the interfaces. The FunctionPrototype with the connected port has to be identified by the FunctionConnector as well. The FunctionConnector is normally routed according to the hardware topology and the allocation of source and destination. If there are redundant paths, a FunctionAllocation may be used to prescribe allocation. Constraints: [1] Can connect two FunctionFlowPorts of different directions when this is an assembly FunctionConnector. [2] Can connect two FunctionFlowPorts of the same direction when this is a delegation FunctionConnector. [3] Can connect two ClientServerPorts of different kinds when this is an assembly FunctionConnector. [4] Can connect two ClientServerPorts of the same kind when this is a delegation FunctionConnector. [5] Can connect two FunctionFlowPorts with direction inout. Notation: FunctionConnector is shown as a solid line Extension: UML Connector The FunctionFlowPort is a metaclass for flowports, inspired by the SysML FlowPort. Semantics: FunctionFlowPorts are single buffer overwrite and nonconsumable. FunctionFlowPorts can be connected if their FunctionPort signatures match; i.e.: EADatatypes that are ValueTypes are compatible if * They have the same "dimension". * They have the same "unit". EADatatypes that are RangeableValueTypes are compatible if * The source EADatatype has the same or better "accuracy". * They have the same baseRangeable. * The source EADatatype has the same or smaller "maxValue". * The source EADatatype has the same or higher "minValue". * The source EADatatype has the same or higher "resolution". * They have the same "significantDigits". EADatatypes that are EnumerationValueTypes are compatible if * They have the same baseEnumeration. A FunctionFlowPort with direction=in is called an input FunctionFlowPort: The input FunctionFlowPort indicates that the containing Function requires input data. The EADatatype of this data is defined by the associated EADatatype. The data is sampled at the invocation of the containing entity for discrete Functions. For continuous Functions, the input FunctionFlowPort represents a continuous input connection point. The input FunctionFlowPort declares a reception point of data. It represents a single element buffer, which is overridden with the latest data. The type of the data is defined by the associated EADatatype. A FunctionFlowPort with direction=out is called an output FunctionFlowPort: The output FunctionFlowPort indicates that the containing Function provides output data. The EADatatype of this data is defined by the associated EADatatype. The data is sent at the completion of the containing entity for discrete Functions. For continuous Functions, the output FunctionFlowPort represents a (time-)continuous output connection point. The output FunctionFlowPort declares a transmission point of data. The type of the data is defined by the associated EADatatype. Extension: UML Port, specialization of SysML::FlowPort The FunctionFlowPort is a metaclass for flowports, inspired by the SysML FlowPort. Semantics: FunctionFlowPorts are single buffer overwrite and nonconsumable. FunctionFlowPorts can be connected if their FunctionPort signatures match; i.e.: EADatatypes that are ValueTypes are compatible if * They have the same "dimension". * They have the same "unit". EADatatypes that are RangeableValueTypes are compatible if * The source EADatatype has the same or better "accuracy". * They have the same baseRangeable. * The source EADatatype has the same or smaller "maxValue". * The source EADatatype has the same or higher "minValue". * The source EADatatype has the same or higher "resolution". * They have the same "significantDigits". EADatatypes that are EnumerationValueTypes are compatible if * They have the same baseEnumeration. A FunctionFlowPort with direction=in is called an input FunctionFlowPort: The input FunctionFlowPort indicates that the containing Function requires input data. The EADatatype of this data is defined by the associated EADatatype. The data is sampled at the invocation of the containing entity for discrete Functions. For continuous Functions, the input FunctionFlowPort represents a continuous input connection point. The input FunctionFlowPort declares a reception point of data. It represents a single element buffer, which is overridden with the latest data. The type of the data is defined by the associated EADatatype. A FunctionFlowPort with direction=out is called an output FunctionFlowPort: The output FunctionFlowPort indicates that the containing Function provides output data. The EADatatype of this data is defined by the associated EADatatype. The data is sent at the completion of the containing entity for discrete Functions. For continuous Functions, the output FunctionFlowPort represents a (time-)continuous output connection point. The output FunctionFlowPort declares a transmission point of data. The type of the data is defined by the associated EADatatype. Extension: UML Port, specialization of SysML::FlowPort The FunctionPowerPort is a FunctionPort for denoting the physical interactions between environment and sensing/actuation functions. Semantics: The FunctionPowerPort conserves physical variables in a dynamic process. The typing CompositeDatatype owns two EADatatypePrototypes called Across and Through, representing the exchanged physical variables of the FunctionPowerPort. In two or more directly connected function power ports, the Across variables always get the same value and the Through variables always sum up to zero. Constraints: [1] The owner of a FunctionPowerPort is either a FunctionalDevice, a HardwareFunctionType, or a FunctionType for environment [2] Two connected FunctionPowerPort must have the same Datatype. [3] The typing Datatype shall have two datatypePrototypes called Across and Through, with Datatypes that are consistent and representing the variables of the PowerPort. Extension: UML Port The FunctionPowerPort is a FunctionPort for denoting the physical interactions between environment and sensing/actuation functions. Semantics: The FunctionPowerPort conserves physical variables in a dynamic process. The typing CompositeDatatype owns two EADatatypePrototypes called Across and Through, representing the exchanged physical variables of the FunctionPowerPort. In two or more directly connected function power ports, the Across variables always get the same value and the Through variables always sum up to zero. Constraints: [1] The owner of a FunctionPowerPort is either a FunctionalDevice, a HardwareFunctionType, or a FunctionType for environment [2] Two connected FunctionPowerPort must have the same Datatype. [3] The typing Datatype shall have two datatypePrototypes called Across and Through, with Datatypes that are consistent and representing the variables of the PowerPort. Extension: UML Port FunctionTrigger represents the triggering parameters necessary to define the execution of an identified FunctionType or FunctionPrototype. When referring to a FunctionType, a FunctionTrigger applies to all FunctionPrototypes of the given type. When referring to a FunctionPrototype, the trigger is only valid for this particular FunctionPrototype. Triggering is defined either as event-driven or time-driven - depending on the property triggerPolicy. If set to TIME, the timing constraint is defined with an event constraint associated with the Function's or FunctionPrototype's EventFunction. The function event refers to the activation of the function. If set to EVENT, one or several ports of the Function trigger the function, i.e., activate the function. In both cases, a triggerCondition is provided in the form of a Boolean expression that must evaluate to true for the function to execute. The triggerCondition syntax and grammar is unspecified. In addition, a FunctionTrigger may refer to a list of Modes in which the trigger will be considered as potentially active. As of FunctionBehaviors may also refer to Modes, it is possible to arrange various function configurations for which different sets of triggers and behaviors are active. And this, at various levels of granularity, either with a type-wise scope (by referring to a FunctionType) or specifically at prototype level (by referring to a FunctionPrototype). Note that several FunctionTriggers may be assigned to the same Function (Type or Prototype), for instance to define alternative trigger conditions and/or timing constraints. Semantics: Association Mode defines in which modes the trigger is active. The FunctionBehavior referenced by the FunctionTrigger is invoked when the FunctionTrigger is active. If multiple ports are referenced, it is sufficient if one is active before triggering. If AND semantics is desired, this is stated in the trigger condition. It is possible to have multiple triggers on a function, e.g., a slow period complemented with an event trigger allows fast response when needed but a minimal execution rate. Constraints: [1] The port association must not be empty when triggerPolicy is EVENT. [2] The port association is empty when triggerPolicy is TIME. [3] Function and functionPrototype are mutually exclusive associations. A FunctionTrigger either identifies a FunctionType or a FunctionPrototype as its target function, but not both. [4] Only FunctionFlowPort of FlowDirection=in shall be referred to in the association port and at least one of them shall trigger the function Extension: Class A Boolean expression that must evaluate to true for this Function to execute. This value is used both for time and event triggered elementary functions. Defines the triggering policy, either EVENT or TIME. The function event refers to the activation of the function. If set to EVENT, one or several ports of the Function triggers the function, i.e., activates the function. FunctionTrigger represents the triggering parameters necessary to define the execution of an identified FunctionType or FunctionPrototype. When referring to a FunctionType, a FunctionTrigger applies to all FunctionPrototypes of the given type. When referring to a FunctionPrototype, the trigger is only valid for this particular FunctionPrototype. Triggering is defined either as event-driven or time-driven - depending on the property triggerPolicy. If set to TIME, the timing constraint is defined with an event constraint associated with the Function's or FunctionPrototype's EventFunction. The function event refers to the activation of the function. If set to EVENT, one or several ports of the Function trigger the function, i.e., activate the function. In both cases, a triggerCondition is provided in the form of a Boolean expression that must evaluate to true for the function to execute. The triggerCondition syntax and grammar is unspecified. In addition, a FunctionTrigger may refer to a list of Modes in which the trigger will be considered as potentially active. As of FunctionBehaviors may also refer to Modes, it is possible to arrange various function configurations for which different sets of triggers and behaviors are active. And this, at various levels of granularity, either with a type-wise scope (by referring to a FunctionType) or specifically at prototype level (by referring to a FunctionPrototype). Note that several FunctionTriggers may be assigned to the same Function (Type or Prototype), for instance to define alternative trigger conditions and/or timing constraints. Semantics: Association Mode defines in which modes the trigger is active. The FunctionBehavior referenced by the FunctionTrigger is invoked when the FunctionTrigger is active. If multiple ports are referenced, it is sufficient if one is active before triggering. If AND semantics is desired, this is stated in the trigger condition. It is possible to have multiple triggers on a function, e.g., a slow period complemented with an event trigger allows fast response when needed but a minimal execution rate. Constraints: [1] The port association must not be empty when triggerPolicy is EVENT. [2] The port association is empty when triggerPolicy is TIME. [3] Function and functionPrototype are mutually exclusive associations. A FunctionTrigger either identifies a FunctionType or a FunctionPrototype as its target function, but not both. [4] Only FunctionFlowPort of FlowDirection=in shall be referred to in the association port and at least one of them shall trigger the function Extension: Class The abstract metaclass FunctionType abstracts the function component types that are used to model the functional structure, which is distinguished from the implementation of component types using AUTOSAR. The syntax of FunctionTypes is inspired from the concept of Block from SysML. FunctionBehavior and FunctionTrigger in the Behavior package are associated to a FunctionType. Semantics: The FunctionType abstracts the function component types that are used to model the functional structure on AnalysisLevel and DesignLevel. Leaf functions of an EAST-ADL function hierarchy are called elementary Functions. Elementary Functions have synchronous execution semantics: 1. Read inputs 2. Execute (duration: Execution time) 3. Write outputs Execution is defined by a behavior that acts as a transfer function. Subclasses of the abstract class FunctionType add their own semantics. If a behavior is attached to the FunctionType, the execution semantic for a discrete elementary FunctionType complies with the run-to-completion semantic. This has the following implications: 1. Input that arrives at the input FunctionPorts after execution begins will be ignored until the next execution cycle. 2. If more than one input value arrives per FunctionPort before execution begins, the last value will override all previous ones in the public part of the input FunctionPort (single element buffers for input). 3. The local part of a FunctionPort does not change its value during execution of the behavior. 4. During an execution cycle, only one output value can be sent per FunctionPort. If consecutive output values are produced on the same FunctionPort during a single execution cycle, the last value will override all previous ones on the output FunctionPort (single element buffers for output). 5. Output will not be available at an output FunctionPort before execution ends. 6. Elementary FunctionTypes may not produce any side effects (i.e., all data passes the FunctionPorts). Constraints: [1] Elementary FunctionTypes shall not have parts. Notation: The FunctionType is shown as a solid-outline rectangle containing the name, with its FunctionPorts or PortGroups on the perimeter. Contained entities may be shown with their FunctionConnectors (White-box view). Extension: UML Class, specialization of SysML::Block True, when this type must not have any parts. The FunctionalDevice represents an abstract sensor or actuator that encapsulates sensor/actuator dynamics and the interfacing software. The FunctionalDevice is the interface between the electronic architecture and the environment (connected by ClampConnectors, see the Environment chapter). As such, it is a transfer function between the AnalysisFunction and the physical entity that it measures or actuates. A Realization dependency can be used for traceability from LocalDeviceManagers in the DesignLevel and Sensors/Actuators in the hardware design architecture that are represented by the FunctionalDevice. Semantics: The behavior associated with the FunctionalDevice is the transfer function between the environment model representing the environment and an AnalysisFunction. The transfer function represents the sensor or actuator and its interfacing hardware and software (connectors, electronics, in/out interface, driver software, and application software). Constraints: No additional constraints. Extension: Class, specialization of SysML::Block FunctionalSafetyConcept represents the set of functional safety requirements that together fulfils a SafetyGoal in accordance with ISO 26262. To comply with the SafetyGoals, the FunctionalSafetyConcept specifies the basic safety mechanisms and safety measures in the form of functional safety requirements. Constraints: [1] Contained functionalSafetyRequirements shall not be of type SafetyGoal. Semantics: The collection of requirements in the FunctionalSafetyConcept defines the requirements necessary to make the Item safe. The requirements are abstract and do not specify technical details. FunctionalSafetyConcept represents the set of functional safety requirements that together fulfils a SafetyGoal in accordance with ISO 26262. To comply with the SafetyGoals, the FunctionalSafetyConcept specifies the basic safety mechanisms and safety measures in the form of functional safety requirements. Constraints: [1] Contained functionalSafetyRequirements shall not be of type SafetyGoal. Semantics: The collection of requirements in the FunctionalSafetyConcept defines the requirements necessary to make the Item safe. The requirements are abstract and do not specify technical details. The GenericConstraint denotes a property, requirement, or a validation result for the identified element of the model. The kind of GenericConstraint is described as one of the GenericConstraintKind literals. Example: If the attribute genericConstraintType is cableLength, the genericConstraintValue could be "5 meters" (value of a numerical datatype with unit "meters"). Semantics: The GenericConstraint does not describe what is classically referred to as a "design" constraint but has the role of a property, requirement, or a validation result. It is a requirement if this GenericConstraint refines a Requirement (by the Refine relationship). The GenericConstraint is a validation result if it realizes a VVActualOutcome, it is an intended validation result if it realizes a VVIntendedOutcome, and in other cases it denotes a property. Extension: Class The type of the GenericConstraint, see GenericConstraintKind. The genericConstraintValue is the concrete value of the GenericConstraint according to the semantics of the genericConstraintType. The GenericConstraint denotes a property, requirement, or a validation result for the identified element of the model. The kind of GenericConstraint is described as one of the GenericConstraintKind literals. Example: If the attribute genericConstraintType is cableLength, the genericConstraintValue could be "5 meters" (value of a numerical datatype with unit "meters"). Semantics: The GenericConstraint does not describe what is classically referred to as a "design" constraint but has the role of a property, requirement, or a validation result. It is a requirement if this GenericConstraint refines a Requirement (by the Refine relationship). The GenericConstraint is a validation result if it realizes a VVActualOutcome, it is an intended validation result if it realizes a VVIntendedOutcome, and in other cases it denotes a property. Extension: Class The collection of generic constraints. This collection can be used across the EAST-ADL abstraction levels. Semantics: GenericConstraintSet is a container element for GenericConstraints and has no specific semantics. The collection of generic constraints. This collection can be used across the EAST-ADL abstraction levels. Semantics: GenericConstraintSet is a container element for GenericConstraints and has no specific semantics. Claim is based on Grounds (evidences) - specific facts about a precise situation that clarify and make good the Claim. Ground represents statements that explain how the SafetyCase Ground clarifies and make good the Claim. Ground has associations to the entities that are the evidences in the SafetyCase. Semantics: Ground (evidence) is information that supports the Claim that the safety requirements and objectives are met i.e. used as the basis of the safety argument. Solution is evidence that the sub-goals have been met. This can be achieved by decomposing all goal claims to a level where direct reference to evidences was considered possible. The evidences address different aspects of the goal. It always has to be ensured that each of them is defensible enough to confirm the underlying statement. Claim is based on Grounds (evidences) - specific facts about a precise situation that clarify and make good the Claim. Ground represents statements that explain how the SafetyCase Ground clarifies and make good the Claim. Ground has associations to the entities that are the evidences in the SafetyCase. Semantics: Ground (evidence) is information that supports the Claim that the safety requirements and objectives are met i.e. used as the basis of the safety argument. Solution is evidence that the sub-goals have been met. This can be achieved by decomposing all goal claims to a level where direct reference to evidences was considered possible. The evidences address different aspects of the goal. It always has to be ensured that each of them is defensible enough to confirm the underlying statement. Appears as part of a HardwareComponentType and is itself typed by a HardwareComponentType. This allows for a reference to the occurrence of a HardwareComponentType when it acts as a part. The purpose is to support the definition of hierarchical structures, and to reuse the same type of Hardware at several places. For example, a wheel speed sensor may occur at all four wheels, but it has a single definition. Semantics: The HardwareComponentPrototype represents an occurrence of a hardware element, according to the type of the HardwareComponentPrototype. Notation: Shall be shown in the same style as the class specified as type, however it shall be clear that this is a part. Extension: Property Appears as part of a HardwareComponentType and is itself typed by a HardwareComponentType. This allows for a reference to the occurrence of a HardwareComponentType when it acts as a part. The purpose is to support the definition of hierarchical structures, and to reuse the same type of Hardware at several places. For example, a wheel speed sensor may occur at all four wheels, but it has a single definition. Semantics: The HardwareComponentPrototype represents an occurrence of a hardware element, according to the type of the HardwareComponentPrototype. Notation: Shall be shown in the same style as the class specified as type, however it shall be clear that this is a part. Extension: Property The HardwareComponentType represents hardware element on an abstract level, allowing preliminary engineering activities related to hardware. Semantics: The HardwareComponentType is a structural entity that defines a part of an electrical architecture. Through its ports it can be connected to electrical sources and sinks. Its logical behavior, the transfer function, may be defined in a HardwareFunctionType referencing the HardwareComponentType. This is typically connected through its ports to the environment model to participate in the end-to-end behavioral definition of a function. Extension: Class The HardwareComponentType represents hardware element on an abstract level, allowing preliminary engineering activities related to hardware. Semantics: The HardwareComponentType is a structural entity that defines a part of an electrical architecture. Through its ports it can be connected to electrical sources and sinks. Its logical behavior, the transfer function, may be defined in a HardwareFunctionType referencing the HardwareComponentType. This is typically connected through its ports to the environment model to participate in the end-to-end behavioral definition of a function. Extension: Class Hardware connectors represent wires that electrically connect the hardware components through its ports. Semantics: The connector joins the two referenced ports electrically, with a resistance defined by the resistance attribute. Extension: Connector Hardware connectors represent wires that electrically connect the hardware components through its ports. Semantics: The connector joins the two referenced ports electrically, with a resistance defined by the resistance attribute. Extension: Connector The HardwareFunctionType is the transfer function for the identified HardwareComponentType or a specification of an intended transfer function. HardwareFunctionType types DesignFunctionPrototypes in the FunctionalDesignArchitecture. The Such DesignFunctionPrototypes are typically at the end of the ClampConnectors on DesignLevel. DesignFunctionPrototypes typed by HardwareFunctionType may be allocated to HardwareComponents in which case the HardwareFunctionType must match the HardwareFunctionType of the target HardwareComponent. Typically, the same HardwareFunctionType types the prototype that is allocated to its target HardwareComponent. HardwareFunctionTypes are typically transfer functions of sensors, actuators, amplifiers and other peripherals with a fixed transfer function. Thus, HardwareFunctionTypes are generally not defined for ECUNodes. Constraints: [1] A DesignFunctionPrototype typed by a HardwareFunctionType shall be connected to the EnvironmentModel via ClampConnectors and to BSWFunctions via FunctionConnectors. Semantics: The HardwareFunctionType is the transfer function for the associated hardware components such as sensors, actuators, amplifiers, etc or a specification of an intended transfer function. A DesignFunctionPrototype typed by a HardwareFunctionType allocated to Sensors or Actuatorsis the interfacing element to the plant model. Extension: UML Class, specialization of SysML::Block The HardwareFunctionType is the transfer function for the identified HardwareComponentType or a specification of an intended transfer function. HardwareFunctionType types DesignFunctionPrototypes in the FunctionalDesignArchitecture. The Such DesignFunctionPrototypes are typically at the end of the ClampConnectors on DesignLevel. DesignFunctionPrototypes typed by HardwareFunctionType may be allocated to HardwareComponents in which case the HardwareFunctionType must match the HardwareFunctionType of the target HardwareComponent. Typically, the same HardwareFunctionType types the prototype that is allocated to its target HardwareComponent. HardwareFunctionTypes are typically transfer functions of sensors, actuators, amplifiers and other peripherals with a fixed transfer function. Thus, HardwareFunctionTypes are generally not defined for ECUNodes. Constraints: [1] A DesignFunctionPrototype typed by a HardwareFunctionType shall be connected to the EnvironmentModel via ClampConnectors and to BSWFunctions via FunctionConnectors. Semantics: The HardwareFunctionType is the transfer function for the associated hardware components such as sensors, actuators, amplifiers, etc or a specification of an intended transfer function. A DesignFunctionPrototype typed by a HardwareFunctionType allocated to Sensors or Actuatorsis the interfacing element to the plant model. Extension: UML Class, specialization of SysML::Block HardwarePin represents electrical connection points in the hardware architecture. Depending on modeling style, the actual wire or a logical connection can be considered. Semantics: Hardware pin represents an electrical connection point. Extension: Port The direction of current through the pin. The internal impedance in Ohms to ground of the component as seen through this pin. Indicates that the pin is connected to ground. The maximal power in watts that can be provided by this pin or that is consumed. The maximal voltage in Volts provided by the pin. Shall not be defined if isGround=TRUE. The HardwarePinGroup provides means to organize hardware pins to improve readability of the component interface and connectors between components. Tools may show the set of ports in the pin group as a single pin, and join connectors that go between pins in pin groups to a single line. Semantics: A HardwarePinGroup has no semantics, but is only a grouping mechanism that may affect visualization and port operations in tools. Extension: Class The HardwarePinGroup provides means to organize hardware pins to improve readability of the component interface and connectors between components. Tools may show the set of ports in the pin group as a single pin, and join connectors that go between pins in pin groups to a single line. Semantics: A HardwarePinGroup has no semantics, but is only a grouping mechanism that may affect visualization and port operations in tools. Extension: Class The Hazard metaclass represents a condition or state in the system that may contribute to accidents. The Hazard is caused by malfunctioning behavior of E/E safety-related systems including interaction of these systems. The Hazard does not address hazards such as electric shock, fire, smoke, heat, radiation, toxicity, flammability, reactivity, corrosion, release of energy, and similar hazards unless directly caused by malfunctioning behavior of safety related electrical/electronic systems. Semantics: The Hazard element represents a condition or state in the system that may contribute to accidents. The associated malfunction identifies the FeatureFlaw that corresponds to the Hazard. Notation: The Hazard is shown as a solid-outline rectangle with "Haz" at the top right. It contains the name of the Hazard and optionally the name of the source entity. Extension: UML::Class The Hazard metaclass represents a condition or state in the system that may contribute to accidents. The Hazard is caused by malfunctioning behavior of E/E safety-related systems including interaction of these systems. The Hazard does not address hazards such as electric shock, fire, smoke, heat, radiation, toxicity, flammability, reactivity, corrosion, release of energy, and similar hazards unless directly caused by malfunctioning behavior of safety related electrical/electronic systems. Semantics: The Hazard element represents a condition or state in the system that may contribute to accidents. The associated malfunction identifies the FeatureFlaw that corresponds to the Hazard. Notation: The Hazard is shown as a solid-outline rectangle with "Haz" at the top right. It contains the name of the Hazard and optionally the name of the source entity. Extension: UML::Class The HazardousEvent metaclass represents a combination of a Hazard and a specific situation, the latter being characterized by operating mode and operational situation in terms of a particular use case, environment and traffic. Semantics: The HazardousEvent denotes a combination of a Hazard and an operational situation. The controllability and severity attributes shall be consistent with the operational situation and operational scenario, and the Exposure shall reflect the likelihood of the operational situation and scenario. Notation: The HazardousEvent is shown as a solid-outline rectangle with "Haz" at the top right. It contains the name of the HazardousEvent and optionally the name of the source entity. Extension: UML::Class The classificationAssumptions attribute denotes assumptions concerning the classification of the Hazard. The controllability by the driver or other traffic participants defined by the enumeration C0, C1, C2 or C3 in accordance with ISO26262. The probability of exposure of the operational situations defined by the probability attributes E1, E2, E3 or E4 in accordance with ISO26262. The ASIL-Level shall be determined for each hazardous event using the estimation parameters in accordance with ISO26262. The severity of potential harm defined by the severity attributes S0, S1, S2 or S3 in accordance with ISO26262. The HazardousEvent metaclass represents a combination of a Hazard and a specific situation, the latter being characterized by operating mode and operational situation in terms of a particular use case, environment and traffic. Semantics: The HazardousEvent denotes a combination of a Hazard and an operational situation. The controllability and severity attributes shall be consistent with the operational situation and operational scenario, and the Exposure shall reflect the likelihood of the operational situation and scenario. Notation: The HazardousEvent is shown as a solid-outline rectangle with "Haz" at the top right. It contains the name of the HazardousEvent and optionally the name of the source entity. Extension: UML::Class IOHardwarePin represents an electrical connection point for digital or analog I/O. Semantics: The IOHardwarePin represents an electrical pin or connection point. Notation: IOHardwarePin is shown as a solid square with an IO inside. Its name may appear outside the square. kind defines whether the IOHardwarePort is digital, analog or PWM (Pulse Width Modulated). IOHardwarePin represents an electrical connection point for digital or analog I/O. Semantics: The IOHardwarePin represents an electrical pin or connection point. Notation: IOHardwarePin is shown as a solid square with an IO inside. Its name may appear outside the square. Instances of this class can be referred to by their identifier (within the namespace borders). In addition to this, Identifiables are objects which contribute significantly to the overall structure of an AUTOSAR description. In particular, Identifiables might contain Identifiables. This element assigns a category to the parent element. The category is intended to specialize the usage and/or the content identifiable object. Such a specialization may also impose particular semantic constraints on the entire substructure (not only the identifiable itself). xml.sequenceOffset="-50" Instances of this class can be referred to by their identifier (within the namespace borders). In addition to this, Identifiables are objects which contribute significantly to the overall structure of an AUTOSAR description. In particular, Identifiables might contain Identifiables. 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" The ImplementationLevel represents the software architecture and the hardware architecture of the electrical/electronic system in the vehicle. The ImplementationLevel is defined by the AUTOSAR SystemArchitecture and SoftwareArchitecture. For example, functions of the FDA will be realized by AUTOSAR SW-Components in the ImplementationLevel. Traceability is supported from implementation level elements (AUTOSAR) to upper level elements by Realization relationships. Semantics: The ImplementationLevel is the representation of the vehicle electrical/electronic system on the implementation abstraction level. It corresponds to the system implementation in Software and Hardware. Notation: The ImplementationLevel is shown as a solid-outline rectangle containing the name. Extension: Class The ImplementationLevel represents the software architecture and the hardware architecture of the electrical/electronic system in the vehicle. The ImplementationLevel is defined by the AUTOSAR SystemArchitecture and SoftwareArchitecture. For example, functions of the FDA will be realized by AUTOSAR SW-Components in the ImplementationLevel. Traceability is supported from implementation level elements (AUTOSAR) to upper level elements by Realization relationships. Semantics: The ImplementationLevel is the representation of the vehicle electrical/electronic system on the implementation abstraction level. It corresponds to the system implementation in Software and Hardware. Notation: The ImplementationLevel is shown as a solid-outline rectangle containing the name. Extension: Class Include is a specialization of the Relationship and represents a relationship between two UseCases, implying that the behavior of the included UseCase is inserted into the behavior of the including UseCase. The including UseCase may only depend on the result (value) of the included UseCase. This value is obtained as a result of the execution of the included UseCase. Note that the included UseCase is not optional and is always required for the including UseCase to execute correctly. Semantics: The Include relationship identifies an addition UseCase, which is inserted in the including UseCase. Include is a specialization of the Relationship and represents a relationship between two UseCases, implying that the behavior of the included UseCase is inserted into the behavior of the including UseCase. The including UseCase may only depend on the result (value) of the included UseCase. This value is obtained as a result of the execution of the included UseCase. Note that the included UseCase is not optional and is always required for the including UseCase to execute correctly. Semantics: The Include relationship identifies an addition UseCase, which is inserted in the including UseCase. InputSynchronizationConstraint is a language entity that expresses a timing constraint on the input synchronization among the set of stimulus events. Basically, the InputSynchronizationConstraint looks from the response event(s) into the past to the stimuli events. All stimulus events must occur within a given sliding window. The sliding window itself may occur within a time interval specified by means of a minimum and maximum distance from the response event(s). Semantics: The parameters of InputSynchronizationConstraint, see TimingConstraint, constrain the time from the first stimulus until last stimulus (i.e., maximum skew between these stimuli). Parameter width defines the sliding window, i.e. the maximum distance between the first and the last stimulus event shall be smaller or equal to width. Furthermore, the minimum and maximum distances of the sliding window to the response event(s) is defined by the parameters upper and lower (from TimingConstraint). In this case, upper denotes the maximal allowed distance from the last response event to the first stimulus event (looking backwards in time), and lower denotes the minimal allowed distance from the first response event to the last stimulus event (looking backwards in time). A join point is identified by the response event in the scope EventChain. Constraints: [1] The set of FunctionFlowPorts referenced by the events should contain only FlowPorts with direction = in. The rationale for this is that the events shall relate to data on FunctionFlowPorts which is considered (or shall be) temporally consistent. [2] The semantics of this constraint requires that there is more than one stimulus Event in the scope EventChain (each refering to a different FlowPort with direction = in). [3] The parameters 'nominal' and 'jitter' (from DelayConstraint) are not relevant for InputSynchronizationConstraint. Extension: Class InputSynchronizationConstraint is a language entity that expresses a timing constraint on the input synchronization among the set of stimulus events. Basically, the InputSynchronizationConstraint looks from the response event(s) into the past to the stimuli events. All stimulus events must occur within a given sliding window. The sliding window itself may occur within a time interval specified by means of a minimum and maximum distance from the response event(s). Semantics: The parameters of InputSynchronizationConstraint, see TimingConstraint, constrain the time from the first stimulus until last stimulus (i.e., maximum skew between these stimuli). Parameter width defines the sliding window, i.e. the maximum distance between the first and the last stimulus event shall be smaller or equal to width. Furthermore, the minimum and maximum distances of the sliding window to the response event(s) is defined by the parameters upper and lower (from TimingConstraint). In this case, upper denotes the maximal allowed distance from the last response event to the first stimulus event (looking backwards in time), and lower denotes the minimal allowed distance from the first response event to the last stimulus event (looking backwards in time). A join point is identified by the response event in the scope EventChain. Constraints: [1] The set of FunctionFlowPorts referenced by the events should contain only FlowPorts with direction = in. The rationale for this is that the events shall relate to data on FunctionFlowPorts which is considered (or shall be) temporally consistent. [2] The semantics of this constraint requires that there is more than one stimulus Event in the scope EventChain (each refering to a different FlowPort with direction = in). [3] The parameters 'nominal' and 'jitter' (from DelayConstraint) are not relevant for InputSynchronizationConstraint. Extension: Class The InternalBinding is the private, internal ConfigurationDecisionModel of the ConfigurableContainer. It defines how the internal, lower-level variability of the ConfigurableContainer is bound, i.e. configured, depending on a given configuration of the ConfigurableContainer's public feature model. This way, the binding of this internal variability is encapsulated and hidden behind the public feature model, which serves as a variability-related interface. Note that for this use case, the source and target feature models need not be defined explicitly because they are deduced implicitly: the ConfigurableContainer's public feature model serves as the (single) target feature model, and the source feature models are deduced from the ConfigurableContainer's internal variability (esp. other, lower-level ConfigurableContainers which are contained). For a definition of the precise meaning of 'internal variability' (also called variable content) refer to the documentation of meta-class ConfigurableContainer. Semantics: See description. The InternalFault metaclass represents the particular internal conditions of the target component/system that are of particular concern for its fault/failure definition. Semantics: The system anomaly represented by an InternalFault, which when activated, can cause errors and failures of the target element. Extension: UML::Part / UML::Event The Item entity identifies the scope of safety information and the safety assessment, i.e. the part of the system onto which the ISO26262 related information applies. Safety analyses are carried out on the basis of an item definition and the safety concepts are derived from it. Semantics: Item represents the scope of safety information and the safety assessment through its reference to one or several Features. Extension: UML::Class The Item entity identifies the scope of safety information and the safety assessment, i.e. the part of the system onto which the ISO26262 related information applies. Safety analyses are carried out on the basis of an item definition and the safety concepts are derived from it. The Item entity identifies the scope of safety information and the safety assessment, i.e. the part of the system onto which the ISO26262 related information applies. Safety analyses are carried out on the basis of an item definition and the safety concepts are derived from it. Semantics: Item represents the scope of safety information and the safety assessment through its reference to one or several Features. Extension: UML::Class The LocalDeviceManager represents a DesignFunction that act as a manager or functional interface to Sensors, Actuators and other devices. It is responsible for translating between the electrical/logical interface of the device, as provided by a BasicSoftwareFunction, and the physical interface of the device. For example, consider a temperature sensor with voltage output. The HardwareFunctionType defines the transfer from temperature to voltage. A BasicSoftwareFunction relays the voltage from the microcontroller's I/O. The role of the LocalDeviceManager is now to translate from voltage to temperature value, taking into account the sensor's characteristics such as nonlinearities, calibration, etc. The resulting temperature is available to the other DesignFunctions. By separating the device specific part from the middleware and ECU specific parts, it is possible to systematically change interface function together with the device. The role of the LocalDeviceManager is to act as an interface between the electrical output of Sensors or electrical input of Actuators and the physical quantity of those devices. Semantics: The LocalDeviceManager encapsulates the device-specific or functional parts of a Sensor or Actuator, device, etc. interface. Constraints: [1] A DesignFunctionPrototype typed by a LocalDeviceManager shall be allocated to the same ECU node as the device that it manages is connected to. [2] A LocalDeviceManager shall interface BSWFunctions and DesignFunctions. Extension: Class, specialization of SysML::Block The LogicalBus represents logical communication channels. It serves as an allocation target for connectors, i.e. the data exchanged between functions in the FunctionalDesignArchitecture. Semantics: The LogicalBus represents a logical connection that carries data from any sender to all receivers. Senders and receivers are identified by the wires of the LogicalBus, i.e. the associated HardwareConnectors. The available busSpeed represents the maximum amount of useful data that can be carried. The busSpeed has already deducted speed reduction resulting from frame overhead, timing effects, etc. Extension: Class The net bus speed in bits per second. Used to assess communication delay and schedulability on the bus. Note that scheduling details are not represented in the model. The type of bus scheduling assumed. The LogicalBus represents logical communication channels. It serves as an allocation target for connectors, i.e. the data exchanged between functions in the FunctionalDesignArchitecture. Semantics: The LogicalBus represents a logical connection that carries data from any sender to all receivers. Senders and receivers are identified by the wires of the LogicalBus, i.e. the associated HardwareConnectors. The available busSpeed represents the maximum amount of useful data that can be carried. The busSpeed has already deducted speed reduction resulting from frame overhead, timing effects, etc. Extension: Class A mission is a use or operation for which a system is intended by one or more stakeholders to meet some set of objectives. [IEEE 1471] Modes are a way to introduce various configurations in the system to account for different states of the system, or of a hardware entity, or an application. The use of modes can be used to filter different views of the model. Modes are characterized by a Boolean condition provided as a String, which evaluates to true when the Mode is active. As far as behavior is concerned, Modes enable the logical organisation of a set of triggers and behaviors over a set of functions. Modes are referred to by both FunctionTriggers and FunctionBehaviors (see FunctionTrigger and FunctionBehavior). Modes can be further organized in mutually exclusive sets with ModeGroups (see that element). Semantics: The Mode is active if and only if the condition is true. A Boolean expression that characterizes the Mode, it evaluates to true when the Mode is active. The syntax and grammar of this expression is unspecified. Modes are a way to introduce various configurations in the system to account for different states of the system, or of a hardware entity, or an application. The use of modes can be used to filter different views of the model. Modes are characterized by a Boolean condition provided as a String, which evaluates to true when the Mode is active. As far as behavior is concerned, Modes enable the logical organisation of a set of triggers and behaviors over a set of functions. Modes are referred to by both FunctionTriggers and FunctionBehaviors (see FunctionTrigger and FunctionBehavior). Modes can be further organized in mutually exclusive sets with ModeGroups (see that element). Semantics: The Mode is active if and only if the condition is true. ModeGroups serve as containers of Modes. The Modes in a ModeGroup are mutually exclusive. This means that only one Mode of a ModeGroup is active at any point in time. A precondition in the form of a Boolean expression is assigned to the ModeGroup so that ModeGroups can be switched on and off as a whole. Semantics: The ModeGroup defines a set of modes of which exactly one is active if precondition is true and otherwise none is active. A Boolean expression that evaluates to true when the ModeGroup is active. ModeGroups serve as containers of Modes. The Modes in a ModeGroup are mutually exclusive. This means that only one Mode of a ModeGroup is active at any point in time. A precondition in the form of a Boolean expression is assigned to the ModeGroup so that ModeGroups can be switched on and off as a whole. Semantics: The ModeGroup defines a set of modes of which exactly one is active if precondition is true and otherwise none is active. The metaclass MultiLevelReference gives the possibility to establish reference links between model elements. Such a reference may be established between two elements when both of them are slightly different but one element is newer and originates from the other element. With such reference, it is possible to keep track of changes (by humans and also computational) in with respect to the original elements. Moreover, it is possible to take over the changes into the original. In EAST-ADL, the Multi-Level concept is primarily used for Feature Modeling and Requirements Interchange. Semantics: MultiLevelReference relates model elements that have an informal specialization relation according to the MulitiLevel concept. The metaclass MultiLevelReference gives the possibility to establish reference links between model elements. Such a reference may be established between two elements when both of them are slightly different but one element is newer and originates from the other element. With such reference, it is possible to keep track of changes (by humans and also computational) in with respect to the original elements. Moreover, it is possible to take over the changes into the original. In EAST-ADL, the Multi-Level concept is primarily used for Feature Modeling and Requirements Interchange. Semantics: MultiLevelReference relates model elements that have an informal specialization relation according to the MulitiLevel concept. Node represents the computer nodes of the embedded electrical/electronic system. Nodes consist of processor(s) and may be connected to sensors, actuators and other ECUs via a BusConnector. Node denotes an electronic control unit that acts as a computing element executing Functions. In case a single CPU ECU is represented, it is sufficient to have a single, non-hierarchical Node. Semantics: The Node element represents an ECU, i.e. an Electronic Control Unit, and an allocation target of FunctionPrototypes. The Node executes its allocated FunctionPrototypes at the specified executionRate. The executionRate denotes how many execution seconds of an allocated functionPrototype´s execution time are processed in each real-time second. Actual execution time is thus found by dividing the parameters of the ExecutionTimeConstraint with executionRate. Example: If an ECU is 25% faster than a standard ECU (e.g., in a certain context, execution times are given assuming a nominal speed of 100 MHz; our CPU is then 125 MHz), the executionRate is 1.25. An execution time of 5 ms would then become 4 ms on this ECU. Notation: Node is shown as a solid-outline rectangle with Node at the top right. The rectangle contains the name, and its ports or port groups on the perimeter. ExecutionRate is used to compute an approximate execution time. A nominal execution time divided by executionRate provides the actual execution time to be used e.g. for timing analysis in feasibility studies. The size in Bytes of the Node's Non-Volatile memory (ROM, NRAM, EPROM, etc.). The size in Bytes of the Node's Volatile memory (RAM) Node represents the computer nodes of the embedded electrical/electronic system. Nodes consist of processor(s) and may be connected to sensors, actuators and other ECUs via a BusConnector. Node denotes an electronic control unit that acts as a computing element executing Functions. In case a single CPU ECU is represented, it is sufficient to have a single, non-hierarchical Node. Semantics: The Node element represents an ECU, i.e. an Electronic Control Unit, and an allocation target of FunctionPrototypes. The Node executes its allocated FunctionPrototypes at the specified executionRate. The executionRate denotes how many execution seconds of an allocated functionPrototype´s execution time are processed in each real-time second. Actual execution time is thus found by dividing the parameters of the ExecutionTimeConstraint with executionRate. Example: If an ECU is 25% faster than a standard ECU (e.g., in a certain context, execution times are given assuming a nominal speed of 100 MHz; our CPU is then 125 MHz), the executionRate is 1.25. An execution time of 5 ms would then become 4 ms on this ECU. Notation: Node is shown as a solid-outline rectangle with Node at the top right. The rectangle contains the name, and its ports or port groups on the perimeter. The Operation is the provided/required operation of a FunctionClientServerInterface. It can specify its return values and arguments by EADatatypePrototypes. Semantics: The Operation is the provided/required operation of a FunctionClientServerInterface. Extension: UML Operation The Operation is the provided/required operation of a FunctionClientServerInterface. It can specify its return values and arguments by EADatatypePrototypes. Semantics: The Operation is the provided/required operation of a FunctionClientServerInterface. Extension: UML Operation An operational situation is a state, condition or scenario in the environment that may influence the vehicle. The Operational Situation may be further detailed by a functional definition in the EnvironmentModel. Semantics: OperationalSituation represent a state, condition or scenario that is external to the vehicle. OutputSynchronizationConstraint is a language entity that expresses a timing constraint on the output synchronization among the set of response events. Basically, the OutputSynchronizationConstraint looks from the stimulus event(s) into the future to the response events. All response events must occur within a given sliding window. The sliding window itself may occur within a time interval specified by means of a minimum and maximum distance from the stimulus event(s). Semantics: The parameters of OutputSynchronizationConstraint, see TimingConstraints, constrain the time from the first response until last response (i.e., maximum skew between these responses). Parameter width defines the sliding window, i.e. the maximum distance between the first and the last response event shall be smaller or equal to width. Furthermore, the minimum and maximum distances of the sliding window to the stimulus event(s) is defined by the parameters upper and lower (from TimingConstraint). In this case, upper denotes the maximal allowed distance from the first stimulus event to the first response event, and lower denotes the minimal allowed distance from the last stimulus event to the first response event. A fork point is identified by the stimulus event in the scope EventChain. Constraints: [1] The set of FunctionFlowPorts referenced by the events should contain only OutFlowPorts. The rationale for this is that the events shall relate to data on FunctionFlowPorts which is considered (or shall be) temporally consistent. [2] The semantics of this constraint require that there is more than one response Events in the scope EventChain. [3] The parameters 'nominal' and 'jitter' (from DelayConstraint) are not relevant for OutputSynchronizationConstraint. Extension: Class OutputSynchronizationConstraint is a language entity that expresses a timing constraint on the output synchronization among the set of response events. Basically, the OutputSynchronizationConstraint looks from the stimulus event(s) into the future to the response events. All response events must occur within a given sliding window. The sliding window itself may occur within a time interval specified by means of a minimum and maximum distance from the stimulus event(s). Semantics: The parameters of OutputSynchronizationConstraint, see TimingConstraints, constrain the time from the first response until last response (i.e., maximum skew between these responses). Parameter width defines the sliding window, i.e. the maximum distance between the first and the last response event shall be smaller or equal to width. Furthermore, the minimum and maximum distances of the sliding window to the stimulus event(s) is defined by the parameters upper and lower (from TimingConstraint). In this case, upper denotes the maximal allowed distance from the first stimulus event to the first response event, and lower denotes the minimal allowed distance from the last stimulus event to the first response event. A fork point is identified by the stimulus event in the scope EventChain. Constraints: [1] The set of FunctionFlowPorts referenced by the events should contain only OutFlowPorts. The rationale for this is that the events shall relate to data on FunctionFlowPorts which is considered (or shall be) temporally consistent. [2] The semantics of this constraint require that there is more than one response Events in the scope EventChain. [3] The parameters 'nominal' and 'jitter' (from DelayConstraint) are not relevant for OutputSynchronizationConstraint. Extension: Class Statement of quantities (e.g., temperature) in the behaviors to be fulfilled by a vehicle feature, a system artifact, or an environment entity. While input/output parameters target the I/O ports of system functions, internal parameters target directly system functions. Constraints: Each parameter in the parameter constraints of function behaviors references either one function type owning such function behaviors or one function port of the same function type. Semantics: A parameter represents an in-, out-, or local-quantity to be processed. It can describe a piece of application or event data within an E/E system, or a variable in the environment such as a monitored/controlled plant variable. Each parameter is typed by an EADataType for specifying the related meta-information like unit, valid range, required accuracy, etc. Statement of quantities (e.g., temperature) in the behaviors to be fulfilled by a vehicle feature, a system artifact, or an environment entity. While input/output parameters target the I/O ports of system functions, internal parameters target directly system functions. Constraints: Each parameter in the parameter constraints of function behaviors references either one function type owning such function behaviors or one function port of the same function type. Semantics: A parameter represents an in-, out-, or local-quantity to be processed. It can describe a piece of application or event data within an E/E system, or a variable in the environment such as a monitored/controlled plant variable. Each parameter is typed by an EADataType for specifying the related meta-information like unit, valid range, required accuracy, etc. Statements of the conditions of individual parameters in relation to the operations of behaviors to be fulfilled by a vehicle feature, a system artifact, or an environment entity. Constraints: A parameter condition is applied to at least one parameter or one parameter condition. Semantics: A parameter condition characterizes the particular state of parameter(s) in nominal and erroneous operating situations. For example, parameter conditions can be used to describe the expected value ranges of a monitored environmental quantity in specific vehicle control scenarios. Parameter conditions can be used as a basis for defining the states of parameters or their combinations (e.g., the establishment of certain input and output mapping, event to output mapping) during different operation situations. For a computation behavior, parameter conditions can be used to specify its pre-/post-conditions and invariants that must be true before, after, and during the execution. EAST-ADL does not define logic and arithmetic operators for the expressions of parameter conditions but would support the definitions in future extensions. The description of parameter condition. Statements of the conditions of individual parameters in relation to the operations of behaviors to be fulfilled by a vehicle feature, a system artifact, or an environment entity. Constraints: A parameter condition is applied to at least one parameter or one parameter condition. Semantics: A parameter condition characterizes the particular state of parameter(s) in nominal and erroneous operating situations. For example, parameter conditions can be used to describe the expected value ranges of a monitored environmental quantity in specific vehicle control scenarios. Parameter conditions can be used as a basis for defining the states of parameters or their combinations (e.g., the establishment of certain input and output mapping, event to output mapping) during different operation situations. For a computation behavior, parameter conditions can be used to specify its pre-/post-conditions and invariants that must be true before, after, and during the execution. EAST-ADL does not define logic and arithmetic operators for the expressions of parameter conditions but would support the definitions in future extensions. Statement of the expected parameters and parameter conditions in the operations of behaviors to be fulfilled by a vehicle feature, a system artifact, or an environment entity. Semantics: Computation constraints refine textual requirements and provide detailed specifications about the quantities and their particular conditions in the operation of behaviors. Statement of the expected parameters and parameter conditions in the operations of behaviors to be fulfilled by a vehicle feature, a system artifact, or an environment entity. Semantics: Computation constraints refine textual requirements and provide detailed specifications about the quantities and their particular conditions in the operation of behaviors. The [Concrete] PatternEventConstraint describes that an event occurs following a known pattern. Semantics: PatternEventConstraint characterizes the occurrence pattern of its associated event. The attribute descriptions provides more specific semantics: period, minimumInterArrivalTime, occurrence jitter. The [Concrete] PatternEventConstraint describes that an event occurs following a known pattern. Semantics: PatternEventConstraint characterizes the occurrence pattern of its associated event. The attribute descriptions provides more specific semantics: period, minimumInterArrivalTime, occurrence jitter. The PeriodicEventConstraint describes that an event occurs periodically. Semantics: PeriodicEventConstraint characterizes the occurrence of the associated event. The attributes jitter, period and minimumInterArrivalTime provides additional semantics. The PeriodicEventConstraint describes that an event occurs periodically. Semantics: PeriodicEventConstraint characterizes the occurrence of the associated event. The attributes jitter, period and minimumInterArrivalTime provides additional semantics. The PortGroup represents several FunctionPorts grouped into one. All FunctionPorts that are part of a PortGroup are graphically represented as a single FunctionPort. The PortGroup has no semantic meaning except that it makes graphical representation of the connected FunctionPorts easier to read, and provides a means to logically organize several FunctionPorts into one group. Connectors are still connected to the contained FunctionPorts, but tool support may simplify connections by allowing semiautomatic or automatic connection to all FunctionPorts of a PortGroup. Note that the term "PortGroup" is also used by AADL. Semantics: The PortGroup provides the means to organize FunctionPorts and FunctionConnectors. It does not add semantics. In the model, the FunctionPorts contained in the PortGroup are connected as individual FunctionPorts. Constraints: [1] The FunctionPorts in a PortGroup must all be of the same component; all FunctionPorts in a PortGroup must be of the same kind (FunctionFlowPort with same EADirectionKind or FunctionClientServerPort with same ClientServerKind). Notation: FunctionConnectors connected to FunctionPorts of a PortGroup are graphically collapsed into a single line. The PortGroup is rendered as its contained ports, but with a double outline. Extension: Class The PortGroup represents several FunctionPorts grouped into one. All FunctionPorts that are part of a PortGroup are graphically represented as a single FunctionPort. The PortGroup has no semantic meaning except that it makes graphical representation of the connected FunctionPorts easier to read, and provides a means to logically organize several FunctionPorts into one group. Connectors are still connected to the contained FunctionPorts, but tool support may simplify connections by allowing semiautomatic or automatic connection to all FunctionPorts of a PortGroup. Note that the term "PortGroup" is also used by AADL. Semantics: The PortGroup provides the means to organize FunctionPorts and FunctionConnectors. It does not add semantics. In the model, the FunctionPorts contained in the PortGroup are connected as individual FunctionPorts. Constraints: [1] The FunctionPorts in a PortGroup must all be of the same component; all FunctionPorts in a PortGroup must be of the same kind (FunctionFlowPort with same EADirectionKind or FunctionClientServerPort with same ClientServerKind). Notation: FunctionConnectors connected to FunctionPorts of a PortGroup are graphically collapsed into a single line. The PortGroup is rendered as its contained ports, but with a double outline. Extension: Class PowerHardwarePin represents a pin that is primarily intended for power supply, either providing or consuming energy. Semantics: A PowerHardwarePin is primarily intended to be a power supply. The direction attribute of the pin defines whether it is providing or consuming energy. Notation: PowerHardwarePin is shown as a solid square with PWR inside. Its name may appear outside the square. PowerSupply represents a hardware element that supplies power. Semantics: PowerSupply denotes a power source that may be active (e.g., a battery) or passive (main relay). Notation: PowerSupply is shown as a solid-outline rectangle with "PWR" at the top right. The rectangle contains the name, and its ports or port groups on the perimeter. Indicates if the PowerSupply is active or passive. PowerSupply represents a hardware element that supplies power. Semantics: PowerSupply denotes a power source that may be active (e.g., a battery) or passive (main relay). Notation: PowerSupply is shown as a solid-outline rectangle with "PWR" at the top right. The rectangle contains the name, and its ports or port groups on the perimeter. The PrecedenceConstraint represents a particular constraint applied on the execution sequence of functions. Semantics: The semantics for the PrecedenceConstraint metaclass is to define an association relationship between Functions, indicating the association relationship such that all predecessors have completed before the successors are started. Note: Without a precedence relation, Functions are executed according to their data dependencies, if these are uni-directional. For bi-directional data dependencies, execution order is not defined unless the PrecedenceDependency relationship is used. Notation: PrecedenceConstraint is shown as a dashed arrow with "Precedes" next to it. It points from preceeding to the successive entity. Extension: The PrecedenceConstraint extends UML2 metaclass Class and Dependency. The PrecedenceConstraint represents a particular constraint applied on the execution sequence of functions. Semantics: The semantics for the PrecedenceConstraint metaclass is to define an association relationship between Functions, indicating the association relationship such that all predecessors have completed before the successors are started. Note: Without a precedence relation, Functions are executed according to their data dependencies, if these are uni-directional. For bi-directional data dependencies, execution order is not defined unless the PrecedenceDependency relationship is used. Notation: PrecedenceConstraint is shown as a dashed arrow with "Precedes" next to it. It points from preceeding to the successive entity. Extension: The PrecedenceConstraint extends UML2 metaclass Class and Dependency. PrivateContent is a marker class that marks the artifact element denoted by association privateElement as private, i.e., it will not be presented to the outside of the containing ConfigurableContainer. Refer to the documentation of meta-class ConfigurableContainer for a detailed explanation of how ConfigurableContainer and PrivateContent work together. Constraints: [1] Identifies either one FunctionPrototype or one FunctionPort or one FunctionConnector or one HardwareComponentPrototype or one HardwarePort or one ClampConnector. Semantics: Marks the element identified by association privateElement as private. Otherwise the elements visibility defaults to public. Extension: Class PrivateContent is a marker class that marks the artifact element denoted by association privateElement as private, i.e., it will not be presented to the outside of the containing ConfigurableContainer. Refer to the documentation of meta-class ConfigurableContainer for a detailed explanation of how ConfigurableContainer and PrivateContent work together. Constraints: [1] Identifies either one FunctionPrototype or one FunctionPort or one FunctionConnector or one HardwareComponentPrototype or one HardwarePort or one ClampConnector. Semantics: Marks the element identified by association privateElement as private. Otherwise the elements visibility defaults to public. Extension: Class The problem statement represents a brief statement summarizing the problem being solved which gives the opportunity to establish traceability from artifacts created later, for example to provide rationales to design decisions or trade-off analysis. The problem statement could be extended with further modeling of dependencies between different problems and deduction of root problems The impact of the problem The brief problem statement. This redefines the text attribute in TraceableSpecification. Lists some key benefits of a successful solution. The problem statement represents a brief statement summarizing the problem being solved which gives the opportunity to establish traceability from artifacts created later, for example to provide rationales to design decisions or trade-off analysis. The problem statement could be extended with further modeling of dependencies between different problems and deduction of root problems The ProcessFaultPrototype metaclass represents the anomalies that the target component/system can have due to design or implementation flaws (e.g., incorrect requirements, buffer size configuration, scheduling, etc.). Semantics: The ProcessFaultPrototype represent general internal anomalies of a component that are introduced during design and implementation. Extension: UML::Part / UML::Event The problem positioning represents an overall brief statement summarizing, at the highest level, the unique position the product intends to fill in the marketplace which gives the opportunity to establish traceability from artifacts created later, for example to provide rationales to design decisions or trade-off analysis. Positioning is assumed to belong to a particular context, typically a system, but also for a smaller part of a system. Brief statement of key benefit; that is, the compelling need for the product. Brief statement of the key capabilities Brief statement of primary competitive alternative Brief statement of primary differentiation Brief statement of target customers. The problem positioning represents an overall brief statement summarizing, at the highest level, the unique position the product intends to fill in the marketplace which gives the opportunity to establish traceability from artifacts created later, for example to provide rationales to design decisions or trade-off analysis. Positioning is assumed to belong to a particular context, typically a system, but also for a smaller part of a system. QualityRequirements or non-functional requirements are used to introduce externally visible properties of the system considered as a whole. They specify criteria that can be used to judge the operation of a system. As opposed to a functional requirement specifying what a system is supposed to do, the non-functional requirements define how a system is supposed to be. The attribute qualityRequirementType allows a more specific classification. Semantics: QualityRequirement element represent a requirement which is non-functional. Extension: Class, specializes Requirement QualityRequirements or non-functional requirements are used to introduce externally visible properties of the system considered as a whole. They specify criteria that can be used to judge the operation of a system. As opposed to a functional requirement specifying what a system is supposed to do, the non-functional requirements define how a system is supposed to be. The attribute qualityRequirementType allows a more specific classification. Semantics: QualityRequirement element represent a requirement which is non-functional. Extension: Class, specializes Requirement The QuantitativeSafetyConstraint metaclass represents the quantitative integrity constraints on a fault or failure. Thus, the system has the same or better performance with respect to the constrained fault or failure, and depending on the role this is either a requirement or a property. Semantics: A QuantitativeSafetyConstraint provides information about the probabilistic estimates of target faults/failures, further specified by the failureRate and repairRate attribute. Extension: (see ADLTraceableSpecification) failureRate denotes the number of failures per unit time, i.e. the density of probability of failure divided by probability of survival for a hardware element (ISO26262 definition). For exponential failure distributions it is often denoted by lambda. repairRate denotes the number of repairs per unit time. For exponential repair distributions it is often denoted by mu. The QuantitativeSafetyConstraint metaclass represents the quantitative integrity constraints on a fault or failure. Thus, the system has the same or better performance with respect to the constrained fault or failure, and depending on the role this is either a requirement or a property. Semantics: A QuantitativeSafetyConstraint provides information about the probabilistic estimates of target faults/failures, further specified by the failureRate and repairRate attribute. Extension: (see ADLTraceableSpecification) An extra allocated part of the EAST-ADL System Model that contains Requirement Specific Data (Container, Reqs etc...) from RIF Import and RIF Export. In the context of requirement engineering, and considering the possibility of importing/exporting requirement related data via RIF, the feature uuid will be used to check that two elements are semantically the same and thus should stay referenced together via a Multi-Level reference link. Requirement data to be imported/exported will be put into an RIFArea. Requirement data elements which are not inside an RIFArea but which have semantically equal element in the RIFAreas (such elements have the same uuid value) will be connected with the appropriate elements in the RIFArea using Multi-Level reference links. Semantics: RIFArea is an abstract class. Semantics is defined on the specializations. Contains (clones of) requirement specific data to be exported in RIF format. Semantics: RIFExportArea contains Requirements that are subject to export in a requirement interchange with external tools. Contains requirement specific data to be imported from an external RIF file. When an element is imported from an external source the uuid will be taken from the given external exchange data file, because the identifier is globally unique and should not be changed anywhere. Semantics: RIFImportArea contains Requirements that are subject to import in a requirement interchange with external tools. The RangeableValueType is a specific ValueType applicable for RangeableDatatypes. It describes the accuracy, resolution, and the significant digits of the baseRangeable datatypes. Semantics: The RangeableValueType adds the ability to describe the accuracy, resolution, and the significant digits of the baseRangeable datatype. Notation: The datatype RangeableValueType is denoted using the rectangle symbol with keyword «Datatype RangeableValueType». Extension: UML Datatype, SysML ValueType The accuracy of the data (e.g., the FunctionFlowports input or output). Example: An accuracy of 0.5 of the temperature means a communicated value of 19 represents an actual temperature of 19 +/- 0.5 degrees. The resolution of the data expressed as the size of the minimum difference between data values. Example: A resolution of 0.1 means that temperature may be represented in increments of 0.1 degrees. The number of significant digits, e.g., for the speed case: if the speed is a one digit number (e.g., 5 km/h), then this digit is significant, if the speed is a two digits number (e.g., 15 km/h), then the first digit is significant (here: 1), if the speed is a three digits number (e.g., 215 km/h), then the first two digits are significant (here: 21). Significant means here, that the respective digits are reliable. The RangeableValueType is a specific ValueType applicable for RangeableDatatypes. It describes the accuracy, resolution, and the significant digits of the baseRangeable datatypes. Semantics: The RangeableValueType adds the ability to describe the accuracy, resolution, and the significant digits of the baseRangeable datatype. Notation: The datatype RangeableValueType is denoted using the rectangle symbol with keyword «Datatype RangeableValueType». Extension: UML Datatype, SysML ValueType Rationale represents a justification to any model element. Semantics: Rationale represents a justification to any model element. ReactionConstraint is used to impose a timing constraint on an event chain in order to specify bounds for reacting on the occurrence of a stimulus or stimuli. The intention of this constraint is to look forward in time. Compare AgeTimingConstraint. Semantics: ReactionConstraint characterizes the reaction delay of the response event compared to the stimulus event. The Realization is a relationship which relates two or more elements across boundaries of the EAST-ADL abstraction levels. It identifies an element that serves as a specification within this realization relationship and on the other side it identifies an element that is supposed to realize this specification on a lower abstraction level or an implementation. Constraints: [1] The realizedBy elements shall be on a lower abstraction level than the realized relements. [2] The realizedBy or realized elements shall be structural or behavioral Semantics: The Realization is a relationship which identifies one or several abstract elements that are realized by one or several concrete elements. The realizedBy elements together represents a realization of the group of realized elements and is collectively responsible for meeting the specification of the realized elements, including (derivations of) its requirements. Notation: A Realization relationship is shown as a dashed line with a triangular arrowhead at the end that corresponds to the realized entity. The entity at the tail of the arrow (the realizing EAElement or the realizing ARElement) depends on the entity at the arrowhead (the realized EAElement). Extension: Realization Temporary change in the profile (to overcome Papyrus current limitation): - added extension towards Dependency The Realization is a relationship which relates two or more elements across boundaries of the EAST-ADL abstraction levels. It identifies an element that serves as a specification within this realization relationship and on the other side it identifies an element that is supposed to realize this specification on a lower abstraction level or an implementation. Constraints: [1] The realizedBy elements shall be on a lower abstraction level than the realized relements. [2] The realizedBy or realized elements shall be structural or behavioral Semantics: The Realization is a relationship which identifies one or several abstract elements that are realized by one or several concrete elements. The realizedBy elements together represents a realization of the group of realized elements and is collectively responsible for meeting the specification of the realized elements, including (derivations of) its requirements. Notation: A Realization relationship is shown as a dashed line with a triangular arrowhead at the end that corresponds to the realized entity. The entity at the tail of the arrow (the realizing EAElement or the realizing ARElement) depends on the entity at the arrowhead (the realized EAElement). Extension: Realization Temporary change in the profile (to overcome Papyrus current limitation): - added extension towards Dependency Instances of this class can be referred to by their identifier (while adhering to namespace borders). This specifies an identifying shortName for the object. It needs to be unique within its context and is intended for humans but even more for technical reference. xml.enforceMinMultiplicity="true";xml.sequenceOffset="-100" The Refine is a relationship metaclass, which signifies a dependency relationship between Requirements and EAElements, showing the relationship when a client EAElement refines the supplier Requirement. Semantics: The Refine metaclass signifies a refined requirement/refined by relationship between a Requirement and an EAElement, where the modification of the supplier Requirement may impact the refining client EAElement. The Refine metaclass implies the semantics that the refining client EAElement is not complete, without the supplier Requirement. Constraints: [1] The property refinedBy must not have the types Requirement or RequirementContainer. Notation: A Refine relationship is shown as a dashed arrow between the Requirements and EAElement. The entity at the tail of the arrow (the refining EAElement) depends on the Requirement at the arrowhead (the refined Requirement). Extension: specializes UML2 stereotype Refine, which extends Dependency. Temporary change in the profile (to overcome bug in Eclipse/UML2 concerning standard stereotypes) - added extension towards Dependency The Refine is a relationship metaclass, which signifies a dependency relationship between Requirements and EAElements, showing the relationship when a client EAElement refines the supplier Requirement. Semantics: The Refine metaclass signifies a refined requirement/refined by relationship between a Requirement and an EAElement, where the modification of the supplier Requirement may impact the refining client EAElement. The Refine metaclass implies the semantics that the refining client EAElement is not complete, without the supplier Requirement. Constraints: [1] The property refinedBy must not have the types Requirement or RequirementContainer. Notation: A Refine relationship is shown as a dashed arrow between the Requirements and EAElement. The entity at the tail of the arrow (the refining EAElement) depends on the Requirement at the arrowhead (the refined Requirement). Extension: specializes UML2 stereotype Refine, which extends Dependency. Temporary change in the profile (to overcome bug in Eclipse/UML2 concerning standard stereotypes) - added extension towards Dependency The Requirement represents a capability or condition that must (or should) be satisfied. A Requirement can also specify an informal constraint, e.g. "The development of the component X must be according to the standard Y", or "The realization of this function as a software component must adhere to the scope and external interface as specified by this function". It will be used to unite the common properties of specific requirement types. A Requirement may either be directly associated with a Context (by inheriting from TraceableSpecification) or it may be included in a RequirementContainer, which represents a larger unit or module of specification information. The traceability between Requirement entities and other specification or design entities will be ensured by the relationship dependencies described in the Infrastructure part of this specification. Semantics: The string in the text attribute inherited from TraceableSpecification is the capability or condition that applies to the Identifiable that is associated to the Requirement through the Satisfy relation. Notation: Requirement is shown as a solid rectangle with Req top right and its name. Extension: To specialize SysML::Requirement, which extends Class Specifies the language used for the requirement statement. Reference to possible external file containing the requirement statement. The Requirement represents a capability or condition that must (or should) be satisfied. A Requirement can also specify an informal constraint, e.g. "The development of the component X must be according to the standard Y", or "The realization of this function as a software component must adhere to the scope and external interface as specified by this function". It will be used to unite the common properties of specific requirement types. A Requirement may either be directly associated with a Context (by inheriting from TraceableSpecification) or it may be included in a RequirementContainer, which represents a larger unit or module of specification information. The traceability between Requirement entities and other specification or design entities will be ensured by the relationship dependencies described in the Infrastructure part of this specification. Semantics: The string in the text attribute inherited from TraceableSpecification is the capability or condition that applies to the Identifiable that is associated to the Requirement through the Satisfy relation. Notation: Requirement is shown as a solid rectangle with Req top right and its name. Extension: To specialize SysML::Requirement, which extends Class RequirementContainer represents a larger unit or module of specification information. It is used to bundle several Requirements which are semantically related to each other. Also, a RequirementContainer structure will be used for structuring requirement specification objects (Requirements, Rationals etc.). Thus, to preserve the ordering of requirement specification objects, the order of child containers is very important here. Furthermore, the RequirementContainer allows the introduction of additional user attribute definitions by way of UserAttributeElementTypes or UserAttributeTemplates, which are valid only locally inside this RequirementContainer. These are additional in that they are used in addition to the user attribute definitions which are provided globally for the entire EAST-ADL repository. An EAST-ADL system model may contain a forest of RequirementContainers (see parent child relationship). Only non-root RequirementContainers that have a parentContainer are allowed to reference a RequirementSpecificationObject. The RequirementContainer with its parent child containment relationship and the reference to RequirementSpecificationObject is the basic element for structuring requirement information into a forest structure. Constraints: [1] Only non-root RequirementContainers (parentContainer must be set) which have a parentContainer are allowed to reference a RequirementSpecificationObject. Semantics: RequirementsContainers organizes Requirements in groups. The semantics of the group is user-defined. Notation: RequirementContainer is shown as a solid-outline rectangle containing the name. Contained entities may also be shown inside (White-box view) Extension: Package RequirementContainer represents a larger unit or module of specification information. It is used to bundle several Requirements which are semantically related to each other. Also, a RequirementContainer structure will be used for structuring requirement specification objects (Requirements, Rationals etc.). Thus, to preserve the ordering of requirement specification objects, the order of child containers is very important here. Furthermore, the RequirementContainer allows the introduction of additional user attribute definitions by way of UserAttributeElementTypes or UserAttributeTemplates, which are valid only locally inside this RequirementContainer. These are additional in that they are used in addition to the user attribute definitions which are provided globally for the entire EAST-ADL repository. An EAST-ADL system model may contain a forest of RequirementContainers (see parent child relationship). Only non-root RequirementContainers that have a parentContainer are allowed to reference a RequirementSpecificationObject. The RequirementContainer with its parent child containment relationship and the reference to RequirementSpecificationObject is the basic element for structuring requirement information into a forest structure. Constraints: [1] Only non-root RequirementContainers (parentContainer must be set) which have a parentContainer are allowed to reference a RequirementSpecificationObject. Semantics: RequirementsContainers organizes Requirements in groups. The semantics of the group is user-defined. Notation: RequirementContainer is shown as a solid-outline rectangle containing the name. Contained entities may also be shown inside (White-box view) Extension: Package RequirementsLink represents a relation between two or more Requirements. Source and target Requirements of the relation are distinguished, which means that the relation is directed (from source to target). If such a distinction does not make sense, then use a RequirementsRelationGroup instead. The standard case will be a relation with one source and one target Requirement. However, it is possible to have several source and/or several target Requirements so that general relations can be expressed with instances of this metaclass. The semantic of a concrete Requirement relation can be provided by the modeler. In particular, three ways are conceivable: (1) The user attributes of the relation can be used to specify its meaning, for example with a user attribute called "relationType" which is set to values such as "needs" or "excludes". (2) The UserAttributeElementType can be used. Certain types will be used for certain relation semantics. (3) RequirementsRelationGroups can be used, i.e. all relations with an "excludes" meaning are put in one relation group and all with a "needs" meaning are put in another. Semantics: The RequirementsLink defines a relation from a set of source and target requirements. The isBidirectional attribute defines whether the relation is bidirectional. The semantics of the relation is user-defined. When set to true, the semantic relation represented by this instance of RequirementRelation does not only apply to the direction from source to target (as always) but also in the opposite direction. Note that this means that the relation becomes directed in both directions but NOT undirected. To express an undirected association use a RequirementsRelationGroup. RequirementsLink represents a relation between two or more Requirements. Source and target Requirements of the relation are distinguished, which means that the relation is directed (from source to target). If such a distinction does not make sense, then use a RequirementsRelationGroup instead. The standard case will be a relation with one source and one target Requirement. However, it is possible to have several source and/or several target Requirements so that general relations can be expressed with instances of this metaclass. The semantic of a concrete Requirement relation can be provided by the modeler. In particular, three ways are conceivable: (1) The user attributes of the relation can be used to specify its meaning, for example with a user attribute called "relationType" which is set to values such as "needs" or "excludes". (2) The UserAttributeElementType can be used. Certain types will be used for certain relation semantics. (3) RequirementsRelationGroups can be used, i.e. all relations with an "excludes" meaning are put in one relation group and all with a "needs" meaning are put in another. Semantics: The RequirementsLink defines a relation from a set of source and target requirements. The isBidirectional attribute defines whether the relation is bidirectional. The semantics of the relation is user-defined. The collection of requirements, their relationships, and use cases. This collection can be done across the EAST-ADL abstraction levels. Semantics: The ReuirementsModel is a container element for requirement-related elements. The collection of requirements, their relationships, and use cases. This collection can be done across the EAST-ADL abstraction levels. Semantics: The ReuirementsModel is a container element for requirement-related elements. This is a placeholder for all objects which are not Requirements (such as Rational, Explanations, Related Material etc.). For example, an element of type RequirementsRelatedInformation, which is a rational of an element of type Requirement, will directly succeed this requirement as a sibling element (see structuring of requirement elements via RequirementContainer). Semantics: This metaclass can be used to represent information. This is not a requirement, but is related to requirements, and is often provided together with a set of requirements in a requirements specification. RequirementsRelationGroup represents a group of relations between Requirements. Semantics: RequirementsRelationGroup represents a group of RequirementsRelations. The semantics of this grouping is defined by the user. RequirementsRelationGroup represents a group of relations between Requirements. Semantics: RequirementsRelationGroup represents a group of RequirementsRelations. The semantics of this grouping is defined by the user. ReuseMetaInformation represents the description information needed in the context of reuse. For example a specific entity is only a short-time solution that is not intended to be reused. Also a specific entity can only be reused for specific model ranges (that are not reflected in the product model). Semantics: The ReuseMetaInformation represents information that explains if and how the respective entity can be reused. Extension: Class The reuse information is stored in this attribute. This Boolean attributes just says whether the owning VariableElement itself can essentially be reused or not. Specific information or constraints on reuse are in the information attribute. ReuseMetaInformation represents the description information needed in the context of reuse. For example a specific entity is only a short-time solution that is not intended to be reused. Also a specific entity can only be reused for specific model ranges (that are not reflected in the product model). Semantics: The ReuseMetaInformation represents information that explains if and how the respective entity can be reused. Extension: Class SafetyCase represents a safety case that communicates a clear, comprehensive and defensible argument that a system is acceptably safe to operate in a given context. Safety Cases are used in safety related systems, where failures can lead to catastrophic or at least dangerous consequences. Semantics: The SafetyCase element is a container element for warrant, type and claim that together represent evidence of safety for the system or item in its context. Description of how the SafetyCase Warrant (argument) relates to, and depends upon, information from other viewpoints. Safety case life cycle stage (preliminary, interim or operational) SafetyCase represents a safety case that communicates a clear, comprehensive and defensible argument that a system is acceptably safe to operate in a given context. Safety Cases are used in safety related systems, where failures can lead to catastrophic or at least dangerous consequences. Semantics: The SafetyCase element is a container element for warrant, type and claim that together represent evidence of safety for the system or item in its context. The SafetyConstraint metaclass represents the qualitative integrity constraints on a fault or failure. Thus, the system has the same or better performance with respect to the constrained fault or failure, and depending on the role this is either a requirement or a property. Semantics: A SafetyConstraint defines qualitative bounds on the constrainedFaultFailure in terms of safety integrity level, asilValue. Depending on role, the SafetyConstraint may define a required or an actual safety integrity level. Extension: (see ADLTraceableSpecification) The ASIL level of the target fault or failure. The SafetyConstraint metaclass represents the qualitative integrity constraints on a fault or failure. Thus, the system has the same or better performance with respect to the constrained fault or failure, and depending on the role this is either a requirement or a property. Semantics: A SafetyConstraint defines qualitative bounds on the constrainedFaultFailure in terms of safety integrity level, asilValue. Depending on role, the SafetyConstraint may define a required or an actual safety integrity level. Extension: (see ADLTraceableSpecification) SafetyGoal represents the top-level safety requirement defined in ISO26262. Its purpose is to define how to avoid its associated HazardousEvents, or reduce the risk associated with the hazardous event to an acceptable level. The SafetyGoal is defined through one or several associated requirement elements. An ASIL shall be assigned to each SafetyGoal, to represent the integrity level at which the SafetyGoal must be met. Similar SafetyGoals can be combined into one SafetyGoal. If different ASILs are assigned to similar SafetyGoals, the highest ASIL shall be assigned to the combined SafetyGoal. For every SafetyGoal, a safe state should be defined, either textually or by referencing a specific mode. The safe state is a system state to be maintained or to be reached when a potential source of its hazardous event is detected. Semantics: SafetyGoal represents a safety Goal according to ISO26262. Requirements define the SafetyGoal, and HazardousEvents identify the responsibility of each SafetyGoal. hazardClassification defines the integrity classification of the SafetyGoal, and safeStates may be defined by a string or formalized through associated Modes. Notation: SafetyGoal is a box with text SafetyGoal at the top left. Extension: Class For every SafetyGoal, a safe state should be defined, in order to declare a system state to be maintained or to be reached when the failure is detected and so to allow a failure mitigation action without any violation of the associated SafetyGoal. SafetyGoal represents the top-level safety requirement defined in ISO26262. Its purpose is to define how to avoid its associated HazardousEvents, or reduce the risk associated with the hazardous event to an acceptable level. The SafetyGoal is defined through one or several associated requirement elements. An ASIL shall be assigned to each SafetyGoal, to represent the integrity level at which the SafetyGoal must be met. Similar SafetyGoals can be combined into one SafetyGoal. If different ASILs are assigned to similar SafetyGoals, the highest ASIL shall be assigned to the combined SafetyGoal. For every SafetyGoal, a safe state should be defined, either textually or by referencing a specific mode. The safe state is a system state to be maintained or to be reached when a potential source of its hazardous event is detected. Semantics: SafetyGoal represents a safety Goal according to ISO26262. Requirements define the SafetyGoal, and HazardousEvents identify the responsibility of each SafetyGoal. hazardClassification defines the integrity classification of the SafetyGoal, and safeStates may be defined by a string or formalized through associated Modes. Notation: SafetyGoal is a box with text SafetyGoal at the top left. Extension: Class The Satisfy is a relationship metaclass, which signifies the relationship between a Requirement and an element intended to satisfy the Requirement. Semantics: The Satisfy metaclass signifies a satisfied requirement/satisfied by relationship between a set of Requirements and a set of satisfying entities, where the modification of the supplier Requirements may impact the satisfying client entities. The Satisfy metaclass implies the semantics that the satisfying client entities are not complete without the supplier Requirement. Constraints: [1] The EAElement in the association satisfiedBy may not be a Requirement or RequirementContainer. [2] An element of type Satisfy is only allowed to have associations to either elements of type UseCase (see satisfiedUseCase) or elements of type Requirement (see satisfiedRequirement). Not both at the same time! Notation: A Satisfy relationship is shown as a dashed line with an arrowhead at the end that corresponds to the satisfied Requirement or UseCaseUseCase. The entity at the tail of the arrow (the satisfying EAElement or the satisfying ARElement) depends on the entity at the arrowhead (the satisfied Requirement or UseCaseUseCase). Extension: To specialize SysML::Satisfy, which extends Realization. Temporary change in the profile (to overcome Papyrus current limitation): - added extension towards Dependency The Satisfy is a relationship metaclass, which signifies the relationship between a Requirement and an element intended to satisfy the Requirement. Semantics: The Satisfy metaclass signifies a satisfied requirement/satisfied by relationship between a set of Requirements and a set of satisfying entities, where the modification of the supplier Requirements may impact the satisfying client entities. The Satisfy metaclass implies the semantics that the satisfying client entities are not complete without the supplier Requirement. Constraints: [1] The EAElement in the association satisfiedBy may not be a Requirement or RequirementContainer. [2] An element of type Satisfy is only allowed to have associations to either elements of type UseCase (see satisfiedUseCase) or elements of type Requirement (see satisfiedRequirement). Not both at the same time! Notation: A Satisfy relationship is shown as a dashed line with an arrowhead at the end that corresponds to the satisfied Requirement or UseCaseUseCase. The entity at the tail of the arrow (the satisfying EAElement or the satisfying ARElement) depends on the entity at the arrowhead (the satisfied Requirement or UseCaseUseCase). Extension: To specialize SysML::Satisfy, which extends Realization. Temporary change in the profile (to overcome Papyrus current limitation): - added extension towards Dependency A mixed string description, identifying the source elements. Semantics: See description. A mixed string description, identifying the source elements. Semantics: See description. Sensor represents a hardware entity for digital or analog sensor elements. The Sensor is connected electrically to the electrical entities of the Hardware Design Architecture. Semantics: Sensor denotes an electrical sensor. The Sensor represents the physical and electrical aspects of sensor hardware. The logical aspect is represented by a HardwareFunctionType associated with the Sensor. Notation: Sensor is shown as an oval. The circle contains the name, and its ports or port groups on the perimeter. The SporadicEventConstraint describes that an event occurs occasionally. In general it is supposed that the event eventually occurs. However, it is also known that some of the events do not occur for whatsoever reasons. Note! The parameters minimum inter-arrival time and maximum inter-arrival time must reference the same point in time. Typically, this is the point in time that specifies the beginning of the period subject to consideration. Semantics: SporadicEventConstraint characterizes the occurrence pattern of the associated event.The attributes provides further semantics: jitter, period, minimumInterArrivalTime and maximumInterArrivalTime. The SporadicEventConstraint describes that an event occurs occasionally. In general it is supposed that the event eventually occurs. However, it is also known that some of the events do not occur for whatsoever reasons. Note! The parameters minimum inter-arrival time and maximum inter-arrival time must reference the same point in time. Typically, this is the point in time that specifies the beginning of the period subject to consideration. Semantics: SporadicEventConstraint characterizes the occurrence pattern of the associated event.The attributes provides further semantics: jitter, period, minimumInterArrivalTime and maximumInterArrivalTime. The stakeholder represents various roles with regard to the creation and use of architectural descriptions. Stakeholders include clients, users, the architect, developers, and evaluators. [IEEE 1471] Summarize the Stakeholder's key responsibilities with regard to the electrical/electronic system being developed; that is, their interest as a Stakeholder. Describes how the Stakeholder defines success. The stakeholder represents various roles with regard to the creation and use of architectural descriptions. Stakeholders include clients, users, the architect, developers, and evaluators. [IEEE 1471] Stakeholder needs represent a list of the key problems as perceived by the stakeholder, and it gives the opportunity to establish traceability from artifacts created later, for example to provide rationales to design decisions or trade-off analysis. The brief need statement. Redefines text. The priority of the need. Stakeholder needs represent a list of the key problems as perceived by the stakeholder, and it gives the opportunity to establish traceability from artifacts created later, for example to provide rationales to design decisions or trade-off analysis. Statement of state elements in state-machine constraints. Semantics: A state is an element in state-machine description. Each state represents a set of parameter conditions that are of particular concern in the operations of behaviors to be fulfilled by a vehicle feature, a system artifact, or an environment entity. A state can also represent a vehicle mode and thereby provides detailed information about the related parameters and mode transitions. Within each state, there can be subordinate state-machines. A subordinate state-machine becomes active if its composite state is active and terminates when the composite state is exited. Indicating an initial state when the value is true. Statement of state elements in state-machine constraints. Semantics: A state is an element in state-machine description. Each state represents a set of parameter conditions that are of particular concern in the operations of behaviors to be fulfilled by a vehicle feature, a system artifact, or an environment entity. A state can also represent a vehicle mode and thereby provides detailed information about the related parameters and mode transitions. Within each state, there can be subordinate state-machines. A subordinate state-machine becomes active if its composite state is active and terminates when the composite state is exited. Statement of state-machine constraints of behaviors to be fulfilled by a vehicle feature, a system artifact, or an environment entity. Semantics: State-machine constraints refine textual requirements and provide detailed specifications about the states of quantities and the state transitions in the operation of behaviors. The definition of state-machine constraint follows a generic definition of automata: In one state, read certain parameter, upon certain parameter condition(s), do certain transformation(s), then go to another state. Each state-machine description normally has a set of states and transitions. A state-machine has a single initial state. Only one state is active during the operation. Statement of state-machine constraints of behaviors to be fulfilled by a vehicle feature, a system artifact, or an environment entity. Semantics: State-machine constraints refine textual requirements and provide detailed specifications about the states of quantities and the state transitions in the operation of behaviors. The definition of state-machine constraint follows a generic definition of automata: In one state, read certain parameter, upon certain parameter condition(s), do certain transformation(s), then go to another state. Each state-machine description normally has a set of states and transitions. A state-machine has a single initial state. Only one state is active during the operation. The top level element of the System Description. The System description defines five major elements: Topology, Software, Communication, Mapping and Mapping Constraints. The System element directly aggregates the elements describing the Software, Mapping and Mapping Constraints; it contains a reference to an ASAM FIBEX description specifying Communication and Topology. Version number of the Ecu Extract. Version number of the System Description. The top level element of the System Description. The System description defines five major elements: Topology, Software, Communication, Mapping and Mapping Constraints. The System element directly aggregates the elements describing the Software, Mapping and Mapping Constraints; it contains a reference to an ASAM FIBEX description specifying Communication and Topology. The SystemModel is used to organize models/architectures according to their abstraction level; it can also hold with relationships between the different levels. Semantics: The SystemModel represents the electrical/electronic system of the vehicle, and concepts related to the various abstraction levels. Notation: The default notation for a SystemModel is a solid-outline rectangle containing the SystemModel's name, and with compartments separating by horizontal lines containing features or other members of the SystemModel. Contained entities may also be shown with their connectors (White-box view). Extension: Class The SystemModel is used to organize models/architectures according to their abstraction level; it can also hold with relationships between the different levels. Semantics: The SystemModel represents the electrical/electronic system of the vehicle, and concepts related to the various abstraction levels. Notation: The default notation for a SystemModel is a solid-outline rectangle containing the SystemModel's name, and with compartments separating by horizontal lines containing features or other members of the SystemModel. Contained entities may also be shown with their connectors (White-box view). Extension: Class The TakeRateConstraint defines the ratio between the number of configurations that includes the target elements and the number of configurations that include the source. If several source elements are referenced, it would be the configurations in which all these exist. TakeRateConstraint complements configuration decisions, as the latter defines the rules for actual configuration. TakeRateConstraint defines expected rates of configurations and the set of constraints should be consistent with the configuration decisions. Also, the set of TakeRateConstraints shall be consistent among themselves. Constraints: [1] The cardinality of target is &gt; 0 Semantics: The TakeRate constraint defines frequency of configurations. Let sourceamount and targetamount be the number of system configurations where all source and target elements, respectively, are included. takeRate= targetamount/sourceamount. If no source is associated, takeRate=targetamount. The rate of target compared with source configurations. The TakeRateConstraint defines the ratio between the number of configurations that includes the target elements and the number of configurations that include the source. If several source elements are referenced, it would be the configurations in which all these exist. TakeRateConstraint complements configuration decisions, as the latter defines the rules for actual configuration. TakeRateConstraint defines expected rates of configurations and the set of constraints should be consistent with the configuration decisions. Also, the set of TakeRateConstraints shall be consistent among themselves. Constraints: [1] The cardinality of target is &gt; 0 Semantics: The TakeRate constraint defines frequency of configurations. Let sourceamount and targetamount be the number of system configurations where all source and target elements, respectively, are included. takeRate= targetamount/sourceamount. If no source is associated, takeRate=targetamount. TechnicalSafetyConcept represents the set of technical safety requirements that together fulfils a FunctionalSafetyConcept and SafetyGoal in accordance with ISO 26262. These are derived from FunctionalSafetyConcepts i.e. TechnicalSafetyRequirements are derived from FunctionalSafetyRequirements. Semantics: The TechnicalSafetyConcept consists of the technical safety requirements and details the functional safety concept considering the functional concept and the preliminary architectural design. It corresponds to the Technical Safety Concept of ISO26262. TechnicalSafetyConcept represents the set of technical safety requirements that together fulfils a FunctionalSafetyConcept and SafetyGoal in accordance with ISO 26262. These are derived from FunctionalSafetyConcepts i.e. TechnicalSafetyRequirements are derived from FunctionalSafetyRequirements. Semantics: The TechnicalSafetyConcept consists of the technical safety requirements and details the functional safety concept considering the functional concept and the preliminary architectural design. It corresponds to the Technical Safety Concept of ISO26262. CseCodeType 0: 1 µsec Time 1: 10 µsec Time 2: 100 µsec Time 3: 1 msec Time 4: 10 msec Time 5: 100 msec Time 6: 1 sec Time 7: 10 sec Time 8: 1 min Time 9: 1 h Time 10: 1 d Time 100: Angular degrees Angle 101: Revolutions 360 degrees Angle 102: Cycle 720 degrees Angle e.g. in case of IC engines 103: Cylinder segment Combustion e.g. in case of IC engines 998: When frame available Time Source defined in the ASAP 2 keyword, FRAME 999: Always if there is new value Calculation of a new upper range limit after receiving a new partial value, e.g. when calculating a complex trigger condition 1000: Non deterministic Without fixed scaling If, for example, the value in swCseCodeFactor is 360 and the value in swCseCode is 100, this is equivalent to the value 1 in swCseCodeFactor and the value 101 in swCseCode. CseCodeType is from AUTOSAR and MSR/ASAM. Note that we have set the cseCodeType for 1 µsec to 0 (error in AUTOSAR R3). And have changed cseCodeType 2 to 100 µsec (error in MSR). Semantics: TimeDuration represents a time duration according to the attributes value, cseCode and cseCodeFactor. xml.xsd.type="double" This is normally time, note that when it is expressed as angle it can be converted to time. Is normally equal to 1. The actual value complemented with the cseCode. CseCodeType 0: 1 µsec Time 1: 10 µsec Time 2: 100 µsec Time 3: 1 msec Time 4: 10 msec Time 5: 100 msec Time 6: 1 sec Time 7: 10 sec Time 8: 1 min Time 9: 1 h Time 10: 1 d Time 100: Angular degrees Angle 101: Revolutions 360 degrees Angle 102: Cycle 720 degrees Angle e.g. in case of IC engines 103: Cylinder segment Combustion e.g. in case of IC engines 998: When frame available Time Source defined in the ASAP 2 keyword, FRAME 999: Always if there is new value Calculation of a new upper range limit after receiving a new partial value, e.g. when calculating a complex trigger condition 1000: Non deterministic Without fixed scaling If, for example, the value in swCseCodeFactor is 360 and the value in swCseCode is 100, this is equivalent to the value 1 in swCseCodeFactor and the value 101 in swCseCode. CseCodeType is from AUTOSAR and MSR/ASAM. Note that we have set the cseCodeType for 1 µsec to 0 (error in AUTOSAR R3). And have changed cseCodeType 2 to 100 µsec (error in MSR). Semantics: TimeDuration represents a time duration according to the attributes value, cseCode and cseCodeFactor. xml.xsd.type="double" This is used to specify a time value based on ASAM CSE codes. It is specified by a code which defined the basis of the time and a scaling factor which finally determines the time value. If for example the the cseCode is 100 and the cseCodeFactor is 360, it represents 360 angular degrees. If the cseCode is 2 and the cseCodeFactor is 50 it represents 50 microseconds Specifies the time base by means of CSE codes. The scaling factor for the time value based on the specified CSE code. This is used to specify a time value based on ASAM CSE codes. It is specified by a code which defined the basis of the time and a scaling factor which finally determines the time value. If for example the the cseCode is 100 and the cseCodeFactor is 360, it represents 360 angular degrees. If the cseCode is 2 and the cseCodeFactor is 50 it represents 50 microseconds The collection of timing constraints and their descriptions in the form of events and event chains. This collection can be done across the EAST-ADL abstraction levels. Semantics: Timing is a container element that collects all elements related to timing. It is possible to have several Timing elements to organize related timing in dedicated containers. The collection of timing constraints and their descriptions in the form of events and event chains. This collection can be done across the EAST-ADL abstraction levels. Semantics: Timing is a container element that collects all elements related to timing. It is possible to have several Timing elements to organize related timing in dedicated containers. TimingConstraint is an abstract entity that identifies a mode. Constraints: [1] upper shall be greater or equal to lower. Semantics: The TimingConstraint does not describe what is classically referred to as a "design" constraint but has the role of a property, requirement, or a validation result. It is a requirement if this TimingConstraint refines a Requirement (by the Refine relationship). The TimingConstraint is a validation result if it realizes a VVActualOutcome, it is an intended validation result if it realizes a VVIntendedOutcome, and in other cases it denotes a property. The TraceableSpecification is an abstract metaclass which is used to allow its specializations to be allocated to a Context. Semantics: TraceableSpecification is specialized by requirements, test cases and other specifications, that can be allocated to a Context, for example to a sensor or to an entire HW architecture. See Context and Relationship. Extension: The ADLTraceableSpecification is a specification stereotype which extends UML2 metaclass Element An optional description attribute that provides textual representation, or a reference to the textual representation, of the Traceable Specification in a specific formalism. A transformation defines an expected computation activity on two sets of quantities in terms of parameters. It describes one set of parameters as a function of other parameters, under the constraint of pre-, post-, and invariant parameter conditions. Constraints: [1] A transformation has at least one out or one inOut parameter. Semantics: Each transformation specifies one computation activity of executing some mathematical functions, each of which maps two sets of quantities by performing some arithmetic, Boolean- or string-related calculations. EAST-ADL does not define expressions of such functions but would support the definitions in future extensions. Inside an EAST-ADL function behavior, the execution of transformations follows the run-to-completion assumption. This means that the execution of a transformation is only possible when the previous execution instance of the same transformation is fully completed. For a system function, the amount of time to execute its transformations is constrained by the EAST-ADL function event in the timing package. A transformation defines an expected computation activity on two sets of quantities in terms of parameters. It describes one set of parameters as a function of other parameters, under the constraint of pre-, post-, and invariant parameter conditions. Constraints: [1] A transformation has at least one out or one inOut parameter. Semantics: Each transformation specifies one computation activity of executing some mathematical functions, each of which maps two sets of quantities by performing some arithmetic, Boolean- or string-related calculations. EAST-ADL does not define expressions of such functions but would support the definitions in future extensions. Inside an EAST-ADL function behavior, the execution of transformations follows the run-to-completion assumption. This means that the execution of a transformation is only possible when the previous execution instance of the same transformation is fully completed. For a system function, the amount of time to execute its transformations is constrained by the EAST-ADL function event in the timing package. Statement of state transtion elements in state-machine constraints. Semantics: A transition goes from a source state to a target state. A transition can only fire if its source state is active, its read parameter is available, and the related parameter condition(s) holds. When it is fired, a transition can invoke certain transformations and write certain parameters (i.e., making such parameters available). Statement of state transtion elements in state-machine constraints. Semantics: A transition goes from a source state to a target state. A transition can only fire if its source state is active, its read parameter is available, and the related parameter condition(s) holds. When it is fired, a transition can invoke certain transformations and write certain parameters (i.e., making such parameters available). A UseCase specifies a usage of a system. Typically, they are used to capture the functionality of a system, that is, what a system is supposed to do. Semantics: A UseCase identifies a usage of its corresponding system. extensionPoint identifies where the use case can be extended with extend UseCases and include identifies UseCases inserted in the including UseCase. A UseCase specifies a usage of a system. Typically, they are used to capture the functionality of a system, that is, what a system is supposed to do. Semantics: A UseCase identifies a usage of its corresponding system. extensionPoint identifies where the use case can be extended with extend UseCases and include identifies UseCases inserted in the including UseCase. UserAttributeDefinition represents a user attribute, i.e. it states that all UserAttributeableElements of a certain UserAttributeElementType are to be attached with an attribute. For example, it can be specified that certain elements should be amended with an attribute "Status". Semantics: UserAttributeDefinition represents a user attribute in the UserAttributeElementType. Extension: Class The default value. This is to be used whenever a user attributeable element has no UserAttributeValue for this UserAttributeDefinition. UserAttributeDefinition represents a user attribute, i.e. it states that all UserAttributeableElements of a certain UserAttributeElementType are to be attached with an attribute. For example, it can be specified that certain elements should be amended with an attribute "Status". Semantics: UserAttributeDefinition represents a user attribute in the UserAttributeElementType. Extension: Class UserAttributeElementType represents a certain, user-defined type of user attributeable elements. With such a type, one or more user attributes can be defined for all user attributeable elements of that type. For example, engineers at Volkswagen could create a UserAttributeElementType called "VWFunction" with a single user attribute definition. That way, all FunctionTypes for which "VWFunction" is defined as the UserAttributeElementType via association uaType will have the corresponding user attribute. User attribute element types can be compared to stereotypes in UML2, but are less rigidly defined. Semantics: UserAttributeElementType defines the type of a UserAttributeDefinition. Extension: Class Comma-separated list of metaclass names this user attribute element type is applicable to. If undefined, then this user attribute element type is applicable to all UserAttributeableElements. Example: If UserAttributeElementType 'VWFunction' has its validFor attribute set to "FunctionalDevice,LocalDeviceManager", then element type 'VWFunction' is only applicable to functional devices and local device managers, i.e. only instances of FunctionalDevice and LocalDeviceManager may have their association uaType point to 'VWFunction'. UserAttributeElementType represents a certain, user-defined type of user attributeable elements. With such a type, one or more user attributes can be defined for all user attributeable elements of that type. For example, engineers at Volkswagen could create a UserAttributeElementType called "VWFunction" with a single user attribute definition. That way, all FunctionTypes for which "VWFunction" is defined as the UserAttributeElementType via association uaType will have the corresponding user attribute. User attribute element types can be compared to stereotypes in UML2, but are less rigidly defined. Semantics: UserAttributeElementType defines the type of a UserAttributeDefinition. Extension: Class UserAttributeValue represents a specific value for a certain user attribute. The actual value is captured in the attribute value and is always represented as a string. Semantics: UserAttributeValue is an annotation of the containing UserAttributableElement. It has a value and the value type is the UserAttributeDefinition. Extension: Class Alternative semantics if the definition of this value is not defined in the model. Holds the actual value of the user attribute identified by the type UserAttributeDefinition. This value is always represented as a string. Non-string values, such as integers, are specified by their corresponding string representation. UserAttributeValue represents a specific value for a certain user attribute. The actual value is captured in the attribute value and is always represented as a string. Semantics: UserAttributeValue is an annotation of the containing UserAttributableElement. It has a value and the value type is the UserAttributeDefinition. Extension: Class UserAttributableElement represents an element to which user attributes can be attached. This is done by way of UserAttributeValues (see association uaValues). What user attributes a certain element should be supplied with can be defined beforehand with UserAttributeDefinitions which are organized in UserAttributeElementTypes (see association uaTypes). According to a common EAST-ADL meta-modeling pattern, the meta-classes that are attributable, i.e. to which user attributes may be attached, do not inherit from meta-class UserAttributableElement but instead UserAttributableElement points to these meta-classes (for example, to allow attaching user attributes to AUTOSAR Identifiable). Semantics: UserAttributeableElement can be annotated with user attributes. Extension: Class UserAttributableElement represents an element to which user attributes can be attached. This is done by way of UserAttributeValues (see association uaValues). What user attributes a certain element should be supplied with can be defined beforehand with UserAttributeDefinitions which are organized in UserAttributeElementTypes (see association uaTypes). According to a common EAST-ADL meta-modeling pattern, the meta-classes that are attributable, i.e. to which user attributes may be attached, do not inherit from meta-class UserAttributableElement but instead UserAttributableElement points to these meta-classes (for example, to allow attaching user attributes to AUTOSAR Identifiable). Semantics: UserAttributeableElement can be annotated with user attributes. Extension: Class VVActualOutcome represents the actual output of the testing environment as represented by VVTarget when triggered by the VVStimuli of the ConcreteVVProcedure. This is defined by the association 'performedVVProcedure' of the containing VVLog. It should be equivalent to the VVIntendedOutcome defined by the association 'intendedOutcome'. Semantics: VVActualOutcome represents the actual output of a verification effort as defined by the V&amp;V elements. Extension: Class VVActualOutcome represents the actual output of the testing environment as represented by VVTarget when triggered by the VVStimuli of the ConcreteVVProcedure. This is defined by the association 'performedVVProcedure' of the containing VVLog. It should be equivalent to the VVIntendedOutcome defined by the association 'intendedOutcome'. Semantics: VVActualOutcome represents the actual output of a verification effort as defined by the V&amp;V elements. Extension: Class VVCase represents a V&amp;V effort, i.e. it specifies concrete test subjects and targets and provides stimuli and the expected outcome on a concrete technical level. Semantics: VVCase is a grouping element for a set of VVProcedures that together makes up a concrete Verification/Validation effort. VVCase represents a V&amp;V effort, i.e. it specifies concrete test subjects and targets and provides stimuli and the expected outcome on a concrete technical level. Semantics: VVCase is a grouping element for a set of VVProcedures that together makes up a concrete Verification/Validation effort. VVIntendedOutcome represents the expected output of the testing environment represented by VVTarget when triggered by the corresponding VVStimuli of the containing ConcreteVVProcedure. Since this entity only occurs on the concrete level (i.e. within the context of a ConcreteVVCase), the output must be provided in a form that can be directly compared to the output of the VVTarget(s) defined for the containing ConcreteVVCase. Semantics: VVIntendedOutcome represents the expected output of a Verification/Validation effort. Extension: Class ConcreteVVCase represents the precise description of a V&amp;V effort on a concrete technical level and thus provides all necessary information to actually perform this V&amp;V effort. However, it does not represent the actual execution of the effort. This is the purpose of the VVLog. Each VVLog metaclass represents an execution of a ConcreteVVCase. For example, if the HIL test of the wiper system with a certain set of stimuli was performed on Friday afternoon and, for checkup, again on Monday, then there will be one ConcreteVVCase describing the HIL test and two VVLogs describing the test results from Friday and Monday respectively. Semantics: VVLog captures an execution of a ConcreteVVCase. Extension: Class Date and time when this log was captured. ConcreteVVCase represents the precise description of a V&amp;V effort on a concrete technical level and thus provides all necessary information to actually perform this V&amp;V effort. However, it does not represent the actual execution of the effort. This is the purpose of the VVLog. Each VVLog metaclass represents an execution of a ConcreteVVCase. For example, if the HIL test of the wiper system with a certain set of stimuli was performed on Friday afternoon and, for checkup, again on Monday, then there will be one ConcreteVVCase describing the HIL test and two VVLogs describing the test results from Friday and Monday respectively. Semantics: VVLog captures an execution of a ConcreteVVCase. Extension: Class VVProcedure represents an individual task in a V&amp;V effort (represented by a VVCase), which has to be performed in order to achieve that effort's overall objective. As with VVCases, the definition of VVProcedures is separated in to two levels: an abstract and a concrete level represented by the entities AbstractVVProcedure and ConcreteVVProcedure. The concreteVVProcedure metaclass represents such a task on a concrete level It is defined with a concrete testing environment in mind and provides stimuli and the expected outcome of the procedure in a form which is directly applicable to this testing environment. Semantics: VVProcedure represents an individual task in a Verifcation/Validation effort. Extension: Class VVProcedure represents an individual task in a V&amp;V effort (represented by a VVCase), which has to be performed in order to achieve that effort's overall objective. As with VVCases, the definition of VVProcedures is separated in to two levels: an abstract and a concrete level represented by the entities AbstractVVProcedure and ConcreteVVProcedure. The concreteVVProcedure metaclass represents such a task on a concrete level It is defined with a concrete testing environment in mind and provides stimuli and the expected outcome of the procedure in a form which is directly applicable to this testing environment. Semantics: VVProcedure represents an individual task in a Verifcation/Validation effort. Extension: Class VVStimuli represents the input values of the testing environment represented by VVTarget in order to perform the corresponding VVProcedure. Since this entity only occurs on the concrete level (i.e. within the context of a ConcreteVVCase), the input values must be provided in a form that is directly applicable to the VVTarget(s) defined for the containing ConcreteVVCase. Semantics: VVStimuli represents the concrete input values used for a VVProcedure during a Verification/Validation effort of a VVTarget. Extension: Class VVTarget represents a concrete testing environment in which a particular V&amp;V activity can be performed. This can be physical hardware or it can be pure software in case of a test by way of design level simulations. Usually, a VVTarget will be a realization of one or more elements. However, there are cases in which this is not true, for example when a VVTarget represents parts of the system's environment. Therefore the association to element has a minimum cardinality of 0. VVTargets can be reused across several ConcreteVVCases. Semantics: VVTarget represents a concrete testing environment in which a particular Verifcation/Validation activity is performed. VVTarget represents a concrete testing environment in which a particular V&amp;V activity can be performed. This can be physical hardware or it can be pure software in case of a test by way of design level simulations. Usually, a VVTarget will be a realization of one or more elements. However, there are cases in which this is not true, for example when a VVTarget represents parts of the system's environment. Therefore the association to element has a minimum cardinality of 0. VVTargets can be reused across several ConcreteVVCases. Semantics: VVTarget represents a concrete testing environment in which a particular Verifcation/Validation activity is performed. From SysML: A ValueType defines types of values that may be used to express information about a system, but cannot be identified as the target of any reference. Since a value cannot be identified except by means of the value itself, each such value within a model is independent of any other, unless other forms of constraints are imposed. Value types may be used to type properties, operation parameters, or potentially other elements within SysML. SysML defines ValueType as a stereotype of UML DataType to establish a more neutral term for system values that may never be given a concrete data representation. For example, the SysML "Real" ValueType expresses the mathematical concept of a real number, but does not impose any restrictions on the precision or scale of a fixed or floating-point representation that expresses this concept. More specific value types can define the concrete data representations that a digital computer can process, such as conventional Float, Integer, or String types. Semantics: The ValueType adds an ability to carry a description, a dimension associated with the value, and a unit of measure. A dimension is a kind of quantity that may be stated in terms of defined units, but does not restrict the selection of a unit to state the value. A unit is a particular value in terms of which a quantity of the same dimension may be expressed. Logical and physical datatypes cannot be distinguished on the type. The context (e.g., EnvironmentModel or FunctionalAnalysisArchitecture) decides if a speed datatype is physical or logical. On AnalysisLevel or DesignLevel, physical datatypes shall not be interpreted in the implementation sense as this would include int32, coding formula, etc. Extension: UML Datatype, SysML ValueType The (physical) quantity, e.g., "Speed", "Temperature". Semantics of the datatype ValueType. The unit of data. Example: For temperature the unit may be "degree Celsius". The collection of variability descriptions, related feature models, and decision models. This collection can be done across the EAST-ADL abstraction levels. Semantics: See description. The collection of variability descriptions, related feature models, and decision models. This collection can be done across the EAST-ADL abstraction levels. Semantics: See description. VariableElement is a marker class that marks an artifact element denoted by association optionalElement as being optional, i.e. it will not be present in all configurations of the complete system. A typical example is an optional FunctionPrototype. In addition, the VariableElement can be used to extend the EAST-ADL variability approach to other languages and standards by pointing from the VariableElement to the respective (non EAST-ADL) element with association optionalElement, thus marking the non EAST-ADL element as optional and providing configuration support within its containing ConfigurableContainer. Refer to the documentation of meta-class ConfigurableContainer for a detailed explanation of how ConfigurableContainer and VariableElement work together. Constraints: [1] Identifies either one FunctionPrototype or one FunctionPort or one FunctionConnector or one HardwareComponentPrototype or one HardwarePort or one ClampConnector. Semantics: Marks the element identified by association optionalElement as optional. Extension: Class VariableElement is a marker class that marks an artifact element denoted by association optionalElement as being optional, i.e. it will not be present in all configurations of the complete system. A typical example is an optional FunctionPrototype. In addition, the VariableElement can be used to extend the EAST-ADL variability approach to other languages and standards by pointing from the VariableElement to the respective (non EAST-ADL) element with association optionalElement, thus marking the non EAST-ADL element as optional and providing configuration support within its containing ConfigurableContainer. Refer to the documentation of meta-class ConfigurableContainer for a detailed explanation of how ConfigurableContainer and VariableElement work together. Constraints: [1] Identifies either one FunctionPrototype or one FunctionPort or one FunctionConnector or one HardwareComponentPrototype or one HardwarePort or one ClampConnector. Semantics: Marks the element identified by association optionalElement as optional. Extension: Class A VariationGroup defines a relation between an arbitrary number of VariableElements. It is primarily intended for defining how these VariableElements may be combined (e.g. one requires the other, alternative, etc.). Semantics: Defines a dependency or constraint between the variable elements denoted by association variableElement. The actual constraint is specified by attribute kind. Extension: Class Only defined iff kind=="custom". A constraint specifying how the VariableElements in the variation group can be combined. This attribute adheres to the syntax and semantics of the VSL language. The kind of the variation group (see enumeration VariationGroupKind). A VariationGroup defines a relation between an arbitrary number of VariableElements. It is primarily intended for defining how these VariableElements may be combined (e.g. one requires the other, alternative, etc.). Semantics: Defines a dependency or constraint between the variable elements denoted by association variableElement. The actual constraint is specified by attribute kind. Extension: Class VehicleFeature represents a special kind of feature intended for use on Vehicle Level. The main difference to features in general is that they provide support for the multi-level concept (via their DeviationAttributeSet) and several additional attributes with meta-information specific to the vehicle level viewpoint. Constraints: [1] VehicleFeatures can only be contained in FeatureModels on VehicleLevel. Semantics: A VehicleFeature is a functional or non-functional characteristic, constraint or property that can be present or not in a vehicle product line on the level of the complete system, i.e. vehicle. Extension: Class This attribute states whether the VehicleFeature is customer visible (in contrast to a VehicleFeature that is e.g. technically driven). VehicleFeatures describe the system's characteristics on the level of the complete system and on a high abstraction level but they can still have a strong technical viewpoint. Therefore, they are usually not suitable for being directly presented to the end-customer. There are two approaches to deal with this situation. (1) The simple approach uses this attribute to denote those VehicleFeatures that are suitable for immediate end-customer configuration: if this attribute is set to true, then the feature will be directly presented to the end-customer for selection or deselection; if set to false, then the feature will be hidden from the end-customer and is thus reserved for internal configuration. (2) The more sophisticated approach is to define a dedicated product feature model to capture the customer viewpoint (available in the variability extension) in addition to the technical feature model on Vehicle Level and to provide a configuration decision model that maps configurations of this end-customer-oriented product feature model to the core technical feature model on Vehicle Level. This approach is much more flexible because the customer-view on the product line's variability can be structured freely and independently from the core technical feature model; furthermore, this approach can cope much better with evolution because the end-customer-oriented feature model can be evolved independently of the core technical feature model (and vice versa). When applying this second approach, this attribute isCustomerVisible will no longer be used, i.e., its value will be ignored. The simple approach #1 is suitable for simple product line scenarios. Approach #2 should be used for complex scenarios with large core technical feature models and/or longer evolution periods of the overall product line infrastructure. A VehicleFeature marked as a design variability rationale captures a variant showing up on a concrete artifact level that needs to be modeled on the Vehicle Level as well, in order to be directly available for immediate configuration on Vehicle Level. It is, from the abstraction layer's point of view, not a true Vehicle Level feature. If true, then isCustomerVisible is usually false but there may be rare exceptions. This attribute describes if the VehicleFeature is removed (but kept in the database for tracking of evolution, which is required by the multi-level concept). VehicleFeature represents a special kind of feature intended for use on Vehicle Level. The main difference to features in general is that they provide support for the multi-level concept (via their DeviationAttributeSet) and several additional attributes with meta-information specific to the vehicle level viewpoint. Constraints: [1] VehicleFeatures can only be contained in FeatureModels on VehicleLevel. Semantics: A VehicleFeature is a functional or non-functional characteristic, constraint or property that can be present or not in a vehicle product line on the level of the complete system, i.e. vehicle. Extension: Class The VehicleLevel represents the vehicle content from an external perspective through an arbitrary set of feature models. These contain VehicleFeatures that are organized to reflect the vehicle configuration and that have associated requirements, use cases, etc. for its definition. Constraints: [1] All contained feature models are FeatureModels that only contain VehicleFeatures. Semantics: The VehicleLevel represents the vehicle content through solution-independent features. Notation: The VehicleLevel is shown as a solid-outline rectangle containing the name. Contained entities may be shown (White-box view). Extension: class. The VehicleLevel represents the vehicle content from an external perspective through an arbitrary set of feature models. These contain VehicleFeatures that are organized to reflect the vehicle configuration and that have associated requirements, use cases, etc. for its definition. Constraints: [1] All contained feature models are FeatureModels that only contain VehicleFeatures. Semantics: The VehicleLevel represents the vehicle content through solution-independent features. Notation: The VehicleLevel is shown as a solid-outline rectangle containing the name. Contained entities may be shown (White-box view). Extension: class. This class represents a binding on the vehicle level or coming from the vehicle level with explicitly defined source and target feature models. The source feature models must be on vehicle level, but the target feature models may be located on artifact level, e.g. the public feature model of the top-level FunctionType in the FDA. This way, a VehicleLevelBinding may be used to bridge the gap from vehicle level variability management to that on the artifact level. Source feature models may be either the core technical feature model (as defined by association technicalFeatureModel of meta-class VehicleLevel) or one of the optional product feature models (as defined by association productFeatureModel of meta-class Variability in the variability extension). Constraints: [1] The sourceVehicleFeatureModels shall only contain VehicleFeatures. [2] The sourceVehicleFeatureModels shall be different from the targetFeatureModels. Semantics: See description. This class represents a binding on the vehicle level or coming from the vehicle level with explicitly defined source and target feature models. The source feature models must be on vehicle level, but the target feature models may be located on artifact level, e.g. the public feature model of the top-level FunctionType in the FDA. This way, a VehicleLevelBinding may be used to bridge the gap from vehicle level variability management to that on the artifact level. Source feature models may be either the core technical feature model (as defined by association technicalFeatureModel of meta-class VehicleLevel) or one of the optional product feature models (as defined by association productFeatureModel of meta-class Variability in the variability extension). Constraints: [1] The sourceVehicleFeatureModels shall only contain VehicleFeatures. [2] The sourceVehicleFeatureModels shall be different from the targetFeatureModels. Semantics: See description. A collection of components organized to accomplish a specific function or set of functions. [IEEE 1471] A collection of components organized to accomplish a specific function or set of functions. [IEEE 1471] The collection of verification and validation elements. This collection can be used across the EAST-ADL abstraction levels. Semantics: VerificationValidation is a container element for a set of related vvTarget and vvCase elements and verify relationships. The collection of verification and validation elements. This collection can be used across the EAST-ADL abstraction levels. Semantics: VerificationValidation is a container element for a set of related vvTarget and vvCase elements and verify relationships. Verify is a relationship metaclass, which signifies a dependency relationship between a Requirement and a VVCase. It shows the relationship when a client VVCase verifies the supplier Requirement. Semantics: The Verify metaclass signifies a refined requirement/verified by relationship between a Requirement and a VVCase, where the modification of the supplier Requirement may impact the verifying client VVCase. The Verify metaclass implies that the semantics of the verifying client VVCase is not complete, without the supplier Requirement. Notation: A Verify relationship is shown as a dashed arrow between the Requirements and VVCase. Extension: To specializes SysML::Verify, which specializes the UML stereotype Trace, which extends Dependency. Temporary change in the profile (to overcome bug in Eclipse/UML2 concerning standard stereotypes) - added extension towards Dependency - removed generalization link towards SysML::Verify Verify is a relationship metaclass, which signifies a dependency relationship between a Requirement and a VVCase. It shows the relationship when a client VVCase verifies the supplier Requirement. Semantics: The Verify metaclass signifies a refined requirement/verified by relationship between a Requirement and a VVCase, where the modification of the supplier Requirement may impact the verifying client VVCase. The Verify metaclass implies that the semantics of the verifying client VVCase is not complete, without the supplier Requirement. Notation: A Verify relationship is shown as a dashed arrow between the Requirements and VVCase. Extension: To specializes SysML::Verify, which specializes the UML stereotype Trace, which extends Dependency. Temporary change in the profile (to overcome bug in Eclipse/UML2 concerning standard stereotypes) - added extension towards Dependency - removed generalization link towards SysML::Verify Warrant represents argumentation of the facts to the Claim in general ways. The Warrant entity has associations with the decomposed goals and with the evidences for the SafetyCase. Semantics: The overall objective of an argument is to lead the evidence to the claim. Arguments are actions of inferring a conclusion from premised propositions. An argument is considered valid if the conclusion can be logically derived from its premises. An argument is considered sound if it is valid and all premises are true. A goal decomposition strategy breaks down a goal into a number of sub-goals. It is recommended that the strategies are of specific form. Warrant represents argumentation of the facts to the Claim in general ways. The Warrant entity has associations with the decomposed goals and with the evidences for the SafetyCase. Semantics: The overall objective of an argument is to lead the evidence to the claim. Arguments are actions of inferring a conclusion from premised propositions. An argument is considered valid if the conclusion can be logically derived from its premises. An argument is considered sound if it is valid and all premises are true. A goal decomposition strategy breaks down a goal into a number of sub-goals. It is recommended that the strategies are of specific form.