Monday, March 13, 2017

Why Codethink is a founding member of the Civil Infrastructure Platform, a Linux Foundation initiative

This blogpost was originally published on the Codethink website on Thursday March 9th.

On April 4th 2016 a new Linux Foundation initiative called the Civil Infrastructure Platform was announced. CIP aims to share efforts around building a Linux-based commodity platform for industrial grade products that need to be maintained for anything between 25 and 50 years - in some cases even longer. Codethink is one of the founding members.

Industrial grade use cases

In order to describe why this initiative is relevant let me go over the use cases that motivate companies like Siemens, Toshiba, Hitachi, and Renesas to share efforts.
During the Open Source Leadership Summit, Noriaki Fukuyasu (Linux Foundation) and myself, based on the experience of Siemens, Hitachi and Toshiba, described the development life cycle in industrial grade use cases. For example, a railway management system is as follows:
  • Analysis + design + development: 3 - 6 years
  • Customizations and extensions: 2 - 4 years
  • The certification process and other authorizations take a year.
  • Each new release or update has to go through further certifications and authorizations that take between 3 and 6 months.
  • The system is expected to work for between 25 and 50 years.
So on average, an industrial grade product might take 5 to 7 years from conception to deployment. This is coherent with our experience in other industries like automotive, where life cycles are also quite long despite the expected lifetime being shorter.

A key part of the life cycle is maintenance. Due to its length, the associated risks are high. The certification processes to introduce significant changes in any already deployed systems are painful and expensive. In addition, the capacity to simulate a production environment is, in general, limited. This is true in other cases like energy production plans, for instance.

Open Source principles in the Civil Infrastructure industry

It’s obvious that Open Source could have a dramatic impact in this industry. By sharing efforts, corporations can commoditise a significant portion of the base system focusing on differentiation factors, increasing control through transparency and the quality of that starting point over time. Collaboration with upstream will bring even higher impact benefits.
Two immediate challenges come to mind when thinking about Open Source in this industry:
  • Development of processes and practices to produce software for safety critical environments.
  • Bridging the gap between the Open Source approach for software maintenance and the approach currently taken when building large-scale platform projects. For instance, how can approaches oriented to update any specific Open Source software component to the latest upstream stable version be compatible with any typical industry SDLC?

Can you reduce the gap?

We have for years been working on transformation projects for which one of the goals has been to reduce the gap between the software our customers ship and what upstream is continuously releasing. One of the key steps is to adapt an organisation’s processes using FOSS tools. Over the years we have been a strong advocate that the closer to upstream you are, the more benefits you reap from the Open Source development model, maintenance cost reductions being one of the main advantages.

So why did we get involved in an initiative that aims to maintain a kernel for 25 years then?

The short answer would be... because we love a challenge!

Safety critical with Linux-based systems is a challenge currently being faced in the automotive industry for instance, where Codethink is a strong player. When we analysed some of the industrial-grade use cases, it called our attention not just to the magnitude of the second challenge enumerated above, related with super long term maintenance, but also the apparent conflict between the industry requirements and the referred well known Open Source practices.

Hence the main driver for an Open Source consultancy like Codethink in participating in an initiative like CIP is to learn by doing, that is, putting the Open Source development, delivery and maintenance best practices under stress in one of the toughest environments. We bring our experience in producing embedded Linux based systems and our Open Source culture, to work together with industry leaders in finding solutions to these challenges, by looking at them with FOSS eyes.

Current activities

Codethink is participating in CIP in several capacities, the most relevant being:

Kernel maintenance
The first CIP approved kernel is 4.4, an LTS kernel supported until Feb 2018. Ben Hutchings is the initial CIP kernel maintainer. Besides providing support for the reference platforms, Ben is working on several activities like backporting the security patches, such as those from the KSPP and consolidating the maintenance policies, taking those from the kernel community as reference.

Testing tooling is the most successful testing project in Open Source. Its impact in the kernel community is growing, as is the number of people and companies involved. It was designed and developed as a service where the testing activities can take place in distributed board farms (labs).

