We help clients create trusted data for critical operations.

We create IoT solutions that transform how our customers manage their business assets

need-advice
need-design-help
need-support
solutions that transform

SCADA and RTU Solutions for Data Acquisition that Includes Systems Services

SCADA (Supervisory Control and Data Acquisition) software systems are essential to operate most industrial, critical infrastructure and manufacturing organisation’s assets. SCADA, PLC and RTU solutions are often complex in nature and for large-scale projects include a variety of equipment in geographically disperse locations. In almost all scenarios, the blended discipline of IT (Information Technology) and OT (Operational Technology) is required to bring together a successfully implemented solution. The technology solutions and SCADA services provided by Parasyn utilise various technologies and infrastructure and aim to reduce design complexity when it is possible. The approach to design and managing implementation ensures that the final solution is maintainable by competent technical personnel either from Parasyn, or the customer’s team. 

Why are SCADA Systems Important?

SCADA, PLC and RTU solutions create communication channels that allow various equipment to provide information and data to the home base or central host. The central host may be physical hardware on premise or could be virtualised. Data acquisition of process information provides status and control of all types of industrial processes. Whether you want to monitor your HVAC system, water treatment plant, power generation equipment, or other intelligent machinery at any location, the SCADA, PLC and RTU equipment is as critical to continuous operation of the plant as the plant itself.

How to Design SCADA Services

The success or failure of any large-scale IT/OT project, such as SCADA, depends on the design, design planning, implementation strategies, testing discipline and people collaboration. There are several subsystems in an enterprise SCADA system which may include remote terminal units (RTUs), programmable logic controllers (PLCs), distributed control systems (DCS), telemetry infrastructure, data acquisition and edge servers, human-machine interfaces, process historian software and so forth. All SCADA Solution components need to seamlessly interact with one another, and particularly if there is a large distance between any component. Latency and access to replace components is all part of the system design. The design team at Parasyn utilises proven techniques to ensure that the best implementation strategy is developed based on the agreed requirements. The Parasyn team have experience designing the project structure as well as the technologies required to deliver customised solutions what work. When you have to guarantee a system for life, you design it better. 

What is the best project structure for SCADA projects?

Most small non-critical SCADA systems do not require significant design investment. When a system grows in size or connects with many devices, the system design and how the data management activity is to be organised and performed must be designed to ensure sufficient resources are available and scheduled for reliable communications and accurate sampling of data from all network devices. For larger systems, there is likely a need for a number of SMEs (subject matter experts) to come together to collaborate. Being familiar with the system components is insufficient grounding to understand the principles involved in doing systems design. Engineers capable of doing end to end systems design (or work part of a team that does such) rarely operated outside of teams as freelance contractors. Most large-scale system’s design is performed by groups of engineers who are organised by discipline and who also have a strong understanding of the impact each component of a system has on other components of the same system. For this reason, it is unwise to hire more people to get a design done quicker. This is usually counterproductive. Assuming the design team has worked together before, usually the efficiency of design is inhibited by not having all of the necessary inputs that allow design decisions to be made when each topic is visited. For new development activities, sometimes Proof of Concept testing is required to prove a new interface works or instil confidence to the user group that their design concepts are valid for their organisation. A proof of concept stage as necessary as it may be, can significantly extend the time to complete an end to end design. The ideal background for doing design is when all user requirements are documented before design begins and stakeholders are made available to the design manager in case any requirements need to be clarified along the way.

Why Choose Parasyn for your Industrial IT Solutions

Parasyn is an Australian IIoT Company which has years of experience developing customers solutions for efficiently management assets. Parasyn specialises in solutions for industrial and manufacturing businesses including oil and gas, water, energy, and transportation. Most of Parasyn’s industry awards are related to systems design for critical infrastructure where a group of engineers collaborated with the customer’s stakeholders to sure up concepts, document the design and then implement the system safely. Even though it is nice to win awards for boutique and unique first-class projects that are cutting edge, these don’t come along every day. Most, but not all that Parasyn does, includes an element of creativity. “Systems of success” is the formula that Parasyn applies to deliver projects without having to make up the plan every single time. Parasyn does not spend time working out how to run jobs, how to develop design processes, organising how teams are to work together or preparing templates to deliver technology projects because it’s all been done before. Parasyn’s creativity and ingenuity is directly applied to solving problems and customising how technology can be deployed successfully. Even though requirements must sometimes be discovered by enquiry, how services and projects are delivered is not guess work. This provides assurance of outcomes.

