Aa 18 02

A supplement to PLANT ControlENGINEERING Engineering and Control PLANT ENGINEERING Engineering magazines magazines

Affordable HMIs for any budget

Starting at only $98.00, you’re guaranteed the savings you need C-more micro HMIs starting at only:

: $98.00 (EA3-S3ML-RN)

®

C-more HMIs starting at:

C-more micro HMIs are perfect for small systems and cost-conscious applications.

With free programming software and a starting price of $98.00, these micro HMIs can provide the visibility and cost savings your project needs.

• NEW! Reduced price 3-inch non-touch and touch screen HMIs • 3-inch EA3 models have 12 selectable background colors while 4-inch, 6-inch, 8-inch and 10-inch models provide 32K color TFT displays • Serial communications on all panels, with USB and Ethernet options available • FREE C-more micro HMI programming software with simulator (EA-MG-PGMSW)

: $465.00

C-more HMIs provide the advanced (EA9-T7CL-R) functionality needed in more complex applications including animations, logic, math, alarming, remote accessibility (web server and mobile app) and a myriad of supported communication protocols.

• NEW! 10-inch widescreen and reduced price 15-inch base model available • 10-touch screen models offered with 7 different screen sizes supporting 64K colors • Serial communication, USB programming, and SD card slot for data logging/program backup on all panels; Ethernet, HDMI video, and audio output options available • C-more HMI programming software (EA9-PGMSW) $99.00

Research, price, buy at:

www.go2adc.com/cmore-micro www.go2adc.com/cmore

Order Today, Ships Today! * See our Web site for details and restrictions. © Copyright 2017 AutomationDirect, Cumming, GA USA. All rights reserved.

1-800-633-0405

the #1 value in automation

Contents A4 Setting internal automation standards Industry regulations aren’t specific enough, so internal standards are required to ensure consistency among automation system hardware and software installed in your plant or facility.

A9 Stopping industrial control system network threats

A4

Threats to the industrial control system (ICS) networks are at an all-time high because of an aging infrastructure, lack of security planning/design, and minimal focus to protect ICS assets.

A9

A14 Understanding the value of best practices The discipline required to follow standardized programming best practices can pay off in the long run.

C OMMENT In pursuit of best practices

T

Jack Smith Editor

he cover story in this issue of AppliedAutomation suggests that a company’s internal standards should transcend industry regulations because of their lack of specificity and consistency among automation systems. In doing so, the author compares these internal standards with best practices: “Companies, plants, and facilities require a set of internal standards, or best practices, for their automation systems’ hardware and software.” The article explains how 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; and sensors and instruments.

The second story in this issue talks about industrial control system (ICS) network threats and how to stop them. The author writes, “A detailed analysis of the infrastructure and operational aspects of

a business can provide great insight into the level of risk as well as identify potential countermeasures to protect key assets. This type of holistic approach should be taken to assure all aspects are considered in order to fully understand the actual level of risk posed to the production system. This includes the cyber and physical security, as well as the status of the system lifecycle.”

The third article in this issue is another bestpractices story. The author points out that sometimes professionals—in this case developers/programmers—who start a new job may not be used to following a best practices routine. According to the author, “What new programmers are likely to find after a few years on the job is that these standard practices deliver tangible results. As they adhere to the best practices that both their own organization and their customers’ companies require, they’ll begin to discover why standardized ways of doing things have value.”

ON THE COVER Human machine interfaces (HMIs), like this C-more HMI Touch Panel from AutomationDirect, should be easy to configure, install, and maintain in a variety of graphical user interface applications. Courtesy: AutomationDirect

Applied Automation February 2018

•

A3

A U T O M AT I O N B E S T P R A C T I C E S

Setting internal automation standards Industry regulations aren’t specific enough, so internal standards are required to ensure consistency among automation system hardware and software installed in your plant or facility.

