WO2020077430A1

WO2020077430A1 - Method and system for processing operating condition data associated with execution of a process

Info

Publication number: WO2020077430A1
Application number: PCT/CA2018/000196
Authority: WO
Inventors: Ev HAUS; Maksym KUZNETSOV; Ryan Gregory MACLEOD; Malcom John ELLIS
Original assignee: Eight Solutions Inc.
Priority date: 2018-10-15
Filing date: 2018-10-15
Publication date: 2020-04-23

Abstract

A system and computer implemented method for processing operating condition data associated with execution of a process is disclosed, the data being uploaded to a data store accessible over a network. The method involves causing a processor circuit to launch a pipeline editor service to provide access to the operating condition data via a pipeline editor interface on a user device, receiving user inputs defining a data pipeline including at least one source node defining at least one operating condition included in the operating condition data, at least one export node defining an operating condition output for the data pipeline, and links between the at least one source node and the export node defining an execution sequence for the execution of associated functions. The method further involves generating a blueprint including codes for implementing each of the nodes and being operable to cause a pipeline execution service to implement the pipeline.

Description

METHOD AND SYSTEM FOR PROCESSING OPERATING CONDITION DATA ASSOCIATED WITH EXECUTION

OF A PROCESS

BACKGROUND

1. Field

This disclosure relates generally to monitoring operating conditions of a process being executed and more specifically to methods and systems for processing the operating condition data to produce an operating condition output.

2. Description of Related Art

When executing a process that involves a number of steps or processing stations, which may involve associated equipment, various operating conditions associated with the process may be monitored. For example, in a plant that processes incoming materials at one or more processing stations to produce an output material, the processing stations may have sensors that monitor operating conditions of equipment, throughput of material over time, and other organizational information associated with operations of the plant. The operating conditions may be represented by data that is captured and stored in a database for later analysis. It is fairly typical that it is easier to capture a wealth of information than to process and analyze the information to provide useful outputs that are sufficiently meaningful and timely to be useful in daily operation of the plant. There remains a need for methods and systems that simplify the processing and analysis of operating condition data generated while executing a process.

SUMMARY

In accordance with one disclosed aspect there is provided a computer implemented method for processing operating condition data associated with execution of a process, the operating condition data being uploaded to a data store accessible over a data network. The method involves, in response to a request received from a user device in communication with the data network, causing a processor circuit to launch a pipeline editor service operable to provide access to the operating condition data via a pipeline editor interface made available for display on the user device. The method also involves receiving from the user device via the pipeline editor interface, user inputs defining a data pipeline. The data pipeline includes at least one source node defining at least one operating condition included in the operating condition data stored at the data store, at least one export node defining an operating condition output for the data pipeline, and links between the at least one source node and the at least one export node defining an execution sequence for the execution of functions associated with each node. The method further involves causing the processor circuit to generate a data pipeline blueprint including codes for implementing each of the nodes, the blueprint being operable to cause a pipeline execution service to implement the data processing pipeline.

The data pipeline may further include one or more operator nodes, each defining an operation to be performed on the least one operating condition to produce the operating condition output, the links further including links between the at least one source node, the one or more operator nodes and the at least one export node.

The method may involve launching the pipeline execution service on the processor circuit.

The operating condition data may include one of a signal generated by a sensor representing a physical operating condition associated with the process, and operating condition data representing organizational aspects related to the process.

The process may be executed at least in part by equipment located at a plant and the sensor may be disposed to monitor a physical operating condition of the equipment.

The data store may be a remote data store accessible over a wide area data network.

The method may involve causing the processor circuit to launch a data ingestion service that directs the processor circuit to receive operating condition data uploaded via the wide area data network and to store the data in the data store.

Causing a processor circuit to launch a pipeline editor service may involve causing the processor circuit to transmit web page data defining the pipeline editor interface to the user device over the wide area data network, the web page data being displayable by the user device within a browser application for interfacing with the pipeline editor service running on the processor circuit, and executing functions at the processor circuit to receive and process user input received from the user device via the pipeline editor interface. Causing the processor circuit to generate the data pipeline blueprint may involve causing the processor circuit to generate a JavaScript Object Notation (JSON) document.

The at least one source node may include a path defining a location of data defining the at least one operating condition in the data store.

A plurality of operating conditions may be stored at the location defined by the path and the at least one source node may involve a selection of the at least one operating condition within the plurality of operating conditions.

The one or more operator nodes may each include a definition of inputs required by the operator, and a code section that is operable to direct the processor circuit to perform functions for performing the operation on the operating condition defined by the at least one source node or one or more operator nodes.

The at least one export node may include at least one of a path defining a location in the data store for storing the operating condition output, and a visualization for displaying the operating condition output.

The data pipeline may include a plurality of operator nodes and the operating condition output of one of the plurality of operator nodes may be an input to another of the plurality of operator nodes.

The operating condition data may involve an ongoing stream of operating condition data uploaded to the data store and the processor circuit pipeline execution service may be operable to generate a corresponding operating condition output stream.

The pipeline editor interface may include a canvas area and wherein each of the nodes in the data pipeline may be displayed as blocks on the canvas, and the links may be displayed as lines connecting the nodes.

In accordance with another disclosed aspect there is provided a non-transitory computer readable medium encoded with codes operable to cause the processor circuit to implement the methods above. ln accordance with another disclosed aspect there is provided a system for processing operating condition data associated with execution of a process, the operating condition data being uploaded to a data store accessible over a data network. The system includes a processor circuit operably configured to receive a request from a user device in communication with the data network and in response, launch a pipeline editor service operable to provide access to the operating condition data via a pipeline editor interface made available for display on a user device. The processor circuit is further operably configured to receive user inputs defining a data pipeline from the user device via the pipeline editor interface. The data pipeline includes at least one source node defining at least one operating condition included in the operating condition data stored at the data store, at least one export node defining an operating condition output for the data pipeline, and links between the at least one source node and the at least one export node defining an execution sequence for the execution of functions associated with each node. The processor circuit is operably configured to generate a data pipeline blueprint including codes for implementing each of the nodes, the blueprint being operable to cause a pipeline execution service to implement the data processing pipeline.

Other aspects and features will become apparent to those ordinarily skilled in the art upon review of the following description of specific disclosed embodiments in conjunction with the accompanying figures.

BRIEF DESCRIPTION OF THE DRAWINGS

In drawings which illustrate disclosed embodiments,

Figure 1 is a block diagram of a system in accordance with one disclosed embodiment for recording operating conditions associated with execution of a process at a plant;

Figure 2 is a block diagram of a processor circuit for implementing an agent processor in the system shown in Figure 1;

