WO2022174130A1 - Procédés d'analyse de mesures de capteurs de série chronologique dans des systèmes physiques - Google Patents

Procédés d'analyse de mesures de capteurs de série chronologique dans des systèmes physiques Download PDF

Info

Publication number
WO2022174130A1
WO2022174130A1 PCT/US2022/016267 US2022016267W WO2022174130A1 WO 2022174130 A1 WO2022174130 A1 WO 2022174130A1 US 2022016267 W US2022016267 W US 2022016267W WO 2022174130 A1 WO2022174130 A1 WO 2022174130A1
Authority
WO
WIPO (PCT)
Prior art keywords
stream
model
sensor
sensor data
physics
Prior art date
Application number
PCT/US2022/016267
Other languages
English (en)
Inventor
Jonathan L. Herlocker
Adam Ashenfelter
Steven HERCHAK
Original Assignee
Tignis, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US17/175,688 external-priority patent/US11630820B2/en
Application filed by Tignis, Inc. filed Critical Tignis, Inc.
Publication of WO2022174130A1 publication Critical patent/WO2022174130A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2365—Ensuring data consistency and integrity
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F17/00—Digital computing or data processing equipment or methods, specially adapted for specific functions
    • G06F17/40—Data acquisition and logging
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B23/00—Testing or monitoring of control systems or parts thereof
    • G05B23/02—Electric testing or monitoring
    • G05B23/0205—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults
    • G05B23/0218—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterised by the fault detection method dealing with either existing or incipient faults
    • G05B23/0243—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterised by the fault detection method dealing with either existing or incipient faults model based detection method, e.g. first-principles knowledge model
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3065—Monitoring arrangements determined by the means or processing involved in reporting the monitored data
    • G06F11/3072—Monitoring arrangements determined by the means or processing involved in reporting the monitored data where the reporting involves data filtering, e.g. pattern matching, time or event triggered, adaptive or policy-based reporting
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466—Performance evaluation by tracing or monitoring

