CBM, Big Data and the Proactive Enterprise

Transcription

1 CBM, Big Data and the Proactive Enterprise Riglogger, Proasense, Prognostics and Health Management Grimstad, Norway, Dr. Ing Tor I. Waag, MHWirth FP7-ICT

2 MHWirth in Brief June 9,

3 Global Reach Equipment on ~500 rigs 4 Regions 4300 employees One Company June 9,

4 Powerful Collaboration Key Figures 2014 Revenue NOK mill EBITDA NOK 941 mill Margin 8.8% Note: Preliminary unaudited pro form figures World-class solutions, lifecycle services and advanced drilling systems for onshore and offshore drilling units, world wide We go beyond the conventional drilling solution to provide our customers with the safer, more efficient and reliable alternative Today more than 500 floaters, jack-ups and fixed installations operate in the market with our equipment June 9,

5 Our Products and Services June 9,

6 Drilling Equipment How our Drilling Equipment drives change June 9,

7 Drilling, Make and Break Uninterrupted drilling operations and high performance - Our drilling, make and break equipment is a powerful collaborator during drilling operations. June 9,

8 Content Riglogger PHM Proasense June 9,

9 Riglogger An IT infrastructure built by MHWirth AS (previously Aker Solutions) Real time acquisition, on-the-fly analytics and long term storage of all available, drilling related variables on oil platforms Valuable for evaluation of Performance Maintenance Incidents

10 Prognostics and Health Management, PHM An internal MHWirth project Real time acquisition, on-the-fly analytics and long term storage of industrial Big Data Valuable for evaluation of condition and planning of Maintenance Reduction of Product Lifecycle Cost Opportunistic instead of Calendar based Maintenance

11 Proasense An IT project in the EU 7 th Framework Program Real time acquisition, on-the-fly analytics and long term storage of industrial Big Data Valuable for evaluation of Performance Maintenance Incidents

12 Definitions Condition Monitoring Condition Based Maintenance Prognostics Proactivity

13 Definition: Condition Monitoring CM is a source of information, monitoring the state of equipment Activity, performed either manually or automatically, intended to observe the actual state of an item. Definitions [BS 13306]

14 Definition: Condition Based Maintenance CBM is a maintenance strategy Preventive maintenance based on performance and/or parameter monitoring and the subsequent actions. Definitions [BS 13306]

15 Definition: Condition Based Maintenance CBM consists of all these activities: Data acquisition and management Analysis Interpretation Fault detection Diagnosis Prognosis and prediction Decision-making Planning and performance of maintenance actions Ref: Al-Najjar 2007b, in E-maintenance, by Kenneth Holmberg, Adam Adgar, Aitor Arnaiz, Erkki Jantunen, Julien Mascolo, Samir Mekid

16 Definition: Prognostics The art and science of making scientifically sound, observation based predictions

17 Definition: Proactivity The art and science of making scientifically sound recommendations or automatic actions based upon prognostics Includes probability distribution function based, automatically calculated recommendations to act Includes predicted cost and gains of several possible actions to choose between Also includes the cost of delay, important in our business

18 Detection of change The art and science of detecting changes to a process variable Departure from a constant to an increasing value Change from a constant to another constant value Change from one speed to another speed Chance from a linear function to a non-linear (accelerating) function

19 Detection of change, contd. Detection of all of the previous taking into account: (e.g. as probabilistic cost functions ) The cost of missed detections The cost of false alarms Set appropriate thresholds in terms of standard deviations σ for level or slope, balancing A and B The cost of delay Averaging reduces standard deviation σ Averaging delays detection by the number of samples included in the averaging Computational cost not trivial for thousands of variables or combinations of variables

20 Detection of change

21 Proasense vs other methods Drilling vs steady state production Event based data flow Event detection Complex event processing Detection of change Probabilistic decision making Automatic action (or notification to act, cannot interfere in critical, remote operations)

22 Proasense, the OODA cycle The phrase OODA loop refers to the decision cycle of observe, orient, decide, and act, developed by military strategist and USAF Colonel John Boyd. Boyd applied the concept to the combat operations process, often at the strategic level in military operations. It is now also often applied to understand commercial operations and learning processes.

23 Proasense, the OODA cycle Observe (sensor input, event detection) Orient (complex event processing) Decide (probabilistic decision support) Act (notification, or automatic feedback)

24 Data input Event detection criteria Offline analytics: Establish normal range of behaviour Event detection Complex event processing Analyse dynamic behaviour Online analytics: Detection of change (slow, rapid) Cost functions Decide Act 24

