What is ISA18?

ISA18 is the standard and guideline for alarm systems including annunciators, process automation systems, and the general development, design, installation, and management of alarm systems in the process industries. It’s main purpose is to establish terminology and practices for alarm systems, including the definition, design, installation, operation, maintenance and modification and work processes recommended to effectively maintain an alarm system over time.

ANSI/ISA-18.1-1979(R2004), Annunciator Sequences and Specifications. This standard is primarily for use with electrical annunciators that call attention to abnormal process conditions by the use of individual illuminated visual displays and audible devices. Annunciators can range from a single annunciator cabinet, to complex annunciator systems with many lamp cabinets and remote logic cabinets. The sequence designations provided can be used to describe basic annunciator sequences and also many sequence variations.

ANSI/ISA-18.2-2009, Management of Alarm Systems in the Process Industries. This standard provides requirements and recomendations for the activities of the alarm management lifecyle. Lifecycle stages include philosophy, identification, rationalization, detail design, implementation, operation, maintenance, monitoring & assessment, management of change, and audit.

Update: For those of you who are within the Berks County and Lehigh Valley, PA area, the ISA Lehigh Valley Section is holding a free presentation of ISA18 (by Todd Stauffer, exida) on September 10th. More details on the event here. Registration is necessary; Members/ Non-members are welcome.

This discussion has come up quite often in the field. Here are my thoughts …

External taps allow a more accurate timestamp with zero packet delay and the physical errors are actually captured; whereas switches may drop the ethernet frames that have CRC errors. This defeats the purpose of trying to monitor, troubleshoot or analyze traffic. I WOULD want to see errors to determine what the problem is instead of it being discarded.

The packets that taps see are WYSIWYG i.e. there isn’t any outside influence on the traffic from the switch or any other source — what you see on your traffic analyzer is unfiltered, *real* and accurate. I can’t say this of mirrored traffic on SPAN ports as 1) the traffic seen is only as good as how the switch is configured and 2) only as good as how the switch functionality/ fabric performs.

So consider this:
- Taps are *dumb* and passive, they do not have the capability of adding traffic within the monitored ports or vice versa
- Taps don’t alter the frame of the packet nor does it introduce jitter or distortion
- Taps do NOT filter packets regardless of error type, IP version, size, and bandwidth

SPAN (or Port Snooping) may impact network performance as there is packet forwarding and duplication to the port that you are using to monitor/analyze. Then there is Cisco who has multiple spanning types (depending on what switch model you use) which may impact the way the Ethernet packets are transported differently.

RSPAN has a downside with its packet timing; the timestamp may not be true or indicative of when it actually reaches the remote port i.e. the timing of the packet may be skewed. Since RSPAN copies packets and distributes it to the remote ports, high volume scenarios may impact network traffic within the switch and propagate to its interconnections. What that means, is that you may have multiple problems added to your network in addition to what you already have. That is one reason why I would stay away from using RSPAN within an industrial control system network.

Taps aren’t totally golden, they do come with some drawbacks. The main drawback is that the network may need to be disrupted for a short period of time so that one can be installed. That may not be an option in certain networks that have to keep running. Putting taps on the network introduces another point of failure as well. Thirdly, taps may incur extra costs within the network system.

So where does that leave you in the decision of which one to use?

It’s a trade-off, the short disruption when installing a tap is manageable (and controlled). SPAN may potentially cause lengthy, uncontrolled disruptions. Uncontrolled disruptions with SPAN may be catastrophic as it is unexpected; short disruptions with tap installations are expected and everyone is prepared for it. Catastrophic occurrences within industrial networks may cost a manufacturing plant thousands of dollars. A worse scenario would be a bit not latching (within a control system), causing a Safety PLC to function incorrectly (or not function at all).

Before deciding which method to use, it would be wise to access the situation within an industrial network first. It goes without saying that monitoring/ troubleshooting of network traffic should always be done by a person that is comfortable performing the related pre setup tasks. You have to make sure that proper thought has been put into using the right analysis method as the switch mechanisms may cause more problems to the network than what you started out with.

My preference is to use external taps for analyzing/ monitoring networks. It is just more indicative of how the network performs at the given time/ instance. It is passive like and there isn’t the worry of it disrupting the network (after the initial installation) as compared with the SPAN alternative. A good industrial network design/ installation would most often have taps at strategic points of the network for instant access to network traffic. Datacom and Net Optics are examples of manufacturers who make network taps.

Of course, the debate of using the network tap vs. SPAN has been long argued by vendors championing its cause. From an industrial automation point of view, the decision of which method to use in troubleshooting may ultimately come down to who is going to have the least impact and risk on the network.

A typical tap setup within a network:

(Graphic source: Net Optics)

Here are some good articles on the web about Taps, SPAN and RSPAN:

SPAN port of Tap? (Tim O’Neill)
RSPAN … Friend or Foe? (Tim O’Neill)
Tap vs. SPAN Ports (Net Optics)
Network Taps vs. SPAN Ports (Datacom)

• DNS lookup in Connect Mode – Allows the name of a remote machine to be resolved automatically

• Expanded Monitor Mode commands ‘NC’ and ‘co’ to include name server IP address – Shows the unit’s current IP address, gateway, subnet mask, and DNS server

About the UDS1100

The Lantronix UDS1100 networks any RS232, RS422 and RS485 equipment to Ethernet, allowing quick remote access, management, monitoring and control capability. Configuration can be done via HTTP, DHCP, Telnet, serial or the Lantronix DeviceInstaller utility.

Other features:

• Transparent network device enabler that uses serial tunneling
• Web page management capability that can be customized to your applications
• On-board flash memory for future system software upgrades and non-volatile web page storage
• Onboard modem emulation mode that replaces the need for dial up modems; accepting standard modem AT commands on the serial port — thus eliminating dedicated modem and phone lines while leveraging the bandwidth of Ethernet
• Total Com Port Control with TruPort Technology enabling Windows-based applications to access and control serial ports on the UDS1100 as if they were actually local PC serial ports. This allows “existing applications to seamlessly transition from controlling local devices to true remote monitoring and control of devices around the world”.

UDS1100 version 6.6.0.1 download and release notes

UDS1100 product store link