CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application serial number 62/597,847, filed on 12-DEC-2017, which is incorporated in its entirety by this reference.

TECHNICAL FIELD

[0002] This invention relates generally to the machine monitoring field, and more specifically to a new and useful system and method for retrofitting machines with monitoring capabilities in the machine monitoring field.

BACKGROUND

[0003] Typical systems and/or methods for physical machine monitoring and/or analysis may require significant customization to be adapted to work with a proprietary interface of a particular physical machine, and/or may risk interfering with operation of the physical machine. Further, many such interfaces do not directly provide the information desired by users of such systems and/or methods. Thus, there is a need in the machine monitoring field for an improved system and method for physical machine monitoring and analysis.

BRIEF DESCRIPTION OF THE FIGURES

[0004] FIGURE l is a schematic representation of the method.

[0005] FIGURE 2 is an example system for performing the method.

[0006] FIGURE 3 is an example of determining the digital duplicate.

[0007] FIGURE 4 is a specific example of the system. DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0008] The following description of the preferred embodiments of the invention is not intended to limit the invention to these preferred embodiments, but rather to enable any person skilled in the art to make and use this invention.

[0009] As shown in FIGURE l, the machine monitoring method preferably includes: receiving packets supplied to a physical machine Sioo; virtually simulating physical machine operation using a digital duplicate of the physical machine and the packets S200; analyzing the virtual outputs of the virtual simulation S300; and/or transmitting the analysis results to a remote device S400. The method can optionally include determining the digital duplicate of the physical machine S500, determining an analysis model for the virtual outputs of the digital duplicate S600, determining digital component modules, and/ or determining digital analysis modules.

[0010] The method preferably functions to retrofit existing physical machines with operational monitoring and continuous process improvement capabilities. The physical machines are preferably machines that lack operational monitoring and analysis capabilities (e.g., low-intelligence machines,“dumb” machines, narrow AI machines, reactive machines, etc.), but can additionally or alternatively include any suitable machines. In a specific example, the physical machines can be industrial manufacturing machines, such as sewing machines, stamps, and cutting machines.

[0011] The method is preferably performed by an on-premises system physically connected to the physical machine, but can be performed by an on-premises system remotely located from the physical machine, a remote computing system (e.g., off- premises), or by any suitable system. The method is preferably continuously performed in real- or near-real time, but can be periodically performed, performed according to a schedule, performed in response to receipt of an execution command (e.g., from a user device or central management system), or performed at any other suitable time.

[0012] As shown in FIGURE 4, the system can optionally include: a data analyzer, a remote computing system, a database of digital component modules, digital analysis modules, digital machines (e.g., including a set of linked digital components), digital analysis models (e.g., analysis graph), recognition modules (e.g., that recognize a digital component module based on the received packets), or any other suitable module.

[0013] Variants of the method can confer benefits over conventional systems. First, variants of the method can have low processing power requirements. This is because the physical machine’s digital duplicate mirrors the physical machine’s component control systems (e.g., only requires as much processing power as that used by the physical control systems), and because the physical machine’s component control systems are typically low-power processors (e.g., microcontrollers).

[0014] Second, variants of the method can minimize processing power (as discussed above) and/or minimize data storage (e.g., by discarding low-level, raw data and storing high-level data abstractions), which can enable small, on-premises footprint retrofits, which can be useful in applications with limited physical space (e.g., a factory floor), in applications where information security is an issue, where there is no IT infrastructure, or where the WAN connection’s bandwidth is consumed by higher-priority data.

[0015] Third, variants of the method can minimize data storage requirements and/or the data bandwidth required to transmit analysis results by converting high frequency low-level data (e.g., the raw packets) to low frequency, high-level derivative data. These variants can further reduce the requisite storage and bandwidth by storing the high-level derivative data in a low-memory form factor (e.g., in binary).

[0016] Fourth, variants of the method can increase response speed by leveraging deterministic analyses. Fifth, variants of the method can minimize machine performance by being a read-only system and/ or passively extracting the data. However, the system and method can confer any suitable set of benefits.

[0017] Receiving packets supplied to a physical machine Sioo functions to obtain data about machine operation. This machine operation data can be used to determine the current state of the physical machine, and can optionally be used to identify the physical components within the physical machine.

[0018] The physical machine preferably includes one or more physical components and a controller, but can additionally or alternatively include a system bus connecting the controller to the physical components (and/or the physical components to each other) or any other suitable subsystem.

[0019] The physical component is preferably a mechanical subsystem that performs a predefined set of tasks. The physical component can include one or more: actuators (e.g., that generates a component output or performs a task), component control systems (e.g., that controls actuator operation based on instructions addressed to the physical component), sensors (e.g., that monitors actuator operation), or other subcomponent. The physical component is preferably identified by a locally unique address (e.g., within the packet header), but can be otherwise identified. The physical component is preferably associated with one or more outputs or operational states. Examples of the outputs or operational states include: actuator motion (e.g., kinematics, such as velocity, acceleration, etc.), actuator or end effector position (e.g., linear position, angular position), applied force (e.g., pressure, torque), emitted sound parameters (e.g., pitch, volume), temperature parameters (e.g., temperature, duration), emitted light parameters (e.g., color, brightness, image, text), or any other suitable output or operational state. Examples of the physical component include: switches (e.g., emergency stop buttons, dead man switches), motors, pedals, displays, or any other suitable physical component.

