Documentation

Note that this documentation needs to be updated to the latest version.

Introduction

In this document, we explain the Quality and Resource Management Language (QRML). We start with providing an overview of the constructs of of the QRML language, after which we illustrate them using a Biometric Access Control (BAC) System example, which can also be found as a public model on this site.

Back to top

Overview of the constructs of the QRML language

This section provides and overview of the constructs of QRML.

The key concept in QRML is the component. A component has an interface consisting of six parts, inputs, outputs, required budgets, provided budgets, qualities, and parameters.

The component interface, as graphically depicted above, is described as follows.

• output is a functional output (usually drawn horizontally) which is connected to the functional input of another component.
• input is a functional input (usually drawn horizontally) which is connected to the functional output of another component.
• provided budget is a resource provision (usually drawn vertically) which is connected to the resource dependency of another component.
• required budget is a resource dependency (usually drawn vertically) which is connected to the resource provision of another component.
• parameter is a configurable aspect of a component.
• quality is an aspect of a component that is intended to be optimized.

Component dependencies connect interfaces of different components, which indicates that they depend on each other. These dependencies can be specified using the following constructs.

• outputs to connects the functional output of one component to the functional input of an other component (usually drawn horizontally).
• runs on connects the resource dependency of one component to the resource provision of an other component (usually drawn vertically).

Each of the six elements of a component interface have a type, which can be defined in three different ways:

• channel is used for the input and output interfaces. It therefore also concerns the outputs to dependency.
• budget is used for the provides and requires interfaces. It therefore also concerns the run on dependency.
• typedef is used for parameters and a qualities but can also be used for a provide, require, input and output.

Additionally, a component can be a composition of other components, yielding a component hierarchy, in the following two ways.

• Component aggregation is used when a component consists of (one or) multiple components.
• Alternatives concerns a component that can behave in different ways, each specified as a component.

The following diagram shows the component hierarchy of the BAC model. Filled diamonds indicate component aggregations, whereas open diamond represent alternatives. It has been automatically generated with the QRML tooling on the basis of the QRML model.

Back to top

Biometric Access Control system

We consider a Biometric Access Control system that grants access to e.g. buildings, rooms, files, or data on the basis of face recognition, e.g., by analyzing the relative position, size, and/or shape of the eyes, nose, cheekbones, and jaw.

BAC system overview

The figure above shows a component model of the BAC system. We define the BAC application, the BAC platform and connect them via a mapping, yielding the BAC system. This separation of concerns facilitates modeling and reasoning about quality and resource management (QRM). Next, we discuss the BAC system in a bottom up way and specify at the same time elements of the QRML language.

Back to top

The BAC application

The figure conveys that the BAC application is a pipeline that consists of three components, namely Face Detection (capturing an image and detecting a face), Face Recognition (identifying a person from the detected face) and Access Control (looking up the access rights of an identified person). The components are connected functionally, i.e., depicted horizontally. Face detection outputs an image to Face Recognition and Face Recognition outputs an ID to Access control. To make this more clear, we demonstrate how this is done in the actual QRML code.

Component Face Detection outputs an image. Furthermore, Face Detection has two requires statements, which means it depends on another component (to be discussed later), from which it requires a resource budget. Finally, there is a latency quality, which depends on the a property of the imgAna subcomponent.

component FaceDetection {
    output Image out

    requires ImageCapturing imgCap
    requires ImageAnalysis imgAna

    quality Latency lat
    constraint lat = imgAna.latency
}

Component Face Recognition inputs an Image from Face Detection and outputs an ID to Access Control. Just like Face Detection, Face Recognition relies on a component that affects its latency. Moreover, another quality named reqQuality is used to determine the recorded quality of the Face Identification procedure.

component FaceRecognition {
    input Image inp
    output Id out

    requires FaceIdentification faceId

    quality Latency lat
    quality Quality recQuality

    constraint lat = faceId.latency
    constraint recQuality = faceId.qual
}

The third component of the pipeline AccessControl only has input functionality, i.e., it receives an ID from Face Recognition. Again, an application component has a quality latency, which depends on where the component is mapped to.

component AccessControl {
    input Id inp

    requires DatabaseAccess dbAcc

    quality Latency lat
    constraint lat = dbAcc.latency
}

Face Detection, Face Recognition and Access Control are aggregated into component BACApplication, as follows.

component BACApplication {
    contains FaceDetection faceDet
    contains FaceRecognition faceRec
    contains AccessControl accCon

    constraint faceDet.out outputs to faceRec.inp
    constraint faceRec.out outputs to accCon.inp

    quality Latency endToEnd { endToEnd = faceDet.lat + faceRec.lat + accCon.lat }
    quality Quality recQuality from faceRec.recQuality

    requires ImageCapturing imgCap from faceDet.imgCap
    requires ImageAnalysis imgAna from faceDet.imgAna
    requires FaceIdentification faceId from faceRec.faceId
    requires DatabaseAccess dbAcc from accCon.dbAcc
}

