Improving the energy e ciency of software systems requires runtime adjustments and explicit knowledge about the system's variability. Component-based software has inherent variability in terms of multiple implementations for components. These implementations utilize hardware resources, which are direct energy consumers, leading to a further dimension of variability: the mapping of implementations to resources. The performance modes of hardware resources span a third dimension of variability. Hence, to realize energy-e cient software systems the central question is: which implementations should run on and utilize which resources in which performance mode to serve the user's demands? This question can only be answered at runtime, as it relies on the runtime state of the system. In this paper, we show how combined hard- and software models can be utilized at runtime to determine valid system con gurations and to identify the optimal one.
Component-Based Software Development (CBSD) [
As models comprising only few components, can already describe di erent
component implementations and deployment locations (e.g., servers), they span
a solution space that describes all possible con gurations of modeled software
systems on modeled hardware landscapes. The problem we address in this
paper is, how to select the most appropriate con guration from this solution space
speci ed by models w.r.t. minimum energy consumption at runtime. Thus, we
rst have to compute all con gurations that are valid (i.e., which ful ll
requirements of involved components such as dependencies, required resources and
provided qualities). Second, we have to select the variant requiring the minimum
energy consumption whilst still serving the user's non-functional requirements.
We use contracts to model quality dependencies between components and call
the determination of the optimal con guration contract negotiation, following
the de nition of Quality-of-Service-level contracts by Beugnard et al. [
The process of contract negotiation has to take place at runtime, which imposes the need to utilize our aforementioned models at runtime, too. E.g., the available hardware infrastructure is represented by a model describing each existing resource along with its properties. This model changes over time, e.g., due to failing or added resources. The same holds for our software models, which need to be kept up to date, e.g., due to added components. The runtime data represented by these models is collected by resource or energy managers. Both processes, hence, work on runtime models.
The remainder of this paper is structured as follows: We introduce the Cool Component Model (CCM) which is the basis for our CBSD architecture in Sect. 2 using a simple video server example. Furthermore, we present the Energy Contract Language (ECL), that describes provided and required qualities of software and hardware components. We describe our contract negotiation approach in Sect. 3. Afterwards, in Sect. 4 we present and demarcate from related work. Finally, in Sect. 5 we discuss future work and conclude this paper. 2
To capture EAT systems, we developed the energy-aware component model CCM and the contract language ECL. The CCM provides concepts to model hierarchical system architectures and covers both software components and hardware resources, because software consumes energy only in an indirect manner (i.e.,
getStream loadData
dataRate : MB/s
non-functional properties provided port required port
dataRate : MB/s
URL playVideo Legend:
framerate : fps VLC
QT the energy is consumed by physical resources which are utilized by the software). ECL provides concepts to express dependencies between CCM components based on non-functional properties. This implies dependencies between software components as well as software and hardware components. In this section we introduce CCM and ECL, by means of a video application scenario. In Sect. 3 we use the scenario to explain our contract negotiation approach. The CCM distinguishes between modeling of the system structure of hardware resources, software components and variants of both. In our project's scope, variants are concrete hardware resources as well as software component implementations. The system structure de nes how a system may look like and, thus, represents type declarations for speci c variants. For instance, consider the upper part of Figure 1 that shows the types of a video application. It consists of several software component types, namely a VideoPlayer, a Decoder and a DataProvider3. Each type may have one or more port types representing an interface of the component. Port types can be used to connect di erent components. A set of connected components describes the software part of a system.
Concrete implementations (i.e., variants) of a software component (shown in the lower part of Figure 1) have to correspond to the component's type. In our example there are two variants of the type Player, the VLC and Quicktime (QT) implementation. For the Decoder type a free (Free) and a commercial (Com.) implementation are available. Finally, the DataProvider is implemented as a local le reader (File) and a remote URL reader (URL).
To capture types available in the hardware landscape, resource types have to be speci ed. Figure 2(a) de nes resource types of a hardware landscape on which our video application shall be executed. The Infrastructure consists of one or more Servers, whereas each server contains one or more CPUs, network interfaces (Net), RAM chips and hard disks (HDD). For reasons of simplicity, we omit port types of resource types in the given example.
For each component type (software and hardware) non-functional properties can be de ned. For instance, the software component type Player de nes a 3 We denote component types using typewriter and variants of them using italic font.
CPU frequency : GHz performance : GFLOPS cpuLoad : percent 1..*
Net bandwidth : Mb/s
CPU_S1 : CPU frequency = 3 GHz performance = 45 GFLOPS
RAM_S1 : RAM free = 402 MB used = 110 MB total = 512 MB throughput = 3 GB/s
Server 1 : Server
Net_S1 : Net bandwidth = 100 Mb/s
HDD_S1 : HDD free = 170 GB used = 150 GB total = 320 GB throughput = 20 MB/s 1..*
RAM free : MB = total – used used : MB total : MB throughput : GB/s 1..*
HDD free : GB = total – used used : GB total : GB throughput : MB/s 1..* 1..*
Server 2 : Server
Net_S2 : Net CPU_S2 : CPU bandwidth = 54 Mb/s frequency = 1,5 GHz
performance = 24 GFLOPS
RAM_S2 : RAM free = 1500 MB used = 512 MB total = 2048 MB throughput = 4 GB/s
HDD_S2 : HDD free = 170 GB used = 150 GB total = 320 GB throughput = 20 MB/s (a) CCM Structure Model for Hardware Landscapes. (b) CCM Variant Model of a Hardware Landscape Comprised of 2 Servers. property framerate in frames per second (fps) whereas the resource type HDD de nes a property used (disk space) in GB. Such properties play an important role for specifying ECL contracts and are the basis for contract negotiation.
Figure 2(b) shows a concrete hardware landscape of the resource type system
mentioned above. It consists of two servers with speci c resources according to
the de nitions at the type level. The servers are connected by their network
devices as depicted by the solid line between Net S1 and Net S2. Consider that
properties de ned at type level are available at variant level with concrete values.
Furthermore, each hardware resource variant has to provide a behavior model
that de nes its energy consumption w.r.t. its utilization. These behavior models
have to be provided as templates for each resource type and are instantiated for
each concrete resource using the values determined by our resource managers
at installation time (i.e., the rst time the resource is registered at the runtime
environment). We derive the implied energy consumption for a given system
con guration (i.e., the distribution of SW components in the infrastructure)
and user request by simulating these models. Since the energy consumption
computation is not part of contract negotiation, these details are omitted here.
The general idea is described in [
Notably, variant models are not de ned by the developer, but generated at runtime by our Three Layer Energy Auto Tuning Runtime Environment (THEATRE) in accordance to the structural models for HW and SW. THEATRE consists of three layers: the user-, software- and resource layer. Each layer is controlled by a global manager; the Global User Manager (GUM), Global Energy Manager (GEM) and Global Resource Manager (GRM). The GEM has the central role of retrieving information from the GUM and GRM to initiate the process of contract negotiation and, based on the result, to perform a system recon guration. The GUM knows about the details of user requests and associated non-functional requirements of the respective users. Finally, the GRM knows the details about the currently available hardware by monitoring it. These managers generate the respective variant models and keep them up-to-date. Distributed servers are handled by local managers for each layer. E.g., in a 2-server scenario, the rst server takes the lead by hosting the global managers, whereas the second server hosts local managers only. Each server, which is part of the system, runs a Local Resource Manager, which registers the server and all its resources at the GRM and sends noti cations whenever a property (i.e., the frequency of a CPU) changes. It is important to note that we include subsymbolic information into our variant models (i.e., concrete numbers) and postpone symbolization until contract negotiation. The information required to derive symbols from the values of non-functional properties is encapsulated in our contracts, which are described in the following subsection. 2.2
Speci cation of ECL Contracts ECL is used to de ne dependencies between CCM components using contracts, which are speci ed for each variant. Therefore, an ECL contract represents a speci c view of a variant regarding its dependencies to other types. A contract may de ne one or more modes, whereas each mode de nes dependencies to other components. Software components can depend on other software components as well as hardware resources, whereas hardware resources can depend on other hardware resources only. Each dependency relates to a component type and de nes bounds for required values of properties at runtime. In addition to constraints expressing required properties, provided properties are speci ed as well.
Listing 1 shows a contract for the VLC video player as a concrete implementation of the VideoPlayer component. It de nes that the player can be used in two modes: high- and lowQuality. For highQuality the contract speci es that a CPU and a Net device are required. The CPU needs to be utilized at most to 50% and needs to have a frequency of 2 GHz at least.4 The Net device has to o er at least a 10 MBit/s bandwidth. Furthermore, a Decoder component is required. Any implementation of that software component type, which is able to provide a data rate of at least 50 KB/s can be used. Finally, the contract de nes that in the highQuality mode a minimum framerate of 25 fps and a resolution of 1024x768 pixels is provided. To determine the hardware requirements, micro-benchmarks written by the component developer, which address the nonfunctional properties of interest, are used. As each software component variant is de ned by one contract, there exist six contracts specifying SW/HW dependencies in total. The remaining contracts not shown in Listing 1 are similarly structured. 4 To ease comprehensibility, we use frequency instead of a performance property measured in instructions per second. } //what is provided in turn provides min frameRate 25 Frame/s provides min imageWidth 1024 Pixel provides min imageHeight 768 Pixel } //dependencies on other SW components requires component Decoder { min dataRate = 50 KB/s
Listing 1. Example Contract for VLC Video Player. 1 contract StandardRAM implements resource RAM { 2 mode low { 3 provides max free: 0.1*total MB 4 } 5 ... 6 }
Listing 2. Example Contract for Memory Resource.
In addition to contracts for software components, we allow to de ne contracts for resources, too. Such contracts suitably illustrate, that the modes of contracts are symbols, which are derived from the resources' properties. E.g., a contract for the resource RAM could de ne the modes HIGH, MEDIUM and LOW as indicated in Listing 2.
In summary, a system modeled with CCM and ECL is highly variable in terms of multiple implementations of component types, multiple quality modes of each implementation and, according to resource requirements of each quality mode, multiple possible mappings of implementations to hardware resources. 3
There are three di erent kinds of variability captured by CCM/ECL. First, multiple implementations may exist for each software component type. Second, in an IT infrastructure with more than one server, variability exists in the decision on how to distribute the software components on this IT infrastructure. Finally, the di erent quality modes speci ed in ECL denote the third kind of variability. To utilize this variability at runtime for increasing energy e ciency, an approach to determine the optimal system con guration in this regard is required.
This determination can be seen as a special kind of constraint solving optimization problem (CSOP). The goal is to identify the con guration, which implies the lowest energy consumption whilst still serving the user's request and demands. Thus, resource employment (cost) has to be negotiated against the gained utility, where the connection between cost and utility can be expressed as constraints. Hence, constraint programming in general can be applied to solve the CSOP. Because our particular problem is a tradeo negotiation, expressible using linear constraints, we can use linear programming, which allows the employment of more e cient solving algorithms. To express mappings of components to resources, we need to constrain the domain of this kind of variables to be of Boolean type, i.e., only the integer values 0 and 1 are permitted. Thus, our problem can be classi ed as a mixed integer linear program (MILP).
An ILP consists of an objective function, a set of constraints and variables
being used in both [
Our ILP comprises four kinds of variables. Variables expressing resource usage are the rst kind, e.g., usage#Server1#RAMS1#size. This variable denotes the size used of the main memory on Server 1. The second kind of variable expresses the mapping selection. E.g., b#F reeDecoder#f ast#Server2 denotes whether or not the FreeDecoder implementation in fast mode has to be mapped to Server 2 (the initial b is meant to indicate that this variable is of Boolean type). Software-related properties, like f ramerate, form the third kind of variable. Finally, the server baseload consumption forms the forth kind of variable.
The objective function of our ILP is shown in Equation 1. The goal is to minimize the sum of all resource usage variables and the server baseload consumption. The resource usage variables are normalized by a respective factor, which translates resource usage into power consumption and is determined by our resource managers the rst time a resource registers at the system. min X (f actorxyz usage#serverx#resourcey#propertyz) + (1) X baseload#serveri
The constraints of the ILP can be divided into four classes: (i) selection criterias, (ii) resource usage and server baseload, (iii) implied values for nonfunctional properties and (iv) user demands. The rst class corresponds to the information present in the structural model, that is, which (and how many) components are required. In our example, one implementation of each software component is required. The requirement, that exactly one implementation of a component type t has to be chosen, can be expressed by constraints of the following form.
usage#Server1#RAMs1#size <= 512:0; usage#Server1#RAMs1#size >= 0:0; X (b#implx;t#modey#serverz) = 1:0; x;y;z
The second class of constraints describes the boundaries of resource usage variables and how they correlate to the mapping of implementations to resources. For each resource usage variable a constraint for the upper bound (3) and the lower bound (4) is introduced. The values for these boundaries are extracted from the hardware variant model.
The baseload of servers (determined by the local resource managers) is reected by constraints for each mapping variable as depicted in Equation 5.
baseload#serveri = b#implx#modey#serveri
The impact of mapping an implementation to a resource can be extracted from ECL contracts and can be represented in constraints like exemplary depicted in Equation 6. Here, e.g., the rst addend of the sum, states that the FreeDecoder implementation requires 512 MB of RAM to operate in fast mode. The same statement holds for any other server, but the example equation refers to RAM usage of Server 1 only.
usage#Server1#RAMs1#size = 512:0 b#F reeDecoder#f ast#Server1 + 256:0 b#F reeDecoder#slow#Server1 + 128:0 b#CommercialDecoder#slow#Server1 + 512:0 b#CommercialDecoder#f ast#Server1 + 1536:0 b#CommercialDecoder#ultraf ast#Server1
The same principle is applied for software-related non-functional properties, which are the third class of constraints as shown exemplary in Equation 7. It states, among others, that the throughput will be ve bit per second, if the URLReader is mapped to Server 1 and con gured to run in URL mode. (2) (3) (4) (5) (6) throughput = 5:0 b#U RLReader#url#Server1 + 20:0 b#F ileReader#f ile#Server2 + 5:0 b#U RLReader#url#Server2 + 20:0 b#F ileReader#f ile#Server1 (7) (8)
Finally, the user demands have to be integrated as a constraint, too. Such a user request, like playing a video with a framerate of at least 20 frames per second, can be integrated as a constraint in a straightforward way: f ramerate >= 20:0;
The ILP as a whole is generated at runtime, whereby the required information is extracted from the runtime model of the current hardware infrastructure and software con guration (software variant model), as well as from the ECL contracts. To solve the ILP a variety of free-to-use solvers exists. For our prototype we have chosen LP Solve 5.55|one of the mature, stable solvers. LP Solve allows to solve linear programs (LP), too.
The key di erence between LP and ILP is that an ILP restricts its variables to be integers instead of oating reals. In our scenario we need oating reals for the resource usage and property variables, but integers for our mapping selection variables. In consequence, the ILP presented above is a mixed integer linear program (MILP). The need for the integer restriction can be easily illustrated: if the variables b#V LC#highQuality#Server1 and b#V LC#highQuality#Server2 are allowed to be oating reals the LP's solution could be, to map 33% of the VLC to Server 1 and the remaining 67% to Server 2, which is obviously not possible.
The most commonly used algorithm to solve a MILP is the simplex
algorithm [
The solution of the example introduced throughout the paper is that the VLC implementation should run in highQuality mode on Server 1, the CommercialDecoder should run in slow mode on Server 2 and the URLReader in URL mode on Server 1. The Decoder implementation is mapped to Server 2 instead of Server 1, due to the CPU performance requirements. If all implementations run on Server 1, the resulting energy consumption will be lower, but the framerate of at least 20 fps cannot be ensured. Furthermore, the solution of the ILP tells us amongst other details, that we need the CPU of Server 1 to operate at 1.5GHz and the CPU of Server 2 at 800 MHz. Thus, we could force the CPUs 5 http://lpsolve.sourceforge.net/5.5/ to operate slower than usual by exploiting the application knowledge in terms of the ILP to save energy whilst ensuring the requested user utility.
Notably, if a new server, with a more powerful CPU, is added to the infrastructure, the ILPs solution is to map all three implementations to that new server, which requires a system recon guration: all implementations have to be migrated from Server 1 or 2 to Server 3. In general, changes in the infrastructure as well as to (the available) component implementations are propagated to our variant models at runtime, which are then used to generate an ILP to derive the optimal system con guration. Finally, the system has to perform a recon guration, which is a sequence of migration steps. 4
Within the research project COMQUAD, a component model was developed that
separated components into their speci cations and implementations [
During the research project SPEEDS and its successor CESAR, the HRC
metamodel [
In the MADAM research project and its successor MUSIC, a component
model for self-adaptive applications on mobile devices has been developed [
The DIVA research project focused on the management of dynamic
adaptive systems with special focus on the problem of exponential growth of
potential system con gurations by combining methods from aspect-oriented
programming/modeling [
In this paper we introduced our contract negotiation approach, which allows to identify the most energy-e cient mapping of software component implementations to resources serving a user's request and demands.
We showed how to formulate this optimization problem as an integer linear program (ILP) and presented a mechanism using models at runtime to generate the ILPs in accordance to the current hard- and software as well as the current users requests and demands. This allows to optimize even dynamic systems, whose hard- and software entities can supervene, disappear or change over time.
Our approach allows for runtime subsymbolic reasoning, which demarcates us from existing approaches. Notably, energy e ciency is just one quality which bene ts from subsymbolic reasoning. E.g., optimizations in systems integrating the physical and virtual world (like robot swarms) require the support for oating point numbers, too.
In the future we plan to improve the approach to consider more complex relations between resource usage and energy consumption and will evaluate our approach in a real world scenario. Furthermore, we plan to investigate how our approach can be applied to systems integrating the physical and virtual world. Acknowledgement This research has been funded by the European Social Fund and Federal State of Saxony within the project ZESSY #080951806, by the Federal Ministry of Education and Research within the project CoolSoftware #FKZ13N10782, part of the LeadingEdge Cluster "Cool Silicon" within the scope of its Leading-Edge Cluster Competition and by the collaborative research center 912 (HAEC), funded by the DFG.