Versions Compared

Old Version 334

changes.mady.by.user Philippe Robin

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

Starting on Wednesday 27 January, the CCS call on Wednesdays gives room to the CVII Technology Stack call, same time (5pm CET). CCS call on Mondays will continue and covers both Vehicle Data and Communication Framework

All tickets query:

Expand

Jira
serverJIRA
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
maximumIssues20
jqlQueryproject = CCS AND resolution = Unresolved ORDER BY priority DESC, updated DESC
serverId121ddff2-c571-320f-9e4d-d5b9371533bd

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.

All tickets query:

Expand

Jira
serverJIRA
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
maximumIssues20
jqlQueryproject = CCS AND resolution = Unresolved ORDER BY priority DESC, updated DESC
serverId121ddff2-c571-320f-9e4d-d5b9371533bd

Monday 2021-11-22

  • 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)

Monday 2021-08-23

  • Geotab data format to VSS conversion is possible.  About 50 signal translations have been defined.
    • Data sets can then be provided (in OVDS format) 
    • Position information likely coming (pending consent).
    • examples: position, speed, ignition, oil temp, turning indicators, seat belt
    • 5-10 vehicles, that type of range.
    • How can/shall we use this data?
  • Stephen reminds about VSS-formated dataset that Access has defined before (available with a demo in GitHub).
  • CCS demos have before focused on Vehicle→OEM cloud parts.  Development in the usage of data, cloud based applications, and deployment/automation as previously discussed.
  • Curve logging implementation in VISS is new compared to last AMM.  It can be demonstrated.
  • Android app - reads from VHAL sends signal to cloud.  Opportunity to use VSS and/or VISS?

Monday 2021-07-12

Participants

  • Florian Pinzel
  • Nikhil Shirka
  • Vishwajit Joshi
  • Stephen Lawrence
  • Gunnar Andersson

Minutes

  • No updates on Tech Brief from Iyyaz this week.
  • Two new participants from KPIT.  Introductions and quick project overview of CCS and CVII.
  • Ongoing vacation season (in Europe).  There will be a break and some meetings will be cancelled in the next few weeks.  (Information coming via email)

Monday 2021-07-05

US friendly time 16:00 CET

Participants

  • Stephen, Florian, Gunnar, Philippe
  • apologies: Kevin, Iyyaz, Ulf, Ted

Minutes

vacation plan

  • discussion on vacation plan of the participants

ISO ExVe

  • following the discussion on ISO ExVe in the CVII workshop, Philippe reports the Renault representative in this WG contacted him and confirmed he will organize a presentation of CVII to the vehicle data subgroup of the French PFA (French equivalent of German VDA) in September
  • Gunnar and Philippe provide a short debrief to Florian on the outcome of the call with ISO WG6 participants on 23 June (ISO WG6 convenor, Stellantis representative, Audi representative, Gunnar, Ted, Philippe). Call went out well. A presentation of CVII to ISO WG6 is likely to be scheduled at the next meeting of ISO WG6 in late August / early September

  • summary of discussion with ISO people is below

    • convenor: in ISO we are starting to work towards enabling third parties to get data and functions embedded in the car within the ExVe architecture, we realized it is difficult to get a similar set of signals from the different OEMs, this is why we decided to move only to an harmonization of the data description among the vehicle OEMs

    • Gunnar exposes the GENIVI/W3C vision

    • Stellantis : we do not want to harmonize the vehicle EE architecture among the OEMs, we do not want to have the same characteristics for the data we get

      • there is no direct access between the neutral server and the vehicle

      • the neutral server knocks at the door of each OEM cloud interface

    • Audi: there is no definition of accessible data, we do not define which data are provided, we are looking for a generic way to describe data

    • Gunnar: ISTM the ExVe interest is with the meta-model

    • convenor: we are discussing more about API catalog than data catalog; it will be something like a function catalog

    • Audi: in our specifications, we are describing the way and how the functions can be accessed (with security) and not the resources themselves

    • convenor: asks where we consider putting the layers implementing the CVII translation / conversion

    • Stellantis: you should talk to Bosch BSH, they have a similar block diagram for the home automation

    • convenor: shows one slide of the presentation he made to UNECE in Geneva a couple of months ago, the slide shows the different ways to access the vehicle data

