Back to [[http://www.omgwiki.org/OMGSysML/doku.php?id=sysml-roadmap:sysml_assessment_and_roadmap_working_group| SysML v2 RFP Working Group]] ====== SysML v2 Model Formalism Working Group ====== ===== Project Overview ===== The SysML v2 Model Formalism project 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 the logical formalism that SysML v2 will be derived from. ===== Driving Requirements ===== * The next-generation modeling language must include precise semantics that avoid ambiguity and enable a concise representation of the concepts. * The language must derive from a well-specified 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. ===== Status Quo ===== * SysML 1.x was originally designed to support diagrams rather than analysis; since then, the expectations on modeling have changed. ===== Limitations of SysML ===== * SysML 1.x is defined as a profile of UML 2.x, which renders its extension capabilities limited. * SysML execution semantics are based on the current UML execution semantics, which only cover a small portion of the overall language. * More precisely, while fUML handles the execution semantics of the core of UML unambiguously, these semantics are based on a discrete model of behavior; whereas SysML needs to embrace both discrete and continuous behavior. Therefore, while SysML has access to unambiguous execution semantics for discrete behavior, the same cannot be said for the continuous behavior that SysML requires, which limits its applicability. * However, activity models can describe continuously changing quantities at small increments of time, like Simulink does. The {{numerical-analysis-activity.pdf|attached activity diagram}} can be run in a clocked fashion, as in numerical simulation, see description around Figure 26 in http://tinyurl.com/ho537cp. fUML might support clocked execution, even though the reference implementation doesn't, but it doesn't support streaming. Clocked execution is within the UML semantics for activities, and it supports streaming, of course. * The current formalism for SysML requires more robust capability to support the full range of reasoning and model checking to ensure system design. Below are some example use cases. * After learning of the government regulation to increase MPG to 27.5, the engineer updates this requirement in the SME. As a result, the SME informs the engineer of which elements in the system design might be impacted by this requirement change (e.g., elements dealing with gear selection). * After making a change to the gear selection algorithm in the system design, the SME informs the engineer of impacted model elements, along with the associated analysis that need to be re-run. Based on the analysis, the engineer discovers that the vehicle's acceleration performance has been reduced. The engineer then uses the SME to determine what other elements have an impact on the acceleration performance to see what other changes could be made to the system design to restore the acceleration performance to the specified level. * The engineer decides that weight reduction will be the preferred approach to restore the acceleration performance. As a result, the engineer uses the SME to consider potential system design changes that could reduce the weight. One such change is to reduce the weight of the transmission. The engineer identifies design alternatives to reduce the transmission weight. For one of the promising candidates, the engineer acquires a model of the transmission from the manufacturer and integrates it into the system model. However, the SME informs the engineer that the electrical connectors are incompatible, and the engineer proceeds to investigate other alternatives. * Based on analysis of other alternatives, the engineer identifies a design alternative that satisfies the required acceleration performance and the required increase in fuel efficiency. The engineer then performs a verification analysis through the SME to verify that the system design still meets the requirements. ===== OMG Presentations ===== * {{sysml-roadmap:sysml_v2_formalism_presentation_sysml_2_rfp_brussels_v3.pptx | SysML v2 Formalism: Requirements & Benefits Brussels - June 2017}} * {{sysml-roadmap:sysml_v2_formalism_presentation_sysml_2_rfp_reston_v11.pptx| Semantics Intro, Formalism Requirememts, Benefits, Use Cases, and Future Directions Reston - March 2017 (SysML 2 RFP WG)}} * {{sysml-roadmap:sysml_v2_formalism_presentation_adtf_coronado_v6.pptx| SysML 2.0 Formalism Requirements and Potential Language Architectures Coronado - December 6 (ADTF)}} * {{sysml-roadmap:sysml_v2_formalism_presentation_sysml_2_rfp_coronado_v6-cb.pptx| SysML 2.0 Formalism: Requirement Benefits, Use Cases, and Potential Language Architectures Coronado - December 2016 (SysML 2 RFP WG)}} * {{sysml-roadmap:sysml_v2_formalism_requirements_chicago_09152016_v4.pptx| SysML v2 Formalism Requirements Chicago - September 2016}} * {{sysml-roadmap:sysml2.0_modeling_formalism_orlando_june2016_ver2.pptx|Modeling Formalism (Modeling Language Foundations) Orlando - June 2016}} * {{sysml-roadmap:sysml2.0_modeling_formalism_reston.pptx|Modeling Formalism (Modeling Language Foundations) Reston - March 2016}} ===== Key Features of New Concepts ===== * TBD ===== Formal Language References ===== * {{http://www.w3.org/TR/owl2-syntax/|OWL 2}} * {{http://www.w3.org/TR/owl2-direct-semantics/|OWL 2 Direct Semantics}} * {{http://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20_ontology1/|IDEAS Foundation}} ===== Review Documents ===== * {{sysml-roadmap:use_case_for_expressing_dysfunctional_behavior.pdf| Use Case for expressing dysfunctional behavior}} * {{sysml-roadmap:sysmlv2_formalism_wg_slides_09012016_v4.pptx| Teleconference Powerpoint Slides (9/7 & 9/9)}} * {{sysml-roadmap:algebraic_structures_on_relationships.pptx| Teleconference Powerpoint Slides (8/15) - Algebraic Structures on Relationships/Customizable Inference Engines in SysML v2}} * {{sysml-roadmap:bayesianreasoningovermodels_-_2016-07-30.pdf| Teleconference Powerpoint Slides (8/1) - A Bayesian Learning Approach to Inconsistency Identification in MBSE, S.Herzig}} * {{sysml-roadmap:herzig-dissertation-2015_1_.pdf| A Baysian Learning Approach to Inconsistency Identification in Model-Based Systems Engineering (Dissertation), S. Herzig}} * {{sysml-roadmap:sysml-formal2.pptx|7/25/2016 Teleconference PowerPoint Slides}} * {{sysml-roadmap:sysml-formal2.pptx|7/25/2016 Teleconference PowerPoint Slides}} ===== Prototypes to Demonstrate Feasibility ===== * TBD ===== SME/SysML v2 Service Requirements (e.g. functions) for the Model Formalism ===== * TBD ===== Related Work, Possibly Reusable ===== * **OMG** * {{http://www.omg.org/techprocess/meetings/schedule/UAF_FTF.html|Unified Architecture Framework FTF}}, adopted response to {{http://doc.omg.org/c4i/13-09-11|UPDM 3.0 RFP}}. OWL-like foundation ([[http://www.ideasgroup.org/|IDEAS]]) metamodel with UML/SysML Profile. * {{http://doc.omg.org/ptc/16-02-37|Distributed Ontology, Modeling, and Specification Language (DOL)}} can be used to integrate first order logic based languages (in [[http://www.omg.org/techprocess/meetings/schedule/DOL_1.0_FTF.html|finalization]] March 2016, from {{http://doc.omg.org/ad/13-12-02|RFP}} December 2013). See Annexes for examples. Overview in {{http://doc.omg.org/ad/15-12-04|ADTF presentation}}. More information on [[http://ontologforum.org/index.php/OntoIOp|Ontolog]]. * {{http://www.omg.org/techprocess/meetings/schedule/MOF_to_RDF_Structural_Mapping_in_Support_of_Linked_Open_Data_RFP.html | MOF to RDF Structural Mapping in Support of Linked Open Data RFP and responses}} * {{http://www.omg.org/techprocess/meetings/schedule/Metamodel_Extension_Facility_RFP.html | Metamodel Extension Facility RFP and responses}} ({{http://www.omg.org/spec/SMOF|SMOF}}-based alternative to profiles) * **Ontology** * {{http://www.menthor.net/ontouml.html| OntoUML}} * {{http://www.w3.org/TR/owl2-semantics/#Independence_of_the_Direct_Semantics_from_the_Datatype_Map_in_OWL_2_DL_.28Informative.29 | OWL 2 Direct Semantics}} * {{http://dx.doi.org/10.5381/jot.2011.10.1.a3| Onto Behavior Modeling (aka "UML3")}} ({{http://conradbock.org/bock-ontological-behavior-modeling-jpl-slides.pdf|slides}}, updates available) * Special case of {{http://www.dsmforum.org/events/dsm10/Papers/Mannadiar.pdf|Domain-Specific Engineering of Domain-Specific Languages}} * {{https://www.nist.gov/node/609191?pub_id=822748| Onto Product Modeling}} ({{http://conradbock.org/ontological-product-modeling-short-slides.pdf|slides}}) * **Model checking** (a proof technique for semantic validation) * {{https://www.researchgate.net/publication/243341927_Towards_a_Multi-Formalism_Model_Checker_Based_on_SDES_Description|Towards a Multi-Formalism Model Checker Based on SDES Description}} * {{http://www.academia.edu/14964641/RDF2SPIN_Mapping_Semantic_Graphs_to_SPIN_Model_Checker|RDF2SPIN: Mapping Semantic Graphs to SPIN Model Checker}} * **Hamilton/Hackler** * {{http://www.htius.com/Articles/INCOSE.pdf | A Formal Universal Systems Semantics for SysML}} * {{http://www.htius.com/Articles/36.pdf | Universal Systems Language for Preventative Systems Engineering}} ===== Current Action Items ===== * Emphasize the need for SysML v2 to be computer interpretable. * Clarify the need for both a textual notation similar to a programming language such as ALF and graphical notation for the formalism. * Clarify that the SME should make you aware of inconsistencies, and provide options for resolving them. * Clarify that the formalism should provide a precise and concise extension mechanism (similar to stereotypes). * Clarify that the use cases for model checking should include well formedness checking such as for interface compatibility. * Clarify the need to be able to apply varying degrees of formalism. For example, the language should not overly constrain the user when developing concepts, recognizing that concepts are formed throughout the life cycle and not just early on. This is partially addressed by differentiating the level of precision from the level of detail, but may also allow for relaxing formalism constraints based on user need. * Continue to refine the usability criteria and how the formalism can impact usability. As an example, some system engineers struggle to understand how to organize a model which involves the concepts of namespace and containment. The criteria should enable us to measure and assess how well a concept aligns with the way different representative users think. Consider the following representative users: * A new SysML modeler who may be experienced with other models such as Simulink * An experienced SysML modeler * Identify alternative formalisms and their pros and cons based on the requirements and evaluation criteria. ===== Team ===== ^ Name ^ Organization ^ email ^ | Jonathan Patrick | [[http://www.uah.edu/rsesc| Rotorcraft Systems Engineering and Simulation Center at the University of Alabama in Huntsville]] | | | Yves Bernard | [[http://www.airbus.com| Airbus]] | | | Bran Selic | [[https://www.simula.no/| Simula Research Laboratory of Norway]] | | | Geoffrey Biggs | [[http://www.aist.go.jp/| National Institute of Advanced Industrial Science and Technology]] | | | Conrad Bock | [[http://www.nist.gov/| National Institute of Standards and Technology]] | | | Roger Burkhart | [[http://www.deere.com/| John Deere]] | | | Hans Peter de Koning | [[http://www.esa.int/cdf| European Space Agency]] | | | Manas Bajaj | [[http://www.intercax.com| Intercax]]| | | Rick Steiner | [[http://skygazerconsulting.com| Skygazer Consulting]]| | | Sebastian Herzig | [[http://www.jpl.nasa.gov/| NASA JPL]] | |