Versions Compared

Old Version 346

changes.mady.by.user Gunnar Andersson

Saved on

compared with

New Version Current

changes.mady.by.user Gunnar Andersson

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Earlier threads (back to backlog)

...

Info

Regular meeting times.  For meeting links, please refer to the list on CVII Home Page or invitations that are sent out on the mailing lists.

Cloud and Connected Services (CCS):  Mondays 1600 CE(S)T

Common Vehicle Interface Initiative (CVII) Technology Stack meeting:   Wednesdays 1700 CE(S)T.   Also vss-tools (discussed in VSS/VSSo meeting) could be relevant.

...

  • Alignment discussion:
    • ODATA is an older model (developed by Microsoft, published OASIS standard) for business related data.
      Are there any reuse/adopt opportunities or does it not apply?   See also web site.

Monday 2021-10-25

  • We suggested to rework the overview picture into one part showing how components are stored in repository, and another for deployment
  • LiveSim is not connected at both ends.  The diagram suggests there is a deployment where data is fed from livesim but also fed back into livesim, which doesn't make sense.  You either collect real data (from some kind of VSS Feeder writing into in-vehicle state storage) or you feed the system from the livesim.  It is true that Livesim consumes a OVDS database format, but it does not 
  • Can we start using some kind of online editing tool or common format in the future? (anything that allows other people to change)
    • YEd?
    • Fallback is always PPTX file (works in MS Office and LibreOffice)

