Vehicle HAL F2F Planning - January 2020

Shared F2F Plan

Date

Week 48, Tuesday the 25th to Thursday the 27th of November.

Start: 09.00

Venue

Wind River, Ismaning.
Steinheilstr. 10
85737 Ismaning, Germany

Transportation

• Have a look at the map to see how to get there.
• If you come from Airport you can either go by taxi (~20 km, 20min) or by public transport (S8, ~20min).
• Go to reception and ask. Room is booked in the name of . will meet up at reception.

Accommodation / Hotels

1. Hotel Zur Post
   • Hauptstraße 7, 85737 Ismaning
   • http://www.hotel-zur-post-ismaning.de
   • +49 (0)89 9698990
2. Hotel-Gasthof zur Mühle
   • Kirchplatz 5, 85737 Ismaning
   • http://www.hotel-muehle.de
   • +49 (0)89 960930
3. Am Schloßpark
   • Schloßstraße 7, 85737 Ismaning
   • http://www.hotelamschlosspark.de
   • +49 (0)89 961020
4. Hotel Gasthof Soller
   • Bahnhofstraße 1, 85737 Ismaning
   • http://www.hotel-soller.de
   • +49 (0)89 962830

Planned Attendees

Timetable

Attendees Day #1

• 
• Unknown User (gunnar.andersson)
• 
• Unknown User (gururaja.n)
• Joonhyung Kim
• 
• 
• 
• David Yates
• Fabien Hernandez
• Jeremiah Foster (arrived at 12am)
• Marco Residori (arrived at 11am)
• Philippe Robin (webex / telco)
• (webex / telco)
• Unknown User (manfred.bathelt) (arrived at 12am)

Attendees Day #2

• 
• Unknown User (gunnar.andersson)
• 
• Unknown User (gururaja.n)
• Joonhyung Kim
• 
• 
• David Yates
• Fabien Hernandez
• Jeremiah Foster
• Marco Residori
• Philippe Robin (webex / telco)
• (webex / telco)
• Stephen Lawrence (webex / telco)

Attendees Day #3

• 
• Unknown User (gunnar.andersson)
• 
• Unknown User (gururaja.n)
• Joonhyung Kim
• 
• David Yates
• Fabien Hernandez
• (arriving at 12am)
• ~oleksandr.domin (arriving at 12am)
• Philippe Robin (webex / telco)

Agenda backlog

GDP

• Proposer: frédéric.bourcier
• Topic owner: frédéric.bourcier
• Length: 1h
• Abstract: As requested on PMO, discuss the GDP and the GDP's role as a development environment/SDK
• Content:

• Gunnar: Scheduled for 1.30pm on Wednesday.
• Frederic: Presenting GENIVI Demo Platform Wiki
• Frederic: GDP has been released but improvements are ongoing
• See reference URL: GDP Public Wiki
• GDP for Intrepid: Intrepid Yocto GDP
• Frederic: Walkthrough of next steps.
• Frederic: GDP-125 - Deeper Lifecycle integration
• Frederic: GDP-122 - GDP layer hosted in a dedicated Yocto repo
• Frederic: GDP-121 - Integration of startup animation
• Frederic: GDP-119 - FSA PoC, nav data partition
• Frederic: GDP-113 - Porting of GDP on the MinnowBoard Max
• Frederic: GDP-112 - GDP porting to porter
• Frederic: GDP-111 - Crosswalk web PoC integration
• Frederic: GDP-110 - Media Manager PoC integration
• Gunnar: How will you manage the Media Manager PoC integration?
• Frederic: First we need to decide what the value is and if it makes sense.
• Marco: What would be the real problem in integrating Media Manager PoC? Dependencies?
• Frederic: Not sure yet due to that we haven't made the analysis as of today.
• Frederic: Has anyone in SAT tested out the GDP?
• Gianpaolo: Yes I have started looking into this but I will be using QEMU target. Any limitations with that?
• Frederic: The only issues would be in regards to Weston and Audio Manager low level audio HW configuration.
• Aki: Are the new features you have listed part of the existing contract with Wind River?
• Frederic: Not everything, e.g. the Media Manager PoC integration was not.
• Frederic: Once the initial release of GDP is done we so though want to get contributions to the project.
• Aki: Are there any active developers currently in the GDP community?
• Frederic: Apart from some contributions from Intel that is quite limited. But the plan is to have this ramped up.
• Philippe: (modified by Philippe Robin: we are still in a dissemination phase, we need to reach parties interested to do some work with GDP, examples: silicon vendors (ST-Micro for instance), Mobis in Korea is discussing with their management possible work with GDP), We need to push that the release with source code is available. We need to push for active contributions within the GENIVI community (modified by Philippe Robin and outside the GENIVI Community, Philippe has introduced the GDP and Media Manager projects to the Tizen IVI team at Eurogiciel last week, i.e. the team we are contact with concerning the application framework)
• Stephen: Renesas will also take the GDP delivery to make sure it is supported on R-Car E2 and R-Car H2 as well, in addition to R-Car M2.
• Gunnar: Should we list even that porting work in the new features list?
• Stephen: Ok, yes it should get listed as well.
• Frederic: Currently we keep the GDP aligned to the baseline and that is also the scope. And we leave feature content to any contributors.
• Gunnar: I get the feeling that it seems like we can't proceed in the work due to that we are waiting for input? The lead times for the input seem quite long? Should we become more agile?
• Philippe: Yes, we need to become more agile to have new features to demonstrate at next AMM in April. [deleted by Philippe RobinBut it might take time to get up to speed].
• Philippe: In early January we can start the first sprint on an agreed feature scope.
• Frederic: There is currently no freeze time frame for GDP, there is no release plan defined.
• Gunnar: Why can't a first sprint in regards to consolidation and stabilization start already on 1st of December?
• Philippe: (modified by Philippe Robin Yes that could be achieved for some items on the todo list but we need input from SAT all participants, today's presentation in the SAT is to make system architects aware that it is not the sole BIT responsability to define the future of GDP, BIT can organize the inputs received from the GENIVI community into a workplan (sprint plan actually), system architects are expected to relay this to their EG) in regards to what to include in the GDP roadmap.
• Gunnar: Concerning the Crosswalk topic I get the feeling that it is slowing down?
• Philippe: (modified by Philippe Robin Correct, I will look into this. It is on going. In this week's pmo call, I asked the NW EG lead to get a statement of work from igalia by mid-December)
• Gunnar: My opinion is that a general principle should be to include all GENIVI components integrated in the GDP. That could be seen as a scope of work for the next steps.
• Gunnar: We in the SAT understand that we should give input to GDP in regards to feature roadmap.
• Gianpaolo: And to clarify, we should add feature requests to the GDP project JIRA. And then there is a process in place in the GDP project for setting up discussions with relevant parties for the integration request?
• Frederic: Correct, but it is a case by case setup.

Media Manager Enhancements - Request for SAT requirements and feedback

• Proposer: Unknown User (gunnar.andersson)
• Responsible group: System Architecture Team
• Topic owner: ,
• Length: 1 hour
• Abstract: Media Manager PoC project has submitted a request for architecture requirements for the next phase of the PoC.
• Content / Proposals for enhancements:
  • Media Manager General
  • Shuffle - Phase 1 has a random function not true shuffle
  • Device Friendly Name - Extracting device name from connected devices
• Video Playback
  • Indexing
  • Control
  • Browsing
  • Playlist generation
  • Playback
• Device Support Enhancement
  • Greater number of devices such as MTP
  • Multiple concurrent device support
  • Device/source management
  • Hot Swap device support in Linux.
• Persistence
  • Implement persistence
  • Persist indexed lists
  • Persist media status, play state, play time, etc.
• Indexer Enhancements
  • Robust parsers for additional media types
  • Album art extractors possibly standalone parser
  • MTP indexing (Plugin ?)
• Integration/Architecture
• Application launching and shutdown
• Integration with other GENIVI & open components
  • Stub for DLNA (Rygel & dLeyna)
  • Stub for Bluetooth audio playback and control (BlueZ )
  • Audio management (GENIVI Project)
  • Device management, (GENIVI Project)
  • External control, tablet based remote (AGL RVI ?)
• Metadata (Standalone component so other services can use also)
• Audio/Video metadata enhancement; album art and ID3 lookup etc.
• API definition for interfacing metadata engines

• Gunnar: Target is Thursday afternoon.
• Paul: See reference Media Manager Next Steps for discussed next steps at CE EG F2F Q4.
• Paul: Walkthrough of the aggregated list from CE EG.
• Paul: For persistence support we would be using GENIVI persistence.
• Philippe: We should not wait for the Statement of Work activities before stating requests from SAT. (modified by Philippe Robin the expectation is to build the statement of work with inputs from all parties)
• Paul: For indexing we will focus on the generic support for the most common containers and not the obscure ones.
• Paul: The JLR intention is to have it running on the Tizen platform and a spin-off is to also add support for running on the GENIVI Demo Platform.
• Philippe: (modified by Philippe Robin AGL Eurogiciel (Tizen IVI team) have stated that they have implemented Miracast and their implementation is used in an automotive project and it is very important for them.)
• Paul: It will be made public as OSS within a week.
• Alexander: The project has not only focused on Miracast but also spent a lot of effort in the integration and in adding support with dependency components.
• Paul: Do you have any SAT architectural constraints you want us to focus on?
• Gunnar: Difficult to state without full insight in the architecture but one topic is persistence.
• Gunnar: It would also be interesting in utilizing some AGL projects in the integration such as possibly support for the V4L video decoder which they had on their list.
• Paul: The sub components of the Media Manager PoC will be released for compliance. Not yet sure on what the intention will be for MTP if that is part of the extended scope.
• Gunnar: MTP seems like a very important component (to support all Android phones in the market) so it would make sense to lift it up for compliance.
• Philippe: libMTP is also used by two projects in the GENIVI gap analysis.
  (added by Philippe Robin recommendation to CEC-MG EG is to start working on the gap analysis (as other EGs are doing))
• Gunnar: The list concerning possible scope for the Media Management Extensions you have provided was quite comprehensive.
• Paul: If we want to adopt some AGL projects and platform components, how should we proceed in that case? The documentation is quite limited.
• Gunnar: If you adopt AGL documents/requirements with a Creative Commons Share-Alike license it will be problematic to put such content in the UML model. We haven't sorted out those legal issues. (Offline clarification: UML model is internal to GENIVI members currently and therefore cannot be contaminated by a share-alike license until decision is taken to publish UML model under such open licenses.)
• Gunnar: A workaround is to not copy any information but instead point from the internal model to externally available documentation. (Offline: This is good practice anyway and an efficient method of reuse)
• Gunnar: In general the path forward in adopting AGL components also depends upon if you will have an AC or SC. For AC we do actually have more requirements and more comprehensive steps in the compliance checklist.
• Gunnar: Another topic. There is now a Document Registry, so you need to update your document numbers based upon the document number you pull from the registry at that Wiki.
• AI(Gunnar): Clarify if the document numbering in the Document Registry follows a running sequence regardless of document prefix (in one table) or if there should be four different tables depending upon prefix and with their own running numbering sequences. (DONE. Joel has put this instruction on the page)
  * AI(Gunnar): Add a JIRA ticket for CE EG to update Jupiter Implementation Updates Wiki. (DONE. I reminded via email instead and Sriram/Paul responded, considering it done)
• Gunnar: Paul, how do you want to manage the same request for Media and Graphics components?
• Paul: Updating the information should be fairly straight forward by who should be managing the checklist for updating the component for compliance?
• Gunnar: I have no clear answer to that.

Usage of Franca IDL to define GENIVI interfaces, state of the art and roadmap

(From Telco long ago, and postponed at previous F2F)

• Proposer: Unknown User (gunnar.andersson) (previously )
• Topic owner:
• Invited: Unknown User (manfred.bathelt) ?
• Length: ~ 2 hour
  • Common API C++ is now P1, and franca has gained some acceptance as "GENIVI IDL"'
  • Can/should we mandate franca usage?
  • For which components it would make sense require Franca interfaces (AC, PC?)
  • What should be the master repository for interfaces, the model, fidl-files? What are are the work-flows with different masters?
  • How much effort/resources we can/want spent for maintaining interfaces
  • What would be impact to modeling guidelines
  • Refer also to F2F-3 topic for additional information

• Gunnar: Scheduled for 1pm on Tuesday.
• Manfred: Walk through of two presentations covering GENIVI Franca interfaces review and details in regards to integration
• AI(Manfred): Add two presentations concerning Franca IDL review status for GENIVI and GENIVI tool chain integration as attachments to the notes.
• Manfred: Integration with GENIVI EA toolbox exists and this has been tested out by Bjoern.
• Manfred: See references and documentation at UML Model Task Force
• Manfred: Technology for utilizing Franca IDL to define GENIVI interfaces is readily available and integrated with GENIVI tool chains.
• Marco: If using a D-Bus binding on the client side to provide Common API, does that enforce that we have to use Common API for existing D-Bus components on the server side?
• Manfred: The goal is not to have this dependency and technically that goal shall be feasible.
• Jeremiah: Common API is now mandatory. With some of the concerns, such as Java build dependency, this is a problem.
• Gunnar: Common API libraries are required to be part of a GENIVI compliant platform, but that does not mean all components need to use it to fulfill compliance. Today we should discuss what we want however.
• JoonHyung: Is Franca IDL also intended to be used for Web IDL?
  (added by Philippe Robin LBS EG is investigating how to generate Web IDL descriptions of the navigation web APIs from the description of LBS APIs, please contact Unknown User (philippe.colliot) and Marco Residori to learn more about this work (which is related to LBS EG contribution to W3C))
• Manfred: It could be used for those use cases but that has not been part of the input requirements. But yes, it may be used but further work is needed to add that support if that is a step we want to take.
• Gunnar: In regards to providing Franca IDL files for all AC I believe there exists a decision already for in the SAT. But we need to review that and (if not properly documented) possibly repeat the decision here.
• David: I don't see that we must limit ourselves to one way for defining interfaces, we have other alternatives that make more sense at some occasions. We could definitely have a recommendation for Franca IDL but in other cases a client library might make more sense.
• Marco: One alternative is also to continue using D-Bus XML.
• Manfred: I would like to have a list of use cases, a table with different methods for defining interfaces mapped to different use cases.
• Marco: We have an example with Sensor Information which states in the component specification that it shall be a C client library.
• Marco: It is an AC P2 and there I see an issue to specify a Franca IDL file and there is no C Common API mapping.
• Gunnar: One solution could be to state that all AC that provides an IPC interface should provide a Franca IDL file together with deployment information.
• Marco / Manfred: Franca IDL to EA round-trip transformation is currently not supported. Work is ongoing but might be a risk.
• AI(Manfred): Look into what needs to be resolved in regards to adding Franca IDL to EA round-trip transformation supported.
• Manfred: One big issue in regards to Franca IDL which we should add control for is in regards to what Franca version being applied in different EGs. They currently differ and cause incompatibility.
• David: For SC we don't typically define an interface due to that they have frequent updates and thus we state a version higher than a specific version to be compliant.
• David: My opinion in general is that I see little value in defining interfaces for adopted OSS components.

• AI(Manfred) Update / Complement the presentation available on the GENIVI wiki with the material presented in this session.
• Gunnar: Presenting slides and walk through of some open issues in using four alternative IPC and service API definition mechanisms.
• AI(Gunnar): Add presentation covering the topic of open issues in using four alternative IPC and service API definition mechanisms as attachment to the notes. (DONE. Attached with minor changes to following week's telco
• Marco: We should add a comment that in the presentation examples it is assumed that the client library is implemented using C++.
• Marco: We have in the SAT previously had comments that we also need to provide a Common API C binding in addition to C++.
• Gunnar: I think there is a higher barrier to overcome when using Common API C+, compared to a typical C library due to the use of many advanced C+ features.
• Manfred: I would see it as equivalent to C for a developer in the C community when compared to a developer in the C++ community.
• Gunnar: Ok, removing the wording barrier from the presentation. It is agreed only that Common API uses advanced C++ features.
• Manfred: Franca is not only an abstract IDL, it also provides a Franca deployment model.
• Manfred: GENIVI could add both Franca Deployment Specification and Franca Deployment Definition to the requirements that would provide a structured and defined IPC mechanism.
• Marco: I have seen issues in EG LBS where we have made a transformation from D-Bus to Franca IDL and Common API and where we get the results that the generated B-Bus API (From Common API) is not compatible with the original D-Bus API.
• Manfred: Ok, we should raise a bug on this issue so that we can correct that within the UML Task Force.
• AI(Marco): File an issue report in JIRA in regards to D-Bus XML to Franca / Common API transformation - that a reverted transformation does not produce a compatible D-Bus XML.
• Gunnar: Marco, can you break down the problem into two steps? First validate that a round-trip transformation between D-Bus XML and Franca IDL and after that a validating the complete chain.
• Gunnar: Maybe Common API tools should provide D-Bus XML files? As a kind of definition of its interface provided to non-CommonAPI clients using other D-Bus binding.
• Manfred: That is currently available in an add-on package by Klaus Birken.
• Tom (on phone): I have had discussions with Klaus concerning Web IDL and Franca IDL, it was no analysis, but more an initial discussion concerning if there is a need to start an investigation and if we could use it for Crosswalk. Similar to what Pelagicore has been doing for Franca IDL with Qt / QML and Qt IVI.
• Gunnar: We should eventually in this discussion end up in the question if Franca IDL is enough for specifying interface definitions.
• Tom / Manfred / Gunnar: There is little difference between Franca IDL + CommonAPI compared to a shared library approach in the risk for needed modifications due to an underlying systematic property for new introduced protocol layer support.
• Tom: I see an economic benefit in utilizing and commonizing upon a common IPC binding such as Common API due to that there is code reuse which limits the impact of bugs being inferred for all clients residing in different Git repositories. That might be worthy of consideration.
• Gunnar: We need to keep in mind that we have an eco-system of OSS developers that are more hands on and implementing code matching code and that are not spending too much effort in abstract UML modeling and design.
• Manfred: Do we agree that the alternatives we have discussed today are the only relevant ones? Or do we see additional alternatives? That should be the first step in getting forward.
• Manfred: We might end up that we also use several or all of the alternatives depending upon what use case or technology we are targeting?
• Gunnar: Yes, that is also a viable result of this discussion.
• Gunnar: We also have the topic of Tizen and eCORE which provide a C-based API. How does that affect our way forward?
• Guru: For eCORE we have a clear statement that we will stay mainstream for the majority of the components and we have added eCORE specific wrappers / APIs for some specific components. The reasoning for this is that we want to also stay compatible with the CE domain.
• Gunnar: That sounds like a bit harsh statement when we are trying to find common ground and where we are trying to see how the eCORE Application Framework could be mapped to GENIVI and be made GENIVI compliant.
• Guru: We are committed to support SAT in the activities related to eCORE packages, API's and Application FW - genivi mapping. We are also committed to what we have agreed/discussed during eCORE f2f in Düsseldorf.
• Jeremiah: Why don't we just continue along the path we have started with Franca IDL and Common API and provide a well-documented concept for the eco-systems. Then we see what kind of adoption we get, maybe this is what the eco-systems are missing.

• Secretary: Long discussion around the Platform APIs and Application Framework request by the board. Not explicitly noted down due to that it is repetitive information for Manfred and this topic will be covered in a separate session during SAT F2F-6.

• Manfred: I think it is important that we separate the discussion about Platform Interfaces with from the discussion around Franca IDL, Common API and D-Bus which is about IPC.
• Manfred: In our work we are also looking into security mechanisms others than what is provided by the IPC by itself so any input is welcome.
• Aki: At BMW we are and have used a legacy platform API and IPC mechanism but we have decided that for the future we will focus on shifting our strategy towards Common API.
• Manfred: I think it also is important to separate between IPC mechanisms such as Franca IDL and Common API and shared library interfaces. They are completely different things.
• Gianpaolo: What is the objective with the ongoing Platform Interface work? Is it 1) To make Tizen IVI and / or eCORE to run on the GENIVI platform interface without modifications to these stacks or 2) Push a need for changes to Tizen IVI and / or eCORE so that they make some changes to adopt a newly defined GENIVI platform interface?
• Gunnar: I envision that they to some extent are not mutually exclusive.
• Gunnar: An important point I want to make (again) is that I need input from the SAT in regards to the available powerpoint material concerning Platform Interfaces for GENIVI. This should become an aligned SAT material.
• Marco: My personal view within the SAT is that we shall focus on the Platform Interfaces and spend our efforts in completing that picture before taking too much input from the Application Framework domain.
• Gunnar: Ok, understand and that is good feedback. We should spend our efforts on many activities within the SAT, including compliance topics. We need to merge your input to the material.
• Guru: My input is that we also should mention the hypervisor solution more prominently in the material. That is an important topic for some applications for IVI.
• Gunnar: Ok, input taken and we should discuss how we include this in the material.
• Gunnar: In regards to the topic of the GENIVI Reference Architecture I want to repeat our alignment since before where the SAT stated that the Compliance Specification must be a subset of the Reference Architecture.
• Gunnar: We had one possible alternative mentioned before by Jeremiah, that one alternative could be to set a standard that others should follow. But if we would go into that direction we would also need the manpower in actually filling all the gaps. That we currently don't have.
• Ned: There might be one step missing in the action list for the Platform Interfaces slides. We have no step that targets on getting a complete picture on input requirements and architecture / system requirements. We previously had the example of Audio Manager and how the same component is used differently in GENIVI and Tizen IVI (Murphy).
• AI(All): Provide input on the action plan in the GENIVI Architecture slides, is the scope and the focus valid?

Gap Analysis

• Goal: Review current status including added projects (Tizen, eCORE)

• Gunnar: Scheduled for 1pm on Wednesday.
• Ned: I would prefer having my part of the session by Thursday. I have some more preparations to do.
• Guru: A gap analysis towards eCORE and Tizen has been performed.
• Guru: Presenting the gap analysis sheet.
• Gianpaolo: Have you also included the versions for the packages?
• Gunnar: Currently no but that should be added to have consistency.
• Guru: Currently the list does not state what additional packages that eCORE and Tizen uses that has not been used within the GENIVI projects from the original GENIVI gap analysis.
• Guru: I need additional time to complete the gap analysis list towards eCORE and Tizen.
• Guru: Next step after completing the full list is to go deeper to investigate how the different packages are used in GENIVI compared to eCORE and Tizen.
• Guru: Also during this analysis I have found other vital parameters we should look into
• Guru: Walkthrough of the list (see below).
• AI(Guru): Provide list with additional parameters (to be added to the notes) we could look into in the gap analysis work.
• Gunnar: Yes, it could be useful questions to discuss but there is a mismatch between these questions and how the gap analysis in GENIVI is defined and used and what information we could retrieve for the other systems.

Infrastructure Usage Checklists

• Gunnar: I believe nothing/little remains unsolved for now. We said we would open discussion again only when the first actions have been performed.
  • Is that the case?

• Gunnar: Any time would be OK for this topic.
• Gunnar: See notes from InfrastructureUsageChecklists
• David: I have taken Lifecycle components (NHM,NSM) and Persistence explaining how they are used and I have filled in the templates for these components.
• David: In the UML model I have then created a new document under checklists where I have copied and pasted the information from the templates to a new artifact.
• David: It is also possible to create a link from the UML Model to the existing document.
• David: What I haven't tried is to use Guido's document generator in this process.
• Gunnar: It should be feasible to create a plugin to the document generator in assisting the work for this process.
• David: We should store the documents in Git or SVN to be able to use a web address in the reference and avoid having local disk path dependencies.
• Gunnar: Yes, but we also want to have support for version control and not point directly to the trunk.
• David: If we want to have the UML model version controlled we need to check in the checklist in the work space.
• Gunnar: We have two open issues:
• Gunnar: 1) How to resolve the issue in avoiding local disk paths as references for the checked in documents?
• Gunnar: 2) How to include the checklist in the component specification automatic document generation?
• AI(David): Discuss and resolve the following open issues with Bjoern: 1) How to resolve the issue in avoiding local disk paths as references for the checked in documents? 2) How to include the checklist in the component specification automatic document generation?
• David: In the end I would be able to generate a document from the UML model stating e.g. who (and how) is using Node Health Manager.
• Gianpaolo: I think the process should be that all components need to fill in the template for the mandatory components (lifecycle, persistence, etc.) regardless if they are used or not.
• Gunnar: It has already been partly decided in previous SAT F2F-4 to include this step into the maturity checklist but we need to resolve how to practically implement the process.
• Decision: Include the mandatory / infrastructure usage checklist in the maturity checklist
• David: We should also not place the empty templates under each component but it should be placed at a higher hierarchy in the UML model. For a component owner it is much easier to find what templates are needed to be filled in. Either under Logical View or GENIVI Model, with preference of the former.
• Decision: Create an empty usage checklists directory directly under Logical View in the UML model for the empty usage checklist templates.
  • (Gunnar, offline): The above decision was agreed if we have no complaints from Bjoern on that file structure and that it does not trip up any existing generation tools.
