Engineering Change Impact Traceability Pattern - OSLC/lifecycle-integration-patterns GitHub Wiki

PatternID: 100.003

Name: Engineering Change Impact Traceability Pattern

Category: Business Scenario

Creation Date: April 15, 2018

Creators: Mark Schulte, Tony O’Hare

Description:

Engineering data for MBSE exists in multiple sources. A single repository for the data is not desired but Systems Engineering needs to be able to track the impact of change across the digital thread. Manually synchronizing data and maintaining traceability is traditionally a very expensive process, often being ineffectively managed via spreadsheets or requiring development and maintenance of custom interfacing tools. A better integration solution is desired. Also, note that traceability across all of the assets is not simply between individual artifacts, but between artifact versions from various configurations. So links need to be managed within a complete set of product data as a single product line configuration.

We need to be able to assess related data artifacts in a timely manner and see the latest information up to date when assessing change impact AND we want to leave the data in its originally authored tool in order to not create confusion as to where the “truth” for any particular piece of data lies.

Stakeholders who are versed in one discipline but need to view related pieces of data, e.g. an architecture diagram from a requirement, should not have to develop expertise in the target application (e.g. Rhapsody or NoMagic) in order to get some basic and useful information.

A secondary challenge will be in how to simplify the authorization and licensing required across all of the distributed applications in order to streamline the user process while not increasing cost.

Stakeholder Roles:

  • Customers
  • Project Managers
  • Systems Engineers
  • Electrical Engineers
  • Safety Engineers
  • Software Engineers
  • Operations Analysis
  • Reliability and Maintainability

Systems of Record:

  • Requirements Database (all levels from customer requirements to system requirements to software requirements, etc.)
  • Systems and software design models
  • Fault Trees, fault hazards
  • Electrical wiring connections and electrical design components

Key Artifacts:

  • Requirements and functional hazards are captured in DOORS/DNG.
  • Requirements are linked to activities in the architecture model (OSLC direct connection today)
  • Hazards are linked to activities in the architecture model (OSLC)
  • Hazards are linked to fault trees in Isograph (reliability tool) (via SDM OSLC capability)
  • Electrical components linked to logical design blocks or an electrical schematic could be linked to an IBD.
  • Component requirements in DOORS to component design in Capital

Integration Solution:

General variants of this could apply to various Programs depending on the needs.

Alternate Solutions & Discussion:

Use OSLC where possible for direct integration between tools where OSLC is supported on both ends of the toolchain. Supplement with use of simple hyperlinks between tools to connect tool artifacts possibly with custom interfaces. All options at the moment center on keeping the source data in the original authoring tools. Not currently considering single tool or federated data or copy/sync options.

Point-to-point access to related data artifacts across disparate repositories offers immediate benefits not previously available without OSLC. However, a holistic integration approach is desirable with the capability to report across all products, view all relationships, and analyze the data programatically, e.g. change impacts. Furthermore, there is a need to manage the configuration of a system as a whole, including managing links appropriately not just between two artifacts, but between the correct version/variant of those artifacts. To achieve this, it's necessary to build additional functionality around OSLC, or use an existing centralized "manager" or "hub" solution (Such as ContextSDM or RELM).

Business Outcome:

Supports transition from document-based environment to an Enterprise Digital Thread ultimately improving quality of products, efficiency in development processes and reduction in needless data replication.