 | Level: Intermediate Peter Seebach (developerworks@seebs.plethora.net), Freelance author, Plethora.net
15 Aug 2006 When the ex cathedra RoHS Directive came down, it was missing a
little crucial piece of information -- how manufacturers, distributors, and purchasers of parts could communicate to each other the RoHS status of every part.
Who got the
lead out?
The EU has adopted a set of governmental standards for reduction of
the use
of hazardous materials in electrical and electronic equipment. These
standards, called "ROHS" or "RoHS" (pronounced "row-hahz" the last time I
heard it pronounced, but also as "row-huss;" to avoid this confusion, many
people refer to it as "lead-free," even though the standard is much
broader than that), are enjoying industry-wide compliance from both
producers and
consumers of components. Component producers need to provide information
that component buyers can use to ensure the compliance of their resulting
products, or component buyers need to specify their requirements so that
component producers can certify compliance.
This creates a problem: how should information about materials and
products
be transmitted? Here, the government-mandated standard is simply silent; the vendor is responsible for making this information available, or for using that
information. However, lack of information is not a defense; the vendor not
only can, but must find some way to get this information. The
compliance
deadline, July 1, 2006, has passed.
So. Multiple companies in a number of countries with some subtle
differences
in local law need to start either complying with a law (facing stiff
fines for
non-compliance) or helping their customers comply with a law. The law
requires distribution and collection of substantial quantities of data.
Furthermore, because exact requirements vary (other countries may impose
additional requirements), a mere yes or no certification of compliance is not
enough for some purposes.
Although the basic goals of RoHS were finalized in February 2003, the
official standard for this, IPC-1752, was developed extremely quickly, and
became available in February 2006. Unfortunately, retooling and redesigning
take time. Companies that needed to be compliant by July of 2006 had been
working on compliance for years already. For the most part, this meant a
series of unrelated ad-hoc solutions which might not interoperate.
In short, standards hell.
Existing
practice and imposed standards
What happened? People made a decision -- we need to reduce the amount of
certain substances, most noticeably lead, used in electronic products. The
decision was made at a high level. This is somewhat justified:
questions like, "twenty years from now, what happens when this product is in
a landfill somewhere?" are normally not on the radar for a product
development
team without external motivation.
What seems to have gone horribly wrong is that the imposition is
incoherent.
The initial standards don't seem to show much consideration for what is or
isn't technically feasible. In many cases, the requirement to replace and
upgrade equipment might result in perfectly functional equipment -- which
happens to have lead in it -- being tossed into landfills right now, instead
of continuing in service for another twenty years. The gradual adoption of
exemptions as more and more manufacturers apply for special protected
status in
their particular market niche reflects the total incoherence of the initial
proposal. It's as though a government rushed through a ban on the use of
leaded gasoline over concerns about the effects the lead will have on children
who drink a lot of gasoline. The ultimate goal -- reducing hazardous
materials -- is a sound one. It should have been pursued by people who
were at
least willing to discuss the question of why a given material is in use, or
what the alternatives are and how well they work.
The real killer, though, is existing practice. Contrast published
standards
for the C language. The success of the C89 standard (and to some extent,
C99 as
well) is clearly directly related to the strong push for standardization of
existing practice. Compiler vendors were not told to do anything that
had not
been done already. Everything specified was known to be
possible, and
indeed, known to be possible under fairly firm restrictions. By
contrast, very
little real-world equipment came anywhere near compliance with the RoHS
standards. When these laws were passed, many of the things required had
never
been done in a production environment. Problems, such as "tin whiskers"
formed
by lead-free solder, simply haven't been solved. A lot of the first round of
RoHS-compliant equipment is probably just going to fail early on and
have to be
replaced.
In an ideal world, people would have had some time to try out various
approaches, find which ones worked, and standardize them. This wasn't
possible,
and it shows. The problem is simple: no one was doing this before. It
is not
entirely clear how the standards people could have fixed this; after
all, the
reason no one was doing this before is that it is very expensive to
retool and
redesign to reduce use of hazardous materials, and without governmental
action,
the incentive just wasn't there. If the timeline was more relaxed, people
might just not have started retooling or developing these technologies as
quickly; after all, it's pricey.
The thing they could have done is given a timeline which was remotely
consistent
with industry timelines for development, testing, and productization of new
technologies. That would have given people time to work some bugs out,
and provided room for development of the secondary standards used to manage
compliance.
Imposed standards generally deprive standards writers of the benefit of
existing practice. This is not a simple thing to correct. Requiring people
to do something without a standard is impractical; writing the standard in
a vacuum is also impossible. The requirement that a standard be developed
and implemented quickly made things predictably difficult.
What's probably called for is a revision to the standard, reflecting
developments and practices over the next couple of years as RoHS compliance
becomes mandatory, other regions pass other (probably conflicting) materials
requirements, and companies get a chance to develop some de facto
standards for communication and automation. The pessimist might dismiss
the standards effort entirely because, after all, people are already working
around it.
Standards
for complying with standards
A crucial omission from the RoHS legislation is any kind of hint
about how
to go about complying with it. One gets the impression that RoHS was
established by people who believe electronics are created through a process
involving lamps and magic wands, and that designs and manufacturing can
be changed
simply by uttering a few different incantations.
The problem designers face is simple: No one builds anything
completely from
scratch. That means that, whatever you're building, it either uses
components
produced by someone else, or it is a component other people will use.
That, in
turn, means you need a way to exchange information with your suppliers and
customers about the RoHS compliance status of what they give you and
what you give
them.
The idea of a standard way of communicating this information is
something standards writers needed time to evaluate, consider, and develop.
Unfortunately, by the time the RoHS legislation was passed, people
already had
to be using something to solve these problems. There wasn't just a
short window of opportunity for developing a specification, there was a
negative window of opportunity. It was simply impossible to
write the
specification until months after it needed to be available.
Still, there's a standard (or two) now. The most obvious and formalized
standard is IPC-1752, produced by IPC (once upon a time the "Institute for
Printed Circuits," but like KFC, now just known by the initials).
IPC-1752
The IPC-1752 standard was a bit late, but worse, it was rushed. It's
PDF and
XML. You may think this sounds like I'm confused; I am. Apparently they
decided on a PDF form as the "standard," but there's some magic to allow
it to
import information from an XML file in a specified form.
What does the PDF file do? Well, for one thing, it's larger and more
proprietary. For another, it lets you ensure strictly that each part gets a
separate page, rather than letting you combine a whole family onto a page.
Presumably, the intent is that printing hundreds of pages of documents
will wear
out old, hazardous, printers and encourage people to buy new,
RoHS-compliant printers.
It's hard to express how confusing and mystifying this decision is.
Who was
it who first said, "well, given that we need a few hundred bytes of data
about
each part, the file should be at least a megabyte"? Ironically, one of the
stated goals of standardization listed in the IPC-1752 standard is that
standards should not "keep people out." I would have started by not
requiring
the use of a proprietary software product, myself.
The question of how, or whether, this can be automated is not directly
addressed, which seems to be one of the barriers. Since requests for
information are also PDF forms, the person handling the request must
open the
PDF form, look at it, and manually send back the requested information.
This is not a design which lends itself to faxback systems or e-mail
auto-responders.
Still, if you get past the marginally surreal choice of
implementation, the
standard seems to do a decent job of defining what information you
really need
to make informed decisions under RoHS regulations, such as what exemptions
you might have, and just in general what things must be certified for each
part.
Does this count as a
monopoly?
Before the IPC-1752 standard was available, people were still scrambling
to retool production lines, and redesign products, to comply with RoHS.
According to an article in Design News (see Resources), one of the most
common
formats for communicating information about parts compliance with RoHS
was Microsoft® Excel®
spreadsheets. After all, everyone will have something in his or her office
that can read spreadsheets, and they make it easy to create and distribute tabular
data, such as checkboxes or numbers associated with index keys, such as
part numbers.
Of course, this didn't start out standardized at all -- it's just people
filling out forms
that allow someone to read the data. Some companies send out "survey" forms
that can be filled out by a materials vendor, then read in through macros or
scripts when they're sent back. However, the need for standardization led
to the development of a more standardized format, called "Eco-compliance
declaration," or more commonly "ECD" (see Resources). This format contains the same data required by IPC-1752, but uses
Excel spreadsheets to send data. Ironically, this is probably less
proprietary than the PDF-based files, because multiple office
packages can generally manage Excel files.
Did I mention it's also
XML?
Of course, both the Excel-based and PDF-based formats have some XML
in them.
XML is being used as an interchange format for collating data. The IPC-1752
standard provides an XML Schema for compliance information to specify the
format of XML files which can then be imported into PDF files; the ECD
people
have a similar arrangement. The astute
reader may observe that, given sufficient technical wizardry, the XML files
themselves could theoretically be used to transmit this data directly,
without
re-encoding into a proprietary format.
The XML Schema itself, in fact, looks like one of the best parts of
the whole
arrangement. This is a task well suited to XML's ability to define a
selection of data elements that may, or must, be included in a data file.
Given some way to move data from your existing database to XML, or even just
to plain text, it's a cakewalk to build the necessary hunks of data.
What
happened here?
While it looks like this "worked," in that vendors were able to assemble and sell RoHS-compliant products in time for the deadline, the process seems to have gone quite firmly awry. The fact is, the first ad-hoc solution thrown together from what's lying around
would have been a spreadsheet, and sure enough, that's in widespread use. Both of the
common variants of distributing the 1752 data, either as Excel files or
as PDF, look suspiciously similar to what you might get if someone was
commanded to make something that works today, using the
material and tools
to hand.
The governmental standards didn't leave enough room for proper
standardization and time-to-market. They left enough time to let people
build products, if there had already been compliance data; they left enough
time to develop a good and robust specification and set of industry
practices
for the compliance data. They didn't leave enough time for both. With
another six months, the standards process could have been less rushed, and
still left time for people to get their product information encoded and
published.
It's harder to explain the PDF forms thing. I think these maybe make
sense
in terms of a paper trail, with the need to make a bunch of single-page
documents that can be printed out and read. Maybe. It still seems like
there ought to be an automation-friendly format and protocol around
somewhere.
An article by Ray Franklin, in October of 2005 (see Resources) bemoans
the lack of practical documentation. There's no real description of how
the XML Schema connects to the forms, and there's no real description of how
to use these forms.
He's right.
Imagine that you're a parts buyer. You want to get information about a
company's parts. What do you do? Do you need to fill out the PDF form, or
can you just e-mail them and ask? Do they have to send you a response
that includes your information as the requestor? This kind of material
is lightly covered at best in the specification, but without it, the forms aren't
especially useful.
The feature set is certainly exhaustive in some ways. For instance,
the PDF form for requests allows the sender to "lock" the fields indicating
part numbers, preventing them from being altered by the vendor. This
might matter if a vendor chooses to change a part number for the new,
RoHS-compliant part; changing a part number could require recertifications,
modifications of other parts that have certification information physically
inscribed on them, and more. The exhaustive
feature set seems to reflect the large number of organizations associated
with the project.
However, the kernel of a standard is now in place. The XML Schema,
under-documented though it may be, seems to be clear enough that people who
are not planning to adopt the IPC-1752 standard are nonetheless using the
same XML Schema. Business needs will drive the development of more ways of
requesting, and publishing, this information.
Lessons learned
In hindsight, one observation is that the specification of what data needs
to be
available to a potential parts user
is logically distinct from the question of how this data should be
transmitted. The XML Schema will be used by a lot of people who have
no interest in the PDF format; a smaller, better-documented standard
for the
XML Schema alone would have been of great value, and might have been
published
sooner, letting more people start experimenting with layers on top of this
that met their business models.
On the other hand, divide-and-conquer isn't always a viable plan. If you
have
to wait for one standard to be done before even starting on another,
that can
make it harder to comply with a tight schedule.
The broader question of how to handle imposed requirements in
standards is
not an easy one. Requirements are often imposed based on things mostly
unrelated to technical feasibility, and a discussion of the feasibility of
reducing lead content might not include much consideration of how
information
about lead content is to be distributed.
When users invent a new standard, that's often a sign that the
existing one
doesn't serve their needs. The ECD standard, no matter how much the
developers say it isn't "competing with" the IPC standard, is still evidence
that the IPC standard isn't meeting some needs. On the other hand, the
essential compatibility between them suggests that reconciliation is
possible. A future unified standard could specify multiple ways to request or send
the underlying data, all built around the core XML Schema holding the needed
information. These are not competing business interests trying to leverage
each other out of the market; these are people trying to get maximum
industry
support and compatibility for something that everyone in the industry is
required to carry out far too quickly. A few bumps along the road are,
in the end,
nothing to be surprised by and will probably be overcome.
Resources
About the author | 
| | Peter Seebach would love to be able to buy food with RoHS certifications, but failing that, he's content to know that any new monitors he buys will be safe to eat. |
Rate this page
| |
