AMALTHEA meta model changes

Based on the changes in AMALTHEA meta model across various releases, below description contains the differences in detail which are considered for model migration:

Version ITEA 1.0.3 to ITEA 1.1.0

Below are the changes in the metamodel from ITEA 1.1.0 version to ITEA 1.1.1

• Changes in the namespaces:

• Following Class names are changed:

• Below are the references which are removed:

• Below are the changes in the reference names :

Version ITEA 1.1.0 to ITEA 1.1.1

Below are the changes in the metamodel from ITEA 1.1.0 version to ITEA 1.1.1

• Changes in the namespaces:

• Below are the changes in the reference names :

• Below are the references which are removed:

• Below are the changes in the default values of Enums :

• Below are the Class’s/Enum’s moved to different sub models :

• ITEA 1.1.0 Class’s removed in ITEA 1.1.1, details how data of these class’s is migrated :

• Model migration behavior:
  • LabelSwitch :
    • From the referred “Label” element inside “LabelSwitch”, “ModeLabel” element is created with the same name -> and associated to the same Software Model where “Label” element is defined
    • “LabelSwitch” element is replaced with “ModeSwitch” element, and it refers to the “ModelLabel” (created in the above step)
  • LabelSwitchEntry :
    • For all the LabelSwitchEntry objects inside a specific AMALTHEA model file, a single “Mode” element is created ( with the following naming convention : “mode_sw_<counter>_migration_generated” )
    • Based on the unique values of LabelSwitchEntry elements, ModeLiteral objects are created
    • LabelSwitchEntry is replaced by ModeSwitchEntry, based on the earlier “value” specified for LabelSwitchEntry -> corresponding ModeLiteral element is referred
    • For details refer to the below figure:
      
      
      
      
  • LabelValueEntry :
    • For Label referred inside each LabelValueEntry, corresponding ModeLabel object is created in the software model and it is associated to the entry object.
    • For all the LabelValueEntry objects inside a specific AMALTHEA model file, a single “Mode” element is created ( with the following naming convention : “mode_stimuli_<counter>_migration_generated” )
    • Based on the unique values of LabelValueEntry elements, ModeLiteral objects are created
    • LabelValueEntry is replaced by ModeValueListEntry, based on the “value” specified for LabelValueEntry -> corresponding ModeLiteral element is referred instead of “value”

    • !! For LabelValueEntry migration to be successful, it is mandatory to have SW-Model in the same model file. In case SW-Model is not present, migration of LabelValueEntry objects will not be performed.

    • For details refer to the below figure:
      
      
      
      

Version ITEA 1.1.1 to App4MC 0.7.0

Below are the changes in the metamodel from ITEA 1.1.1 version to APP4MC 0.7.0

• Instead of multiple namespaces (e.g: sw,hw,constraints,components etc.,) a single namespace “am” is introduced
  • Impact on 0.7.0 model file due to this change:
    • xmlns:am="http://app4mc.eclipse.org/amalthea/0.7.0 is included in the xmi file, instead of other namespaces (e.g: xmlns:hw, xmlns:sw etc.,)
    • xsi:type attributes will consists of namespace prefix as “am” in the value. Example:
      <ports xsi:type="am:ComplexPort" name="Mem_1_port" bitWidth="16" direction="R" writeCycles="10" readCycles="10"/>
    • Root tag will have “am” as the prefix. Example:
      <am:HWModel xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:am="http://app4mc.eclipse.org/amalthea/0.7.0"/>
• Reference pattern is changed.
  As there is single model namespace in 0.7.0, namespace prefix is removed before the class name (eg: “ABSMode?type=Label”).
  • old: <Element Name>?type=<NameSpace prefix>.<ElementClassName>
  • new: <Element Name>?type=<ElementClassName>
• Root tag of the model, changed from AMALTHEA to Amalthea
• IPort interface is changed to abstract class Port
• FInterface reference (i.e. Franca Interface) is removed from class FInterfacePort
  • Impact on 0.7.0 model file due to this change:
    • If AMALTHEA models from previous versions have the reference to Franca Interface ports, as a part of migration this reference is removed. ( In this case, reference to the Franca Interface element is stored as a CustomProperty of type String inside FInterfacePort element)
• InterfaceKind ENUM literal values are changed from PROVIDES, REQUIRES to provides, requires
• Following class names are changed
  
  

• Below references are removed inside ComplexNode and HardwareTypeDescription ( both these class’s are part of Hardware Model)
  • AbstractType[] attribute , AbstractType[] features
    • Impact on 0.7.0 model file due to this change: Content inside the attribute and features is stored as a CustomProperty elements inside the corresponding elements.
      • Content of “AbstractType[] attribute” is stored in the CustomProperty, with key as “attribute#<attribute name>” and value as <attribute value>
      • Content of “AbstractType[] features” is stored in the CustomProperty, with key as “feature#<feature name>” and value as <feature value>
    • Below figure shows the changes between 1.1.1 model ( containing attributes & features) and the corresponding 0.7.0 model ( created using model migration utility)
