sysml-roadmap:system_analysis_workgroup
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision Last revision Both sides next revision | ||
|
sysml-roadmap:system_analysis_workgroup [2016-04-19 12:37] mbajaj |
sysml-roadmap:system_analysis_workgroup [2017-05-23 14:44] sfriedenthal [Presentations] |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | Back to [[http://www.omgwiki.org/OMGSysML/doku.php?id=sysml-roadmap:sysml_assessment_and_roadmap_working_group| System Modeling Assessment and Roadmap Working Group]] | + | Back to [[http://www.omgwiki.org/OMGSysML/doku.php?id=sysml-roadmap:sysml_assessment_and_roadmap_working_group| SysML v2 RFP Working Group]] |
| Line 10: | Line 10: | ||
| - | ===== Project Overview ===== | + | ===== Overview ===== |
| - | The Systems Analysis Workgroup originated as part of the SysML Roadmap effort within the OMG Systems Engineering Domain Special Interest Group (SE DSIG). The near term goal is to identify requirements related to interoperability such that SysML can support standards for data interoperability, traceability, analytics in a multi-disciplinary engineering context. | + | The Systems Analysis Workgroup is formed under the [[SysML Assessment and Roadmap Working Group]] to research and gather requirements for seamless and integrated analyses of complex systems across their lifecycle. This workgroup focuses on the system analysis challenge stated in INCOSE Insight article (Vol 18, Issue 2, Aug 2015) {{sysml-roadmap:incose_themed_insight_article-evolving_sysml_and_the_system_modeling_environment_to_support_mbse-draft-2015-02-01.pdf| Evolving SysML and the System Modeling Environment to Support MBSE}} that states: |
| + | //The next-generation modeling language must include precise semantics that avoid ambiguity and enable a concise representation of the concepts. SysML currently leverages the UML metamodel for much of its semantic foundations. The language must derive from a well-specifed logical formalism that can leverage the model for a broad range of analysis and model checking. This includes the ability to validate that the model is logically consistent, and the ability to answer questions such as the impact of a requirement or design change, or assess how a failure could propagate through a system. The language and tools must also integrate with a diverse range of equation solvers and execution environments that enable the capture of quantitative data. // | ||
| - | ===== Driving Requirements ===== | ||
| - | * The next-generation modeling language and tools must support MBSE in the broader context of Model-Based Engineering (MBE), where the models and tools are fully integrated across discipline-specific engineering tools, including hardware and software design, analysis and simulation, and verification. All these model-based tools working together establish an environment for engineering the total system. | + | ===== Goals ===== |
| - | * The next-generation modeling language must provide a standard application programming interface (API) to provide dynamic access to the model, while providing appropriate access controls. | + | The System Analysis Workgroup is pursuing the following goals for SysML 2.0: |
| - | * It should also integrate with emerging platforms for managing and integrating model-based content, such as Open Services for Lifecycle Collaboration (OSLC), which is based on linked data and semantic web technology, and the Functional Mockup Interface (FMI), which provides model exchange and co-simulation capability for executable behavior models. | + | - Analysis must be seamless integrated with system development and operation |
| - | * Model transformation is another core capability of the SME, by providing the ability to translate from one modeling language to another. | + | - Support various types of system analyses and execution tools |
| + | - Manage analysis models and relate results to decisions | ||
| + | - Improved user interaction to define/generate, execute, archive analysis models (analysis lifecycle) | ||
| - | ===== Example Use Cases ===== | + | ===== Analysis Definition and Examples ===== |
| - | - Elaborating a SysML Block with a behavioural model described in a different language (e.g. Modelica) and keeping the interfaces in synch | + | System Analysis is the systematic investigation of a real or planned system to (a) compare and select candidate system architectures, or (b) determine causes & resolutions of failures / exceptions [SEBoK - http://goo.gl/RCtAKt, NASA SE Handbook (2007) - http://goo.gl/iVBVES]. Some common examples of system analysis are as follows: |
| - | - Rendering a SysML diagram on a lightweight / web based tool | + | |
| - | - Reading SysML models by analysis tools, for example, making sure the model conforms to some pre-defined rules | + | |
| - | - Linking SysML elements with external elements such as requirements or test cases | + | |
| - | - Model transformation rules (UPDM->SysML, SysML->UML) | + | |
| - | and more... | + | - Compute and compare the mileage/cost for a set of car designs |
| + | - What is the design impact of a requirement change? | ||
| + | - Optimize manufacturing process to max yield/cost | ||
| + | - Trace parts or functions that caused the failure of a system | ||
| - | ===== Status Quo ===== | + | ===== Challenges in formulation, representation, and execution of system analyses ===== |
| - | + | The current generation of SysML (1.x) has the following challenges related to formulating, representing, and executing system analyses. | |
| - | * No cross-disciplinary traceability | + | - Analysis is a missing concept in SysML |
| - | * Different (proprietary) data formats | + | - Lack of formal represenation of analysis objectives, subject system, analysis models, results, and decisions |
| - | * Need to capture multi-disciplinary engineering data and relationships in a common data format | + | - Lack of formal representation of design <-> analysis model transformations |
| - | * No standard API to access SysML data | + | - Incomplete definitions of types and units |
| - | * No standard Web API to access SysML data | + | - Lack of formal representation of complex data structures, such as vectors, tensors, and matrices |
| - | * No standard Query API to perform complex queries on SysML data | + | - Lack of formal representation of mathematical operators, such as needed for differentials and integrals |
| + | - Lack of formal representation of primitive geometry concepts, as needed for precise representation and verification of requirements | ||
| + | - Lack of formal representation of visualization concepts, such as mathematical graphs as needed for representing analysis results | ||
| + | - Lack of a unique identifier system for model elements | ||
| + | - Lack of element-level version and configuration management | ||
| + | ===== Presentations ===== | ||
| + | - {{sysml-roadmap:sysml_v2_analysis_requirements_omg_reston_2017-03-23.zip|SysML 2 Analysis Requirements presentation (zip) at SysML 2 RFP WG mtg at OMG Technical Meeting, Reston (Mar 20-24, 2017) }} | ||
| + | - {{sysml-roadmap:sysml_2_analysis_requirements_2017-02-08_.pdf|SysML 2 Analysis Requirements presentation at SysML 2 RFP webcon (Feb 8, 2017) }} | ||
| + | - {{sysml-roadmap:sysml_2_analysis_wg_2016-11-16.pdf|System Analysis presentation at SysML 2 RFP webcon (Nov 16, 2016) }} | ||
| + | - {{sysml-roadmap:sysml_2_analysis_wg_2016-09-13.pdf|System Analysis presentation at Chicago (Sep 2016) }} | ||
| + | - {{sysml-roadmap:05-sysml_v2-system_analysis-bajaj-intercax-_2015-12-08.pdf|System Analysis presentation at La Jolla (Dec 2015)}} | ||
| + | - {{sysml-roadmap:sysml_v2-analysis_concept-manas_bajaj_intercax-reston-2016-03-16.pdf|System Analysis presentation at Reston (Mar 2016) }} | ||
| - | + | ====== System Analysis Workgroup Team ====== | |
| - | ===== Limitations of SysML ===== | + | |
| - | + | ||
| - | SysML data is currently not available: | + | |
| - | * in a standardized graph-based data format | + | |
| - | * through a standard API | + | |
| - | * through a standard Web API | + | |
| - | * through a standard Query API to perform complex queries | + | |
| - | + | ||
| - | + | ||
| - | ===== Derived Requirements for Interoperability ===== | + | |
| - | + | ||
| - | System Modeling Environment (SME) should support: | + | |
| - | * a data format suitable for describing graphs | + | |
| - | * a non-proprietary data format | + | |
| - | * a widely adopted data format | + | |
| - | * Standard Web API to access SysML data | + | |
| - | * Standard Web API supporting complex queries | + | |
| - | + | ||
| - | + | ||
| - | + | ||
| - | ===== Key Features of New Concepts ===== | + | |
| - | + | ||
| - | * Adoption of data format and data access standards aligned with W3C standards | + | |
| - | * Adoption of data format and data access standards aligned with the larger web community | + | |
| - | * Merging/Linking different systems engineering standards (STEP/OMG/ISO/OSLC) through Linked Data | + | |
| - | + | ||
| - | + | ||
| - | + | ||
| - | ===== Recommended Standards for Interoperability ===== | + | |
| - | * **Data** of the System Modeling Environment (SME) should be available in the W3C standard **[[http://www.w3.org/RDF/Resource Description Framework (RDF)| Resource Description Framework (RDF)]]** | + | |
| - | * **Metadata** (semantics) in the System Modeling Environment (SME) should be defined in RDF vocabularies (W3C standard **[[http://www.w3.org/TR/rdf-schema/| RDF Schema]]**) and shape constraints (W3C standard **[[http://www.w3.org/TR/shacl/| SHACL]]**) | + | |
| - | * **Web API** of the System Modeling Environment (SME) should be RESTful and conform to the W3C standard **[[http://www.w3.org/TR/rdf-schema/| Linked Data Platform]]** | + | |
| - | * **Query API** of the System Modeling Environment (SME) should conform to the W3C standards **[[http://www.w3.org/TR/sparql11-query/| SPARQL]]** and **[[http://www.w3.org/TR/sparql11-protocol/| SPARQL Protocol]]** | + | |
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | ===== Review Documents ===== | + | |
| - | + | ||
| - | * {{sysml-roadmap:sysml_v2_model_interoperability_requirements_-_axel_reichwein_-_dec_10_2015_v3.pptx|SysML v2 Model Interoperability Requirements - Axel Reichwein - Dec 10 2015}} | + | |
| - | + | ||
| - | + | ||
| - | ===== Prototypes to demonstrate feasibility ===== | + | |
| - | * Open-source OSLC and Linked Data solutions available at [[https://github.com/ld4mbse| GitHub ld4mbse]] | + | |
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | ===== SME/SysML v2 Service requirements (e.g. functions) to support interoperability ===== | + | |
| - | + | ||
| - | Most services listed in the {{00-SysML v2-Services-2015-11-26.xlsx| spreadsheet}} are useful for supporting data traceability/interoperability. | + | |
| - | + | ||
| - | * Services to create, read, update, and delete links between tools | + | |
| - | * Services to create, read, update, delete, and execute transformations to/from SysML models | + | |
| - | * Services to export and import unstructured and structured data | + | |
| - | * Services to create, update, delete, and execute model elements and patterns | + | |
| - | * Services to create, resd, update, and delete viewpoints | + | |
| - | * Services to create, read, update, delete, and execute model queries to support visualization and analysis | + | |
| - | * Services to generate and manage views | + | |
| - | * Services to create, read, update, delete, and execute model validation rules to validate input data and model | + | |
| - | * Services to create, read, update, delete, and execute analytical models | + | |
| - | * Services to manage model metadata | + | |
| - | * Services to manage changes to model | + | |
| - | * Services to create, read, update, delete, and execute workflows and notifications | + | |
| - | + | ||
| - | + | ||
| - | + | ||
| - | ===== Current Action Items ===== | + | |
| - | + | ||
| - | * Address requirements related to FMI and model transformation | + | |
| - | * Present traceability/interoperability requirements in the context of change management scenarios | + | |
| - | * Illustration of how their concepts supports the Hybrid SuV scenario | + | |
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | ===== Team ===== | + | |
| ^ Name ^ Organization ^ email ^ | ^ Name ^ Organization ^ email ^ | ||
| - | | Axel Reichwein | [[http://koneksys.com/| Koneksys]] | <axel.reichwein@koneksys.com> | | + | | Manas Bajaj | Intercax | <manas.bajaj@intercax.com> | |
| - | | Nerijus Jankevicius | No Magic | <nerijus@nomagic.com> | | + | | Bjorn Cole | NASA JPL | <bjorn.cole@jpl.nasa.gov> | |
| - | | Eldad Palachi | IBM | <eldad.palachi@il.ibm.com> | | + | | Ahsan Qamar | Ford | <AQAMAR2@ford.com> | |
| + | | George Walley | Ford | <gwalley2@ford.com> | | ||
| - | Last updated February 17, 2016 | + | Last updated Apr 19, 2016 |
sysml-roadmap/system_analysis_workgroup.txt · Last modified: 2017-05-23 14:50 by sfriedenthal
Page Tools
