Visual Dynamic Model Inspecting with OPM Model-Based Simulation Environment

1. Visual Dynamic Model Inspecting with OPM Model-Based Simulation Environment Yevgeny Yaroker, Valeria Perelman, Prof. Dov Dori 16 July 2014

2. 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

3. 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

4. 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) • …

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

6. 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

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

8. 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

9. 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 Procedural links Connect objects to objects Connect objects to processes Structural Links Consumption Generalization- Specialization Aggregation- Participation Result Effect Classification- Instantiation Exhibition- Characterization Agent Instrument Uni- and Bi-directional Tagged link object object

11. 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

12. 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

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

14. 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. Status Bar Main toolbar

15. 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.

16. 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.

17. 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.

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

19. 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.

20. 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. • …

21. Evaluation Experiment • 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

22. 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.

23. Evaluation Results (2) • Paired t-test results. N =49 pairs, 98 students. • 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.

24. 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