First, the three components are mentioned, followed by two outputs to constraints to connect them in a pipeline fashion. Then, we introduce two qualities that expose metrics of interest to users or to a QRM. The BAC application has a Latency endToEndand a recQuality, which represent the end-to-end latency of the pipeline and the recorded quality as in Face Recognition. The latency is determined as the sum of the individual latencies of the pipeline components with a constraint. The recorded quality is merely a copy of the recorded quality of the Face Recognition component. The required budgets, stated using the requires keyword are specified. With the from-clause they are set to be equal to required budgets of subcomponents. Later, when the platform is introduced which provides budgets, we will fulfill these requirements.

Back to top

The BAC platform

The key component of the BAC platform is the Smart Camera, a machine vision system providing, in normal mode, image capturing and analysis. In advanced mode, it also extracts person IDs from captured images. The Smart Camera is defined as follows.

component SmartCamera {
    contains SmartCameraNormalMode normal or SmartCameraAdvancedMode advanced as sc

    provides ImageCapturing imgCap from sc.imgCap
    provides ImageAnalysis imgAna from sc.imgAna
    provides FaceIdentification faceId from sc.faceId
}

The Smart Camera has two alternative realizations, i.e., it can behave in either one of two ways, which are both specified by a component. These alternatives are SmartCameraNormalMode and SmartCameraAdvancedMode, respectively. In normal mode, the Smart Camera has a latency of 25 for image analysis.

component SmartCameraNormalMode {
    provides ImageCapturing imgCap
    provides ImageAnalysis imgAna { latency = 25 }
} 

In advanced mode, the latency for image analysis is slower, namely 50. However, in turn the Smart Camera is able to perform Face Identification at low quality and a latency of 20. Hence, selecting the camera mode is clearly a trade-off.

component SmartCameraAdvancedMode {
    provides ImageCapturing imgCap
    provides ImageAnalysis imgAna { latency = 50 }
    provides FaceIdentification faceId { qual = low & latency = 20 }
}

The compute platform is defined in a similar way as the Smart Camera; it also has two alternatives, as follows.

component ComputePlatform {
    contains CloudComputePlatform cloud or LocalComputePlatform local as computePf

    provides FaceIdentification faceId from computePf.faceId
    provides DatabaseAccess dbAcc from computePf.dbAcc
} 

Either, computations are performed in the cloud, via Cloud Compute Platform, leading to a high image quality but at the price of two high latencies of 100.

component CloudComputePlatform {
    provides FaceIdentification faceId { qual = high & latency = 100 }
    provides DatabaseAccess dbAcc { latency = 100 }
}

Alternatively, computations are performed locally, via Local Compute Platform, leading to a medium image quality but at with lower latencies of 50.

component LocalComputePlatform {
    provides FaceIdentification faceId { qual = medium & latency = 50 }
    provides DatabaseAccess dbAcc { latency = 50 }
}

component BACPlatform {
    contains SmartCamera sc
    contains ComputePlatform cp

    parameter FaceRecPlatform fr

    provides ImageCapturing imgCap from sc.imgCap
    provides ImageAnalysis imgAna from sc.imgAna
    provides DatabaseAccess dbAcc from cp.dbAcc

    provides FaceIdentification faceId
    constraint fr = smartCam => (faceId = sc.faceId)
    constraint fr = compPlat => (faceId = cp.faceId)
}

Note that for the mapping of Face Identification, a parameter is used, which mandates whether it is run on the Smart Camera (in advanced more), or on the Compute Platform (either Local or in the Cloud), by means of a constraint that determines which budget is present at the outside of the component.

Back to top

The BAC system

Now that the BAC application, the BAC platform have been defined, it has become possible to connect them. This leads to the BAC System that is presented as follows.

main component BACSystem { 
    contains BACApplication app
    contains BACPlatform plt

    parameter FaceRecPlatform fr from plt.fr

    quality Latency endToEnd from app.endToEnd
    quality Quality recQuality from app.recQuality

    constraint app.imgCap runs on plt.imgCap
    constraint app.imgAna runs on plt.imgAna

    constraint app.faceId runs on plt.faceId
    constraint app.dbAcc runs on plt.dbAcc
}

The main keyword indicates that this component is the main system. That is, the component that the QRML tooling will use as its starting point of analysis. BAC System aggregates BAC Application and BAC Platform and forwards the parameter fr to BAC Platform to enable the selection of the platform there. Furthermore, the four required budgets are mapped to the four supported budgets using the runs on keyword. Finally the qualities of BAC application are copied one-on-one here, to make them available at system level.

Back to top

Typedefs, channels and budgets

The BAC model uses nine types. We identify four budgets which are used for required and supported budgets.

budget ImageCapturing boolean ordered by = 

budget ImageAnalysis{
    latency : Latency
}

budget FaceIdentification {
    latency : Latency
    qual : Quality
}

budget DatabaseAccess {
    latency : Latency
}

There are two channels, which connected inputs and outputs.

channel Image integer
channel Id integer

And finally, there are three type definitions. Latency and Quality are used to describe qualities, whereas faceRecPlatform is used to specify the mapping of Face Recognition.

typedef Quality enumeration {bottom, low, medium, high} ordered left-to-right
typedef Latency integer ordered by >=
typedef FaceRecPlatform enumeration {smartCam, compPlat} ordered left-to-right

Back to top