Note that this documentation needs to be updated to the latest version.
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.
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.
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.
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.
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.
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.
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 endToEnd
and 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.
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
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.
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
This work has received funding from the Electronic Component Systems for European Leadership (ECSEL) Joint Undertaking under grant agreement no 783162 (FitOpTiVis)