Inductive Automation is pleased to announce that for the third year in a row FactorySQL was successfully tested at the OPC Foundation's North American Interoperability Conference. FactorySQL was successfully tested with a large range of industry leading OPC servers, and once again received the OPC Foundation's "Self-Tested" certification.
This year's server field included over 40 products from MatrikonOPC, Kepware, Cogent Realtime Systems, Siemens, Software Toolbox, Wonderware and more. Each server was tested for compatibility with the OPC specification, and operation with FactorySQL. Additionally, FactorySQL once again passed the OPC "Self-Tested" certification test, which is conducted by OPC officials and tests for compliance with the specification and best-practice guidelines.
FactorySQL is a full featured, bi-directional OPC to SQL databridge, providing historical logging, realtime status and control, and more. The OPC foundation is a collective of over 300 top-name companies dedicated to ensuring interoperability in automation by creating and maintaining open specifications for communication. Since the first specification was published in 1996, OPC has become the de-facto standard in the field. Through OPC, FactorySQL is able to effortlessly link nearly all industrial devices with any standard database system.
Showing posts with label FactorySQL. Show all posts
Showing posts with label FactorySQL. Show all posts
Thursday, April 17, 2008
Inductive Automation attends 2008 North American Interop Conference; Receives 'Self-Tested' certification
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.
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: 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.
Subscribe to:
Posts (Atom)
