simpler pages, no id, alerts

Note that Figure 1 aims at showing a global overview of the main classes of SAREF4AUTO and their mutual relations. More details on the different parts of Figure 1 are provided from clause 4.2.2 to clause 4.2.8 of the present document.

Note that Figure 1 aims at showing a global overview of the main classes of SAREF4AUTO and their mutual relations. More details on the different parts of Figure 1 are provided from clause 4.2.2 to clause 4.2.8 of the present document.

<figure id="Figure_1">

<figure>

        <img data-docx-width="17.00cm" src="diagrams/image2.png" alt="SAREF4AUTO overview"/>

        <img data-docx-width="17.00cm" src="diagrams/image2.png" alt="SAREF4AUTO overview"/>

        <figcaption>Figure 1: SAREF4AUTO overview</figcaption>

        <figcaption>Figure 1: SAREF4AUTO overview</figcaption>

    </figure>

    </figure>

As all measurements are subject to uncertainty, a confidence (error) value is always associated with measurement values. Therefore, SAREF4AUTO defines the `s4auto:hasConfidence` property that relates a `saref:Measurement` to its confidence `s4auto:Confidence`. 

As all measurements are subject to uncertainty, a confidence (error) value is always associated with measurement values. Therefore, SAREF4AUTO defines the `s4auto:hasConfidence` property that relates a `saref:Measurement` to its confidence `s4auto:Confidence`. 

<figure id="Figure_2">

<figure>

        <img data-docx-width="15.54cm" src="diagrams/image3.jpeg" alt="Measurement model"/>

        <img data-docx-width="15.54cm" src="diagrams/image3.jpeg" alt="Measurement model"/>

        <figcaption>Figure 2: Measurement model</figcaption>

        <figcaption>Figure 2: Measurement model</figcaption>

    </figure>

    </figure>

Table 2 and Table 3 summarize the definitions of the classes and properties described above.

Table 2 and Table 3 summarize the definitions of the classes and properties described above.

<table id="Table_2" data-docx-preferred-width="7.69cm 8.48cm">

<table data-docx-preferred-width="7.69cm 8.48cm">

  <caption>Table 2: Measurement: class definitions</caption>

  <caption>Table 2: Measurement: class definitions</caption>

  <tr>

  <tr>

    <th>Class</th>

    <th>Class</th>

<table id="Table_3" data-docx-preferred-width="7.69cm 8.48cm">

<table data-docx-preferred-width="7.69cm 8.48cm">

  <caption>Table 3: Measurement: property definitions</caption>

  <caption>Table 3: Measurement: property definitions</caption>

  <tr>

  <tr>

    <th>Property</th>

    <th>Property</th>

To define the main objects of interest in the automotive domain, the `s4auto:AutomotiveObject` class has been created. This class includes vehicles (such as cars, trucks, public transport and two-wheeler), personal devices that are used by pedestrians or the riders of a two-wheeler, traffic management centres that provide services to road users, and roadside equipment (i.e. roadside devices used for the communication between connected vehicles and between connected vehicles and the infrastructure). Figure 3 shows the hierarchy of automotive objects in SAREF4AUTO.  

To define the main objects of interest in the automotive domain, the `s4auto:AutomotiveObject` class has been created. This class includes vehicles (such as cars, trucks, public transport and two-wheeler), personal devices that are used by pedestrians or the riders of a two-wheeler, traffic management centres that provide services to road users, and roadside equipment (i.e. roadside devices used for the communication between connected vehicles and between connected vehicles and the infrastructure). Figure 3 shows the hierarchy of automotive objects in SAREF4AUTO.  

<figure id="Figure_3">

<figure>

        <img data-docx-width="16.30cm" src="diagrams/image4.jpeg" alt="Automotive Object hierarchy"/>

        <img data-docx-width="16.30cm" src="diagrams/image4.jpeg" alt="Automotive Object hierarchy"/>

        <figcaption>Figure 3: Automotive Object hierarchy</figcaption>

        <figcaption>Figure 3: Automotive Object hierarchy</figcaption>

    </figure>

    </figure>

Note that the hierarchy of automotive objects shown in Figure 3 is not exhaustive. It is possible and recommended to further specialize it, if needed, and extend it for new and additional use cases, to be included in future versions of the present document. Table 4 summarizes the definitions of the classes described above and Table 5 focuses on the properties of the Vehicle class.