...

  • Gunnar : current CCS project focus is on the implementation of the CCS end-to-end architecture

  • Gunnar explains the status of the implementation (using the diagram in CCS Proof-Of-Concept - Reference Architecture - Work Breakdown Structure

  • Florian welcomes favorably the CCS approach to promote the use of open source and off-the-shelf components for the implementation

  • Gunnar focuses today's discussion on the identity and access management
  • Iyyaz: Hydra/Okta challenging to set up. Okta seeems popular.  Hydra is the implementation.  See https://oauth.net/code/
  • .....AWS, MS/Azure, etc. have their own offered services.
  • ...Need ideas / definition of task to progress this within CCS PoC implementation.
  • Gunnar: Self-hosted solutions?
  • Iyyaz: They are all hosted services.  Some configurability regarding which servers to use.
  • Signing up as a developer to Okta gives access to a limited account with a certain number of users  (quite many,~7000)
  • Identity and access management is a moving target, important to track security updates, etc. which speaks to partnering with expert companies.

...

review of work breakdown structure

  • CCS Proof-Of-Concept - Work Breakdown Structure updated on line
  • entries modified
    • #2 - In-vehicle VSS2 translation:  Implement CAN + VSS translation support (e.g. reuse from Bosch code project) added as an additional activity and possible option for implementing the sw components
    • #3 - In-vehicle data package: VISS server role explained in the context of production-grade implementation
    • #5 - OEM Cloud vehicle client: vehicle client configuration options added
    • #6 - OEM Cloud VSS2 database: using path as ID
    • #8 - OEM Cloud access management: Iyyaz points to the following code
    • #10 - Neutral server data marletplace: note added on neutral server API
  • addition of AWS tools in the Cloud Infrastructure Tools section
  • new sprint created (Sprint 17)

...

  • Kevin: CVII call of last week was positive, Q. can we embed our CCS poc in the bigger CVII picture ?

  • quick look at CCS Proof-Of-Concept - Reference Architecture - Work Breakdown Structure

  • Gunnar: there are 2 areas where it is still worth completing the implementation

    • the graphql implementaion

    • the access management

  • Iyyaz: concenring access management, are you looking for an implementation on the cloud side ?

  • @kevin: is it for the neutral server to authenticate or for 3rd parties ?

  • Kevin: this is for both

  • Gunnar: it does not replace the authentication on the pipe to the vehicle, VISS protocol does have a definition of access control

  • Gunnar: shows the vss-graphql repository

  • Christian H: why don't we collaborate with kuksa project on this, since they have implemented it

  • Gunnar: is it aligned with OAuth ?

  • Christian H: this is to be checked with Sebastian Schidlt

  • discussion on the various approaches of authentication

  • Gunnar / Ulf: we use the same authentication mechanism but not the same authentication token on the cloud side and the vehicle side

  • Iyyaz: what are the actions resulting from this discussion ?

  • Gunnar: IMHO there is a need to review the kuksa code to check what can be reused

  • Gunnar: there is a need to cross-check whether kuksa project supports OAuth with Sebastian until next call

  • Gunnar: IMHO a deep knowledge of the OAuth2 specfication is necessary

  • Gunnar: we might be willing to explore which implementation exist in the open source

  • Iyyaz: I have been using the okta implementation of OAuth2, it is actually a service, but provides some code examples of how the service can be used

  • Christian H: the authenticator should be the code we are looking for

  • Iyyaz: points to https://medium.com/decentralized-identity/the-universal-resolver-infrastructure-395281d2b540

  • Christian H: points to  https://dev.uniresolver.io/

  • TODO look into the kuksa code

    • Christian: on Bosch side the developer is "wenwenchen", we should open a ticket in github to get in touch with the developer

    • Christian: I will check with wenwen which material is available for explaining the authentication approach in kuksa

    • Jira
      serverJIRA
      serverId121ddff2-c571-320f-9e4d-d5b9371533bd
      keyCCS-193
      created and assigned to Christian H

  • TODO Iyyaz to explain the rationale for using an external authentication service (like okta)

    • Jira
      serverJIRA
      serverId121ddff2-c571-320f-9e4d-d5b9371533bd
      keyCCS-194
      created and assigned to Iyyaz

  • Philippe: I recommend that we use the mailing list for this because it gives more visibilty than comments in a Jira ticket

  • Jira
    serverJIRA
    serverId121ddff2-c571-320f-9e4d-d5b9371533bd
    keyCCS-127
    thrown into the current sprint

...

  • review of epic
    Jira
    serverJIRA
    serverId121ddff2-c571-320f-9e4d-d5b9371533bd
    keyCCS-18
  • Jira
    serverJIRA
    serverId121ddff2-c571-320f-9e4d-d5b9371533bd
    keyCCS-106
    • Jira
      serverJIRA
      serverId121ddff2-c571-320f-9e4d-d5b9371533bd
      keyCCS-107
      • State storage is actually implemented using SQLite in the demo delivered at the AMM, ticket comm"nted and closed
      • TODO Philippe to poke Keith on the liaison with Autosar, there is a need for a translation from Autosar to VSS DONE waiting for feedback
      • Philippe: an alternative contact for Autosar might Christian H.
    • Jira
      serverJIRA
      serverId121ddff2-c571-320f-9e4d-d5b9371533bd
      keyCCS-108

      • SQLite ias accepted and used in production already, do we have alternatives ?

      • Ulf: some years ago, JLR develop something called VSI (on genivi github) that relied on shared memory

      • Gunnar: in some sense it is a kind of library, relevant to state storage

      • links in github

      • TODO Ulf to have a quick look at VSI, ticket assigned to Ulf

    • Jira
      serverJIRA
      serverId121ddff2-c571-320f-9e4d-d5b9371533bd
      keyCCS-109
      • there is a need to reactivate the discussion with Sebastian and Bosch in general
      • TODO Philippe to poke Sebastian, ticket commented
    • Jira
      serverJIRA
      serverId121ddff2-c571-320f-9e4d-d5b9371533bd
      keyCCS-121
      • Jira
        serverJIRA
        serverId121ddff2-c571-320f-9e4d-d5b9371533bd
        keyCCS-123

        • Gunnar: it would be good to demonstrate with thousands of vehicles to show the performance

        • Ulf: agreed

        • ticket assigned to Gunnar, Ulf will help adapting the go code in the server (postgres)

        • note: postgres is an option, influx DB is another option


      • Jira
        serverJIRA
        serverId121ddff2-c571-320f-9e4d-d5b9371533bd
        keyCCS-168

        • need to poke Glenn about it ?

        • ulf: would rather cancel it

        • ticket closed ac CANCELLED

    • review of backlog suspended at
      Jira
      serverJIRA
      serverId121ddff2-c571-320f-9e4d-d5b9371533bd
      keyCCS-128

review of workbreakdown structure

  • entry #1 - In-vehicle State storage : technonology choices for proof-of-concept and production-grade updated, see Jira tickets
  • entry #4 - In-vehicle Data server : technonology choice for proof-of-concept updated (Gen2 implementation now uses ovds.db file. On-demand requests are fetched from database. Timed subscriptions are also supported, i.e. send updates at regular intervals.
    • There is not yet implementation of a trigger to the gen 2 server from the database when a new value is written (SQLite supports trigger in theory).
  • entry #8 - OEM cloud access management :
    Jira
    serverJIRA
    serverId121ddff2-c571-320f-9e4d-d5b9371533bd
    keyCCS-127
    is a large piece of work
  • entry #9 - OEM cloud resource management: we still use the manually generated graphql schema
    • Gunnar: the update of the graphql schema is still to do, will poke Daniel (BMW) on this
    • a new ticket is to be created for tracking the connection between graphql and ovds,
      Jira
      serverJIRA
      serverId121ddff2-c571-320f-9e4d-d5b9371533bd
      keyCCS-181
      created
    • entry #10 - neutral data server marketplace

...

  • Jira
    serverJIRA
    serverId121ddff2-c571-320f-9e4d-d5b9371533bd
    keyCCS-87
    assigned to Unknown User (christian.heissenberger)

  • Jira
    serverJIRA
    serverId121ddff2-c571-320f-9e4d-d5b9371533bd
    keyCCS-156
    as discussed above

  • Jira
    serverJIRA
    serverId121ddff2-c571-320f-9e4d-d5b9371533bd
    keyCCS-11
    closed

    • Jira
      serverJIRA
      serverId121ddff2-c571-320f-9e4d-d5b9371533bd
      keyCCS-180
      a new one to be created (technology stack for CVII)

  • Jira
    serverJIRA
    serverId121ddff2-c571-320f-9e4d-d5b9371533bd
    keyCCS-59

    • we watched Cloudera project marketing pitch at the beginning og the AMM, to be discussed in this week's PMO call, Michael to be poked again

  • Jira
    serverJIRA
    serverId121ddff2-c571-320f-9e4d-d5b9371533bd
    keyCCS-102
    we need to identify the feature content for the next version of the demo in 2 or 3-month time (next milestone was CES at the beginning of Jan 2021)

  • Jira
    serverJIRA
    serverId121ddff2-c571-320f-9e4d-d5b9371533bd
    keyCCS-159
    add link to Stefano's presentation, ticket is closed

  • Jira
    serverJIRA
    serverId121ddff2-c571-320f-9e4d-d5b9371533bd
    keyCCS-71
    Kevin will finalize this ticket

  • Jira
    serverJIRA
    serverId121ddff2-c571-320f-9e4d-d5b9371533bd
    keyCCS-83

    • Gunnar:  we had a significant discussion on last Friday's VHAL working session

    • discussion on access control policy

    • Philippe: it would be good to create a wiki page to capture the inputs for creating an example

    • Ulf: will populate the wiki page Data Access Control

  • Jira
    serverJIRA
    serverId121ddff2-c571-320f-9e4d-d5b9371533bd
    keyCCS-105
    the follow up with the various stakeholders of CVII will be discussed in this week's PMO call

...

  • objective is to update the wiki page and align the page content with the actual status of the implementation work
  • after the update is done, Kevin will start preparing the agenda for the working session at the upcoming virtual tech summit
  • wiki page updated online CCS Proof-Of-Concept - Work Breakdown Structure
  • discussion starts with the review of the updated block-diagram at the top of the page
  • review will continue during this week's Wednesday call

...

Recap of implementation plan and status.

The plan/status table in CCS Proof-Of-Concept Reference Architecture - Work Breakdown Structure is a bit outdated (wrong(?) responsibles, wrong plan).
It still needs a bit of an update.  For now taking the notes here.

...

  • discussion on Hortonworks demo on fleet management: which radio stations are best used among a fleet of vehicles ? Sanjeev said it is an impressive demo
  • discussion on implementation of gen2 server
  • Gunnar shows the code quality guidelines
  • update of PoC WBS online

Second call - US friendly time 16:00 CET

...

...

  • Gunnar: Alex (BMW) is still waiting for a colleague to review his example before publishing it

  • Kevin: shows the tool chain Gunnar and he proposed to go from VSS2 to graphql schema, look at the model transformation workflow attached to

    Jira
    serverJIRA
    serverId121ddff2-c571-320f-9e4d-d5b9371533bd
    keyCCS-96

    • grey boxes corresponds to the open source implementation of the neutral server components that High-Mobility will provide

  • Kevin: explains the workflow and also a possible alternate workflow from VSS2 to 3rd party client (i.e. w/o going through the neutral server)

  • Kevin: for the demonstrator we will focus on the EV charging datapoints in order to show attractive use cases

  • discussion on the data packages and distance w.r.t. the data structures used by CVIM and Sensoris

    • CCS data packages (look at the high-level architecture diagram here) should be generic enough so that they can be mapped to any specific project data structures

  • Ulf: this format does not fit very well with Gen2, IMHO this is not seen in the Gen2 protocol transfer, but rather in the OEM cloud

  • Gunnar: The picture does not show it used for the transmission to the cloud but in the vehicle only.  The format might be used in the car, or not... but I think it is OK to indicate the idea of this would be there (to support historical values).   The format is not fixed yet, it needs to be refined further

  • Gunnar: the in-vehicle state storage could use SQL but might also not need it (it is a simple key-value if not multiple time stamps are stored).

  • Kevin: I will document which format to put for which version of the proof-of-concept in the wiki

  • /TODO/ Kevin V to document which format to put for which version of the proof-of-concept in the wiki

PoC design & implementation

...

PoC design & implementation - please refer to CCS Proof-Of-Concept - Work Breakdown Structure

  • Gunnar: suggests Ulf translates the slides he presented last week into a set of SQL instructions
  • Philippe: IMHO we need to change to a implement and build mindset now
  • Philippe: we need to think about the minimal demo we will show in one-month time at the virtual tech summit mid-May
  • Ulf: it would be good to connect the data lake, the vehicle client and the data server (look at the proof-of-concept block diagram)
  • Philippe: invites Ulf to join the Monday call with Sanjeev
  • Gunnar: shows the vehicle client implementation VehicleSignalInterfaceImpl he tried out
  • discussion on the feature set for the mid-May demo
  • Gunnar: timestamp is enough (please refer to the wiki page Data serialization / value formats)
  • Kevin: do the language or platform we use for the PoC implementation matter ?
  • Gunnar: my proposal at this stage is that this does not matter, it is easier to do that way

...

  • Gunnar; presents the refinement made on the component interface last week, in CCS Proof-Of-Concept - Reference Architecture - Work Breakdown Structure
  • Gunnar: we are now collecting proposals for graphql schemas
  • discussion on impact on Sanjeev's workitems
  • Sanjeev: in my opinion, we might need someting like an object store for the data lake
  • Gunnar: Ulf is likely to propose a relational data base
  • Philippe: Ulf will make a presentation on the data lake in this afternoon CCS call
  • Sanjeev: is there any reason to use a relational database ? I saw the data coming as a continuous data stream, unless there is a need of classification of data, I am wondering why we should use a database
  • Gunnar:  understood, in the long run, the name data lake means there could be very diverse data and it could make more sense to look into an object oriented database for instance
  • Sanjeev: I stumbled in similar problems in the IoT domain
  • Gunnar: we might go to Hadoop in a later version of the proof-of-concept

...

  • continuation of the review of CCS Proof-Of-Concept - Reference Architecture - Work Breakdown Structure, wiki page updated online
  • component #1 - in-vehicle storage

    • the selection of database is  perhaps to be shared with AASIG VHAL project

  • component #2 - in-vehicle VSS2 translation (a.k.a. VSS feeder)
    • we need to set up a call asap with Bosch to determine what could be reused from Kuksa project and to discuss the model transformation tools (VSS-to-Franca and Franca-to-ARXML)
    • /TODO/ Philippe to contact Bosch (Sebastian and Christian) for setting up the call asap
  • discussion on the simulator that might be used to feed simulated data in the poc
    • Keith: presents shortly the LGE simulator
      • the simulator is based on unify and can be run using ROS and be interfaced with AutoWare (https://www.autoware.org/) and Apollo (https://github.com/ApolloAuto/apollo)
      • the simulator provides driving itineraries corresponding to big chunks of San Francisco
      • the simulator needs to run on a very powerful desktop, it might be appropriate for a CES kind of demo
    • Philippe: the LGE simulator could be an option for the milestone #4 of the CCS PoC (demo at CES 2021)
    • Gunnar: what do you mean by interfacing Apollo ?
    • Keith: you can run Autoware or Apollo to enable the execution of open source ADAS stacks
  • component #4 - OEM cloud - vehicle client
    • there are several options for this implementation
    • curl scripts proposed by Gunnar are only a plan C or higher for the implementation, other options are to be analyzed first
  • short discussion on open source licence
    • Keith: would prefer Apache 2.0, MPL 2.0 copyleft is much too strong for the automotive industry (e.g. vsomeip used by Adaptive Autosar demonstrator)
    • Gunnar: currently, we are doing our shopping list for the poc based on existing components
    • Gunnar: it is only if new components are developed and hosted by GENIVI that the question of the open source licence needs to be analyzed, anyway GENIVI has a list of "green" licences and is not limited to MPL 2.0 if necessary
  • component #8 - OEM Cloud (Resource Management =) Data server API

    • Gunnar emailed Adnan (BMW) and Daniel (BMW) to get some clarity on their GraphQL work

    • Philippe: Alex (BMW) showed the work on GraphQL he did for the AASIG EDS PoC yesterday, his work might also help with this

...

  • /TODO/ all CCS participants to review the Geotab document on EV data access requirements
    • Philippe reminds this TODO to participants, Kevin will look at Geotab document this week
  • /TODO/ Rex to review the Adaptive Autosar signal-to-service specifications
    • Philippe asks Keith (who knows well the Adaptive Autosar stack) whether he could provide an overview of the signal-to-service specifications to the CCS team
    • Keith: will do,
      Jira
      serverJIRA
      serverId121ddff2-c571-320f-9e4d-d5b9371533bd
      keyCCS-88
      Jira ticket created for tracking
  • sync on the communication framework
    • Keith was able to join today after a long period of overlapping between CCS call and other calls that prevented him from joining
    • Kevin: for the sake of synchronizing Keith with the CCS current status of work, Kevin presents the CCS PoC as described in CCS Proof-Of-Concept - Reference Architecture - Work Breakdown Structure
    • Keith: asks how we can get the gps position of a fleet of cars using the communication infrastructure proposed in the poc
    • Kevin V / Philippe: we might have different variants of the poc depending on whether we simulate the vehicle data or we use existing devices like the Geotab Go device if we want to connect to actual cars
    • Philippe: for the vehicle simulation, two options have been discussed in the GENIVI AASIG project which is also working on a poc : either using the vehicle simulator published by JLR on GENIVI gitub (genivi-vehicle-simulator repository) or using opends
    • Keith: indicates that LGE Labs in the Silicon Valley have also a vehicle simulator
    • Philippe: although we will start with laptops as execution targets for the poc, we might switch to automotive boards for the in-vehicle segment of the poc in the future, FYI Renesas has set up a lava-based test farm (with R-Car boards) to build and run the GENIVI CI process, we could use the test farm to simulate the vehicle segment
    • Keith: FYI Adaptive Autosar has decommissionned their test farm and runs the CI process on qemu only
    • Philippe: invites Keith to the second call of the week which is dedicated to the communication infrastructure

...

  • Philippe: reminds that it is now time for the team need to pick up some of work items for the CCS PoC implementation,
  • Ulf: I can take over the data server, and its connection to the state storage in the in-vehicle OS box, I am also interested in the data lake

  • Kevin: we can provide sample applications for the 3rd party service and neutral server marketplace boxes, i.e. entities that will consume graphql apis

  • Philippe: what about the OEM cloud box ?

  • Gunnar: we need to determine the signals and the use cases we want to show

  • Kevin V: we should show different data categories including big data chunks

  • Kevin V: showing anonymized data is not really possible because this requires a lot of data, it would be better to show different categories

  • short discussion on the demo use cases
  • Philippe: explains the use cases selected by the AASIG for the PoC demo (EV data, speed & tyre monitoring and air conditioning
  • need to add the use cases definition work item

  • Gerald: I might be able to pull in someone in the in-vehicle OS box , I will ask Sebastian and Christian whether they could recycle something from the kuksa project for the state storage

  • Gunnar: we need to agree on the format for storing values, e.g. time stamps and values of different types

  • Gunnar: I would like to get an example of a query for getting multiple snapshots of vehicle data in order to make graphql shine a little bit

  • Kevin V: if you look at the state of the vehicle, you have a benefit of using a graphql query (get multiple data in one query)

  • Kevin V: it should also possible to push data with graphql

  • discussion on the protocols between boxes

  • Gunnar: I am still waiting for an actual schema for using graphql from someone

  • Philippe: what about Geotab / Canada ?

  • Kevin S: I am still chasing what GENIVI is doing, I see myself in a support role rather

  • review and update of the owner column in the WBS table

  • Ulf: someone else has to take over the vehicle simulation

  • Philippe: execution targets will be laptops for the initial implementation

  • Vehicle client
    • vehicle client: Sanjeev's work does not seem to be directly reusable
    • Ulf: the client would be repsonsible for stoting the data into the data lake
  • Data lake
    • Gunnar: concenring the data lake, do we have a database person in the call ?
    • KevinV not on my side
    • Ulf: this is where we should try to get BMW in,  it won't be a good idea to invent our own database structure
    • Ted: their solution is based on VSS/VSSo too, trying to get Adnan to present what he showed at last W3C F2F
    • Gunnar: I talked to Adnan yesterda
  • OEM cloud

    • Gunnar: what the resource management is all about in this box ?

    • Kevin V: resource management comes from the extended vehicle ISO standard

    • Gunnar: can we replace this naming by "data server apis" in the OEM cloud

    • Kevin V: agreed

  • Neutral Server market

    • Kevin V: it is important that we consume data coming the OEM cloud (server) api

  • Miscellaneous

    • Gunnar: I could likely take over the vehicle client and the graphql and data base

  • Test farm

    • Stephen: I checked the use of lava farm for running the CCS poc, do you want to use a RTOS in the in-vehicle OS box or linux ?

    • Gunnar: we can plan for this at a later time, The PoC will be linux-based including the in-vehicle OS box

    • Philippe: however Renesas could an Adaptive Autosar demonstrator stack in the in-vehicle OS box, this would be good for the demo, it will still be linux-based because the Adaptive Autosar demonstrator is based in RT Linuw

...

communication framework

  • Gunnar: shows the CCS PoC WBS
  • Gunnar: aks Sanjeev for clarification on the work he is doing on the so-called clients
  • Sanjeev: I limited the scope of my work to the W3C demo shceduled un a couple of weeks time
  • Sanjeev: I implemented http and websocket connections for the Tizen watch, we have now the vehicle dashboard on the watch, the java scripts used in this implementation are quite straitghforward but need to be rewritten for better clarity
  • Sanjeev the watch code is in the app store, but I intenf to publish the code as well, the web interface is avauable is the daemon folder, the watch interface is pretty much a html interface
  • Ted: Magnus from Melco set up the Gen2 server instance on MIT cloud host, the app could point to that
  • Ted: has set up a Gen2 server instance for demo purposes
  • Ulf: this data server is up and running, it is available but the link to it has not been released yet
  • Ted: link is https://www.w3.org/auto/wg/wiki/Vss_data
  • Sanjeev: back to the clients I am developing, I want to separate the library interfaces from the UX
  • Gunnar: we need to figure out an idea of the demo we want to do, we need to major progress on this actually
  • Kevin V: there is a lot of different use cases, that could be used to demonstrate the PoC
  • Gunnar: we can work with simple queries, but it owuld be good to have simple queries moving a lot of data in odrer to learn abour possible bottlenecks in our communication framework proposal
  • Benjamin:  we could reuse what we have introduced in the data bundles
  • Rex:  do you have at Geotab a document listing all the telematics data ?
  • Glenn: I am not aware of it
  • /TODO/ TBD (Benjamin ?) to compare Geotab doc on EV data requirements and the content of the data bundles wiki page
  • Ulf: asks whether Gunnar can present the CCS PoC block diagram in next week's W3C virtual meeting
  • Gunnar: will do

...

  • Ulf: informed Ted (W3C) about the work we are planning to do on the CCS PoC and invited him to join the call
  • Gunnar: introduces briefly the 2 main thrads of activities in the CCS project: vehicle data model and communication infrastructure, then presents the CCS PoC wiki page CCS Proof-Of-Concept Reference Architecture - Work Breakdown Structure
  • Ted: are you in contact with Graham Smethurs at BMW ?
  • Philippe: Yes, there is an action item to talk to him
  • Ted: are the CCS PoC aligned with BMW ?
  • Gunnar: yes; we are very much aligned on the data server between GENIVI CCS and AASIG projects , and BMW is active in AASIG and promotes graphql there
  • short discussion about Sanjeev who completed the Gen2 clients on Tizen (for the Samsung watch), Linux, and Android, Sanjeev seems to be looking at graphql as well (TBC)
  • Philippe: I have an action item to contact Sanjeev that we happen to know very well due to former collaboration on demonstrators
  • Ted: I talked to John S at Ford recently, Ford is still in the process of making plans concerning the vehicle data APIs
  • Philippe: @Ted John delivered a talk in the CCS project track at the GENIVI tech summit of Nov 2019 in Troy, USA, slide deck is here
  • Gunnar & Philippe invite Ted to join the CCS weekly calls
  • Ted will be added to the CCS mailing list

...

  • Kevin presents the wiki page containing the WBS
  • /TODO/ all participants to review the WBS and identify which work item could be taken over
  • Gunnar shows 
    Jira
    serverJIRA
    serverId121ddff2-c571-320f-9e4d-d5b9371533bd
    keyCCS-11
    where he added the list of technogolies that could be used for the PoC
  • Ulf: regarding the client implementation Sanjeev is doing, Sanjeev will present his work as part of the remote F2F W3C will have at the end of the month, Sanjeev is working on different platforms including an Android app
  • OEM cloud: Kevin is fine with Hadoop
  • Glenn: we need to remap the data from different OEMs to a common standard, go back to the data guys and talk to them about the pinpoints
  • /TODO/ Glenn provide feedback on a possible common standard for next week
  • /TODO/ Philippe set up a call with Sanjeev and invite him to follow / join the CCS project
  • Rex: IMHO we could set an Adaptive Autosar stack in the cloud
  • Philippe: possibly but in my opinion this is for the future, the architecture of the current PoC adresses a mid-term vehicle EE architecture (like the one depicted on slide #4 and marked as "today" of the VAP presentation by Bosch), having an Autosar stack in the cloud corresponfs rather to a future vehicle EE architecture like the one depicted on slide #4 and marked as "smart infrastructure" of the VAP presentation by Bosch

...

  • Connected Services project charter

    • Philippe asks participants to review the project charter and provide comments by next week

    • Philippe: asks participants for their inputs on what should be the project deliverables; he suggests a combination of paper work (likely EA (UML) models, text-based specifications) and code (prototype implementation, proof-of-concept), reminds that Gerald presented the list of outputs of the various sprints identified in the workplan he presented at the last AMM (look here)
    • Kevin: the text is good, the charter will be useful for sharing with the HM team
    • /TODO/ all review the project charter and send comments to Philippe by email by next week
  • ISO Extended Vehicle update
  • W3C work status
    • Gunnar presents the content of the following wiki page Connected Services: W3C VISS/VSI specification status
      • discussion on proff-of-concept implementation of the VISS/VSI
    • Kevin: is there a general plan/timeline for VSS Gen2 ?
    • Benjamin: things will be delayed until the data models for transportation workshop has happened (scheduled on 12-13 September 2019)(look here)
      • current WG charter started on May 2018 and will end on June 2020, 
        Jira
        serverJIRA
        serverId121ddff2-c571-320f-9e4d-d5b9371533bd
        keyVCS-27
          commented
  • Sensoris
    • Gerald shows a slide deck (link TO BE ADDED) from Bosch describing the status of Sensoris work
    • Version 1.0.0 of the Sensoris specification will be released in the next days under CC-ND license
    • data provided by Sensoris are not only about the vehicles but about the environment
    • Version 1.1.0 will introduce the concept of "jobs"
      • jobs = login jobs running for a certain period of time for a certain fleet of vehicles
    • Gunnar: it would be good to identify how much overlap we have, shows the interest of different domain taxonomies
    • Gerald: it would be good also to set up a call with the sensoris project once we have reviewed the Sensoris specification that will be published soon
  • AOB
    • telco schedule
      • DECISION  we will start scheduling the weekly call on Monday afternoons at 4pm CET next week (8 July)
      • (added offline) cloudera and autonomic.ai which are based on US Pacific coast have been invited to join

...