Monday 2021-06-28

US friendly time 16:00 CET

Participants

  • Stephen, Ted, Gunnar, Philippe
  • apologies: Kevin, Iyyaz, Ulf

Minutes

tech brief

  • Iyyaz said via email that he will send the draft document on Wed/Thu this week

OPIN

  • in the minutes of last Friday"s OPIN meeting, Steve and Philippe got an action item to provide a OEM oriented use case (Steve suggested a driver distraction use case) and a (truck) fleet management use case. Philippe suggested in the same call the use case related to the refrigeration of the cargo bay (monitoring of the cargo temperature)
  • Gunnar: concerning trucks and their cargo, we have a signal in VSS indicated whether the trailer is hatched / not hatched
  • Gunnar: concerning the OEM use case, we have in VSS signals that could be relevant for detecting the driver's behavior
  • Gunnar: IMHO the technical architecture is in place and we should not be contemplating architectural changes due these additional use cases
  • Philippe: asks whether Ted could find some help within Geotab to provide a truck fleet management scenario to share with OPIN
  • Philippe: proposes to reach out to Kevin and ask whether High Mobility could provide a OEM use case (e.g. driver distraction)
  • discussion follows on the coordination between Catena-x and VSS and OPIN and the structuring of vss signals

Monday 2021-06-21

US friendly time 16:00 CET

Participants

  • Ulf, Iyyaz, Stepahen, Ted, Gunnar, Philippe
  • apologies: Kevin,

Minutes

tech brief on CCS mapping to cloud providers



...

Monday 2021-06-14

US friendly time 16:00 CET

Participants

  • Ulf, Iyyaz, Stephen, Ted, Gunnar, Philippe
  • apologies: Kevin

Minutes

tech brief on CCS mapping to cloud providers

  • Brainstorm (document structure, headings, content, principles, goals...) for the tech brief
  • look at Tech Brief planning on CCS mapping to cloud providers
  • TODO all to consider taking ownership of the tech brief for the writing of the document,  remember that our practice is to have the contributors' name and company advertized in the tech brief

Monday 2021-06-07

US friendly time 16:00 CET

...

  • 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.

...

  • Jira
    serverJIRA
    serverId121ddff2-c571-320f-9e4d-d5b9371533bd
    keyCCS-167
    ,
    Jira
    serverJIRA
    serverId121ddff2-c571-320f-9e4d-d5b9371533bd
    keyCCS-143
    • discussion on Benjamin's review comments (look at file attached to the ticket)

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

    • Gunnar: shows the addition made to Value measurement Data serialization / value formats wiki page, i.e. a geospatial record in addition to the timestamp record

    • Christian: are we safe w.r.t. possible changes of Sensoris in the future ?

    • Gunnar: Sensoris always includes the position because of its orientation on sensing the vehicle environment, Sensoris data set complements VSS

    • Christian: we should talk to Sensoris

    • Gunnar: yes, we will do, we want do discuss the license

    • Christian: Sensoris is open to discuss the licensing

    • TODO Christian to organize a meeting with Sensoris, i.e. Bosch representative in Sensoris + others, ticket will be assigned to Christian

