Considerations for Hardware Estimation

Before going to the considerations, let’s talk about the different architectures a project might have and the different functions available in ADISRA SmartView. 

The ADISRA SmartView standard architecture involves connecting to one or more PLCs (or external controller), an Industrial PC (or desktop/server), a database (either on the local PC or on a remote PC), and one or more graphical interfaces, which could be a Monitor/keyboard/mouse, a monitor only (e.g. wall hung monitor), a touch panel display, or a mobile device with a wireless connection to the runtime PC. The location of all of these devices can vary from application to application.

The runtime computer contains a license to enable the ADISRA SmartView software to run. The license will specify the maximum tag count and the maximum number of simultaneous viewers supported.

Internal Architecture

The following diagram shows the modules in the Runtime Core of the ADISRA SmartView. The runtime core can operate on Windows platforms (e.g. Windows Server 2012/20 12 R2/2016/2019/2022, Windows 8.1/10/11, and Windows IoT Enterprise LTSC) and since version 4.1 it can also run on Linux operating systems such as Centos, Ubuntu, Alpine, Red Hat using X64 or ARM64 architectures.

There are several modules in the runtime core. These include:

• Drivers. This module passes tag values to/from external devices such as PLCs or other devices using a specified communication protocol. ADISRA SmartView supports a wide variety of communication protocols, including OPC UA.

• OPC UA Server. ADISRA SmartView can serve as an OPC UA Server to external OPC UA client devices, allowing data in the runtime to be shared with other devices.

• Redundancy. ADISRA SmartView has built-in redundancy support, allowing a second device to automatically take over as the primary runtime in case of a hardware failure. This helps ensure continued operation.

• Services/Triggers. These are built-in functions to execute code segments based on Trigger events (e.g. Time-based or Tag Change)

• Tunneling. Allows control of the flow of data between two tags (e.g. two different PLC devices).

• Tag History. Can store tag data into either a proprietary file system or a SQL-compliant database on the local machine or on a remote machine
• Background Tasks. There are background tasks such as Alarms/Events, Trend, Recipes and Reports that perform specific functions utilizing tag data gRPC Server. Is used to communicate tag value changes to local/remote viewing devices, so graphical screens are updated with current value(s) and changes made on the Viewer get sent to the runtime. Uses HTTP/2 to multiplex communications on a single TCP connection.
  

Additionally, there is a Runtime Viewer used to generate graphical displays on a device, either the same device as the runtime or a remote platform. On the remote platform, you can use either a Viewer or an HTML-5 compatible web browser.

Hardware Requirements

In today’s world, you have a lot of choices when it comes to hardware. The computers have different speeds and number of processor cores to support a multi-threaded application. Additionally, computers have different amounts of RAM and size/types of storage drives. So when choosing the type of hardware platform you will need, there are multiple considerations:

• CPU Speed and # of cores
• RAM
• Storage
• Networks

ADISRA SmartView supports a multi-threaded environment that can handle multiple tasks executing in parallel. A task is added to the server’s execution depending on the features that were added to the application by the user and some tasks are internal tasks responsible for keeping the server active.

ADISRA SmartView supports different tag count configurations. Runtime licenses start at 150 tags and go up to 64,000 tags (current limitation) and support up to 32 concurrent viewers. Every tag consumes memory. Binary, Integer, Float, and Date/Time tags are fixed-length tags but String tags are variable length, up to 2 billion bytes in length although typically much smaller. In addition, each tag has multiple tag properties (Max/Min values, Timestamp, Quality, etc.) that require additional memory usage.

Tag storage can also be a performance issue. The number of tags written in a given period and the storage mechanism needs to be considered in the performance evaluation. Using a Relational database typically has much better performance than the Proprietary file system performance. A proprietary database consists of multiple binary files generated daily per tag, so when the system requests the tags history, a list of values from multiple days is selected from multiple files (multiple IO operations) while the relational database can deliver a better performance when selecting the same list of values.

The disk space storage requirements also needs to be estimated based on the application requirements.If the application connects to a database and that database will be installed in the same computer that is used by the ADISRA SmartView runtime, or in case the application is using the proprietary database, the disk space utilization and storage speed must be estimated depending on the number of tags being stored, the rate at which the data is being stored, and the amount of time to keep the tag history in the database.

Viewer performance depends on the number of tags configured in the Graphics screen(s) and any script segments executing in the Graphics. When using the cache option with Graphics screen(s), the memory usage performance will drop significantly since all the Graphics set to be cached will be kept loaded in memory, however memory utilization will increase and users will be able to navigate faster on the screens. Applications that also load many Graphics and display them on multiple monitors will require a faster processor, depending on the number of tags. Trend objects, Data Grid objects, Alarm/Event objects might also consume processor bandwidth since they can load a huge amount of data.

When reading a large number of tags from one or more PLC devices, you want to consider network performance and CPU utilization associated with this process, as well as memory requirements. Runtime performance depends on the number of threads that will be executing continuously and the type of operations these threads are executing. As mentioned, IO (PLC communications) operations are costly, driver communication can be costly if they are all kept active all the time and are communicating at an extremely fast rate.

As a starting point, a basic ADISRA SmartView runtime application (version 4.0.3.7) with one integer tag utilizes 104.7 MB. The ADISRA SmartView Demo application, which comes with the basic product, utilizes a total of 1,441 tags. Running this demo application on a PC platform utilizing the Intel I7-3770, 4-core processor running at 3.4 Ghz, the demo application consumed (depending on the screens opened) approximately 300 MB of RAM and 2.5-3.0% of the CPU bandwidth. Additionally, keep in mind that any other applications running on the PC will also consume RAM and processing bandwidth, along with the Windows Operating System requirements.

When you develop and ADISRA SmartView application, you can run the ADISRA SmartView runtime on the development PC and use the Windows Task Manager to give a rough estimate of the memory and performance requirements for the project.