JP2019509565A - Handling prediction models based on asset location - Google Patents

Abstract

Disclosed is a computer architecture and software configured to change the handling of a predictive model by an asset monitoring system based on the location of the asset. Consistent with an exemplary embodiment, the asset monitoring system may maintain data indicating locations of interest as representing places where driving data from assets should be ignored. The asset monitoring system can determine whether the asset is within range of the location of interest. If yes, the asset monitoring system can ignore the operational data for the asset when dealing with predictive models for asset operation.

Description

  The present invention relates to the handling of prediction models made based on the location of assets.

CROSS REFERENCE TO RELATED APPLICATIONS This application is a priority of US patent application Ser. No. 15 / 064,878, filed Mar. 9, 2016 and not a provisional application entitled “Handling Prediction Models Based on Asset Location”. The entire application is incorporated by reference. This application also incorporates by reference the entirety of each of the following patent applications: US patent application Ser. No. 14 / 732,258, filed June 5, 2015, and not a provisional application entitled “Asset Health Score”. And US patent application Ser. No. 14 / 963,207 filed Dec. 8, 2015 and is not a provisional application entitled “Local analytics in assets”.

  Today, machines (hereinafter also referred to as “assets”) are ubiquitous in many industries. Assets play an important role in everyday life, whether they are locomotives that transport cargo between countries or construction equipment that supports the construction of houses and cities. Depending on the role the asset plays, its complexity and cost can vary. For example, some assets may include multiple subsystems that need to work in concert (eg, locomotive engines, transmissions, etc.) for the assets to function properly.

  Because assets play a major role in daily life, it is desirable for assets to have reparability and limited downtime. Thus, some assets have an advanced mechanism that monitors and detects abnormal conditions within the asset, thereby assisting asset repair and may minimize downtime.

US patent application Ser. No. 14 / 963,207

  Current methods of asset monitoring typically involve asset-loaded computers that receive driving data, which takes the appearance of signals from various sensors and / or actuators. And / or actuators are dispersed throughout the asset, and the sensors and / or actuators monitor the operational status of the asset. In one representative case, if the asset is a locomotive, the sensor and / or actuator may monitor parameters such as temperature, voltage, speed, etc., although there may be others. If the sensor and / or actuator signal from one or more of these devices reaches a certain value, the asset-mounted computer can generate an abnormal condition indicator, such as a “fault code”, that is in the asset Indicates that an abnormal condition has occurred.

  In general, an abnormal condition can be defective at an asset or at a component of the asset, which can cause failure of the asset and / or component. Thus, because an abnormal condition is symptomatic for a given fault or multiple faults, the abnormal condition can be associated with a given fault or possibly multiple faults. In practice, the user typically defines a sensor and each sensor value associated with each abnormal condition indicator. That is, the user defines the “normal” operating state (for example, a state in which a failure code is not activated) and an “abnormal” operating state (for example, a state in which a failure code is activated) of the asset.

  The asset-loaded computer can pass sensor data, actuator data, and / or abnormal condition indicator data to another computing system or device, which can perform further processing on such data. For example, a remote asset monitoring system may use specific data received from an asset as training data for defining (or modifying) a predictive model and / or as input data for executing a predictive model for an asset. Can be used. Additionally or alternatively, the local asset monitoring system can perform all or part of these data processing operations on the asset itself using specific asset data.

  In general, asset monitoring systems handle predictive models based on operational data for one or more assets while one or more assets are operating under real world conditions. That is, asset monitoring systems typically handle predictive models based on operational data that reflects how assets are functioning in the field. However, typically, the asset monitoring system will receive driving data for one or more assets without being aware of the driving context of the one or more assets. For example, an asset monitoring system may not know whether the operational data for an asset corresponds to a “typical” or “non-typical” context.

  Thus, in some cases, asset monitoring systems may receive uncertain data about the handling of predictive models without knowing about the asset. For example, an asset may reside in a repair shop / repair shop, where diagnostic assets and other problem-solving tools can be run on the asset, thereby making the asset representative It may output operation data that cannot be said. In another example, an asset may reside in a location that temporarily elicits a non-typical aspect of asset behavior, such as in a tunnel or some other enclosed area. Yes, where such assets may similarly output driving data that the asset is not representative of, which may distort the training, modification, and / or output of the predictive model. There may be other examples for non-representative contexts.

  Unfortunately, current asset monitoring systems typically receive asset operational data without knowing whether the data is representative of “normal” behavior, and predictive Not sure if the model can be used reliably in defining, modifying, and / or executing. In fact, current asset monitoring systems typically do not track which locations are associated with non-typical driving data such as repair shops and tunnels. As a result, current asset monitoring systems may unknowingly define, modify, and / or execute predictive models using uncertain operational data, which can lead to inaccurate models and / or model outputs. Other problems can also arise.

  The disclosed exemplary systems, devices, and methods are directed to addressing one or more of these issues. In an exemplary embodiment, one or more assets can communicate with one or more asset monitoring systems, which are remote in relation to one or more assets, or with at least one asset. You can be local in a relationship.

  As previously described, each asset can include multiple sensors and / or actuators distributed across the asset, which facilitate monitoring of the operational state of the asset. Some assets may provide each asset's operational status data to the asset monitoring system, and the system is configured to perform one or more actions based on the provided data. Can do.

  In an exemplary embodiment, the asset monitoring system may be configured to do the following: define one or more prediction models associated with the operation of the asset, and one or more predictions Operate according to the model. In general, each such predictive model can receive data from a particular asset as input, and at least one event of a predetermined group of events in the asset during a particular future period. Possible occurrences can be output. (Note that in the context of this disclosure, an “event group” can include both single events and multiple events.) In one particular case, the predictive model includes at least one fault. The likelihood that an event will occur in the asset during a specific future period may be output. Such a model is hereinafter also referred to as a “failure model”. As another example, a predictive model may predict the likelihood that an asset will complete a task in a future time period. There may be other examples of predictive models.

  In practice, a predictive model may be defined based on historical data for one or more assets. At a minimum, this historical data may include operational data that indicates the operational state of a given asset, including abnormal state data that identifies faulty instances that occurred in the asset and / or the time of those instances. Sensor / actuator data, etc., indicating one or more physical characteristics measured on the asset before and after.

  As mentioned above, it may not be desirable for a remote asset monitoring system (and / or a local asset monitoring system) to use asset operational data as usual, for example, in defining, modifying and / or executing a predictive model. obtain. An example of such a case is when the asset is placed in a repair workshop, tunnel, or other non-representative location, in which case the asset generates uncertain operational data. Tend.

  Thus, in an exemplary embodiment, the asset monitoring system can be configured to maintain data indicative of one or more locations of interest. In general, a location of interest represents a location where asset operational data is uncertain and may be considered to be ignored. Places of interest can be places where assets are tested or otherwise forced to operate in a non-typical manner (eg, asset repair shop / repair shop) or outside There may be other examples including a place (for example, in a tunnel) where the asset operation state temporarily shifts to a state that is not representative due to the situation.

  The asset monitoring system can be configured to maintain a location of interest in various ways. In an exemplary embodiment, the asset monitoring system can receive data indicating one or more locations of interest from another system or device. In such an embodiment, another system or device can be pre-involved in defining the location of interest and can provide the asset monitoring system with data indicating the location of interest that has been defined. .

  In other exemplary embodiments, an asset monitoring system holding a location of interest can involve the asset monitoring system itself in defining the location of interest, which can be done in various ways. it can. In one exemplary embodiment, the asset monitoring system may define locations of interest based on historical location data for multiple assets. For example, based on these data, the asset monitoring system identifies where the assets “crowd”, identifies certain additional asset-related information associated with the group, and these groups are also interested in It can be inferred that it corresponds to the location. There may be other examples of defining locations of interest.

  In any case, the asset monitoring system operates to use driving data for one or more assets in the context of a predictive model for driving the asset, while maintaining data indicating one or more locations of interest. Can be. While operating in this manner, the asset monitoring system can determine that location data for a particular asset of one or more assets matches one of the locations of interest.

  Based on the determination, the asset monitoring system can transition to the following operation mode: That is, when the asset monitoring system handles a predictive model related to the operation of the asset, the operation data for the specific asset is monitored. The mode of operation that the system ignores. For example, other examples are possible, but the asset monitoring system does not consider the driving data for a given asset received by the asset monitoring system after the decision, or corresponds to position data that matches the location of interest. Such a prediction model can be defined, modified, and / or executed without considering any of the operational data for a given asset. In this way, the asset monitoring system can ignore driving data for assets that may be in non-typical locations where the asset typically outputs uncertain data, thereby matching the predictive model. Consistency maintenance is done for other assets and / or for future prediction model execution for specific assets.

  Thus, according to one aspect, a method for handling driving data for an asset based on asset location data is disclosed, the method comprising a computing system that comprises the following steps: (i) Receiving position data for each of the plurality of assets; and (ii) determining whether the predetermined position data for the predetermined asset of the plurality of assets matches a location associated with uncertain driving data; , (Iii) in response to the decision, a step of deciding to ignore the driving data for a given asset in the case of handling a prediction model for driving a plurality of assets, and (iv) a step of handling the prediction model according to the decision.

  According to another aspect, a computing system is disclosed, the system comprising: (a) at least one processor; (b) a non-transitory computer readable medium; and (c) non-transitory. Program instructions stored on a computer readable medium that, when executed by at least one processor, cause a computing system to perform the functions disclosed herein, the functions based on asset location data Instructions on functions for handling driving data about.

  According to yet another aspect, a non-transitory computer readable medium having instructions stored thereon is disclosed, the instructions being executable by a processor, the instructions being executed by a computing system as disclosed herein. A non-transitory computer readable medium relating to a function for handling driving data for the asset based on the asset location data.

  Those skilled in the art will appreciate these and several other aspects by contacting the following disclosure.

FIG. 2 is a schematic diagram illustrating an example network configuration in which an example embodiment may be implemented. FIG. 6 is a simplified block diagram for an exemplary asset. It is the schematic which shows an example abnormal condition parameter | index and activation criteria. FIG. 3 is a simplified block diagram for an exemplary analysis platform. Figure 5 is an exemplary flow diagram for a definition stage that can be used to define a prediction model. 4 is an exemplary flow diagram for a modeling phase that can be used to define a predictive model that outputs a health metric. FIG. 3 is a schematic diagram of data used to define a model. 6 is a flow diagram illustrating an exemplary operation that may be used to ignore asset operational data. FIG. 6 is a schematic diagram of historical asset position data at a first time point. It is the schematic about the historical asset position data in the 2nd time. It is the schematic about the historical asset position data in the 3rd time. FIG. 6 is a schematic diagram of aggregate asset location data used to define a location of interest. It is a schematic diagram about aggregated asset position data and a defined part of interest. It is the schematic about the defined interest location and asset position data in the 4th time. It is the schematic about the defined interest location and asset position data in the 5th time. It is the schematic about the defined interest location and asset position data in the 6th time. 5 is a flow diagram for an exemplary method for handling operational data for an asset based on asset location data. 6 is a flow diagram for another exemplary method for handling operational data for an asset based on asset location data.

  The following disclosure refers to the accompanying drawings and some exemplary situations. Those skilled in the art will appreciate that such references are made for illustrative purposes only and are not intended to be limiting. All or part of the disclosed systems, devices, and methods may be rearranged, combined, added, and / or excluded in various ways, each of which is contemplated herein.