...

  • Jira
    serverJIRA
    columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
    serverId121ddff2-c571-320f-9e4d-d5b9371533bd
    keyCCS-72
    changed to done

    • Glenn has provided the link to the video presenting the Geotab algorithm

    • Ulf: the functionality for this algotrithm will be in Gen2

    • Gunnar: I will look at this video, I am not sure whether the compression algorithm should be part of Gen2, other statistics like an average could be implemented in a "node", this must be discussed with W3C people

    •  

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

  • Jira
    serverJIRA
    columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
    serverId121ddff2-c571-320f-9e4d-d5b9371533bd
    keyCCS-74
    changed to done

    • Glenn has provided the link to the NTHSA paper on V2X and an additional paper

    • Gunnar: will look at it as well

      Jira
      serverJIRA
      serverId121ddff2-c571-320f-9e4d-d5b9371533bd
      keyCCS-157
      created

    • note: this ticket is rather a topic for a Monday call

  • Jira
    serverJIRA
    columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
    serverId121ddff2-c571-320f-9e4d-d5b9371533bd
    keyCCS-4

    • Gunnar: the wiki page Value measurement Data serialization / value formats is now finalized, all subtasks are done, changed to done

    • The overall analysis feels quite done now. If the idea of edge-processed / statistical values becomes more refined then there might be a few more subclasses to define those different types of calculations, but we can leave that for later.
    • If we want to cover MQTT just for good measure, then this needs a concrete data encoding and that's covered in CCS-143
  • Jira
    serverJIRA
    columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
    serverId121ddff2-c571-320f-9e4d-d5b9371533bd
    keyCCS-96
     &
    Jira
    serverJIRA
    columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
    serverId121ddff2-c571-320f-9e4d-d5b9371533bd
    keyCCS-97

    • Kevin will add concluding comments to both tickets and close them

  • Jira
    serverJIRA
    columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
    serverId121ddff2-c571-320f-9e4d-d5b9371533bd
    keyCCS-97
    • Ulf added a concluding comment on Daniel Wilms' vision of the data lake design

    • Daniel Willms view is that the graphql server should directly access the SQL database, instead of via the HTTP interface that the OVDS server exposes. 

    • That makes possible more complex queries on the data set than what is possible through the OVDS server interface. I see no problem with exposing both, and let a client choose which to use.

    • Jira
      serverJIRA
      serverId121ddff2-c571-320f-9e4d-d5b9371533bd
      keyCCS-158
      created and assigned to Ulf
  • Jira
    serverJIRA
    columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
    serverId121ddff2-c571-320f-9e4d-d5b9371533bd
    keyCCS-59
    changed to in-progress
    • Gunnar sent an email to Cloudera
    • link added to Sanjeev's work
      Jira
      serverJIRA
      columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
      serverId121ddff2-c571-320f-9e4d-d5b9371533bd
      keyCCS-124
  • Jira
    serverJIRA
    serverId121ddff2-c571-320f-9e4d-d5b9371533bd
    keyCCS-102
    comment added

    • Gunnar: production in my mind means actual deployment in the industry, in order to manage millions of vehicles, our work is not going to reach production, I tried to capture in this column of the work breakdown structure (and this ticket) which technogoies need to be changed to go to that kind of scale

    • Gunnar: we should not talk about a reference version term and use v1,v2,v3,v4 to label the maturity of the implementation

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

    • Ted: refers to an email sent by Arnand, who is not sure whether we need to look at specific use cases, we should rather be looking at the data points (as required by the European Union for instance)

    • looking for business cases is not relevant anymore, ticket changed to done


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

    • Philippe: will do this review, ticket reassigned

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

    • Philippe: we need to create a ticket to bring elements for a story telling about the use cases

    • Ted: next week I will meet with John from Ford and they will talk about the group John is forming within Ford

    • Ulf: about the biz cases in the graph project, at Geotab we believe we have to change the solution because we think that OEMs will not agree to share vehicle data in the same repo , Geotab thinks the model has to be revised
    • Ulf: we will come back with a proposal on how to explain the biz value of the graph project to the OEMs and other stakeholders in two-week time likely
      • ticket assigned to Ulf for tracking the presentation of this proposal

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

    • Gunnar: no feedback from the security team although some of them might be aware of this EU work

    • Philippe: the list of reviewers who provided comments on the EU document is available here . 3 OEMs did it (VW, Volvo Cars, Tesla  and ACEA which represents the European OEMs)

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

    • Gunnar/Philippe; the same question can be asked both Geotab and High Mobility

    • Kevin: it is difficult to relate our CCS work to a commercial platform, this is about how the CCS work could be integrated with a commercial platform

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

    • Kevin: will descrive the oem cloud resource management

    • "In the communication framework we have a distinction between different interfaces from the OEM cloud:

      • Consent Management
      • Authentication Management
      • Resource Management (data access)

      This has been done as a best practice and to follow the Extended Vehicle architecture. However for the PoC it makes to simpify. What is needed is an API component that exposes the GraphQL server externally to Neutral Servers and 3rd parties. This component has to take care of querying the requested data from the OEM cloud database as well."

