Source-linked AI summary
Ontology-based Requirements Transformation
Jan Novacek, Alexander Viehl, Oliver Bringmann, Wolfgang Rosenstiel
TL;DR
The paper addresses inefficient transformation of Mission Profile requirements across supply chains and fragmented engineering data. It proposes an ontology-based system using OWL, models, and reasoning to support MBSE-integrated transformations, knowledge reuse, and removal of irrelevant information, while SWRL and in-memory construction impose limitations.
Problem
Complex-system requirements are scattered across poorly managed documents and must be efficiently transformed as they are refined into subsequent tier needs.
Method
The paper proposes an ontology-based transformation system that integrates heterogeneous data into models and uses OWL, SWRL, and reasoning to support Mission Profile transformations within MBSE methods.
Results
The approach supports supply-chain-aware transformation of Mission Profiles while enabling integration with existing MBSE methods, knowledge sharing and reuse, and removal of unnecessary information.
Takeaways & Limitations
The system is intended to improve engineering-process efficiency, reduce communication overhead and transformation errors, and better protect intellectual property.
Takeaways & Limitations
SWRL transformations cannot modify or remove existing ontology information, and in-memory ontology construction is problematic for very large Mission Profiles.
Abstract
from arXiv · showhide
This paper presents an ontology-based approach to the supply chain-aware transformation of functional and environmental load requirements given by so-called Mission Profiles (MPs). The approach aims at improving the efficiency of the engineering process through supporting the transformation process and enabling a better integration of the transformation into existing Model-based Systems Engineering (MBSE) processes. We propose a methodology and a supporting system which aids in the transformation process while the latter feature is obtained by constructing and working on models. Consequent utilization of the standardized language OWL to express model representations further enables better knowledge integration and transfer among hetero-geneous systems. In addition to that, this favors knowledge reuse across projects which can reduce overall costs. Moreover, the system enables stripping off irrelevant information from MPs, thus improving protection of intellectual property.
I. INTRODUCTION
The paper addresses inefficient, fragmented Mission Profile transformation across complex-system supply chains by using ontology-based models and standardized semantic languages. The approach supports MBSE integration while enabling knowledge reuse, reduced communication overhead, error avoidance, and protection of intellectual property.
- Motivation: Mission Profiles are transformed as requirements are refined and broken down for successive supply-chain tiers.The approach supports selecting, parameterizing, and applying transformations to MP data.
- Approach: OWL and SWRL represent models and transformations, supporting knowledge sharing, reuse, and integration with existing MBSE methods.The ontology-based design also follows Linked Data principles for interlinking and discovering data sources.
- Motivation: Non-standardized MP representations and scattered systems-engineering data make automatic transformation and relevant-data integration challenging.MPs may be shared through Excel sheets or Word documents, requiring custom solutions for each representation.
- Approach: The proposed system integrates heterogeneous data sources into models and supports MP transformation through those constructed models.Its workflow specifies tier needs, identifies parameters to maintain, creates executable operations, maps the base MP to an ontology, and executes the transformation.
- Benefits: The stated benefits include lower costs, better intellectual-property protection, less communication overhead, transformation reuse across projects, and fewer transformation errors.Removing unnecessary MP information supports IP protection, while reducing transformations lowers communication overhead.
A. Mission Profiles
Mission Profiles capture functional and environmental loads for system development, but their manual and varied handling motivates tool support. The paper frames supply-chain awareness, extensibility, and multiple transformation approaches as requirements for MP transformation.
- Mission Profiles: Mission Profiles capture environmental conditions and functional loads that components experience throughout their life cycles.They are assembled from load and environmental profiles, requirements, and stress-test scenarios.
- Mission Profiles: Mission Profile consideration remains mainly manual, motivating software support for automation and adoption.The related work identifies only limited existing software support for Mission Profile Aware Design.
- Transformation approaches: The approach supports multiple Model-to-Model transformation categories rather than being limited to one category.The paper distinguishes relational/declarative, imperative/operational, graph-based, and hybrid approaches.
- Supply chain consideration: MP transformation tools should account for supply-chain tiers because different tiers require different portions of the original MP data.Parameters needed for failure-model application at technology-provider level may need to be preserved at preceding tiers.
- Extensibility: General environmental-load specification requires versatile descriptions and extensible mechanisms for discovering and processing previously unknown loads.This extensibility must apply both to load-specification mechanisms and to processing-tool functionality.
3) Varying level of detail:
The transformation system is designed to accommodate mission profiles with varying detail levels through scalable, customizable processing and explicit evaluation criteria. Its ontology-based workflow specifies tier needs, identifies maintained parameters, generates executable operations, maps MPFO documents to MPOs, and executes transformations.
- Varying level of detail: MP transformation tools should process different detail levels equally well and support customizable manipulation operations.The requirements arise because mission-profile detail varies across inputs.
- Key requirements: The abstract requirements include parameter maintenance, versatile and extensible processing, and customizable manipulation operations.These requirements were extracted as the basis for evaluating the proposed system.
- Evaluation criteria: Specific evaluation criteria define parameter maintenance, multiple transformation classes, extensibility, modifiability, and equal handling of detail levels.The criteria make fulfillment of the abstract requirements more precise and evaluable.
- Approach overview: The approach is organized as an overview, solution concept, framework design, and architecture description for ontology-based mission-profile transformation.These components structure the proposed solution.
- Approach overview: The workflow specifies tier needs, identifies parameters to maintain from failure models, produces executable operations, maps MPFO documents to MPOs, and executes the ontology-based transformation.The numbered process combines manual specifications, ontology mapping, and transformation execution.
B. Solution concept
The solution concept uses OWL as a unifying language for integrating models and knowledge, with mechanisms for supply-chain parameter maintenance, transformation diversity, extensibility, modifiability, and detail handling.
- Unifying representation: OWL is used continuously as the unifying language for models to reduce the effort of integrating data, information, and knowledge.The stated purpose is to support mission-profile transformation and its implementation.
- Model lifting: Existing models are lifted into OWL by translating source models into OWL expressions and enriching them with relevant knowledge.The enrichment supports achievement of the transformation task.
- Supply-chain awareness: Supply-chain awareness is implemented by marking parameters required by lower-tier failure models for maintenance during transformation.The mechanism uses an ontology-based repository of failure models.
- Transformation approaches: The system supports both direct-manipulation and relational model-to-model transformation approaches.The two approaches belong to different transformation classes under the adopted classification.
- Extensibility and modifiability: A plug-in mechanism allows new transformation approaches to be added through predefined interfaces, while specifications and parameters support behavioral modifiability and reuse.The concrete plug-in design depends on the implementation technology.
- Performance boundary: Handling different mission-profile detail levels relies on established libraries, while users must consider performance when defining concrete transformations.Transformation definitions directly affect performance.
C. Framework design
The framework maps mission-profile documents into OWL ontologies and provides platform services for processing, interlinking, integration, reasoning, and interaction. Its ontology model represents failure models and transformations, while OWL axioms and SWRL rules identify parameters requiring maintenance across supply-chain tiers.
- Framework design: MPFO documents are mapped into corresponding OWL ontologies serialized in RDF/XML by existing Semantic Mission Profile Aware Design Platform tooling.The mapping engine takes MPFO document format as input.
- Framework design: The platform processes, interlinks, and integrates mission profiles and requirements, with OWL output enabling reasoning mechanisms.Document inputs are lifted to ontologies by mapping engines.
- Framework design: A RESTful API and browser-based GUI support interaction from standard-conforming browsers and integration into existing design environments.The GUI is implemented with HTML and JavaScript.
- Failure model and transformation ontology: The parameter-maintenance ontology uses OWL axioms and SWRL rules to infer which mission-profile parameters must be maintained through transformation.The inference addresses supply-chain requirements associated with failure models.
- Failure model and transformation ontology: A technological failure model is modeled as a specialization of the failure-model concept within the transformation ontology.The ontology represents failure models and transformations as classes connected through axioms.
- Failure model and transformation ontology: The ontology models transformations as classes and applies supply-chain rules analogously across tiers when failure-model parameters must be maintained.The rules mark parameters on transformation instances associated with supply-chain levels.
- Failure model and transformation ontology: The failure-model taxonomy includes CMOS device models for electromigration, hot-carrier injection, time-dependent dielectric breakdown, and bias temperature instability.These models are added as instances of corresponding ontology classes.
2) System:
The system models mission-profile transformations through reusable transformation traits, mappings, rules, and model providers. Its UML-oriented design supports multiple mapping cardinalities and user-defined transformation behavior.
- 2) System:: MPOTransformation organizes transformations around source and target data together with a list of mappings.The system represents these elements through transformation traits and associated data structures.
- 2) System:: OneToOneMapping supports one-to-one mappings while the mapping design also accommodates one-to-many, many-to-one, and many-to-many transformations.This flexibility is required for creating the transformation relationships used by the system.
- 2) System:: DirectManipulationMPOTransformation accesses a model manipulation API, whereas RuleBasedMPOTransformation associates rules with specific mappings.Rule-based transformations store mapping-to-rule associations, while direct manipulation relies on a model provider.
- 2) System:: Implementing classes can define transformation behavior by overriding the apply method of transformation traits.This satisfies the system's modification criterion through specialization of transformation traits.
V. USE CASES
The use-case section presents two industrial applications: technology failure-model parameter maintenance and derivation of sub-component mission profiles.
- V. USE CASES: The use cases address application of technology failure models using the parameter-maintenance mechanism.This demonstrates how required mission-profile parameters are retained for downstream failure-model use.
- V. USE CASES: The use cases also address deriving sub-component mission profiles from higher-level mission-profile information.Both applications are described through concrete examples.
- V. USE CASES: Both use cases are presented as typical industrial applications of the proposed transformation technology.The section uses concrete examples to illustrate the applications.
A. Technology failure model application
The technology failure-model use case identifies which mission-profile parameters must be retained at a specified supply-chain tier before applying a failure-model transformation.
- A. Technology failure model application: The example mission profile contains seven parameters and eight temperature intervals ranging from -10 °C to 90 °C.The parameters are t0, t1, t2, v0, v1, v2, and failureRate.
- A. Technology failure model application: An ontology and failure-model repository determine which parameters require maintenance for the selected supply-chain tier.The example repository contains five FEOL and BEOL failure models with associated technology, product, and mission-profile parameters.
- A. Technology failure model application: The transformation implementation loads a source ontology, creates a target ontology, preserves its format, and applies ontology changes before saving the result.The Scala template uses OWLAPI operations and source and target paths to execute the transformation.
// TRANSFORMATION OPERATIONS
The transformation operation applies ontology changes to produce a saved target ontology from a source ontology. The reported output preserves object and data property assertions while discarding selected mission-profile information.
- // TRANSFORMATION OPERATIONS: The OWLAPI transformation applies axiom removals and additions before saving the target ontology.The operation sequence explicitly applies both change sets and then persists the transformed ontology.
- // TRANSFORMATION OPERATIONS: The Scala source code is provided as a template for implementing OWLAPI-based transformations.The template defines source and target ontology handling and transformation operations.
- // TRANSFORMATION OPERATIONS: Object and data property assertions are preserved even though some axioms are removed from the transformed ontology.The removed axioms correspond to intentionally discarded operating-state and port-specification information.
B. Sub-component MP derivation
The use case derives a Mission Profile for an IC sub-component from an ECU profile by applying ontology-supported transformations that preserve failure-model parameters. Temperature relationships, supply-chain information, and expert-specified operations guide the transformation while irrelevant data can be removed.
- Base Mission Profile: The ECU temperature profile is represented as a histogram of 12 ranges spanning -40 °C to 125 °C.The profile describes the inner-air temperature of the ECU, referring to the EEM Internal measurement point.
- Temperature transformation: Given ambient temperature TA, device power dissipation P, and junction-to-ambient resistance θJA, equation 7 calculates junction temperature TJ.Equations 7 and 8 then calculate a corresponding Tier-3 temperature profile from the ECU Mission Profile.
- Use case: The use case derives an IC sub-component Mission Profile from a base ECU Mission Profile across a three-tier supply chain.A Tier-1 assembles the ECU, a Tier-2 supplies the IC, and a Tier-3 supplies the underlying technology.
- Transformation outcomes: Expert-defined load relationships determine transformation operations, while unneeded parameters can be stripped to protect intellectual property and reduce storage.Reusable transformation specifications can save time and avoid errors when profiles are required for multiple ECU sub-components.
- Transformation workflow: Users specify the transformation tier and operations, while ontologies, failure models, and reasoning identify parameters that must be maintained.The system maps the ECU Mission Profile into OWL before executing the transformation.
VI. CONCLUSION
The proposed system supports supply-chain-aware Mission Profile transformation and integrates multiple transformation approaches through an extensible design. Its current limitations include monotonic SWRL inference and in-memory ontology construction for very large profiles.
- Conclusion: The system supports Mission Profile transformation with consideration of supply-chain structure, high-level failure models, and technology failure models.
- Conclusion: Its extensible design integrates multiple transformation approaches, an identified requirement for Mission Profile transformation systems.
- Limitations: SWRL-based transformations can add facts but cannot modify or remove existing ontology information because SWRL provides monotonic inference only.Pre- and post-processing steps could handle fact modification or removal.
- Limitations: In-memory ontology construction is problematic for very large Mission Profiles, although such profiles are described as infrequent in practice.
- Future work: Potential improvements include reuse and verification of model-to-model transformations, pattern-based transformation, and direct failure-model evaluation using SWRL Built-In extensions.
- Design choice: The authors chose ontologies and standardized languages over EMF, ETL, and ATL to keep the system design simple and reduce complexity.They report this as a viable way to realize a Mission Profile transformation system.