We use cookies on this site to enhance your user experience. By using this site, you are giving your consent for us to set cookies.


You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Monday 3 June weekly call

Participants:

  • Petar (Visteon)
  • Christian (BMW) (partially)
  • Kevin (High Mobility)
  • Rafael (xapix)
  • Stephen L
  • Gunnar
  • Philippe

Minutes

  • roundtable

    • Rafael: xapix is a German company based in Berlin trying to create an api automotive platform www.xapix.io
  • takeaway from AMM
    • Kevin: liked to talk about the standardization of car data, VSS, VSS 2
    • high mobility has a different perspective, establishing the framework between high mobility, the car and the cloud
    • a lot of different protocols, not only VSS 2 but also several others
    • discussion on the various protocols
    • Gunnar: at AMM we got a presentation by cloudera on the way data are managed in an automotive api framework (big data architecture)
    • Discussion followed on capturing all the different players/users of the architecture. Third-party "app" development API, is that a programming API or "only" the W3C REST-based architecture?
  • High level vision on the project scope
    • Gunnar: shows this slide deck
    • Petar: agrees totally with slides 3&4
    • one question on how to describe a behavior/service, need to represent different data types, and how to represent data that is made up of combining data from several sources.
    • Gunnar: When it comes to combining signals into more refined data, the VSM project is investigating exactly that. It provides currently a python implementation. This can be useful to run on powerful IT systems, and/or be further refined to a optimized compiled code through code-generation for example.
    • look at: GitHub/GENIVI/vehicle_signal_manager
    • Kevin: I have a more organisational level, question, is VSS 2 more based on REST ?
    • clarification brought by Gunnar on the various topics wip at W3C: VISS, VSS 2, etc.
    • Clarifying VSS (Data Model @GENIVI GitHub), VISS v1 (W3C specification, which does also refer to VSS as the (minimum) data that shall be provided. VISS v2 (ongoing, in combination of augmenting VSS v2 to the needs). VISS v2 primarily focuses on adding HTTP/REST but some augmentations of the underlying features and data models happen in combination with this.
    • Clarifying differences of work in data definition:
      • data-model description (Exemplified by VSS - shared among implementors)
      • actual data names and descriptions (Also exemplified by VSS - shared among data providers/users)
      • actual data names and descriptions (E.g. proprietary extended VSS additional, e.g. OEM private)
    • Notice that VSS provides two different roles - defining HOW to define data, and also WHAT data, but these can be treated separately!
    • There is some talk of "other data models" in W3C, not clear if this is just other proprietary data, described in VSS-like format, or if it is described in some other format. Also not clear what those other formats might be. VSS is generally adapted to match the needs that come up.
    • The fact that some companies are worried to agree that all data names/descriptions are shared tend to block the discussion. We all understand that some data definitions are unique and private and VSS v1 already described private extensions. We understand that we benefit first from a shared way to describe it, and shared tooling, second that we also can benefit from some data being shared and defined (e.g. any "developer API" *requires* that to be defined at some point), and we also agree that companies may have some own unique and private data. Key point: No part should block progress on any other part.
    • Kevin asked about if W3C VISS service covers security access control features. Gunnar answered that it is specified weakly on VISS v1 (but that still allows for implementors to add it), and that in v2 we will see what makes it into the formal specification (timing, progress), but there are some discussions.
  • homework
    • review the draft workplan and Gunnar's slidedeck
  • AOB
    • back to the project naming ==> homework for next week- coin other project names
    • participation to OADF open conference next week in Munich ==> check whether some of your colleagues are attending it

Monday 27 May weekly call

Participants:

  • Petar (Visteon)
  • Gerald (Bosch)
  • Christian (BMW)
  • Benjamin (BMW)
  • Gunnar
  • Philippe

Minutes

  • roundtable
  • discussion on the project name, consensus on "connected services"
  • Slidedeck
    • Gerald went again through the slide deck he presented at the AMM

  • Slide #3-4:

    • Gunnar: needs to identify what are the higher level protocols we use on top of radio links

    • discussion on the roles to play by various organizations for the definition of data containers, many organizations are currently competing on this

    • Gerald: where is the most interested area for the genivi group ?

    • Benjamin: I have  multiple perspectives on those topics (slide 3), this is a highly fragmented ecosystem

    • Petar: IoT style communications are more interesting to me, having a connected vehicle does not mean a vehicle is always connected in my opinion

  • slide 6 - ISO ExVehicle

    • BMW: does not know who from BMW is involved

    • /TODO/ each participant find who in their company is involved in ISO work ExVehicle

    • /TODO/ Philippe contact Kevin to check whether high-mobility is implementing an alpha version of the ExVehicle concept and ask him to join the call

    • Gunnar: does everyone has the same understanding of what a neutral server is ?

    • Gunnar: as genivi we need to work on the interfaces between the various parts of the architecture

    • Christian: agreed, we need to define the interfaces and *do it first*

  • slide 6 - Sensoris

    • Gerald: they have something like a neutral server

    • /TODO/ each participatant attend or get information on the OADF/Sensoris workshop scheduled in June

    • The next OADF meeting will take place on June 12, 2019 in the Leonardo Royal Hotel in Munich, Germany. It will be combined with the first NDS Public Conference on the day after at the same location:
  • slide 7

    • discussion on how CCC and W3C sync on those topics

    • Gunnar: in his opinion, this should not be not a constraint for our work

    • /TODO/ each participant find who in their company is involved in CCC work

  • slide 8

    • automat: it is likely a good idea to check this project because there are 2 OEMs involved (VW, Renault) and also there seems to be a comprehensive work on security and privacy

    • Philippe: IoT - FYI genivi has a liaison agreement with OCF

    • /TODO/ Petar look into OCF work

    • Petar: kuksa project  is quite comprehensive

    • Autosar: cloud services - Benjamin discussed this with Sebastianat the AMM

    • /TODO/ Philippe contact Sebastian (Bosch) about the Autosar cloud services

  • slide 11

    • Gerald: thinks we need to pre-integrate some parts of the reference architecture

    • /TODO/ Philippe ask Daniel (BMW) why he has a concern about abstract layers and invite him to join the call

  • Gunnar will prepare a slidedeck delivering his vision of what we should work on (in reference to the 5-level ladder shown in the panel on future vehicle electrical architectures at the AMM, look at slide #3 of future EE architectures)

Monday 20 May weekly call

Participants:

  • Petar (Visteon) new participant
  • Gerald (Bosch)
  • Guru (Bosch)
  • Gunnar
  • Philippe

Minutes

  • roundtable
    • Petar: works with Visteon Connected Car team, he is a colleague of Giovanni (GPRO project), he is also based in Sofia, Bulgaria
    • Petar is the solution architect of the team responsible for the overall architecture of the Visteon platform for connected services
    • Petar has 12 year experience in connected services, for the entire stack from infrastructure to Web content end-to-end and for standard compliance
    • Petar is currently more on R&D and prototyping than production
  • Slidedeck
    • Gerald went through the slide deck he presented at the AMM
    • Gerald: session went out very well, better than expected, a lot of experience people attended, Melco (Mitsubishi Electric) which is quite involved in W3C was there and showed a lot of interest
  • next steps following AMM workshop
    • organization of weekly calls (instead of every other week):  agreed
    • /TODO/ Philippe send out an invite for the calls (starting next Monday) to the genivi-projects mailing list and the list of interested participants gathered  at the AMM
    • /TODO/ Philippe initiate a wiki page for the project
  • feedback from today's call participants
    • Petar: workplan is quite interesting, told us he identified interesting work on IoT protocol standardization, the Homie protocol specification  that he came across a couple of months ago. Although it is suggested to be home IoT-oriented, it is generic enough to provide structured data interface for IoT communication, which falls in the scope of Car to Cloud.
    • link: https://homieiot.github.io/
    • Petar: has a question on the authorization work, is it also on the cloud side ?
    • Gerald: yes, you are right, something is needed on the cloud side
    • Gerald: Daniel Wilms (BMW) expressed his concern about piling up abstraction layers
    • Philippe: this has been a recurrent concern from BMW for a couple of years
    • Gunnar: thinks this is a no brainer
  • No labels

Privacy Policy | Cookie Policy