Reliability information databases and feasibility

within accelerator community

Heinrich Humer (AIT Austrian Institute of Technology)
Alexander Preinerstorfer (AIT Austrian Institute of Technology)
Johannes Gutleber (CERN)
Arto Niemi (CERN)
Klaus Höppner (HIT Heidelberg)

1
Contents
• Motivation
• Current status on reliability data collection in accelerator facilities
• Open Reliability information system for accelerators
• Requirements for a prototype implementation
• Roles and Use Cases
• Data model – Information structure
• Prototype implementation
• Conclusion

2
Motivation
• Reliability and maintenance Oil & Gas Nuclear energy
data are vital to analyse and
improve system performance
• Generating credible statistics
is a long term activity OREDA & ISO 14224 Reliability data sharing standard
ISO 6527
In various industries collected Wind energy Fusion power
reliability data is shared to
ease the burden
• Could the same work in
accelerator community?
Sparta (UK) & WInD- ENEA Fusion component
Pool (Germany) reliability DB

3
Situation today at CERN
• Failure data is recorded in various data Accelerator Fault
Tracking
sources for various purposes

combining operation & expert system data

Source Intended to provide

AFT aims for high level, unified view by

Logbooks Operational information for
subsequent shifts
Excel Specialized information for an
spreadsheets individual data collector
Maintenance Failure information for the unit
databases that maintains the system
Accelerator fault High level statistics and failure
tracking information

• Generally: Not intended for reliability data

sharing between organisations

4
Open Reliability information system for accelerators

• Based on ISO 14224 and ISO 6527 Historical Fault tracking,

Logbooks,
industry standards records
Observations,
Estimates
• Data users see:
• Own organisation’s uploaded data Handbooks,
Data initiatives
• Generalized statistics of shared data Information
System

• Data privacy & ownership never changes:

• Only anonymized statistics are shared PDF(characteristics, quality, conditions)

• Users can decide from which systems Model driven

statistics are collected

Design and improvement

5
What anonymized sub-system statistics are?
Using the anonymized OREDA Example: Taxonomy to identify the sub-system
statistics requires Population size & length
• Coherent taxonomy to of the observation period
identify a sub-system
• Measure of data credibility

Environmental conditions are

important for accelerators:
• Level of radiation
• Is the equipment located
indoors or outdoors
Failure modes Failure rates & repair times
with confidence bounds
6
Requirements for a prototype implementation
• An open infrastructure for Reliability data
• Cloud-Solution
• Support for many organisations (either in cooperation or in competition)
• Privacy areas of equipment data, maintenance data and event data
• Central administration of the taxonomy for equipment type
• Distributed maintenance of organisations (users, rights) and installations
• Common usage of statistical reports
• Quality management for data

7
Roles or Actors
• External User
• Registered User
• Information user
• Equipment Data Provider
• Quality Manager
• Equipment Type Editor
• Equipment Taxonomy Editor
• Reliability Data importer
• Global Admin
• Organisational Admin

8
Equipment units versus Equipment group
• Holder of statistics on „Objects of interest“

• Equipment unit:
• specific equipment (instance) within an equipment class as defined by its
boundary, identified by a serial number given by organisation
• Equipment units can exist as spare part or can be installed at a specific
location.
• Equipment group:
• Collection of equipment units with same properties descriped as group, not
as single instances
• They exist without reference to an installation location.

9
Use Cases for Equipment data provider
• Equipment Data Provider
• Insert an equipment unit
• Bulk insert of eq.units
• Edit equipment unit
• Insert an equipment group
• Bulk insert of equipment groups
• Edit equipment group
• Change privacy of own euipment
units/groups

10
Use Cases for Information user
• Information user
• Search (Lookup) of equipment
units or equipment groups
• Use statistic data on unit or group
• Use event data
• Uses merged equipment group
statistic data
• Gives feedback of usability

• Quality manager
• Add quality annotation for
contribution

