1. 1 Modeling Formalism (Modeling Language Foundations) System Modeling Assessment & Roadmap Working Group Meeting – SE DSIG Reston – March, 2016 Yves BERNARD

2. Motivations  Driving requirement #2. a)The next-generation modeling language must include precise semantics that avoid ambiguity and enable a concise representation of the concepts. b)The language must derive from a well-specified logical formalism that can leverage the model for a broad range of analysis and model checking. c)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. d)The language and tools must also integrate with a diverse range of equation solvers and execution environments that enable the capture of quantitative data. 2

3. Evaluation criteria  Precision/unambiguity: ability to have only one (official/standard) semantic interpretation  Usability: easiness to learn (i.e. average learning curve), to operate (e.g. number of clicks/inputs for basic operations)  Efficiency: conciseness, (i.e. telling more with less)  Interoperability: ability to be read and use by analysis tools 3

4. SysML v2 Services  Will contribute to the following services (as defined by the “SysML v2 Services spreadsheet”): – Create, view, update, delete, and execute model transformations to/from SysML models –Define, update, delete, and execute model queries to support visualization and analysis –Define, update, delete, and execute model validation rules to validate input data and model –Define, transform, and execute analytical models 4

5. Illustration with Hybrid SUV Change Scenario  Vehicle design unable to meet a requirement (e.g., stopping distance, safety, stability)  Analysis capabilities able to provide evidence of such a statement  Propose requirement change / assess potential impact  Computation of potential impacts of this change on the design  Provide capabilities for both static analysis and simulation  Propose update to system design  Ability to compute differences between “as is” and “to be” design  Implement/update design  Automated (HW/SW) code generation, and other M2T/M2M transformation  Verify system meets requirement  Provide capabilities for both static analysis and simulation 5

6. La Jolla meeting outcomes Logics formalism worth to be considered:  Temporal logics (=> causal model of time, i.e. events ordering)  High level formalism based on FOL (e.g. Petri-Nets, state machines, …).and the Category theory (which expand the Set theory) as well.  Ability to allow for a variable level of formalism (i.e. just like compiler error levels) About evaluation criteria:  Level of training required for using formal languages (as part of the usability criterion)  effort/cost related to the implementation of the language. Linked to technology readiness/maturity aspect.  Computing power required to operate the language as expected  To be clarified: “evaluation criteria” versus “requirements” 6 New / Updated

7. Requirements vs Evaluation Criteria  Definitions –An evaluation criterion specifies a quantitative characteristic of interest (“property”) which can be assessed. Its value may be parametric (i.e. numerical) or not. –A requirement is a statement about one thing. Evaluating a thing against a requirement results in a Boolean value depending on whether the corresponding statement is true or false for that thing. A requirement may refer on an evaluation criterion. 7 New / Updated

8. Evaluation criteria computation rules  Precision/unambiguity: ability to have only one (official/standard) semantic interpretation  % of the language elements that have one and only one possible interpretation.  Usability: easiness to learn (i.e. average learning curve)  Number of concepts (i.e. metaclasses) / a reference number (TBD, e.g.: nb of reserved words in the C programming language, nb of entries in the SE glossary…)  Efficiency: conciseness, (i.e. telling more with less)  Number of model elements to represent a set of system aspects used as a benchmark  Interoperability: ability to be read and use by analysis tools  @Pawel: to provide input on this 8 New / Updated

9. Modeling Language properties  Related to execution capabilities –Ability to qualify and describe data and data structure (i.e. metadata) –Ability to specify values (i.e. data) –Ability to specify state/value changes (including functions as y=f(x)) –Ability to specify sequences of change –Ability to specify data flows among changes –Ability to specify control structures of change sequences Note: a wider set of control structures will have a positive impact on the efficiency but may reduce the usability  Related to logical inference capabilities –Ability to specify categorical statement –Ability to specify ternary relationships among them (i.e. syllogism) –Ability to consider empty categories 9 Behavior semantics New / Updated

10. ANNEX 10

11. About Language Syntax and Semantics  Extracted from fUML: “A formal language only attaches meaning to statements that are correctly constructed or well formed. The syntax of the language provides the rules for how to construct well-formed statements or, equivalently, for validating that a proposed statement is actually well-formed. The semantics of the language then provides the specification of the meaning of well-formed statements.” 11 New / Updated

12. SysML (UML) 12 PrecisionUsabilityEfficiencyComments Structures Values State change Process Behavior Categories Ternary relationships Unsupported Empty categories Unsupported

13. Current SysML definition and its limitations  Based on UML 2.5, defined as a profile, i.e. has limited extension capabilities  Not fully compliant to UML 2.5 Profile specification  these extension capabilities seem to be unsufficient  Not executable  analyses require specific extension (i.e. non standard)  Design for supporting diagram, rather than analysis: expectation on modeling have changed  MBSE requires more than creating diagrams 13

14. Proposal for formalism specification in the RFP  Option 1: based on “compilation” approach (cf. Cambridge meeting’s presentation)  Other option? 14

15. Foundation Candidates  First Order Logics –Basis for defining axioms on which analyses can be built –used by fUML (bUML base semantics) –No intrinsic support for time  Temporal Logics –Add modes related to time –Better support of evolving systems (i.e. behaviors)  Description Logics (ontologies, processes) –Knowledge representation, based of FOL Note: support for time is part of the fUML roadmap 15