Standards and specs: Of RoHS and rushed standards

XML, PDF, IPC, ECD -- TLAs abound when RoHS bureaucracy runs amok

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.

Share:

Peter Seebach, Freelance author, Plethora.net

Peter SeebachPeter 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.



15 August 2006

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

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Multicore acceleration
ArticleID=154172
ArticleTitle=Standards and specs: Of RoHS and rushed standards
publish-date=08152006