11
Use Cases for Admin Usages
• User Administration Usage
• Classical administration of
organisation, users and roles
• Global / Local administration
• Taxonomy Admin
• Administration of taxonomy
structure

• Reliability Data importer

• Importer for external maintenance
databases
• Importer for Event Logs

12
Classification Taxonomy modification
ISO 14224 - Petroleum, petrochemical and natural gas industries - Collection and exchange of reliability and
maintenance data for equipment

Replaced by:
- Organisation
- Installation
- Location/Sublocation

Alternative access by class hierarchy:

- Equipment class
- Subclasses ….
- Equipment types

Part: Currently not used

13
Information at which level
ISO 14224 - Petroleum, petrochemical and natural gas industries - Collection and exchange of reliability and
maintenance data for equipment

14
Data model – Information structure
• Equipment class - class of similar type of equipment units (e.g. all pumps)
• Structure element to build up a hierarchy
• No Meta information
• Equipment type - particular feature of the design which is significantly different from the other
design(s) within the same equipment class
• Enables the construction of a type hierarchy for an equipment class
• Name, Description
• Boundery definition
• Operating states (def. Taxonomy)
• Failure modes (def. Taxonomy)
• Subunits
• Maintainable items

15
Example: 1:1 Translation of the OREDA concept

Example: „ISO-14224-2016.pdf“, p.77ff

16
Equipment type specific data
dm Equipment structure

EQ_EQUIPMENT_TYPE

«column» +EQ_EQUIPMENT_TYPE_PK
*PK EQ_TYPE_ID: NUMBER(0)
EQ_TYPE_NAME: VARCHAR2(50 CHAR)
ICON: VARCHAR2(50 CHAR)
FK CLASS_ID: NUMBER(0) +EQ_EQUIPMENT_TYPE_SUBTYPE_FK
MANUFACT_MODEL_NR: VARCHAR2(50 CHAR)
BOUNDARY_DEFINITION: CLOB
FK PARENT_TYPE_ID: NUMBER(0)
+EQ_EQUIPMENT_TYPE_PK OPERATING_STATE_TAXO_ID: NUMBER(0) +EQ_EQUIPMENT_TYPE_PK
FAILURE_MODE_TAXO_ID: NUMBER(0)

+EQ_EQUIPMENT_TYPE_PK
+EQ_EQUIPMENT_GROUP_TYP_FK

EQ_TYPE_PROPERTY_DEF
EQ_EQUIPMENT_GROUP +EQ_TYPE_PROPERTY_TYPE_FK
«column»
«column» *PK PROP_TYPE_ID: NUMBER(0)
*PK EQG_ID: NUMBER(0) PROP_TYPE_NAME: VARCHAR2(50)
FK EQ_TYPE_ID: NUMBER(0) *FK EQ_TYPE_ID: NUMBER(0)
FK ORG_ID: NUMBER(0) EQ_EQUIPMENT_PROPERTIES BASETYPE: VARCHAR2(10)
+EQ_TYPE_PROPERTY_DEF_PK
MANUFACT_NAME: VARCHAR2(50) DESCRIPTION: VARCHAR2(512)
MANUFACT_MODEL_NR: VARCHAR2(50) «column» LOV_PARAMS: VARCHAR2(512)
+EQ_EQUIPMENT_GROUP_PK *PK PROP_ID: NUMBER(0) UNIT: VARCHAR2(32)
DESCRIPTION: VARCHAR2(2000)
+EQ_EQUIPMENT_UNIT_TYPE_FK PRIVAT: VARCHAR2(1) *FK EQ_ID: NUMBER(0) PRIORITY: NUMBER(0)
CREATED_DATE: DATE FK EQG_ID: NUMBER(0) +EQ_EQUIPMENT_PROPS_PROPDEF_FK
+EQ_EQUIPMENT_PROPS_EQGRP_FK
CRETAED_BY: NUMBER(0) *FK PROP_TYPE_ID: NUMBER(0)
LAST_MODIFIED_DATE: DATE VALUE_STR: VARCHAR2(512)
LAST_MODIFIED_BY: NUMBER(0) VALUE_INT: NUMBER(0)
VALUE_FLOAT: FLOAT(50)
CONDITION_TIID: NUMBER(0)
EQ_EQUIPMENT_UNIT
PRIVAT: VARCHAR2(1)
+EQ_EQUIPMENT_UNIT_PK +EQ_EQUIPMENT_PROPS_EQUNIT_FK STATUS: VARCHAR2(1)
«column»
CREATED_DATE: DATE
*PK EQ_ID: NUMBER(0)
CREATED_BY: NUMBER(0)
EQ_IDENTIFICATION: VARCHAR2(50)
LAST_MODIFIED_DATE: DATE
FK ORG_ID: NUMBER(0)
LAST_MODIFIED_BY: NUMBER(0)
EQ_DESCRIPTION: VARCHAR2(2000)
FK EQ_TYPE_ID: NUMBER(0)
FK LOCATION_ID: NUMBER(0)
MANUFACTURER_NAME: VARCHAR2(256)
MANUFACTURER_MODEL_ID: VARCHAR2(50)
PRIVAT: VARCHAR2(1)
CREATED_DATE: DATE
CREATED_BY: NUMBER(0)
LAST_MODIFIED_DATE: DATE
LAST_MODIFIED_BY: NUMBER(0)

