## 1. Introduction

Component frameworks enable the construction of systems from a set of loosely coupled, independent components through composition mechanisms. A component framework emphasizes abstraction, separation of concerns and reuse. It has inherently loose coupling between components, and explicit and visible dependencies. This eases, for instance, dynamic reconfiguration and thereby adaptability. Component-based models of computation can be classified into component models and interface models

[1]. A component model specifies how a component behaves in an arbitrary environment. An interface model specifies how a component can be used, e.g., for composition, and restricts the environment: it makes input assumptions and provides output guarantees for the case when the input assumptions are met by the environment. We present an interface model for (dynamic) quality and resource management of component-based systems. Each component in our framework has one or more*configurations*that may be parameterized. A configuration has an

*input*, an

*output*, a

*required budget*, a

*provided budget*, and a

*quality*. Parameters capture the configurable working points of the component. External actors, the user or a quality and resource manager for instance, can use the parameters to partially control configuration of components for, e.g., dynamic reconfiguration of the system. The input and output model the functionality of a particular configuration of the component. For instance, a component configuration can have a video stream as input, and for each frame a set of image features as output. The types of extracted features may be adjustable via the parameters. The required and provided budgets model the services that a component configuration provides or requires. A component configuration may, for instance, offer, or conversely, require, a volatile storage capacity of 64 MB. Finally, the quality of a component configuration refers to the properties that we want to optimize, for instance, latency, throughput, energy consumption, cost. These five parts and the parameters form a

*quality and resource management interface*that can be used for dynamic reconfiguration of the system to ensure functionality and a certain quality of service. We use concepts from the Pareto algebra framework [2] to mathematically define our components and their composition.

Related work: Design based on components is a well-known approach to tackle the increasing complexity of today’s systems. The general idea is to use pre-defined components with well-specified behaviors and interfaces as interoperable building blocks. These components can be composed to create larger components with more complex functionality. Well-known component models in the software domain are the Component Object Model (COM) [3], the Common Object Request Broker Architecture (CORBA) [4], JavaBeans [5], and Open Services Gateway Initiative (OSGi) [6]. These are all generally applicable and do not depend on the application domain. An example of a more specialized software component model is the KOALA framework [7]. It is aimed at the software development of a product family of high-end television sets, with an emphasis on dealing with variability. Platforms that aim at predictability and composability are, for instance, the CompSOC platform [8] and PRET machines [9]. CompSOC aims to reduce system complexity through composability of applications and through (timing) predictability. PRET machines also focus on providing solid timing predictability for processors thereby making the timing of the composition of programs predictable. Examples of component frameworks with tool support for cyber-physical systems are the Behavior Interaction Priorities (BIP) framework [10] and the Ptolemy framework [11]. Other conceptual component models are, for instance, the I/O automata [12] and timed I/O automata [13] frameworks, which provide formal notions of components, composition, and abstraction.

Interface models for components have been introduced by [1]. An interface model of a component specifies what the component expects of the environment and what it can provide. This supports compositional refinement and therefore component-based design. Using this principle, interface automata capture temporal assumptions about how a component is used and how it uses other components [14]. The authors of, e.g., [15, 16, 17, 18] use interface-based design concepts for real-time aspects of systems. Contract-based design, e.g., [19, 20], uses similar ideas. It specifies contracts of components as a combination of assumptions that the component makes about the environment and the guarantees that it then can give.

All work mentioned above has the scope of software development or system design. In contrast, we position our work in the scope of system operation with quality and resource management as focus. In [21], a middleware solution is presented that builds on a general-purpose component model. The middleware supports dynamic reconfiguration of components based on their quality-of-service demands. The quality-of-service parameters are fixed to period, deadline and priority, and each deployed component has a known worst-case execution time. The view presented in [21] of components as sets of instances, each with its own quality-of-service parameters is similar to our view. A runtime resource manager based on OpenCL is introduced in [22]. An extended compiler generates OpenCL kernels of the same code for various computational resources (CPU, GPU, FPGA, etc.) including resource-usage information. The runtime resource manager uses this to dynamically adapt the system if needed. The authors of [23] informally introduce a component framework for quality-of-service management. They distinguish functional requirements, e.g., the required input format of a video-processing component, from resource requirements, e.g., the amount of memory needed. This is similar to our view in which we also make this distinction explicit. Finally, [24] presents a resource-management framework to create and manage multi-processor partitions at runtime, which provides a high level of (timing) predictability. The resource model is a simple instance of our model.

Contribution:
Our framework uses partially-ordered sets as the interface model of components and defines composition in terms of operations from the Pareto algebra [2].
We show that the framework supports a notion of refinement called *dominance*.
This natively supports domain-independent quality and resource management by a formal semantics and compositional multi-objective optimization.
Our work is on a formal, conceptual level and this distinguishes it from existing component-based approaches within the quality and resource management scope, e.g., [21, 22, 23], as these are concretely tailored to some domain or lack a formal semantics. The generality of our approach enables application to many domains, but requires further specialization before it can be applied.

