CS/ECE 541 - Computer Systems Analysis Möbius Introduction Ken Keefe - 9/26/2014 http://goo.gl/CzJ2TW

Talk Outline Motivation The Möbius Framework The Möbius Tool Möbius Models Fault Trees Rep/Join Performance Variables Set Study Flat State Space/Symbolic State Space Generators Analytical Solvers Example Demo - Car System Getting Möbius Homework Assignment #2 Discussion Conclusion

Challenges of Modeling Complex Systems Dealing with many levels of abstraction in system models E.g., when modeling complex cyber-physical systems, one must represent models at many levels Need structured models able to represent system subcomponents in a composable way Need way to decompose models and solve parts separately Modeling many different types of system components May need multiple model representations Solving many types of models with differing assumptions and characteristics May need multiple model solution methods Challenging to support solution of extremely large and stiff models in both simulation and analytic/numerical solution: State space largeness (largeness) Large time scale differences in event rates (stiffness)

Möbius Framework C++ Libraries Abstract base classes for building and executing models (blue) Formalisms define formalism specific base classes that inherit from the abstract base classes and are included in the Mobius framework (orange) C++ representation of models in a formalism are classes that inherit from the formalism base classes (green) Möbius AFI Model-Level AFI State Variables and Actions State-Level AFI BaseAtomicModel BaseAction BaseSANModel SANActivity ProcSANModel CPUFailureActivity

Möbius Tool Java front-end for Graphically defining models Generating C++ code representations Building executable models Executing the models Reporting, storing, and visualizing results Atomic Editors Composer Editors Reward Editor Study Editor Atomic Object Code Reward Object Code Study Object Code Comp. Object Code Linker Formalism Libraries Solver Libraries Executable Model

Möbius Models Overview Study Reward Composed Atomics Composed Transformer Simulator Analytical Solver

Fault Trees Fault trees consist of the following primitives: Node - State variable representing failure state of the system. > 0 is a failure Event - Action that fires only once and represents failure of a system component And - Failure is passed if all children fail Or - Failure is passed if at least one child fails Xor - Failure is passed if exactly one child fails KofN - Failure is passed if at least K children fail PriorityAnd - Failure is passed if the children fail in the order specified by the gate Fault trees typically have a single node at the top that represents system failure, several events that are leaves in the tree and represent component failures, and a set of logic gates that build the tree structure and defines what component failures must exist before the system fails.

Rep/Join Rep/Join is a state sharing composed formalism. The three primitives are: Models These can be either atomic models or other composed models Cycles are not allowed Join nodes Join nodes define a set of shared variables that are joined across the child models and nodes Shared variables must all have the same type and initial value Rep nodes Rep nodes define a set of identical replicas and a set of shared variables across those replicas

Performance Variables A performance variable model contains a set of performance variables that are used to define measures of the system model. Each performance variable defines: A reward function (either) A rate reward function which is fired and aggregated based on the timing information A set of impulse reward functions which are each tied to an event in the system. When the event fires, the impulse reward function fires. Timing information (instant of time, interval of time, time averaged interval, etc.) Simulation information: Whether to calculate mean, variance, interval, or distribution The required confidence interval for the performance variable to converge to before simulation may halt.

Set Study Studies are used to vary initial model parameters. Global variables are defined in an atomic, composed, or reward model. Global variables can be used in any C++ expression box, e.g. the rate of an event in a fault tree can be some function of one or more global variables Studies then define a set of experiments with values for each global variable defined earlier The set study allows the sets of experiments to be defined one by one manually. The range study allows sets of experiments to be defined by expressing a range of values for each global variable. Every executable model must have a study defined. If there are no global variables, the study is simply empty.

State Space Generators State Space Generators must be executed before an analytical solver is executed. The simulator does not require an SSG. The Flat SSG builds a set of possible states and table of transitions between those states. The Symbolic SSG builds Multi-valued Decision Diagrams (MDDs) for the possible states, Matrix Diagrams (MDs) for the transitions, and Multi-Terminal MDDs (MTMDDs) for the performance variable values in each state. (Derisavi 05) Analytical solvers can use either representation of the CTMCs to evaluate the model. The Flat SSG can build a state space several orders of magnitude larger than the Symbolic SSG and uses significantly more disk space to store the data structures it generates. However, analytical solvers will run dramatically faster because the data structures are easier to read in an work with. The Symbolic SSG uses much less disk space and leverages several state lumping techniques to decompose the state space and can produce a state space size several orders of magnitude smaller than the Flat SSG. However, solvers can run significantly slower on the output of the symbolic SSG.

Solvers Simulator can execute any well formed model, but provides inaccurate results and typically takes longer. Analytical solvers can only solve certain classes of models (CTMCs) and require a state space to be generated first, but provide precise results.

Example Demo - Car Car has two systems Wheels 4 independent tires that each fail with a rate of 2.0 E -7 Engine Engine can overheat (rate of 6.3 E -6) or blow a head gasket (rate of 5.5 E -5) Car fails if either system fails Wheels fail if one tire fails Engine fails if it overheats and blows a head gasket Rates above are per hour. Determine the 90 day reliability of the car (2160 hours)

Getting Möbius Available on Windows 7-8, OSX 10.8-10.9, and Ubuntu Linux 13.10-14.04 Visit https://www.mobius.illinois.edu/createAccount.php Once approved, visit https://www.mobius.illinois.edu/wiki/index.php/Installation

Homework #3 Build a model of a reliable web server using: A fault tree model of one part of the web server Define a performance variable for the reliability of this component Calculate the mean by hand and compare it to the result you get from Möbius Define the remaining components of the web server Define a Rep/Join model to compose the components together Execute the system model and collect results Use Möbius’ built in documentation feature to document your work Due on Wednesday, October 8. Give yourself plenty of time to download, install, and work out the kinks. My office is CSL 225 My email is kjkeefe@illinois.edu Bugs and problems: dev@mobius.illinois.edu When you email me for help, be sure to send a minimal archive of your model!

Conclusion http://goo.gl/CzJ2TW