Test Cell - LabVIEW SCADA with PXI?

[JMA_eng]

Greetings,

I'm looking for a few suggestions on command and control with a test cell.  I have an older PXI chassis which I'm considering reworking for the test cell.  Below are my quick notes on the application and a possible architecture.  At the bottom are a few questions.

Cheers,

JMA_eng

Basic System:

• Up to 100 channels @ 1 Hz update rate; generally inputs with a few digital outputs; analog outputs possible, but may not be suitable at a slow update rate
• Multiple channels with alarms and alarm outputs
• System will be operated hours / days / weeks
• Remote monitoring preferred through a client
• Digital representation or basic plotting for data
• Text files or easy method for configuration to a specific setup (fixed PXI I/O channels, but not all channels will be used and alarm conditions would be unique such as rising / falling and time criteria)
• must not require in-depth knowledge of LabVIEW after deployment for normal operation by the team

LabVIEW SCADA – starting from the system sample project

Server:

• PXI embedded controller – running Windows; older NI PXI-8104
• Server Application
• Database
• Shared variable engine
• (New) Implement OPC server – all I/O of PXI chassis; each physical grouping of channels would be a sub-system;
• (New) Watchdog – ensure tasks running / check-in and communication; places system included I/O in a safe state

Client – external PC

• Events
• Subsystem view
• Alarm view
• Historical view
• (New) Configuration of inputs and outputs – enable/disable; meaning names; measurement type; engineering units
• (New) Calibration of inputs and outputs – offset; min/max; scaling

Client & Server communicate over TCP/IP

Is the LabVIEW SCADA reasonable for what I’ve outlined?  Does another solution seem like a better fit?

I would like the OPC client to apply any scaling / interpretation and have the shared variables in the correct format.  Does this require start/stop of the OPC Server / OPC Client / Overall Server / HMI Client  when the configuration and calibration are applied?  I believe there is a shared variable constant which should allow updating properties.  Could this work for setting up scaling, engineering units, etc. on the shared variables.

Does implementing an OPC Server in the PXI make sense?  With the LabVIEW OPC add-on package this did not seem to be extremely difficult.  Perhaps another architecture makes sense.  Something like setting up tasks in MAX and exposing them to the shared variable engine (no idea if this is possible).  Applying a scaling, etc. may be difficult.

[Garena]

Hello,

1) This seems to be a fair approach, there might be other approaches that could make the application more efficient, however, this solution you propuse its valid, So, you already know this technologies, it would be more efficient from your side to follow this implementation than adding other technologies that could make you invest a lot of time for increasing the application efficiency in some points.

2) For scaling shared variables you can use a sharedvariableIO property node to change the scaling on the file. 

http://zone.ni.com/reference/en-XX/help/371618K-01/lvdscprop/sharedvariableio_p/

3) Using an OPC server on the PXI makes perfect sense, since this is going to be the device that is going to be always online. The other idea you have could implement. You could create a LabVIEW script that allows you to write DAQ data into specific shared variables. The only advantage I see is that you could publish DAQ data without requiring the OPC license which you will require for the OPC servers.

[MarkBlack · Accepted solution]

Hi JMA_eng, 

Thanks for providing all of the details. This helps a lot to understand your goals and what you would like to achieve. Overall, what you are proposing is certainly possible with LabVIEW, OPC, and Shared Variables. That said I would like to inform you of some new technologies I believe will suite your use case well, prevent you from reinventing the wheel in several aspects, and put you on a technology stack that is receiving a lot of focus and attention at NI. 

Are you aware of NI SystemLink? SystemLink is a services backend that is designed for medium to large scale test and measurement applications, and includes several technologies that directly apply to your use case, and several more that may not so I won't go into as much details. You interact with SystemLink through a web browser. 

Basic System

For this portion of your requirements I would like to make you aware of the SystemLink Tag service. This service is specifically designed for the type for high volume but low update rates you describe. SystemLink tags can be configured to retain data (history) such that they can be reviewed at a later time with a web client (either built in or custom) or downloaded to CSV format. Additionally Tags can be configured with multiple alarm severity conditions that when triggered can send notification emails. These alarms as designed to trigger when a value threshold is met, but we are working to release a full Alarm API this fall that would enable you to create logic to fire alarms based on rising/falling time. 