Outline: We use a motivating example of a video-processing system from the healthcare domain throughout this paper. This example is introduced in Sec. 2. Section 3 summarizes the main results from [2] that form the foundation of our interface model for quality and resource management. In Sec. 4 we introduce our interface model, and in Sec. 5 we define a generic pattern for composition, and basic operators that can be used for the composition. Sec. 6 describes three concrete and useful composition patterns that are based on composition operators for the underlying posets. Furthermore, it shows a full quality and resource management example. Finally, Sec. 7 concludes.

## 2. Motivating Example – Description

We consider a video-processing system from the healthcare domain. The system scales video streams in an operating theatre, for display on one or more displays. The system receives video streams with a certain resolution and rate. Examples of common resolutions are HD (1280x720 pixels), HD+ (1600x900 pixels) and FHD (1920x1080 pixels). We assume that a pixel is encoded with four bytes. The platform of the system consists of fiber links, to transport streams from their sources to processing resources, and hardware scalers that perform the processing. Each fiber has a capacity of 10 Gb/s. A single FHD stream at 60 Hz takes approximately 4 Gb/s, so a fiber can transport at most two such streams. A scaler can downscale a stream to a given output resolution. Each scaler can process up to 300 Mpixels/s, and it can handle up to four streams. Depending on the resolution of a stream, a scaler requires a certain amount of memory to buffer a single horizontal line of that stream. Each scaler has access to only a limited amount of memory that thus must be shared by the streams that are mapped to that scaler. This memory is split into 32 segments of 128 pixels each. A scaler can reduce the frame rate of the outgoing stream to reduce its computational requirements. For instance, if a scaler does not have enough computational resources to process an incoming FHD stream at 60 Hz, then it can reduce the outgoing rate from 60 to 30 Hz by just dropping half of the incoming video frames. This reduces the video quality at the benefit of being able to process more streams. The end user can also prioritize streams. The task of the quality and resource manager of this system is to map streams to scalers while respecting the resource constraints, and at the same time optimizing the frame rate of the outgoing streams given the end-user’s priority. Dynamic reconfiguration takes place when streams are added or removed, or when the end user changes output resolutions or priorities.

Figure 1 shows an overview of the components in the system.
Each stream in the system is modeled as an *application* that consists of a Transport component and a Scaler component.
The Transport component has video both as input and output and requires connection bandwidth that is determined by the rate and resolution of the video that is transported. This is a parameter of the Transport component that is set at runtime to match the transport configuration to the actual incoming stream.
Video is modeled as a horizontal resolution in pixels, a vertical resolution in pixels and a rate in Hz, each being a natural number. The connection bandwidth is the number of bits per second, again a natural number.
The Scaler component also has video as input and output, and requires a scaling budget, which consists of computational capacity (Mpixels per second) and memory requirements (a number of 128 pixel segments for line buffering).
The parameters of the Scaler specify working points for the resolution of the resulting video stream, and these can be set from the outside by, e.g., the end user or some application using the video system.
The computational budget needed by the Scaler is determined by the input video resolution and the output video resolution and rate.
The quality aspect of the Scaler is the frame rate of the outgoing video stream.

To have a feasible composition, the output of the Transport needs to *match* the input of the Scaler. We use partial-order relations to model this i/o matching, and also for the budget matching, i.e., matching a required budget with a provided budget.
For instance, the relation could be used for *video*, as the Scaler can only guarantee its correct functioning if it exactly knows the input resolutions and rate.
For connection bandwidth, for instance, we can use the relation, as the transportation of a certain video can be guaranteed also when more bandwidth is given to the Transport component than strictly needed.

A Scaler component typically has multiple *configurations* which the end user or the quality and resource manager can partially select through the parameters of the component.
A Transport component also has multiple configurations, where the specific configuration is determined by the environment since the type of the incoming stream is uncontrollable.
For instance, suppose that we need to scale a 60 Hz FHD stream.
(We abbreviate video-related types; for instance, we write FHD@60 for .)
Then we have a Transport component with a configuration that requires a connection-bandwidth budget of Gb/s, with a FHD@60 input and output video.
The Scaler component has parameterized configurations. One configuration associated with output-resolution parameter HD has FHD@60 video input and HD@60 video output, requires a scaling budget of , and has frame rate as quality.
Another configuration, also associated with output-resolution parameter HD, has FHD@60 video input and HD@30 video output, requires a scaling budget of , and has frame rate as quality.
A third configuration with parameter HD has FHD@60 video input and HD@20 video output with scaling budget , and quality . The latter two configurations trade quality for a smaller required budget.