Figure 3 is a flowchart depicting blocks of code for directing the agent processor shown in Figure 2 to process operating condition data in a data pipeline;

Figure 4 is a block diagram of a processor circuit for implementing a remote processor in the system shown in Figure 1; Figure 5 is a flowchart depicting blocks of code for directing the remote processor shown in Figure 4 to ingest data; Figure 6 is a flowchart depicting blocks of code for directing the remote processor shown in Figure 4 to provide editor functions for defining a data processing pipeline;

Figure 7A - 7C are screenshots of a pipeline editor interface displayed on a user device shown the system of

Figure 1 for generating a data pipeline;

Figure 8 is an example of an outline of a blueprint produced by the remote processor shown in Figure

4;

Figure 9 is a flowchart depicting blocks of code for directing the remote processor shown in Figure 4 to handle user input from the user device;

Figure 10 is a flowchart depicting blocks of code for directing the remote processor shown in Figure 4 to execute the data pipeline generated pipeline editor interface shown in Figure 7; and Figure 11 is an example of a visualization produced from data generated by the data pipeline.

DETAILED DESCRIPTION

Referring to Figure 1, a system for recording operating conditions associated with execution of a process at a plant 102 is shown generally at 100. In the embodiment shown the plant 102 is a sawmill and the process under execution is the processing of logs into lumber at the sawmill. The plant 102 includes multiple processing stations. A feed of raw logs is received at 104 and passed to a log sorter 106 that performs operations to sort and separate logs into batches for processing based on various characteristics such as length, diameter, species etc. The sorted logs are then passed to a debarker 108, which strips bark off the logs before passing the logs through a canter line 110 that cuts the debarked raw logs into cants for further processing into lumber. Finally the processed logs from the canter line are passed through a resorting and packaging process 112, and the packaged products are transported out from the plant 102 or further processed at 114. While the system 100 is described for the example of a sawmill embodiment, the recording of operating conditions may be implemented for any process or any plant.

While executing the process in the plant 102, operating conditions of the log sorter 106, the debarker 108, the canter line 110, and the resorting and packaging equipment 112 may be monitored by sensors that generate signals representing any of a plurality of different conditions. For example, the throughput of the log sorting process performed by the log sorter 106 may be monitored to quantify and characterize the raw log the input 104. Various operating conditions of the debarker 108 and the canter line 110 may be monitored, such as operating temperatures of key components, electrical component information for each saw at the canter line such as motor speeds, voltages and amperage, line speed data for conveyor belts, dimensions and measurements of the debarked logs such as diameter, length, species, wane, curve and other shape characteristics. The output 114 of the resorting and packaging 112 may be similarly monitored to quantify and characterize the output. As such, the plant 102 may have a number of sensors producing signals representing operating conditions on an ongoing basis. Other organizational aspects associated with the process under execution at the plant 102 may also be represented by operating condition data. Such operating condition data may take the form of documents detailing, for example, an operating shift schedule or production schedule.

The system 100 also includes a plurality of data acquisition units 122 - 128. In this embodiment, each data acquisition unit 122 - 129 is associated respectively with the log sorter 106, the debarker 108, the canter line 110 and the resorting and packaging equipment 112. In other embodiments a data acquisition unit may be associated with more than one processing station or there may be more than one data acquisition unit associated with a single processing station. In the embodiment shown, for each data acquisition unit 122 - 128 there is a respective database 130 - 136 for storing operating condition data. In other embodiments a database may be associated with more than one data acquisition unit or there may be more than one database associated with a single data acquisition unit. Each database 130 - 136 includes a data storage medium such as a hard drive and has a database interface, which may be provided by a processor circuit associated with the database. Alternatively, the database may be provided integrated together with a computer implemented data acquisition unit or may be implemented as any other type of data store.

The data acquisition units 122 - 128 generally receive signals from the processing stations 106 - 112 and generate operating condition data based on the signals. As an example, a temperature sensor may generate an analog signal representing a temperature of a component in the canter line 110 and the signal may be received at the data acquisition unit 122, converted into a digital representation, and saved in the database 130. Additional data such as the time of day and an identifier of the sensor may be saved to the database 130 along with the converted temperature data. The data acquisition unit 122 may be implemented using analog circuitry, logic circuitry, a processor circuit, or a combination thereof. In some cases the data may take the form of a stream of continually updated operating conditions, such as a temperature reading of a critical portion of equipment. In other cases, the data may be updated less frequently, such as for example a shift schedule document that defines the timing of shifts implemented at the plant 102.

While many sawmills may already monitor processing stations and employ data acquisition units to write operating condition data to databases, access to the data may be too involved for sawmill personnel who are not trained in computer and database skills. Extraction of information on operating conditions may thus reside in the domain of computer specialists, which may be an impediment to providing timely access to the stored information for business and/or operating purposes.

The system 100 also includes an agent processor 140, which is able to access the databases 130 - 136 and extract operating condition information for. The agent processor 140 is in communication with a data network 150, for uploading the operating condition data to a data store accessible over the data network 150. The system 100 further includes a remote processing location 160, which includes a remote processor 162 in communication with the data network 150. The remote processing location 160 also includes data stores 166 and 168. The remote processor 162 receives the extracted information transmitted by the agent processor 140 and stores the information in one of the data stores 166 or 168. The system 100 further includes a user location 170, where a user is able to communicate using a user device 172 with the remote processor 162 via the data network 150. The user device 172 has an associated user input device 176 and display 174. In one embodiment the user device may be an internet connected desktop or laptop computer. Alternatively the user device may be a tablet or smartphone device. The user device 172 is able to access services hosted by the remote processor 162 for viewing, organizing, and analyzing the operating condition information stored in the data stores 166 or 168. In one embodiment the plant 102, remote processing location 160, and user location 170 may be at different geographic locations, which in other embodiments the various locations may all be at the plant 102.

A processor circuit for implementing the agent processor 140 is shown in Figure 2. Referring to Figure 2 the processor circuit includes a microprocessor 200, a program memory 202, a variable memory 204, and an input output port (I/O) 206, all of which are in communication with the microprocessor 200. Program codes for directing the microprocessor 200 to carry out various functions are stored in the program memory 202, which may be implemented as a random access memory (RAM), and/or a solid state or hard disk drive, or a combination thereof. The program memory 202 includes a block of program codes 210 for directing the microprocessor 200 to perform operating system functions. The program memory 202 also includes a block of codes 212 for directing the microprocessor to execute an agent service and a block of codes 214 for directing the microprocessor to provide driver functions.

