Application developers in the automotive domain have to deal with thousands of di erent signals, represented in highly heterogeneous formats, and coming from various car architectures. This situation prevents the development and connectivity of modern applications. We hypothesize that a formal model of car signals, in which the de nition of signals are uncorrelated with the physical implementations producing them, would improve interoperability. In this paper, we propose VSSo, a car signal ontology that derives from the automotive standard VSS, and that follows the SSN/SOSA pattern for representing observations and actuations. This ontology is comprehensive while being extensible for OEMs, so that they can use additional private signals in an interoperable way. We developed a simulator for interacting with data modeled under the VSSo ontology pattern available at http://automotive.eurecom.fr/simulator/query
Current and future automotive applications rely on the ability to manage highly heterogeneous data. In this context, vehicle data needs to be interoperable in order to be handled by remote applications and services regardless of the brand, model, and internal network architecture of each connected vehicle. This is actually challenging today as a developer needs deep insights into the architecture of a vehicle3 in order to have access and to process data coming from a vehicle signal. In addition, information about signal metadata is needed in order to interpret the returned values. As soon as the internal architecture changes, the developer has to update the implementation and will need the same prior knowledge. This might be the case already with di erent models of the same brand. 3 http://www.ieee802.org/1/files/public/docs2013/new-tsn-diarra-osilayers-in-automotive-networks-0313-v01.pdf
We propose to use semantic technologies for addressing the challenge of de
ning a formal model of car signals [
W3C and OGC have developed standards for de ning systems with their
signals. The Semantic Sensor Network4 (SSN) ontology [
We therefore observe a gap between the need for data interoperability and the current state of the art in terms of car modeling. We see a need for an ontology focusing on car signals and sensors. We also identify another requirement: such an ontology should be compliant with automotive standard such as the Vehicle Signal Speci cation (VSS)6 or follow best modeling practices in order to be used. We require such an ontology to be comprehensive enough to cover most known signals while being extensible by OEMs. The remainder of this paper is structured as follow. First, we list our requirements in Section 2. We describe how we have converted the VSS automotive standard into an ontology in Section 3. We evaluate it in Section 4. Finally we conclude and describe future work in Section 5. 2
A good car signal ontology should enable a web developer to query and extract knowledge from a car signal database with no deep expertise in the automotive domain. In this section, we de ne a set of competency questions7, which we will later use as a mean of evaluating the produced ontology.
There is a need to de ne a number of static properties or attributes describing either a complete vehicle or its parts. For instance: { How many attributes does a car have? { What is the model and release date of this car? { What are the dimensions of this car?
5 http://www.w3.org/ns/sosa/ 6 https://github.com/GENIVI/vehicle_signal_specification 7 The full list of questions is available at https://github.com/klotzbenjamin/vssontology { What type of transmission does this car have? { How many doors or seats does this car have? { On which side is located the steering wheel in this car?
A car contains numerous sensors that produce signals. We need to be able to retrieve metadata about those sensors and signals. For instance: { Is there a signal measuring the steering wheel angle? { Which signals are both observable and actuable? { How many di erent speedometers does this car contain? { What unit type does the signal vss:VehicleYaw use? { What are the maximum values allowed for all signals from a Vehicle? { Which signals measure a temperature and in which part are they located in the car?
Car sensors will generate a lot of values that depend on time and space. One should be able to query the current values of the signals as well as past historical ones. This leads to additional competency questions: { What is the current gear? { Which windows are currently open? { What is the local temperature on the driver side now?
We hypothesize that the generic modeling patterns de ned in the
SSN/SOSA ontology [
We developed VSSo, a vehicle signal ontology based on the GENIVI and W3C standard data model VSS (Vehicle Signal Speci cation). The ontology is available at https://github.com/klotzbenjamin/vss-ontology/. 3.1
VSS The Vehicle Signal Speci cation de nes a tree containing 451 Branches, 43 Attributes and 1060 Signals that aim to represent car data. The speci cation states that: { Branches are car parts or components. They are represented as nodes in the
VSS tree. Branches can contain other branches or signals and attributes. { Attributes are the static information about a car. They are represented as leaves in the VSS tree and de ned by a path starting with \Attribute" describing its position in the VSS tree. For instance, the VIN is Attribute.Vehicle.VehicleIdentification.VIN. They also have entries such as a description, a type, a unit or restrictions on values. { Signals are the dynamic information about a car that is either produced by a sensor or consumed by an actuator. For instance, Signal.Drivetrain.Transmission.Speed is the car speed, measured in the Transmission branch. Signals, like attributes, have entries providing a description, a type, and potentially a unit and restrictions on values.
In its original form, VSS did not contain information about sensors or actuators. In order to describe the di erence between signals measuring the same phenomenon with di erent sensors, we added new entries in VSS signals. We also clari ed the concepts names and choices of units. Those corrections have been approved by GENIVI and are now part of evolution of this standard. 3.2
The general idea behind the design of the VSS ontology is to reuse the pattern of VSS. All branches are sub-branches of bigger branches. Therefore, we reuse it in a component-based pattern using subclasses of vss:Branch linked with the transitive object property vss:partOf. This means that a VSS Branch is used to generate a new class, and the parent branch is attached to it with a vss:partOf property (Listing 1.1).
Listing 1.1. vss:Drivetrain is an example of a generated class part of vss:Vehicle v s s : D r i v e t r a i n a r d f s : Class , owl : C l a s s ; r d f s : subClassOf v s s : Branch ; r d f s : subClassOf [ a owl : R e s t r i c t i o n ; owl : onProperty v s s : partOf ; owl : a llValuesFrom v s s : V e h i c l e ] ; r d f s : l a b e l " D r i v e t r a i n "@en ; r d f s : comment " D r i v e t r a i n . A l l body components "@en .
It also reuses the sets of entries de ning VSS concepts. Indeed, attributes, branches and signals are all de ned by at least a name, a type and a description. These entries allow the generation of one class per VSS concept, with a RDFS label and comment. Attributes and signals also have additional entries, such as a unit, or a set of potential values and a sensor or actuator. All these entries de ne the speci c details of an attribute or signal (Listing 1.2).
Listing 1.2. vss:AmbientAirTemperature is a signal measured by a vss:Thermometer in qudt:DegreeCelcius v s s : AmbientAirTemperature a r d f s : Class , owl : C l a s s ; r d f s : subClassOf v s s : O b s e r v a b l e S i g n a l ; r d f s : l a b e l " AmbientAirTemperature "@en ; r d f s : comment " S i g n a l . V e h i c l e . AmbientAirTemperature :
Ambient a i r t e m p e r a t u r e "@en ; r d f s : subClassOf [ a owl : R e s t r i c t i o n ; owl : onProperty s o s a : isObservedBy ; owl : a llValuesFrom v s s : Thermometer ] ; r d f s : subClassOf [ a owl : R e s t r i c t i o n ;
owl : onProperty qudt : u n i t ; owl : a l l V a l u e s F r o m qudt : TemperatureUnit ] .
We generate a datatype property for each VSS attribute which are subproperties of a generic vss:attribute datatype property. All those attributes being static, there is no need to model them using a dynamic pattern. VSS attributes are attached to VSS branches which is materialized in the domain of those properties, while their range makes use of a custom datatype (Listing 1.3).
Listing 1.3. vss:tankCapacity is an attribute of the vss:FuelSystem branch v s s : tankCapacity a owl : DatatypeProperty ; r d f s : subPropertyOf v s s : a t t r i b u t e ; r d f s : l a b e l " TankCapacity "@en ; r d f s : comment " A t t r i b u t e . D r i v e t r a i n . FuelSystem . TankCapacity :
Capacity o f t he f u e l tank i n l i t e r s "@en ; r d f s : domain v s s : FuelSystem ; r d f s : range c dt : volume .
Signals, however, are going to be observed over time and space and there is a need for a dynamic modeling pattern. We take advantage of the SSN/SOSA pattern for modeling sensors, actuators, observable and actuatable properties, observations and actuations. SOSA uses the triplets (Observation, ObservableProperty, Sensor ) to model this. Observations contextualize the data with properties such as sosa:FeatureOfInterest (e.g. a car), the sosa:(Simple)Result as well as sosa:phenomenonTime and geo:lat, geo:long for the spatiotemporal context of the Observation. An equivalent pattern exist for actuations in SOSA.
SSN/SOSA does not de ne a unique unit ontology, but it is open to use
multiple ones. In order to remain open, we only set restrictions on unit systems
in the QUDT ontology8[
Several exceptions and issues prevent the trivial generation of a healthy ontology from VSS.
Concept disambiguation. VSS relies on a full path to de ne an attribute or a signal. For instance Signal.Drivetrain.Engine.Speed, is clearly the rotation speed of the engine while Signal.Cabin.Infotainment.Navigation.CurrentLocation.Speed is the vehicle speed measured by the GPS. However they would both generate a class vss:Speed if we would take the leaf of the tree as the base concepts. Therefore, VSS concepts are renamed for clari cation. In this example, vss:EngineSpeed and vss:VehicleSpeed are actually created. Sometimes, two di erent paths in the VSS tree actually refer to the same concept. For example, the signal Signal.Drivetrain.Transmission.Speed also measures the speed of the car according to the gearbox. The class vss:VehicleSpeed is here unique. Its instances di er given the sensors that will produce the values and the branch hosting the sensor (Fig. 1).
Signals are observable, actuatable or both. We de ne two main signal classes in the VSS ontology: vss:ObservableSignal, as a subclass of sosa:ObservableProperty, and vss:ActuatableSignal subclass of sosa:ActuatableProperty. All signals in VSS are subclasses of at least one of them. Many signals are subclasses of both. The choice of making a signal observable or actuatable is based on the existence of the sensor and actuator entries of each VSS Signal.
We also de ne a sosa:Sensor for all sosa:ObservableProperty and a sosa:Actuator for all sosa:ActuatableProperty. These sensors and actuators are as technology-independent as possible, as their physical instances vary from one OEM to another. Some signals relate to complex systems such as the infotainment system where there are no physical sensors or actuators. In this case, a virtual system de nes the sensor/actuator producing and consuming the data.
All branches are vss:partOf vss:Vehicle. The path de ning attributes and signals begins with the top element of the tree, being either \Attribute" or \Signal". The modeling choice would require the top branch to be the complete vehicle that contains all branches. There is, nevertheless, a branch among the top one called \Vehicle" containing attributes and signals about the full vehicle, such as its VIN. We take this branch as the top one containing all other branches. Position-related concepts are not branches. In VSS, the path to certain attributes and signals contains the position of certain branches. This is especially the case for elements that exist multiple times within one car, such as doors, seats and mirrors. For instance, there are signals Door.Left.IsLocked and Mirror.Right.Tilt. It is not desired to have classes de ning \left" and \right". We decide to model the hosting branches with a property vss:position. This de nes instances of such branches with the correct positions and still refer to a unique class. Using the same example, a door instance would have vss:position vss:Left and the mirror instance a vss:position vss:Right.
In order to evaluate the coverage of the VSS ontology, we tried to write SPARQL queries for all competency questions described in the Section 2. We also generate synthetic traces data using the VSSo ontology. Here are simple examples of such queries: What are the attributes of the chassis? SELECT ? a t t r i b u t e ? v a l u e WHERE f ? a t t r i b u t e r d f s : subPropertyOf ? branch ? a t t r i b u t e ? v a l u e ;
a v s s : C h a s s i s . g What is the current gear? SELECT ? s i g n a l ? r e s u l t ? time WHERE f ? s i g n a l a v s s : Gear . ? obs a s o s a : O b s e r v a t i o n ; s o s a : o b s e r v e d P r o p e r t y ? s i g n a l ; s o s a : h a s S i m p l e R e s u l t ? r e s u l t ; s o s a : phenomenonTime ? time . g ORDER BY DESC( ? time ) LIMIT 1 v s s : a t t r i b u t e .
VSSo ts our requirements of being based on an automotive standard and semantically enriching car data. Furthermore, with more than 300 di erent signals and 50 attributes, VSSo de nes more concepts than all ontologies, vocabularies and schemata from the state of the art, making it more complete. Finally, because VSSo is based on a speci cation meant to be extended, it is also easy to extend. In order to do so, a developer can directly use VSSo and its patterns to create new attributes, branches and signals. Another solution consists in writing the VSS extension in VSS format, and generate a new ontology. However, this second solution requires a step of validation afterwards. We extended the generator9 with a simple health check script. For instance, an OEM can de ne a private signal for a new embedded camera. In order to use it, a developer will de ne this camera as part of the VSSo extension in a new namespace. 5
In this paper, we identi ed a gap in formal de nition of car signals and sensors. We used some best practices both from the Semantic Web community and the automotive standards to propose VSSo, an ontology developed on top of 9 https://github.com/klotzbenjamin/vss-ontology/tree/master/rdfgeneration the SSN/SOSA recommendation. This new formal representation of car signals and attributes allows semantic queries. Various applications can bene t from this ontology, such as car eet monitoring, car trajectory mining, contextual representation of a car and interaction between any car and web services.