1660605079428 Cg1008 Feat3

Why Does Your Process Sampling System Need a PC?

Aug. 10, 2010
The Proposed Sensor Actuator Manager (SAM) Controller and Software Applets Could Help the New Sampling/Sensor Initiative (NeSSI) Succeed

By Rob Dubois

One can safely say that a modern refrigerator has more automation than your average process analytical sample system. Why is this?

Since the launch of the New Sampling/Sensor Initiative (NeSSI), significant strides have been made to advance automation in the process analytical community. One tangible result has been the introduction of physically small, low-power, intrinsically safe (IS) buses—IS CAN-in-Automation and Siemens' I2C—which are tailored specifically for process analytical requirements.

However, despite these efforts and others over the past 10 years, the move to sampling system automation has been glacial. Could the lack of a small, programmable PC to manage the sub-systems, provide simple control and deal with signal requirements be regarded as the greatest contributor to this delay?

What is SAM?

The Sensor Actuator Manager (SAM), as proposed by NeSSI, is a small, hockey puck-sized, programmable, low-cost, process automated controller (PAC)-type device rated for hazardous area operation and packaged for operation across a wide range of environmental conditions. It's a mini-PC equivalent for process analytical systems. SAM serves four major functions (Figure 1):

SAM in the Middle

Figure 1: The Sensor Actuator Manager (SAM) is a small process automated controller (PAC)-type device or mini-PC that serves four main functions: It connects to a powered serial bus; contains transportable software applets, provides universal connectivity and connects to local and remote maintenance devices.

  • It connects to a powered serial bus communicating with sensors, actuators and remote I/O modules. This bus can be intrinsically safe or non-intrinsically safe depending on the application. (This can be considered as a purpose-based bus similar to USB.)
  • It acts as a container for transportable, industry-standard "applets" that are used for automating repetitive sampling, analyzer shelter and analytical measurement tasks.
  • It provides a universal connectivity solution to a secure plant DCS.
  • It connects to local and remote maintenance devices, handheld configurators (including portable PCs) and the Internet. This connection would be considered non-secure and "hermetically sealed" from other SAM functions. This connection may be wireless.

Stakeholder Requirements

To better understand these issues, let's look at SAM through the eyes of various process analytical stakeholders, and see what features of a SAM would have value for them. Can SAM serve as a common denominator for these diverse needs?

For example, to an operator, the most important element is confidence. Nothing will be more damaging to the credibility of an installation than running a process based on an assumption that the data is correct when it isn't. Operators don't need detailed information; they need a performance factor. That's why the simple concept of a traffic light—red light (bad data), green light (good data), and yellow light (impending failure)—is used as an operator alert system. To have confidence, an operator needs to know the status of the complete analytical system, which includes the analyzer + sampling system + auxiliary systems.

For maintenance staff, automation is a boon if it makes troubleshooting and configuration easier, and provides better performance. It must be simple to use and not require complex programming. Having remote and local connectivity to troubleshoot and monitor an analytical system, having a way to visualize flow paths and a mechanism to access service documentation in the field are all important. Being able to control sample flows, pressures and temperatures within the analytical environment is maintenance friendly.

Similarly, system integrators would benefit from having:

  • Interoperability with disparate system connectivity.
  • Seamless sub-system connectivity of shelter, analyzer, pre/post conditioner, HVAC and sample system.
  • Integrated heater and heat-tracing controls.
  • Ability to self-test each module prior to drop-shipping.

In addition, DCS system and IT gatekeepers require that the data transmitted over their networks and into their distributed control systems (DCS) systems be as secure as Fort Knox. Wireless can be a dirty word. Security and data integrity is paramount.

Meanwhile, analytical sensor developers and analyzer manufacturers find it difficult and costly to penetrate the process analytical marketplace. Not only do they need to come to grips with sample systems, but they also need to come to terms with DCS connectivity, system validation and electrical hazardous classifications. There is a strong desire to have a universal way to connect to anyone's DCS or SCADA system. The analytical sensor designer may need custom programming requirements, packaged for industry, to control their device.

Also, for analytical system designers, it is now evident that much of the hard-won learning is complete with respect to sampling, and that the crystallization of this knowledge needs to be captured in standard practices for deployment on future projects. There needs to be a flexible way of repurposing analytical designs to satisfy the nuances of each new project. The ability to link together various subsystems gives design flexibility, reduces cost and speeds design.

Is Embedded SAM the Sole Solution?

Embedding the SAM in intelligent analyzers such as gas chromatographs (CG) may seem like the complete answer, but it is not. Still, two major GC manufacturers (Siemens Industry and ABB) are doing so, even though 95% of the analyzers purchased in the process industries are not GCs. 

Consequently, there remains a significant inventory of non-intelligent legacy equipment that could be upgraded to avoid obsolescence. For example, one multi-national chemical manufacturer was interested in adopting NeSSI, but after finding that there was no easy way to manage the signals, its developers became frustrated—and they remain on the sidelines. Embedding SAM in a smart device is good, but not the complete answer.

Applets Proposed at CPAC