[0020] The controller functions to control one or more physical components based on a control program. In particular, the controller can generate transmissions (e.g., instructions, such as control packets) for the physical components based on the control program, physical component feedback, sensor feedback, or any other suitable input. The controller can be an industrial control system, a master SCADA control system, or be any other suitable controller. The controller preferably transmits the transmissions (e.g., control packets) to the respective physical component over the system bus, but can alternatively or additionally transmit the transmissions over a wireless LAN (e.g., Bluetooth network, WiFi network, etc.), and/or through any other suitable communication channel. The transmissions are preferably addressed to the respective, individual physical component, but can be otherwise addressed. The transmissions preferably include control instructions, but can additionally or alternatively include processing instructions (e.g., wherein the component can process data according to the processing instructions), secondary endpoint information (e.g., a second component’s address), and/or any other suitable information. The control instructions can be in the form of: power modulation (e.g., adjusting the supplied voltage and/or current), binary signals, machine instructions, assembly instructions, and/ or in any suitable format. The control instructions are preferably provided in a known (e.g., standard) protocol, but can alternatively be in a proprietary protocol or any other suitable protocol.

[0021] The system bus functions as an intra-machine network connection, and communicates data (e.g., packets) and/or power between the controller and the physical component(s). The system bus preferably defines one or more communications links (e.g., real-time and/ or deterministic communications links) between the controller and the physical components. The system bus is preferably a real-time, deterministic bus (e.g., fieldbus, such as standardized in IEC 61158), but can be any other suitable bus. The system bus can be a parallel bus, serial bus, or any other suitable bus. The system bus is preferably a wired network communication system (e.g., including one or more wired communication links), but can additionally or alternatively include wireless communication links. Examples of the system bus include: Ethernet, EtherCAT, VARAN, GPIB, Bitbus, RS-232, Centronics, IEEE 1284, RJ11, USB, and/or any other suitable network communication system.

[0022] The received packets are preferably control packets, but can additionally or alternatively be return packets generated by the physical component or be any other suitable packet. The return packets can be addressed to the controller, a secondary physical component, or to any suitable endpoint. The return packets can include: sensor measurements (e.g., generated by component sensors), packet receipt confirmation, command execution confirmation, error codes, or any other suitable information.

[0023] Receiving the packets preferably includes intercepting (e.g., listening, capturing, sniffing) and logging (and/ or otherwise acting upon, such as buffering, storing, duplicating, streaming, etc.) the packets from the system bus with a data analyzer (e.g., tap, such as a passive tap). However, the packets can be otherwise received. The data analyzer can be hardware (e.g., a microprocessor, a microcontroller, a FPGA, an ASIC, a CPU, a GPU, etc.) or software that reads packets transmitted along the bus (e.g., transmitted from the controller to the physical components, or from the physical components to the controller), but can be any other suitable agent. The data analyzer is preferably connected to a passive system bus splitter, but can be connected to the controller or be otherwise connected to the system. The data analyzer is preferably passive and does not transmit packages to the system bus (e.g., the packets are allowed to propagate through the system bus in the same manner as if the data analyzer were not present), but can alternatively be active (e.g., query physical components or the controller for information, such as the physical component identity). The packets are preferably continuously received in real- or near-real time (e.g., as the packets are being transmitted), but can be received in batches, randomly sampled, or with any other suitable timing (e.g., at any suitable frequency). The packets are preferably received at a high frequency (e.g., more than a threshold amount, such as 100, 300, 1000, 3000, 10,000, 30,000, 100,000, 300,000, 10-100, 100-1000, 1000-10,000, 10,000-30,000, 30,000-100,000, or 100,000-1,000,000 packets per second, etc.), but can additionally or alternatively be received with any other suitable frequency. The data analyzer preferably receives every packet generated by the machine, but can alternatively receive every Nth packet, receive random packets, or receive any suitable packet. The packets can be cached for a predetermined time window (e.g., and discarded thereafter), stored until they are consumed by the digital duplicate, stored until they are transmitted to the remote system, or otherwise managed. The packets can be stored in time-series within a common buffer, within a buffer specific to the packet address and/or respective digital component module, or otherwise stored.

[0024] Virtually simulating physical machine operation using a digital duplicate of the physical machine and the packets S200 functions to determine the current operational state of the physical machine and/ or each physical component. The virtual simulation is preferably performed in real- or near-real time, as the packets (e.g., instructions) are received, but can alternatively be performed asynchronously.

[0025] The virtual simulation is preferably executed by the on-premises system, but can be performed by a remote computing system (e.g., wherein the raw packets, derivatory data determined from the raw packets, or other information can be transmitted to the remote computing system), a local device (e.g., a user device, which can pull the cached raw packets or derivatory data from the on-premises system), or by any suitable device.

