Skip to end of metadata
Go to start of metadata

Startup of the work

Individuals who expressed their interest in participating the group

Name (alphabetic order) Company Role 
Gunnar AnderssonVolvo Car Corporation Lead Architect 
Manfred BatheltBMW  
Klaus Birkenitemis  
Bjoern CullmannTelemotive  
Jeremiah FosterPelagicore Community Manager 
Pavel KonopelkoVisteon  
Stephen LawrenceRenesas BIT Member 
Gianpaolo MacarioMentor Graphics EG-SI Architect 
Torsten MosisElektrobit  
Daniel Owens ARM  
Philippe RobinTechnoveo PMO Lead 
Frederic BourcierWind River BIT Lead 
Vidyesh NabarIGATE 
Marco ResidoriMentor GraphicsEG-LBS Architect
Andreas WarnkeElektrobit SW-Architect 

Initial meeting (conference call)


As not everybody interested in this group will attend the AMM,
we will start the BoF work with a conference call.

The call will be 2014-10-01, 10:00-11:30 CEST (as announced via genivi-dev email).
Later in 2014 (after the AMM), we could go for a F2F meeting.
If you want to attend, please ensure that your name is on the list below!

Name Available on 2014-09-30, 13:30-15:00 CEST? Actual date: 2014-10-01, 10:00-11:30 CEST
Klaus Birkenyes yes 
Jeremiah FosterYes Yes 
Gunnar AnderssonUnfortunately no, attending a funeral. Yes, with hard stop at 11.30 
Pavel Konopelkono yes 
Gianpaolo MacarioYes Yes 
Frederic BourcierNo Yes 
Philippe RobinYes TBC 
Manfred Batheltyes yes 
Stephen Lawrenceyes yes, but hard stop @ 11:30 for BIT meeting 
Bjoern Cullmannyes yes 
Marco Residoriyes yes 


Proposal for the agenda of the initial call:

  1. Welcome and agenda review
  2. Collection of expectations of participants (as base for a scope definition)
  3. Review of the list of topics, additions where necessary
  4. Planning for a F2F meeting after the Detroit AMM

Collection of expectations of participants (as base for a scope definition)


  • have a forum for discussing tool-related topics
  • define a minimal set of tools for developing GENIVI-related systems
  • present new tools and innovations


  • group-scope: GENIVI-internal or public?
  • documenting best-practice about using those tools


  • define workflow/process/recipes how those tools are used
  • based on the work in the team, it should be decided if a more formal group should be formed (e.g., EG Tools)
  • distinguish between tools which are common (and open) and those which are differentiating (and cannot be shared)


  • identify needs, provide good solutions regarding tools
  • less formal process, more recipe and documentation (processes are defined by SAT and PMO)
  • start a survey/poll to identify input on needs, document requests of member companies
  • tool independence: tools should provide value, but not force anyone to use a certain tool (e.g., Eclipse)


  • create a common tool-set
  • maximize synergy between common tools (e.g., using the Eclipse-platform as common base for Franca/CommonAPI/Yamaica)
  • common forum for GENIVI development processes
  • provide public documentation about tools best-practice (available for anybody)
  • requirements should be collected by the group


  • discuss contents of VM image containing a GENIVI tool collection
  • consolidate several layers of tooling currently available
  • draw flowchart of the way GENIVI is currently developing software (and where the tools are located)


  • ensure that tools (esp. SDK) fit to the GENIVI demo platform (part of the platform is the SDK)
  • yocto baseline as early enabler for new developers

Review of the list of topics, additions where necessary

See below, direct editing.


This section is a draft - collected from the communication on genivi-dev. To be clarified during the initial meetings of the BoF.
The clustering in the sections below is also an early attempt to classify the topics into manageable chunks.

Modeling of Architecture and Interfaces

  • UML modeling / Franca interface modelling in UML
  • UML Franca interface validation tool 
  • EA Importer
  • Yamaica tool
  • Franca
  • CommonAPI code generation tools
  • component/instance model: Franca, CommonAPI and yamaica
  • IoNAS (Autosar/GENIVI model transformations)
  • Franca install automation using Vagrant
    (create a virtual machine image which has Eclipse+Franca installed;
    but also supports installing directly on your own machine without Vagrant)

