An enormous amount of information is needed to precisely and unambiguously define all of the fabrication details for a PCB and ensure that it is manufactured, tested, qualified and delivered exactly as the customer specified. The principal area of concern is not the image data that constitutes the board design—there are already well-established and well-accepted formats for conveying those instructions across the CAD/CAM interface—but all of the other bits and pieces of essential information needed to fulfill the order requirement that need to be communicated over the same interface. It costs the PCB industry substantial time and money interpreting this information when it is presented in different styles by different customers. A uniform “language” would save these costs and avoid misinterpretations.
Widely reported recently has been the development of a new open standard for exchanging printed circuit fabrication data by an independent international task group with members from the entire supply chain. A glance at the CircuitData website gives a clear indication of what the group has set out to achieve: Fundamentally it recognises that extending existing CAD/CAM formats, or even creating new ones, is not the way to go—those formats have been developed and refined for a specific purpose and it is not logical to try to incorporate several layers of additional information into them. Neither should it be the PCB designer’s responsibility to input this information.
The CircuitData group is concerned with communicating data on details such as the physical description of the board and the way it is to be panelised, the materials for dielectric and conductor layers, the stack-up, drilling and other mechanical processes, plating, solder mask, legend, final finishes, testing, etc., as well as standards and requirements and conflict resolution procedures. Indeed, this pertains to any information relevant to achieving cost-effective and timely delivery exactly in accordance with customer requirements. The terminology will be based on IPC-T-50, and the data will have an XML or JSON output.
The project was initiated by Norway-based Elmatica, the world’s longest-established PCB broker with over 46 years of experience in a business where accurate and efficient communication of PCB manufacturing information is of paramount importance, particularly when servicing customers in the defence, automotive, civil aviation and medical sectors, amongst others.
Elmatica’s Chief Technical Officer Andreas Lydersen and Senior Technical Advisor Jan Pedersen act as CircuitData project moderators, and I was delighted to have the opportunity to talk with them.
Pete Starkey: Andreas, Jan, thank you for joining me. I am very interested to learn more about your data transfer language, and I am sure that our I-Connect007 readers will be too. I speak as a retired quick-turn PCB fabricator who can remember the days when we received circuit designs as 4:1 hand-taped masters, which we would take to the local photographer for camera-reduction and step-and-repeat. Early CAD designs were output onto a vector plotter and we received our information as 1:1 photomasters, generally accompanied by an engineering drawing and a customer specification. Customers were reluctant to give us digital data, even when we had our own CAM system and laser plotter, for fear that we might corrupt their designs, and it took some time to build up their confidence. We subsequently experienced the development of several proprietary CAM and engineering software solutions and their ancillary functions in quoting and reporting. There are some quite sophisticated systems available now.
But having read some of your published articles and taken a look at the CircuitData website, I can appreciate what you are aiming to achieve. And I particularly acknowledge that, at Elmatica, where you are in the business of providing a service connecting multiple suppliers with multiple customers, and with your in-depth understanding of the market, you are in an ideal neutral position to moderate this forum objectively and encourage the industry to recognise the benefits to all concerned of communicating in a standardised language.
Jan Pedersen: To give an idea of my background, people joke that I was born in a PCB shop! My father began to produce PCBs near Oslo [Norway] in 1960, and I joined him in the business as a young boy and worked in every department before joining Elmatica in 1992 and progressing through sales and auditing and all of the technical aspects to where I am today as senior technical advisor.
Starkey: I also note that you chair two IPC task groups and were honoured this year with the IPC Rising Star Award. My congratulations!
Andreas Lydersen: For my part, I’ve been with Elmatica for about six years, and I am more of a computer science guy. And from the beginning kind of shocked at the amount of communication that goes back and forth in the form of PDF, and looking to do something about it.
A couple of things it is important to point out: We are not competing with any other format. We did get quite a few reactions to start with, on the basis that there are already formats, so why don’t we use them? We prefer to get things in ODB++ or IPC-2581, but in fact 90% of what we receive is Gerbers. So, our main purpose is to have a language that enables us, even though we are in the middle of the supply chain, to convert all the information we have into something that is machine-readable so we don’t put further strain on the supply chain. This is something to be made very clear. We’re not looking to start a battle!
Starkey: From what I have read, it is evident that you simply want to be a mediator who pulls all the information from whatever source into a uniform system that people can understand and machines can understand. Even with regard to terminology, although you can describe something in so many different ways, just to use one glossary like IPC-T-50 means that, even if we’re not yet talking the same language, at least we are using the same vocabulary.
Lydersen: Even in IPC-T-50, they have multiple terms for the same technical aspects, and people can get confused if it’s in written form rather than in a machine-readable language.
Starkey: So, Andreas, could you give us a quick status update?
Lydersen: Certainly. This has been in the workings for a while now but it’s been formalised for the last 6−8 months. We started out by taking all the information we currently hold. As a broker, we put a great deal of effort into understanding each and every article we receive in order to pick the right supplier. We counted that we asked ourselves 108 questions for each product we receive. We took those and we added the most common questions we get as engineering queries, and also all the documents that go together with the Gerbers. Then we gathered all that information into a spreadsheet and looked through the current technology like IPC-T-50 to see whether we were using any expressions that weren’t listed. And we boiled it down to something that we could hand off to others. We had a talk with IPC, but it was clear that they were focused on 2581, so we decided to open-source it. Since then we have been fine-tuning the language to be able to export everything we have today. The proof is in the pudding—we need to try it out! As of today, everything we send out is also downloadable as CircuitData. Nobody will be able to read it unless they put some effort into it, but at least we are walking the talk and using the language right now.
Starkey: Just to be clear, the language is called CircuitData?
Lydersen: Yes, it is. The language is compatible with two different standards: XML, which is an older standard and has a name that everybody knows about, but we do prefer a more modern standard called JSON—JavaScript Object Notation—and going forward we will be promoting that as a machine-readable format that has fewer variations. All current files that we make available for download are in JSON.
What we are doing now is gathering support and adding people to the forum, and talking to various companies, big and small, encouraging people to join in. From what we can see there is a lot of interest.
By comparison, if we look at IPC-2581 as an example, we receive approximately 10,000 unique articles in a year and only a handful of those are in IPC-2581. And they’ve been going at it since 2004
Starkey: There have already been several initiatives aimed at achieving a more unified understanding in the business: The developments of GenCAM and IPC-2511, and the integration of ODB++ to create Offspring, which effectively became IPC-2581—all the stuff that dear Dieter Bergman was dedicated to promoting. What is the main difference between these initiatives and yours?
Lydersen: I think that the main difference between our effort and the existing formats is that those formats are chosen by the designer, and the whole supply chain then needs to be ready to receive those files. In our case, we present information both from that file, and other files that are added after the designer, into a new file. If only we use it and some of our clients use it, both of us are saving time and money. Adding it on top of the format gives a very short path to success and we start getting the benefits very quickly. So, that’s pretty much where we’re at now.
Pedersen: Maybe I can a give practical example. Part of my job is handling engineering queries, and you can imagine the different requests we get from the factory related to basic understanding. Take the case of a designer who is outsourced. He’s creating the design and he’s making the article specification. Then it comes to the product owner who adds his corporate requirements and passes it over to the EMS. The EMS is adding his panel-array requirements. There could also be requirements for materials, tolerances, solderability—whatever it is. Then quite often it comes through someone like us, and we may also add some of our own requirements—packing for example. And then it arrives at the PCB shop, and I would say that a considerable proportion goes through China. There you have a translator, a young girl or guy for example, sitting and translating all this data into Chinese. And then they send it in to the engineer. OK, there are some companies where the engineers can read and understand English, but not that often. This means that the engineer gets information that’s been translated into Chinese and he then tries to understand all these sections and compare the PDFs and all the work documents from maybe three or four companies. Then, for example, he sees that in one requirement it says that you should use immersion gold but in another it says lead-free HASL. And it says that it shall have this tolerance there, and it says another tolerance there—it’s actually a big mess!
And then we have engineering queries that come to us or to the EMS, sometimes all the way back to the PCB designer, and we get the answers back. Then we say you have solved everything. The problem is that the original designer did not change his article specification. We have a new product with new requirements—and now we can call it a “product” because we have finished with engineering queries and we start producing. Maybe we shouldn’t call it a “product” until it is received as an acceptable PCB. Only this morning I had a question about the stack-up of a PCB that has been changed all through the supply chain and there was no traceability for it.
Now, this is what we want to do: The designer has this file, and he sends it up to his company. If they have their requirement in the same digital file format, XML or JSON, then if they want to make a change, say from immersion gold to lead-free HASL, and add tolerances and whatever, we have only one file to send over to the EMS. Say that the EMS then adds their panel array requirements, and maybe some additional mechanical tolerances because of the characteristics of certain components that the designer was not aware of. They add all these requirements to one single file. Then the file comes to us and, say we have some packing or labelling requirements, we add these in and then the package goes to the PCB shop.
Now they don’t need the translator because if we do this correctly, the engineer can read it directly in Chinese. For example, IPC-T-50 has an exact description in English and Chinese, so if you translate all these descriptions you get a clear understanding of what the customer needs. Then we will avoid maybe 50% of the engineering queries. This goes fast, and the beauty of it is that, when the engineering queries are finished, the article specification can be uploaded to an on-line system and the designer will have his updated article specification instantly. So, you have one file, one understanding, through all processes. And you avoid a lot of questions, a lot of fuss and misunderstandings because you no longer have maybe three people describing the same thing in three different ways or stating confusing mechanical tolerances. These things will be changed throughout the process and updated before the file reaches the PCB fabricator. Then the only questions you get back are to do with capability. But then another thing we can do is to compare this with the capability of the factory so we can see immediately if this factory is able to produce the board.
Lydersen: Another good thing is that nobody has tampered with the Gerbers, which is something that you really want to avoid.
Starkey: And to be clear, that image information can be there as Gerber, or ODB++, or IPC-2581—it’s just part of a data set and it’s still there in the package in its original plot format?
Lydersen: Yes, that’s true. But let’s consider security. Remember that most of the communication in the supply chain is about quoting. In today’s supply chains, hit rates are often as low as 20% or less, meaning that 80% of requests for quotations never end up in an order. But still the Gerbers are sent out to everybody, even though they may often be classified information. Everybody interprets the files, checks the capability of factories and further distributes the files—including the classified ones. But with this, you could actually send off a request without sending the Gerbers and have the pricing and the lead time information generated immediately, directly from the machine that receives it. That means a lot of time and money saved in the process, and a massive move away from exchanging classified information. It has a lot of potential and I am confident that it has the possibility to reduce the manpower needed and to reduce the errors created by the current way of doing things.
Pedersen: I would add that we can include a lot more information than you would see in a normal article specification. Take for example a design where minimum track is 0.1 mm and minimum gap 0.1 mm, but it doesn’t tell you on which layer—whether it’s a plated layer or unplated layer. With CircuitData we detail it down to that level, so that when the factory receives this article specification they can see that a bigger track and gap is needed on the plated layer than on the unplated layer. You have been in PCB fabrication, Pete, and you know how important it is to match track and gap to copper thickness. Almost every day I get engineering queries related to not being able to achieve the specified track and gap on a plated layer, or not being able to achieve solder mask dams on 2-ounce copper. So if you specify the right details then the factory does not need to read the Gerber to make those capability decisions.
Lydersen: You are saving manpower, you are saving time, you are not asking non-capable suppliers, and you are resolving your engineering queries in minutes instead of days with all the necessary translations and time zone issues. It should be to the benefit of everybody.
Starkey: I certainly agree that you present a very convincing case, and I can really appreciate it from the point of view of the PCB fabricator, to be able to describe a product exactly and without false interpretations. I understand that you have a beta version of CircuitData ready for public launch. What’s your timescale for this?
Lydersen: Right now, we are at Version 0.6, and from our perspective this is as far as we can get on our own. Now, what we need in order to progress to Version 1 and get it into production is to have others join the project. We are happy to sponsor it—we have already put in a lot of time, plus the cost of setting up the forum. But from here on we need the cooperation of others.
Pedersen: We do have a project timeline: we are looking for the official launch of Version 1 to be October this year, and we plan to have a pre-launch webinar on 26 September. We will tell more about that on our LinkedIn page, which will be distributed to the industry news-lines. Ongoing, we plan to have a live forum to further discussion and to make improvements, almost in real time. We have a steering group that will meet four times a year. We will also have seminars and conferences at least once a year, and a webinar every time we launch an upgrade, which we plan to do twice a year.
Lydersen: If you go to www.circuitdata.org, you will find help articles, graphical elements and logos, and there is also a link to the GitHub project that contains all the current codes and the documentation of the project so far. And we will keep on suggesting stuff and adding new people to the steering group.
Starkey: Andreas, Jan, this has been a most interesting and illuminating half-hour. Thank you for sparing your time to bring me up to date and for sharing your experiences. I will make every effort to keep people aware of what is going on.
