Setting internal automation standards
Companies, plants, and facilities require a set of internal standards, or best practices, for their automation systems’ hardware and software. These standards ensure consistency and safety, while providing clear guidelines for new projects. Although these internal standards will comply with industry regulations, they will be more specific to a company’s plant and facilities.
These standards should cover four key areas:
- Safety, electrical, and pneumatic
- Human-machine interfaces (HMIs) and operator interface terminals (OITs)
- Controllers and input/output (I/O) systems
- Sensors and instruments.
This article discusses these topics and suggest best practices to use, along with internal standards for each.
Safety, electrical, and pneumatic
Safety, electrical, and pneumatic standards are well defined by national and international agencies. Internal standards should include a list of applicable national and international standards, along with instructions about how to follow each closely.
Internal standards should require adherence to all applicable local and national codes, which should be listed and specified. These codes regulate the installation and operation of machines and equipment, vary from area to area, and often change over time. It is the responsibility of plant personnel to determine which codes should be followed-and to verify that equipment, installation, and operation complies with the latest revisions of these codes.
At a minimum in the U.S., internal standards must follow all applicable sections of NFPA 70-2017: National Electrical Code (NEC), National Fire Protection Association (NFPA), and National Electrical Manufacturer’s Association (NEMA). Other international codes may be applicable as well, particularly for OEMs manufacturing machines that will be shipped overseas.
NFPA 79-2018: Electrical Standard for Industrial Machinery is a good place to start for protecting operators, machinery, and facilities from electrical and fire hazards. Additional requirements may be available from regulatory or government offices. These offices can help determine which codes and standards are necessary for safe machine installation and operation.
If applicable codes and standards are not followed, serious injury to personnel or machine damage may occur. In the event of any incident, failure to adhere to national codes and standards can increase liability from a legal standpoint.
Internal standards must reference applicable standards, and this information must be made available to both internal and external personnel, such as engineers, machine builders, and system integrators. These standards also can be a functional basis for acceptance criteria on new projects to ensure proper product design, installation, and operation.
Listing and following applicable codes and standards are the first steps toward ensuring consistent and supportable automation on the plant floor. To ensure adherence to best practices, internal standards must cover HMIs, controllers, and field devices.
HMIs and OITs
The specification for HMIs and OITs should start with the operating conditions (see Figures 1 and 2). Requiring an operating temperature up to 122°F and minimum of NEMA 12 protection work well on most factory floors.
A company’s internal HMI and OIT specifications often will list a series of vendor-specific products acceptable for use. Sticking to this list of products will ensure consistency among applications, easing design, implementation, and operation.
Use cases for specific HMIs and OITs should be clearly defined. A micro touch text panel OIT can provide cost-effective graphics and operator interaction for small machines, but would not be suitable for medium to large machines, or for a production line. When it comes to graphically displaying every pushbutton, switch, meter, and peripheral device on an automated piece of equipment, display size matters. Therefore, internal standards should clearly state screen size requirements, along with a range of defining the appropriate number of screens for each type of application.
Screen design standards should be carefully defined. Common main, manual function, data, and fault screens—along with consistent navigation buttons—should be documented with actual application examples. Color usage and indicator functions also should be documented. Enforcing this standard so that it’s used on all machines and equipment will reduce training requirements, ease operation, and shorten troubleshooting time.
Specific HMI and OIT programming software should be included in the specification, along with a procedure to assure everyone is using the correct software, including the right revision.
HMIs and OITs connect to controllers, plant networks, and possibly the cloud. Internal standards should define acceptable hardware connections and communication protocols. Common hardware connections include Ethernet, RS-232C/422/485 serial, and USB. More than 10 different industrial Ethernet protocols are available for use, an unwieldy amount, so internal standards should define a smaller number of protocols acceptable for use. The same is true for serial protocols.
Limiting acceptable Ethernet protocols to a few common options, such as Ethernet/IP and Modbus TCP simplifies connections, but exceptions may be required. An example is when a specific machine is needed, but only provides communications via a protocol not specified in internal standards.
These exceptions can be handled by performing protocol conversion. Depending on the specific protocol to be converted, this can often be handled within a PC-based HMI. Specifying HMI software with these capabilities is a good design practice.
Remote access policies should be carefully considered and defined. Some HMIs allow remote users to connect, monitor, and control an HMI using a PC, laptop, smartphone, and/or laptop. If this access is to be allowed, a list of approved users, with levels of access for each, must be specified. Login procedures, multilevel access control, and program notification tags also should be carefully specified to provide the required level of cybersecurity.
Controllers and I/O
There are three main controller types for factory automation: programmable logic controllers (PLCs), programmable automation controllers (PACs), and industrial PCs, so a specific type should be designated. In some cases, a single vendor also may be specified, although some flexibility usually is required. Controller functionality is merging, so for many plants and facilities, specifying a single family of controllers from one vendor can cover most applications (see Figure 3).
A wide variety of I/O is available for each type of controller. Some I/O requirements to add to a standard include acceptable discrete voltage levels, analog signal levels, and specialty modules. A good standard for discrete signals is to use 24 Vdc or 120 Vac for both inputs and outputs. An analog signal level standard, such as 4-20 mA, also should be specified. Specialty items, such as resistance temperature detectors (RTDs), thermocouples, and weigh scale modules, also should be included in the standard.
Communication protocols and their standards should be documented for use with controllers as well. The protocol preference often is driven by the controller selected. With any controller chosen, it’s a good practice to include several communication ports, with Ethernet being the most important. It’s almost a must for future industrial Internet of Things (IIoT) and smart machine requirements.
As with HMIs and OITs, support for Ethernet communications enables remote access to controllers, requiring rules to be defined in internal standards. For example, one should not allow use of the default Internet protocol (IP) address or default gateway, but should instead require changing this factory setting. Internal standards should limit Web server functionality to read-only, and carefully define remote monitoring applications, account names, and passwords.
Defining remote access policies and enforcement are critical. Requiring remote access to controllers only through HMIs, which generally can provide more flexible levels of security and data access, also should be considered and defined in the internal standard.
Controller data-logging capabilities is another area requiring internal standardization. Definition of periodic or event-based data logging of tag values can provide important historical overall equipment effectiveness (OEE) and production information, and it can help buffer data for upper-level systems. Data transfer security also should be documented.
The internal standard for controllers should include application considerations. For example, the preferred connection to motion controllers or drives should be provided. Communication preferences as well as the need to control multiple drives at once should be made clear. High-speed communication methods to vision systems also should be defined. Again, both the communication method and the data handling requirements should be documented.
Controller programming standards are critical internal standards to define. Requirements and programming methods, along with examples, should be documented in a separate manual. Without these types of standards, each programmer may go his or her own way, creating an undecipherable collection of software applications.
Sensors and instruments
Sensor and instrumentation standards can help improve machine control and reduce required spares (see Figure 4). For example, a common internal standard is a requirement to provide an end-of-travel sensor on every cylinder or actuator. The preferred type of sensor and cable for different sensing applications should be a specified.
One of the main standards to define is the use of smart sensors and instruments. These smart field devices use a digital communication protocol to exchange data with controllers, and sometimes with HMIs or OITs. This data is in addition to the parameter being sensed. Smart field devices are more expensive than their simpler counterparts, so they should be used only when the extra data they provide can be used to improve operation.
As with HMIs, OITs, and controllers, acceptable communication protocols must be defined to prevent an unwieldy proliferation of incompatible protocols.
Having a different sensor vendor or type of sensor on each machine is not efficient for design, implementation, or support. Therefore, an acceptable short list of sensor and instrument vendors and types should be part of any internal standard.
Whether it’s an HMI, an OIT, a controller, or a field device, minimizing the number of vendors and communication protocols will lower costs, simplify training, and improve productivity. The time spent documenting the internal standards is well worth it in the long run to realize these benefits, and to improve safety.
Bill Dehner is a technical marketing engineer at AutomationDirect. He has spent the majority of his 11-year engineering career designing and installing industrial control systems for the oil & gas, power, and package handling industries.
– See other articles from the supplement below.