My understanding (which may well be incomplete or wrong) is that the standard's tests for AFDDs work on the assumption that once there is a break in a cable which causes intermittent arcing, the arcing chars some of the insulation over time, and the carbon makes future arcing easier. So the tests are with carbon rods. A lot of the youtube tests try to create arcs with small copper to copper gaps, which tend not to last more than a second or two, and may be seen by the AFDD as a motor-type spark and not trigger a disconnect.

So when a youtuber shows an AFDD failing to disconnect, it may be that the AFDD is actually working correctly. Or it may be being completely useless. Or the standard isn't up to scratch. We can't tell from the video.

Hi Mike

Thats the video yes.  The language is colourful but I think the facts he brings up are very valid.  Like the Hagar test device that goes in the CU.  The fact there is still no firmware update despite the fact that people are reporting issues to Hagar.

Should a fire arise from a Hagar AFDD not working correctly there will need to be a firmware update rolls out or possible a factury recall of all their (Smart) AFDD devices.

Should a fire arise from a Hagar AFDD not working correctly there will need to be a firmware update rolls out or possible a factury recall of all their (Smart) AFDD devices.

I suspect that'll never happen - after all how could anyone demonstrate that the fire would really have been prevented if the AFDD had behaved differently? The fire may have been started by simple resistive heating at a bad joint or a conductor thinned by damage m'Lud - without any significant arcing being present - which of course no AFDD could ever reasonably be expected to detect. Prove otherwise their highly paid lawyers will say.

   - Andy.

Did you watch the video Andy?  Do you think that David at DSES has some valid points about the Hagar AFDD?

I saw the earlier one, and have skimmed the latest - yes there are questions I'd like answered. These big companies though are primarily there to make money for their shareholders - recalls or similar mass updates cost a fortune, so unless their position becomes indefensible they'll not spend the money. As long as they pass the tests required by EN 62606 or whatever (which I presume they do) I'm sure their lawyers will be telling them they're on safe legal grounds, whatever a bloke with a bit of lego and brass (or carbon) fittings comes up with.

Nothing's perfect - it's reckoned around 7% of in service RCDs don't trip when the should, 'when they should' doesn't include lots situations that have residual d.c. currents - and even then there's 5% of the population that are aren't covered for shock protection.

   - Andy.

There is another follow up video from David.S at DSES on AFDDs

Titled

AFDD: Rig MK III and an all-star line up

https://youtu.be/CZtSsFBr4K8?si=tgX6ZToSZ73eV43C

Looks like Hagar do indeed have a new firmware for the AFDD

This now raises a few questions

The Caveat of the MI (Manufacturer Instruction) if the the firmware is optional then you are OK but if the MI states that they will ONLY support the current or latest stable release then you need to get those updates done.   Possible/Maybe

Without a BS7671 entry for this (AFDD firmware update) or another BS then the manufacturers Caveats will be so complex that a small electrical company or sole trader will be always left exposed.

Are they updates to firmware CRITICAL, if so what timeframe do they need to be applied?  I think this will start to raise some eyebrows soon across the industry.  Who can do the updates, the customer or the engineer?  What happens if the firmware update Bricks the device (other terms are also available) does it stop working or go to a FailSafe mode and consistently notify of it status?

From a functional safety and cyber security viewpoint, software updates should be controlled and the update should include security information so that the device will only accept legitimate updates (i.e. they should be digitally signed). I wouldn't be surprised if this isn't common practice.

I would expect that any update required due to a functional safety concern would result in a "recall" being issued; that may not be a physical recall, just an instruction to update the software (similar to the way that a number of Tesla "recalls" have been handled by over-the-air updates rather than taking the car to a dealership).

Update-able devices in a CU/DB are still a new thing for the consumer/installer/engineer.  As with a lot of things in their infancy time will tell.  As an example I bet the AFDD is not even NIS2 (Network and Information Security Directive 2) compliant

Indeed - it rather depends on the instructions for the update 'only use this on existing installations if problems are being experienced' might be just about OK - but after a few decades, how do you even verify which of several  software patches have been applied or not.

An instruction like 'must update to latest' may introduce an unexpected trips problem where there was none before, or be impractical to perform in buildings with more than passing cyber security processes.

And it really could be a great attack vector. Imagine pre-loading firmware to trip off a bank's data centre power at some particular future time or on the occurrence of some specified  switching sequence that occurs on a bank holiday or something.
It does not feel good.
Mike.

It does feel like enduser firmware as apposed to manufacturer installed only firmware will need some kind of British Standards or IEC.  The British Standard and Requirements are distinct but related concepts. BS standards are voluntary guidelines produced by the British Standards Institution (BSI), offering best practices and technical specifications. Requirements, on the other hand, can be either mandatory legal obligations or contractual obligations. While BS standards can support compliance with regulations and improve quality, they are not legally binding in themselves.  Again this will need to tie into NIS2 I assume.  This may be a topic for JPEL64 or similar to discuss?

It does feel like enduser firmware as apposed to manufacturer installed only firmware will need some kind of British Standards or IEC.  The British Standard and Requirements are distinct but related concepts. BS standards are voluntary guidelines produced by the British Standards Institution (BSI), offering best practices and technical specifications. Requirements, on the other hand, can be either mandatory legal obligations or contractual obligations. While BS standards can support compliance with regulations and improve quality, they are not legally binding in themselves.  Again this will need to tie into NIS2 I assume.  This may be a topic for JPEL64 or similar to discuss?