Due to continuous improvements and due to the addition of new or modification of existing functionality, the information and storage structure of medini analyze projects may be different in different versions of medini analyze. To avoid any problems or information loss, medini analyze supports the automatic migration of projects to a newer major version of the tool. A migration may be required in the following cases:
After installing a new major version of the tool, for projects in the same workspace
When importing projects created with an older version of the tool
Note: Projects of different minor versions are compatible while projects of different major versions are incompatible. The installation of a bugfix release (patch update) does not require a migration. This is true for upgrade and downgrade installations.
Projects which require a migration are indicated in the Model Browser by a decorator with the tool version number next to the project name. Right-clicking the project gives you an abbreviated context menu, with only the options to migrate, delete, or close the project. Choose the entry to start the migration.
A progress bar is shown until the migration is completed. After migration, you can save the migrated project or cancel the complete migration.
The steps that are performed during the migration depend on the original version of the project and the current version of the tool. Relevant issues are reported in the Problems View dialog using markers, so that you can check whether manual steps are required after the automatic migration completes (available from V3.4.x migration onwards).
A general documentation of the migration steps and any special issues are mentioned in the subsequent sections.
Beginning with version 2024 R2, medini analyze supports the migration of shared projects. A project needs migration when the tool version of the project is earlier than the tool version with which you are trying to open it.
As with local projects that need migration, a decorator with the tool version number appears next to the project name in the Server Browser. You cannot load or delete a project that needs migration until it has been migrated.
Only users with editing permissions can migrate projects. To migrate a project, the user's tool version must be later than the version shown in the decorator. In addition, the user's tool version must match the tool version on the server. Note that a local project can have a different version than a shared project with the same name.
After the migration completes, you get a dialog that includes the name of the user who started the migration. You can check for any errors by clicking the button.
If a shared project is migrated by another user while you are working in it, you will not be able to open the project again unless your own tool version matches the new project tool version.
Note: To open a named version of a project (read-only), the tool version of the project version must be 2024 R2 or later. For more information about project versions, see About Project Versions.
Migration from older product versions 1.x and 2.x (released before June 2014) is officially no longer supported. In case you have such projects and need to migrate them please contact the Ansys medini support team for assistance.
During the migration of projects from Version 3.0.x to 3.1.x the following special tasks will be performed:
System Element
Some renaming of properties related to failure rates have been applied in order to have a common naming schema. Raw FIT values are now stored in features having a prefix "raw" in their feature name, other features are now derived. Therefore the following attributes have been changed and the values are copied:
1. Failable.failureRate -> Failable.rawFailureRate
Constraints
The message of constraints #40 is updated.
During the migration of projects from Version 3.1.x to 3.2.x the following special tasks will be performed:
Table State Files
The encoding of all table state files is changed to Unicode.
Constraints
The expression of constraint #29 is updated to handle comparison of different ASIL values correctly, especially having decomposed ASILs.
The migration of projects from Version 3.2.x and 3.3.x to 3.4 is a bigger step, and mainly required due to changes to the FTA metamodel. Note that the automatic migration is only supported for V3.x projects. In case you have older projects (< V3.0) you need to install and migrate to V3.x as an intermediate step before you can do the migration to V3.4. In case you have difficulties please contact our support. For contact details see Support for medini analyze.
During the migration of projects from Version 3.2.x resp 3.3.x to 3.4.x the following special tasks will be performed:
FTA
Each former Event is split into a new Event and an EventNode which refers to the event. Note that trace relationships and all other references to an event including custom references, are kept as is, i.e. they still refer to the event.
Connectors between events are redirected to connect EventNodes instead of Events.
Diagrams are updated to represent EventNodes instead of Events.
Diagrams are updated to support frequency labels.
Diagrams are updated to compensate layout improvements.
The feature FTAModel.topEvent from the model to a single top event is removed and replaced by a derived list property FTAModel.topEvents.
The feature Event.failureRateProvider is renamed to the more general property Event.represents.
Event kinds TOP_LEVEL and INTERMEDIATE are not set anymore but automatically computed.
The prediction model of events has changed and existing projects are migrated as the following:
Depending on the existing data, different probability models are created and set to Event.probabilityData
For fixed probabilities (e.g. probabilityIsDerived is false) no probability model is set and the value of probability is written to rawProbability
If probability is derived and failure rate is derived but no represents is set, a fixed probability of 1.0 is set
If probability is derived and failure rate is derived and represents is any simulink element, Measure, Hazard, Malfunction, FailureMode in a FailureCollection, or Error, a fixed probability of 0.0 is set
If probability is derived and failure rate is derived and represents is a DCSafetyMechanism, a TimeIndependentProbabilityModel is set and probability is calculated as (100-DC)/100
If probability is derived and failure rate is derived and represents is any other type of elements (i.e. system element, failure mode, ...) and missionTimeIsDerived is false, a ScriptedProbabilityModel with expression language is set with
p = 1.0 - exp(-1.0 * (<lambda>/1.0E9) * <missionTime>)for the probability andf = 1.0E-9 * <lambda> * exp(-1.0 * (<lambda>/1.0E9) * <missionTime>)for the frequency, where in both cases <lambda> is replaced by the variable "lambda" and <missionTime> is replaced with the concrete value, note that an event specific mission time is not explicitly supported anymore and scripting needs to be used insteadIf probability is derived and failure rate is derived and represents is any other type of elements (i.e. system element, failure mode, ...) and missionTimeIsDerived is set, an ExponentialProbabilityModel is set
If probability is derived but failure rate is not derived, an ExponentialProbabilityModel is used. In case the missionTimeIsDerived is false, alternatively a ScriptedProbabilityModel is used with a constant lambda value instead of the variable "lambda"
The features probabilityIsDerived is removed and replaced with the probability model
The feature frequencyIsDerived is replaced by lambdaDerived for TimeDependentProbabilityModel (e.g. exponential)
Values for feature frequency are moved to TimeDependentProbabilityModel.rawLambda and default value for lambda is changed from 1.0 to 0.0
The feature missionTimeIsDerived is removed without replacement, scripting can be used
Constraints
Constraint #51 is updated to cover individual metrics.
Constraint #04,#31,#37,#38, and #44 are updated to reflect FTA changes.
New constraints #53-#57 are added to cover individual metrics.
This version upgrade will have an impact on the failure rate computation, since there have been three major changes:
The variable lookup has been simplified. The "Variables for contained elements" is no longer available, since now variables are automatically available to all contained elements. During migration these variables are moved into the remaining "Variables" section of an element. In V4.x the computation will than have the same semantics, with the limitation that a variable value for an element itself and its children can't be different. If this is required, an intermediate element has to be inserted into the model to redefine a certain variable. In case you need assistance, please contact our support.
The scaling expression evaluation was changed to eliminate side effects of the "iterate" statement, which is (therefore) not supported anymore. In V3.x it was possible to redefine a variable and evaluate a function using that variable with the new value. This "rewriting semantics" has been removed in V4.0, which simplifies the expression semantics a lot. For users of the "iterate" statement (e.g. applying a mission profile to SN29500), native features were added. In case you have additional application cases, please contact our support team.
A mission profile can be used in conjunction with the SN29500. That means all parts/types which do not provide an explicit value for the mean average temperature "Teta_U" variable will automatically compute their failure rates based on the mission profile. For indication and further details please see Using Mission Profiles with SN29500, IEC61709, MIL-HDBK-217F, and GJB299C.
Please verify that all settings are still correct for the failure rates after migration. As helper, the migration creates now problem markers in the problem view that point to potential issues during migration (see below).
From V4.x on each project receives a config folder to maintain customizable project settings, e.g. mapping files for DOORS or PTC import, report templates, etc. This folder is created during migration.
Furthermore, the following metamodel changes have been applied:
Variables for contained elements have been removed: IFailureRateData#scopeVariables
Enumeration FailureRateMode has a new literal FROM_PARENT, FROM_CHILDREN has been removed.
The attributes FailureMode#rawFailureRate and FailureMode#rawFailureRateDistribution are removed. The values are accessible via failureRate and failureRateDistribution of FailureMode directly.
Meta-class SafetyMechanismCatalog is replaced by MeasureCatalog, the collectionType determines what kind of measure/mechanism is contained.
SecurityMechanism is added as native meta-class.
The DCCoverage enumeration has been moved to the safety core model (package: safetyModel).
DCSafetyMechanism has been renamed to SafetyMechanism and inherits now from Measure, therefore the id attribute replaces the former key attribute that has been removed.
Description of problem markers:
#01
Problem while creating the config folder in the project. A file entry with the name "config" already exists. Please remove/rename the entry in the old tool version before migration.
#02
Problem while creating the config folder in the project. A folder entry with the name "config" already exists, but did not point to a folder with name "config". Please remove/rename the entry in the old tool version before migration.
#03
Problem while creating the config folder in the project. An according entry already exists, but is not marked as "config" folder entry. Please remove/rename the entry in the old tool version before migration.
#04
Imported DOORS model has no custom mapping (e.g. for ASIL attribute). Default mapping is created and used. This mapping can be adjusted in the config folder (via the Navigator View).
#05
Model exported to Integrity has no custom mapping. Default mapping is used. This mapping can be adjusted in the config folder (via the Navigator View). If you have used an integrity.mapping file in the workspace folder, the installation or configuration folder, or in an external location in V3.x, copy this file into a sub-folder "config/integrity" in the project to resolve this issue.
#06
A scaling expression was used in conjunction with the prediction mode sum of failure modes. This had not clearly defined semantics in V3.x and earlier and therefore this scaling is no longer available for this prediction mode. During migration, the scaling expression is removed. Please check the correctness of settings for the failure rate.
#07
The variable to access the raw failure rate has been changed from lambda to rawFailureRate. In the scaling expression a lambda variable was found, which is renamed. Please adapt the expression accordingly.
#08
The iterate statement for scaling expression is not supported anymore, but the scaling expression uses it. Please adapt the expression accordingly using other aggregations (e.g. sum).
#09
Variables only for contained elements are not supported anymore (see above). The migration gas moved the indicated variable to the general variable section. Please verify that the failure rate is correctly computed with the change.
#10
Variables only for contained elements are not supported anymore (see above). Moving the variable to the variable section lead to a duplication, since the variable is already defined there. Usually it is sufficient to remove the duplicate, if their values are the same. Please check for correct settings.
#11
A custom probability expressions for FTA event contains the iterate statement. This construct is not supported anymore. Please adapt the script accordingly.
During this migration, the default constraints #24 and #40 are updated to correctly ignore the newly introduced transient failure rates.
Furthermore, the following metamodel additions have been applied:
Meta-class Failable has received a new attribute for transientFailureRate of type BigDecimal.
FailureMode has a new attribute failureType of enumeration FailureType { PERMANENT, TRANSIENT } to distinguish between transient and permanent failures.
The migration will change the internal data storage for the ISO 26262 specific attributes (e.g. ASIL) and store them in the newly introduced safety domain profile. For the time being, the corresponding native attributes in the metamodel are maintained so that e.g. the asil at SysML elements can be accessed in the same way as before.
The metamodel changes in detail:
FMEA: the attribute occurrence has been added to the MeasureGroup. The FMEA worksheet entries for occurrence (at CauseEntry) are migration to MeasureEntry.
Moreover, the default constraints #01 (SysML to Simulink port mapping) has been dropped and #42 was adjusted to limit the 0.0 FIT check to HW parts only.
This version introduces the new Ansys versioning schema starting with <Year> followed by an release ID, i.e. R1, R2, R3, and so on. The project migration itself mainly adapt the internal data storage of the ISO 26262 HARA specific attributes and introduce the FHA.
The metamodel changes in detail:
HARA: The following attributes of HazardousEvents are now prefixed with "ISO26262_": location, roadConditions, environment, operationMode, trafficAndPeople, itemUsage, defaultExposureComment, and safetyGoal. Moreover, the isoAsil object reference is gone and all attributes are now directly available at the HazardousEvent: ISO26262_exposure, ISO26262_exposureComment, ISO26262_severity, ISO26262_severityComment, ISO26262_controllability, ISO26262_controllabilityComment, and ISO26262_asil.
FTA: The mission time in FTA is now only globally stored in the project model as a singleton of type EventProbabilityParameters. This class will also be used for the quantitative evaluation. Therefore the field missionTime of FTAModel does no longer exist. Note that different mission times at FTAs will be set to the highest value during migration.
IP Design profile: The IPD-XML import will auto-migrate SysML parts and add a new attribute user_ipd_gateCount during import or update of a model. Note that 2019 R1 supports the IPD-XML specification Version 1.1 (Schema URI: http://www.ikv.de/medini/ipdesign/1.1)
Please refer to the metamodel guide for further details on the metamodel.
In this version, profiling is enabled for Measure Catalogs and Failure Collections but no user data is changed.
The IPD-XML version has been upgraded to V1.2 of the specification, a reimport will auto-migrate SysML parts and add a new attribute user_ipd_gateCell. Note that this IPD-XML version is backward compatible to V1.1 and V1.0. In case you have an older file generated with versions V1.0/1.1 you can patch the schema URI to http://www.ikv.de/medini/ipdesign/1.2 and proceed with the import.
The migration will upgrade the project from R2 (or earlier) to R3 with no change of user data.
The safety core metamodel as well as the profiling mechanisms have been extended in 2020 R1. As consequence, the auto migration will touch almost all data objects if they use profile attributes or reference some of the safety core features. However, the changes should be transparent and older projects will appear as if they were not changed. Nevertheless, please note the following:
Safety core metamodel changes can affect custom validation constraints, scripts, and reports. Check out the Ansys medini analyze Metamodel guide for 2020 R1 and make sure that all is working fine. Since most of the meta-classes have rather new base classes and features have been moved "upwards" to include SOTIF and Cybersecurity, the adaptations should be straightforward.
FMEDA/DC Worksheets now show ports of a block definitions (i.e. types). In case you have derived a FMEDA spreadsheet from a block directly, the ports appear in the analysis and must be either marked as "not safety related" or included properly. Note that during migration there will be a warning coming up if the tool detects such a case.
Some smaller metamodel additions have been applied regarding FMEA and FTA to support the VDA-AIAG which are documented in the metamodel guide. All other changes should be backward compatible with 2020 R1.
This migration is a true version up since some new concepts have been added such as System Weakness Analysis (SWA), Attack Path calculations, as well as a combined Safety+Cybersecurity project. Most of the metamodel changes should be transparent to constraints, however, note the following:
In the project model, there can be multiple packages with the same "Package Tag". This was not allowed before.
New metaclasses have been added:
AttackTree to distiguish clearly between FTA and AttackTrees
AttackPathModel for the analysis of attack paths
AbstractCutSetModel as common base class for FTA and AttackTree analyses
SWAWorksheet as specialization of FMEAWorksheet
New metaclass attributes:
AbstractCutSetModel::cutSetLength (Integer)
The migration is introducing a number of changes that are visible in the metamodel regarding the stepwise migration to SysML v2. Moreover, the metamodel for RBD and DSM are completely added. Regarding migration please note the following:
The "event" parameter in scripted probabilities is deprecated and replaced by "element" (which is the same - and only parameter - for RBDBlock)
Completely new package "pm" for "Project Planning" has been added
Completely new package "rbd" for "Reliability Block Diagrams" has been added (Beta)
Class inheritance changed for several SysML classes (now deriving from SysMLElement):
sysml.SysMLActivityEdge
sysml.SysMLFinalNode
sysml.SysMLForkJoin
sysml.SysMLInitialNode
sysml.SysMLObjectNode
sysml.SysMLPin
sysml.SysML
New meta classes:
FTA.ProbabilityElement (aligned between FTA and RBD)
safetygoals.SecurityGoal (models security goals separately from safety goals)
sysml.SysMLPortDefinition (SysML v2)
sysml.SysMLValueType (SysML v2)
sysml.SysMLValueProperty (SysML v2)
In addition, there will be markers created during migration if your project will be affected by the change in the "sum of causes" calculations in the failure net (see Failure Mode Properties). Since now the conditional probability beta will be considered in failure rate calculations, this might affect projects that had used this factor already (e.g. for FMECA or scripting).
Note: A change in the numerical integration regarding precision in FTA evaluations might lead to changes in numerical results (i.e. precision for all target values, e.g. Q(t), PFD, F(t), etc.). This can lead to a difference in the last digit(s) when comparing the numbers against results from version 2021 R1. See also the changelog for more details.
The metamodel and API changes are along the features released in this version. Note that all validation rules or scripts need to be adjusted if they make use the concepts defined in the following sub-sections.
FTA
The new TRUE/FALSE event model is realized as specialization of meta-class ProbabilityModel:
TrueFalseProbabilityModel::state: EBoolean determines whether the event is set to TRUE or FALSE
Regarding the new Q/T calculations, each Event stores now the values which were used during the computation:
Event:: eventProbabilityParameters : EventProbabilityParameters is the reference to the used calculation parameters
EventProbabilityParameters::probabilityKind : ProbabilityKind stores the computation mode for the event
EventProbabilityParameters::missionTime : EBigDecimal stores the mission time for which the event has been calculated.
The enum ProbabilityKind has the following literals:
PROBABILITY: indicates that the event was computed at the missionTime
UNAVAILABILITY_AVERAGE: indicates that the event was computed considering average probabilties, that means especially using tau/2 as time for MONITORED events (latent)
UNAVAILABILITY_WORST_CASE: indicates that the event was computed considering worst-case probabilties, that means especially using tau as time for MONITORED events (latent)
SafetyCore and FMEA
The connection to the Project Management (package: pm) concepts PMMilestone and PMSubject is realized by additional references in the metamodel. These are introduced in the safety core as well as in FMEA:
MeasureGroup::targetMilestone : PMMilestone references the milestone (if set)
MeasureGroup::derivedTargetDate: EDate provides convenient access to the date that is set explicitly or derived from the the milestone
Measure::targetMilestone : PMMilestone references the milestone (if set)
Measure::derivedTargetDate: EDate provides convenient access to the date that is set explicitly or derived from the the milestone
FMEAWorksheet::teamLead: PMSubject provide the link to team lead (if set)
FMEAWorksheet::derivedTeamLead: EString let's you access the team lead whether it is referenced or a plain string
FMEAWorksheet::teamMembers[0..*] : PMSubject provide the link to team members (if set)
FMEAWorksheet::derivedFmeaTeam : EString gives you the team as string
FMEAWorksheet::revisionMilestone[0..*] : PMMilestone provides a link to the revised milestone (date)
FMEAWorksheet::derivedRevisionDate : EDate provides convenient access to the actual date independent of whether it is derived from a milestone or entered directly in the worksheet
FMEDA
The new meta-class Variant is actually contained in the FMEA (package: fmea) package and the variants are accessible as follows:
FMEAWorksheet::variants[0..*]: Variant contains the variants as seen in the worksheet which have the following attributes:
Variant::name
Variant::identifier
SysML
The EUML base metamodel has been completely removed and replaced by a SysML v2 metamodel as new kernel. Nevertheless, the SysML meta-classes have been mostly kept and evolved. The details of this technical change is in the metamodel guide.
Security Core / Damage Scenarios
The security core metamodel (package: security) has been extended with the new class DamageScenario. DamageScenario inherits from a new meta-class SystemEffect which now bundles all top-level effects for the failure net. The latter is a specialization of the base class for the failure/cause-effect net named CauseEffect.
DamageScenarios are managed in SystemEffectCollections, which is the container collection
SystemEffectCollection::systemEffects[0..*]: SystemEffect stores all damage scenarios.
The metamodel and API changes are mainly for the hybrid failure net and fully backwards compatible.
FTA
The method ProbabilityCutOffMethod has been extended with the literals UNAVAILABILITY_AVERAGE and UNAVAILABILITY_WORST_CASE to distinguish the computation cases for average and worst case Q/T.
SysML
The metaclasses SysMLEnumerationDefinition, SysMLEnumerationUsage, SysMLItemDefinition, and SysMLItemUsage have been added that reflect the corresponding SysML v2 concepts.
SafetyCore and FMEA
For the hybrid failure net, the base class CausalityRelation has a reference to mitigationMeasures : MeasureGroup. In addition, the MeasureGroup metaclass has two new references:
mitigationRelations : CausalityRelation: backward reference to potential mitigated effect relations
mostSevereEffects : CauseEffect: derived reference to get the (list of) those effects that have the highest severity
The metamodel has been extended for Component Fault Trees (CFT) as described in Component Fault Trees (CFT) and the ASIL None option in the ISO 26262 risk graph. These changes are fully backwards compatible. Please refer to the Ansys medini™ analyze Metamodel Documentation for further information.
Another change has been applied in the computations for FTA and RBD. We have improved the precision in the numerical integration for small mission times. Effectivly, the resolution of the time interval between zero and the first integration stepwidth time has been increased. This might lead to slightely different (i.e. numerically more precise) results e.g. for Weibull distributions or repairable events.
The metamodel has not been changed from 2023 R1 to R2. However, there have been changes on the internal data structures, namely the identifier handling and table layout files. These changes will be fully transparent to end users, unless you base e.g. customization scripts on the knowledge about internal UUIDs of the tool. All constraints, validation rules, or scripts using the metamodel and official APIs should work.
The introduction of the collaboration server brought some technical changes that are handled as part of a model migration.
Although these changes should be transparent to an end user, your scripts might be affected if you use unofficial APIs.
The changes are as follows:
All files in the config folder of a project are now part of the project model. If your project has content in the config folder, the file structure is migrated to a folder (PJPackage) and file (PJExternalDocument). This includes XML mapping files for third-party requirement adapters. The third-party requirement adapters themselves are moved into a connector-dependent subpackage. For example, the Jama requirements adapter is moved to config/mappings/Jama/.
Foreign IDs for SysML models imported from EA models and using MSR-XML for FMEA are now stored in annotations to the model elements.
The internal storage of project preferences was changed.
The migration step from 2024 R1 to 2024 R2 completes internal changes to projects for management by a collaboration server.
The changes are:
Foreign IDs for all imported models are now consistently stored in annotations to the model elements. This is true for the MSR-XML import, as well as for Cameo, Rhapsody, EA, and all other importers.
For SysML importers, the model baseline handling was revised. Scripts shall make no assumptions about baseline storage.
The metamodel and API changes are minor and fully backwards compatible.
mapping
The literal Correlation was added to the RelationType enum.
OCLConstraints
The attribute enabled was added to the Constraint class.
FMEA
The attribute showFailureMeasureGroups was added to the FMEAWorksheet class.