Designing an open communication framework for the connected car
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Valdek, Kevin
Bjorkengren, Ulf
The connected car has been around some time but we are still waiting for a large breakthrough when it comes to third party services powered by vehicle data. The fragmentation of different technical solutions makes it difficult for 3rd parties or developers to work with easily accessible vehicle APIs. To tackle this, the GENIVI Cloud & Connected Services project is designing an end-to-end communication framework starting from the data transfer from embedded systems in the vehicles and spanning to cloud based APIs. The framework is built on open protocols and is demonstrated with open-source reference code with the aim of simplifying implementation work for both car manufacturers and 3rd party developers. This presentation will detail the work results to date and will be co-presented by Kevin Valdek from HIGH MOBILITY and Ulf Bjorkengren from Geotab. We’ll have a look at the key technical challenges and considerations that are necessary to make in order to create a successful framework. Designing a useful API for developers starts in the vehicle where topics like the data model is already considered. Further on, we’ll show a Proof-of-Concept implementation that anyone can try out. The Proof-of-Concept implements a data server in the vehicle that exposes an API to data clients, such as backend servers. The data transfer interface follows the W3C Vehicle API protocol and the Proof-of-Concept brings in additional considerations in the cloud to make APIs available to 3rd party developers. The GENIVI Alliance is a non-profit automotive industry alliance that develops standard approaches for integrating operating systems and middleware present in the centralized and connected vehicle cockpit. The Cloud & Connected Services project is performed by a work group that is open for anyone to join and to contribute to.
 you Hi and welcome to this next session. My name is Kevin Valdek and together with Udv Björk Engren we will speak about designing an open communication framework for the connected car. This is a project within the Geneva Alliance, it's a non-profit organization. It's an open project meaning that all the work or things that we will show today is it's all open source, it's available and the project itself is also open and meeting minutes are online so if you see anything that's interesting today there's definitely good opportunities to contribute. As we're talking about communication framework maybe one of the first thing is to kind of clarify yes it's the kind of data that is communicated so we will look at the kind of needs or requirements that we had in mind when starting to design this framework. Then we'll go into depths of all the different kind of components or not too much in depth as the short talk but we'll talk about the different components that we have in this framework and a second part of the presentation will be a demonstration especially focusing on the vehicle server which is running in the vehicle and the client that is retrieving the data so it's more focused on the part where the vehicle is sending data. So the general needs that we had to kind of consider were that there are a lot of different types of data that can be generated and of course different use cases in using that data but some important things is that we can kind of categorize it to personalized services and big data services. If you look at what the needs were of course we have to be able to retrieve data from the vehicle that's the basics. We have to have some kind of subscription mechanism so when new data is becoming available we can get an event and fetch that data. We also have to consider that the vehicle could be offline for a longer periods of time still it has to collect data it has to be possible to retrieve that data. We could also consider streaming APIs and also customize jobs when we assign different jobs to the vehicle saying that okay now in this next journey the focus should be on this type of data because obviously the vehicle generating tons and tons of data and we need to be able to specify what data should be transmitted really. And when it comes to big data services we can also consider things like creating some kind of analytics or histograms and other type of advanced services like media streaming it's also a source of data in the vehicle could also be used in some use cases. To name a lot of this the first thing we need to we considered was okay we can select different components we can build different services but in essence we also need to have some kind of common language and for this case it's a common data model. So that was the first thing we set out to use and we decided on using vehicle signal specification. So the vehicle signal specification is it's an open protocol has been developed by Genevieve for several years and the main things it was kind of considering it when when starting to build this was that yes it has to be easy to read and write for a human but it also has to be computer processable so we can build different types of abstraction layers it cannot be used directly in different systems and so the young format was selected as the format to go to specify it. Here's an example of how it looks like so in the gray box we have vehicle.body.windshield.front.warsherfluid.level so quite a long path but this is how it's kind of built up as a tree structure with different paths where it starts from the vehicle as the main object and it goes downwards to all different types of sensors, actuators, attributes so it supports both or it supports fixed values signals which are dynamic values that can change any time also actuators so different kind of computers that can perform simple functions and here are some examples how it looks like and in the young format we have the data type defined unit the type and description and of course this is easily extendable to other type of data as well. Now the communication framework itself here's a kind of splash view of all of it starting from the bottom right we have the software that is running inside of the vehicle we have the OEM cloud so the vehicle manufacturer cloud in the top right and on the left hand side we have third parties so of course in the communication framework is a basis to support different services using that data and typically that can be third party services and in the bottom right we have the core of it where we actually produce the data in the vehicle and we capture that data. In this we also have this gray box we chose that the data model vss as mentioned is used we also have a github link so you can also download the presentation right now or afterwards you can also follow the links you can get the repositories and here right now in this red box this is where we are focusing this talk a bit is definitely the demonstration where we have the data server in the vehicle that provides the data to the vehicle client but before demonstration we can look at the components so starting from the in-vehicle components. First thing we have here is the state storage it's a simple mechanism of getting input from all the different sensors and networks in the vehicle and then outputting that data to the data server that has the interface to the cloud in our proof of concept implementation so we have done a proof of concept implementation which we finished by the end of last year so just a few months ago there we have built this PUC with a relational database using SQLite the manager implementation is done in go meaning that it's set up the database takes care of the configuration and then in the end the data server which needs to get access to data from the state storage is using SQL directly. In the github repository we have all the documentation of how that is set up and also how it is being interface so that's the kind of simple way of handling the latest cached or known data values of the vehicle. Next we have the data feeder in the proof of concept implementation we first we looked at different simulators, vehicle simulators, how that can be used in the end we decided for a bit more simpler approach that we have another database running in the vehicle which actually possesses data that has been captured in different ways earlier or let's say wheel trip data and when we play that simulator it just feeds the previously captured data into the state storage so it's a simple way for us to kind of use data we collect on the streets just put it in the vehicle we run it and then constantly as the timestamps update it sends new data updates directly to the state storage that can later then be transferred to the to the cloud. The in-vehicle data server this will be one of the key focus points in the demonstration it's using the W3C VISS v2 protocol so and we have done the implementation here that we have the protocol implemented exactly as it should be in the vehicle it is a data server so it's data server because of course the vehicle is one that possesses the the true source of data it constantly being updated new type of data and then it exposes that to the the cloud so it can be fetched. So when it gets a request the data server simply looks in the state storage if that data is available in the PUC or proof of concept we return dummy data if nothing is found and also this this data server is implemented in go and fully available on github so you can check it out also and and how that works. So on the cloud side we have first off the vehicle client so the vehicle client of course is the one connecting to the data server so of course it's also using the VISS v2 protocol and then pulse data in our proof of concept implementation and on a pre-autical basis the protocol itself supports subscriptions so the vehicle or the vehicle client can really subscribe to different events based on what the interest is in a given moment that what type of data to monitor what type of data to look after and as soon as data is being retrieved that data is then being stored in the in the database on the cloud side. In the proof of concept we have implemented the database also the relational database also SQLite similar to the in-vehicle state storage it's using go language as the language to kind of build a manager to set it up and configure it and but it can be accessed in two different ways either through SQL directly or through REST interface so there's different ways of interacting with them with the database to store this data from the vehicle client side. Then lastly the last component that we'll go into is the API for third parties so pretty simple it's of course any type of API could be exposed to third parties in this case we use the GraphQL API in the proof of concept so we have a GraphQL server that exposes a GraphQL schema using the vehicle signal specification so the same data model we have in the vehicle it's in the end exposed to the third parties and then it interfaces the the database in the cloud to get the latest data that is then being exposed so that's kind of the that's the general framework and how we have defined the different components so we are not locked into anything specific so if you look at these different implementation that we have done in Go we have selected SQLite and so on it's more about yeah just a selection for the proof of concept of course any relational database could be used any language could be used to write the write the adapters the goal language doesn't have to be used but the simple way of demonstrating this and it's all also openly available on github could be used as a reference implementation for anyone using it but it can also be used for by anyone or by you if you want to check it out or even in a hobby project or put it on some kind of raspberry and run it in the vehicle easy to set it up and get this type of concept running with a data server and a vehicle client on the on the cloud side. So with that we'll go to a demonstration I will hand over to Ulf who will show how the vehicle server and client works in practice. So the automotive group in the WCC is currently working on a second generation of the VISS specification which is a specification of an in-vehicle server working to serve in vehicle or off vehicle clients. The specification consists of two documents the core documents documents shown here which contains the higher level messaging layer description and access control model and so forth and there is also a transport document that describes the supported transport protocols, HTTP and web sockets and their respective payloads. These documents are still not made public however the plan is to do so to get the first working draft made public later on this spring. You can in the meantime if you like access the same information in html files at the automotive WCC automotive github if you like. There is also a github where an implementation of the server is being developed. Let's see we can have a quick look at the architecture of this server. You see here it consists of a server core part to which managers for the different transport protocols can register web socket and HTTP currently it can very easily be scaled into supporting more protocols that can register to the server core but currently we follow the specification with these two. On the south side of the server core there are the service managers that also register into the server core and then do the actual processing of the request to access data in the vehicle subsystem below. The server core is responsible for checking that the requests are valid and are found in the VSS tree which is the data model being used here and then the routing of the messages between the different service managers and transport managers in order to get the response back to the clients at the top. The actual directory structure of on this github follows a mirror this architecture so there is a server directory where you can find the different components the HTTP manager and web socket manager and the server core of course and so forth. And there is also a client directory where you can find simple test clients written in Java script that can be used to test the server. We have a HTTP client and we have a web socket client. We have also a web socket client where we test to compress the payloads that's outside of this actual specification but that's tested here. There is also a file containing templates for payloads request payloads that can be used by the by the clients. So let's try and see if we can run this in the root of the repo you can find a shell script that you can start the server with. So let's see first tries to stop it and there was nothing so now it's starting and it says that all the six different processes of which four constitutes the actual server and two are part of the access control system the access grant token server and access token server if one wants to play with the access control system also specified. So we have now started and then let's see we can go sorry let's see here so we can go to the directory where we have the test clients and we can start the web socket uncompressed client. It's very simple but you first have to insert the correct IP address and it's connected and now we can let's see go to the um file with the templates and we can copy one of the commands and insert here and we'll send it to the server and we'll see that it couldn't find this path so if you send something incorrect the server will tell you let's see if we can find some other so we'll try with this one instead so we'll copy that and go back here and insert that and send it to the server and we can see here that we got the correct response back we sent a get and we had a request ID which is not shown here but the same and then we have the the data coming back so from the vehicle acceleration longitudinal path we have a data point of the value of 1002 in the timestamp of I guess today no it's an old one well that the timestamp says when the value was captured so this is a value capture a couple of days ago. We can try some other requests according to the specification to for example to request multiple signal values in one request as specified so we copy that and we'll see what happens we insert that we couldn't find that either which was due to a bug you can see here that it's it's checked for historic data which is a feature also supported in the specification and we didn't ask for that but it couldn't find any because and that's correct because there isn't any so here's a bug that we have to fix the historic data is very recently added to the server so let's see if we can try something else like this request which is a subscription request that is time-based so that it will return a value signal a value every third second so let's see if we have more success with that one and it persists that it worked and then it starts now to return values every third second from the and it's you see the the data part here the path that we asked for and then the data points of value and the timestamp the value is just the dummy value that is counted up on the timestamp this is for the current time I believe now yes this so it works and I let's see if we can also unsubscribe to it so that it should stop again we'll try that unsubscribe response there and it seems like there are no more notifications sent to us it stopped so this shows that the server can indeed respond correctly but not correctly with everything right now but it will very soon when the bug is fixed to the different requests we have tested now web sockets and you can also start up the HTTP part actually you don't have to start anything up it's already sitting there ready to to respond to any any requests so but you have to start up the test HTTP test client and then apply IP address and then one could use the different templates here of course the paths can be changed and everything can be changed and tested these are just templates to to help test a tester there are also some templates for for payloads if one wants to play with the access control system so to for requests to the access grant token server something looking like this should be used and then for for the in the second step to the access token server the token received from this request should be one part of the payload and then some other parts here as as as shown so that that can also be tested and and and it works according to and follows the specification so finally I was I just want to say that what we've what I show now is is the example of the data server the viz version 2 server and a client not not the client here in the ccs architecture but the test client so we have tested this part here for the other components that you can find here like the state storage and and the actual database the open vehicle data set and the server that can be used to insert values or retrieve values from it and this vehicle client that reads data into the ovds server can be found on this github where we have under the ovds directory a server that as I said is responsible for reading and writing into the actual database and this is the client that is used in the in the architecture image that we just looked at here is also the state storage the the database the in vehicle database that is working as a buffer between the the vis server and the underlying vehicle system there are some other parts like live simulator that can be used to to simulate vehicle data given that it has a database of the ovds format that it can read so then it can then replay that and write it into the state storage and so forth all of this is used in the was used in the demo of the ccs architecture that was demoed at the old members meeting genievi all members meeting a couple of months ago if I recall correctly so I think this concludes my presentation so I live back to Kevin thank you Ulf great so we also have a video online about the full end turn demonstration so considering all the different components in the framework the link is in the presentation so feel free to follow that just a few last notes and so this work or the project is definitely work in progress so constant it's not a wrapped up finished framework just yet continues to evolve if you want to join we have different telcos twice per week I want to talk about vehicle data more on mondays and then the communication framework also one Asia friendly time on mondays and then on Wednesdays we have another time slot there's a mailing list there's a wiki on the bottom of this page you can see the links to the wiki you can find all different resources for this project that's it so thanks from both of us I hope this was interesting we're both available for to chat if you have any questions just let us know thank you you yeah not that doesn't so questions that we missed at least yeah all right I'll ask a few questions now so we didn't really get any questions in the uh and the chat window here so I just want to know uh we we what about the um what about the uh flash how do you how are you is there a lot of impact on the flash memory with are you storing a lot of data on the vehicle you you know up until now we have not used real vehicles we are so we we run the server only on a on a laptop or some some some computer so so uh in in the genievi ccs project where a lot of of this development is is is used the first phase of that project is is just sim simulated vehicle simulated vehicle data and then there is a second phase where we plan actually to to try to use real vehicles and vehicle data so so but we are not there yet so so therefore I have at least no information or or experience from from flash usage or or load and things like that right now okay yeah especially with the recent uh and recently announced tesla recall where their emce mc controller is uh failing yes right yeah I don't really have any any answer to that since we have not come to to that point so we have gained an experience from from such issues right right and then I'm not sure if we already got on the uh well it looks like you
 you  Hi and welcome to this next session. My name is Kevin Valdek and together with  Udv Björk Engren we will speak about designing an open communication framework for the connected car.  This is a project within the Geneva Alliance, it's a non-profit organization. It's an open  project meaning that all the work or things that we will show today is it's all open source, it's  available and the project itself is also open and meeting minutes are online so if you see anything  that's interesting today there's definitely good opportunities to contribute. As we're talking  about communication framework maybe one of the first thing is to kind of clarify yes it's the  kind of data that is communicated so we will look at the kind of needs or requirements that  we had in mind when starting to design this framework. Then we'll go into depths of all the  different kind of components or not too much in depth as the short talk but we'll talk about  the different components that we have in this framework and a second part of the presentation  will be a demonstration especially focusing on the vehicle server which is running in the vehicle  and the client that is retrieving the data so it's more focused on the part where the vehicle is  sending data. So the general needs that we had to kind of consider were that there are a lot of  different types of data that can be generated and of course different use cases in using that data  but some important things is that we can kind of categorize it to personalized services and big  data services. If you look at what the needs were of course we have to be able to retrieve data from  the vehicle that's the basics. We have to have some kind of subscription mechanism so when new  data is becoming available we can get an event and fetch that data. We also have to consider that  the vehicle could be offline for a longer periods of time still it has to collect data it has to  be possible to retrieve that data. We could also consider streaming APIs and also customize jobs  when we assign different jobs to the vehicle saying that okay now in this next journey the  focus should be on this type of data because obviously the vehicle generating tons and tons of  data and we need to be able to specify what data should be transmitted really. And when it comes  to big data services we can also consider things like creating some kind of analytics  or histograms and other type of advanced services like media streaming it's also a  source of data in the vehicle could also be used in some use cases. To name a lot of this the first  thing we need to we considered was okay we can select different components we can build different  services but in essence we also need to have some kind of common language and for this case it's a  common data model. So that was the first thing we set out to use and we decided on using vehicle  signal specification. So the vehicle signal specification is it's an open protocol has  been developed by Genevieve for several years and the main things it was kind of considering  it when when starting to build this was that yes it has to be easy to read and write for a human  but it also has to be computer processable so we can build different types of abstraction layers  it cannot be used directly in different systems and so the young format was selected as the  format to go to specify it. Here's an example of how it looks like so in the gray box we have  vehicle.body.windshield.front.warsherfluid.level so quite a long path but this is how it's kind of  built up as a tree structure with different paths where it starts from the vehicle as the main  object and it goes downwards to all different types of sensors, actuators, attributes so it  supports both or it supports fixed values signals which are dynamic values that can change any time  also actuators so different kind of computers that can perform simple functions and here are some  examples how it looks like and in the young format we have the data type defined unit the type and  description and of course this is easily extendable to other type of data as well.  Now the communication framework itself here's a kind of splash view of all of it starting from  the bottom right we have the software that is running inside of the vehicle we have the OEM  cloud so the vehicle manufacturer cloud in the top right and on the left hand side we have  third parties so of course in the communication framework is a basis to support different services  using that data and typically that can be third party services and in the bottom right we have  the core of it where we actually produce the data in the vehicle and we capture that data.  In this we also have this gray box we chose that the data model vss as mentioned is used we also  have a github link so you can also download the presentation right now or afterwards you can  also follow the links you can get the repositories and here right now in this red box this is where  we are focusing this talk a bit is definitely the demonstration where we have the data server in  the vehicle that provides the data to the vehicle client but before demonstration we can look at  the components so starting from the in-vehicle components. First thing we have here is the  state storage it's a simple mechanism of getting input from all the different sensors and networks  in the vehicle and then outputting that data to the data server that has the interface to the cloud  in our proof of concept implementation so we have done a proof of concept implementation  which we finished by the end of last year so just a few months ago there we have built this  PUC with a relational database using SQLite the manager implementation is done in go  meaning that it's set up the database takes care of the configuration and then in the end the  data server which needs to get access to data from the state storage is using SQL directly.  In the github repository we have all the documentation of how that is set up and also how  it is being interface so that's the kind of simple way of handling the latest cached or  known data values of the vehicle. Next we have the data feeder in the proof of concept implementation  we first we looked at different simulators, vehicle simulators, how that can be used in the end we  decided for a bit more simpler approach that we have another database running in the vehicle  which actually possesses data that has been captured in different ways earlier or let's say  wheel trip data and when we play that simulator it just feeds the previously captured data into  the state storage so it's a simple way for us to kind of use data we collect on the streets  just put it in the vehicle we run it and then constantly as the timestamps update it sends  new data updates directly to the state storage that can later then be transferred to the to the cloud.  The in-vehicle data server this will be one of the key focus points in the demonstration  it's using the W3C VISS v2 protocol so and we have done the implementation here that we have  the protocol implemented exactly as it should be in the vehicle it is a data server so it's data  server because of course the vehicle is one that possesses the the true source of data  it constantly being updated new type of data and then it exposes that to the the cloud so it can be  fetched. So when it gets a request the data server simply looks in the state storage if that  data is available in the PUC or proof of concept we return dummy data if nothing is found and also  this this data server is implemented in go and fully available on github so you can check it out  also and and how that works. So on the cloud side we have first off the vehicle client so the vehicle  client of course is the one connecting to the data server so of course it's also using the  VISS v2 protocol and then pulse data in our proof of concept implementation and on a  pre-autical basis the protocol itself supports subscriptions so the vehicle or the vehicle  client can really subscribe to different events based on what the interest is in a given moment  that what type of data to monitor what type of data to look after and as soon as data is being  retrieved that data is then being stored in the in the database on the cloud side.  In the proof of concept we have implemented the database also the relational database also SQLite  similar to the in-vehicle state storage it's using go language as the language to kind of  build a manager to set it up and configure it and but it can be accessed in two different ways  either through SQL directly or through REST interface so there's different ways of interacting  with them with the database to store this data from the vehicle client side.  Then lastly the last component that we'll go into is the API for third parties so pretty simple  it's of course any type of API could be exposed to third parties in this case we use the GraphQL  API in the proof of concept so we have a GraphQL server that exposes a GraphQL schema using the  vehicle signal specification so the same data model we have in the vehicle it's in the end  exposed to the third parties and then it interfaces the the database in the cloud to get the latest  data that is then being exposed so that's kind of the that's the general framework and how we  have defined the different components so we are not locked into anything specific so if you look  at these different implementation that we have done in Go we have selected SQLite and so on it's  more about yeah just a selection for the proof of concept of course any relational database could be  used any language could be used to write the write the adapters the goal language doesn't have to be  used but the simple way of demonstrating this and it's all also openly available on github could  be used as a reference implementation for anyone using it but it can also be used for  by anyone or by you if you want to check it out or even in a hobby project or put it on some kind  of raspberry and run it in the vehicle easy to set it up and get this type of concept running with  a data server and a vehicle client on the on the cloud side. So with that we'll go to a demonstration  I will hand over to Ulf who will show how the vehicle server and client works in practice.  So the automotive group in the WCC is currently working on a second generation of the VISS  specification which is a specification of an in-vehicle server working to serve  in vehicle or off vehicle clients. The specification consists of two documents the core documents  documents shown here which contains the higher level messaging layer description and  access control model and so forth and there is also a transport document that describes the  supported transport protocols, HTTP and web sockets and their respective payloads.  These documents are still not made public however the plan is to do so to get the first  working draft made public later on this spring. You can in the meantime if you like access the same  information in html files at the automotive WCC automotive github if you like. There is also  a github where an implementation of the server is being developed.  Let's see we can have a quick look at the architecture of this server. You see here it  consists of a server core part to which managers for the different transport protocols can register  web socket and HTTP currently it can very easily be scaled into supporting more protocols that can  register to the server core but currently we follow the specification with these two.  On the south side of the server core there are the service managers that also register into  the server core and then do the actual processing of the request to access data in the vehicle  subsystem below. The server core is responsible for checking that the requests are valid and are  found in the VSS tree which is the data model being used here and then the routing of the messages  between the different service managers and transport managers in order to get the response  back to the clients at the top. The actual directory structure of on this github follows  a mirror this architecture so there is a server directory where you can find the different  components the HTTP manager and web socket manager and the server core of course and so forth.  And there is also a client directory where you can find simple test clients  written in Java script that can be used to test the server. We have a HTTP client and we have  a web socket client. We have also a web socket client where we test to compress the payloads  that's outside of this actual specification but that's tested here. There is also a file containing  templates for payloads request payloads that can be used by the by the clients.  So let's try and see if we can run this in the root of the repo you can find a shell script  that you can start the server with. So let's see first tries to stop it and there was nothing so  now it's starting and it says that all the six different processes of which four constitutes  the actual server and two are part of the access control system the access grant token server and  access token server if one wants to play with the access control system also specified.  So we have now started and then let's see we can go sorry let's see here  so we can go to the directory where we have the test clients and we can start the  web socket uncompressed client. It's very simple but you first have to  insert the correct IP address and it's connected and now we can let's see go to the  um file with the templates and we can copy one of the commands and insert here  and we'll send it to the server and we'll see that it couldn't find this path so if you send  something incorrect the server will tell you let's see if we can find some other  so we'll try with this one instead so we'll copy that and go back here  and insert that and send it to the server and we can see here that we got the correct response  back we sent a get and we had a request ID which is not shown here but the same and then we have  the the data coming back so from the vehicle acceleration longitudinal path we have a data  point of the value of 1002 in the timestamp of I guess today no it's an old one well that the  timestamp says when the value was captured so this is a value capture a couple of days ago.  We can try some other requests according to the specification to for example to request multiple  signal values in one request as specified so we copy that and we'll see what happens we insert that  we couldn't find that either which was due to a bug you can see here that it's  it's checked for historic data which is a feature also supported in the specification and we didn't  ask for that but it couldn't find any because and that's correct because there isn't any so here's  a bug that we have to fix the historic data is very recently added to the server so let's see if  we can try something else like this request which is a subscription request that is time-based so  that it will return a value signal a value every third second so let's see if we have more success  with that one and it persists that it worked and then it starts now to return values every third  second from the and it's you see the the data part here the path that we asked for and then  the data points of value and the timestamp the value is just the dummy value that is counted up  on the timestamp this is for the current time I believe now yes this so it works and I  let's see if we can also unsubscribe to it so that it should stop again  we'll try that unsubscribe response there and it seems like there are no more  notifications sent to us it stopped so this shows that the server can indeed  respond correctly but not correctly with everything right now but it will very soon when the bug is  fixed to the different requests we have tested now web sockets and you can also start up the  HTTP part actually you don't have to start anything up it's already sitting there ready to  to respond to any any requests so but you have to start up the test HTTP test client and then apply  IP address and then one could use the different templates here of course the paths can be changed  and everything can be changed and tested these are just templates to to help test a tester  there are also some templates for for payloads if one wants to play with the access control system  so to for requests to the access grant token server something looking like this should be used and  then for for the in the second step to the access token server the token received from this request  should be one part of the payload and then some other parts here as as as shown so that  that can also be tested and and and it works according to and follows the specification  so finally I was I just want to say that what we've what I show now is is the  example of the data server the viz version 2 server and a client not not the client here in  the ccs architecture but the test client so we have tested this part here  for the other components that you can find here like the state storage and and the actual  database the open vehicle data set and the server that can be used to insert values or  retrieve values from it and this vehicle client that reads data into the ovds server can be found on  this github where we have under the ovds directory a server that as I said is responsible for  reading and writing into the actual database and this is the client that is used in the  in the architecture image that we just looked at  here is also the state storage the the database the in vehicle database that is working as a  buffer between the the vis server and the underlying vehicle system there are some other parts like  live simulator that can be used to to simulate vehicle data given that it has a database of the  ovds format that it can read so then it can then replay that and write it into the state storage  and so forth all of this is used in the was used in the demo of the ccs architecture that was  demoed at the old members meeting genievi all members meeting a couple of months ago if I recall  correctly so I think this concludes my presentation so I live back to Kevin thank you Ulf great so  we also have a video online about the full end turn demonstration so considering all the different  components in the framework the link is in the presentation so feel free to follow that  just a few last notes and so this work or the project is definitely work in progress so constant  it's not a wrapped up finished framework just yet continues to evolve if you want to join we have  different telcos twice per week I want to talk about vehicle data more on mondays and then the  communication framework also one Asia friendly time on mondays and then on Wednesdays we have  another time slot there's a mailing list there's a wiki on the bottom of this page you can see the  links to the wiki you can find all different resources for this project that's it so thanks  from both of us I hope this was interesting we're both available for to chat if you have any questions  just let us know thank you  you  yeah not that doesn't so questions that we missed at least yeah  all right I'll ask a few questions now so we didn't really get any questions in the  uh and the chat window here so I just want to know uh we we what about the um what about the uh  flash how do you how are you is there a lot of impact on the flash memory with are you storing  a lot of data on the vehicle you you know up until now we have not used real vehicles we are so we  we run the server only on a on a laptop or some some some computer so so uh in in the  genievi ccs project where a lot of of this development is is is used the first phase  of that project is is just sim simulated vehicle simulated vehicle data and then there is a second  phase where we plan actually to to try to use real vehicles and vehicle data so so but we are not  there yet so so therefore I have at least no information or or experience from from flash  usage or or load and things like that right now okay yeah especially with the recent uh and recently  announced tesla recall where their emce mc controller is uh failing yes right yeah I don't  really have any any answer to that since we have not come to to that point so we have  gained an experience from from such issues right right and then I'm not sure if we already got on the  uh well it looks like  you
open_communication_fw_0_7619.png open_communication_fw_7620_20339.png open_communication_fw_20340_20615.png open_communication_fw_20616_22691.png open_communication_fw_22692_22775.png open_communication_fw_22776_23723.png open_communication_fw_23724_37403.png open_communication_fw_37404_40427.png open_communication_fw_40428_41375.png open_communication_fw_41376_42095.png open_communication_fw_42096_42155.png open_communication_fw_42156_42263.png open_communication_fw_42264_42431.png open_communication_fw_42432_42671.png open_communication_fw_42672_42719.png open_communication_fw_42720_42767.png open_communication_fw_42768_43031.png open_communication_fw_43032_43199.png open_communication_fw_43200_43295.png open_communication_fw_43296_43667.png open_communication_fw_43668_43967.png open_communication_fw_43968_45119.png open_communication_fw_45120_45233.png