17
Example:

18
Equipment Units - Location
• Organisation defines installation and location
dm Equipment structure

AD_INSTALLATION

«col umn»
*PK INSTALLATION_ID: NUMBER(0)

structure
* INSTALLATION_NAME: VARCHAR2(132 CHAR)
LOCATION: VARCHAR2(4000 CHAR)
URL: VARCHAR2(132 CHAR)
COUNTRY: VARCHAR2(2 CHAR)
ADRESS1: VARCHAR2(132 CHAR)
ADRESS2: VARCHAR2(132 CHAR)

•
POST CODE: VARCHAR2(10 CHAR)

Each Equipment Unit can be associated

CIT Y: VARCHAR2(132 CHAR)
TYPE_OF_INSTALLATION: VARCHAR2(10 CHAR)
FK ORG_ID: NUMBER(0)

to one location of the organisation

+AD_ORGANISATION_PK

+FK_LocationClass_InInstallation
+AD_LOCATION_PK

•
AD_LOCATION

„Spare parts“ are kept at the «col umn»

*pfK LOCATION_ID: NUMBER(0)
+AD_LOCATION_PARENT_FK

LOCATION_NAME: VARCHAR2(50 CHAR)

LOCATION_GEOMETRY: SDO_GEOMETRY
ORG_ID: NUMBER(0)

„spare parts“ location.

FK INSTALLATION_ID: NUMBER(0)
SUB_LOCATION_OF: NUMBER(0)

+AD_LOCATION_PK

+EQ_EQUIPMENT_UNIT_LOC_FK

EQ_EQUIPMENT_UNIT

«column»
*PK EQ_ID: NUMBER(0)
EQ_IDENTIFICATION: VARCHAR2(50)
FK ORG_ID: NUMBER(0)
EQ_DESCRIPTION: VARCHAR2(2000)
FK EQ_TYPE_ID: NUMBER(0)
FK LOCATION_ID: NUMBER(0)
MANUFACTURER_NAME: VARCHAR2(256)
MANUFACTURER_MODEL_ID: VARCHAR2(50)
PRIVAT: VARCHAR2(1)
CREATED_DATE: DATE
CREATED_BY: NUMBER(0)
LAST_MODIFIED_DATE: DATE
LAST_MODIFIED_BY: NUMBER(0)

19
Reliability statistic data

dmEquipment structure

EQ_EQUIPMENT_GROUP