By Bill Dehner

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 ompanies, plants, and facilities require a set codes may be applicable as well, particularly for OEMs of internal standards, or best practices, for manufacturing machines that will be shipped overseas. their automation systems’ hardware and softNFPA 79-2018: Electrical Standard for Industrial ware. These standards ensure consistency Machinery is a good place to start for protecting operaand safety, while providing clear guidelines for new projects. Although these internal stan- tors, machinery, and facilities from electrical and fire hazards. Additional requirements may be available from dards will comply with industry regulations, they will be regulatory or government offices. These offices can help more specific to a company’s plant and facilities. determine which codes and standards are necessary for These standards should cover four key areas: safe machine installation and operation.

If applicable codes and standards are • Safety, electrical, and pneumatic.

Internal standards must not followed, serious injury to personnel • Human-machine interfaces (HMIs) reference applicable or machine damage may occur. In the and operator interface terminals event of any incident, failure to adhere (OITs). standards, and this infor- to national codes and standards can • Controllers and input/output (I/O) increase liability from a legal standpoint. systems. mation must be made Internal standards must reference • Sensors and instruments. available to both internal applicable standards, and this information must be made available to both This article discusses these topics and and external personinternal and external personnel, such suggest best practices to use, along with nel, such as engineers, as engineers, machine builders, and internal standards for each. system integrators. These standards machine builders, and Safety, electrical, and pneumatic also can be a functional basis for system integrators. acceptance criteria on new projects Safety, electrical, and pneumatic stanto ensure proper product design, dards are well defined by national and installation, and operation. international agencies. Internal standards should include Listing and following applicable codes and standards a list of applicable national and international standards, are the first steps toward ensuring consistent and supalong with instructions about how to follow each closely. portable automation on the plant floor. To ensure adherInternal standards should require adherence to all ence to best practices, internal standards must cover applicable local and national codes, which should be HMIs, controllers, and field devices. listed and specified. These codes regulate the installation and operation of machines and equipment, vary HMIs and OITs from area to area, and often change over time. It is the responsibility of plant personnel to determine which The specification for HMIs and OITs should start with codes should be followed—and to verify that equipment, the operating conditions (see Figures 1 and 2). Requiring installation, and operation complies with the latest revian operating temperature up to 122°F and minimum of sions of these codes.

NEMA 12 protection work well on most factory floors.

AutomationDirect

C

A4 • February 2018

Applied Automation

Figure 1: Human machine interfaces (HMIs), like this C-more HMI Touch Panel from AutomationDirect, should be easy to configure, install, and maintain in a variety of graphical user interface applications. All graphics courtesy: AutomationDirect

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 costeffective 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.

Figure 2: Small operator interface terminals (OITs), such as this C-more Micro Touch Panel, provide less functionality than an HMI, but are less expensive and much more compact.

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

Applied Automation February 2018

•

A5

A U T O M AT I O N B E S T P R A C T I C E S

Figure 3: These Productivity programmable controllers from AutomationDirect come in several form factors, offering rack-based, micro-modular, or stackable hardware in the same family of controllers.

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,

A6 • February 2018

Applied Automation

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.

PLC WITH BUILT-IN VPN & FIREWALL

C SE

U

Y RIT

B

-IN T L UI

PFC Series Performance Class Controllers • VPN technology with IPsec and OpenVPN security protocols • IIoT-ready application security with SSL/TLS encryption • Firewall with whitelisting for increased network security www.wago.us/PLC-VPN

A U T O M AT I O N B E S T P R A C T I C E S

Figure 4: Limiting sensors to a few standardized types simplifies maintenance and reduces stocking requirements.

Sensors and Instruments Sensor and instrumentation standards can help improve machine control and reduce required spares (see Figure 4). For example, a com-

mon 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.

Jim Langhenry

Patrick Lynch

Co-Founder and Publisher, CFE Media jlanghenry@cfemedia.com

Director of Content Marketing Solutions plynch@cfetechnology.com

Paul Brouch