The resource needs of an application, i.e., a Transport and Scaler pair in this example, are specified via a required private *virtual execution platform* (VEP) that abstracts from the underlying execution platform (for instance, real-time operating system and hardware). A VEP for our stream application consists of a Connection component that provides a connection bandwidth, and a Virtual Scaler component that provides scaling.
The underlying hardware forms the *execution platform*, and consists of Fiber components (only one is shown), and HW scaler components (only one is shown).
A single Fiber provides bandwidth in Gb/s, which is modeled as a natural number.
Each Scaler provides a budget consisting of three parts: (i) the number of streams that can still be processed by this Scaler (limited to four), (ii) the free amount of memory (at most 32 segments), and (iii) the remaining computational power (at most 300 Mpixels/s), captured by the tuple .

Again, suppose that a 60 Hz FHD stream needs to be scaled. The Transport component requires a connection bandwidth budget of Gb/s, so a Connection component is used that provides this budget. To realize this, it requires a bandwidth budget of Gb/s from some Fiber component. The remaining Gb/s of that Fiber is available for other VEPs. In the same way, the required and provided budget of the Virtual scaler component can be calculated from the Scaler component (for a specific configuration of the Scaler component). A Virtual scaler component can be composed with any HW scaler component with matching budget.

In general, composition may lead to configurations that are not interesting because other configurations perform better in all aspects.
Consider, for instance, two 60 Hz FHD streams that need to be scaled to HD. There are many possibilities to compose these with the hardware platform. A naive way is to compose both streams with a single HW scaler. This can be done if the output rate is set to 30 Hz.
Another way is to compose each stream with its own Fiber and HW scaler. In that case, the output rates can be 60 Hz.
The first option is *dominated* by the second option if the used and remaining platform resources are not important.
Such a dominated combination can be ignored for further analysis and composition. That is, only the *Pareto-optimal* component combinations need to be considered.

The quality and resource management problem for this system is the following. Given a number of incoming video streams (applications) and given the required output resolution of each video stream (parameters), find mappings of these streams on a platform consisting of a number of Fibers and a number of HW scalers such that the output rates (qualities) are optimized according to some user-defined cost function (e.g., maximize the minimum output rate among all streams). In the following sections, we introduce the mathematics that we need to solve this problem. The application of the theory is demonstrated in the last example of this paper, which shows a domain-specific solution for the quality and resource management problem of the video-processing system explained above.

## 3. Preliminaries – Pareto Algebra

This section briefly summarizes the results from Pareto algebra [2] that we need for our interface-modeling framework. A partially-ordered set (poset) is a set with a partial-order relation . In the remainder, we take shortcuts for readability and conciseness in the sense that we often write about a poset without mentioning the accompanying partial-order relation explicitly. Furthermore, we sometimes omit the subscript from when the ordering relation is clear from the context. The converse relation of is denoted by .

[Configuration Space] A configuration space is defined as the Cartesian product of a finite number of posets. A configuration is an element of a configuration space.

It is useful to have a notion whether a configuration is really better than another configuration.
This kind of information can help to choose between configurations in quality and resource management questions.
The notion of *dominance* on a configuration space serves this purpose.

[Dominance] Let be a configuration space, and let . We say that is dominated by , or equivalently, that dominates , denoted by if and only if for all .

Note that we reverse the interpretation of with respect to [2]. Observe that a configuration space with the dominance relation constructed from posets is itself again a poset. Hence, configuration spaces can serve as posets in other configuration spaces.

The notion of Pareto minimality expresses that a set of configurations only contains configurations that are relevant. This can be used to define the concepts of set dominance and Pareto equivalence of configuration sets.

[Pareto minimality] Let be a configuration space and let be a set of configurations. We say that is Pareto minimal if and only if for all .

[Set dominance] Let be a configuration space and let be sets of configurations. We say that dominates , denoted by , if and only if for every there is some such that .

[Pareto equivalence] Let be a configuration space and let . We say that is equivalent to , denoted by if and only if .

Pareto equivalence expresses the notion that neither of the sets have a configuration that cannot be at least matched by a configuration of the other set.
The following theorem states that every well-ordered^{1}^{1}1A poset is well ordered if every chain contains a smallest element. set of configurations has a unique minimal equivalent, which is often called the Pareto frontier in other contexts. As a corollary of this theorem, every finite set of configurations has such a unique minimal equivalent.

If is a set of configurations, and is well ordered, then there is a unique Pareto-minimal set of configurations such that .

If is a finite set of configurations, then there is a unique Pareto-minimal set of configurations such that .

[Minimization] Let be a configuration space, and let such that is well ordered. We let denote the unique Pareto-minimal and Pareto-equivalent set of configurations.

