CircuitData: Creating an Open Source Language for PCB Data Exchange

Estimated reading time: 12 minutes

I recently had the opportunity to speak with Elmatica CTO Andreas Lydersen on a subject of great interest to him and his supply chain, namely CircuitData. This open source language promises to greatly improve communication of details that can often be misinterpreted due to the differences in terminology used throughout the supply chain. A standardized language could save much time and error in board design, quoting and the actual build of the PCB. His colleague, Jan Pedersen, will be speaking on the subject at IPC’s Design Forum on Monday, February 26 at 9:20 am. The Design Forum is part of IPC APEX EXPO 2018 in San Diego.

Patty Goldman: Andreas, please share a little bit about Elmatica for our readers.

Andreas Lydersen: Elmatica is a 46-year-old PCB brokering company, as far as we know the world's oldest. We are based in Oslo, Norway, with offices throughout Europe, and in Hong Kong. We broker printed circuit boards, which means we get specifications in, we pick the right supplier, negotiate the price and follow up on the production, and we do the logistics. I joined the company six years ago as CTO, not the technical part concerning the boards themselves, but IT-wise.

Goldman: Please tell me about CircuitData.

Lydersen: The CircuitData Project is something that came about because we tried to figure out how to do what we do as smoothly as possible, without creating any noise in the supply chain—which we found to be surprisingly hard. To stay in control and know that we were offering the right product and picking the right supplier, we were asking, either ourselves based on what we could find in the specifications, or our customers, 108 questions every time. After inputting these into our systems and doing our magic; we ship that off to suppliers, who end up doing the same thing again.

We concluded that this is because we don't have a common language—everybody just defines their own. If you're the owner, an OEM or an EMS, that doesn't seem to be a problem, but it actually creates a lot of noise further down the supply chain, and ends up costing money and raising questions. So in this world of everything being automated and Industry 4.0 being on everybody's lips, that doesn't seem right. That’s why we started this open-source project called CircuitData to create and build this common language—which goes beyond the existing formats, like Gerbers or like IPC-2581.

Goldman: What is the status of CircuitData?

Lydersen: We have a beta version released, open-sourced. Also we've established a board of directors where we have a seat. There are still more seats, so we're open for more members. Currently, in addition to Jan Pedersen from Elmatica, we have a representative from the German manufacturer ILFA who focuses on the high-tech part of the PCB industry, and we have one representative from IPC.

The reaction so far has been that people understand that the lack of a common language is a challenge that needs to be addressed. Everybody is talking about automating their processes and shop floors but nobody is addressing this, apart from this project. So we do get a lot of acceptance, and we're also seeing some early adopters starting to implement the language.

That's the status. We've gone as far as we can on our own. We took our accumulated knowledge based on those 46 years, and we wrote that down into a language, gave it away, and said, "Okay, so now we need more people to join in." If you look at the forum on circuitdata.org, you'll see that people are contributing and they see this as an opportunity to cut down on the need for man hours.

Goldman: Basically, CircuitData is a language to help designers and PCB manufacturers communicate more effectively, correct?

Lydersen: Yes, it is. You can divide it up into three parts. First is the vocabulary itself—what do they call what we're working with? Over the years people have been referencing the same process in many ways.

Goldman: I was reading a column by Mike Carano on the defect called mouse bites, which is a rather strange term but we've used this term forever, and I thought, "We still say mouse bites?" And I know there are other terms used for that defect. We do need to upgrade our language.

Lydersen: That's very true. It's all over the place. There are two ways of solving this. Either you can add a layer of some sort of artificial intelligence that understands that, okay, you call it mouse bites in your PDFs when you send it to us, and we call it tear-off or whatever. But that takes a lot of work, so the correct way of doing it, in my opinion, is agreeing on what we call it.

Back to the three parts; you have the vocabulary, and then you have the syntax, which is the grammar of the language. When I send you some information, do I do it in a PDF or do we use another syntax so that it's machine-readable? And the third and last part is called a schema, which is that combination of the two. It's like a teacher that looks through your vocabulary and your syntax and it tells you immediately if it's right or wrong.

The hope is that you can use the three parts of the language machine-to-machine, but also machine-to-human, of course. So you could end up generating PDFs that are in the same language, and that would be a lot better than PDFs in different languages, but ideally you would end up with systems communicating to systems, and solving their issues in getting the price or lead times or whatever they need to get.

Goldman: I guess you've got several challenges, but what do you see as your next steps?

Lydersen: The next immediate step is to have more members on the board, members who have an interest in implementing CircuitData. We're looking for some big players that can join, but also the main influencers.

Goldman: So you need not just other PCB manufacturers but you need the end-users, the designers, and maybe the assemblers to participate?

Lydersen: Yes, we need the whole supply chain. We also need the technical people, IT guys like me, involved in the industry, to write the code. Apart from that, I think you asked about the challenges. The challenges are that, as I said, the people who should be interested in this, the end-users or the owners or OEMs or EMS providers, they don't see this as an actual challenge. They have solved it in their eyes; they're just writing it down in their languages and sending it off. And then somebody else needs to go through it and interpret it. They don’t see it as their problem.

But what they don't think about is that it's costing them time, because if there are complications further down the line—and in our experience, there are in 90% of the cases—it's going to raise some engineering queries or something and then they're kind of stuck. They need to wait for translations. The other part is that quality is an issue, right? They don't know what they're comparing, they ship off their specifications in their language, and they receive quotations back, but they don't know if it's the same product.

Goldman: Do you have some timeline goals to get this going along further?

Lydersen: We had hoped to launch Version 1.0 of the language in November, but due to the activity in the forum and things that people needed to add, we're now looking at February.

Goldman: Are you thinking of launching this at IPC APEX EXPO?

Lydersen: The board is going to be present at APEX, and there will be a presentation about it. We had some issues to start with because the subcommittee for IPC-2581 looked at this language as a competing initiative; but in our opinion, it's not. All the formats have an approach to the market where the end user is the one who creates the product in a given format, and then ships it off. And the more they can cover, the better, right? So that's why they're developing their languages; but in our opinion, everybody in the supply chain adds or subtracts from the specification. A format is not enough; you need a language to top that off. When they understood that, then they were on board, so I don't think we have that issue anymore.

You were talking about the timeline. That's version 1.0. What we need is for people to start implementing it in their system, to use it. Releasing version 1.0 is great, but we need use cases. We already have a small-use case, a software company called KwickFit, in Florida, that implemented it immediately. Elmatica is developing software that we released a live version of in December, and we're releasing a new one in March, hopefully just after the release of version 1.0.

Who’s using it is a more interesting thing. We went on a trip to China a few weeks ago, just to look at the challenges there, and what their view on a language like this is. What we found is that almost everybody has some sort of automation project going on. They're automating their shop floors, adding robots, and cutting down on staff, but when it comes to their engineering departments, they are growing; it's the other way around. I mean, they can't do anything. The more quotations they want to answer, the more people they need to look through the material. They were all on-board and wanted this to happen. That was a great adventure and we are working with a couple of big companies over there.

Page 1 of 2

• Next Page >