I. Exemplary Network Configuration Turning to FIG. 1, an exemplary network configuration 100 is shown and an exemplary embodiment may be implemented in this regard. As shown, network configuration 100 includes: asset 102, asset 104, communication network 106, remote computing system 108, output system 110, and data source 112, which may be an analysis platform.

  The communication network 106 can connect components in the network configuration 100 in a communicable manner. For example, assets 102 and 104 can communicate with analysis platform 108 via communication network 106. In some cases, assets 102 and 104 can communicate with one or more intermediate systems, such as an asset gateway (not shown), which can also communicate with analysis platform 108. Similarly, the analysis platform 108 can communicate with the output system 110 via the communication network 106. In some cases, the analysis platform 108 can communicate with an intermediate system, such as a host server (not shown), which can communicate with the output system 110. Many other configuration examples are possible. In the exemplary case, communication network 106 may facilitate secure communication (eg, with encryption and other security measures) between network components.

  In general, assets 102 and 104 can be any device configured to perform one or more actions (which can be defined based on fields), or one or more operational states of a given asset. Equipment that is configured to transmit data indicative of In some examples, an asset may include one or more subsystems that are each configured to perform one or more operations. In practice, assets operate by multiple subsystems operating in parallel or sequentially.

  Exemplary assets include transport machinery (eg, locomotives, passenger vehicles, semi-trailer trucks, ships, etc.), industrial machinery (eg, mining equipment, construction equipment, processing equipment, assembly equipment, etc.), and unmanned air vehicles. Other examples are possible. Those skilled in the art will recognize that these examples are only a few and that many other examples are possible and envisioned.

  In the exemplary embodiment, assets 102 and 104 are each of the same type (eg, there may be other examples, such as a locomotive fleet or an aircraft fleet), or of the same class. (E.g., the same equipment type, brand, and / or model). In other examples, assets 102 and 104 may differ with respect to type, brand, type, and the like. For example, assets 102 and 104 can be different equipment at a work site (eg, excavation site), a manufacturing facility, etc., and other examples are possible. Assets will be described in detail below, with reference to FIG.

  As shown, assets 102 and 104, and possibly data source 112, can communicate with analysis platform 108 via communication network 106. In general, communication network 106 may include one or more computing systems and a network infrastructure configured to facilitate data communication between network components. The communication network 106 can include or can include the following, which can be wired and / or wireless and can also support secure communications: One or more wide area networks (WAN) and / or local area networks (LAN). In some examples, the communication network 106 can include one or more cellular networks and / or the Internet, and there can be other networks. The communication network 106 can operate according to one or more of the following communication protocols: LTE, CDMA, GSM, LPWAN, WiFi®, Bluetooth®, Ethernet®, HTTP / S, TCP CoAP / DTLS etc. Note that although the communication network 106 is illustrated as a single network, the communication network 106 may include multiple separate networks, each of which is communicatively linked. The communication network 106 may adopt other forms.

  As described above, analysis platform 108 (sometimes referred to herein as a “remote asset monitoring system”) can be configured to receive data from assets 102 and 104 and data source 112. . Broadly speaking, the analysis platform 108 may include one or more computing systems, such as computing servers, databases, etc., that receive, drastically analyze, and output data. It is configured. The analysis platform 108 can be configured according to a predetermined data flow technology such as TPL Dataflow or NiFi, and other examples are possible. The analysis platform 108 will be described in detail below, with reference to FIG.

  As shown, analysis platform 108 may be configured to transmit data to assets 102 and 104 and / or output system 110. The specific data transmitted can take a variety of forms and will be described in detail below.

  In general, output system 110 may be a computing system or device configured to receive data and provide some output. The output system 110 can be implemented in various forms. In one example, the output system 110 can include or include the following: receiving data and audible, visual, and / or tactile output in response to the data An output device configured to provide. In general, the output device may include one or more input interfaces configured to receive user input, such that the output device transmits data over the communication network 106 based on such user input. Can be configured. Examples of output devices include: tablets, smartphones, laptop computers, other portable computing devices, desktop computers, smart televisions, and the like.

  Another example of output system 110 may be a work-order system configured to output a request to a mechanic worker or the like to repair an asset. Yet another example of the output system 110 may be a part-order system configured to place an order on an asset part and output a copy of the order. A number of other output systems are possible.

  Data source 112 may be configured to communicate with analysis platform 108. In general, the data source 112 may include or may include: Collecting data for one or more computing systems that may be relevant to functions performed by the analysis platform 108. One or more computing systems configured to provide to other systems such as storage, and / or analysis platform 108. Data source 112 may be configured to generate and / or obtain data independent of assets 102 and 104. Therefore, the data provided by the data source 112 is hereinafter also referred to as “external data”. Data source 112 may be configured to provide current and / or historical data. In practice, the analysis platform 108 may receive data from the data source 112 by “subscribing” to services provided by the data source. However, the analysis platform 108 may receive data from the data source 112 in other ways.

  Examples of data sources 112 include: environmental data sources, asset management data sources, and other data sources. In general, environmental data sources provide data indicative of some characteristic of the environment in which the asset operates. Examples of environmental data sources include the following and other examples: weather data servers, global navigation satellite system (GNSS) servers, map data servers, and predetermined regions Topographic data server that provides information on the natural and artificial features of

  In general, asset management data sources provide data that indicates the state of events or entities (eg, other assets) that can affect the operation or maintenance of the asset (eg, where and when the asset is driven, where and when). Etc.) Examples of asset management data sources include the following, and other examples: a traffic data server that provides information about air traffic, water traffic, and / or ground traffic, a specific date and / or An asset schedule server that provides information about an assumed route and / or location for an asset at a particular time, information about one or more states for an asset passing in the vicinity of a defect detection system (also called a “hot box”) A defect detection system to be provided, a part that a particular supplier has in stock and / or a part-supplier server that provides information about their prices, a repair shop server that provides information about repair shop capacity, etc.

  Examples of other data sources include, and may be other examples: a grid server that provides information about power consumption, an external database that stores historical operational data about assets. Those skilled in the art will recognize that these are just examples of data sources and that many other examples are possible.

  Note that the network configuration 100 is only one example of a network in which embodiments of the present disclosure may be implemented. Note that a number of other arrangements are possible and envisioned. For example, other network configurations may have additional components not shown and / or increase or decrease for the components shown.

II. Exemplary Assets Turning to FIG. 2, a simplified block diagram for an asset 200 is shown. Either or both assets 102 and 104 in FIG. 1 may be configured as asset 200. As shown, the asset 200 may include: one or more subsystems 202, one or more sensors 204, one or more actuators 205, a central processing unit 206, a data storage 208, a network interface 210. , User interface 212, position unit 214, and possibly local analyzer 220. All of these can be linked (directly or indirectly) in a communicable manner via a system bus, network or other connection mechanism. One of ordinary skill in the art should understand that the asset 200 may include additional components not shown and / or that there may be an increase or decrease in the components shown.

  In general terms, asset 200 may include one or more electrical, mechanical, and / or electromechanical components configured to perform one or more operations. In some cases, one or more components may be grouped into a given subsystem 202.

  In general, subsystem 202 may include a group of related components that are part of asset 200. One subsystem 202 can perform one or more operations alone, or one subsystem 202 can operate in conjunction with one or more other subsystems to perform one or more operations. Typically, different types of assets may also include different subsystems, even different classes of the same type of asset.

  For example, in the context of transportation assets, examples of subsystem 202 include the following, and may include a number of other subsystems: engine, transmission, driveline, fuel system, battery system, Exhaust systems, braking systems, electrical systems, signal processing systems, generators, gearboxes, rotors, and hydraulic systems.

  As suggested above, asset 200 includes various sensors 204 configured to monitor the operational status of asset 200 and various actuators 205 configured to interact with asset 200 or its components. And the operational state of the asset 200 is monitored. In some cases, some of the sensors 204 and / or actuators 205 can be grouped based on a particular subsystem 202. In this way, a group of sensors 204 and / or actuators 205 can be configured to monitor the operating status of a particular subsystem 202, and actuators belonging to that group can be configured to monitor their operating status. Can be configured to interact with a particular subsystem 202 to change the behavior of the subsystem in some manner based on

  In general, the sensor 204 can be configured to sense a physical characteristic indicative of one or more operational states of the asset 200 and provide an indication such as an electrical signal for the sensed physical characteristic. . In operation, the sensor 204 can be configured to acquire measurements continuously, periodically (eg, according to a sampling frequency), and / or in response to some triggering event. In some examples, the sensor 204 can be pre-configured with operating parameters for taking measurements and / or can take measurements according to operating parameters provided by the central processing unit 206. (For example, a sampling signal that instructs the sensor 204 to acquire a measured value). For example, different sensors 204 can have different operating parameters (eg, some sensors sample at a first frequency, while other sensors sample at a different second frequency). Regardless, the sensor 204 can be configured to transmit an electrical signal indicative of the measured physical characteristic to the central processing unit 206. The sensor 204 can provide such a signal to the central processing unit 206 continuously or periodically.

  For example, the sensor 204 can be configured to measure physical properties such as the location and / or movement of the asset 200, in which case the sensor can be: GNSS sensor, dead Reckoning (dead reckoning) system sensors, accelerometers, gyroscopes, pedometers, magnetometers, etc. In the exemplary embodiment, one or more sensors may be integrated with the position unit 214 or installed remotely from the unit, as will be described below.

  Additionally, the various sensors 204 can be configured to measure other operating conditions of the asset 200, examples of which include the following and other examples are possible: : Temperature, pressure, speed, acceleration or deceleration, friction force, power consumption, fuel consumption, fluid level, operating time, voltage and current, magnetic field, electric field, presence or absence of objects, component position, and power generation . Those skilled in the art will appreciate that these conditions are only an example of the operating conditions that the sensor is set to measure. Sensors can be increased or decreased according to industrial applications or specific assets.

  As suggested above, the actuator 205 may be configured in a manner similar to the sensor 204 in some aspects. Specifically, the actuator 205 can be configured to detect a physical characteristic indicative of the operational state of the asset 200 and provide the indication in a manner similar to the sensor 204.

  Further, the actuator 205 can be configured to interact with the asset 200, one or more subsystems 202, and / or some component thereof. Thus, the actuator 205 may include a motor or the like configured to perform mechanical movement (eg, move) or otherwise control the component, subsystem, or system. In particular examples, the actuator can be configured to measure the fuel flow and change the fuel flow (eg, suppress the fuel flow), or the actuator can measure the oil pressure and change the oil pressure (eg, The hydraulic pressure can be increased or decreased). A number of other exemplary interactions with the actuator are possible and are envisioned herein.

  In general, the central processing unit 206 may include one or more processors and / or controllers, which may be general purpose or special purpose processors or controllers. In particular, in the exemplary embodiment, the central processing unit 206 is or can include: a microprocessor, a microcontroller, an application specific integrated circuit (ASIC), a digital signal processor (DSP). etc. And the data storage 208 can be or include the following, and other examples are possible: one or more of optical, magnetic, organic, or flash memory, etc. Non-transitory computer-readable storage medium.

  The central processing unit 206 can be configured to store, access, and execute computer readable program instructions stored in the data store 208 to perform the asset operations described herein. For example, as suggested above, the central processing unit 206 can be configured to receive respective sensor signals from the sensors 204 and / or actuators 205. The central processing unit 206 can be configured to store sensor and / or actuator data in the data store 208 and access it later in the data store 208.

  The central processing unit 206 can also be configured to determine whether the received sensor and / or actuator signal triggers some abnormal condition indicator, such as a fault code. For example, the central processing unit 206 can be configured to store abnormal condition rules in the data storage unit 208, each of which includes a predetermined abnormal condition index representing a specific abnormal condition, and an abnormal condition index. Each trigger criteria to be activated. That is, each abnormal condition index corresponds to one or more sensor and / or actuator measurements that must be satisfied before the abnormal condition index is triggered. In practice, asset 200 can be preprogrammed with abnormal condition rules and / or receive new abnormal condition rules or updates to existing rules from a computing system such as analysis platform 108. Can do.

  Regardless, the central processing unit 206 can be configured to determine whether the received sensor and / or actuator signal triggers any abnormal condition indicator. That is, the central processing unit 206 can determine whether the received sensor and / or actuator signal meets some triggering criteria. If such a determination is positive, the central processing unit 206 can generate abnormal condition data and also cause the asset's network interface 210 to transmit abnormal condition data to the analysis platform 108, and Alternatively, the asset user interface 212 can be made to output an abnormal condition indicator, such as a visual and / or audible alert. In addition, the central processing unit 206 can log the generated event of the abnormal state index in the data storage unit 208, and may include a time stamp in some cases.

  FIG. 3 shows an exemplary abnormal condition indicator for assets and a schematic representation for each triggering criterion. In particular, FIG. 3 schematically shows an example for a fault code. As shown, table 300 includes columns 302, 304, and 306, which correspond to sensor A, actuator B, and sensor C, respectively, and the table includes rows 308, 310, and 312 which are Corresponds to failure codes 1, 2, and 3, respectively. Entry 314 specifies a sensor reference (eg, sensor threshold) corresponding to a predetermined fault code.

  For example, fault code 1 is triggered when sensor A detects a rotation measurement higher than 135 revolutions per minute (RPM) and sensor C detects a temperature measurement higher than 65 degrees Celsius (° C). The fault code 2 is activated when the actuator B detects a voltage measurement value higher than 1000 volts (V) and the sensor C detects a temperature measurement value less than 55 ° C. 3 is activated when sensor A detects a rotation measurement higher than 100 RPM, actuator B detects a voltage measurement higher than 750 V, and sensor C detects a temperature measurement higher than 60 ° C. One of ordinary skill in the art will realize that FIG. 3 is presented for illustrative and explanatory purposes only, and understand that a number of other fault codes and / or trigger criteria are possible; These are envisioned.

  Returning to FIG. 2, the central processing unit 206 may perform various additional functions for managing and / or controlling the operation of the asset 200. For example, the central processing unit 206 can be configured to provide command signals to the subsystem 202 and / or the actuator 205, which can cause the subsystem 202 and / or the actuator 205 to perform the following actions: Can be done: Some action, such as changing the throttle opening. Additionally, the central processing unit 206 can be configured to change the speed at which data from the sensors 204 and / or actuators 205 is processed, or the central processing unit 206 can be configured with the sensors 204 and / or Or it can be configured to provide a command signal that causes the actuator 205 to perform the following actions: for example, a command signal that changes the sampling rate. The central processing unit 206 can also be configured to receive signals from the subsystem 202, sensors 204, actuators 205, network interface 210, user interface 212, and / or position unit 214, and Some operation is performed based on the signal. Still further, the central processing unit 206 can be configured to receive a signal from a computing device, such as a diagnostic device, by which the central processing unit 206 is stored in the data storage unit 208. One or more diagnostic tools can be executed according to the diagnostic rules. Other functions of the central processing unit 206 will be described later.

  The network interface 210 may be configured to provide communication between the asset 200 and various network components connected to the communication network 106. For example, the network interface 210 may be configured to allow wireless communication to and / or from the communication network 106, and thus transmit and receive various wireless signals with the antenna structure. Can be configured with related equipment. Other examples are possible. In practice, the network interface 210 can be configured according to any of the communication protocols described above, but is not limited to those protocols.

  The user interface 212 can be configured to support user interaction with the asset 200 and can be configured to cause the asset 200 to perform an action in response to the user interaction. Examples of user interface 212 include the following, and may be other examples: touch-sensitive interfaces, mechanical interfaces (eg, levers, buttons, wheels, dials, keyboards, etc.) and other user inputs. Interface (eg microphone). In some cases, the user interface 212 may include or provide connectivity to output components such as display screens, speakers, headphone jacks, and the like.

  In general, the position unit 214 may be configured to perform geospatial location / position and / or navigation related functions. More specifically, the position unit 214 is configured to determine the location and position of the asset 200 and / or track the movement of the asset 200 using one or more of the following positioning techniques: GNSS technology (GPS, GLONASS, Galileo, BeiDou, etc.), triangulation technology, and similar technologies. Accordingly, the position unit 214 may include one or more sensors and / or receivers configured in accordance with one or more specific positioning techniques.

  In the exemplary embodiment, position unit 214 allows asset 200 to provide position data that indicates the position of asset 200 to other systems and / or devices (eg, analysis platform 108). And the data can be in other formats that can be GPS coordinates. In some embodiments, asset 200 may provide location data to other systems in the following manner: continuous manner, periodic manner, trigger-coupled manner, or some other manner. Also, the asset 200 can provide location data independently or with other asset related data (eg, with driving data).

  In general, the local analyzer 220 can be configured to receive and analyze data associated with the asset 200, and one or more actions are performed on the asset 200 based on such analysis. Can act as For example, the local analyzer 220 can receive operational data for the asset 200 (eg, data generated by the sensor 204 and / or the actuator 205) and based on such data, the central processor 206, the sensor 204, and An instruction may be provided to the actuator 205 to cause the asset 200 to perform some action. In another example, the local analyzer 220 receives location data from the position unit 214 and how it uses the prediction model and / or the asset 200 based on such data. You can change whether the workflow should be handled. Other exemplary analysis and response operations are possible.

  In order to facilitate some of these operations, the local analyzer 220 may include one or more asset interfaces configured as follows: the local analyzer 220 may include one or more airborne systems of assets and Asset interface to merge. For example, as shown in FIG. 2, the local analyzer 220 may have an interface to an asset central processor 206, which allows the local analyzer 220 to receive data from the central processor 206 (eg, Operation data generated by the sensor 204 and / or actuator 205 and sent to the central processor 206, position data generated by the position unit 214, etc.) may be received, and the instructions may be received by the central processor. 206 may be provided. In this way, the local analyzer 220 interacts indirectly with and from other airborne systems (eg, sensors 204 and / or actuators 205) via the central processing unit 206. Data can be received. Additionally or alternatively, as shown in FIG. 2, the local analyzer 220 can have an interface to one or more sensors 204 and / or actuators 205, depending on the interface. It may be possible for the local analyzer 220 to communicate directly with the sensor 204 and / or the actuator 205. The local analyzer 220 may interact with the airborne system of the asset 200 in other ways, and the interface shown in FIG. 2 may be supported by one or more intermediate systems not shown. This is also included.

  In practice, the local analysis device 220 can enable the asset 200 to perform advanced analysis operations and their associated operations (eg, executing a predictive model and corresponding workflow) locally. , These may not have been possible with other asset-based components. In this manner, the local analyzer 220 can assist in providing additional processing power and / or intelligence to the asset.

  It should also be noted that the local analyzer 220 can be configured to cause the asset 200 to perform actions that are not related to the prediction model. For example, the local analyzer 220 can receive data from a remote source, such as the analysis platform 108 or the output system 110, and can cause the asset 200 to perform one or more operations based on the received data. In one particular example, the local analyzer 220 can receive a firmware update for the asset 200 from a remote source and attempt to cause the asset 200 to update its firmware. In another specific example, the local analyzer 220 can be configured to receive diagnostic instructions from a remote source and cause the asset 200 to execute a local diagnostic tool in a manner that is compliant with the received instructions. Several other examples are possible.

  As shown, in addition to the one or more asset interfaces described above, the local analyzer 220 can also include a processing unit 222, a data store 224, and / or a network interface 226, all of which are system It can be linked in a communicable manner with a bus, network, or other connection mechanism. Processing unit 222 may include any of the components described above in connection with central processing unit 206. The data storage 224 can then be or include one or more non-transitory computer readable storage media that can take any form of the computer readable storage media described above.

  The processing unit 222 can be configured to perform a storing act, an accessing act, and an executing act on the computer readable program instructions stored in the data storage unit 224, and the operation of the local analysis device disclosed herein can be performed. . For example, the processing unit 222 is configured to receive respective sensor and / or actuator signals generated by the sensors 204 and / or actuators 205 and to execute a prediction model and a corresponding workflow based on such signals. Can be. Other functions will be described later.

  The network interface 226 can be the same as or similar to the network interface described above. In practice, the network interface 226 can support communication between the local analyzer 220 and the analysis platform 108.

  In some embodiments, the local analyzer 220 can include and / or communicate with a user interface similar to the user interface 212. In practice, the user interface may be located remotely from the local analyzer 220 (and / or asset 200). Other examples are possible.

  FIG. 2 illustrates that the local analyzer 220 is coupled in a manner that allows it to physically communicate with the asset with which it is associated (eg, asset 200). Note that this is not the case with the asset interface. For example, in some embodiments, the local analyzer 220 is not physically coupled to the asset with which it is associated, but instead may be remotely located in relation to the asset 200. In such an implementation, the local analysis device 220 can be coupled to the asset 200 in a wirelessly communicable manner. Other arrangements and configurations are possible.

  Those skilled in the art will appreciate that the asset 200 shown in FIG. 2 is a representative and simple example of an asset, and that many other examples are possible. . For example, other assets may include additional components not shown and may be increased or decreased for the components shown. In addition, the predetermined asset can include a plurality of individual assets that are operated in a coordinated manner and perform operations of the predetermined asset. Other examples are possible.

III. Exemplary Analysis Platform Turning to FIG. 4, a simplified block diagram for an exemplary analysis platform 400 is shown. As suggested above, the analysis platform 400 may include one or more computing systems that are linked and arranged in a communicable manner to perform various operations of the present disclosure. For example, as shown, the analysis platform 400 may include a data acceptance system 402, a data analysis system 404, and one or more databases 406. These system components can be combined in a manner that allows communication via one or more wireless and / or wired connections, and these connections can be configured to allow secure communication. . Further, two or more of these components can be integrated together in whole or in part.

  In general, the data receiving system 402 receives data and captures at least a portion of the received data for output to the data analysis system 404. Thus, the data acceptance system 402 is configured to receive data from various network components of the network configuration 100 (eg, assets 102, 104, output system 110, and / or data source 112, etc.). Network interfaces. In particular, the data acceptance system 402 can be configured to receive analog signals, data streams, and / or network packets, and there can be other examples. Thus, the network interface may include one or more wired network interfaces, such as ports, and / or wireless network interfaces, such as those described above. In some examples, the data acceptance system 402 can be or include the following: a component configured in accordance with a predetermined data flow technology, such as a NiFi receiver.

  The data acceptance system 402 may include one or more processing components configured to perform one or more operations. Examples of operations include the following, and may include other operations: compression and / or decompression, encryption and / or decryption, analog to digital and / or digital to analog conversion, amplification, formatting, and Packaging. The data acceptance system 402 may also be configured to filter, parse, sort, classify, route, and / or store data according to one or more acceptance parameters. For example, the data acceptance system 402 may operate according to acceptance parameters that define a specific set of data variables to be accepted from the asset (a specific set of asset sensor / actuator measurements to be captured). As another example, the data acceptance system 402 can operate according to acceptance parameters that define how fast data should be accepted from the asset (eg, sampling frequency). As yet another example, the data acceptance system 402 can operate according to acceptance parameters that define where data captured from an asset is stored. The data acceptance system 402 can also operate according to other acceptance parameters.

  In general, the data received by the data receiving system 402 can be in a variety of formats. For example, the payload portion of the data may include operational data such as single sensor or actuator measurements, multiple sensor or actuator measurements, abnormal condition data, and / or other data related to the operation of the asset. . Other examples are possible.

  The received data may also include other data corresponding to the driving data, such as a source identifier, a time stamp (eg, date and / or time of information acquisition), and / or location data. . For example, each asset can be assigned a unique identifier (eg, a computer generated alphabetic, numeric, mixed alphabetic and numeric identifier, or similar), and in some cases each sensor and A unique identifier can also be assigned to the actuator. Such an identifier may be such as to allow identification of the asset, sensor, or actuator that is the source of the data. Furthermore, the location data may represent the location of the asset (eg, in the form of GPS coordinates, etc.), and in certain cases, the location data corresponds to the asset location at the time of obtaining specific information such as driving data. In practice, other data corresponding to the driving data can be signal signatures or metadata, and other examples are possible.

  The data analysis system 404 can generally function to receive and analyze data (eg, from the data receiving system 402), and one or more actions can occur as a result of such analysis. Accordingly, the data analysis system 404 may include one or more network interfaces, processing units 410, and data storage units 412 all linked in a communicable manner via a system bus, network, or other connection mechanism. Has been. In some cases, the data analysis system 404 can be configured to store and access one or more APIs (Application Programming Interfaces) that assist in performing some of the disclosed functions.

  The network interface 408 can be the same or similar to any of the network interfaces described above. In practice, the network interface 408 allows communication (with some security) between the data analysis system 404 and various other entities, including various data receiving systems 402 and databases. 406, asset 102, output system 110, and the like.

  The processing device 410 can include one or more processors, which can be any type of processor described above. Data storage 412 can then be or include one or more non-transitory computer readable storage media, which can be any type of computer readable storage media described above. The processing device 410 can be configured to store, access, and execute computer readable program instructions stored in the data storage unit 412, thereby performing the functions of the analysis platform described herein. it can.

  In general, the processing unit 410 can be configured to perform analysis on data received from the data receiving system 402. In this regard, the processing device 410 can be configured to execute one or more modules, each of which includes one or more program instruction sets stored in the data store 412. can do. The module may be configured to facilitate a specific result being triggered based on the execution of each program instruction. Exemplary results for a given module are envisaged, but other examples are possible: outputting data to another module, sending a given module and / or another module's program instructions Updating and outputting data to the network interface 408 for transmission to the asset and / or output system.

  In general, the database 406 functions to store and store data (eg, from the data analysis system 404). Thus, each database 406 may include one or more of any of the non-transitory computer readable storage media described above. In practice, the database 406 is separate from or integrated with the data storage unit 412.

  Database 406 can be configured to store various types of data, some of which are described below. In practice, some of the data stored in the database 406 may include a time stamp that indicates the date and time when the data was generated or added to the database. Additionally or alternatively, some of the data stored in the database 406 is collected as location data (eg, GPS coordinates) that indicates the asset location at a particular point in time and / or as specific data on whether the asset was generated. Position data indicating the position at a given time point may be included.

  In addition, data can be stored in various modes in the database 406. For example, data was classified in chronological order, in tabular form, and / or according to data source type (eg, asset, asset type, sensor, sensor type, actuator, actuator type, or asset position) or abnormal condition indicator It can be stored in a form, and other examples are possible. Representative examples of database types include time series databases, document databases, relational databases, and / or graph databases, but there may be other types.

  Note that analysis platform 400 may include other systems and / or other components. For example, the analysis platform 400 can include a system for determining and / or tracking the location of assets. Other examples are possible.

IV. Exemplary Operation The operation of the exemplary network configuration 100 shown in FIG. Flow charts may be referred to to assist in the description of some operations and to describe combinations of operations that can be performed. In some cases, each block represents a module or part of program code, which includes instructions that can be executed by the processor to implement a specific logic function or step in the procedure. It is. The program code may be stored in any type of computer readable medium, such as a non-transitory computer readable medium. In another case, each block represents a circuit that is wired to perform a particular logical function or step in the procedure. Also, the blocks shown in the flowchart may be rearranged in a different order, merged into fewer blocks, divided into additional blocks, and / or removed, depending on the particular embodiment. can do.

  The following description refers to the case where a single data source, such as asset 102, provides data to analysis platform 108, which in turn performs one or more functions. This mechanism is merely employed for clarity and convenience of explanation and is not intended to be limiting. In practice, the analysis platform 108 typically receives data from multiple sources simultaneously and operates on such aggregated received data.