Minimization of a set of configurations can be done with, for instance, the Simple Cull algorithm (see, e.g., [25]) with a worst-case complexity of where is the number of configurations. Below we define some operations on configuration spaces. Whether an operator on configuration spaces can safely use minimized operands is expressed through the notion of dominance preservation.

[Dominance preservation]
Let be configuration spaces, let be an operator with operands, and let . We say that *preserves dominance* if and only if
.

If preserves dominance, then can safely use Pareto-minimal operands, i.e., .

Whether the result of an operator is already minimal is expressed by a notion of completeness that is formalized below.

[Minimality preservation]
Let be configuration spaces, let be an operator with operands, and let . We say that *preserves minimality* if and only if .

Pareto-minimal sets of configurations are sufficient and necessary for the optimization of arbitrary cost functions which behave monotonically.

[Derivation^{2}^{2}2This is a small and straightforward extension of the concept of *monotonicity* from [2].]
Let be a configuration space, let be a poset and let .
We say that is an -derivation (increasing derivation) if and only if implies that for all .
Similarly, we say that is a -derivation (decreasing derivation) if and only if implies that for all .

[Cost function] Let be a configuration space, let , let be a poset and let . Then we say that is a cost function if and only if it is an -derivation. We say that is an optimum in if and only if for all , and is called optimal if and only if for all .

The following two theorems, taken from [2], express (i) that dominated configurations are not needed to derive optimal configurations, and (ii) that every Pareto-minimal configuration in a configuration set is the unique optimum under at least some cost function.

[Sufficiency of Pareto-minimal sets] Let be a configuration space, let , and let be a cost function. If , then .

[Necessity of Pareto-minimal sets] Let be a configuration space, let such that is Pareto minimal, and let . Then there exists a cost function such that is the unique optimum configuration.

Next, four operations on configuration spaces are defined that all preserve dominance and all but one preserve minimality. We use these operations later on to define composition of components in our framework.

[Free product] Let and be configuration spaces, let and let . The free product of and is the Cartesian product in the configuration space . The free product preserves dominance. The free product preserves minimality.

[Safe constraint] Let be a configuration space. A safe constraint is a set such that for all holds that if and , then (implying that dominating configurations cannot be excluded from a safe constraint). Application of a constraint to a set of configurations is defined as . Application of a safe constraint preserves dominance. Application of a safe constraint preserves minimality.

[Function application] Let be a configuration space, let , let be a poset and let . Application of to yields a new configuration space and is defined as . We define . Application of an -derivation preserves dominance. Application of an -derivation preserves minimality.

Note that this definition of function application overloads the derivation name. I.e., if is an -derivation, then is also used to denote the application of to some configuration space.

[Abstraction] Let be a configuration space, and let . The -abstraction is a function defined as . We define . Application of -abstraction preserves dominance.

Abstraction does not preserve minimality because an abstraction can remove the single dimension that made some configuration incomparable to any other configuration. For instance, take with as ordering on . Then is Pareto minimal. We have , which clearly is not Pareto minimal because .

The following is not explicit in [2] but follows trivially. Permutation allows us to reorder the dimensions of a configuration space.

[Permutation] Let be a configuration space, let be a set of configurations, and let be a bijection, i.e., a permutation. We define and also let denote the function defined as . Furthermore, we define . Permutation preserves dominance. Permutation preserves minimality.

Finally, we need one more concept from Pareto algebra that we use in our quality- and resource management example later on.

[Alternatives] Let be a configuration space, and let . Then is called the set of alternatives of and . Alternatives preserve dominance.

The alternatives operation does not preserve minimality.

## 4. An Interface for Quality and Resource Management

The information needed for quality and resource management purposes is captured in our framework by an interface model for components.
A component has an input, an output, a required budget, a provided budget, a quality, and it may be parameterized.
The input, required budget, and parameters model the input assumptions, and the output, provided budget and quality model the output guarantees of the component [1].
All six parts are modeled by posets.
Each of these posets can be multi-dimensional, to capture cases with multiple inputs, outputs, resource requirements, etc.
This is the *quality and resource management interface* of the component.

[QRM interface] The QRM interface of a component is a set of configurations from a six-dimensional configuration space . By convention, the first dimension models the input of the component, the second dimension models the output, the third dimension models the required budget, the fourth dimension models the provided budget, the fifth dimension models the quality, and the sixth dimension models the parameters. Different components can use different configuration spaces.

A component can thus have a QRM interface that has multiple configurations. Each configuration models a specific working point of the component with specific values for input, output, required budget, provided budget, quality and parameters. These values usually are the result of some kind of analysis that is applied to the technology that is used to implement the component. External actors, e.g., end users, can typically control selection of subsets of configurations through the parameters. The freedom that remains to choose the final configuration is left to the quality and resource manager for optimization.

