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

Re: [802.3_10SPE] Proposed response to MDI connector comment r02-14




George,

I see the potential SPE application space as large as the two wire sensor market both reuse and greenfield. We are talking about providing data and power to the wired world of current and evolving two wire sensors for in buildings and automobiles. I support the inclusion of the MDI references in the current draft to “enable” compatibility to TIA/ISO balanced cabling evolving in support of SPE. I would prefer the MDI references be required “shall” but recognize this as non-optimal for reuse and may limit possible end point sensor applications. 

Regards, Chris



 


-----Original Message-----
From: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>
To: STDS-802-3-10SPE <STDS-802-3-10SPE@xxxxxxxxxxxxxxxxx>
Sent: Fri, Aug 30, 2019 8:14 pm
Subject: Re: [802.3_10SPE] Proposed response to MDI connector comment r02-14

There are parts of this discussion that seem to have gotten down to assumptions about who will use the various clauses of 802.3cg.  It seems a lot of people assume singular usage models for the PHYs we are developing, but that is not the case.
 
There are those who assume that clause 147 is relegated primarily and purely to the automotive industry, and those who assume that the clause 146 PHY would have a ubiquitous generic interface.
While these may be where the CFI discussion started, now a few years back, they are, in my experience, not true today.  Successful ethernet standards do not lock themselves to applications.
 
The discussion of 10BASE-T1L (clause 146) began with process control (with intrinsic safety requirements) in the CFI, and, if it had stopped there, IMHO, we wouldn’t have had enough to make a standard worthwhile.  It has expanded to include (at least) sensor, access control, and alarm applications, within industrial and commercial building environments.
Similarly, the discussion of 10BASE-TS (clause 147) started with automotive (and I think that Geoff thinks it ends there), and has expanded to include industrial and intra-system applications.  Remember, we thought there was enough utility in this that we even went to the process of a second CFI and expanded the PAR, and the new CFI is a testament to the fact that thinking on applications is still evolving and expanding.
 
I urge those thinking about whether or not to specify a connector not to lock themselves into an “THIS and ONLY THIS is what is successful” mindset.  On the subject of connectors and MDI interface requirements, Ethernet has done a variety of things.  Electrical specification at the interface is the key interoperability requirement.  Mechanics can be adapted.  BASE-T Ethernet clauses generally specify a singular connector.  That practice is consistent with BASE-T Ethernet having grown up common in IT environments (and where not technically IT, the computer network was TREATED as an IT environment) over many years.  Optical ethernet clauses have specified multiple connectors, and of course, have also specified module interfaces and test points – these are appropriate for that environment where module form-factors change over time and application.  Backplane ethernet specifies test points and generally not connectors, which is appropriate for that environment.
 
Despite what some may say, Ethernet does not require a specific connector to be successful.  If that were true, much of the Ethernet world would be dead meat.  For better or worse, everyone focuses on the history of BASE-T Ethernet – a small (but mighty!) subset of the Ethernet clauses in 802.3.
 
BASE-T1 Ethernet is just entering the general market.  To assume we know right now how the entire application space will play out takes quite a bit of hubris.   If it were exactly like BASE-T in application, but only used one pair, I would not advocate developing it.  The application space is (and must be) differentiated.  And hence it’s differentiation relates to the debate at hand.
 
What I see is NOT the same as the situation when BASE-T Ethernet entered the market through the decade of the 1990s where the primary application was IT networking and telecom based.  It isn’t the same as having a decade of established a practice and familiarity, of reasonably consistent physical usage models, expansion of BASE-T Ethernet into other areas adopted the consistent and already-familiar connector.  Rather, I see a diversification of applications, particularly in regards to the physical environments’ demands on the applications, which is much more difficult to predict.
 
I have personal experience with various industrial parties interested in BOTH PHYs, for both specialized environments (e.g., process control) and for nonspecialized (e.g., commercial building-like) environments).  These tend to have wildly different requirements for form factor and environmental hardness on connectors.  Some applications are engineered or ‘closed’ systems, where the interfaces themselves are not open to an end user.  Some are not.  I also have personal experience with parties in the building automation and sensor area interested in BOTH PHYS, for devices with differing form factors, power requirements and applications.  Some have regulatory requirements for protection and locking, others do not, and these requirements might have a real impact on the utility.
 
Any of the applications I’ve seen have the potential for being significant, mainstream applications.  And, they have diversified physical requirements.
Fortunately, Ethernet, as I mentioned before, deals with diversification already, and there are different models in the 802.3 standard.
 
As such, I am happy with not having a REQUIRED connector in the draft.  I would be OK with either the state from draft 3.2 or the state from draft 3.3.  Given that neither REQUIRES a connector, and resolving this question will be better aided by field experience and adoption of the technology than by talking about it in a room or reflector, I am satisfied with the status quo as the best way to get this technology off and started in the marketplace.
 
 

To unsubscribe from the STDS-802-3-10SPE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-10SPE&A=1

To unsubscribe from the STDS-802-3-10SPE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-10SPE&A=1