Co-Founder, CFE Media srourke@cfemedia.com

Director of Operations pbrouch@cfemedia.com

Trudy Kelly

Rick Ellis

Assistant to the Publisher

tkelly@cfemedia.com

Audience Management Director rellis@cfemedia.com

Kristen Nimmo

Michael Rotz

Marketing Manager knimmo@cfemedia.com

Print Production Manager mike.rotz@frycomm.com

Elena Moeller-Younger

NORTHEAST

Richard A. Groth Jr. 774-277-7266 Fax: 508-590-0432 rgroth@cfemedia.com SOUTHEAST

Karen Cira 704-523-5466 Fax: 630-214-4504 MIDWEST/EAST COAST

Jennifer Wafalosky 216-409-8314 jwafalosky@cfemedia.com WEST COAST, TX, OK

Tom Corcoran

Marketing Manager emyounger@cfemedia.com

215-275-6420 Fax: 484-631-0598 tcorcoran@cfemedia.com

CONTENT SPECIALISTS/EDITORIAL Jack Smith

Michael Smith

Editor 630-907-1622 jsmith@cfemedia.com

Creative Director msmith@cfemedia.com

Mark Hoske

Director of Research 631-320-0655 apelliccione@cfemedia.com

Amanda Pelliccione

Content Manager Mobile: 847-830-3215 mhoske@cfemedia.com

Bob Vavra

AppliedAutomation is published bimonthly by CFE Media and is mailed as a supplement with Control Engineering and Plant Engineering magazines.

Copyright 2018 by CFE Media LLC. All rights reserved. Editorial offices are located at 3010 Highland Parkway, Suite 325, Downers Grove, IL 60515. Phone 630-571-4070.

Content Manager 630-571-4070 x2212 bvavra@cfemedia.com

Emily Guenther Associate Content Manager 630-571-4070 x2220 eguenther@cfemedia.com

A8 • February 2018

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.

PUBLICATION SALES

PUBLICATION SERVICES 3010 Highland Parkway, Suite 325, Downers Grove, IL 60515 Phone: 630-571-4070 Fax: 630-214-4504 Email: customerservice@cfemedia.com

Steve Rourke

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.

Applied Automation

SPECIAL ACCOUNTS

Jerry Preston 480-396-9585 jpreston@cfemedia.com INSIDE SALES

Diane Houghton 508-298-9021 dhoughton@cfemedia.com INTERNATIONAL

Stuart Smith SSM Global Media Ltd. +44 208 464 5577 Fax: +44 208 464 5588 stuart.smith@ssm.co.uk

INDUSTRIAL NETWORK SECURITY

Stopping industrial control system network threats Threats to the industrial control system (ICS) networks are at an all-time high because of an aging infrastructure, lack of security planning/design, and minimal focus to protect ICS assets.

By Robbie Peoples

protocols facilitates easier connections with information technology (IT) or business systems. This sharing of data from the production system to the business system potentially can provide valuable business insight with minimal effort to collect and analyze the data. hreats to the industrial control system (ICS) netThese same features that have improved the lifework infrastructure continue to increase and cycles and made connectivity a snap can expose the the level of complexity is greater than ever vulnerabilities of ICS applications that are not designed before. The increased volume and sophisticaspecifically with security as a primary focus. ICS providtion of these attacks make an ICS an easy tarers typically publish recommended security practices get for perpetrators because of its aging infrastructure, that define a specific methodology to allow for connectlack of security planning/design, and minimal focus to ing to external systems, but ultimately the responsibility protect ICS assets. of deploying and maintaining a secure ICS network is A detailed analysis of the infrastructure and operacompletely upon the end user. Securing these networks tional aspects of a business can provide great insight to ensure production availability into the level of risk as well as and protection from a security identify potential countermeasures Both IT and ICS infrastructure concern should be a comprehento protect key assets. This type of sive business objective defined holistic approach should be taken use common networking and supported by management. to assure all aspects are considMany of the infrastructures ered in order to fully understand components, but they are deployed today do not follow the the actual level of risk posed to the very different when it comes National Institute of Standards production system. This includes and Technology (NIST) standard the cyber and physical security, as to maintenance, operation, Guide to Industrial Control System well as the status of the system Security, which is recognized lifecycle. To help discern the exact and security management. by the Department of Homeland level of risk, each element should Security. The Presidential Policy be evaluated thoroughly to underDirective: Critical Infrastructure Security and Resilience stand the design, operational, and maintenance differenc(PPD-21), proactively coordinates, strengthens, and es and to preserve the livelihood of production systems. maintains critical infrastructure that is vital to public ICS evolution safety, prosperity, and overall well-being.

