Skip to main content
Monthly Archives

March 2018

Linuxgizmos: Civil Infrastructure Platform wants Linux to save civilization

By In the News

At the Embedded Linux Conference conference, Civil Infrastructure Platform contributor Yoshitake Kobayashi talks about the CIP project’s progress in bringing a 10-year SLTS Linux kernel to the world of power plants and transportation systems.

“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.”

Read more at Linuxgizmos.

Linux.com: Civil Infrastructure Platform Sets Out to Save Civilization

By In the News

“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.”

Read more at Linux.com.

CIP Member Spotlight: Codethink

By Blog

The Civil Infrastructure Platform (CIP) project aims to speed implementation of Linux-based civil infrastructure systems, build upon existing open source foundations and expertise, establish de facto standards by providing a base layer reference implementation, and contribute to and influence upstream projects regarding industrial needs. CIP is driven by some of the world’s leading manufacturers of civil infrastructure systems and industry leaders including Codethink, Hitachi, Plat’Home, Renesas, Siemens, Moxa and Toshiba.

This spotlight series highlights CIP members and how they are contributing to open source software solutions that will benefit the world’s technical systems. Today, we highlight Codethink in a conversation with Agustín Benito Bethencourt, Principal Consultant and active CIP member.

What does your company do and what is your role?

Codethink is an independent engineering and consultancy services company. We specialize in system-level infrastructure to support advanced technical applications, working across a range of industries including finance, automotive, aerospace, medical and telecoms. We deliver critical technology services and solutions for international corporates. We develop and maintain system-level software and infrastructure within three practices: Enterprise, Devices and Automotive.

We have a wealth of experience in truly understanding the software development life-cycle and are happy to provide specialist expertise to slot into an existing project/product team, or to handle the turnkey supply of a complete solution to a managed budget, time or quality. We are experts in Free and Open Source Software (FOSS). We participate in upstream and are active contributors to a wide range of FOSS projects.

As a consultant at Codethink, I have two main roles: I help customers to transition from traditional embedded delivery models to modern ones, embracing Open Source best practices and agile principles, either in R&D or in production environments with a special focus on automotive at the moment. Additionally, I represent Codethink at The Linux Foundation and CIP project.

Why is your company investing in an open source “base layer” of industrial grade software?

Historically, Codethink has a very strong Open Source Software background. We believe that within the civil infrastructure industry there is plenty of room for sharing effort in the open, to create a commodity base system that can be maintained and shaped long term, enabling numerous stakeholders to participate and consume such software and knowledge for product development. Open Source ecosystems offer good opportunities for companies like Codethink to learn and demonstrate capabilities by actively participating in and contributing to CIP.

Why did your company join CIP?

Modern software practices are moving towards producing and deploying software fast enough so that it can be kept up to date. A significant part of our business revolves around that idea. There are environments though, in which following this approach is particularly challenging. The Civil/Social Infrastructure industry is one of them.

When it comes to software delivery or maintenance, for instance, the time perspective and economics for developing products that will still be operating in 50 years, is new to most of those coming from Open Source, especially when applied to safety critical environments. This is the main reason we wanted to participate in the foundation of CIP. The Linux Foundation project represents – for us – the perfect forum to challenge ourselves while helping others to embrace an Open Source mindset.

How are you currently active in CIP?

Our previous experience in open source community environments, helped Codethink to play an important role in shaping and foster CIP as an open source forum. As the project shifted its focus to the CIP kernel, Codethink led the testing and maintenance effort. We currently share the responsibility with Siemens, who is managing the real-time version of the CIP kernel we maintain.

Additionally, Codethink supports CIP on several other fronts such as promotion, content creation, participating in CIP governance forums, building strategic relations with other projects, etc.

How are you going to use the software?

Since Codethink is a consulting company, we don’t ship products based on CIP’s industrial grade software, but some of our customers do, especially those in industries where safety is critically important. For example, our Automotive OEMs customers are great candidates for the software.

What benefits have you seen or what do you expect to achieve?