A. Collecting Operational Data As described above, the representative asset 102 can be given a variety of formats and can be configured to perform several operations. In a non-limiting example, asset 102 may be a locomotive that traverses the United States and transports cargo. During operation, the sensor and / or actuator of the asset 102 may obtain data that reflects one or more of the operational states of the asset 102. The sensor and / or actuator may then send the data to the processing device of the asset 102.

  The processing device may be configured to receive data from sensors and / or actuators. In practice, the processing device may receive sensor data from multiple sensors and / or actuator data from multiple actuators simultaneously or sequentially. As described above, when receiving these data, the processing device is also configured to determine whether the data satisfies a triggering criterion that triggers any abnormal condition indicator, such as a fault code. be able to. If the processing device determines that one or more abnormal condition indicators have been triggered, the processing device is configured to perform one or more local operations, such as outputting the triggered indicators via a user interface. Can be.

  The asset 102 then transmits the operational data to the analysis platform 108 via the network interface of the asset 102 and / or the communication network 106. In the exemplary embodiment, asset 102 may provide other data along with operational data. For example, asset 102 may provide location data, time stamps, and / or source identifiers that correspond to driving data. Alternatively, asset 102 may provide such other data in a data stream that is different from the operational data. For example, asset 102 may provide a first data stream that includes driving data for the asset, and asset 102 may also provide a second data stream that includes location data for the asset. Other examples are possible.

  In operation, the asset 102 can transmit operational data to the analysis platform 108 continuously, periodically, and / or in response to triggered events (eg, abnormal conditions). Specifically, the asset 102 can periodically transmit driving data based on a specific frequency (eg, every day, every hour, every 15 minutes, every minute, every second, etc.), or the asset 102 can drive It can be configured to send a continuous real-time feed about the data. Additionally or alternatively, asset 102 may transmit driving data based on specific triggering events, such as when sensor and / or actuator measurements meet triggering criteria for any abnormal condition indicator. Can be configured. The asset 102 may transmit driving data in other manners.

  In practice, the operational data for asset 102 may include sensor data, actuator data, abnormal condition data, and / or other asset event data (eg, data indicating asset shutdown, restart, etc.). In some embodiments, asset 102 is configured to provide driving data in a single data stream, while in other embodiments asset 102 provides driving data in multiple separate data streams. Can be configured to. For example, asset 102 may provide analysis platform 108 with a first data stream that includes sensor and / or actuator data and a second data stream that includes abnormal condition data. As another example, asset 102 may provide a separate data stream to analysis platform 108 for each sensor and / or actuator of asset 102. Other possibilities are possible.

  Sensor and actuator data can be provided in various forms. For example, in some cases, sensor data (or actuator data) may include measurements taken by each sensor (or actuator) of asset 102. On the other hand, in another context, sensor data (or actuator data) may include measurements obtained from a subset of the sensors (or actuators) of asset 102.

  In particular, the sensor and / or actuator data may include measurements taken from sensors and / or actuators associated with a predetermined triggered abnormal condition indicator. For example, if the activated fault code is fault code 1 in FIG. 3, the sensor data may include raw measurements acquired by sensors A and C. Additionally or alternatively, the data may include measurements taken from one or more sensors or actuators that are not directly associated with the triggered fault code. Continuing with the most recent example, additionally, the data may also include measurements taken by actuator B and / or other sensors and actuators. In some examples, asset 102 may include specific sensor data within operational data found based on fault code rules or instructions provided by analysis platform 108, for example, actuator B may measure There may be a case where there is a correlation between the value that is being used and the cause that originally caused the fault code 1 to be activated. Other examples are possible.

  Further, the data may include one or more sensor and / or actuator measurements from each of the interesting sensors and / or actuators based on the time of interest that may be selected based on several factors. May be included. In some embodiments, a particular time of interest can be determined based on the sampling frequency. In other embodiments, the time of particular interest can be determined based on when the abnormal condition indicator is triggered.

  In particular, based on when the abnormal condition indicator is triggered, the data can include one or more of each sensor and / or actuator measurement from each of the sensors and / or actuators of interest (eg, triggering). Sensors and / or actuators that are directly and indirectly associated with the measured index). The one or more measured values can be based on a specific number of measurements or based on a specific time frame set before and after the time when the abnormal condition indicator is triggered.

  For example, if the activated fault code is fault code 2 in FIG. 3, the sensors / actuators of interest may include actuator B and sensor C. The one or more measurements include each of the recent measurements taken by actuator B and sensor C before the fault code (eg, triggering measurement) was triggered, or alternatively Each set of measurements taken before, after, or around. There may be other possibilities, but the set of five measurements may include the following configuration: If it contains five measurements before or after the trigger measurement (eg, excluding trigger measurements), When including the four measured values before and after the trigger measurement value and the trigger measurement value, or when including the two previous measurement values and the two subsequent measurement values and the trigger measurement value.

  Similar to sensor and actuator data, various aspects can be provided for abnormal state data. In general, the abnormal state data may include an index that can distinguish all other abnormal states that may occur in the asset 102 from a specific abnormal state that has occurred in the asset 102 and uniquely identify the latter. Or it can have the form of such an indicator. The abnormal condition indicator may be an alphabetic, numeric, or mixed alphabet and numeric identifier, and there may be other examples. Furthermore, the abnormal condition index can be a word string that adds a descriptive explanation about the abnormal condition, such as “Overheated Engine” or “Out of Fuel”. There can be other examples.

  The analysis platform 108, and in particular the data receiving system of the analysis platform 108, receives data such as driving data and / or location data from one or more assets and / or receives them from other data sources. Can be configured. The data acceptance system is configured to accept at least a portion of the received data, perform one or more operations on the received data, and communicate the data to the data analysis system of the analysis platform 108. Can be.

B. Operational Data Usage During standard operations, operational data collected for a given asset can be used for a variety of applications. As an example, the driving data can be used in the definition, modification, and / or execution process of a predictive model and corresponding workflow (ie, “model-workflow pair”) associated with asset driving. As another example, driving data can be used in a definition, modification, and / or execution process for other workflows related to asset driving (eg, workflows are independent in relation to predictive models). An example of a workflow is a workflow for providing a notification based on asset operation data. Other examples are possible. These examples of asset operational data are described in detail below.

1. Model-Workflow Pairs As an example, the analysis platform 108 uses the operational data for multiple assets (although there may be other data) to define and modify the model-workflow pairs associated with asset operations. And / or execution.

  In general, a model-workflow pair may include program instructions that cause the device to do the following: To determine the likelihood that at least one event of a given set of events will occur in the future To monitor for specific operating conditions; to perform specific actions if that possibility satisfies certain conditions. For example, a predictive model can include an algorithm having an input and an output, where the input is sensor and / or actuator data from one or more sensors and / or actuators of the asset, and the output is future Utilized to determine the likelihood that a particular type of event will occur (or no such event will occur) in an asset during a specific period of time. The corresponding workflow is composed of one or more operations performed when the output of the prediction model satisfies a specific condition.

  In practice, analysis platform 108 may be configured to define, aggregate, and / or individualize predictive models and / or workflows. An “aggregated” model-workflow pair can mean a model-workflow pair that is common to assets, and is defined without taking into account the individual characteristics of a given asset. On the other hand, an “individualized” model / workflow is a model-workflow pair that is specially prepared for an asset of a single asset or a group of assets, and is an individual Defined based on characteristics.

  The procedure for defining and executing model-workflow pairs is described in detail below.