The I/O 206 includes a first interface 220 configured by driver codes in the block of codes 214 to read data from the database 130 convert the data into a format suitable for transmission. The I/O 206 further includes a second third and fourth interfaces 222 - 226 configured by driver codes in the block of codes 214 to read data from the respective databases 132 - 136 and to convert the data into a format suitable for transmission. As an example any of the databases 132 - 136 may be implemented as SQL or NoSQL databases and the drivers may be configured as either a SQL driver or NoSQL driver for accessing data on the database. The I/O 206 also includes an interface 228 operable to transmit the data formatted by the interfaces 220 - 226 over the data network 150 to the remote processor 162. The variable memory 204 includes a plurality of storage locations providing temporary storage of data while formatting and processing data read from the databases 130 - 136. The variable memory 204 may be implemented in random access memory or flash memory, for example.

Referring to Figure 3, a flowchart depicting blocks of code for directing the processor circuit of the agent processor 140 to process operating condition data is shown generally at 300. The blocks generally represent codes that may be read from the program memory 202, for directing the microprocessor 200 to perform data formatting and transmission functions. The actual code to implement each block may be written in any suitable program language, such as Javascript, Python, Java, C, C++, C #, and/or assembly code, for example.

The process begins at block 302, which directs the microprocessor 200 to start the agent processing service by executing the agent service codes 212 in the program memory 202. Block 304 then directs the microprocessor to execute the driver codes 214 in the program memory 202. The driver codes configure the interfaces 220 - 228 to read operating condition data from the databases 130 - 136. The agent processor 140 will generally initiate a processing thread for each operating condition that it is desired to monitor. In Figure 3, three separate threads 306, 308, and 310 are initiated. Further processing under the thread 306 is shown in Figure 3, while similar processing will also be performed under the threads 308 and 310.

Block 312 directs the microprocessor 200 to determine whether new data is available for operating condition 1. For example, if the operating condition 1 is a pressure associated with the canter line 110, block 312 directs the microprocessor 200 to read the database 134 to determine whether new pressure data has been written to the database by the data acquisition unit 126. If no new data is available, the process continues at block 314 which directs the microprocessor 200 to suspend the thread for some time t_s. The time t_s may be selected based on an update frequency associated with the sensor at the canter line 110 generating the operating condition signal and/or the processing rate of the data acquisition unit 126. Block 314 then directs the microprocessor 200 back to repeat block 312. If at block 312, new data is determined to be available, then the microprocessor is directed to block 316.

Block 316 directs the microprocessor 200 to read the data associated with the operating condition from the database. In general, data in the databases 130 to 136 may be stored in any of a plurality of different proprietary formats adopted by manufacturers of the sensors and/or data acquisition units 122 - 128. The read data may be temporarily stored in the variable memory 204. Block 318 then directs the microprocessor 200 to format the data for transmission to the remote processor 162. In one embodiment data transmitted to the remote processor 162 is formatted in accordance with a schema that defines a record or data structure. An example of a schema for an operating condition data source is shown in Appendix A. The schema has an identifier (id: "71d3e80016ae46788ae6elb2cl0ade87") that uniquely identifies the data source. The portion of the schema following the tag "schema:" defines the format of the operating condition data that will be transmitted by the agent processor 140. In this example, the data written will consist of a "pressure" number, converted time string, the identifier ("id"), a source type, system tags, and a topic name. For the pressure database example, successive pressure measurements will each have the format of the schema and will be logically grouped by the identifier "id". The reformatted data may be temporarily stored in the variable memory 204 prior to transmission.

Block 320 then directs the microprocessor 200 to send a request to the remote processor 162 via the data network 150 to upload new data to the remote processor. If at block 322, the upload request is acknowledged by the remote processor 162, block 324 directs the microprocessor 200 to upload the formatted data stored in the variable memory 204 to the remote processor via the data network 150. For the example where the data network 150 is the internet, the data may be encapsulated in one or more data packets (such as TCP-IP packets) and transmitted to a network address associated with a communications interface of the remote processor 162. If at block 322, the upload request is not acknowledged, block 322 directs the microprocessor the microprocessor 200 to wait for the upload request to be acknowledged. In other embodiments, block 322 may direct the microprocessor 200 to repeat the block 320 and send a further upload request if no acknowledgement is received.

Block 324 then directs the microprocessor 200 back to block 312 and the process thread for the operating condition 1 is repeated. The process thread 308 is thus continuously repeated while the agent processing service is running and the thread remains activated.

In other embodiments, operating condition data may be associated with a process other than operation of a plant such as shown in Figure 1. For example, the process could be a commercial process, financial process, or any other data associated with a non-manufacturing aspect of an enterprise's operations. The operating condition data may also not be produced by a physical sensor or related to operation of equipment, but may be any structured data set generated by any process. The data may be in a format such as an excel spreadsheet or other document and need not be in the form of a database record, for example.

A processor circuit for implementing the remote processor 162 at the remote processing location 160 is shown in Figure 4. Referring to Figure 4 the processor circuit includes a microprocessor 400, a program memory 402, a variable memory 404, and an input output port (I/O) 406, all of which are in communication with the microprocessor 400. Program codes for directing the microprocessor 400 to carry out various functions are stored in the program memory 402, which may be implemented as a random access memory (RAM), and/or a solid state or hard disk drive, or a combination thereof. The code may be written in any suitable program language, such as Javascript, Python, Java, C, C++, C#, and/or assembly code, for example. The program memory 402 includes a block of program codes 410 for directing the microprocessor 400 to perform operating system functions. The program memory 402 also includes a block of codes 412 for directing the microprocessor to execute data ingestion service, blocks of codes 414 and 416 for directing the microprocessor to provide data storage functions for implementing the data stores 166 and 168, a block of codes 418 for directing the microprocessor to invoke a pipeline editor service, a block of codes 420 defining operator functions in an operator library, a block of codes 422 for directing the microprocessor to invoke a pipeline execution service, a block of codes 424 for instantiating a virtual machine, a block of codes 426 for providing authentication services, and a block of codes 428 for providing data visualization services.

The I/O 406 includes a communications interface 450 for communication over the data network 150. In the embodiment showing in Figure 4, the remote processor 162 further includes a mass storage unit 408 providing data storage for implementing the data stores 166 and 168. The mass storage unit 408 may be implemented using one or more hard drive units, solid state drives, or other persistent storage medium such as a magnetic tape storage unit. In one embodiment the remote processor 162 may be implemented as a configurable computer system provided by a supplier of cloud computing resources. As such, the microprocessor 400, program memory 402, variable memory 404, and I/O 406, may be parts of a virtual machine hosted on a shared and/or distributed computing resource.

