Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [8023-POEP] Liaison letter from IEC TC65/SC65C/JWG10 - Power over Ethernet performance in industrial environments



Gents,

In a sense I agree with Geoff in that the IEEE is not in the applications support business or a system/design consultant.  We do however have members who are in the PoE business.  The problem with item 1) is that it is lacking in enough information to provide a useful response.

I believe this is the basis of Yair's questions.

The author also assumes we all know what MICE, E2 and E3 are.  I found this http://www.odva.org/Portals/0/Library/CIPConf_AGM/ODVA_12_AGM_Standards_Update_Lounsbury.pdf.  Also www.it-cabling.com/Standards/isoiptg/Meeting09/IPTG09-15.pdf , www.belden.com/pdfs/Techpprs/CNSmayjune2008standard.pdf .  So our members from the EIA might be able to help us understand.

The contention of 1) is that both the PSE and PD were compliant, and that "probing and classification" (detection?) caused a PD (?) failure seems unlikely.  However the question is written in a manner that makes it hard to determine if this is the actual question.

In my mind a part of the reported problem might be that devices intended for 33.4.1 Class A environments may have been used for Class B environments.  In my experience, many PDs (and PSEs) are really designed for office environments (MICE E1) with little additional thought to transient protection.  Taking such devices and applying to heavy industrial environments (like operating next to a high horsepower motor) is a case of poor planning and system-level design.

In addition, it has come to my attention that there are some installations that mix grounded-output adapters into the PoE power supply, failing the 33.4.1 requirements.  This may not always be under the control of the PD manufacturer.

Ideas for a response include:

1) The idea that 802.3 provides functional requirements for the data and power, not environmental or safety requirements
2) The concept of the broad market served by 802.3 finds MICE E1 adequate
3) Various other standards bodies provide environmental requirements including things like ESD, EFT, EM emissions, EM susceptability, flicker, isolation, safety.  Some of these relate application/environment to recognized standards.  Several examples are ETSI EN 300 386-x, and the EU's Low Voltage Directive.  I have not been in the industrial business, so I can't point to one for that environment.
4) One of the documents I provided links to above infers that IEC 61784 may deal with the issue of device requirements for E2 & E3 installations, but I don't have access to these.

As for 2) in the liason letter I agree with David's comment about limits to PD di/dt, and also the new PSE limits of 33.2.9.2.  However, this is designed to accommodate intra-PoE functionality and does not include effects of induced noise and transients from external sources (i.e. this is for interoperability).  I believe that some other environmental specification (not 802.3-200?)  would need to specify what resistance to environmental noise the system would have to have.  Even if a standard does not exist, the supply base will provide hardened PDs and PSEs if the customer-base will pay for performance.

To make it clear what I am talking about, consider that a well-designed PD with proper isolation and a grouded output is embedded within some large industrial machine.  Typical EMI considerations in a PD power supply result in a (1500V capable) capacitor between the output and input.  If the local ground at the PD takes an abrupt transient, a current may well flow from the PD output, through the power supply, and into the link.  This could give rise to a momentary data corruption - or BER "hit."  Further, this transient may be able to flow through a PSE, and into other connected links.  Think of this as a large star network of interconnected noise sources with multiple complex paths.  We have this today in installations that provide isolated adapters connected to the PoE front end at every PD.  The adapter ac coupling to the ac mains network provides paths for (hopefully small) transients currents to circulate.

I think requirements for hardening against these kinds of environments is outside of our project scope.
Regards,
Martin




Martin Patoka
Systems Engineering Manager
Texas Instruments
O: 214-567-5487
mpatoka@xxxxxx

-----Original Message-----
From: owner-stds-802-3-poep@xxxxxxxx [mailto:owner-stds-802-3-poep@xxxxxxxx] On Behalf Of David Law
Sent: Monday, June 01, 2009 6:12 PM
To: STDS-802-3-POEP@xxxxxxxxxxxxxxxxx
Subject: Re: [8023-POEP] Liaison letter from IEC TC65/SC65C/JWG10 - Power over Ethernet performance in industrial environments

Hi Geoff,

Thank you for your comments - I wanted to get some thoughts on this letter prior to the meeting - and that seems to be working, which is good. As I hope I made clear in my email, I was indicating my intent to delegate the drafting of the response to this Task Force - but, as always, the actual delegation will occur in the IEEE 802.3 Opening Plenary where the liaison letter will be reviewed - and the actual decision could be different from my intent.

In respect to item #2, I do think this is an area that IEEE P802.3at has some expertise in as [1] the question relates to the effects of transients that are created on Power over Ethernet and [2] there has been work done in IEEE P802.3at on the limits of the transient envelope. The draft, for example, contains a PD specification related to limiting transients in subclause 33.3.7.5 'Peak transient current' which specifies the maximum transient current drawn by the PD in terms of mA/µs.

I do, however, take your point that we also need to involve twisted-pair copper PHY experts. I believe the best place to find them is currently in IEEE P802.3az. Based on that, I propose to take two actions:

1. When IEEE P802.3at considers this letter they make sure they coordinate with IEEE P802.3az

2. I will send an email out to the IEEE P802.3az reflector to make sure those interested can also participate.

In respect to the outcome reported at the IEEE closing plenary, I'm more than happy if more time to work on this is what needed, and I agree that, based on my reading of the letter, that may well be the case.

Best regards,
  David




owner-stds-802-3-poep@xxxxxxxx wrote on 01/06/2009 19:26:20:

> David-
>
> After examining the letter, I would assert that the P802.3at Task
> Force does not have the expertise to address all of the issues raised
> in the letter. In particular, question #2 lies fully outside the
> expertise of the Task Force and should be brought before the Working Group on Monday.

> I would guess that Q2 might more appropriately be assigned to either
> maintenance or to the copper sub-task force of 802.3ba for a response.
>
> With respect to both questions, my guess is something more than just
> an anecdotal response should be considered. As such, it might be more
> appropriate to carry over the action item of a full response so that
> our

> members can gather up more information or (perhaps) solicit more
> specific failure information.
>
> Best regards,
>
> Geoff Thompson
>
> On 6/1/09 4:09 AM, David Law wrote:
> > All,
> >
> > The IEEE 802.3 Working Group has received a liaison letter from IEC
> > TC65/SC65C/JWG10, Industrial process measurement, control and
> > automation/Industrial networks with respect to Power over Ethernet
> > performance in industrial environments.
> >
> > I just wanted to inform you that I intend to delegate the generation
of a
> > draft response to the IEEE P802.3at DTE Power Enhancements Task
> > Force during the plenary week in July. The draft response will be
> > consider
and
> > then voted upon at the closing IEEE 802.3 Working Group plenary as
part of
> > the IEEE P802.3at closing report. You therefore may wish to review
> > the letter prior to the meeting, the letter can be accessed at the
> > URL [
> >
http://www.ieee802.org/3/minutes/jul09/0709_IEC_SC65C_JWG10_to_802_3.pdf
> > ].
> >
> > Best regards,
> >    David Law
> >    IEEE 802.3 Working Group Chair
> >
> >