MoSSEC Business Scenarios

The different phases of systems engineering each have their own engineering problems to solve involving different types of information and data at different levels of maturity. However they all need to establish the traceability of that data through the system lifecycle and evolution.

Some typical types of information and data managed and traced by the v-cycle phases are:

• Business/Mission Analysis: Problems and opportunities; solution space; potential solutions; decisions, rationale and assumptions.
• Stakeholder Needs and Requirement Definition: Stakeholder expectations, goals, needs; value drivers; quantified objectives. All providing traceability for the stakeholder requirement definitions
• System Requirement Definition: Operations / operational needs; system requirements
• Architecture Design: study management; requirement cascade and emergence; interfaces; architectures; assumptions and decisions.
• Design definition: interfaces; requirements; physical, functional, and logical models
• System Analysis: methods and tools; simulation models; performance, behavior, feasibility, sensitivity results
• Integration: physical, functional, logical models linked to architecture and requirements.
• Verification: architecture, system requirements satisfaction, verification and evidence; procedures; reviews; test results and reports.
• Validation: architecture, stakeholder requirements satisfaction, verification and evidence; procedures; reviews; test results and reports

Traceability across domains, platforms and organizations

There are mature PLM platforms in the marketplace that manage traceability, however the distinguishing feature of the traceability business processes targeted by MoSSEC is the need for traceability between domain teams, between platforms and between organizations.

The business processe problem statments are characterised by:

• The need to understand the links between “things” both for planning (e.g. what should be used), and for pedigree (e.g. what was used),
• The need to push (what should be sent) and pull (what should be used) to/from another domain/platform/organisation.
• In addition to tangible “things” like the product definition (e.g. what geometry was used) and methods and tools, “things” also include intangibles like assumptions, decisions, uncertainties i.e. who, what, where, when, how and why.

To achieve this traceability, all the domains, platforms and organisations need to be able to share and/or exchange this type of information associated to the technical data (e.g. Geometry, Finite Element, Functional behaviour files) which already have well established standards for exchange

There are many business processes that involve traceability questions or directives. These questions/directives can be illustrated using the table below:

For Example:

• What organization was used for this simulation/analysis?
• What requirement version should be used for this behavior analysis assessment
• This method/tool should be used for this requirement verification.
• What is the delta of the product definition that should be sent for this simulation?
• Where was this assumption used for a decision?
• Why was this technology used for this component?
• Prove that the right analysis result was used for this assumption.
• If there is a change to this requirement version what does it impact?
• This behavior simulation model should be used for this breakdown element (of this architecture, with these interfaces and these operational scenarios).

Other traceability questions/directives that do not fit into the above table include:

• Change proposal: If change C was made to Product definition version P it is expected to improve performance Y
• Multiple links: The Simulation analysis result S showed that Product definition version P met requirement R with a margin of M and that margin has an uncertainty of U.
• System Integration: What sub-system behavior simulation models should be used to build an integrated system behavior simulation model and how do they interface together?

The business processes are characterized by:

• The need to understand the links between “things” both for planning (e.g. what should be used), and for pedigree (e.g. what was used)
• The need to push (what should be sent) and pull (what should be used) to/from another domain/platform/organization
• In addition to tangible “things” like the product definition (e.g. what geometry was used) and methods and tools, “things” also include intangibles like assumptions, decisions, uncertainties i.e. who, what, where, when, how and why.

To achieve this traceability, all the domains, platforms and organizations need to be able to share and/or exchange this type of information associated to the technical data (e.g. Geometry, Finite Element, Functional behavior files) which already have well established standards for exchange.

Cross-Organization additional issues

Cross organization traceability adds security issues to the problems, with the need to assure security of information (IPR) and the need to cross company firewalls.

Cross-Platform Standard Interfaces

The need for cross-platform traceability means that platforms and tools will potentially need to be able to trace information across many other platforms and tools. Using custom interfaces between each platform/tool is not a scalable or maintainable scenario; therefore a standard interface is needed for this type of information (who, what, where, when, how and why).

Typical problem statements are:

• Modelling and Simulation Specialist: I want to change my process to call the latest capability from my platform without having to wait for someone to integrate it
• Project Manager: I want to use development process information in my programme scheduling tool.
• Method and Tool Architect: I want platforms and tools to be able to communicate using an internationally recognized standard so that I do not have to maintain a multitude of platform interfaces, and am not tied into one platform.
• Archivist: I want to be able to archive the technical data with its context and decision data using international standards so that it can be read and utilized in the future by the platforms that will be in use at the time.
• Capability Vendor: I want engineers to be able to plug my new capability into their platform without my having to write an interface to that platform
• Platform Vendor: I want to use my valuable software development team to enhance the platform rather than spend time developing interfaces.