Hello everyone!
We often need to cross-check model consistency, especially between SysML Parts and their associated Failures. This is crucial when importing data (e.g., from technical architecture or BOM) and you have one or multiple existing architecture (e.g., preliminary or functional) already available in medini.
While traceability and stringent naming conventions are vital, they are not always guaranteed across these modeling approaches. Therefore, implementing specific OCL or validation rules is essential for our customers to control these quality standards.
Today, we're sharing a concise, powerful OCL rule example to enforce this coherence.
A common internal rule is: If a SysMLPart traces to a Failure, the Failure's name must contain the full Part's name. This ensures immediate traceability and strict nomenclature.
OCL Rule Example:
inv NameMatchingForTracedFailures:
self.mediniGetTracedElements(safetyModel::FailureMode)->forAll(tracedElement | tracedElement.oclAsType(safetyModel::FailureMode).name.toLower().indexOf(self.name.toLower()) <> -1)
Aspect | Technical Detail | Implication |
Custom Function | mediniGetTracedElements(...) | medini-specific navigation method, filtering the traced elements to only include FailureMode objects f |
Case Insensitivity | .toLower() on both names | The search is not case sensitive, ensuring the rule passes regardless of capitalization (e.g., checks if "PART_A" is in "Failure of part_a"). |
Search Logic | .indexOf(...) <> -1 | The rule verifies that the Part's name is contained within the FailureMode's name. It passes if the substring is found (index is not “-1”). |
OCL Iterator | ->forAll(...) | The entire rule fails （returns False） if any single traced FailureMode violates the specified naming condition – please note: the JS code below employs a more refined logic, which handles additional exceptions, particularly when multiple traces are encountered |
Explicit Casting | .oclAsType(...) | Ensures safe access to the .name attribute by explicitly treating the generic tracedElement as a specific FailureMode object. |
This example demonstrates how OCL rules provide a rapid, non-intrusive way for customers to validate modeling correctness against specific internal process rules.
This could be key for:
- Quality Assurance: Enforcing naming standards and clean traceability from preliminary architecture models.
- Safety Analysis: Ensuring the architecture-to-failure linkage is correct from the start.
- Supplier Collaboration: Establishing clear, verifiable modeling standards between Tier-X and suppliers.
Beyond OCL: JS and Graphical Representation
While OCL is excellent for formal validation, a visual representation is often preferred.
A similar check can be implemented using JavaScript Derived Property for SysMLPart.
This property can display True/False and other possible results in case of multiple traceability between SysML elements and failures modes. A dedicated Table View (to be derived from the System Model under analysis) could provide instant, graphical validation status for every SysMLPart.
If you have any questions about implementing this or other OCL rules or derived JS properties, please don't hesitate to leave a comment below or contact us directly.
Happy Scripting!
Michele
