Remote Process Control Using a Reliable, Real-Time Protocol
Observe and control remote processes reliably and in real time, with provision for secure, proprietary process control.
OpenFlow software defined networks may be able to deliver reliable, high-speed communication with end-to-end latency that is predictable and essentially constant. Such a capability would be the ideal platform on which to build a real-time remote sensing capability, combine it with local information processing capability that produces proprietary control commands, and then deliver those commands in real time to the remote destination where critical steps in a process are performed.
From the area of advanced manufacturing, consider the application of reliable, real-time observation of the process that is taking place within the build volume of a remote 3-D printer operated by a manufacturing service provider. With the proposed connection established to the printer and appropriate sensing systems, the article designer’s local computer could do much more than simply download the 3-D fabrication path geometry and material(s) selection command sequence to be executed in an open loop fashion. Instead, in real time that computer could send printer commands, monitor their effect on the formation of the article, compare those observations with the design, and apply a perhaps proprietary feedback control algorithm to adjust future printer commands, achieving a real-time feedback control loop across the internet. The end goal could be to realize tighter control of process, materials, and tolerances, or it could be to reserve some portion of the printer command generation to a computer secured by the designer, thus concealing a portion of the manufacturing knowledge from the 3-D printing service provider. Generalizing this idea, one can imagine the designer establishing a connection to a third-party control algorithm service provider that can deliver advanced process knowledge or superior computing capability or both and so on, as critical components of the total process can be located flexibly.<br/>
If we imagine that the 3-D printer and sensors of the example above are replaced by a surgical robot beside a trauma patient in an emergency room or on a battlefield, and that the designer’s local computer and algorithm is now the trained mind and hands of a specialist physician, then the process becomes a surgical intervention on behalf of the patient, and the proposed communication capability serves an example in the field of healthcare. The OpenFlow connection postulated would provide the physician with the same confidence to perform procedures as if she were able to reach out and touch the patient. Every emergency room or battlefield medevac location with an OpenFlow connection could have the services of remote healthcare specialists when needed.
How will your idea make people's live's better?
Being able to reliably control a manufacturing process that is remote to the user will empower engineers, artists, and experimenters who are not near the means of production. Manufacturing teams can each bring their specialized skills and capabilities together without regard to limitations of geography. Delivering healthcare to patients who are far from the appropriate specialist will yield better patient outcomes.
How does your idea take advantage of next-generation networks?
The ability to build a fault-tolerant, fixed latency communication path does not exist with todays TCP/IP Internet but OpenFlow switches can establish redundant communication paths and merge paths. Key needs here are to dynamically build redundant, similar length and delay paths in the dynamic network graph. See U.S. Patent 4,523,273 [Adams and Siegel] for a networking idea that provides for two paths (single redundancy and single fault tolerance) between network endpoints. The OpenFlow programming primitives of multipath, link aggregation, and goto appear to be sufficient to build multiple paths between two network access points and to balance the time delays of each of the paths. With redundant, balanced paths established in a sufficiently fast network, then fixed-latency, real-time communication with fault tolerance is possible. In the event of a path outage, a replacement path would be built while the remaining path(s) support(s) communication between the access points, thus reestablishing the desired level of fault tolerance. Further investigation and development is needed to establish the precise capability of the OpenFlow Switch Specification version 1.1.0 to support the proposed communication style. It may be that the switch specification would need to be revised. New methods of managing for or responding to congestion, attacks, and other real world challenges will likely need to be developed. Assistance in this investigation and development is welcomed.