Today, CIP is thrilled to welcome IoT.bzh as the newest member of the project. The Civil Infrastructure Platform strives to create an open source “base layer” of industrial-grade software to enable the use and implementation of software building blocks in civil infrastructure projects. Embedded systems are key to the civil infrastructure. IoT.bzh’s expertise in IoT and embedded as well as its deep history with open source, make them a welcomed voice to the CIP Project.
“As we enter into an era of ongoing security risks to our most critical infrastructure, things like updates and security are crucial. Now, more than ever, supporting CIP means investing in the long term support and maintenance on the very foundational infrastructure we all rely on, said Yoshitake Kobayashi , Technical Steering Committee Chair of CIP. “For that, we are thrilled to have IoT.bzh as a new CIP member”
IoT.bzh, leading open source company for secured embedded systems provides redpesk®, a software factory in a white box enabling users to speed up and control embedded developments from the initial design cycle until product end of life. IoT.bzh works with developers from Industrial IoT markets (automotive, marine, military, energy, aeronautics etc) to help them focusing on the differentiating applications that bring value to their business
“We are thrilled to welcome IoT.bzh to the CIP Project. As an organization, they have great experience with helping the very audience CIP also aims to support,” said Urs Gleim, CIP Board Chair. “As members of the CIP Project, we look forward to working together.”
Interested in becoming a CIP member, learn more here.
Today, the Civil Infrastructure Platform has multiple requirements that need to be maintained. This is where the CIP Testing Work Group (TWG) comes in. The TWG configures and manages the automated test infrastructure for the CIP project and ensures all systems are operating correctly. Currently led by Chris Paterson (patersonc), the TWG’s main focus is on maintaining the LAVA instance that the project uses. Overall, the TWG provides the infrastructure needed to test the various CIP projects such as the Super Long Term Support (SLTS) Kernels and CIP-Core reference filesystems.
The CIP project aims to provide support for the Linux Kernel for a comparatively long time. Over time the amount of testing required will keep increasing as the project grows, so it is important to have as much of that testing as automated as possible. Without automation, the cost of testing would be prohibitive.
Under the hood
Our Continuous Integration (CI) setup is driven by GitLab CI/CD which dynamically boots up AWS EC2 on-demand instances for our build jobs using our gitlab-cloud-ci tool.
Test jobs are also created and submitted to our LAVA instance, where they are run on QEMU virtual machines and on physical devices.
The GitLab CI pipelines that we use to build/test the Kernel are hosted in a separate GitLab repository.
Currently, CIP has two LAVA master instances (production & staging) and 5 LAVA workers (Cybertrust, Denx, Mentor, Renesas & “Chris” (staging)) in use, hosting a total of 284 devices.
We support all of the CIP reference platforms. We are working to expand the number of devices available, increasing reference platform availability whilst reducing test times.
Testing WG and the ecosystem
This group is a critical part of the overall CIP ecosystems, working with other CIP WGs as well as external open source projects. For example, CIP Testing works with all of the other CIP projects and working groups as most, if not all require the ability to test their software. Outside of CIP the testing group collaborates with other open source projects such as KernelCI, LAVA and Linaro’s test definitions. CIP also builds and boot tests each stable Linux Kernel release candidate in a number of different configurations.
On the Horizon
CIP has recently started work on their third SLTS Kernel, based on v5.10.y, which means that our automated testing needs to be expanded accordingly.
On the roadmap is collaborating further with the KernalCI project on testing management. The TWG is currently working with the KernelCI project to set up CIP’s own instance of KernelCI’s back/front-end. This will allow the project to better manage its testing and automatically process and check the results for any regressions. The front-end GUI that KernelCI provides is much better for reviewing test results then the setup CIP is currently using.
Get Involved
We are always happy to collaborate with others to expand and improve our setup, whether it’s upgrading the core infrastructure or simply adding support for more test cases.
The Civil Infrastructure Platform has several work groups that ensure things keep running. Below is a Q and A with the CIP Kernel Team.
1. What is CIP Kernel Team (What does this team work on, what issues does it solve)
While the CIP project aims to establish an open source base layer (OSBL) of industrial grade software to enable the use and implementation of software building blocks for civil infrastructure, CIP Kernel Team is responsible for Linux kernel in OSBL to sustain industrial grade systems or devices during their life cycles.
2. What is the primary goal of this team?
The goal of the team is to provide CIP kernels with more than a ten year maintenance period by fixing versions to fulfill the required level of reliability, sustainability, and security.
3. What is the development principle of CIP?
CIP adopts the upstream first as our development principle. The “Upstream First” principle allows patch commits only if those patches are already in the upstream. By following this principle, if a desired patch is not in the upstream yet, this patch should be accepted by the upstream at first. Therefore, it may take time to introduce the desired patch to our project.
But, it enables us to share our outputs with the upstream. At the same time, the risk of conflicts can be eliminated.
CIP is aiming to sustain target systems and devices during their life cycles which are very long by their nature. So the Upstream First principle is essential to achieve our goal.
4. What is “Upstream First” for the Kernel Team?
For the CIP kernel team, upstreams are Linux mainline and LTS. The team collaborates with upstream projects. Before using their outputs, the team upstreams what the team has and doesn’t keep them locally.
As marked 1, “Contribution” is our first action. Feature upstreaming is done by CIP member developers. On the other hand, the CIP Kernel Team contributes to upstream in a more general manner. The team developed open source tools in order to work on contributions effectively..
As marked 2, “Use” is the second action. The team uses LTS kernels to release CIP SLTS kernels. For those releases, automated testing plays a very important role. Therefore the CIP kernel team is closely working with the CIP testing team.
As marked 3, “Integrate” is the third action. By integrating those SLTS kernels with CIP Core packages and additional packages, industrial systems or devices can be developed and maintained.
5. How does the team use LTS kernels?
The team uses LTS for CIP SLTS kernel bases.
CIP SLTS kernels are based on LTS 4.4 and 4.19. The first releases of SLTS 4.19 and 4.19rt were done in 2019. The team plans to maintain them until 2029 for ten years. The first releases of SLTS 4.4 and 4.4rt were done in 2017, and likewise the team supports them for ten years till 2027.
Both LTS 4.4 and 4.19 are maintained for 6 years by the LTS project. So, the remaining 4 years will be maintained by the CIP Kernel Team.
6. How can CIP kernels be used?
By integrating the SLTS kernels with CIP Core packages and additional packages, industrial systems or devices can be developed.
CIP refers to Debian for userland packages. If you would like to use Debian source packages, you can use Yocto/Poky as a build system.
CIP core packages contain tens of packages which may not be sufficient for the development of end products. So, you can add necessary packages from Debian by writing recipes.
7. What has this team accomplished so far?
Currently SLTS 4.19 is released twice a month and 4.4 is once a month. SLTS 4.19-rt is once a month and 4.4-rt once every two months.
So far the team has steadily released CIP SLTS kernels by following release frequencies below.
(as of June 7, 2020)
8. What are some future goals?
The team made major releases in 2017 and 2019. So, a major release frequency is once per two years so far. Another two years is going to pass, and Year 2021 is approaching. So, the team started to discuss new SLTS kernels.
9. How can people get involved?
To get the latest information, please subscribe and contact:
