A COVID-19 Challenge Conquered
In the early days of the COVID-19 pandemic, ICE Process Management faced a daunting task: conducting an integrated MCC-DeltaV Factory Acceptance Test (FAT) without the luxury of having DeltaV hardware physically present. The urgency was high, and availability of on-site personnel was severely limited due to pandemic protocols. How could we bridge a physical network to a non-existent DeltaV network without anyone on-site?
The Challenge
The scenario is clear: an urgent need for an integrated MCC-DeltaV FAT, but no DeltaV hardware available on-site to connect to. Our team had to think outside the box and find a solution that would work quickly, bypass purchasing protocols, and avoid executive-level project management approval requirements. Any element of unnecessary delay had to be avoided.
Leveraging Cloud-Based DeltaV Development
Our starting point was our internal cloud-based DeltaV system, set up for development. However, we had never attempted to connect physical devices to this environment before. The various MCC components required connections via both Modbus TCP and Ethernet IP. Unfortunately, using a standard VPN for Ethernet/IP was not feasible due to its reliance on packet broadcasting. Standard VPN’s operate on Level 3 routing, which disallows the broadcast function from completing its tasks, thus Ethernet/IP communications are blocked on standard VPN’s.
The Unexpected Solution
We scoured the internet for answers, seeking technically feasible solutions that wouldn’t get bogged down by business management hurdles or an excessive price tag. We hoped to identify a VPN, suitable for connecting an Ethernet/IP network with a virtual EIOC. To our pleasant surprise, we stumbled upon an open-source VPN solution that operated on Layer 2 of the network. This discovery meant we could handle the Ethernet/IP protocol effectively within the financial constraints and the time pressure.
Deploying the Solution
The next challenge was deployment. The open-source L2-VPN came packaged for Windows OS, which conveniently matched the spare laptop we had on hand. Equipped with a WiFi card and a single Ethernet adapter, the laptop qualified to become our network bridge. However, there was still a lingering concern: Could the ground crew at the MCC fabricators be relied upon to build the network and configure the settings? After all, this was hardly a common scenario to deploy. We loaded the laptop with a remote-viewing software package as a fail-safe.
Success Amid Uncertainty
The ground crew successfully connected our laptop to the Wi-Fi network and proceeded to pass control to us remotely. A single physical ethernet cable connected the MCC network to our laptop’s ethernet port. We then performed the integration to our cloud-based DeltaV system remotely and tested the VFD’s and starters from the cloud-based EIOC to the network nodes.
Altogether we had this solution in place within 3 days. We were able to carry out the FAT was the following week, with full confidence that check-outs would commence first-thing on Monday morning. Most remarkably, the only cost for this solution was the shipping of a laptop to site, so that we could confirm that all integrations were complete prior to the commencement of the FAT.
Some time had passed when we asked the local Emerson Impact Partner to deploy a similar solution for another FAT. They claimed it could not be done. At this point we were proudly able to proclaim that we had already successfully executed this scenario and were able to provide them with the architecture and configurations.
In summary, this experience taught us that resourcefulness, adaptability, and a willingness to explore unconventional solutions are essential for achieving success—even when faced with significant limitations and pressure. In this case, it proved to be a good thing that our curiosity was never going to be discouraged by anyone claiming something is impossible.