Note that the hierarchy of automotive objects shown in Figure 3 is not exhaustive. It is possible and recommended to further specialize it, if needed, and extend it for new and additional use cases, to be included in future versions of the present document. Table 4 summarizes the definitions of the classes described above and Table 5 focuses on the properties of the Vehicle class.

<table id="Table_4" data-docx-preferred-width="7.69cm 8.48cm">

<table data-docx-preferred-width="7.69cm 8.48cm">

  <caption>Table 4: Automotive Objects: class definitions</caption>

  <caption>Table 4: Automotive Objects: class definitions</caption>

  <tr>

  <tr>

    <th>Class</th>

    <th>Class</th>

<table id="Table_5" data-docx-preferred-width="7.69cm 8.48cm">

<table data-docx-preferred-width="7.69cm 8.48cm">

  <caption>Table 5: Vehicle: property definitions</caption>

  <caption>Table 5: Vehicle: property definitions</caption>

  <tr>

  <tr>

    <th>Property</th>

    <th>Property</th>

Other relevant types of device are the personal devices that are used by pedestrians or the riders of a two-wheeler. Personal devices may be used for example by passenger car or truck drivers, but as they are considered as devices different from the vehicle ECU. 

Other relevant types of device are the personal devices that are used by pedestrians or the riders of a two-wheeler. Personal devices may be used for example by passenger car or truck drivers, but as they are considered as devices different from the vehicle ECU. 

<figure id="Figure_4">

<figure>

        <img data-docx-width="17.00cm" src="diagrams/image5.png" alt="Device model"/>

        <img data-docx-width="17.00cm" src="diagrams/image5.png" alt="Device model"/>

        <figcaption>Figure 4: Device model</figcaption>

        <figcaption>Figure 4: Device model</figcaption>

    </figure>

    </figure>

Table 6 and Table 7 summarize the definitions of the classes and properties described above.

Table 6 and Table 7 summarize the definitions of the classes and properties described above.

<table id="Table_6" data-docx-preferred-width="7.69cm 8.48cm">

<table data-docx-preferred-width="7.69cm 8.48cm">

  <caption>Table 6: Device: class definitions</caption>

  <caption>Table 6: Device: class definitions</caption>

  <tr>

  <tr>

    <th>Class</th>

    <th>Class</th>

<table id="Table_7" data-docx-preferred-width="7.69cm 8.48cm">

<table data-docx-preferred-width="7.69cm 8.48cm">

  <caption>Table 7: Device: property definitions</caption>

  <caption>Table 7: Device: property definitions</caption>

  <tr>

  <tr>

    <th>Property</th>

    <th>Property</th>

