The SCADA programmer

Article dated 21/04/2023 - Written by Di Muro Francesco

A few days ago I happened to receive a call for a job offer, during which, as usual, I was asked to talk about my work experiences, citing the most relevant skills learned. Shortly after starting to speak, the interlocutor stops me, asking me:

“Excuse the question, but what exactly do you do in your job? I've never heard of SCADA”;
so, a little surprised, I started explaining what my job consisted of.
This conversation prompted me to write this article, in which I want to talk about my personal work experience as a SCADA programmer, exposing personal reflections about this role unknown to many.

Surely, compared to many other categories of programmers, the SCADA programmer (or in jargon "scadista"), is a lesser known role that certainly arouses more confusion than curiosity when you hear about it.

To better understand the content of this article, it is good to start with some definitions.

What does SCADA mean?

SCADA is the acronym of Supervisory Control And Data Acquiring, or in Italian, [System of] Control [,] of Supervision and Data Acquisition
In the most generic software & hardware friendly definition, the SCADA is a virtual or physical server on which applications and applications, which can be grouped into four macro-areas, thanks to which it is possible to satisfy the requirements of the nature of the system itself.

Specifically, we can divide the macro-areas into:

1. driver(s) for communication with field devices (PLCs, recorders, OPC servers or other SCADA systems);

2. SCADA "core" services (process database, graphic navigation in the system);

3. data logging services, alarms and events;

4. reporting tools and data analysis.

A practical example of SCADA can be an operator panel mounted on the front panel, which has the task of monitoring of a CIP plant, logging alarms and events on a MS SQL database, generating reports, processing and alarms and events through customized tools.

Although the role of the "scadista" may seem simple and of little impact, the reality is that it is not at all in both cases
Below are some practical examples relating to the macro-areas mentioned above, to better describe the role of a SCADA programmer in as much detail as possible.

Communication drivers

When we talk about communication drivers, we are talking about a wide range of services thanks to which we access data, raw and not, which are fundamental for any SCADA system.
Often, the communication drivers have a different operating logic, which is why the programmer must study the documentation before implementing the structural logic thanks to which the SCADA can access the process data.
Most of the communication drivers have been moving for years now towards a standard and more current direction, although there are cases in which the use of communication standards is preferred legacy, which force programmers to have to intervene on the software side to obtain the necessary data.

The Human Machine Interface (HMI)

Navigation in a SCADA system is essential for the users who use it, which is why it must be simple, immediately understandable, and must be able to satisfy customer requests and European standards or international;
moreover, most of the design of the graphical interface, and the totality of the realization of the graphic elements of navigation within the same are the responsibility of the SCADA programmer.

Data logging and analysis

The data logging services, alarms and events concern a fundamental and extremely delicate aspect of any SCADA system that requires their implementation, since thanks to these data not only are we kept track of what happens to the system and what it monitors, but, integrating the use of dedicated tools to create reports and dashboards (audit trail, historical alarms, batches), a predictive analysis is also carried out, thanks to which the probability of occurrence of anomalies is considerably reduced, in such a way as to guarantee safety and continuity of operation of the entire system.

The other responsibilities of a SCADA programmer

After talking about the basic responsibilities of a SCADA programmer, I'd like to talk about what are the indirect responsibilities, including:

• the responsibility of interfacing with teams of electronic experts to define, for example, the inputs and outputs used by a PLC for interfacing between the field (what has to be monitored/controlled) and the SCADA system;

• the responsibility of interfacing with process engineers to define the critical parameters and operating logic of a system, using flow charts and document specifications, which ensure the functioning of the system itself in compliance with the customer's and European standards/ international;

• the responsibility of interfacing with validation engineers, with whom they create project documents such as operator manuals, software detail specifications, signal lists, validation protocols to test and validate systems, and many other documents.

In all of this, in most cases, a SCADA programmer interfaces directly with the customer, presenting the navigation structure, operating examples of the required specifications, continuously receiving feedback to correct and/or improve the system.

Given my passion for programming in general, I have always looked for and still look for new ways of doing things, getting as close as possible to the technologies widely used in the job market for the various programmer profiles.

In confirmation of what has just been written, thanks to several large projects and my desire to enrich myself professionally:

• learned and honed my skills in seven programming languages, including Python, VBA and T-SQL;

• I have learned the use of terminologies in the sector in which I work;

• I learned to work in a team, but especially to work alone;

• I learned the concepts and realized servers, clients, APIs, network configurations and many other things.

Pros and Cons of this job

As in any job, there are pros and cons that can be more or less subjective, which is why I will list those that I personally believe belong to the relevant categories.

Pros:

• ability to work remotely, company permitting;

• possibility of getting to know different environments and systems, thanks to which one is enriched on a personal and work level;

• possibility of developing team working skills (company permitting);

• possibility of developing team leading skills (company permitting);

• possibility to develop social skills in different fields (interfacing with different teams, interfacing with customers);

• possibility of continuous study of technologies to create SCADA systems that comply with customer and/or international standards (company permitting).

Cons:

• constant travel, due to the fact that most of the activities must be carried out at the customer's premises, except in some cases where the customer sets up a remote access system to its network infrastructure;

• working in smart working is not always granted, and if it is granted, the tools for accessing company servers are legacy and not user-friendly;

• low salary compared to the responsibilities and duties, with RAL rarely exceeding €25,000;

• possibility of being victims of overworking, due to the fact that one can find oneself managing several different projects at the same time;

• low probability of growth within the company, especially in smaller ones, given that the technologies used are always the same, and sometimes they are obsolete technologies;

• value not immediately recognized in the job market, given that it is a niche role, in which little-known technologies are used compared to other profiles in the programming field.

Personally, I think that the SCADA programmer is a good starting point for those who, like me, have not embarked on a university course aimed at aiming for a more "prestigious" job position, and after seven years of experience in this role, I can state that being a SCADA programmer is not THE job, especially for young people who want to grow continuously both professionally and economically.

I hope this article has been exhaustive and has made you understand that a SCADA programmer can know many more technologies than a programmer specialized in a single field, making it a positively surprising little gem.