Page History

Monday,  February 17 - Vehicle Data

Agenda:

• Data set for EV management
• Kuksa project update / Vehicle Abstraction Layer
• AOB

Participants

• Ulf (Geotab), Sebastian (Bosch), Gerald, Guru, Gunnar, Philippe

• apologies: Glenn (bank holiday in Canada)

Minutes

Data set for EV management

• Ulf joins today's call following a request made by Glenn, Ulf is in CET timezone, Ulf checked the VSS tree for data related to EVs
• Ulf works rather with the structure of the tree and not on the content
  • the tree contains many branches, I did a grep on EV data and found only one file called battery management containing data like temperature, charge status, there is also an charging inlet which is an enum that contains values like AC, DC
  • in the drivetrain branch , there is an electric motor branch but with no data in it
• Philippe: who is in the position to complement the VSS tree ?
• Gunnar: complementing the tree is not a W3C process question , we need to spot the identify domain expert to fill the blanks
• Ulf: I agree with Gunnar, we need domain experts from OEMs to get the EV branch populated, I asked Volvo (VCC) before (when I was working with them), and got very small success
• Gunnar: this needs to get into the tree in order to get things move on with EVs
• Gunnar: we will follow up with Sarah (see minutes of CCS call of 10 February) , we can use whatever is available through Geotab devices (connected to OBD port today), since we do not know what is available from the OEMs yet
• Gunnar: a key question with the battery data is that OEMs might not be willing to share the data (e.g. battery capacity) that would be related to battery degradation
• Gunnar: it would be good to check which diagnostic data on battery we could get
• Philippe: what about W3C ?
• Gunnar: Ted is willing to get inputs on EV, but our interest is to get this done faster
• Ulf: if OEMs are relucant to bring inputs, we might initiate this gathering by asking Geotab for the data they are used to
• Philippe: I will follow-up with Sarah

Kuksa project update / Vehicle Abstraction Layer

• Sebastian presents one slide giving the main timeline of the Kuksa projet and the follow-up project called VAL
  
  • Appstacle project is over
  • VAPP is an internal Bosch project, we are allowed to share on it, VAL stands for Vehicle Abstraction Layer
  • Eclipse KUKSA.val project contains the Kuksa VISS server that was spinned off as a separate component
• Then Sebastian shows a slide deck presenting the Vehicle Asbtraction Layer concept Bosch is now digging into
  • the slide deck contains the well known Bosch slide on vehicle EE architecture evolution (slide #3) and the next step which is the EE architecture extension to cloud connectivity (slide #4)
  • the end2end vehicle application architecture (from back end / cloud services) to domain and zone controller is shown (slide  #7)
  • a so-called Vehicle Application Plugin Platform is identified that would support the execution of Vehicle Services plugins that run on HPC (High Power Computer) nodes and not and deeply embedded microcontrollers
  • one example of a Vehicle Service is for instance the the trunk opening (for putting packages in the trunk), the actual implementation is very different among OEMS, having a trunk opening service abstract description would help (look at slides #8-9-10)
• Gunnar: is VSS on the slides ?
• Sebastian: VSS was not there because these slides were a teaser about the VAL project (before kick-off)
• Ulf: will this work suitable for future VSS work ?
• Sebastian: not only one technology is suitable for data abstraction, VSS is one (look at slide #11)
• Philippe: do we  need more abstraction beyond the trunk lock and trunk electric drive ?
• Gunnar: the trunk opening abstraction is something like a programming API
• Sebastian: the RPC is an easy question, w.r.t. abstraction, the trunk might be different for a car, a bus or a truck (this last one being very different)
• Sebastian: we can play with the Kuksa implementation of VSS, it is good for playing with the abstraction concepts
• Sebastian:  however we do not intend to push the work we did in ISO (TBC)
• Gunnar: I agree that the current state of VSS is not enough to describe a vehicle, the goal in my opinion is that at the end of the road the signals in VSS are actually this
  vehicle abstraction layer
• Gunnar: the part / model / layer about the trunk opening is a (parallel) project different from VSS in my opinion
• Sebastian: agreed, the VAPP stuff is different from VSS
• Gunnar: I have no problem with the Bosch big picture and having more programming APIs
• Philippe: do you intend to describe the vehicle hardware elements as well ?
• Sebastian: we have signals and RPCs but we do not intend to describe the vehicle hw
• Gunnar: AFAIK Philippe refers to the vehicle configuration, e.g. in infotainment how many speakers do we have ?
• Gunnar: this configuration might be something to add to the VAPP description, what do you think ?
• Sebastian: my opinion is that the hw description is given by some sort of tooling whose role is to describe the "ugly part of the system", the VSS fits well for describing the abstraction
  we need
• Ulf: I agree that the stuff below should be abstracted, IMHO the tree structure used by VSS is also suitable for describing the "ugly stuff below", a few OEMs are using
  the VSS tree to link things together, there is the layer mechanism we are using in W3C to organize/abstract the data that helps this work, but it is OEM specific work that can be
  added to the framework
• Gunnar: this is the proprietary data base that could be added using the same framework
• Gunnar: it is very unlikely that OEMs will redefine their CAN signals because of VSS, we will need a translation for those signals, however when we move to Ethernet, we could use VSS to describe the data (PDUs) on the Ethernet networks
• Sebastian: so called feeders will push the available data to the live tree representing the car wherever they come from (OBD, CAN, Ethernet, etc.)
• Gunnar: IMHO the live tree you mentioned is the data storage used by the vehicle data server
• Gunnar: today's discussion is helpful, we are synchronizing our vision of the vehicle abstraction

Review of TODOs

• TODO Glenn review the current EV branch of the VSS database and check whether the data described there are relevant and sufficient for enabling EV charging management / DERMS DONE
  • Ulf provided his feedback today (on behalf of Glenn)
• TODO Philippe to get back to Sarah to get possible inputs from Geotab on the data used for EV management

Wednesday,  February 12 - Communication Framework

Agenda:

• Communication framework big picture
• Next steps
• Review of TODOs
• AOB

...