Figure 5 recalls the device model that was presented in clause 4.2.4 of the present document and provides the details of the `saref:Property` class. It shows the subclasses of `saref:FeatureOfInterest` class, which are `s4auto:Vehicle`, `s4auto:RoadEntity` and `s4auto:RoadObject`. It also depicts the sub-classes of `s4auto:Position` (i.e. `s4auto:AbsolutePosition`, `s4auto:RelativePosition`, `s4auto:PlatoonPosition,` `s4auto:RoadTopologyPosition` and the possible types of position relationships, for example of the `s4auto:Vehicle` feature of interest.

Figure 5 recalls the device model that was presented in clause 4.2.4 of the present document and provides the details of the `saref:Property` class. It shows the subclasses of `saref:FeatureOfInterest` class, which are `s4auto:Vehicle`, `s4auto:RoadEntity` and `s4auto:RoadObject`. It also depicts the sub-classes of `s4auto:Position` (i.e. `s4auto:AbsolutePosition`, `s4auto:RelativePosition`, `s4auto:PlatoonPosition,` `s4auto:RoadTopologyPosition` and the possible types of position relationships, for example of the `s4auto:Vehicle` feature of interest.

<figure id="Figure_5">

<figure>

        <img data-docx-width="17.00cm" src="diagrams/image6.png" alt="Property and Feature of Interest hierarchy"/>

        <img data-docx-width="17.00cm" src="diagrams/image6.png" alt="Property and Feature of Interest hierarchy"/>

        <figcaption>Figure 5: Property and Feature of Interest hierarchy</figcaption>

        <figcaption>Figure 5: Property and Feature of Interest hierarchy</figcaption>

    </figure>

    </figure>

Figure 6 shows the modelling of a platoon, which is composed by some members of type `s4auto:Vehicle` that automatically follow one another at a relatively close distance. Vehicles in the platoon have different roles (`s4auto:hasPlatoonRole` property), such as, for example, `s4auto:leader`, `s4auto:follower` or `s4auto:trailing`. The platoon can be characterized by different states over time (`s4auto:hasPlatoonState` property), such as, for example, `s4auto:assembling` or `s4auto:platooning`. The size of a platoon changes dynamically depending on the composition of the platoon over time (the `s4auto:Size` class). The property (`s4auto:hasMaxSize)`defines a fixed maximum size of vehicles that can compose a platoon at a particular moment in time. Figure 6 further shows that the platoon follows a route with a destination end point (which is usually the same destination of the platoon's leader). An example of a platoon defined according to this model is proposed in clause 4.3.1 of the present document. 

Figure 6 shows the modelling of a platoon, which is composed by some members of type `s4auto:Vehicle` that automatically follow one another at a relatively close distance. Vehicles in the platoon have different roles (`s4auto:hasPlatoonRole` property), such as, for example, `s4auto:leader`, `s4auto:follower` or `s4auto:trailing`. The platoon can be characterized by different states over time (`s4auto:hasPlatoonState` property), such as, for example, `s4auto:assembling` or `s4auto:platooning`. The size of a platoon changes dynamically depending on the composition of the platoon over time (the `s4auto:Size` class). The property (`s4auto:hasMaxSize)`defines a fixed maximum size of vehicles that can compose a platoon at a particular moment in time. Figure 6 further shows that the platoon follows a route with a destination end point (which is usually the same destination of the platoon's leader). An example of a platoon defined according to this model is proposed in clause 4.3.1 of the present document. 

<figure id="Figure_6">

<figure>

        <img data-docx-width="16.95cm" src="diagrams/image7.jpeg" alt="Platoon model"/>

        <img data-docx-width="16.95cm" src="diagrams/image7.jpeg" alt="Platoon model"/>

        <figcaption>Figure 6: Platoon model</figcaption>

        <figcaption>Figure 6: Platoon model</figcaption>

    </figure>

    </figure>

Table 8 and Table 9 summarize the definitions of the classes and properties of platoon that are described above.

Table 8 and Table 9 summarize the definitions of the classes and properties of platoon that are described above.

<table id="Table_8" data-docx-preferred-width="7.69cm 8.48cm">

<table data-docx-preferred-width="7.69cm 8.48cm">

  <caption>Table 8: Platoon: class definitions</caption>

  <caption>Table 8: Platoon: class definitions</caption>

  <tr>

  <tr>

    <th>Class</th>

    <th>Class</th>

<table id="Table_9" data-docx-preferred-width="7.69cm 8.48cm">

<table data-docx-preferred-width="7.69cm 8.48cm">

  <caption>Table 9: Platoon: property definitions</caption>

  <caption>Table 9: Platoon: property definitions</caption>

  <tr>

  <tr>

    <th>Property</th>

    <th>Property</th>

The topology model refers to the GeoSPARQL standard [i.5] for further details on how to define the parking topology (and possibly also the road topology) for the automotive domain and to the example instantiations in clause 4.3.2. 

The topology model refers to the GeoSPARQL standard [i.5] for further details on how to define the parking topology (and possibly also the road topology) for the automotive domain and to the example instantiations in clause 4.3.2. 

<figure id="Figure_7">

<figure>

        <img data-docx-width="16.51cm" src="diagrams/image8.jpeg" alt="Topology model"/>

        <img data-docx-width="16.51cm" src="diagrams/image8.jpeg" alt="Topology model"/>

        <figcaption>Figure 7: Topology model</figcaption>

        <figcaption>Figure 7: Topology model</figcaption>

    </figure>

    </figure>

The capacity to perceive the environment is reflected in the `s4auto:PerceptionState` class.

The capacity to perceive the environment is reflected in the `s4auto:PerceptionState` class.

<figure id="Figure_8">

<figure>

        <img data-docx-width="17.00cm" src="diagrams/image9.png" alt="Vehicle environment model"/>

        <img data-docx-width="17.00cm" src="diagrams/image9.png" alt="Vehicle environment model"/>

        <figcaption>Figure 8: Vehicle environment model</figcaption>

        <figcaption>Figure 8: Vehicle environment model</figcaption>

    </figure>

    </figure>

Table 10 and Table 11 summarize the class and properties that characterize the `s4auto:RoadEntity` class. For the `saref:Property` class, see clause 4.2.5 of the present document and Table 12 for the properties specific to the vehicle environment (i.e. shape and movement). 

Table 10 and Table 11 summarize the class and properties that characterize the `s4auto:RoadEntity` class. For the `saref:Property` class, see clause 4.2.5 of the present document and Table 12 for the properties specific to the vehicle environment (i.e. shape and movement). 

<table id="Table_10" data-docx-preferred-width="7.69cm 8.48cm">

<table data-docx-preferred-width="7.69cm 8.48cm">

  <caption>Table 10: Vehicle environment: class definitions</caption>

  <caption>Table 10: Vehicle environment: class definitions</caption>

  <tr>

  <tr>

    <th>Class</th>

    <th>Class</th>

<table id="Table_11" data-docx-preferred-width="7.69cm 8.48cm">

<table data-docx-preferred-width="7.69cm 8.48cm">

  <caption>Table 11: Vehicle environment: property definitions</caption>

  <caption>Table 11: Vehicle environment: property definitions</caption>

  <tr>

  <tr>

    <th>Property</th>

    <th>Property</th>

<table id="Table_12" data-docx-preferred-width="7.69cm 8.48cm">

<table data-docx-preferred-width="7.69cm 8.48cm">

  <caption>Table 12: Sub-classes of saref:Property specific to the vehicle environment </caption>

  <caption>Table 12: Sub-classes of saref:Property specific to the vehicle environment </caption>

  <tr>

  <tr>

    <th>Class</th>

    <th>Class</th>

Figure 9 shows an instance of a platoon, namely _ex:Platoon1_, which is composed by three members, namely _ex:Truck1_, _ex:Truck2_ and _ex:Truck3_. These trucks have different roles in the platoon, which are, respectively, `s4auto:leader`, `s4auto:follower` and `s4auto:trailing`. Note that these roles have the `s4auto:` prefix since they are pre-defined in the SAREF4AUTO ontology. In contrast, Platoon1, Truck1, Truck2 and Truck 3 have the _ex:_ prefix since they are defined as a separate example instantiation. The platoon can be characterized by different states over time. For example, at _18:48:15_ of _2020-02-02_ this state is unknown (_ex:Platoon1Unknown_ instance), whilst later in the same day at _19:01:00_, _19:04:50_ and _19:16:38_, the platoon is in the platooning state (_ex:Platoon1Platooning_ instance). The platoon has also a fixed maximum size of vehicles that can compose it (`s4auto:hasMaxSize` property) that in this example has a value of _6_, therefore, not more than 6 vehicles at a time are allowed to join _ex:Platoon1_. The platoon also has a size that changes dynamically, depending on the composition of the platoon over time. This is expressed in Figure 9 by the _ex:Platoon1Size_ instance of the `s4auto:Size` class that is associated with the measurement of how many members compose the platoon at a certain moment (_ex:Platoon1Size_Meas1_ instance of the `saref:Measurement` class). For example, at _18:45:35_ of _2020-02-02_, the size of the platoon has a value of _2_. Figure 9 finally shows that the destination of the platoon (_ex:Platoon1EndPoint_ instance) is the same destination of its leader (_ex:Truck1EndPoint_ instance), which in this case is Truck1. 

Figure 9 shows an instance of a platoon, namely _ex:Platoon1_, which is composed by three members, namely _ex:Truck1_, _ex:Truck2_ and _ex:Truck3_. These trucks have different roles in the platoon, which are, respectively, `s4auto:leader`, `s4auto:follower` and `s4auto:trailing`. Note that these roles have the `s4auto:` prefix since they are pre-defined in the SAREF4AUTO ontology. In contrast, Platoon1, Truck1, Truck2 and Truck 3 have the _ex:_ prefix since they are defined as a separate example instantiation. The platoon can be characterized by different states over time. For example, at _18:48:15_ of _2020-02-02_ this state is unknown (_ex:Platoon1Unknown_ instance), whilst later in the same day at _19:01:00_, _19:04:50_ and _19:16:38_, the platoon is in the platooning state (_ex:Platoon1Platooning_ instance). The platoon has also a fixed maximum size of vehicles that can compose it (`s4auto:hasMaxSize` property) that in this example has a value of _6_, therefore, not more than 6 vehicles at a time are allowed to join _ex:Platoon1_. The platoon also has a size that changes dynamically, depending on the composition of the platoon over time. This is expressed in Figure 9 by the _ex:Platoon1Size_ instance of the `s4auto:Size` class that is associated with the measurement of how many members compose the platoon at a certain moment (_ex:Platoon1Size_Meas1_ instance of the `saref:Measurement` class). For example, at _18:45:35_ of _2020-02-02_, the size of the platoon has a value of _2_. Figure 9 finally shows that the destination of the platoon (_ex:Platoon1EndPoint_ instance) is the same destination of its leader (_ex:Truck1EndPoint_ instance), which in this case is Truck1. 

<figure id="Figure_9">

<figure>

        <img data-docx-width="16.64cm" src="diagrams/image11.png" alt="Platoon example"/>

        <img data-docx-width="16.64cm" src="diagrams/image11.png" alt="Platoon example"/>

        <figcaption>Figure 9: Platoon example</figcaption>

        <figcaption>Figure 9: Platoon example</figcaption>

    </figure>

    </figure>

Figure 10 elaborates on the three trucks that are members of the _ex:Platoon1_ instance. These trucks are all characterized by an identifier (`s4auto:hasIdentifier` property), which is defined as a Station ID (_ex:StationID4_, _ex:StationID5_ and _ex:StationID6_ instances). Furthermore, all trucks have a certain role and position in the platoon. For example, Truck1 has the leading role and, consequently, it assumes the first position in the platoon. This is expressed in Figure 10 by the `s4auto:hasPlatoonPosition` property, which relates the _ex:Truck1_ instance with the _ex:PlatoonPosition1_ instance, which in turn has a `s4auto:hasPlatoonIndex` property value of _1_. The _ex:Truck2_ instance has a follower role and consequently relates to the _ex:PlatoonPosition2_ instance with a `s4auto:hasPlatoonIndex` property value of _2_. Since the _ex:Truck3_ instance has a trailing role, it occupies the last position in the platoon (_ex:PlatoonPosition3_ instance) with a `s4auto:hasPlatoonIndex` property value of _3_.

Figure 10 elaborates on the three trucks that are members of the _ex:Platoon1_ instance. These trucks are all characterized by an identifier (`s4auto:hasIdentifier` property), which is defined as a Station ID (_ex:StationID4_, _ex:StationID5_ and _ex:StationID6_ instances). Furthermore, all trucks have a certain role and position in the platoon. For example, Truck1 has the leading role and, consequently, it assumes the first position in the platoon. This is expressed in Figure 10 by the `s4auto:hasPlatoonPosition` property, which relates the _ex:Truck1_ instance with the _ex:PlatoonPosition1_ instance, which in turn has a `s4auto:hasPlatoonIndex` property value of _1_. The _ex:Truck2_ instance has a follower role and consequently relates to the _ex:PlatoonPosition2_ instance with a `s4auto:hasPlatoonIndex` property value of _2_. Since the _ex:Truck3_ instance has a trailing role, it occupies the last position in the platoon (_ex:PlatoonPosition3_ instance) with a `s4auto:hasPlatoonIndex` property value of _3_.

<figure id="Figure_10">

<figure>

        <img data-docx-width="17.00cm" src="diagrams/image12.png" alt="Platoon members example"/>

        <img data-docx-width="17.00cm" src="diagrams/image12.png" alt="Platoon members example"/>

        <figcaption>Figure 10: Platoon members example</figcaption>

        <figcaption>Figure 10: Platoon members example</figcaption>

    </figure>

    </figure>

Figure 11 further shows that the car is provided with a `s4auto:ElectronicControlUnit` (_ex:Car1ECU_ instance) that can make measurements about relevant properties, such as speed, acceleration, position, etc. In the example, the electronic control unit provides a speed measurement (_ex:Car1Speed_Meas1_ instance) with a value of 100 km per hour with an associated timestamp. As all measurements are subject to uncertainty, a confidence is always associated with measurement values. Therefore, a confidence of the _ex:Car1Speed_Meas1_ measurement is also provided and show in Figure 11 as the _ex:Confidence1_ instance with a value of 3 km per hour. 

Figure 11 further shows that the car is provided with a `s4auto:ElectronicControlUnit` (_ex:Car1ECU_ instance) that can make measurements about relevant properties, such as speed, acceleration, position, etc. In the example, the electronic control unit provides a speed measurement (_ex:Car1Speed_Meas1_ instance) with a value of 100 km per hour with an associated timestamp. As all measurements are subject to uncertainty, a confidence is always associated with measurement values. Therefore, a confidence of the _ex:Car1Speed_Meas1_ measurement is also provided and show in Figure 11 as the _ex:Confidence1_ instance with a value of 3 km per hour. 

<figure id="Figure_11">

<figure>

        <img data-docx-width="17.00cm" src="diagrams/image13.png" alt="Car example"/>

        <img data-docx-width="17.00cm" src="diagrams/image13.png" alt="Car example"/>

        <figcaption>Figure 11: Car example</figcaption>

        <figcaption>Figure 11: Car example</figcaption>

    </figure>

    </figure>

Figure 12 shows how the GeoSPARQL ontology has been reused in SAREF4AUTO to represent the parking spot topology. A parking spot is defined as the _ex:ParkingSpot1_ instance of the `s4auto:RegularParkingSpot` class, which in turn is a subclass of the more general `geosp:Feature` class that allows to define spatial features. The geometry of a parking spot is usually defined by several points describing the shape of the spot, e.g. 4 points describing a rectangle shape and then a central point. For the sake of simplifying the example, the geometry of this parking spot is simplified defining only its central point, namely the _ex:ParkingSpot1_ instance of the `s4auto:RegularParkingSpot` class, with a latitude and longitude that have values 52.081927 and 4.325145, respectively. Note that the `sf:Polygon` class described in clause 4.2.7 can be used to further define the rectangle shape of the parking spot. The parking spot is characterized by different states over time (`s4auto:hasParkingSpotState` property), depending on the states of the car that is driving towards the spot (which are shown in Figure 13). For example, at _14:00:00_ of _2020-04-08_ the parking spot is free (_ex:ParkingSpot1Free_ instance), whilst a few minutes later at _14:03:00_ the parking spot becomes reserved (_ex:ParkingSpot1Reserved_ instance), since Car1 arrived at the drop off spot (shown in Figure 13) and reserved a nearby spot available, which happens to be ParkingSpot1. At _14:07:00_, after the car drives to the parking spot and parks, the parking spot becomes occupied (_ex:ParkingSpot1OCcupied_ instance). 

Figure 12 shows how the GeoSPARQL ontology has been reused in SAREF4AUTO to represent the parking spot topology. A parking spot is defined as the _ex:ParkingSpot1_ instance of the `s4auto:RegularParkingSpot` class, which in turn is a subclass of the more general `geosp:Feature` class that allows to define spatial features. The geometry of a parking spot is usually defined by several points describing the shape of the spot, e.g. 4 points describing a rectangle shape and then a central point. For the sake of simplifying the example, the geometry of this parking spot is simplified defining only its central point, namely the _ex:ParkingSpot1_ instance of the `s4auto:RegularParkingSpot` class, with a latitude and longitude that have values 52.081927 and 4.325145, respectively. Note that the `sf:Polygon` class described in clause 4.2.7 can be used to further define the rectangle shape of the parking spot. The parking spot is characterized by different states over time (`s4auto:hasParkingSpotState` property), depending on the states of the car that is driving towards the spot (which are shown in Figure 13). For example, at _14:00:00_ of _2020-04-08_ the parking spot is free (_ex:ParkingSpot1Free_ instance), whilst a few minutes later at _14:03:00_ the parking spot becomes reserved (_ex:ParkingSpot1Reserved_ instance), since Car1 arrived at the drop off spot (shown in Figure 13) and reserved a nearby spot available, which happens to be ParkingSpot1. At _14:07:00_, after the car drives to the parking spot and parks, the parking spot becomes occupied (_ex:ParkingSpot1OCcupied_ instance). 

<figure id="Figure_12">

<figure>

        <img data-docx-width="13.43cm" src="diagrams/image14.png" alt="Parking Spot example"/>

        <img data-docx-width="13.43cm" src="diagrams/image14.png" alt="Parking Spot example"/>

        <figcaption>Figure 12: Parking Spot example</figcaption>

        <figcaption>Figure 12: Parking Spot example</figcaption>

    </figure>

    </figure>

Finally, Figure 13 shows the different states of the car during the AVP. At _14:02:10_ of _2020-04-08_ the car arrives at the drop off spot (_ex:Car1AtDropOffSpot1_ instance) and looks for an available nearby parking spot (provided by a third party service in the IoT platform). The _ex:ParkingSpot1_ is subsequently reserved and its state becomes reserved at _14:03:00_ (_ex:ParkingSpot1Reserved_ instance shown in Figure 12). The car drives to the reserved parking spot and at _14:04:00_ has state _ex:Car1DrivingToParkingSpot1_, which then turns into the _ex:Car1ParkinginSpot1_ state at _14:07:00_, once the car has arrived at the parking spot and it is parking. Note that at the same moment, the state of the parking spot becomes occupied (_ex:ParkingSpot1Reserved_ instance shown in Figure 12). At _14:10:00_, once the car is parked, its state turns to parked (_ex:Car1ParkedInSpot1_ instance). 

Finally, Figure 13 shows the different states of the car during the AVP. At _14:02:10_ of _2020-04-08_ the car arrives at the drop off spot (_ex:Car1AtDropOffSpot1_ instance) and looks for an available nearby parking spot (provided by a third party service in the IoT platform). The _ex:ParkingSpot1_ is subsequently reserved and its state becomes reserved at _14:03:00_ (_ex:ParkingSpot1Reserved_ instance shown in Figure 12). The car drives to the reserved parking spot and at _14:04:00_ has state _ex:Car1DrivingToParkingSpot1_, which then turns into the _ex:Car1ParkinginSpot1_ state at _14:07:00_, once the car has arrived at the parking spot and it is parking. Note that at the same moment, the state of the parking spot becomes occupied (_ex:ParkingSpot1Reserved_ instance shown in Figure 12). At _14:10:00_, once the car is parked, its state turns to parked (_ex:Car1ParkedInSpot1_ instance). 

<figure id="Figure_13">

<figure>

        <img data-docx-width="15.01cm" src="diagrams/image15.png" alt="Automated Valet Parking example "/>

        <img data-docx-width="15.01cm" src="diagrams/image15.png" alt="Automated Valet Parking example "/>

        <figcaption>Figure 13: Automated Valet Parking example </figcaption>

        <figcaption>Figure 13: Automated Valet Parking example </figcaption>

    </figure>

    </figure>

This clause shows an example instance of a vehicle at a crossroad which is able to recognize the different road entities in its environment. For each entity, the information related to its properties is included. The example shows in the environment a vehicle coming in the opposite direction and another one coming from the right. There are two pedestrians, one waiting to cross a road (thus not moving) and a young child (smaller height) crossing while it is not allowed to, thus generating an alert from a smart traffic light. A motorcycle is also crossing from the left of the instantiated vehicle. Figure 14 helps visualizing this example.

This clause shows an example instance of a vehicle at a crossroad which is able to recognize the different road entities in its environment. For each entity, the information related to its properties is included. The example shows in the environment a vehicle coming in the opposite direction and another one coming from the right. There are two pedestrians, one waiting to cross a road (thus not moving) and a young child (smaller height) crossing while it is not allowed to, thus generating an alert from a smart traffic light. A motorcycle is also crossing from the left of the instantiated vehicle. Figure 14 helps visualizing this example.

<figure id="Figure_14">

<figure>

        <img data-docx-width="12.71cm" src="diagrams/image16.png" alt="Example scenario for vehicle environment with VRU"/>

        <img data-docx-width="12.71cm" src="diagrams/image16.png" alt="Example scenario for vehicle environment with VRU"/>

        <figcaption>Figure 14: Example scenario for vehicle environment with VRU</figcaption>

        <figcaption>Figure 14: Example scenario for vehicle environment with VRU</figcaption>

    </figure>

    </figure>

Figure 15 contains an example of instantiation of SAREF4AUTO for the example featured in Figure 14. The main feature of interest in the example is Car1 (`ex:Car1`) which indicates that it is able to sense its environment (`ex:EnvironmentDetected`). At the time of detection, Car1 has a position (`ex:Car1AbsolutePosition1`) and a speed (`ex:Car1Speed`) which is measured as 10 km/h (Car1Speed_Meas1). Figure 15 also illustrates the different entities that compose the environment (`ex:Car1VehicleEnv`) of Car1: two vehicles, i.e. a car (`ex:Car4`) and a truck (`ex:Truck4`), as well as four other road entities: a child pedestrian (`ex:RoadEntityChild1`), an adult pedestrian (`ex:RoadEntityAdult1`), a motorcycle (`ex:RoadEntityMoto1`) and an event (`ex:RoadEntityEvent1`) which is received because the child is crossing the road in front of Car1, while it is not allowed to do so.

Figure 15 contains an example of instantiation of SAREF4AUTO for the example featured in Figure 14. The main feature of interest in the example is Car1 (`ex:Car1`) which indicates that it is able to sense its environment (`ex:EnvironmentDetected`). At the time of detection, Car1 has a position (`ex:Car1AbsolutePosition1`) and a speed (`ex:Car1Speed`) which is measured as 10 km/h (Car1Speed_Meas1). Figure 15 also illustrates the different entities that compose the environment (`ex:Car1VehicleEnv`) of Car1: two vehicles, i.e. a car (`ex:Car4`) and a truck (`ex:Truck4`), as well as four other road entities: a child pedestrian (`ex:RoadEntityChild1`), an adult pedestrian (`ex:RoadEntityAdult1`), a motorcycle (`ex:RoadEntityMoto1`) and an event (`ex:RoadEntityEvent1`) which is received because the child is crossing the road in front of Car1, while it is not allowed to do so.

<figure id="Figure_15">

<figure>

        <img data-docx-width="16.99cm" src="diagrams/image17.png" alt="Example of Vehicle environment at a crossroad"/>

        <img data-docx-width="16.99cm" src="diagrams/image17.png" alt="Example of Vehicle environment at a crossroad"/>

        <figcaption>Figure 15: Example of Vehicle environment at a crossroad</figcaption>

        <figcaption>Figure 15: Example of Vehicle environment at a crossroad</figcaption>

    </figure>

    </figure>

The last road entity shown in Figure 16 is the event (`ex:RoadEntityEvent1`) that is disseminated to indicate to vehicles that the child (`ex:RoadEntityChild1`) is crossing the road while it is not allowed to do so. This entity consists of a notified event (`ex:humanPresenceOnTheRoad`) and has the same values for its relative position (`ex:Event1RelativePosition`) as the child (`ex:RoadEntityChild1`).

The last road entity shown in Figure 16 is the event (`ex:RoadEntityEvent1`) that is disseminated to indicate to vehicles that the child (`ex:RoadEntityChild1`) is crossing the road while it is not allowed to do so. This entity consists of a notified event (`ex:humanPresenceOnTheRoad`) and has the same values for its relative position (`ex:Event1RelativePosition`) as the child (`ex:RoadEntityChild1`).

<figure id="Figure_16">

<figure>

        <img data-docx-width="15.90cm" src="diagrams/image18.png" alt="Example of sensed entities with Vulnerable Road Users"/>

        <img data-docx-width="15.90cm" src="diagrams/image18.png" alt="Example of sensed entities with Vulnerable Road Users"/>

        <figcaption>Figure 16: Example of sensed entities with Vulnerable Road Users</figcaption>

        <figcaption>Figure 16: Example of sensed entities with Vulnerable Road Users</figcaption>

    </figure>

    </figure>

* <a id="[i.1]">[i.1]</a>	ETSI TR 103 508 (V1.1.1) (10-2019): "SmartM2M; SAREF extension investigation; Requirements for Automotive".

* <a id="[i.1]">[i.1]</a>	ETSI TR 103 508 (V1.1.1) (10-2019): "SmartM2M; SAREF extension investigation; Requirements for Automotive".

* <a id="[i.2]">[i.2]</a>	SENSORIS: "Sensor Interface Specification".

* <a id="[i.2]">[i.2]</a>	SENSORIS: "Sensor Interface Specification".

!!! alert-info "NOTE:"

!!! alert alert-info "NOTE:"

    Available at [https://sensor-is.org/](https://sensor-is.org/).

    Available at [https://sensor-is.org/](https://sensor-is.org/).

* <a id="[i.3]">[i.3]</a>	CEN EN 16157-2:2019: "Intelligent transport systems - DATEX II data exchange specifications for traffic management and information - Part 2: Location referencing".

* <a id="[i.3]">[i.3]</a>	CEN EN 16157-2:2019: "Intelligent transport systems - DATEX II data exchange specifications for traffic management and information - Part 2: Location referencing".

* <a id="[i.4]">[i.4]</a>	"The DATEX II Parking Publications Extension".

* <a id="[i.4]">[i.4]</a>	"The DATEX II Parking Publications Extension".

!!! alert-info "NOTE:"

!!! alert alert-info "NOTE:"

    Available at [https://datex2.eu/implementations/extension_directory/parking-publications-extension-v10a](https://datex2.eu/implementations/extension_directory/parking-publications-extension-v10a).

    Available at [https://datex2.eu/implementations/extension_directory/parking-publications-extension-v10a](https://datex2.eu/implementations/extension_directory/parking-publications-extension-v10a).

* <a id="[i.5]">[i.5]</a>	OGC 11-052r4: "OGC GeoSPARQL - A Geographic Query Language for RDF Data". Version 1.0.

* <a id="[i.5]">[i.5]</a>	OGC 11-052r4: "OGC GeoSPARQL - A Geographic Query Language for RDF Data". Version 1.0.