Prometheus-X Components & Services

Edge computing - AI processing BB – Design Document

The Edge Computing (Decentralized AI processing) BB provides value-added services exploiting an underlying distributed edge computing infrastructure (e.g. owned and operated by Cloud Providers).

Two main high-level objectives are targeted by these services:

Technical usage scenarios & Features

In general, the main goal is to move the processing functions close to the data, and execute them on-site. If the execution capability is available in the node storing the data, the processing function (FaaS based operation) or container (CaaS based operation) is launched there (e.g. by the Kubernetes/Knative platform). By these means, we can avoid the transmission of a large amount of data. (goal 2)

As a more realistic use case, the data is also moved but only within a pre-defined privacy zone. This privacy zone encompasses worker nodes (using Kubernetes terminology) where we can deploy the processing functions on demand. (goal 1)

Features/main functionalities

Technical usage scenarios

scenario 0: set up infrastructure

scenario 1: privacy-preserving AI processing

More details of the communications related to scenario 1 are given here: Dynamic Behaviour

scenario 2: efficient near-data processing

Requirements

Integrations

Direct Integrations with Other BBs

Integrations via Connector

The integration with all other BBs playing the role of the TriggeringBB is expected to be done via the Connector.

Relevant Standards

Data Format Standards

The main data format standards to be followed in internal and external data exchange will be:

Mapping to Data Space Reference Architecture Models

This building block integrates an instance of the Prometheus-X Dataspace Connector (PDC) to act as a data provider to:

Connector, Data Provider, Data Consumer and Service Consumer are defined in IDS-RAM 4.0.

This building block interacts with the Catalog, Contract and Consent components provided by the (Personal) Data Space Intermediary. Data Space Intermediary and Personal Data Intermediary are defined in DSSC blueprint. The services offered by the Data (Space) Intermediary are described as Core Services or Enabling Services by DSSC blueprint and defined as Data Intermediation Services by the Data Governance Act.

Input / Output Data

The following data types and variables are used in the subsequent diagrams and descriptions.

Data Type Variable Description
AccessInfo access ID of a Provider and access info (REST API) of its Connector
PrivateData PD reference/ID of the private data
pdata pd the exact private data
Data D reference/ID of the NOT private data
data d the exact NOT private data
Function F reference/ID of the function to be applied to the private data (function-specific configuration data can also be included)
function f the exact function
Contract Cd and Cf contracts between the TriggeringBB and DataProvider and FunctionProvider, respectively
Consent Cons(F on PD) the consent from the User which allows the execution of the function on private data
AccessToken T token created by the DataProvider related to the user’s consent
PrivacyZoneData PZData describing the privacy zone information related to the DataProvider and PrivateData
Artifact A software artifact: container (CaaS) or function (CaaS) depending on the infrastructure
Result R the result of the function execution on private data

Customer-facing API (EdgeAPI):

- requestEdgeProc(
	Function F, PrivateData PD, 
	Contract Cd, Contract Cf, 
	Consent Cons(F on PD), AccessToken T)
  output: Result R
- requestEdgeProc(
	Function F, Data D, 
	Contract Cd, Contract Cf)
  output: Result R

Connector-facing API (PrivacyPreservingPDC):

- getPZData(
	DataProvider DP, PrivateData PD)
  output: PrivacyZoneData PZData
- requestFunction(
	Function F, Contract Cf)
  output: function f
- requestData/wPrivacyPreserving(
	PrivateData PD, 
	Contract Cd, 
	Consent Cons(F on PD))
  output: pdata pd

Catalog extension:

- getAccessInfo(
	Function F)
  output: ID of FunctionProvider and AccessInfo (e.g. REST API) of its Connector

The performance and the typical workload for a transaction cannot be estimated in general because these parameters strongly depend on the specific processing function and the (private) data which the function is executed on.

Architecture

The high-level architecture of the Edge Computing BB is shown by the following figure.

High-level architcture of the Edge Computing BB

The architecture of the Edge Computing BB is described by the following class diagram.

Architcture of the Edge Computing BB: Class Diagram

The purpose and tasks of the BB components are given in the table below.

