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 14:32:35 +02:00
parent 4912525659
commit ecc031f355
1 changed files with 14 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

33
Bachelorarbeit.tex
View File

@ -1321,21 +1321,17 @@ 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. 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:
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 ü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 als Schwellwert festgelegt. Somit müssen über diesen Zeitraum alle Ereignisse vom Typ \texttt{CarWearEvent} nach PKW gruppiert und dann ausgezählt werden, um darauf aufbauend eine Kontextbedingung zu formulieren. 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]
CONDITION ($(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}
Übersetzt man dies nun in einen C-SPARQL-Query, so erhält man folgendes:
\begin{lstlisting}[label={lst:scenario_union_maintenance},caption={Signalisierung von Wartungsbedarf anhand von Ereignisaufkommen}]
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#>
@ -1344,22 +1340,19 @@ PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
PREFIX car: <http://example.org/carSim/carSimulationOntology#>
CONSTRUCT {
[] rdf:type car:CarMaintenanceNeededEvent
; car:relatedCar ?car .
; car:relatedCar ?car
; car:numberOfWearEvents ?numberWearEvents .
}
FROM STREAM <http://example.org/carSim/stream/carStream> [RANGE 5s TUMBLING]
FROM STREAM <http://example.org/carSim/stream/getEngineWear> [RANGE 4h STEP 5m]
FROM STREAM <http://example.org/carSim/stream/getWearEvents> [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 .
SELECT (?carWithWear AS ?car) (COUNT(?wearEvent) AS ?numberWearEvents)
WHERE {
?wearEvent rdf:type car:CarWearEvent .
?wearEvent car:relatedCar ?carWithWear .
}
GROUP BY ?carWithWear
HAVING (COUNT(?wearEvent) > 10)
}
}
\end{lstlisting}