• Gunnar: We should also rename the filled in checklists to something else than just checklist to clarify the purpose and the content.
• David: We have a lot of open questions concerning this topic, like e.g. how to enforce checklists for legacy components? See notes in URL above.
• David: The benefit of having filled in templates even for components where there are no dependencies or usage is to be able to detect that required work has not been performed.
• Gunnar: What we are aiming for with this checklist is to get deeper information about why a certain component is not using or having dependencies towards the mandatory / infrastructure components. With a UML model dependency diagram you can only read out if there is a dependency. Not any information about if a missing dependency is due to a mistake or a conscious choice.
• David: It would be beneficial to have a table (ToC) stating the usage of mandatory / infrastructure components to avoid filling in templates for components that are not used. This ToC document can also be used for the component specification document generation.
• Gianpaolo: Another question is that if we enforce the use of these usage checklists (including ToC) - for what component types?
• David: One reasoning to enforce this for all components is to be able to judge the maturity of a component. It can still pass compliance but it aids in the evaluation of maturity for e.g. a PoC.
• Gunnar: Yes, filling in the usage checklists should be part of the maturity checklist.
• Decision: Component owners are responsible for creating the template for usage of mandatory / infrastructure components. It should be allowed and possible to use for SC and AC but not a must. It is up to the component owners to decide if crating a template is needed or not.
• David: For the maturity checklist we need to write a rule that it is mandatory for certain components (such as owned components) and optional for e.g. adopted components.
• David: Usage of the checklist for legacy components should be enforced upon modification of the component.
• -AI(Gunnar): Update the compliance specification in regards to including the use of the mandatory / infrastructure component usage checklist.- (DONE. The Compliance Proposal Checklist (not the specification) was updated.)
• AI(David): Create a checklist summary template for summarizing the usage the mandatory / infrastructure components
• AI(Gianpaolo): GT-3117 - Try creating component subdirectory under Logical View storage directory and make sure that all UML tooling is still working.

