Digital Trends and Trend Storage on Data Change

Hi Chris,
What version of the Wonderware Historian Connector are you using?
In the V3.0 release the following change was made:
- Connector stores "floating point (8-byte samples)" values from Citect SCADA as double in Wonderware Historian.
- Connector stores "scaled (2-byte samples)" values from Citect SCADA as a float in Wonderware Historian.
It is also possible to historize Digital Tags directly, without the need to configure a Trend tag. You are correct, 2-bytes of storage isn't the most efficient way to store a digital value.
The only thing to be aware of is that Digital Variable Tags (which have Historize = True) get .Discrete appended to the tagname in the Historian DB. They also don't support backfilling, so you might miss samples while Connector is down.
I agree that there should be a better way in Citect SCADA to store digital data more efficiently.
With regard to storing Variable Tag data in a Trend only when it changes, your best option is to use Event Trends. The amount of engineering you need to do to make this work will depend on the protocol you are using. If you have OPC, DNP, ABCLX or IEC61850 then these drivers are Driver Runtime Interface enabled, which means they push samples into the Trend and Alarm system. If you have a traditional poll based driver (like MODNET, S7NT, etc.) then you will need to configure a tag or expression which controls when the Trend sample is taken (via the Trigger field).
Kind regards
Olivier

Oliver,

We are using V2.1 of the connector and currently the 2-byte tags are stored in the Historian as 32bit INT same data size as a float. There doesn't seem to be any clear documentation on what would happen if we upgraded the connector to V3.0, hence the reason we stuck with V2.1. By the way, we have had nothing but trouble at first with the connector and found that we needed to move the Citect API .dll files from the Citect installation to the connector's bin directory, solve all of our issues.

Back to the trends, my colleague just pointed out that there is a deadband parameter that can be set when configuring a trend tag. We have not used this and wonder if this would work. The docs state that...

"A deadband allows the value of a variable tag to fluctuate within a defined threshold without updates being sent through to the trend tag. This may be useful if a tag produces many small, insignificant value changes. The threshold is represented as a percentage of the tag's engineering range. The default value is 0 (zero), which captures every value change."

I assume that the "percentage of the tag's engineering range" is the variable tag not the trend tag, and that it might do what we need, even setting the trend type to "TRN_PERIODIC".

Any experience with using the deadband on trend tags?

Thanks,

Chris

Hi Chris,
Apologies for the delayed reply.
There are quite a few known issues with the V2.1 version of the Connector. I'd highly recommend you upgrade to V3.0 when you can. The upgrade is straight forward. You should uninstall existing version, install new, check configuration settings. Then run the new connector.
With regards to Deadband, it will have some effect. It won't reduce the amount of samples stored within the Trend archive, since it is periodic. But it may have an impact on any connected Historian system. However most modern Historians have quite good compression algorithms which make this unnecessary. Most customers want high fidelity, lossless sampling anyway.
I'd say give the Deadband setting a go, experiment with it and see if it makes much of a difference.
Kind regards
Olivier

Olivier,

We plan to roll out v3.0 soon, just didn't know what will happen to the existing historian tag names as there doesn't seem to be any documentation on our specific situation.

One thing that would be EXTREMELY useful is a direct back fill utility from CitectSCADA to Wonderware Historian. We have struggled with back-filling all of our systems into the Wonderware Historian when we switched from the Citect Historian. We have 7 server pairs, 8 clusters, and about 5000 trend tags, all of which get historized. I've always though there could be an easy way to incorporate this functionality in the Connector.

On the Trend Deaband subject, so what you are saying is if we use Periodic storage method combined with a Trend tag Deadband, it will still log a sample even if the Deadband has not be exceeded, that sample would be that last know variable tag value?
I'll need to spend some time testing this, just trying minimize the data storage we consume with Trending. We keep 13 months of 0.100 second sample data, most tags don't change much and we could save a lot a space.

Thanks,
Chris