a. Predictive Model Definition In an exemplary embodiment, analysis platform 108 may be configured to define an aggregate model-workflow pair based on aggregate operational data for multiple assets. The work of defining an aggregation model-workflow pair can be done in various ways.

  FIG. 5 is a flow diagram for an example illustrating one possibility for a definition phase that may be used to define a prediction model. For illustration purposes, the exemplary definition stage is described as being done by the analysis platform 108, but this definition stage may be done by other systems. One skilled in the art will understand that the flowchart 500 is provided for clarity and explanation purposes only, and defines a model-workflow pair utilizing a number of other behavioral combinations. You will understand that you can.

  As shown in FIG. 5, at block 502, the analysis platform 108 may begin processing by defining a data set that is the basis for a predetermined predictive model (eg, data of interest). The data of interest can be derived from a number of sources, which include assets 102 and 104, and data source 112, which can be stored in the analysis platform 108 database.

  Interesting data is a history of a set for a particular asset in a group of assets, or for all assets in an asset group (eg, an asset of interest) Data can be included. Also, the data of interest may include measurements from a specific set of sensors and / or actuators from each of the assets of interest, or all of the sensors and / or actuators from each of the assets of interest. Measurements can be included. Furthermore, the data of interest can include data from a specific period in the past. For example, historical data for two weeks can be assumed.

  The data of interest can include various types of data and will depend on a predetermined prediction model. In some cases, the data of interest includes at least operation data indicating the operation condition of the asset. For the operation data here, refer to the item “collecting operation data” described above. Additionally, the data of interest may include environmental data that indicates the environment in which the asset normally operates and / or scheduling data that indicates the date and time that the asset is scheduled to perform a particular task. . Other types of data may also be included in the data of interest.

  In practice, the data of interest can be defined along several aspects. In one example, the data of interest can be defined by the user. In particular, the user can operate an output system 110 that receives user input indicating selections for data of particular interest, and the output system 110 analyzes data indicating such selections. The platform 108 can be provided. The analysis platform 108 then defines the data of interest based on the received data.

  In another example, the data of interest can be defined by a machine. In particular, the analysis platform 108 can perform various operations, such as simulation, to determine the data of interest that produces the most accurate prediction model. Other examples are possible.

  Returning to FIG. 5, at block 504, the analysis platform 108 may be configured to define an aggregated prediction model related to the behavior of the asset based on the data of interest. In general, an aggregated prediction model can define a relationship between an asset's operational state and the likelihood of an event occurring on the asset. Specifically, the aggregated prediction model is received as sensor data from an asset sensor and / or actuator data input from an asset actuator, and at least one of a predetermined set of events is within a specified future period. To output the possibility of occurrence in the asset.

  The events predicted by the prediction model may vary depending on the specific implementation. For example, such an event can be a failure event that can occur in the asset, in which case the predictive model will predict the likelihood of the failure event occurring during a specific period in the future. In another example, such an event can be an action that can be taken by the asset (e.g., a restart or shutdown action), in which case the predictive model is that the asset takes action during a specified period in the future And / or predict the likelihood of completion. In other examples, such an event can be a completed task (eg, delivering a payload item to a destination), in which case the predictive model is that the asset completes the task during a specific period in the future. Will predict the possibility of doing. In yet another example, such an event can be a replacement event (eg, fluid or component replacement), in which case the predictive model predicts the amount of time until the replacement event is forced. Become. In yet another example, such an event can be an asset productivity change event, in which case the predictive model will predict asset productivity at a specific time in the future. In yet another example, such an event can be a “advanced indicator” event that indicates that the asset behavior is different from the expected asset behavior, in which case the predictive model is one or more proactive types in the future. The probability that an indicator event will occur will be predicted. There may be other examples of predictive models.

  In general, defining an aggregated prediction model can involve utilizing one or more modeling techniques, thereby creating a model that returns a probability between zero and one. There are other modeling methods, but there are random forest methods, logistic regression methods, and other regression methods. However, other methods are possible.

  In one particular exemplary embodiment, the predictive model can be one or more predictive models that monitor health and output a health metric for the asset (eg, a “health score”). Yes, the metric is a single aggregated metric that indicates whether a failure will occur on a given asset within a given period in the future (eg, within the next two weeks). In particular, the health metric indicates that any failure in the failure group may not occur in the asset during a predetermined period in the future, or at least one failure in the failure group is determined in the future It can indicate the likelihood of an asset occurring within a period of time.

  Depending on the desired granularity for the health metric, the analysis platform 108 may be configured to define different prediction models that output different levels of health metrics, each used as a prediction model in accordance with the present disclosure. Can be done. For example, the analysis platform 108 can define a predictive model that outputs a health metric for the entire asset (ie, an asset level health metric). As another example, analysis platform 108 may define respective predictive models that each output a health metric (ie, a subsystem level health metric) for one or more subsystems of the asset. In some cases, the output of each subsystem level prediction model can be combined to produce an asset level health metric. Other examples are possible.

  In general, with respect to defining a predictive model that outputs a health metric, this can be done in a variety of ways. The flowchart 600 of FIG. 6 shows one possible example of a modeling phase process that can be used to define a model that outputs health metrics. For illustrative purposes, the exemplary modeling phase is described as being performed by the analysis platform 108, but the modeling phase may be performed by other systems. One of ordinary skill in the art will understand that the flowchart 600 is provided for clarity and explanation purposes only, and several other behavioral combinations can be utilized to determine the health metric. You will understand that you can.

  As shown in block 602 of FIG. 6, the analysis platform 108 initiates the procedure by defining one or more sets of faults that will form the basis of the health metric (ie, interest). Target failure). In practice, one or more failures may be failures that would render the asset (or its subsystem) unusable if it occurred. Based on the defined set of faults, the analysis platform 108 can define various models for predicting the likelihood that any fault will occur within a predetermined period of time in the future (eg, within the next two weeks). Steps can be defined.

  In particular, at block 604, the analysis platform 108 can analyze historical operational data for the group of one or more assets to identify a history of a given fault in the set of faults. At block 606, the analysis platform 108 is associated with each identified as a past occurrence for a predetermined fault (eg, sensor and / or actuator data during a predetermined period prior to the occurrence of the predetermined fault). Each set of operational data can be identified. At block 608, the analysis platform 108 analyzes the set of operational data associated with the past occurrences of the specified failure that has been identified, and the relationship between the following (1) and (2) ( For example, a failure model can be defined: (1) a value for a predetermined set of operational metrics, and (2) a predetermined failure occurs within a predetermined period in the future (eg, within the next two weeks) Possibility to do. Finally, at block 610, a model for predicting the overall likelihood that a failure will occur, where predefined relationships (eg, individual failure models) for each failure in the defined set are grouped together. Is obtained.

  While the analysis platform 108 continues to receive updated operational data for one or more asset groups, the analysis platform 108 refines the prediction model for one or more defined sets of faults ( For example, steps 604 to 610 are repeated for the updated operation data.

  The functions of the exemplary modeling stage shown in FIG. 6 are described in detail below. Beginning at block 602, as described above, the analysis platform 108 begins the procedure by defining a set of one or more faults that will form the basis of the health metric. The analysis platform 108 can perform this function in various ways.

  In one example, the set of one or more faults can be based on one or more user inputs. Specifically, the analysis platform 108 can receive input data indicating a user selection for one or more faults from a computing system being operated by a user, such as the output system 110. In this way, a set of one or more faults can be defined by the user.

  In other examples, the set of one or more faults can be based on decisions made by the analysis platform 108 (eg, for a machine-defined type). In particular, the analysis platform 108 can be configured to define one or more sets of faults, which can occur in a number of ways.

  For example, the analysis platform 108 can be configured to define a set of faults based on one or more characteristics of the asset 102. That is, a particular failure may correspond to a particular property of the asset (eg, asset type, class, etc.). For example, for each asset type and / or class, there may be a respective failure of interest.

  In another case, the analysis platform 108 is configured to define a set of faults based on historical data stored in the database of the analysis platform 108 and / or external data provided by the data source 112. Can be. For example, the analysis platform 108 can utilize such data to provide other examples of operations, but which failure results in the longest repair time and / or what additional failure in historical terms. Can be determined as to whether an error occurs following a certain failure.

  In yet another example, a set for one or more faults can be defined based on a combination of user input and decisions made by the analysis platform 108. Other examples are possible.

  At block 604, for each fault in the set of faults, the analysis platform 108 analyzes historical operational data (eg, abnormal condition data) for the group for one or more assets to determine the occurrence of a given fault in the past. Can be specified. A group for one or more assets can include a single asset, such as asset 102, or multiple assets of the same or similar maintenance type, such as a fleet that includes assets 102 and 104. The analysis platform 108 can analyze a specific amount of historical operation data, and the amount to be analyzed can be data of a specific period length (for example, for one month) or a specific number of data points. (For example, 1000 recent data points), and other examples are possible.

  In practice, the action of identifying past occurrences for a given fault may involve the analysis platform 108 performing the following actions: identifying the type of operational data such as abnormal state data indicating the given fault . In general, a given fault can be associated with one or more abnormal condition indicators such as a fault code. In other words, one or more abnormal condition indicators may be triggered when a predetermined failure occurs. Therefore, the abnormal state index may reflect the symptom underlying the predetermined failure.

  After identifying the type of operational data indicative of a given failure, the analysis platform 108 can identify past occurrences for the given failure in several ways. For example, the analysis platform 108 can find abnormal condition data corresponding to an abnormal condition indicator associated with a predetermined failure from historical operational data stored in the database of the analysis platform 108. Each of the abnormal condition data found will indicate an occurrence of a predetermined failure. Based on the abnormal state data found, the analysis platform 108 can identify the time when a failure has occurred in the past.

  At block 606, the analysis platform 108 can identify each set of operational data associated with each identified past occurrence of the predetermined fault. In particular, the analysis platform 108 can identify a set of sensor and / or actuator data for a particular period around the time of occurrence of a given occurrence of a given failure. For example, the data set can be from the following range: a range that is before, after, or about a certain period (eg, 2 weeks) in relation to a given occurrence of a given failure . In other cases, the data set can be identified from a specific number of data points belonging to the following range: a range that is before, after, or around a given failure occurrence.

  In the exemplary embodiment, the set of operational data may include sensor and / or actuator data from all or a portion of the sensors and actuators of asset 102. For example, the set of operational data may include data from sensors and / or actuators that are associated with an abnormal condition indicator corresponding to a predetermined failure.

Illustratively, FIG. 7 represents a schematic diagram of historical driving data that can be analyzed by the analysis platform 108 to facilitate model definition. The plot 700 may correspond to a segment of historical data arising from all or part of the sensors and actuators of the asset 102 (eg, sensor A and sensor B). As shown, the plot 700 represents time on the x-axis 702 and measured values on the y-axis 704, with sensor data 706 corresponding to sensor A and actuator data 708 corresponding to actuator B. , Each containing various data points representing measurements at a particular time T _i . Also, the plot 700 shows an indication of the occurrence of a failure 710 that occurred at a past time point, T _f (eg, time of failure), and before the occurrence of the failure to be specified for a set of operating data. Indices for the period 712, ΔT are included. Thus, T _f −ΔT defines a period 714 for the data point of interest.

Returning to FIG. 6, after the analysis platform 108 has identified a set of operational data for a given occurrence for a given fault (eg, an occurrence at _Tf ), the analysis platform 108 may further identify the operation to be identified. It can be determined whether there are any remaining sets of data. If there are remaining occurrences, block 606 will be repeated for each remaining occurrence.

  Thereafter, at block 608, the analysis platform 108 analyzes the identified set of operational data associated with the past occurrences of the predetermined failure, between the following (1) and (2) Relationships (eg, failure models) can be defined: (1) a predetermined set of operational metrics (eg, a predetermined set of sensor and / or actuator measurements), (2) within a predetermined period in the future A certain failure may occur (for example, in the next two weeks). That is, the predetermined failure model accepts sensor and / or actuator measurements from one or more sensors and / or actuators as input and outputs the possibility that a predetermined failure will occur within a predetermined period in the future. be able to.

  In general, a failure model can define a relationship between the operational state of the asset 102 and the likelihood that a failure will occur. In some embodiments, in addition to the raw data signals from the sensors and / or actuators of the asset 102, the failure model may include some other data, also referred to as features derived from the sensors and / or actuator signals. Input can be received. Such features may include the following: the average value or range of values historically observed at the time of the failure, the average value gradient historically observed before the failure occurred (eg, Rate of change of measured values) or range of value gradients, elapsed time between failures (eg, amount of elapsed time or number of data points between first and second failures), and / or One or more failure patterns that indicate sensor and / or actuator measurement trends at the time of failure. One skilled in the art will appreciate that these are just a few examples of features that can be derived from sensor and / or actuator signals, and that many other features are possible.

  In practice, the failure model can be defined in several ways. In the exemplary embodiment, analysis platform 108 can define a failure model by leveraging one or more modeling techniques that return probabilities between zero and one, which model can be any of the modeling techniques described above. Can be embodied as

  In certain cases, the failure model definition operation may involve the analysis platform 108 generating response variables based on the historical operational data identified at block 606. Specifically, the analysis platform 108 can determine an associated response variable for each set of sensor and / or actuator measurements received at a particular time. Thus, the response variable can be embodied as a data set associated with the fault model.

  The response variable can indicate whether the predetermined set of measurements is within any period determined at block 606. That is, the response variable can reflect whether or not the predetermined data set belongs to the time of interest when the failure occurred. The response variable can be a binary response variable, and the associated response variable is assigned a value of 1 if the predetermined set of measurements is within any determined period, In other cases, the associated response variable may be assigned a value of zero.

Returning to FIG. 7, a schematic diagram for the response variable vector, Y _res , is shown in plot 700. As shown, the value of the response variable associated with the measurement set within period 714 is 1 (eg, Y _{res at} time T _{i + 3} −T _{i + 8} ), while associated with the measurement set outside period 714. The value of the response variable being zero is zero (eg, Y _{res at} times T _i −T _{i + 2} and T _{i + 9} −T _{i + 10} , for example). Other response variables are possible.

  To further illustrate the specific example of defining a failure model based on a response variable, the analysis platform 108 trains the failure model using the historical operational data identified at block 606 and the generated response variable. Can do. Based on this training procedure, the analysis platform 108 then defines the failure model as follows: In the period used to receive various sensor and / or actuator data as input and generate response variables. A fault model that outputs the probability (between zero and one) that a fault will occur within an equivalent period.

  In some cases, variable importance statistics for each sensor and / or actuator are obtained by training with the historical operational data identified at block 606 and the generated response variables. ) May be obtained. The predetermined variable importance statistic is a value that can indicate the relative influence of the sensor or actuator on the probability that a predetermined failure will occur in a future time period.

  Additionally or alternatively, the analysis platform 108 can be configured to define a failure model based on a survival analysis technique, such as a Cox proportional hazard technique. The analysis platform 108 can leverage the survival analysis approach in a manner similar in some respects to the modeling approach described above, but the analysis platform 108 can be used between the last failure and the next expected failure. A survival time-response variable indicative of the amount of time can be determined. The next expected event may be the event that occurs first, either: receipt of sensor and / or actuator measurements, or the occurrence of a fault. This response variable may include a value pair associated with each specific point in time when the measurement value was received. Then, using the response variable, it is possible to determine the probability that a failure within a predetermined period will occur in the future.

  In some exemplary embodiments, the failure model may be defined based on external data, such as weather data and “hot box” data, but other data may also be present. For example, based on such data, the failure model can increase or decrease the output failure probability.

  In practice, the external data can be observed at a time that does not coincide with the time at which the asset's sensor and / or actuator takes a measurement. For example, the time at which “hot box” data is collected (for example, the time when the locomotive passes through the railroad track section where the hot box sensor is installed) is inconsistent with the sensor and / or actuator measurement time. Can do. In such a case, analysis platform 108 may be configured to perform one or more operations to determine an external data observation that would have been measured at a time corresponding to the sensor measurement time. .

  Specifically, the analysis platform 108 can utilize the external data observation time and the measurement time to interpolate the external data observation to provide an external data value for the time corresponding to the measurement time. Interpolation of external data may allow external data observations or features derived therefrom to be included as fault model inputs. In practice, external data can be interpolated with sensor and / or actuator data using various techniques, and other examples are possible, such as nearest neighbor interpolation, linear interpolation, polynomial interpolation, and Spline interpolation or the like can be used.

  Returning to FIG. 6, after the analysis platform 108 determines a failure model for a given failure from the failure set defined in block 602, the analysis platform 108 determines that there are remaining failures to determine the failure model. You can decide whether it is still there. If there are still faults remaining to determine the fault model, the analysis platform 108 may iterate the loop of blocks 604-608. In some embodiments, the analysis platform 108 can determine a single fault model that encompasses all of the faults defined in block 602. In other embodiments, the analysis platform 108 can determine a failure model for each subsystem of the asset 102 and utilize it to determine an asset level failure model. Other examples are possible.

  Finally, at block 610, the defined relationship for each fault in the defined set (eg, individual fault model) is the overall likelihood that the fault will occur within a predetermined period of time in the future (overall can be integrated into a model (eg, a health model) for predicting the likelihood. That is, the model receives sensor and / or actuator measurements as input from one or more sensors and / or actuators, and a single probability that at least one fault belonging to the fault set will occur within a predetermined period in the future. (Single probability) is output.

  The analysis platform 108 can define a health metric model in accordance with several aspects, which may depend on the desired granularity for the health metric. That is, in the case where there are a plurality of failure models, the outcome of the failure model can be utilized in accordance with several aspects to obtain the output of the soundness metric model. For example, the analysis platform 108 can determine a maximum value, median value, or average value from a plurality of failure models and utilize the determined value as the output of the health metric model.

  In another example, the determination of the health metric model can involve the analysis platform 108 weighting the individual probabilities output by the individual fault models. For example, each fault that belongs to a fault set may be considered equally unfavorable, and therefore the same weight can be assigned to each probability in the same manner in determining the health metric model. In other cases, some failures may be considered less favorable than others (eg, more catastrophic failures or failures that require longer repair periods) and therefore correspond to these The establishment can be weighted higher than the others.

In yet another example, the determination of the health metric model may involve the analysis platform 108 utilizing one or more modeling techniques such as a regression technique. The aggregated response variable can be a logical OR for response variables from each of the individual fault models (eg, Y _res in FIG. 7). For example, an aggregated response variable associated with any set of measurements that occurred within any period determined at block 606 (eg, period 714 of FIG. 7) may have a value of 1. On the other hand, the aggregated response variable associated with the set of measurements that occurred outside of any period may have a value of zero. Other definitions are possible for the definition of the health metric model.

  In some embodiments, block 610 may be unnecessary. For example, as described above, analysis platform 108 can determine a single failure model, in which case the health metric model can be a single failure model.

  It should be noted that the soundness score model disclosed in the present application is merely an example of a prediction model for invoking a workflow for adjusting an acceptance operation. Other examples for predictive models can also be used.

  Returning to FIG. 5, the analysis platform 108 can be configured to define a personalized prediction model for the asset, and the operation can involve utilizing the aggregated prediction model as a baseline. . Personalization can be based on specific characteristics of the asset. In this way, the analysis platform 108 can provide a given asset with a more accurate and robust prediction model compared to an aggregated prediction model.

  In particular, at block 506, the analysis platform 108 can be configured to determine whether the aggregation model defined at block 504 should be individualized for a given asset, such as asset 102. The analysis platform 108 can make this decision in several ways.

  In some cases, the analysis platform 108 can be configured to define a personalized prediction model by default. In another case, the analysis platform 108 may be configured to determine whether a personalized prediction model should be defined based on certain characteristics of the asset 102. For example, in some cases, only specific types and classes of assets, assets that operate in specific environments, or assets with specific health scores can be given a personalized prediction model. . In yet another case, the user can define whether an individualized model is defined for asset 102. Other examples are possible.

  Regardless, if the analysis platform 108 decides to define a personalized prediction model for the asset 102, the analysis platform 108 can do this at block 508.

  At block 508, the analysis platform 108 may be configured to define a personalized prediction model in accordance with some aspects. In the exemplary embodiment, analysis platform 108 may define a personalized prediction model based at least in part on one or more characteristics of asset 102.

  Prior to defining a personalized predictive model for the asset 102, the analysis platform 108 may have determined one or more asset characteristics of interest that form the basis of the personalized model. In practice, different prediction models can have different characteristics of interest.

  In general, the property of interest can be a property related to an aggregation model-workflow pair. For example, the characteristic of interest can be a characteristic that the analysis platform 108 has determined to affect the accuracy of the aggregate model-workflow pair. Examples of such characteristics include the following, but there may be other characteristics: asset age, asset usage, asset capacity, asset load, asset health (in some cases The asset health metric, which may be indicated by an asset health metric, see below), the asset class (eg, brand and / or type), and the environment in which the asset is operating.

  The analysis platform 108 can determine the characteristic of interest in accordance with several aspects. In one example, the analysis platform 108 can perform its operations by performing one or more modeling simulations that facilitate the identification of characteristics of interest. In another example, the characteristic of interest can be predefined and stored in the data store of the analysis platform 108. In yet another example, the characteristic of interest may be defined by the user and provided to the analysis platform 108 via the output system 110. Other examples are possible.

  Regardless, after determining the characteristic of interest, analysis platform 108 can determine the characteristic of asset 102 that corresponds to the determined characteristic of interest. That is, the analysis platform 108 can determine the type, value, presence or absence, etc., for the property of the asset 102 that corresponds to the property of interest. The analysis platform 108 can perform this operation in accordance with several aspects.

  To illustrate, the analysis platform 108 can be configured to perform this operation based on data originating from the asset 102 and / or the data source 112. In particular, the analysis platform 108 can utilize operational data and / or data source 112 empty external data for the asset 102 to determine one or more characteristics for the asset 102. Other examples are possible.

  Based on the determined one or more characteristics for the asset 102, the analysis platform 108 may define a personalized prediction model by modifying the aggregation model. The aggregation model can be modified according to several aspects. For example, with respect to modifying an aggregate model, there may be other examples, but it can be done in the following manner: changing one or more model inputs (eg, adding, removing, Reordering, etc.), changing one or more sensor and / or actuator measurement ranges corresponding to asset operating limits, changing one or more calculations, weighting variables or outputs of calculations (Or changing weights), using a different modeling approach than that used to define the aggregation model, and / or different from that used to define the aggregation model Take advantage of response variables.

  In practice, individualizing an aggregation model may depend on one or more characteristics of a given asset. In particular, certain characteristics may affect the modification of the aggregate model in a manner different from other characteristics. In addition, the type, value, presence, etc. of the property can affect the modification. For example, asset age may affect the first part of the aggregation model, while asset class may affect a second part different from the former of the aggregation model. Furthermore, asset age within the first age range can affect the first part of the aggregation model in a first manner, while a second age range that is different from the first range. The asset age within may affect the first part of the aggregation model in a second manner different from the former. Other examples are possible.

  In some embodiments, individualizing the aggregation model may depend on considerations that are added to or substituted for asset characteristics. For example, if the asset is known to be in relatively good operating condition (eg, as defined by a mechanic worker etc.), the aggregation model may be based on asset sensor and / or actuator readings. Can be individualized. More specifically, in the example of a proactive indicator prediction model, the analysis platform 108 provides an indication from the asset that the asset is in good operating condition (eg, from a computing device operated by a mechanic). It can be configured to receive with operating data. And based at least on the driving data, the analysis platform 108 can personalize the leading indicator prediction model for the asset by modifying the respective driving limits corresponding to the “leading indicator” event. Other examples are possible.

  Also, in some embodiments, the analysis platform 108 may be configured to define an individualized prediction model for a given asset without first defining an aggregated prediction model. Please keep in mind. Other examples are possible.

  Once the predictive model is defined, the analysis platform 108 can also be configured to update (eg, change) the model based on the new asset data. For example, based on new operational data received from an asset or other data source, the analysis platform 108 can change the aggregation and / or individualization model for the asset. The analysis platform 108 may perform this update function periodically (eg, daily, weekly, monthly, etc.) and / or in response to some triggered event (eg, receipt of new historical data or occurrence of an event). it can. The analysis platform 108 can also update the prediction model according to other aspects.

  The analysis platform 108 can be further configured to send an aggregated and / or individualized prediction model to other devices and / or systems, where the other devices and / or systems execute the prediction model. To function. As one possible example, the analysis platform 108 may convert the aggregated and / or individualized prediction model to any asset that is configured to execute the prediction model locally (eg, a local analysis device, etc.). Via). The analysis platform 108 may be configured to perform this transmission act periodically or based on triggered events such as any changes or updates to the predictive model.

  Note that devices and / or systems other than analysis platform 108 may be configured to personalize and modify the prediction model. For example, if an asset includes a local analyzer that is configured to receive and execute a predictive model, the local analyzer may be individualized and / or modified with respect to the predictive model alone or with the analysis platform Can also be configured. For details of the operation of a typical local analyzer, see US Patent No. 14 / 963,207, which is incorporated by reference in its entirety.

b. Corresponding Workflow Definitions As described above, the prediction model described above can correspond to one or more workflows, each workflow involving one or more actions to be performed based on the output of the prediction model. One or more workflows can take on various aspects.

  In one embodiment, the one or more workflows can include a workflow to be performed by the analysis platform 108 based on the output of the predictive model. Operations that form part of such a workflow may include the following operations, but may also include other exemplary operations: causing an output system or device to output an indication of a health metric for a given asset Generating an instruction for one or more recommended actions that may affect the health metric for a given asset to the output system or device, and generating a work order to repair the given asset or part thereof Doing, ordering parts for a given asset, and / or encouraging a given asset to change behavior on a given asset via one or more instructions.

  In another embodiment, the one or more workflows can include a workflow to be performed by the asset 102 based on the output of the predictive model. Operations that form part of such a workflow may include the following operations, but may also include other exemplary workflow operations: an asset acquiring data according to a specific data acquisition scheme, specific data Sending data to the analysis platform 108 according to the sending scheme, running a local diagnostic tool, and / or changing the operational state of the asset.

  A particular data acquisition scheme can indicate how an asset acquires data. In particular, the data acquisition scheme shows for specific sensors and / or actuators that an asset uses for data acquisition, eg, a subset of multiple assets and actuators of an asset. Subsets of sensors and / or actuators and the like are envisioned (eg, sensors / actuators of interest). In addition, the data acquisition scheme can indicate the amount of data that the asset acquires from the sensors / actuators of interest and / or the sampling frequency at which the asset acquires such data. The data acquisition scheme may also include various other attributes. In certain exemplary embodiments, a particular data acquisition scheme may correspond to a predictive model for asset health, acquiring more data based on reduced asset health, and / or , Can be tailored to obtain specific data (eg, data from a specific sensor). Alternatively, a specific data acquisition scheme may correspond to a leading indicator system prediction model, and asset sensors and / or based on the increased likelihood of leading indicator events that may represent that a subsystem failure may occur Or it can be adjusted to change the data acquired by the actuator.

  A specific data-transmission scheme may indicate how an asset transmits data to the analysis platform 108. Specifically, the data transmission scheme indicates the type of data that the asset is to transmit (and the scheme can also indicate the format and / or structure of the data), with the following notions as types: Is: data from a particular sensor or actuator, the number of data samples that the asset is to transmit, the frequency of transmission, and / or the data priority scheme that the asset should include when transmitting data. In some cases, a particular data-acquisition scheme can include a data transmission scheme, or the data acquisition scheme can be paired with a data transmission scheme. In some exemplary embodiments, a particular data transmission scheme may correspond to a predictive model for asset health, and adjusts to reduce the frequency of data transmission when asset health exceeds a threshold Can do. Other examples are possible.

  As suggested above, the local diagnostic tool can be a set of procedures stored locally in the asset, or the like. In general, local diagnostic tools can assist in diagnosing the cause of a failure or failure in an asset. In some cases, when a local diagnostic tool is executed, inspection inputs are sent into the asset subsystem or part of it to obtain inspection results, thereby providing fault or failure indications. Can help diagnose the cause. These local diagnostic tools are typically dormant on the asset and are not executed until the asset receives specific diagnostic instructions. There may be other local diagnostic tools. In one exemplary embodiment, a particular local diagnostic tool may correspond to a predictive model for asset subsystem health, based on the subsystem health being below a threshold. Can be executed.

  Finally, it should be noted that a workflow may involve a modification of the asset operating state. For example, one or more actuators of the asset can be controlled to prompt modification of the asset operating state. Various operating conditions can be changed, and there are other examples, including: speed, temperature, pressure, fluid level, draw current, and power distribution. In certain exemplary embodiments, the driving state change workflow may correspond to a predictive model for predicting whether an asset can complete a task in time, and the predicted completion rate (percentage) is Assets can be encouraged to increase the speed of movement when below a threshold.

  In general, defining the workflow described above involves selecting the appropriate workflow action to be performed and defining the conditions that trigger such action based on the output of the predictive model. Come. These triggers can come in various forms. In one example, a workflow trigger can be provided as a threshold (or range of values) for predictive model output (eg, a health metric of 10% or less). As another example, a workflow trigger can be provided as a threshold for the rate of change for the predictive model output. As yet another example, a workflow trigger can be provided as a threshold for the amount of time that the predictive model output has achieved a threshold. Other examples are possible. Further, in some cases, a workflow can have multiple triggering factors (eg, multiple thresholds), each of which can lead to different actions. Note also that one or more thresholds can be set.

  The workflow as described above can be defined in various ways. In one example, the workflow can be defined by the user. For example, a user can operate a computing device that receives user input indicative of a selection for a particular workflow action and trigger, and the computing device can analyze data indicative of such a selection with the analysis platform 108 and And / or provide to the assets 102 themselves, and they implement a user definition of the workflow. As part of this process, the user can access historical driving data, which can assist in the following actions: selecting an appropriate workflow action, defining a trigger, or other Configure the workflow according to the viewpoint.

  In another example, a corresponding workflow can be defined by a machine. For example, the analysis platform 108 can perform various functions such as data analysis and / or simulation, thereby determining a workflow that can help: The cause of the probability output by the predictive model And / or prevent the occurrence of events predicted by the model. While performing these functions, the analysis platform 108 can rely on historical driving data to assist in the following: selecting appropriate workflow actions, defining triggers, or other aspects Configure the workflow according to There may be other examples of defining a corresponding workflow.

  Similar to the prediction model described above, an integrated workflow and an individualized workflow are considered for the workflow. In this regard, the analysis platform 108 can define a personalization workflow for a given asset using techniques similar to those described above with respect to the personalized prediction model (eg, one or more of the given asset). To modify the aggregation workflow based on characteristics).

  Further, similar to the prediction model, the workflow can be changed based on new asset data. For example, based on new data received from assets or other data sources, the analysis platform 108 can make changes to the aggregation workflow and / or the personalization workflow. This modification function can be performed periodically (eg, daily, weekly, monthly, etc.) and / or in response to some trigger event (eg, upon receipt of new historical data or the occurrence of an event). . The workflow may be changed according to other aspects.

  Further, the analysis platform 108 can be configured to send the aggregated workflow and / or personalized workflow to other devices and / or systems, and the devices and / or systems execute the workflow. can do. In one possible example, the analysis platform 108 is configured to execute an aggregated workflow and / or an individualized workflow locally (eg, via a local analyzer or the like). Can be sent to any asset. The analysis platform 108 may be configured to perform this transmission operation periodically or based on a triggering event such as any change or update to the predictive model.

  Note also that a workflow may be defined, personalized, and / or modified by devices and / or systems other than the analysis platform 108. For example, an asset can be configured to define, personalize, and / or modify a workflow (via a local analysis device, central processing unit, etc.), either alone or on the analysis platform 108. You can make them together. As described above, the operation of the representative local analyzer 5 is described in more detail in Patent Document 1.