Additionally SystemLink includes a dashboard tool that simplifies the creation of monitoring UIs of tag data without programming. If more complex operator interfaces are needed, LabVIEW NXG WebVIs can be created that call into the SystemLink services for more sophisticated interactions and UIs. Your need for a UI for easy configuration of "specific setups" may be well suited for WebVIs, but it's not your only option. SystemLink's powerful tooling for systems management enables you to not only install software remotely it can be used to version and tightly control the deployment of configuration documents like what you are describing. 

LabVIEW SCADA

Most everything you mention here is suitable for SystemLink. SystemLink is a server application that includes and abstracts a database so you can better interact and manage your systems and data rather than manage a database. As mention before the Shared Variable engine would be replaced by the SystemLink tag service that is much more scalable and much more secure than shared variables. The watchdog you describe is another good use case for SystemLink alarms. I would like to understand better what is driving your OPC requirements. Does another OPC Client need to consume the data coming from the test cell? SystemLink currently can pull in data from an OPC UA server, but it cannot yet publish tag data as OPC UA variables. Depending on your use case this is an important distinction. That said, from what I can tell here I'm not sure how critical your OPC requirement is. 

Client

As mentioned above one of the key value propositions of SystemLink is that everything is web based, and as such you wouldn't need a dedicated client machines. Instead machine with a current web browsers would work.

• Per events can you go into more details of what you are planning here?
• Per subsystem view can you go into ore detail of what you are planning here? Our dashboards may be a good fit, but it depends upon you needs. 
• Alarm View - we have a dedicated application for viewing and interacting with alarms. We also surface alarm information in relevant other views within SystemLink such as system health views. 
• Historical View - Our tag viewer application has a subview where historical data for one or more tags can be viewed
• (New) Configuration of inputs and outputs - Depending on your needs I could imagine doing this either in our tag viewer or within a custom WebVI that is reading and writing tags with these values. 
• (New) Calibration of inputs and outputs – Typically when we discuss calibration in SystemLink we are calibrating measurement instruments such as PXI cards. This seems to be something more akin to MAX custom channels. We've kicked around ideas of how to add custom scaling to particular tags, but haven't implemented anything yet. Can you expand on this concept to ensure we understand your needs better?

Client and server would communicate everything over HTTP(S). This provides both an IT friendly commutation mechanism (which shared variables are not), while also leveraging best in class industry standard security practices. 

Let me know what you think and questions you may have!

[JMA_eng]

Thank you very much for the feedback and information.  I missed the shared variable IO properties document in my original search.

Cheers,

JMA_eng

[JMA_eng]

Greetings MarkBlack,

Thank you for the information on another technology.  I am unfamiliar with NI SystemLInk.

Best resource?
https://www.ni.com/en/support/documentation/supplemental/17/getting-started-with-systemlink.html

Online manuals, etc.

I’ll need to review the online manuals to make more sense of the pertinent details of the NI SystemLink.  The high level information on the link you provided has some features which clearly fit our needs, but also some features of little value right now.  Items of particular interest I will need to review relating to overall architecture ->  Hosted server where?  Requirements on server hardware?  What/how for getting data to and from the server (SystemLink tag service instead of OPC w/ shared variables)? 

Webpages served to clients over HTTPS is a very attractive interface and allows for non-dedicated machines with client software (less to maintain; less headache for myself and IT group).

With UI clients, is it possible with operator controls on screen to affect variables that can be seen in the system?  One way monitoring of indicators is ok for some items, but my goal is both.  For example, a slider on screen that indicates a desired RPM.  This would be seen by the application interfacing the hardware and set the desired level.  This type of monitoring would also be needed with the alarms.  Depending on alarm conditions, the test may need to terminate.  Typical alarms could be water flow for cooling, over temperature on the device under test or support equipment, etc.

OPC is not a requirement and merely an attempt to fit into the provided SCADA example.  However, OPC seemed reasonable for long term future use and C.O.T.S. PLC’s could be seamlessly integrated if needed.  The main hardware platform will be PXI chassis with embedded controllers.  Depending on the test cell, there could be a few different hardware setups and/or multiple setups together for increased functionality (more I/O channels or different mix).    

Client:

Events – responding to user interface controls (part of original LabVIEW SCADA architecture);  Overall enabling of alarms (tests typically do not have alarms enabled until the system is in a known start state); request for historical data, setup configuration and calibration (launch amin console)

Subsystem view – (part of original LabVIEW SCADA architecture); immediate view of present variables within the present subsystem; detailed view or views for the type of system and/or data; this includes an alarms, historical trend.   

