path: root/extraplugins/eastadl/org.eclipse.papyrus.eastadl/model/eastadl.ecore

<?xml version="1.0" encoding="UTF-8"?>
<ecore:EPackage xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="eastadl" nsURI="http://www.papyrusuml.org/EAST-ADL2/1" nsPrefix="EAST-ADL2">
  <eClassifiers xsi:type="ecore:EEnum" name="dummy"/>
  <eSubpackages name="variability" nsURI="http://www.papyrusuml.org/EAST-ADL2/Variability/1"
      nsPrefix="Variability">
    <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
      <details key="documentation" value="This package contains elements to express variability in the analysis architecture, design architecture and implementation architecture. These abstraction levels in EAST-ADL2 will sometimes be called the artifact levels."/>
    </eAnnotations>
    <eClassifiers xsi:type="ecore:EClass" name="VariationGroup" eSuperTypes="#//infrastructure/elements/EAElement">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="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.).&#xA;&#xA;&#xA;Semantics:&#xA;Defines a dependency or constraint between the variable elements denoted by association variableElement. The actual constraint is specified by attribute kind.&#xA;&#xA;Extension:&#xA;Class"/>
      </eAnnotations>
      <eStructuralFeatures xsi:type="ecore:EAttribute" name="constraint" ordered="false"
          lowerBound="1" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//String"/>
      <eStructuralFeatures xsi:type="ecore:EAttribute" name="kind" ordered="false"
          unique="false" lowerBound="1" eType="#//structure/featuremodeling/VariabilityDependencyKind">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The kind of the variation group (see enumeration VariationGroupKind)."/>
        </eAnnotations>
      </eStructuralFeatures>
      <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
          unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="variableElement" lowerBound="1"
          upperBound="-1" eType="#//variability/VariableElement"/>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EClass" name="VariableElement" eSuperTypes="#//infrastructure/elements/EAElement">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="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.&#xA;&#xA;In addition, the VariableElement can be used to extend the EAST-ADL2 variability approach to other languages and standards by pointing from the VariableElement to the respective (non EAST-ADL2) element with association optionalElement, by that marking the non EAST-ADL2 element as optional and providing configuration support within its containing ConfigurableContainer.&#xA;&#xA;Refer to the documentation of meta-class ConfigurableContainer for a detailed explanation of how ConfigurableContainer and VariableElement play together.&#xA;&#xA;&#xA;Constraints:&#xA;[1] Identifies either one FunctionPrototype or one FunctionPort or one FunctionConnector or one HardwareComponentPrototype or one HardwarePort or one ClampConnector.&#xA;&#xA;Semantics:&#xA;Marks the element identified by association optionalElement as optional.&#xA;&#xA;Extension:&#xA;Class"/>
      </eAnnotations>
      <eStructuralFeatures xsi:type="ecore:EReference" name="requiredBindingTime"
          ordered="false" eType="#//structure/featuremodeling/BindingTime"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="actualBindingTime" ordered="false"
          lowerBound="1" eType="#//structure/featuremodeling/BindingTime"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="reuseMetaInformation"
          ordered="false" eType="#//variability/ReuseMetaInformation"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="optionalElement" ordered="false"
          unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//NamedElement"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
          unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EClass" name="ReuseMetaInformation" eSuperTypes="#//infrastructure/elements/TraceableSpecification">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="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). This kind of information can be stored in this information.&#xA;&#xA;Semantics:&#xA;The ReuseMetaInformation represents information that explains if and how the respective entity can be reused.&#xA;&#xA;&#xA;Extension: Class"/>
      </eAnnotations>
      <eStructuralFeatures xsi:type="ecore:EAttribute" name="information" ordered="false"
          unique="false" lowerBound="1" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//String">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The reuse information is stored in this attribute."/>
        </eAnnotations>
      </eStructuralFeatures>
      <eStructuralFeatures xsi:type="ecore:EAttribute" name="isReusable" ordered="false"
          unique="false" lowerBound="1" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//Boolean"
          defaultValueLiteral="true">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="This Boolean attributes just says if the entity itself can essentially be reused or not. Specific information or constraints on reuse are in the information attribute. Default value is TRUE."/>
        </eAnnotations>
      </eStructuralFeatures>
      <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
          unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EClass" name="ConfigurableContainer" eSuperTypes="#//infrastructure/elements/EAElement">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="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 &quot;internal binding&quot;.&#xA;&#xA;In addition, the ConfigurableContainer can be used to extend the EAST-ADL2 variability approach to other languages and standards by pointing from the ConfigurableContainer to the respective (non EAST-ADL2) element with association configurableElement. This provides the public feature model and the ConfigurationDecisionModel to that non EAST-ADL2 element.&#xA;&#xA;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.&#xA;&#xA;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 &quot;WiperSystem&quot; containing two FunctionPrototypes &quot;front&quot; and &quot;rear&quot; both typed by FunctionType &quot;WiperMotor&quot;; to make the wiper system configurable and the rear wiper motor optional, a ConfigurableContainer is created that points to FunctionType &quot;WiperSystem&quot; (with association configurableElement) and a VariableElement is created that points to FunctionPrototype &quot;rear&quot; (with association optionalElement); the containment between the ConfigurableContainer and the VariableElement is therefore not explicitly defined between these classes but instead only between FunctionType &quot;WiperSystem&quot; and &quot;FunctionPrototype&quot; rear. In addition, the variability-related visibility of &quot;rear&quot; can be changed with PrivateContent: by default the variability of &quot;rear&quot; will be public and visible for direct configuration from the outside of its containing ConfigurableContainer, i.e. &quot;WiperSystem&quot;; by defining a PrivateContent marker object pointing to the FunctionPrototype &quot;rear&quot; this can be changed to private and this variability will not be visible from the outside of &quot;WiperSystem&quot;.&#xA;&#xA;Constraints:&#xA;[1] Identifies one FunctionType or one HardwareComponentType.&#xA;&#xA;[2] The publicFeatureModel is only allowed to contain Features (no VehicleFeatures).&#xA;&#xA;Semantics:&#xA;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.&#xA;&#xA;Extension:&#xA;Class"/>
      </eAnnotations>
      <eStructuralFeatures xsi:type="ecore:EReference" name="internalBinding" ordered="false"
          eType="#//variability/InternalBinding">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The PDM of the configurable container."/>
        </eAnnotations>
      </eStructuralFeatures>
      <eStructuralFeatures xsi:type="ecore:EReference" name="variationGroup" ordered="false"
          upperBound="-1" eType="#//variability/VariationGroup">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The variation groups that define certain constraints between this ADLVariableContainer's variable elements."/>
        </eAnnotations>
      </eStructuralFeatures>
      <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
          unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="base_Package" ordered="false"
          unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Package"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="configurableElement"
          ordered="false" unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//NamedElement"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="publicFeatureModel" ordered="false"
          eType="#//structure/featuremodeling/FeatureModel">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The local feature model of the configurable container."/>
        </eAnnotations>
      </eStructuralFeatures>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EClass" name="InternalBinding" eSuperTypes="#//variability/ConfigurationDecisionModel">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="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.&#xA;&#xA;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).&#xA;&#xA;For a definition of the precise meaning of 'internal variability' in the above sense (also called variable content) refer to the documentation of meta-class ConfigurableContainer."/>
      </eAnnotations>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EClass" name="ConfigurationDecisionModel" abstract="true"
        eSuperTypes="#//infrastructure/elements/EAElement">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="A ConfigurationDecisionModel defines how to configure m so-called target feature models, depending on a given configuration of n so-called 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).&#xA;&#xA;For example, a ConfigurationDecisionModel can capture information such as &quot;if feature 'S-Class' is selected in the source feature model, then select feature 'RainSensor' in the target feature model&quot; or &quot;if feature 'USA' is selected in the source feature model, then select feature 'CupHolder' in the target feature model&quot;.&#xA;&#xA;Note that in principle all ConfigurationDecisionModels have source / target feature models. However, only for those used on vehicle level they are defined explicitly; 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).&#xA;&#xA;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).&#xA;&#xA;&#xA;Extension:&#xA;Class"/>
      </eAnnotations>
      <eStructuralFeatures xsi:type="ecore:EReference" name="base_Package" ordered="false"
          unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Package"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
          unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="rootEntry" ordered="false"
          upperBound="-1" eType="#//variability/ConfigurationDecisionModelEntry"/>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EClass" name="ConfigurationDecisionModelEntry" abstract="true"
        eSuperTypes="#//infrastructure/elements/EAElement">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="ConfigurationDecisionModelEntry is the abstract base class for all content of a ConfigurationDecisionModel.&#xA;&#xA;Extension:&#xA;Class"/>
      </eAnnotations>
      <eStructuralFeatures xsi:type="ecore:EAttribute" name="isActive" ordered="false"
          unique="false" lowerBound="1" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//Boolean"
          defaultValueLiteral="true">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="If active==TRUE then the entry is selected for the ProductDecisionModel."/>
        </eAnnotations>
      </eStructuralFeatures>
      <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
          unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EClass" name="Variability" eSuperTypes="#//infrastructure/elements/Context">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="The collection of variability descriptions, related feature models, and decision models. This collection can be done across the EAST-ADL2 abstraction levels."/>
      </eAnnotations>
      <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
          unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="base_Package" ordered="false"
          unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Package"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="configurableContainer"
          ordered="false" upperBound="-1" eType="#//variability/ConfigurableContainer"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="configuration" ordered="false"
          upperBound="-1" eType="#//variability/FeatureConfiguration"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="productFeatureModel"
          ordered="false" upperBound="-1" eType="#//structure/featuremodeling/FeatureModel"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="decisionModel" ordered="false"
          upperBound="-1" eType="#//variability/VehicleLevelBinding"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="variableElement" ordered="false"
          unique="false" upperBound="-1" eType="#//variability/VariableElement"/>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EClass" name="FeatureConfiguration" eSuperTypes="#//variability/ConfigurationDecisionModel">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="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.&#xA;&#xA;Note that configurations of feature models are realized as a specialization of metaclass ConfigurationDecisionModel. This is possible because a ConfigurationDecisionModel also captures 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), we here simply define a &quot;constant&quot; 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 are no source feature model to which the criterion can refer, all ConfigurationDecisions in a FeatureConfiguration must have &quot;true&quot; as their criterion.&#xA;&#xA;&#xA;Semantics:&#xA;The FeatureConfiguration specifies a concrete configuration of a feature model, in particular which Features of this FeatureModel are selected or deselected.&#xA;&#xA;Extension:&#xA;Class&#xA;&#xA;Constraint:&#xA;[1] Attribute criterion of all ConfigurationDecisions in a FeatureConfiguration must be set to &quot;true&quot;."/>
      </eAnnotations>
      <eStructuralFeatures xsi:type="ecore:EReference" name="configuredFeatureModel"
          ordered="false" unique="false" lowerBound="1" eType="#//structure/featuremodeling/FeatureModel"/>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EClass" name="VehicleLevelBinding" eSuperTypes="#//variability/ConfigurationDecisionModel">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="This class represents a ConfigurationDecisionModel on 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 VehicleLevelConfigurationDecisionModel may be used to bridge the gap from vehicle level variability management to that on artifact level.&#xA;&#xA;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).&#xA;&#xA;Constraints:&#xA;[1] The sourceVehicleFeatureModels shall only contain VehicleFeatures.&#xA;[2] The sourceVehicleFeatureModels shall be different from the targetFeatureModels"/>
      </eAnnotations>
      <eStructuralFeatures xsi:type="ecore:EReference" name="sourceVehicleFeatureModel"
          unique="false" upperBound="-1" eType="#//structure/featuremodeling/FeatureModel"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="targetFeatureModel" unique="false"
          upperBound="-1" eType="#//structure/featuremodeling/FeatureModel"/>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EClass" name="ConfigurationDecision" eSuperTypes="#//variability/ConfigurationDecisionModelEntry">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="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: &quot;all North American (USA+Canada) cars except A-Class have cruise control&quot; (one ConfigurationDecision) or &quot;all Canadian cars have adaptive cruise control&quot; (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).&#xA;&#xA;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.) in dependency of a configuration of FM1. In other words, with a ConfigurationDecision we can express something like: &quot;If USA is selected in FM1 AND A-Class is not selected in FM1, then CruiseControl will be selected in FM2&quot;.&#xA;&#xA;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 &quot;USA &amp; not A-Class&quot; and the effect would be &quot;CruiseControl[+]&quot;.&#xA;&#xA;&#xA;Semantics:&#xA;The ConfigurationDecision excludes or includes Features based on a given criterion.&#xA;&#xA;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. &#xA;&#xA;Extension:&#xA;Class"/>
      </eAnnotations>
      <eStructuralFeatures xsi:type="ecore:EAttribute" name="effect" ordered="false"
          unique="false" lowerBound="1" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//String">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The rationale gives the reason for the specified product decision, especially for the inclusion criterion and the selection of included and excluded features."/>
        </eAnnotations>
      </eStructuralFeatures>
      <eStructuralFeatures xsi:type="ecore:EAttribute" name="criterion" ordered="false"
          unique="false" lowerBound="1" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//String">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The inclusionCriterion gives the criterion to select the respective products (e.g. Northern American cars)."/>
        </eAnnotations>
      </eStructuralFeatures>
      <eStructuralFeatures xsi:type="ecore:EAttribute" name="isEquivalence" ordered="false"
          unique="false" lowerBound="1" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//Boolean">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="Means that the included and excluded features are selected if and only if the specified inclusion criterion holds."/>
        </eAnnotations>
      </eStructuralFeatures>
      <eStructuralFeatures xsi:type="ecore:EReference" name="target" unique="false"
          upperBound="-1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//NamedElement"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="selectionCriterion" ordered="false"
          eType="#//variability/SelectionCriterion"/>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EClass" name="SelectionCriterion" eSuperTypes="#//infrastructure/elements/EAElement">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="A mixed string description, identifying the source elements."/>
      </eAnnotations>
      <eStructuralFeatures xsi:type="ecore:EReference" name="source" unique="false"
          upperBound="-1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//NamedElement"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
          unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EClass" name="ConfigurationDecisionFolder" eSuperTypes="#//variability/ConfigurationDecisionModelEntry">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="ConfigurationDecisionFolder represents a grouping for ConfigurationDecisions.&#xA;&#xA;&#xA;Semantics:&#xA;ConfigurationDecisionFolder is a grouping entity for ConfigurationDecisions.&#xA;&#xA;Extension:&#xA;Class"/>
      </eAnnotations>
      <eStructuralFeatures xsi:type="ecore:EReference" name="childEntry" ordered="false"
          upperBound="-1" eType="#//variability/ConfigurationDecisionModelEntry"/>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EClass" name="ContainerConfiguration" eSuperTypes="#//variability/ConfigurationDecisionModel">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="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 contained other ConfigurableContainers. For more details on the variable content of a ConfigurableContainer refer to the documentation of meta-class ConfigurableContainer.&#xA;&#xA;The ContainerConfiguration inherits from ConfigurationDecisionModel even though it does not define a configuration link between feature models, similar as FeatureConfiguration. For more information on this refer to the documentation of meta-class FeatureConfiguration.&#xA;&#xA;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.&#xA;&#xA;Semantics:&#xA;The ContainerConfiguration specifies a concrete configuration of the variable content of a ConfigurableContainer.&#xA;&#xA;Extension:&#xA;Class"/>
      </eAnnotations>
      <eStructuralFeatures xsi:type="ecore:EReference" name="configuredContainer"
          ordered="false" unique="false" lowerBound="1" eType="#//variability/ConfigurableContainer"/>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EClass" name="PrivateContent" eSuperTypes="#//infrastructure/elements/EAElement">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="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.&#xA;&#xA;Refer to the documentation of meta-class ConfigurableContainer for a detailed explanation of how ConfigurableContainer and PrivateContent play together.&#xA;&#xA;Constraint:&#xA;[1] Identifies either one FunctionPrototype or one FunctionPort or one FunctionConnector or one HardwareComponentPrototype or one HardwarePort or one ClampConnector.&#xA;&#xA;Semantics:&#xA;Marks the element identified by association privateElement as private. Otherwise the elements visibility defaults to public.&#xA;&#xA;Extension:&#xA;Class"/>
      </eAnnotations>
      <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
          unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="privateElement" ordered="false"
          unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//NamedElement"/>
    </eClassifiers>
  </eSubpackages>
  <eSubpackages name="infrastructure" nsURI="http://www.papyrusuml.org/EAST-ADL2/Infrastructure/1"
      nsPrefix="Infrastructure">
    <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
      <details key="documentation" value="This section contains the UML-profile specification, specifying stereotypes in the UML-profile, defined from the metaclasses in the ADLCoreConstructs package. It includes specification details for each stereotype. If the stereotype has properties, which may be referred to as tag definitions, or if the stereotype has constraints, this section also includes specification details for these properties and constraints.&#xD;&#xA;&#xD;&#xA;Overview:&#xD;&#xA;This subprofile defines a set of abstract stereotypes which provide basic constructs to the other subprofiles. Two subprofiles are also defined, ADLTypes and ADLRelationshipModeling which are described in the following sections."/>
    </eAnnotations>
    <eClassifiers xsi:type="ecore:EDataType" name="Dummy" instanceClassName="java.lang.String"/>
    <eSubpackages name="datatypes" nsURI="http://www.papyrusuml.org/EAST-ADL2/Infrastructure/Datatypes/1"
        nsPrefix="Datatypes">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="The Datatypes subpackage of EAST-ADL2 defines EAST-ADL2 general-purpose datatypes that may be used to type structural constructs in several different modeling diagrams.&#xA;&#xA;The purpose of the metaclasses in the Datatypes subpackage is to specify the concepts for the specific domain."/>
      </eAnnotations>
      <eClassifiers xsi:type="ecore:EClass" name="EADatatype" abstract="true" eSuperTypes="#//infrastructure/elements/TraceableSpecification">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The EADatatype is a metaclass, which signifies a type whose instances are identified only by their value. The EADatatype metaclass represents the description of the value set for some variable, parameter etc. without a description of how these possible values are represented on implementation level. The implementation representation is defined on implementation level by the AUTOSAR concept PrimitiveTypeWithSemantics, and the implemented datatype shall be associated with a Realization relationship. The realizing datatype must match the EADatatype regarding range, resolution, unit, and dimension.&#xA;&#xA;Semantics:&#xA;EADatatype metaclass is a special kind of classifier, similar to a class. It differs from the class in that instances of a data type are identified only by their value.&#xA;&#xA;Constraints:&#xA;[1] In the case of an AR implementation, an EADatatype is realized generally by PrimitiveTypeWithSemantics, which has to be consistent w.r.t. range, resolution, etc.&#xA;&#xA;Notation:&#xA;The EADatatype is denoted using the rectangle symbol with keyword «Datatype»."/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_DataType" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//DataType"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="EADatatypePrototype" eSuperTypes="#//infrastructure/elements/EAElement">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="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. The EADatatypePrototype is also used to represent argument and return values of operations or to represent a parameter.&#xA;&#xA;Semantics:&#xA;The EADatatypePrototype represents a typed variable. It acts as an occurrence of a datatype.&#xA;&#xA;Extension: Property"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="type" ordered="false"
            unique="false" lowerBound="1" eType="#//infrastructure/datatypes/EADatatype"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Property" ordered="false"
            unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Property"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Parameter" ordered="false"
            unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Parameter"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="ValueType" abstract="true" eSuperTypes="#//infrastructure/datatypes/EADatatype">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="From SysML:&#xA;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 &quot;Real&quot; 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. SysML ValueType adds an ability to carry a unit of measure or dimension associated with the value. 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. A SysML ValueType may define its own properties and/or operations, just as for a UML DataType.&#xA;&#xA;Semantics:&#xA;The abstract ValueType defines types of values that may be used to express information about a system. 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.&#xA;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.&#xA;&#xA;Extension: UML Datatype"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="semantics" ordered="false"
            unique="false" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//String"/>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="dimension" ordered="false"
            unique="false" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//String"/>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="unit" ordered="false"
            unique="false" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//String"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="RangeableDatatype" abstract="true"
          eSuperTypes="#//infrastructure/datatypes/EADatatype">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The stereotype RangeableDatatype reflects numeric datatypes that may have a range (between a minimal and a maximal value). An example for a RangeableDatatype is the Celsius temperature scale with minValue = -273.15.&#xA;&#xA;Semantics:&#xA;The stereotype RangeableDatatype reflects numeric datatypes that may have a range (between a minimal and a maximal value).&#xA;&#xA;&#xA;Extension: UML Datatype"/>
        </eAnnotations>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="RangeableValueType" eSuperTypes="#//infrastructure/datatypes/ValueType">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The RangeableValueType is a specific ValueType applicable for RangeableDatatypes. It provides the possibility to describe the accuracy, resolution, and the significant digits of the baseRangeable datatypes.&#xA;&#xA;Semantics:&#xA;The RangeableValueType adds the ability to describe the accuracy, resolution, and the significant digits of the baseRangeable datatype.&#xA;&#xA;Notation:&#xA;The datatype RangeableValueType is denoted using the rectangle symbol with keyword «Datatype RangeableValueType».&#xA;&#xA;Extension: UML Datatype"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="accuracy" ordered="false"
            unique="false" lowerBound="1" eType="#//infrastructure/datatypes/javalangFloat"/>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="resolution" ordered="false"
            unique="false" lowerBound="1" eType="#//infrastructure/datatypes/javalangFloat"/>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="significantDigits"
            ordered="false" unique="false" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//Integer"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EDataType" name="javalangFloat" instanceClassName="java.lang.Float">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="An instance of Float 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.&#xA;&#xA;Semantics:&#xA;Float has the semantics of the Float datatype as defined by IEEE Standard for Floating-Point Arithmetic (IEEE 754).&#xA;&#xA;Notation:&#xA;The datatype Float is denoted using the rectangle symbol with keyword «Datatype Float».&#xA;&#xA;Extension: UML PrimitiveType"/>
        </eAnnotations>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="EnumerationValueType" eSuperTypes="#//infrastructure/datatypes/ValueType">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="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.&#xA;&#xA;Semantics:&#xA;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.&#xA;&#xA;&#xA;Notation:&#xA;The datatype EnumerationValueType is denoted using the rectangle symbol with keyword «Datatype EnumerationValueType».&#xA;&#xA;Extension: UML Enumeration"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="isMultiValued" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//Boolean"/>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="literalSemantics" unique="false"
            lowerBound="2" upperBound="-1" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//String"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Enumeration" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Enumeration"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="CompositeDatatype" eSuperTypes="#//infrastructure/datatypes/EADatatype">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="A CompositeDatatype represents a non-scalar datatype. Take as an example a CompositeDatatype &quot;MyCountries&quot; that can refer, e.g., to an Enumeration &quot;CountryEnumeration&quot; {USA, Canada, Japan, EU} via two EADatatypePrototypes (record variables): FirstCountry and SecondCountry. Then an attribute typed by this CompositeDatatype &quot;MyCountries&quot; may have a value like: (EU (identified as FirstCountry), Japan (identified as SecondCountry)).&#xA;&#xA;Semantics:&#xA;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).&#xA;&#xA;Notation:&#xA;The datatype CompositeDatatype is denoted using the rectangle symbol with keyword «Datatype CompositeDatatype».&#xA;&#xA;Extension: UML Datatype"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="datatypePrototype"
            lowerBound="1" upperBound="-1" eType="#//infrastructure/datatypes/EADatatypePrototype"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="EAString" eSuperTypes="#//infrastructure/datatypes/EADatatype"/>
      <eClassifiers xsi:type="ecore:EClass" name="EABoolean" eSuperTypes="#//infrastructure/datatypes/EADatatype"/>
      <eClassifiers xsi:type="ecore:EClass" name="EAFloat" eSuperTypes="#//infrastructure/datatypes/RangeableDatatype">
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="min" ordered="false"
            unique="false" eType="#//infrastructure/datatypes/javalangFloat"/>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="max" ordered="false"
            unique="false" eType="#//infrastructure/datatypes/javalangFloat"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="EAInteger" eSuperTypes="#//infrastructure/datatypes/RangeableDatatype">
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="min" ordered="false"
            unique="false" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//Integer"/>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="max" ordered="false"
            unique="false" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//Integer"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="EnumerationLiteral" eSuperTypes="#//infrastructure/elements/EAElement"/>
      <eClassifiers xsi:type="ecore:EClass" name="Enumeration" eSuperTypes="#//infrastructure/datatypes/EADatatype">
        <eStructuralFeatures xsi:type="ecore:EReference" name="literal" ordered="false"
            lowerBound="2" upperBound="-1" eType="#//infrastructure/datatypes/EnumerationLiteral"
            containment="true"/>
      </eClassifiers>
    </eSubpackages>
    <eSubpackages name="userattributes" nsURI="http://www.papyrusuml.org/EAST-ADL2/Infrastructure/UserAttributes/1"
        nsPrefix="UserAttributes">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="User attributes in EAST-ADL2 are primarily intended to provide a mechanism for augmenting the elements of an EAST-ADL2 model with customized meta-information.  All instances of metaclass ADLEntity can have user attributes attached to them.  The scope and structuring of this meta-information can be defined on a per-project basis by defining user attributes for certain types of EAST-ADL2 elements within UATemplates.&#xD;&#xA;Since EAST-ADL2 requirements are in their most general form simple objects with all information contained in user-customized, project-specific attributes, the concept of user attributes is also perfectly suitable to define those attributes of requirements.  In that sense, basic requirements in EAST-ADL2 can be seen as &quot;empty&quot; elements which only provide a node to which user attributes can be attached in order to supply the requirement with all necessary information, including its main textual description.  However, in case of requirements the context in which the available user attributes are defined is different: here the container of the requirements is the point where user attribute definitions are store and these are then applicable only within this container.&#xD;&#xA;The role of user attributes within the overall EAST-ADL2 is thus twofold: they (1) provide a means to customize the language to specific company and project needs and (2) constitute an important part of the requirements support of the language.&#xD;&#xA;The mechanism of user attributes was optimized for flexibility and simplicity.  In particular, the actual attributes attached to an element and/or their values may well conflict the attribute definitions in effect for this element.  For example, it is perfectly legal to not provide an attribute value if an attribute definition was specified or, the other way round, to provide a value for an undefined attribute.  The attribute definitions are merely meant as a guideline for the engineer and as a basis for optionally checking if all attribute values are correct with respect to attribute definitions (by way of appropriate tool support).  With this conception of attribute values and definitions, many intricacies and difficult situations during the creation and evolution of a model are circumvented and complex interdependencies between parts of the model are avoided.  For example, it is made sure that a model and all its user attribute values can be safely viewed and edited even if the attribute definitions (i.e. UATemplates) for the model are temporarily unavailable or permanently lost.&#xD;&#xA;&#xD;&#xA;Overview:&#xD;&#xA;The stereotypes defined in this subprofile provide a set of constructs to help user define their own attributes. The core construct in EAST-ADL2, the ADLEntity, inherits from UserAttributableElement stereotype so that virtually any types of EAST-ADL2 entities might be enhanced with user-defined attributes. Of course in a UML model one is allowed to add attributes to the classes and UML elements on which stereotypes are applied, yet this mechanism enables to distinguish between attributes meant to be interpreted as compliant with EASt-ADL2 language and other if any."/>
      </eAnnotations>
      <eClassifiers xsi:type="ecore:EClass" name="UserAttributeElementType" eSuperTypes="#//infrastructure/elements/EAElement">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="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.&#xA;&#xA;For example, engineers at Volkswagen could create a UserAttributeElementType called &quot;VWFunction&quot; with a single user attribute definition. That way, all FunctionTypes for which &quot;VWFunction&quot; is defined as the UserAttributeElementType via association uaType will have the corresponding user attribute.&#xA;&#xA;User attribute element types can be compared to stereotypes in UML2, but are less rigidly defined.&#xA;&#xA;Extension:&#xA;Class"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="extendedElementType"
            ordered="false" unique="false" eType="#//infrastructure/userattributes/UserAttributeElementType">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="The UAElementTypes this type is inheriting from.&#xA;&#xA;When UAElementType ET2 inherits from type ET1, then this means that all attributes defined for ET1 by way of UserAttributeDefinitions are available whenever ET2 is specified as the type of a user attributeable element (in addition to those directly defined in ET2).  This includes UserAttributeDefinitions which ET1 itself may inherit from other types."/>
          </eAnnotations>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EReference" name="attribute" ordered="false"
            upperBound="-1" eType="#//infrastructure/userattributes/UserAttributeDefinition">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="The attributes defined for this type.&#xA;&#xA;Note that also inherited attribute definitions need to be taken into account."/>
          </eAnnotations>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="validFor" ordered="false"
            unique="false" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//String"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="UserAttributeDefinition" eSuperTypes="#//infrastructure/elements/EAElement">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="UserAttributeDefinition represents a user attribute, i.e. it states that all UserAttributeableElements of a certain UserAttributeElementType are to be attached with an attribute identified by 'key'. For example, it can be specified that certain elements should be amended with an attribute &quot;Status&quot;.&#xA;&#xA;Extension:&#xA;Class, Property"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
            unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="defaultValue" ordered="false"
            unique="false" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//String"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="type" ordered="false"
            unique="false" lowerBound="1" eType="#//infrastructure/datatypes/EADatatype"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Property" ordered="false"
            unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Property"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="UserAttributeableElement">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="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').&#xA;&#xA;IMPORTANT: It is technically possible and legal to attach any key/value pair, even if this is in conflict with the attribute definitions of the UserAttributeElementTypes of this UserAttributeableElement (as defined by association 'uaTypes'). All implementations of this information model must expect such attribute definition violations. The reason for this is that (1) the attribute definitions and the types they define for the attributes are only meant as a guideline for working with user attributes on the modeling level, not as an implementation level type system and (2) this convention avoids a multitude of intricate problems when editing a model's user attribute definitions or values, which significantly simplifies implementation.&#xA;&#xA;&#xA;Extension:&#xA;NamedElement"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="uaValue" ordered="false"
            upperBound="-1" eType="#//infrastructure/userattributes/UserAttributeValue">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="The user attribute values, i.e. key-value pairs, which are attached to this element."/>
          </eAnnotations>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EReference" name="uaType" ordered="false"
            unique="false" upperBound="-1" eType="#//infrastructure/userattributes/UserAttributeElementType">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="The UAElementTypes of this user attirbuteable element.&#xA;&#xA;It is possible to provide more than one type.  In that case, the UserAttributeDefinitions of all UAElementTypes apply.  If there are several attribute definitions with an identical 'key', then the corresponding user attribute will be applied only once."/>
          </eAnnotations>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EReference" name="attributedElement"
            ordered="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//NamedElement"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_NamedElement"
            ordered="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//NamedElement"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="UserAttributeValue" eSuperTypes="#//infrastructure/elements/EAElement">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="UserAttributeValue represents a specific value for a certain user attribute. User attributes are simple key/value pairs which can be attached to all UserAttributeableElements. Each user attribute is identified by a globally unique key.&#xA;&#xA;In principle, there is no restriction which user attributes, i.e. keys, may be attached to a particular element and what strings may be used as value (cf. class UserAttributeableElement). However, user attribute definitions can be used to define a set of legal values for a particular key (see class UserAttributeDefinition) and user attribute element types can be used to state what attributes, i.e. keys, may or should be attached to elements of certain types (cf. class UserAttributeElementType).&#xA;&#xA;The actual value is captured in attribute 'value' and is always represented as a string.&#xA;&#xA;Extension:&#xA;Class, Property"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
            unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="value" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//String"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Property" ordered="false"
            unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Property"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="definition" ordered="false"
            eType="#//infrastructure/userattributes/UserAttributeDefinition"/>
      </eClassifiers>
    </eSubpackages>
    <eSubpackages name="elements" nsURI="http://www.papyrusuml.org/EAST-ADL2/Infrastructure/Elements/1"
        nsPrefix="Elements">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="This section contains the UML-profile specification, specifying stereotypes in the UML-profile, defined from the metaclasses in the Infrastructure::Elements subprofile. It includes specification details for each stereotype. If the stereotype has properties, which may be referred to as tag definitions, or if the stereotype has constraints, this section also includes specification details for these properties and constraints.&#xD;&#xA;&#xD;&#xA;Overview:&#xD;&#xA;The Infrastructure::Elements subprofile of EAST-ADL2 defines general-purpose relationship constructs that may be used to model dependencies between structural constructs.&#xD;&#xA;The purpose of the stereotypes in this subprofile is to specify rigorously (&quot;formally&quot;) the various relationships that may exist between basic constructs."/>
      </eAnnotations>
      <eClassifiers xsi:type="ecore:EClass" name="TraceableSpecification" abstract="true"
          eSuperTypes="#//infrastructure/elements/EAPackageableElement">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The TraceableSpecification is an abstract metaclass which is used to allow its specializations to be allocated to a Context. &#xA;&#xA;Semantics:&#xA;TraceableSpecification is specialized by requirements, test cases and other specifications, that there by can be allocated to a Context, for example to a sensor or to an entire HW architecture.&#xA;&#xA;See Context and Relationship.&#xA;&#xA;&#xA;Changes:&#xA;New class in EAST-ADL2&#xA;&#xA;Extension: &#xA;TraceableSpecification is a specification stereotype which extends UML2 PackageableElement"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="note" ordered="false"
            unique="false" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//String"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="EAPackageableElement" abstract="true"
          eSuperTypes="#//infrastructure/elements/EAElement">
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_PackageableElement"
            ordered="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//PackageableElement"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="Realization" eSuperTypes="#//infrastructure/elements/Relationship">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The Realization is a relationship which relates two or more elements across boundaries of the EAST-ADL2 abstraction levels. &#xA;&#xA;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.&#xA;&#xA;&#xA;Semantics:&#xA;The modification of the supplier realized element impact the realizing client entity. The Realization metaclass implies the semantics that the realizing client is not complete, without the supplier.&#xA;&#xA;Notation:&#xA;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).&#xA;&#xA;Changes:&#xA;Renamed from Realization.&#xA;&#xA;Extension: Realization"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="realized" ordered="false"
            lowerBound="1" upperBound="-1" eType="#//infrastructure/elements/EAElement"
            changeable="false" volatile="true" transient="true" derived="true">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="The set of ADL entities, which are realized by the set of client ADL entities or realized by the set of client AUTOSAR elements.&#xD;&#xA;{derived from UML::DirectedRelationship::target}"/>
          </eAnnotations>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EReference" name="realizedBy" ordered="false"
            upperBound="-1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//NamedElement"
            changeable="false" volatile="true" transient="true" derived="true">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="The set of client ADL entities, realizing the set of supplier ADL entities.&#xD;&#xA;{derived from UML::Dependency::client}"/>
          </eAnnotations>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Realization" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Realization"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="realizedBy_path" upperBound="-1"
            eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//NamedElement"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="realized_path" upperBound="-1"
            eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//NamedElement"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="Relationship" abstract="true" eSuperTypes="#//infrastructure/elements/EAElement">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The Relationship is an abstract metaclass which represents a relationship between arbitrary elements.&#xA;&#xA;Semantics:&#xA;In many cases, Contexts such as functions and sensors need to have requirements and other specification elements allocated them. In other cases, the relation between an element and the related specification element is specific for a certain Context: for example a Requirement on a sensor is only applicable in certain hardware architecture. These relationships are modeled by concrete specializations of Relationship.&#xA;&#xA;See Context and TraceableSpecification.&#xA;&#xA;&#xA;Changes:&#xA;New class in EAST-ADL2&#xA;&#xA;Extension: &#xA;The Relationship stereotype is abstract"/>
        </eAnnotations>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="Context" abstract="true" eSuperTypes="#//infrastructure/elements/EAElement">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="Context represents a simple and practical way to allocate TraceableSpecifications to a specific EAST-ADL2 model context, and to let this specific model context own Relationships.&#xA;&#xA;Semantics:&#xA;See Relationship and TraceableSpecification.&#xA;&#xA;&#xA;Changes:&#xA;New class in EAST-ADL2&#xA;&#xA;Extension: &#xA;The Context stereotype is an abstract stereotype which extends UML2 PackageableElement"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="traceableSpecification"
            ordered="false" unique="false" upperBound="-1" eType="#//infrastructure/elements/TraceableSpecification">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="Traceable specification(s) allocated to this context."/>
          </eAnnotations>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EReference" name="ownedRelationship"
            ordered="false" upperBound="-1" eType="#//infrastructure/elements/Relationship">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="Relationship(s) associated to this context."/>
          </eAnnotations>
        </eStructuralFeatures>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="MultiLevelReference" eSuperTypes="#//infrastructure/elements/Relationship">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="MultiLevelReference gives the possibility to establish reference links (Multi-Level Concept) between model elements."/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Dependency" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Dependency"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="referring" ordered="false"
            lowerBound="1" eType="#//infrastructure/elements/EAElement" changeable="false"
            volatile="true" transient="true" derived="true">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="Referencing the target element of a Multi-Level reference link."/>
          </eAnnotations>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EReference" name="reference" ordered="false"
            lowerBound="1" eType="#//infrastructure/elements/EAElement" changeable="false"
            volatile="true" transient="true" derived="true">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="Referencing the source element of a Multi-Level reference link."/>
          </eAnnotations>
        </eStructuralFeatures>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="Rationale" eSuperTypes="platform:/plugin/org.eclipse.papyrus.sysml/model/sysml.ecore#//modelelements/Rationale"/>
      <eClassifiers xsi:type="ecore:EClass" name="EAPackage" eSuperTypes="#//infrastructure/elements/EAElement">
        <eStructuralFeatures xsi:type="ecore:EReference" name="subPackages" ordered="false"
            upperBound="-1" eType="#//infrastructure/elements/EAPackage" containment="true"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="element" ordered="false"
            upperBound="-1" eType="#//infrastructure/elements/EAPackageableElement"
            containment="true"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Package" ordered="false"
            lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Package"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="Comment">
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="body" ordered="false"
            lowerBound="1" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//String"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Comment" ordered="false"
            lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Comment"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="EAElement" abstract="true">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="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.&#xA;&#xA;The abbreviation EA in the name of this metaclass is short for EAST-ADL.&#xA;&#xA;&#xA;Semantics:&#xA;Also the EAElement can be used to extend the EAST-ADL2 approach to other languages and standards by adding a generalize relation from the respective (non EAST-ADL2) element to the EAElement.&#xA;&#xA;&#xA;Changes:&#xA;New class in EAST-ADL2&#xA;&#xA;Extension: &#xA;The EAElement stereotype is an abstract stereotype"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="name" ordered="false"
            unique="false" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//String"
            volatile="true" transient="true" derived="true"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_NamedElement"
            ordered="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//NamedElement"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="ownedComment" ordered="false"
            upperBound="-1" eType="#//infrastructure/elements/Comment"/>
      </eClassifiers>
    </eSubpackages>
  </eSubpackages>
  <eSubpackages name="structure" nsURI="http://www.papyrusuml.org/EAST-ADL2/Structure/1"
      nsPrefix="Structure">
    <eClassifiers xsi:type="ecore:EDataType" name="Dummy" instanceClassName="java.lang.String">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="Dummy DataType, just added for code generation purpose.&#xD;&#xA;In other words, this data type for EMF generation of SysmlPackage and SysmlFactory&#xD;&#xA;java classes in the model code.&#xD;&#xA;&#xD;&#xA;Do not remove this !!!"/>
      </eAnnotations>
    </eClassifiers>
    <eSubpackages name="functionmodeling" nsURI="http://www.papyrusuml.org/EAST-ADL2/Structure/FunctionModeling/1"
        nsPrefix="FunctionModeling">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="The function modeling is performed in the FunctionalAnalysisArchitecture (in the AnalysisLevel) and the FunctionalDesignArchitecture (in the DesignLevel). The root component of the function compositional hierarchy on AnalysisLevel is the FunctionalAnalysisArchitecture (FAA); the root component of the function compositional hierarchy on DesignLevel is the FunctionalDesignArchitecture (FDA), see the diagram for SystemModeling. &#xA;&#xA;The main modeling concept applied here is functional component modeling: Functions interact with one another via ports that are connected by connectors owned by the composing function. Occurrences of functions are modeled by typed prototypes in the composing function. These occurrences are typed by types. This naming convention of the type-prototype pattern is from AUTOSAR, however the concept of types and typed elements is also available in e.g. UML2."/>
      </eAnnotations>
      <eClassifiers xsi:type="ecore:EClass" name="LocalDeviceManager" eSuperTypes="#//structure/functionmodeling/DesignFunctionType">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The LocalDeviceManager represents a DesignFunction that act as a manager or functional interface to Sensors, Actuators and other devices. It is responsible fort 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. &#xA;&#xA;&#xA;Semantics:&#xA;The LocalDeviceManager encapsulates the device-specific or functional parts of a Sensor or, Actuator, device, etc. interface.&#xA;&#xA;&#xA;Constraints:&#xA;[1] A DesignFunctionPrototype typed by a LocalDeviceManager shall be allocated to the same ECU node as the device that it manages is connected to.&#xA;&#xA;[2] A LocalDeviceManager may only interface either Sensors or Actuators.&#xA;&#xA;[3] A LocalDeviceManager shall interface BSWFunctions and DesignFunctions. &#xA;&#xA;&#xA;Extension: Class, specialization of SysML::Block"/>
        </eAnnotations>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="DesignFunctionType" eSuperTypes="#//structure/functionmodeling/FunctionType">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="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 from the type-prototype pattern used by AUTOSAR.&#xA;&#xA;The DesignFunctions may interact with other DesignFunctions (i.e., also BasicSoftwareFunctions, HardwareFunctions, and LocalDeviceManager) through their FunctionPorts.&#xA;&#xA;Furthermore, a DesignFunction may be decomposed into (sub-)DesignFunctions. This allows breaking up hierarchically the functionalities provided by the parent DesignFunction into subfunctionalities.&#xA;&#xA;Execution time constraints on the DesignFunctionType can be expressed by ExecutionTimeConstraints, see the Timing package.&#xA;&#xA;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).&#xA;&#xA;&#xA;Semantics:&#xA;The DesignFunctionType represents a node in a tree structure corresponding to the functional decomposition of a top level DesignFunction. The DesignFunction is representing 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.&#xA;&#xA;Constraints:&#xA;[1] DesignFunctionTypes may only be used on DesignLevel.&#xA;&#xA;&#xA;&#xA;Extension: UML Class, specialization of SysML::Block"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="part" ordered="false"
            upperBound="-1" eType="#//structure/functionmodeling/DesignFunctionPrototype"
            changeable="false" volatile="true" transient="true" derived="true"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="FunctionType" abstract="true" eSuperTypes="#//infrastructure/elements/Context platform:/plugin/org.eclipse.papyrus.sysml/model/sysml.ecore#//blocks/Block">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="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.&#xA;&#xA;FunctionBehavior and FunctionTrigger in the Behavior package are associated to a FunctionType.&#xA;&#xA;&#xA;Semantics:&#xA;The FunctionType abstracts the function component types that are used to model the functional structure on AnalysisLevel and DesignLevel.&#xA;Leaf functions of an EAST-ADL2 function hierarchy are called elementary Functions.&#xA;Elementary Functions have synchronous execution semantics:&#xA;1. Read inputs&#xA;2. Execute (duration: Execution time)&#xA;3. Write outputs&#xA;Execution is defined by a behavior that acts as a transfer function.&#xA;Subclasses of the abstract class FunctionType add their own semantics.&#xA;&#xA;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:&#xA;&#xA;1. Input that arrives at the input FunctionPorts after execution begins will be ignored until the next execution cycle.&#xA;&#xA;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).&#xA;&#xA;3. The local part of a FunctionPort does not change its value during execution of the behavior.&#xA;&#xA;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).&#xA;&#xA;5. Output will not be available at an output FunctionPort before execution ends.&#xA;&#xA;6. Elementary FunctionTypes may not produce any side effects (i.e., all data passes the FunctionPorts).&#xA;&#xA;&#xA;Constraints:&#xA;[1] Elementary FunctionTypes shall not have parts.&#xA;&#xA;Notation:&#xA;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 its FunctionConnectors (White-box view)&#xA;&#xA;Extension: UML Class, specialization of SysML::Block"/>
        </eAnnotations>
        <eOperations name="getIcon" ordered="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Image"/>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="isElementary" ordered="false"
            lowerBound="1" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//Boolean"
            changeable="false" volatile="true" transient="true" defaultValueLiteral="false"
            derived="true"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="port" ordered="false"
            upperBound="-1" eType="#//structure/functionmodeling/FunctionPort" changeable="false"
            volatile="true" transient="true" derived="true">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="Owned in- and out-flow ports.&#xD;&#xA;{derived from UML::EncapsulatedClassifier::ownedPort}"/>
          </eAnnotations>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EReference" name="portGroup" ordered="false"
            upperBound="-1" eType="#//structure/functionmodeling/PortGroup" changeable="false"
            volatile="true" transient="true" derived="true">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="Grouping of ports owned by this element.&#xD;&#xA;{derived from UML::Class::nestedClassifier}"/>
          </eAnnotations>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EReference" name="connector" ordered="false"
            upperBound="-1" eType="#//structure/functionmodeling/FunctionConnector"
            changeable="false" volatile="true" transient="true" derived="true"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="FunctionPort" abstract="true" eSuperTypes="#//infrastructure/elements/EAElement">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The ports conserve variables for component interaction."/>
        </eAnnotations>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="PortGroup" eSuperTypes="#//infrastructure/elements/EAElement">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The ADLPortGroup metaclass is used to collapse several ports to one. All ports that are part of a port group are graphically represented as a single port. Connectors connected to ports of a port group pair are graphically collapsed to a single line.&#xD;&#xA;The ADLPortGroup has no semantic meaning except that it makes graphical representation of the connected ports easier to read, and provides a means to logically organize several ports to one group.&#xD;&#xA;Connectors are still connected to the contained ports, but tool support may simplify connections by allowing semi-automatic or automatic connection to all ports of a port group. &#xD;&#xA;&#xD;&#xA;Semantics:&#xD;&#xA;The ADLPortGroup provides a means to organize ports and connectors. It does not add semantics. In the model, the ports contained in the port group are connected as individual ports."/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="port" ordered="false"
            lowerBound="1" upperBound="-1" eType="#//structure/functionmodeling/FunctionPort"
            changeable="false" volatile="true" transient="true" derived="true">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="The grouped ports.&#xD;&#xA;{derived from UML::EncapsulatedClassifier::ownedPort} when this stereotype is applied on a Class. When the stereotype is applied on a Port the value is derived from the ports in the type."/>
          </eAnnotations>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
            unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Port" ordered="false"
            unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Port"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="portGroup" ordered="false"
            upperBound="-1" eType="#//structure/functionmodeling/PortGroup"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="FunctionConnector" eSuperTypes="#//infrastructure/elements/EAElement #//structure/functionmodeling/AllocateableElement">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The FunctionConnector indicates that the connected FunctionPorts exchange signals or client-server requests/responses.&#xA;&#xA;Semantics:&#xA;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 occurrence of the FunctionType that specifies the occurrence of the FunctionPrototype has to be identified by the FunctionConnector as well.&#xA;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.&#xA;&#xA;&#xA;Constraints:&#xA;[1] Can connect two FunctionFlowPorts of different direction when this is an assembly FunctionConnector.&#xA;&#xA;[2] Can connect two FunctionFlowPorts of the same direction when this is a delegation FunctionConnector.&#xA;&#xA;[3] Can connect two ClientServerPorts of different kind when this is an assembly FunctionConnector.&#xA;&#xA;[4] Can connect two ClientServerPorts of the same kind when this is a delegation FunctionConnector.&#xA;&#xA;[5] Can connect two FunctionFlowPorts with direction inout.&#xA;&#xA;Notation: FunctionConnector is shown as a solid line&#xA;&#xA;Extension: UML Connector"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="port" ordered="false"
            upperBound="2" eType="#//structure/functionmodeling/FunctionPort" changeable="false"
            volatile="true" transient="true" derived="true">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="The ports that are connected by this connector.&#xD;&#xA;{derived from UML::Connector::end}"/>
          </eAnnotations>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Connector" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Connector"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="port1_path" upperBound="-1"
            eType="#//structure/functionmodeling/FunctionPrototype"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="port2_path" upperBound="-1"
            eType="#//structure/functionmodeling/FunctionPrototype"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="AllocateableElement" abstract="true">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The AllocateableElement is an abstract superclass for elements that are allocateable.&#xA;&#xA;Semantics:&#xA;The AllocateableElement abstracts all elements that are allocateable.&#xA;Subclasses of the abstract class AllocateableElement add their own semantics.&#xA;&#xA;Extension: abstract, no extension"/>
        </eAnnotations>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="FunctionPrototype" abstract="true"
          eSuperTypes="#//infrastructure/elements/EAElement">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="FunctionPrototype represents a reference to the occurrence of a FunctionType when it acts as a part.&#xA;&#xA;The FunctionPrototype is typed by a FunctionType.&#xA;&#xA;FunctionTrigger in the Behavior package is associated to a FunctionPrototype.&#xA;&#xA;&#xA;&#xA;Semantics:&#xA;The FunctionPrototype represents an occurrence of the FunctionType that types it.&#xA;&#xA;Notation:&#xA;Shall be shown in the same style as the class specified as type, however it shall be clear that this is a part.&#xA;&#xA;Changes:&#xA;Renamed from ADLFunctionPart&#xA;&#xA;Extension: &#xA;To specialize SysML::BlockProperty, which extends Property"/>
        </eAnnotations>
        <eOperations name="getIcon" ordered="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Image"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Property" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Property"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="DesignFunctionPrototype" eSuperTypes="#//structure/functionmodeling/FunctionPrototype #//structure/functionmodeling/AllocateableElement">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The DesignFunctionPrototype represents references to the occurrence of the DesignFunctionType that types it when it acts as a part.&#xA;The DesignFunctionPrototype is typed by a DesignFunctionType .&#xA;&#xA;Semantics:&#xA;The DesignFunctionPrototype represents an occurrence of the DesignFunctionType that types it.&#xA;&#xA;Extension:&#xA;UML Property, specialization of SysML::BlockProperty"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="type" ordered="false"
            unique="false" lowerBound="1" eType="#//structure/functionmodeling/DesignFunctionType"
            changeable="false" volatile="true" transient="true" derived="true"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="FunctionalDevice" eSuperTypes="#//structure/functionmodeling/AnalysisFunctionType">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="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). As such, it is a transfer function between the AnalysisFunction and the physical entity that it measures or actuates.&#xA;A Realization dependency can be used for traceability between LocalDeviceManagers and Sensors/Actuators that are represented by the FunctionalDevice.&#xA;&#xA;Semantics:&#xA;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).&#xA;&#xA;Constraints:&#xA;No additional constraints.&#xA;&#xA;Changes:&#xA;Now specializes AnalysisFunctionType.&#xA;&#xA;Extension: Class, specialization of SysML::Block"/>
        </eAnnotations>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="AnalysisFunctionType" eSuperTypes="#//structure/functionmodeling/FunctionType">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="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.&#xA;&#xA;The AnalysisFunctions may interact with other AnalysisFunctions (i.e., also FunctionalDevices) through their FunctionPorts.&#xA;&#xA;Furthermore, an AnalysisFunction may be decomposed into (sub-)AnalysisFunctions. This allows breaking up hierarchically the functionalities provided by the parent AnalysisFunction into subfunctionalities.&#xA;&#xA;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 subAnalysisFunction. If the AnalysisFunction is not decomposed (i.e., if the AnalysisFunction is elementary), then the behavior is describing the behavior of the subAnalysisFunction, which is to be used when building the global behavior of the FunctionalAnalysisArchitecture by composition of the leaf behaviors.&#xA;&#xA;&#xA;Semantics:&#xA;The AnalysisFunctionType represents a node in a tree structure corresponding to the functional decomposition of a top level AnalysisFunction. The AnalysisFunction is representing 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. &#xA;&#xA;Constraints:&#xA;[1] AnalysisFunctionTypes may only be used on AnalysisLevel.&#xA;&#xA;&#xA;Extension: UML Class, specialization of SysML::Block"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="part" ordered="false"
            upperBound="-1" eType="#//structure/functionmodeling/AnalysisFunctionPrototype"
            changeable="false" volatile="true" transient="true" derived="true"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="AnalysisFunctionPrototype" eSuperTypes="#//structure/functionmodeling/FunctionPrototype">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The AnalysisFunctionPrototype represents references to the occurrence of the AnalysisFunctionType that types it when it acts as a part.&#xA;&#xA;The AnalysisFunctionPrototype is typed by an AnalysisFunctionType.&#xA;&#xA;&#xA;Semantics:&#xA;The AnalysisFunctionPrototype represents an occurrence of the AnalysisFunctionType that types it.&#xA;&#xA;&#xA;Extension:&#xA;UML Property, specialization of SysML::BlockProperty"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="type" ordered="false"
            unique="false" lowerBound="1" eType="#//structure/functionmodeling/AnalysisFunctionType"
            changeable="false" volatile="true" transient="true" derived="true"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="FunctionFlowPort" eSuperTypes="platform:/plugin/org.eclipse.papyrus.sysml/model/sysml.ecore#//portandflows/FlowPort #//structure/functionmodeling/FunctionPort">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The FunctionFlowPort is a metaclass for flowports, inspired by the SysML FlowPort.&#xA;&#xA;Semantics:&#xA;FunctionFlowPorts are single buffer overwrite and nonconsumable.&#xA;&#xA;FunctionFlowPorts can be connected if their FunctionPort signatures match; i.e.:&#xA;&#xA;EADatatypes that are ValueTypes are compatible if&#xA;&#xA;* They have the same &quot;dimension&quot;.&#xA;&#xA;* They have the same &quot;unit&quot;.&#xA;&#xA;EADatatypes that are RangeableValueTypes are compatible if&#xA;&#xA;* The source EADatatype has the same or better &quot;accuracy&quot;.&#xA;&#xA;* They have the same baseRangeable.&#xA;&#xA;* The source EADatatype has the same or smaller &quot;maxValue&quot;.&#xA;&#xA;* The source EADatatype has the same or higher &quot;minValue&quot;.&#xA;&#xA;* The source EADatatype has the same or higher &quot;resolution&quot;.&#xA;&#xA;* They have the same &quot;significantDigits&quot;.&#xA;&#xA;EADatatypes that are EnumerationValueTypes are compatible if&#xA;&#xA;* They have the same baseEnumeration.&#xA;&#xA;FunctionFlowPort with direction=in, is called an input FunctionFlowPort:&#xA;&#xA;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.&#xA;&#xA;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.&#xA;&#xA;FunctionFlowPort with direction=out, is called an output FunctionFlowPort:&#xA;&#xA;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.&#xA;&#xA;The output FunctionFlowPort declares a transmission point of data. The type of the data is defined by the associated EADatatype.&#xA;&#xA;&#xA;Extension: UML Port, specialization of SysML::FlowPort"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="type" ordered="false"
            unique="false" lowerBound="1" eType="#//infrastructure/datatypes/EADatatype"
            changeable="false" volatile="true" transient="true" derived="true"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="FunctionClientServerPort" eSuperTypes="#//structure/functionmodeling/FunctionPort">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The FunctionClientServerPort is a FunctionPort for client-server interaction. A number of FunctionClientServerPorts of clientServerType &quot;client&quot; can be connected to one FunctionClientServerPort of clientServerType &quot;server&quot;, i.e. when connected the multiplicity for the connection is n to 1 for client and server.&#xA;&#xA;Semantics: &#xA;The FunctionClientServerPort is a FunctionPort for client-server interaction.&#xA;&#xA;FunctionClientServerPorts are single buffer overwrite and nonconsumable.&#xA;&#xA;Constraints:&#xA;[1] A FunctionClientServerPort of clientServerType &quot;client&quot; can only be connected to one FunctionClientServerPort of clientServerType &quot;server&quot;.&#xA;&#xA;Extension: UML Port"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="type" ordered="false"
            lowerBound="1" eType="#//structure/functionmodeling/FunctionClientServerInterface"
            changeable="false" volatile="true" transient="true" derived="true">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="The interface of this port.&#xD;&#xA;&#xD;&#xA;{derived from UML::TypedElement::type}"/>
          </eAnnotations>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Port" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Port"/>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="clientServerType" ordered="false"
            unique="false" lowerBound="1" eType="#//structure/functionmodeling/ClientServerKind"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="FunctionClientServerInterface" eSuperTypes="#//infrastructure/elements/EAElement">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The FunctionClientServerInterface is used to specify the operations in FunctionClientServerPorts.&#xA;&#xA;Semantics:&#xA;The operations of the FunctionClientServerInterface are required or provided through the FunctionClientServerPorts typed by the FunctionClientServerInterface.&#xA;&#xA;Extension: UML Interface"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Interface" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Interface"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="operation" ordered="false"
            upperBound="-1" eType="#//structure/functionmodeling/Operation" changeable="false"
            volatile="true" transient="true" derived="true"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="Operation" eSuperTypes="#//infrastructure/elements/EAElement">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The Operation is the provided/required operation of a FunctionClientServerInterface. It can specify its return values and arguments by EADatatypePrototypes.&#xA;&#xA;Semantics: &#xA;The Operation is the provided/required operation of a FunctionClientServerInterface.&#xA;&#xA;Extension: UML Operation"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Operation" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Operation"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="argument" upperBound="-1"
            eType="#//infrastructure/datatypes/EADatatypePrototype" changeable="false"
            volatile="true" transient="true" derived="true"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="return" ordered="false"
            eType="#//infrastructure/datatypes/EADatatypePrototype" changeable="false"
            volatile="true" transient="true" derived="true"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EEnum" name="ClientServerKind">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="This element is an enumeration for the kind of the FunctionClientServerPort, which can either be a &quot;client&quot; or a &quot;server&quot;.&#xA;&#xA;Semantics:&#xA;The ClientServerKind is an enumeration with the two literals &quot;client&quot; and &quot;server&quot;.&#xA;&#xA;Extension: &#xA;Enumeration, no extension."/>
        </eAnnotations>
        <eLiterals name="client"/>
        <eLiterals name="server" value="1"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EEnum" name="EADirectionKind">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="This element is an enumeration for the direction of a Port, which can either be &quot;in&quot;, &quot;out&quot;, or &quot;inout&quot;.&#xA;&#xA;Semantics:&#xA;The EADirectionKind is an enumeration with the three literals &quot;in&quot;, &quot;out&quot;, and &quot;inout&quot;.&#xA;&#xA;Extension: &#xA;Enumeration, no extension."/>
        </eAnnotations>
        <eLiterals name="in"/>
        <eLiterals name="out" value="1"/>
        <eLiterals name="inout" value="2"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="BasicSoftwareFunctionType" eSuperTypes="#//structure/functionmodeling/DesignFunctionType">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The BasicSoftwareFunctionType is an abstraction of middleware functionality.&#xA;&#xA;Semantics:&#xA;The BasicSoftwareFunctionType is an abstraction of the middleware.&#xA;&#xA;Extension: &#xA;UML Class, specialization of SysML::Block"/>
        </eAnnotations>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="HardwareFunctionType" eSuperTypes="#//structure/functionmodeling/DesignFunctionType">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="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 DesignFunctionPrototype is typically the end of the ClampConnector on DesignLevel.&#xA;&#xA;Prototypes typed by HardwareComponentType may be allocated to HardwareComponents in which case the HardwareFunctionType must match the HardwareFunctionType of the target HardwareComponent.&#xA;&#xA;DesignFunctionPrototypes typed by HardwareFunctionType may be allocated to HardwareComponents in which case the HardwareFunctionType must match the HardwareFunctionType of the target HardwareComponent.&#xA;&#xA;Constraints:&#xA;[1] A DesignFunctionPrototype typed by a HardwareFunctionType shall be connected to the EnvironmentModel via ClampConnectors and to BSWFunctions via FunctionConnectors.&#xA;&#xA;Semantics: &#xA;The HardwareFunctionHardwareFunctionType is the transfer function for hardware components such as sensors, actuators, amplifiers, etc or a specification of an intended transfer function. &#xA;&#xA;HardwareFunctions can be allocated to Sensors or Actuators, i.e. the interfacing element to the plant model.&#xA;&#xA;&#xA;Extension: &#xA;UML Class, specialization of SysML::Block"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="hardwareComponent"
            ordered="false" unique="false" eType="#//structure/hardwaremodeling/HardwareComponentType"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="FunctionAllocation" eSuperTypes="#//infrastructure/elements/EAElement">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="FunctionAllocation represents an allocation constraint binding an AllocateableElement on an AllocationTarget.&#xA;&#xA;The same constraint could be expressed in a textual design constraint.&#xA;&#xA;Semantics:&#xA;AllocationTarget is specialized by HardwareComponentPrototype in the HardwareModeling package and AllocateableElement is specialized by the concrete elements DesignFunctionPrototype and FunctionConnector in the FunctionModeling package.&#xA;&#xA;Notation:&#xA;A FunctionAllocation is shown as a dependency (dashed line) with an &quot;allocation&quot; keyword attached to it.&#xA;&#xA;&#xA;Extension: Class, specializesDesignConstraint&#xA;target to AUTOSAR::ECUResourceTemplate::ECU&#xA;allocatedAutosarComponent to AUTOSAR::Components::ClientPort&#xA;&#xA;ToDo:&#xA;Cf. AUTOSAR SWMapping::MappingConstraint"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="target" ordered="false"
            unique="false" lowerBound="1" eType="#//structure/hardwaremodeling/AllocationTarget"
            changeable="false" volatile="true" transient="true" derived="true">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="The ECU where the functionality must be allocated."/>
          </eAnnotations>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EReference" name="allocatedElement" ordered="false"
            unique="false" lowerBound="1" eType="#//structure/functionmodeling/AllocateableElement"
            changeable="false" volatile="true" transient="true" derived="true"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Dependency" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Dependency"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="allocatedElement_path"
            upperBound="-1" eType="#//structure/functionmodeling/AllocateableElement"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="target_path" upperBound="-1"
            eType="#//structure/hardwaremodeling/AllocationTarget"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="Allocation" eSuperTypes="#//infrastructure/elements/EAElement">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The Allocation element contains functionAllocations. It can bundle functionAllocations that belong together, e.g., all functionAllocations for a simulation.&#xA;&#xA;Semantics:&#xA;The Allocation element contains functionAllocations, i.e., it can bundle functionAllocations that belong together.&#xA;&#xA;Extension: Class"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
            unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Package" ordered="false"
            unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Package"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="functionAllocation"
            ordered="false" upperBound="-1" eType="#//structure/functionmodeling/FunctionAllocation"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="FunctionPowerPort" eSuperTypes="#//structure/functionmodeling/FunctionPort">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The FunctionPowerPort is a FunctionPort for denoting the physical interactions between environment and sensing/actuation functions.&#xA;&#xA;Semantics: &#xA;The FunctionPowerPort conserves physical variables in a dynamic process.&#xA;&#xA;The typing Datatype owns two datatypePrototypes 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.&#xA;&#xA;Constraints:&#xA;[1] The owner of a FunctionPowerPort is either a FunctionalDevice, a HardwareFunctionType, or a FunctionType for environment &#xA;&#xA;[2] Two connected FunctionPowerPort must have the same Datatype.&#xA;&#xA;[3] The typing Datatype shall have two datatypePrototypes called Across and Through, with Datatypes that are consistent and representing the variables of the PowerPort. &#xA;&#xA;&#xA;Extension: UML Port"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Port" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Port"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="type" ordered="false"
            unique="false" lowerBound="1" eType="#//infrastructure/datatypes/CompositeDatatype"
            changeable="false" volatile="true" transient="true" derived="true"/>
      </eClassifiers>
    </eSubpackages>
    <eSubpackages name="hardwaremodeling" nsURI="http://www.papyrusuml.org/EAST-ADL2/Structure/HardwareModeling/1"
        nsPrefix="HardwareModeling">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="The package HardwareModeling contains the elements to model physical entities of the embedded EE system. These elements allow capturing the hardware in sufficient detail to allow preliminary allocation decisions. &#xA;&#xA;The allocation decisions are based on requirements on timing, storage, data throughput, processing power, etc. that are defined in the Functional Analysis Architecture and the Functional Design Architecture.&#xA;&#xA;Conversely, the Functional Analysis Architecture and the Functional Design Architecture may be revised based on analysis using information from the Hardware Design Architecture. An example is control law design, where algorithms may be modified for expected computational and communication delays. Thus, the Hardware Design Architecture contains information about properties in order to support, e.g., timing analysis and performance in these respects."/>
      </eAnnotations>
      <eClassifiers xsi:type="ecore:EClass" name="HardwareConnector" eSuperTypes="#//infrastructure/elements/EAElement">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="Hardware connectors represent wires that electrically connect the hardware components through its ports.&#xA;&#xA;Semantics:&#xA;The connector joins the two referenced ports electrically, with a resistance defined by the resistance attribute.&#xA;&#xA;Extension:&#xA;Connector"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Connector" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Connector"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="port" ordered="false"
            unique="false" lowerBound="2" upperBound="2" eType="#//structure/hardwaremodeling/HardwarePin"
            volatile="true" transient="true" derived="true"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="port1_path" upperBound="-1"
            eType="#//structure/hardwaremodeling/HardwareComponentPrototype"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="port2_path" upperBound="-1"
            eType="#//structure/hardwaremodeling/HardwareComponentPrototype"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="HardwarePin" abstract="true" eSuperTypes="#//infrastructure/elements/EAElement">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="HardwarePin represents electrical connection points in the hardware architecture. Depending on modeling style, the actual wire or a logical connection can be considered.&#xA;&#xA;Semantics&#xA;Hardware pin represents an electrical connection point.&#xA;&#xA;Extension:&#xA;Port"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Port" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Port"/>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="isGround" ordered="false"
            unique="false" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//Boolean">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="Indicates that the pin is connected to ground."/>
          </eAnnotations>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="voltage" ordered="false"
            unique="false" eType="#//infrastructure/datatypes/javalangFloat">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="The maximal voltage in Volts provided by the pin. Shall not be defined if isGround=TRUE."/>
          </eAnnotations>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="direction" ordered="false"
            unique="false" lowerBound="1" eType="#//structure/functionmodeling/EADirectionKind">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="The direction of current through the pin."/>
          </eAnnotations>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="impedance" ordered="false"
            unique="false" eType="#//infrastructure/datatypes/javalangFloat">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="The internal impedance in Ohms to ground of the component as seen through this pin."/>
          </eAnnotations>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="power" ordered="false"
            unique="false" eType="#//infrastructure/datatypes/javalangFloat">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="The maximal power in watts that can be provided by this pin or that is consumed."/>
          </eAnnotations>
        </eStructuralFeatures>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="HardwareComponentPrototype" eSuperTypes="#//structure/hardwaremodeling/AllocationTarget">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="Appear as parts 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. &#xA;&#xA;Semantics:&#xA;The HardwareComponentPrototype represents an occurrence of a hardware element, according to the type of the HardwareComponentPrototype. &#xA;&#xA;Notation:&#xA;Shall be shown in the same style as the class specified as type, however it shall be clear that this is a part.&#xA;&#xA;Extension: Property"/>
        </eAnnotations>
        <eOperations name="getIcon" ordered="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Image"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="type" ordered="false"
            unique="false" lowerBound="1" eType="#//structure/hardwaremodeling/HardwareComponentType"
            changeable="false" volatile="true" transient="true" derived="true">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="The type of the HWElement.&#xD;&#xA;{derived from UML::TypedElement::type}"/>
          </eAnnotations>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Property" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Property"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="AllocationTarget" abstract="true"
          eSuperTypes="#//infrastructure/elements/EAElement">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The AllocationTarget is a superclass for elements to which AllocateableElements can be allocated. &#xA;&#xA;Semantics:&#xA;An AllocationTarget is a resource element in the Hardware Design Architecture which may host functional behaviors in the Functional Design Architecture.&#xA;&#xA;Extension: abstract, no extension"/>
        </eAnnotations>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="IOHardwarePin" eSuperTypes="#//structure/hardwaremodeling/HardwarePin">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="IOHardwarePin represents an electrical connection point for digital or analog I/O. &#xA;&#xA;Semantics:&#xA;The IOHardwarePin represents an electrical pin or connection point. &#xA;&#xA;Notation:&#xA;IOHardwarePin is shown as a solid square with an IO inside. Its name may appear outside the square."/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="type" ordered="false"
            unique="false" lowerBound="1" eType="#//structure/hardwaremodeling/IOHardwarePinKind">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="kind defines whether the IOHardwarePort is digital, analog or PWM (Pulse Width Modulated)."/>
          </eAnnotations>
        </eStructuralFeatures>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EEnum" name="IOHardwarePinKind">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="IOHardwarePinKind is an enumeration type representing different kinds of I/O Hardware Ports.&#xA;&#xA;Extension: &#xA;Enumeration, no extension."/>
        </eAnnotations>
        <eLiterals name="digital">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="I/O with fixed amplitude."/>
          </eAnnotations>
        </eLiterals>
        <eLiterals name="analog" value="1">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="I/O with varying amplitude."/>
          </eAnnotations>
        </eLiterals>
        <eLiterals name="pwm" value="2">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="PWM (Pulse Width Modulated) modulated I/O, i.e. a signal with fixed frequency and amplitude but varying duty cycle."/>
          </eAnnotations>
        </eLiterals>
        <eLiterals name="other" value="3">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="Another type of I/O port."/>
          </eAnnotations>
        </eLiterals>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="PowerHardwarePin" eSuperTypes="#//structure/hardwaremodeling/HardwarePin">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="PowerHardwarePin represents a pin that is primarily intended for power supply, either providing or consuming energy.&#xA;&#xA;Semantics:&#xA;A PowerHardwarePin is primarily intended to be a power supply. The direction attribute of the pin defines whether it is providing or consuming energy &#xA;&#xA;Notation:&#xA;PowerHardwarePin is shown as a solid square with PWR inside. Its name may appear outside the square."/>
        </eAnnotations>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="CommunicationHardwarePin" eSuperTypes="#//structure/hardwaremodeling/HardwarePin">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="CommunicationHardwarePin represents an electrical connection point that can be used to define how the wire harness is logically defined. &#xA;&#xA;Semantics:&#xA;The CommunicationHardwarePin represents the hardware connection point of a communication bus. &#xA;&#xA;Depending on modeling style, one or two pins may be defined for a dual-wire bus.&#xA;&#xA;Notation:&#xA;CommunicationHardwarePin is shown as a solid square with a C inside. Its name may appear outside the square."/>
        </eAnnotations>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="Node" eSuperTypes="#//structure/hardwaremodeling/HardwareComponentType">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="Node represents the computer nodes of the embedded EE system. Nodes consist of processor(s) and may be connected to sensors, actuators and other ECUs via a BusConnector.&#xA;&#xA;Node denotes an electronic control unit that acts as a computing element executing Functions. In case a single CPU-single core ECU is represented, it is sufficient to have a single, non-hierarchical Node. &#xA;&#xA;Semantics:&#xA;The Node element represents an ECU, i.e. an Electronic Control Unit and an allocation target of FunctionPrototypes.&#xA;&#xA;The Node executes its allocated FunctionPrototypes at the specified executionRate. The executionRate denotes how many execution seconds of an allocated functionPrototype´s execution time that is processed each real-time second. Actual execution time is thus found by dividing the parameters of the ExecutionTimeConstraint with executionRate.&#xA;&#xA;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.&#xA;&#xA;Notation:&#xA;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."/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="executionRate" ordered="false"
            unique="false" lowerBound="1" eType="#//infrastructure/datatypes/javalangFloat"
            defaultValueLiteral="1">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="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."/>
          </eAnnotations>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="nonVolatileMemory"
            ordered="false" unique="false" lowerBound="1" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//Integer">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="The size in Bytes of the Node’s Non-Volatile memory (ROM, NRAM, EPROM, etc ."/>
          </eAnnotations>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="volatileMemory" ordered="false"
            unique="false" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//Integer">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="The size in Bytes of the Node’s Volatile memory (RAM)"/>
          </eAnnotations>
        </eStructuralFeatures>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="PowerSupply" eSuperTypes="#//structure/hardwaremodeling/HardwareComponentType">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="PowerSupply represents a hardware element that supplies power.&#xA;&#xA;Semantics:&#xA;PowerSupply denotes a power source that may be active (e.g., a battery) or passive (main relay).&#xA;&#xA;Notation:&#xA;PowerSupply is shown as a solid-outline rectangle with &quot;PWR&quot; at the top right. The rectangle contains the name, and its ports or port groups on the perimeter."/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="isActive" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//Boolean">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="Indicates if the PowerSupply is active or passive."/>
          </eAnnotations>
        </eStructuralFeatures>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="Sensor" eSuperTypes="#//structure/hardwaremodeling/HardwareComponentType">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="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. &#xA;&#xA;Semantics:&#xA;Sensor denotes an electrical sensor. The Sensor represents the physical and electrical aspects of sensor hardware. The logical aspect is represented by an HWFunctionType associated to the Sensor.&#xA;&#xA;Notation:&#xA;Sensor is shown as a Circle or oval. The circle contains the name, and its ports or port groups on the perimeter."/>
        </eAnnotations>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="Actuator" eSuperTypes="#//structure/hardwaremodeling/HardwareComponentType">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="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. &#xA;&#xA;Semantics:&#xA;The Actuator metaclass represents the physical and electrical aspects of actuator hardware. The logical aspect is represented by a HWFunctionType associated to the Actuator.&#xA;&#xA;Notation:&#xA;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."/>
        </eAnnotations>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="LogicalBus" eSuperTypes="#//structure/hardwaremodeling/AllocationTarget">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The LogicalBus represents logical communication channels. It serves as an allocation target for connectors, i.e. the data exchanged between functions in the FunctionalDesignArchitecture. &#xA;&#xA;&#xA;Semantics:&#xA;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. &#xA;&#xA;Extension: &#xA;Class"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="busSpeed" ordered="false"
            unique="false" lowerBound="1" eType="#//infrastructure/datatypes/javalangFloat"/>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="busType" ordered="false"
            unique="false" lowerBound="1" eType="#//structure/hardwaremodeling/LogicalBusKind"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="wire" unique="false"
            upperBound="-1" eType="#//structure/hardwaremodeling/HardwareConnector"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="wire_path" upperBound="-1"
            eType="#//structure/hardwaremodeling/HardwareComponentPrototype"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EEnum" name="LogicalBusKind">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="LogicalBusKind is an enumeration type representing different kinds of busses.&#xA;&#xA;Extension: &#xA;Enumeration, no extension."/>
        </eAnnotations>
        <eLiterals name="TimeTriggered">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="Bus is time-triggered"/>
          </eAnnotations>
        </eLiterals>
        <eLiterals name="EventTriggered" value="1">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="Bus is event-triggered"/>
          </eAnnotations>
        </eLiterals>
        <eLiterals name="TimeandEventTriggered" value="2">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="Bus is both time and event-triggered"/>
          </eAnnotations>
        </eLiterals>
        <eLiterals name="other" value="3">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="Another type of bus communication"/>
          </eAnnotations>
        </eLiterals>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="HardwarePinGroup" eSuperTypes="#//infrastructure/elements/EAElement">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="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, join connectors that go between pins in pin groups to a single line. &#xA;&#xA;Semantics:&#xA;A HardwarePinGroup has no semantics, but is only a grouping mechanism that may affect visualization and port operations in tools.&#xA;&#xA;Extension:&#xA;Class"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Port" ordered="false"
            unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Port"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
            unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="portGroup" ordered="false"
            upperBound="-1" eType="#//structure/hardwaremodeling/HardwarePinGroup"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="port" ordered="false"
            unique="false" upperBound="-1" eType="#//structure/hardwaremodeling/HardwarePin"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="HardwareComponentType" eSuperTypes="#//infrastructure/elements/Context">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The HardwareComponentType represents hardware element on an abstract level, allowing preliminary engineering activities related to hardware.&#xA;&#xA;Semantics:&#xA;The HardwareElementType 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 an HWFunctionType referencing the HardwareElementType. This is typically connected through its ports to the environment model to participate in the end-to-end behavioral definition of a function. &#xA;&#xA;&#xA;Extension:&#xA;Class"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="connector" ordered="false"
            unique="false" upperBound="-1" eType="#//structure/hardwaremodeling/HardwareConnector"
            changeable="false" volatile="true" transient="true" derived="true">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="The HWConnectors.&#xD;&#xA;{derived from UML::StructuredClassifier::ownedConnector}"/>
          </eAnnotations>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EReference" name="port" ordered="false"
            upperBound="-1" eType="#//structure/hardwaremodeling/HardwarePin" changeable="false"
            volatile="true" transient="true" derived="true">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="The Ports.&#xD;&#xA;{derived from UML::EncapsulatedClassifier::ownedPort}"/>
          </eAnnotations>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EReference" name="part" ordered="false"
            upperBound="-1" eType="#//structure/hardwaremodeling/HardwareComponentPrototype"
            changeable="false" volatile="true" transient="true" derived="true">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="The HWElementPrototypes.&#xD;&#xA;{derived from UML::Classifier::attribute}"/>
          </eAnnotations>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="bus" ordered="false"
            upperBound="-1" eType="#//structure/hardwaremodeling/LogicalBus"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="portGroup" ordered="false"
            upperBound="-1" eType="#//structure/hardwaremodeling/HardwarePinGroup"/>
      </eClassifiers>
    </eSubpackages>
    <eSubpackages name="systemmodeling" nsURI="http://www.papyrusuml.org/EAST-ADL2/Structure/SystemModeling/1"
        nsPrefix="SystemModeling">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="The ADLSystemModel is the top level container of an EAST-ADL2 model. It represents the electronics &amp; software of the vehicle, and its environment, and concepts related to the various abstraction level of models used in EAST-ADL2. It is mainly based on both concepts: Models and architectures.&#xD;&#xA;VehicleFeatureModel represents the features of the vehicle, i.e. the externally visible properties&#xD;&#xA;The AnalysisArchitecture is the abstract functional description of the vehicle electronics&#xD;&#xA;The DesignArchitecture contains the functional specification and hardware architecture of the vehicle electronics&#xD;&#xA;The Implementation Architecture contains the software architecture and components and the hardware architecture of the vehicle&#xD;&#xA;The Operational Architecture represents the actual software and electronics in the manufactured vehicle&#xD;&#xA;The word model vs. architecture is chosen rather informally. Architecture is used where this term is often used in practice, and where the construct is a complete (in some sense) reflection of the aspects that it captures. Model is used in other cases.&#xD;&#xA;These models/architectures contain further elements in a hierarchy.. Relations between these elements over the boundaries between the models/architectures are contained in the ADLSystemModel. This is possible because the SystemModel is a specialization of the ADLContext, and is thus able to contain relations. Typical relations are described in the sub-package CoreConstructs (see definition of ADLRelationship, ADLRealization and ADLSatisfy).&#xD;&#xA;&#xD;&#xA;Overview:&#xD;&#xA;The ADLSystemModel is the top level container of an EAST-ADL2 model. It represents the electronics &amp; software of the vehicle, and its environment, and concepts related to the various abstraction level of models used in EAST-ADL2. It is mainly based on both concepts: Models and architectures."/>
      </eAnnotations>
      <eClassifiers xsi:type="ecore:EClass" name="SystemModel" eSuperTypes="#//infrastructure/elements/Context">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="SystemModel is used to organize models/architectures according to their abstraction level; it can also hold with relationships between the different levels.&#xA;&#xA;Semantics:&#xA;The SystemModel represents the EE system of the vehicle, and concepts related to the various abstraction levels.&#xA;&#xA;Notation:&#xA;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 its connectors (White-box view).&#xA;&#xA;Changes: New class in EAST-ADL2&#xA;&#xA;Extension: Class"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="implementationLevel"
            ordered="false" eType="#//structure/systemmodeling/ImplementationLevel">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="The Implementation Architecture abstraction level."/>
          </eAnnotations>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EReference" name="analysisLevel" ordered="false"
            eType="#//structure/systemmodeling/AnalysisLevel">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="The AnalysisArchitecture contained in the SystemModel and connected to the EnvironmentModel through ports-connectors"/>
          </eAnnotations>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EReference" name="designLevel" ordered="false"
            eType="#//structure/systemmodeling/DesignLevel">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="The designArchitecture contained in the SystemModel and connected to the EnvironmentModel through ports-connectors"/>
          </eAnnotations>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EReference" name="vehicleLevel" ordered="false"
            eType="#//structure/systemmodeling/VehicleLevel">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="The Vehicle Feature Model contained in the SystemModel."/>
          </eAnnotations>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
            unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Package" ordered="false"
            unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Package"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="ImplementationLevel" eSuperTypes="#//infrastructure/elements/Context">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="ImplementationLevel represents the software architecture and components, and the hardware architecture of the EE system in the vehicle. The ImplementationLevel is defined by the AUTOSAR System- and SoftwareArchitecture. For example, functions of the Functional Design Architecture 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.&#xA;&#xA;&#xA;Extension: Class"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="autosarSystem" ordered="false"
            unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//NamedElement"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
            unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Package" ordered="false"
            unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Package"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="AnalysisLevel" eSuperTypes="#//infrastructure/elements/Context">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="AnalysisLevel represents the vehicle EE system in terms of its abstract functional definition. It includes the functional analysis architecture (FAA) which represents the abstract functional structure.&#xA;&#xA;Semantics:&#xA;AnalysisLevel represents the vehicle EE system in terms of its abstract functional definition. It defines the logical functionality and a logical decomposition of functionality down to the appropriate granularity.&#xA;&#xA;Notation:&#xA;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 its connectors (White-box view).&#xA;&#xA;Extension:&#xA;Class"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
            unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Package" ordered="false"
            unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Package"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="functionalAnalysisArchitecture"
            ordered="false" eType="#//structure/functionmodeling/AnalysisFunctionPrototype"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="DesignLevel" eSuperTypes="#//infrastructure/elements/Context">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="DesignLevel represents the vehicle EE system on the design abstraction level. It includes primarily the Functional Design Architecture (FDA), and the HardwareDesignArchitecture (HDA).&#xA;&#xA;FDA represents a top level Function. It is supposed to implement all the functionalities of a vehicle, as specified by a Functional Analysis Architecture or a Vehicle level (if no Functional Analysis Architecture has been defined during the process).&#xA;&#xA;The design level in EAST-ADL2 includes the design architecture containing the functional specification and hardware architecture of the vehicle EE system. The design architecture includes the Functional Design Architecture 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- and the ones on the analysis level. &#xA;&#xA;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.&#xA;&#xA;The Functional Design Architecture parts are typed by FunctionTypes and LocalDeviceManagers. The view of the HardwareArchitecture facilitates the realization of LocalDeviceManager as sensor/actuator HW elements.&#xA;&#xA;The HDA is the hardware design from a system perspective. The HDA has two purposes:&#xA;&#xA;1) It shows the physical entities and how they are connected.&#xA;&#xA;2) It is an allocation target for the Functions of the Functional Design Architecture.&#xA;&#xA;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. &#xA;&#xA;Semantics:&#xA;The DesignLevel is the representation of the vehicle EE system on the design abstraction level. It corresponds to the design of logical functions and boundaries extended in regards to resource commitment.&#xA;&#xA;Notation:&#xA;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 its connectors (White-box view).&#xA;&#xA;&#xA;Extension: Class"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
            unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Package" ordered="false"
            unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Package"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="functionalDesignArchitecture"
            ordered="false" eType="#//structure/functionmodeling/DesignFunctionPrototype"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="hardwareDesignArchitecture"
            ordered="false" eType="#//structure/hardwaremodeling/HardwareComponentPrototype"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="allocation" ordered="false"
            upperBound="-1" eType="#//structure/functionmodeling/Allocation"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="VehicleLevel" eSuperTypes="#//infrastructure/elements/Context">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="VehicleLevel represents an arbitrary set of feature models containing only VehicleFeatures.&#xA;&#xA;Constraints:&#xA;[1] All contained feature models are FeatureModels that only contain VehicleFeatures.&#xA;&#xA;Semantics:&#xA;The VehicleLevel contains the technical feature models.&#xA;&#xA;Extension: class."/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Package" ordered="false"
            unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Package"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
            unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="technicalFeatureModel"
            ordered="false" upperBound="-1" eType="#//structure/featuremodeling/FeatureModel"/>
      </eClassifiers>
    </eSubpackages>
    <eSubpackages name="vehiclefeaturemodeling" nsURI="http://www.papyrusuml.org/EAST-ADL2/Structure/VehicleFeatureModeling/1"
        nsPrefix="VehicleFeatureModeling">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="At the highest abstraction level, i.e. the vehicle level, EAST-ADL2 provides support for classification and definition of product lines (the entire vehicle for a car maker or some of its sub-systems for suppliers). The different possible configurations of the embedded electronic architecture are captured on a high abstraction level in terms of features. A feature in this sense is a characteristic or trait that individual variants of the vehicle may or may not have.&#xA;&#xA;The specification of the features themselves, together with their forms of realization, the dependencies between them and the requirements to be respected for their realization is performed at the vehicle level and it should be done independently of any product line. This would be the basis for a consistent reuse of features in different product lines and projects. At this level, a feature represents particular high level requirements to be realized in all product line members that respect some conditions, e.g., US cars with elegance trim and engine size higher than 2.4."/>
      </eAnnotations>
      <eClassifiers xsi:type="ecore:EClass" name="DeviationAttributeSet" eSuperTypes="#//infrastructure/elements/EAElement">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="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 might be possible.&#xA;&#xA;Extension:&#xA;DataType"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="allowChangeAttribute"
            ordered="false" lowerBound="1" eType="#//structure/vehiclefeaturemodeling/DeviationPermissionKind"
            defaultValueLiteral="YES"/>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="allowChangeCardinality"
            ordered="false" lowerBound="1" eType="#//structure/vehiclefeaturemodeling/DeviationPermissionKind"
            defaultValueLiteral="YES"/>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="allowChangeDescription"
            ordered="false" lowerBound="1" eType="#//structure/vehiclefeaturemodeling/DeviationPermissionKind"
            defaultValueLiteral="YES"/>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="allowChangeName" ordered="false"
            lowerBound="1" eType="#//structure/vehiclefeaturemodeling/DeviationPermissionKind"
            defaultValueLiteral="YES"/>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="allowMove" ordered="false"
            lowerBound="1" eType="#//structure/vehiclefeaturemodeling/DeviationPermissionKind"
            defaultValueLiteral="YES"/>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="allowReduction" ordered="false"
            lowerBound="1" eType="#//structure/vehiclefeaturemodeling/DeviationPermissionKind"
            defaultValueLiteral="YES"/>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="allowRefinement" ordered="false"
            lowerBound="1" eType="#//structure/vehiclefeaturemodeling/DeviationPermissionKind"
            defaultValueLiteral="YES"/>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="allowRegrouping" ordered="false"
            lowerBound="1" eType="#//structure/vehiclefeaturemodeling/DeviationPermissionKind"
            defaultValueLiteral="YES"/>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="allowRemoval" ordered="false"
            lowerBound="1" eType="#//structure/vehiclefeaturemodeling/DeviationPermissionKind"
            defaultValueLiteral="YES"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_DataType" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//DataType"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="feature" ordered="false"
            unique="false" lowerBound="1" eType="#//structure/vehiclefeaturemodeling/VehicleFeature"
            eOpposite="#//structure/vehiclefeaturemodeling/VehicleFeature/deviationAttributeSet">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="The deviation attributes belong to vehicle features that are part of a reference feature model in the context of multi-level feature models. The attribute can constrain the allowed deviation for the respective referring features."/>
          </eAnnotations>
        </eStructuralFeatures>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EEnum" name="DeviationPermissionKind">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="Possible values for deviation attributes.&#xD;&#xA;&#xD;&#xA;Semantics:&#xD;&#xA;DeviationPermissionKind has no specific semantics. Further subclasses of DeviationPermissionKind will add semantics appropriate to the concept they represent."/>
        </eAnnotations>
        <eLiterals name="no">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="The deviation is not allowed."/>
          </eAnnotations>
        </eLiterals>
        <eLiterals name="subtree" value="1">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="In case of deviation attribute &quot;allowMove&quot;: the parent of the VehicleFeature may be changed, but the original parent must remain a predecessor (i.e. moving the VehicleFeature itself is allowed but it may only be moved further down within the same subtree).&#xA;&#xA;In case of deviation attribute &quot;allowReduction&quot;: the children of the VehicleFeature may be moved elsewhere, but they must remain successors of the VehicleFeature (i.e. moving them away is allowed but they may only be moved further down within the same subtree).&#xA;&#xA;This kind is only applicable to deviation attributes &quot;allowMove&quot; and &quot;allowReduction&quot;."/>
          </eAnnotations>
        </eLiterals>
        <eLiterals name="append" value="2">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="The name, description or other attribute may only be changed by appending text without changing the original text. This kind is only applicable to deviation attributes &quot;allowChangeName&quot;, &quot;allowChangeDescription&quot; and &quot;allowChangeAttribute&quot;."/>
          </eAnnotations>
        </eLiterals>
        <eLiterals name="subset" value="3">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="The cardinality may only be changed such that the new cardinality is a subset of the original cardinality. This kind is only applicable to deviation attribute &quot;allowChangeCardinality&quot;."/>
          </eAnnotations>
        </eLiterals>
        <eLiterals name="yes" value="4">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="The deviation is allowed."/>
          </eAnnotations>
        </eLiterals>
        <eLiterals name="widen" value="5">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="Feature groups may only be widened, i.e. it is only legal to add features into a feature group that were not grouped before, but not to ungroup features. This kind is only applicable to deviation attribute 'allowRegrouping'."/>
          </eAnnotations>
        </eLiterals>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="VehicleFeature" eSuperTypes="#//structure/featuremodeling/Feature">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="VehicleFeature represents a special kind of feature intended for use on the vehicle level. The main difference to features in general is that they provide support for the multi-level concept (with their DeviationAttributeSet) and several additional attributes with meta-information specific to the vehicle level viewpoint.&#xA;&#xA;&#xA;Constraints:&#xA;[1] VehicleFeatures can only be contained in FeatureModels on VehicleLevel.&#xA;&#xA;Semantics:&#xA;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.&#xA;&#xA;Extension:&#xA;Class"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="isDesignVariabilityRationale"
            ordered="false" lowerBound="1" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//Boolean"/>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="isCustomerVisible"
            ordered="false" lowerBound="1" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//Boolean"/>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="isRemoved" ordered="false"
            lowerBound="1" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//Boolean"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="deviationAttributeSet"
            ordered="false" eType="#//structure/vehiclefeaturemodeling/DeviationAttributeSet"
            eOpposite="#//structure/vehiclefeaturemodeling/DeviationAttributeSet/feature">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="The deviation attributes belong to vehicle features that are part of a reference feature model in the context of multi-level feature models. The attribute can constrain the allowed deviation for the respective referring features."/>
          </eAnnotations>
        </eStructuralFeatures>
      </eClassifiers>
    </eSubpackages>
    <eSubpackages name="featuremodeling" nsURI="http://www.papyrusuml.org/EAST-ADL2/Structure/FeatureModeling/1"
        nsPrefix="FeatureModeling">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="This package describes the basic feature modeling that is employed on the vehicle level as well as on the artifact levels, i.e. on AnalysisLevel and below. Details of feature modeling that are specific to the vehicle level are factored out and documented separately in the package VehicleFeatureModeling."/>
      </eAnnotations>
      <eClassifiers xsi:type="ecore:EClass" name="FeatureModel" eSuperTypes="#//infrastructure/elements/Context">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="FeatureModel denotes a model owning Features. The FeatureModel can be used to describe variability and commonality of a specified EE-System at any abstraction level in the SystemModel.&#xA;&#xA;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).&#xA;&#xA;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 &quot;coarse-grained requirements&quot;. 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-ADL2 are primarily motivated by variability definition and management.&#xA;&#xA;A public, local FeatureModel of an artifact element realizes a VehicleFeature of the VehicleLevel.&#xA;&#xA;&#xA;Semantics:&#xA;The FeatureModel has no specific semantics. Further subclasses of FeatureModel will add semantics appropriate to the concept they represent.&#xA;&#xA;&#xA;Extension:&#xA;Package"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Package" ordered="false"
            unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Package"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
            unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="rootFeature" ordered="false"
            upperBound="-1" eType="#//structure/featuremodeling/Feature"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="featureLink" ordered="false"
            upperBound="-1" eType="#//structure/featuremodeling/FeatureLink"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="featureConstraint"
            ordered="false" upperBound="-1" eType="#//structure/featuremodeling/FeatureConstraint"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="Feature" eSuperTypes="#//structure/featuremodeling/FeatureTreeNode">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="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.&#xA;&#xA;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.&#xA;&#xA;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.&#xA;&#xA;&#xA;Semantics:&#xA;Feature is a (non)functional characteristic, constraint or property that can be present or not in a (vehicle) product line.&#xA;&#xA;&#xA;Extension:&#xA;Class"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="cardinality" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//String">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="The Cardinality describes for a feature its cardinality. In the context of a feature group it describes the variability behavior of the group (e.g. a cardinality of 1 in a feature group means that one of the child features has to be selected). Cardinalities for features: A cardinality of 0..1 at a feature means that this feature is optional. A cardinality of 1 means that this feature is mandatory and a cardinality of 0..n with n>1 means that this feature may be instantiated more than once in the product to be realized.&#xA;Note that allowing cardinalities >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 a complianceLevel in FeatureModel."/>
          </eAnnotations>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EReference" name="requiredBindingTime"
            ordered="false" eType="#//structure/featuremodeling/BindingTime">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="The required binding time could possibly deviate from the actual binding time but reflects the intended binding time and actual binding time can be later adapted to the required binding time, if surrounding constraints allow a change."/>
          </eAnnotations>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EReference" name="actualBindingTime"
            ordered="false" lowerBound="1" eType="#//structure/featuremodeling/BindingTime">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="The actual binding time, independent of the required binding time."/>
          </eAnnotations>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EReference" name="featureParameter" ordered="false"
            eType="#//infrastructure/datatypes/EADatatypePrototype"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="childNode" ordered="false"
            upperBound="-1" eType="#//structure/featuremodeling/FeatureTreeNode"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="FeatureTreeNode" abstract="true"
          eSuperTypes="#//infrastructure/elements/Context">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The abstract base class for all nodes in a feature tree.&#xA;&#xA;&#xA;Semantics:&#xA;FeatureTreeNode has no specific semantics. Further subclasses of FeatureTreeNode will add semantics appropriate to the concept they represent.&#xA;&#xA;&#xA;Extension: &#xA;abstract, no extension"/>
        </eAnnotations>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="BindingTime" eSuperTypes="#//infrastructure/elements/EAElement">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The motivation for attributing features and variable elements with binding times is that binding times encapsulate important information about the variability under view:&#xA;&#xA;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.&#xA;&#xA;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:&#xA;&#xA;-&#x9;SystemDesignTime&#xA;-&#x9;CodeGenerationTime&#xA;-&#x9;PreCompileTime&#xA;-&#x9;LinkTime&#xA;-&#x9;PostBuild&#xA;-&#x9;Runtime&#xA;&#xA;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.&#xA;&#xA;Each feature must have a binding time (association requiredBindingTime) and may have one further binding time (association actualBindingTime).&#xA;&#xA;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 and what the reasons are for a (different) actual binding time.&#xA;&#xA;Extension:&#xA;Class."/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="kind" ordered="false"
            lowerBound="1" eType="#//structure/featuremodeling/BindingTimeKind" defaultValueLiteral="systemDesignTime">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="The kind of the binding time, see enumeration of binding times."/>
          </eAnnotations>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EEnum" name="BindingTimeKind">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="BindingTimeKind represents the set of possible binding times."/>
        </eAnnotations>
        <eLiterals name="systemDesignTime">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="Variability will be bound during development of the EE-System.&#xA;&#xA;From AUTOSAR:&#xA;* Designing the VFB.&#xA;* Software Component types (portinterfaces).&#xA;* SWC Prototypes and the Connections between SWCprototypes.&#xA;* Designing the Topology&#xA;* ECUs and interconnecting Networks&#xA;* Designing the Communication Matrix and Data Mapping"/>
          </eAnnotations>
        </eLiterals>
        <eLiterals name="codeGenerationTime" value="1">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="Variability will be bound during code generation.&#xA;&#xA;From AUTOSAR:&#xA;* Coding by hand, based on requirements document.&#xA;* Tool based code generation, e.g. from a model.&#xA;* The model may contain variants.&#xA;* Only code for the selected variant(s) is actually generated."/>
          </eAnnotations>
        </eLiterals>
        <eLiterals name="precompileTime" value="2">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="Variability will be bound during or immediately prior to code compilation.&#xA;&#xA;From AUTOSAR:&#xA;This is typically the C-Preprocessor. Exclude parts of the code from the compilation process, e.g., because they are not required for the selected variant, because they are incompatible with the selected variant, because they require resources that are not present in the selected variant. Object code is only generated for the selected variant(s). The code that is excluded at this stage code will not be available at later stages."/>
          </eAnnotations>
        </eLiterals>
        <eLiterals name="linkTime" value="3">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="Variability will be bound during linking.&#xA;&#xA;From AUTOSAR:&#xA;Configure what is included in object code, and what is omitted&#xA;Based on which variant(s) are selected&#xA;E.g. for modules that are delivered as object code (as opposed to those that are delivered as source code)"/>
          </eAnnotations>
        </eLiterals>
        <eLiterals name="postBuild" value="4">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="Variability will be bound at certain occasions after shipment, for example when the vehicle is in a workshop."/>
          </eAnnotations>
        </eLiterals>
        <eLiterals name="runtime" value="5">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="Variability will be bound by the customer after shipment by way of vehicle configuration.&#xA;&#xA;Variability with such a late binding time can also be seen as a special functionality of the system which is not documented as variability at all. However, it is sometimes advantageous to represent such cases as variability in order to be able to seamlessly include them in the overall variability management activities."/>
          </eAnnotations>
        </eLiterals>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="FeatureLink" eSuperTypes="#//infrastructure/elements/Relationship">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="A FeatureLink resembles a Relationship between two Features referred to as 'start' and 'end' feature (such as &quot;feature S requires feature E&quot; or &quot;S excludes E&quot;).&#xA;&#xA;The type of the FeatureLink specifies the precise semantics of the relationship. There are several predefined types, for example &quot;needs&quot; 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.&#xA;&#xA;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).&#xA;&#xA;&#xA;Semantics:&#xA;The FeatureLink is a relationship between Features that may constraint the selection of Features involved in the relationship.&#xA;&#xA;&#xA;Constraints:&#xA;[1] The start and end Features of a FeatureLink must be contained in the FeatureModel that contains the FeatureLink.&#xA;&#xA;Extension:&#xA;AssociationClass"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="isBidirectional" ordered="false"
            eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//Boolean"/>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="customType" ordered="false"
            lowerBound="1" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//String"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Dependency" ordered="false"
            unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Dependency"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="start" ordered="false"
            unique="false" lowerBound="1" eType="#//structure/featuremodeling/Feature"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="end" ordered="false"
            unique="false" lowerBound="1" eType="#//structure/featuremodeling/Feature"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_AssociationClass"
            ordered="false" unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//AssociationClass"/>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="kind" ordered="false"
            unique="false" lowerBound="1" eType="#//structure/featuremodeling/VariabilityDependencyKind"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="FeatureConstraint" eSuperTypes="#//infrastructure/elements/EAElement">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="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."/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="criterion" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//String"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
            unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Constraint" ordered="false"
            unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Constraint"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="FeatureGroup" eSuperTypes="#//structure/featuremodeling/FeatureTreeNode">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="FeatureGroup is a specialization of the FeatureTreeNode, enabling grouping of several Features. It specifies with its cardinality how these grouped features can be combined. For example, a FeatureGroup owning the two Features A and B, with a cardinality of [1] means that A and B are alternative.&#xA;&#xA;&#xA;Semantics:&#xA;FeatureGroup is a grouping entity for sibling Features to reflect variability for a set of Features.&#xA;&#xA;&#xA;Extension:&#xA;Class"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="cardinality" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//String">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="The Cardinality describes for a feature group its cardinality. It describes the variability behavior of the group (e.g. a cardinality of 1 in a feature group means that one of the child features has to be selected)."/>
          </eAnnotations>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EReference" name="childFeature" ordered="false"
            lowerBound="2" upperBound="-1" eType="#//structure/featuremodeling/Feature"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EEnum" name="VariabilityDependencyKind">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="This enumeration encapsulates the available types of constraints that can be applied to a FeatureLink or VariationGroup (the latter is applicable only if the variability extension is used).&#xA;&#xA;Semantics:&#xA;Predefined kinds of constraints that can be associated to a FeatureLink or VariationGroup.&#xA;&#xA;Extension: &#xA;Enumeration, no extension."/>
        </eAnnotations>
        <eLiterals name="needs">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="When used in a FeatureLink: if the FeatureLink's start feature S is selected, then also its end feature E must be selected: not (S and not E). Always unidirectional.&#xA;&#xA;When used in a VariationGroup: assuming the ordered association variableElement in meta-class VariationGroup refers to elements VE1, VE2, ..., VEn, this kind states that VE1 requires (i.e. may not appear without) all other elements VE2, VE3, ..., VEn."/>
          </eAnnotations>
        </eLiterals>
        <eLiterals name="optionalAlternative" value="1">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="When used in a FeatureLink: the FeatureLink's start feature S and end feature E are incompatible and must never be both selected in a single configuration: not (S and E). Always bidirectional.&#xA;&#xA;When used in a VariationGroup: this kind states that at most(!) one element of the elements denoted by association variableElement of the VariationGroup must be selected in any valid final system configuration."/>
          </eAnnotations>
        </eLiterals>
        <eLiterals name="custom" value="2">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="When used in a FeatureLink: the attribute customType in the FeatureLink defines the custom feature link type as explained there.&#xA;&#xA;When used in a VariationGroup: this kind states that the dependency between the elements denoted by association variableElement of the VariationGroup will be defined by a logical expression in attribute 'constraint' of the VariationGroup."/>
          </eAnnotations>
        </eLiterals>
        <eLiterals name="mandatoryAlternative" value="3">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="When used in a FeatureLink: either the FeatureLink's start feature S or its end feature E must be selected in any configuration: S xor E. Always bidirectional.&#xA;&#xA;When used in a VariationGroup: this kind states that exactly(!) one element of the elements denoted by association variableElement of the VariationGroup must be selected in any valid final system configuration."/>
          </eAnnotations>
        </eLiterals>
        <eLiterals name="suggests" value="4">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="Weak form of &quot;needs&quot;. &#xA;&#xA;When used in a FeatureLink: if the FeatureLink's start feature S is selected, then usually(!) also its end feature E must be selected. You can select S without E but you should have a good reason to do so. Always unidirectional.&#xA;&#xA;When used in a VariationGroup: accordingly as above."/>
          </eAnnotations>
        </eLiterals>
        <eLiterals name="impedes" value="5">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="Weak from of &quot;excludes&quot;.&#xA;&#xA;When used in a FeatureLink: the FeatureLink's start feature S and its end feature E must usually(!) not be selected in a single configuration. You can select S together with E but you should have a good reason to do so. Always bidirectional.&#xA;&#xA;When used in a VariationGroup: accordingly as above."/>
          </eAnnotations>
        </eLiterals>
      </eClassifiers>
    </eSubpackages>
  </eSubpackages>
  <eSubpackages name="behavior" nsURI="http://www.papyrusuml.org/EAST-ADL2/Behavior/1"
      nsPrefix="Behavior">
    <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
      <details key="documentation" value="This chapter describes the behavioral constructs of the EAST-ADL2 language. What we mean by behavior here is either a function performing some computation on provided data (FlowPort interaction) or the execution of a service called upon by another function (in a ClientServer interaction).&#xA;&#xA;The execution of the behavior assumes a strict run-to-completion, single buffer-overwrite management of data. That is each execution starts with the reading of data, which are not stored locally and are constantly replaced by fresher data arriving on ports. The function then performs some calculation and finally outputs some data on the output ports. The execution is non-concurrent: only one behavior is active at any point in time and not preemptable.&#xA;&#xA;A FunctionBehavior in EAST-ADL2 is mainly a reference point to some description provided else where in a tool-dependent format, as depicted in the Diagram for FunctionBehavior below. This enables to re-use current behavior descriptions contained in the tools currently used by automotive companies and suppliers. Given that, requirement and traceability information can be provided for behavior in relation to the rest of the EAST-ADL2 model. A list of typical tool format is provided as an enumeration, FunctionBehaviorKind. Depending on the EAST-ADL2 language implementation such a behavior description can be provided in the model itself, for instance when using a UML-implementation of the EAST-ADL2, UML behaviors can be used. Yet it shall be noted that the behavior described shall be compliant with the execution semantics of an EAST-ADL2 function.&#xA;&#xA;The rest of the behavioral constructs (see the first following Diagram of the behavior of a function) relate to the organization of the triggering of behaviors attached to functions. At a high level one can define activation Modes which may span across the whole architecture. Such Modes can be regrouped in exclusive sets. Whenever a FunctionTrigger or a FunctionBehavior refers to a Mode, this means its activation is dependent on the Mode being active or not. Thus different execution configurations can be defined.&#xA;&#xA;The triggering of behavior itself, defined by FunctionTrigger, can be either time or event-based and be either type-wise or prototype-wise to allow further adjustments of functions in a particular context. Events and timing constraint that are defined in separate sections of the language (see Events, Time and TimingConstraints sections)."/>
    </eAnnotations>
    <eClassifiers xsi:type="ecore:EClass" name="FunctionBehavior" eSuperTypes="#//infrastructure/elements/Context">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="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 with the purpose of containing information about and links to the external behavioral model.&#xA;&#xA;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).&#xA;&#xA;The triggering of a FunctionBehavior is unknown to the behavior. It is defined by FunctionTriggers (see this element).&#xA;&#xA;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-ADL2 language specification does not require that 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.&#xA;&#xA;Although each FunctionBehavior can refer to at most one FunctionType, note that several FunctionBehaviors can be referring 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-ADL2 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, etc. must prevent two behaviors being potentially active.&#xA;&#xA;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.&#xA;&#xA;In the case where the identified FunctionType is decomposed in parts, the behavior is a specification for the composed behavior of the FunctionType. &#xA;&#xA;&#xA;Semantics:&#xA;Though the representation provided to a FunctionBehavior follows the semantics of the behavioral representation used (for instance SIMULINK, ASCET, etc.). Externally, in relation to the EAST-ADL2 model, however, the FunctionBehavior has synchronous execution semantics:&#xA;1. Read inputs from input ports&#xA;2. Execute Behavior with fixed inputs (run to completion)&#xA;3. Provide outputs to output ports&#xA;&#xA;The data transfer between the EAST-ADL2 ports and the FunctionBehavior is representation specific and considered part of the execution of the FunctionBehavior.&#xA;&#xA;&#xA;&#xA;Notation:&#xA;FunctionBehavior appears, if shown in a diagram, as a solid-outline rectangle with &quot;Behavior&quot; at the top right. The rectangle contains the name. &#xA;&#xA;&#xA;Extension: Behavior"/>
      </eAnnotations>
      <eStructuralFeatures xsi:type="ecore:EReference" name="base_Behavior" ordered="false"
          unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Behavior"/>
      <eStructuralFeatures xsi:type="ecore:EAttribute" name="path" ordered="false"
          unique="false" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//String">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The path to the file or model entity containing the ExternalBehavior"/>
        </eAnnotations>
      </eStructuralFeatures>
      <eStructuralFeatures xsi:type="ecore:EAttribute" name="representation" ordered="false"
          unique="false" lowerBound="1" eType="#//behavior/FunctionBehaviorKind">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The type of behavior that the ExternalBehavior represents."/>
        </eAnnotations>
      </eStructuralFeatures>
      <eStructuralFeatures xsi:type="ecore:EReference" name="mode" ordered="false"
          unique="false" upperBound="-1" eType="#//behavior/Mode"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="function" ordered="false"
          unique="false" eType="#//structure/functionmodeling/FunctionType"/>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EEnum" name="FunctionBehaviorKind">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="FunctionBehaviorKind is an enumeration which lists the various representations, used to describe a FunctionBehavior. It is used as a property of a FunctionBehavior. Several representations are listed; however one can always extend this list by using the literal OTHER. &#xA;&#xA;Semantics:&#xA;Distinction between UML and MARTE comes from the slight differences in the behavioral definitions (namely concerning data-flow oriented behaviors).&#xA;&#xA;It shall be noted that though one can use several languages to provide a representation of a FunctionBehavior, the semantics shall remain compliant with the overall EAST-ADL2 execution semantics.&#xA;&#xA;Extension: &#xA;Enumeration, no extension."/>
      </eAnnotations>
      <eLiterals name="ASCET"/>
      <eLiterals name="OTHER" value="1"/>
      <eLiterals name="SCADE" value="2"/>
      <eLiterals name="SDL" value="3"/>
      <eLiterals name="SIMULINK" value="4"/>
      <eLiterals name="STATEMATE" value="5"/>
      <eLiterals name="MARTE" value="6"/>
      <eLiterals name="UML" value="7"/>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EClass" name="Mode" eSuperTypes="#//infrastructure/elements/EAElement">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="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.&#xA;&#xA;Modes are characterized by a Boolean condition provided as a String which evaluates to true when the Mode is active.&#xA;&#xA;As far as behavior is concerned, Modes enable to logically organize a set of triggers and behaviors over a set of functions. Modes are both referred to by FunctionTriggers and FunctionBehaviors, thus capturing this organization (see FunctionTrigger and FunctionBehavior).&#xA;&#xA;Modes can be further organized in mutually exclusive sets with ModeGroups (see that element).&#xA;&#xA;Semantics:&#xA;The Mode is active if and only if the condition is true."/>
      </eAnnotations>
      <eStructuralFeatures xsi:type="ecore:EAttribute" name="condition" ordered="false"
          unique="false" lowerBound="1" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//String"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
          unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EClass" name="Behavior" eSuperTypes="#//infrastructure/elements/Context">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="Behavior is a container of FunctionBehaviors, it enables to regroup 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).&#xA;&#xA;The collection of functional behaviors can be done across the EAST-ADL2 abstraction levels.&#xA;&#xA;Semantics:&#xA;This element has the same role and semantics as Context, but for behavioral aspects.&#xA;&#xA;Extension: BehavioredClassifier"/>
      </eAnnotations>
      <eStructuralFeatures xsi:type="ecore:EReference" name="behavior" ordered="false"
          upperBound="-1" eType="#//behavior/FunctionBehavior"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="functionTrigger" ordered="false"
          upperBound="-1" eType="#//behavior/FunctionTrigger"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="modeGroup" ordered="false"
          unique="false" upperBound="-1" eType="#//behavior/ModeGroup"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="base_Package" ordered="false"
          unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Package"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
          unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EClass" name="FunctionTrigger" eSuperTypes="#//infrastructure/elements/EAElement">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="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.&#xA;&#xA;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 triggers the function, i.e. activates 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.&#xA;&#xA;In addition a FunctionTrigger may refer to a list of Modes in which the trigger will be considered as potentially active. Because of FunctionBehaviors may also refer to Modes, it is thus possible to arrange various function configurations for which different sets of triggers and behaviors are active. And this, at various level of granularity, either with a type-wise scope (by referring to a FunctionType) or specifically at prototype level (by referring to a FunctionPrototype).&#xA;&#xA;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.&#xA;&#xA;&#xA;Semantics:&#xA;Association Mode defines in which modes the trigger is active&#xA;&#xA;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.&#xA;&#xA;&#xA;Constraints:&#xA;[1] The port association must not be empty when triggerPolicy is EVENT.&#xA;&#xA;[2] The port association is empty when triggerPolicy is TIME.&#xA;&#xA;[3] Function and functionPrototype are mutually exclusive associations. A FunctionTrigger either identifies a FunctionType or a FunctionPrototype as its target function, but not both.&#xA;&#xA;[4] Only FunctionFlowPort of FlowDirection=in shall be referred to in the association port and at least one of them shall trigger the function&#xA;&#xA;Extension:&#xA;Class"/>
      </eAnnotations>
      <eStructuralFeatures xsi:type="ecore:EAttribute" name="triggerCondition" ordered="false"
          unique="false" lowerBound="1" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//String">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="An OCL expression that allows release of the ADLFunctionType only if it evaluates to TRUE."/>
        </eAnnotations>
      </eStructuralFeatures>
      <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
          unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
      <eStructuralFeatures xsi:type="ecore:EAttribute" name="triggerPolicy" ordered="false"
          unique="false" lowerBound="1" eType="#//behavior/TriggerPolicyKind">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="Defines whether time or trigger events on ports makes the Function execute"/>
        </eAnnotations>
      </eStructuralFeatures>
      <eStructuralFeatures xsi:type="ecore:EReference" name="mode" ordered="false"
          unique="false" upperBound="-1" eType="#//behavior/Mode"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="function" ordered="false"
          unique="false" eType="#//structure/functionmodeling/FunctionType"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="port" ordered="false"
          unique="false" upperBound="-1" eType="#//structure/functionmodeling/FunctionPort"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="functionPrototype" ordered="false"
          unique="false" eType="#//structure/functionmodeling/FunctionPrototype"/>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EEnum" name="TriggerPolicyKind">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="TriggerPolicyKind represents an enumeration for triggering policies.&#xA;&#xA;Semantics:&#xA;The TriggerPolicyKind contains EVENT and TIME as possible triggering policies. &#xA;&#xA;Extension: &#xA;Enumeration, no extension."/>
      </eAnnotations>
      <eLiterals name="EVENT">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="Triggering by event."/>
        </eAnnotations>
      </eLiterals>
      <eLiterals name="TIME" value="1">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="Triggering by time."/>
        </eAnnotations>
      </eLiterals>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EClass" name="ModeGroup" eSuperTypes="#//infrastructure/elements/TraceableSpecification">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="ModeGroups serve as container of Modes. The set of 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."/>
      </eAnnotations>
      <eStructuralFeatures xsi:type="ecore:EAttribute" name="precondition" ordered="false"
          unique="false" lowerBound="1" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//String"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="mode" ordered="false"
          unique="false" lowerBound="1" upperBound="-1" eType="#//behavior/Mode"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
          unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
    </eClassifiers>
  </eSubpackages>
  <eSubpackages name="requirements" nsURI="http://www.papyrusuml.org/EAST-ADL2/Requirements/1"
      nsPrefix="Requirements">
    <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
      <details key="documentation" value="A requirement expresses a condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification or other formally imposed properties.&#xA;&#xA;Requirements can be introduced in different phases of the development process for different reasons. They could be introduced by marketing people, control engineers, system engineers, software engineers, Driver/OS developers, basic software developers or hardware engineers. This leads to the fact that requirements have many sources, and requirements are of many types (at different level of detail) and have several relations between them. Under these conditions the number of requirements can become quickly unmanageable if appropriate management does not exist. Note that, requirements can change during the project development and the changes should be taken into account. Requirements are organized hierarchically through several kinds of refinement relations.&#xA;&#xA;EAST-ADL2 has constructs that deal with these problems. Some of these constructs deals with general issues in software development and have been already addressed in the past by general processes. As done for the structure part of EAST-ADL2, the requirements part will be compliant with UML2. The EAST-ADL2 adapts existing concepts whenever possible and develops new ones otherwise. Support for requirements modeling is provided by the EAST-ADL2 on two levels: a generic level and specializing levels (e.g. Dependability.SafetyRequirement) where specialized requirement entities are provided which are intended for certain special uses.&#xA;&#xA;Elements inspired by SysML are Requirement, Satisfy, Refine, DeriveRequirement, (Verify)"/>
    </eAnnotations>
    <eClassifiers xsi:type="ecore:EClass" name="QualityRequirement" eSuperTypes="#//requirements/Requirement">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="QualityRequirements are the kind of requirements that are used to introduce externally visible properties of the system considered as a whole.&#xA;The attribute qualityRequirementType allows a more specific classification.&#xA;&#xA;&#xA;&#xA;Extension: &#xA;Class, specializes Requirement"/>
      </eAnnotations>
      <eStructuralFeatures xsi:type="ecore:EAttribute" name="qualityRequirementType"
          ordered="false" lowerBound="1" eType="#//requirements/QualityRequirementKind"/>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EClass" name="Requirement" eSuperTypes="platform:/plugin/org.eclipse.papyrus.sysml/model/sysml.ecore#//requirements/Requirement #//requirements/RequirementSpecificationObject">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="The Requirement represents a capability or condition that must (or should) be satisfied. A Requirement can also specify an informal constraint, e.g. &quot;The development of the component X must be according to the standard Y&quot;, or &quot;The realization of this function as a software component must adhere to the scope and external interface as specified by this function&quot;. It will be used to unite the common properties of specific requirement types. A Requirement may either be directly associated to a Context (by inheriting from TraceableSpecification or it may be included in a RequirementContainer, which represents a larger unit or module of specification information.&#xA;&#xA;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.&#xA;&#xA;Semantics:&#xA;The Requirement metaclass applies to the EAElement that is associated to the Requirement through the Satisfy relation.&#xA;&#xA;Notation:&#xA;Requirement is shown as a solid rectangle with Req top right and its name.&#xA;&#xA;Changes:&#xA;Renamed from Requirement, name clash with SysML&#xA;ToDo:&#xA;Check the attributes specified in EAST.&#xA;&#xA;Extension:&#xA;To specialize SysML::Requirement, which extends Class"/>
      </eAnnotations>
      <eStructuralFeatures xsi:type="ecore:EAttribute" name="formalism" ordered="false"
          eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//String">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="Specifies the language used for the requirement statement."/>
        </eAnnotations>
      </eStructuralFeatures>
      <eStructuralFeatures xsi:type="ecore:EAttribute" name="url" ordered="false"
          unique="false" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//String">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="Reference to possible external file containing the requirement statement."/>
        </eAnnotations>
      </eStructuralFeatures>
      <eStructuralFeatures xsi:type="ecore:EReference" name="mode" ordered="false"
          unique="false" upperBound="-1" eType="#//behavior/Mode"/>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EClass" name="RequirementSpecificationObject" abstract="true"
        eSuperTypes="#//infrastructure/elements/TraceableSpecification">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="In general it is a standard practice (e.g. using IBM Rational DOORS) to define requirements and also rationales, explanations and other requirement related information as direct successors or predecessors of an appropriate requirement. Thus, requirements and requirement related information are generalized to RequirementSpecificationObject which in turn can be referenced by the structuring container structure (RequirementContainer)."/>
      </eAnnotations>
      <eStructuralFeatures xsi:type="ecore:EReference" name="referencingContainer"
          ordered="false" lowerBound="1" upperBound="-1" eType="#//requirements/RequirementsContainer"/>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EClass" name="RequirementsContainer" eSuperTypes="#//infrastructure/elements/TraceableSpecification">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="RequirementContainer represents a larger unit or module of specification information. It is used to share 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 ordering of child containers is very important here.&#xA;&#xA;In addition to sharing related Requirements, the RequirementContainer allows to define relations between its contained Requirements and also a grouping of them.&#xA;&#xA;Furthermore, the RequirementContainer allows introducing 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-ADL2 repository.&#xA;&#xA;An EAST-ADL2 system model may contain a forest of RequirementContainer (see parent child relationship). Only non root RequirementContainer which have a parentContainer are allowed to reference a RequirementSpecificationObject.&#xA;The RequirementContainer with its parent child containment relationship and the reference to RequirementSpecificationObject is the basis element for structuring requirement information into a forest structure.&#xA;&#xA;Constraints:&#xA;[1] Only non root RequirementContainer (parentContainer must be set) which have a parentContainer are allowed to reference a RequirementSpecificationObject.&#xA;&#xA;Notation:&#xA;RequirementContainer is shown as a solid-outline rectangle containing the name. Contained entities may also be shown inside (White-box view)&#xA;&#xA;Extension: Package"/>
      </eAnnotations>
      <eStructuralFeatures xsi:type="ecore:EReference" name="childContainer" upperBound="-1"
          eType="#//requirements/RequirementsContainer" eOpposite="#//requirements/RequirementsContainer/parentContainer">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="Sub containers of a requirement container. Sub containers may have references (each time max. 1) to requirement specification objects. To preserve the original ordering of requirement specifiaction objects, the ordering of Sub containers is very important here."/>
        </eAnnotations>
      </eStructuralFeatures>
      <eStructuralFeatures xsi:type="ecore:EReference" name="parentContainer" ordered="false"
          unique="false" eType="#//requirements/RequirementsContainer" eOpposite="#//requirements/RequirementsContainer/childContainer">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The Parent container of a container. If there is no parent, the container is a root container and thus cannot have a reference to a requirement specification object."/>
        </eAnnotations>
      </eStructuralFeatures>
      <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
          unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="base_Package" ordered="false"
          unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Package"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="containedReqSpecObject"
          ordered="false" unique="false" eType="#//requirements/RequirementSpecificationObject"/>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EEnum" name="QualityRequirementKind">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="QualityRequirementKind represents an enumeration with enumeration literals describing various types of quality requirements.&#xA;&#xA;Extension: &#xA;Enumeration, no extension."/>
      </eAnnotations>
      <eLiterals name="ergonomy"/>
      <eLiterals name="configurability" value="1"/>
      <eLiterals name="integrity" value="2"/>
      <eLiterals name="safety" value="3"/>
      <eLiterals name="other" value="4"/>
      <eLiterals name="security" value="5"/>
      <eLiterals name="humanMachineInterface" value="6"/>
      <eLiterals name="timing" value="7"/>
      <eLiterals name="availability" value="8"/>
      <eLiterals name="reliability" value="9"/>
      <eLiterals name="confidentiality" value="10"/>
      <eLiterals name="maintainability" value="11"/>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EClass" name="RequirementsRelatedInformation" eSuperTypes="#//requirements/RequirementSpecificationObject">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="This is a placeholder for all objects which are not Requirements (such as Rational, Explanations, Related Material etc...). E.g. an element of type RequirementsRelatedInformation which is a rational of an element of type Requirement will directly succeeding this requirement as a sibling element (see structuring of requirement elements via RequirementContainer).&#xA;&#xA;Semantics:&#xA;This metaclass can be used to represents 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."/>
      </eAnnotations>
      <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
          unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EClass" name="RequirementsRelationship" abstract="true"
        eSuperTypes="#//infrastructure/elements/Relationship">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="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 ReqGroup instead.&#xA;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 n:m relations can be expressed with instances of this class.&#xA;The semantic of a concrete requirement relation is not defined by the EAST-ADL2 and therefore needs to be provided by the modeler.  In particular, three ways are conceivable:&#xA;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.&#xA;2) The uaType (user attributeable element type) can be used.  Certain types will be used for certain relation semantics.&#xA;3) ReqRelationGroups 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"/>
      </eAnnotations>
      <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
          unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EClass" name="Satisfy" eSuperTypes="#//requirements/RequirementsRelationship platform:/plugin/org.eclipse.papyrus.sysml/model/sysml.ecore#//requirements/Satisfy">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="The Satisfy is a relationship metaclass, which signifies relationship between Requirements and an element intended to satisfy the Requirement.&#xA;&#xA;Semantics:&#xA;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.&#xA;&#xA;Constraints:&#xA;[1] The EAElement in the association satisfiedBy may not be a Requirement or RequirementContainer.&#xA;[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!&#xA;&#xA;Notation:&#xA;A Satisfy relationship is shown as a dashed line with a 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).&#xA;&#xA;Extension:&#xA;To specialize SysML::Satisfy, which extends Realization."/>
      </eAnnotations>
      <eStructuralFeatures xsi:type="ecore:EReference" name="satisfiedRequirement"
          ordered="false" upperBound="-1" eType="#//requirements/Requirement" changeable="false"
          volatile="true" transient="true" derived="true">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="List of satisfied ADL requirements, which are satisfied by the client ADL entities.&#xD;&#xA;{derived from UML::DirectedRelationship::target}"/>
        </eAnnotations>
      </eStructuralFeatures>
      <eStructuralFeatures xsi:type="ecore:EReference" name="satisfiedBy" ordered="false"
          upperBound="-1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//NamedElement"
          changeable="false" volatile="true" transient="true" derived="true">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="List of satisfied ADL use cases, which are satisfied by the client ADL entities or satisfied by the client AUTOSAR elements.&#xA;{derived from UML::Dependency::client}"/>
        </eAnnotations>
      </eStructuralFeatures>
      <eStructuralFeatures xsi:type="ecore:EReference" name="satisfiedBy_path" upperBound="-1"
          eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//NamedElement"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="satisfiedUseCase" ordered="false"
          upperBound="-1" eType="#//requirements/UseCase"/>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EClass" name="UseCase" eSuperTypes="#//infrastructure/elements/TraceableSpecification">
      <eStructuralFeatures xsi:type="ecore:EReference" name="base_UseCase" ordered="false"
          lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//UseCase"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="include" ordered="false"
          upperBound="-1" eType="#//requirements/Include" containment="true"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="extend" ordered="false"
          upperBound="-1" eType="#//requirements/Extend" containment="true"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="extensionPoint" ordered="false"
          upperBound="-1" eType="#//requirements/ExtensionPoint" containment="true"/>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EClass" name="Include" eSuperTypes="#//infrastructure/elements/Relationship">
      <eStructuralFeatures xsi:type="ecore:EReference" name="base_Include" ordered="false"
          lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Include"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="addition" ordered="false"
          lowerBound="1" eType="#//requirements/UseCase"/>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EClass" name="Extend" eSuperTypes="#//infrastructure/elements/Relationship">
      <eStructuralFeatures xsi:type="ecore:EReference" name="base_Extend" ordered="false"
          lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Extend"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="extendedCase" ordered="false"
          lowerBound="1" eType="#//requirements/UseCase"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="extensionLocation" ordered="false"
          lowerBound="1" upperBound="-1" eType="#//requirements/ExtensionPoint"/>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EClass" name="ExtensionPoint" eSuperTypes="#//requirements/RedefinableElement">
      <eStructuralFeatures xsi:type="ecore:EReference" name="base_ExtensionPoint"
          ordered="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//ExtensionPoint"/>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EClass" name="RedefinableElement" abstract="true">
      <eStructuralFeatures xsi:type="ecore:EReference" name="base_RedefinableElement"
          ordered="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//RedefinableElement"/>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EClass" name="Refine" eSuperTypes="#//requirements/RequirementsRelationship platform:/plugin/org.eclipse.uml2.uml.profile.l2/model/L2.ecore#//Refine">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="The Refine is a relationship metaclass, which signifies a dependency relationship in-between Requirements and EAElements, showing the relationship when a client EAElement refines the supplier Requirement.&#xA;&#xA;Semantics:&#xA;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. &#xA;&#xA;Constraints:&#xA;[1] The property refinedBy must not have the types Requirement or RequirementContainer.&#xA;&#xA;Notation:&#xA;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).&#xA;&#xA;Extension: specializes UML2 stereotype Refine, which extends Dependency."/>
      </eAnnotations>
      <eStructuralFeatures xsi:type="ecore:EReference" name="refinedRequirement" ordered="false"
          lowerBound="1" upperBound="-1" eType="#//requirements/Requirement" changeable="false"
          volatile="true" transient="true" derived="true">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="List of refined requirements.&#xD;&#xA;{derived from UML::DirectedRelationship::target}"/>
        </eAnnotations>
      </eStructuralFeatures>
      <eStructuralFeatures xsi:type="ecore:EReference" name="refinedBy" ordered="false"
          lowerBound="1" upperBound="-1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//NamedElement"
          changeable="false" volatile="true" transient="true" derived="true">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="List of ADLEntity participating to the refinement of the refined ADL requirements.&#xD;&#xA;{derived from UML::Dependency::client}"/>
        </eAnnotations>
      </eStructuralFeatures>
      <eStructuralFeatures xsi:type="ecore:EReference" name="base_Dependency" ordered="false"
          unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Dependency"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="refinedBy_path" upperBound="-1"
          eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//NamedElement"/>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EClass" name="DeriveRequirement" eSuperTypes="#//requirements/RequirementsRelationship platform:/plugin/org.eclipse.papyrus.sysml/model/sysml.ecore#//requirements/DeriveReqt">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="ADLDeriveReqt signifies a dependency relationship in-between two sets of ADL requirements, showing the relationship when a set of derived client ADL requirement (client requirement) is derived from a set of ADL requirements (supplier requirement). It inherits from SysML::DeriveReqt which extends Dependency.&#xD;&#xA;&#xD;&#xA;Semantics:&#xD;&#xA;ADLDeriveReqt signifies a derived/derived by relationship between ADLRequirements, where the modification of the supplierADLRequirement may impact the derived client ADLRequirement. ADLDeriveReqt implies the semantics that the derived client ADLRequirement is not complete, without the supplier ADLRequirement."/>
      </eAnnotations>
      <eStructuralFeatures xsi:type="ecore:EReference" name="derived" ordered="false"
          lowerBound="1" upperBound="-1" eType="#//requirements/Requirement" changeable="false"
          volatile="true" transient="true" derived="true">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The set of ADL requirements derived from the supplier ADL requirement.&#xD;&#xA;{derived from UML::DirectedRelationship::target}"/>
        </eAnnotations>
      </eStructuralFeatures>
      <eStructuralFeatures xsi:type="ecore:EReference" name="derivedFrom" ordered="false"
          lowerBound="1" upperBound="-1" eType="#//requirements/Requirement" changeable="false"
          volatile="true" transient="true" derived="true">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The set of ADL requirements that the client ADL requirement are derived from.&#xD;&#xA;{derived from UML::DirectedRelationship::source}"/>
        </eAnnotations>
      </eStructuralFeatures>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EClass" name="RequirementsRelationGroup" eSuperTypes="#//infrastructure/elements/TraceableSpecification">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="RequirementsRelationGroup represents a group of relations between Requirements."/>
      </eAnnotations>
      <eStructuralFeatures xsi:type="ecore:EReference" name="relation" ordered="false"
          unique="false" upperBound="-1" eType="#//requirements/RequirementsLink">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The relations that are grouped by this relation group. Note that this is not a containment association, i.e. a single relation may be grouped by several ReqRelationGroups."/>
        </eAnnotations>
      </eStructuralFeatures>
      <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
          unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="base_Package" ordered="false"
          unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Package"/>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EClass" name="RequirementsLink" eSuperTypes="#//requirements/RequirementsRelationship">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="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 RequirementsGroup instead.&#xA;&#xA;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.&#xA;&#xA;The semantic of a concrete Requirement relation can be provided by the modeler. In particular, three ways are conceivable:&#xA;&#xA;(1) The user attributes of the relation can be used to specify its meaning, for example with a user attribute called &quot;relationType&quot; which is set to values such as &quot;needs&quot; or &quot;excludes&quot;.&#xA;&#xA;(2) The UserAttributeElementType can be used. Certain types will be used for certain relation semantics.&#xA;&#xA;(3) RequirementsRelationGroups can be used, i.e. all relations with an &quot;excludes&quot; meaning are put in one relation group and all with a &quot;needs&quot; meaning are put in another."/>
      </eAnnotations>
      <eStructuralFeatures xsi:type="ecore:EAttribute" name="isBidirectional" ordered="false"
          unique="false" lowerBound="1" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//Boolean"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="source" ordered="false"
          unique="false" lowerBound="1" upperBound="-1" eType="#//requirements/Requirement"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="target" ordered="false"
          unique="false" lowerBound="1" upperBound="-1" eType="#//requirements/Requirement"/>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EClass" name="RequirementsModel" eSuperTypes="#//infrastructure/elements/Context">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="The collection of requirements, their relationships, and usecases. This collection can be done across the EAST-ADL2 abstraction levels."/>
      </eAnnotations>
      <eStructuralFeatures xsi:type="ecore:EReference" name="useCase" ordered="false"
          upperBound="-1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//UseCase"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="requirement" ordered="false"
          upperBound="-1" eType="#//requirements/RequirementSpecificationObject"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="requirementContainer"
          ordered="false" upperBound="-1" eType="#//requirements/RequirementsContainer"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="operationalSituation"
          ordered="false" unique="false" upperBound="-1" eType="#//requirements/OperationalSituation"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="base_Package" ordered="false"
          unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Package"/>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EClass" name="OperationalSituation" eSuperTypes="#//infrastructure/elements/TraceableSpecification">
      <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
          unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EClass" name="Actor" eSuperTypes="#//infrastructure/elements/TraceableSpecification">
      <eStructuralFeatures xsi:type="ecore:EReference" name="base_Actor" ordered="false"
          lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Actor"/>
    </eClassifiers>
    <eSubpackages name="verificationvalidation" nsURI="http://www.papyrusuml.org/EAST-ADL2/Requirements/VerificationValidation/1"
        nsPrefix="VerificationValidation">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="A multitude of different verification and validation (V&amp;V) techniques, methods and tools are applied during the development of EE-Systems. Different techniques are applicable at different abstraction levels. Also, the technique of choice depends on the properties to validate and/or verify. Furthermore, each partner in a project may develop and employ his own V&amp;V processes and activities. Hence it is impossible to introduce in the EAST-ADL2 a way to model all the objects that can be required by all the possible V&amp;V techniques. As a consequence, EAST-ADL2 furnishes just the means for planning, organizing and describing V&amp;V activities on a fairly abstract level, and for defining the links between those V&amp;V activities, the satisfied and verified requirements, and the objects modeling the system (Functional Analysis Architecture, Functional components, Logical Tasks, etc.). The common parts of all V&amp;V techniques are described by the EAST-ADL2, which includes: the results expected from the V&amp;V activities, the actual results which were obtained when applying the V&amp;V techniques, how the V&amp;V activities are constrained. Information that is specific to an individual V&amp;V technique is not described in EAST-ADL2, but a place for storing this information is provided.&#xA;&#xA;Single V&amp;V techniques may be used only once or at several stages during an overall V&amp;V effort. Some of them are specific to one modeling design stage; others can be applied at various design stages.&#xA;&#xA;A set of V&amp;V techniques and activities is necessary in order to achieve a complete verification and validation of a given system. Often these techniques and activities are employed and performed by many different teams and departments, frequently even by different companies. This raises the demand for an overall planning and organization of all V&amp;V related information.&#xA;&#xA;A very important notion of V&amp;V support in EAST-ADL2 is the distinction of abstract and concrete V&amp;V information:&#xA;&#xA;(1) On the abstract level, verification and validation information is defined without referring to a concrete testing environment and without specifying stimuli and the expected outcome of a particular VVProcedure on a detailed technical level.&#xA;&#xA;(2) On the concrete level, verification and validation information specifies a concrete testing environment and provides all necessary details for testing, e.g. stimuli and expected outcomes, on a concrete technical level applicable to that testing environment.&#xA;&#xA;In accordance to the &quot;what vs. how&quot; definition of requirements one could say: the abstract level defines what needs to be done to verify and validate a certain system, but not precisely how this is done. Conversely, the concrete level defines the precise technical details for particular testing environments. So all abstract VVCases and VVProcedures for a certain system together form sort of a &quot;to-do&quot;-list, which describes what needs to be done when actually testing the system with a concrete testing environment, but in a form applicable to all conceivable testing environments to all conceivable testing environments."/>
      </eAnnotations>
      <eClassifiers xsi:type="ecore:EClass" name="VVStimuli" eSuperTypes="#//infrastructure/elements/TraceableSpecification">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="VVStimuli represents the input values to the testing environment represented by VVTarget in order to perform the corresponding VVProcedure.&#xA;&#xA;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 such that they are directly applicable to the VVTarget(s) defined for the containing ConcreteVVCase.&#xA;&#xA;&#xA;Extension: Class"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="VVIntendedOutcome" eSuperTypes="#//infrastructure/elements/TraceableSpecification">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="Expected output of the testing environment represented by VVTarget when triggered by the corresponding VVStimuli of the containing ConcreteVVProcedure.&#xA;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 such that it can directly be compared to the output of the VVTarget(s) defined for the containing ConcreteVVCase."/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="VVActualOutcome" eSuperTypes="#//infrastructure/elements/TraceableSpecification">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="VVActualOutcome represents the actual output of the testing environment represented by VVTarget when triggered by the VVStimuli of the ConcreteVVProcedure which is defined by the association 'performedVVProcedure' of the containing VVLog. It should be equivalent to the VVIntendedOutcome defined by association 'intendedOutcome'&#xA;&#xA;&#xA;Extension: Class"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="intendedOutcome" ordered="false"
            unique="false" eType="#//requirements/verificationvalidation/VVIntendedOutcome">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="Denotes the VVIntendedOutcome that must be matched by this actual outcome."/>
          </eAnnotations>
        </eStructuralFeatures>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="VVCase" eSuperTypes="#//infrastructure/elements/TraceableSpecification">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="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."/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="vvCase" ordered="false"
            unique="false" upperBound="-1" eType="#//requirements/verificationvalidation/VVCase"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="abstractVVCase" ordered="false"
            unique="false" eType="#//requirements/verificationvalidation/VVCase"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="vvTarget" ordered="false"
            unique="false" lowerBound="1" upperBound="-1" eType="#//requirements/verificationvalidation/VVTarget"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="vvSubject" ordered="false"
            unique="false" lowerBound="1" upperBound="-1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//NamedElement"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="vvLog" ordered="false"
            upperBound="-1" eType="#//requirements/verificationvalidation/VVLog"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="vvProcedure" upperBound="-1"
            eType="#//requirements/verificationvalidation/VVProcedure">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="The abstract VV procedures for this AbstractVVCase."/>
          </eAnnotations>
        </eStructuralFeatures>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="VVTarget" eSuperTypes="#//infrastructure/elements/TraceableSpecification">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="VVTarget represents a concrete testing environment in which or on 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.&#xA;&#xA;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.&#xA;&#xA;VVTargets can be reused across several ConcreteVVCases."/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="element" ordered="false"
            unique="false" upperBound="-1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//NamedElement"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="VVLog" eSuperTypes="#//infrastructure/elements/TraceableSpecification">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="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. &#xA;&#xA;This is the purpose of the VVLog. Each VVLog metaclass represents a certain execution of a ConcreteVVCase.&#xA;&#xA;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 result from Friday and Monday respectively.&#xA;&#xA;&#xA;Extension: Class"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="date" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//String">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="Date and time when this log was captured."/>
          </eAnnotations>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EReference" name="vvActualOutcome" ordered="false"
            upperBound="-1" eType="#//requirements/verificationvalidation/VVActualOutcome">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="Set of outcome results."/>
          </eAnnotations>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="performedVVProcedure"
            ordered="false" unique="false" lowerBound="1" eType="#//requirements/verificationvalidation/VVProcedure"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="VVProcedure" eSuperTypes="#//infrastructure/elements/TraceableSpecification">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="VVProcedure represents an individual task in the context of an overall V&amp;V effort (represented by a VVCase), which has to be performed in order to achieve that effort's overall objective. Just as is the case for VVCases, the definition of VVProcedures is separated in two levels: an abstract and a concrete level represented by the entities AbstractVVProcedure and ConcreteVVProcedure.&#xA;&#xA;The concreteVVProcedure metaclass represents such a task on a concrete level, i.e. it is defined with a concrete testing environment in mind and provides stimuli and an expected outcome of the procedure in a form which is directly applicable to this testing environment.&#xA;&#xA;Extension: Class"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="abstractVVProcedure"
            ordered="false" unique="false" eType="#//requirements/verificationvalidation/VVProcedure"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="concreteVVProcedure"
            ordered="false" unique="false" upperBound="-1" eType="#//requirements/verificationvalidation/VVProcedure"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="vvIntendedOutcome"
            ordered="false" upperBound="-1" eType="#//requirements/verificationvalidation/VVIntendedOutcome"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="vvStimuli" ordered="false"
            upperBound="-1" eType="#//requirements/verificationvalidation/VVStimuli"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="VerificationValidation" eSuperTypes="#//infrastructure/elements/Context">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The collection of verification and validation elements. This collection can be done across the EAST-ADL2 abstraction levels."/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
            unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Package" ordered="false"
            unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Package"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="verify" ordered="false"
            upperBound="-1" eType="#//requirements/verificationvalidation/Verify"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="vvCase" ordered="false"
            upperBound="-1" eType="#//requirements/verificationvalidation/VVCase"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="vvTarget" ordered="false"
            upperBound="-1" eType="#//requirements/verificationvalidation/VVTarget"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="Verify" eSuperTypes="#//requirements/RequirementsRelationship platform:/plugin/org.eclipse.papyrus.sysml/model/sysml.ecore#//requirements/Verify">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The Verify is a relationship metaclass, which signifies a dependency relationship between a Requirement and a VVCase, showing the relationship when a client VVCase verifies the supplier Requirement.&#xA;&#xA;Semantics:&#xA;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 the semantics that the verifying client VVCase is not complete, without the supplier Requirement. &#xA;&#xA;Notation:&#xA;A Verify relationship is shown as a dashed arrow between the Requirements and VVCase.&#xA;&#xA;Extension:&#xA;To specializes SysML::Verify, which specializes the UML stereotype Trace, which extends Dependency."/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="verifiedByProcedure"
            ordered="false" upperBound="-1" eType="#//requirements/verificationvalidation/VVProcedure">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="The procedures used to verify the requirements."/>
          </eAnnotations>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EReference" name="verifiedByCase" ordered="false"
            lowerBound="1" upperBound="-1" eType="#//requirements/verificationvalidation/VVCase"
            changeable="false" volatile="true" transient="true" derived="true">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="The verification that verifies the supplier requirement(s).&#xD;&#xA;{derived from UML::DirectedRelationship::source}"/>
          </eAnnotations>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EReference" name="verifiedRequirement"
            ordered="false" lowerBound="1" upperBound="-1" eType="#//requirements/Requirement"
            changeable="false" volatile="true" transient="true" derived="true">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="The set of ADL requirements which the client VV cases verify.&#xD;&#xA;{derived from UML::DirectedRelationship::target}"/>
          </eAnnotations>
        </eStructuralFeatures>
      </eClassifiers>
    </eSubpackages>
  </eSubpackages>
  <eSubpackages name="timing" nsURI="http://www.papyrusuml.org/EAST-ADL2/Timing/1"
      nsPrefix="Timing">
    <eClassifiers xsi:type="ecore:EClass" name="TimingDescription" abstract="true"
        eSuperTypes="#//infrastructure/elements/EAElement">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="An abstract metaclass describing the timing events and their relations within the model."/>
      </eAnnotations>
      <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
          unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EClass" name="TimingConstraint" abstract="true"
        eSuperTypes="#//infrastructure/elements/EAElement">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="TimingConstraint is an abstract entity that identifies a mode.&#xA;&#xA;Constraints:&#xA;[1] upper shall be greater or equal to lower.&#xA;&#xA;&#xA;Semantics:&#xA;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."/>
      </eAnnotations>
      <eStructuralFeatures xsi:type="ecore:EReference" name="mode" ordered="false"
          unique="false" upperBound="-1" eType="#//behavior/Mode">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The mode where the TimingConstraint is valid."/>
        </eAnnotations>
      </eStructuralFeatures>
      <eStructuralFeatures xsi:type="ecore:EReference" name="upper" ordered="false"
          unique="false" eType="#//timing/TimeDuration"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="lower" ordered="false"
          unique="false" eType="#//timing/TimeDuration"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
          unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="base_Constraint" ordered="false"
          unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Constraint"/>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EClass" name="TimeDuration" eSuperTypes="#//infrastructure/elements/EAElement">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="CseCodeType &#xA;0:&#x9;1 µsec &#x9;&#x9;Time&#x9;&#xA;1:&#x9;10 µsec&#x9;&#x9;Time&#x9;&#xA;2:&#x9;100 µsec&#x9;Time&#x9;&#xA;3:&#x9;1 msec&#x9;&#x9;Time&#x9;&#xA;4:&#x9;10 msec&#x9;&#x9;Time&#x9;&#xA;5:&#x9;100 msec&#x9;Time&#x9;&#xA;6:&#x9;1 sec&#x9;&#x9;Time&#x9;&#xA;7:&#x9;10 sec&#x9;&#x9;Time&#x9;&#xA;8:&#x9;1 min&#x9;&#x9;Time&#x9;&#xA;9:&#x9;1 h&#x9;&#x9;Time&#x9;&#xA;10:&#x9;1 d&#x9;&#x9;Time&#x9;&#xA;&#xA;100:&#x9;Angular degrees&#x9;&#x9;&#x9;Angle&#x9;&#xA;101:&#x9;Revolutions 360 degrees&#x9;Angle&#x9;&#xA;102:&#x9;Cycle 720 degrees&#x9;&#x9;Angle&#x9;e.g. in case of IC engines&#xA;103:&#x9;Cylinder segment&#x9;&#x9;Combustion&#x9;e.g. in case of IC engines&#xA;998:&#x9;When frame available&#x9;Time&#x9;Source defined in the ASAP 2 keyword, FRAME&#xA;999:&#x9;Always if there is new value&#x9;&#x9;Calculation of a new upper range limit after receiving a new partial value, e.g. when calculating a complex trigger condition&#xA;1000:&#x9;Non deterministic&#x9;&#x9;Without fixed scaling&#xA;&#xA;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.&#xA;&#xA;CseCodeType is from AUTOSAR and MSR/ASAM.&#xA;&#xA;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)."/>
      </eAnnotations>
      <eStructuralFeatures xsi:type="ecore:EReference" name="base_DataType" ordered="false"
          unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//DataType"/>
      <eStructuralFeatures xsi:type="ecore:EAttribute" name="cseCode" ordered="false"
          unique="false" lowerBound="1" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//Integer">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="Within TIMMO this is normally time, note that when it is expressed as angle it can be converted to time."/>
        </eAnnotations>
      </eStructuralFeatures>
      <eStructuralFeatures xsi:type="ecore:EAttribute" name="cseCodeFactor" ordered="false"
          unique="false" lowerBound="1" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//Integer"
          defaultValueLiteral="1">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="Is normally equal to 1."/>
        </eAnnotations>
      </eStructuralFeatures>
      <eStructuralFeatures xsi:type="ecore:EAttribute" name="value" ordered="false"
          unique="false" lowerBound="1" eType="#//infrastructure/datatypes/javalangFloat">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The actual value complemented with the cseCode."/>
        </eAnnotations>
      </eStructuralFeatures>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EClass" name="Timing" eSuperTypes="#//infrastructure/elements/Context">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="The collection of timing constraints and their descriptions in the form of events and event chains. This collection can be done across the EAST-ADL2 abstraction levels."/>
      </eAnnotations>
      <eStructuralFeatures xsi:type="ecore:EReference" name="timingConstraint" ordered="false"
          upperBound="-1" eType="#//timing/TimingConstraint"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="timingDescription" ordered="false"
          upperBound="-1" eType="#//timing/TimingDescription"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
          unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="base_Package" ordered="false"
          unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Package"/>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EClass" name="EventChain" eSuperTypes="#//timing/TimingDescription">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="The purpose of event chains is to describe the temporal behavior of a number of steps to be taken to respond to one or more events accordingly. [An event chain is also used to express that a temporal requirement/constraint is imposed on a number of steps to respond to one or more events accordingly (-> requirement).] Such events could be observed in a given system and are categorized into stimuli and responses.&#xA;&#xA;Event chains can refer to other event chains which are then called event chain segments or 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.&#xA;&#xA;Constraints:&#xA;[1] The cardinality of strand shall be either 0 or greater than 1. Rationale: Only values > 1 express true parallelism.&#xA;&#xA;Semantics:&#xA;An EventChain references two groups of events: stimulus and response. The semantics is 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, independently of whether there actually exists a causal connection between these events in the structural model."/>
      </eAnnotations>
      <eStructuralFeatures xsi:type="ecore:EReference" name="segment" unique="false"
          upperBound="-1" eType="#//timing/EventChain">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="Referred EventChains that are not parallel and in sequence refines this EventChain."/>
        </eAnnotations>
      </eStructuralFeatures>
      <eStructuralFeatures xsi:type="ecore:EReference" name="strand" ordered="false"
          unique="false" upperBound="-1" eType="#//timing/EventChain">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="Parallel EventChains refining this EventChain."/>
        </eAnnotations>
      </eStructuralFeatures>
      <eStructuralFeatures xsi:type="ecore:EReference" name="response" ordered="false"
          unique="false" lowerBound="1" upperBound="-1" eType="#//timing/Event">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The Response element is the entity to describe an event that is a response to a stimulus that occurred before."/>
        </eAnnotations>
      </eStructuralFeatures>
      <eStructuralFeatures xsi:type="ecore:EReference" name="stimulus" ordered="false"
          unique="false" lowerBound="1" upperBound="-1" eType="#//timing/Event">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The Stimulus element is the entity to describe an event that stimulates the steps to be taken to respond to this event."/>
        </eAnnotations>
      </eStructuralFeatures>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EClass" name="Event" abstract="true" eSuperTypes="#//timing/TimingDescription">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="An Event (E) is supposed to denote 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 &quot;driver door has been opened&quot; is an event indicating a state change; whereas the &quot;driver door is open&quot; is an event reporting a state.&#xA;&#xA;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.&#xA;&#xA;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 in turn always succeed stimuli.&#xA;&#xA;An event occurs instantaneously, which means that an event occurs at a time instant 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. &#xA;&#xA;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.&#xA;&#xA;&#xA;Constraints:&#xA;[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."/>
      </eAnnotations>
      <eStructuralFeatures xsi:type="ecore:EAttribute" name="isStateChanged" ordered="false"
          unique="false" lowerBound="1" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//Boolean"
          defaultValueLiteral="true">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="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). &#xA;If the boolean value is FALSE, then the event reports a [current] state. &#xA;By default, the value of this attribute is TRUE."/>
        </eAnnotations>
      </eStructuralFeatures>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EClass" name="ExecutionTimeConstraint" eSuperTypes="#//timing/TimingConstraint">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="ExecutionTimeConstraint expresses the execution time of a function under the assumption of a nominal CPU that executes 1 &quot;function second&quot; per second. Function allocation will decide the actual execution time by multiplication with the relative speed of the host CPU. &#xA;&#xA;Example:&#xA;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) &#xA;&#xA;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 blocking from other functions on the same resource&#xA;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). &#xA;&#xA;Constraints:&#xA;[1] An ExecutionTimeConstraint either identifies a FunctionType or a FunctionPrototype as its target function.&#xA;[2] variation shall be a value between 0 and upper-lower.&#xA;&#xA;Semantics:&#xA;lower (from TimingConstraint) denotes the minimal best case execution time.&#xA;upper (from TimingConstraint) denotes the maximal worst case execution time.&#xA;variation denotes the allowed variation in execution time, i.e. maximal minimal execution time.&#xA;&#xA;Example:&#xA;lower=5&#xA;upper=10&#xA;variation=2&#xA;best case execution time of 6 and worst case of 7 is within this constraint&#xA;best case execution time of 6 and worst case of 9 violates this constraint&#xA;&#xA;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."/>
      </eAnnotations>
      <eStructuralFeatures xsi:type="ecore:EReference" name="variation" ordered="false"
          unique="false" lowerBound="1" eType="#//timing/TimeDuration"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="targetDesignFunctionType"
          ordered="false" unique="false" eType="#//structure/functionmodeling/DesignFunctionType"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="targetDesignFunction"
          ordered="false" lowerBound="1" eType="#//structure/functionmodeling/DesignFunctionType"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="targetDesignFunctionPrototype"
          ordered="false" lowerBound="1" eType="#//structure/functionmodeling/DesignFunctionPrototype"/>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EClass" name="PrecedenceConstraint" eSuperTypes="#//timing/TimingConstraint">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="The PrecedenceConstraint represents a particular constraint applied on the execution sequence of functions.&#xA;&#xA;Semantics:&#xA;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.&#xA;&#xA;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.&#xA;&#xA;Notation:&#xA;PrecedenceConstraint is shown as a dashed arrow with &quot;Precedes&quot; next to it. It points from preceeding to the successive entity.&#xA;&#xA;Changes:&#xA;Renamed from Precedes&#xA;&#xA;Extension: &#xA;The PrecedenceConstraint extends UML2 metaclass Class and Dependency."/>
      </eAnnotations>
      <eStructuralFeatures xsi:type="ecore:EReference" name="successive" lowerBound="1"
          upperBound="-1" eType="#//structure/functionmodeling/FunctionPrototype"
          changeable="false" volatile="true" transient="true" derived="true">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The function prototypes that must be executed after preceding was executed.&#xD;&#xA;{derived from UML::DirectedRelationship::target}"/>
        </eAnnotations>
      </eStructuralFeatures>
      <eStructuralFeatures xsi:type="ecore:EReference" name="preceding" ordered="false"
          lowerBound="1" eType="#//structure/functionmodeling/FunctionPrototype" changeable="false"
          volatile="true" transient="true" derived="true">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The function prototype that must be executed first.&#xD;&#xA;{derived from UML::DirectedRelationship::source}"/>
        </eAnnotations>
      </eStructuralFeatures>
      <eStructuralFeatures xsi:type="ecore:EReference" name="base_Dependency" ordered="false"
          unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Dependency"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="successive_path" upperBound="-1"
          eType="#//structure/functionmodeling/FunctionPrototype"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="preceding_path" upperBound="-1"
          eType="#//structure/functionmodeling/FunctionPrototype"/>
    </eClassifiers>
    <eSubpackages name="timingconstraints" nsURI="http://www.papyrusuml.org/EAST-ADL2/Timing/TimingConstraints/1"
        nsPrefix="TimingConstraints">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="This section describes the timing constraints."/>
      </eAnnotations>
      <eClassifiers xsi:type="ecore:EClass" name="DelayConstraint" abstract="true"
          eSuperTypes="#//timing/TimingConstraint">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="DelayConstraints give bounds on system timing attributes, i.e. end-to-end delays, periods, etc.&#xA;&#xA;A DelayConstraint can specify one or several of an upper bound, a lower bound or a nominal value and jitter. The jitter is evenly distributed around the nominal (nominal - jitter/2 .. nominal + jitter/2). The bound will be measured in a given unit.&#xA;&#xA;Constraints:&#xA;[1] At least Upper or Nominal must be specified. Rationale: At least one value is needed to work with.&#xA;&#xA;Semantics:&#xA;Lower (from TimingConstraint) denotes the minimum value of the given bound.&#xA;Upper (from TimingConstraint) denotes the maximum value of the given bound.&#xA;Variation around the nominal value can be expressed by means of an upper and lower bound, or by means of a jitter value.&#xA;For example, [lower=10, upper=20, nominal=15] is equal to [nominal=15, jitter=10].&#xA;&#xA;&#xA;Extension:&#xA;abstract, no extension"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="jitter" ordered="false"
            unique="false" eType="#//timing/TimeDuration">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="Jitter is the range within which a value varies."/>
          </eAnnotations>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EReference" name="nominal" ordered="false"
            unique="false" eType="#//timing/TimeDuration">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="The recurring distance between each occurrence."/>
          </eAnnotations>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EReference" name="scope" ordered="false"
            unique="false" eType="#//timing/EventChain"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="AgeTimingConstraint" eSuperTypes="#//timing/timingconstraints/DelayConstraint">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="Different tolerances on over-/undersampling can be identified when the solution has been modeled.&#xA;&#xA;An age constraint is of interest in control engineering when looking back through the system.&#xA;&#xA;In case of over- or undersampling, there is no one-to-one relation 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.&#xA;&#xA;The attribute upper is applicable in worst-case analysis.&#xA;&#xA;The attribute lower is applicable in best-case analysis."/>
        </eAnnotations>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="EventConstraint" abstract="true"
          eSuperTypes="#//timing/TimingConstraint">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="An EventConstraint describes the basic characteristics of the way an event occurs over time."/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="event" ordered="false"
            unique="false" eType="#//timing/Event"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="offset" ordered="false"
            unique="false" eType="#//timing/TimeDuration">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="In addition an event model may specify an offset, which delays the start of the first period - the occurrence of the very first event - by the given amount of time."/>
          </eAnnotations>
        </eStructuralFeatures>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="InputSynchronizationConstraint"
          eSuperTypes="#//timing/timingconstraints/AgeTimingConstraint">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="InputSynchronizationConstraint is a language entity that expresses a timing constraint on the input synchronization among the set of stimulus events.&#xA;&#xA;Semantics:&#xA;The parameters of InputSynchronizationConstraint, see TimingConstraint, constrain the time from the first stimulus until last stimulus (i.e., maximum skew between these stimuli). A join point is identified by the response event in the scope EventChain.&#xA;&#xA;Constraints:&#xA;[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.&#xA;&#xA;[2] The scope EventChain shall contain exactly one response Event.&#xA;&#xA;[3] 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).&#xA;&#xA;Extension: Class"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="width" ordered="false"
            unique="false" lowerBound="1" eType="#//timing/TimeDuration">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="The width of the sliding window."/>
          </eAnnotations>
        </eStructuralFeatures>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="OutputSynchronizationConstraint"
          eSuperTypes="#//timing/timingconstraints/ReactionConstraint">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="OutputSynchronizationConstraint is a language entity that expresses a timing constraint on the output synchronization among the set of response events.&#xA;&#xA;Semantics:&#xA;The parameters of OutputSynchronizationConstraint, see TimingConstraints, constrain the time from the first response until last response (i.e., maximum skew between these responses). A fork point is identified by the stimulus event in the scope EventChain.&#xA;&#xA;Constraints:&#xA;[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.&#xA;&#xA;[2] The scope EventChain shall contain exactly one stimulus Event.&#xA;&#xA;[3] The semantics of this constraint require that there is more than one response Events in the scope EventChain.&#xA;&#xA;&#xA;Extension: Class"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="width" ordered="false"
            unique="false" lowerBound="1" eType="#//timing/TimeDuration">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="The width of the sliding window."/>
          </eAnnotations>
        </eStructuralFeatures>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="ReactionConstraint" eSuperTypes="#//timing/timingconstraints/DelayConstraint">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="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.&#xA;&#xA;Compare AgeTimingConstraint."/>
        </eAnnotations>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="SporadicEventConstraint" eSuperTypes="#//timing/timingconstraints/EventConstraint">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The Sporadic Event Constraint describes that an event occurs occasionally. In general it is supposed that the event eventually occurs. Indeed, it is also known that some of the events do not occur for whatsoever reasons.&#xA;&#xA;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."/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="jitter" ordered="false"
            unique="false" eType="#//timing/TimeDuration">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="The optional parameter jitter specifies the maximal possible time interval the occurrence of an event can vary (formerly: be delayed). By nature, a sporadic event is supposed to occur at any time, thus it is one of the characteristic that the occurrence is jittery."/>
          </eAnnotations>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EReference" name="period" ordered="false"
            unique="false" lowerBound="1" eType="#//timing/TimeDuration">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="The period specifies the ideal time interval between two subsequent occurrences of the event."/>
          </eAnnotations>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EReference" name="maximumInterArrivalTime"
            ordered="false" unique="false" eType="#//timing/TimeDuration">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="The optional parameter maximum inter-arrival time specifies the maximal possible time interval between two consecutive occurrences of an event.&#xA;The maximum inter-arrival time may be used to describe different cases:&#xA;(1) The maximum inter-arrival time is equal to the duration of the period.&#xA;(2) The maximum inter-arrival time is used to specify a point in time within the period that immediately follows the period subject to consideration.&#xA;(3) The maximum inter-arrival time is used to specify a point in time within one of the subsequent periods that follow the period subject to consideration."/>
          </eAnnotations>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EReference" name="minimumInterArrivalTime"
            ordered="false" unique="false" lowerBound="1" eType="#//timing/TimeDuration">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="The minimum inter-arrival time specifies is the minimal possible time interval between two consecutive occurrences of an event."/>
          </eAnnotations>
        </eStructuralFeatures>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="PeriodicEventConstraint" eSuperTypes="#//timing/timingconstraints/EventConstraint">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The PeriodicEventConstraint describes that an event occurs periodically."/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="jitter" ordered="false"
            unique="false" lowerBound="1" eType="#//timing/TimeDuration">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="The jitter specifies the maximal possible time interval the occurrence of an event can vary (formerly: be delayed)."/>
          </eAnnotations>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EReference" name="period" ordered="false"
            unique="false" lowerBound="1" eType="#//timing/TimeDuration">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="The period specifies the ideal time interval between two subsequent occurrences of the event."/>
          </eAnnotations>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EReference" name="minimumInterArrivalTime"
            ordered="false" unique="false" lowerBound="1" eType="#//timing/TimeDuration">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="The minimum inter-arrival time specifies the minimal possible time interval between two consecutive occurrences of an event."/>
          </eAnnotations>
        </eStructuralFeatures>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="PatternEventConstraint" eSuperTypes="#//timing/timingconstraints/EventConstraint">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The [Concrete] Pattern Event Constraint describes that an event occurs following a known pattern. The pattern event model is characterized by the following parameters:"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="period" ordered="false"
            unique="false" lowerBound="1" eType="#//timing/TimeDuration">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="The period specifies the time interval within the event occurs any number of times following a pattern."/>
          </eAnnotations>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EReference" name="minimumInterArrivalTime"
            ordered="false" unique="false" lowerBound="1" eType="#//timing/TimeDuration">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="The minimum inter-arrival time specifies the minimal possible time interval between two consecutive occurrences of the event within the given period."/>
          </eAnnotations>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EReference" name="occurence" unique="false"
            lowerBound="1" upperBound="-1" eType="#//timing/TimeDuration">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="The set occurrence (1..n) specifies the offset for each occurrence of the event in the specified period. Each occurrence is specified from the beginning of the period"/>
          </eAnnotations>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EReference" name="jitter" ordered="false"
            unique="false" lowerBound="1" eType="#//timing/TimeDuration">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="The jitter specifies maximal possible time interval the occurrence of the events within the given period can vary (formerly: can be delayed)."/>
          </eAnnotations>
        </eStructuralFeatures>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="ArbitraryEventConstraint" eSuperTypes="#//timing/timingconstraints/EventConstraint">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The Arbitrary Event Model describes that an event occurs occasionally, singly, irregular 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.&#xA;&#xA;Constraints:&#xA;[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."/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="minimumInterArrivalTime"
            ordered="false" unique="false" lowerBound="1" upperBound="-1" eType="#//timing/TimeDuration">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="The set of minimum inter-arrival times specifies the minimum inter-arrival time between two and more subsequent occurrences of the event. The first element in the set specifies the minimum inter-arrival time between two subsequent occurrences of the event among the given occurrences. The second element in the set specifies the minimum inter-arrival time between three subsequent occurrences of the event among the given occurrences; and so forth."/>
          </eAnnotations>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EReference" name="maximumInterArrivalTime"
            ordered="false" unique="false" lowerBound="1" upperBound="-1" eType="#//timing/TimeDuration">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="The set of maximum inter-arrival times specifies the maximum inter-arrival time between two and more subsequent occurrences of the event. The first element in the set specifies the maximum inter-arrival time between two subsequent occurrences of the event among the given occurrences. The second element in the set specifies the maximum inter-arrival time between three subsequent occurrences of the event among the given occurrences; and so forth."/>
          </eAnnotations>
        </eStructuralFeatures>
      </eClassifiers>
    </eSubpackages>
    <eSubpackages name="events" nsURI="http://www.papyrusuml.org/EAST-ADL2/Timing/Events/1"
        nsPrefix="Events">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="This section describes the concept of events for EAST-ADL2."/>
      </eAnnotations>
      <eClassifiers xsi:type="ecore:EClass" name="EventFunctionFlowPort" eSuperTypes="#//timing/Event">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="Event that refers to the triggering of the Function at a flow port, i.e., when data is sent or received."/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="port" ordered="false"
            unique="false" lowerBound="1" eType="#//structure/functionmodeling/FunctionPort"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="port_path" upperBound="-1"
            eType="#//structure/functionmodeling/FunctionPrototype"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="EventFunctionClientServerPort" eSuperTypes="#//timing/Event">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="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.&#xA;&#xA;Constraints:&#xA;[1] eventKind is sentRequest or receivedResponse for a FunctionClientServerPort of type client. Rationale: Only these values make sense for client ports.&#xA;&#xA;[2] eventKind is receivedRequest or sentResponse for a FunctionClientServerPort of type server. Rationale: Only these values make sense for server ports."/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="eventKind" ordered="false"
            unique="false" lowerBound="1" eType="#//timing/events/EventFunctionClientServerPortKind"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="port" ordered="false"
            unique="false" lowerBound="1" eType="#//structure/functionmodeling/FunctionClientServerPort"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="port_path" upperBound="-1"
            eType="#//structure/functionmodeling/FunctionPrototype"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EEnum" name="EventFunctionClientServerPortKind">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="Possible values of eventKind.&#xA;&#xA;Extension: &#xA;Enumeration, no extension."/>
        </eAnnotations>
        <eLiterals name="receivedRequest"/>
        <eLiterals name="sentResponse" value="1"/>
        <eLiterals name="sentRequest" value="2"/>
        <eLiterals name="receivedResponse" value="3"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="EventFunction" eSuperTypes="#//timing/Event">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="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 is used in conjunction with FunctionTrigger (see that concept) 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. &#xA;&#xA;Compare categories of AUTOSAR runnables:&#xA;&#xA;1a triggering only on start and finish (this type of event)&#xA;&#xA;1b triggering allowed anytime during the execution (events on ports, see EventInFlowPort)&#xA;&#xA;&#xA;Constraints:&#xA;[1] An EventFunction either identifies a FunctionType or a FunctionPrototype as its target function."/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="function" ordered="false"
            unique="false" eType="#//structure/functionmodeling/FunctionPrototype"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="functionType" ordered="false"
            unique="false" eType="#//structure/functionmodeling/FunctionType"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="function_path" upperBound="-1"
            eType="#//structure/functionmodeling/FunctionPrototype"/>
      </eClassifiers>
    </eSubpackages>
  </eSubpackages>
  <eSubpackages name="interchange" nsURI="http://www.papyrusuml.org/EAST-ADL2/Interchange/1"
      nsPrefix="Interchange">
    <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
      <details key="documentation" value="The interchange part of an EAST-ADL2 system model is for exchanging model data with external stakeholders. E.g. it provides elements (see RIFArea) for importing resp. exporting requirements specifications into resp. out of an EAST-ADL2 system model."/>
    </eAnnotations>
    <eClassifiers xsi:type="ecore:EClass" name="RIFArea" abstract="true" eSuperTypes="#//infrastructure/elements/Context">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="An extra allocated part of the EAST-ADL2 System Model that contains Requirement Specific Data (Container, Reqs etc...) from RIF Import resp. RIF Export.&#xA;&#xA;Especially for the context of requirement engineering and considering the possibility to import/export requirement related data via RIF, the feature uuid will be used to check that two elements are semantically the same and thus should stay together in reference via a Multi-Level reference link.&#xA;&#xA;Since requirement data to be imported/exported will be put into RIFArea, requirement data elements which are not inside RIFArea and 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."/>
      </eAnnotations>
      <eStructuralFeatures xsi:type="ecore:EReference" name="rootRequirementContainer"
          unique="false" upperBound="-1" eType="#//requirements/RequirementsContainer"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
          unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="interchangeReqSpecObject"
          ordered="false" unique="false" upperBound="-1" eType="#//requirements/RequirementSpecificationObject"/>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EClass" name="RIFExportArea" eSuperTypes="#//interchange/RIFArea">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="Contains (clones of) requirement specific data to be exported in RIF format."/>
      </eAnnotations>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EClass" name="RIFImportArea" eSuperTypes="#//interchange/RIFArea">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="Contains requirement specific data to be imported from an external RIF file.&#xA;&#xA;If an element will be imported from external the uuid will be taken from the given external exchange data file, because the identifier is global unique and shall not be changed somewhere."/>
      </eAnnotations>
    </eClassifiers>
  </eSubpackages>
  <eSubpackages name="environment" nsURI="http://www.papyrusuml.org/EAST-ADL2/Environment/1"
      nsPrefix="Environment">
    <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
      <details key="documentation" value="The Environment model is used to describe the environment of the vehicle electric and electronic architecture. It is modeled by continuous functions representing the system environment."/>
    </eAnnotations>
    <eClassifiers xsi:type="ecore:EClass" name="Environment" eSuperTypes="#//infrastructure/elements/Context">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="The collection of the environment functional description. This collection can be done across the EAST-ADL2 abstraction levels.&#xA;&#xA;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).&#xA;&#xA;A functionPrototype of the environment model can have interactions with FAA FunctionalDevice and an FDA HardwareFunction through the ClampConnector."/>
      </eAnnotations>
      <eStructuralFeatures xsi:type="ecore:EReference" name="environmentModel" ordered="false"
          eType="#//structure/functionmodeling/FunctionPrototype"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="clampConnector" ordered="false"
          upperBound="-1" eType="#//environment/ClampConnector"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
          unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="base_Package" ordered="false"
          unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Package"/>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EClass" name="ClampConnector" eSuperTypes="#//infrastructure/elements/EAElement">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="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.&#xA;&#xA;Constraints:&#xA;[1] Can connect two FunctionFlowPorts of different direction.&#xA;[2] Can connect two ClientServerPorts of different kind.&#xA;[3] Can connect two FunctionFlowPorts with direction inout.&#xA;[4] Cannot connect ports in the same SystemModel."/>
      </eAnnotations>
      <eStructuralFeatures xsi:type="ecore:EReference" name="port" ordered="false"
          lowerBound="2" upperBound="2" eType="#//structure/functionmodeling/FunctionPort"
          changeable="false" volatile="true" transient="true" derived="true"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="base_Connector" ordered="false"
          unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Connector"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="port1_path" upperBound="-1"
          eType="#//structure/functionmodeling/FunctionPrototype"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="port2_path" upperBound="-1"
          eType="#//structure/functionmodeling/FunctionPrototype"/>
    </eClassifiers>
  </eSubpackages>
  <eSubpackages name="dependability" nsURI="http://www.papyrusuml.org/EAST-ADL2/Dependability/1"
      nsPrefix="Dependability">
    <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
      <details key="documentation" value="Dependability of a system is the ability to avoid service failures that are more frequent and more severe than is acceptable. Dependability includes several aspects, namely Availability, Reliability, Safety, Integrity and Maintainability. The Dependability package includes support for defining and classifying safety requirements through preliminary Hazard Analysis Risk Assessment, tracing and categorizing safety requirements according to role in safety life-cycle, formalizing safety requirements using safety constraints, formalizing and assessing fault propagation through error models and organizing evidence of safety in a Safety Case.&#xA;The support for safety is designed to support the automotive standard for Functional Safety, ISO/DIS 26262."/>
    </eAnnotations>
    <eClassifiers xsi:type="ecore:EClass" name="HazardousEvent" eSuperTypes="#//infrastructure/elements/TraceableSpecification">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="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. &#xA;&#xA;Semantics:&#xA;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.&#xA;&#xA;Notation:&#xA;The Hazard is shown as a solid-outline rectangle with &quot;Haz&quot; at the top right. It contains the name of the Hazard and optionally the name of the source entity.&#xA;&#xA;Extension: &#xA;UML::Class"/>
      </eAnnotations>
      <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
          unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
      <eStructuralFeatures xsi:type="ecore:EAttribute" name="controllability" ordered="false"
          unique="false" lowerBound="1" eType="#//dependability/ControllabilityClassKind"/>
      <eStructuralFeatures xsi:type="ecore:EAttribute" name="exposure" ordered="false"
          unique="false" lowerBound="1" eType="#//dependability/ExposureClassKind"/>
      <eStructuralFeatures xsi:type="ecore:EAttribute" name="hazardClassification"
          ordered="false" unique="false" lowerBound="1" eType="#//dependability/safetyconstraints/ASILKind"/>
      <eStructuralFeatures xsi:type="ecore:EAttribute" name="severity" ordered="false"
          unique="false" lowerBound="1" eType="#//dependability/SeverityClassKind"/>
      <eStructuralFeatures xsi:type="ecore:EAttribute" name="classificationAssumptions"
          ordered="false" unique="false" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//String"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="hazard" ordered="false"
          unique="false" lowerBound="1" upperBound="-1" eType="#//dependability/Hazard"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="traffic" ordered="false"
          unique="false" upperBound="-1" eType="#//requirements/OperationalSituation"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="environment" ordered="false"
          unique="false" upperBound="-1" eType="#//requirements/OperationalSituation"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="operationalSituationUseCase"
          ordered="false" unique="false" lowerBound="1" upperBound="-1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//UseCase"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="operatingMode" ordered="false"
          unique="false" upperBound="-1" eType="#//behavior/Mode"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="externalMeasures" ordered="false"
          unique="false" upperBound="-1" eType="#//requirements/Requirement"/>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EEnum" name="ControllabilityClassKind">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="The ControllabilityClassKind is an enumeration metaclass with enumeration literals indicating controllability attributes C0, C1, C2 or C3 in accordance with ISO26262.&#xA;&#xA;Semantics:&#xA;The semantics is defined at each enumeration literal and fully defined in the ISO26262 standard.&#xA;&#xA;Extension: &#xA;Enumeration, no extension."/>
      </eAnnotations>
      <eLiterals name="C1">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="Simply controllable"/>
        </eAnnotations>
      </eLiterals>
      <eLiterals name="C2" value="1">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="Normally controllable"/>
        </eAnnotations>
      </eLiterals>
      <eLiterals name="C3" value="2">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="Difficult to control or uncontrollable"/>
        </eAnnotations>
      </eLiterals>
      <eLiterals name="C0" value="3">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="Controllable in general"/>
        </eAnnotations>
      </eLiterals>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EEnum" name="ExposureClassKind">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="The ExposureClassKind is an enumeration metaclass with enumeration literals indicating the probability attributes E1, E2, E3 or E4 in accordance with ISO26262.&#xA;&#xA;Semantics:&#xA;The semantics is defined at each enumeration literal and fully defined in the ISO26262 standard.&#xA;&#xA;Extension: &#xA;Enumeration, no extension."/>
      </eAnnotations>
      <eLiterals name="E1">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="Rare events&#xD;&#xA;Situations that occur less often yhan once a year for the great majority of drivers"/>
        </eAnnotations>
      </eLiterals>
      <eLiterals name="E2" value="1">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="Sometimes&#xD;&#xA;Situations that occur a few times a year for the great majority of drivers"/>
        </eAnnotations>
      </eLiterals>
      <eLiterals name="E3" value="2">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="Quite often&#xD;&#xA;Situations that occur once a month or more often for an average driver"/>
        </eAnnotations>
      </eLiterals>
      <eLiterals name="E4" value="3">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="Often&#xD;&#xA;All situations that occur during almost every drive on average"/>
        </eAnnotations>
      </eLiterals>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EEnum" name="SeverityClassKind">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="The SeverityClassKind is an enumeration metaclass with enumeration literals indicating the severity attributes S0, S1, S2 or S3 in accordance with ISO26262.&#xA;&#xA;Semantics:&#xA;The semantics is defined at each enumeration literal and fully defined in the ISO26262 standard.&#xA;&#xA;Extension: &#xA;Enumeration, no extension."/>
      </eAnnotations>
      <eLiterals name="S0">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="No injuries."/>
        </eAnnotations>
      </eLiterals>
      <eLiterals name="S1" value="1">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="Light and moderate injuries"/>
        </eAnnotations>
      </eLiterals>
      <eLiterals name="S2" value="2">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="Severe and life-threatening injuries (survival probable)"/>
        </eAnnotations>
      </eLiterals>
      <eLiterals name="S3" value="3">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="Life-threatening injuries (survival uncertain), fatal injuries"/>
        </eAnnotations>
      </eLiterals>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EClass" name="Hazard" eSuperTypes="#//infrastructure/elements/TraceableSpecification">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="The Hazard represents a condition or state in the system that may contribute to accidents. It is usually a failure of some kind, but may also be a result of nominal operation. &#xA;The Hazard does not address hazards as electric shock, fire, smoke, heat, radiation, toxicity, flammability, reactivity, corrosion, release of energy, and similar hazards unless directly caused by malfunctioning behaviour of E/E safety related systems..&#xA;The Hazard metaclass is contained in the context, as Hazard specializes ADLTraceableSpecification. The context describes the element of the system where this hazard occur."/>
      </eAnnotations>
      <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
          unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="malfunction" ordered="false"
          unique="false" lowerBound="1" upperBound="-1" eType="#//dependability/FeatureFlaw"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="item" ordered="false"
          unique="false" lowerBound="1" upperBound="-1" eType="#//dependability/Item"/>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EClass" name="FeatureFlaw" eSuperTypes="#//infrastructure/elements/TraceableSpecification">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="FeatureFlaw denotes an abstract failure of a set of items, i.e. an inability to fulfill one or several of its requirements.&#xA;&#xA;Semantics:&#xA;FeatureFlaw represents functional anomalies derivable from each foreseeable source. nonFulfilledRequirements identifies those requirements that corresponds to the FeatureFlaw.&#xA;&#xA;Extension:&#xA;UML::Class"/>
      </eAnnotations>
      <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
          unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="item" ordered="false"
          unique="false" lowerBound="1" upperBound="-1" eType="#//dependability/Item"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="nonFulfilledRequirement"
          ordered="false" unique="false" upperBound="-1" eType="#//requirements/Requirement"/>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EClass" name="Item" eSuperTypes="#//infrastructure/elements/EAElement">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="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.&#xA;&#xA;Semantics:&#xA;Item represents the scope of safety information and the safety assessment trough its reference to one or several Features.&#xA;&#xA;Extension:&#xA;UML::Class"/>
      </eAnnotations>
      <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
          unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
      <eStructuralFeatures xsi:type="ecore:EAttribute" name="developmentCategory"
          ordered="false" unique="false" lowerBound="1" eType="#//dependability/DevelopmentCategoryKind">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="It shall be determined whether the item is a modification of an existing item or if it is a new development."/>
        </eAnnotations>
      </eStructuralFeatures>
      <eStructuralFeatures xsi:type="ecore:EReference" name="vehicleFeature" ordered="false"
          unique="false" lowerBound="1" upperBound="-1" eType="#//structure/vehiclefeaturemodeling/VehicleFeature"/>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EEnum" name="DevelopmentCategoryKind">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="DevelopmentCategoryKind in an enumeration with enumeration literals indicating whether the item is a modification of an existing item or if it is a new development.&#xA;&#xA;Semantics:&#xA;The semantics is defined at each enumeration literal and fully defined in the ISO26262 standard.&#xA;&#xA;Extension: &#xA;Enumeration, no extension."/>
      </eAnnotations>
      <eLiterals name="modificationOfExistingItem">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="In case of a modification the relevant lifecycle sub-phases and activities shall be determined."/>
        </eAnnotations>
      </eLiterals>
      <eLiterals name="newItemDevelopment" value="1">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="In case of a new development, the entire lifecycle shall be passed through."/>
        </eAnnotations>
      </eLiterals>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EClass" name="Dependability" eSuperTypes="#//infrastructure/elements/Context">
      <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
          unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="base_Package" ordered="false"
          unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Package"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="functionalSafetyConcept"
          ordered="false" unique="false" upperBound="-1" eType="#//dependability/safetyrequirement/FunctionalSafetyConcept"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="safetyGoal" ordered="false"
          unique="false" upperBound="-1" eType="#//dependability/safetyrequirement/SafetyGoal"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="technicalSafetyConcept"
          ordered="false" unique="false" upperBound="-1" eType="#//dependability/safetyrequirement/TechnicalSafetyConcept"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="hazardousEvent" ordered="false"
          unique="false" upperBound="-1" eType="#//dependability/HazardousEvent"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="featureFlaw" ordered="false"
          unique="false" upperBound="-1" eType="#//dependability/FeatureFlaw"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="item" ordered="false"
          unique="false" upperBound="-1" eType="#//dependability/Item"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="eADatatype" ordered="false"
          unique="false" upperBound="-1" eType="#//infrastructure/datatypes/EADatatype"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="faultFailure" ordered="false"
          unique="false" upperBound="-1" eType="#//dependability/safetyconstraints/FaultFailure"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="quantitativeSafetyConstraint"
          ordered="false" unique="false" upperBound="-1" eType="#//dependability/safetyconstraints/QuantitativeSafetyConstraint"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="safetyConstraint" ordered="false"
          unique="false" upperBound="-1" eType="#//dependability/safetyconstraints/SafetyConstraint"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="safetyCase" ordered="false"
          unique="false" upperBound="-1" eType="#//dependability/safetycase/SafetyCase"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="errorModelType" ordered="false"
          unique="false" upperBound="-1" eType="#//dependability/errormodel/ErrorModelType"/>
    </eClassifiers>
    <eSubpackages name="errormodel" nsURI="http://www.papyrusuml.org/EAST-ADL2/Dependability/ErrorModel/1"
        nsPrefix="ErrorModel">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="The EAST-ADL2 sub-package for error modeling provides support for safety engineering by representing possible, incorrect behaviors of a system in its operation (e.g., component errors and their propagations).&#xA;Abnormal behaviors of architectural elements as well as their instantiations in a particular product context can be represented, forming a basis for safety analysis through external techniques and tools. Through the integration with other language constructs, definitions of error behaviors and hazards can be traced to the specifications of safety requirements, and further to the subsequent functional and non-functional requirements on error handing and hazard mitigations as well as to the necessary V&amp;V efforts. &#xA;Error behaviors are treated as a separated view, orthogonal to the nominal architecture model. This separation of concern in modeling is considered necessary in order to avoid some undesired effects of error modeling, such as the risk of mixing nominal and erroneous behavior in regards to the comprehension, reuse, and system synthesis (e.g., code generation)."/>
      </eAnnotations>
      <eClassifiers xsi:type="ecore:EClass" name="ErrorBehavior" eSuperTypes="#//infrastructure/elements/EAElement">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="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.&#xA;Each ErrorBehavior description relates the occurrences of internal faults and incoming external faults to failures. The faults and failures that the errorBehavior propagated to and from the target element are declared through the ports of the error model.&#xA;&#xA;Semantics: &#xA;ErrorBehavior defines the error propagation logic of its containing ErrorModelType.&#xA;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. &#xA;The ErrorBehavior is defined in the failureLogic string, either directly or as a url referencing an external specification. &#xA;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. &#xA;&#xA;Extension:&#xA;UML:Behavior"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Behavior" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Behavior"/>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="failureLogic" ordered="false"
            unique="false" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//String">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="The error logic description based on an external formalism or the path to the file or model entity containing the external error logic description."/>
          </eAnnotations>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="type" ordered="false"
            unique="false" lowerBound="1" eType="#//dependability/errormodel/ErrorBehaviorKind">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="The type of formalism applied for the error behavior description."/>
          </eAnnotations>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EReference" name="internalFault" ordered="false"
            unique="false" upperBound="-1" eType="#//dependability/errormodel/InternalFaultPrototype">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="The occurrences of internal faults."/>
          </eAnnotations>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EReference" name="owner" ordered="false"
            unique="false" eType="#//dependability/errormodel/ErrorModelType" eOpposite="#//dependability/errormodel/ErrorModelType/errorBehaviorDescription"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="externalFailure" ordered="false"
            unique="false" lowerBound="1" upperBound="-1" eType="#//dependability/errormodel/FailureOutPort"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="externalFault" ordered="false"
            unique="false" upperBound="-1" eType="#//dependability/errormodel/FaultInPort"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="processFault" ordered="false"
            unique="false" upperBound="-1" eType="#//dependability/errormodel/ProcessFaultPrototype"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EEnum" name="ErrorBehaviorKind">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The ErrorBehaviorKind metaclass represents an enumeration of literals describing various types of formalisms used for specifying error behavior.&#xA;&#xA;Semantics:&#xA;ErrorBehaviorKind represents different formalisms for ErrorBehavior. The semantics is defined at each enumeration literal. &#xA;&#xA;Extension: &#xA;Enumeration, no extension."/>
        </eAnnotations>
        <eLiterals name="HIP_HOPS"/>
        <eLiterals name="ALTARICA" value="1"/>
        <eLiterals name="AADL" value="2"/>
        <eLiterals name="OTHER" value="3"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="InternalFaultPrototype" eSuperTypes="#//dependability/errormodel/Anomaly">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The InternalFault metaclass represents the particular internal conditions of the target component/system that are of particular concern for its fault/failure definition. &#xA;&#xA;Semantics:&#xA;The system anomaly represented by an InternalFault, which when activated, can cause errors and failures of the target element.&#xA;&#xA;Extension:&#xA;UML::Part / UML::Event"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
            unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Event" ordered="false"
            unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Event"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="Anomaly" eSuperTypes="#//infrastructure/elements/EAElement">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The Anomaly metaclass represents a Fault that may occur internally in an ErrorModel or being 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:&#xA;&#xA;BrakeAnomaly:&#xA;- BrakePressureTooLow&#xA;Semantics=&quot;brake pressure is below 20% of requested value&quot;&#xA;- Omission&#xA;Semantics=&quot;brake pressure is below 10% of maximal brake pressure&quot;&#xA;- Comission&#xA;Semantics=&quot;brake pressure exceeds requested value with more than 10% of maximal brake pressure&quot;&#xA;&#xA;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.&#xA;&#xA;Semantics:&#xA;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.&#xA;&#xA;&#xA;Extension:&#xA;(UML::Part)"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="genericDescription"
            ordered="false" unique="false" lowerBound="1" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//String"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Property" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Property"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="type" ordered="false"
            unique="false" lowerBound="1" eType="#//infrastructure/datatypes/EADatatype"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="ErrorModelType" eSuperTypes="#//infrastructure/elements/TraceableSpecification">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="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. &#xA;&#xA;An ErrorModelType represents the internal faults and fault propagations of the nominal element that it targets. &#xA;&#xA;Typically the target is a system/subsystem, a function, a software component, or a hardware device.&#xA;&#xA;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. &#xA;&#xA;Constraints:&#xA;An ErrorModelType without part shall have one errorBehaviorDescription&#xA;&#xA;Semantics:&#xA;The ErrorModelType represents a specification of the faults and fault propagations of its target element. &#xA;&#xA;Both types and prototypes may be targets, and the following cases are relevant:&#xA;- One nominal type: &#xA;The ErrorModelType represents the identified nominal type wherever this nominal type is instantiated. &#xA;- Several nominal types: &#xA;The ErrorModelType represents the identified nominal types individually, i.e. the same error model applies to all nominal types and is reused.&#xA;- One nominal prototype: &#xA;The ErrorModelType represents the identified nominal prototype whenever its context, i.e. its top-level composition is instantiated. &#xA;- Several nominal prototypes with instanceref: &#xA;The ErrorModelType represents the identified set of nominal prototypes (together) whenever their context, i.e. their top-level composition is instantiated. &#xA;&#xA;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.&#xA;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. &#xA;The ErrorModelType contains internalFaults and externalFaults, representing faults that are either propagated to externalFailures or masked, according to the definition of its fault propagation.&#xA;A processFault represents a flaw introduced during design, and may lead to any of the failures represented by the ErrorModelType. A processFault thus has a direct propagation to all externalFailures and cannot be masked. &#xA;&#xA;Extension:&#xA;(see ADLTraceableSpecfication)"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="genericDescription"
            ordered="false" unique="false" lowerBound="1" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//String"
            defaultValueLiteral="NA"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="faultFailureConnector"
            ordered="false" upperBound="-1" eType="#//dependability/errormodel/FaultFailurePropagationLink"
            changeable="false" volatile="true" transient="true" derived="true">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="The links for the error propagations between subordinate error models.&#xD;{derived from UML::StructuredClassifier::ownedConnector}"/>
          </eAnnotations>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EReference" name="part" ordered="false"
            upperBound="-1" eType="#//dependability/errormodel/ErrorModelPrototype"
            changeable="false" volatile="true" transient="true" derived="true">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="{derived from UML::Classifier::attribute}"/>
          </eAnnotations>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EReference" name="failure" ordered="false"
            upperBound="-1" eType="#//dependability/errormodel/FailureOutPort" changeable="false"
            volatile="true" transient="true" derived="true"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="externalFault" ordered="false"
            upperBound="-1" eType="#//dependability/errormodel/FaultInPort" changeable="false"
            volatile="true" transient="true" derived="true"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="internalFault" ordered="false"
            upperBound="-1" eType="#//dependability/errormodel/InternalFaultPrototype"
            changeable="false" volatile="true" transient="true" derived="true"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="processFault" ordered="false"
            upperBound="-1" eType="#//dependability/errormodel/ProcessFaultPrototype"
            changeable="false" volatile="true" transient="true" derived="true"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="target" ordered="false"
            unique="false" upperBound="-1" eType="#//structure/functionmodeling/FunctionType"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="hwTarget" ordered="false"
            unique="false" upperBound="-1" eType="#//structure/hardwaremodeling/HardwareComponentType"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="errorBehaviorDescription"
            ordered="false" lowerBound="1" upperBound="-1" eType="#//dependability/errormodel/ErrorBehavior"
            eOpposite="#//dependability/errormodel/ErrorBehavior/owner"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="FaultFailurePropagationLink" eSuperTypes="#//infrastructure/elements/EAElement">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="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.&#xA;&#xA;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. &#xA;&#xA;Constraints:&#xA;[1] Only compatible fromPort-toPort pairs may be connectedNo additional constraints&#xA;&#xA;[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. &#xA;&#xA;&#xA;Semantics:&#xA;The FaultFailurePropagationLink defines a Failure propagation path, from the fromPort on one error model to the toPort of another error model. &#xA;&#xA;&#xA;Extension:&#xA;UML::Connector"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Connector" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Connector"/>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="immediatePropagation"
            ordered="false" unique="false" lowerBound="1" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//Boolean"
            defaultValueLiteral="true"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="toPort" ordered="false"
            lowerBound="1" eType="#//dependability/errormodel/FaultFailurePort" changeable="false"
            volatile="true" transient="true" derived="true"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="fromPort" ordered="false"
            lowerBound="1" eType="#//dependability/errormodel/FaultFailurePort" changeable="false"
            volatile="true" transient="true" derived="true"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="fromPort_path" upperBound="-1"
            eType="#//dependability/errormodel/ErrorModelPrototype"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="toPort_path" upperBound="-1"
            eType="#//dependability/errormodel/ErrorModelPrototype"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="FaultFailurePort" abstract="true"
          eSuperTypes="#//dependability/errormodel/Anomaly">
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Port" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Port"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="functionTarget" ordered="false"
            unique="false" upperBound="-1" eType="#//structure/functionmodeling/FunctionPort"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="hwTarget" ordered="false"
            unique="false" upperBound="-1" eType="#//structure/hardwaremodeling/HardwarePin"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="functionTarget_path"
            upperBound="-1" eType="#//structure/functionmodeling/FunctionPrototype"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="hwTarget_path" upperBound="-1"
            eType="#//structure/hardwaremodeling/HardwareComponentPrototype"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="ErrorModelPrototype" eSuperTypes="#//infrastructure/elements/EAElement">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="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. &#xA;&#xA;The ErrorModelPrototype is used to define hierarchical error models allowing additional detail or structure to the error model of a particular target. A hierarchal structure can also be defined when several ErrorModels are integrated to a larger ErrorModel representing a system integrated from several targets. &#xA;&#xA;Typically the target is a system/subsystem, a function, a software component, or a hardware device.&#xA;&#xA;&#xA;Semantics:&#xA;An ErrorModelPrototype represents a unique compositional occurrence of the ErrorModelType that types it in the containing ErrorModelType.&#xA;&#xA;Extension:&#xA;(See ADLFunctionPrototype)"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Property" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Property"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="type" ordered="false"
            lowerBound="1" eType="#//dependability/errormodel/ErrorModelType" changeable="false"
            volatile="true" transient="true" derived="true">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="{derived from UML::TypedElement::type}"/>
          </eAnnotations>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EReference" name="target" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//NamedElement"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="functionTarget" ordered="false"
            unique="false" upperBound="-1" eType="#//structure/functionmodeling/FunctionPrototype"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="hwTarget" ordered="false"
            unique="false" upperBound="-1" eType="#//structure/hardwaremodeling/HardwareComponentPrototype"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="functionTarget_path"
            upperBound="-1" eType="#//structure/functionmodeling/FunctionPrototype"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="hwTarget_path" upperBound="-1"
            eType="#//structure/hardwaremodeling/HardwareComponentPrototype" containment="true"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="FailureOutPort" eSuperTypes="#//dependability/errormodel/FaultFailurePort">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="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.&#xA;&#xA;&#xA;Constraints:&#xA;[1] The direction of the nominal port must be out.&#xA;&#xA;Semantics:&#xA;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.&#xA;&#xA;If nominal Ports HWTargets or FunctionTargets are referenced, the failures of the FailureOutPort correspond to data on these nominal ports.&#xA;&#xA;&#xA;Extension: &#xA;UML::Port"/>
        </eAnnotations>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="FaultInPort" eSuperTypes="#//dependability/errormodel/FaultFailurePort">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="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.&#xA;&#xA;Constraints:&#xA;[1] The direction of the nominal port must be in.&#xA;&#xA;Semantics:&#xA;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.&#xA;&#xA;If nominal Ports HWTarget or FunctionTarget are referenced, the faults on the FaultInPort.&#xA;&#xA;&#xA;Extension: &#xA;UML::Port"/>
        </eAnnotations>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="ProcessFaultPrototype" eSuperTypes="#//dependability/errormodel/Anomaly">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="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.). &#xA;&#xA;Semantics: &#xA;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.).&#xA;&#xA;Extension:&#xA;UML::Part / UML::Event"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Event" ordered="false"
            unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Event"/>
      </eClassifiers>
    </eSubpackages>
    <eSubpackages name="safetyrequirement" nsURI="http://www.papyrusuml.org/EAST-ADL2/Dependability/SafetyRequirement/1"
        nsPrefix="SafetyRequirement">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="This subprofile defines a set of stereotypes concerning the definition of safety requirements inked to ISO26262 norm.&#xD;&#xA;&#xD;&#xA;Overview:&#xD;&#xA;This subprofile defines a set of stereotypes concerning the definition of safety requirements linked to the ISO26262 norm."/>
      </eAnnotations>
      <eClassifiers xsi:type="ecore:EClass" name="FunctionalSafetyConcept" eSuperTypes="#//requirements/RequirementsContainer">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="FunctionalSafetyConcept represents the set of functional safety requirements that together fulfils a SafetyGoal in accordance with ISO 26262.&#xA;&#xA;To comply with the SafetyGoals, the FunctionalSafetyConcept specifies the basic safety mechanisms and safety measures in the form of functional safety requirements.&#xA;&#xA;Constraints:&#xA;[1] Contained functionalSafetyRequirements shall not be of type SafetyGoal.&#xA;&#xA;Semantics:&#xA;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."/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="functionalSafetyRequirement"
            unique="false" upperBound="-1" eType="#//requirements/Requirement"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="SafetyGoal" eSuperTypes="#//infrastructure/elements/EAElement">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="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.&#xA;The SafetyGoal is defined through one or several associated requirement elements.&#xA;An ASIL shall be assigned to each SafetyGoal, to represent the integrity level at which the SafetyGoal must be met.&#xA;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. &#xA;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.&#xA;&#xA;Semantics:&#xA;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.&#xA;&#xA;Notation:&#xA;SafetyGoal is a box with text SafetyGoal at the top left.&#xA;&#xA;Extension:&#xA;Class"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="derivedFrom" ordered="false"
            unique="false" lowerBound="1" upperBound="-1" eType="#//dependability/HazardousEvent"/>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="safeStates" ordered="false"
            unique="false" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//String">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="For every safety goal, 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 safety goal."/>
          </eAnnotations>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="requirement" ordered="false"
            unique="false" lowerBound="1" upperBound="-1" eType="#//requirements/Requirement"/>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="hazardClassification"
            ordered="false" unique="false" lowerBound="1" eType="#//dependability/safetyconstraints/ASILKind"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="safeModes" ordered="false"
            unique="false" upperBound="-1" eType="#//behavior/Mode"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="TechnicalSafetyConcept" eSuperTypes="#//requirements/RequirementsContainer">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="TechnicalSafetyConcept represents the set of technical safety requirements that together fulfils a FunctionalSafetyConcept and SafetyGoal in accordance with ISO 26262.&#xA;&#xA;These are derived from FunctionalSafetyConcepts i.e. TechnicalSafetyRequirements are derived from FunctionalSafetyRequirements.&#xA;&#xA;&#xA;Semantics:&#xA;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."/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="technicalSafetyRequirement"
            unique="false" upperBound="-1" eType="#//requirements/Requirement">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="technicalSafety Requirements."/>
          </eAnnotations>
        </eStructuralFeatures>
      </eClassifiers>
    </eSubpackages>
    <eSubpackages name="safetyconstraints" nsURI="http://www.papyrusuml.org/EAST-ADL2/Dependability/SafetyConstraints/1"
        nsPrefix="SafetyConstraints">
      <eClassifiers xsi:type="ecore:EClass" name="FaultFailure" eSuperTypes="#//infrastructure/elements/TraceableSpecification">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="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. &#xA;&#xA;Semantics:&#xA;A FaultFailure is defined as a certain value, faultFailureValue, occurring at the referenced Anomaly."/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="faultFailureValue"
            ordered="false" lowerBound="1" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//String"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="anomaly" ordered="false"
            unique="false" eType="#//dependability/errormodel/Anomaly"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="SafetyConstraint" eSuperTypes="#//infrastructure/elements/TraceableSpecification">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The SafetyConstraint metaclass represents the qualitative integrity constraints on a fault or failure. Thus, the system has 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.&#xA;&#xA;Semantics:&#xA;A SafetyConstraint defines qualitative bounds on the constrainedFaultFailure in terms of safety integrity level, asilValue.&#xA;&#xA;Depending on role, the SafetyConstraint may define a required or an actual safety integrity level. &#xA;&#xA;&#xA;Extension:&#xA;(see ADLTraceableSpecification)"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="asilValue" ordered="false"
            unique="false" lowerBound="1" eType="#//dependability/safetyconstraints/ASILKind"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="constrainedFaultFailure"
            ordered="false" unique="false" lowerBound="1" upperBound="-1" eType="#//dependability/safetyconstraints/FaultFailure"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
            unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Constraint" ordered="false"
            unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Constraint"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="QuantitativeSafetyConstraint" eSuperTypes="#//infrastructure/elements/TraceableSpecification">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The QuantitativeSafetyConstraint metaclass represents the quantitative integrity constraints on a fault or failure. Thus, the system has 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.&#xA;&#xA;Semantics:&#xA;A QuantitativeSafetyConstraint provides information about the probabilistic estimates of target faults/failures, further specified by the failureRate and repairRate attribute.&#xA;&#xA;Extension:&#xA;(see ADLTraceableSpecification)"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="constrainedFaultFailure"
            ordered="false" unique="false" lowerBound="1" upperBound="-1" eType="#//dependability/safetyconstraints/FaultFailure"/>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="failureRate" ordered="false"
            unique="false" lowerBound="1" eType="#//infrastructure/datatypes/javalangFloat"/>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="repairRate" ordered="false"
            unique="false" lowerBound="1" eType="#//infrastructure/datatypes/javalangFloat"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
            unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Constraint" ordered="false"
            unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Constraint"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EEnum" name="ASILKind">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The ASILKind is an enumeration metaclass with enumeration literals indicating the level of safety integrity in accordance with ISO26262.&#xA;&#xA;Semantics:&#xA;The semantics is defined at each enumeration literal and fully defined in the ISO26262 standard.&#xA;&#xA;Extension: &#xA;Enumeration, no extension."/>
        </eAnnotations>
        <eLiterals name="ASIL_A">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="ASIL A, Lowest Safety Integrity Level."/>
          </eAnnotations>
        </eLiterals>
        <eLiterals name="ASIL_D" value="1">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="ASIL D, Highest Safety Integrity Level."/>
          </eAnnotations>
        </eLiterals>
        <eLiterals name="ASIL_C" value="2">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="ASIL C, second highest Safety Integrity Level."/>
          </eAnnotations>
        </eLiterals>
        <eLiterals name="ASIL_B" value="3">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="ASIL B, second lowest Safety Integrity Level."/>
          </eAnnotations>
        </eLiterals>
        <eLiterals name="QM" value="4">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="Quality Management only, no requirement according to ISO 26262."/>
          </eAnnotations>
        </eLiterals>
      </eClassifiers>
    </eSubpackages>
    <eSubpackages name="safetycase" nsURI="http://www.papyrusuml.org/EAST-ADL2/Dependability/SafetyCase/1"
        nsPrefix="SafetyCase">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="Safety is a property of a system that is difficult to verify quantitatively since no clear measurement method exists that can be applied during the development. Not even exhaustive testing is feasible, as faults in electronics can have an intensity of 10^-9 faults/hour and still pose an unacceptable risk. Hence, it is only when enough field data have been collected from a system used in a particular context that it can be said to be safe enough. Nonetheless, safety must be addressed and assessed during development; restricted to qualitative reasoning about the safety of a product. A structured engineering method is thus needed to approach this problem. One such method is the so called safety case, which came originally from the nuclear industry."/>
      </eAnnotations>
      <eClassifiers xsi:type="ecore:EClass" name="SafetyCase" eSuperTypes="#//infrastructure/elements/TraceableSpecification">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="SafetyCase represents a safety case that communicates a clear, comprehensive and defensible argument that a system is acceptable safe to operate in a given context.&#xA;&#xA;Safety Cases are used in safety related systems, where failures can lead to catastrophic or at least dangerous consequences."/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="safetyCase" ordered="false"
            upperBound="-1" eType="#//dependability/safetycase/SafetyCase" containment="true">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="Attached SafetyCases"/>
          </eAnnotations>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="stage" ordered="false"
            lowerBound="1" eType="#//dependability/safetycase/LifecycleStageKind"/>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="context" ordered="false"
            lowerBound="1" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//String"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="ground" ordered="false"
            lowerBound="1" upperBound="-1" eType="#//dependability/safetycase/Ground"
            containment="true"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="warrant" ordered="false"
            upperBound="-1" eType="#//dependability/safetycase/Warrant"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="claim" ordered="false"
            lowerBound="1" upperBound="-1" eType="#//dependability/safetycase/Claim"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EEnum" name="LifecycleStageKind">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The SafetyCase should be initiated at the earliest possible stage in the safety program so that hazards are identified and dealt with while the opportunities for their exclusion exist. &#xA;&#xA;The LifecycleStageKind is an enumeration metaclass with enumeration literals indicating safety case life cycle stage.&#xA;&#xA;Semantics:&#xA;The safety case is one incremental safety case, rather than several complete new ones. The safety case lifecycle stage has the following meanings:&#xA;&#xA;- The preliminary safety case is started when development of the system is started. After this stage discussions with the customer can commence about possible safety issues (hazards). &#xA;&#xA;- The interim safety case is situated after the first system design and tests.&#xA;&#xA;- The operational safety case is prior to in-service use. &#xA;&#xA;Extension: &#xA;Enumeration, no extension."/>
        </eAnnotations>
        <eLiterals name="PreliminarySafetyCase"/>
        <eLiterals name="InterimSafetyCase" value="1"/>
        <eLiterals name="OperationalSafetyCase" value="2"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="Ground" eSuperTypes="#//infrastructure/elements/TraceableSpecification">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="Claim is based on Grounds (evidences) - specific facts about a precise situation that clarify and make good the Claim. &#xA;&#xA;Ground represents statements that explain how the SafetyCase Ground clarifies and make good the Claim.&#xA;&#xA;Ground has associations to the entities that are the evidences in the SafetyCase.&#xA;&#xA;Semantics:&#xA;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.&#xA;&#xA;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 felt possible.&#xA;&#xA;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."/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="safetyEvidence" ordered="false"
            unique="false" upperBound="-1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//NamedElement">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="Safety evidence in system model."/>
          </eAnnotations>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="justification" ordered="false"
            upperBound="-1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Comment"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="Warrant" eSuperTypes="#//infrastructure/elements/TraceableSpecification">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="Warrant represents argumentation of the facts to the Claim in general ways.&#xA;&#xA;The Warrant entity has associations to the decomposed goals and to the evidences for the SafetyCase.&#xA;&#xA;Semantics:&#xA;The overall objective of an argument is to lead the evidence to the claim.&#xA;&#xA;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.&#xA;&#xA;A goal decomposition strategy breaks down a goal into a number of sub-goals. It is recommended that the strategies are of specific form."/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="decomposedGoal" ordered="false"
            unique="false" upperBound="-1" eType="#//dependability/safetycase/Claim"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="evidence" ordered="false"
            unique="false" upperBound="-1" eType="#//dependability/safetycase/Ground"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="justification" ordered="false"
            upperBound="-1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Comment"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="Claim" eSuperTypes="#//infrastructure/elements/TraceableSpecification">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="Claim represents a statement the truth of which needs to be confirmed.&#xA;&#xA;Claim has associations to the strategy for goal decomposition and to supported arguments. It also holds associations to the evidences for the SafetyCase.&#xA;&#xA;Semantics:&#xA;Goal-based development provides the claim what should be achieved.&#xA;&#xA;Goal is what the argument must show to be true."/>
        </eAnnotations>
        <eAnnotations source="duplicates">
          <contents xsi:type="ecore:EReference" name="goalDecompositionStrategy" ordered="false"
              unique="false" upperBound="-1" eType="#//dependability/safetycase/Warrant">
            <eAnnotations source="redefines" references="#//dependability/safetycase/Claim/goalDecompositionStrategy"/>
          </contents>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="safetyRequirement"
            ordered="false" unique="false" upperBound="-1" eType="#//infrastructure/elements/TraceableSpecification">
          <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
            <details key="documentation" value="Safety requirements and objectives in system model."/>
          </eAnnotations>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EReference" name="supportedArgument"
            ordered="false" unique="false" upperBound="-1" eType="#//dependability/safetycase/Warrant"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="goalDecompositionStrategy"
            ordered="false" unique="false" upperBound="-1" eType="#//dependability/safetycase/Warrant"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="justification" ordered="false"
            upperBound="-1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Comment"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="evidence" ordered="false"
            unique="false" lowerBound="1" upperBound="-1" eType="#//dependability/safetycase/Ground"/>
      </eClassifiers>
    </eSubpackages>
  </eSubpackages>
  <eSubpackages name="annex" nsURI="http://www.papyrusuml.org/EAST-ADL2/Annex/1" nsPrefix="Annex">
    <eClassifiers xsi:type="ecore:EDataType" name="Dummy" instanceClassName="java.lang.String">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="Dummy DataType, just added for code generation purpose.&#xD;&#xA;In other words, this data type for EMF generation of SysmlPackage and SysmlFactory&#xD;&#xA;java classes in the model code.&#xD;&#xA;&#xD;&#xA;Do not remove this !!!"/>
      </eAnnotations>
    </eClassifiers>
    <eSubpackages name="needs" nsURI="http://www.papyrusuml.org/EAST-ADL2/Annex/Needs/1"
        nsPrefix="Needs">
      <eClassifiers xsi:type="ecore:EClass" name="Stakeholder" eSuperTypes="#//infrastructure/elements/TraceableSpecification">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="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]"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="responsibilities" ordered="false"
            unique="false" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//String"/>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="successCriteria" ordered="false"
            unique="false" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//String"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="StakeholderNeed" eSuperTypes="#//infrastructure/elements/TraceableSpecification">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="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."/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="need" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//String">
          <eAnnotations source="redefines" references="#//infrastructure/elements/TraceableSpecification/note"/>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="priority" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//Integer"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="stakeHolder" ordered="false"
            unique="false" lowerBound="1" upperBound="-1" eType="#//annex/needs/Stakeholder"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="problemStatement" ordered="false"
            unique="false" lowerBound="1" upperBound="-1" eType="#//annex/needs/ProblemStatement"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="ProblemStatement" eSuperTypes="#//infrastructure/elements/TraceableSpecification">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="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.&#xA;&#xA;The problem statement could be extended with further modeling of dependencies between different problems and deduction of root problems"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="affects" ordered="false"
            unique="false" upperBound="-1" eType="#//annex/needs/Stakeholder"/>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="impact" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//String"/>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="problem" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//String">
          <eAnnotations source="redefines" references="#//infrastructure/elements/TraceableSpecification/note"/>
        </eStructuralFeatures>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="solutionBenefits" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//String"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="ProductPositioning" eSuperTypes="#//infrastructure/elements/TraceableSpecification">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="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.&#xA;&#xA;Positioning is assumed to belong to a particular context, typically a system, but also for a smaller part of a system."/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="drivingNeeds" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//String"/>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="keyCapabilities" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//String"/>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="primaryCompetitiveAlternative"
            ordered="false" unique="false" lowerBound="1" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//String"/>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="primaryDifferentiation"
            ordered="false" unique="false" lowerBound="1" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//String"/>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="targetCustomers" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//String"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="BusinessOpportunity" eSuperTypes="#//infrastructure/elements/TraceableSpecification">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The business opportunity represents a brief description of the business opportunity being met by developing the EE-System which establishes traceability from artifacts created later, for example to provide rationales to design decisions or trade-off analysis."/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
            unique="false" lowerBound="1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="problemStatement" ordered="false"
            unique="false" upperBound="-1" eType="#//annex/needs/ProblemStatement"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="productPositioning"
            ordered="false" unique="false" upperBound="-1" eType="#//annex/needs/ProductPositioning"/>
        <eStructuralFeatures xsi:type="ecore:EAttribute" name="businessOpportunity"
            ordered="false" unique="false" lowerBound="1" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//String">
          <eAnnotations source="redefines" references="#//infrastructure/elements/TraceableSpecification/note"/>
        </eStructuralFeatures>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="Concept" abstract="true" eSuperTypes="#//infrastructure/elements/EAElement">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="An abstract or general idea inferred or derived from specific instances. [Webster]"/>
        </eAnnotations>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="Mission" eSuperTypes="#//annex/needs/Concept">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="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]"/>
        </eAnnotations>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="VehicleSystem" eSuperTypes="#//annex/needs/Concept">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="A collection of components organized to accomplish a specific function or set of functions. [IEEE 1471]"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="fulfills" ordered="false"
            unique="false" lowerBound="1" upperBound="-1" eType="#//annex/needs/Mission"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="hasAn" ordered="false"
            unique="false" lowerBound="1" eType="#//annex/needs/Architecture"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="has" ordered="false"
            unique="false" lowerBound="1" upperBound="-1" eType="#//annex/needs/Stakeholder"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="Architecture" eSuperTypes="#//annex/needs/Concept">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution. [IEEE 1471]"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="describedBy" ordered="false"
            unique="false" lowerBound="1" eType="#//annex/needs/ArchitecturalDescription"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="ArchitecturalDescription" eSuperTypes="#//annex/needs/Concept">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="A collection of products to document an architecture. [IEEE 1471]"/>
        </eAnnotations>
        <eStructuralFeatures xsi:type="ecore:EReference" name="aggregates" ordered="false"
            lowerBound="1" upperBound="-1" eType="#//annex/needs/ArchitecturalModel"/>
        <eStructuralFeatures xsi:type="ecore:EReference" name="identifies" ordered="false"
            unique="false" lowerBound="1" upperBound="-1" eType="#//annex/needs/Stakeholder"/>
      </eClassifiers>
      <eClassifiers xsi:type="ecore:EClass" name="ArchitecturalModel" eSuperTypes="#//annex/needs/Concept">
        <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
          <details key="documentation" value="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]"/>
        </eAnnotations>
      </eClassifiers>
    </eSubpackages>
  </eSubpackages>
  <eSubpackages name="genericconstraints" nsURI="http://www.papyrusuml.org/EAST-ADL2/GenericConstraints/1"
      nsPrefix="GenericConstraints">
    <eClassifiers xsi:type="ecore:EClass" name="GenericConstraint" eSuperTypes="#//infrastructure/elements/TraceableSpecification">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="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.&#xA;&#xA;Example: If the attribute genericConstraintType is cableLength, the genericConstraintValue could be &quot;5 meters&quot; (value of a numerical datatype with unit &quot;meters&quot;).&#xA;&#xA;Semantics:&#xA;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.&#xA;&#xA;&#xA;&#xA;Extension: Class, Constraint"/>
      </eAnnotations>
      <eStructuralFeatures xsi:type="ecore:EAttribute" name="designConstraintType"
          ordered="false" eType="#//genericconstraints/GenericConstraintKind" defaultValueLiteral=""/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="base_Constraint" ordered="false"
          unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Constraint"/>
      <eStructuralFeatures xsi:type="ecore:EAttribute" name="genericConstraintValue"
          ordered="false" lowerBound="1" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.types/model/Types.ecore#//String"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
          unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="target" ordered="false"
          unique="false" upperBound="-1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//NamedElement"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="mode" ordered="false"
          unique="false" upperBound="-1" eType="#//behavior/Mode"/>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EEnum" name="GenericConstraintKind">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="Enumeration for different type of constraints."/>
      </eAnnotations>
      <eLiterals name="powerConsumption"/>
      <eLiterals name="other" value="1"/>
      <eLiterals name="pieceCost" value="2"/>
      <eLiterals name="weight" value="3"/>
      <eLiterals name="standard" value="4"/>
      <eLiterals name="cableLength" value="5"/>
      <eLiterals name="developmentCost" value="6"/>
      <eLiterals name="functionAllocationDifferentNodes" value="7"/>
      <eLiterals name="functionAllocationSameNode" value="8"/>
      <eLiterals name="powerSupplyIndependent" value="9"/>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EClass" name="GenericConstraintSet" eSuperTypes="#//infrastructure/elements/Context">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="The collection of generic constraints. This collection can be done across the EAST-ADL2 abstraction levels."/>
      </eAnnotations>
      <eStructuralFeatures xsi:type="ecore:EReference" name="genericConstraint" ordered="false"
          upperBound="-1" eType="#//genericconstraints/GenericConstraint"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="base_Package" ordered="false"
          unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Package"/>
      <eStructuralFeatures xsi:type="ecore:EReference" name="base_Class" ordered="false"
          unique="false" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class"/>
    </eClassifiers>
    <eClassifiers xsi:type="ecore:EClass" name="TakeRateConstraint" eSuperTypes="#//genericconstraints/GenericConstraint">
      <eStructuralFeatures xsi:type="ecore:EReference" name="source" ordered="false"
          unique="false" upperBound="-1" eType="ecore:EClass platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//NamedElement"/>
      <eStructuralFeatures xsi:type="ecore:EAttribute" name="takeRate" ordered="false"
          unique="false" lowerBound="1" eType="#//infrastructure/datatypes/javalangFloat"/>
    </eClassifiers>
  </eSubpackages>
</ecore:EPackage>