Historically, ICS providers used proprietary hardware Managing IT and ICS infrastructure and/or software, which were physically isolated from external connections. Today, ICS uses commercial Both IT and ICS infrastructure use common networking off-the-shelf (COTS) components, standard operatcomponents, but they are very different when it comes ing systems, and common communication protocols. to maintenance, operation, and security management.

The move from proprietary systems to open technology The security goals of an IT business network and an ICS allows for the use of third-party hardware and software network are different concepts, but they are based on the components, which has helped drive the overall lifecycle same principles of confidentiality, integrity, and availability. costs of ICS down. In addition, the adoption of standard For IT, business owners are concerned mainly about common components and associated communication disclosure of intellectual property, and confidentiality is Cross Company

T

Applied Automation February 2018

•

A9

INDUSTRIAL NETWORK SECURITY the highest priority. Next, the integrity of the data is very important, and that is followed by network availability.

The ICS network has different priorities due to the critical nature of production system data. The dependence upon human interface requires the availability of the system to be the highest priority for the industrial sector.

The integrity of the data is also very vital; it is important to have accurate information. Confidentiality is not typically a major concern for industrial networks. These differences

“Risk”

is defined as the potential of gaining or losing something of value.

works due to their requirement of needing deterministic highly-available data. An example of standard IT security practices includes applying operating system patches, application updates, and server system upgrades. These are considered common practice in the IT world. However, on an ICS network, these actions can potentially have a very negative effect on the operations and associated components.

Other common IT practices, such as domain changes, virus scanner updates, anti-malware updates, router configuration changes, and port blocking strategies, are examples of actions that can be detrimental to ICS networks due to the critical nature of associated software, system components, and/or delivery of data. The deployment of any such change to an ICS network or associated components must be considered carefully and should be staged on a test system to analyze performance characteristics prior to deployment on an active production system.

In addition, special consideration of security practices must be taken to ensure the ICS network operation is not impeded. Identifying the correct approach and applying the most cost-effective risk mitigation solutions are critical to support business for both IT and ICS infrastructure.

The availability of ICS network requirements makes them much more sensitive to any minor changes within the production system.

Determine an accurate risk level in the system priority make the operation and security management aspects of the network drastically different.

While both systems use common components for infrastructure, the operation of IT and ICS networks are significantly different. Typically, IT network operations are initiated by users on an irregular basis, or as needed. The amount of traffic generated on the business network can be sporadic and unpredictable. The network components, such as servers, network devices, and computers, are removed or added to support business needs. Business system communication protocols are built around this type of operation and typically do not include any type of deterministic mechanism because of the sporadic data.

On the other hand, ICS networks require a very high level of availability to support continuous and uninterrupted production system requirements. These systems are designed to deliver data at a deterministic rate to allow for predictability and repeatability. ICS communication protocols support deterministic activities that capture timecritical events. These systems are designed to allow for high availability of critical data that is time-sensitive. The contrast in network operations of IT and ICS makes the implementation of security methods very different as well.

Standard IT “fixes” may harm an ICS IT typically deploys broad security countermeasures to help prevent cyber-attacks. However, most common IT security methods can have an adverse effect on ICS net-

A10 • February 2018

