Featured 

PcVue Masters Series - S1E2: Interoperability & scalability of the system

PcVue-Master-Series-S1E_20190920-152225_1

Discover the PcVue Solutions Master Series

Mini-series that inform you on everything you need to know to [supervise] your systems!
Each series is split in several articles on our blogs and episodes on our Youtube channel

Season 1: “The 6 questions to ask when choosing your supervisory platform”

This first series aims to guide you in choosing the right SCADA platform for your needs.

S1E2 – Interoperability & scalability of the system

My project will evolve in time and I don’t know the functional requirements of the future application?

As most projects evolve over time, it is often a difficult task to make initial design when one does not fully know the functional requirements of the future evolution of the application. 

We strongly advise to be very careful on this point. Functional requirements of projects are often subject to changes between the initial needs analysis and the implementation phases of the project, all the way through commissioning. It is therefore important to ensure that the supervision platform you choose will be able to absorb these drifts without requiring constant redesign and redevelopment. We discuss in this episode the criteria to be considered.

Opening to 3rd party systems

The supervision software is by nature connected many different devices and systems. As systems change over the time, it is very important that the supervision platform be open enough to adapt with systems changes.

Does the supervision platform have open interfaces for exchanging data with other systems (ERP, CRM, CMMS, ....)?

We’re talking about:

  •       Import of 3rd party software configuration  such as PLCs configuration, autocad files or xml files
  •       Simple Read / Write transactions with different types of database (SQL, ORACLE, SQL Azure, Postgre, etc)
  •       Dynamic exchange of real-time data or alarms via WebServices, RestAPI or OPC Client / Server
  •       Communication with IoT type equipment (eg LPWAN, MQTT) to easily instrument using low cost data interfaces
  •       Generic import toolkit for third party configurations
  •       Built-in SNMP agent to share variables to an external network hypervisor
  •       Capability to behave as a Modbus slave device
  •       Capability to upload and download files from a FTP server using password and/or FTP status variable

 

 

Script editors and software development kit

Despite the tools to make project design easier and faster, there are needs that will require special treatment.
It may be useful to be able to develop a specific function with a script editor. Most editors offer their own script editor that should be as simple as possible and very well documented. Ideally, a standard and well-known script editor such as Microsoft VBA should also be integrated with the supervisor.

Non-standard drivers represent another element that should not be overlooked. They are often best managed through a development kit, it is then important to investigate whether your SCADA offers SDKs (Software Development Kits) and in what language it should be developed.

These kits generally allow you to relocate processes, to interface with third-party non-standard or even old systems that cannot be easily maintained. They can help to answer specific customer requirements like the Swiss knives of SCADA helping you solve non-standard issues in the SCADA environment. It’s also important to check if these sdk are provided with additional costs or free of charge.

Scalability of the platform

As a project grows, the number of points may expand proportionally. So you must question beforehand:

Can the number of I/O tags in the SCADA easily evolve without constraint?

ü   It must be possible to start with a basic application and develop along the needs of expanding the I/O without technical restrictionsEven if the majority of supervision vendors base their prices according to the number of tags, the platform should remain the same and not require expensive redevelopment. For example, if the project needs more client stations, the addition of a client station should be configured seamlessly into the existing project with a minimum impact on the deployment (variables, features, mimic, and so on)

ü    The system must offer, in each I/O range, a margin in its calculation of number of tags, in order to avoid delays in each phase of project implementation and commissioning on site.

ü     Any "internal" tags which are not connected to devices must not be counted in the I/O limitations.  If not, you risk the pain of seeing the cost of the application exploding during the project development. Only points from external sources (PLC, other software, etc.) should be taken into account.

To Remember

Considering right from the start that the system will evolve is very important. The platform you will select must be able to evolve with the system without constraints. It should be able to connect any new third party system, and allow adding new stations or tags with no redevelopment.

To learn more about SDK available for PcVue please take a look here: https://www.pcvuesolutions.com/index.php/software-development-kit

Watch the video for episode 2 on YouTube

Coming next in the third episode, the importance of customer service and technical support!

 

SB4DViewer : Un projet Européen pour le BIM
PcVue Masters Series - The 6 questions to ask when...
 

Comments

No comments made yet. Be the first to submit a comment
Guest
Saturday, 07 December 2019