Ted: different interests in
observations...OEM/aftermarket sensors
...proprietary extensions to VSS
Peter: I have been working on related
questions, for instance.
...what about observations that don't come from a sensor in the car?
Ted: could also come from a paired device
https://docs.google.com/presentation/d/1Vi7sdMO8z_Ysw23dM0jVjNzOpmHRxsNt/edit#slide=id.p1
George: pubsub based on messages
... model of generic sensor (6)
... converts some physical phenomenom into and electric signal
... very general model of sensor web
... 7 is existing standards around encoding, services...
... tells you what is measured, geometric factors, material data sheet from manufacturers including calibrations
... you can pull sensorml into your software
... key thing about making an observations in the world
... topic of joint work with W3C in SDWIG
... observations based on measurement. started from scientic measurement conventions and worked into ontology
... web services perspective started in 2015, doesn't use wsdl
... you can make a request to get a specific observation, ask what it provides
... any kind of sensor with tasking involved, eg go into a certain mode, point in a given direction
... sensor alert service associated with pubsub environment, send a message when a given threshold is met
... it was developed and deployed in a number of places. EU started using this for anticipating charging requests for EV
Mark: have you settled on tvtt or roling your own?
George: 'the gum' blue book - iso standards for units and rest that drove it
... come back to units of measure...
... porting into a modern IT environment is a pain
... to Peter's question on bikes, there is a related EU project
... supports all NOAA buoys, various military and satellite activities
... Semantic Sensor Network Ontology
... relationships between sensors, observations
... link in chat goes into that
... 9 sensor web enablement, on an IoT comm stack, mqtt in this example
... uses odata - OASIS data standard
... it is going to ITU for standardization
[back to 8]
Linda: it would be good to go into abstract observations and measurements
[observations and measurements spec from OGC]
Linda: author Simon Cox
[observation uml]
Linda: feature, property of a thing, there is usually some procedure info in the information and result
... works for lots of types of observations, including rather complex types - you could be doing series of measurements on eg soil or water
... could be same observation as a time series, specific intervals
... this is observations and measurements, it is an abstract model. represented in xml schema and basis for SSN
... it is not only for modeling observations but sensors as well
... you can describe all sorts of features about the sensors
[showing SSN spec]
Linda: SDWWG created SSN spec, it is both an OGC and W3C standard
... it is modularized in a pretty good way with a simple core
... sensors and actuators, defines classes and properties but not much beyond that
... you can use either just that or the more complex capabilities of SSN
... you can see it is an implementation of observations, showing properties of a feature of interest, can receive procedure requests and return readings
... it is basic model you have in SOSA core
... you can see the more complex parts, green is simpler SOSA, blue fuller SSN
... the procedure can be described more fully, you can model stimuli
... you can model position of sensor and other additional platform details
... actuation in this case the activity, feature of interest and property in this example
... you have samplings, can model activity of taking a sample
... SDWIG is now maintaining these specs
... we also published some extensions to SSN recently
... this is adding collections, you can have a logical container
... the observations and measurements standard from OGC I started with is going through major revisions, Clemens and I are part of this group
... work is being done in github
<brinkwoman> https://github.com/opengeospatial/om-swg
Linda reviews roadmap
Linda: there should be xml and json encodings
... SDWIG also working on OWL-Time and probably of interest to this group
<brinkwoman> https://github.com/w3c/sdw
Linda: all of our work is in this one repo
... specs, extensions and best practices
... issues labeled
... having OGC and W3C participants works well, we are using W3C tools primarily their github, mailing list
... meet twice a year, typically at OGC plenary and W3C TPAC
<brinkwoman> https://www.w3.org/TR/vocab-ssn-ext/
Benjamin: how does SWE relate to Sensor spec or API
... it was also presented in W3C WoT
... are they converging?
Linda: Sensor of Things is an OGC standard and not in a joint OGC/W3C group
... it is important to get them in touch with W3C WoT
... Sensor of Things is a web API with JSON encoding for the messaging and results
... they're also basis their content model on the abstract Observations and Measurements model but not SSN as it predated SSN
George: there is still alot of commonality, I presented Sensor of Things API at a WoT workshop in Princeton...
Benjamin: I heard about it at Munich workshop
... interested in how SWE fits in here
... sounds like some core divergence
Linda: SSN and Sensor of Things is following the same conceptual model for observations
Benjamin: so some interoperability should be possible
George: Sensor of Things uses a different communications stack, simpler API and decade newer than SWE
Clemens: also in general the compatibility should be there
... some of the same people involved in both. there is work bringing it in line with SOSA
... concept in use in Sensor Things API. there are different fora and not guaranteed, everything should be largely the same
Gunnar: can you explain the difference between observation and sampling?
Linda: yes, sampling is activity where you are observing several properties, could be repeated at interval
Ted: I also wonder if it can be conveyed as an assessment instead of the actual raw data
George: there is a common filter approach based on state that would be compatible with
Gunnar: I'm trying to be clear on terms and nomenclature
George: sampling is subset or abstract of sensor data
Gunnar: observation is clear, getting latest value for entity or as Ted described collection of signals based on certain conditions
... different approaches and need them named
George: time series aspect is useful, temporal algebra in spec
Linda: Time series
George: joint one with W3C...
Linda: Time ontology
<brinkwoman> https://www.w3.org/TR/owl-time/
Gunnar: what do you mean by an abstract specification
George: we have this notion of abstract and implementation specs, latter you can hand to a developer whereas abstract is an agreed concept
Benjamin: just learned about SSN-extension and should feature into VSSo evolution
... are there other extensions being developed?
Linda: there are some more ideas, not sure how evolved they are
... they're in github
George: alignment of data streams is different than static collections
<brinkwoman> https://github.com/w3c/sdw/projects/7
Glenn: Geotab is an aftermarket telematics service provider for commercial fleets
... we have an open architecture, connect to vehicle on one hand and allow addition sensors (eg temp for a refrigerator truck)
... these specs seem applicable and could broader interoperability
... an aftermarket sensor is intergrated with our Go device, for example there is a video one from a partner and it can determine if an object is a pedestrian etc
Ted: I wonder if ITS or SmartCities is categorizing these sorts of observations including object classications (pedestrians bikes etc)
Megan: more a different level
MagnusG: Melco is pretty big but as far as I know ADAS assessments are mostly kept in-vehicle but there could be some group that is bringing it to the cloud
Peter: I can say I was involved in a project that isn't exactly observations but a bike reporting itself as a bike to make vehicle in vicinity aware
... including direction and speed
... you can do observations but trusting external devices/vehicles is a challenging worth validating with second observations
Ulf: Geotab does quite a bit in this field with 2M connected vehicles
... many existing sensors can be used to deduce observations with on-board calculations
... Amir presented in Palo Alto some use cases like micro-weather reports
... determine existence of a pothole, reported from multiple vehicles allows it to be conveyed conretely to stakeholders
Adnan: difficult for us to discuss given how diverse the company is
MagnusF: not part of that either for us so not sure what we are reporting that I can talk about and future plans
Ted: TOCC - seek to avoid chaos in competing standards'
data models at ontological layer
... it can provide feedback like specific question from RJ that
started off the mailing list and got response from NOAA
... choose small number of core ontologies to focus on such as route
and observations, how to expand
George: I expected a flood from community when I relayed your/DOT question
... accurate, robust weather measurements and what goes into that is carefully managed international standards
... as for coming from the vehicle, quality measurements is a huge safety opportunity
Daniel: when we were discussing taxonomies for Gen2 and have alternate data models instead of trying to put everything in VSS
... finding other domains and how to bring them together reached pushback. the thinking of how to use other domains in Gen2
... this kind of modeling fits our needs
... only way to avoid the duplication is to define it
George: would you share your brake slip information to a public audience?
Daniel: signals don't need to be shared, you may have authorization to use in the vehicle and can send out an observation
... it is a politic issue but want to stay technical
... we need to define a way. agree we want to avoid various private branches
Gunnar: there is a difference between specificying signals and sharing
... you may not be sharing your break data but derived information
... that translates to a slippery road
Daniel: it would be good to take a couple examples and see how to do it
MagnusF: there are only two reasons we would be inclined to share data is if we can scrub it and make money or if there is a legislative requirement to provide it
... we do need to establish a technical way to do it
... we have costs (data, software dev etc) and permission from policy perspective from owner
Carlos: I share your thoughts on what we see with Ford
MagnusF: risk, lawsuit avoidance is big in auto industry
... anyone aware of legislation coming such as right to repair
Ted: right to repair includes data rights as of last year
MagnusF: also diagnostics for repair shops
Carlos: also being driven from ExtVeh in EU
[discussion of politics]
MagnusF: we are going to need something and coordination
... do we try to establish best practices
Ted points out coordination and input from ISO ITS, Smartcities etc may well percolate back as regulations
Jay: peaked my interest around sharing of data and business opportunity as a motivator
... you made some comments around the vehicle owner's data rights
... this is a discussion we have had with Ford. they have the notion it is their data to monetize
... how does that line up with your opportunities to monetize
MagnusF: disclaimer, those were personal observations not JLR statement
... we generally require a waiver, collected in some cases through IVI from driver/owner
... revenue streams are a motivator
... and would be more from scrubbed, sanitized and anonymized data
Jay: we take a more software than automanufacturer perspective
... dealers/repair shops can do OTA updates and diagnostics assessments
... the repair market is what has those relationships with the user not the auto manufacturer
MagnusF: we are ok with authorized dealerships having more access
... independent repair shops want to run diagnostics including assessments on running vehicles which gets back to Ted's proposed best practices
... if aftermarket came to OEM and offered money for the data they want they would get attention
Jay: I agree with that
... the independents work on varied manufacturers' vehicles and want access to that data
... there are regional needs, interests based on regular/road conditions of that hyperlocalized area
... OEM will have the needed data but not the context
MagnusF: Massachussets wants to force OEMs to open up access to independents base on owner not OEM permission
... I agree we should work on good generic tooling and practices
Ted goes over next steps on best practices and observations
Raphael: we have a small presentation on VSSo which will be brought over to W3C repo shortly
... Benjamin did most of the work on the slides, he and I were involved with BMW in creating with Daniel and Adnan
Benjamin: I want to discuss how we describe data coming from the vehicle, currently they vary by brand, model etc
... we took some requirements on different domains and use cases
[slide 2]
Benjamin: you have a signal or attribute you want to standardize, follow naming conventions and we wanted to represent that with SOSA
... observation allows you to represent a literal in a specific data type
... we have quite a bit of flexibility. observations was fairly simple to use as core for VSS
... definition matched pretty well, sensor units and so on. we have nothing vehicle specific from SOSA
... we wanted subclasses you define with SOSA
... the structure of VSS with branches
... VSS mapped to SOSA, QUDT for units
... we get simple readable results. there were a few modeling issues
... names should be unique and not tree path. you want to be able to open a node and know what you are dealing with
... it is possible for different nodes to represent same data - that is the case for speed, transmissions, gps, etc
... what about information not coming from a sensor. you can digitally describe the hardware that produces given data in order to make observations
... VSS contains duplicates. there are 25 defined seat positions for example but comprised of a handful of signals
... we needed position attributes to describe location of signal within car
MagnusF: you can have virtual, computed instead of actual signals. eg location without gps, inside a garage it can be calculated by dead reckoning, steering etc
... there a way to represent that?
Benjamin: you can define your own 'signals' for that, could be calculated based on mix of sensors
... SOSA allows you to define procedure to distinguish it
Raphael: that is strength of SOSA, phenomenom be represented can be comprised of multiple sensor
Carlos: imagine check engine light comes on, simple signal to turn light on or off
... could be result of multiple conditions in vehicle, do you represent that in your model?
Benjamin: same as Magnus' question, representing it is fine, generating it will require your own rules for the procedure
Gunnar: there is a limit on what is useful to model. in plain VSS we would not distinguish a derived from measured raw signal
... there is implementations of this already with VSS using derived signals
Raphael: it is not meant to be able to handle all possible procedures for deriving knowledge but representing what you can observe
Daniel: what is more important for developer is accuracy and frequency than source, whether it is derived
Benjamin: related to private branches in VSS is also layering discussion yesterday
... as of today we have VSSo as core signals from VSS but we have options for including other domains
[graph example]
[get slide and wiki links from slack]
Benjamin: it comes back often to SOSA pattern
... branches are related to each other and have their own signals and attributes
... any signal we create, using temp as example, it is human and machine readable
... we have about 300 signals, documentation is avail
... more complex use cases and graph
... for future work, currently moving documentation to W3C space
... need to update for latest changes in VSS
... VSS layers will need to be handled
Raphael: moving over to W3C, encourage Gunnar to help coordinate with VSS, need the idea of snapshots with version numbers...
... we would like to make use of VSS layers that has been discussed
... there is some artificially generated data. we want to get some bigger datasets that we can convert to VSSo
... I know Ted has tried to make such a prototype possible for people being able to play with such data
Raphael: aggregation, outliers, all sorts of use cases some next steps
Gunnar: we should focus on major changes, setting a label is pretty easy
... I think you are talking about ongoing changes
... we are setting up a forum to have an ongoing forum about that
... we will be organizing a GENIVI VSS call before or after W3C WG call
... Daniel has been largely maintaining VSS and think he wants to focus on VSSo
Daniel: there is a set of open issues in github, some discussed yesterday
[break]
Ted asks Ulf about EV signals subtopic from VSS breakout
Ulf: MagnusF agreed to look at Geotab proposal and respond
MagnusF: correct, have internal conversation tomorrow and can respond
Ulf: I'll discuss the architecture for the implementation we've done for the Gen2 server
... Gen2 would be deployed in the vehicle, access grant server would be in the cloud, access token in the car also
... we are not concerning ourselves with vehicle and running all in the cloud
... this server implementation is deployed and available in cloud now on a W3C/MIT server
... the bubble on top is client application. we have some rudimentary client applications and a more elaborate one from Sanjeev
... server consists of three layers, one of components that are implementing the transport protocols
... right now we have a web socket manager towards the client and another for http
... all these components in the diagram are implemented as Go programs as separate processes
... all the internal communication between the different processes use W3C web sockets
... that means the http manager that communicates http to client applications needs to internally translate to web sockets
... the server core will inspect payload and route further to lowest level, service managers
... we only have one at present but there could be any number, this allows extending for additional transport protocols
... service managers sits between server core
... separate VSS paths could be handled by different service managers
... server core needs to have information about how the VSS tree is structured. there is a tree manager that represents the format of the tree
... tree manager can be extended. we have full VSS tree as it existed a couple months ago
... we have dummy values being sent back at present. earlier we had some canned CAN signals we were playing back
... the core server has further structures, registration threads
... we took advantage of Go language threading
... to handle registration of service managers
... if it is a transport or service manager, once it is registered it gets back information about the data traffic
... we support wildcards in path which returns requests from tree manager
Ken: where is security being handled?
Ulf: not complete yet, but the working draft of our specification has those access grant server based on oauth2
... we have basic structure implemented, influenced by VW's ViWi
... typically access grant server in cloud will provide permissions for a given application
... we are discussing using roles (RBAC)
... client app will get a certain scope of permissions and token it will use for communicating to Gen2 server
Ken: have you looked at IEEE 1609.2, ISO 21177?
Ulf: need to look at them
Ken: Europe has a slightly different tweak, that defines how to define secure connections to the vehicle for public infrastructure communications
... worth a look
... happy to get intros to the experts involved in them
MagnusG: this is more a trial implementation
[Magnus shares screen]
MagnusG: I wanted to go over the source code, ways to build it, run a docker or use the W3C server instance
... in addition to how to run it, how to configure it. I don't plan on going into the tools used but happy to go into that if you drop me an email
... this implementation is on Melco's github repository. if you want to contribute you can make a fork and when you have something you want to contribute back, make a pull request
... as for trying it out and testing it, we have a web client from Sanjeev and others in github repo
Ted points out there will be more permanent labs.w3.org uris later
MagnusG: you can use our docker image, build scripts or build other way
... docker is easiest, you don't need to create Go language environment
... you clone repo, change directory and then simply docker-compose up-d
... if you have GoLang installed we have some convenience scripts for starting and stopping the server
... there are build scripts for each component
... we use go modules in this project. it is a dependency management system
... you can do cleaning and updating with eg go mody tidy
... you can make your own builds and customize pieces
Ulf: I'll present the simple clients we have in javascript and then Sanjeev will show his client apps
[Ulf shares screen]
Ulf: in the repo there is javascript client directory
... we have example ones using http and ws
... you can download the html files and run
Ted: we can figure out usable github.io uris so they can run directly from web
Ulf: as you see you can point to different server, I'll use puppis.w3.org instead of local
... I'll copy an example command
[pastes into form and gets response]
Ulf: we have a watchdog to handle issues on server
... we have two branches access controlled at present, body and adas
... one is write protected and other read+write protected
... you can get missing or insufficient token reponse
Sanjeev: a month and a half ago, I made a couple client applications
... took a weekend to develop the html client app
... simple setup
... it provides a three leg structure for vss, every time user selects one of these signals
... once the subscription is accepted we should see notifications
... we can use current existing js libraries
... in this client I didn't implement tokens and some signals require them
... the most complicated part of this app was to create the tree representation
... this is a Tizen Linux emulated environment
[watch client app demo]
[running on actual watch now]
Sanjeev: I have this in the Samsung app store if you have a phone+watch
Ulf: I really like your clients and hopefully encourages others to play with this
... feel free to run your local server too if you don't trust this instance
... we'll work out the problems
... we want feedback
Sanjeev starts local instance of server
[adjourned]