I will start by stating that I am not 100% familiar with these types of systems [Fiber Optic Light Detecting]. In recent MV switchgear submittal the manufacturer [I assume at the recommendation of the engineer of record and or the owner] included a fiber optic light detection system for arc flash mitigation. This included “point source detection� at the terminations in addition to “linear fiber optic detection� in the breaker cubicles at the runbacks / breaker connections. In discussing with multiple manufactures of these types of systems and colleges. The way I understand is that when the fiber optic system detects the light emitted during the early stages of an event and triggers the relay trip circuit to operate the breaker. Most of the literature from manufactures indicates a lower category of PPE required due to the increased / early detection and interruption however I have not found any literature or testing that quantifies what level of light [lumens?] is required in order to operate the trip signal, and at what level of arcing current this is correlated to? So all this leads to how is this type of detection system typically modeled in the different AF software’s if there is no testing to correlate the arcing current to emitted light? Has IEEE reviewed this? How can the manufactures claim or “guarantee� two levels lower of PPE? Is it based purely on testing by the manufacturer? I understand that these types of systems are recognized by the IEC [62271-200]. Has anyone on the forum installed, started up or familiar with these types of systems I would like to get your feedback on their reliability, and if there is a industry standard [ANSI/IEEE/UL] on how these types of systems are manufactured / installed /etc.. Thanks in advance.

You're right about concern over liability. I'd advise them not to work energized - leave it at that. The table method might look okay but the message you got from the NFPA doesn't reassure me. The table method assumes too many things will work correctly. Places like 7-11 might have equipment that looks okay, but the chances are it's not been touched unless it was for repair or modification. So, if I were you, 'd not mention the table method and leave it to your students to check into the table themselves. If they bring it up in class, you can discuss it but I'd be careful about endorsing it or telling them they can rely on it.

My understanding is that to avoid false tripping from flash photography for example, these systems use current supervision. Therefore for modeling, treat it like instantaneous overcurrent. You essentially have a maintenance switch without needing a physical switch. I'm unaware of any guarantees. Which manufacturer speaks of two level reduction in PPE?

The early versions of AF relays used visible light and no current detection. The newer models use the wavelength of the detected light (in the lower end of the visible spectrum) and current detection to prevent false tripping. The amount of lumens does not apply for the system testing.

For calculating the incident energy, this significantly decreases the detection time, in the range of 0.003 seconds depending on the manufacturer. You would need to add the breaker's clearing time, to the detection time, for the AF calculations. The net result is a very quick clearing time for the calculations, thereby reducing the incident energy. I do not see a way to use the NEC tables to find a PPE rating.

You use a fixed opening time with these systems. Light intensity doesn't matter. It's like instantaneous tripping except the current does not matter.

Arc-flash protection involves detecting an over current as well as light (arc).
Light sensors are supervised with an instantaneous over current element offering enhanced security against false trips for SEL 751A relay. MET L command will display the Light Intensity in Lumens. Once relay is programmed test the relay using a flash (camera) and test set. These relays have clearing time in msec. There are several ways to model this in AF software.
For e.g. SKM you can any of the below
1. Add a relay and link a library device with arc flash (no regular device 50/51) settings
2. Use Bus competent "ARC FLASH INSTANTANEOUS PROTECTION" in second sub view of the Competent Editor.
3. Unlink the TCC in the Arc Flash window and enter the relay clearing time.

We have installed several of these.

Hope this helps!

Absolutely, the faster the arc is detected, the faster it can be interrupted. However, the Arc Flash relay operating time is never equal to the fault clearing time.

Look at the system not just the components.
For medium voltage industrial applications fault clearing time can approach 100msec, when safety margins are included and other control elements, like lock out relays, are considered.
For 480V industrial applications fault clearing time can easily approach 500msec, especially when the device is a molded case breaker with a 120VAC add on shunt trip mechanism.

Agreed with the last poster. Taking a typical medium voltage example if you have a DC shunt trip coil and a Toshiba vacuum breaker (not picking on Toshiba...others are similar) once the vacuum breaker contacts are open it has to go through a current zero (maximum delay 8 ms) with NO mechanical operation time. Typically breaker opening time specifications are around 35 ms so we have 8 ms to interrupt current and 27 ms for movement, or 3 cycles, plus the 4-8 ms for the arc flash relay. This is assuming you shunt trip the breaker directly and look for light only (no di/dt detection). If you add di/dt, then it increases to a full 4 cycles. This is with direct operation of the breaker which I recommend with today's multifunction relays. Adding an Electroswitch lockout relay adds 1 additional cycle of delay for a total of 5 cycles or 83 ms...good reason to finally retire the lockout relay in favor of the microprocessor equivalent.

With molded case air breakers, it's not unusual to hit as low as 2-3 cycles or about 50 ms as it forcibly breaks the arc in the arc chutes, especially with microprocessor trip units.

Of course you can also have a ton of discrete relays and all kinds of intentional or unintentional delays that slow this down significantly but for most cases these are the exception and not the rule.