SACRAMENTO, CA MAY 15, 2008 - The installation and maintenance of FactorySQL/FactoryPMI based systems involves a wide range of
technologies. Each normal installation consists of at least 4 components: FactorySQL, FactoryPMI, an OPC server and a database. Given that each component has its own set of requirements and caveats, it is important to have an organized game plan when implementing and installing a project.
For that reason, Inductive Automation has put together an installation checklist that will help you with both the installation and the startup of a project.
Inductive Automation Install checklist
Inductive Automation
Inductive Automation pioneered the first full-featured web-launched HMI/SCADA system in the world. Its standards based, database-centric architecture receives accolades from plant managers, IT managers, and system integrators worldwide. With a commitment to software quality and technical support second to none, Inductive Automation is at the forefront of industrial software.
Showing posts with label how to. Show all posts
Showing posts with label how to. Show all posts
Monday, May 19, 2008
Inductive Automation Installation Checklist
Sunday, March 9, 2008
How To: Use Click to Graph with FactoryPMI Easy Chart
This article demonstrates how to install and use Click to Graph, a powerful way to add and remove pens from FactoryPMI's Easy Chart Component in runtime. Click to Graph allows you to add a right click menu to components, such as led displays, labels, numeric labels, etc, to add or remove that item from an Easy Chart graph dynamically. You can even save graphs and come back to them at later times. This way you choose what you want to see in a graph. Please read the instructions carefully and perform them in order.
Installing Click to Graph
Step 1: Download Click to Graph File
1) Click on the following link to download the zip file:
2) Extract the contents of the ctg.zip to a folder. This file contains 5 files:
ctg.sql - a MySQL backup file containing all the necessary tables
ctg.py - a python script that contains all the necessary functions
ctg.fpal - a custom palette that contains a few sample components
ctg.fwin - a file that contains all the necessary FactoryPMI windows
ctg_shutdown_script.txt - a file that contains the shutdown script needed
Step 2: Import MySQL Dump File
1) Open up Command Prompt by going to Start->Program Files->Accessories->Command Prompt
2) Change directory to MySQL bin by entering in (afterwards press enter):
cd "C:\Program Files\MySQL\MySQL Server 5.0\bin"
3) Now import ctg.sql by entering in (afterwards press enter):
mysql -u root -p YourDBName < "C:\Location to\ctg.sql"
4) Enter in your MySQL root password (afterwards press enter)
5) Done. The Click to Graph tables are now successfully imported.
Step 3: Import FactoryPMI Script Module
1) Open up the FactoryPMI Gateway Configuration page from: Start->Program Files->Inductive Automation->FactoryPMI->Configuration Page
2) Open up the FactoryPMI Designer by clicking on the Launch Designer link. Login with your username and password (default is admin and password). Select the project you want to use Click to Graph in.
3) Once open, go to Project->Script Modules from the menu bar.
4) Click on the Import a package or script button.
5) Select the ctg.py file.
6) Name the module ctg.
7) Done, you now have some global functions that we are going to use later. Press Ok to close.
Step 4: Import FactoryPMI Palette
1) With the designer still open, right click on the Component Palette and select Import Palette(s).
2) Select the ctg.fpal file.
7) Done, you now have some pre-configured components for Click to Graph that we can use.
Step 5: Import FactoryPMI Windows
1) With the designer still open, right click inside the Project Browser and select Import Window(s).
2) Select the ctg.fwin file.
7) Done, you now have some pre-configured windows for Click to Graph that we can use.
8) Lastly, you need to add the global shutdown script. Go to Project->Global Event Scripts. Next select the Shutdown tab and enter in the contents of the ctg_shutdown_script.txt. The script clears out the current graph when the user logs out or closes the client.
All done! Now let's go over how Click to Graph works.
How Click to Graph Works
The first part to understand is that Click to Graph stores pen configurations in the database. During the runtime each user picks and chooses from these pens. Picking and choosing these pens manipulates the ctg_active_client table. This table then drives the Easy Chart's pens/axes datasets dynamically. The ctg_active_client table is based on a unique Client ID created by FactoryPMI when you login to a client. This ID uniquely identifies one client from another. This way each client can have its own set of pens the user can configure. If that ID is somehow lost (possible via redirection), the user must log in again to access the graph.
Let's take a look at the databases tables needed for Click to Graph to work (there are 4 of them):
ctg_pens - table stores all possible pens for the graph.
ctg_axes - table stores all the available axes for the pens.
ctg_saved_pens - table stores the saved graphs.
ctg_active_client - table stores all the pens the clients have selected.
The ctg_pens table can be manipulated using the CTG_Pen_Edit window that we imported into our FactoryPMI project earlier. Here you can add/edit/remove pens. These pens correspond to tag or item that FactorySQL (or another historian) is already trending. Attached to a pen is a Point ID, which uniquely identifies one pen from another. Every FactoryPMI component that we want to use as a Click to Graph item must also contain the Point ID, so that it knows how to add or remove that specific pen. Let's go over a small example to get started.
Next, the actual Easy Chart, located on the CTG_Graph window, has two expert properties called pens and axes which are both bound to a SQL query. The pens dataset is bound to a join of the ctg_active_client table and the ctg_pens table. The axes dataset is bound to the ctg_axes table.
Let's go over a small example to understand how everything relates.
Example 1: Using a Click to Graph Component
1) Open up the FactoryPMI Designer.
2) Open up or create a window.
3) From the Component Palette under CTG Palette, drag and drop the Multi-State Indicator pre-configured component into the window.
4) You will notice there is a Dynamic Property called PointID attached to the component with a value of HOA. This Point ID must match the Point ID of a pen in the ctg_pens table.
5) Now, let's take a look at the Mouse Pressed and Released actions on this component. This is where the right click menu is called. So, right click on the component and select Configure Actions...
6) You will notice the script is the same for the mousePressed and mouseReleased. They both call a global script function that we imported earlier into the Script Modules. We pass the event object into the showPopup function and it knows how to retrieve the Point ID from the component. The function also takes care of creating the popup menu.
7) Now, cancel out of the action configuration and go into Preview mode in the designer by selecting Project->Preview mode from the menu. Now we can interact with the components. Right click on the indicator and you will get the following menu:
8) That's it! You can click (+) Add to Graph to add that pen to the current working graph. If the pen does not exist in the ctg_pens table the script will create one automatically with the default settings. After that, you can remove the pen and event clear out the current graph.
9) To see the current graph open up the CTG_Graph window.
How to add Click to Graph to already existing components
So, if you would like to add Click to Graph to already existing components do the following:
1) Right click on the component and select Component Customizers->Dynamic Properties and add a new property named PointID of type String.
2) Lastly, add the following script in the mousePressed and mouseReleased actions by right clicking on the component and selecting Configure Actions..:
if event.button != event.BUTTON1:
app.ctg.showPopup(event)
Have fun with this goodie and as always if you have any questions please call us at 800.266.7798.
Friday, January 18, 2008
Redundancy On The Cheap: How to use two servers, FactoryPMI, FactorySQL, and MySQL to make a mission critical HMI/SCADA application.
SACRAMENTO, CA -
FactoryPMI and FactorySQL have long supported clustering and redundancy, respectively. But their database-centric architecture always left the question: What about the database? A true clustered database solution, like Microsoft SQL Server Clustering or Oracle 11g RAC works great, but can take 4+ extra servers and tens of thousands of dollars worth of software. This whitepaper describes how to set up redundancy on the cheap, using 2 servers and MySQL.
First disclaimer: The solution provided here works well, but you do give up some of the reliability that you'd get with a true clustering solution. If you can afford it, go with a true clustered database. They are great and are built for exactly what you're doing. That said; we understand that budgets aren't infinite, and sometimes you have to do more with less. In that case, read on.
Second disclaimer: The solution here isn't rocket science, but it does demand that the user has a solid grasp on our products, databases, and networking. After all, rocket science probably isn't that difficult if you're a rocket scientist. If you start thinking this might be beyond your technical capability, skip to the bottom where we provide a much simpler solution that very well might be "good enough" for many users.
This guide is going to be using some advanced features of FactorySQL, FactoryPMI, and MySQL that you may not be familiar with. Let's go over some of these features first.
FactorySQL Redundancy. FactorySQL Redundancy is a feature that lets two or more FactorySQL services running on different physical machines cooperate, so that if the primary instance goes down due to a machine crash or software fault, one of the secondary instances will take over. FactorySQL uses a common database connection to share project configuration data, as well as monitor who is the currently running master instance.
FactoryPMI Clustering. FactoryPMI Clustering is a feature that lets two or more FactoryPMI Gateway instances running on different physical machines share configuration data and split client load evenly across all running instances, with dynamic client failover. FactoryPMI Clustering uses UDP communication over the local subnet for all clustering communication.
Aggregate Connections / Failover Connections. In FactorySQL, you can create an aggregate connection to a database. This special connection type uses two other database connections to create a single one. If the primary connection goes down, the secondary connection will be used instead. In FactoryPMI, you can specify a failover connection for any datasource connection. In a similar fashion, if that datasource connection fails, the failover connection will be used instead. These two features are very important to the technique presented in this guide, because they let FactorySQL and FactoryPMI use two separate databases as one, which is how we simulate a clustered database.
MySQL Replication. MySQL Replication is a feature of MySQL that lets you specify one database as a master and one as a slave. All changes that are made to the master will be replicated over the network to the slave. Setting up MySQL replication is out of the scope of this guide, but was covered in an earlier article, available here.
The basic idea is to set up MySQL replication for realtime data (status and control), and FactorySQL datacaching for historical data. When both servers are up, history will be logged to the master database, and realtime status and control will go through the master database. In the event that the master server goes down, history will be cached by the secondary server's FactorySQL, and realtime status and control will be routed through the secondary database. When the master server is brought back up, the secondary FactorySQL will put all cached history into the master database. So, during the failure, history will be unavailable, but status and control will work.
Figure 1: Redundant Architecture Overview (click to zoom)
Figure 1 is a diagram of the architecture this guide is describing. You'll see a "master" and "slave" server. Each server has the full "stack" of software on it, that is: an OPC Server, FactorySQL, a database (MySQL), and FactoryPMI. Don't let the picture frighten you, it's not as bad as it looks. Notice that there is a lot of symmetry here: Both instances of FactorySQL actually have the exact same connections, and the same goes for both of the FactoryPMI Gateways. Let's go over the configuration for each piece of the software stack.
First, we have the OPC server. Both OPC servers will be connected to your devices (PLCs, RTUs, etc). They don't need to be specifically set up for "redundancy", but they do need to be configured in the same manner, so that they have access to the same tags, etc.
Before we go over FactorySQL, let's look at the database. Notice that there are two separate schemas: one for historical data, and one for realtime data. Separating the data into two schemas lets us use different connections for each schema. The master database has both schemas, but the slave server only has the realtime schema. You need to set up MySQL replication to replicate the realtime schema from the master to the slave. Again, see this article for detailed instructions on setting up MySQL replication .
The FactorySQL configuration will be identical on both the master and the slave. The crux of the configuration here is in the Data Connection Settings. You'll need the following connections:
- HistoryConnection: Connection to the master's historical schema. Native or DSN connection. Ensure that Data Caching is enabled in the Service Settings.
- MasterRealtime: Connection to the master's realtime schema. Native or DSN connection.
- SlaveRealtime: Connection to the slave's realtime schema. Native or DSN connection.
- RealtimeConnection: Aggregate connection with MasterRealtime as the primary connection, and SlaveRealtime
as the secondary connection. Failover mode should be set to "Use secondary until primary is available"
Ensure that SQLTags is enabled and using the RealtimeConnection (unless you aren't using SQLTags). Enable redundancy, and set it to use the RealtimeConnection. Note that FactorySQL redundancy makes your project configuration shared implicitly across your master and slave, but the settings themselves need to be configured individually.
FactoryPMI configuration is fairly simple. You'll want to configure your master, and when it is all configured, you'll join your slave into the master's cluster. The configuration, again, mostly has to do with the datasource connections. You'll need the following connections:
- HistoryConnection: A connection to the master's historical schema.
- SlaveRealtime: A connection to the slave's realtime schema.
- MasterRealtime: A connection to the master's realtime schema, with the SlaveRealtime set as the "Failover Datasource".
In your project, make sure to use the HistoryConnection for all historical queries (e.g. charts, tables, reports etc. Use the MasterRealtime for all realtime information (e.g. SQLTags). To cluster your two FactoryPMI Gateways together, first set the Cluster Name of the master server to something intelligible, such as "FPMICluster". Then set the slave's Cluster Name to the same name. Ensure that you don't have any software firewalls such as Windows Firewall enabled, and that multicast UDP traffic on a single port can pass between the two Gateways.
Now that you have your master and slave configured, let's take a look at how it will work in the event of a failure. First, look at Figure 2, which shows the path data takes when both servers are running. Notice that realtime and historical data go through the master database, and the FactoryPMI Gateways share the client load. Data flow is shown in the thick green lines. All other connections are not being used.
Figure 2: Normal Data Flow (click to zoom)
Now let's look at the data flow in the event that the master server has crashed in Figure 3. Again, the active data paths are shown in thick green. Notice that the realtime data is going through the slave's realtime schema, FactorySQL is caching the historical data, and the FactoryPMI clients have all switched to the FactoryPMI Gateway instance running on the slave.
Figure 3: Master Crashed Data Flow (click to zoom)
There you have it, with some clever partitioning of connections and some MySQL replication, you can create a mission critical HMI/SCADA system that logs seamless history, and never loses control of your application. Of course, there are details to work out, such as backup schemes for your history in case the master server crash cannot be recovered from, but such things can be put in place fairly easily. If you are going to put a system like this in place, we recommend two additional things: purchase the commercial version of MySQL (it is fairly inexpensive) so that you can receive support from them, and practice. Disaster recovery plans and redundant software can be quite complex. If you're serious about a highly available SCADA system, make sure that you regularly practice simulated outages to ensure that everything goes smoothly.
Last but not least, we have promised a simpler alternative, in case this all seems too complex. The alternative is: Have a cold-standby server ready and waiting. Purchase a USB licensing dongle from us (so that you can simply swap the FactoryPMI and FactorySQL license in a physical form), and in the event of a failure, turn on the secondary server and give it the IP address that your master server used to have. Yes, you'll probably be down for 5 to 10 minutes, and you will lose the history during that period, but you'll be able to explain how it works in one sentence. The only tricky part to this is to make sure that your secondary server's project files stay up to date. This can be achieved reliably through well-known procedural guidelines, or through automatic ghosting.
As always, if you'd like to speak to one of our engineers to discuss any of these architectures, or have some new ideas that we haven't thought of, please give us a call at 1-800-266-7798.
Inductive Automation
Inductive Automation pioneered the first full-featured web-launched HMI/SCADA system in the world. Its standards based, database-centric architecture receives accolades from plant managers, IT managers, and system integrators worldwide. With a commitment to software quality and technical support second to none, Inductive Automation is at the forefront of industrial software.
Feature Highlight: FactoryPMI ™ Retargeting Creates Seamless SCADA Across Multiple Plants
SACRAMENTO, CA - The ability to web-launch unlimited, free HMI/SCADA clients anywhere on a corporate network is almost universally everyone's favorite feature of FactoryPMITM. As an added bonus, these days it is commonplace to have a corporate network that spans multiple physical plants, whether they are across town or across the country. With corporate networks like this, a manager at the Austin, TX plant could open up the HMI system for the Atlanta, GA facility to monitor line performance, or check inventory levels. Scenarios like this is where retargeting comes in.
FactoryPMI's retargeting feature lets you take advantage of existing corporate networks to create a completely seamless HMI/SCADA system across physical locations, while retaining local functionality at each location in the event that any inter-facility WAN connection were to go down. This feature is so simple that using it takes a single line of script. Suppose you had a FactoryPMI project called "Line A" located in Austin, TX, and another FactoryPMI project in Atlanta, CA called "Line B". If you wanted to add a button to your Line A project to retarget to the Line B project, all you?d have to do was write the following line of script:
fpmi.system.retarget("Line B", "10.0.28.224")
That's it! All you need is the name of the project, and the IP Address of the remote FactoryPMI Gateway. This feature is almost too simple ? most of our users overlook it. Those who have discovered it have used it to create some of the most advanced seamless global SCADA systems in the world. Note that your current authentication credentials will be passed onto the new server when you retarget, which should make for a seamless user experience if you're using Microsoft Active DirectoryTM authentication. If not, you'll be asked to log into the new project with a valid username. That's all there is to this feature. As additional inspiration, here is a screen capture from a project that uses retargeting to create an interactive facility map:
Inductive Automation
Inductive Automation pioneered the first full-featured web-launched HMI/SCADA system in the world. Its standards based, database-centric architecture receives accolades from plant managers, IT managers, and system integrators worldwide. With a commitment to software quality and technical support second to none, Inductive Automation is at the forefront of industrial software.
How To: Use SQLTags Scan Classes
SACRAMENTO, CA DECEMBER 11, 2007 - Whenever we release a large set of new features, it’s always interesting to watch how those features are received and utilized by our users. Most users prefer to “click and discover” vs. “read the manual”, and apparently the scan class button is too inconspicuous. This article aims to shed some light on scan classes and offer some tips about their advanced features.
What is a Scan Class?
A scan class defines how frequently FactorySQL will receive updates from the OPC server. The default scan class for SQLTags (appropriately named "Default") is set up for 5 seconds. This means that any tags in this scan class will update at most every 5 seconds. We say “at most”, because if the tag didn’t change in the PLC, then the SQLTag won’t update, of course. This is pretty slow, and we invite users to feel free to modify the default scan class. Without further ado, let’s see how to modify scan class settings.
First, select the SQLTags provider you wish to work with. Then, press the “Edit Scan Classes… button to bring up the Scan Class Editor window.
Here you can see all of the options for a scan class. When you change any of these options, all tags assigned to that scan class will immediately be running with the new settings. Scan classes provide a very convenient way to centrally manage the polling options for groups of tags.
Scan Class Modes
There are three modes that a scan class can run in. The most common mode is Direct mode. In this mode, the scan class always runs at a constant Rate (the Low Rate), which is the amount of time in milliseconds between updates. All modes of scan classes also have a Stale Timeout, which is the amount of time (in milliseconds) that can elapse after a scheduled update before the tags in that scan class are considered Stale. (If you aren’t already familiar with them, see the user manual’s discussion of SQLTags quality codes here)
Most users will only ever use Direct scan classes. It will often make sense to have more than one scan class. For example, suppose you have some control points that you want very quick updates on, perhaps to show feedback of a momentary button or some similar control device. Maybe you have other data that doesn’t need such quick updates. You could have a scan class named “Fast” that was set to update every 500 or 250 milliseconds, and another scan class named “Normal” that was updating every 1250 milliseconds. This way, the system knows to expend more resources updating those crucial tags quickly, but isn’t bothered by the bulk of the tags that don’t need such a fast update rate.
There are two other scan class modes besides Direct mode. They are Driven and Leased modes. A Driven scan class will toggle between a High Rate and a Low Rate, based upon the value of some other tag. This can be useful for tags that need very fast updates only when some condition is true. For instance, the values of an oven may need very fast update rates, but only when the oven is on. To set up a driven scan class, set up a tag that will represent the condition that drives the rate of your driven scan class. The only “gotcha” here is that the tag that drives your scan class cannot be in that driven scan class. Other than that, setting up a driven scan class is quite easy
The last kind of scan class mode is the Leased mode. A leased scan class also toggles between a High Rate and a Low Rate. Whenever there is any active subscription for a tag in a leased scan class, the scan class will run at its high rate. If nothing has a tag from the scan class subscribed, it will run at the low rate. This is like an on-demand system. When a FactoryPMI window is opened that has bindings for tags in a leased scan class, the scan class will start running at its high rate. When all windows that deal with that scan class are closed, it will run at its low rate. If the low rate is zero, that scan class is essentially disabled or turned off. This mode is useful when bandwidth is expensive, such as a satellite connection, or any time when you don’t want the PLC to be polled unless there is a need.
Conclusion
As you can see, scan classes offer the designer a great deal of flexibility when creating HMI/SCADA applications with FactorySQL and FactoryPMI. While the Direct scan class will suffice for the majority of users, we’ve seen some motivating examples of advanced situations where Driven and Leased scan classes can be useful. If after reading this article, you realize that you’d like to fine tune your scan class settings, but you’ve already created a few tens of thousands of tags, don’t worry! It is easy to bulk-modify tags to modify which scan class they are assigned to. Simply select multiple tags and only edit their scan class property. Even better, use the Tag Search button to quickly find and sort through your tags so that re-assigning their scan classes is a snap.
About Inductive Automation
Inductive Automation pioneered the first full-featured web-launched HMI/SCADA system in the world. Its standards based, database-centric architecture receives accolades from plant managers, IT managers, and system integrators worldwide. With a commitment to software quality and technical support second to none, Inductive Automation is at the forefront of industrial software.
Contact
Jim Meisler
(800) 266-7798 x227
jmeisler@inductiveautomation.com
How to use Indirect Tag Binding for Rapid Development
SACRAMENTO, CA OCTOBER 12, 2007 - Indirect tag binding is a type of data binding available in FactoryPMI 3.0. It allows the designer to bind a component’s property to any number of tags using one or more layers of indirection. This lets one create templated components and parameterized windows. A templated component is a component or group of components whose data bindings are relative to some properties of the component. A parameterized window is similar, the difference being that the entire window’s contents are relative to a parameter that is passed into the window when it is opened. Indirect tag binding makes creating these components and windows a snap. All you need to do is bind to a tag, and then choose the part of the tag path that changes, replacing it with a value from a property in the window.
To demonstrate indirect tag binding, suppose we had a tank farm with four tanks. Each tank has some properties, like level and temperature. Each tank also has an outlet pump, that can be controlled from the screen and has amperage associated with it. Here is how the tag structure would look in the SQLTags browser:
Our goal with indirection is to bind to tag paths like:
[]TankX/PumpAmps... where the
"X" is replaced with 1-4. Let’s say we wanted all 4 tanks on the same screen. In this case we’ll set up a templated component, or rather, group of components. Put all the components you want to represent 1 tank in a container, like so:
These components were created simply by dragging the tags represented into the container. The pump is an image whose tint color is bound to the pump mode tag. To turn this container into a templated component, simply add an integer dynamic property to the container called
"TankNum", and set its value to 1. Now modify each of the data bindings on the components’ properties from a direct tag binding like this:
... to an indirect tag binding like this:
To create this indirect tag binding, first browse for the tag:
"Tank1/Level." Then, remove the "1" in "Tank1", and browse for your "TankNum" dynamic property. That’s it – your binding is now indirect, and will point to whichever tank is indicated by the value of "TankNum". Now all you need to do is copy and paste this container 4 times and change the value of TankNum appropriately, to create a screen like this:
Creating a parameterized window is just as easy. The only trick is that the dynamic property
"TankNum" that controls the indirection for the bindings needs to be placed on the popup window’s Root Container. This lets you create a popup window like this:
Whenever you open this window, simply send it a value of 1 through 4 by passing the
"TankNum" parameter in the navigation action. In this way, one popup window can be used for a number of devices.About Inductive Automation
Inductive Automation pioneered the first full-featured web-launched HMI/SCADA system in the world. Its standards based, database-centric architecture receives accolades from plant managers, IT managers, and system integrators worldwide. With a commitment to software quality and technical support second to none, Inductive Automation is at the forefront of industrial software.
Contact
Jim Meisler
(800) 266-7798 x227
jmeisler@inductiveautomation.com
SQLTags Guide for existing FactorySQL and FactoryPMI Users
SACRAMENTO, CA SEPTEMBER 25, 2007 - SQLTags™: A Guide for Existing FactorySQL™ and FactoryPMI™ Users
SQLTags represents a significant change in architecture for FactorySQL and FactoryPMI. While our core architecture of web-launched clients and database-centric data storage hasn’t changed, the techniques used for configuring status and control screens have changed greatly. This guide is meant as a primer for existing users of FactorySQL and FactoryPMI. It will explain the design rationale of SQLTags, introduce the new features, and to provide some motivation for why it might be in your best interest to upgrade your existing system.
The Basics
SQLTags is an underlying technology in FactoryPMI 3.0 and FactorySQL 4.0. These versions are completely backwards compatible. SQLTags works by creating a high-performance tag database inside your existing database. It does this by creating new tables that both FactorySQL and FactoryPMI will use. Because both FactorySQL and FactoryPMI “understand” how these tables work, you (the designer) no longer need to be concerned about writing SQL queries to interface with your data. Rather, you simply deal with “tags”. In essence, we’ve more tightly coupled communication between FactoryPMI and FactorySQL, but all data is still in the database so that we don’t lose any of the much-loved flexibility, scalability, and simplicity of our database-centric architecture.
It is important to note, however, that SQLTags currently only deals with real-time status and control data. All history, downtime tracking, etc is accomplished in the same manner as before. There are future plans for a historical addition to SQLTags.
Design Rationale
- Ease-of-Use. We wanted to decrease the learning curve for using our software for basic HMI-type screens. Specifically, we wanted a new designer to be able to set up a status and control screen without leaving the FactoryPMI Designer, and without writing a single SQL query.
- Status Feedback. Our existing status and control architecture was highly de-coupled. It was so de-coupled, in fact, that status information was typically lost without expending extra design effort to capture it. For instance, if a write failed to OPC, the operator wouldn’t know about it. If the PLC was unplugged, the operator wouldn’t know that the numbers s/he was looking at shouldn’t be trusted. SQLTags completely fixes this.
- Scalability. Our existing architecture involved polling simple SQL queries to retrieve real-time status information. This didn’t scale very well, because each concurrent client was running its own queries. This put a large strain on the database as more clients were launched. While there was a nice technique to mitigate this problem, it wasn’t immediately obvious. SQLTags improves scalability dramatically.
How You Use Tags
- SQLTags introduces a new panel to the FactoryPMI Designer: the SQLTags Tree Browser. This panel gives you access to all the tags in your system. In addition to the tags stored in your database, you also have client tags and system tags. There are actually 4 different types of tags:
- OPC Tags. These tags are stored in the database, and driven by FactorySQL from an OPC server.
- DB Tags. These tags are also stored in the database, but aren’t attached to OPC. They can simply be values accessible by all clients, can be calculated via an expression, or be the results of a SQL query.
- Client Tags. These tags are stored in your FactoryPMI project itself. Each client will have its own copy of these tags.
- System Tags. These tags are available to each client and provide client-specific system information, such as the currently logged-in username, system time, etc.
Tags are addressed by their path, which looks like this:
[MyDB]EastSection/TankFarm/Tank15.value
The first part, in square brackets [MyDB], is called the source. Typically this will be the name of your datasource connection, or simply blank to use the project’s default datasource. The next part is the path to the tag with forward slashes as folder delimiters. Lastly, one of the tags properties is referenced (in this case, “Value”). If no property is present, Value is assumed. Tags have lots of properties, such as Value, Quality, Documentation, EngUnits, etc. See the documentation for a full list.
Tags are used in your FactoryPMI projects via the familiar property-binding paradigm. Just like you are used to binding properties to expressions or SQL queries, you can now bind properties to tag values. You can bind to most properties of a tag. You can also use tags in expressions and SQL query bindings.
Even better, you can simply drag a tag and drop it onto a component. Depending on the component and the type of the tag, appropriate property bindings will be added. Or, if you drop a tag onto a container, it will prompt you to create an appropriate component to display that tag. Lastly, you can drag a tag onto a property, which will add a binding to that property.
The Overlay System
Each tag has a quality. There are many different qualities defined (see the documentation), but some common ones are:
- OPC_BAD_DATA: OPC is reporting that the data is bad, probably due to communication issues with the PLC
- GOOD_DATA: The tag is working well
- STALE: The value is stale. Either FactoryPMI isn’t fetching the value because you’ve turned the datasource communication off, or FactorySQL isn’t running.
- CONFIG_ERROR: Something is wrong with the configuration of the tag.
New with SQLTags is a status overlay system. Each component in FactoryPMI will calculate its quality based on the worst quality of any tag bindings configured on it. If the quality is anything but GOOD_DATA, you’ll get a noticeable visual overlay on top of the component. This is a crucial part of SQLTags – with no extra effort, you get reliable status indication on every component on your screen.
OPC Browsing
With SQLTags, you can create a new tag manually by pressing the “New Tag” button on the SQLTags Browser Panel’s toolbar. Even better, though, you can now browse your OPC servers from the Designer! Simply open the OPC browsing panel and your FactorySQL instance will be listed. From there you can browse the OPC servers that are available. Drag OPC items into the SQLTags tree to create OPC tags based on those items.
Writing to Tags / New Control Buttons
Writing to tags is very simple – simply check the “bidirectional” checkbox on your tag binding. This is applicable for bindings on properties that change as the user interacts with a component, such as a numeric input field. There are also 3 new control buttons in this release that are made specifically to work with SQLTags:
- One-Shot Button. This button writes a value to a tag, and then waits for the value to be reset by the PLC.
- Two-State Toggle: This button is great for tags that toggle between two values (such as 0 and 1). It will display differently based on the current state, and is configurable with the Styles feature.
- Multi-State Button: This button is really a series of buttons. Each button represents a value of a multi-state tag. For instance, 1=Hand, 0=Off, 2=Auto. The states and how they are displayed are configurable via the button’s Customizer.
All 3 of these buttons can be configured simply by dropping the appropriate tag onto them.
Scalability
As mentioned before, SQLTags is a highly scalable system. The load to the database, which has until now been variable with the number of clients, is now fixed. The Gateway handles all SQLTags polling activities irrespective of how many clients are running. Clients then poll the Gateway, which is highly optimized to handle a large number of concurrent clients.
As of this writing, we hadn’t performed formal benchmarks yet, but preliminary benchmarks look promising. A quick in-office test with FactorySQL, FactoryPMI, and an un-tuned MySQL database running on a desktop machine served 93 clients running a load test application that handled over 35 tag changes per second with under 50% CPU utilization.
Touchscreen Components
All input components are touchscreen-enabled by default now. No more need to handle touchscreen events with mouse scripts anymore. Don’t worry, this was done in a backwards-compatible manner – your old scripts won’t step on the toes of the new automatic system.
Conclusion
SQLTags completely obsoletes the “old way” of implementing status and control. Using SQLTags, one can implement a more scalable, more reliable status and control screen in much less time compared to FactoryPMI 2.0. The good news for existing users is that it is backwards compatible, but also easy to convert. If you want to convert your existing status and control screens, all you need to do is drag your OPC items into the SQLTags tree, and drop the appropriate tags on top of your existing status and control components. Want to see more? Call us for a personalized web-demo.
Free New FactorySQL™ UDP Monitor Plugin Available With Source Code
SACRAMENTO, CA SEPTEMBER 7, 2007 - A new FactorySQL plugin to monitor UDP messages is now available, with source code, from the plugins section of the Inductive Automation website. This free plugin allows FactorySQL to monitor any number of ports for UDP packets, and makes the data received available through an action item expression function.
The ability to monitor UDP packets can be very useful in many applications, including bar code scanners, printers, PLC messaging, and more. The full source code of the plugin is included in the download, allowing users to adapt and enhance the functionality for their own needs.
To download, please visit http://www.inductiveautomation.com/products/plugins/
How To: Use Active Directory® Authentication with FactoryPMI™
SACRAMENTO, CA AUGUST 14, 2007 - Microsoft’s Active Directory authentication technology is secure and in widespread use throughout the industrial landscape. By using Active Directory authentication in FactoryPMI, you ensure that access to your HMI/SCADA application is governed by a well-maintained, secure authentication source. In addition, compliance with the FDA’s 21CFR part 11 mandates that you use Active Directory! FactoryPMI has long supported Active Directory authentication. With FactoryPMI version 2.2.0, this support just got easier to configure and more flexible. In this article, we’ll demonstrate how to set up FactoryPMI’s Active Directory authentication feature.
Authentication Profiles
FactoryPMI can concurrently support many different types of authentication through use of authentication profiles. Each profile defines a different way to authenticate users. Each project can then choose which profile to use. To get started, we need to add a new authentication profile of type “Active Directory”. First, log into the configuration section of your FactoryPMI Gateway. Next, choose “Profiles” under “Authentication” in the menu. Then press the “Add Profile” button. You’ll see a screen that looks like this. Hit “Next”.
Settings
The settings for the Active Directory profile are simple. Basically all you need are your domain name, the address of your domain controller(s), and a username/password pair so that the FactoryPMI designer can log in to retrieve the list of all possible roles.
Testing and Tuning
That’s it - your Active Directory authentication profile is complete. To test it out, edit your project and make it’s Authentication Profile be your new profile. Now try to log in. Use the username and password that you log into Windows with. If you have any problems, give us a call or ask a question at our user forum at http://www.inductiveautomation.com/forum. If you’re finding that the role listing function in the Designer is going too slow, you may need to tune your Active Directory profile. Suppose all of your roles are stored below some sub folder in your Active Directory tree, such as MyCompany.com/Users/Roles. Then edit your Active Directory authentication profile and modify the Role Search Base property to something like:
"OU=Users,DC=Mycompany,DC=com". This will make the role search faster by searching less of the Active Directory tree.
Now sit back and enjoy the security and convenience of centralized user management!
About Inductive Automation
Inductive Automation pioneered the first full featured web-launched HMI/SCADA system in the world. Its standards based, database-centric architecture receives accolades from plant managers, IT managers, and system integrators worldwide. With a commitment to software quality and technical support second to none, Inductive Automation is the rising star in the industrial software landscape.
Contact
Jim Meisler
(800) 266-7798 x27
jmeisler@inductiveautomation.com
How To: Setup FactorySQL Alert Distribution Lists
SACRAMENTO, CA JULY 12, 2007 - This article demonstrates how to setup email alert distribution lists in FactorySQL. For this example, we will show how to setup a severity based list, a group based list and a shift based list.
Background
Alert Distribution lists allow you to define Groups and Contacts, and rules that define when contacts receive various alerts.
A group has an expression that defines which alert it will receive. Whenever an alert occurs that passes the group's expression, an email is sent to all contacts who belong to that group.
The expression is the same as an action item expression, and can use all of the functions and operators available to them. Unlike action items, the distribution group expression can refer to the properties of an alert, such as its Value, Time, Severity, Group Name, etc.
A contact consists of a name and email address, and a list of groups that they belong to.
Note: only one email will be sent to each contact per alert, therefore it is OK to have contacts that are members of groups whose expressions may overlap.
Getting Started
First, we need turn on alerting in FactorySQL. Open up the FactorySQL frontend and select Settings -> Alert Settings. Once there select a Log connection, which will be the database FactorySQL uses to store alerts. Next, give FactorySQL two table names, a log table and a status table. Make sure the System Behavior is set to Standard. Lastly, click the checkbox Send an email to the following addresses when an alert occurs and fill out the bottom portion giving the Mail Server, Port, etc. Once you are done hit OK. FactorySQL will automatically create the log table and status table in your database.
Here is an example:
Next, select Distribution Lists under Alert Settings on the left. Again, tell FactorySQL what database you want to store the groups and contacts in by selecting the connection under Data Connection. Now we are ready to start configuring our lists.Here is an example:
To learn how to setup individual alerts please consult the FactorySQL user manual.
Severity Based List
In the Alert Distribution Lists section add a new group and call it Severity Group. Now, we need to write an expression that deals with an alert's severity. For this group, let's send out emails when the severity is Medium which translates to a value of 2.
Translations:
Low = 0
Low-Medium = 1
Medium = 2
Medium-High = 3
High = 4
This is what the expression will look like:
{[SEVERITY]} = 2Enter this code into the expression and save the group. The group will look like this:
That's it! Now when an alert occurs and its severity is Medium an email will be sent out to all of the contacts in the Severity Group.
Group Based List
In the Alert Distribution Lists section add a new group and call it Group. Now, we need to write an expression that deals with an alert's group name. For this group, let's send out emails when the group name is "Test Group".
This is what the expression will look like:
{[GROUP_NAME]} = "Test Group"Enter this code into the expression and save the group. The group will look like this:
That's it! Now when an alert occurs and it is inside the group "Test Group" an email will be sent out to all of the contacts in the Group.
Shift Based List
In the Alert Distribution Lists section add a new group and call it Shift Group. Now, we need to write an expression that deals with an alert's time. For this group, let's send out emails to a shift that runs from 8:00 AM to 1:00 PM.
This is what the expression will look like:
TimeBetween({[TIME]}, "8:00 am", "1:00 pm")Enter this code into the expression and save the group. The group will look like this:
That's it! Now when an alert occurs and its time is between 8:00 AM and 1:00 PM an email will be sent out to all of the contacts in the Group.
More Information
Please consult the FactorySQL user manual for more information on the properties available to expressions. Also, you can combine groups above into a single group using the && operator in the expression. So, you could have an expression like this:
{[GROUP_NAME]} = "Test Group" && {[SEVERITY]} = 2Here an email will be sent out when the alert's group name is Test Group and the severity is medium.
If you want to configure the alert distribution lists inside of the FactoryPMI look at the Alert Distribution lists goodie located here.
How To: Use FactoryPMI Gateway On 2 Closed Networks
SACRAMENTO, CA JUNE 5, 2007 - This article explains how to set up a FactoryPMI Gateway that needs to be accessible from 2 separate private networks on different adapters.
Many industrial controls systems have been set up as 2 separate networks; the corporate subnet has local server and Internet access, while the controls subnet houses the PLCs and HMI systems. SCADA applications, especially as you get into reporting, MES, and ERP, often need to access both sides. These setups typically have computers with 2 network cards, one attached to each network. This is called a multihomed host. This article describes how to configure FactoryPMI on a multihomed computer.
We don't recommend this type of setup, especially since they were often configured without care. In critical production facilities it's not uncommon to see IP addresses like 1.2.3.4 (random routable addresses) or subnet masks that show that the engineer had no idea what they do. That was fine when industrial sites were isolated. Now that Internet access is becoming universal, this kind of practice borders somewhere between sloppy and unprofessional. Additionally, SCADA security is a hot and important area of Homeland Security.
Background
The FactoryPMI Gateway needs to be able to tell runtime clients its single address to communicate over. This is important for clustering and reconnection, even if there is only one Gateway. The address is set as the HTTP Address in the Network section of the Gateway Configuration page. If set to autodetect, the Gateway will choose one IP address, and runtime clients will only work if they can contact the Gateway via that address - in most cases one network will work and the other will not! If autodetect is unchecked it can be set to an IP address (for example 192.168.0.55), a hostname or NetBIOS name (sn25p), or a fully registered domain name (fpmi.inductiveautomation.com).
Determining the Gateway address and problem
On a working FactoryPMI client menu go to help->About FactoryPMI. This is most simply done on the FactoryPMI Gateway machine. You will see the FPMI Gateway location. This is the address that the FactoryPMI Gateway gives clients for communication. If a client can not connect to the Gateway over this address it won't be able to run a project.
You should always be able to pull up the Gateway Configuration web page - the Gateway (web server) listens over all IP addresses and interfaces. The common problem that you may see is that launching the client on one network works and the other fails. On the failed network it will load as if everything were fine, but then give you an error message right before logging in. Possible errors that you may see are Error Loading Plugins or Error downloading project data.
Getting FactoryPMI working on both networks
Getting both networks running is as simple as telling both networks a name or address that they each recognize. The easiest way to accomplish this is to simply use a the computers hostname or NetBIOS name. Name resolution can work in a number of ways. The easiest way to determine if it will work is by opening a DOS prompt and the client and pinging the Gateway by that address. If you get a response, you're good on that network. Repeat for both networks.
In most cases this will resolve seemingly magically by broadcast. If client and Gateway use the same WINS server, this should always work. If you have control of your own DNS servers you can add an "A" record, but Dynamic DNS might resolve it automatically. In the worst case you can always add manual hostname to IP address mappings in the HOSTS or LMHOSTS file of the local client.
Success! You should now be able to run your FactoryPMI clients from either network!
Naive 2 network setup usually = bad idea
The "separate networks" concept for security is a good idea. You should consider putting a computer on both networks to be the same (or worse) than putting a router in between the networks as far as security is concerned. It can be done securely or insecurely, but should not be plugged in carelessly. This type of setup isn't the best solution, but it's cheap and easy, and therefore common. Here are a few reasons that this type of setup should eventually become a relic of times passed:
- A properly configured router (can be a PC) can isolate both subnets, routing traffic for certain designated nodes, identified by MAC address. This provides a single, configurable, secure, point. Each node needs only one Ethernet adapter and IP address. A layer 3 switch is ideal for this application.
- Even home Ethernet switches provide enough bandwidth so that one side will not bog down the other. QOS (quality of service) and other performance options exist. If the PLC side truly needs realtime or deterministic performance, or the corporate network is huge, you'll probably be using other equipment and have a knowledgeable IT staff.
- It's now standard to use non-routable IP addresses and NAT behind a firewall for the corporate network. Companies no longer provide real (Internet accessible) addresses for each computer. In most cases this a sufficient starting point with respect to security, for the controls network. If it's not, you should be using an IT department instead of a tacky workaround. Your efforts are better spent password protecting the PLCs and securing the firewall.
The point to take away is that a closed (controls) network is about as secure as you can get. It no longer remains closed when you bridge it to another network. Don't kid yourself into thinking that the networks are still isolated when you have that one computer with 2 ethernet cards plugged into each. As you add computers to both networks or make your SCADA system more distributed, which is the trend for corporate access, the security of this 2 networks concept disappears. If you need security, standard IT technology has this problem figured out. There is nothing inherently "bad" about a multihomed system - it's something that you should strive to learn more about if you wish to implement one. Industrial software users and systems integrators alike should become proficient with IT basics.
Summary
We learned that FactoryPMI can be easily set up to work in a multihomed setup. We considered that networking technologies exist to properly segment and secure our traffic.
Here's how we setup a FactoryPMI Gateway to work with multiple networks:
- Verified that name resolution works on both networks
- In the Network section of the Gateway Configuration page, set a hostname as the http address
How To: Expose a FactoryPMI Gateway Behind a Private Network
SACRAMENTO, CA MAY 1, 2007 - This month's article covers some basic networking principals and settings to expose a local FactoryPMI gateway to a wider network.
Background
We're going to learn about TCP/IP and networking with FactoryPMI by example. Our setup uses the address range 192.168.0.1-254. This is an example of a non-routable Class C IP network. Class C means that we have 255 addresses to deal with and a 24 bit subnet mask (255.255.255.0). Non-routable means that we're using addresses have been reserved for private (non-Internet) use. This means that Internet routers will ignore requests that use these addresses. Make sure that you use non-routable addresses when setting up private control networks! We have a router set up that has a single legal IP address and provides Internet access to our network with Network Address Translation (NAT). This article is relevant to any setup where you use NAT, port forwarding, or a DMZ (Demilitarized zone, a subnetwork that sits between the internal and external network).
- The FactoryPMI gateway uses the static (non-DHCP) address 192.168.0.2 and currently runs over port 8080
- The router uses the LAN address 192.168.0.1
- The router uses the WAN (Internet) address 69.19.188.26
- Clients' addresses are assigned via DHCP in the range 192.168.0.100-150. They need to access the FactoryPMI project
- We want to be able to access our application over the Internet
Getting Started
Our first step to allow access to the FactoryPMI gateway is by setting up a port forward rule in the router. It should specify that TCP traffic directed to 69.19.188.26 over port 8080 be forwarded to 192.168.0.2. You may also need to add an incoming firewall rule to support this with the same settings.
To test, open http://69.19.188.26:8080 in a web browser. If you see the default FactoryPMI Gateway web site it worked! If not, try loosening up your firewall policy and using 192.168.0.2 as the DMZ host. Keep in mind that a home router DMZ host is not a true DMZ in terms of network segmenting - it is a feature that will pass all traffic to our Gateway, with the exception of certain attacks. This is much more wide open than a single port forward - more geared toward Internet games that require numerous ports to be open. Incrementally tighten back security as you determine what works.
Next make sure that your firewall doesn't block outbound TCP traffic from your local network over port 8080. In most cases it shouldn't, but our network is very secure so we'll set up an outbound firewall rule to allow TCP traffic from 192.168.0.x to 69.19.188.26 over port 8080. Without this rule, Internet users won't have a problem, but your local clients won't be able to access the system. Your clients should address 69.19.188.26 instead of 192.168.0.2 when using the FactoryPMI runtime. I would then restrict gateway configuration access to either 127.0.0.1 (localhost) or 192.168.0.*.
Launching Projects
Now launch one of your applications via Java Web Start by clicking on a project link. The application will seem to download properly, but fail to launch. What gives? The FactoryPMI Gateway web server can listen over all IP addresses, but the client application needs to know the address of its Gateway - this setting is true for each Gateway in the Cluster. Normally this is automatically detected properly, but our Network Address Translation fools the client. Another error that you may see will say Error Loading Plugins, indicating the same problem.
We need to statically tell clients that their gateway address will be the valid Internet IP address. Go to the Gateway Configuration Page -> Network and uncheck Autodetect HTTP Address. We then type 69.19.188.26 under HTTP Address.
I'm also going to uncheck Autodetect Bind Interface since I have multiple network adapters. I'll then specify 192.168.0.2 as the address for Bind Interface. This wasn't necessary, but is good to disambiguate our IP addresses.
Summary
Here's how we setup a FactoryPMI Gateway to work with NAT
- Set up a port forward rule in our router
- Under the Network tab of the FactoryPMI Gateway Configuration page, uncheck Autodetect HTTP address and specify
- Ensure that outbound TCP client traffic is allowed from our network to the WAN address of our router over the FactoryPMI port
- Clients now reference the FactoryPMI project from the WAN address. So do computers over the Internet.
FactoryPMI How To: Turn An Existing PDF Into A Dynamic Report
How To: Turn An Existing PDF Into A Dynamic Report
SACRAMENTO, CA APRIL 4, 2007 - This article demonstrates how to use the FactoryPMI Reporting Plugin to dynamically fill an existing PDF report. For this example, we will fill in a 1040EZ Income Tax Return with data from a MySQL database.
Background
The database we are using for this example is called
Accounting. There are two tables inside the database, one called Contacts and one called Income.The contacts data can be retrieved from the accounting database with the following SQL query:
SELECT C.* FROM Contacts C ORDER BY C.ID;
The income data can be retrieved from the accounting database with the following SQL query:
SELECT I.* FROM Income I ORDER BY I.ContactID;
You can retrieve the combined data for the first contact with the following query:
SELECT C.*, I.* FROM Contacts C, Income I WHERE C.ID = I.ContactID AND C.ID = 1;Getting Started
Begin by installing the Reporting Plugin in the FactoryPMI Gateway Configuration under the section labeled Plugins. Once you have the plugin installed open up the FactoryPMI Designer and select the project you want to configure. Now create a new window and drag down a
Report Viewer from the Reporting tab. Next, populate the Data dynamic dataset property by binding it to the combined sql query from the last section. Now click on the Customizer (Cntl+U) button to start designing the report.
Creating the Report
First drag and drop an existing PDF from Windows into your report designer. This will make the existing PDF the background of your report.
Now, select the
Keys tab on the right hand side of the report designer. Next, select Data and then drag and drop the Firstname key into the report. It is as simple as that!
Finish dragging in all of the keys for the report. You can even do dynamic calculations inside the report as well. Once you are done click OK and the report will look like this:
Learn more about the FactoryPMI Reporting Plugin
Subscribe to:
Posts (Atom)