In the kernel front, for instance, CIP takes advantage of all the work done by the kernel community on the 4.4 LTS process. CIP is adding additional effort to that process, contributing directly upstream instead of creating a separate and independent process where upstream is just an input, which requires additional effort to close the circle when contributing back to upstream. Our current simple process has proved to be very efficient.

Once the current LTS process ends, CIP will be maintaining such a critical component on its own. That will be the moment of truth for CIP. The same will apply to the rest of the components of CIP’s “base layer”, called CIP Core, which relies on Debian sources.

If the learning process we are currently following at CIP is successful, and the consolidation of the project reaches the required activation threshold, CIP will become a key forum for all those parties that ship long lasting Linux based products. Otherwise, the scope of the Initiative will be solely determined by the needs and efforts of the current members which, looking at the size of some of them, might be a bright future too.

Where do you see civil infrastructure systems in 20 years?

I see civil infrastructure systems following the general path that embedded industries and automotive are following, where the commoditization of part of the software stack is the only approach to tackle the increasing complexity, leaving enough resources to focus on differentiation factors that add value to customers. This process should push companies towards sharing more effort and resources. Open Source enables the healthiest environment in which to do so.

I think that the same principle will apply to safety critical related systems, although the adoption there will probably be slower but inexorable.

In summary, the overall transition from being Open Source consumers to producers first and contributors later, will take place faster than most think, just like it has in other industries before the Civil/Social Infrastructure.

LWN.net: Super long-term kernel support

By In the News

ome years ago, prominent community leaders doubted that even short-term stable maintenance of kernel releases was feasible. More recently, selecting an occasional kernel for a two-year maintenance cycle has become routine, and some kernels, such as 3.2 under the care of Ben Hutchings, have received constant maintenance for as much as six years. But even that sort of extended maintenance is not enough for some use cases, as Yoshitake Kobayashi explained in his Embedded Linux Conference talk. To meet those needs, the Civil Infrastructure Platform (CIP) project is setting out to maintain releases for a minimum of 20 years.

Read more at LWN.net.

Real-time patchset for the CIP Kernel

By Blog

By Daniel Wagner, CIP member and kernel maintainer and Embedded Linux Developer at Siemens AG

CIP aims to establish a “base layer” of industrial-grade tooling using the Linux kernel and other open source projects. This base layer will be available for use by developers creating software building blocks that meet safety, security, reliability and other requirements that are critical to industrial and civil infrastructure projects.

As part of this mission, CIP provides super long term support (SLTS) for the kernel. This is an important base and the CIP kernel maintainers, like myself and Ben Hutchings, are working within various environments in order to meet Industrial Grade requirements. As we’re working on the SLTS, we realized that it was missing the real-time aspect of the operation system.

While the Linux Foundation’s Real-Time Linux collaborative project is working on getting the final features from the RPEEMPT_RT patchset into mainline kernel, there is no direct support a -rt flavor for the CIP kernel. There are stable real-time patches for 3.2, 3.10, 3.18, 4.1, 4.4 and 4.9. They are based on top of the LTS trees maintained by Greg Kroah-Hartman, Sasha Levin and Ben Hutchings.

The use cases CIP project is targeting have a life cycle of for more than 10 years. In theory, this is the time in which products shipped with the CIP kernel will be under maintenance. However, identifying and backporting relevant fixes becomes increasingly difficult as upstream kernel development diverges further from a stable branch. Any given SLTS branch is unlikely to be maintainable for more than 10-20 years.

Since the first CIP kernel is also 4.4 based, maintaining a variation of the 4.4-rt stable patchset is possible without too much overhead. The CIP real-time patchset will be follow the 4.4 stable-rt patchset as close as possible. The stable-rt patchset won’t gain new features (e.g. hrtimer rework, cpu hotplug rework, no_hz fixes) because backporting has a high risk of breaking stable-rt. Therefore, the stable-rt maintaining goals overlap with the cip-rt goals, which allows keep the variations of the real-time patchset smaller.

For more details, visit the CIP kernel maintenance wiki page. If you want to join the conversation or ask questions, subscribe to the CIP Dev List.