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 meta model from ITEA 1.1.0 version to ITEA 1.1.1
-
Changes in the namespaces:
|
AMALTHEA Namespace (version ITEA 1.0.3)
|
AMALTHEA Namespace (verison ITEA 1.1.0)
|
| http://www.amalthea.itea2.org/model/1.1.0/sw |
http://www.amalthea.itea2.org/model/1.2.0/sw |
| http://www.amalthea.itea2.org/model/1.1.0/stimuli |
http://www.amalthea.itea2.org/model/1.2.0/stimuli |
| http://www.amalthea.itea2.org/model/1.1.0/propertyconstraints |
http://www.amalthea.itea2.org/model/1.2.0/propertyconstraints |
| http://www.amalthea.itea2.org/model/1.1.0/os |
http://www.amalthea.itea2.org/model/1.2.0/os |
| http://www.amalthea.itea2.org/model/1.1.0/mapping |
http://www.amalthea.itea2.org/model/1.2.0/mapping |
| http://www.amalthea.itea2.org/model/1.1.0/hw |
http://www.amalthea.itea2.org/model/1.2.0/hw |
| http://www.amalthea.itea2.org/model/1.1.0/events |
http://www.amalthea.itea2.org/model/1.2.0/events |
| http://www.amalthea.itea2.org/model/1.1.0/constraints |
http://www.amalthea.itea2.org/model/1.2.0/constraints |
| http://www.amalthea.itea2.org/model/1.1.0/config |
http://www.amalthea.itea2.org/model/1.2.0/config |
| http://www.amalthea.itea2.org/model/1.1.0/common |
http://www.amalthea.itea2.org/model/1.2.0/common |
| http://www.amalthea.itea2.org/model/1.1.0/central |
http://www.amalthea.itea2.org/model/1.2.0/central |
| http://amalthea.itea2.org/model/1.1.0/components |
http://amalthea.itea2.org/model/1.2.0/components |
-
Following Class names are changed:
|
Class name in 1.0.3
|
Changed Class name in 1.1.0
|
Amalthea sub-model
|
| DeadlineMonotinic |
DeadlineMonotonic |
OS |
-
Below are the references which are removed:
|
Variable Name (version ITEA 1.0.3)
|
Class containing Variable
|
AMALTHEA sub model
|
how migration is done from 1.0.3 models to 1.1.0
|
| scheduler |
OSModel |
OS model |
“scheduler” elements contained inside OSModel element are converted into TaskScheduler elements in the following way: - OperatingSystem element is created and associated to the OSModel element
(Note: OperatingSystem class is newly introduced in 1.1.0)
- All the Scheduler elements present inside the OSModel element are moved to the OperatingSystem element as TaskScheduler’s
- All the places where Scheduler elements were referred earlier, are updated so as to refer corresponding TaskScheduler element
|
| read, write |
LabelAccessStatistic |
Software model |
“read” elements contained inside LabelAccessStatistic element are removed and “write” elements are replaced by tag name “value” based on the following criteria : - If the LabelAccess element containing LabelAccessStatistic ->contains the access as “write”, then all the “read” elements of LabelAccessStatistic are removed
“write” elements contained inside LabelAccessStatistic element are removed and “read” elements are replaced by tag name “value” based on the following criteria : - If the LabelAccess element containing LabelAccessStatistic ->contains the access as “read”, then all the “write” elements of LabelAccessStatistic are removed
|
-
Below are the changes in the reference names :
|
Variable Name (version ITEA 1.0.3)
|
Changed Variable Name (version ITEA 1.1.0)
|
Class containing Variable
|
AMALTHEA sub model
|
how migration is done from 1.0.3 models to 1.1.0
|
| readCacheMisses |
cacheMisses |
LabelAccessStatistic |
Software model |
“readCacheMisses” is changed to “cacheMisses” in all the places where LabelAccessStatistic definition is present |
| executableAllocation |
processAllocation, runnableAllocation |
MappingModel |
Mapping model |
Based on the content of the “executableAllocation”, accordingly either “processAllocation” or “runnableAllocation” elements are created and the corresponding data of “exeuctableAllocation” is mapped. Below are the criterions : - If “executableAllocation” consists of Task element and Scheduler mapping then - > “ProcessAllocation” of type “mapping:TaskAllocation” is created
- If “executableAllocation” consists of ISR element and Scheduler mapping then - > “ProcessAllocation” of type “mapping:ISRAllocation” is created, and to it corresponding ISR element and “InterruptController” element are associated (
Note:If there is a mapping to “ISR” and “Scheduler” in “executableAllocation”, InterruptController element is created and referred in the “executableAllocation”. In this case previous mapping to the Scheduler element is lost)
- If “executableAllocation” consists of Runnable element and Scheduler mapping then - > “RunnableAllocation” of type “mapping:RunnableAllocation” is created
|
Version ITEA 1.1.0 to ITEA 1.1.1
Below are the changes in the meta model from ITEA 1.1.0 version to ITEA 1.1.1
-
Changes in the namespaces:
|
AMALTHEA Namespace (version ITEA 1.1.0)
|
AMALTHEA Namespace (version ITEA 1.1.1)
|
| http://www.amalthea.itea2.org/model/1.2.0/sw |
http://www.amalthea.itea2.org/model/1.3.0/sw |
| http://www.amalthea.itea2.org/model/1.2.0/stimuli |
http://www.amalthea.itea2.org/model/1.3.0/stimuli |
| http://www.amalthea.itea2.org/model/1.2.0/propertyconstraints |
http://www.amalthea.itea2.org/model/1.3.0/propertyconstraints |
| http://www.amalthea.itea2.org/model/1.2.0/os |
http://www.amalthea.itea2.org/model/1.3.0/os |
| http://www.amalthea.itea2.org/model/1.2.0/mapping |
http://www.amalthea.itea2.org/model/1.3.0/mapping |
| http://www.amalthea.itea2.org/model/1.2.0/hw |
http://www.amalthea.itea2.org/model/1.3.0/hw |
| http://www.amalthea.itea2.org/model/1.2.0/events |
http://www.amalthea.itea2.org/model/1.3.0/events |
| http://www.amalthea.itea2.org/model/1.2.0/constraints |
http://www.amalthea.itea2.org/model/1.3.0/constraints |
| http://www.amalthea.itea2.org/model/1.2.0/config |
http://www.amalthea.itea2.org/model/1.3.0/config |
| http://www.amalthea.itea2.org/model/1.2.0/common |
http://www.amalthea.itea2.org/model/1.3.0/common |
| http://www.amalthea.itea2.org/model/1.2.0/central |
http://www.amalthea.itea2.org/model/1.3.0/central |
| http://amalthea.itea2.org/model/1.2.0/components |
http://amalthea.itea2.org/model/1.3.0/components |
-
Below are the changes in the reference names :
|
Variable Name (version ITEA 1.1.0)
|
Changed Variable Name (version ITEA 1.1.1)
|
Class containing Variable
|
AMALTHEA sub model
|
how migration is done from 1.1.0 models to 1.1.1
|
| tagName |
name |
Tag |
Software model, Components model |
attribute “tagName” is changed to “name” in all the places where Tag definition is present |
| elements |
components, systems |
ComponentsModel |
Components model |
- XML child elements of ComponentsModel having name as “elements” and attribute “xsi:type” as either “components:Component” or “components:Composite” are changed to "components"
- XML child elements of ComponentsModel having name as “elements” and attribute “xsi:type” as “components:System” are changed to “systems”
|
| elements |
connectors, componentInstances |
System |
Components model |
- XML child elements of System having name as “elements” and attribute “xsi:type” as “components:Connector” are changed to "components"
- XML child elements of ComponentsModel having name as “elements” and attribute “xsi:type” as “components:ComponentInstance” are changed to “componentInstances”
|
| maximumCyle |
maximumCycle |
DataAgeCycle |
Constraints model |
attribute “maximumCyle” is changed to “maximumCycle” in all the places where DataAgeCycle definition is present |
| setLabelsList |
setModeValueList |
Stimulus |
Stimuli model |
XML node name is set as "setModeValueList" |
| enablingLabelsList |
enablingModeValueList |
Stimulus |
Stimuli model |
XML node name is set as "enablingModeValueList" |
| disablingLabelsList |
disablingModeValueList |
Stimulus |
Stimuli model |
XML node name is set as "disablingModeValueList" |
-
Below are the references which are removed:
|
Variable Name (version ITEA 1.1.0)
|
Class containing Variable
|
AMALTHEA sub model
|
how migration is done from 1.1.0 models to 1.1.1
|
| deadline |
Task, ISR, ProcessPrototype |
Software model |
“deadline” specified at the Process, ProcessPrototype is converted into a constraint element in the following way: - with the name of corresponding Process/ProcessPrototype -> ProcessRequirement object is created and the object of Process/ProcessPrototype is linked to it
- TimeRequirement object is created with the following properties and associated to the created ProcessRequirement:
- limitType as upperlimit
- metric as responsetime
- SignedTime elment is created with the following properties and associated to the TimeRequirement element : value and unit - > values for these elements are fetched from the “deadline” object available at Process/ProcessPrototype
- once the required content from the “deadline” element of Process/ProcessPrototype is fetched, “deadline” is removed
|
| initialValue |
Label |
Software model |
Initial value attribute is removed from all the Label objects |
-
Below are the changes in the default values of Enums :
|
Enum Name
|
Default value (version ITEA 1.1.0)
|
Default value (version ITEA 1.1.1)
|
AMALTHEA sub model
|
Behaviour model migration to migrated 1.1.0 models to 1.1.1
|
| TimeUnit |
ps |
_undefined_ |
Common model |
Attribute “unit” with value as “ps” is created (when it is missing in the input model) -> for all the XMI tags where TimeUnit defintion should be present |
| InterfaceKind |
PROVIDES |
_undefined_ |
Components model |
Attribute “kind” with value as “PROVIDES” is created (when it is missing in the input model) -> for all the XMI tags where InterfaceKind defintion should be present |
| RunnableOrderType |
successor |
_undefined_ |
Constraints model |
Attribute “orderType” with value as “successor” is created (when it is missing in the input model)-> for all the XMI tags where RunnableOrderType defintion should be present |
| RunnableGroupingType |
allOfThem |
_undefined_ |
Constraints model |
Attribute “groupingType” with value as “allOfThem” is created (when it is missing in the input model)-> for all the XMI tags where RunnableGroupingType defintion should be present |
| QType |
DYNAMIC |
_undefined_ |
Hardware model |
Attribute “type” with value as “DYNAMIC” is created (when it is missing in the input model)-> for all the XMI tags where QType defintion should be present |
| MemoryType |
RAM |
_undefined_ |
Hardware model |
Attribute “type” with value as “RAM” is created (when it is missing in the input model)-> for all the XMI tags where MemoryType defintion should be present |
| BusType |
CAN |
_undefined_ |
Hardware model |
Attribute “busType” with value as “CAN” is created (when it is missing in the input model)-> for all the XMI tags where BusType defintion should be present |
| RWType |
R |
_undefined_ |
Hardware model |
Attribute “direction” with value as “R” is created (when it is missing in the input model)-> for all the XMI tags where RWType defintion should be present |
| SchedType |
RROBIN |
_undefined_ |
Hardware model |
Attribute “schedPolicy” with value as “RROBIN” is created (when it is missing in the input model)-> for all the XMI tags where SchedType defintion should be present |
| PinType |
ANALOG |
_undefined_ |
Hardware model |
Attribute “type” with value as “ANALOG” is created (when it is missing in the input model)-> for all the XMI tags where PinType defintion should be present |
| FeatureType |
floatingPointUnit |
_undefined_ |
Hardware model |
Attribute “value” with value as “floatingPointUnit” is created (when it is missing in the input model)-> for all the XMI tags where FeatureType defintion should be present |
| MemoryAddressMappingType |
none |
_undefined_ |
Mapping model |
Attribute “addressMappingType” with value as “none” is created (when it is missing in the input model)-> for all the XMI tags where MemoryAddressMappingType defintion should be present |
| ComparatorType |
equal |
_undefined_ |
Property Constraints model |
Attribute “comparator” with value as “equal” is created (when it is missing in the input model)-> for all the XMI tags where ComparatorType defintion should be present |
| ConjunctionType |
and |
_undefined_ |
Property Constraints model |
Attribute “conjunction” with value as “and” is created (when it is missing in the input model)-> for all the XMI tags where ConjunctionType defintion should be present |
| WaitEventType |
AND |
_undefined_ |
Software model |
Attribute “maskType” with value as “AND” is created (when it is missing in the input model)-> for all the XMI tags where WaitEventType defintion should be present |
| WaitingBehaviour |
unspecified |
_undefined_ |
Software model |
In sw:WaitEvent/ sw:SynchronousServerCall / sw:SynchronousServerCall -> if attribute “waitingBehaviour” is with value as “unspecified”, then attribute “waitingBehaviour” and its value are removed in the XML, so that the default value for “waitingBehaviour” as per 1.1.1 : "_
unspecified _" is consisdered
|
| AccessPrecedenceType |
ignoreWR |
_undefined_ |
Software model |
Attribute “orderType” with value as “ignoreWR” is created (when it is missing in the input model)-> for all the XMI tags where AccessPrecedenceType defintion should be present |
| OrderType |
order |
_undefined_ |
Software model |
Attribute “orderType” with value as “order” is created (when it is missing in the input model)-> for all the XMI tags where OrderType defintion should be present |
| LabelAccessEnum |
read |
_undefined_ |
Software model |
Attribute “access” with value as “read” is created (when it is missing in the input model)-> for all the XMI tags where LabelAccessEnum defintion should be present |
| SemaphoreAccessEnum |
request |
_undefined_ |
Software model |
Attribute “accessEnum” with value as “request” is created (when it is missing in the input model)-> for all the XMI tags where SemaphoreAccessEnum defintion should be present |
| Preemption |
cooperative |
_undefined_ |
Software model |
Attribute “preemption” with value as “cooperative” is created (when it is missing in the input model)-> for all the XMI tags where Preemption defintion should be present |
-
Below are the Class’s/Enum’s moved to different sub models :
|
Enum/Class Name
|
Namespace (version ITEA 1.1.0)
|
Namespace (version ITEA 1.1.1)
|
Behaviour model migration to migrated 1.1.0 models to 1.1.1
|
| SchedulingSWUnit |
sw |
os |
Attribute “xsi:type” of XML node of TaskScheduler/InterruptController is updated to "os:SchedulingSWUnit" |
-
ITEA 1.1.0 Class’s removed in ITEA 1.1.1, details how data of these class’s is migrated :
-
LabelSwitchEntry
(present in Software model)
- Class is removed in ITEA 1.1.1, and as replacement following Class is introduced: "ModeSwitchEntry"
-
LabelSwitch
(present in Software model)
- Class is removed in ITEA 1.1.1, and as replacement following Class’s are introduced: "ModeSwitch, ModeLabel"
-
LabelValueEntry
(present in Stimuli model)
- Class is removed in ITEA 1.1.1, and as replacement following Class is introduced: "ModeValueListEntry"
-
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 meta model 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
|
Class name from 1.1.1
|
Changed Class name in 0.7.0
|
| OSEvent |
OsEvent |
| MemType |
MemoryType |
| System |
HwSystem |
| Component |
HwComponent |
| Port |
HwPort |
| AbstractionTypeDescription |
AbstractionType |
| MemoryType |
MemoryTypeEnum |
| OSInstructions |
OsInstructions |
| Periodic |
PeriodicActivation |
- 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 :
|
Variable Name (version ITEA 1.1.1)
|
Changed Variable Name (version APP4MC 0.7.0)
|
Class containing Variable
|
AMALTHEA sub model
|
| isMaster |
master |
ComplexPort |
Hardware model |
| mem |
memory |
Mapping |
Mapping model |
| memTypeDefinitions |
memoryTypeDefinitions |
PropertyConstraintsModel |
Property Constraints model |
| isDefault |
default |
ModeSwitchEntry |
Software model |
| isBuffered |
buffered |
Label |
Software model |
| isBuffered |
buffered |
LabelAccess |
Software model |
| accessEnum |
access |
SemaphoreAccess |
Software model |
| isBuffered |
buffered |
SenderReceiverCommunication |
Software model |
| isOrdered |
ordered |
Group |
Software model |
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:
|
AMALTHEA Namespace (version App4MC 0.7.0)
|
AMALTHEA Namespace (version App4MC 0.7.1)
|
| http://app4mc.eclipse.org/amalthea/0.7.0 |
http://app4mc.eclipse.org/amalthea/0.7.1 |
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.
Input model (containing SWModel as the root tag):
"<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>"
Output model (after model migration):
<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:
|
Variable Name (version APP4MC 0.7.0)
|
Changed Variable Name (version APP4MC 0.7.1)
|
Class containing Variable
|
AMALTHEA sub model
|
Model Migration behavior
|
| graphEntries |
items |
ModeSwitchEntry |
SW Model |
xml tag “graphEntries” present inside “ModeSwitchEntry” object is changed to “items” in amxmi file |
| value |
values |
ModeSwitchEntry |
SW Model |
xml tag “value” present inside “ModeSwitchEntry” object is changed to “values” in amxmi file |
Below are the changes in the reference Types:
|
Variable Name
|
Variable Type (version APP4MC 0.7.0)
|
Variable Type (version APP4MC 0.7.1)
|
Class containing Variable
|
AMALTHEA sub model
|
Model Migration behavior
|
| size |
Long |
DataSize |
MemoryType |
HW Model, PropertyConstraintsModel |
Attribute “size” is migrated as “DataSize” object. Long value of “size” is migrated to “value” of DataSize. As the DataSizeUnit info is not available, “unit” value is not set |
| size |
DataUnit |
DataSize |
AbstractElementMemoryInformation |
SW Model |
“size” of type “DataUnit” is migrated as “DataSize” object. Int value of “numberBits” attribute is migrated to “value” of DataSize, “unit” attribute is set as “bit” of type DataSizeUnit |
| size |
DataUnit |
DataSize |
BaseTypeDefinition |
SW Model |
“size” of type “DataUnit” is migrated as “DataSize” object. Int value of “numberBit” attribute is migrated to “value” of DataSize, “unit” attribute is set as “bit” of type DataSizeUnit |
| frequency |
EInt |
Frequency |
Quartz |
SW Model |
Attribute “frequency” of type EInt is migrated as “Frequency” object. “frequency” EInt value is migrated to “value” EDouble of DataSize. As the FrequencyUnit info is not available, “unit” value is not set |
Below references are removed:
|
Variable Name
|
Variable Type
|
Class containing Variable
|
AMALTHEA sub model
|
Model Migration behavior
|
| size |
DataUnit |
Section |
SW Model |
Content is removed from the model as size can’t be specified for “Section” (considered as virtual memory section) |
| labels |
[0-*] Label |
Section |
SW Model |
Content is removed from the model. As per APP4MC 0.7.1 semantics, Label object has the association to the Section inside which it can be allocated |
| runEntities |
[0-*] Runnable |
Section |
SW Model |
Content is removed from the model. As per APP4MC 0.7.1 semantics, Runnable object has the association to the Section inside which it can be allocated |
| groupingType |
RunnableGroupingType |
ProcessRunnableGroup |
Constraints Model |
Content is removed from the model |
| entries |
[0-*] ProcessRunnableGroupEntry |
ProcessRunnableGroup |
Constraints Model |
Content is removed from the model. Runnable object belonging to the ProcessRunnableGroupEntry is associated to the runnables list contained at the ProcessRunnableGroup object |
| default |
EBoolean |
ModeSwitchEntry |
SW Model |
Content removed from the model. If several ModeSwitchEntry objects contain attribute “default” as “true”, then first ModeSwitchEntry which has “default” as “true” is converted to “ModeSwitchDefault” object |
Below Classes are removed:
|
Class Name
|
AMALTHEA sub model
|
Model Migration behavior
|
| SchedulerPairingConstraint |
Constraints Model |
Content is removed from the model. There is no equivalent of this model element in APP4MC 0.7.1 |
| SchedulerSeparationConstraint |
Constraints Model |
Content is removed from the model. There is no equivalent of this model element in APP4MC 0.7.1 |
| ProcessRunnableGroupEntry |
Constraints Model |
This element is removed from the model, but the Runnables associated to it are associated to ProcessRunnableGroup object |
| OrderConstraint |
Constraints Model |
Content is removed from the model. There is no equivalent of this model element in APP4MC 0.7.1 |
| AgeConstraint |
Constraints model |
Content is migrated as EventChainLatencyConstraint element with LatencyType as "Age" |
| ReactionConstraint |
Constraints model |
Content is migrated as EventChainLatencyConstraint element with LatencyType as "Reaction" |
| SynchronisationConstraint |
Constraints model |
Content is migrated as EventSynchronizationConstraint element |
| SectionMapping |
Mapping Model |
Content is removed from the model. As per 0.7.1, there is a possibility to specify PhysicalSectionMapping element i.e. defining mapping of various Section elements to Memory |
| SectionMappingConstraint |
Property Constraints Model |
Content is removed from the model.As per 0.7.1, there is a possibility to specify PhysicalSectionConstraint element i.e. defining possibility of Section allocation across various Memories |
| DataUnit |
Sw model |
Content is migrated as DataSize. Attribute “unit” is set as DataSizeUnit of type "bit" |
Version APP4MC 0.7.1 to APP4MC 0.7.2
Change in the namespace:
|
AMALTHEA Namespace (version App4MC 0.7.1)
|
AMALTHEA Namespace (version App4MC 0.7.2)
|
| http://app4mc.eclipse.org/amalthea/0.7.1 |
http://app4mc.eclipse.org/amalthea/0.7.2 |
Below are the changes in the reference names:
|
Variable Name (version APP4MC 0.7.1)
|
Changed Variable Name (version APP4MC 0.7.2)
|
Class containing Variable
|
AMALTHEA sub model
|
Model Migration behavior
|
| runnables |
group |
RunnablePairingConstraint |
Constraints Model |
xml tag “runnables” present inside “RunnablePairingConstraint” object is changed to “group” in amxmi file |
| processes |
group |
ProcessPairingConstraint |
Constraints Model |
xml tag “processes” present inside “ProcessPairingConstraint” object is changed to “group” in amxmi file |
| labels |
group |
DataPairingConstraint |
Constraints Model |
xml tag “labels” present inside “DataPairingConstraint” object is changed to “group” in amxmi file |
| initalValue |
initialValue |
Semaphore |
OS Model |
xml attribute “initalValue” present inside “Semaphore” object is changed to “initialValue” in amxmi file |
| arrivalCurveEntries |
entries |
ArrivalCurve |
Stimuli Model |
xml tag “arrivalCurveEntries” present inside “ArrivalCurve” object is changed to “entries” in amxmi file |
Below are the changes in the reference Types:
|
Variable Name
|
Variable Type (version APP4MC 0.7.1)
|
Variable Type (version APP4MC 0.7.2)
|
Class containing Variable
|
AMALTHEA sub model
|
Model Migration behavior
|
| instructions |
OsExecutionInstructions |
Instructions |
SchedulingSWUnit |
OS Model |
type of the instructions tag in amxmi is updated either to InstructionsConstant or InstructionsDeviation based on if the type in input is : OsExecutionInstructionsConstant or OsExecutionInstructionsDeviation |
| apiSendMessage |
OsExecutionInstructions |
Instructions |
OsAPIInstructions |
OS Model |
type of the apiSendMessage tag in amxmi is updated either to InstructionsConstant or InstructionsDeviation based on if the type in input is : OsExecutionInstructionsConstant or OsExecutionInstructionsDeviation |
| apiTerminateTask |
OsExecutionInstructions |
Instructions |
OsAPIInstructions |
OS Model |
type of the apiTerminateTask tag in amxmi is updated either to InstructionsConstant or InstructionsDeviation based on if the type in input is : OsExecutionInstructionsConstant or OsExecutionInstructionsDeviation |
| apiSchedule |
OsExecutionInstructions |
Instructions |
OsAPIInstructions |
OS Model |
type of the apiSchedule tag in amxmi is updated either to InstructionsConstant or InstructionsDeviation based on if the type in input is : OsExecutionInstructionsConstant or OsExecutionInstructionsDeviation |
| apiRequestResource |
OsExecutionInstructions |
Instructions |
OsAPIInstructions |
OS Model |
type of the apiRequestResource tag in amxmi is updated either to InstructionsConstant or InstructionsDeviation based on if the type in input is : OsExecutionInstructionsConstant or OsExecutionInstructionsDeviation |
| apiReleaseResource |
OsExecutionInstructions |
Instructions |
OsAPIInstructions |
OS Model |
type of the apiReleaseResource tag in amxmi is updated either to InstructionsConstant or InstructionsDeviation based on if the type in input is : OsExecutionInstructionsConstant or OsExecutionInstructionsDeviation |
| apiSetEvent |
OsExecutionInstructions |
Instructions |
OsAPIInstructions |
OS Model |
type of the apiSetEvent tag in amxmi is updated either to InstructionsConstant or InstructionsDeviation based on if the type in input is : OsExecutionInstructionsConstant or OsExecutionInstructionsDeviation |
| apiWaitEvent |
OsExecutionInstructions |
Instructions |
OsAPIInstructions |
OS Model |
type of the apiWaitEvent tag in amxmi is updated either to InstructionsConstant or InstructionsDeviation based on if the type in input is : OsExecutionInstructionsConstant or OsExecutionInstructionsDeviation |
| apiClearEvent |
OsExecutionInstructions |
Instructions |
OsAPIInstructions |
OS Model |
type of the apiClearEvent tag in amxmi is updated either to InstructionsConstant or InstructionsDeviation based on if the type in input is : OsExecutionInstructionsConstant or OsExecutionInstructionsDeviation |
| apiActivateTask |
OsExecutionInstructions |
Instructions |
OsAPIInstructions |
OS Model |
type of the apiActivateTask tag in amxmi is updated either to InstructionsConstant or InstructionsDeviation based on if the type in input is : OsExecutionInstructionsConstant or OsExecutionInstructionsDeviation |
| apiEnforcedMigration |
OsExecutionInstructions |
Instructions |
OsAPIInstructions |
OS Model |
type of the apiEnforcedMigration tag in amxmi is updated either to InstructionsConstant or InstructionsDeviation based on if the type in input is : OsExecutionInstructionsConstant or OsExecutionInstructionsDeviation |
Below are the changes in the relation of elements:
|
Variable Name
|
Variable Type
|
Variable Relation (version APP4MC 0.7.1)
|
Variable Relation (version APP4MC 0.7.2)
|
Class containing Variable
|
AMALTHEA sub model
|
Model Migration behavior
|
| memory |
Memory |
containment |
association |
HwMemoryProperty |
PropertyConstraints model |
memory objects containment is changed as association relation. As a result definition of Memory object should not be present inside HwMemoryProperty, rather only reference of memory should be present inside HwMemoryProperty. Model migration is performed in the following way for this change : Memory elements definition from HwMemoryProperty tag are moved to HW Model (Note: addition of Memory (from PropertyConstraints model) to HW model happens only if Memory with this name is not existing in the model scope) |
| core |
Core |
containment |
association |
HwCoreProperty |
PropertyConstraints model |
core objects containment is changed as association relation. As a result definition of Core object should not be present inside HWCoreProperty, rather only reference of core should be present inside HWCoreProperty. Model migration is performed in the following way for this change : Core elements definition from HwCoreProperty tag are moved to HW Model (Note: addition of Memory (from PropertyConstraints model) to HW model happens only if Memory with this name is not existing in the model scope) |
Below are the changes in Enum elements:
|
Enum Name
|
Enum Literal (version APP4MC 0.7.1)
|
Enum Literal (version APP4MC 0.7.2)
|
AMALTHEA sub model
|
Model Migration behavior
|
| Preemption |
unknown |
- |
SW Model |
unknown literal is removed from Preemption. Model Migration will replace “unknown” literal with the default literal |
Below references are removed:
|
Variable Name (version APP4MC 0.7.1)
|
Variable Type
|
Class containing Variable
|
AMALTHEA sub model
|
Model Migration behavior
|
| samplingType |
SamplingType |
Deviation |
Hardware Model Stimuli MOdel OS Model Software Model |
In 0.7.2, samplingType attribute is shifted from Deviation to Boundaries element.As a part of Model migration -> samplingType content is removed from Deviation and associated to the corresponding Distribution of type Boundaries. If Boundaries element is not present inside Deviation as a distribution, corresponding samplingType data is skipped during model migration |
| coreTypeDefinitions |
CoreType |
PropertyConstraintsModel |
Property Constraints Model |
coreTypeDefinitions objects are removed from the PropertyConstraintsModel tag and are associated to HW Model (Note: addition of CoreType to HW model happens only if CoreType with this name is not existing in the model scope. If there exists CoreType element with the same name in “PropertyConstraintsModel” and in “HW Model” --> the one from PropertyConstraintsModel will be removed and the one from HW Model will be referred accordingly inside Core element etc.,) |
| memoryTypeDefinitions |
MemoryType |
PropertyConstraintsModel |
Property Constraints Model |
memoryTypeDefinitions objects are removed from the PropertyConstraintsModel tag and are associated to HW Model (Note: addition of MemoryType to HW model happens only if MemoryType with this name is not existing in the model scope . If there exists MemoryType element with the same name in “PropertyConstraintsModel” and in “HW Model” --> the one from PropertyConstraintsModel will be removed and the one from HW Model will be referred accordingly inside MemoryElement element etc.,) |
| tags |
Tag |
ComponentsModel, HWModel, SWModel |
Components Model, Hardware Model, Software Model |
Tag objects are removed from the ComponentsModel,HWModel,SWModel tags and their content is shifted to CommonElements Model (Note: CommonElements model is contained inside Amalthea root node) |
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)
|
|
Version APP4MC 0.7.2 to APP4MC 0.8.0
Change in the namespace:
|
AMALTHEA Namespace (version App4MC 0.7.2)
|
AMALTHEA Namespace (version App4MC 0.8.0)
|
| http://app4mc.eclipse.org/amalthea/0.7.2 |
http://app4mc.eclipse.org/amalthea/0.8.0 |
Below references are removed from storage format (amxmi):
|
Variable Name (version APP4MC 0.7.2)
|
Variable Type
|
Class containing Variable
|
AMALTHEA sub model
|
Model Migration behavior
|
| mode |
Mode |
ModeValueProvider |
SW Model |
mode is made as a derived variable and transient property is set to it, as a result it will not be serialized into the model file. Based on the selection of ModeLiteral (in ModeValueProvider element) mode element will be considered accordingly. |
| osDataConsistency |
OsDataConsistency |
OSModel |
OS Model |
OsDataConsistency element is shifted from OSModel to OperatingSystem element. As a part of migration, osDataConsistency element content is copied inside each OperatingSystem element |
Below references names are changed :
|
Variable Name (version APP4MC 0.7.2)
|
Variable Name (version APP4MC 0.8.0)
|
Variable Type
|
Class containing Variable
|
AMALTHEA sub model
|
Model Migration behavior
|
| mapping |
memoryMapping |
Mapping (in 0.7.2) -> MemoryMapping (in 0.8.0) |
MappingModel |
Mapping model |
As there is a change in the reference name (from mapping to memoryMapping) in metamodel --> corresponding XML tag names in amxmi are changed from mapping to memoryMapping, type attribute is removed from memoryMapping XML tag as MemoryMapping is a concrete class |
Below Classes/Interfaces are removed:
|
Class Name (version APP4MC 0.7.2)
|
AMALTHEA sub model
|
Model Migration behavior
|
| ModeValueProvider (Interface) |
SW Model |
Content present inside ModeValueProvider class is moved to ModeLabel. Reference to Mode element is made as derived variable, and it automatically populated based on the selection of ModeLiteral. |
| SignedTimeObject |
SW Model |
Equivalent of this element is TimeObject in APP4MC 0.8.0. There is no change in the storage format. |
| SignedTime |
SW Model |
Equivalent of this element is Time in APP4MC 0.8.0. There is no change in the storage format. |
| Mapping |
Mapping Model |
This interface is removed from the model. MemoryMapping is equivalent of this model element in APP4MC 0.8.0. As a part of model migration type attribute is removed from the tag which is defining MemoryMapping. |
| AbstractElementMapping |
Mapping Model |
MemoryMapping is equivalent of this model element in APP4MC 0.8.0. As a part of model migration type attribute is removed from the tag which is defining MemoryMapping. |
| AbstractElementMemoryInformation |
HW Model |
AbstractMemoryElement is the equivalent of this model element in APP4MC 0.8.0. There is no change in the storage format. |
| ProbabiltitySwitch |
HW Model |
ProbabiltitySwitch class is changed to ProbabilitySwitch (typo corrected in the class name). ProbabilitySwitch is the equivalent of this model element in APP4MC 0.8.0 |
| AllocationConstraint |
PropertyConstraints Model |
AllocationConstraint class is changed to CoreAllocationConstraint. In CoreAllocationConstraint -> reference to HwCoreConstraint element is removed, based on this change -> during model migration CustomProperty is created with key as “hwConstraint (element removed during Migration of Model to 0.8.0 version)” and value as the XML content of “hwConstraint” element. |
| MappingConstraint |
PropertyConstraints Model |
MappingConstraint class is changed to MemoryMappingConstraint. In MemoryMappingConstraint -> reference to HwMemmoryConstraint element is removed, based on this change -> during model migration CustomProperty is created with key as “hwConstraint (element removed during Migration of Model to 0.8.0 version)” and value as the XML content of “hwConstraint” element. |
| HwCoreConstraint, HwCoreConjunction, HwCoreProperty |
PropertyConstraints Model |
These elements are removed from the model. As a reference XML content is stored as a CustomProperty inside CoreAllocationConstraint |
| HwMemoryConstraint, HwMemoryConjunction, HwMemoryProperty |
PropertyConstraints Model |
These elements are removed from the model. As a reference XML content is stored as a CustomProperty inside MemoryMappingConstraint |
Below are the changes in the datatype of elements:
|
Variable Name
|
Variable datatype (version APP4MC 0.7.2)
|
Variable datatype (version APP4MC 0.8.0)
|
Class containing Variable
|
AMALTHEA sub model
|
Model Migration behavior
|
| instructionsPerCycle |
int |
float |
CoreType |
HW model |
int is converted to float |
Version APP4MC 0.8.0 to APP4MC 0.8.1
Change in the namespace:
|
AMALTHEA Namespace (version App4MC 0.8.0)
|
AMALTHEA Namespace (version App4MC 0.8.1)
|
| http://app4mc.eclipse.org/amalthea/0.8.0 |
http://app4mc.eclipse.org/amalthea/0.8.1 |
Below Classes/Interfaces behaviour is changed:
|
Class Name (version APP4MC 0.8.0)
|
AMALTHEA sub model
|
Changes in behavior (as per 0.8.1)
|
Model Migration behavior
|
| SubEventChain |
Constraints Model |
SubEventChain class (in 0.8.0) is replaced by EventChainContainer class (in 0.8.1). EventChainContainer class is modelled to contain SubEventChain elements (in 0.8.1) which are non referrable child EventChain elements. |
- In amxmi file, xsi:type with “am:SubEventChain” is replaced with “am:EventChainContainer”.
- If sub EventChain elements are referred inside EventChainReference or inside TimingConstraints
(e.g: EventChainLatencyConstraint or EventChainSynchronizationConstraint):
- Then corresponding reference is removed and the reference String is stored in a CustomProperty of the corresponding element
|
| Quartz |
Hardware Model |
Quartz is not extending ComplexNode class. In addition below are the other changes w.r.t. Quartz: - It is no longer possible to have nested Quartz elements
- All Quartz elements should be present in single list, which is part of HwSystem class
|
- Per each amxmi file, from HWModel all Quartz elements are collected (
both root and sub Quartz elements) and are added in a central list which is part of HwSystem.
- Quartz element definitions are removed from the other HW elements
(which are sub-classes of ComplexNode)
|
| ModeValueListEntry |
Stimuli model |
ModeValueListEntry class is having two sub-classes ModeValue and ModeValueConjunction |
ModeValue type is associated to all the ModeValueListEntry elements |
Below Classes are removed:
|
Class Name (version APP4MC 0.8.0)
|
AMALTHEA sub model
|
Model Migration behavior
|
| CoreAllocation |
Mapping Model |
CoreAllocation is replaced by SchedulerAllocation. As a part of model migration, In Mapping model references of CoreAllocation are changed as SchedulerAllocation. Also the “core” attribute/tag of it is renamed to "responsibility" |
| SchedulingHWUnit |
OS model |
SchedulingHWUnit reference is removed from Scheduler |
| SchedulingSWUnit |
OS model |
SchedulingSWUnit reference is removed from Scheduler and content of Instructions is copied to the corresponding ComputationItem elements of type RunnableInstructions |
| ArrivalCurve |
Stimuli model |
This class is renamed to ArrivalCurveStimulus. Element type is updated at both defintion and references in amxmi file |
| InterProcess |
Stimuli model |
This class is renamed to InterProcessStimulus. Element type is updated at both defintion and references in amxmi file |
| Periodic |
Stimuli model |
This class is renamed to PeriodicStimulus. Element type is updated at both defintion and references in amxmi file |
| PeriodicEvent |
Stimuli model |
This class is renamed to VariableRateStimulus. Element type is updated at both defintion and references in amxmi file |
| Single |
Stimuli model |
This class is renamed to SingleStimulus. Element type is updated at both defintion and references in amxmi file |
| Sporadic |
Stimuli model |
This class is renamed to SporadicStimulus. Element type is updated at both defintion and references in amxmi file |
| Synthetic |
Stimuli model |
This class is renamed to SyntheticStimulus. Element type is updated at both defintion and references in amxmi file |
| InterProcessActivation |
SW model |
This class is renamed to InterProcessTrigger. Element type is updated at both defintion and references in amxmi file |
Below references are removed/changed:
|
Variable Name
|
Variable Type
|
Class containing Variable
|
AMALTHEA sub model
|
Model Migration behavior
|
| coreAllocation |
CoreAllocation |
MappingModel |
Mapping Model |
coreAllocation tag name is renamed to schedulerAllocation. Equivalent of CoreAllocation is SchedulerAllocation element |
| priority |
integer |
TaskAllocation |
Mapping Model |
priority attribute is removed from TaskAllocation and its corresponding value is copied to priority attribute of the SchedulingParameters |
| xAccessPattern |
String |
MemoryType |
HW model |
xAccessPattern attribute and its value present in MemoryType element are removed from the amxmi file |
| parameter |
AlgorithmParameter |
Scheduler |
OS model |
parameter tag name is changed to parameterExtensions (
Also changed variable Type here is : ParameterExtensions)
|
| scheduleUnitPriority |
integer |
Scheduler |
OS model |
scheduleUnitPriority attribute is removed |
| delay |
Time |
SchedulingHWUnit |
OS model |
delay tag is removed |
| instructions |
Instructions |
SchedulingSWUnit |
OS model |
“instructions” tag is removed from the SchedulingSWUnit and each “instructions” tag content is copied as a “default” tag of computationItems (of type RunnableInstructions) |
| schedulingUnit |
SchedulingUnit |
Scheduler |
OS model |
schedulingUnit tag is removed. And the contents of SchedulingSWUnit are migrated to ComputationItem’s |
| trigger |
TriggerEvent |
EventStimulus |
Event model |
renamed to triggeringEvents |
| activation |
Activation |
Runnable |
SW model |
renamed to activations |
| deadline |
Time |
PeriodicActivation |
SW model |
deadline attribute is removed |
| trigger |
TriggerEvent |
EventActivation |
SW model |
renamed to triggeringEvents |
| priority |
integer |
Process |
SW model |
priority attribute is removed |
| osekTaskGroup |
integer |
Task |
SW model |
osekTaskGroup attribute is removed |
| quartzes |
List of Quartz |
Core
ECU
HwComponent
Memory
Microcontroller
Network |
Hardware Model |
All Quartz elements from these model elements are moved to HwSystem element.
Note:If there are nested Quartz elements, they are flattened and stored inside a single list |
Version APP4MC 0.8.1 to APP4MC 0.8.2
Change in the namespace:
|
AMALTHEA Namespace (version App4MC 0.8.1)
|
AMALTHEA Namespace (version App4MC 0.8.2)
|
| http://app4mc.eclipse.org/amalthea/0.8.1 |
http://app4mc.eclipse.org/amalthea/0.8.2 |
Version APP4MC 0.8.2 to APP4MC 0.8.3
Change in the namespace:
|
AMALTHEA Namespace (version App4MC 0.8.2)
|
AMALTHEA Namespace (version App4MC 0.8.3)
|
| http://app4mc.eclipse.org/amalthea/0.8.2 |
http://app4mc.eclipse.org/amalthea/0.8.3 |
Below Classes/Interfaces behaviour is changed:
|
Class Name (version APP4MC 0.8.2)
|
AMALTHEA sub model
|
Changes in behavior (as per 0.8.3)
|
Model Migration behavior
|
| ModeSwitch, RunnableModelSwitch |
SW Model |
valueProvider (
of ModeLabel reference) is removed and is associated to ModeValue element.
|
valueProvider (
of ModeLabel reference) is removed and is associated to ModeValue element, which is created inside ModeValueDisjunction element contained in ModeSwitch, RunnableModeSwitch
|
| ModeSwitchEntry |
SW Model |
values (
of type list of ModeLiteral) is removed and is as ModeValue element inside ModeValueDisjunction class.
|
values (
of type list of ModeLiteral) is removed and each element in the list is associated as ModeValue element, which is created inside ModeValueDisjunction element contained in ModeSwitch, RunnableModeSwitch
|
| PeriodicStimulus |
Stimuli Model |
stimulusDevaiation, offset, clock elements are removed |
For migration, below points are to be considered:- If
clock value is set for PeriodicStimuls, then this PeriodicStimulus will be migrated as VariableRateStimulus.
- clock, recurrence elements are moved from PeriodicStimulus to Scenario element, contained inside VariableRateStimulus.
- offset element vlaue is moved as a customProperty for Scenario element
- If
clock value is not set for PeriodicStimuls, then type of the element will not be changed.
- stimulsDeviation element is renamed as jitter.
|
Below Classes are removed:
|
Class Name (version APP4MC 0.8.2)
|
AMALTHEA sub model
|
Model Migration behavior
|
| FInterfacePort |
Components Model |
FinterfacePort is replaced by InterfacePort class. As a part of model migration, in Components model -> type attribute for the definition of FInterfacePort is changed from “am:FInterfacePort” to “am:InterfacePort”, and new type (InterfacePort) is also updated for references of FInterfacePort |
| SyntheticStimulus |
Stimuli Model |
SyntheticStimulus is replaced by PeriodicSyntheticStimulus class. As a part of model migration, in Stimuli model -> type attribute for the definition of FInterfacePort is changed from “am:SyntheticStimulus” to “am:PeriodicSyntheticStimulus”, and new type (PeriodicSyntheticStimulus) is also updated for references of SyntheticStimulus |
| SporadicStimulus |
Stimuli Model |
SporadicStimulus is replaced by RelativePeriodicStimulus class. As a part of model migration, in Stimuli model -> type attribute for the definition of SporadicStimulus is changed from “am:SporadicStimulus” to “am:RelativePeriodicStimulus”, and new type (RelativePeriodicStimulus) is also updated for references of SporadicStimulus |
Below references are removed/changed:
|
Variable Name
|
Variable Type
|
Class containing Variable
|
AMALTHEA sub model
|
Model Migration behavior
|
| activationDeviation |
Deviation |
VariableRateActivation |
SW Model |
activationDeviation element is removed from the VariableRateActivation element |
| valueProvider |
ModeLabel |
ModeSwitch, RunnableModeSwitch |
SW Model |
valueProvider (
ModeLabel reference) is removed directly from
ModeSwitch, RunnableModelSwitch
elements and associated to each ModeValue element ->> which is created inside condition element (
of type ModeValueDisJunction)
|
| values |
ModeLiteral |
ModeSwitch, RunnableModeSwitch |
SW Model |
values list is removed directly from
ModeSwitch, RunnableModelSwitch
and associated inside condition element (
of type ModeValueDisJunction) as different ModeValue elements (
Note: Each element in values List is created a seperate ModeValue element inside condition element)
|
| period |
Time |
SyntheticStimulus |
Stimuli Model |
period element is changed to recurrence |
| triggerTimes |
TimeStampList |
SyntheticStimulus |
Stimuli Model |
triggerTimes element is removed from SyntheticStimulus. Content of TriggerTimes element ->
timeStamps list is migrated as occurrenceTimes element inside SyntheticStimulus
|
| stimulusDeviation |
Deviation |
SporadicStimulus |
Stimuli Model |
stimulusDeviation element is changed as nextOccurrence |
| numberOfEvents |
Integer |
ArrivalCurveEntry |
Stimuli Model |
numberOfEvents element is changed as numberOfOccurrences |
| stimulusDeviation |
Deviation |
ArrivalCurveStimulus, SingleStimulus, CustomStimulus, InterProcessStimulus, EventStimulus, SyntheticStimulus |
Stimuli Model |
stimulusDeviation element is removed from SingleStimulus |
| activation |
Time |
SingleStimulus |
Stimuli Model |
activation element is changed as occurrence |
| stimulusDeviation |
Deviation |
PeriodicStimulus |
Stimuli Model |
If clock value is
not set for PeriodicStimulus, in this case stimulusDeviation element is changed as jitter.
|
| recurrence, clock |
Time |
PeriodicStimulus |
Stimuli Model |
If clock value is
set for PeriodicStimulus, in this case both recurrence and clock are removed directly from PeriodicStimulus and their values are added inside Scenario element -> contained inside PeriodicStimulus(
which will be migrated to VariableRateStimulus as a part of migration)
|
| offset |
Time |
PeriodicStimulus |
Stimuli Model |
If clock value is
set for PeriodicStimulus, in this case offset element is removed directly from PeriodicStimulus and its value is added inside Scenario element -> contained inside PeriodicStimulus(
which will be migrated to VariableRateStimulus as a part of migration) as a CustomProperty with name "offset"
|
| stimulusDeviation |
Deviation |
PeriodicStimulus |
Stimuli Model |
If clock value is
set then stimulusDeviation element is removed from PeriodicStimulus
|
Version APP4MC 0.8.3 to APP4MC 0.9.0
Change in the namespace:
|
AMALTHEA Namespace (version App4MC 0.8.3)
|
AMALTHEA Namespace (version App4MC 0.9.0)
|
| http://app4mc.eclipse.org/amalthea/0.8.3 |
http://app4mc.eclipse.org/amalthea/0.9.0 |
Below Classes/Interfaces behaviour is changed:
|
Class Name (version APP4MC 0.8.3)
|
AMALTHEA sub model
|
Changes in behavior (as per 0.9.0)
|
Model Migration behavior
|
| Memory |
HWModel |
Memory and Cache are two different elements. Memory can be defined only inside a HwStructure where as Cache can be defined inside HwStructure and ProcessingUnit |
Memory element of 0.8.3 is converted either as a Memory elemnt or Cache element based on the type specified for MemoryType element. If the type is specified as
CACHE, then Memory object
_ is converted as
Cache element and in other cases it is converted as
Memory.
Note: _In 0.8.3, Memory element could be contained inside a ComplexNode, as a part of migration : If there is not a possibiity to define either a Cache or Memory inside a specific element then it is added as a part of the corresponding parent HwStructure element
|
| HwPort |
HWModel |
HwPort and ComplexPort elements from 0.8.3 are represented as HwPort in 0.9.0. |
For both HwPort and ComplexPort elements, HwPort object is created. Based on the value of attribute master on HwPort or ComplexPort : portType is set either as initiator
_ or responder _(if master=false)
|
Below Classes are removed:
|
Class Name (version APP4MC 0.8.3)
|
AMALTHEA sub model
|
Model Migration behavior
|
| RunnableInstructions |
SWModel, OSModel |
Equivalent element of this class in 0.9.0 is ExecutionNeed.
default InstructionsConstant,InstructionsDeviation are converted as NeedEntry and the key refers to HwFeatureCategory "Instructions"
|
| RunnableInstructionsEntry |
SWModel, OSModel |
Equivalent element of this class in 0.9.0 is ExecutionNeedExtended. Key attribute of ExecutionNeedExtended refer to
ProcessingUnitDefintion
|
| ECUType |
HWModel |
There is no equivalent element in 0.9.0 |
| MicroControllerType |
HWModel |
There is no equivalent element in 0.9.0 |
| SystemType |
HWModel |
There is no equivalent element in 0.9.0 |
| HWAccessPath |
HWModel |
There is no equivalent element in 0.9.0. Only LatencyAccessPath is migrated |
| HWComponent |
HWModel |
There is no equivalent element in 0.9.0 |
| NestedComponent |
HWModel |
There is no equivalent element in 0.9.0 |
| PreScaler |
HWModel |
There is no equivalent element in 0.9.0. Based on to which HW element PreScaler is added ,Quartz of the corresponding element is fetched : value of
clockRatio is multiplied with the Frequency value of the Quartz and a new FrequencyDomain object is created which contains the obtained Frequency value. Created FrequencyDomain will contain clockratio value in suffix of the name
|
| Quartz |
HWModel |
Equivalent element of this class in 0.9.0 is FrequencyDomain. |
| Pin |
HWModel |
There is no equivalent element in 0.9.0 |
| MemoryType |
HWModel |
Equivalent element of this class in 0.9.0 is MemoryDefinition. If type is specified as
Cache, then corresponding element is migrated as
CacheDefinition, in other cases it will be MemoryDefinition
|
| CoreType |
HWModel |
Equivalent element of this class in 0.9.0 is ProcessingUnitDefinition. |
| NetworkType, Bus, Bridge, CrossbarSwitch |
HWModel |
Equivalent element of these classes in 0.9.0 is ConnectionHandlerDefinition. |
| LatencyAccessPath |
HWModel |
Equivalent element of this class in 0.9.0 is HwAccessElement. If the source element of the LatencyAccessPath is Core, in the corresponding ProcessingUnit : HwAccessElement is created and the destination of it is set based on the destination of LatencyAccessPath
(Note: Destination of HwAccessElement can only be Memory or ProcessingUnit)
|
| System |
HWModel |
Equivalent element of this class in 0.9.0 is HwStructure. StructureType is set as System |
| ECU |
HWModel |
Equivalent element of this class in 0.9.0 is HwStructure. StructureType is set as ECU |
| MicroController |
HWModel |
Equivalent element of this class in 0.9.0 is HwStructure. StructureType is set as Microcontroller |
| Core |
HWModel |
Equivalent element of this class in 0.9.0 is ProcessingUnit |
| Network |
HWModel |
Equivalent element of this class in 0.9.0 is ConnectionHandler |
| ComplexPort |
HWModel |
There is no equivalent element in 0.9.0 |
Below references are removed/changed:
|
Variable Name(version APP4MC 0.8.3)
|
Variable Type
|
Class containing Variable
|
AMALTHEA sub model
|
Model Migration behavior
|
| memories |
Memory |
TargetMemory |
ConstraintsModel |
If the Memory object as per 0.8.3 is still Memory in 0.9.0, then reference is unchanged. If Memory in 0.8.3 is migrated as Cache based on the type of MemoryType
(as CACHE in 0.8.3) , corresponding reference is removed
|
| memories |
Memory |
PhysicalSectionConstraint |
ConstraintsModel |
If the Memory object as per 0.8.3 is still Memory in 0.9.0, then reference is unchanged. If Memory in 0.8.3 is migrated as Cache based on the type of MemoryType
(as CACHE in 0.8.3) , corresponding reference is removed
|
| memory |
Memory |
PhysicalSectionMapping |
MappingModel |
If the Memory object as per 0.8.3 is still Memory in 0.9.0, then reference is unchanged. If Memory in 0.8.3 is migrated as Cache based on the type of MemoryType
(as CACHE in 0.8.3) , corresponding reference is removed
|
| memory |
Memory |
MemoryMapping |
MappingModel |
If the Memory object as per 0.8.3 is still Memory in 0.9.0, then reference is unchanged. If Memory in 0.8.3 is migrated as Cache based on the type of MemoryType
(as CACHE in 0.8.3) , corresponding reference is removed
|
| cores |
Core |
TargetCore |
ConstraintsModel |
instead of Core object, variable Type is updated to corresponding ProcessingUnit element |
| hardwareContext |
ComplexNode |
CPUPercentageRequirementLimit |
ConstraintModel |
variable Type is changed to ProcessingUnit. In 0.8.3 models if an element was referring to any other ComplexNode other than Core, corresponding reference will be removed |
| core |
Core |
ProcessEvent |
EventModel |
variable name is changed from core to processingUnit.Type of the reference is changed to ProcessingUnit |
| core |
Core |
ProcessChainEvent |
EventModel |
variable name is changed from core to processingUnit.Type of the reference is changed to ProcessingUnit |
| core |
Core |
RunnableEvent |
EventModel |
variable name is changed from core to processingUnit.Type of the reference is changed to ProcessingUnit |
| core |
Core |
SemaphoreEvent |
EventModel |
variable name is changed from core to processingUnit.Type of the reference is changed to ProcessingUnit |
| cores |
Core |
MicroController |
HWModel |
variable name is changed from cores to modules.Type of the reference is changed to ProcessingUnit. MicroController class is changed to HwStructure |
| responsibility |
Core |
SchdulerAllocation |
MappingModel |
Type is changed from Core to ProcessingUnit |
| executingCore |
Core |
SchdulerAllocation |
MappingModel |
variable name is changed from executingCore to executingPU. Type is changed from Core to ProcessingUnit |
| coreAffinity |
Core |
TaskAllocation |
MappingModel |
variable name is changed from coreAffinity to affinity. Type is changed from Core to ProcessingUnit |
| items, runnableItems, computationItems |
RunnableInstructions |
Group, Runnable, Scheduler |
SWModel, OSModel |
Type is changed from RunnableInstructions to ExecutionNeed |