4.2 Concept
4.2.3 Classifier Training and Online Context Recognition
The tools presented above provide all means necessary to prepare sensor data recordings for use in context recognition methods. At this stage (see Figure 4.1), the recorded sensor data is ready to be fed into scripts and applications for training and evaluating machine learning methods. There is a wide spread range of programming libraries and tools available that help processing and analyzing numerical data, and training and evaluating classifiers (e.g., WEKA, scikit- learn (Python), Matlab, just to name a few). For the purpose of online context- and activity recognition, we provide the CRN Toolbox presented in Chapter 2 which offers an efficient and flexible runtime environment for this purpose. The reader tasks involved in the recording of the data set (Section 4.2.1) and the transformation tasks used in the Trace Generator (Section 4.2.2) may simply be re-used in the configuration at this stage, providing the online recognition system with exactly the same data format and processing steps as were applied to the training data. In the simplest case, only the configured classifier and an appropriate writer task need to be added to the configuration.
In the remainder of this section we present an extension to the Toolbox which allows for dynamic sharing of sensor data and services.
A Service-Oriented Extension for the CRN Toolbox
Regarding context recognition in well-known and stable surroundings, the CRN Toolbox is capable of setting up such a scenario and delivering data back to an application instantly. However, despite the fact that Toolbox instances can be flexibly distributed amongst numerous devices (this includes mobile devices such as small wearable computers, phones, PDAs, laptops, as well as desktop computers, workstations, and servers) and include other applications into their data flow, a distributed setup is error-prone, as each Toolbox instance relies on a known and stable network topology due to its static configuration.
It is quite common in environments of mobile, networked devices that devices leave the current network permanently or are temporarily unavailable due to lost connections. Once they rejoin the system, they might have another IP
address assigned to its network interfaces. Furthermore, mobile devices often disable their wireless connection to preserve battery power, go into low-power modes or even shut down automatically once the battery is just about to run out. Moreover, new sensors or devices – possibly valuable to the application’s mission – occasionally appear, such as an inertial sensor in a new shoe or a new edition of a smartphone offering better sensing and processing capabilities.
In these cases, the current Toolbox setup will either no longer function cor- rectly, hence a manual reconfiguration of the setup is inevitable (i.e., changing the IP addresses in the configuration file), or the setup is just not optimal any- more and the configuration would need to be adapted. Consequently, many applications are hard to incorporate because of the static nature of the Toolbox configuration.
As a result of these observations, we enhanced the CRN Toolbox to support service-level interfacing of its instances and rise the system to a more abstract level of services. Consequently, we can now replace the static Toolbox configura- tion with dynamic ad-hoc recombination of Toolbox services. In order to achieve this, two major extensions need to be incorporated into the system, with service registration and service discovery being the first, and semantic annotations for these newly available services being the second.
We compared several options for the implementation of the service regis- tration and service discovery layer: Universal Plug and Play (UPnP)2, Service
Location Protocol (SLP)3, Jini4 and DNS Service Discovery (DNS-SD)5. Dur-
ing our tests, DNS-SD outperformed the other protocols clearly. With every Toolbox implementing the DNS-SD protocol, it becomes easy for a third-party application to register and discover the available services. Basic service data like the name of the service’s host or the port it is bound to, is provided automati- cally by the DNS-SD protocol itself. Service-specific data on the other hand, can be included during service registration. In our case, this service-specific data represents the current configuration of the Toolbox service, i.e., which tasks are loaded and how they are connected amongst each other. As the configuration of a Toolbox itself is semantically not meaningful enough and happens on a rather low abstraction level, we introduce a semantic layer on top of the Toolbox, that is capable of describing services.
Basically, two types of CRN Toolbox services can be distinguished: simple sensing services, that are recording data from sensors, and more complex recog- nition services, which are encapsulating a concrete recognition algorithm. These algorithms usually require a specific type of sensor, i.e., sensing service, since they rely on a certain data format, sampling rate and of course need appropriate data sets for them to work properly.
The description of sensing services is straightforward: it includes fields char- acterizing the sensor the service is working on, such as sampling rate, supported axes and the sensor’s exact location, as well as the sensor service’s output. The description of the recognition service contains the output of the service as well, but also defines a set of predefined taxonomies and rules that have to be fulfilled by any sensing service in order to be considered as a possible candidate, that could be linked to the recognition service.
2UPnP: http://www.upnp.org/
3SLP: http://www.ietf.org/rfc/rfc2608.txt
4Jini: http://www.jini.org/wiki/Main_Page
With these extensions being made to the CRN Toolbox, dynamic ad-hoc recombination of CRN Toolbox services may take place. A context-aware appli- cation may for example browse for a specific recognition service which realizes exactly the task the application is looking for. After having found such a ser- vice, the service itself is able to find matching sensing services by reasoning over ontology rules. With a match being found, the sensing services are linked to the recognition service, which then initiates its algorithm and starts processing the input data and delivers the results back to the context-aware application for further processing steps. A comparable procedure has to be followed by the application in case it tries to find a suitable recognition service for a sensing service the application seeks to interact with.
Ultimately, the extensions described in this section allow for semi-automatic recombination of context-recognition tasks. Extending this work by making the step towards fully-automatic recombination might enable self-configuring and even self-healing sensor networks in the future.