Building and Certifying an Open-Source IoT Controller, Part 2: Open-Source Certification

In Part 1 of this series, we introduced the Anthilla Controller project and discussed the benefits of making its hardware open source. Now, in Part 2, we’ll look in more detail at what an open-source certification entails. The goal is twofold: to help clarify the certification process for designers, and to explain what makes a project certifiably open-source. We’ll begin with the latter.

 

What Makes a Project Open Source?

The Open Source Hardware Association (OSHWA) defines “open-source hardware” at length on their website. Essentially, however, a hardware project needs two things to be considered open source:

1. Publicly available documentation.
2. An appropriate open-source license.

Separate from the open-source hardware definition, OSHWA recommends that projects include four basic elements:

1. Hardware.
2. Software.
3. Documentation.
4. Branding.

Of these, only hardware and documentation are compulsory to gain an Open Source Hardware certification (Figure 1). If software isn’t included, ‘documentation’ refers only to documentation of the hardware. Either way, the documentation must have an open-source license, as per the definition above. We’ll discuss licensing later in the article.

 

Figure 1. Anthilla Controller board with Open Source Hardware certification (lower right corner).

 

For the Anthilla Controller, we decided to forgo including software in either the file repository or the license. The AnthC is a flexible IoT hardware platform, so the software code differs depending upon the application—making a specific code available and maintainable wouldn’t help most users. Nevertheless, it’s possible that in the future some code to test the basic functionalities and verify the assembly of a new board will be uploaded.

This leaves the hardware documentation, which can be broken down into three categories:

1. The schematic.
2. Manufacturing files.
3. Assembly files.

Together, these allow a new person to replicate or maintain the project. We’ll discuss each of these categories individually—along with the importance of documentation more generally—in the next section.

 

Documentation

It’s a common pitfall to think nothing else needs to be done once the product starts to work. Documentation is as important as the design phase, and well-organized documentation is what makes a project accessible and popular.

Sharing the project documentation is one of the main requirements of certifying a project as open source. Once the files are shared, another person can then use them to replicate the project, to repair the product, or even just as a learning tool. The important thing is that this transfer of information should be done without the intervention of the project’s creator.

As noted above, open-source hardware documentation should include manufacturing files, assembly files, and a schematic.

 

The Schematic

The electronic schematic describes the logical connections between the elements of the board. It’s useful both for understanding the goal of a system and for learning about specific parts of the electronic design. Since the readers might not have the appropriate design tool, it’s a good practice to generate a PDF with all the schematic sheets.

The schematic should be readable by people who are new to the project, so it needs to be well-organized and clear. Figure 2 shows the Anthilla Controller’s schematic diagrams—note that the different functional areas are separated into blocks to make them easy to find.

 

Figure 2. Schematic for the Anthilla Controller M2-R3.

 

Manufacturing Files

The manufacturing files serve to replicate the PCB. Manufacturers don’t need the native CAD files, which we generated using KiCAD. Instead, they use a specific set of files that are generated from the native files. These can be:

• ODB++ files.
• IPC-2581 files.
• Gerber and drill files.

The manufacturing files for the Anthilla Controller are formatted as Gerber and drill files. These are easily generated with KiCAD, and are a common choice for that reason.

 

Assembly Files

Assembly files serve to complete the project build by specifying what exact components should be assembled on the board. In the early stages of development, they also help to estimate the price and the lead time. These files include:

• The Bill of Materials: lists all the components.
• The Pick and Place file: shows where, and in what orientation, components should be placed.

Now that we’ve covered the documentation, let’s talk about licensing.

 

Licensing

Open-source projects are made to be shared. An open-source license defines the parameters of that sharing by telling others how your intellectual property (IP) can be used. Choose your license carefully—a mistake here can have a major impact on the project, particularly if there are specific commercial interests to protect.

The entire project doesn’t need to use a single license—it’s possible to use one license for the hardware, another license for the documentation, and a third for the software (if applicable). The AnthC chose the following licenses:

• Hardware: CERN-OHL-W-2.0.
• Software: no license needed, as there’s no software to be certified.
• Documentation: Creative Commons CC0-1.0.

Our main goal when licensing the Anthilla Controller was to ensure that the controller could be used by as many people as possible. We also wanted future products that included the controller to be accessible. Finally, we expected the software to change as the controller was adapted to each application. It was with these goals and expectations in mind that we picked out the AnthC’s licenses.

The CERN Open Hardware License (OHL) is widely used in the open-source community. As the name suggests, it was specifically designed for hardware projects. There are three subclasses of this license:

• Strongly reciprocal (CERN-OHL-S): somebody using your product should distribute the subsequent products under the same license type.
• Weakly reciprocal (CERN-OHL-W): somebody using your product is not forced to distribute the rest of the components (those not included in your original project) under the same license type.
• Permissive reciprocal (CERN-OHL-P): there is no obligation to distribute the sources when shipping your product.

As stated above, we chose to use the weakly reciprocal version of the license.This is a copyleft license, meaning that derivative projects (those based on the licensed project) must be released under the same license as the original project. Because it’s only weakly reciprocal, this only applies if the new project directly modifies the AnthC. The AnthC can be used as a component of new, non-open-source projects.

For our documentation, we went with a permissive Creative Commons license that put our files into the public domain. While we didn’t license software for the AnthC, Creative Commons licenses are also frequently used for that purpose.

 

Next steps

At this stage the project is stable: the documentation is versioned and all the hardware files are frozen. In Part 3, we’ll discuss product testing and the manufacturing process. We’ll also talk about some challenges related to component obsolescence that arose at this point.

 

Editorial note: The Anthilla Controller’s initial development, testing, and manufacturing was made possible by funding from Anthilla, but the company is not currently involved with the project. Neither All About Circuits nor the author of this article receive any financial benefit from Anthilla for the article’s publication.

 

All images used courtesy of Ignacio de Mendizábal