Machine Diagnostics for IIoT Applications

The use of electronics within manufacturing industries has taken a huge leap forward in recent years thanks mainly to smart manufacturing initiatives such as Industry 4.0 led by the German government. The industry momentum resulting from the Internet of Things (IoT) has also had a significant influence on manufacturing automation. Indeed, the adoption of the phrase Industrial IoT, or IIoT, pays respect to the basic concepts of the IoT being highly relevant for the masses of data collection and analysis that the control aspects of any smart factory implementation needs. In many ways IIoT has been heralded as a connectivity and control approach more immediately able to deliver productivity and profit benefits than other IoT-based projects.

Industrial automation systems have been implemented in factories since the early 2000s. At that stage a number of proprietary communications protocols and network topologies were used to connect automation equipment together. This resulted little in the way of manufacturer interoperability, and tied a factory's implementation to potentially one vendor. Alongside this, Ethernet had become the network protocol in the world of IT although a number of shortcomings made its application in factory automation projects limited.

The primary challenge with standard Ethernet is that the MAC layer is not able to support real-time low latency data transfers. Designed for the transfer of large amounts of information across an enterprise network, the protocol is not suitable for moving the relatively small amounts of information needed for industrial control. For example, controlling a valve requires very little information to make it turn and for a sensor to report its current open/closed status. The other aspect of this is that, with Ethernet, control of the network is down to the devices attached to it, thus making it hard to predict when something will transfer. This, for a time-critical manufacturing process, is a major concern.

Control of manufacturing robots, valves, actuators etc., must take place in a deterministic manner. Diagnostics of the automation equipment in operation also requires a very deterministic response within the control instruction process such that an operation can be immediately halted before any other instruction is executed. It should also be noted that the focus of diagnostics is not only on the operation of the controlled device, such as a motor, actuator or valve, but of the network and associated network hardware too. German manufacturer Beckhoff had seen the wide adoption potential for Ethernet and developed its own Fieldbus protocol in order to correct the low bandwidth and deterministic nature within the standard Ethernet. This became known as EtherCAT^® (Ethernet for Control Automation Technology) and is now an open standard and has become adopted by many thousands of automation equipment suppliers.

Figure 1: Typical EtherCAT Master/Slave arrangement

The EtherCAT topology is that of a Master/Slave configuration and no special hardware is required for the Master device, a standard PC is suitable. An example of the Master/Slave configuration is illustrated in Figure 1. The protocol has a "processing on the fly" approach, which allows each node on the network to read the data as it passes through to the next node. A star topology also has a built-in redundancy that compensates for potential breaks in wiring, something that, from a diagnostic perspective, can be reported to the EtherCAT Master. Figure 2 shows an example EtherCAT slave configuration. Also, with the emphasis on timing and a deterministic behavior, EtherCAT conforms to the IEEE 1588 Precision Time Protocol standard and has a low jitter rate. Time stamping of each data frame by both the Master on sending, and by the slave on receipt, allows the Master to calibrate itself to know precisely the likely time to send a message to a slave device. The propagation of EtherCAT frames through the slaves takes place in a distinctive order, providing output/control data but also collecting input data prior to returning to the master. At the end of each EtherCAT datagram is a 16-bit counter called the Working Counter that allows detection of errors such as to whether a slave has read the data correctly and whether it was able to write data, highlighting errors to the master to take appropriate action. This provides an in-built diagnostic capability for the data communication and slave operation. At a diagnostic level, an example of the working counter would be immediately to stop a multi-axis motor motion controller should the slave controller of one of the axes not respond with its correct value response. Another example is the failure of clock synchronization in a slave resulting in the loss of real-time deterministic behavior across the process. The working counter will also indicate loss of a group of slaves, perhaps due to a network cable failure or a power failure to a major piece of machinery. A slave will always give a response in a datagram so their loss will enable the master to flag the problem.

Figure 2: Example EtherCAT Slave configuration

EtherCAT slave devices are available as a single-chip solution that incorporates both a microprocessor, or an FPGA, and an EtherCAT slave controller, or by incorporating a dedicated slave controller into the existing design. Both have relative merits, depending on the application requirement, but a single-chip solution tends to be more board space efficient and have a lower bill of materials cost.