What is a SCADA network?

SCADA is used by many professionals as a general term that describes all of the information systems and infrastructure use to manage a group of assets. Sometimes SCADA subsystems may be identified which include telecommunications, IT infrastructure, instrumentation, wiring, domains, WAN, LAN and software. Sometimes SCADA systems share infrastructure with other enterprise systems.

How do SCADA systems work? What is a HMI?

SCADA systems are a culmination of subsystems and components. They may be complex or very simple. A simple system could consist of one PLC used to control a pump or piece of equipment and a HMI (Human Machine Interface) could be a touch panel. The system itself may be fully autonomous and may not require any user intervention, or the opposite may be true where operators must interact with the HMI when fault conditions occur, and operational inputs are required. In modern terms, the HMI could be an Apple iPad, but the control system components would almost always be branded as one of the major Industrial Automation suppliers. To the contrary, a large-scale size enterprise SCADA system could have thousands of field devices, hundreds of thousands of data points (tags) and hundreds of data consumers.

Users interact via the HMI. The HMI is the customised visualisation GUI which is developed to represent how the assets are to be logically operated. Sometimes the HMI also includes schematics of plant and equipment, geographic information, pictures and plant reports to assist operators to be fully informed when operating equipment.

Who uses SCADA?

Almost all essential services and industry uses SCADA. The defence force, public infrastructure and utilities use SCADA, manufacturers use SCADA to control various types of production machinery, building automation systems in hospitals use a form of SCADA (if they do not used rudimentary SCADA), transport companies, mining companies and virtually anyone who needs to operate critical assets reliability, more reliability that what is typical for desktop consumer grade applications.

What are the Applications used in SCADA?

Some may argue (based on their own enterprise experience) that SCADA only applies to the software system used across the greater enterprise which manages groups of assets, however, the SCADA software itself could be the very same software being used locally. In other words, the plant software or the enterprise software is the same but has been configured specifically for use locally or at the enterprise level. For this reason, there is sometimes confusion about the reach of the SCADA system.

The SCADA software may include visualisation, alarm management tools, client distribution technologies, reporting and other tools specific to the industry itself. Some SCADA systems allow integration with other 3rd Party enterprise systems. SCADA software is synonymous with customised visualisation of an enterprises asset footprint. The SCADA development environment makes it possible to organise information logically so that standards can be applied for maintaining each asset, instrument or virtual device that is part of the “system”.

SCADA Systems and Control Systems (which may or may not be part of the SCADA) usually use industrial grade communications protocols. Some of the more common device protocols are; Modbus, DNP3, Profibus, DeviceNet. Devices that are configured to use one or more protocols must comply with the published standards to ensure devices operate safely and error free. Control systems that use industry protocols, are designed for purpose and tested correctly are very safe, very deterministic and reliable. This means when End to End SCADA design is comprehensive, the system operates in a predictable and reliable fashion. When adding to an existing system design, the equilibrium may be disturbed, and it may not be possible to operate safely and error free by simply adding more of the “same thing”. System design considers how components interact, how they are configured and how they are to operate in fault or fail over

What is a PLC?

Programmable Logic Controllers (PLCs) are a control device similar in concept to a computer. They are very similar to an RTU. The operating system is purpose built (embedded) and designed specifically for control applications where routine activities must be done reliably and regularly without failure. These high-speed controllers may have options for redundant CPUs, power supplies, communications, I/O cards and safety certification depending on the application and brand of the PLC. All of these options come at a price, therefore, the choice of which PLC may be determined by a number of factors. These factors may include:

  • Does the organisation already have the configuration software?
  • Does the organisation have a code library that can be used to help develop this particular solution?
  • Does the SCADA, other PLCs or HMI need to communicate with this device?
  • Is this a safety system which may require triple redundancy?
  • How familiar is the support team with this device?
  • How expensive is the device of choice?

What is a DCS?

A Distributed Control System is generally used for controlling continuous processes plant. In the 70-80’s, DCS were used for controlling many process plants. In time, as PLC’s improved in performance and reliability, they took over some roles of the DCS. Slowly PLCs (particularly safety grade PLCs) have been used more often in place of DCS’s.

A DCS solution is usually a very significant investment for the asset owner or asset manager. A DCS solution is synonymous with a quality solution and a price tag to match. In recent years as the PLC market has penetrated and replaced many DCS applications, DCS vendors have begun to release “lower grade” DCS solutions with less features and a matching price tag so that they are able to use their solutions in applications which are now typical for PLC solutions.