Although the remote processor 162 is shown in Figure 4 as having conventional computer architecture, the remote processor may be implemented using shared configurable computer system resources such as may be provided by companies such as Microsoft, Google, or Amazon and other cloud computing resource providers. As such, the remote processor 162 shown in Figure 4 may represent a virtual machine while in practice the resource provider may use multiple processors and other resources to provide the necessary functionality. One advantage of using a shared computing resource is that the resource becomes dynamically scalable and additional processing power or storage may be allocated as required.

Referring to Figure 5, a flowchart depicting blocks of code for directing the processor circuit of the remote processor 162 to receive (ingest) data from the agent processor 140 is shown generally at 500. The process begins at block 502, which directs the microprocessor 400 to start the data ingestion service by executing the codes 412 in the program memory 402. Block 504 then directs the microprocessor 400 to start the data store services by executing the codes 414 and 416 in the program memory 402. In one embodiment the data store 166 may be configured as an Apache Kafka database, which is able to efficiently manage and process data streams such as would be produced by a temperature sensor or pressure sensor. The data store 168 may be a document processing database such as a MongoDB, which may be used to store data related to plant operations such as a shift schedule, production schedule, etc. Various other data stores or databases may be implemented in addition to or in place of the above described data stores.

Block 508 then directs the microprocessor 508 to determine whether a request to upload data has been received from an agent processor such as the agent processor 140. If an upload request has been received then the process continues at block 510, which directs the microprocessor 400 to read the uploaded data and to write the data to the applicable data store. For example, if the data in the upload request contains sensor readings from a pressure or temperature sensor, the data may be written to the data store 166. If the data contains an updated shift schedule, then the data may be written to the data store 168.

In one embodiment, data may be stored in a hierarchical data structure that classifies and organizes the data from the plant 102. The data stores 166 and 168 may thus implement several hierarchical levels for data storage. For example, an organization level may be associated with a particular company (e.g. XYZ Forestry Products). A domain level may be associated with a logical grouping of data sources, such as a physical plant location. Under each domain, there may be multiple hierarchical levels that may be associated with the input 104, each particular processing station 106 - 112, and the output 114. As an example, a hierarchical level that groups operating conditions associated with the canter line 110 may be created. Further hierarchical levels may be created under the canter line hierarchical level to further group operating conditions pertaining to specific functions, systems, or attributes of the canter line 110. Finally at the lowest level of the hierarchical structure, individual operating condition sources may be logically grouped. The hierarchical data structure is effective in organizing operating condition sources into a tree like structure that facilitates selection of a specific operating condition from a large number of possible operating conditions associated with each processing station or activity at the plant 102.

Block 510 then directs the microprocessor 400 to return to block 508, and blocks 508 and 510 are continuously repeated. The data ingestion process 500 thus continuously receives operating condition data from the plant 102 and the data is stored in in one of the data stores 166 or 168 on an ongoing basis. The data stores 166 or 168 may thus store both current and historical operating condition data streams for any of a variety of operating conditions being monitored at the plant 102. While the individual streams of operating condition data may provide some useful insights into operations at the plant 102, data streams may also be combined with other data streams or documents, such as shift data, to provide greater insight into plant operations. In conventional data acquisition systems, extracting and combining data to produce reports or views of the data is a task that usually requires specialized programming skills. As an example, in a sawmill it may be useful to generate a visualization showing the number of logs processed by the canter line 110 during each shift at the plant 102. Such a visualization would necessarily require accessing an operating condition source that provides an ongoing count of the number of logs processed, which may be provided by the data acquisition unit 126 associated with the canter line 110. The count of the number of logs processed may be continuously updated, but not necessarily on a shift basis. Extraction of data on a shift basis requires and specialized skills and additional processing.

Referring to Figure 6, a flowchart depicting blocks of code for directing the processor circuit of the remote processor 162 to provide editor functions for defining a data processing pipeline is shown generally at 600. The process 600 begins at block 602, which directs the microprocessor 400 to execute the pipeline editor service block of codes 418, thereby launching a pipeline editor service operable to provide access to the operating condition data. The access may be provided by the remote processor 162 implementing a web server at the remote processor 162. Block 602 may be executed in response to a request received from the user device 172 in communication with the data network 150.

Block 604 then directs the microprocessor 400 to await input from a user device such as the user device 172 shown in Figure 1. If at block 604, a request is not received from the user device 172, then the block is repeated. If a request is received from the user device 172 over the data network 150 to invoke the pipeline editor interface, block 604 directs the microprocessor 400 to block 606. Block 606 then directs the microprocessor 400 to transmit data defining the pipeline editor interface to the user device 172 for display within a browser running on the user device. In one embodiment the pipeline editor is implemented as a web page including HTML data and client side scripting for implementing the interface on the user device 172. The pipeline editor interface permits a user of the user device 172 to interact with the pipeline editor service running on the remote processor 162. The remote processor 162 thus receives user input defining a data pipeline from the user device 172 via the pipeline editor interface. A screenshot of the pipeline editor interface as displayed on the user device 172 is shown in Figure 7 at 700. The pipeline editor interface 700 includes a canvas 702 and a control bar 704. The control bar 704 displays an editable name field 706 for the editor session, which may be changed by the user. The control bar 704 also includes a source function button 708, an operator function button 710, and an Export function button 712. The control bar 704 may also include a settings function button 714, which invokes an interface that permits the user to configure options for the editor interface 700. The example of the pipeline editor interface 700 shown in Figure 7 has a number of blocks representing processing nodes 716 - 730 that are displayed on the canvas 702. The user of the user device 172 is able to submit user input by moving a cursor 732 and using a pointing device or other input device to click on the function buttons 708, 710, and 712 or by clicking on or moving the nodes 716 - 730 on the canvas 702. In the embodiment shown, the operator nodes 720, 722, and 724 each have a node output (for example node 720 has a node output 732) and each has a node input (for example node 722 has a node input 734). Source nodes only have a node output, while export nodes only have a node input. The canvas 702 also displays user configurable links between nodes, for example the link 736 between the node output 732 of node 720 and the node input 734 of node 722.

Generally the data pipeline includes at least one source node, at least one export node , and links between the source node and the export node which would cause the export node to pass the data from the source node to the export node in a unaltered condition. In other embodiments, the data pipeline further includes one or more operator nodes, each defining an operation to be performed on the least one operating condition from the source node to produce an altered operating condition output at the export node. Thus, a plurality of operator nodes may be included and linked in an order that the operators are to be applied to the data.

