Shishir Rege is a Technical Sales Specialist, Controls Architectures at Balluff Inc. He brings over 19 years of experience in applying robotics and industrial automation technologies in diverse industries including automotive, packaging, aerospace, and medical. Shishir enjoys sharing his knowledge and passion for automation to solve today's automation challenges.
As manufacturers move toward Industry 4.0 and the Industrial Internet of Things (IIoT), common communication platforms are needed to achieve the next level of efficiency boost. Using common communication platforms, like Time-Sensitive Networking (TSN), significantly reduces the burden of separate networks for IT and OT without compromising the separate requirements from both areas of the plant/enterprise.
TSN is the mother of all network protocols. It makes it possible to share the network bandwidth wisely by allocating rules of time sensitivity. For example, industrial motion control related communication, safety communication, general automation control communication (I/O), IT software communications, video surveillance communication, or Industrial vision system communication would need to be configured based on their time sensitivity priority so that the network of switches and communication gateways can effectively manage all the traffic without compromising service offerings.
If you are unfamiliar with TSN, you aren’t alone. Manufacturers are currently in the early adopter phase. User groups of all major industrial networking protocols such as ODVA (CIP and EtherNet/IP), PNO (for PROFINET and PROFISAFE), and CLPA (for CC-Link IE) are working toward incorporating TSN abilities in their respective network protocols. CC-Link IE Field has already released some of the products related to CC-Link IE Field TSN.
With TSN implementation, the current set of industrial protocols do not go away. If a machine uses today’s industrial protocols, it can continue to use that. TSN implementation has some gateway modules that would allow communicating the standard protocols while adding TSN to the facility.
While it would be optimal to have one universal protocol of communication across the plant floor, that is an unlikely scenario. Instead, we will continue to see TSN flavors of different protocols as each protocol has its own benefits of things it does the best. TSN allows for this co-existence of protocols on the same network.
IO-Link is a point-to-point communication standard [IEC61131-9]. It is basically a protocol for communicating information from end devices to the controller and back. The beauty of this protocol is that it does not require any specialized cabling. It uses the standard 3-pin sensor cable to communicate. Before IO-Link, each device needed a different cable and communication protocol. For example, measurement devices needed analog signals for communication and shielded cables; digital devices such as proximity sensors or photo eyes needed 2-pin/3-pin cables to communicate ON/OFF state; and any type of smart devices such as laser sensors needed both interfaces requiring multi-conductor cables. All of these requirements and communication was limited to signals.
With IO-Link all the devices communicate over a standard 3-pin (some devices would require 4/5 pin depending if they need separate power for actuation). And, instead of communicating signals, all these devices are communicating data. This provides a tremendous amount of flexibility in designing the controls architectures for the next generation machines.
IO-Link data communication can be divided into 3 parts:
Process data: This is the basic functionality of the sensor communicated over cyclical messages. For example, a measurement device communicating measurement values, not 4-20mA signals, but the engineering units of measurement.
Parameter data: This is a cyclic messaging data communication and where IO-Link really shines. Manufacturers can add significant value to their sensors in this area. Parameter data is communicated only when the controller wants to make changes to the sensor. Examples of this include changing the engineering units of measurement from inches to millimeters or feet, or changing the operational mode of a photoelectric sensor from through-beam to retro-reflective, or even collecting capacitance value from a capacitive sensor. There is no specific parameter data governed by the consortium — consortium only focuses on how this data is communicated.
Event data: This is where IO-Link helps out by troubleshooting and debugging issues. Event messages are generated by the sensor to inform the controller that something has changed or to convey critical information about the sensor itself. A good example would be when a photoeye lens gets cloudy or knocked out of alignment causing a significant decrease in the re-emitted light value and the sensor triggers an event indicating the probable failure. The other example is the sensor triggering an event to alert the control system of a high amperage spike or critical ambient temperatures. When to trigger these events can be scheduled through parameter data for that sensor.
Each and every IO-Link device on the market offers different configurations and are ideally suited for various purposes in the plant. If inventory optimization is the goal of the plant, the buyer should look for features in the IO-Link device that can function in different modes of operation such as a photo eye that can operate as through-beam or retro-reflective. On the other hand, if machine condition monitoring is the objective, then he should opt for sensors that can offer vibration and ambient temperature information along with the primary function.
In short, IO-Link communication offers tremendous benefits to operations. With options like auto-parameterization and cable standardization, IO-Link is a maintenance-friendly standard delivering major benefits across manufacturing.
While fieldbus solutions utilize sensors and devices with networking ability, they come with limitations. IO-Link provides one standard device level communication that is smart in nature and network independent. That enables interoperability throughout the controls pyramid, making it the most suitable choice for smart manufacturing.
IO-Link offers a cost effective solution to the problems. Here is how:
IO-Link uses data communication rather than signal communication. That means the communication is digital with 24V signal with high resistance to the electrical noise signals.
IO-Link offers three different communication modes: Process communication, Diagnostic communication (also known as configuration or parameter communication), and Events.
Process communication offers the measurement data for which the device or sensor is primarily selected. This communication is cyclical and continuous in nature similar to discrete I/O or analog communication.
Diagnostic communication is a messaging (acyclic) communication that is used to set up configuration parameters, receive error codes and diagnostic messages.
Event communication is also acyclic in nature and is how the device informs the controller about some significant event that the sensor or that device experienced.
IO-Link is point-to-point communication, so the devices communicate to the IO-Link master module, which acts as a gateway to the fieldbus or network systems or even standard TCP/IP communication system. So, depending on the field-bus/network used, the IO-Link master may change but all the IO-Link devices enjoy the freedom from the choice of network. Power is part of the IO-Link communication, so it does not require separate power port/drop on the devices.
Every open IO-Link master port offers expansion possibilities for future integration. For example, you could host an IO-Link RFID device or a barcode reader for machine access control as a part of a traceability improvement program.
As technology advances at a faster pace and the world becomes flatter, manufacturing operations are generally focused on efficient production to maximize profitability for the organization. In the new era of industrial automation and smart manufacturing, organizations are turning to data generated on their plant floors to make sound decisions about production and process improvements.
Smart manufacturing improvements can be divided roughly into six different segments: Predictive Analytics, Track and Trace, Error Proofing, Predictive Maintenance, Ease of Troubleshooting, and Remote Monitoring.To implement any or all of these improvements requires interoperable systems that can communicate effectively and sensors and devices with the ability to provide the data required to achieve the manufacturer’s goals. For example, if the goal is to have error free change-overs between production cycles, then feedback systems that include identification of change parts, measurements for machine alignment changes, or even point of use indication for operators may be required. Similarly, to implement predictive maintenance, systems require devices that provide alerts or information about their health or overall system health.
Traditional control system integration methods that rely heavily on discrete or analog (or both) modes of communication are limited to specific operations. For example, a 4-20mA measurement device would only communicate a signal between 4-20mA. When it goes beyond those limits there is a failure in communication, in the device or in the system. Identifying that failure requires manual intervention for debugging the problem and wastes precious time on the manufacturing floor.
The question then becomes, why not utilize only sensors and devices with networking ability such as a fieldbus node? This could solve the data and interoperability problems, but it isn’t an ideal solution:
Most fieldbuses do not integrate power and hence require devices to have separate power drops making the devices bulkier.
Multiple fieldbuses in the plant on different machines requires the devices to support multiple fieldbus/network protocols. This can be cost prohibitive, otherwise the manufacturer will need to stock all varieties of the same sensor.
Several of the commonly used fieldbuses have limitations on the number nodes you can add — in general 256 nodes is capacity for a subnet. Additional nodes requires new expensive switches and other hardware.
IO-Link provides one standard device level communication that is smart in nature and network independent, thus it enables interoperability throughout the controls pyramid making it the most suitable choice for smart manufacturing.
We will go over more specific details on why IO-Link is the best suited technology for smart manufacturing in next week’s blog.
In the first part of this series “Demystifying Class A and Class B Type IO-Link Ports” we discussed the two different types of IO-Link master ports and pointed out how they differ in operation and applications. The point of that blog was to ensure that when we choose one over the other, what is the opportunity cost of that decision.
In my recent blog, part #2 in this series, “Not all IO-Link Masters are Born Equal!“, we explored that even when multiple vendors provide or call out their IO-Link master, they are different in the implementation of features and functions they offer. IO-Link is IO-Link! It is a standard for communication but other features that accompany the communication differentiates how they behave; for example- sensor only master, hybrid master, and architecture backbone master.
In this blog, we will focus on various implementations of Port Type A (or Class A) and how they add varying degrees of value to your applications.
Implementation #1: Figure 1 below depicts the guts (electrical connections) of one of the three implementations of the IO-Link Class A master port. Two key things to notice here:
The power coming into the IO-Link master port is only device power. There is no output power with this implementation. The reason that it is designed like this is to only integrate sensor inputs.
Pin 1 and Pin 3 provide the device power and ground (common) to the IO-Link device, pin 4 is IO-Link communication. Pin 2 works as an input only for digital sensors like photo-eyes or prox switches. Basically, this port can be split to use one IO-Link sensor (pins 1, 3 and 4) and one standard ON/OFF sensor (pins 1,3, and 2).
Another alternate of this implementation is that some vendors may have another IO-Link connection on Pin 2. So, it serves to add 2 IO-Link devices off the same port. Unfortunately, I am not an expert to say whether this is according to the specification or not.
The Pros: Low power consumption and simplifies integrating smart sensors.
The Cons: By definition, a control system has both inputs and outputs – controlling “something” based on sensory inputs and logic. This implementation provides semi-standard implementation to the controls architecture. IO-Link promises unified communication across the plant floor not half of the plant floor. Characteristics of this type of master port would be max output current of about 250-300mA per port and about 2A per module (rated for up to 4A, if its carries UL).
Implementation #2: This implementation is a slight variation of the sensor only port (Implementation #1 above). It is achieved by adding an output capability for pin 2 on each port- shown in figure 2 below. It is important to note that although each port has output capability on pin 2, the output power is shared with the device power for the port. It implies that, in case of E-stop situations, where shutting off power to the valves/solenoids connected to pin 2 or an IO-Link device that requires an output power, the entire device power will be shut-off. Basically, the state of the device connected to pin 2 and state of IO-Link devices connected on pin 4 will be lost or requires more elaborate approach (programming, testing and validation) in the controls side to handling these types of safety situations.
This type of implementation is commonly found on hybrid IO-Link master’s Class A (type A) port implementation.
The Pros: Flexibility to use pin 2 for input or output – standardized approach to all devices.
The Cons: Lack of ability to control the output power separate from the device power – causing variety of controls approaches (lots of precautions) when incorporating machine safety.
Implementation #3: This implementation offers the most flexibility in designing the controls architecture that utilizes IO-Link. Figure 3 depicts the implementation below. In this case, the device power, as prior approaches, comes from pin 1 and pin 3 but pin 2 uses a separate power for output. The pin 2 on each of these ports can be used for input, output or to provide separate output power to the IO-Link devices. It is important to note that although pin 2 offers output power separate from the device power, the common/ground for this power is still tied to pin 3. The output power is separate but not isolated, like in the Class B port implementation discussed in the blog “Demystifying Class A and Class B Type IO-Link Ports“.
The two key advantages with this approach are: 1) High amperage output can be used from pin 2 to control valves or solenoids by splitting the port, and 2) IO-Link devices such as valve terminals or configurable I/O hubs that require output power can be connected with standard 4 pole cables without needing additional power cables or connectors.
This does appear very similar to implementation 2 where output power can be provided as well. The key difference is that since the output power comes from a different power line, it is not shared with the device power — as you know, amperage reduces when you have parallel circuits, so implementation 2 is subject to that principle whereas implementation #3 is not.
Another benefit with this approach is that a safety relay can be placed on the power going to pin 2 because the output power for the entire module is separate. That means in case of E-stop situations, the output power can be shut off without harming the device power. This eliminates the need for elaborated controls planning as the device state is maintained throughout the operation. After recovering from an E-stop, the valves and all other outputs go back to their original state. This significantly simplifies your controls architecture, offers standardized approach to cabling and provides unified interface for all devices.
To learn more about Balluff’s implementation of IO-Link masters please visit www.balluff.com.
IO-Link as a standard for device level communication has been around for over a decade. It has started gaining huge momentum in the Americas with 60-70% growth in IO-Link integration in 2017 alone (awaiting official numbers from the IO-Link consortium). Due to this huge market demand for IO-Link, there has been an insurgence of IO-Link masters with features and functionality that is dazzling machine builders and end users alike.
While IO-Link as a communication platform is a standard (IEC 61131-9), the added features and functions leave some machine builders confused on how to reap benefits of these different masters that are around. Some machine builders have a thought process of “Hey, vendor A is selling an IO-Link master and vendor B is also selling an IO-Link master – they are both IO-Link so, why should I pay more?” These machine builders are choosing the lower cost options without realizing what they are missing out on – and sometimes getting disgruntled about the technology itself. On the other hand, some machine builders are spending too much time in measuring and testing a variety of masters – wasting precious time and materials to identify what fits best for their solution. With this blog post and my next, I am hoping to add some clarity on how to detect differences quickly amongst the masters and make a decision that is best suitable for the applications at hand.
IO-Link started out as a standard of communications for smart sensors with a focus to eliminate variety of different interfaces on the plant floor- but since its inception it has manifested itself to be much more than simple sensor integration. It has also gained significance as a backbone for enabling Industry 4.0 or IIoT. So, let’s review different types of IO-Link masters.
The very first thing machine builders have to do is determine whether the IO-Link master should be IP20 (in cabinet) implementation or IP65-67-69 rated (machine mounted) implementation.
The machine mounted version makes sense as it is suitable for most industrial environments. The IP20 version may be desirable if the machine is operating in extreme environments or experiences continuous changes in temperature, humidity and other factors.
With machine mount masters:
It is easier to debug the system with onboard diagnostics availability
Eliminates wiring and terminates hassle and saves time and money during the machine building process.
If the IP20 master is your choice, then there isn’t a major difference between vendor A and vendor B IO-Link masters. The difference could appear based on whether the IO-Link master is a part of a larger system or stand-alone module connected to the machine controller through one of the fieldbus or network gateway. One more thing to note about IP20 masters is they are meant for connecting 3-pin IO-Link devices only. If you want to use architectural benefits of having added Vaux (separate output power) then using IP20 masters becomes complicated and quickly becomes expensive.
If the initial features of machine mounted masters are appealing to you, then there are a few more decisions to be made. The machine mounted IO-Link masters (for simplicity let’s call them IP67 Masters) range from “sensor only” integration capable masters to the ones that have the ability to become a backbone for flexible modular controls architecture. There are primarily three different types of masters as shown below in the chart and they differ based on the power routing capabilities and power handling capabilities.
Since the inception of the Class (or Type) A and Class (or Type) B ports in the IO-Link specifications, there have been several new IO-Link devices and IO-Link masters introduced to the market. This has caused a lot of confusion about when and where to use Class A and Class B IO-Link masters and devices.
Before getting into the details of Class A vs. Class B, I would like to address one question that I get asked quite often: are Class B master ports safety-rated? The answer is no. Just like any other network I/O modules (with the exception of the Safety I/O modules), any type of IO-Link master (whether it is Class A, Class B or mixed) is not safety rated. If the block is safety-rated, I am certain that the manufacturers of these blocks will kindly let you know. So, we just busted the first myth about Class B ports. Side note: the IO-Link Consortium just released a specification for IO-Link Safety. At the time of this posting (Oct. 2017), there are no IO-Link masters on the market that are safety rated, even when the IO-Link master ports exist alongside Safety I/O parts on the same block.
For IO-Link communication, only pins 1, 3 and 4 have significance. The implementations of pin 2 and 5 is where Class A and Class B ports differ and with that, the advantages and disadvantages of the uses for these ports.
Clearly, with the wiring diagrams above, a Class A port offers more flexibility in terms of additional I/O count and in some cases high-amperage outputs to drive high-current devices such as valves. We will discuss the detailed power routing and application flexibility of Class A ports in a later blog.
With Class B ports, Pin 2 and Pin 5 are tied to a separate power source and cannot really be used as I/O. Pin 5, the ground for output power, is separated from pin 3, the ground for device power. Actuation devices, such as valve banks, that are now offered on IO-Link could utilize separate output power that can be turned off through safety relays. Technically, this separation of power is possible with Class A ports as well, but it is inherent with Class B ports.
A word of caution when implementing I/O architectures with Class B masters: since the commons for device power and output power are isolated at the master, the power fed to this device should be isolated at the source as well to keep the isolation intact. That means, the power supplies feeding the power to these devices should be isolated.
Another question that I get asked frequently reveals another myth about Class B master ports: do Class B master ports offer any extra power than Class A ports? Again the answer is no. Class B does not mean extra power or the ability to provide more power. It simply means output power with isolated commons. What leads to that thinking is that on several IO-Link masters in the market, the outputs available on pin 2 of Type A ports have lower amperage ratings, because in most cases the output power is shared or drawn from the same source that feeds device power. There will be more discussion about this in my next blog!
A third interesting question is, can you plug Class A IO-Link devices into Class B master ports? In most cases there is no problem doing this as a true IO-Link Class A device is only a 3 pin device using pins 1,3, and 4 shown above. So as long as pin 2 of the device does not exist or is not being used for any purpose, it is possible to use Class A devices with Class B ports. Caution: several manufacturers make sensors that can be used in IO-Link mode as well as analog or digital mode and the implementation may have more than 3 pins. In these circumstances, you will need to use a 3-pole cable to keep the device unharmed or the pin 2 of the type B port that always has +24V going through may damage or disrupt the sensor.
Meanwhile, I hope this blog helped provide some clarity on Class A and Class B ports.
These days, there are several options to solve the integration problems with analog sensors such as measurement or temperature sensors. This blog explains the several options for analog integration and the “expected” benefits.
Before we describe the options, let’s get a few things cleared up. First, most controllers out there today do not understand analog at all: whenever a controller needs to record an analog value, an analog-to-digital converter is required. On the other end of the equation is the actual sensor measuring the physical property, such as distance, temperature, pressure, inclination, etc. This sensor, a transducer, converts the physical property into an analog signal. These days with the advanced technologies and with the cost of microprocessors going down, it is hard to find a pure analog device. This is because the piezo-electronics inside the sensor measures the true analog signal, but it is converted to a digital signal so that the microprocessor can synthesize it and convert it back to an analog signal. You can read more about this in a previous blog of mine “How Do I Make My Analog Sensor Less Complex?”
Now let’s review the options available:
The classical approach: an analog to digital converter card is installed inside the control cabinet next to the controller or a PLC. This card offers 2, 4, or even 8 channels of conversion from analog to digital so that the controller can process this information. The analog data can be a current measurement such as 0-20mA or 4-20mA, voltage measurement such as 0-10V, +5- -5V etc., or a temperature measurement such as PT100, PT1000, Type J, Type K and so on. Prior to networks or IO-Link, this was the only option available, so people did not realize the down-side of this implementation. The three major downsides are as follows:
Long sensor cable runs are required from the sensor all the way to the cabinet, and this required careful termination to ensure proper grounding and shielding.
There are no diagnostics available with this approach: it is always a brute-force method to determine whether the cable or the actual transducer/sensor has the issue. This causes longer down-times to troubleshoot problems and leads to a higher cost to maintain the architecture.
Every time a sensor needs to be replaced, the right tools have to be found (programming tools or a teaching sequence manual) to calibrate the new sensor before replacement. Again, this just added to the cost of downtime.
The network approach — As networks or fieldbuses gained popularity, the network-based analog modules emerged. The long cable runs became short double-ended pre-wired connectors, significantly reducing the wiring cost. But this solution added the cost of network node and an additional power drop. This approach did not solve the diagnostic problems (b) or the replacement problem above (c ). The cost of the network analog module was comparable to the analog card, so there was effectively no savings for end users in that area. As the number of power drops increase, in most cases, the power supply becomes bigger or more power supplies are required for the application.
The IO-Link sensor approach is a great approach to completely eliminate the analog hassle altogether. As I mentioned earlier, since the sensor already has a microprocessor that converts the signal to digital form for synthesis and signal stabilization, why not use that same digital data over a smarter communication to completely get rid of analog? In a nutshell, the data coming out of the sensor is no longer an analog value; instead it is a digital value of the actual result. So, now the controller can directly get the data in engineering units such as psi, bar, Celsius, Fahrenheit, meters, millimeters, and so on. NO MORE SCALING of data in the controller is necessary, there are no more worries of resolution, and best of all enhanced diagnostics are available with the sensor now. So, the sensor can alert the controller through IO-Link event data if it requires maintenance or if it is going out of commission soon. With this approach, the analog conversion card is replaced by the IO-Link gateway module which comes in 4-channels or 8 channels.
Just to recap about the IO-Link sensor:
IO-Link eliminated the analog cable hassle
IO-Link eliminated the resolution and scaling issue
IO-Link added enhanced diagnostics so that the end users can perform predictive maintenance instead of preventative maintenance.
The IO-Link gateway modules offers configuration and parameter server functionality that allows storing the sensor configuration data either at the IO-Link master port or in the controller so that when it is a time to replace the sensor, all that is required is finding the sensor with the same part number and plugging it in the same port — and the job is done! No more calibration required. Of course, don’t forget to turn on this functionality on the IO-Link master port.
Well, this raises two questions:
Where do I find IO-Link capable sensors? The answer is simple: the IO-Link consortium (www.IO-Link.com) has over 120 member companies that develop IO-Link devices. It is very likely that you will find the sensor in the IO-Link version. Want to use your existing sensor? Balluff offers some innovative solutions that will allow you bring your analog sensor over to IO-Link.
Balluff offers a broad portfolio of IO-Link that includes sensors, RFID, SmartLights, Valve connectors, I/O hubs, and the gateway modules for all the popular fieldbuses and networks. Learn more at www.balluff.com
In a previous post, 3 Smart Applications for Process Visualization, we discussed how the term “process visualization” has evolved since the introduction of the SmartLight. While it can definitely be used as a stack light, its additional modes can be applied for all sorts of different operation/ process visualization tasks. Below are a few more examples we’ve come across.
Use Case #4: Fill Level Status:
From micro-breweries to steel-mills and oil refineries, all have state-of-the art tack fill level detection systems measuring fill levels to the last millimeter or in some cases cubic inches. But when you want to take peek at the how much the reservoir is full at any given time- you have to go to the HMI in some corner to see that value. Nine times out of ten this fill indication provides you only with numerical value. What if SmartLight shows you the value visually using the level mode of operation? Then the decision to run another batch of bottle filling can be taken without going to that corner and punching some numbers. Additionally, the colors of the segments can be changed to indicate the temperature or pressure inside the tank or just different fill levels so the line supervisors can take decisions promptly on the next action.
Several times plants invest in huge TV monitors to provide a real-time visual feedback to their employees on how their operations are progressing compared to the quota assigned. At one plant, they found no increase in employee productivity with such investment because the TV monitors failed to provide a visual feedback. The television sets indicated 112/300 – which meant nothing to the operators. The SmartLight, however, provided them the feedback using the level mode of operation on how they are performing to the quota. The moment SmartLight turns yellow was an indication to the operator(s) that they are falling behind the level of the lighted LED indicated that they are closing the gap to their daily quota. If the operator notices problems with the batch of components or machine itself they could change the SmartLight to a run light mode with a push of a button indicating trouble in the workcell – the supervisor then can deploy the right maintenance person to the cell. Utilizing the SmartLight light not only provided instantaneous feedback on performance but also added efficiency in handling production issues.
In one automotive plant, the maintenance team designed an innovative solution with SmartLights for hazard communication. This plant has several automated guided vehicles (AGVs). The light indicators on these AGVs are the same type that was on the mast of most of the workcells in the plant. It was hard to notice when the AGVs were pulling out of and entering their parking stand. Maintenance engineers installed SmartLights on the mast of the AGV parking stand and with different color scheme and level mode indicated if the AGV is coming to stop or just starting the motion. This simple idea avoided daily occurrences of mishaps for the forklift drivers and operators.
With linear assembly process it can be difficult to detect bottlenecks in the production process. With increase complexity of today’s production flows the bottlenecks dynamically change under various conditions. Installing SmartLights programmed to change their mode of operation depending on certain conditions (on-demand change of mode) could help point out bottlenecks in the current environment. For example, these days the automation controllers are equipped to calculate its overall equipment effectiveness (OEE). That information can be directed to the SmartLight. A specified segment may turn green when OEE >80%, turns yellow when 60% < OEE < 80% and red if the OEE falls below 60%. Now, the plant supervisors can see the overall picture of the entire floor to make informed and timely decisions.
Use Case #8: Time Lapse Counter:
Wouldn’t it be nice to know how long it takes to replenish the stack of pallets in the robotic palletizing cell? Or how often the operator has to go into the cell (causing stop operations) for mis-fired sensor or dropped package? How about break-times for the operators? Well SmartLights can be used for all these types of operations. This can be done by changing the blinking frequency of the SmartLight segment, and changing the colors or modes of operations, a multitude of information can be displayed for various purposes.
These days almost every smart industrial device that comes to the market is advertised as “ready for IIoT.” But what does it actually mean? Before we get too technical, we should look at what the objectives are for IIoT and why it is important to the industrial age of our time.
In a previous post, “The promise of the Industrial Internet of Things (IIoT)“, we highlighted features such as Virtual IP address, to help address several things that plant maintenance and management would like to achieve. This blog touches those topics in a different perspective.
The concept of the Industrial Internet of Things (IIoT), or Industry 4.0, applies to the future of industrial automation, and these concepts heavily rely on the interoperability of a wide variety of devices and systems that communicate large amounts of data. This data is important because IIoT promises superior efficiency of machines and personalized manufacturing. Personalized manufacturing – also known as micro batch production or lot size one – means connecting with the customers at an individual level rather than connecting to masses. If efficiency and customization in production are the end goals or prime objectives for IIoT, these questions must be answered: What type of data would be necessary? Where and how is that data obtainable? In other words, what are the capabilities or characteristics of the device or system that really qualify as being “ready for IIoT”? Does simply providing an Ethernet connection to the device or adding a webserver qualify the device for IIoT? The answer is NO!
In my opinion, the following 5 key characteristics/capabilities, depending of course on the end user’s objectives, would qualify for being “ready for IIoT” tag.
If an end-user of automation wants to run the plant efficiently, the device or system should be able to provide information regarding; (1) Condition Monitoring, and (2) Automatic Parameterization
Condition Monitoring enables predictive maintenance and eliminates unplanned downtime. Is the PLC or automation controller the right place for determining predictive maintenance? Maybe not. The PLC should focus on making sure the system is running effectively. Adding more non-application related stuff to the PLC may disrupt what is truly important. In most cases you would need a different PC or server to do this pattern analysis throughout the plant. A system or device with the “ready for IIoT” tag should be able to collect and provide that information to a higher level controls system/server. An example would be a power supply with IO-Link. Through the IO-Link master it tells the system about the stress or ambient temperature and predicts its lifetime.
Automatic configuration or parameterization of sensors and systems. This feature enables plug-n-play benefit so that replacing devices is easy and the system automatically configures the replaced device to reduce downtime.
As IT and Controls Engineering work closer together, there are other characteristics of the devices that become important.
Configurability of sensors and production line beyond controller of the system: Automation controllers in use today have physical limits of memory and logic. Today manufacturers are running multiple batches of different products on the same line which means more change over and more downtime. If the devices could allow for quick line change configurations such as set point changes for your sensors, different pressures on fluids, different color detections for the parts or even the ability to provide you with detection of the physical format change, that would significantly reduce your changeover times. In a PLC or controller, you can only build logic for factors known today (for ex. the number of configurations), but in the near future there will be additional product configurations. To be truly ready for the IIoT, you need devices that can be configured (with proper authorizations) in multiple ways. A webserver might be one of the ways – but that also has its limitations. Simple Network Management Protocol (SNMP) is widely used with several of the network management software tools in the IT world. OPC UA is another open communication protocol in industrial space. JSON is a protocol for cloud interface among many others. A device that can offer connectivity, via SNMP, OPC UA, JSON or other such open formats, to connect to other network software tools to gather information or configuration would solve several of these challenges without burdening the existing PLC or controller logic. In other words, these types of interfaces can connect your machine directly to an MRP or similar enterprise-level system which would make production floors much more efficient for quick changeovers.
Capability for asset tracking, and quick troubleshooting: These features become important when there are hundreds of parameters changing and configurations evolving as your system becomes smarter and more efficient. To ensure right things are happening down the line, error-proofing your system becomes essential, and this involves additional information tracking. So the systems or solutions you choose should have these features.
Scalability for the future: This characteristic can be interpreted in many different ways. But, in this blog it refers to adding features and functions as the need arises and building in capability to adapt to these changes is needed so that you are not starting from scratch again when the business needs to evolve again.
So, as we move into this new era of manufacturing, it is important to understand what the “ready for IIoT” tag on the device you are investing in means, and how it is helping you become more efficient or helping you connect to your customer one-on-one. Using IIoT to implement an ‘Enable and Scale’ plan would be the best way to meet the ever-evolving needs for the plant floor.