Avoiding SCADA Pitfalls: 3 Tips for Operational and Business Advantages

Implementing a well-designed supervisory control and data acquisition (SCADA) system in an automation setup can reduce operating expenses, increase throughput, and enhance usability. The design process can be tricky, with pitfalls on both the operations and business sides. To navigate through these common mistakes and deploy the most efficient SCADA system, thorough architectural planning should occur at the very beginning of the project.

 

Figure 1. SCADA controls the flow of information between all components of the automation system. At the heart of this SCADA system is the Ignition Server by Inductive Automation

 

On the Operations Side

There are three problems that most commonly plague the operations side of SCADA planning.

• Lack of data standardizations
• Little focus on user experience (UX) or user interface (UI)
• Improper integration of information technology (IT) and operational technology (OT)

These issues lead to a harder installation and deployment of hardware components, delays in coding, and wreak havoc on engineers and technicians attempting to troubleshoot the system.

 

Lack of Data Standardizations

Large, complex automation projects require integration across multiple sensors, actuators, machines, data centers, and control systems. Often, each of these pieces has different needs, data output formats, control signals, and connectivity requirements, and in some cases, they have different manufacturers entirely.

There is often a temptation to “divide and conquer”, meaning to assign integration tasks to each cluster of equipment, defaulting to the people who know that cluster the best. At a glance, this looks like an effective strategy: put the experts from each device on the task of integrating that device with the rest of the system. However, without a common theme between these parts and a standardized set of data, the project will be filled with delays and headaches. If groups are working independently of one another, a seemingly near-complete project would be halted if it is discovered that none of the datasets are compatible.

The need to standardize data modeling is at the heart of this standardization problem. Data from different sources, such as PLCs and other control hardware from various manufacturers, must integrate with an established data standard before the SCADA system can be fully designed. Several organizations, such as the OPC Foundation, are working towards developing these standards, but the end designer must ultimately choose how to implement them.

The design approach could be better modified to “standardize, divide, and conquer.” The vision of the completed system and how the data will be used should be determined early, at the forefront of the development of each system. While minor hiccups may still be present during final integration, the bulk of the work will already be completed and usable.

 

Little Focus on UX/UI

A frustration that arises is when engineers roll out a new solution without first consulting the operators, ensuring their buy-in, and confirming they are equipped to operate the new version effectively. In many cases, programmers develop what they think is an intuitive UX/UI, only to find that the operators cannot navigate it efficiently.

Instead of the integration engineers rolling out a new SCADA design scheme, they should bring operators into the process early on. This gives them a seat at the table and allows them to sign off on some of the changes to ensure that the new SCADA design will benefit them rather than work against them.

Another solution to this problem is to develop documentation and training procedures while developing the UX/UI. Typically, training and documentation are tacked onto a project as an afterthought. This does not set operators up for success and will only steepen the learning curve for using the new SCADA design.

To bridge the gap between the engineer’s view on design and the operator’s use of UX/UI, some companies are turning to consultants to improve this integration. The consultants leverage their knowledge of other projects, as well as trends in UX/UI, improving accessibility across all employees and even bringing psychological factors into the design. Furthermore, the UX/UI can be made compatible across multiple platforms, from smart screens to tablets to phones.

 

Shadow IT - Not Integrating IT and OT

In many cases, the IT decision-makers and the OT decision-makers are also on different pages. For example, OT and hardware experts might add a new controller without checking with the IT team to ensure that it remains safe from cyberattacks. On the other hand, IT professionals may roll out a new security patch, only to find it is not compatible with a legacy device downstream.

To combat these issues, both IT and OT need to be represented early in the design process. Not only should they be present, but they should also both be helping to develop change management procedures from both the hardware and software sides of the new SCADA system. This way, there is a well-documented procedure to follow for iterative designs, security patches, and process expansions without the need to redesign the entire automation system.

 

Figure 2. The best SCADA implementation considers both business and operational priorities. Image used courtesy of Adobe Stock

 

On the Business Side

