Fault Detection and Management System Broadcasts Motor Drive Faults
In medium and high-power systems, a multi-motor architecture is an effective approach to achieve a variety of objectives, including: higher total power level, scalability, modularity, redundancy, flexibility, and electronic gearing.
Megawatt-level applications can employ sub-megawatt motors and motor drive building blocks previously developed as stand-alone units and field-proven as mature products. Immediate benefits include reduced system development cost and faster time-to-market. A common building block allows for varying applications of different power levels, permitting the emergence of other important benefits like scalability and standardization. These aspects point to the numerous advantages that a multi-motor architecture offers to high-power applications. Fig. 1 shows an application example using three permanent magnet (PM) motor units to build a 1350 hp electric top-drive for gas/oil drilling rigs.
Multi-Motor Drive System
The building block of the multi-motor system consists of a 450 hp motor drive and a dual-airgap axial field PM motor. The motor and its drive are liquid cooled, and have a power density of about 1.8kW/kg. Initially developed as a stand-alone unit, the 450 hp motor drive features additional hardware and embedded routines to obtain scalable power by networking multiple motor units in master-slave architecture. The drive controller is equipped with two serial communication ports, one for multi-motor drive networking and the other for PC interfacing for online monitoring using Labview-based software.
When configured as multi-motor system, one motor unit acts as master, while other units are slaved. The master-slave communication is bidirectional, and implemented via an RS485 serial link. Apart from the commands specific to torque/speed control loops, the data traffic on the RS485 link includes information relevant to the fault-management subroutines running in each motor unit. The master broadcasts to all networked units; torque/speed commands, system status and operating-mode information. The master asks the slaves to sequentially provide feedback on their status to achieve proper response to faults at system level.
Fault Management
Technically speaking, the fault management (FM) algorithm is an embedded software module that runs in parallel with the motor control loops, and can command operation modifications to avoid system damage or to minimize impact onto the application objective.
A centralized FM scheme, where all faults report to the master unit, which then decides the appropriate response for each networked unit, isn't considered effective because:
- The flawless operation of the master-slave communication conditions the system to deal with faults.
- Fault processing speed limited by the baud rate of the master-slave link (115 kbaud) isn't sufficient for faults requiring immediate response action.
- Transmission of local faults, via RS485 link from motor units to master, reduces remaining space for control loop commands.
The implemented FM scheme (Fig. 2) is distributed so each networked unit is directly involved in deciding the response to its own faults. The faulted unit notifies the master unit, and updates a “health-index” system parameter broadcast to all units. The system health-index can trigger in each unit an emergency-stop, a soft-shutdown, or allow the unit to continue operation depending on its value (“OK,” “acceptable,” “bad,” or “critical”). In the eventuality of a faulty or broken master-slave communication link, the system is still able to handle faults. The isolated unit shuts itself down when detecting the absence or nonvalidity of messages. The master will simultaneously detect the absence of response from the isolated unit and send to all networked units an updated “health-index” triggering a pre-established shutdown sequence.
Hierarchically, the implemented FM scheme consists in a local fault management algorithm (residing in each unit) and a global one (at system level), as seen in Fig. 2, on page 40. You can find local and global fault management algorithms embedded in all units — master or slaves. Depending on the unit rank detected automatically at system start-up, only the master unit activates the global FM logic.
Local Fault Management
The logic behind the local FM is two-fold: one is basic logic (Tables 1 and 2, on page 40) based on the initial stand-alone developed motor unit, the other is supplementary logic (Tables 3 and 4) added to allow the unit to handle faults as part of a multi-motor system.
Fig. 3 shows the block diagram of the local FM responsible for processing local sensor data and fault signals generated by hardware. Whereas the later ones are Boolean values, the data from sensors requires adequate interpretation to detect potential functional problems. The basic results of this interpretation are software-generated warnings/faults added to the hardware-generated ones.
Accounting for the analog nature of sensor readings, you can use two thresholds for each sensed signal to distinguish if the measured variable is within the normal domain, warning domain or exceeding the maximum limit. A third threshold determines out-of-range measurements indicative of potential hardware problems along the sensing path. If the number of out-of-range events detected per-unit time interval exceeds a specified percentage, declare the sensing path “faulty.”
Next, you can pass the warnings and/or faults detected by hardware and software via a fault-masking block allowing the user to mask the fault signals individually, which could benefit the application objective. Then, input the filtered faults and warning signals to the decision-making block responsible for generating four decisions for the motor unit it manages
- E-stop.
- Soft-shutdown.
- Continue to run under modified control algorithm.
- Continue operation as normally.
The decision-making block of the local FM takes into account a global system parameter labeled “health-index” (see Table 4, on page 42) that's continuously updated by the global FM running in the master.
Finally, local FM reports all detected warnings and faults to an optional Labview interface, allowing the user to set the fault mask.
Global Fault Management
The global FM runs only in the master unit, and its logic relates to system-level aspects. Thus, it ensures the synchronization between the local fault-managers so all units react consistently to faults occurring in any arbitrary motor unit of the system. You can achieve this by the means of the system parameter called “health-index.”
Under normal circumstances, the system health-index shows the value “OK.” You can assume the two temperature sensors are faulty as per the sensor-data-interpretation module of an arbitrary slave unit (see Table 1, No. 19, on page 40). Within the faulted unit, the decision logic of local FM will trigger a soft-shutdown sequence (see Table 2, No. 2, on page 40). The master receives notification as soon as it polls that particular slave (the master polls each slave periodically at a fixed rate, about every 100 ms). Based on the faulted slave response, the global FM updates the value of system health-index to “bad” and broadcasts it immediately to all units (including the faulted one). Upon receiving the message
If you have multi-motor applications with motors mechanically coupled to the same load, you can configure the global FM to recognize faults or malfunctions of resolvers installed on motor shafts. This occurs because each slave unit sends its motor speed to the master. The global FM compares the speed from sensors with its own. A mismatch of 20% in speed values flags a resolver fault. Accordingly, the system health-index value updates to “critical,” then broadcasts simultaneously to all motor units, leading all local FM to trigger an emergency stop, which sends the entire system into an e-stop.
For more information on this article, CIRCLE 334 on Reader Service Card