Creating OECL IDs

19 May 2014 | Three-minute read

In the last post, we saw that IDs link things together. In practice, you could use anything for the IDs, as long as both the ID and the reference are the same.

Universally Unique IDs are Important

Just because you can doesn’t mean you should. In this case, you really shouldn’t and the format specification tells you you shouldn’t. In fact, the format specification tells you to make them universally unique. But why?

Two reasons. Let’s suppose you get an OECL file from a manufacturer and you import it to your software. The manufacturer now finds a mistake in the file and releases an update and you import the new file to your software. Ideally, it should replace the old definition (or archive it in some way), but to do that, you need to know which items to replace. IDs tell you which items to update, but that only works if the IDs are universally unique.

Or instead, let’s suppose that rather than containing all information in a single file, but instead, it is spread over multiple files. The ID reference, if it contains a fully formed URL followed by the file local ID, might give you a way to spread information among multiple documents. A stable ID facilitates linking multiple files together.

There are no products that work like this, and you shouldn’t infer that any are in any plans. But, this should tell you why well created IDs are important.

Creating a Universally Unique ID

IDs in OECL should be unique, but they should also be reproducible for the same component, model, etc. If two people independently create the same component in different software, the component should be assigned the same ID because it is the same component which facilitates updating components in a database (library). But there is no registration process, so this is not entirely possible.

Developers (or model writers) should a best effort to construct IDs in a consistent manner so that the same component created in the same software will be assigned the same ID. The OECL format describes a recommended way to achieve this.

To ensure uniqueness, identifierType instances should be written in reverse domain name notation. The reverse domain name notation should include a company/organization name, a category for the identifier, and a unique name for the item. Items that comply with a published standard, such as should include the standard body, a category for the identifier, and the unique name for the item.

This means the identifier should look like

1. com.company_name.category_item
2. org.standards_body.category.item

The OECL format description suggests the following identifier categories:

Let’s look at the LM7121 from Texas Instruments as an example. It has multiple part numbers and it is available in multiple packages.

The component would have the following IDs