What is the difference between a DCS and PLC?

Generally, a DCS hardware platform is fully integrated and certified to only operate with its own SCADA Platform. SCADA systems are event driven and the core component of the DCS is state driven. These important distinctions help to explain the reason that DCS systems are used for applications like continuous process mining plants and oil rigs.

In many cases the DCS solution may not be as flexible as off the shelf SCADA, PLC and RTU systems, however, the DCS solution is intended for applications where repeatability is paramount, and flexibility is less important due to the limited number of customisations required for operations.

What are the best protocols for SCADA?

Time series protocols win this challenge hands down every time. Today, the most established over the air protocol for distributed SCADA systems is DNP3. There are others to choose from, however, with the exception of the real time protocol Modbus, they are less common and that means more challenging to support and maintain. Even though DNP3 is very well established by many vendors, vendors sometimes do not have their interfaces independently certified. Vendors sometimes develop their own “protocol stack” from scratch. This means to ensure full compatibility with other certified products, either certification or thorough testing must occur.

DNP3 is a time series protocol. This means the value of the sample is recorded with the time and data in the field device. As long as the field device is synchronised accurately with a time source (e.g. NTP or GPS) then the events created by the DNP3 RTU or device can be used for an SOE (Sequence of Events) system. This is very common practice in Rail and Power industries and is quickly becoming the pseudo standard for other utilities throughout the world.

What are the greatest problems with SCADA systems?

Without explaining why, the biggest problems we see with SCADA systems can be summarised in the follow bullet list:

  • Too many connections to the SCADA platform inhibiting its ability to perform its primary purpose of data acquisition and alarm notification.
  • Device selection by personal preference at the cost of system design criteria
  • Incorrect selection of network protocols
  • No data management plan, ie how much data do I need for the business, do I have the communications network to support this, do I have storage for the data payload
  • Documented design which can be used to scale up the systems as it needs to grow, downsize the system, split the system, or replace it.
  • Having too many “thick” client applications all accessing information at the same time instead of using other technologies like Enterprise Historians which are designed for high performance data access.

What is meant by RTU?

An RTU (Remote Terminal or Terminating Unit) is a microprocessor-controlled device that interfaces with objects and reports status or controls about the local condition of equipment. In the earliest days, RTUs were “bundled” with other equipment eg telecommunications equipment, generators, pumps etc, as a means to monitor status and health of its associated equipment. The next generation of RTUs extended control to operators to remotely start and stop devices using RTUs as the end to end communications platform. In these cases, the HMI could have been a bespoke software application or a touch panel many hundreds of kilometres away. In time as RTUs matured and became more like PLCs, engineers began using RTUs in place of PLCs because typically RTUs had superior communications capability over that of traditional PLCs.

RTUs have more recently become the pseudo control device for distributed asset management. It is very common to see water, gas and power assets managed and controlled using RTUs with PLCs being reserved for very high-performance application like asset protection. In these cases, it is common place to see PLCs and RTUs used together, ie the PLC with the role of chief controller, and the RTU as the marshalling communications device which incorporates all health and status reporting. This is most appropriate when the SCADA network protocol is DNP3 as most PLCs do not support this network protocol.

What are the common PLC & RTU Programming Languages?

Under the IEC 61131-3 standard, PLCs (and RTUs) can be programmed using standards-based programming languages. The most commonly used programming language is Ladder Diagram (LD) also known as relay ladder logic. It uses Contact-Coil logic to make programs like an electrical line diagram. The full list of programming styles are as follows:

  1. Ladder diagram (LD), graphical
  2. Function block diagram (FBD), graphical
  3. Sequential function chart (SFC), has elements to organize programs for sequential and parallel control processing.
  4. Structured text (ST), textual

There is no “one” philosophy that fits all situations. Sometimes SFC is the simplest method when developing a new concept. To the contrary when editing large arrays of points, STs are more suitable. The power of the debug tools that are made available with the software platform also may influence what the engineer may choose to implement the software with.

The most important aspect of which PLC tool to select is maintainability for parties other than the original developer. The original developers often fully understand the system design concepts and may even be a primary contributor to the design. The maintainer may not have the luxury of understanding the system design. For this reason, systems design should consider the use of tools for development and also the maintenance of the system.