[0026] Virtually simulating the physical machine can include feeding the packets to the digital duplicate, wherein the digital duplicate virtually re-creates the physical machine operation (example shown in FIGURE 2). For example, the virtual simulation of a stamping machine preferably stamps at the same time (and/or with the same operation parameters, such as simulated pressure) as the physical stamping machine. In one variation, feeding the packets to the digital duplicate can include: transmitting (e.g., broadcasting) the packets to the digital duplicate, wherein the corresponding digital component module (e.g., digital component module that shares the physical component’s address) extracts packets addressed to the physical component from the transmitted packet stream and simulates physical component operation based on the packet. Alternatively or additionally, virtually simulating the physical machine can include feeding the packets or signals to a component event detector and/or machine event detector (discussed below). However, the physical machine can be otherwise virtually simulated. The virtual output of the digital component module can be: fed to secondary digital component modules (e.g., when the physical machine includes multiple physical components chained in series); compared to the output of the physical component module (e.g., extracted from subsequently received packets); treated as an output of the digital duplicate; or otherwise used. In a second variation, feeding the packets to the digital duplicate can include: identifying the digital component module associated with a packet (e.g., based on the packet address), and transmitting the packet directly to the identified digital component module for physical component simulation. However, the physical machine can be otherwise virtually simulated.

[0027] The digital duplicate of the physical machine functions to virtually simulate the physical machine by ingesting the same packet data and outputting the same outputs (e.g., data outputs, physical outputs, etc.) as the physical machine. [0028] In a first variation, the digital duplicate includes a single model representing the entire physical machine, wherein the single model ingests all packets (addressed to one or more physical components) and outputs one or more outputs. This model can include: neural networks, rules, decision trees, Bayesian methods (e.g., Naive Bayes, Markov), genetic programs, support vectors, kernel methods, probabilities, deterministics, or any other suitable module. The model can be generated using supervised training (e.g., wherein the training data can include the packets associated with observed outputs of the physical machine), unsupervised training (e.g., based on the packets), reinforcement learning (e.g., based on the packets and observed outputs), or otherwise generated.

[0029] In a second variation, the digital duplicate includes one or more digital component modules coupled together in the same manner as physical component module (example shown in FIGURE 2 and FIGURE 3). In this variation, each digital component module preferably represents a physical component within the physical machine (e.g., with a 1:1 ratio or match, such as a one-to-one association between each digital component module and the corresponding physical component it represents). However, the digital component module can additionally or alternatively represent a subset of a physical component, multiple physical components, or any suitable portion of the physical machine.

[0030] The digital duplicate preferably includes digital component modules connected with a set of digital couplings, but can be otherwise configured. The digital duplicate preferably includes digital component modules for each active physical component that receives a command (e.g., on the system bus), but can alternatively or additionally include digital component modules for passive physical components (e.g., that do not receive commands), digital component modules for a subset of the active physical components, or for any suitable set of physical components. In one example, the digital duplicate of a sewing machine can include a digital component module for the motor, but lack a digital component module for the needle.

[0031] The digital component module preferably shares the same address with the physical component, ingests the same packets as the physical component, and outputs a virtual representation of the physical component’s output. For example, the digital duplicate of a motor can ingest motor control packets and output the motor position (e.g., angular position). However, the digital component module can have a different address (e.g., wherein the digital duplicate can include a translator that translates the physical component address to the digital component module address), be re-assigned the physical component address, or otherwise adjusted. The digital component module is preferably generic and shared across multiple digital duplicates of different physical machines, but can alternatively be custom for the instantaneous physical machine.

[0032] The virtual representation of the physical component’s output (virtual output) is preferably a value (e.g., x, y coordinates associated with an actuator’s current position in a digital coordinate system), but can alternatively or additionally be a vector, a 2-D or 3-D digital rendering, or otherwise represented. The virtual output is preferably output on the same coordinate system as the physical component, but can alternatively or additionally be output on the physical machine’s coordinate system or a different related or unrelated coordinate system.

[0033] Each digital component module preferably includes an internal control loop that processes the packets (e.g., operation instructions) into the virtual outputs. However, the packets can alternatively be processed by an external system or otherwise processed. The control loop is preferably executed synchronously (e.g., in real-time, as packets are received), but can alternatively be executed asynchronously (e.g., based on available processing power, module criticality, module output frequency, a predetermined rule, etc.), or executed at any suitable time. The control loop can be a matching model (e.g., that matches control instructions to outputs), physics model (e.g., that converts the control instructions to motion, and determines the output based on the motion), the same control loop stored by the physical component’s controller, or use any other suitable model, rules, or set of equations.

[0034] The control loops for multiple digital component modules are preferably independently executed by the same processing system, but can alternatively be executed in a batch, executed in parallel, executed in series, executed by different processing systems, or otherwise executed. In one variation, the processing system can have specific memory or processor segments allocated to each digital component module. In a second variation, the processing system memory and/ or processing power can be dynamically allocated based on the digital component module being activated (e.g., receiving packets). However, the processing resources can be otherwise allocated.