Developing GENIVI systems

  • SDK that will be delivered as part of the GENIVI demo platform project
  • Common Development Environment topic initiated by SAT
  • Debian system initiated by Jeremiah
  • Gianpaolo's "easy-build" setup using Docker - a very good basis for creating a standardized yocto setup

Remark Stephen Lawrence, 2014-09-03:
Alignment with the GDP SDK is a good goal I think, although it may be a while yet
before we get good feedback on its utility. I'm thinking about the next steps for
the dev side of our platform so I'll be interested to hear where this project is
going and what problems it wants to solve.

Development methods / working environment

  • sharing of how member companies are working today when developing linux based systems

Remark Gunnar Andersson, 2014-08-21:
Agree - it was an outcome from SAT F2F to interview companies and thus gather
more information. IIRC Aki got an action to clarify what the current best
practice and needs are from BMW. Of course, your preferred working
environment can simply be explained here on the mailing list as part of the discussion.

Remark Jeremiah Foster, 2014-09-08: I wanted to add some clarification to the three points above and add some additional information. I feel this is required based on new information from Bosch and their eCORE platform since their work overlaps some of GENIVI's work. Specifically, Bosch uses a Debian base and apparently incorporates GENIVI software into eCORE. While exact details need to be clarified it would seem that Bosch and GENIVI could each save each other work by collaborating at least on the packaging of GENIVI software. If GENIVI's software is already packaged by Bosch, perhaps we can use that in a Debian based Vagrant install that includes Franca and other development tools. Both Gunnar and Gianpaolo have done some work in this direction with Vagrant and Franca leaving the remaining work to packaging GENIVI software for Debian. As stated earlier, I'm happy to help in this regard, but only if the work is going to be reused.
We'll need to define the maintainership policy since we don't want to create unmaintained projects, but so far both Gianpaolo and Gunnar seem to maintain their projects and they develop against widely used GENIVI development environments so there is some promise there. We'd need to define how Bosch would contribute or how they would accept contribution if in fact eCORE packages are of interest to GENIVI. Obviously some of that work needs to be clarified by the SAT as well as EG Tools.
In short, there seems the resources to merge these three topics into an easy, cross-platform developer environment with tooling. This is close to an SDK and it seems quite possible the addition of Crosswalk / GNOME / Qt packages could turn it into a complete SDK.
I intend to create a document proposing an updated Common Development Environment based on Debian, eCORE, Vagrant, and EG Tools packages which I'll submit for review to SAT / EG Tools.


  • DLT Viewer and plug-ins
  • Document generator

General remarks

Remark Manfred Bathelt, 2014-05-14:
In my opinion GENIVI should aim to some standards for any tools that are related to GENIVI.
For example Eclipse as an IDE for tool integration makes life much easier for users, as they don´t have to maintain many several environments and all tools could use each other.
For current Franca/CommonAPI/yamaica stuff these advantages get quite visible:

  • We all can use the Eclipse CPP compiler and editor features, Franca model implementation is used by CommonAPI-codegenerators and yamaica-transformations easily. Anybody can add functionality by just using the existing features.
  • This way efforts to create new GENIVI contents are reduced significantly, and this also helps providing a convenient SDK environment to developers to produce more/better GENIVI code (just to mention the connection to the boards focus).

Remark Manfred Bathelt, 2014-09-08:
It could be very beneficial to use EG-Tools to further describe aspects of tool-integration, or some kind of tooling environment to simplify contributions of smaller tools.

Mission Statement

Tools Team Charter is currently under review.




This Team is interfacing or will interface with several already existing activities in GENIVI

High Level Tasks

Tasks comment Status 
Define Mission Statement Define a Mission Statement for the Team, 
Define Workplan Define a Workplan for the Team, 


During the first BoF Tools F2F meeting in January 2015,
we decided to have a bi-weekly, 90-minute conference call to continue our work
(we used a BoF Tools conf call poll to fix the actual time).

Face to face meetings

Action Items


Mailing Lists

Lists Access information Additional Information 
TBD TBD@mail.genivi.orgArchive

The usage of a dedicated mailing list is to be decided.

see also: GENIVI Mailing Lists


  • No labels