Runtime variability management of component-based software systems allows to consider the current context of a system for system con guration to achieve energy-e ciency. For optimizing the system con guration at runtime, the early recognition of situations apt to reconguration is an important task. To describe these situations on di ering levels of detail and to allow their recognition even if only incomplete information is available, we employ the ontology language OWL 2 and the reasoning services de ned for it. In this paper, we show that the relevant situations for optimizing the current system con guration can be modeled in the di erent OWL 2 pro les. We further provide a case study on the performance of state of the art OWL 2 reasoning systems for answering concept queries and conjunctive queries modeling the situations to be detected.
A typical approach to introduce variability into complex software systems is
the application of component-based software engineering, where variability is
achieved by multiple implementations for components [
A feasible approach to component-based self-adaptive systems are
contractbased negotiations, which re ect the non-functional behavior of component
implementations [
Collaborative Research Center 912 `Highly Adaptive Energy-E cient Computing'.
Variability management for energy saving is carried out at runtime of the software system, to ensure that the current con guration of system components employed uses energy optimally. A key aspect is the ability to adjust the system con guration to the current system load and, more importantly, to the hardware resources available. In the end it is the hardware that consumes the energy directly when being utilized by the software. Depending on the current context (e.g., the available resources, the system load, the software variants available, etc.) a component-based software system can be adapted in di erent ways to save power at runtime.
Clearly, system adaptation needs to be carried out, if there are 'violations' of contract clauses of a component, which re ect the assumptions that led to the selection of this component. Contract violations occur if the requirements of the selected software variants cannot be provided anymore (e.g., if utilization thresholds are exceeded). In order to save energy, adaptations should be performed in situations where energy is (about to be) wasted. This kind of situations does not necessarily involve a violation, but is a type of situations where clauses that were not valid at the time of the last decision have now become valid.
Ideally, a software management system is noti ed in advance about situations where a recon guration might be bene cial to carry out appropriate adjustments in time. To this end, context information characterizing the execution environment has to be collected, and situations apt to optimization have to be recognized in this (abstract) representation of the actual system. In case a critical situation is recognized, the adjustments to be carried out have to be determined in a second step by the software management system. In this paper, we concentrate only on the task of situation recognition.
Typically, the information sources for the overall software system's status providing information relevant to situation recognition are very heterogeneous. For instance, the properties of di erent implementations of a particular functionality may be given by the software providers and could be stored in a database, while other information, such as the setup of the hardware and the current system parameters, could be retrieved from the operating system directly. These sources yield information of di erent levels of detail, which can be integrated in a Description Logic (DL) ontology. Moreover, logical reasoning as provided by DL systems, can handle incomplete information on the current situation gracefully, since these systems operate under the open world assumption.
For these reasons, we follow a common approach to situation recognition
and use an ontology describing the managed software system and its hardware.
We employ DL reasoning services to recognize situations of interest. This
approach has been employed in several domains for context-aware applications,
for instance, scene interpretation [
DLs are the logical under-pinning of the ontology language OWL 2 [
In OWL 2, categories from the application domain are described by concept expressions and binary relations by so-called roles. For example, the concept VideoServer, which is a server that hosts components to provide transcoding (i.e., the conversion of video encodings), up- and downloading services can be characterized by the expression:
Server u (9hosts:TranscoderComponent) u (9hosts:UploaderComponent) u (9hosts:DownloaderComponent) Such de nitions of concepts are stored in the TBox. In addition, the TBox can contain characteristics of roles (e.g., transitivity). Our TBox contains information on concepts common in the domain of modular video platforms (e.g., server or transcoder component) and on relations.
The ABox stores concrete facts about a particular application|in our case the servers available together with their utilization. These facts are expressed by concept assertions, which state that an individual belongs to a (possibly complex) concept or role assertions that relate two individuals via a role. For example, we can state in our ABox A1 that the individual Server1 belongs to the class VideoServer and that its related transcoder component is individual Variant1 , which belongs to the concept FastTranscoderImplementation, by writing: A1 = f VideoServer(Server1 ); hosts(Server1 ; Variant1 );
FastTranscoderImplementation(Variant1 ) g: A TBox and an ABox together constitute an ontology.
Now, such an ontology can be used to detect complex situations by applying the DL reasoning services: concept query answering and conjunctive query answering. Both are applied to retrieve (tuples of) speci c individuals from an ontology. Given a concept and an ontology, concept query answering returns all individuals of the ABox that belong to that concept regarding the information captured in the ontology. Conjunctive query answering allows to retrieve tuples of ABox individuals that ful ll the conditions speci ed in the query. Concept and conjunctive queries also di er in the expressive power for specifying the situations. While the former are limited by the expressivity of the ontology language, the latter can make use of variables to describe arbitrary structures as aspects of situations. This addition in expressivity comes at the cost of higher computational complexity of reasoning.
The OWL 2 standard for ontology languages comprises so-called OWL 2
proles which di er w.r.t. their expressivity [
Concept query answering in the corresponding DL SROIQ is
2NExpTimecomplete [
Over the past years, highly optimized reasoners for answering concept or conjunctive queries have been developed. Although the computational complexity of the implemented algorithms for OWL 2 EL and QL is promisingly low, it is not clear whether these implementations are yet fast enough to realize situation recognition for applications that deal with complex situations and require fast response times|such as component-based systems recon guring.
While [
In this paper, we demonstrate that the di erent OWL pro les can be applied for modeling a modular video platform and critical situations for system recon guration (in Section 2). Second, we present an empirical evaluation w.r.t. the di erent OWL pro les on how current DL reasoners perform on concept and conjunctive queries in our scenario (in Section 3). 2
To show the bene ts of the ontology-based approach to variability management, we consider a modular video platform as application scenario. Among others, the platform provides software components for transcoding, up- and downloading of videos. These functionalities are complex and resource-intensive, which have to be provided in a required quality. In order to e ectively exploit the available resources, we optimize the con guration of the system at runtime. We choose software variants that allow for optimal con guration of the hardware resources, to reduce the overall energy consumption of the video platform. Consider a server providing a transcoding service. If the server's load is currently decreasing, the CPU frequency can be reduced to save energy. To ensure, however, that the system still provides the required quality, such a change might necessitate a recon guration (i.e., a switch to implementations that simply allow for a lower CPU frequency).
To recognize situations where recon gurations can be bene cial, we create
ontologies modeling information about the system, capture situations apt for
recon guration as query concepts or as conjunctive queries and then apply DL
reasoners to detect situations by invoking concept query answering or
conjunctive query answering, respectively. More precisely, at design time, the general
domain knowledge about video platforms (e.g., the kinds of services provided)
and notions of components of the systems (e.g., dependencies on hardware
resources or speci c software variants) are modeled in the TBox. The situations to
be recognized are modeled as concept or conjunctive queries|depending on the
reasoning task to be employed. We assume the TBox and the set of queries to
be xed over the runtime of the system. The ABox describes the actual
architecture of the speci c application (i.e., the currently available hard- and software
resources) and their current state (e.g., the load of the system, and the
implementations executed). Most of this data is collected at runtime of the software
system. Due to the highly dynamic nature of the system, the ABox is refreshed
several times a minute storing information from several information sources.
Socalled preprocessors are applied for the task of converting numerical sensor data
into primitive named concepts (following the approach in [
are added to the ABox created for the past interval. Once the ABox is refreshed, we apply the DL reasoner to answer the concept or conjunctive queries. 2.1
Now we describe how the overall video platform system is modeled in the
ontology that is the base ontology for our tests and how the queries are captured
in the di erent OWL 2 variants. Our TBox contains concepts describing the
video platform domain (e.g., characteristics of a TranscodingService) and notions
for component systems (e.g., FastTranscoderImplementation), written in the DL
ALCI, a proper sub-logic of OWL 2. For this DL, testing concept queries is
PSpace-complete [
Example 1. Assume the load of our Server1 has changed to `underutilized' in the past intervals. Now, the characterization of Server1 , its resources, and states at runtime can be captured by:
It turned out that even the expressivity of the lightweight pro les OWL 2 EL and QL allow to describe the main characteristics of the domain knowledge of our application scenario. This is because the TBox primarily captures the hard- and software architecture of the system, which is exactly the conceptual modeling use case DL-Lite has been developed for. Further, complex concept de nitions that cannot be represented in the lightweight pro les can be captured, alternatively, using ne-granular conjunctive queries for modeling the situations to be recognized. Consider the following concept de nition for underutilized servers, which have a load average that is underutilized or almost underutilized:
9hasLoadAverage:(AlmostUnderUtilized t UnderUtilized) It cannot be expressed in an OWL 2 EL/QL ontology, due to the disjunction. However, it can be expressed with unions of conjunctive queries and thus be used in these situation descriptions. 2.2
To recognize critical situations, we apply either answering of concept or of (unions of) conjunctive queries. For the former, the situations need to be specied as concepts, while for the latter, as (unions of) conjunctive queries. Example 2. Consider a situation apt for switching between transcoder implementations with two di erent speci cations: one needs a medium CPU frequency and the other requires a high CPU frequency. Both implementations must be hosted on the same machine. The server has to have a high CPU frequency while its load average is low and anticipated to stay so. The resulting query concept is displayed in Figure 1 in the upper half as the concept SwitchTranscoderSituationAnticipatory and the corresponding conjunctive query qSwitchTranscoderSituationAnticipatory in the lower half of the gure. In Figure 1, a situation that generalizes the above one is characterized in the query qSwitchTranscoderSituation. In this situation the average load trend cannot be forecasted; apart from that, the situations are the same. Clearly, this situation is re ned by the rst one. It is fruitful to model such re nements of situations in order to allow for graceful handling of incomplete information. Assume that, for a particular moment in time, it cannot be determined that the load average will show some constant development in the next intervals. Then, a corresponding assertion is not generated, and the next ABox is incomplete. In such a case, a situation indicating that a change of a transcoder implementation is bene cial cannot be recognized. More precisely, the concept
ABox and the query qSwitchTranscoderSituationAnticipatory yields no tuples. However, a more general concept SwitchTranscoderSituation would have an instance and the query qSwitchTranscoderSituation would yield a result tuple. Thus, this kind of situation could be recognized, and it could be decided (e.g., by using other context information) whether a recon guration should take place. SwitchTranscoderAnticipatorySituation =
TranscoderComponent u 9requires:MedCPUFreq u 9isHostedBy:(UnderUtilizedServer u 9hosts:(TranscoderComponent u 9requires:HighCPUFreq) u 9hasLoadAvgTrend:DecreasingLAT u 9hasCPUFrequency:HighCPUFreq) qSwitchTranscoderAnticipatorySituation = 9x; y:TranscoderComponent(x) ^ requires(x; z1) ^ MedCPUFreq(z1) ^ isHostedBy(x; z2) ^ UnderUtilizedServer(z2) ^ hosts(z2; y) ^ TranscoderComponent(y) ^ requires(y; z3) ^ HighCPUFreq(z3) ^ hasCPUFrequency(z2; z4) ^ HighCPUFreq(z4) ^ hasLoadAvgTrend(z2; z5) ^ DecreasingLAT(z5) qSwitchTranscoderSituation = 9x; y:TranscoderComponent(x) ^ requires(x; z1) ^ MedCPUFreq(z1) ^ isHostedBy(x; z2) ^ UnderUtilizedServer(z2) ^ hosts(z2; y) ^ TranscoderComponent(y) ^ requires(y; z3) ^ HighCPUFreq(z3) ^ hasCPUFrequency(z2; z4) ^ HighCPUFreq(z4)
Although our modeling is in large parts rather abstract, it captures the nature of component systems. We conjecture that the ontology grows primarily in size rather than in complexity, in case real applications are considered. Also, the modeling should be similar for component systems in other domains, since the focus is generally on modeling the components with their contracts and the topological structure of the system's hardware environment. 3
The goal of our evaluation is to see whether current OWL 2 reasoners are yet appropriate for situation recognition to initiate system recon guration for selfadaptive software. However, to adopt DL reasoning for this kind of scenario, the reasoners have to be able to detect situations by processing realistic amounts of data within short time. We consider OWL 2 and the two pro les OWL 2 EL and OWL 2 QL in our evaluation. Since the syntactic restrictions of the lightweight pro les allow only for coarser modeling than full OWL 2, some information cannot be modeled. An interesting question is whether this leads to missing inferences in our scenario. 3.1
Test TBoxes. Our base TBox from Section 2.1 contains about 200 concepts and 40 roles and uses ALCI, a sub-logic of OWL 2. For both lightweight pro les, we built variations of the base TBox manually|keeping as much information as possible. Test ABoxes. The ABoxes model a modular video platform running on four servers and providing the services described in Section 2. Since the concept assertions use only named concepts, the ABoxes do not vary for the pro les.
We consider two di erent ABoxes modeling two di erent states of the system. In order to re ect realistic scenarios, the test ABoxes do not only contain information about the situations to be detected, but model the overall system state. For example, we modeled other users requesting video services. This roughly doubles the sizes of both ABoxes. Each of the test ABoxes contains about 450 individuals, 485 concept, and 350 role assertions.
Test Queries. We modeled 9 critical situations to be recognized as OWL 2 concepts. For OWL 2 EL, these concept de nitions had to be only slightly adapted. In particular, we removed the disjunction by replacing it with adequate new concepts and corresponding inheritance relations.
Since the OWL 2 QL pro le does not support truly complex concept descriptions, the situations cannot be modeled as concepts; but they can be captured with conjunctive queries. Therefore, we only evaluate conjunctive query answering for the QL pro le.
Note that for modeling the modular video platform and situations for recon guration, we do not need universal quanti cation. For the 9 situations, we formulated corresponding conjunctive queries for our test suite. The concept queries have a size of about 10{counting the concept and role names. The conjunctive queries are formulated in the query languages SPARQL and nrql. They contain 15 conjuncts on average.1 Reasoning Systems. The tests were run for seven DL reasoners, which di er w.r.t. the DL they support and the reasoning services they provide. Table 1 depicts the tested reasoners, the used version, and the closest DL of the respective pro le they implement (`x' stands for full coverage).
Next to the tableaux-based reasoners for expressive DLs in the rst group of Table 1, we tested reasoners specialized on lightweight pro les, which are listed in the second and third group of the table. Quest can be used for ontology-based 1 Our complete test data is available from http://lat.inf.tu-dresden.de/~thost/download/exp_data_owled13.zip Concept queries
Conjunctive queries
Load. Reason. Avg/Q. Total Load. Reason. Avg/Q. Total data access (i.e., a data base functions as ABox and can be queried directly). However, we used Quest with classical ABoxes, here. 3.2
The tests were carried out on an Intel Core 2 Duo workstation with 2 GB RAM using Java 1.6.0. on Ubuntu. Besides recording the mere runtimes, we checked whether the reasoners delivered the same results for a query. For our concept queries, all reasoners agreed on the result individuals. For the conjunctive queries, we noticed that Pellet did not compute the expected answer sets. On the one hand, it did not deliver all answer tuples for 8 queries while reasoning in OWL 2 QL. On the other, it returned too many result tuples for one query in OWL 2 EL. The other reasoners delivered the expected answers. This nicely demonstrates that the lightweight pro les su ce for modeling and reasoning about our modular video platform|and thus about the hard- and software of complex systems, in general.
Performance for Concept Queries. For concept queries, we ran tests for full OWL 2 and the OWL 2 EL pro le. We used the OWL API (version 3.4.1) to access the reasoners. The results are displayed in the left half of Table 2 sorted by pro les. The rst column depicts the time spent on loading the ontology. The next one displays the time for answering all the concept queries. The average runtime per query is displayed next. The last column contains the runtime for the overall process and thus is the most interesting for our application of situation recognition. As expected, it shows that the overall runtime is higher for OWL 2 than for the OWL 2 EL pro le, especially for FaCT++ and Pellet. Nevertheless, the gain when using OWL 2 EL is not big. Interestingly, RacerPro performs slightly better for OWL. OWL 2: Apart from RacerPro, which took about 2 seconds, all reasoners delivered a full situation recognition within roughly 1 second.
OWL 2 EL: With an overall runtime of about 0.25 seconds, ELK and FaCT++ outperform the other systems. For these systems the overall runtime is dominated by the time for loading the ontology. HermiT and jCel can still test for occurrence of a critical situation within half a second. All systems can perform situation recognition within about 2 seconds.
results for all of the three pro les are displayed in right half of Table 2. As for answering concept queries, reasoning in the lightweight pro les is a little faster. OWL 2: Here, RacerPro needs about 2 seconds overall runtime. It thus takes about the same time as for the concept queries. Note that its reasoning time for the conjunctive queries is lower than for concept queries, but the loading of the same ontology takes more than twice using the RacerPro's interface for conjunctive querying.
OWL 2 EL: Pellet and RacerPro answer all queries in less than 2 seconds. However, Pellet didn't deliver the correct result, whereas RacerPro did. OWL 2 QL: RacerPro performs even slightly better for this pro le. While Pellet performs worse than in the OWL 2 EL case giving an incomplete answer. By taking 6 seconds, Quest shows a signi cantly worse performance. We conjecture that this is attributed to running a rst alpha version of Quest and using a traditional ABox instead of a database, for which it has been designed for.
All in all, the experiments show that most state of the art reasoners can be applied for situation recognition in our component-based video platform, since response times of 1 to 2 seconds are acceptable if one considers the long time video services such as transcoding usually run. Especially by the use of the lightweight pro les, we achieve very good runtimes for reasoning. Our study revealed two surprising e ects. First, comparing the runtimes for concept query answering and conjunctive query answering, it showed that the run times do not di er largely, which wasn't to be expected. Second, the loss of information when using a lightweight pro le turned out to be only marginal for our video platform use case, and, more importantly, it did not in uence the completeness of the results|apart those of Pellet. 4
We have supplied a study on employing OWL 2 and DL reasoners to perform situation recognition for runtime variability management applied to a video platform. To the end of automatically recognizing complex situations that might invoke the switching of software variants in order to achieve energy e ciency, the domain was modeled in an OWL 2 ontology. In this ontology the ABox reected realistic situations in the application. The actual recognition of critical situations, was realized by concept query answering or conjunctive query answering. Our experiments w.r.t. the di erent OWL 2 pro les gave evidence that the performance of today's DL systems is su cient to detect complex situations fast enough. In particular, for the OWL 2 EL and the OWL 2 QL pro le it can be done within 2 seconds for each of the inferences employed. Thus, there still seems to be room for growth|considering larger ontologies in practice.
Future work on the practical side should evaluate whether the gain of reasoning time given by the lightweight pro les grows, too, with larger ontologies. Clearly, it would be interesting to run Quest in the ODBA mode and to realize the whole situation recognition more tightly coupled to a DB, such that the data collected there can be queried directly, instead of generating and loading an ABox. Further, the actual energy gain should be considered. On the theoretical side, we would like to lift the limitation of OWL regarding the modeling of fuzzy or even temporal information by investigating query answering for sequences of ABoxes, which contain this kind of information.