...

  • 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

...

  • Gunnar: goes through the latest modifications he made and through Ulf's comment at the end of the page
    • Jira
      serverJIRA
      serverId121ddff2-c571-320f-9e4d-d5b9371533bd
      keyCCS-91
  • Gerald: it is a side topic maybe, can we discuss in the future the anonymization of the vehicle ID ? in C2C they provide temporary IDs and change it every 5mn
  • Gunnar: update the "vehicle identity" definition in the wiki page online
  • Philippe: what is the status of
    Jira
    serverJIRA
    serverId121ddff2-c571-320f-9e4d-d5b9371533bd
    keyCCS-93
    ?

  • Gunnar:  in the value measurement formats we have similar concepts as in CVIM and Sensoris, we need to check what maps to what

  • Ted: Sensoris is part of the Geospace consortium (OGC.3c work), AFAIK Sensoris is not technically aligned (tbc)

  • Gunnar: Unknown User (benjamin_klotz) can you help us do the mapping between the value measurement formats and the Sensoris spec ? ideally we should share the same names and perhaps the same content

  • Benjamin: I can do that both for Sensoris and CVIM as well

  • CCS-93 commented and changed to in-progress

  • discussion on Gen 2

  • Gunnar: I am not sure Gen2 needs to integrate the value measurement formats

  • Ulf: IMHO most of these should be outside of gen2

  • Gunnar: shows the "Protocol does not (yet) cover all variations of data exchange" bullet point of the section "Relationship to Protocols"  of the wiki page

  • Ulf: however some data structures shown in the value measurement formats should be added to a gen2 client if the client needs historical data (Ulf Bjorkengren please review here and below)

  • Ulf: my proposal was that if a node supports historical data you can have metadata in the tree

  • Ulf: we need to discuss this in the Gen2 group

  • Ted: how does an application register and sign up to use data (this is related in my opinion to the best practice work in W3C ) ?

...

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 Value measurement 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

...

  • Kevin V : explains the comments he made to the wiki page (look at the bottom of the page)
  • Kevin V: we need such a protocol to be defined, the content of the wiki page is very advanced
  • Kevin V: sensitivity level - an example of such an attribute is driver's fatigue  (high) vs. engine oil level (low)

  • Gunnar: thanks for your very good feedback

  • Gunnar: the container is some kind of top level messaging format

  • Gunnar: I tried to work out a type hierarchy with subtypes

  • Gunnar: we should think that the content of the wiki page comes down to a generic protocol definition that could be instantiated into several actual protocol specifications

  • Gunnar: the W3C Gen 2 protocol might not take over all the facets of the generic procotol as it is defined there, but if we can align on some definitions and naming with W3C it would be good

  • Jira
    serverJIRA
    serverId121ddff2-c571-320f-9e4d-d5b9371533bd
    keyCCS-81
    done
  • Philippe: did you have a look at the description of formats ?
  • Ulf: not yet, however since I am very Gen2 centric, I would say the formatting layer lies on top of Gen 2,  using Gen 2 as the transport mechanism
  • discussion continues of the position of the formatting layer in the CCS PoC
  • quick check on the sprint & backlog
    • Philippe: the cross-checking w.r.t. CVIM and Sensoris is to be performed next
    • Jira
      serverJIRA
      serverId121ddff2-c571-320f-9e4d-d5b9371533bd
      keyCCS-4
      , subtask
      Jira
      serverJIRA
      serverId121ddff2-c571-320f-9e4d-d5b9371533bd
      keyCCS-93
      unanimous consent to reassign this ticket to Benjamin because of his former work on CVIM and Sensoris (smile)

