“The Civil Infrastructure Platform is the most conservative of The Linux Foundation projects,” began Yoshitake Kobayashi at the recent Embedded Linux Conference in Portland. Yet, if any eyelids started fluttering shut in anticipation of an afternoon nap, they quickly opened when he added: “It may also be the most important to the future of civilization.”
The Linux Foundation launched the Civil Infrastructure Platform (CIP) project in April 2016 to develop base layer, open source industrial-grade software for civil infrastructure projects, starting with a 10-year Super Long-Term Support (SLTS) Linux kernel built around the LTS kernel. CIP expects to add other similarly reusable software building blocks that meet the safety and reliability requirements of industrial and civil infrastructure. CIP supports electrical and power grids, water and sewage facilities, oil and gas plants, and rail, shipping and transportation systems, among other applications.
“Our civilization’s infrastructure already runs on Linux,” said Kobayashi, a CIP contributor and Senior Manager of Open Source Technology at Toshiba’s Software Development and Engineering Center. “Our power plants run on Linux. If they stop working, it’s serious.”
CIP’s OSBL may not be disruptive technology, but its aim is to more quickly and affordably bring disruptive tech into projects whose lifespans extend for a half century or more. The goal is to reduce development and testing time so that the latest clean energy equipment, IoT monitors, AI edge computing, and smart city technology can come online more quickly and be updated in a timely manner.
With standardization, open source licensing, and greater reuse of software, CIP plans to reduce duplication of effort and project costs, as well as ease maintenance and improve reliability. “We can provide the stability needed by infrastructure by using Linux,” said Kobayashi.
In many ways, CIP is like The Linux Foundation’s Automotive Grade Linux project in that it’s trying to more quickly introduce the latest technologies into a traditional industry with long lead times. In this case, however, the development times and product and maintenance lifespans can last decades.
Kobayashi explained that a power plant has a life cycle of 25-60 years. The technology takes 3-5 years to develop plus up to four years for customer specific extensions, 6-8 years for supply time, and 15+ years of hardware maintenance after the latest shipment.
“Things change a lot in 60 years, such as IoT, which requires security management and industrial grade devices,” said Kobayashi. Yet, bringing these technologies online is slowed by rampant duplication of effort. “In civil infrastructure, you typically have many companies doing industrial grade development and long-time support even if their business areas are quite similar. There’s a lot of duplication.”
In his talk, Kobayashi gave an overview of CIP’s first two years and shared plans for the future. CIP’s founding members – Codethink, Hitachi, Plat’Home, Siemens, and Toshiba – have since been joined by Renesas, which last October announced that the Linux stack for its Arm-based RZ/G SoCs had been upgraded to use CIP’s 10-year SLTS kernel. In December, CIP was joined by Moxa.
Upstream first, backport later
Unlike AGL, CIP is not developing and maintaining a full Linux distribution. CIP’s Open Source Base Layer (OSBL) is aligned closely with Debian, but it’s also designed to be usable with other Linux distributions.
Kobayashi emphasized that CIP is working closely with the upstream community. “We created a kernel maintenance policy where the most important principle is ‘upstream first.’ All features have to be in the upstream kernel before backporting to the CIP kernel.” Kobayashi added that out-of-tree drivers are unsupported by CIP.
The CIP project initially focused on the SLTS kernel, maintained by Codethink’s Ben Hutchings. New builds have come every 4-6 weeks, adding features such as security patch management.
The most recent, Mar. 9 Linux 4.4.120-cip20 build, based on linux-stable-git, adds Meltdown and Spectre fixes as well as backported patches, such as support for the Renesas RZ/G SoCs and Siemens IoT2000 gateway. It also includes a Kernel Self Protection Project that includes ASLR for user space process, GCC’s undefined behavior Sanitizer (UBSAN), and faster page poisoning.
Over the last year, the project has focused on real-time support. The first CIP SLTS real-time kernel was released in early January based on Stable RT Linux with PREEMPT-RT. The problem here is that Real Time Linux is not yet fully upstream. “We need it immediately, so we are trying to help the RTL project by becoming a Gold member,” said Kobayashi.
More recent projects have included the creation of an environment for testing kernels called Board At Desk (B&D), based on KernelCI and LAVA. The current focus is kernel testing, but CIP plans to eventually test the entire OSBL platform.
CIP is also developing a CIP Core implementation with minimal filesystem images for SLTS that is designed for creating and testing installable images. The project is currently defining component versions for its CIP Core package, which “is difficult because you have to go upstream,” says Kobayashi. “We decided to use Debian as the primary reference distribution, so CIP Core package components will be selected from Debian packages. We have begun to support the Debian-LTS project at the Platinum level.”
CIP has created a build environment for CIP Core based on Debian’s native-build system. The environment supports a Renesas RZ/G based iwg20m, which appears to be another name for iWave’s iW-RainboW-G20M-Qseven module. Other targets include the BeagleBone Black, Intel’s Cyclone V FPGA SoC, and QEMUx86.
The main challenge with aligning CIP with Debian is that Debian-LTS “is only five years but we need 10 years,” said Kobayashi. In addition, while CIP supports both Debian’s native-build and cross-build technology, Debian does not currently support cross-build. However, a Debian-cross (CrossToolchains) project is under development.
Next up: Cybersecurity and Y2038 protections
The CIP SLTS kernel and OSBL platform will have a major release every 2-3 years, so a new release can be expected in 2019. Potential additions include support for the ISA/IEC-62443 cybersecurity standard for industrial automation and control. “We think we can help developers gain certification, but we are not planning to develop procedures or certification schemes,” said Kobayashi.
CIP is also planning workarounds for the Y2038 bug. A Y2K-like computer clock crisis could occur in 2038 because 32-bit systems won’t be able to tell the difference between 2038 and 1970, the genesis year of 32-bit timing schemes.
The v2 release will also add some functional safety and software update code, and potentially add support for The Linux Foundation’s EdgeX Foundry IoT edge computing middleware standard. The main issue here, says Kobayashi, is that unlike EdgeX CIP’s OSBL does not support Java. Debian does, however, so there may be a fix.
Kobayashi concluded by emphasizing that “kernel version alignment is important” to CIP. At the Open Source Summit Japan (June 20-22), CIP is hosting an F2F meeting with participants from LTS/LTSI, AGL, and Debian.
The slidedeck and 47-minute video of “Civil Infrastructure Platform: Industrial Grade Open Source Base-Layer” are now available. You can watch the complete presentation here:
