The software defined network has become all the rage lately for reasons that seem to vary and are caught up in interesting perceptions. One view was that it allowed a single network to be controlled centrally and divided up logically to prevent different groups from interfering with one another, well that's true. Another view is that it provides a central place of management that configures and monitors the network for performance and faults, well that is true.
The basis is really the separation of the control plane (configuration and management) onto a server that centrally controls many network nodes. From the data plane which are the switches and routers that pass the data for the application from one end device to another, or many. The SDN controller communicates over a secure communications path using an API supported by the network device.
Yet what may be the most significant possibility of SDN is the ability to use programmatic control from the very applications that use the network for transport to stipulate any number of services that application needs from the network. We are seeing this in data centers that will allow end user departments to define a complete network for say ERP from within the ERP application and no help from IT. Why not for controls? And since SDN is based on open source initiatives the ability for anyone to create and market applications for say a controls system is very real.
Networks historically have belonged to Information Technology departments and they have viewed any network outside their control as rogue. On the other hand industrial networks have been under the control of the operational technology (OT) folks in the manufacturing organization simply because if production stops then so does the money. And IT and OT have very different motivations on how to manage what would appear on the surface to be the same kind of technology. This has led to interesting relationships as each side works to insure the other does not take over the entire environment.
While computers and programming have traversed from the IT to the OT groups to the point where each group has comparable expertise in say c++ programming or database development. However those of us in network have managed to keep networks and network technology shrouded in mystery to insure that no network change can be made without us. And yes we do know that cannot continue much longer. But are the networks ready to have the veil of secrecy lifted? I think they are.
Allowing the controls engineer to treat the network as another set of elements with variables that are part and parcel of their process will remove any need for specialized expertise to set up that network as part of the process.
What would this possibly mean? If the controls engineer knows that he must maintain a scan rate across a cell that has an isochronous rate of 10 milliseconds and a deterministic rate of 20 milliseconds with signal jitter no greater than 250 microseconds and they can simply stipulate that in their machine programming tool to be sent to each node in the network for the defined path of that signal. And then further stipulate that other converged applications data cannot impact the control loop.
This is accomplished by the creation of applications that use network information and programmatic information to define the networks per the control engineers' program. These intermediate applications should generally be defined by 5 essential pillars of functionality (as described by Cisco Distinguished Systems Engineer, Scott Kirby):
The diagram depicts how this may be structured logically:
Automation control manufacturers, machine builders and end users would be able to create specialized and generic applications that will add more value to the process control solution they have created by making better use of the Industrial Ethernet and Wireless network.
This is what I think. How about you?
Dave Cronberger