[0035] The digital couplings function as a virtual representation of the relationships between physical components. The digital couplings can represent: digital connections (e.g., wherein an upstream component feeds its output to a downstream component), physical connections (e.g., wherein the position, operation parameter value, or operation mode of one physical component affects the operation of a second physical component), or represent any other suitable connection. For example, the digital duplicate of a physical sewing machine with a pedal controlling a motor’s speed can include a digital pedal module that outputs a pedal position, signal (e.g., voltage), or packet, wherein the digital pedal module is virtually connected to a digital motor module that ingests the digital pedal module output and outputs the motor speed and/ or angular position.

[0036] All or some of the virtual outputs of the digital component modules and/or digital duplicate can be cached for a predetermined time window (e.g., and discarded thereafter), stored until they are analyzed by the analysis model, stored until they are transmitted to the remote system, or otherwise managed. When a subset of the virtual outputs is stored, the stored virtual outputs can be those output by the final digital component module in a series of digital component modules, be virtual outputs from a preselected set of digital component modules (e.g., selected based on the physical machine type, based on the data required for the analysis modules, manually selected, empirically selected, etc.), or otherwise determined.

[0037] Analyzing the virtual outputs S300 preferably functions to reduce the high- frequency, low-level packets to low-frequency, high-level information. The high-level information preferably has a low frequency (e.g., number of entries, such as entries corresponding to high-level events, per unit time), such as a frequency below a threshold frequency (e.g., less than one event every 0.001, 0.01, 0.1, 1, 2, 5, 10, 20, 50, 100, 200, 500, 1000, 10,000, 100,000, 0.001-0.1, 0.1-1, 1-3, 3-10, 10-30, 30-100, 100-300, 300-1000, or 1000-100,000 s, etc.) and/or much lower than the packet frequency (e.g., less than the packet frequency by a factor of at least 10, 100, 1000, 3000, 10,000, 20,000, 50,000, 100,000, 300,000, 1,000,000, 1-30, 30-300, 300-3000, 3000-10,000, 10,000-30,000, 30,000-100,000, 100,000-300,000, or 300,000-10,000,000, etc.). The analysis is preferably performed in real- or near-real time, as the virtual outputs are generated, but can alternatively or additionally be performed asynchronously or in any suitable order. Additionally or alternatively, the packets themselves can be directly analyzed, without passing through S200.

[0038] The analysis is preferably performed using one or more analysis models, but can be manually or otherwise analyzed. The analysis model can be determined based on the digital component modules within the digital duplicate, the physical machine type, manually specified, or otherwise determined. The analysis model can be executed by the same processing system as that executing the virtual simulation, by a different processing system (e.g., a remote computing system, a SCADA system), or by any suitable system.

[0039] Each analysis model preferably includes one or more analysis modules (example shown in FIGURE 2), which can execute independently or be linked (e.g., wherein the output of one analysis module is passed to a second analysis module). In one example, the set of analysis modules are organized into a graph. In a second example, the analysis module can include a neural network or other model. However, the analysis model can have any other suitable data structure.

[0040] In one variation, all virtual outputs are fed into the same analysis model, wherein the constituent analysis modules can select and ingest the virtual outputs specific to that module. In a second variation, different virtual outputs are fed into different analysis modules of the analysis model. However, the virtual outputs can be otherwise supplied to analysis modules of the analysis model.

[0041] The analysis module functions to output a limited subset of derivatory data (e.g., derivative data, such as data derived from the low-level information such as the received packets). This derivatory data can be used as-is, be passed into downstream analysis modules, and/ or otherwise used. Each analysis module preferably includes an internal control loop, specific to the analysis associated with the analysis module, that processes the virtual outputs of a predetermined set of digital component modules. However, the virtual outputs can be processed by an external system or otherwise processed.

[0042] Multiple analysis modules’ control loops are preferably independently executed by the same processing system, but can alternatively be executed in a batch, executed in parallel, executed in series, executed by different processing systems, or otherwise executed. In one variation, the processing system can have specific memory or processor segments allocated to each analysis module (e.g., wherein new derivatory data can overwrite old derivatory data). In a second variation, the processing system memory and/or processing power can be dynamically allocated based on the analysis module being activated (e.g., the analysis module that ingests the virtual outputs being generated). However, the processing resources can be otherwise allocated. The analysis module is preferably generic and shared across multiple digital duplicates of different analysis models, but can alternatively be custom for the instantaneous analysis model.

[0043] The analysis module can detect events and/or otherwise determine that events have (or are likely to have) occurred (e.g., such that the analysis model is an event- driven model), preferably events associated with physical machine operation, summarize component operation, summarize machine operation, and/ or generate any other suitable higher-level derivatory data. The derivatory data is preferably a value or an array, but can alternatively be a secondary virtual simulation or any other suitable data structure. Examples of the derivatory data output by analysis modules can include: geofence ingress and/or egress (e.g., wherein the geofence is defined relative to the physical machine coordinates, digital duplicate coordinates, or digital component module coordinates), path parameters (e.g., absolute path length, apparent path length, etc.), part completion (e.g., detecting a product completion event), part failure (e.g., rejection, such as detecting a product rejection event), count, component state, uptime, number of operation sessions, failure rate, whether actual output (from virtual simulation) meets the expected output (determined from control program command), variation between actual and expected, error codes, deviations from typical operation (e.g., wherein typical operation is determined from historically received packets, historic virtual simulation, etc.), output rate (e.g., throughput), material loading events (e.g., associated with loading and/or reloading of material for physical machine operation, such as raw material for product manufacturing), and/or any other suitable data.

[0044] In one variation, the system includes a set of component event detectors (state detectors) corresponding to each physical machine component. The component event detectors preferably output a binary output for a single component (e.g., binary component states), but can alternatively or additionally output states for multiple components, output a continuous output (e.g., one of a continuum of potential values), or output any suitable output. The component event detectors preferably: receive a time series of data packets from the data analyzer (and/or a time series of signal changes) for the respective component(s); detect component events from the signals (e.g., by filtering the signals with an event-associated filter for the component); and determine the machine event from the set of detected component events. The component event detector (event model) can be a filter (e.g., state filter), a heuristic model, a classification model, a regression model, a deterministic model, a neural network, a fuzzy logic model, or be any other suitable model. The component event detector is preferably specific to the component, but can alternatively be specific to a set of components, specific to the component -machine combination, specific to the component function, and/or be otherwise related to the component. Component event detectors can be shared across multiple virtual machine models when the respective physical machines include the respective physical component, or be otherwise shared. The machine event detector can be a neural network (e.g., CNN, RNN, clustering method, etc.), a classifier, a deterministic model, a pattern-matching model, or be any suitable model. The machine event detector is preferably specific to the individual machine, but can alternatively be specific to the machine type (e.g., SKU number, brand, make and model, etc.), specific to the machine function (e.g., all sewing machines share a model, etc.), and/or be otherwise related to the machine.

[0045] The component event filters and machine event classifier(s) can be executed by: the on-premises system (e.g., the data analyzer, the controller, etc.), a remote computing system, and/or by any suitable system. In one variation, the component event filters and the machine event classifiers are executed by the on-premises system (e.g., the data analyzer, analysis device), wherein the detected machine events are transmitted to the remote computing system for subsequent monitoring and analysis. In a second variation, the component event filters are executed by the on-premises system (e.g., the data analyzer), wherein the detected component states or events are transmitted to the remote computing system for machine event analysis and detection. In a third variation, the data streams (and/ or state changes) are transmitted to the remote computing system, wherein the remote computing system detects the component event filters and the machine event detector. However, the machine events can be otherwise determined.

[0046] In some embodiments, the physical machine includes comprises an access control device (e.g., door, barrier, lock, latch, etc.) and/or access sensor (e.g., door state sensor, presence sensor such as a line of sight sensor, weight sensor, optical sensor, etc.) associated with a region for material loading (e.g., portion of the physical machine configured to retain the material). The derivatory data can include time-dependent access state information (e.g., door open, region entered, etc.), such as the amount of time for which the access control device was open, and/or material state information (e.g., material remaining, material retention region full, material retention region empty, etc.). The derivatory data can additionally or alternatively include information determined based on this information. For example, based on determining that the material loading region has been accessed and/ or accessible (e.g., in embodiments in which the region is not accessible during normal machine operation) for more than a threshold period of time (e.g., l, 3, 10, 20, 6o, 120, 200, 500, 1000, 0.1-1, 1-10, 10-30, 30-90, 90-200, 200- 500, 500-1000, or 1000-10,000 seconds), determining derivatory data can include determining that a material loading event has occurred.

[0047] All or some of the derivatory data (analysis results) from the analysis modules or analysis model can be cached for a predetermined time window (e.g., and discarded thereafter), stored until they are analyzed by a downstream analysis module, stored until they are transmitted to a remote system, or otherwise managed. When a subset of the derivatory data are stored, the stored derivatory data can be those output by the final analysis module in a series of analysis modules, be derivatory data from a preselected set of analysis modules (e.g., selected based on the physical machine type, based on the data required for downstream analysis modules, manually selected, empirically selected, etc.), or otherwise determined. The analysis results can be stored as: a single value (e.g., the most current value), a time series (e.g., values with associated absolute or relative timestamps), or otherwise stored. The analysis results data structure can be specified by the analysis module, the amount of memory allocated to the analysis module, manually specified, or otherwise specified.

[0048] In some embodiments, S300 includes classifying physical machine state (e.g., operation state) during one or more time intervals, preferably consecutive intervals of a predetermined (e.g., equal) duration (e.g., 0.1, 0.25, 0.5, 1, 2, 5, 10, 20, 50, 100, 0.1- 1, 1-10, or 10-100 minutes). For example, each time interval can be associated with a classification such as: normal operation, jammed, loading material, broken component, and/ or any other suitable classifications.

[0049] Transmitting the analysis results to a remote device S400 functions to present the derivatory data to a user (example shown in FIGURE 2). The analysis results are preferably transmitted by the on-premises system, but can be transmitted by any suitable system. The remote device can be a proximal mobile device (e.g., smartphone, tablet, etc.), an on-premises remote server system, an off-premises remote server system, or be any other suitable computing device. The analysis results can be broadcast, unicast, multicast, returned (e.g., in response to a request), retrieved, flooded, or otherwise transmitted. The analysis results can be transmitted: in real-time (e.g., as the derivatory data is being generated), in response to receipt of a request from the remote device, when sufficient bandwidth is available on a communications system (e.g., on the field bus, on a wireless communication system, etc.), at a predetermined time (e.g., scheduled for factory downtimes), or transmitted at any other suitable time. The analysis results can be transmitted over: a wireless communications system shared by the analysis system (e.g., on-premises system) and remote device, such as Bluetooth, WiFi, cellular, or mesh; a wired connection, such as the field bus or a separate Ethernet connection; or transmitted using any other suitable communications system. [0050] The analysis results can be subsequently presented to the user, used to generate notifications (e.g., sent to a managing entity or device in response to a combination of the derivatory data satisfying a predetermined condition), used to generate improvement recommendations, or otherwise used. For example, automatically generating improvement recommendations can include: identifying a first and second similar digital duplicate and/or physical machine (e.g., based on similar constituent digital component modules and/or digital couplings) associated with the same or different managing entities; comparing the respective performance metrics, determined based on the analysis results output by the respective analysis models; identifying a higher-performing physical machine based on the performance metrics (e.g., the physical machine with a higher metric value, lower failure rate, etc.); determining an operation difference between the higher-performing and lower-performing machines based on the analysis results (e.g., upstream analysis results, such as motor velocity); and sending a recommendation to the lower-performing managing entity based on the higher performing physical machine’s operation parameters (e.g., recommending use of the higher-performing physical machine’s operation parameters). However, the analysis results can be otherwise used.

[0051] The method can optionally include determining the digital duplicate of the physical machine S500, which functions to generate the model used to virtually simulate the physical machine. The digital duplicate is preferably automatically generated (e.g., based on the packets, based on the manually-specified machine type, etc.), but can optionally be semi-automatically generated (e.g., most of digital duplicate is automatically generated, then query a user to interpret or add modules for unknown signals), manually generated (e.g., the user manually selects digital component modules and digital connections), or otherwise generated. The digital duplicate can be determined by: the on-premises system, a remote device, a remote computing system (e.g., wherein raw information, such as raw packets, can be transmitted to the remote computing system and the digital duplicate can be pushed to the on-premises system), or by any other suitable computing system. The digital duplicate can be determined by: a master controller executing on the determining system; individually, by the digital component module executing on the determining system; individually, by a listening module (identification module) executing on the determining system; or otherwise determined.

[0052] The digital duplicate is preferably determined based on the received packets, but can additionally or alternatively be determined based on a machine type (e.g., manually-specified, determined based on sensor measurements, determined based on packet characteristics, etc.), based on signals sampled by on-board sensors, or based on any other suitable set of information. For example, the packets can be used to identify the components within the physical machine (e.g., based on the packet types, transmission frequencies, packet address such as an origin address and/or destination address, packet information, etc.), determine how the components are related or coupled together (e.g., based on the packet sources and endpoints, call and response packet timing, etc.), or otherwise used to generate the model.

[0053] The digital duplicate is preferably generated using a library or database of known, predetermined digital component modules, but can be manually created, empirically created (e.g., wherein the output of the digital duplicate or digital component module can be compared against physical machine or physical component outputs), or otherwise generated.

[0054] The digital component modules are preferably associated with: an internal control loop (e.g., model configured to interpret the addressed packets) and a predetermined packet fingerprint or set of packet stream characteristics (e.g., protocol, packet length, transmission frequency, OUI, etc.), but can additionally or alternatively be associated with a predetermined set of analysis modules, a predetermined set of digital connections and/or related digital component modules, machine type(s), address(es), or any other suitable information. The digital component modules can be manually generated, automatically generated, or otherwise generated. In a first example, the digital component module can be generated using: a packet stream supplied to the physical component and sensor measurements of the physical component output (e.g., using a neural network, etc.). In a second example, the digital component module is generated using: the control program’s command (e.g., used as a proxy for the intended component output) and resultant control packets, wherein the control packet characteristics can be mapped to the intended component output (example shown in FIGURE 3).

[0055] However, the digital component modules can be otherwise generated.

[0056] Automatically generating the digital duplicate can include: receiving packets transmitted by the physical machine (e.g., on the field bus), identifying packets addressed to an unknown component, caching the identified packets, identifying a digital component module based on the cached identified packets, and adding the digital component module to the digital duplicate (example shown in FIGURE 3). However, the digital duplicate can be otherwise generated. This can optionally include assigning the previously-unknown component’s address to the digital component module. The unknown component is preferably a physical component without a predefined digital counterpart (e.g., digital component module) in the digital duplicate, but can be otherwise defined. One or more versions of the digital duplicate can be concurrently generated based on the same (or different) packet stream, wherein the best digital duplicate can be converged upon, selected based on a metric (e.g., accuracy as compared to the physical component’s actual output), or otherwise identified and used.

[0057] Identifying the digital component module functions to identify digital component modules corresponding to the physical components of the physical machine. In a first variation, the digital component module is identified based on the packet address, wherein the packet address is associated with a specific physical component and corresponding digital component module.

[0058] In a second variation, identifying the digital component module includes: matching characteristics of the identified packets to known patterns associated with predetermined digital component modules and physical components (e.g., packet fingerprints associated with digital component modules). The digital component module can be further determined based on a physical machine type or class (e.g., manually determined, determined based on a set of sensor measurements, etc.), wherein the physical machine type can be used to limit the search space (e.g., used to filter or weight higher-probability digital component modules), and/or based on other information. Characteristics that can be used to identify the component include: packet signaling protocol, packet length, packet address, temporal characteristics of packet transmission (e.g., transmission frequency, relationship to other components’ packet transmissions, etc.), whether the packet is digital or analog, whether the packet is a command packet or response packet, packet content (e.g., interpreted based on a recognized, known signaling protocol), or otherwise determined.

[0059] The characteristics can be matched (or digital component module otherwise identified) by an identification module, wherein the identification module can use: classification (e.g., parametric, nonparametric), clustering, ensemble learning, multilinear subspace learning, real-valued sequence labeling, regression algorithms, sequence labeling, template matching, or any other suitable method. The identification module can be: manually generated, automatically generated, empirically determined, or otherwise determined. In one example, the identification module is automatically generated by: caching packets addressed to a prior, known physical component; extracting a packet fingerprint based on the cached packet(s); determining a digital component module for the physical component; and associating the packet fingerprint with the digital component module. However, the identification module can be otherwise generated. However, the packet stream can be otherwise matched to a digital component module.

[0060] The selected digital component module can optionally be validated using the physical component’s output packets, sensor measurements characterizing physical component output (e.g., sensors retrofitted onto the physical machine), manually validated, or otherwise validated.

[0061] In one example of the second variation, the digital duplicate can be initially populated by a set of identification modules (e.g., an identification module for each unique packet address), wherein each identification module eventually selects a digital component module replacement based on the respectively addressed packet stream’s characteristics. In a second example of the second variation, an identification module can listen to the entire packet stream, and select one or more digital component modules based on the packet stream as a whole. [0062] In a third variation, identifying the digital component module includes: recognizing the packet protocol; interpreting the packet, based on the recognized protocol, into a set of commands; and identifying the digital component module based on the command characteristics (e.g., command type, command call, command frequency, combination of commands, command patterns, etc.)· The digital component module can be identified by a similar identification module as that discussed above (e.g., trained on command characteristics instead of packet characteristics) or be otherwise identified.

[0063] In a fourth variation, identifying the digital component module includes: receiving sensor signals indicative of physical component operation and identifying the digital component module associated with characteristics of the sensor signals (e.g., with the sensor measurement fingerprint). The digital component module can be identified by a similar identification module as that discussed above (e.g., trained on signal measurement characteristics instead of packet or command characteristics) or be otherwise identified.

[0064] In a fifth variation, identifying the digital component module includes: supplying the packet stream to a neural network or other module, wherein the neural network can output an identifier for the physical component based on the packet stream. Alternatively or additionally, the neural network can be specific to a physical component or digital component module, wherein the neural network outputs a decision on whether the packet stream is indicative of the associated physical component or digital component module. However, the digital component modules within the digital duplicate can be identified from a schema associated with a vendor for the physical machine, identified based on the packet protocol used (e.g., wherein the protocol is only used with a limited set of physical components), identified based on data supplied by the physical machine’s controller (e.g., metadata, component name), or otherwise determined.

[0065] Generating the digital duplicate can optionally include determining the digital couplings between the digital component modules. The digital couplings can be determined: automatically, semi-automatically, manually, empirically, iteratively, or otherwise determined. The digital couplings can be determined based on: the machine type (e.g., wherein the machine type is associated with a predetermined set of digital couplings), different component packets’ timing, packet types (e.g., confirmation packet), other digital component modules, or any other suitable information.

[0066] In a specific example, determining the digital duplicate can include: listening to the packet stream; creating a new node for each unique packet address, each node representative of a physical component and initially populated with an identification module; at each identification module, receiving packets addressed to the respective address, extracting packet characteristics from the received packet stream, and identifying a predetermined digital component module based on the packet characteristics; and replacing the identification module with the identified digital component module (e.g., after a threshold confidence level has been surpassed).

[0067] Determining the analysis model functions to determine the set of analyses to run on the virtual simulation. The analysis model can be manually, semi-automatically, automatically, or otherwise determined. The analysis model is preferably generated by a remote computing system and stored on the on-premises system, but can alternatively be otherwise generated and stored on the remote computing system, or otherwise generated or stored. The analysis model and/ or modules association with a machine type, digital duplicate, digital component module, and/or other data structure can be empirically determined, crowdsourced, learned, or otherwise determined. Each analysis module can be manually generated, automatically generated (e.g., based on user feedback), or otherwise determined.

