FP7-ICT-2013.1.3
Grimstad, Norway , 08.06.2015
CBM, Big Data and the Proactive EnterpriseRiglogger™, Proasense, Prognostics and Health Management
Dr. Ing Tor I. Waag, MHWirth
MHWirth in Brief
June 9, 2015 2
Global Reach
June 9, 2015 3
Equipment on ~500 rigs 4 Regions | 4300 employees
One Company
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
Powerful Collaboration
Key Figures 2014
Revenue NOK 10 681 mill
EBITDA NOK 941 mill
Margin 8.8%
Note: Preliminary unaudited pro form figures
June 9, 2015 4
Our Products and Services
June 9, 2015 5
How our Drilling Equipment drives change
Drilling Equipment
June 9, 2015 6
Drilling, Make and Break
June 9, 2015 7
Uninterrupted drilling operations and high performance - Our drilling, make and break equipment is a powerful collaborator during drilling operations.
Content
June 9, 2015 8
Riglogger™
PHM
Proasense
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
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
Proasense
An IT project in the EU 7th Framework Program Real time acquisition, on-the-fly analytics and long term
storage of industrial Big Data Valuable for evaluation of Performance Maintenance Incidents
Definitions
Condition Monitoring Condition Based Maintenance Prognostics Proactivity
Definition: Condition Monitoring
“Activity, performed either manually or automatically, intended to observe the actual state of an item.”Definitions [BS 13306]
CM is a source of information, monitoring the state of equipment
Definition: Condition Based Maintenance
”Preventive maintenance based on performance and/or parameter monitoring and the subsequent actions.”Definitions [BS 13306]
CBM is a maintenance strategy
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
Definition: Prognostics
The art and science of making scientifically sound, observation based predictions
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
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
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
Detection of change
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)
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.
Proasense, the OODA cycle
Observe (sensor input, event detection) Orient (complex event processing) Decide (probabilistic decision support) Act (notification, or automatic feedback)
Data input
Event detection
criteria
Event detectionComplex event
processing
Analyse dynamic
behaviour
Offline analytics:Establish
normal rangeof behaviour
Online analytics:Detection of change
(slow, rapid)
ActDecideCost functions
24
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)
ProaSense Objectives (1-3)
25
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
ProaSense Objectives, continued
26
Sensing Architecture Layer
Data Infra-structure
Enterprise data adapter
Business context data adapter
User-provided input
Sensing Architecture LayerSoftware SensorsHardware Sensors Human Sensors
Historian adapter
CSV files Legacy system(s)Historian
External systemsOSIsoft PI
(MHWirth)HYDRA MES
(HELLA) MHWirth HELLAOpen Historian
ChallengeThe design of the architecture will be in the spirit of “Big Data” supporting three major dimensions when dealing with intensive streaming data, namely: • Volume (scale of data being processed), • Velocity (speed of moving data and optimized reaction time), and • Variety (supporting heterogeneous types to data under consideration).
State of the art analysis Internet of Things (IoT) platforms that support the registration and management of heterogeneous sensors and their data, providing APIs and data aggregation.• Commercial solutions: Xively , NanoService, TempoDB• Open source solutions: Nimbits, ThingSpeak, 52° North SOS , SensApp, ThingML
Approach • Process/filter data as close to the sensors as possible• Virtual sensors that optimize sensor data acquisition by filtering raw
sensor data, e.g. data cleaning, sampling frequency, merging sensor data, and simple calculations.
• Using common standards and semantics (e.g. SSN ontology) to precisely specify structure/context of sensor data
28
PrognosticsMarkov and stochastic processes
29
Markov Decision Process Parameters of the method, general
Markov Decision ProcessProbability Distribution of the occurrence of the eventParameters of the probability distribution
Input from events
Actionsai
Costs Cai (tai)
Delays δai
Cost of undesired
event Cu
Optimal action
Optimal time of action
Input from user
Output
Cost Matrix / Optimisation and (Probabilistic) RulesParameters of the method
Cost MatrixAnd
Probabilistic Rules
Corrective Maintenance
Cost Cc
Planned Maintenance
Cost Cp
Planned Time for
Maintenance
Optimal Time for Maintenance
Input from events
Input from user
Output
Predicted time of undesired event
• 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.
Complex Event Processing
Sensors
Applications
Processes
Notifications
ActionsEven
t Pr
oduc
ers
Even
t Co
nsum
ers
Event Processing Network
Relevant Situations
Humans
33
• 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
Modeling Distributed Complex Event Processing PipelinesObjectives
Example: Sensor Transformation Pipeline
Sensor #1
Filter bythreshold value
Enrich withcontextualknowledge
Performpattern
detection
DecisionManagement
Event Stream
34
Motivation: Technical HeterogeneityIntegration of heterogeneous technical landscapes
Sensor #1
Filter bythreshold value
Enrich withcontextualknowledge
Performpattern
detection
DecisionManagement
35
Motivation: Technical HeterogeneityDistributed processing
Source EPA EPA EPA
Source
Source
Source EPA
EPA
EPA
EPA
EPA
EPA
Consumer
Consumer
Consumer
36
Motivation: Technical HeterogeneityDifferent stream processing technologies depending on the purpose/data frequency
Source Storm Online Analytics
Online Analytics
Source
Source
Source Spark
Online Analytics
CEP Engine
CEP Engine
Storm
CEP Engine
Consumer
Consumer
Consumer
37
Motivation: Technical HeterogeneityMultiple protocols on the event transportation layer
Source Storm Algorithm Algorithm
Source
Source
Source Spark
Algorithm
CEP Engine
CEP Engine
Storm
CEP Engine
Consumer
Consumer
Consumer
MQTT
MQTT
JMS
Kafka
Kafka
MQTT
Websocket
Websocket
JMS
AMQP
38
ChallengeEnd-To-End Modelling of distributed stream processing pipelines
Source Storm Algorithm Algorithm
Source
Source
Source Spark
Algorithm
CEP Engine
CEP Engine
Storm
CEP Engine
Consumer
Consumer
Consumer
MQTT
MQTT
JMS
Kafka
Kafka
MQTT
Websocket
Websocket
JMS
AMQP
39
Copyright and DisclaimerCopyrightCopyright 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.
DisclaimerThis 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.
mhwirth.com
Generic Proactive Maintenance
Generic model from literature (e.g. Muller et al. 2008)
Proactive Maintenance and OODAIn ProaSense
ObserveSense –
Proactivemonitoring of real time data
Decide – based on predictionsOrient – detect
a deviation and predict future
system performance
ACT –(i) Action taken at the
operational level (since this is the maintenance
process);(ii) Provide feedback to the
strategic processes of the organisation.
• 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.
Layers of ComplexityData analytics
44
• 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.
Data Storage
45
• 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.
Preparation/Preprocessing/Concentration
46
• 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.
Data Processing
47
• 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?
Decision Making
48
Motivation: ReusabilityExample: Esper Event Processing Language
insert into Filtered select value, timestamp, type, location from Sensor1
insert into Enrichedselect a.value, b.value, compute(a.type, b.type, timestamp) as enrichedDatafrom Filtered.win:time(30 min)
insert into SomethingHappens select a.value, b.value, a.variableTypefrom pattern [every a=Enriched -> b=Enriched whereb.value > a.value * 120 where timer:within(20 secs)];
Sensor #1
Filter bythreshold value
Enrich withcontextualknowledge
Performpattern
detection
DecisionManagement
49
Motivation: ReusabilityExample: Sensor failure, required modifications
insert into FilteredS2 selectobservation, timestamp, sensorId, lat, lng from Sensor2
insert into FilteredS2 select a.observation, b.observation, a.sensorIdfrom pattern [every a=FilteredS2 -> b=FilteredS2where b.value > a.value * 120 wheretimer:within(30 secs)];
Sensor #2
Filter bythreshold value
Performpattern
detection
DecisionManagement
Steps required- register new event types- pattern adaptations
Reusing patterns in case of replacement of sensors or required adaptations of patterns requireshigh manual effort
50
Motivation: Technical HeterogeneityAbstract view: Event Processing Network
Sensor EPA EPA EPA EPA
51