Clarify the requirements for WwG dependencies disclosure

• Gunnar: I believe nothing still open for discussion. Waiting for actions to be performed since last time?
  • See F2F-4 notes

• Gunnar: Any time would be OK for this topic.
• Ned: OK.
• We went through some of the results, on some of the actions performed by Ned from previous discussion.

The GENIVI Architecture - (re)setting the big picture

• With understanding of the recent architectural discussion and slides, revisit the notes from this topic and check which concrete activities we can now launch.
  • Refer to F2F-4 notes

• Gunnar: Any time would be OK. Walkthrough of updated slides.

Revisit the definition of Baseline and related terms (F2F-1)

• Goal: Produce an initial proposal of a baseline definition (for review / discussion with BIT)
  • A webcast was made (16 Sept?). We should consider all the information provided there.

• Gunnar: Create a draft definition of what the baseline should be.
• Gunnar: Should be done before Wednesday to review with Frederic.

Review and approve the component specification template

• (Last time Approval was not possible since the template was not complete.
• Actions/responsibilities were not assigned to make it complete in time now either. Take decision on what to do for this compliance round.
• Start with F2F-4 notes
  • Document is maintained on SVN https://svn.genivi.org/compliance/trunk/templates/

• Gunnar: Working on this now inside of the meeting would be needed to create a simple template ready to be used.
• Gianpaolo: Is anyone using the template?
• Gunnar: Not that I am aware about.
• Gunnar: See notes from F2F-4
• Gunnar/Gianpaolo: We have examples from before when implementation details were requested to be removed from the component spec (Persistence).
• Gunnar: It seems like we need a separate document covering these topics instead, may not be part of the compliance document.
• Gunnar: Should the programmer's manual go into the component specification? Would a separate optional document be used instead?
• Ned: I would leave it to the project's discretion.
• Gianpaolo: We should make sure that the template contains relevant information so that we can enforce the use of the template.
• Marco: The template and its information should of course be readable, we have examples as of today where this is not the case. Examples include Layer Manager and some Lifecycle components.
• Marco: That specifically concerns Specific Components where we don't mandate the use of a component specification.
• Marco: It is hard to find the relevant information - sometimes it just points to a GIT repo and you have to actually compile the information from source.
• Gunnar: Do we have such an example?
• Marco searches. Marco says it is difficult to know where to find the needed information.
• Gunnar: We have discussed this before and the suggestion has been that the compliance spec shall always point to a landing page for each component with a defined structure (using a template) to find all relevant information.
• Gianpaolo: For the programmer's manual we are now talking about a component specification and therefore specifically talking about Abstract Components.
• Ned: The information stated in that section does not necessarily state relevance to the component specifications but it shows how to use the API and the component.
• Marco: We should consider the component as a black box and only explain the usage of the API or prerequisites, etc. for using the component.
• Gunnar: Ok, seems like we are aligned in that an optional programmer's manual section fills a purpose according to the discussion today.
• Decision: Include the section Programmer's Manual in the Component Specification with the definition that the component is treated as a black box and that the Programmer's Manual explains how to utilize the API.
• Gunnar: And now to the Reference Implementation section.
• Gianpaolo: For Placeholder Components is it difficult to know what the PoC is, it is currently not stated in the component- or compliance specification. Adding this information to the section Reference Implementation would help.
• Marco: I would prefer to not use it for PoC, only for Reference Implementations. PoCs are not stable and might be exchanged and it adds a maintenance burden to the component specification.
• (Someone, not Marco?): Statement in support of including PoC references as well.
• Gunnar: For both of these sections
• Gunnar: We could vote on if we are to include PoC references into the component specification, but I would prefer to see consensus or at least a strong majority support since this is a significant change compared to before.
• Gianpaolo: How about test plan? When and how is that used? I fear that it might be outdated.
• Gunnar: In principle the test plan shall never be outdated due to that it is used in the compliance process and thus need to be updated according to the component.
• Gunnar: We do though have a vague definition of what the test plan actually is.
• Gunnar: Review of an updated document proposal: GENIVI_Component_Specification_Template.docx
• AI(Gunnar): Fix the footer for the document GENIVI Component Specification Template. (CANCELLED: I think this comment was related to the license discussion (see next action))
• Gunnar: I have updated the license information to the private GENIVI license.
• David: What does this license state? Why do we want to have a restricted license? In some cases we want to make the information publically available.
• Gunnar: Do we need to create two versions of the template with different licenses?
• AI(Gunnar): Clarify with the license review team, Steve Crumb and Pavel concerning what license to use for the GENIVI Component Specification Template. Two versions with different licenses needed? (CANCELLED: See next line)
  • (Gunnar, offline We shortly after this remembered that the template allows switching between licenses.
• Guru: We should add an Author for the revision history table.
• Gunnar: Noted and changing directly in the document.
• David: I am assuming that System Overview is a standard paragraph. Who is doing that one?
• Gunnar: Not clear as of today. I have it as a comment / remark in the document
• David: I would also like to see section Subsystem or Domain Overview between the sections System Overview and Component Overview.
• David: Shouldn't also the Document Overview be a standard paragraph / boiler-plate?
• Gunnar: Correct. Updating.
• David: What is supposed to be stated under section 4 Requirements? We have 4.1 Functional and 4.2 Non-functional.
• Gunnar: Chapter 4 is an informational template which is kept in the final result (non italic text). Chapter 4.1 / 4.2 has examples to be deleted and replaced with real requirements.
• David: We don't have functional and non-functional requirements in the UML. Why would we have that in the Template document? It is very difficult to do the extract due to the missing information. In the UML model we have Vehicle and Software requirements.
• Gunnar: That sounds like a valid statement. Should we change that in the template? Or what could be the reason for having it like this? We will not change now.
• Guru: What does the statement handwritten mean?
• David: It is defining what can be generated from the UML model and what needs to be manually added.
• Guru: It is not used consistently anyway.
• Guru: For 6.3.2 Provided Interfaces. We should comment that it also covers internal interfaces.
• David: For 6.3.3 Required Interfaces. What level of detail are we asking for?
• Gunnar: A short description of what interfaces that are needed should be enough.
• Guru: 9.1 Implementation Details needs to be rephrased, impossible to understand.
• Gunnar: Agree, updating.
• David: For the test plan it should be preferred to have a link to a separate document.
• AI(Gunnar): Simplify section 9.2 in Component Specification Template document.
• (added by Philippe Robin in the sharing experience at AMM-Goteborg, maintainers underlined that what open source developers need to learn about a component code is a "10-page" overview, it would be good to add such a summary/overview as a section of the component specification template in order to get ready for the publishing of the PoC or RI or SC if the next step is to go for a SC)

Alignment of compliance roadmap with other projects roadmap (F2F-1)

Excellent points made here, and good decisions: Was it collected in a guideline/checklist?

A few points mentioned

1. Track dependency information
It was decided this is something to discuss in a UML discussion team.

2. Upstream projects update, compliance needs to update with them (BlueZ was the trigger for this discussion)
Answer: This has been recently introduced - see Jupiter Implementation Upgrades

-> remaining, some hints that also ACs should be considered. E.g. if implementation has changed API or added new features. Do we agree that this is adequately covered by going over all RIs, thus covering all AC/P1?

• Gunnar: We might need to revisit the notes to fully understand remaining work.
• Gunnar: Review of notes from Alignmentofcomplianceroadmapwithotherprojectsroadmap
• Gunnar: Walkthrough of Jupiter Implementation Upgrades
• Gianpaolo: It would be beneficial to track issues with compliance within the SAT even if the bulk of the work is performed in the EG. We should be able to catch issues with e.g. GStreamer in regards to compliance. Usually people report such issues to incorrect instance and documenting a procedure for this might make sense.
• Gunnar: The place to store any compliance bugs and issues should be JIRA but the SAT could monitor open tickets. We own the responsibility.
• Decision: Create a summary page for open issues towards compliance that exists in JIRA. Continue using JIRA for such issues, even small issues.

Handling component dependencies in the UML model

• Confirm the status of the topic

  Were the answers given in GUM-133 also captured on a relevant Wiki page?

  (Offline, answer: No, GUM-133 was just a minor detail. Instead looking back at previous F2F minutes, and new discussion)

• Gunnar: Review of notes from HandlingcomponentdependenciesintheUMLmodel
• David: I feel that we in the UML model should have a dependency diagram. It is an important part of a software architect.
• David: In previous discussions around this topic we have identified some technical issues for realizing the support in the UML model.
• Gianpaolo: Many technical issues have now been resolved due to working in a single working branch but the main blocker is to set the scope and the definition of what we want to achieve.
• Ned: Build dependencies are easy to extract during the build. This would enable us to create a build dependency database that can be queried.
• Gunnar: Good proposal but it is serving a different purpose.
• Ned: Yes but due to that the output is XML we can do anything we want with the data. We could import the build dependencies directly into the UML model?
• Gunnar: Putting all dependencies in the UML model is not realistic, what we want to achieve is to have dependencies stated for GENIVI components already available within the UML model.
• Gunnar: It seems like everyone agrees that this is needed and that we should try and add the information within the UML model.
• David: We need to discuss the details in what view and artifacts in the UML model we should use for stating dependencies. Should it be in the Implementation View (deployment) or in the Logical View?
• Gianpaolo: Currently the UML model doesn't trace to the correct components from the Logical View.
• Marco: I feel that a good first step would be to add dependencies in the Logical View. That would be less effort and still provide a good value.
• Gunnar: Sounds reasonable. Should we start with tracking dependencies in the Logical View? For EGs that in addition want to continue on with adding dependencies in the Implementation View that is OK.
• David: I am OK with that.
• Gunnar: Should we also put a requirement on that it for Abstract Components shall be part of the component specification for compliance?
• Gianpaolo: Yes is would be very good to get that transparency.
• Ned: Yes and then we can connect it to the maturity checklist for new and modified components.
• Decision: The EGs shall provide a dependency diagram in the Logical View for all Specific- and Abstract Components. It is also allowed (optional) that EGs adds an additional dependency diagram within the Implementation View to make deployment specifics more visible. The Logical View dependency diagram shall also be included in the component specification.
• Aki: We should also make sure that the dependency diagrams are consistent between all the EGs.
• AI(Marco and Aki): Create a guideline with a template for how to create component dependency diagrams in the UML model Logical View.
• Gianpaolo: We should also remember to add support for extracting the dependency diagram in the document generator workflow.

Documenting a reference architecture

• Proposer: Unknown User (gunnar.andersson)
• Responsible group: System Architecture Team
• Topic owner: Unknown User (gunnar.andersson)
• Length: <How much time is required for this session>
• Abstract: Documenting the reference architecture
• Content: Will we be able to meet the request from the board in providing a reference architecture?

• Gunnar: Do we feel that it is feasible that SAT can provide a reference architecture before Christmas time frame? There is a request from the board about this and I need to provide an update concerning the status and out feasibility.
• Gunnar: Based on statements done yesterday, I need to ask each of you if you will support or not support the work. I cannot have unclarity that slows the work down.
• David: Isn't the question more about what the scope is? Depending upon scope the answer might be different.
• Gunnar: Concerning application frameworks. It is part of the scope for the GENIVI reference architecture to investigate that area. That doesn't mean that it will end up in compliance. But the surroundings, including application frameworks, affect the GENIVI reference architecture.
• David: On a high level the picture looks valid. My only comment is if we intend to do any work with the blue line, the application APIs?
• Gunnar: For application APIs there is no specific work intended for us, but instead referencing already existing application APIs.
• Gunnar: As a first step, do we agree that we need this reference architecture picture?
• David: My personal view on this is yes, I have stated this need for many years.
• David: I see a need for two pictures; one for external use like the one you already have depicted and one for internal use that identifies our internal gaps and where we should focus our work.
• Marco: I also have no objections to the scope we are discussing here. I support the statement from David.
• Aki: My problem has previously been to understand the definition of the architecture picture. But I fully support what David is stating. But we shouldn't spend too much time in SAT in defining what is on top of the yellow line, the platform interfaces.
• Gunnar: There we are in full alignment.
• Gianpaolo: I also agree to what has been discussed here. I do though have a question concerning what the scope is for the Native Application block? What has been requested by the board?
• Gunnar: The board has not stated any request for this specifically, it is up to the SAT to decide. There have though been requests for looking into platform support for sandboxed type of application environments (from the board), and more tightly integrated platform applications has been our strategy in the past. (So both need to be covered.)
• Secretary: Long discussion not fully captured in the minutes, summary statements will be made after the discussion.
• Gunnar: We have after a discussion reached several alternative names for the "Native Applications" - Standard, Native, Integrated, Core, Privileged, Direct Access, Direct, Base.... What do we prefer?
• Gunnar: After an initial poll in SAT we will include the following in the poll: Core, Native, Integrated, Privileged, Base
• Gunnar: Internal SAT poll gives the result; Native - 5, Core - 5; Integrated - 6; Base - 3
• Gunnar: Even that I am partial to Integrated I must consider this result inconclusive. Due to the close vote we should ask for all SAT architects to vote.
• Decision: It is agreed within the SAT (people attending F2F-6) to continue to work with the Reference Architecture and to provide a block level architecture to the board until the end of the year.

Document Generator

• Follow up and status

• Gunnar: Status is that several people in SAT seem to have issues. This document can be used as a test template: playground.docx
• Gunnar: Status is that I could start the tool once and now I get exceptions all the time upon startup
• David: Seems to work for requirements but not with images, then I get an exception. Tested on multiple environments.
• (Gunnar, Offline: Marco appeared to have similar problems as David. He can run it but generating what he expects)

Extend and revise compliance explanation documents

• Open actions. How do we get this done?

• Gunnar: This is one of the key topics or this week.
• Ned: Presenting the updated Component Compliance Explanation document.
• Ned: Section 4.2.1 has been updated with the two decisions taken by the SAT.
• Ned: For consistency reasons I would propose to review the components used in the baseline to see that we have a match.
• Secretary: All feedback, comments and updates are performed live and updated directly in the document. Not capturing all comments in the notes.
• Ned: I will upload the updated document and the links to the Wiki.
• Gunnar: Due to that we already have decisions in SAT concerning the updated it is just a formality to approve the update.
• Gunnar: I see a concern with a decision we have taken in SAT before concerning that applicant shall disclose any information needed that is necessary to port the corresponding Baseline to the hardware stated for the platform in the compliance submission. It is not matching the discussion we are now having and how it is stated in the Component Compliance Explanation document.
• Gunnar: The applicant for WwG submissions might most likely not want to endlessly maintain this for the stated Baseline.
• Ned: I prefer the statements that we have in the Component Compliance Explanation document over the statement in the decision.
• Gunnar: We seem to have a proposal to overturn the previous decisions to explicitly add the previous statements in the Component Compliance Explanation document?
• Gunnar: It seems like we currently don't have consensus for this proposal in the SAT.
• Gunnar: To summarize, we have decisions stated here: ClarifytherequirementsforWwGdependenciesdisclosure.
• Gunnar: For the first decision point (updating the compliance explanation document); part 1 is covered by the updates performed by Ned in the document; for part 2 (virtualized hardware) there is no changed due to that it is already covered by the wording hardware; for part 3 (disclose porting information) it is delayed due to a new proposal that need to be discussed at a later stage.
• AI(Gunnar): Formulate a proposal and question concerning part 3) stated in the minutes above and send for discussing and review on sys-arch mailing list
• Decision: the discussed changes to the Component Compliance Explanation document in its current form is approved but shall be reviewed by Gunnar.
• AI(Ned): Upload the updated Component Compliance Explanation document to SVN for review.
• AI(Gunnar): Review the updated Component Compliance Explanation document located in SVN after update and provide to Steve Crumb (on hold due to open proposals).
• Decision: it is decided that the SAT Secretary shall take on the task to perform an initial review in regards to e.g. correctness of platform and baseline references, etc. This applies to both WwG an compliance submissions.
• AI(Ned): Provide updated checklists to SAT Secretary in regards to initial review of submitted WwG and compliance submissions.

Collection of Minor/old topics

• Similar to before, review previous topics, check status of actions, decide if topic is closed or not, etc.

  • Improving the reviews of compliance proposals
    • Proposal: Topic is closed. The SAT voted against any changes in assigning reviews.
    • The early maturity check has been introduced on the SAT meetings. Waiting for EGs to now bring input.
  • Clarify the requirements for WwG dependencies disclosure
    • Decisions were taken. Waiting for them to be implemented (actions performed)

<Title of proposal (Template)>

• Proposer: <Person proposing topic>
• Responsible group: System Architecture Team
• Topic owner: <Person leading topic (may be different from Proposer)>
• Length: <How much time is required for this session>
• Abstract: <Short description of topic>
• Content:

Planning

This section is for planning the location and dates for the F2F.

Date Planning

Edit the table below to indicate your status with respect to the proposed dates for the F2F, entering one of the following:

If you would use case exactly as shown ("YES", "no") that would help for visually scanning the table.

There are a lot of people to try to schedule to suitable dates, so please be as generous as possible in specifying "YES" or "??"

Availability planning

Venue proposals

In the table below, add your proposal for a venue for the F2F.

Venue requirements:

• Venue is confirmed to be available
• Not too difficult to reach by international flights
• Meeting room suitable for 15 people
• Network access available
• Data projector
• Nearby hotel accommodation

Candidates venues:

Location voting

Let's vote for a location as per the scores here:

For attendance status, put in one of the following

Locations to vote for: