presentation_syndeia_for_mbe_at_tmt_workshop_2016-11-02.pdf , Syndeia demonstration (YouTube link) - https://youtu.be/Fu1w6sQviko
1. Presentation of Syndeia by Intercax - Manas
Intercax : Software for MBSE MBSE: Unified model of system versus series of disconnected documents or document based flows between models DBSE > MBSE = 2d⇒3D CAD Total System Model: Digital blueprint connecting models across disciplines.Evolves as each of version managed models evolve. Goal: Traceability between disciplines across system lifecycle Intramodel vs intermodal connections: building blocks of interoperability. intermodel- between elements in different models. intra-track/compare/sync/execute connection elements. Syndeia= Software Platform for MBSE
Dashboard provides view of systems Ex Teamcenter, DOORS, SysML, Repository,etc views Moving across operations connections are created and modeled in the graph. Circle layout displays connections between systems. Changes in system and/or requirements are shown, and differences between versions.
Project management: Interface with JIRA. Linked to SysML model. Architecture and simulation model are connected and track changes.
Mechanical cad domain: domain requirements, define in Sysml model, and seed. Eliminates text based requirements. Connection between System and Mechanical domains.
Syndeia- Usage and implementation of open standards, frameworks, and API’s. MBSE-centric tool, stores inter model connections.
Enterprise MBE application, Connected to CAD models openAPI, Requirements in domain model Configuration Control: Authentication of server (IP Issues when sharing across organizations) Syntactic and semantic levels of checking requirements. Graph shows which versions are connected. How to check integrity of the models: Information in the graph, integrity check at the macro level.
Configuration management workflow, overall of individual versions: Report shows existing configuration and changes. More difficult problem requires us to think about how we create models Allows for data integrity and consistency checking. Socialization process and cost can make difficulties. Rigid configuration control.
2. Phoenix Model Center
Robert provided a brief overview of Phoenix Model Center.
Workflows : explore tradespace, range of parameters, run design, pareto front Model workflow and execute workflow, model version controls of input and output of data Design structure at JPL. Document workflow for analysis, and version control. Simplifies parameters, scalable
Differences between PMC and Syndeia: Phoenix Model CenterAnalysis, define data flowing between tools, and there is a transformation, optimization tool, scheduling mechanism, limits parametric models if you plan on changing your architecture. Syndeia: Unified graph, how analysis models are connected, connects the tools together
Michele Zamparelli reported from some evaluation ESO did some years ago where the decision was not to go with PMC because of the apparently infrequent design changes. Attached is an overview of the tool and model landscape which could have been in the scope of PMC workflow.
3. Object Oriented Systems Engineering Method (OOSEM)
Robert gave an overview. OOSEM provides guidance on Organization of model, construction of view and viewpoints of the model. It followed an object oriented approach and use case driven. Introduces concepts of Domain (everything you need to complete mission), Enterprise, System of Interest. Helps to identify system boundaries, structural diagram, identify use cases at enterprise level. By elaborating use cases in mission enterprise context at black box level in terms of activity diagrams to define all operations needed.
It pursues an iterative and incremental approach to elaborate into conceptual (logical) and realization (physical) level.
Conceptual level: Specify further your black box level. Specify which conceptual elements are needed. Recursive process. Technology independent.
Decision of what technology is needed to achieve the operations. All levels of system decomposition hierarchy structure, function, behavior are defined.
Executable Systems Engineering Method (ESEM) augments the OOSEM activities by enabling executable models. Extended OOSEM with executable patterns. SysML models that verifies requirements automatically against design specificitions.
ISO 42010 defines viewpoints and architectural frameworks. George claimed that we face the problem of converting a formal, computer interpretable specification into an ambiguous natural language form so the average engineer can understand it. After manufacturing there could be errors in hardware, and viewers can’t check SysML model to check requirements. There is need for document. OpenMBEE's document generation and and online document in ViewEditor addresses this need.
LSST mentioned their “triangular” methodology which consists of requirements, structure, and behavior.
MBSE Issues o Cost o Challenge to sell to management when DBSE is working efficiently o Communication barriers & willingness to learn a new system o A universal language is necessary both internal and external to the company (i.e. reviewers); MBSE language may not be understood universally, so an additional system is needed to convert the language to English for all to utilize the benefits of MBSE o Lack of paper drawings/specific instructions for contractors creates a gap in production verification – example from Northrop Grumman
MBSE Benefits o Quality improvements & lowers risk o Accessible interface connections o Lowers cost of document configuration management efforts
Successful transition will involve step-by-step implementation. Start with database, see benefits, then move to full MBSE, or maintain DB/MB-SE hybrid system
MBSE may not be beneficial everywhere, so it’s important to analyze the benefits before/during implementation to get the most of it
MBSE aspects include behavioral analysis, system architecture, requirement traceability, performance analysis, simulation, tests
4. MagicGrid from NoMagic - Salius
SysML is JUST language, needs to be combined with methodology/framework. MagicGrid provides a simplified framework based on OOSEM. Clearly defines modeling process. Pillars: Requirements, Behavior, Structure, Parametrics Layers of Abstraction: Specification(Concept,Problem) vs Design(Solution) Flow of Concept : Stakeholder needs→ use cases → system context→Measurements of Effectiveness Goals: long term and global statements Flow of Solution: System→Subsystem→Component
JPL comments: Initially tried to construct model according to Viewpoints but viewpoints keep changing. Experience shows it's better to construct model according to methodology with same structure and construct view points by querying the model to produce tables and other human readable artifacts. Try to map physical/logical model to OOSEM concepts to maintain consistency even if organization is different. Challenges: Traceability between multiple levels of abstraction. Specialization relationships between levels of abstraction. Block is a functional unit.
5. FMI (Functional Mockup Interface)
Robert gave a brief overview of FMI. specifies open std for model exchange and co-simulation of dynamic models. tool dependent std for -model exchange -co-simulation tool develops FMU (Functional Mockup Unit), tools can attach FMU, call data benefits: open, tool support.
6. LSST Verification - Brian
V&V Integrated into assembly, integration, and verification. Verification and Validation: LSE-160 is the governing doc on LSST V&V
Process: Requirements, requirements are verifiable, verification planning, task interdependency, verification events.
Tools utilized for strengths. SysML is extensible allowing for additional stereotypes
Refinement of Individual Test Cases: Refined and detailed input to the commissioning planning effort. Can be used directly as inputs to writing detailed test & analysis procedures.
AIV Models: Why is it required to have that level of detail of AIV processes? Inconsistencies from moving one tool to another. Activity diagrams that encapsulate concepts. Every requirement is traced into a verification event. Verification has success criteria that has been met, and which can be automated.
Provisions in plan for issues: time allocated for fixes. Time allocated is in the flow of the integrated master schedule. Refined test case actions mapped to associated PMCS activity steps.
Top things missing in managing V&V process: How the person implements verification activity checklist. JIRA management, interface between model and JIRA.
7. Modeling Patterns (structure, behavior, operational scenarios)
Robert gives overview of pattern based model construction with composite structure. Example for requirements: Property Based Requirements, patterns for executable models for budgets and early design verification. Advantage of having an addition Abstract Requirement: Customizations, Class can own fundamental properties,
Library and Composite Pattern Approach: Specialize general req, and use redefinition to repopulate values.
Systems specification is based on the property based requirements. Ex. constraint, and the parametric models binds a parameter to one of the constraint parameters. Later in the system design: the verification context binds the systems design to the constraint parameter.
Move away from refinement and dependencies, to libraries, association blocks, and composite structures. Don’t extend language through stereotype mechanism. Create profiles automatically based from ontology. Correct by construction as native SysML language constructs are used.
Library specialized by the domain. Constraints are defined at the metal level and are applied at the instance level. Reduces number of stereotypes.
8. Telescope domain specific modeling problems - Gelys
Gelys provides overview of TMT AO operational scenario modeling for TMT. Address problem that stakeholder will not be able to communicate with you. Use activities for operational scenarios. Duration constraints on actions. Swim lanes with action, when you have a control flow you have an interface which is based on behavior.
Block: components defined, behavior defined in state machines, communication through ports. Duration analysis results verified against requirement for a particular configuration. Based on behavior, the flow of information of scenarios and components.
Query ICD’s. What do you capture, how do you capture it, and how do you query ICD’s. Auto generate based on port properties and port flows of interfaces.
Duration analysis. Fully automated process. Part of simulation.
(ex. operational modes for components. Dynamic power roll up for particular scenarios.)
ViewEditor provides document version of information you query from the model. Document oriented web client for the model. Edits to document result in edits to SysML model. Merging between document and SysML model can be difficult.
9. Analysis OpenMBEE's Platform for Model Analysis (PMA): Provide common generic platform for model analysis for scheduled or on demand job. Limited to document generation and requirements verification based on simulation at the moment. Ideally it should be able to run with any interface with the same platforms.
OpenMBEE's Behavior Analysis Engine (BAE): Operates from model repository, open sourced, Constraint solver, scalability for problem size, integrates
10. MBSE Cookbook with SysML next generation Widely demanded to have a practical oriented cookbook to show how to construct, query, analyze a model. Suggestions: MagicDraw models Best practices Generic systems engineering perspective Where to start, what do I do, how do I get out of it. Conventions. State analysis (state affects diagram) Complex Examples From a vendor's perspective clients need guidance and preferred methods to use it.
Actions: o TMT will upload all presentations to MBSE Wiki o Willing parties to provide their organization’s glossary/ontology o Follow up meetings down the road proposed by Gelys o All to read MBSE Cookbook and provide recommendations to Robert for improvements