layer communications into four levels from field
devices to corporate business systems.
Click on image for a larger illustration.
An “ideal” network-monitoring tool shouldn’t impact the network it’s watching. However, in practical terms this isn’t possible. So, we aim to minimize interruptions or traffic on the network by operating in passive or monitoring mode and simply recording the information flowing by or through the tool, which in many cases is software residing either on a computer or dedicated server/appliance on the network. One way to minimize the impact on the network is to transmit the data being gathered via a separate or parallel network. In the case of Level 0 and Level 1 (Figure 2), wireless networks are starting to handle some of this parallel data transfer. Wireless networks have a different range of conditions, constraints and considerations than conventional or wired networks (see Wireless comes with strings below).
It’s often the “little things” that can create the greatest grief — this certainly is true for network systems. Surprisingly, terminations, which everyone takes for granted, are one of the largest causes of problems. Difficulties can develop if the terminations aren’t properly torqued, or through vibration, someone tripping over a cable, corrosion (because the unit isn’t properly vented or the vent becomes plugged), short circuit (this one will often manifest itself right away), surge and associated damage, or electromagnetic or radio frequency interference. So, it’s critical that this backbone of the system be properly installed and maintained.
Fortunately, the majority of the analytical tools on the market, especially if they’re connected online, can catch many post-start-up problems as they develop and before they cause a process interruption.
A common practice to maintain high levels of reliability is to install redundancy. This approach is often employed at Levels 1 and 2, and, occasionally for special applications such as safety systems, at Level 0 as well. Redundant systems have duplicate hardware identically configured (I/O points, software, etc.) continuously monitoring the operating condition of each other, so that if one unit fails the other is ready to assume full operation without interruption to the process.
This fail-over capability is often used as a means to install system upgrades. When an upgrade needs to be made, one of the redundant units or nodes is taken offline, the upgrade (typically software) is installed and the upgraded unit is brought back into service as the standby or secondary system. The primary system (which still has the old software release) then is forced to fail-over, so the backup unit with the upgrade installed becomes the primary controller and the upgrade can be made to the second unit.
Another practice to maintain high reliability is to have a test bed that has a similar architecture and layout as the installed control system, with at least one of each component of the Level 1 and 2 system being used and running. This serves two purposes: first, it provides a set of spare parts that are known to be functional and at the same software and firmware revision levels as the running plant and, second, it’s where new software updates are first tested by plant staff, to verify the integrity of the upgrade as well as to check the procedure developed for the upgrade. Only larger facilities typically have their own test beds. However, every distributed control system (DCS) supplier uses just such a system as part of its quality assurance, development and release process.
Today, software largely is COTS technology, predominantly Windows. This brings with it the associated task of managing all the patches and upgrades for the operating system and also for related software such as virus scans, firewalls, etc. Unfortunately, as yet there isn’t an automated tool to help. You must work closely with your host system supplier because, in many cases, a change to the software also can alter system settings required for control communications. The best form of security here is to subscribe to the support program of your system software suppliers and have them do the necessary testing to verify that any upgrades won’t impact your system. Regardless, test them on an offline system first.