c. Executing Model-Workflow Pairs Once a predictive model and corresponding workflow are defined, the model-workflow pair can be deployed for runtime execution. Thereafter, the analysis platform 108, (eg, via a local analysis device, central processing unit, etc.) the asset or some combination thereof can perform a model-workflow pair using the operational data.

  For example, in one embodiment, the analysis platform 108 can be configured to execute both the predictive model and the corresponding workflow. According to this embodiment, the analysis platform 108 receives driving data for a given asset, provides at least a portion of the driving data as an input to the prediction model, and executes a corresponding workflow based on the output of the prediction model can do.

  In another embodiment, the analysis platform 108 can be configured to run a predictive model for a given asset, while the given asset itself is configured to run a corresponding workflow. be able to. According to this embodiment, the analysis platform 108 receives driving data for a given asset, provides at least a portion of the driving data as an input to the prediction model, and based on the output of the prediction model, A signal can be issued, and the other party can then execute the corresponding workflow.

  In yet another embodiment, a given asset can be configured to execute a predictive model, while the analysis platform 108 can be configured to execute a corresponding workflow. According to this embodiment, a given asset can provide at least a portion of its driving data as an input to the prediction model and can signal the analysis platform 108 based on the output of the prediction model. The other party can execute the corresponding workflow.

  In yet another embodiment, a given asset can be configured to execute both a predictive model and a corresponding workflow. According to this embodiment, a given asset can provide at least a portion of its driving data as an input to a prediction model and execute a corresponding workflow based on the output of the prediction model.

  As will be described here again, as described above, the operation of a typical local analyzer is described in more detail in Patent Document 1.

2. Other Workflows In some embodiments, driving data for a given asset is also used to define, change, and execute other asset driving related workflows that do not correspond to the predictive model. These workflows can take various forms.

  An example of such a workflow is a notification providing process that is performed based on driving data. For example, the analysis platform 108, asset, or some combination thereof may execute a workflow that supports the following notification: a specific abnormal condition indicator generated for a given asset (or a specific combination of abnormal condition indicators) Notification that tells the user about the. As another example, analysis platform 108, an asset, or some combination thereof may perform a workflow that results in the following notification: a predetermined sensor value for a given asset satisfies a threshold condition that represents an abnormal value A notification telling the user that he has done. These notifications can take a variety of forms, examples of which include alerts presented via graphical user interfaces, emails, text messages, and the like.

  Another such workflow includes a process for sharing received operational data with other devices and / or systems. For example, the analysis platform 108 may execute a workflow that communicates operational data received from a particular asset to one or more other analysis platforms. There can also be various other workflows that are based on operational data.

  These workflows can be defined, changed, and executed in a manner similar to the workflow described above corresponding to the prediction model.

