Rationale

The MoSSEC standard is designed to enable the sharing and exchange of Modeling and Simulation  information in a collaborative Systems Engineering Context - “MoSSEC”.

The globalization of aerospace and defence industries drives large volumes of work for modelling and simulation of product performance and behaviour, into geographically distributed teams and into the supply chain. This data is used to justify change decisions and to validate the product throughout development, certification and in-service. The MoSSEC standard enables a proper exchange and sharing of modelling and simulation data with traceability to its systems engineering & PDM context. This enables competitive and robust product development in global teams, where modelling and simulation data is fully traceable to the PDM referential, and enabling quick validation of next design changes, whether in product development or in-service phases.

This collaborative context data can be summarised as “who”, “what”, “where”, “when”, “how”, “why”.

Interaction with other standards

Within a collaboration context the Collaboration Context data and the Technical Modelling and Simulation data are shared and exchanged, which allows the connection and control of the SDM dataset and global processes. The technical data will continue to be exchanged with the technical standards in use today, and MoSSEC will provide the standard for the collaboration context information. Together they enable the distributed dataset

The use of the MoSSEC standard will enable full traceability and re-use of modeling and simulation information throughout the product lifecycle and independent of the specific IT applications used across collaborating enterprises. The standard targets to cover a core subset of AP239 systems engineering information content and related  information services, that can be readily implemented and deployed  to support engineering collaboration

Systems Engineering Context

To provide the systems engineering conext, some typical types of information and data managed and traced 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 definition
• System Requirement Definition: Operations / operational needs; system requirement
• Architecture Design: study management; requirement cascade and emergence; interfaces; architectures; assumptions and decisions.
• Design definition: interfaces; requirements; physical, functional, and logical model
• System Analysis: methods and tools; simulation models; performance, behavior, feasibility, sensitivity results
• Integration: physical, functional, logical models linked to architecture and requirements.
•  
• Transition: stakeholder requirements, operations, architecture
• Validation: architecture, stakeholder requirements satisfaction, verification and evidence; procedures; reviews; test results and reports

Scope for MoSSEC

The full scope of the systems engineering context is too ambitious for the first edition of MoSSEC. Over a series of  multi-partner research projects a set of Business Objects for MoSSEC have been identified and can be summarised in a cartoon jigsaw as shown.

MoSSEC edition 1 is targeted at the core business objects which follow the "80/20" rule, providing the majority of coverage needed for the most common business scenarios. These are represented by the central row and column of the jigsaw cartoon covering Studies, Models, and Requirements/Quality, Architectures and Organisation with some aspects of the other pieces are necessarily included.

Target Business scenarios

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 domains, between platforms and between organisations

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.

   Example Problem statements in business scenarios:

• What organisation was used for this simulation/analysis?
• What requirement version should be used for this behaviour 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?
• Prove that the right analysis result was used for this assumption.
• If there is a change to this requirement version what does it impact?
• 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.