• ProcessAllocation class removed from MappingModel, instead ISRAllocation ( maps ISR and InterruptController) and TaskAllocation ( maps Task and Scheduler)
  • Impact on 0.7.0 model file due to this change:
    • processAllocation tag is removed from mappingModel, and instead of this taskAllocation and isrAllocation tags will be generated accordingly.
      For details refer to the image
      
• Below are the changes in the reference names :

Version APP4MC 0.7.0 to App4MC 0.7.1

Below are the changes in the meta model from APP4MC 0.7.0 to APP4MC 0.7.1

Change in the namespace:

Root Tag in AMALTHEA model amxmi file: It is recommended to have “Amalthea” as a root tag in amxmi file.

Based on the above statement, if the AMALTHEA model file is having sub-model tag as root element (e.g: SWModel or HWModel etc.,), as a part of model migration -> root element is changed as “Amalthea” tag and the content of sub-model is copied inside it.

 "<am:SWModel xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:am="http://app4mc.eclipse.org/amalthea/0.7.0">
  <labels/>
</am:SWModel>"

<am:Amalthea xmlns:am="http://app4mc.eclipse.org/amalthea/0.7.0" xmlns:xmi="http://www.omg.org/XMI">
  <swModel>
    <labels />
  </swModel>
</am:Amalthea> 

Below are the changes in the reference names:

Below are the changes in the reference Types:

Below references are removed:

Below Classes are removed:

Version APP4MC 0.7.1 to APP4MC 0.7.2

Change in the namespace:

Below are the changes in the reference names:

Below are the changes in the reference Types:

Below are the changes in the relation of elements:

Below are the changes in Enum elements:

Below references are removed:

Below Classes are removed:

Class Name (version APP4MC 0.7.1)	AMALTHEA sub model	Model Migration behavior
TargetProcess	Constraints Model	Content is removed from the model. There is no equivalent of this model element in APP4MC 0.7.2
TargetCallSequence	Constraints Model	Content is removed from the model. There is no equivalent of this model element in APP4MC 0.7.2
OsExecutionInstructions, OsExecutionInstructionsDeviation, OsExecutionInstructionsConstant	OS Model	Replacement elements are : Instructions,InstructionsDeviation,InstructionsConstant. As there is no change in the content of these elements(when compared to previous elements) -> during model migration corresponding old type names are replaced with the new model elements
ProbabilityGroup	SW Model	ProbabilityGroup is replaced with RunnableProbabilitySwitch
ProbabilityRunnableItem	SW Model	ProbabilityRunnableItem is replaced wtih ProbabilitySwitchEntry
DeviationRunnableItem	SW Model	Content of DeviationRunnableItem i.e RunnableItem is moved directly inside the Group as a part of “items” list
EventConfigElement, EventConfigLink	Config Model	Both EventConfigElement and EventConfigLink objects are converted as EventConfig objects (As EventConfigElement & EventConfigLink classes are removed from the MetaModel – as per the semantics equivalent class for both of them is EventConfig). In case of migrating EventConfigElement – If definition of EntityEvent element is present as a sub-element -> it is moved to Events Model and the corresponding reference to EntityEvent is established inside EventConfig using attribute "event"
OsBuffering	OS Model	OsBuffering elements are migrated as OsDataConsistency elements. Below steps describe the criteria considered for migration of data :
LabelBufferring	SW Model	LabelBufferring elements are migrated as DataStability elements. Below steps describe the criteria considered for migration of data : - If LabelBuffering value is “buffered” then the corresponding value of “dataStability” is set as "CustomProtection" - If LabelBuffering value is “notBuffered” then the corresponding value of “dataStability” is set as “noProtection” - If LabelBuffering value is " undefined" (default) then the corresponding value of “dataStability” is set as " undefined" (default)
LabelAccessBufferring	SW Model	LabelAccessBufferring elements are migrated as DataStability elements. Below steps describe the criteria considered for migration of data : - If LabelAccessBufferring value is “inherited” then the corresponding value of “dataStability” is set as "inherited" - If LabelAccessBufferring value is “buffered” then the corresponding value of “dataStability” is set as “customProtection” - If LabelAccessBufferring value is “notBuffered” then the corresponding value of “dataStability” is set as “noProtection” - If LabelAccessBufferring value is " undefined" (default) then the corresponding value of “dataStability” is set as " undefined" (default)