In the first of a three part series, we talk to some of the people behind the Polarsys Industry Working Group - a recently set-up open source community hosted by Eclipse with its aim to define, build and maintain open source tools for safety-critical and embedded system development in demanding engineering domains. Just some of the companies that have signed up include Airbus, Obeo and Thales with heavyweights from sectors such as aerospace, defence and security, transportation, energy, healthcare and telecommunications represented by the working group

What is unique about this project is that the companies involved typically require maintenance of tool chains for the very long term – from 30-70 years in some cases.

We talked to Airbus' Pierre Gaufillet about the entire initiative...

JAX: What were the reasons behind Airbus joining the Polarsys Working Group?

PG: Since 2004, Airbus has made the choice of using open source tools to develop its avionics applications. Within that time, it became apparent that if open source was solving many very long term availability issues we were facing, some were still pending: how to maintain skills and components, how to coordinate the development efforts of industrial users, how to share collaboration costs (VCS, mailing lists, build system) how to ensure tools maturity, etc.

Airbus decided for this reason to launch with other industrial and academic partners an ITEA project named OPEES in 2009. The main goal of OPEES is to set up a sustainable organization and ecosystem that would take care of open source tools and more generally components in the very long-term, in a way that fits the constraints of critical/embedded systems industries. Polarsys is actually this sustainable organization.

To summarise, Airbus and the other OPEES partners created Polarsys and are joining the IWG to ensure the development and maintenance of their open source toolsets in the very long-term.

 Why is it important for a company like Airbus to rely on tool chains for long-term time constraints?

The reasons are simple: the complexity of embedded applications is increasing while the constraints over costs increase. And of course, avionics products have to, more than ever, meet safety regulations. Automating development activities is probably the only way to meet all those requirements, because it implies formalising further artefacts and processes (therefore making possible powerful approaches like formal verification or code generation) and allows the engineers to focus their efforts on the most important aspects.

Another reason is that our families of products have a life-cycle of 70 years and more: formalisation and automation are a very good guarantee that the technical know-how will not be lost when the initial development team will have rotated 3 or 4 times.

How do you actively participate in the Working Group?

In several ways: first by defining the set-up of Polarsys through the OPEES project, then through the various governance bodies – the Steering committee for strategic aspects, the Architecture Board for technical guidelines, the Quality & Labelling Committee for QA/QC and providers/components labels, and various Change Control Boards for coordinating industrial users around specific components.

Being a Polarsys member also implies a financial participation, beyond the Eclipse Solution Membership fee. This specific fee will be used to set up and maintain collaborative infrastructure for the very long-term. And lastly, apart from the coordination and strategic activities, Airbus will regularly contribute to the maintenance of a subset of the open source tools or components followed up by Polarsys, thanks to specialised companies like ATOS or Obeo.

What open source tool chains and software are you dealing with?

Today, our development toolchain includes of course most Topcased modelling features – OCL checker, gendoc2, model editors like MDT Papyrus, SAM or AUI, etc. – but also some other components like gPM (a configurable and robust ticket tracker), Frama (C for C code verification), and some more casual Eclipse components, like the CDT or JDT.

What will be Airbus' contribution to the Eclipse community?

In fact, your question may be “What is Airbus’ contribution to the Eclipse community?”

Through Topcased, Airbus already contributed modelling components, like ECORE Tools and has actively contributed for several years to the development of MDT Papyrus as the next generation of UML/SysML editor. Most of the time, these contributions have been and will be done by specialized commercial partners: Airbus is not a tool provider and does not intend to become one.

I think also that the merging of constraints and requirements of critical industries and open source communities may lead to interesting cross-fertilization, ie bringing better quality/control level to open source processes while introducing more flexibility and innovative approaches to our industrial processes.

This interview originally appeared in our sister publication, the German publication Eclipse Magazin.