Six Things to Consider When You Get Down to the Network Details
July 11, 2013
It all comes down to the details. That’s as true for networking as it is for every other aspect of an automation project. Here are some tips for making sure the details are covered with your industrial network:
1. Keep a list. Networked devices have addresses. It is very important to keep a list that shows the assigned address, the product this address has been assigned to and the line/plant location where the product has been installed. It is very difficult to troubleshoot many systems because this basic information was not captured, leading to significant equipment downtime. Once installed, these devices need to be labeled accordingly since it is not uncommon to have several identical devices in close proximity. This information should also be part of any electrical and mechanical drawing.
2. Test to failure. When developing data collection / data passing applications (PLC to PLC, PC to PLC, etc.) using Ethernet, fieldbuses and especially proprietary networks, it is critical to test to the point of failure. These failure points can be associated with the number of Ethernet port connections, the size and frequency of data being managed, as well as data addressing in the PLC. The PLC addresses used in data collection, if not contiguous or near contiguous, can cause excess read / write cycles to the PLC. Some PLCs can only provide 'X' number of devices in one read. If that number is 1k (1024 devices) and you attempt to read the values of coils 250, 1400, 5000 and 6500 in one cycle, it can actually create four separate read requests. This results in performance issues and missing data. Think of the impact if you want to read 250 values! FMEA (Failure Modes and Effect Analysis) is a great tool to aid in trying to identify '"what can go wrong."
3. Be aware of security issues. You have to be constantly aware of the security aspects of your control network. Seek cooperation with the IT professionals; you likely have more overlap with office systems than you might know.
4. Avoid sub-networks. When selecting fieldbus or network architecture, avoid the use of sub-network systems or expandability features that require configuration of expansion modules or field devices separately from the PC or PLC. Subnet components add an additional burden for end-user support and complexity in software (re-tagging/programming) when the subnet I/O count or type changes.
5. Need network analyzer. When a system using a fieldbus / industrial network does not work as expected, somehow the network is always blamed: too slow, too many flipped bits due to EMC (electromagnetic compatibility) issues, etc. Without proper measuring equipment, a network troubleshooter won't stand a chance of disproving this. Make sure high-quality network analyzers are available, and the real root cause of the problems will show up very quickly: very often it is application software. A network engineer without a network analyzer is like an electrician without a multi-meter: clueless.
6. Everything's networked. Nothing is not in the network any more. When you implement a new project or a new system, the networking criteria are a critical consideration. Every device needs a communication port or ports, physical media, communication protocol and tools to configure, display, diagnose, analysis, etc.
Optimize food production with SEW-EURODRIVE’s hygienic, energy-efficient automation and drive solutions for precision, reliability, and sustainability.
George Reed, with the help of Factory Technologies, was looking to further automate the processes at its quarries and make Ignition an organization-wide standard.
Goodnight Midstream chose Ignition because it could fulfill several requirements: data mining and business intelligence work on the system backend; powerful Linux-based edge deployments...
In the automation world, the Purdue Model (also known as the Purdue reference model, Purdue network model, ISA 95, or the Automation Pyramid) is a well-known architectural framework...