Codethink has been working on making the tools easy to deploy on developer machines through a VM, so they can test kernels on directly connected boards. This first milestone of the CIP testing project is called Board At Desk - Single Developer. This activity was described at the Open Source Leadership Summit 2017 and the first beta released during ELC 2017.


The challenges for Open Source that Industrial-grade product development and maintenance introduce are great, especially in two aspects: safety-critical and maintenance. Codethink is working on CIP to help the industry to overcome these challenges by adding our Open Source perspective.

Learn more about the CIP project by checking the following slides and videos from the conferences in which CIP members have participated.

Sunday, March 05, 2017

Automotive supply chain and Open Source: a personal view

Software in automotive yesterday
The automotive industry has treated software like any other component, as part of the traditional, well structured and highly controlled supply chain. Tier-1's has been providing software to car auto-makers for some years now and both together have done what they have could to prevent consumers or downstream players in the supply chain from manipulating it, improving it, customising it nor from adapting it. It didn't matter if the software was Open Source or not, they have treated it as if it was proprietary, promoting locked-in practices. Only very few stakeholders with the right kind of agreement could manipulate it in a very limited way. Consumers and third parties didn't have a say.

For a software company, there has been no life outside the traditional supply chain of any auto-maker.

Automotive yesterday

From all the reasons I've heard since I am involved in automotive, that justifies this situation, arguments related with security together with the safety critical nature of some systems shipped in a car are among the most popular ones.

But wait, once I buy a car, I can manipulate or even change the engine, the suspensions, the tiers, the brakes... but I can't even dream about changing the software? Eveny if it is Open Source?

Software in automotive tomorrow

In my opinion the current way software is treated by automakers, the supply chain associated to them and the current business model around software in automotive will change dramatically. And the main reason will not be the license of the software used but the fact that the increasing amount and complexity of the software shipped with any car, together with the challenges that connectivity and privacy bring, will open up the door for new new players with new business models, Open Source business models. Those new factors will also provide current stakeholders in the supply chain the opportunity to increase their services around software. New players will challenge the current controlled and centralised environment.

I believe the software supply chain will expand beyond the purchase of the car, providing inputs at every level. Initially this will take place in a semi-controlled way, specialy by dealers, but later on software will become a major point at every stage, where there will be a wide offering of security and performance improvements, deployment of new functionality, maintenance services, customizations, integration with third party services, etc., to consumers directly by ISVs, enhancing the user experience adding more choice and adaptability to their particular use cases. The role software companies today play as providers will be substitued by a partnership relation.

In the same way that we all have a relative that "fix cars", there are many developers out there that can put their hands on the provided software of their own vehicles. There are also many companies willing to do the same for their own fleet or somebody else's one. A new car cost a hundred times more than a mobile and its life cycle is at least five times longer. I do not think the mobile industry will be the mirror for autmotive.

I believe that the picture will be closer to the current one in the enterprise industry, even if the journey to get there is diferent. Some automakers might remain as key stakeholders when talking about software, but not like today. 

Software in automotive tomorrow

The consumers demand for more and better services and the portability needs across the different platforms and devices (cars) in order to make business with software at scale, will increase the pressure on OEMs and Tier-1s over hardware and software standarization. That pressure might become in some cases as strong as govements regulations, I think. It will be definetly stronger that in the mobile industry. I see this as a positive factor for consumers.

Software in automotive soon
Experience shows that, if you intend to control a software ecosystem, you need to become upstream and create around your software a business model that serves as a service platform for third parties (ISVs). Maybe not even then you will be able to stay in control of what the customer is consuming. In other words, to be like Apple you need to control the hardware, develop at least the software platform and create a field for third parties to make money through "your platform", which means at least controlling the distribution and updates. 

I do not believe automakers will be able to achieve that same level of control being only a Open Source consumers in a connected world, by restricting access to your platform to anybody but those who are part of your supply chain. not even if they become Open Source contributors. And no, the Android model does not apply to a single hardware (car) vendor.

I am obviously no guru so take all this as nothing but a personal opinion from an Open Source geek. But if you think it is feasable for an automaker to achive similar levels of control with Open Source based platforms than Google or Apple has over their ecosystems in the mobile industry, I think you are at least as crazy as you claim I am.