C. Ignoring Uncertain Driving Data As mentioned above, it may be undesirable for the analysis platform 108 (and / or the asset's local analyzer) to use the driving data for the asset in the normal way, for example, A process for defining, modifying and / or executing a model-workflow pair or other workflow is envisioned as such. Such a case may be applicable when the asset is located in a specific place of interest (for example, in a repair shop or tunnel). If there is an asset in such a place, the asset is representative. There is a tendency to operate in a non-targeted manner or to generate uncertain data in other ways. Therefore, if a given asset generates driving data while being placed in such a location of interest, avoid using such driving data when dealing with predictive models related to asset behavior It may be desirable for the analysis platform 108 (and / or a local analytics device for a given asset). After leaving the place where the predetermined asset is of interest, the analysis platform 108 and / or the local analytics platform can resume use and use the operational data of the predetermined asset as usual.

  Generally speaking, ignoring actions performed on uncertain driving data can be performed in various ways. FIG. 8 shows a flow diagram 800 for an exemplary method having one possibility for ignoring driving data based on asset location data. Although the exemplary method 800 is described as being performed by an asset monitoring system for exemplary purposes, the method 800 may be performed by other platforms, systems, and / or devices. One skilled in the art will understand that the method 800 is provided for clarity and explanation purposes only, and a number of other motion combinations can be utilized to ignore operating data. You will understand.

  As shown in FIG. 8, the method 800 may involve maintaining data indicating one or more locations of interest at block 802, each of the locations of interest being driven from an asset. Represents a place where data can be uncertain. The method 800 may involve, at block 804, determining that location data for a particular asset (eg, asset 102) matches one of the locations of interest. The method 800 may involve, at block 806, ignoring specific asset driving data in handling a predictive model for driving multiple assets.

  The function of the exemplary method 800 is described in further detail below. Specifically, the described method 800 is performed by an asset monitoring system, which may be embodied as the analysis platform 108 or as a local analysis device for the asset 102. In certain embodiments, the analysis platform 108 and the local analysis device of the asset 102 may perform the operations of the method 800 in a coordinated manner. Other examples are possible.

  Regardless, at block 802, the method 800 may involve the following processing: maintaining data that the asset monitoring system indicates about one or more locations of interest. As described above, a place of interest is a place where assets tend to generate uncertain driving data. That is, the location of interest is a location where the asset generates operational data that can result in a treatment that is not representative of the model-workflow pair. Therefore, the place of interest represents the place where the driving data from the asset should be ignored.

  In practice, the location of interest can be a single point in space or an area that encompasses multiple points in space. For example, a location of interest represented as a single point in space can be a geographical location that can be identified by latitude and longitude coordinates, for example, and a location of interest represented as a region can be, for example, a land boundary It may be a geographical area that can be identified by a description, multiple latitude and longitude coordinates, or some other boundary identifier. In particular examples, the location of interest can be identified using a geofence or the like. Other examples are possible.

  There are many examples of places of interest. Examples of places of interest include the following exemplary types: places where malfunctioning assets accumulate, places where asset operating conditions tend to be temporarily abnormal, and assets are ideal (or nearly ideal) ) Places that work in context or work without being exposed to real world stress. Examples of locations where misbehaving assets accumulate may include the following, and other examples: repair shops or repair shops, asset inspection facilities, and other locations where diagnostics are typically performed. Examples of places where asset operating conditions are likely to be temporarily abnormal can include the following, and other examples: tunnels and other places where assets are confined, steep uphills and steep descents Locations with slopes or other extreme terrain, and locations with higher or lower temperatures than normal and other extreme environmental conditions. Examples of places where assets operate in an ideal or near-ideal context can include the following, as well as other examples: asset dealer stores and the like.

  Regardless, the operation that the asset monitoring system maintains data indicating one or more locations of interest can be done in various ways. In an exemplary embodiment, this operation may involve the asset monitoring system receiving data indicating one or more locations of interest and storing such data in a storage. In such an embodiment, a location where another device or system is of interest can be defined and provided to the asset monitoring system.

  For example, the asset monitoring system can receive a message identifying one or more places of interest from the computing system or device, possibly with an indication that they are actually places of interest. In practice, the user can provide input identifying the location of interest at the computing system or device. The computing system or device can then send a message about the interesting location based on those inputs to the asset monitoring system, and the asset monitoring system indicates the interesting location identified in the message. Data can be retained.

  In another example where the local analyzer of the asset 102 performs the method 800, the local analyzer can maintain data indicating one or more places of interest by doing the following: Receiving a message about the location of interest and storing in memory a data indicating the location of interest identified in the message. Other examples are possible.

  In another exemplary embodiment, maintaining data that the asset monitoring system indicates about one or more locations of interest may involve the following: The asset monitoring system itself may identify one or more locations of interest. Define and store those places of interest of interest. In practice, the asset monitoring system can define places of interest in various ways.

  For example, the asset monitoring system may define locations of interest based on location data for multiple assets. In particular, the asset monitoring system can perform this operation with historical location data, current location data, or a combination thereof. In general, defining an interesting location based on asset location data by an asset monitoring system can involve: location data and possibly additional information associated with that location data. (E.g., a property of an asset that is expressed while being placed at a position indicated by position data) to infer that there is a predetermined place of interest, and the estimation is made in various ways. obtain.

  For example, an asset monitoring system aggregates location data from multiple assets, analyzes the aggregated location data, identifies any locations where assets tend to “float”, and these cluster locations are of interest. It can be inferred that it corresponds to the target location. More specifically, when an asset operates, the asset can provide each location data to the asset monitoring system, which can be stored in a database or the like. Assets can provide such data periodically, continuously, or in conjunction with specific triggering events, and other examples are possible.

  9A, 9B, 9C represent schematic schematics for asset location data at various times that the asset monitoring system can store. FIG. 9A shows asset location data 902 for an exemplary geographic region 900 at a first point in time. Each asset location data 902 corresponds to a particular asset and represents the location of that specific asset within the geographic region 900 at a first point in time. FIG. 9B shows asset location data 904 for the geographic region 900 at the second time point. As is the case here, each asset location data 904 corresponds to a particular asset and represents the location of that particular asset within the geographic region 900 at a second point in time. It should be noted that the asset location data 904 can correspond to one or more different assets in relation to those corresponding to the asset location data 902 of FIG. 9A. Similarly, FIG. 9C shows asset location data 906 for a geographic region 900 at a third point in time. Each asset location data 906 corresponds to a particular asset and represents the location of that specific asset within the geographic area 900 at a third point in time. Asset location data 906 may correspond to one or more different assets in relation to those corresponding to asset location data 902 in FIG. 9A and / or to those corresponding to asset location data 904 in FIG. 9B.

  Based on historical location data, the asset monitoring system identifies any location where assets cluster from a historical point of view, and this operation can be done in various ways. In general, this action may involve the following, and other examples are possible: where the asset monitoring system is where the data point density exceeds the density threshold and / or data points and other data points Determine the location where the distance between is within the proximity distance threshold. In an exemplary embodiment, the asset monitoring system performs a clustering analysis on historical position data to identify locations where assets tend to cluster. An exemplary clustering analysis may include the execution of the following models, and there may be other clustering related models: connectivity model, distribution model, density model, and / or group model.

  Additionally or alternatively, statistical classification techniques that utilize controlled learning algorithms are used to identify places of interest. Exemplary statistical classification techniques include the following, and may be other statistical classification techniques: logistic regression and linear classifiers such as naive Bayes classifiers, support vector machines, k-nearest neighbor classification , Random forest model, learning vector, and quantized neural network.

  In practice, the asset monitoring system can identify the places of interest by analyzing the following data and using statistical classification techniques: including all or part of the same driving data entered into the predictive model Data about the response variables associated with the data obtained, asset location data, and the results of the predictive model. The response variable can be derived in a manner similar to FIG. For example, identification can be made when the prediction model is operating in a non-typical manner (eg, utilizing uncertain driving data). The response variable and the associated motion and position data values for these times are set to 1. All other time and position response variable values are zero. The algorithm analyzes this data to identify locations that are correlated with assets that operate in a manner that is temporarily not representative. Other exemplary response variables are possible.

  FIG. 10 shows a schematic diagram for historical asset-position data that may be subjected to analysis regarding cluster discovery. FIG. 10 shows the same area as the geographic area 900 of FIGS. 9A-9C and includes asset-position data 902, 904, 906 from FIGS. 9A, 9B, and 9C, respectively. The asset monitoring system may analyze such aggregated historical asset location data for the cluster using any of the techniques described above, and in this example, the result that the asset monitoring system identifies the cluster 1000. Can occur.

  After the asset monitoring system identifies any clusters, the system may define places of interest based on the given clusters. This operation can be done in various ways. In one example, this operation may involve: the asset monitoring system determining whether a given cluster is associated with some information that can be inferred to be a place of interest. There may be many other examples, but the information may indicate, for example: the presence of a given cluster in the vicinity of where a number threshold asset part is ordered or delivered within a time threshold, a given cluster Assets tend to output more abnormal status indicators while placed in the vicinity, and assets tend to output the same or similar abnormal status indicators while placed near a given cluster Or, there is a tendency for assets having a health metric less than a threshold to gather around a predetermined cluster.

  Regardless, the asset monitoring system may define places of interest near each cluster in various ways. Specifically, in one example, the asset monitoring system may define a location of interest as a point within an area covered by various data points that define the cluster. This point may or may not correspond to an asset-position data point. In some such cases, the asset monitoring system may further define an area around the point as a location of interest, such as a radius around the point.

  In other cases, the asset monitoring system may define a location of interest as an area that encompasses all or part of the data points that define the cluster. Such regions can take various shapes: circles, squares, rectangles, triangles, free-form shapes, etc. An example is shown in FIG. 11, which shows a schematic diagram of defined places of interest. As shown, FIG. 11 shows a location 1100 of interest, which is defined as an area that encompasses each asset location data point that defines the cluster 1000. There can be other examples of predefined places of interest.

  Additionally or alternatively, the act of the asset monitoring system defining a location of interest based on a given cluster may involve the following: selecting data indicative of the location of interest into a computing system or device To receive from. More specifically, the asset monitoring system can cause a computing system (eg, output system 110) or device to do the following based on the identified cluster: at a location corresponding to the identified cluster Display an indication that there is probably a place of interest. The computing system can then receive an input selection (eg, from a user) that selects, outlines, or otherwise identifies a location to be defined as a location of interest. For example, the user can provide an input selection that provides a geofence around the suggested location. Regardless, this input selection is provided to the asset monitoring system, which defines places of interest based on the input selection.

  The asset monitoring system can define places of interest in other ways as well. For example, the asset monitoring system can define a location of interest based at least on an instance that indicates that a given asset was at a particular location of interest. Specifically, the asset monitoring system can determine an instance (eg, date and / or time) that was known to have a given asset at a particular location of interest. For example, based on a repair shop log, the asset monitoring system may determine that the asset 102 was repaired at a repair shop on a predetermined date. The asset monitoring system can then determine the location of the predetermined asset in that particular instance. For example, the asset monitoring system can determine the GPS coordinates of the asset 102 on a given day.

  The asset monitoring system can then define locations of interest based on the determined location of a given asset in a particular instance. For example, in some embodiments, the asset monitoring system can define a determined location of a given asset in a particular instance as a location of interest. Alternatively, the asset monitoring system uses the determined location of a given asset as a starting point for finding a location of interest, and uses other historical asset location data to define the location boundary of interest. be able to.

  Returning to FIG. 10 to illustrate these, the asset location data 1002 may correspond to the location of the asset 102 on a given date determined by the asset monitoring system, where the asset 102 is being repaired at the repair shop. Suppose that. Then, the asset monitoring system can determine the boundary of a place of interest (for example, a repair shop) based on historical position data close to the asset position data 1002. In an exemplary embodiment, a data point within a threshold distance from asset location data 1002 may be utilized to define a location boundary of interest. Other examples are possible.

  In yet another exemplary embodiment, the asset monitoring system can define a location of interest based at least on abnormal condition data generated by the asset. For example, the places of interest can be: places where assets tend to generate a relatively large number of abnormal condition indicators and / or assets that tend to generate abnormal condition indicators. There are many places. Thus, it may be useful to identify locations where there is a “rapid increase” in abnormal state activity using an asset monitoring system.

  Specifically, based on the historical abnormal state data of a plurality of assets, the asset monitoring system can determine the asset position where the abnormal state index is activated. And in an aspect similar to the above, the asset monitoring system can define a location corresponding to a location where abnormal state activities are relatively highly concentrated as a location of interest. There may be other examples of defining places of interest.

  Returning to FIG. 8, at block 804, the method 800 may include the following operations: The asset monitoring system may identify one of the locations of interest where the location data for a particular asset (eg, asset 102) is defined at block 802. To decide that In practice, as described above, the asset monitoring system can receive location data for multiple assets, and the asset monitoring system can also receive received location data (eg, with or separately from location data). , Each data corresponding to the operation data) can also be received. Regardless, based on location data for multiple assets, the asset monitoring system can determine which of such location data matches any location of interest. The asset monitoring system can make this determination according to various aspects.

  For example, this action may include the following: An asset monitoring system may retrieve location data from the asset 102 (or another system such as a location system) that reflects the location of the asset 102 at a past or current time. To receive. In the exemplary embodiment, as described above, the location data may correspond to the location of asset 102 when asset 102 generated driving data or otherwise collected. Regardless, based on this location data, the asset monitoring system can determine whether the location of the asset 102 matches any of the locations of interest.

  Actually, if the position data of the asset 102 corresponds to the next place, it is considered that the position of the asset 102 matches the place of interest, but there are other examples: (1) Interest A location that is equal to the location of interest (for example, if the GPS coordinates of the asset 102 are equal to that of the location of interest), (2) a location that is within the boundaries of the location of interest (eg, the location of interest is defined as a region) Or (3) a location that is within a threshold distance or meets other proximity requirements in relation to the location of interest (eg, the location of interest is defined as a single point or region) If you have).

  In an exemplary embodiment in which the asset monitoring system is a local analyzer for asset 102, the following operations may be performed with respect to the local analyzer making a determination that the location data of asset 102 matches the location of interest. Is concerned: the local analyzer determines the position of the asset 102 based on, for example, position data from the position unit of the asset 102. The local analysis device can then compare the location of the asset 102 with each interesting location stored in memory to determine if the asset 102 is in the interesting location. Other examples are possible.

  By way of example, FIGS. 12A, 12B, 12C show schematic schematics for asset location data in relation to defined places of interest at various times. As shown, FIGS. 12A-12C include the geographic region 900 of FIGS. 9A-9C and the defined location of interest 1100 of FIG. 11, respectively. FIG. 12A includes asset position data corresponding to a plurality of assets at the fourth time point, and also includes asset position data 1200 corresponding to the asset 102. Based on such asset location data, the asset monitoring system does not determine that the asset 102 is in a location of interest.

  FIG. 12B includes asset position data corresponding to a plurality of assets at the fifth time point, and also includes asset position data 1200 corresponding to the asset 102. As shown, asset position data 1200 at this point in time indicates the asset location within the location 1100 of interest. Accordingly, based on the asset location data 1200 of the asset 102, the asset monitoring system will determine that the asset 102 is in a location of interest.

  Another example is FIG. 12C, in which asset position data corresponding to a plurality of assets at the sixth time point is included, and asset position data 1200 corresponding to the asset 102 is included. As shown, the asset 102 is moving relative to the position shown in FIG. 12, but the asset position data 1200 is still in the location 1100 of interest. Thus, the asset monitoring system will determine that the asset 102 is in the location of interest. The asset monitoring system will also determine that two other assets are also in the location of interest.

  In another exemplary embodiment, for an asset monitoring system that is trying to determine if any location data matches any of the locations of interest, the following actions may be taken: the asset monitoring system is interested in the asset 102 Receiving an indication from the asset 102 that it is within the target location. In particular, asset 102 may receive data identifying a location of interest, for example from analysis platform 108, and asset 102 may store this in memory. In operation, asset 102 monitors its current location and determines whether its current location is within some interesting location. The asset 102 can then send a message to the asset monitoring system if the asset 102 is within any one interesting location. There may be other examples of determining whether the asset location data matches the location of interest.

  At block 806, the method 800 may include the following actions: the asset monitoring system ignores driving data for the asset 102 in handling a predictive model related to the actions of the plurality of assets based on the determination of the block 804. In practice, this action may initially involve the following actions: The asset monitoring system determines to ignore the operational data for asset 102 in handling the predictive model in response to the determination of block 804. A prediction model is then handled based on this determination, which may involve the following actions: the asset monitoring system ignores the driving data for the asset 102.

  In practice, the decision to ignore the operational data for asset 102 can be made in several widths. For example, the asset monitoring system may ignore the following data: all or part of the driving data for the asset 102 received by the asset monitoring system after the decision (in some cases the asset location data no longer matches the location of interest The range until the asset monitoring system decides what to do), all or part of the operational data that it received before the decision, or any combination thereof. Additionally or alternatively, the asset monitoring system may decide to ignore all or part of the driving data of the asset 102 corresponding to the location data that triggered the decision. For example, as described above, the position data can correspond to driving data (eg, the predetermined position data can reflect the position where the asset 102 was present when the predetermined driving data was generated), Therefore, it can be determined that only the driving data corresponding to the position data matching the location of interest is ignored. There may be other examples of decisions.

  In accordance with the decision, an asset monitoring system that handles a predictive model for asset operation can be handled in various ways. For example, before deciding to ignore driving data for asset 102, the asset monitoring system may have operated in the following manner: based on driving data for assets including asset 102 A model-workflow pair has been defined and / or a model-workflow pair has been modified or executed based at least on the operational data for the asset 102. After the decision, the asset monitoring system may transition to handle the prediction model and / or the corresponding workflow in different ways, but there may be other differences.

  For example, after the determination, the asset monitoring system can ignore the operation data for the asset 102 when handling the prediction model, otherwise it refrains from handling the prediction model based on the operation data for the asset 102. More specifically, before the determination, the asset monitoring system defines a prediction model based on driving data for a plurality of assets including the asset 102, but after the determination, the asset monitoring system operates for the asset 102. A prediction model can be defined based on driving data for multiple assets that does not include data (i.e., exclude driving data for asset 102).

  Additionally or alternatively, the asset monitoring system can execute a predictive model for each asset of the plurality of assets based on each driving data before the decision, but after the decision the asset monitoring system A predictive model can be run for each asset in the plurality of assets, and for asset 102, the predictive model is forgotten. In embodiments where the asset monitoring system is a local analysis device for asset 102, the local analysis device may forego execution of a predictive model for asset 102 after the decision is made. In addition, the local analyzer may refrain from sending operational data to the analysis platform 108.

  Additionally or alternatively, the asset monitoring system can update (eg, change) the predictive model based on operational data for one or more assets, including asset 102, prior to the decision, The asset monitoring system can update the prediction model based on the driving data for multiple assets without including the driving data for the asset 102 (ie, excluding the driving data for the asset 102).

  In practice, the function of ignoring the operation data of a predetermined asset when handling a prediction model can be implemented in various ways. For example, if the asset monitoring system is the analysis platform 108, the data receiving system of the analysis platform 108 may turn around without accepting operational data for the asset 102 (eg, block or otherwise filter out). Or the data acceptance system accepts operational data for the asset 102 but can walk around without communicating such data to the data analysis system of the analysis platform 108, or the data analysis system can operate around the asset 102. Even if the data is received, it is possible to choose to forego the use of such data as input to a predictive model related to the behavior of the asset. If the asset monitoring system is a local analysis device for asset 102, the local analysis system will turn around without accepting operational data from asset 102, or accept such data, but use such data as input to the predictive model And / or may refrain from sending operational data to the analysis platform 108. Other examples are possible.

  Regardless, the treatment of the predictive model made in accordance with the decision to ignore the operational data for asset 102 may allow the asset monitoring system to do the following in a more desirable manner: related to the behavior of the asset Handling predictive models and corresponding workflows. For example, the asset monitoring system may provide driving data for assets 102 (as well as any other assets in the location of interest) that may be located in locations where the asset 102 will output uncertain data. Can be ignored, thereby contributing to maintaining the integrity of the prediction model with respect to other assets and / or with respect to the future execution of the prediction model for asset 102. There may be other advantages.

  In some embodiments, the asset monitoring system additionally or alternatively responds differently from other actions in response to determining that the location data for asset 102 matches the location of interest. You can get none. For example, in response to the determination, the asset monitoring system may communicate in a different manner when communicating with other systems. In particular, before the determination, when the data indicates that an abnormal state has occurred in the asset 102 (when the operation data of the asset 102 satisfies a specific criterion), the asset monitoring system uses the output device. Alternatively, the system (eg, output system 110) can be forced to output an abnormal condition indicator (eg, fault code) based on the operational data of asset 102. After the decision, the asset monitoring system forced the output device or system to output an abnormal condition indicator even if the operational data from the asset 102 indicated the presence of an abnormal condition in the asset 102 Can be stopped (forcing off in the first case).

  In another example, additionally or alternatively, the asset monitoring system can ignore driving data for some prediction models and utilize driving data for other prediction models. For example, in the exemplary embodiment, the asset monitoring system ignores operational data for predictive models related to asset operations (eg, predictive models for health metrics and other predictive models for asset operations in the field). Yes, operational data about predictive models related to the performance of asset repairs (or other predictive models related to non-representative contexts about assets) can be leveraged. Includes models such as: predictive models that help provide mechanics and other repair-related workers who repair assets to provide repair-related recommendations. There may be other examples of how the asset monitoring system operates differently.

  At some point after deciding to handle the prediction model according to the decision to ignore the operational data for asset 102, the asset monitoring system can transition and return to the operational state prior to the decision. This transition occurs for a variety of reasons. For example, the asset monitoring system may determine that the asset 102 has left the location of interest 1100 based on the location data of the asset 102. In another example, a time trigger or another trigger occurs, leading to a transition for the asset monitoring system to return. Other examples are possible.