Figure 2 shows the graphical format that we use for a single configuration of the QRM interface of some component.
Depicting the complete interface with all configurations is often problematic as the values of input , output , required budget , provided budget , quality , and parameters differ between configurations.
The interpretation of the partial-order relation on input is that if , then is considered *weaker*^{3}^{3}3For convenience we do not distinguish between the strict and non-strict versions for the description of the order relations..
For output we interpret as that is *stronger* than .
For the required budget we say that means that is *smaller* than .
For the provided budget we say that means that is *larger* than .
The quality dimension is interpreted as follows: means that is *better* than .
Parameters are typically unordered; there are no better or worse parameter values. Whether a configuration is better or worse than, or incomparable to, another configuration is determined by the other five parts of the configurations.

In our framework, input and required budget specifications capture requirements, and output, provided budget and quality capture promises.
Requiring more is worse than requiring less. We have diametrically opposed interpretations of for input and output, and also for required budget and provided budget, to be able to use the dominance relation of Def. 3.
The dominating configuration thus has a weaker input requirement, a stronger output guarantee, a smaller required budget, a larger provided budget, a better quality and better, i.e., equal, parameters.
This *alternating* approach to dominance is similar to the notion of alternating simulation that is used to define refinement for interface automata [14], and is also used, for instance, in contract-based design to define refinement between contracts [19].
Note that if we have a poset with partial order that models the input and we need a poset for modeling the output that has the same semantic domain, we can just take the dual poset, i.e., the same set with partial order where if and only if . Clearly, the same goes for the required and provided budgets.

Consider Ex. 2. The posets used to model the component parts are shown at the bottom of the figure.
Now let us look at three configurations of the Scaler component, that scale FHS@60 input video to different resolutions and rates. Formally, these are the following^{4}^{4}4The Scaler component (and other components also) have many more configurations than mentioned in the examples. We only show some of these configurations to make our examples concise.:

Here we use the *void poset* with partial order to model the provided budget of the Scaler.
Note that the parameters poset uses equality as its ordering relation as parameters are unordered.
Therefore, neither dominates nor is dominated by either or because it has a different parameter value.
Because equality is also used for the output, neither dominates nor is dominated by .
Now suppose that the Scaler has two other configurations that employ a different scaling algorithm that needs more buffering space:

Then we have that and because the different scaling algorithm requires a larger budget but does not provide anything in terms of quality or output. Thus, , is not Pareto minimal. Its Pareto-minimal and equivalent component is , because , and is Pareto minimal because forms an anti-chain with respect to the dominance relation. Adding the algorithm as an actual parameter would result in being Pareto minimal. Also the situation where and have an additonal quality such as using less energy, would have this result.

The parameters can be used for several purposes. In this example, the parameters can be used to control the output resolution of the Scalers. We mentioned that parameters also can be used to differentiate between configurations that have different implementation algorithms. Such implementation alternatives may or may not be equal in terms of the input, output, budgets and quality. A related example is that they can be used to differentiate between different versions of components, where the version can be captured as an unordered quality to allow on-line version management.

A quality and resource management challenge arises when there are multiple components that implement the QRM interface. All these components must be combined in a proper way while optimizing some objective(s). In the next section we therefore explain how Pareto-algebraic concepts can be used to create compositions of components that implement the QRM interface. These compositions can again be described by a QRM interface. The whole composition process is thus expressed in Pareto-algebraic terms, and the notion of Pareto minimality applies. This naturally gives the necessary tools for multi-objective optimization.

## 5. Composition of Components

In this section we show how we approach composition of two QRM interfaces, resulting in a new QRM interface. First, we create the free product (Def. 3). The result of this free product is not a QRM interface anymore as the product configuration space has twelve dimensions. Then we apply constraints originating from i/o and budget matching, as well as selection constraints on allowed parameter combinations. Next, we apply operations that express the semantics of the composition in the application domain. We assume that we have a composition operator for all parts (input, output, etcetera) of the QRM interface. Typically such a composition operator takes the parts of the two QRM interfaces and creates a new part for the composition using a number of building-block functions, most notably domain-specific -derivations that can be applied using Def. 3. After application of the proper derivations, we reconcile the result with our notion of QRM interface by abstraction of dimensions that represent the two original interfaces, resulting in a six-dimensional configuration space of their combination with the usual interpretation of the dimensions. Finally, we apply any relevant constraints on the resulting configurations and apply Pareto minimization. To be more precise, we use the following template for our composition functions:

(1) |

Here is the free product, and are the composition functions for input, output, etcetera. The constraints are split into three parts: models the i/o and budget matching constraints, models the parameter constraints, and models domain-specific quality constraints, e.g., a constraint on a quality such as output rate. Finally, abstracts the first twelve dimensions, and is the minimization operation. We require that the composition functions are such that they add a single dimension to the configuration space, namely the specific part of the QRM interface (where this single dimension can itself be multi-dimensional). In that way, removing the first twelve dimensions by the abstraction gives us a six-dimensional configuration space with the specified QRM-interface interpretation of the dimensions.