Hi Chris,
There are some manual steps required to upgrade correctly depending on the features you used in V2.1. These changes may need to be managed manually, on the Wonderware Historian side. For example, if you upgrade from V2.1 to V3.0, any Variable Tags of data type String that were being Historized, will now have a new Wonderware Historian tag created for them, appended with .String. In V2.2 extra support for Digital Variable tags was also added, which appended .Discrete to the end of the Historian tag.
The Trend Tag names will however be unchanged. So there should be no impact there.
Can you describe the back fill feature you require? My understanding is that if the Connector is disconnected (or shutdown) for any period of time, when it starts up, it will request the trend data from the SCADA system from the time of interruption, thus back filling any missing data.
There was a feature in Citect Historian where you could poll a Variable tag for data, and then on disconnect/shutdown it would back fill from the available Trend tag data (which corresponds to the Variable tag). This feature is not available in the Connector, but it is just requesting data from the Trend Server. If there is any missing data, it is likely a bug. I believe all known issues around back filling have been resolved in V3.0 version of the Connector, so I am confident you will get a much better experience.
I also found through my experience with the Connector that you can maximise throughput performance by setting the following parameter on the Citect SCADA Trend servers:
[Trend]
ReadWatchTime=0
On the Deadband subject, I can confirm that this will not take any effect on the number of samples stored by the Trend system. The Trend system will just store the sample value (while applying the deadband) on the defined period. So even if the sample hasn't changed out of the deadband range, the Trend server will just log the previous value again. This is useful if you want to filter out noisey data sources, but not what I guess you are trying to achieve.
You could also look at Windows file compression to save some space. There will be a small hit to read and write performance, but it shouldn't impact the Trend Server.
Kind regards
Olivier

Olivier,

Thanks for the detailed reply.

Yes, when you shut down the connector, it saves the last known datetime of each trend tag sample it was able to push to the Historian. Once the Connector is started back up, it will check for new Trend tags and their historize flag and pick up where it left off. It is also tolerant to our WAN connection being poor at times, if it looses the connection to the Historian, it goes into storage mode. Upon reconnecting to the Historian, it will forward that data on.

The backfill feature I am requesting is one that the user can manually initiate a backfill. We originally setup our Trends to save 13 months of data(700GB-900GB) per server, per cluster. When we installed our central Wonderware Historian, the past 13 months of data was very difficult if not impossible to backfill. We tried using Eric Black's CiCode function where it creates fast load .csv files from the trending data, but was too slow, the HUGE .csv files needed to be manually transferred across our network to the Historian, and you needed to have a lot of HDD space available on each Citect Server in the first place. So with that, it would have been really nice to have the connector doing that for us. The biggest danger that I see of this feature is if someone starts a backfill where there is data samples already, you'll end up with double samples. There would need to be some sort of method built in to prevent this, by or mark existing Historian data as bad before writing new samples. Maybe even a user selection as to how to handle it.

I appreciate your helping me better understand the deadbands on the Trends. We'll probably just keep them undefined for now and consider rolling back the amount of on server Trend data we save to help with HDD space and rely on the Historian for the rest.

Regards,

Chris

Hi Chris,

I understand now. You want to be able to backfill all available data from the SCADA system and send it to your Historian. By default, the Connector will try and backfill 7 days of data. The reason it is set to 7 days is the time it takes to request all trend data for that range. It might take hours if no days to get this data backfilled on a large system. Some customers expect the Connector to catchup quickly and start getting data in real-time. The mechanism it uses (TrnQuery) to get the data is not super efficient either. The request is sent per Trend Tag for a defined period of time, which the Trend Server then needs to process, read data (either from memory or disk) then respond. I don't think there will be an easy way for the existing Connector to achieve this functionality. I will discuss it with some of the developers and pass on this information to the Product Management.

From what I have learnt through other exchanges with customers and project delivery teams, is that the bulk of the data is transferred manually using custom code or export data from the SCADA system, then imported into the Historian. The Connector is then started with the default settings (7 days backfill) to get the remaining data + real-time data. It sounds like you did everything right, it just isn't a seamless experience.

With regards to duplicate data, I believe the Historian should be capable of handling this, but it is probably worth checking this with a WW Historian expert.

Kind regards
Olivier

Good afternoon, how are you?

We are testing Aveva with Citect SCADA through the Citect SCADA Connector.

It was published only as discrete and string tags, but is also required for analog tags (int, long, word, etc.).

Are there any specific settings for analog tags?

Thankful,

Hi Alessandro ,
The Citect SCADA Connector V3.0 only supports the publishing of String and Digital Variable Tags. That is, variable tags of data type String and Digital, which have the Historize flag set to TRUE.
The only way to publish analog values (e.g. INT, LONG, REAL, etc.) is to create a Trend Tag for these variable tags. Then set the Historize flag to TRUE for the Trend tags you want to publish.
The Trend Tags is a better approach, since the Trend System acts as a value buffer, so even if the Connector is shutdown or disconnected, it can recover from the last known sample value. The same isn't true for Variable tags, since you can only query the current value.
Hope this information helps.
Kind regards
Olivier

Thankful Olivier,

To create the OEE, imported the equipment list and status. But displays error in Reason list: Import Generic Utilization Reasons - Error Details

"The state equipment was not found in the efficiency model"

How to resolve this error?

Thank you very much,
Alessandro