25 ProaSense Objectives (1-3) Understanding of the importance and benefits of the proactive behavior in an enterprise context To enable comprehensive observation of the relevant business context/ecosystem (Observe) To enable semantic understanding of sensed information (Orient) 25

26 ProaSense Objectives, continued Making decisions ahead of time (Decide) Proactive handling for sustainable business improvements (Act) Demonstrate the efficiency and added business value Disseminate results in the wider research and industry community 26

27 Sensing Architecture Layer Challenge Approach The design of the architecture will Process/filter State be in the spirit data of the of as Big close art analysis Data to the supporting sensors three as possible major dimensions Internet when of Things dealing (IoT) Virtual with platforms intensive sensors that streaming that support optimize the data, registration sensor namely: data and acquisition management by filtering of raw heterogeneous sensors and their data, providing APIs and data aggregation. Volume (scale of data being sensor processed), data, e.g. data cleaning, sampling frequency, merging sensor Commercial solutions: data, and Xively simple, NanoService, calculations. TempoDB Velocity (speed of moving data and optimized reaction time), and Open source solutions: Using common Nimbits, ThingSpeak, standards and 52 semantics North SOS (e.g., SensApp, SSN ontology) ThingML to Variety (supporting heterogeneous precisely types specify to data structure/context under consideration). of sensor data Sensing Architecture Layer Historian adapter Hardware Sensors Data Infrastructure Enterprise data adapter Software Sensors Business context data adapter Human Sensors User-provided input Historian CSV files Legacy system(s) OSIsoft PI (MHWirth) HYDRA MES (HELLA) Open Historian MHWirth HELLA External systems 28

28 Prognostics Markov and stochastic processes 29

29 Markov Decision Process Parameters of the method, general Input from events Actions ai Input from user Costs Cai (tai) Delays δai Cost of undesired event Cu Output Probability Distribution of the occurrence of the event Parameters of the probability distribution Markov Decision Process Optimal action Optimal time of action

30 Cost Matrix / Optimisation and (Probabilistic) Rules Parameters of the method Input from user Input from events Corrective Maintenance Cost Cc Planned Maintenance Cost Cp Planned Time for Maintenance Output Predicted time of undesired event Cost Matrix And Probabilistic Rules Optimal Time for Maintenance If there are more than one possible action, the same procedure can be followed for each action and then, the action which minimizes the generalized cost is selected. Probabilistic Rules can be used to express company s policies regarding maintenance when there is uncertainty about a decision.

31

32 Complex Event Processing Sensors Event Producers Applications Humans Event Processing Network Notifications Actions Event Consumers Processes Relevant Situations 33

33 Modeling Distributed Complex Event Processing Pipelines Objectives Processing pipelines: Integration of streams, real-time processing logic and consumers Fast pipeline definition and modification should be possible without further implementation effort for non-technical users Example: Sensor Transformation Pipeline Sensor #1 Filter by threshold value Enrich with contextual knowledge Perform pattern detection Decision Management Event Stream 34

34 Motivation: Technical Heterogeneity Integration of heterogeneous technical landscapes Sensor #1 Filter by threshold value Enrich with contextual knowledge Perform pattern detection Decision Management 35

35 Motivation: Technical Heterogeneity Distributed processing Source EPA EPA Cons umer Source EPA EPA EPA Cons umer Source EPA EPA EPA Source EPA Cons umer 36

36 Motivation: Technical Heterogeneity Different stream processing technologies depending on the purpose/data frequency Source Spark CEP Engine Cons umer Source Storm Online Analytics Online Analytics Cons umer Source Online Analytics Storm CEP Engine Source CEP Engine Cons umer 37

37 Motivation: Technical Heterogeneity Multiple protocols on the event transportation layer Source Kafka Spark MQTT CEP Engine Webso cket Cons umer JMS Source Storm Algorithm Algorithm Cons umer Kafka MQTT AMQP Source Algorithm MQTT Storm Source JMS CEP Engine CEP Engine Webso cket Cons umer 38

38 Challenge End-To-End Modelling of distributed stream processing pipelines Source Kafka Spark MQTT CEP Engine Webso cket Cons umer JMS Source Storm Algorithm Algorithm Cons umer Kafka MQTT AMQP Source Algorithm MQTT Storm Source JMS CEP Engine CEP Engine Webso cket Cons umer 39