Our client needs for data visualization when tests are running are not crazy and a basic digital view or plot would be sufficient.  These seem very reasonable with a web page.  Having the ability to create specific client visualization screens for tests would be of great benefit.  From these saved visualizations I would then try to automate manipulating saved data for analysis or report generation.    

Configuration and calibration:

I would setup the hardware to provide data to monitor & capture at a known rate for view in the system.  A mechanism is needed for enabling/disable channels of interest, adding engineering units (interpreting the data for example, frequency to GPM for a flow sensor).  A mechanism is also needed to apply calibration to the channel.  We typically use a system calibration rather than a sensor or simply hardware calibration.  For example, we would use a precise temperature transmitter to inject a known thermocouple values into a channel.  We would capture these measurement and adjust the scaling & offset to bring the readings to match.  A two point scaling factor for each channel would be saved and applied.  Curve fitting would be nice on occasion for scaling when non-linear behavior is present, but it is not a critical path item.  The system calibration is preferred as it accounts for any losses, especially if the signals are voltage based with long cable runs.

I’ve attached screen shots below for reference from the LabVIEW SCADA example.  The client screens we would need to customize, but they provide a bit of context for the different setup needs.

Cheers,

JMA_eng

[MarkBlack]

Yes, that is a very good resource to begin with. 

Hosted server where? 

SystemLink is designed on a single server class Windows PC. This could be a machine at your desk, in an IT managed data center or in a cloud provider such as AWS or Azure. We also have a SaaS product SystemLink Cloud that has a subset of the features available in our on premises server software. 

Requirements on server hardware? 

Please see the SystemLink Readme.

What/how for getting data to and from the server (SystemLink tag service instead of OPC w/ shared variables)? 

Please see this following help documents on our data services:

https://www.ni.com/docs/en-US/bundle/systemlink-api/page/systemlink-nodes.html

With UI clients, is it possible with operator controls on screen to affect variables that can be seen in the system?

You can both read and write tags from either our tag viewer application of by API calls in a VI or WebVI. Your idea of using a tag to set a set point is inline with our expected use case for tags. 

This type of monitoring would also be needed with the alarms.  Depending on alarm conditions, the test may need to terminate.

Our soon to be release Alarm API will enable you to create logic in your application to accomplish this. 

However, OPC seemed reasonable for long term future use and C.O.T.S. PLC’s...

I think we can work well here by either using NI OPC Servers as an intermediary or by reading and writing OPC variables hosted directly on the PLC itself should the PLC have that capability. 

Client

With the details you've provided as well as the screen shots of the current UI I am confident SystemLink with WebVIs can fulfill all of these requirements .

Configuration and calibration:

How are you solving this today? Currently I would expect setting this all up would be a combination of  a custom operator interface and logic on the edge node. Again using tags to set the value for offsets and coefficients seems reasonable. If you are doing more complex command and control I recommend SystemLink messages, which are a better fit for that use case than tags. 

[JMA_eng]

Greetings MarkBlack,

Thank you so much for the extra information and consideration.

The technology looks like a reasonable fit.  I still need to wrap my head around a few key items with the application(s) running on the managed systems.  

Are there any guidelines or metrics available with throughput?  For example, could 10 - 100 Hz variable rate be supported?  Slow data rates with high channel is obviously the target.  This however is only a subset of our testing.  Perhaps we could use the same architecture and run tests on the managed systems, and somehow display a complete large data set in a chunk (sort of 'file' transfer or big 'graph' set).  

With regards to the solution today, I'm afraid we have taken an historical approach.  The test bay setups have typically been stand-alone systems with custom applications and/or hardware.  Networking between these systems is very limited or not present.  Part of the right solution is an opportunity to standardize on a system architecture which can be easily maintained going forward for decades.  

[MarkBlack]

Are there any guidelines or metrics available with throughput?  For example, could 10 - 100 Hz variable rate be supported?

With our tag service, no we wouldn't want you to write at those rates. You could probably do 10Hz with a few tags, but not 100s or 1000s that the service is better suited for dealing with. That said we have another service, the SystemLink File Service, that is designed to accommodate data generated at the rates you mention and faster. Our expected use cases include logging the high speed data locally to TDMS or another file type then using the SystemLink File service to upload the file to the central server in an automated fashion (e.g. we have a VI for uploading files through this service). From there you can review and download the files from the SystemLink web interface. Some files types, including TDMS, can actually be previewed within a SystemLink WebVI without having to download it. 

Please see

https://www.ni.com/docs/en-US/bundle/systemlink/page/sharing-data-across-systems.html