Page History

...

• OCF (Open Connectivity Forum) Cloud Services WG introduction
• GENIVI technical summit - announcement and content planning
• Design concerns wiki page - feedback from participants
• Gap analysis deliverable - status of drafts
• Sprint & backlog review
  • look at active sprint & backlog of VCS tracker

...

• OCF (Open Connectivity Forum) Cloud Services WG introduction
  • Ondrej works for Kitsler, a sensor manufacturing company https://www.kistler.com
  • Ondrej shows a slide deck on OCF Cloud WG, Device API for Cloud Services, Cloud API for Cloud Services>>>>>
  • Philippe: IMHO the OCF cloud services are to be added as a possible cloud-based framework for poc development & end-to-end integration in the later stages of CCS project
  • Gerald: can we possibly clarify about the mapping of the OCF cloud services to the automotive use cases ? with vendor A = BMW and vendor = GM for instance
  • Ondrej : my car is one of the devices, when I sit in my car, I can see my local (home) data
  • Guru: is there a limitation on the number of vehicles connected ?
  • Ondrej: the implementation is fully scalable
  • Ondrej will share the slide deck and the API specifications with GENIVI (how to share these materials with the CCS participants is being checked)
• GENIVI technical summit
  
  • Philippe:announces the date and location for the tech summit - Tuesday 12 and Wednesday 13 November, in Troy, Michigan, USA and outlines the tech summit content that will focus on Android Automotive SIG, Cloud&Connected Services and Cybersecurity for the Vehicle
  • Steve: has spent last couple of weeks reaching with Ford, GM and FCA, metwith Ford alrealy and will meet with GM on Friday this week and later with FCA
  • Steve: the CCS project charter is close to what Ford thinks about where the market is going
  • Steve: our objective is to engage those OEMs (and their suppliers) in working sessions about the CCS project
  • Philippe:  please all of you put a note in your calendar and check your travel plan ! thanks
• Design concerns
  
  • Kevin provided his inputs as comments to the wiki page, look at Design concerns, comments are reviewed online
  • Kevin: the wiki page is a very good thread opener
  • discussion on Kevin's first comment on the protocols, actually rather on the different ways of performing the data capturing from the vehicle to the servers

  • Gunnar: on the protocol for Vehicle => 3rd Party Servers, we need to go out and survey who are the players in the industry and which models of data capturing are acceptable

  • Kevin: : it's a bit of a different case, it could be brought out separately from the in-vehicle infotainment system to third-party servers, because that's the route the data would take.

  • Gunnar: presumably,  yes, it is like an app getting a direct connection and maybe we leave that out the scope and say that's not part of our infrastructure. But at the same time in order to cover all cases, we should consider these points, see what they mean for us and see if we can relate to them in some way in our specifications because otherwise companies tend to work around it anyway, and they end up doing ad hoc things that we might be able to avoid if we actually cover it in our discussions

  • Kevin: actually vehicle to third-party servers connection comes down to connecting to devices or devices in general like a smartphone, this is the obvious example of having a direct access from my mobile device or an application in a mobile device to the onboard systems, that's more of the typical MirrorLink type of solutions, but it is true there is a lack of data protocols there and if this is VSS that the Vehicle Gateway is using and if these are VSS data that are being uploaded to the cloud, then of course if there is a direct connection with Wi-Fi or Bluetooth from smartphone and the vehicle, it makes sense that the VSS model or a certain data model is used there as well.

  • Kevin: One more comment in the OEM server to neutral server part,  we should add a connection from OEM server to third-party servers or developers as in general the OEMs will provide an API both for neutral servers who serve as intermediaries and directly to third parties, that's already starting to become a common practice and should be considered.

  • Kevin: I have another comment that relates to the question Gerald mentioned with big data earlier, in my opinion there are certain (or maybe even larger) design impacts of the system considering personalized data, which are more like small data chunks with high frequency and high velocity rather than big data type of sharing between two different services. Probably the system block-diagrams are to look quite different at some components level.

  • Kevin: in my second set of comments, I added some thoughts about the third-party expectations. This is nothing groundbreaking but more practical things. The callback feature is one thing that third parties expect. Third parties rely a lot on quite up-to-date data. That means that sometimes even one minute old data is not that good because of a business case where you need to act fast on certain data or because of the user experience for instance in electric car charging where you want to get an event as soon as charging is complete.

  • Kevin: with the VSS and the W3C, I've seen websocket protocols are considered, and the system design should have (when we have a Rest API or an SDK) a callback system with web hooks, this was mentioned also in the OCF presentation. Today a lot of these OEM systems that do provide data don't provide callback systems in general and it is a bit of a headache for third parties. Typically there are different request limits that can be hard to meet at the same time, if there are no webhooks, it creates a problem because third parties want to get the latest data at the same time and the OEMs might limit them with their request limits because otherwise they get too much traffic to the servers. This kind of problem needs to be solved with technology and should be part of the system design we are considering

  • Kevin: in the last two steps of my second set of comments, I added a few things about the fleets. In general with data sharing, there is a general consent from the owners of the car, this is more for personal vehicles, when it comes to fleets, there are different considerations. If a fleet owner has 1,000 vehicles for instance, the third party application and the fleet owner are the same entity, in that case how that is handled and how the data querying is handled probably should be also part of the overall system design.

  • Gunnar: I agree with your views, IMHO we should have a list of typical applications / use cases, i.e. something to drive where we need to do different solutions. As you said, the solutions might be different for fleet management applications and user oriented applications. Also what you said about the Big Data statistics being a different one from user-centric data.

  • Kevin: agreed, I could add a list of use cases in the wiki page trying to cover some different verticals.

  • Philippe: we need to ask again Cloudera about their inputs of the system design for gathering vehicle big data

  • /TODO/ Gunnar set up a call with Cloudera to get their inputs of the system design for gathering vehicle big data

• Gap analysis
  • Gunnar: shares the draft sections on VSS available at this document and asks participants to review it
  • Guru: wonders whether building a huge wiki page containing all the sections of the gap analysis is the right approach
  • Gunnar: for the time being, in my opinion, the sections for each project should be structured according to the wiki page table of content
  • Guru: will finalize the draft sections on Sensoris accordingly in the document he initiated and will call for a review in one day or so

Monday, September 23

Participants

...