39 Copyright and Disclaimer Copyright Copyright of all published material including photographs, drawings and images in this document remains vested in MHWirth and third party contributors as appropriate. Accordingly, neither the whole nor any part of this document shall be reproduced in any form nor used in any manner without express prior permission and applicable acknowledgements. No trademark, copyright or other notice shall be altered or removed from any reproduction. Disclaimer This Presentation includes and is based, inter alia, on forward-looking information and statements that are subject to risks and uncertainties that could cause actual results to differ. These statements and this Presentation are based on current expectations, estimates and projections about global economic conditions, the economic conditions of the regions and industries that are major markets for MHWirth AS and MHWirth AS (including subsidiaries and affiliates) lines of business. These expectations, estimates and projections are generally identifiable by statements containing words such as expects, believes, estimates or similar expressions. Important factors that could cause actual results to differ materially from those expectations include, among others, economic and market conditions in the geographic areas and industries that are or will be major markets for MHWirth s businesses, oil prices, market acceptance of new products and services, changes in governmental regulations, interest rates, fluctuations in currency exchange rates and such other factors as may be discussed from time to time in the Presentation. Although MHWirth AS believes that its expectations and the Presentation are based upon reasonable assumptions, it can give no assurance that those expectations will be achieved or that the actual results will be as set out in the Presentation. MHWirth AS is making no representation or warranty, expressed or implied, as to the accuracy, reliability or completeness of the Presentation, and neither MHWirth AS nor any of its directors, officers or employees will have any liability to you or any other persons resulting from your use. MHWirth consists of many legally independent entities, constituting their own separate identities. MHWirth is used as the common brand or trade mark for most of these entities. In this presentation we may sometimes use MHWirth, we or us when we refer to MHWirth companies in general or where no useful purpose is served by identifying any particular MHWirth company.

40 mhwirth.com

41 Generic Proactive Maintenance Generic model from literature (e.g. Muller et al. 2008)

42 Proactive Maintenance and OODA In ProaSense Observe Sense Proactive monitoring of real time data Orient detect a deviation and predict future system performance Decide based on predictions ACT (i) Action taken at the operational level (since this is the maintenance process); (ii) Provide feedback to the strategic processes of the organisation.

43 Layers of Complexity Data analytics Data analytics for Condition Monitoring (CM) and Condition Based Maintenance (CBM) purposes can roughly be divided into four steps: Data storage Data preparation/ pre-processing/ concentration Data processing Decision making Each step of the cycle has to be configured to perform effectively to result in a reliable CBM system. The next slides will review the level of complexity of the process developing such systems in more detail. 44

44 Data Storage Ensure that relevant parameters are stored (iterative process). Configure data resolution per parameter to be sufficient to make use of the time series without storing excessive information. Nature of each parameter to be considered (Slow or rapid, high or low dynamic range, ). Define relevant context parameter from non-hardware sensors. 45

45 Preparation/Preprocessing/Concentration Decide which time periods are of most interest for a specific case. Define logic to isolate these periods of interest and configure the processing infrastructure accordingly. Define required variables relevant to include for the periods of interest to prepare for subsequent steps. 46

46 Data Processing Define input parameters, configuration of algorithm steps including necessary interim storage of results and finally the output parameters. Define trending requirements of the output parameter(s) Define realistic thresholds value(s) to compare the output parameters towards Examine the possibility to launch more advanced mathematical or physical models or methods to improve the results or the interpretation. 47

47 Decision Making Define the range of preventive or corrective actions that are relevant for the specific case. Define rules for when to act (thresholds or degradation) Define context data which can improve the confident in the decision findings (and move to step one) Configure possible optimization rules for which preventive or corrective actions is most suitable at what time. Define who is relevant to notify, when and how? 48

48 Motivation: Reusability Example: Esper Event Processing Language insert into Filtered select value, timestamp, type, location from Sensor1 insert into SomethingHappens select a.value, b.value, a.variabletype from pattern [every a=enriched -> b=enriched where b.value > a.value * 120 where timer:within(20 secs)]; Sensor #1 Filter by threshold value Enrich with contextual knowledge Perform pattern detection Decision Management insert into Enriched select a.value, b.value, compute(a.type, b.type, timestamp) as enricheddata from Filtered.win:time(30 min) 49

49 Motivation: Reusability Example: Sensor failure, required modifications insert into FilteredS2 select observation, timestamp, sensorid, lat, lng from Sensor2 insert into FilteredS2 select a.observation, b.observation, a.sensorid from pattern [every a=filtereds2 -> b=filtereds2 where b.value > a.value * 120 where timer:within(30 secs)]; Senso r #2 Filter by threshold value Perform pattern detection Decision Management Steps required - register new event types - pattern adaptations Reusing patterns in case of replacement of sensors or required adaptations of patterns requires high manual effort 50

50 Motivation: Technical Heterogeneity Abstract view: Event Processing Network Sensor EPA EPA EPA EPA 51