V. Exemplary Method Turning to FIG. 13, a flow diagram illustrating functions that may be performed in accordance with an exemplary method 1300 for handling asset driving data based on asset location data is illustrated. For purposes of illustration only, these functions are described as being performed by analysis platform 108. However, it should be noted that one or more of these functions may be performed by other devices or systems. It should also be noted that specific functions can be added to the exemplary method 1300 and / or specific functions described below can be modified or removed from the exemplary method 1300.

  At block 1302, the method 1300 may involve the following steps: the analysis platform 108 receiving location data for each of the plurality of assets. In some cases, the analysis platform 108 may also receive driving data corresponding to the position data (eg, driving data generated by a given asset when placed at the position indicated by the position data. ). At block 1304, the method 1300 may involve the following steps: The analysis platform 108 may determine where the predetermined location data for a predetermined asset of the plurality of assets is associated with uncertain driving data (eg, A step of determining whether or not it matches a location of interest. At block 1306, the method 1300 may involve the following steps: In response to the determination at block 1304, the operational data for a given asset in the analysis platform 108 when dealing with a predictive model for the behavior of multiple assets. Step to decide to ignore. At block 1308, the method 1300 may involve the following steps: the analysis platform 108 handling the predictive model according to the decision made at block 1306.

  FIG. 14 shows a flow diagram representing functions that may be performed in accordance with an exemplary method 1400 for handling asset operational data based on asset location. For purposes of illustration only, these functions are described as being performed by a local analyzer of asset 102. However, it should be noted that one or more of these functions may be performed by other devices or systems. It should also be noted that certain functions may be added to the example method 1400 and / or certain functions described below may be modified or removed from the example method 1400.

  At block 1402, method 1400 may involve the following steps: a local analyzer receiving location data for asset 102. In some cases, the local analyzer may also receive driving data corresponding to the position data (eg, driving data generated by the asset 102 when placed at the position indicated by the position data. ). At block 1404, the method 1400 may involve the following steps: The local analyzer matches the predetermined location data for the asset with a location (eg, location of interest) associated with uncertain driving data. Step to decide. At block 1406, the method 1400 may involve the following steps: In response to the determination of block 1404, the local analysis device may handle a predictive model for the behavior of multiple assets, including the asset 102, for the asset. A step of deciding to ignore the operation data. At block 1408, the method 1400 may involve the following steps: the local analyzer handling the prediction model according to the decision made at block 1406.

VI. CONCLUSION Exemplary embodiments relating to the disclosed innovation have been described above. However, one of ordinary skill in the art appreciates that changes and modifications can be made to the disclosed embodiments without departing from the true scope and spirit of the invention as defined by the appended claims. Will.

Further, where the disclosed examples involve operations performed or initiated by actors such as “humans”, “operators”, “users” or other entities, such descriptions are for illustrative and explanatory purposes. It is only provided. Unless the language of a claim explicitly requires an action by such an actor, the claim should not be construed as requiring an action by such an actor.

Claims (20)

A computing system,
At least one processor;
A non-transitory computer readable medium;
Program instructions stored on the non-transitory computer readable medium when executed by the at least one processor to the computing system,
Receiving location data for each of a plurality of assets;
Determining whether predetermined position data for a predetermined asset of the plurality of assets matches a location associated with uncertain driving data;
In response to the determination, deciding to ignore driving data for the predetermined asset in the case of handling a prediction model for the driving of the plurality of assets;
And a command for causing the step of handling the prediction model according to the determination. The computing system of claim 1, wherein the program instructions stored on the non-transitory computer readable medium are executed by the at least one processor to the computing system.
A computing system further comprising the step of receiving driving data corresponding to the position data for each of the plurality of assets.   The computing system according to claim 2, wherein the step of handling the prediction model according to the determination excludes the driving data corresponding to the predetermined position data for the predetermined asset. Defining the prediction model based on the driving data corresponding to the location data.   3. The computing system of claim 2, wherein the prediction model has been previously defined by the computing system, and the step of handling the prediction model according to the determination comprises the predetermined position for the predetermined asset. A computing system comprising: changing the prediction model based on the driving data corresponding to the position data for the plurality of assets, excluding the driving data corresponding to data.   The computing system of claim 1, wherein handling the prediction model according to the determination includes forcing the execution of the prediction model for the predetermined asset. The computing system of claim 1, wherein the location associated with uncertain driving data is a first location, and the program instructions stored on the non-transitory computer-readable medium are: When executed by at least one processor, the computing system includes:
A computing system further comprising: prior to the determination, defining one or more locations associated with uncertain driving data, wherein the one or more locations include the first location.   7. The computing system of claim 6, wherein defining the one or more locations is based at least on historical location data for one or more of the plurality of assets.   The computing system of claim 1, wherein determining that the predetermined location data for the predetermined asset of the plurality of assets matches the location associated with uncertain driving data comprises: Determining that the position data corresponds to a position within a threshold distance from the location associated with uncertain driving data. The computing system of claim 1, wherein the program instructions stored on the non-transitory computer readable medium are executed by the at least one processor to the computing system.
Prior to the determination, causing the computing device to output an indication of an abnormal condition if the operational data for the predetermined asset meets certain criteria;
In response to the determination, forcing the computing device to output the instruction for the abnormal condition if the operational data for the predetermined asset satisfies the specific criteria. , Computing systems. A non-transitory computer-readable medium having executable instructions stored thereon, wherein execution of the instructions causes the computing system to
Receiving location data for each of a plurality of assets;
Determining whether predetermined position data for a predetermined asset of the plurality of assets matches a location associated with uncertain driving data;
In response to the determination, deciding to ignore driving data for the predetermined asset in the case of handling a prediction model for the driving of the plurality of assets;
A non-transitory computer readable medium that causes the prediction model to be handled according to the determination.   The non-transitory computer readable medium of claim 10, wherein the program instructions stored on the non-transitory computer readable medium correspond to the location data for each of the plurality of assets to the computing system. A non-transitory computer readable medium for further performing the step of receiving operational data.   12. The non-transitory computer readable medium of claim 11, wherein the step of handling the predictive model according to the determination comprises excluding the driving data corresponding to the predetermined position data for the predetermined asset. A non-transitory computer readable medium comprising defining the prediction model based on the driving data corresponding to the location data for an asset.   12. The non-transitory computer readable medium of claim 11, wherein the prediction model has been previously defined by the computing system, and handling the prediction model according to the determination comprises the step for the predetermined asset. A non-transitory computer readable medium comprising: changing the prediction model based on the driving data corresponding to the position data for the plurality of assets, excluding the driving data corresponding to predetermined position data.   The non-transitory computer readable medium of claim 10, wherein handling the prediction model according to the determination includes forcing the execution of the prediction model for the predetermined asset. The non-transitory computer readable medium of claim 10, wherein the program instructions stored on the non-transitory computer readable medium are transmitted to the computing system.
Prior to the determination, causing the computing device to output an indication of an abnormal condition if the operational data for the predetermined asset meets certain criteria;
In response to the determination, forcing the computing device to output the instruction for the abnormal condition if the operational data for the predetermined asset satisfies the specific criteria. A non-transitory computer readable medium. A computer-implemented method comprising:
Receiving position data for each of a plurality of assets by a computing system;
Determining, by the computing system, predetermined location data for a predetermined asset of the plurality of assets matches a location associated with uncertain driving data;
In response to the determination, in the case of handling a prediction model related to the driving of the plurality of assets, the computing system determines to ignore driving data for the predetermined asset;
Handling the prediction model according to the determination by the computing system.   The computer-implemented method of claim 16, wherein the location associated with uncertain driving data is a first location, and the method is associated with uncertain driving data prior to the determination. Defining the one or more locations by the computing system, the one or more locations further comprising the first location.   The computer-implemented method of claim 17, wherein the step of defining the one or more locations is made based at least on historical location data for one or more of the plurality of assets.   The computer-implemented method of claim 16, wherein determining that the predetermined location data for the predetermined asset of the plurality of assets matches the location associated with uncertain driving data comprises: Determining that the predetermined position data corresponds to a position within a threshold distance from the location associated with uncertain driving data. The computer-implemented method of claim 16, wherein handling the prediction model according to the determination includes forcing the execution of the prediction model for the predetermined asset.

Images