One way for SAM to help standardize the repetitive functions required of a process analyzer system is with transportable software applets. Doing this starts with asking a question: Why does each manufacturer come up with a sample stream switching routine? At some point, they all look the same. In fact, CPAC has published a list of over 60 tasks which potentially could be used as applets. The use of applets, written as function blocks using IEC-61131-1, was well-accepted at CPAC. This standard is supported by PLCopen (www.plcopen.org). A not-for-profit group to manage and guarantee conformity for applets also was proposed as a solution.

SAM's Secure Connectivity to DCS

Large end users have developed connectivity rules to tie analyzers into their own DCS systems, and sophisticated systems suc as gas chromatographs come with their own serial connectivity mechanisms. As a result, a SAM could provide a universal connectivity solution and come with needed security features already solved.

Some members of the analytical community have been actively involved with the OPC-UA group (www.opcfoundation.org) developing an analytical companion specification for DCS connectivity. This initiative originates from pharmaceutical companies associated with the process analyzer technology (PAT) initiative. This may be the common solution we seek to connecting our networked analytical devices serially to the DCS in a secure manner. A SAM outfitted with an OPC server would give end users a robust way to tie their analytical network into anyone's DCS system. Each subsystem needs to have an Ethernet port. It was noted that the legacy, open protocol Modbus is important. Still, there remains lots of legacy equipment out there.

Get on the NeSSI-bus

In addition, the CAN-in-Automation (www.can-CiA.de) organization has off-the-shelf profiles for sensors, such as pressure, and controllers. New, generic profiles could be created for analytical sensor manufacturers to simplify and standardize the connection of a device to a NeSSI-bus. This ability would allow manufacturers to maintain their own intellectual property for special capabilities they want to add to their device. 

Cooperation among analytical sensor and actuator manufacturers is an ideal way to simplify connectivity to the NeSSI-bus. The CiA organization has proposed the formation of a special interest group (SIG) to deal with analytical sensors and actuators.

SAM's Form Factor

Presently, we use small, field-mounted pressure and temperature instruments packaged for hazardous areas. Likewise, it's important to have SAM packaged in a compact instrument enclosure. Unfortunately, there are no small packaged devices yet on the market to serve these needs. Repackaging a conventional PLC or PC for industrial use adds a layer of cost, size and engineering complexity that discourages the use of conventional solutions. Use of conventional discrete and analogue I/O is costly and inflexible for our needs.

SAM's Remote Connectivity

The new generation of maintenance technicians grew up with Nintendo, Blackberries, Google, etc. How long do you think they are going to tolerate the status quo in process analytical automation? Connectivity to the Internet, which is firewalled from plant functions, is important. Secure wireless is the ticket that allows maintenance personnel to get local and remote connectivity with an analytical system. We do our banking over the Internet, so we can certainly build in security features for analytical.

SAM's Visual Display

Currently, we use embedded screens in many analyzers to serve as operator interfaces. Custom text entries are common, but they're not so user-friendly. The use of a portable, Div. 2, wireless, portable PC/PDA (rated Div/Zone 2) to connect to a universal SAM would be maintenance-friendly and minimize the relearning required for each specific interface.

Challenges for SAM

The downside of a SAM is that some simple sample systems do not need a lot of intelligence, and so using it may be considered overkill in some applications. As a result, the cost of a SAM must also be reasonable.

Of course, the use of transportable applets in a SAM requires some collaboration across end users and manufacturers. Whether this is done in a collaborative fashion or by other means remains to be determined.

In short, the appeal of automation to the end user and system integration community will remain tepid until a low-cost, field-hardened SAM is available that can manage our signals and integrate the various subsystems. Without SAM, the progress of NeSSI Generation III—both micro-analytical and by-line installation—becomes more difficult. Having a SAM spurs the use of automation and ultimately brings higher reliability to the process analytical discipline.  

[Editor's note: "Making Sense of SAM" was the subject of a workshop at the Centre for Process Analytical Chemistry (CPAC) in November 2009 in Seattle, Wa. For more information, visit www.cpac.washington.edu/NeSSI/NeSSI.htm.]

Rob Dubois is a member of the Center  for Process Analytical  Chemistry's (CPAC) NeSSI steering team. He can be reached at [email protected].

Sponsored Recommendations

IEC 62443 4-1 Cyber Certification – Why ML 3 is So Important

The IEC 62443 Security for Industrial Automation and Control Systems - Part 4-1: Secure Product Development Lifecycle Requirements help increase resilience for control systems...

Multi-Server SCADA Maintenance Made Easy

See how the intuitive VTScada Services Page ensures your multi-server SCADA application remains operational and resilient, even when performing regular server maintenance.

Your Industrial Historical Database Should be Designed for SCADA

VTScada's Chief Software Architect discusses how VTScada's purpose-built SCADA historian has created a paradigm shift in industry expectations for industrial redundancy and performance...

Linux and SCADA – What You May Not Have Considered

There’s a lot to keep in mind when considering the Linux® Operating System for critical SCADA systems. See how the Linux security model compares to Windows® and Mac OS®.