Meeting minutes
Curve logging code tour in VISS2
Ulf: last week or so, I've been playing with converting curve logging from open source version from Geotab's github repo
[Ulf shares screen, architectural overview]
Ulf: there is a unified protocol on what I call the transport layer handled by the manager
… we only have one manager implemented but possible to have multiple
… I added curve logging to service manager. I split off into a separate file since the algorithm is a bit involved to have it easier to read
… function activateIfIntervalOrCL
… differentiates which is used
… it first looks at the signals received and divides into 1, 2 or 3 dimensional signals
… a simple signal like speed that varies over time is 1 dimensional. Latitude could also be represented as 1 dimension but logically belongs with Longitude hence 2 and perhaps want a 3rd which is accelerometer
… we use max error for criteria to register new data point collection
… what signals you want to be tracked in combination (dimensions) can be configured in json
https://
https://
Ulf: I may optimize code a bit further as there is a bit of redundancy
… regardless of how many signal dimensions you use, typically 1, you also have time as another dimension. minimum is a 2 dimensional graph on x, y axis
… on first request, freshest value is sent
… in my implementation I introduced a sleep of 800ms to not overload the sqlite server used for this prototype
Ulf: I build up a ring buffer at the start. the analysis is quite quick
https://
some have equated it to lossy compression, reduces number of data points needed to provide a reasonably accurate depiction
Ulf: when buffer becomes full or an unsubscription, we break out of infinite loop
… that brings us to the core logic, rest is just information flow
… core logic figures out what points are needed to save and tosses out others
… here we use a linear buffer, translate strings to appropriate variable types and use Unix timestamps
… the actual reduction is performed on this buffer and max error. the method is recursive and calls itself
… if you look at the Geotab python in github you'll see that represented here
… line is 'drawn' and compared to max error for the various data points to see if any sample exceeds max error
… what this method returns is an array of the indexes that should be saved
… rest is basically correcting sorting since the recursion interferes with that. the data points corresponding to the indexes array are then collected from the ring buffer
Ted encourages people to comment on met topic of optional versus required filters https://
Transparent auth capabilities
Ted summarizes discussion from last week and captured in comment on https://
Ulf: we would like to be able to accomodate what Bosch is asking for, a less complex authentication scenario
… my idea is we do away with the access grant server in the cloud, claim and receive a role
… then an access token is received in the vehicle. my understanding is Bosch only has one server in the vehicle
… this can be handled by access grant server issuing a token with no expiration date. this can be provisioned in any number of ways without even a server
… this simpler scenario removes access grant server entirely and essentially matches Bosch's model
… this is a claim and although Isaac, Ted and I believe it is feasible, need to prove
… the other major difference is role based authorization and there think we have a superuser role with granular exceptions
[Gunnar leaves]
Erik: Sebastian has better knowledge of what we have implemented
… access grant and token servers in the spec are themselves not normative, right?
Ulf: correct, it is currently not mandatory
… currently it is all or nothing
Erik: would access token be required to be short lived?
Ulf: you have a token and it must correlate to some extent?
Erik: intention then is access token should still be there
Ulf: yes and assume you generate tokens somewhere/somehow in your system
… access token could be integrated in VISS implementation or kept separate. I kept them as separate servers in my implementation
Erik: I will check with Sebastian and others, get their opinion
Ulf: we are willing to make tweaks but idea that I hope we can achieve is we keep as much of the architecture and handle both scenarios
Ted: first and foremost we want the client/VISS interactions to be consistent, architectures may vary some and either or both solutions may need some tweaks to meet in the middle to attain that
… we should do that first before getting into roles
Erik: I'll discuss on our end