Hello Historians and databases specialists,

We are looking for solutions to upgrade our current Labview-based application that takes data from PLCs through OPC servers and store them into a home-designed binary file structures, locally on a PC.

These are our specifications:

- All our processes are parts driven (discrete). We are not dealing with time-based processes

- One part is produced every 1min

- The data acquisition is triggered by the polling of a 'trigger' (counter) and when this counter increments the application get all related data. In other words, nothing happen during 1min (just the trigger scrutiny) and all data transfer is once per minute.

- Per cycle we are taking about 15.000 tags (16 bits words) per machine

- Per plant we have roughly 10 machines, all with a cycle time of 1 min. One PC today is connected to 1 or 2 machines. So 5 PCs per plant roughly.

- Emphasis given on the visualization of the data close to the machine to help the operator in his process adjustments. Here the operator needs to visualize all parameters for a specific machine cycle, overlay profiles (a profile is a serie of tags for a defined cycle), graph parameters against cycles or against time (but even against time the different points of the graph mean a specific part produced)

- We do not really have time constraints as to the time it takes to fetch and write the data into the database. It can take 10s, we do not really care.

- Open database so that people can make cross-machines analysis of data (data mining)

- Cost-effective solution

An internal discussion lead to considering that instead of writing into a local home-made Database we could simply write into a centrally located SQL database (located on a plant’s server).

I know that Historians could also be a way to go but do not understand the advantages that we would have especially considering the specs given here-above.

What solutions would you recommend to implement or to study?

Thank you very much to share some thoughts with me
Christophe

 

Well, normally, I would advise that SQL relational Databases are absolutely the worst way to store time series data. But in this case you're not not storing time series data, so its likely that an SQL type database would work very well and save you an enormous amount of effort required to develop and maintain a proprietary database.

Your most cost effective database is probably MySQL - so cost effective in fact that the community editions are free, and will serve most small or medium sized one off applications quite nicely. MySQL is open source, and will run on any windows or unix platform. There a variety of connectors available including ODBC, C, J, Python and PHP, so you should be able to use an off the shelf OPC to ODBC interface to collect data from your PLCs. (If you've never heard of MySQL, its one of THE most popular SQL databases used for a huge number of web applications so is very much a main stream product). In any case, you could start with the community edition and decide later whether you want to use one of the commercial versions.

Rob
Www(.)lymac.co.nz

 

Thanks for this answer. I wanted to add few features that the current application does in case it changes a bit the answer...

Visualization windows: the Labview application that we wrote provides several ways to visualize the data:

For the local user close to the machine under supervision, operators mainly use the 3 following windows of the application:

Window1/ All process data values for a machine (can be thousands of parameters) displayed for a specific cycle number selected. Displayed in a kind of two-columns table. The selection is either a cycle number or date/time (in this case the application fetches the cycle closest to the date/time requested)

Window 2/ Some parameters are what we call profiles ie. collection of consecutive tags. Those must be displayed as curves for a selected cycle. For example after each cycle we collect pressure profiles, each profile being 500 consecutive tags.

Window 3/ 5-graphs, each one able to display a parameter against cycle number or time. Even when time is selected as X-axis, each point will represent the value of the parameter for a part produced.

The application also gives the possibility to set limits on parameters (different limits for different products). Those limits are displayed in the graphs of Window 2 and in the Window 3 interface as well.

For more advanced users performing off-line analysis they use the same windows and also an interface that allows extraction of parameters into CSV files for further data mining.

Thanks again for your thoughts.
Christophe

 

Ok, so let me address this from the angle of communications. The drivers in the OPC Sever are going to communicated synchronously to the devices they have been configured to talk with. They do this because that is how the communications protocols in the devices are designed.

The Historian software will tell the servers the items it wants to acquire data from and the rate at which that data should be acquired. The problem with using triggers is that you have to ensure that the the historian has been updated with all of the data it will be logging before the trigger changes value and initiates/triggers the logging/saving of the data. In most cases this is handled triggering the counter x amount of time after the data to be logged has been changed and the device has been polled. Polling has to be precise for it to work correctly.

 

Hello Fred,

I understand what you say about synchro between OPC servers and devices. But I am not clear as how this answer my original question, what are your thoughts as to the direction I should take, historian vs sql database?

Thanks for your inputs. The things with which I am a bit reluctant bringing an Historian into the picture is the fact that reading users' experiences and vendors advertisements, Historians are meant for:

- time-based recording (not the case in our processes, we use the Part as the reference)

- huge data throughput to database (not our case, we log data once per cycle so lets say every minute)

- Big volume of data: that is maybe (not sure) a pro for historian but I am not even sure. A typical plant includes 30 machines ranging from 100 to 10.000 tags to collect once per minute. It does not matter if the collection phase itself take a few seconds.

I do not know if there are integrated tools (SQL analysis) that exist if we get rid of the historians and we go towards the SQL-only database.

Thanks again
Christophe

 

Hi,

I am an expert in SCADA design and development, specialized in Siemens SCADA WinCC.

What you are looking for is not a historian but a application specific highly customized SCADA development.

I have engineered and commissioned very similar projects. The screenshot are as attached in the link below. You can see XY table in background probably the way you want. And customer also wanted the scada to show current punching graph on scada. So the popup window shows the current status of machine (red is one type of punch while blue is another type of punch) This does not use any historian but a well engineered SCADA.

If you can suggest a convenient time, I can show the working demo on team viewer.

Please clarify following:
1) Do you use OPC DA or OPC HDA for accessing your job profile.
If your old software uses OPC DA, then clearly historian is out of question.

2) Can your budget allows going for standard SCADA software like Siemens WinCC plus engineering? In either case I can help you. However if it is standard SCADA then engineering cost will be little less.

http://www.plctalk.net/qanda/showthread.php?t=76134&highlight=historian