Referring back to Figure 6, the process 600 continues at block 608, which directs the microprocessor 400 to create a blueprint for the initiated editor session. An example of a blueprint outline is shown generally at 800 in Figure 8. In this embodiment the blueprint is formatted as a JSON schema including fields that hold details of the data pipeline being edited and the state of the pipeline editor session. The blueprint 800 includes a metadata section 802 that identifies the data pipeline, a node definition section 804 that defines vertices or nodes making up the pipeline, a node connection section 806 that defines connections between the vertices or nodes that define the pipeline, a pipeline editor state portion 808 that defines the state of the pipeline editor interface, and a source/sink location section 810 that defines hierarchical locations for reading data from sources in the data stores 166 and 168 or writing data to the data stores. When the editor session is first initiated at block 608, the blueprint will have metadata fields 802 such as the "name" populated, but the remaining sections will remain empty until one of the function buttons 708, 710, or 712 are clicked at the user device 172.

Block 610 of the process 600 then directs the microprocessor 400 to determine whether user input has been received from the user device 172. If at block 610, no user input is received from the user device 172, then the block is repeated. When a user input is received from the user device 172 at the remote processor 162, block 610 directs the microprocessor 400 to block 902 of a user input handling process 900 shown in Figure 8.

Referring to Figure 9, a flowchart depicting blocks of code for directing the processor circuit of the remote processor 162 to handle user input is shown generally at 900. The process 900 begins at block 902, which directs the microprocessor 400 to determine whether the source function button 708 has been clicked on the user device 172 to invoke the source function. In some embodiments the web page editor interface displayed on the user device 172 may include client-side scripting that causes the canvas 702 to be locally updated in response to user input. The user device 172 also transmits data via the data network 150 that notifies the pipeline processing service running on the remote processor 162 of the user input and current state of the editor interface 700. At the remote processor 162, when user input is received from the user device 172 indicating that the source function has been invoked, block 902 directs the microprocessor 400 to block 904. Block 904 directs the microprocessor 400 to update a blueprint 800 for the editor session to add the source node. The process then continues at block 906, which directs the microprocessor 400 to receive user selection of an operating condition source from one of the data stores 166 or 168. At the user device 172, selection of the operating condition source may be via a displayed user selection panel such as shown in Figure 7B at 750. The user selection panel 750 groups data sources in a tree structure 752 (under Cumul8/Cumula8/AII sources etc) allowing the user to drill down through the various hierarchical levels to select a desired data source. A field "validationError" in the pipeline editor state portion 808 ("feState") will initially be set to indicate a validation error, until a valid data source is selected.

Block 910 of the process 900 then directs the microprocessor 400 to update the blueprint 800. Fields in the node definition section 804, the pipeline editor state portion 808, and the source/sink section 810 of the blueprint 800 are written to reflect the addition of the source node at block 904 and the selection of a specific source at block 906. An example of a JSON schema portion that includes details of the source node is shown in Appendix B. The codes under the "vertexes" tag (node definition section 804 of the blueprint 800) define the source node 716 including a unique identifier that identifies the data source ("id"), a name, and a value. The code under the "nodes" tag (editor state portion 808 of the blueprint 800) identifies the state of the pipeline editor interface 700 as appearing on the user device 172 including fields such as the node name, whether the node is currently selected, and the x and y coordinates of the representative block 716 on the canvas 702. The editor state portion 808 of the blueprint that captures the layout of the pipeline editor interface 700 within the blueprint to facilitate later display for editing.

Block 910 then directs the microprocessor 400 back to block 608 in Figure 6 to await further user input from the user device 172.

If at block 902 the source function button 708 has not been invoked at the user device 172, the microprocessor 400 is directed to block 912, which directs the microprocessor to determine whether the operator function button 710 has been clicked to invoke the operator function. Block 914 then directs the microprocessor 400 to update a blueprint 800 for the editor session to add JSON code defining an operator node (for example the node 720 shown in Figure 7). Block 916 then directs the microprocessor 400 to receive a user selection of the operator and a configuration of the parameters associated with the operator. An example of the node definition section 804 of the blueprint 800 for an operator is shown in Appendix B under the "vertexes" tag. The name of the operator is "op_average", which identifies the operator codes to be used for implementing the operator, what are stored in the operator library block of codes 420. The operator library 420 may include codes for a plurality of operators, including operators that perform simple math functions, conditional testing, data filtering, data and time processing, statistical functions, and data windowing functions, for example. The "op_average" operator has two required values "averageField" and "resetField". The node definition also specifies that the operating condition data to be used for the "averageField" is "AvgDiam". The node definition also specifies that the operating condition data to be used for the "resetField" comes from an "IsComplete" output field provided by the "op_windowOpen" operator 720 in Figure 7. The node 722 thus specifies the operator to be used and the parameters that the operator will access from the preceding operators and sources 720, 716 and 718.

The operator itself may be stored in the operator library 420 as a JSON schema, a portion of which is shown in Appendix C. The schema includes a "code:" tag that indicates the start of a JavaScript code section of the operator that can be used to direct the microprocessor 400 to perform the operation on the data. The schema also includes other metadata that provides information about the operator that can be used in the pipeline editor interface 700 to display context sensitive help for configuring the operator, validation criteria for parameters, whether parameters are required or optional, and other information. The code portion includes conventional functions that calculate the average and generate the output for the node 722 at the node output. Other operators 720, 724, and 726 will each have a JSON schema stored in the operator library 420 having a similar format to that shown in Appendix B.

At block 916 of the process 900, when configuration of the operator meets the validation criteria in the metadata section of the JSON schema, the process continues at block 918, which directs the microprocessor 400 to update the blueprint to include the operator details. Block 918 also directs the microprocessor 400 to return to block 608 of Figure 6 to await further user input.

If at block 912 the operator function button 710 has not been invoked at the user device 172, the microprocessor 400 is directed to block 920, which directs the microprocessor to determine whether the export function button 712 has been clicked to invoke the export function. Block 920 then directs the microprocessor 400 to update a blueprint 800 for the editor session to add an export node (corresponding to the node 728 shown in Figure 7). The export function defines an export or storage location on one of the data stores 166 or 168 where the operating condition output will be stored. As in the case of the operating condition source, the data will be written to storage in accordance with a schema, similar to the source definition shown in Appendix A. The export location will also have a unique identifier ("id") to facilitate locating the export location in the data store 166 or 168. An example of a JSON schema portion that includes details of the export node is shown in Appendix E. The "values" section includes an "id":"8279e6adadl245a090f72184b81a290b", which is the identifier of the source location. In some embodiments it may be desirable to display a visualization of the data at the node output of the keep operator 726. In one embodiment an export node 730 (shown in Figure 7) may be included that produces a visualization rather than storing data in one of the data stores 166 or 168. The visualization node 730 defines attributes that may be provided to a set of graphing functions provided when the visualization service block of codes 428 are executed to display the output of the data pipeline. An example of a graphical output is shown in Figure 11. In other embodiments the export node 728 that stores data in the data stores 166 or 168 may be omitted, in which case ongoing near real-time data may be displayed on the graph but will not be stored in the data stores.

