Principles to define table format for definition and

Principles to define table format for definition and management of models in reliability engineering Arto Niemi Acknowledgements: J-P Penttinen, J. Gutleber

Contents • • Motivation and general requirements Concepts • • • Classes Folders Connections Attributes Common ground for collaboration 6/16/2021 Document reference 3

Motivation • • Collaborations need a common database to store models Systems with repeating elements* require clever ways to define models format is a “UI” ELMAS independent way to store models to future proof long term accessibility Tabular format is good for databases and can fulfil these requirements *e. g. PSB RF model by O. Orozco: https: //cdsweb. cern. ch/record/2207497 6/16/2021 Document reference 4

Complex Case: • • • Circular colliders availability for luminosity production* Requires reliability and operations modelling Model consists of coupled fault trees, Markov chains and functions Year schedule Machin e studies Physics Cycl production e Year schedule Technical stop e Accelerator Complex Phase dependent failures rates and repairs *For more details: https: //doi. org/10. 1103/Phys. Rev. Accel. Beams. 19. 121003 6/16/2021 Document reference 5

Approach • • Cover numerous different model types Remain open for future cases es s e r T ree t l u T Fa ault F v o k r Ma ains Ch ility b lia ams e R gr Dia tri e P ts Ne 6/16/2021 nt e Ev es Tre ns o i t nc u F Document reference 6

Generally: We want to store and define diagram based models in tables: Fault trees 6/16/2021 Document reference 7

Generally: We want to store and define diagram based models in tables: Reliability block diagrams 6/16/2021 Document reference 8

Generally: We want to store and define diagram based models in tables: Event trees 6/16/2021 Document reference 9

Generally: We want to store and define diagram based models in tables: Markov Chains Active state moves in chain 6/16/2021 Document reference 10

Generally: We want to store and define diagram based models in tables: Petri-nets Tokens move in net 6/16/2021 Document reference 11

Generally: We want to store and define diagram based models in tables: Functions 6/16/2021 Document reference 12

…and models that combine these elements 6/16/2021 Document reference 13

Drivers Leads to a small Information needed to define a model: number of tables (<5) 1. What elements in the model? 2. Contained by which other elements? 3. How many elements? 4. How are elements connected? 5. Which attributes do they have? 6/16/2021 Document reference 14

Concept 1: Classes & Instances • • • Elements of different “kinds” (= classes) called “instances” Classes govern what attributes an element has, and how it behaves and how it appears in the model Classes need to be defined 6/16/2021 Classes & Inheritance • Nodes • • Operators • • Fault nodes, Markov states, Petri-net places… AND, OR, Transfers… Inheritance for special cases (e. g. failure that requires access) Document reference 15

Concept 2: Collections To ease re-use and handle growing models (scale-free) 6/16/2021 Document reference 16

Example: Collection definition folder Collection definition Instances • Changes in this definition will affect all instances of this assembly • Definitions can be rewritten for specific instances 6/16/2021 Document reference 17

Concept 3: Connections Elements can connect to multiple other elements -> calls for separate table Connections Example: Safety system Fault in every connection No alarm False signal form any connection False alarm Purpose of the example is to clarify the concept. In practice, component failure rates for these two cases 6/16/2021 would likely be different. Document reference AND OR 18

Concept 4: Attributes Failure rates, Repair times. . Functions 6/16/2021 Document reference 19

Concept 4: Attributes Failure rates, Repair times. . Functions 6/16/2021 Simulation parameters: • How many rounds? • Studied duration • Sensitivity analyses? • Result handling Document reference 20

Concept 4: Attributes Failure rates, Repair times. . Functions Meta data: Who did the model? When? Released? 6/16/2021 Simulation parameters: • How many rounds? • Studied time period • Sensitivity analyses? • Result handling Document reference 21

Concept 4: Attributes Failure rates, Repair times. . Functions Meta data: Who did the model? When? Released? Simulation parameters: • How many rounds? • Studied time period • Sensitivity analyses? • Result handling Visual properties 6/16/2021 Document reference 22

Concept 4: Attributes Failure rates, Repair times. . Functions Meta data: Who did the model? When? Released? Simulation parameters: • How many rounds? • Studied time period • Sensitivity analyses? • Result handling Visual properties User defined properties 6/16/2021 Document reference 23

Concept 4: Attributes Failure rates, Repair times. . Functions Meta data: Who did the model? When? Released? Visual properties User defined properties 6/16/2021 Simulation parameters: • How many rounds? • Studied time period • Sensitivity analyses? • Result handling Aim for flexibility both on what and how information is stored: Numbers, SQL queries, links… Document reference 24

Common ground for collaboration How developments coexist? conversion “Team Arto” ELMAS Format ? 1 “Team Odei” Format 6/16/2021 2 ? Benefits: • Clear common vocabulary • Good requirements coverage • Consistent implementation • Eventually sharing of models to reduce workload Document reference 25