BB Component Description
EdgeAPI Entry point of the BB
PrivacyZoneMgr Gather, handle, process privazy zone data related to the DataProvider and the PrivateData
PDC Prometheus-X DataSpace Connector (core component)
PrivacyPreservingPDC Extended PDC equipped with the capability of privacy preserving data sharing and with function sharing (part of the BB)
Scheduler Custom Kubernetes Scheduler taking also privacy related information into account
ArtifactBuilder Build the software artifacts to be deployed (abstract class)
CaaS/FaaSBuilder CaaS and FaaS based implementation of the ArtifactBuilder
Wrapper Wrapper functions/serivces/data (e.g. AccessToken) added to the software artifact (abstract class)
CaaS/FaaSWrapper CaaS and FaaS based implementation of the Wrapper
WorkerNode Kubernetes/Knative worker node (edge node) which can execute the container/function

Dynamic Behaviour

The following sequence diagram shows how the components communicate with each other, assuming the most complex and relevant operation: scenario 1.

Dynamic Operation of the Edge Computing BB: Sequence Diagram (example)

Assumptions:

BB Component Description
EdgeAPI Entry point of the BB
PrivacyZoneMgr Gather, handle, process privazy zone data related to the DataProvider and the Data
ConnectorEdge The connector functionality of the data consumer is delegated to the Edge Computing BB, it is the counterpart of the provider’s connector equipped with the capability of privacy preserving data sharing and function sharing
Scheduler Custom Kubernetes Scheduler
ArtifactBuilder Build the software artifacts to be deployed
Wrapper Wrapper functions/serivces/data added to the container/function artifact
WorkerNode Kubernetes worker node (edge node) which can execute the container/function
Other Actors Description
Triggering BB (Consumer) The triggering BB which plays the role of the data and function consumer. It also provides the consent related information gathered in advance making use of its own connector (not shown in the diagram).
FunctionProvider Storing the processing function to be executed (it can be the Triggering BB itself)
ConnectorFP The connector of the function provider equipped with the capability of function sharing
DataProvider Storing the data including personal data
ConnectorDP The connector of the data provider equipped with the capability of privacy preserving data sharing
Contract Prometheus-X core component (might be extended)
Catalog Prometheus-X core component extended with function sharing capability
Consent Prometheus-X core component (might be extended)

The main steps of the operation are detailed below.

Detailed steps of the operation realizing scenario 1 (privacy-preserving AI processing)

Configuration and deployment settings

Configuration parameters

The operational parameters of the BB will be described in a corresponding YAML configuration file. It will be composed of the following relevant elements:

Configuration of the Prometheus-X Data Space Connector (PDC) is documented by the PDC building block.

Logging

The BB will use a Prometheus based monitoring service which is an open-source tool and a standard approach in Kubernetes systems. Besides the relevant infrastructure-level operational data, the Edge Computing BB related logging information will also be integrated into the monitoring system. Furthermore, customized alerting configuration will also be supported

In addition, a Grafana dashboard will be added where the operator of the BB can visually follow and inspect the relevant operational parameters.

Erros scenarios

The following error scenarios are identified at the current design stage:

Each error scenario results in refusing the request and providing the identified root cause.

Third Party Components & Licenses

Our implementation will be built on Kubernetes and Knative which components are licensed under the Apache License 2.0. Our BB will use the same licesne.

OpenAPI Specification

The curren version of the OpenAPI specification can be found here:

Edge Computing BB - OpenAPI specification

Test specification

Test plan

At a first step, the REST APIs of the BB will be tested making use of e.g. Postman to generate test requests. A mockup version of the BB will be responsible for checking the input parameters and their formats and for providing dummy answers.

In addition, the Connector (PDC) related extensions, such as Privacy Zone information handling, will also be mimicked at this stage.

As a second step, component related tests will be designed. The following entities can be tested separately at this level:

As a third step, integration tests will be defined which can be used to validate the interoperation among the internal components of the BB. First, the ArtifactBuilder - Scheduler cooperation can be tested which integrates the previously defined component tests. Second, the Privacy Zone calculation process can be tested including the PrivacyZoneMgr, ConnectoEdge and EdgeAPI. And third, the overall workflow can be tested involving each component.

Finally, the integration tests with external BBs and the core components will be defined. The relevant entities are the following (according to our current view):

Partners & roles

Usage in the dataspace

This building block is part of the service chain with the title “Decentralized AI Training”. That service chain defines how these two building blocks can be integrated into one combined solution.

Furthermore, it’s planned to integrate and showcase this building block in the Use Case “Job Opening Prediction”. Details of this use case are still under development, the design will be further discussed.