An example of a stand-alone EtherCAT slave controller is the LAN9252 from Microchip. Providing dual 10/100 Ethernet transceivers, wake-up on LAN and standalone digital I/O interfaces, it can be easily interfaced to most embedded microcontrollers or microprocessors. Targeted at a broad range of motor motion control and hydraulic and pneumatic valve systems, it also features network cable support. Figure 3 illustrates the block diagram of the LAN9252.

Figure 3: Microchip LAN9252 internal block diagram

The parallel interface provides access to the host MCU/MPU bus and also to available GPIO and serial peripheral interfaces. These can be used to implement machinery diagnostics in conjunction with the host but it is more likely this would be undertaken from the host. The LAN9252 also features a cable diagnostic function that has two modes of operation: Time Domain Reflectometry (TDR) and Matched Cable Diagnostics. The TDR mode enables the detection of open or short circuit cabling on the TX or RX pair in addition to cable length estimation to the fault. The matched cable diagnostics provides cable length to fault estimation up to 120 meters. A full technical explanation of this technique is available within the LAN9252 datasheet.

A comprehensive evaluation kit is available for the Microchip LAN9252 – EVB-LAN9252-HBI. See Figure 4.

Figure 4: Microchip LAN9252 evaluation board

The eval board provides full access to the LAN9252's capabilities, in particular the host bus interface and GPIO, and uses an on-board Microchip PIC32 microcontroller as the host.

An example of a single-chip SoC EtherCAT slave is the XMC4800 series from Infineon. Featuring an ARM® Cortex®-M4 with floating point unit running up to 144 MHz, Flash and on-chip RAM, a high resolution PWM channel and supporting up to six serial channels, EtherCAT slave and a host of ADC/DAC analog I/O the XMC4800 is truly a single-chip solution. Figure 5 highlights the XMC4800 block diagram.

Figure 5: Infineon XMC4800 block diagram

The series of devices targets mid- to higher-end industrial automation and control applications. In addition to the EtherCAT capability, the inclusion of 4 and 8 channel PWM timers makes it suitable for motor control applications such as illustrated in Figure 6.

Figure 6: Infineon dual motor control with XMC4800

The XMC4800, with its plethora of GPIO and serial peripheral capabilities, is ideal for interfacing to a range of diagnostic sensors associated with the controlled machinery. Temperature sensors, vibration detectors and safety interlock and limit switches are easily incorporated into an end-design in order to provide monitoring of the equipment, ensuring the confidence of reliable operation.

Provisioning an EtherCAT Slave controller capability coupled with enhanced IO features without the need to depend on the resources of a host CPU is the TMC8460 from Trinamic. Targeting motor motion control applications, this device incorporates PWM and Step/Dir IO peripherals that do not need to be routed through the firmware of a host MCU, thus significantly reducing the datagram to control latency and suiting applications where as close as possible to a real-time operation is required. Adding a set of comprehensive peripherals accessible from either the MCU or the EtherCAT Master, the 8460 includes a stand-alone mode that allows direct mapping of integrated peripherals to bus registers. Figure 7 shows a schematic of the TMC8460 operating using the I/O block mode, which reduces the software overhead and provides real-time hardware support to the host MCU.

Figure 7: TMC8460 in I/O block mode

Incorporating equipment diagnostic monitoring data using the TMC8460's register sets accessible by the EtherCAT Master would provide near-real-time response to equipment failure or faults, and in extreme cases provide a method of halting the whole operation with a minimum of equipment damage.

The ability to maintain production assets operating reliably, with the minimum of downtime, requires real-time monitoring of the complete manufacturing facility at all levels. The devices mentioned in this article together with associated sensors provide the capability to achieve this for the machines themselves and all aspects of the EtherCAT network connecting them. In addition, software tools can provide a deeper analysis of the operation of the EtherCAT network and the slaves. At a higher level, diagnostics form a fundamental component of maintain, repair and operate (MRO) disciplines under which many manufacturers using capital-intensive production assets function. The initial concepts of machine-to-machine communication and the IoT stem from the automation of many MRO functions, and today IIoT will help to drive smart factory initiatives even further.