Applied Automation

Failure to assimilate the actual level of risk of an ICS network is due to a lack of awareness and understanding of all the potential vulnerabilities. Just like IT systems, the effort required to make an ICS network cyber-ready must be a comprehensive effort recognized by management to ensure the availability of the production systems.

Considering the sophistication of modern hackers, simply putting a firewall between the ICS and IT network is not enough protection to remove the risk.

“Risk” is defined as the potential of gaining or losing something of value. To fully understand the actual level of risk to a production system, one must evaluate all aspects that expose vulnerabilities, such as a loss in production, environmental harm, equipment damage, and/or human safety. This can include cyber, physical, and local interface vulnerabilities that are potentially threatening from internal, external, malicious, and unintentional incidents. All aspects of the ICS lifecycle must be defined to ensure all potential hazards are considered.

Risk can be introduced through multiple vulnerabilities in ICS infrastructure such as using legacy platforms, system architecture design, connectivity to external networks, wireless access points, and/or remote interface points. Generally, ICS are deployed much longer than standard IT systems, which can be attributed to costs, desire to avoid production outages to move to a newer system, as well as a lack of knowledge of associated risk with running legacy systems.

Iconic Since 1967

Delivering the Future in America for 50 Years Building on our 50-year reputation for delivering revolutionary innovation, Yaskawa America promises to maintain the culture that provides the products, processes and people that enable our customers to do what they do – better.

SYSTEM

Leading Innovation • Quality Products • Industry Knowledge • Personal Service • Custom Solutions

Yaskawa America, Inc.

Drives & Motion Division

1-800-YASKAWA

yaskawa.com

For more info: http://go.yaskawa-america.com/yai1134

INDUSTRIAL NETWORK SECURITY place much longer. Due to the high availability requirements of production systems, the change-over to a new system can be risky as well. It is likely that the new system will require reprogramming and the logic will need to be deciphered and/or compiled to a new language. This introduces the possibility of human error and could potentially have adverse effects on the production system.

The operator interface likely will look and operate different than the existing legacy system. Migrating from a legacy to a newer system can involve many aspects of detail logic specifications to define the safe operation, extensive testing, and operator training to fully qualify a production system. Full-scale replacement may take a period of years and include multiple complex phases to minimize the production both IT and outages. Management of an ICS lifecycle should include a comprehensive ICS infrastructures are roadmap that plans all of the cut-over details to minimize the amount of risk evolving continually and to the production system.

Another factor that contributes to potential vulnerabilities is a failure to design and/or maintain a secure ICS network, which may be the result of having multiple engineers responsible for a network for many years without proper security plans or procedures in place.

Alternatively, it can be a result of fast-track deployment of multiple projects, upgrades, or additions that have compromised security.

To successfully manage risk, companies must fully define exactly what is in place, understand where the ICS lifecycle is, and ensure they have a plan in place to maintain the production system from all possible vulnerabilities. These charters should be mandated by management to assure the livelihood of production system assets remains intact over the Threats to entire system lifecycle.

The unique threat to an ICS

Threats to both IT and ICS infrastructures are evolving continually and are becoming more difficult to are becoming more difMitigating risk and prevent, detect, and mitigate. The ICS protecting assets networks are challenging to secure ficult to prevent, detect, due to the critical nature of production Mitigating risk and identifying a requirements. Therefore, the techniholistic plan to protect business assets and mitigate. cians and engineers that oversee the requires a comprehensive assessICS infrastructure must have a more ment of all production system risks. stringent, planned, and disciplined approach to deploy Protection of assets should include layers of security and security methods. should not rely on a single piece of software or hardware Completely disconnecting the ICS network from Internet to minimize risk. The consequences of a compromised ICS connectivity still does not remove all associated risk. potentially can cause a loss of production, environmental External threats are obvious if connected to the Internet, harm, damage to processing equipment, and can comprobut internal threats have even more harmful potential than mise personal safety. external threats. These include both inside malicious actions Asset protection starts with direction from upper manand unintentional human error that can cause havoc on the agement to identify a proactive initiative and to assure ICS network. Threats to a production system include any the ICS is ready to handle evolving threats. A holistic plan and all aspects of the system’s ability to display accurate documents security tasks and procedures and outlines the run-time data continuously and uninterruptedly. layers of protection, mitigation procedures, and migration This includes the ability for operators to access desktop plans to cover the lifecycle of the ICS. Reaction to an incifunctions, local login permissions, and system ports and/or dent that compromises the production system should be a interfaces. The effort to physically and procedurally secure planned event that is clearly understood by all personnel, the automation system can be very extensive and timethus minimizing its impact. consuming. However, the only way to prevent common The migration plan should include a system roadmap system failures is to remove the ability for common users to minimize production outages and ensure a safe and to access these systems, which includes software, hardreliable system during the change-over period. As threats ware, and physical access as well. continue to become more complex in nature, it is highly The lack of planning and/or procedures to fully manrecommended to perform an audit of the protection layage both the security and lifecycle of the ICS represents ers annually to ensure they are not compromised. The the largest threat to ICS critical infrastructure in the U.S. risk factor will never be removed completely, but the asset Security can be compromised through digital networks or owners can take responsibility for the readiness of the prophysical aspects. However, operating on a legacy platform duction system by removing as much risk as possible. can be detrimental to the longevity of a production system.

Legacy hardware, software, and support for the system can Robbie Peoples is an integration manager at Cross be both sparse and expensive, if they are available at all.

Company Integrated Systems Group. This article originally Typically, IT systems are upgraded on a cycle of three appeared on Cross Company’s Innovative Controls blog. to five years, whereas production systems may remain in Cross Company is a CSIA member as of 9/14/2017.

A12 • February 2018

Applied Automation

ADVERTISEMENT

A

utomationDirect takes the best ideas from the consumer world to serve the industrial market. As a direct seller of industrial automation products for more than 20 years, AutomationDirect is a leader in the industry that offers many customer services not typical with traditional distributors.

The company created a print catalog, and later an online store that provides complete product information and pricing so customers can make informed decisions on their automation purchases quickly and independently.

AutomationDirect’ s products are practical, easy to use and offer a low cost of ownership. The company offers quality products at prices up to 50 percent lower than those of more traditional distributors. Most product programming software is free, requiring no initial or upgrade costs and no software maintenance contracts. Product offerings include programmable logic controllers (PLCs), alternating-current (AC) drives/motors, operator interface panels/human machine interface (HMI), power supplies, direct-current (DC) motors, sensors, push buttons, National Electrical Manufacturers Association (NEMA) enclosures, pneumatic supplies and more.

See videos on AutomationDirect’s YouTube channel: https://www.youtube.com/user/automationdirect

Customers can also obtain return authorizations online for quick and easy product returns or exchanges.

AutomationDirect’s phone technical support staff has garnered top honors in service from industry magazine readers 15 years in a row.

And, with tens of thousands of active customers, the company’s online technical forum taps into that knowledge base by encouraging peers to help each other with applications and other questions.

Other online help includes frequently asked questions, application examples and product selection guides.

They Guarantee It AutomationDirect’s corporate headquarters near Atlanta, Georgia

Award-Winning Services Satisfy Customers

AutomationDirect has always maintained a huge inventory, allowing them to ship 99.7 percent of orders complete the same day. They were among the first to offer free two-day shipping, available for any order over $49. Shipment confirmations and any backorder status and estimated delivery information are communicated electronically to keep you informed.

Their online store is one of the most exhaustive in the industry – all technical documentation can be downloaded free of charge, as well as software and firmware updates. Hundreds of instructional videos are available without registration. Online access to your account allows viewing and changing account information, viewing order history and making payments.

