AVEVA Intouch using single thread or multi thread ?

rickard.norin  any comments on this please ? Any plans to make it multi-thread for performance ?

Hi,

An InTouch solution may include a fair amount of components and processes such as view.exe, alarm manager, communication drivers, web server, Historian, Reports, etc.

These processes are subject to load balancing by the operating system whcih will utilize mutliple CPU cores when such are available.

View.exe is, however, monolithic and will not distribute across cores. At least not in a simple single-node architecture. For larger applications, say 100k+ tags, we recommend a tag server architecture which splits the tag server from visualization client processes. This can be achieve with either dedicated client nodes or with a single Remote Desktop Services host. In case of RDS hosting, the view.exe sessions for server and clients will be separate processes which the operating system may schedule across multiple cores.

As we progress forward with significant investments in future versions of InTouch, you will see an increased granularity in the software architecture as well as adaptation to parallel processing as opposed to high Hz processing.     

This is the answer I'm looking for !!! Can you explain if this was licensing under Intouch unlimited since it allows for only one App but tag server architecture will require two apps ( one for tags , other for clients ) , I have done using two apps for this above reason and my bracket for this is much lower than yours ( 30k + tags ) , For Intouch i would like to split tag fetching and manipulation services versus visualisation. 

I'm thinking that InTouch Unlimited Professional and Premier editions should be able to accomodate an RDS-based tag server architecture. If it doesn't, I'm open to discuss fixing that

Hi Rickard, web doesn't seem to work in this kind of architecture, I have provided Intouch professional as the solution but a two app solution causes issues within RDS environment. Honestly , the real treat would be to allow multiple applications so that customers can slowly upgrade from legacy to RDS environment. . 

I would be very happy to work with your team to fix some of these things which can significantly improve the performance of intouch unlimited, most customers like the Intouch unlimited ( perpetual and subscriptions ) but have performance issues while scaling

We verify InTouch for hundreds of thousands of tags using tag server architecture so from my perspective it scales pretty well. InTouch will, however, not compare to a multi-million tag System Platform architecture.

Here are some tips for large and/or performat InTouch applications:

• Use bulk load to generate tags.
• Be careful not to load too much data on screens at the same time. Instead, use  Situational Awareness design principles, e.g. drill-down through L1-L4 screens.
• Use Historian instead of LGH files, which have an upper limit around 2GB which can fill fast with large tag counts.
• Be careful not to query history and other data stores for too much data at a time. When using Historian, leverage summary retrieval or other clever Historian features when accessing historical data.

FYI, we are working on a deployment guide for InTouch, much like the one for System Platform, which we expect to be helpful in chosing the right architecture as well as implementing it.

We are using Intouch unlimited between 10k to 100k tag region , may have customers using the 150k tag max. I think having deployment guide will really help in best practices/ gold standards that can bring out the max capabilities of Intouch

We are using Intouch unlimited between 10k to 100k tag region , may have customers using the 150k tag max. I think having deployment guide will really help in best practices/ gold standards that can bring out the max capabilities of Intouch