This discussion is locked.
You cannot post a reply to this discussion. If you have a question start a new discussion

Ethernet cables in metal portioned walls

What are people's thoughts on achieving compliance with the below when installing ethernet/structured wiring cables in metal partitioned walls? 

Is ethernet SELV or PELV? If it is can we assume that everything that the structured wiring is used for will be SELV or PELV.

  • Ethernet (base T) was designed to be intrinsically safe, connecting two points with cable isolation at both ends. You can cut and hold onto the cables until the cows come home with zero risk. POE slightly changes this as multiple cables may have core centre taps that are common, but still they present no shock risk. None of this is thus the slightest bit relevant to BS7671, although it seems to have become included. Very odd.

    I guess you could say the same of SELV lighting, which BS 7671 has covered for a reasonably long time. I guess part of the argument is that BS 7671 covers a lot of things other than just electric shock protection (from causing fires to cable supports to EMC) and in the world of standards it's useful to have a back stop 'if nothing else covers it then refer to this for basic principles'. I do think that 522.6 is ill thought out and badly placed though - insisting on earthing things presumes ADS and really doesn't make a lot of sense for separated or truly double/reinforced insulated systems and possibly not FELV either.

       - Andy.

  • What has Ethernet got to do with power electrical installations?

    They are installed alongside each other. 

    supposedly power electrical specification

    Not according to the scope. Buildings are full of all sorts of electrical installations these days, I don't think we can look at individual systems in isolation especially when it comes to safety which is literally the object of the Wiring Regulations.

    You can cut and hold onto the cables until the cows come home with zero risk.

    We are talking about a structured wiring system that could be used for many things including POE e.g. access control, CCTV, and displays. During the building's life, there may also be a use for which we have not envisaged.

  • POE does not change this one jot, it provides battery level power, which of course is completely isolated from any mains supply. Why the reference above to RCDs? Ethernet (base T) was designed to be intrinsically safe, connecting two points with cable isolation at both ends.

    The assumptions that PoE have 'battery level voltages' and is 'completely isolated from mains' under all conditions, are completely false.

    Whilst PoE might, currently, be often implemented at 48 V DC, there is, in reality, no such voltage limit - although PoE is not necessarily 'pure DC' either. However, PoE can be implemented at voltages that would not be suitable for some cases, where PoE would seem to be ideal (those covered by Section 701, Section 702, Section 710 for example ... but also BS EN IEC 60204-1 for machinery).

    The real problem, however, is not in selection of the system voltages ... as stated in my previous posts, BS EN 62368-series, which is used to manufacture some of the 'source' equipment for PoE, does not limit touch-voltages to safe levels in single-fault conditions.

    The problem is the foolish "feature creep" of supposedly power electrical specifications

    PoE could be considered feature-creep the other way ... however, luckily the installation standards for telecomms and electrical installations, at least, are fully aligned to work together (if you know enough about them, that is very apparent) ... it's the product standards that are not aligned.

  • Again, whilst SELV is designed to be intrinsically safe, some product standards now have deviated from that path, and the assumed safety has been lost. This is NOT an issue between ELV vs LV, or telecomms vs BS 7671 (IEC 60364) ... it's one of product standards not aligning with basic safety principles set out in what are termed 'horizontal standards', quite possibly with scope not fully aligned relative to real-world use-cases.