If at block 920 the export function button 710 has not been invoked at the user device 172, the microprocessor 400 is directed to block 928, which directs the microprocessor to determine whether the link function has been invoked. At the user device 172 when the user drags a link such as the link 736 between the node output 732 and the node input 734, the nodes are connected on the canvas and the user device 172 also sends details of the link to the pipeline editor service running on the remote processor 162. Block 930 then directs the microprocessor 400 to update a blueprint 800 for the editor session to define the link between the nodes in the node connection section 806. An example of a node connection section 806 that defines links between nodes is shown in Appendix E. In the first portion of the JSON schema in Appendix F, the link 736 is defined as being between the "op_average node" (i.e. node output 732 on the node 720) and the "op_windowOpen" node (i.e. node input 734 on the node 722). Further portions of the JSON schema define connections between the remaining nodes 716 - 728.

If at block 928 the link function has not been invoked at the user device 172, the microprocessor 400 is directed to block 932, which directs the microprocessor to determine whether a start pipeline function has been invoked at the user device 172. Referring to Figure 7 C, a start pipeline function button 740 becomes available on a menu 742, which is displayed on the right hand side of the canvas 702 when the settings function button 714 is clicked. The start pipeline function button 740 is only active if all nodes 716 - 728 have passed validation, and may not be displayed or greyed out if any nodes are not validated. When the start pipeline function is invoked at the user device 172, data identifying the blueprint (i.e. the "id" field in the metadata fields 802 of the blueprint 800 shown in Figure 8) is sent to the remote processor 162 via the data network 150. If at block 932, the microprocessor 400 determines that the start pipeline function has not been invoked, the microprocessor is directed back to block 608 in Figure 6 to await further user input. If at block 932, the microprocessor 400 determines that the start pipeline function has been invoked, the microprocessor is directed to block 1002 of a pipeline execution process shown in Figure 10.

Referring to Figure 10, a flowchart depicting blocks of code for directing the remote processor 162 to execute the data pipeline is shown generally at 1000. The process begins when the remote processor 162 receives data from the user device 172 indicating that the pipeline should be started. Block 1002 directs the microprocessor 400 to start the pipeline execution service block of codes 422 stored in the program memory 402 of the processor circuit (shown in Figure 4). If the pipeline execution service is already running then block 1002 would not be re-executed.

Block 1004 then directs the microprocessor 400 to access the blueprint 800. For an example where the pipeline execution service is written in JavaScript there are functions available that facilitate reading in portions of a JSON schema. The blueprint 800 in turn provides links to additional schema identifying sources, export sinks, and operators, which may also be read by the pipeline execution service. Block 1006 then directs the microprocessor 400 to generate executable code for the data pipeline based on the blueprint. The executable code may thus include code portions accessing the sources defined at the nodes 716 and 718, code portions (such as shown in Appendix D) for implementing the operators 720 - 726, and code portions that store the resulting operating condition output to the defined export location.

Block 1008 then directs the microprocessor 400 to determine whether any of the data sources defined in the blueprint require authentication of the user prior to providing access to the data. In some instances the plant 102 may wish to protect data sources from being accessed by other than authorized users. If any data sources require authentication, block 1008 directs the microprocessor 400 to launch the authentication service block of codes 426. Block 1010 then directs the microprocessor 400 to access the authentication service for authentication of the user. The user will then be required to provide credentials such as a login name and password or other information to permit access to the data source. Once authentication is completed the process 1000 continues at block 1012. If none of the data sources require authentication for use at block 1008, the microprocessor 400 is directed to block 1012.

Block 1012 directs the microprocessor 400 to run the virtual machine block of codes 424 to instantiate a new virtual machine. In one embodiment the virtual machine block of codes 424 may be implemented as a Kubernetes cluster that instantiates a container within which each data pipeline can be run. Each data pipeline is thus virtually independent of other data pipelines running on the remote processor 162 and a failure within a specific pipeline container should have no effect on other executing pipeline containers.

The process then continues at block 1014, which directs the microprocessor 400 to execute the executable code of the data pipeline within the instantiated container. The executing data pipeline will access the defined data sources, perform processing, and generate operating condition output data. Block 1016 directs the microprocessor 400 to determine whether a termination instruction has been received, in which case the microprocessor is directed to block 1018, which causes the pipeline execution service to terminate execution of the data pipeline and to close down the container within which it was executing. If no termination instruction is received at block 1016, the pipeline execution continues.

As described above, the editor session shown in Figure 7 generates a blueprint 800 that captures configuration details input by a user at the user device 172 representing the pipeline editor interface 700 as shown. The editor interface 700 as such is a representation of the data pipeline in a human readable format that allows a user without computer programming knowledge to configure relatively complex data pipelines. The blueprint also captures the actual layout of the nodes 716 - 728 on the canvas 702 for re display, should the user wish to edit the blueprint at a later time.

In the example shown in Figure 7, two operating condition data sources are identified, i.e. logData and shiftDat. The logData includes a stream of data representing the average diameter of each log processed through the plant 102 ("AvgDiam"). The shiftDat source may be a document that details shift schedules in the plant 102. The operator 720 implements a windowing function that segments the average log diameter data according to the shifts detailed in the shiftDat source. At the time of a shift change, the window operator 720 asserts an "IsComplete" output at the node output 732. The "op_average" operator 722 averages the data provided by node output 732 of the window operator 720. When the shift change occurs, the "op_average" operator 722 resets the average in response to receiving the "IsComplete" output from the window operator 720. This starts a new average for the new shift. The "op_average" operator 722 produces a running average of log diameter at its node output. The operator 724 is also a windowing operator that is responsive to the completion of a shift indicated by the "IsComplete" output at the node output 732 being asserted. However, the window operator 724 operates on the running average produced by the "op_average" operator 722 rather than the "AvgDiam" data from the source node 716. When the shift completes, the window operator 724 closes the window. The operator 726 is a "keep" operator that acts to preserve or keep certain data provided by the pipeline, while other data may be discarded. In this example, the intent is to capture average log diameter over a shift and this data is thus relevant and should be kept. However, the "AvgDiam" for each log is already being stored in the data stores 166 or 168 and may thus be discarded to avoid saving redundant data. The keep operator 726 thus makes the average data and a shift closing timestamp available at its node output. The export node 728 then writes the data produced by the pipeline to the data store 166 or 186.

While specific embodiments have been described and illustrated, such embodiments should be considered illustrative only and not as limiting the disclosed embodiments as construed in accordance with the accompanying claims.

Appendices

Appendix A: Source

