I should start by mentioning that Pepperl+Fuchs has the pleasure of working with automation engineers every day. They build incredible machines by reducing the most complex problems into a number of simpler tasks. Those tasks are automated, put in sequence, and at the end, they ship a machine that transforms raw material or small components into our everyday items. But, there is one aspect of such machines that is frequently overlooked: diagnostics.
The reason for taking shortcuts when designing a machine is easily understood. These well-designed systems operate at peak performance virtually all the time; for the sake of this discussion let's say with 98% uptime. And since a complex task is solved by combining simple steps in a linear fashion, each of which must be executed properly, there is just one way the raw material or subparts can move successfully through the system. Conversely, each simple step has many ways of failing. Combine many such small steps and the total number of possible failure cases increases quickly. This is the reason why failure mode analysis documents tend to be so complex. But when failures occur and machines stop producing, or even worse produce scrap, fast diagnostics is invaluable.
The root problem is that control engineers are asked to optimize the manufacturing process, the single path through the system that leads to success. After all, if she can increase the production rate of the machine from 98% to 99%, a lot more product can ship without using up any more time or raw material. Consequently, it is hard to justify spending a lot of energy, resources, or time on all those failure cases. I see this all the time and want to make this clearer by looking at the PLC logic necessary to implement an RFID system. Modern high-frequency-based RFID systems are incredibly reliable. A tag can be read thousands of times and always provide the same (i.e., correct) data. Setting up and interacting with an RFID system is essentially a three-step process:
- Basic setup -- This step includes assigning an IP address to an RFID controller that is part of an EtherNet/IP network, setting up certain internal timing parameters, and perhaps specifying the HF chip used within the RFID tag. Each of those steps is not difficult, and modern hardware offers a multitude of ways of doing this, including integrated Web pages and function keys and displays. In other words, engineers and installers have some kind of HMI available to easily do this as part of the construction process of the machine.
- Issuing a command -- Once the system has been set up, instructing it to read RFID tag data is equally as easy. A command and its parameters are sent from the PLC to the RFID controller using an industrial network. The controller takes over and shortly thereafter returns the desired data. The PLC knows that everything is OK because the response messages contain a status. And since there is just one way for an RFID controller to successfully perform the requested read operation, there is only one OK status. On the other hand, there are many possible fault cases that a good RFID controller has to consider. While they are each quite unlikely, they are still important and must be sent to the PLC.
- Evaluating the response -- While evaluating the response status is not difficult, the issue every programmer faces is that there is just one OK status but many possible Not OK responses. As a result, many PLC programmers will lump all Not OK responses into a single "system fault" message instead of processing each possible case separately. Again, in light of the fact that the RFID will almost never fail, this is efficient and understandable. Since it takes almost as much effort to program the logic for the Not OK cases as it takes the programmer to write the logic for the OK case, detailed diagnostics seem to provide poor return on investment as far as implementation and testing time is concerned.
With this in mind, it is understandable that PLC programmers working with RFID systems write great code for the process, but usually take the easy way out when it comes to diagnostics. Fortunately, new technology stands a chance to solve this dilemma by making detailed diagnostics as part of the PLC logic a thing of the past. The Cyber Physical Systems or CPS approach can be that solution.
Cyber Physical Systems and SmartBridge
If you've never heard about CPS you can easily find a lot of information by searching the Internet. You can also read a blog recently published by one of my colleagues ("What in the World Are Cyber-Physical Systems?"). In a nutshell, CPS are objects that bring the physical (i.e., hardware) together with the computational world. These days, CPS are frequently mentioned along with Industry 4.0, the next industrial revolution based on combining manufacturing hardware and network or web-based technologies.
To clarify how a CPS can simplify PLC logic, just imagine what it would be like to have full RFID system diagnostics without the need to write any PLC logic. Instead of considering all possible status response messages and writing the appropriate PLC logic, the PLC programmer only worries about the "good" case of reading data. All other situations are, as is done in most cases right now anyway, lumped into a Not OK message that will then be displayed on the machine's HMI and sent as a message to a smart phone or tablet device.
CPS come into play via a new highly visual user interface on a smart phone or tablet device. The tablet utilizes a diagnostics visualization app designed and provided by the RFID hardware manufacturer. Using this approach essentially moves the responsibility of designing diagnostics code from the PLC programmer to the manufacturer of the RFID system. And because the RFID hardware manufacturer has to do this work just one time, they will spend the resources necessary to provide detailed help for the user. Additionally, the technical support personnel at the RFID supplier will be familiar with the data provided by this method, making its interpretation simpler. This speeds up phone support in the rare case this is even necessary. When the PLC identifies a problem, maintenance simply looks at the data provided on the tablet.
Clearly, there are many devices that already have web pages designed to provide diagnostic information, but this approach is limited to higher-level end devices and cannot be applied to simple or small sensors. In addition to the prohibitive expense of adding a web interface to a low-cost item, more practical considerations, like the need to integrate an additional connector, have to be considered. As powerful as a web browser approach may be, it is most likely not going to be the universal solution we are looking for. There has to be a better way, and Pepperl+Fuchs' SmartBridge has all the right ingredients to become the solution of the future. Today, SmartBridge is not a product in the sense that customers can buy and use it. It is an advanced design and implementation study first introduced to the engineering community at the 2013 SPS/IPC Drives show in Nuremberg. The idea behind SmartBridge is to give network visibility to all sorts of automation products, from simple sensors to more complex analog transducers, automation light grids, and RFID systems. SmartBridge is one of those ideas that, once you have read about it, you wonder why it was not conceived earlier. For more detail on how our SmartBridge study works, keep following this blog. There will be more soon.
Getting back to the issue of better diagnostics, in the case of an RFID system, SmartBridge allows maintenance personnel to use ultra-portable devices to get detailed fault diagnostics. Consider the case of a severed cable between the RFID controller and R/W head. In the case of the Pepperl+Fuchs' IDENTControl solution, this results in a response status with value 0x06. The PLC simply reports that 'something is not right with the controller at line location "unload part".' Armed with this information, maintenance activates the SmartBridge app on a supported tablet. Right away, the app reports that the R/W head is not communicating and offers possible reasons (cable disconnected or cut, damaged R/W head...). And since the SmartBridge knows which R/W head was present, it offers to connect to the Pepperl+Fuchs web site and download the proper data sheet for additional details. And this is just the beginning. Clearly, treating the RFID system as a CPS has the ability to simplify and reduce PLC while adding diagnostic features that were simply not possible before.