As a first example of a composition, we show a free composition without any i/o or budget matching. This can, for example, be used to compose a platform for our running example from Fiber and HW scaler components. Some simple and generally useful -derivations that can be used to create the composition functions , , etcetera are defined next. First, a grouping derivation can be defined as follows that puts dimensions to in a single new multi-dimensional dimension. This new dimension uses the element-wise relation of its subdimensions (i.e., the dominance relation).

[Grouping] Let be a configuration space and let . We define with and if and only if for all as follows: . Grouping is an -derivation. ∎

Note that just copies a dimension. We abbreviate by . Next, ungrouping can help to access parts of multi-dimensional posets.

[Ungrouping] Let be a configuration space, let , let and let . Furthermore, let if and only if for all . We define as . Ungrouping is an -derivation. ∎

Finally, the void derivation adds a void value that can be used, e.g., to model empty component parts.

[Voiding] Let be a configuration space. We define as , with as the order on . Voiding is an -derivation. ∎

The next example shows how we apply all this for a simple composition.

[Free composition]
In this example we compose a Fiber with a HW scaler, both introduced in Sec. 2.
Since there is no connection made between input and output, or between provided and required budget, we call this a *free composition*.
We assume that we have a single Fiber that provides 10 Gb/s bandwidth and a single HW scaler that provides a scalers budget of four streams, 300 Mpixels/s processing, and 32 memory segments of 128 pixels each.
Both components have a single configuration, and only a non-void provided budget:

We then apply the free product to obtain:

Next, we define the compositions for the six interface parts. The composition of input, output and required budget is modeled by the void derivation, because the Fiber and HW scaler do not have these parts. The composition of the provided budget is done by grouping the respective provided budgets. Finally, we again use the void derivation for the composition of quality and parameters. This gives the following configuration:

The final steps are to abstract from the individual component parts, i.e., the first twelve dimensions, and to minimize (which is trivial for a configuration set of size one). This yields the execution platform component with only a single element.

This composition can thus be written as the following composition of our building-block functions (where constraints are not present, as mentioned before):

Our next example shows a more complicated composition. We want to make sure that input and output match. We do this by application of a producer-consumer constraint, which is already introduced in [2].

[Producer-consumer constraint] Let be a configuration space, let and let be a -derivation. Then is a producer-consumer constraint. A producer-consumer constraint is safe.

###### Proof.

Let and let . Let us assume that . We have to show that , which is to say that . We have that and since also that and . Since is a -derivation, we have that . Thus, . ∎

Another generally applicable constraint lets us select an arbitrary subset of configurations based on an unordered dimension. This is typically used to select arbitrary parameter valuations.

[Subset constraint] Let be a configuration space, let , let be the partial order for , and let . The constraint is called a subset constraint. A subset constraint is safe.

###### Proof.

Let , let , and let . We have that for all . We assumed that and thus . Because of the assumption on we thus have that , and therefore, . Thus, . ∎

[Horizontal composition] In this example we compose a Transport with a Scaler. The key difference with the previous example is that we have to match the output of the Transport with the input of the Scaler. We call this a horizontal composition. In this example we consider a Transport with two configurations: one for 60Hz FHD input, and one for 60Hz HD input. The required budget refers to the needed connection bandwidth in Gb/s.

For the Scaler we look at the following configurations:

Taking the free component product results in a configuration set with six configurations (the left-hand side of these configurations is the Transport component):

The stream that needs to be processed is of type FHD@60, and we use a subset constraint on the Transport parameter, , to select only the relevant transport configurations, which are , and . We also need to match the output of the Transport to the input of the Scaler. Since the output type of the Transport is equal to the input type of the Scaler, we use the identity function (which clearly is a -derivation) to create a producer-consumer constraint . Then we see that , since output FHD@60 does not match input HD+@60 (with as the ordering). This removes . Then we also apply a parameter constraint, , to select only those configurations with an HD output. That removes since it has HD+ output.

The derivations for the composition of the parts are the following. We use for the input, since the input of the composition is the input of the Transport. We use for the output, since the output of the composition is the output of the Scaler. This models that the output of the transport is consumed completely by the Scaler. We use for the required budget (collecting the required budgets of the two constituent components), for the provided budget, for the quality (indicating that the composition inherits its quality from the Scaler) and for the parameters. This last voiding models abstraction of the Transport and Scaler parameters as they have served their purpose and are not relevant anymore. Alternatively, one could decide that the composition copies the parameters from the Scaler, to allow configuration of the output of streams as a whole. Finally, we abstract from the first twelve dimensions which contain the individual component parts and minimize. This gives the following configuration:

This composition formally is the following function:

Note that an actual implementation of this composition can be done much more efficiently than what is shown here. Typically, the application of constraints and the derivations and abstractions can be inlined during the creation of the free product. Since abstraction is always used in our composition (see Eq. 1) and it does not preserve minimality, we always need to recalculate the set of Pareto-minimal configurations. This can be done using, e.g., the Simple Cull algorithm with quadratic worst-case complexity. Computation of the free product with the inline calculation of the constraints and derivations, can on its turn also be inlined in the Simple Cull algorithm, making it suitable for on-line operation [25].

The example above has shown how we can use parameters to select subsets of configurations, and how to use a producer-consumer constraint for i/o matching (budget matching works in a similar way). The output in the example above is completely consumed. This, however, needs not be the case in general. Modeling broadcast, for instance, leaves the broadcasting output untouched in a composition. In general we need non-trivial -derivations for the composition of the parts, for instance, to calculate the remaining budget when a required budget is strictly smaller than a provided budget. The remaining budget is offered by the composition to other components. Another example is the composition of two image-processing components that both have latency as quality. For the composition, we want to add the latencies of the individual components. Real numbers can often be used to express inputs, outputs, budgets and qualities. The kind of arithmetic operations that we need for the proper -derivations are supported by the following definitions.

[Addition-Multiplication-Min-Max] Let be a configuration space, let , let and , and let and . We define with and as . We define , and in a similar way. Addition/multiplication/min/max are -derivations.

###### Proof.

Let and let . We have to show that with being addition, multiplication, min or max. This follows straightforwardly from the assumption that and . ∎

For subtraction and division the situation is subtly different as the ordering on one of the posets needs to be reversed. Subtraction can be used, for instance, to compute the remaining provided budget when a budget provider is composed with a budget consumer. This, however, nicely matches with the alternating interpretation of input and output, and provided budget and required budget as we will see in the example below. In the following definition, is typically the producer (output or provided budget), and is the consumer (input or required budget).

[Subtraction-Division] Let be a configuration space, let , let , and let and . We define with and as . We define in a similar way, but only for . Subtraction/division are -derivations.

###### Proof.

Let and let . We have to show that with being subtraction or division. We have assumed that , which means that . We also have assumed that , which means that . Clearly, , and (assuming non-negative numbers) . ∎

[Vertical composition]
In this example we compose a Fiber component that provides 10 Gb/s *bandwidth* and a Connection component that requires Gb/s *bandwidth* and provides Gb/s *connection bandwidth*.
We connect the provided budget of the Fiber with the required budget of the Connection and therefore call this a vertical composition.

Application of the budget constraint does not filter out this configuration because .
Then we apply three times to model the input and output derivation, and the derivation for the required budget.
We use (on the natural numbers) to model the consumption of the budget and compute the remaining provided *bandwidth* budget.
Note that the requirements that , and are met because of the alternating approach to modeling provided and required budgets.
We group this remaining provided *bandwidth* with the provided *connection bandwidth* and remove the superfluous dimension.
Finally, we apply twice to model the composition of the quality and parameter parts.
As last steps we abstract from the first twelve dimensions and minimize.
This gives the following configuration.

This composition formally is the following function:

Above we have given a number of operations that we can use for composition. The free product combines two components and creates all possible combinations of the individual configurations. Abstraction can be used to remove dimensions that are not relevant anymore. Function application of -derivations defined above gives us operations that can be used to model the composition of input, output, etcetera. Finally, the producer-consumer constraint can be used to match input with output or required budget with provided budget, and the subset constraint can be used to select an arbitrary subset of configurations based on an unordered dimension (e.g., the parameter dimension). As shown in Ex. 5, Ex. 5 and Ex. 5, composition functions can be constructed from these basic building blocks using the template of Eq. 1.

The use of a number of well-defined atomic building blocks for our composition functions (that can be extended with domain-specific functions if needed) makes our approach highly flexible. The functions can and must be tailored to the semantics of the application domain. All our operations preserve dominance, and all except for the abstraction also preserve minimality. As stated in Th. 3 and Th. 3, Pareto-minimal sets of configurations are sufficient and necessary for the optimization of arbitrary cost functions. Our way of composition thus enables us to use Pareto-minimal intermediates by the dominance-preservation property of all operators. This can save the examination of a lot of (potentially exponentially many) configurations.

The next theorem formalizes refinement in our setting. If component implementations are at least as good as is stated in their quality and resource management interfaces, then the composition of the implementations is at least as good as the composition based on the interfaces.

[Refinement] Let and be components, and let for all . Furthermore, let be a function that composes these components using all previously defined composition functions, i.e., for some configuration space . Then .

###### Proof.