«column»
*PK EQG_ID: NUMBER(0)
FK EQ_TYPE_ID: NUMBER(0)
FK ORG_ID: NUMBER(0)
MANUFACT_NAME: VARCHAR2(50)
MANUFACT_MODEL_NR: VARCHAR2(50)
DESCRIPTION: VARCHAR2(2000)
PRIVAT: VARCHAR2(1)
CREATED_DATE: DATE
CRETAED_BY: NUMBER(0)
LAST_MODIFIED_DATE: DATE
LAST_MODIFIED_BY: NUMBER(0)

EQ_EQUIPMENT_UNIT

«column»
*PK EQ_ID: NUMBER(0)
EQ_IDENTIFICATION: VARCHAR2(50)
FK ORG_ID: NUMBER(0)
EQ_DESCRIPTION: VARCHAR2(2000)
FK EQ_TYPE_ID: NUMBER(0)
FK LOCATION_ID: NUMBER(0)
MANUFACTURER_NAME: VARCHAR2(256)
MANUFACTURER_MODEL_ID: VARCHAR2(50)
PRIVAT: VARCHAR2(1)
CREATED_DATE: DATE
CREATED_BY: NUMBER(0)
LAST_MODIFIED_DATE: DATE
LAST_MODIFIED_BY: NUMBER(0)
+EQ_EQUIPMENT_GROUP_PK
+FK_ReliabilityS_EquipmentGr_01
+EQ_EQUIPMENT_UNIT_PK
RELIABILITY_STAT_DATA
«column»
*PK RS_ID: NUMBER(0)
FK EQG_ID: NUMBER(0)
FK EQ_ID: NUMBER(0)
+RELIABILITY_STAT_DATA_EQGRP_FK CONDITION_TIID: NUMBER(0)
CALENDAR_TIME_MIO_HRS: NUMBER(0)
OPERATION_TIME_MIO_HRS: NUMBER(0)
TOTAL_NR_COMPONENTS: NUMBER(0)
NUMBER_OF_DEMANDS: NUMBER(0)
PRIVAT: VARCHAR2(1)
STATUS: VARCHAR2(1)
CREATED_DATE: DATE
CREATED_BY: NUMBER(0)
LAST_MODIFIED_DATE: DATE
LAST_MODIFIED_BY: NUMBER(0)
SOURCE_TYPE: VARCHAR2(1CHAR)
SOURCE_REFERENCE: VARCHAR2(132CHAR)
RELIABILITY_STAT_DATA_MODE
«column»
*pfKRS_ID: NUMBER(0)
*PK FAIULRE_MODE_TIID: NUMBER(0)
TOTAL_NR_FAILURES: NUMBER(0)
FAILURE_RATE1_OBSERVED: NUMBER(0)
+FK_ReliabilityS_Reliability_01 FAILURE_RATE1_LO: NUMBER(0)
+RELIABILITY_STAT_DATA_PK FAILURE_RATE1_UP: NUMBER(0)
FAILURE_RATE2_LO: NUMBER(0)
FAILURE_RATE2_UP: NUMBER(0)
FAILURE_RATE2_OBSERVED: NUMBER(0)
UNAVAILABILITY_TIME_HRS: NUMBER(0)
MTTR_HRS: NUMBER(0)
MTTR_LO_HRS: NUMBER(0)
MTTR_HI_HRS: NUMBER(0)

20
Implementation prototype
• Cloud solution:
• Oracle database
• Tomcat-Service,
• REST-interface, Swagger
• Angular Client
• HTTP
• Typescript

21
Evaluation site: HIT Heidelberg

Evaluation of the usability of the selected design

Feedback should improve the data model

Open problem:
- Taxonomy of the Equipment class hierarchy
MUST be INDEPENDENT of INSTALLATION
- Improvements of usability are open

Missing functionalities:
- Quality management processes
- Calculation of group statistics

22
Conclusion
• Reliability data sharing concept has worked &
provided value in various industries
• First prototype of an implementation has been built
up, but currently not with full functionality
• Implementation is not a technical challenge, real
limiting factor are the personnel resources to collect
the reliability data.

23