...

  • 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

...

  • Gunnar: shows the modifications of Value measurement Data serialization / value formats wiki page he made since last Monday call

  • Keith: remark on VIN number vs MAC address

  • Gunnar: I use here the VSS defined VIN

  • Gunnar: details the record types and subtypes

  • Ulf: do you envision this to be on top of Gen2 ?

  • Gunnar: this should be on top of every single protocol we want to use

  • Ulf: agreed, Gen2 is one protocol (the only one for the time being)

  • Ulf: IMHO this translates partially into subscribe requests on Gen2

  • Gunnar: yes, the subscribe request is close to what I explained here

  • Gunnar: my expectation is that all participants this wiki page and check whether the naming of the various items described is appropriate

  • Ulf: I will look into this,

    Jira
    serverJIRA
    serverId121ddff2-c571-320f-9e4d-d5b9371533bd
    keyCCS-91
    created

  • Kevin: likes it a lot, it is a very comprehensive set of definitions, are these definitions independent of the data models ?

  • Gunnar: yes

  • Kevin: CVIM & Sensoris touched this a little bit, job and streams are a litthe bit independent from the other definitions

  • Ulf: Kevin pointed  out a very crucial thing, how do we structure the storage in the cloud VSS tree, we need to complement the values with time dimension & VIN dimension ?

  • Ulf: it is quite complicated to come up with the best solution

  • Gunnar: agreed, this is not trivial

  • Kevin: it is good to define various layers like time series, etc.

  • Gunnar: we need to analyse how this work can influence the definition of the database schema

  • Gunnar: any volunteer for the review of this ?

  • Kevin: I will look at it,

    Jira
    serverJIRA
    serverId121ddff2-c571-320f-9e4d-d5b9371533bd
    keyCCS-92
    created

  • Gunnar: I will look into Sensoris and CVIM afterwards

  • Jira
    serverJIRA
    serverId121ddff2-c571-320f-9e4d-d5b9371533bd
    keyCCS-90
    created for tracking the update of Value measurement Data serialization / value formats wiki page

communication framework

...

  • 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

...

  • Philippe: we need to start thinking about the identification of APIs that could be standardized

  • Gunnar: we are at a very early stage, i.e. first iteration of the PoC, the identification of APIs will take time and several PoC iterations

  • Gunnar: I would propose to start a design justification wiki page for the poc where we can capture the rationale for selecting the components (currently the number one criterion is that the component exists)

  • Philippe: reminds about the following wiki pages Big Picture & Design concerns that might contain some useful inputs

  • Gunnar: there is this wiki page Vehicle data exchange protocols

  • Gunnar: I have also created the following wiki page Value measurement Data serialization / value formats, the content was reviewed with Unknown User (benjamin_klotz) during Monday's vehicle data call and then augmented, it would be good you read it

  • /TODO/ CCS participants to review the wiki page Value measurement Data serialization / value formats
  • Philippe: next week we need to go through Jira and do a sprint review and we need to kick-start the implementation work

...

  • discussion starts on the EV data access requirements
    • /TODO/ TBD (Benjamin ?) to compare Geotab doc on EV data requirements and the content of the data bundles wiki page

    • Philippe: brings clarification on his expectation concerning data categories vs EV data requirements sent by Geotab

  • discussion continues on the definition of data bundles as described in the wiki page previously named Data Bundles

  • Gunnar: in his opinion, it is now important to start looking into the format for message values

  • Gunnar shows the wiki page Value measurement Data serialization / value formats he drafted
    • review of the definition section of this proposal
    • Benjamin: agrees with the definition of a signal
    • Benjamin: for the record item, he would rather use observation or measurement
    • discussion of examples for a record, with timestamp attached and possible additional information
    • there is the special use case of streaming where you have a continuous connection: look at the stream item
  • discussion continues on data format requirements for the different types of signals
  • wiki page updated online by Gunnar, look at Value measurement Data serialization / value formats

Second call

  • /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

...