From the operations side, it seems like more planning is always a good thing; to some extent, that is true. However, unless that planning is targeted and direct, the idea will never leave the drawing board. Three common business problems can prevent the success of a SCADA system implementation, while it may have looked good on paper:

• Feature creep
• Lack of foresight in planning
• Overplanning

 

Feature Creep

Feature creep is the temptation to keep adding more components, complicating the design while it is being constructed. At first, feature creep starts innocently enough; a forgotten sensor, or a request for a controller that has a little more capability. If this is allowed to continue, eight temperature sensors suddenly become eighty, the agreed-upon data standardization no longer works, and the whole project becomes unworkable very quickly.

To avoid this, developers should remember that they are building the starting piece and that iterative design can always add complexity later as the system grows. This allows for a much more organized approach to adding capability to the entire system, versus a hap-hazard growth pattern.

As soon as the SCADA system is being developed, developers should take notes on features they think might be a good fit for the next upgrade. In this case, developers should examine each potential new feature on a scale of “need,” “want,” or “nice-to-have.” The needs should be included, and then a table of pros and cons can be created for each item in the wants or nice-to-have categories.

 

Lack of Foresight in Planning

Another issue that arises during the planning phase is failing to plan for expansion. Sometimes this is the result of feature creep, where a project has grown beyond reasonable expectations. To reduce initial costs, components are cut and systems are downgraded to reach a reasonable budget. This SCADA design may meet today’s needs but has no inroads for tomorrow’s.

One method to avoid this issue is to build in expansion based on expected market growth. While this can be difficult to forecast, it can be approximated. Perform a cost-benefit analysis: if the market expands by 10% over the next five years, will the expansion be necessary and will it yield a positive ROI?

Relatively simple ways to plan for the future are by using expandable modules for control systems. The cost difference between a four-slot chassis and an eight-slot chassis is often small; buying an expandable model will allow for expansion, with reduced costs and integration time. The same goes for buying modules with higher channel counts. Perhaps today only eight channels are needed, but the cost to upgrade to sixteen channels may be worth the price.

Finally, complete documentation throughout the process will make the next iteration easier to deploy.

 

Overplanning

There is a drive to make the first SCADA design be the final iteration, a perfect system capable of doing everything it needs to do for now and for the future. However, this overplanning means designs become too expensive to implement and waste too much time, such that they never leave the design phase.

The key is to remember that design is not a one-time affair, but rather an iterative process. As the first version of the system is used, there will be new feedback from operators and engineers that can be incorporated into the next version. Market needs and product regulations may change and dictate new directions for sensors that could not have been anticipated in the early stages of design.

One thing designers can do to encourage this iterative design is to standardize a means of receiving and tracking feedback from all users of the system.

 

Figure 3. An example of the Ignition SCADA interface by Inductive Automation

 

Integrating the Advantages

It’s a balancing act: underplanning and overplanning are both to be avoided. Under-planning leads to inefficient systems, operators bypassing “features” to get the job done, and allowing no room for growth. Overplanning leads to bulky, expensive systems that often never leave the drawing board.

The point is to walk the line between under-planning and overplanning, gathering as many details as possible at the beginning of the project but then accepting that the first draft of the SCADA design will not be perfect forever.

Ultimately, SCADA is not just about today’s business needs. It is the foundation for transforming data collection and process control into the digital world. Digitization of this data is essential for Industry 4.0- combining IT and OT, predictive maintenance, and leveraging machine learning (ML) and artificial intelligence (AI). A well-designed SCADA system is a way to build forward, not just address the current pain points.

 

Take Action

Overwhelming? It doesn’t have to be. The best way to navigate the challenges of a new SCADA design is to partner with experts who have designed other systems. They can help you avoid the pitfalls and integrate the advantages for a successful SCADA deployment.

Inductive Automation has been designing SCADA software solutions for over 20 years and has worked with many industries and markets in over 140 countries. Their guidance can make the difference between a well-planned, efficient automation system and a cumbersome, expensive headache. For more information on designing effective SCADA systems, visit the Inductive Automation website. Contact their team of experts at [email protected] or call 1-800-266-7798 to discuss the specific needs for your next SCADA project.