Visual Dynamic Model Inspecting with OPM Model- Based Simulation Environment Yevgeny Yaroker, Valeria Perelman, Prof. Dov Dori 18 March 2016

Introduction Our domain: Conceptual design phase in the systems engineering lifecycle. The decisions made during this phase are the most critical to get right and hardest to change. Existing testing approaches operate on the system’s detailed design, a stage which is too technical for the customer to follow may be very expensive to backtrack

Motivation There is a need to detect problems starting at early stages of the system development, when detailed design does not yet exist. Benefits include: Debugging during earlier stages of system development, finding system malfunctions before investing in extensive code writing Working on a more abstract model – keeping the model simpler with concealed details. Modeling with focus on satisfying requirements. Predictability of changes/modifications in design

Model-Based Simulation Frameworks System model simulation frameworks for detailed design: Modelica, ARENA, Simulink, … Graphical presentation of process flows OPM Animation (OPCAT) Model-based simulation case tools: xUMLite – (xUML) …

run-time verification unit tests integration tests formal verification questionnaires Conceptual modeling Time/ Phase checklist scenario simulation metrics Detailed Design Sub-systems Implementation Integration System testing and evaluation approaches Non- formal Formal Conceiving & alternatives evaluation prototyping

What makes the conceptual model evaluating so complicated? Human abilities to comprehend system dynamics, based on numerous static diagrams, are limited even when well-organized and holistic modeling languages (ML) are used. High level of abstraction, which is typical of conceptual MLs, propagate notations ambiguity.  These factors lead to numerous human errors while: constructing system models reading conceptual models written by others

Research Goal Develop and evaluate a visual dynamic model inspecting with OPM model-based simulation environment.

What is Object Process Methodology (OPM)? OPM is a comprehensive, generic systems development and lifecycle support paradigm OPM Integrates the system’s function, structure and dynamics in a single, unifying model. Complexity is controlled through recursive and selective scaling (zooming) of objects and/or processes to any desired level of detail. The OPM model combines image and text: intuitive graphics a subset of natural English

OPM Basic Concepts Object: A thing that exists or can exist physically or logically Process: A thing that transforms an object by creating it or consuming it or changing its state Objects and processes can be connected with links, which can be structural (such as aggregation, generalization) and procedural (enabling, transformation, and event links)

10 OPM main links Structural Links Procedural links Connect objects to objects Connect objects to processes Aggregation- Participation Generalization- Specialization Exhibition- Characterization Classification- Instantiation Consumption Result Effect Agent Uni- and Bi- directional Tagged link Instrument object

Solution Outline Develop a model-based animation mechanism as an extension of OPM using the infrastructure provided by OPCAT Define clear system behavioral rules in line with OPM syntax and semantics Design a software tool with a wide user profile: having easy-to-use User Interface (UI), not requiring a special technical background providing efficient problem detection and reporting mechanisms Develop a flexible system to enable future extensions

Technical Requirements Simulation/visualization workflow requirements: Simulation shall follow OPM rules. Instance-level simulation shall be enabled. “DVD film” simulation mode requirement: Enable easy work through possible scenarios inexperienced users: Forward/backward simulation, step by step/continuous simulation, pause/continue (relevant only for continuous mode), changing simulation speed Debugging functional requirements: Capability to define breakpoints Provide “lifespan” component which graphically describes the state of all the OPM entities at any stage of simulation Provide special “Debug Info” component which detects possible problems and notifies user about them. Capability to reproduce problematic scenarios

Simulation Typical View Process is colored if it is currently executed Object with existing instance is colored Red token runs on the activated link

Simulation Main Controls Main Toolbar – Controlling simulation flow Starting/Stopping simulation. Playing forward/backward. Controlling simulation velocity. Invoking simulation properties dialog. Status Bar – Observing simulation status Play mode. Current timeline. Main toolbar Status Bar

Model Debugging Process User can toggle breakpoint on a process. The simulation runs till the breakpoint is reached. Reaching the breakpoint will pause the simulation.

Debug Information Notifying a user regarding the problems making the further progress run impossible, such as: A process invocation failure, A required manual process activation, “No future simulation events” situation.

Architecture – Main Constructs Task Queue consists of Simulation Tasks. A Simulation Task: represents an atomic simulation activity implements Command and Undo DPs. Task Queue keeps the simulation working schedule. Rule defines the Simulation Tasks to be scheduled upon some simulation events. Scheduler uses rules to build the Tasks Queue.

Architecture: The Three Layered Model Tasks Queue Creation Layer Tasks Queue Execution Layer Plug-in Layer

Rules Simulation Rule is defined for each OPM entity and for each simulation event. For instance, there is a rule for object’s instance creation and its deletion. An activated rule determines the Simulation Tasks to be executed and the set of next Rules to be scheduled. For each rule there is a class implementing its functionality.

Process Activation Rule Example Activation Conditions: The elements linked to the process with one of the following links should be active - Instrument link. Condition link. … Consequent Rules: Process termination will be scheduled t time units after its activation time, where t – is the process execution time. Elements linked to the process with Consumption link will be deactivated. … Consequent Tasks: The process will be painted. Elements linked to the process with Result link will be painted progressively. …

Evaluation Experiment Group BGroup A Analysis with the simulation environment assistance Static (manual) analysisSystem Model 1 Static (manual) analysisAnalysis with the simulation environment assistance System Model 2 Two OPM models were prepared for two different example systems. The systems are very similar in their size and complexity. Structural and behavioral errors were inserted intentionally to the OPM models. Two groups of students were asked to find all the errors in the two models. Each group analyzed one system using solely static set of the model diagrams, and another system using simulation tool. Following table describes the experiment setup

Evaluation Results (1) Group of 98 students made the experiments in pairs (49 pairs). The experience of this group with OPM and system modeling is average. Structural errors found (max = 5) Behavioral errors found (max = 5) Static (manual) analysis Analysis with the OPCAT simulation environment

Evaluation Results (2) The students were also asked to give their general impression about helpfulness of the tool. The average mark is 4.81 on a 1-7 scale. PT < Behavioral aspect < Structural aspect Paired t-test results. N =49 pairs, 98 students.

Summary Through the research visual dynamic model inspecting with OPM model-based simulation environment was developed. Results gathered using two experiments carried out on a large group of students confirmed the efficiency of the proposed solution. Although the proposed solution is OPM-oriented, the architecture and attitude could be reused to implement simulation engines for other MLs