Page History

Monday, October 28

Participants

• Gunnar, Kevin, Keith, Gerald, Benjamin, Guru, Steve, Philippe

Minutes

Connected Services planning of tech summit

Session One: towards a common data model

• Introductory slides and more slides to guide a workshop:
• Define overall goal (* of workshop)
  • find a common data model
  • include questions to trigger discussion
• the goal of the project itself should be in the earlier overview presentation, but can be repeated
• /TODO/ Keith review the CCS project charter
• Outline from before:
  • starting from the data in the vehicle
  • VSS intro, AA Vehicle HAL intro
  • Report on the gap analysis (Sensoris, etc.)
  • Need for consolidating the models: Ask OEMs & participants about it
• Anticipate and think about answers to questions/concerns that come up: (Many new people, some might start from scratch with this standardization idea)
  • Hard to standardize on CAN signals
    • (find useful subset (already exists in diagnostics),
    • => discuss the need for standards on the developer "API" level anyway.
    • VSS can be used on CAN/network level but also on the higher levels.
    • => Discuss the need to minimize (but maybe not eliminate) data translation across network -> local apps -> cloud → data/statistics users
  • Someone might ask: Does the work cover remote Unlock car, start engine, and similar functions?
    • =>There is definite resistance to this. Discuss reasons why? Is it security concerns?
    • => Do open specifications have a (negative) relationship to cyber-security ? Prepare answer on this.

  • Keith: IMHO we need to explain we do not look at the downloading of data from the cloud to the vehicle, just upload of vehicle data, it might help breaking some resistance to the standardization of an upload link

  • Concerns about that standards may be linked to OEMs being forced to give away data
    • -> A controlled (standard) approach will allow handling this likely better than a "wild west"
  • CCS can focus, if participants prefer, not on not only technical standards but also anticipate a framework for the commercial contract setups that control the actual live data that is exchanged at any time. In other words: Technical standards are not equal to the data exchange itself
• How to define data items is not the same as the actual data (sensor measurements, user data)
• How is access managed?
  • => Fine-grained access control for applications and users of data
  • Prepare presentation of access control approaches (technical means)
    • => Access control in a Neutral-Server environment (probably input from Kevin)
• Before 10:45am-12:15pm (towards a common data model session) there is the project introduction session. Make sure to address some of the concerns there.
  • Data on the internal vehicle level is not the same as outside the car. Both have potential for some standardization but can be done on only one of them too.
  • How the choice of technical specification can affect the end result (performance, feasibility of ...)
  • Policies for future-proofing (new versions of protocol specifications, and of the VSS itself).
  • Discussion: What parts of the VSS-based ecosystem is based on a standard database of named signal, and how large parts are proprietary extensions?
    • Example: Oil consumption unit depends on location.
    • Units - VSS has losely specified an approach for this as follows:
      • Prefer international (SI) units.
      • But in some cases non-SI unit is the defacto standard in automotive.
      • And in some cases there are no agreed standards.
  • Question: Are there some signals that should allow for more than one unit to be fair to all OEMs ? E.g. km/h and miles/h. Some that have a preference extremely strong in some markets? Notable, drivers are in different countries so on the user HMI level, car manufacturers already do a lot of conversion to local preferences. So the problem would remain only on standardization on in-car networks
• /TODO/ Benjamin, prepare material with input from the above, and we can do a final review next week
  
  • Present Gap Analysis results is also a part of this

Abstract of Session One (for reference)
The GENIVI Cloud and Connected Services project intends to define an end-to-end reference architecture between vehicle sensors and the back-end cloud. Essential to this architecture is agreeing to a common method of representing in-vehicle data. This session will provide overviews of the Vehicle Signal Specification (VSS), used in the definition of the W3C automotive working group. It will look at gaps existing with other data models and in the in-vehicle portion of the architecture, explore data in an Android Automotive context and consider ways of consolidating vehicle data modeling approaches

Session Two: The Value of Vehicle Data to Enterprises., Moderated by Keith (LGE)

• FIRST: Keith -- create short intro. (needs input on what the speakers will include, i.e. needs their slides)
• Connection to AUTOSAR? Keith is our liaison
• Session plan:
  • Blueprint for Vehicle-Oriented, Data Strategy (Kevin Valdek, CTO, High Mobility) 30 min?
  • Unlocking the Value in Vehicular Data Using Analytics (Amir Sayegh, Geotab)  30 min?
  • Can we have a coffee break here? Yes (possibly local to this track) Coffee break - plan for 30 minutes
  • Industry Standards for Advanced Vehicle Data (John Schmotzer, Emerging Analytics Connected Vehicle Manager, Ford) 30 min?
  • Q&A: 30 minutes,
  • Coffee break - plan for 30 minutes
  • Total time : 150 minutes
    = total 30 minutes remains for additional discussion time.
  • Should be adequate, if we can have the coffee break as planned _before_ the last talk.

Session Three:  Capturing Vehicle Data and Communication Framework Design (Moderated by Kevin Valdek, High Mobility)

Kevin is preparing his inputs following call with Gunnar and Philippe scheduled on Thursday last week

Monday, October 21

Participants

• Stephen L
• Steve C
• Benjamin
• Don Dulchinos
• Gerald
• Gunnar
• Philippe

...

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

Minutes

• roundtable
  • Petar: works with Visteon Connected Car team, he is a colleague of Giovanni (GPRO project), he is also based in Sofia, Bulgaria
  • Petar is the solution architect of the team responsible for the overall architecture of the Visteon platform for connected services
  • Petar has 12 year experience in connected services, for the entire stack from infrastructure to Web content end-to-end and for standard compliance
  • Petar is currently more on R&D and prototyping than production
• Slidedeck
  • Gerald went through the slide deck he presented at the AMM
  • Gerald: session went out very well, better than expected, a lot of experience people attended, Melco (Mitsubishi Electric) which is quite involved in W3C was there and showed a lot of interest

...