Getting actionable data from an ICS
While industrial control systems (ICSs) will always need to provide functionality, there is an increasing focus on obtaining actionable data from automation platforms.
- See how programmable logic controllers (PLCs) and programmable automation controllers (PACs) need to do more than provide automation.
- Understand that designers should evaluate PLC and PAC in their abilities to handle data securely.
- Learn that structured data is an efficient way to model assets controlled or monitored by the PLC and PAC.
Any industrial control system (ICS) must run machinery and equipment the right way, day in and day out, to maximize productivity and ease of use. In today’s operating environment, though, that is no longer enough. Users want to gather data from all types of instrument and equipment sources so they can view, analyze and act. All aspects of data management have become integral to designing and deploying control systems.
Most new industrial automation devices are Ethernet-compatible, but this does not guarantee it will be easy or convenient to get at the data they gather and contain. This is due to the variety of data sources, frequently unstructured data formats and the nature of some protocols and automation devices, which can cause absence or loss of contextual information.
While designers are still finding it important to apply programmable logic controllers (PLCs) and programmable automation controllers (PACs) for their automation needs, they need to extend their evaluations to consider which platforms meet current and future data management and security needs.
Getting the right data to the consumer
Traditionally, many smaller plant-level and machine automation systems have used an architecture where a PLC/PAC is installed in the field, connected to classic I/O, and sometimes networked to intelligent devices. The PLC/PAC communicates with a local human machine interface (HMI) or a sitewide supervisory control and data acquisition (SCADA) system for visualization and alarming. Only larger systems would connect to higher-level operations or enterprise systems for more intensive data processing (Figure 1).
The drive for better data connectivity is due in part to a greater number of more capable data sources, and to the expanded flexibility of data destinations, especially cloud-based resources. Getting the right data to the right consumer is important and desirable for systems of all sizes—even individual machines or localized monitoring systems. Some examples of popular data consumers and Industrial Internet of Things (IIoT) applications include:
- Remote/mobile visualization
- Analytical applications
- Manufacturing execution systems (MES)
- Enterprise resource planning (ERP).
The functionalities needed to implement these applications have been improving. More PLCs/PACs support newer communication protocols, and some PLCs/PACs have advanced to the point where developers can create and preserve data structures, while keeping or enhancing context.
Modern fieldbus protocols—including EtherNet/IP, Profinet and IO-Link—can provide structured instrument and device data to PLCs/PACs. While older controllers might discard this type of structure, newer platforms can preserve or create it. This is important because ERP, MES and other high-level IIoT applications often work best when using structured data.
Overcoming unstructured obstacles to PLC controls
Unstructured and non-contextual data—essentially individual raw numbers without any scaling, engineering units, or other descriptive contextual information—has long been the norm, and it is still used by many local HMI and SCADA systems. This classic approach is workable, but it requires significant management effort up front and support to properly map and use the data as it travels from the source to the PLC/PAC to HMI/SCADA, and beyond.
Structured data embeds useful asset information for multiple associated data tags. This is true whether the data originates in one field instrument or if it’s organized as part of a PLC/PAC-based control scheme.
One example is an injection molding machine with a main drive, cutter drive and heater PID. A structured data hierarchy would include the variable speed drive (VSD) command and monitoring parameters, the temperature and other derived values, such as status, fault and energy information (Figure 2).
Developers find structured data is an efficient way to model assets controlled or monitored by the PLC/PAC, providing many benefits:
- Structured data can span from PLC/PAC to a variety of destinations, including HMI, SCADA, historian, MES, ERP and more.
- Developers can create logical hierarchies, modelling assets and their roles within a manufacturing facility.
- Users find it easier to work with standardized structures because these can be associated with human-readable asset names.
- Providing access to higher-level applications and even external users is simplified with universal asset models because it is not necessary to invest time reverse engineering data as it is transmitted through multiple architecture levels.
Of course, the organization offered by structured data and asset definitions does add some level of complexity, along with considerations for subsequent data access. But these and other concerns can be mitigated by providing improved security in the form of access controls. The benefits outweigh the complexities.
Structured data enables client applications—often associated with higher-level processing—to aggregate data, enrich information and compare results among assets of the same type even if they are located in many different places. End users approaching structured data for the first time will find it helpful to review the ISA-95 standard as a resource providing guidance for developing effective hierarchy models and for creating object definitions.
Security through PLC data structure
Modern PLCs/PACs incorporate a greater focus on data handling than traditional versions, and are gaining provisions for assigning which data structure values and properties are exposed to external clients and which remain internal to the PLC/PAC. This granular control allows the designer to assign data access to users based on the user role.
In addition to providing access control, developers can define data tags as “no access,” “read-only,” or “full-access.” This access can be defined one time at the structure level, and then applied to all created instances. Control of who can see what, and what actions can be taken by each person, provides a significant security improvement over older PLCs/PACs without such provisions and improve the proper handling of data between OT and IT (Figure 3).
Because PLCs/PACs have often acted as very localized standalone controllers, even more modern versions tend to handle security as a “local-only island” for managing user/client roles. Comprehensive role-based user/client access is almost always adopted by corporate IT, but most PLCs/PACs have limited or no integration with corporate security infrastructures. As the number of edge-based controllers and the amount of data being handled increases, local PLC/PAC security management becomes a greater burden.
Just as PLCs/PACs evolved from basic controllers into data processors, they will need to continue this evolution by providing integrated security functionality. The close integration of OT-based devices such as PLCs/PACs with IT-based security will consolidate management of these systems, but it will require a cooperative relationship between IT and OT groups.
Future PLCs/PACs emphasize data and security
PLC and PAC’s ability to control equipment in harsh environments is well established. In part, these capabilities have been delivered because PLC/PAC vendors have been slow to adopt new technologies unless the benefits improved performance. Traditional PLCs/PACs have a large installed base and continue to be specified for new work.
However, the expectations of today’s sophisticated users, their need to incorporate advanced manufacturing methods, and the accelerating risk due to cybersecurity threats have combined to change the business-as-usual approach for future work.
For retrofit and new projects, designers should evaluate PLC/PAC products for their data handling and security aspects. This task is easier because PLC/PAC innovations, including some that embrace modern IT open-source concepts, are giving designers better choices for their connected applications.
Keywords: data management, industrial control system
How are you using PLCs and PACs differently today compared to 10 years ago and what has the result been?