Here are a few links for implementing data acquisition and control systems. It is good to see NIST getting involved in this area, though it is unclear to me how much of the standard is really available. I'm an app developer, so written specs for me are an important component. I've done many data collection and control systems over the years using mostly OPC based technologies, and even though those systems work, I haven't been thrilled with the results either. I'm just throwing out a couple of links to promote the understanding and interest of the community where I work.

First, the prime NIST site is http://ieee1451.nist.gov.

There are a few references to a reference implementation provided by NIST, but I have not actually found the reference implementation.

Another related project is java's JDDAC project. Google will give you the best references to that project, though you really have to wade through the jddac.dev.java.net organization to find that there really is a product that you can download and a tutorial that accompanies it. These the tutorial is invaluable, but only serves as a warm-up to reading the source code.

I tried hard to make TANGO do what I wanted,
http://www.esrf.fr/tango, but could never get past some of the initial setup issues. I spent days with it, and never really liked it. But I did discover a set of web-widgets for visualizing data at http://www.elettra.trieste.it/~tango/Canone.

I'm on a quest for a "real time database". I hate that misnomer, but I don't know what else to call it. In my book, it is the data collection repository usually maintained by some vendor's product.

I look forward to the day when this component of the control system is standardized and open source.

bbaker

 

hi,
There are open source SCADA (system control & Data Aquision). Most of these are OPC based, and provide all the tools and graphics required to do the job. I notice now that more and more SCADA are XML based, using standard windows components, i use these too and they are fine.

There are also SCADA packages that provide Native communication drivers that are generally faster than OPC. But I find that for OPC to an interface, that there are no major issues at all, the SCADA interface i am doing at the moment has about 50,000 OPC points configured to it, and it doesnt miss a beat! Its just a matter of good program structure and array your OPC Points.

Dennis

 

If you are programming in C or VB or whatever, check out Codebase. It is an xbase database library that is small and fast. It resides in RAM until you flush it to disk. It's been around a while too, so it is stable.

 

There are things called "real time databases" used by the telecom and other industries. They typically operate entirely in-memory and use a clustering system for high reliability. MySQL is working with a number of customers for solutions in this area (MySQL has different storage back ends for their SQL engine). This probably isn't what you mean though.

If you just want a bog standard SQL DB for storing and retrieving data though, there really isn't anything the proprietary database vendors offer that would interest you which isn't also available from the open source databases. It's also a lot easier to find someone who actually knows their way around MySQL than it is for any of the proprietary databases.

PostgreSQL is considered better by many people because it is more standards compliant, and because of how it handles transactions (if you need that feature). If you really just need an embedded database, SQLite is well regarded, and has a great many language bindings. There are others, but I haved just listed some of the more famous ones.

There are probably a *lot* of people who are unknowingly "pirating" a proprietary database. Under a typical proprietary database license structure, the application software vendor can use and install the proprietary database at no cost. It is up to the customer to research what license fee they have to pay and forward this directly to the database vendor (along with annual "maintenance" charges). The application software vendor isn't going to point out that little fact to their customer though because it makes their product look more expensive.

If the application comes with a license for a proprietary database, then it is typically a very narrow one for very limited use. There have been several discussions on this list already where someone was adding a feature or making a change to a SCADA or MMI system which had a proprietary database, and someone connected with the original application vendor pointed out that to legally make change 'x', you have to pay more money to database vendor 'y'. It's not that you need to actually buy any new software, it's that you need to pay more money to change the scope of the license.

Customers also sometimes mistakenly assume that because the company "already has a site license" for a proprietary database, they don't have to pay more money. It doesn't normally work like that. If you add more clients, you have to buy more CALs. If you add a web interface, you have to buy a special web interface license. Actually, if you do just about anything, you have to pay more money.

Given these problems, its not surprising that people who are just interested in getting the job done like the open source databases better than dealing with the proprietary vendors.