Modeling Formalism Modeling Language Foundations System Modeling Assessment

Modeling Formalism (Modeling Language Foundations) System Modeling Assessment & Roadmap Working Group Meeting – SE DSIG La Jolla – Dec 08, 2015 Yves BERNARD 1

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

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 M 2 T/M 2 M transformation § Verify system meets requirement Þ Provide capabilities for both static analysis and simulation 3

Sys. ML v 2 Services § Will contribute to the following services (as defined by the “Sys. ML v 2 Services spreadsheet”): – Create, view, update, delete, and execute model transformations to/from Sys. ML 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

Current Sys. ML 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 5

Foundation Candidates § First Order Logics – Basis for defining axioms on which analyses can be built – used by f. UML (b. UML 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 f. UML roadmap 6

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 7

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