AutomationDirect wants you to be pleased with every order. That is why they offer 30-day moneyback guarantee on almost every product they sell, including software (see Terms and Conditions for certain exclusions).

sales@automationdirect.com 1-800-633-0405 • www.automationdirect.com

PROGRAMMING BEST PRACTICES

Understanding the value of best practices The discipline required to follow standardized programming best practices can pay off in the long run.

By Bryan Little

A Av a n c e o n

ccording to the Merriam-Webster dictionary, a “best practice” is “a procedure that has been shown by research and experience to produce optimal results and that is established or proposed as a standard suitable for widespread adoption.”

The important words in this definition are “experience” and “optimal results.” When developers build solutions following corporate best practices, they’ll follow proven designs established through experience for general program structure, user interface, and operation. If their organization’s standard best practices are already good, then following them will help the developers deliver the quality results their organizations demand.

But what about this thing called “optimal results?” How do standardized best practices provide them? The real answer lies in how they are implemented.

Implementing standardized best practices Many developers come to their jobs without exposure to standardized programming practices. When they start, they may feel they’re not being trusted, that being required to follow best practices is something of a slap in the face.

But most organizations with a commitment to excellence do indeed establish standard ways of doing things, as do their customers. A new developer is likely to encounter device-based best practices, equipment-based best practices, and procedural best practices. They may find themselves wondering what kind of over-regulated environment they’ve fallen into. It may all feel a little overwhelming and more than a little bit constraining.

What new programmers are likely to find after a few years on the job is that these standard practices deliver tangible results. As they adhere to the best practices that both their own organization and their customers’ companies require, they’ll begin to discover why standardized ways of doing things have value. Best practice

A14 • February 2018

Applied Automation

programming approaches help save time developing and implementing new software. They also make code reuse easier. If developers can recycle existing code for a new project, they can save considerable engineering time.

And time, as we all know, equals money.

Reaping benefits of programming best practices Many integrators will find that the real value of programming best practices is that they help build the confidence to go to different plants for the same customer and dive right in to fix or change things. If the programming best practices have been followed and routines have been designed according to the proper guidelines, they will know how the code is organized and how the results should act and look, even if they were not the original coders. Standardized practices make integrating new functionality easier and troubleshooting issues far less troublesome because they provide integrators guideposts for finding what they’re seeking in the code—especially when standardized, reliable documentation is one of the best practices being followed. The value for in-plant engineers is even greater: each time they return to their code, they’ll have the security of knowing exactly how things are being done, no matter which system they’re examining.

So here is the message to give new programmers: Best practices aren’t constraining, they’re liberating.

They allow developers working with existing systems to concentrate on achieving desired results rather than figuring out how the current system is implemented. They make new projects more likely to be able to reuse existing code. They provide a structure and process flow that makes program maintenance easier. They’re called “best practices” for a good reason.

It sounds a bit like a contradiction, but the constraints of best practices can actually set you free.

Bryan Little is a principal engineer and food leader specialist at Avanceon, providing support for food & beverage customers. He has been working in the world of integration for more than 20 years.

Byte Me! Go ahead...talk nerdy to us. We’ll byte back. That’s because our fieldbus cards and gateways can speak your language.

We can also eliminate all of your C++ or C# programming. That’s right...no special language needed! Finally, you can easily and dramatically reduce the startup time on conveyors, hoists, turntables and many other applications. So, keep your bus and leave the driving to us.

seweurodrive.com / 864-439-7537

Big ideas open up completely new perspectives.

We have taken another step towards mechatronic integration with the combination of the new g500 gearbox range and the Lenze Smart Motor. By using this single drive solution you will be able to cover a broad spectrum of applications and reduce the number of variants you need by up to 70%. Thanks to the excellent levels of energy efficiency and the long life expectancy, your machines will achieve more productivity with a maximum degree of reliability.

To learn more visit www.Lenze.com or come see us at: MODEX 2018, April 9-12 in Atlanta, GA – booth #B3163

As easy as that.