[0068] In a first variation, analysis modules pre-associated with a given digital component module can be added to the analysis model. For example, digital motor modules are associated with a rotation count (analysis module). In a second variation, a predetermined analysis model is associated with a given machine type. For example, the digital motor module (digital component module) within a sewing machine (machine type) can be associated with a stitch counter (analysis module). In a third variation, analysis modules are manually selected and/or linked together to form the analysis model. In a fourth variation, a predetermined set of analysis modules can be associated with a given set of virtual outputs. However, the analysis model can be otherwise determined. [0069] In some embodiments, the data analyzer (e.g., packet analyzer) includes a network tap and an analysis device. The network tap is preferably a passive tap, such as wherein transmissions (e.g., packets) on the network are preferably not substantially altered by the presence and/or action of the tap (e.g., wherein the transmissions propagate on the network without or substantially without delay), but can additionally or alternatively include an active tap (e.g., which captures, duplicates, and/ or retransmits the packets) and/ or any other suitable tap. The network tap is preferably communicably coupled to the analysis device (e.g., by a wired connection, such as an Ethernet connection). The network tap preferably transmits the packets it observes on the network to the analysis element, but can additionally or alternatively store the packets, filter the packets (e.g., prior to transmission), transmit the packets to any other suitable endpoints, and/ or otherwise act upon the packets.

[0070] The analysis device is preferably a computing system (e.g., local computing system, such as a computer collocated with the network tap), but can additionally or alternatively include a remote computing system and/or any other suitable analysis elements. The analysis device preferably functions to identify, filter, and/ or otherwise analyze the packets, and can additionally or alternatively transmit the packets to one or more downstream devices (e.g., remote computing system) and/or perform any other suitable functions. The packets are preferably analyzed in response to (e.g., in real-time or near real-time, such as immediately in response to) receipt by the analysis device, but can additionally or alternatively be analyzed at any other suitable time.

[0071] Identifying the packets preferably includes determining which physical component(s) the packets were transmitted to and/or from. For example, the packets can be identified based on a packet address (e.g., wherein packets including an address associated with a particular physical component are preferably determined to be associated with that component), packet content (e.g., wherein instructions for a particular type of physical component can be determined to be associated with that physical component), and/ or any other suitable information.

[0072] Filtering the packets can include discarding one or more packets, saving the packets but only transmitting a subset to a downstream device such as a remote computing system, and/or filtering in any other suitable manner. The packets can be filtered based on the associated physical component (e.g., wherein packets associated with a first set of physical components are not filtered out, wherein packets associated with a second set of physical components and/or not associated with the first set of physical components are filtered out, etc.), state changes (e.g., delta filtered, such as only saving and/ or transmitting packets associated with changes in physical machine state), packet content (e.g., packet type, such as keeping instruction packets, sensor measurement packets, and error packets, but filtering out all other packets; instruction type; control values and/or sensor data values, such as filtering packets including or not including values within threshold ranges such as predetermined ranges; etc.), and/or any other suitable criteria.

[0073] A person of skill in the art will recognize that the“packets” described herein can include not only Level 3 packets (e.g., packets including frames) and/or Level 2 packets (e.g., frames), but can additionally or alternatively include any other suitable communications and/or communication blocks (e.g., electronic and/or optical signals, preferably digital signals but additionally or alternatively analog signals and/or any other suitable signals), and analogously that the “data analyzer” can additionally or alternatively be configured to analyze any other suitable communication blocks.

[0074] A person of skill in the art will recognize that the elements described herein as“digital” (e.g., digital duplicates, digital components, digital analysis modules, digital machines, etc.) can additionally or alternatively include any suitable virtual elements (e.g., virtual duplicates, virtual components, virtual analysis modules, virtual machines, etc.), regardless of whether any or all such virtual elements include a digital representation.

[0075] An alternative embodiment preferably implements the some or all of above methods in a computer-readable medium storing computer-readable instructions. The instructions are preferably executed by computer-executable components preferably integrated with a communication routing system. The communication routing system may include a communication system, routing system and a pricing system. The computer-readable medium maybe stored on any suitable computer readable media such as RAMs, ROMs, flash memory, EEPROMs, optical devices (CD or DVD), hard drives, floppy drives, or any suitable device. The computer-executable component is preferably a processor but the instructions may alternatively or additionally be executed by any suitable dedicated hardware device.

[0076] Although omitted for conciseness, embodiments of the system and/or method can include every combination and permutation of the various system components and the various method processes, wherein one or more instances of the method and/or processes described herein can be performed asynchronously (e.g., sequentially), concurrently (e.g., in parallel), or in any other suitable order by and/or using one or more instances of the systems, elements, and/or entities described herein.

[0077] The FIGURES illustrate the architecture, functionality and operation of possible implementations of systems, methods and computer program products according to preferred embodiments, example configurations, and variations thereof. In this regard, each block in the flowchart or block diagrams may represent a module, segment, step, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block can occur out of the order noted in the FIGURES. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/ or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

[0078] As a person skilled in the art will recognize from the previous detailed description and from the figures and claims, modifications and changes can be made to the preferred embodiments of the invention without departing from the scope of this invention defined in the following claims.