JPT
/
bachelorthesis
0
0
Fork 0
Code Issues Pull Requests Activity

[TASK] Generic commit.

This commit is contained in:
Jan Philipp Timme 2016-10-11 13:33:39 +02:00
parent eabc2ec614
commit 4912525659
1 changed files with 49 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

53
Bachelorarbeit.tex
View File

@ -1294,7 +1294,12 @@ PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX f: <http://larkc.eu/csparql/sparql/jena/ext#>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
PREFIX car: <http://example.org/carSim/carSimulationOntology#>
SELECT ?e ?type ?car ?driverName ?driverPhone
CONSTRUCT {
[] rdf:type car:CarWearEvent
; car:relatedCar ?car
; car:responsibleDriverName ?driverName
; car:responsibleDriverPhone ?driverPhone .
}
FROM STREAM <http://example.org/carSim/stream/getEngineWear> [RANGE 1s TUMBLING]
FROM STREAM <http://example.org/carSim/stream/getBrakeWear> [RANGE 1s TUMBLING]
FROM STREAM <http://example.org/carSim/stream/getHandbrakeWear> [RANGE 1s TUMBLING]
@ -1316,11 +1321,51 @@ Beobachtet man die Ergebnisse dieser Abfrage, so hat man die Möglichkeit, nutzu
\subsection{Erkennung von Wartungsbedarf am Fahrzeug}
Um Wartungsbedarf zu signalisieren soll eine Abfrage erzeugt werden, die Ereignisse vom Typ \texttt{CarMaintenanceNeededEvent} für jeden PKW liefert, für den ein Wartungsbedarf existiert. Ein Wartungsbedarf ist dann gegeben, wenn ein PKW entweder ein Ereignis vom Typ \texttt{CarCheckEngineEvent} auslöst, oder wenn über einen größeren Zeitraum eine bestimmte Menge von \texttt{CarWearEvent}s ausgelöst wurde.
\todo{!!}
Um Wartungsbedarf zu signalisieren soll eine Abfrage erzeugt werden, die Ereignisse vom Typ \texttt{CarMaintenanceNeededEvent} für jeden PKW liefert, für den ein Wartungsbedarf existiert. Ein Wartungsbedarf ist dann gegeben, wenn ein PKW entweder ein Ereignis vom Typ \texttt{CarCheckEngineEvent} auslöst, oder wenn über einen größeren Zeitraum eine bestimmte Menge von \texttt{CarWearEvent}s ausgelöst wurde. In diesem Beispiel wurde eine Menge von 100 \texttt{CarWearEvent}s über einen Zeitraum von vier Stunden festgelegt. Da auftretende \texttt{CarCheckEngineEvent}s hingegen sofort verarbeitet werden sollen, müssen sie in einem separaten Tumbling Window betrachtet werden. Somit müssen hier zwei Ereignisströme über ein logisches Oder miteinander verknüpft werden, um einen Wartungsbedarf zu signalisieren. In einer abstrakten CEP-Regel sieht dies wie folgt aus:
\begin{lstlisting}[mathescape=true,label={},caption={}]
CONDITION
($(CarCheckEngineEvent\ AS\ checkEngineEvent)$)[WindowSize:5s,StepSize:5s]
$\wedge$ checkEngineEvent.relatedCar AS car
$\vee$
($(CarWearEvent\ AS\ wearEvent)$)[WindowSize:4h,StepSize:5m]
$\wedge$ wearEvent.relatedCar AS car
$\wedge$ AGGREGATE(wearEvent, "relatedCar", COUNT) AS numberWearEvents
$\wedge$ numberWearEvents > 100
ACTION
new CarMaintenanceNeededEvent(relatedCar=car)
\end{lstlisting}
Übersetzt man dies nun in einen C-SPARQL-Query unter Verwendung des Konstrukts \texttt{UNION}, so erhält man diesen Query:
\begin{lstlisting}
REGISTER STREAM getMaintenanceEvents AS
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX f: <http://larkc.eu/csparql/sparql/jena/ext#>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
PREFIX car: <http://example.org/carSim/carSimulationOntology#>
CONSTRUCT {
[] rdf:type car:CarMaintenanceNeededEvent
; car:relatedCar ?car .
}
FROM STREAM <http://example.org/carSim/stream/carStream> [RANGE 5s TUMBLING]
FROM STREAM <http://example.org/carSim/stream/getEngineWear> [RANGE 4h STEP 5m]
WHERE {
{
OPTIONAL {
?e rdf:type car:CarWearEvent .
?e car:relatedCar ?car .
}
}
UNION {
OPTIONAL {
?checkEngineEvent rdf:type car:CarCheckEngineEvent .
?checkEngineEvent car:relatedCar ?car .
}
}
}
\end{lstlisting}
\subsection{Unfallerkennung}
Die Erkennung von schweren Unfällen ist anhand von Ereignissen vom Typ \texttt{Car\allowbreak Airbag\allowbreak Triggered\allowbreak Event} relativ leicht. Die Erkennung kleinerer Kollisionen hingegen stellt selbst mit Daten von Schocksensoren eine Herausforderung dar und kann somit im Rahmen dieses Szenarios nicht durchgeführt werden. Es bleibt die direkte Auswertung der \texttt{Car\allowbreak Airbag\allowbreak Triggered\allowbreak Event}s, um Unfälle zu erkennen. Die abstrakte CEP-Regel dafür sieht wie folgt aus:
Die Erkennung von schweren Unfällen ist anhand von Ereignissen vom Typ \texttt{Car\allowbreak Airbag\allowbreak Triggered\allowbreak Event} relativ leicht, da mit sehr hoher Wahrscheinlichkeit davon ausgegangen werden kann, dass ein ausgelöster Airbag mit einem schweren Aufprall zusammenhängt. Die Erkennung kleinerer Kollisionen hingegen stellt selbst mit Daten von Schocksensoren eine Herausforderung dar und kann somit im Rahmen dieses Szenarios nicht durchgeführt werden. Es bleibt die direkte Auswertung der \texttt{Car\allowbreak Airbag\allowbreak Triggered\allowbreak Event}s, um Unfälle zu erkennen. Dabei sind nur Fahrzeuge interessant, die zur Zeit auch gefahren werden; für die also ein Fahrer eingetragen ist. Die abstrakte CEP-Regel dafür sieht wie folgt aus:
\begin{lstlisting}[mathescape=true,label={},caption={}]
CONDITION ($(CarAirbagTriggeredEvent\ AS\ airbagEvent)$)[WindowSize:5s,StepSize:5s]
$\wedge$ lookup("driver", airbagEvent.relatedCar) AS driver