By induction to the number of applications of the six basic Pareto-algebraic operators that we use for our compositions: free product, constraint application, derivation, abstraction, permutation and alternatives. The base case for a single application is proven by dominance preservation of these operators, see Props. 3, 3, 3, 3, 3, 3. Now suppose that the theorem holds for applications of the composition operators. Then we have composed an intermediate component from the former set, and we can compose an intermediate component from the latter set such that . Applying the next composition operator to (and possibly in case of the free product) results in . Applying the next composition operator to (and possibly ) results in . Again, by dominance preservation of the composition operators, the induction hypothesis that , and the assumption that , we have that . Therefore, the theorem also holds for applications of the composition operators. ∎

A component declares a QRM interface consisting of a number of configurations using Def. 4. This is an abstraction of the real configurations of the component, the implementation, that can also be expressed as a QRM interface , but which may not be exactly known. The assumption that we make, however, is that the implementation is at least as good as declared. That is to say that the implementation dominates the interface: . Note that this allows the implementation to have more or less configurations than declared in the interface.

The theorem above is defined in terms of dominance of sets of configurations without taking a particular cost function into account.
Now suppose that we have created a composition based on the interface models and using a certain cost function we find an optimal configuration of this composition.
I.e., we have and the cost function selects as optimum.
We can trace for each interface which configuration was used to achieve this optimum: let be the configurations used to obtain .
The question then is what happens when in an implementation, components and configurations are used that are refinements of the interface models, leading to the realization of the configuration instead of ?
According to the definition of set dominance, for every interface configuration , there exists an implementation configuration in the implementation of the component, that is at least as good: .
From Th. 5 it follows that there exists a configuration in the composition of the implementations such that . This thus means that an optimization done based on the interfaces is *safe* in the sense that the corresponding implementations yield a result that is at least as good for any arbitrary cost function.

The monotonic nature of our framework fits well with other formalisms with a monotonic nature that may be used to model and analyze the relation between the various quality and resource management aspects of the component configurations.
An example is the synchronous dataflow (SDF) formalism [26] that is suitable for analyzing streaming applications such as the video-processing system of our motivating example.
It is well-known that this formalism is monotone in the sense that reducing the execution times of actors^{5}^{5}5An actor is part of the SDF formalism and models some (computational) task with a fixed execution time. will not result in a decrease of throughput. This is used in [18] for compositional refinement that preserves key real-time performance metrics such as throughput and latency.
We can also use the monotonicity in our setting.
Suppose that some component can be modeled using sdf, and that its quality is throughput and its required budget relates directly to the execution times of the actors.
Sdf analysis gives concrete values for several component configurations, i.e., the analysis calculates the throughput for a number of required budget values (actor execution times).
Now let us consider the composition with another component that provides the budget for the actor execution.
The monotonicity of sdf in combination with Thm. 5 provides several robustness benefits.
First, if the provided budget is larger than the required budget, then the throughput will not decrease because of sdf monotonicity. This means that the partial order on the actor execution budget can be a more flexible partial order than just equality.
This eases implementation of the providing component: not exactly the required budget should be delivered, but a slightly larger budget (just to be safe) is also good according to Thm. 5.
Second, usually the worst-case execution time of actors is used during sdf analysis. Because of monotonicity of sdf, an implementation will not have worse throughput. In terms of our framework, the component implementation dominates the interface that was used for composition.
By Thm. 5, this is no problem and the result is at least as good as was predicted based on the interface.

The examples in this section have shown three patterns that can be used for composition: free composition, horizontal composition and vertical composition. These patterns can be realized by using the general composition structure as shown in Eq. 1 with proper derivations to implement etc., and with constraints for matching, parameter selection and domain-specific filtering using the quality dimension. In the next section, we show how we can define composition functions on the posets and use them to realize the free, horizontal and vertical composition. Although this is more restrictive than using the general pattern, it is easier to automate.

## 6. Composition patterns for quality and resource management

The composition pattern in Eq. 1 requires us to define the composition of the component parts in terms of -derivations. The examples in the previous section have shown us three general composition patterns that can also be expressed using suitable and operations on our posets. Let us assume that we know how to add and subtract, i.e., we have functions and with signature with the following properties for every poset :

These properties hold for the regular addition and subtraction of numbers. These operations give rise to -derivations. Poset addition, defined below, takes care of adding values from identical posets, and also of values from different posets by grouping them together in a tuple.

[Poset addition] Let be a configuration space, and let . We define as follows: with if and and otherwise with if and only if and . Poset addition is an -derivation.

###### Proof.

Let and let . First, assume that and . Then and . From the assumption that and follows with the definition of that . Second, assume that or . Then and . Clearly, since and . ∎

The case for subtraction is more complicated due to the alternating interpretation but similar to the situations of the producer-consumer constraint of Def. 5 and the subtraction-division of Def. 5.

[Poset subtraction] Let

Comments

There are no comments yet.