{

agent_data: {driver: "solutions", disabled: false,...},

created: "2017-05-19T02 : 29 : 26.486Z" ,

data_type: "event",

domain_id : "58afOcl1380540ea04e48d20cef805 " ,

id: "71d3e80016ae46788ae6elb2cl0ade87",

meta: {db_name: "", collection_name : filter_key: filter_value : filter_is_object_id: false,...},

name: "Pressure Sensor Database",

schema :

" { "properties" : { "pressure" : { "type" : "number" } , "converted_time" : { "type" : "strin g" } , "id" : { "type" : "number" } " ,

source_type : "sql_server_2018 " ,

system_tags: ["DDS"],

topic_name : "k8-source- 91328e8a3fffaadlcl2cbd" ,

}

Appendix B: Blueprint - source definition

"vertexes" : [

{

"nodeid" : "57d4a858518a4fac59d86516c63fb92f",

"name" : "source_logData" ,

"values" : {

"id" : " f7b4f3ffe72141ee9614fc3cb29bll6c" ,

"sourceName" : "Log Data"

}

},

"feState" : {

"diagramState" : {

"nodes" : [

{

"nodeName" : " source_logData" ,

"nodeType" : "source" ,

"params" : {

"id" : "f7b4f3ffe71141ee8614fc3bc29b226c" ,

"sourceName" : "Log Data"

},

"selected" : false,

"sourceName" : "source" ,

"sourceNodeld" : "57d4a858328a4fac95d86516c63fb29f",

"validationError " : null,

"x" : 72,

"y" : 168

}, Appendix C: Blueprint - operator definition

Appendix D: Operator code

code :

(function (name, opts) {

// Averages incoming event fields

// Adds a new ^'Average' :: number field to the payload

// averageField : ; field - A field that we want to average

// resetField : : field - A field that causes the average to reset when true

var calculateAverage = function (state, value) {

if ([null, undefined] . indexOf (value ) < 0) {

state . Increase ( ' count ' ) ;

state . IncreaseBy (' sum' , value); var average = 0;

if ( state . Get (' count ' ) !== 0) {

average = state . Get (' sum' ) / state . Get ('count'); return average;

}

var cb = function (payload, metadata, state) {

var fieldValue = j s_lib . getPath (payload, opts . averageField) var average = 0;

if (Array . isArray (fieldValue) ) {

average = (fieldValue | | []) . reduce ( function (reducedValue, item)

return calculateAverage ( state , item);

}, 0)

} else {

average = calculateAverage ( state, fieldValue)

}

if (opts . resetField && j s_lib . getPath (payload, opts . resetField)

=== true) {

state . Set (' count ¹ , 0);

state . Set (' sum ' , 0.0);

}

var output = j s_lib . setNodeData (payload, name, { Average: average, return output;

} ;

return [

ops . NewMap (name, ops . NewMapParams ( )

.Cb(cb)

. InitialState ( sys . NewUdfState ( {

count: 0,

sum: 0.0,

} ) )

),

}) ;

{

"id" : "38d992a6a4d77ab9b0cbc2e3141752bl" ,

"name": "ops . average" ,

"description": "Averages the values of the averageField and resets to zero on resetField=true" ,

"owner" : "468al8b20b864aal8d01276330699264" ,

"code": " \n\n ( function (name, opts) {\n\t\/\/ Averages incoming event fields\n\t\/\/ Adds a new 'Average^' :: number field to the payload\n\t\/\/ averageField : : field - A field that we want to average\n\t\/\/ resetField : : field - A field that causes the average to reset when true\n\n\tvar calculateAverage = function (state, value) {\n\t\tif ([null, undefined] . indexOf (value ) < 0)

{ \n\t\t\tstate . Increase ( ¹ count ' ) ; \n\t\t\tstate . IncreaseBy ( ' sum' ,

value) ; \n\t\t} \n\n\t\tvar average = 0;\n\t\tif ( state . Get (' count ' ) ! == 0)

{ \n\t\t\taverage = state . Get (' su ' ) \/ state . Get (' count '); \n\t\t } \n\n\t\treturn average ; \n\t } \n\n\tvar cb = function (payload, metadata, state) {\n\t\tvar fieldValue = j s_lib . getPath (payload, opts . averageField) \n\n\t\tvar average = 0;\n\t\tif (Array . isArray (fieldValue) ) { \n\t\t\taverage = (fieldValue | |

[]) . reduce ( function (reducedValue, item) { \n\t\t\t\treturn calculateAverage (state, item) ; \n\t\t\t } , 0)\n\t\t} else { \n\t\t\taverage

= calculateAverage ( state , fieldValue ) \n\t\t } \n\n\t\tif (opts . resetField && j s_lib . getPath (payload, opts . resetField) === true)

{ \n\t\t\tstate . Set ( ' count ' , 0) ; \n\t\t\tstate . Set ( ' sum' ,

0.0 ) ; \n\t\t } \n\n\t\tvar output = j s_lib . setNodeData (payload, name, { \n\t\t\tAverage : average, \n\t\t } ) ; \n\n\t\treturn output; \n\t} ; \n\n\treturn [\n\t\tops .NewMap (name, ops . NewMapParams () \n\t\t\t.Cb(cb) \n\t\t\t. InitialState (sys .NewUdfState ( { \ n\t\t\t\tcount : 0, \n\t\t\t\tsum: 0.0,\n\t\t\t}) ) \n\t\t) ,\n\t] ;\n}) ;\n", "params": [

{

"name": "averageField",

"description": "A field that we want to average",

"type": " field_number" ,

"required": true, "default": null,

"validValues " : [],

"supportsArrayProcessing" : true

},

{

"name": "resetField" ,

"description": "A field that cause a reset when true

"type": " field_boolean" ,

"required": false,

"default": null,

"validValues": [],

"supportsArrayProcessing" : false

}

r

numberOfInputs " : {

"str_val":

"int val": 1

"numberOfOutputs" : {

"str val":

"int^~val" : 1

},

"metadata": {

"type": "op"

},

"xformRules " : [

{

"rules " : [

"add field cumul8_generated_data vertex-name | Average number"

]

}

"chainedNode!Ds" : []

Appendix E: Blueprint - export definition

"vertexes" : [

{

"nodeid" : "dc21068cf94d4024aa7499a51ecl2068",

"name" : "sink_export" ,

"values" : {

"id" : "8279e6adadl245a010f62183b81a290b" ,

"sourceName" : "Canter Average Log Diameter"

} Appendix F: Blueprint - link definition

Claims

What is claimed is:

1. A computer implemented method for processing operating condition data associated with execution of a process, the operating condition data being uploaded to a data store accessible over a data network, the method comprising: in response to a request received from a user device in communication with the data network, causing a processor circuit to launch a pipeline editor service operable to provide access to the operating condition data via a pipeline editor interface made available for display on the user device; receiving from the user device via the pipeline editor interface, user inputs defining a data pipeline, the data pipeline comprising: at least one source node defining at least one operating condition included in the operating condition data stored at the data store; at least one export node defining an operating condition output for the data pipeline; links between the at least one source node and the at least one export node defining an execution sequence for the execution of functions associated with each node; and causing the processor circuit to generate a data pipeline blueprint including codes for implementing each of the nodes, the blueprint being operable to cause a pipeline execution service to implement the data processing pipeline.

2. The method of claim 1 wherein the data pipeline further comprises one or more operator nodes, each defining an operation to be performed on the least one operating condition to produce the operating condition output, the links further including links between the at least one source node, the one or more operator nodes and the at least one export node.

3. The method of claim 1 further comprising launching the pipeline execution service on the processor circuit.

4. The method of claim 1 wherein the operating condition data comprises one of: a signal generated by a sensor representing a physical operating condition associated with the process; and operating condition data representing organizational aspects related to the process.

5. The method of claim 4 wherein the process is executed at least in part by equipment located at a plant and wherein the sensor is disposed to monitor a physical operating condition of the equipment. 6. The method of claim 1 wherein the data store is a remote data store accessible over a wide area data network.

7. The method of claim 6 further comprising causing the processor circuit to launch a data ingestion service that directs the processor circuit to receive operating condition data uploaded via the wide area data network and to store the data in the data store. 8 The method of claim 7 wherein causing a processor circuit to launch a pipeline editor service comprises: causing the processor circuit to transmit web page data defining the pipeline editor interface to the user device over the wide area data network, the web page data being displayable by the user device within a browser application for interfacing with the pipeline editor service running on the processor circuit; and executing functions at the processor circuit to receive and process user input received from the user device via the pipeline editor interface.

The method of claim 1 wherein causing the processor circuit to generate the data pipeline blueprint comprises causing the processor circuit to generate a JavaScript Object Notation (JSON) document.

10. The method of claim 9 wherein the at least one source node comprises a path defining a location of data defining the at least one operating condition in the data store.

11. The method of claim 10 wherein a plurality of operating conditions are stored at the location defined by the path and wherein the at least one source node comprises a selection of the at least one operating condition within the plurality of operating conditions.

12. The method of claim 1 wherein the one or more operator nodes each include: a definition of inputs required by the operator; and a code section that is operable to direct the processor circuit to perform functions for performing the operation on the operating condition defined by the at least one source node or one or more operator nodes.

13. The method of claim 1 wherein the at least one export node comprises at least one of: a path defining a location in the data store for storing the operating condition output; and a visualization for displaying the operating condition output.

14. The method of claim 1 wherein data pipeline comprises a plurality of operator nodes and wherein the operating condition output of one of the plurality of operator nodes comprises an input to another of the plurality of operator nodes. 15. The method of claim 1 wherein the operating condition data comprises an ongoing stream of operating condition data uploaded to the data store and wherein the processor circuit pipeline execution service is operable to generate a corresponding operating condition output stream.

16. The method of claim 1 wherein the pipeline editor interface comprises a canvas area and wherein: each of the nodes in the data pipeline are displayed as blocks on the canvas; and the links are displayed as lines connecting the nodes.

17. A non-transitory computer readable medium encoded with codes operable to cause the processor circuit to implement the method of any one of claims 1 to 15.

18. A system for processing operating condition data associated with execution of a process, the operating condition data being uploaded to a data store accessible over a data network, the system comprising: a processor circuit operably configured to receive a request from a user device in communication with the data network and in response, launch a pipeline editor service operable to provide access to the operating condition data via a pipeline editor interface made available for display on a user device; wherein the processor circuit is further operably configured to receive user inputs defining a data pipeline from the user device via the pipeline editor interface, the data pipeline comprising: at least one source node defining at least one operating condition included in the operating condition data stored at the data store; at least one export node defining an operating condition output for the data pipeline; links between the at least one source node and the at least one export node defining an execution sequence for the execution of functions associated with each node; and wherein the processor circuit is operably configured to generate a data pipeline blueprint including codes for implementing each of the nodes, the blueprint being operable to cause a pipeline execution service to implement the data processing pipeline.

19. The system of claim 18 wherein the data pipeline further comprises one or more operator nodes, each defining an operation to be performed on the least one operating condition to produce the operating condition output, the links further including links between the at least one source node, the one or more operator nodes and the at least one export node. 20. The system of claim 18 wherein the processor circuit is operably configured to execute the pipeline execution service.

21. The system of claim 18 wherein the operating condition data comprises one of: a signal generated by a sensor representing a physical operating condition associated with the process; and data representing conditions representing organizational aspects related to the process.

22. The system of claim 21 wherein the process is executed at least in part by equipment located at a plant and wherein the sensor is disposed to monitor a physical operating condition of the equipment.

23. The system of claim 18 wherein the data store is a remote data store accessible over a wide area data network.

24. The system of claim 23 wherein the processor circuit is operably configured to launch a data ingestion service for receiving operating condition data uploaded via the wide area data network and wherein the processor circuit is operably configured to store the data in the data store.

25. The system of claim 24 wherein the processor circuit is operably configured to launch a pipeline editor service by: transmitting web page data defining the pipeline editor interface to the user device over the wide area data network, the web page data being displayable by the user device within a browser application for interfacing with the pipeline editor service running on the processor circuit; and executing functions to receive and process user input received from the user device via the pipeline editor interface. 26. The system of claim 18 wherein the processor circuit is operably configured to generate the data pipeline blueprint by generating a JavaScript Object Notation (JSON) document.

27. The system of claim 26 wherein the at least one source node comprises a path defining a location of data defining the at least one operating condition in the data store.

28. The system of claim 27 wherein a plurality of operating conditions are stored at the location defined by the path and wherein the at least one source node comprises a selection of the at least one operating condition within the plurality of operating conditions.

29. The system of claim 18 wherein the one or more operator nodes each include: a definition of inputs required by the operator; and a code section that is operable to direct the processor circuit to perform functions for performing the operation on the operating condition defined by the at least one source node or one or more operator nodes.

30. The system of claim 18 wherein the at least one export node comprises at least one of: a path defining a location in the data store for storing the operating condition output; and a visualization for displaying the operating condition output.

The system of claim 18 wherein data pipeline comprises a plurality of operator nodes and wherein the operating condition output of one of the plurality of operator nodes comprises an input to another of the plurality of operator nodes.

32. The system of claim 18 wherein the operating condition data comprises an ongoing stream of operating condition data uploaded to the data store and wherein the processor circuit pipeline execution service is operable to generate a corresponding operating condition output stream.