Definitions

  • the present invention relates generally to methods for monitoring and analysis of physical systems.
  • a digital twin for a physical system captures two distinct types of information.
  • the relationships between physical devices e.g., pumps, fans, filters, cooling coils
  • the relationships between physical devices may be captured with a graph database.
  • Data from sensors attached to the physical devices may be captured with a time-series database.
  • the invention provides a method for analyzing time series data of a physical system, the method comprising: a) storing a process graph representing the physical system, wherein nodes of the process graph represent devices of the physical system and l edges of the process graph represent causal physical influences between the devices, wherein the devices comprise physical assets and sensors, where the sensors are configured to measure physical quantities; b) storing physics rules representing relations between quantities; c) storing a set of physics models, wherein each of the physics models comprises a physics rule selected from the stored physics rules and an assignment of quantities of the physics rule to properties of the physical system; d) storing sensor time series data, wherein the sensor time series data comprises: i) a sequence of values of a physical quantity measured by one of the sensors paired with ii) a corresponding sequence of times when the values of the sequence of values were measured; e) retrieving sensor data streams from the time series data, wherein each of the sensor data streams comprises a sequence of time-value pairs, wherein each of the sensor data streams
  • the method may also include defining a machine learning model stream by specifying a type of machine learning model, a training data stream, a time window, and a period; and applying the machine learning model stream to data streams to produce a model output metric data stream.
  • Defining a machine learning model stream may include specifying model parameters, feature engineering parameters, and/or model lifecycle parameters.
  • the method may also include determining a support value for the training data stream, where the support value is indicative of the fraction of missing values in the training data stream; and determining whether the support value exceeds a predetermined threshold.
  • the machine learning model may be a model selected from the group consisting of linear regression, isolation forests, lightweight on-line detector of anomalies, logistic regression, random forests, and gradient-boosted trees.
  • the method may also include producing from the sensor data streams interval streams, and/or key-value pairs of metadata.
  • the properties of the physical system may comprise physical properties derived from a set of sensor nodes of the process graph, or statistical properties derived from a set of sensor nodes of the process graph.
  • the relations between quantities may be relations between measurable physical quantities, or relations between quantities derived from measurable physical quantities.
  • the method may also include storing the set of physics models comprises using a dynamic data model that provides a user-customizable view of the physics models and physics rules.
  • Fig. 1 is a flow chart illustrating the steps of a method for monitoring and analyzing a physical system according to an embodiment of the invention.
  • Fig. 2 is schematic diagram illustrating a data processing pipeline for a method for monitoring and analyzing a physical system according to an embodiment of the invention.
  • Fig. 3A and Fig. 3B show a schematic process diagram of a physical system and a corresponding process graph, respectively, according to an embodiment of the invention.
  • Fig. 1 is a flow chart illustrating the steps of a method for analysis of time series data in a physical system according to an embodiment of the invention.
  • a system process graph 102 that represents the physical system is stored in a memory.
  • the graph includes a collection of nodes connected by directed edges, where distinct nodes represent distinct devices of the physical system, and where edges represent causal physical influences between the devices.
  • the devices include assets that perform actions in the physical system and sensors that measure physical quantities in the physical system.
  • a system process graph may also include information such as physical dimensions of process variables and other metadata associated with nodes and edges.
  • a complete process graph contains a node for every transforming process of the system, and an edge for every physical connection or causal relation of the system. In addition, it may also include nodes for sensors that are not associated directly with an asset or transforming process.
  • a process graph is typically derived from a system process diagram which provides a visual schematic representation of the system, such as an engineering schematic.
  • a system process graph is typically created by a subject matter expert based on a system process diagram; the process graph is constructed to contain all physical connections or causal relations as edges and all transforming processes as distinct nodes.
  • the process graph may be created by an automatic transformation of a process diagram using image recognition techniques. For example, starting with an image of a system process diagram, standard image recognition techniques may be used to generate a list of all named entities (equipment and sensors) in the image. Then a trained neural network can recognize in the image standardized schematic icons and generate an itemized list of entities and their types, as well as connections between them.
  • the identified entities are matched with the names, for example, based on proximity of bounding boxes entities and names in the image.
  • This matching could take into account standard conventions for positioning names next to their corresponding schematic icons, e.g., placement of names more frequently above and to the left of the icon than below and to the right.
  • Fig. 3A is an illustrative example of a process diagram of a physical refrigeration system that includes various assets such as power supply 300, fan 304, evaporator 306, and compressor 308.
  • the system also includes various sensors such as voltage meter 302.
  • Fig. 3B is a process graph corresponding to the refrigeration system process diagram of Fig. 3A, where the assets are represented by square nodes and the sensors are represented by round nodes. The directed edges of the graph correspond to electrical or fluidic connections between the assets.
  • nodes 310, 314, 316, 318 represent assets 300, 304, 306, 308, respectively
  • node 312 represents sensor 302.
  • the edge from node 310 to node 314 represents the electrical connection from power supply 300 to fan 304
  • the edge from node 314 to node 316 represents the fluidic connection (i.e., air blowing) from fan 304 to evaporator 306
  • the edge from node 316 to node 318 represents the fluidic connection (i.e., flow of refrigerant) from evaporator 306 to compressor 308.
  • the process graph thus provides an abstract representation of the devices in the physical system and their causal physical relationships.
  • the stored process graph also includes physical dimensions (e.g., time, length, mass) and units (e.g., seconds, meters, kilograms) associated with each sensor node.
  • a physics rule library 100 is stored in memory.
  • a physics rule specifies a general mathematical relationship (e.g., function) between quantities. They may be defined in a domain-specific language or in code. Each rule specifies a mathematical relationship between multiple variables. Although some physics rules may represent laws of physics relating physical quantities, physics rules in general may represent relationships between physical or non-physical quantities.
  • the variables is a physics rule represent quantities that are directly or indirectly related to physical quantities measured by the system sensors. Some variables may directly represent physical quantities, in which case the physical dimensions and units of each variable may be specified.
  • the conservation of mass rule for steady-state flow specifies that the mass flow rate (kg-s _1 ) into and out of any device must be equal
  • Some variables may be indirectly related to physical quantities.
  • variables in a rule may represent statistics of one or more physical quantities or scores derived from physical quantities.
  • the physics rule library preferably contains a collection of universal rules that are commonly applicable to portions of industrial systems and plants.
  • the physics model may be viewed as a specific instantiation of a physics rule, where the variables of the physics rule are instantiated as localized process variables at particular sensors or other quantities.
  • a physics model thus allows values in data streams from particular sensors, or values in derived data streams, to be related to each other through computation according to the model.
  • the physics rules may, more generally, also include arbitrary computations on data streams, such as computing statistical properties of values in a sensor data stream.
  • a physics rule may be instantiated as physics models relating quantities derived indirectly from physical quantities. For example, a physics rule could be instantiated to compute a health score of an asset, a predicted time to failure of an asset, or a count of assets of a particular type.
  • Sensor data 106 from the physical system is retrieved from a data store.
  • the sensor data includes values of physical quantities measured by the sensors of the physical system.
  • the sensor data may include, for each sensor, a time-indexed sequence of numerical values of the physical quantity measured by the sensor.
  • the sensor data includes time-indexed values of measured process variables for the system, called a sensor data stream.
  • the time-indices represent times separated by a fixed period, corresponding to the inverse of the sensor sampling rate.
  • Data from different sensors may be stored at different sampling rates, resulting in different periods.
  • the resulting sensor data stream may represent a sub-sampled data stream within a time window specified for example by start and end times.
  • the fetched sensor data stream may be live, very recent data, or historical data.
  • the sensor data 206 originate at the physical system 200 which includes assets 202 and sensors 204.
  • the sensor measurement data 206 is then transmitted to sensor data storage 208 (e.g., cloud storage).
  • sensor data storage 208 e.g., cloud storage
  • portions of sensor data are extracted from the storage and transmitted as sensor data streams 220 to a processor 216 that performs analysis and monitoring computations.
  • the processor 216 uses the sensor data streams 220, physics rule library 214, and system graph 212 derived from system process flow diagram 210 to produce one or more metric data streams 218.
  • Processor 216 may be implemented by a master orchestrator which starts a job for each model for each process graph, where a job may be local thread or an entire cloud hosted machine. The job fetches its necessary sensor data streams 220 from a local or cloud time series database 208.
  • step 110 the sensor data streams 106 that were retrieved from the data store are automatically synchronized and upsampled, if needed, to ensure that they have the same period and starting times.
  • the resulting synchronized and resampled sensor data streams 112 are then used in step 114 to perform a point-wise computation using a physics model 108 to produce a resulting metric data stream 116.
  • the most common type of stream is a metric data stream, defined as a sequence of time, value pairs, where the values are either numeric or categorical.
  • a stream may contain missing values, i.e., some values may be null.
  • the period of a stream may be provided as an input when defining the stream or may be determined automatically by inspecting the first pairs of a stream, or it may be missing if no regular period is found.
  • a stream may be either synchronized or unsynchronized.
  • a stream has a finite sequence of time, value pairs within a time window defined by a starting time and ending time.
  • a sensor data stream is retrieved or fetched from a time series sensor data store.
  • the data store could be represented as CSV files, a time series database, or accessed through a cloud service.
  • the time series data for a particular sensor can be identified in a time series database query by specifying a unique sensor entity ID and name of a physical quantity measured by the sensor (note that a sensor may measure multiple physical quantities) .
  • each stream fetched from the time series database is referred to by some unique stream ID, allowing a caching layer to be implemented on top of the fetch.
  • caching is preferably implemented by storing segments of a stream.
  • a stream cache query expects a unique ID (or key) and a start and end range. If the cache has all or part of the range available, it will return that portion of the stream. For the portion of the interval that was missing the stream is fetched (or calculated/trained in the case of non-metric streams) according to the producer function.
  • the cache may be built using interval trees, segment trees, or other data structures as long as the interface allows queries over a range.
  • the stream cache may be advantageously combined with other hashes of stream computations. Whenever an operation takes place on a metric stream, the existing hash (or id) of the stream is combined with parameters defining the operation to produce a new unique hash (or id) . These hashes are created when transforming any stream type (metrics, rows, models), and encapsulate everything that makes that stream unique. This allows the stream caching mechanism to be applied to all stream types and allows caching of intermediate states of computations. If final or intermediate stream computations are found in the stream cache then the evaluation may use them, skipping expensive recently performed computations such as re-building models or fetching their supporting metric streams.
  • the cache may exist in local memory or it may be a cloud service. This may be customized according to the stream type. So, a metric stream may be cached in local memory while the more expensive model streams may be cached by a cloud service. Synchronizing and Resampling Streams
  • a time series fill may be used to interpolate between pre-existing values of the stream in one of two methods. Filled in points may either use linear interpolation or a fill- forward approach where the last known value is repeated. The default is fill-forward as linear interpolation may not be computable when the next data point is not yet available (e.g., real-time scenarios).
  • the simplest type of stream computations is uniformly performing point-wise arithmetic operations on values of a metric stream to produce a new metric stream.
  • Stream computations may also combine multiple streams to produce a new stream by performing point-wise functions of values of the streams. If the streams are not already synchronized, they will be automatically synchronized using the process described earlier so that the point-wise computation is well-defined.
  • fluidPower flow * pressure
  • logic operations values are treated as false when they are null (have missing values), and the ‘or’ will return the point-wise value from the first metric stream that is true, while ‘and’ will return the value from the last metric when both are true.
  • Stream operations can also include point-wise functions such as mean and max: mean(FLOWl, FLOW2, FLOW3) max(FLOWl, FLOW2)
  • the period of the resulting stream of a stream operation can be specified. max(FLOWl, FLOW2) per lh
  • the duration of the window of the resulting stream can also be specified: mean(FLOW) over lh
  • Window operations produce a single value from all the values of one or more streams within a specified window. Examples of window operations are as follows: count: The number of non-missing values in the stream support: The count of non-missing values divided by the total count sum: The sum of the non-missing values. mean: The mean of the non-missing values min: The minimum of the non-missing values max: The maximum of the non-missing values spread: The difference between the max and the min. mode: The most common non-missing value median: Median of the non-missing values. quantile: The desired quantile (extra parameter) over the non-missing values.
  • Stream operations over windows may not produce desired results if one or both streams contain missing values, due to sensor data reporting gaps.
  • parameters may be specified for the operation to filter results according to a condition that a minimum number (count) of values is present in the input stream: mean(PRESSURE) over lh when(count > 5)
  • This provides a way to throw out aggregations that might not be trustworthy due to missing values.
  • the count depends on the period of the underlying input stream.
  • the operation may be filtered depending on the ratio of the count of non missing values to the total number of values in the window, called the support. This allows expressive filters that are not dependent on the period. For example, this operation would only produce a mean pressure value when the pressure sensor stream has non-missing values for at least half of the values during an hour: mean(PRESSURE) over lh when(support > 0.5)
  • Streams are sequences of (time, value) pairs.
  • the type of value determines the type of the stream:
  • Metric The value is numeric or categorical.
  • - Row The value is a list of numeric or categorical values. List length cannot change.
  • the value is a model that meets the model interface described later below.
  • a row stream can be constructed by specifying multiple metric streams as an input. At each point in the resulting stream, the value is a list of values from the corresponding points of the input metric streams. Each input metric stream is automatically synchronized as needed. A period may be specified for the resulting row stream:
  • FlowPressureData row(FLOW, PRESSURE) per 30m
  • Row streams of the same type can be interleaved to merge the data. For example, flow and pressure row streams from three sensors can be merged to form a single row stream whose points have a list value including six quantities.
  • FlowPressData interleave(FlowPressDatal, FlowPressData2, FlowPressData3)
  • the period of the new interleaved stream will be autodetected if not specified.
  • Row streams may be used to build machine learning models over data derived from multiple entities.
  • the model operation takes as input a stream of rows, an optional stream of metrics, and optional parameters.
  • the result is a stream of models.
  • Each point in a model stream is a machine learning model.
  • a model in this case, is built given a set or rows and can also accept a row and produce a score, such as the case when ‘apply" is used, as described below.
  • each point in a model stream is a model
  • each such model is not necessarily stored.
  • the information required to build any of the models in the stream is stored and used on demand as needed.
  • the operation can optionally take a metric stream to use as the objective (or target) for supervised machine learning models.
  • Various other machine learning models may be used, including isolation forests, lightweight on-line detector of anomalies, logistic regression, random forests, and gradient-boosted trees.
  • Machine learning models should adhere to the following abstractions.
  • a model is buildable given a seed value, a sequence of rows, an optional set of parameters, and for supervised models a sequence of target metrics.
  • a seed is provided for models that use a stochastic process during construction.
  • a “build’ always produces the exact same model given the same inputs. apply(model, row, params?)
  • the models produced with “build’ support an “apply” where the model produces either a numeric or categorical value given a single row and optional parameters.
  • An unsupervised anomaly detection model may produce numeric anomaly scores when applied.
  • a supervised decision tree model may produce a categorical prediction when applied.
  • Some models can produce a variety of information when applied to a row. For instance, a decision tree might produce a categorical prediction for the most likely class, or it might produce a numeric estimate of the probability for a particular class. The optional parameters allow the output of the apply to be customized.
  • the apply operation takes as input a stream of models and a stream of rows. It applies the most recent model in the model stream to each row in the row stream to produce a result metric stream.
  • This result stream may be, for example, anomaly scores for anomaly detection models or predictions for predictive models.
  • the result stream will have a period matching the row stream.
  • the ‘ensemble’ operation takes a stream of models as input and produces a new stream of models as a result. All the models that occur within the ensemble’s ‘over’ period will be used to create a new meta-model. These meta-models are the models that appear in the resulting model stream. When applying the meta-model to a row the results of the underlying models will be combined. For regression models the default aggregation is ‘mean’ while for classification models the default is ‘mode’.
  • the ‘ensemble’ method helps model streams to evolve more smoothly. Models no longer replace one another whole cloth as time progresses, instead the ensemble’s meta-model changes incrementally as individual models move into and out of the window.
  • model construction and storage reduce to a caching problem.
  • a regression model might collect the mean squared error over the training data.
  • model attributes are represented as metric streams. This is a powerful way to explore how a model stream changes over time.
  • one model attribute is the training mean squared error of a logistic regression model. The stream of this attribute represents how the model evolves over time and can be used to highlight periods when the error becomes concerning.
  • Digital twin query language introduces a flexible way to both capture and perform optimizations over conditional parameter search spaces (using techniques such as bayesian optimization) .
  • the parameters need not be limited to model parameters but may include feature engineering parameters or model lifecycle parameters (such as the size of training set and the frequency of retraining) .
  • the following DTQL rules define building a kernel ridge linear regression model to predict pump power based on pump speed and flow.
  • the speed sensor data is smoothed over six hours using a median.
  • a mean squared error is computed from the predictions over a specific time interval. This will be a scalar value which a DTQL user can mark as the optimization target to minimize.
  • a DTQL user may substitute any constant with a list of possible parameters to search.
  • the user could optimize a feature engineering parameter by searching over the size of the smoothing window for speed.
  • a search list may include entire expressions. Those expressions may contain their own search lists. This allows DTQL to search conditional parameter spaces.
  • DTQL can define model streams (as discussed above), a user can also search over model lifecycle parameters such as the size of the training window or the frequency of retraining. Building on the previous example, the DTQL user chooses to also search over the possible training windows sized between 2 to 8 weeks.
  • the DTQL system allows a user to optimize parameters anywhere in a machine learning workflow.
  • DTQL relies on a data source (such as an external database) to inform it of which entities exist and their related features.
  • a data source such as an external database
  • the set of all known entities and their features (which can include relationships between entities) is considered the ‘data model’.
  • the external data source provides a baseline of the data model
  • DTQL allows users to modify the data model without changing the underlying data source.
  • the following DTQL ruleset targets an entity defined by the external datasource.
  • This entity is a pump with an attached ‘FLOW’ sensor and a relationship to another pump (‘DOWNSTREAM’).
  • a DTQL user defines a new relationship to another pump (‘UPSTREAM’) and defines two new metric features (‘UPSTREAM DIFF’ and ‘DOWNSTREAM DIFF’) .
  • UPSTREAM entity (‘pump234’) ;
  • UPSTREAM DIFF UPSTREAM:FLOW - FLOW; return UPSTREAM, UPSTREAM DIFF, DOWNSTREAM DIFF;
  • each DTQL has the ability to modify that data model as needed without impacting other DTQL users or their pre-existing rulesets.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Mathematical Physics (AREA)
  • Software Systems (AREA)
  • Automation & Control Theory (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Testing Or Calibration Of Command Recording Devices (AREA)

Abstract

Un procédé d'analyse de données de capteur de série chronologique d'un système physique représenté par un graphe de processus récupère des flux de données de capteur à partir de données de série chronologique de capteur stockées [106]. Chacun des flux de données de capteur comprend une séquence de paires de valeurs temporelles et est associé à un identifiant de capteur, un décalage temporel et une période d'échantillonnage. Un flux de données métriques est produit à partir des flux de données de capteur récupérés conformément à un modèle physique stocké du système physique. La production du flux de données métriques comprend i) la synchronisation [110] des flux de données de capteur par ajustement des décalages temporels des flux de données de capteur et l'ajout de valeurs interpolées et de temps aux flux de données de capteur pour produire des flux synchronisés [112] avec des périodes d'échantillonnage égales ; et ii) la réalisation d'un calcul par points [114] sur des valeurs des flux de données de capteur conformément au modèle physique.
PCT/US2022/016267 2021-02-14 2022-02-14 Procédés d'analyse de mesures de capteurs de série chronologique dans des systèmes physiques WO2022174130A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US17/175,688 US11630820B2 (en) 2019-12-17 2021-02-14 Analysis of time series sensor measurements in physical systems
US17/175,688 2021-02-14

Publications (1)

Publication Number Publication Date
WO2022174130A1 true WO2022174130A1 (fr) 2022-08-18

Family

ID=82801393

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2022/016267 WO2022174130A1 (fr) 2021-02-14 2022-02-14 Procédés d'analyse de mesures de capteurs de série chronologique dans des systèmes physiques

Country Status (1)

Country Link
WO (1) WO2022174130A1 (fr)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020139347A1 (fr) * 2018-12-27 2020-07-02 Halliburton Energy Services, Inc. Révisions en temps réel de planification de chantier de fracturation hydraulique utilisant des données de caractéristiques de réponse détectées

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020139347A1 (fr) * 2018-12-27 2020-07-02 Halliburton Energy Services, Inc. Révisions en temps réel de planification de chantier de fracturation hydraulique utilisant des données de caractéristiques de réponse détectées

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
RAI, R. ET AL.: "Driven by Data or Derived Through Physics? A Review of Hybrid Physics Guided Machine Learning Techniques with Cyber-Physical System (CPS) Focus", IEEE ACCESS, vol. 8, 28 April 2020 (2020-04-28) - 29 April 2022 (2022-04-29), pages 71050 - 71073, XP011785620, Retrieved from the Internet <URL:https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=9064519> DOI: 10.1109/ACCESS.2020.2987324 *
YANG, F. ET AL.: "Capturing Connectivity and Causality in Complex Industrial Processes. Springer Briefs in Applied Sciences and Technology", SPRINGER SCIENCE & BUSINESS MEDIA, 26 March 2014 (2014-03-26) - 3 May 2022 (2022-05-03), pages 3, XP055963179, Retrieved from the Internet <URL:https://www.researchgate.net/publication/262918711_Capturing_Connectivity_and_Causality_in_Complex-industdalProcesses/link/53flea8f0cf2bc0c40e6ed65/download> *

Similar Documents

Publication Publication Date Title
US11308250B2 (en) Learning expected operational behavior of machines from generic definitions and past behavior
US20230394052A1 (en) Building management system with declarative views of timeseries data
CN105144112B (zh) Java堆使用的季节趋势、预报、异常检测和端点预测
Cugola et al. Introducing uncertainty in complex event processing: model, implementation, and validation
JP6068468B2 (ja) 予測及び予知のための逐次的カーネル回帰モデリング方法
US20180137424A1 (en) Methods and systems for identifying gaps in predictive model ontology
US9152918B1 (en) Resource forecasting using Bayesian model reduction
CN107408226A (zh) 资产健康评分及其使用
Hu et al. Automated structural defects diagnosis in underground transportation tunnels using semantic technologies
JP2018128855A (ja) イベント解析装置、イベント解析システム、イベント解析方法、イベント解析プログラム、および記録媒体
JP2014524094A (ja) パターン・シーケンスを持つカーネル回帰モデリングを用いる監視システム
CN105593864B (zh) 用于维护设备的分析设备退化
JP2014032657A (ja) 異常検知方法及びその装置
Ehrlinger et al. Automated Data Quality Monitoring.
Cózar et al. An application of dynamic Bayesian networks to condition monitoring and fault prediction in a sensored system: A case study
Liu et al. Enhancing veracity of IoT generated big data in decision making
CN117194919A (zh) 一种生产数据分析系统
CN117235524A (zh) 自动估值模型的学习训练平台
Jin et al. Bayesian hierarchical model for change point detection in multivariate sequences
US11630820B2 (en) Analysis of time series sensor measurements in physical systems
WO2022174130A1 (fr) Procédés d&#39;analyse de mesures de capteurs de série chronologique dans des systèmes physiques
US20230349608A1 (en) Anomaly detection for refrigeration systems
Patri et al. Predicting compressor valve failures from multi-sensor data
Xiao et al. Building information modeling and building automation systems data integration and big data analytics for building energy management
CN110275875B (zh) 用于为工业基础设施提供经实例化的工业语义模型的方法和装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22753479

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 22753479

Country of ref document: EP

Kind code of ref document: A1