Skip to content

1. Software Architecture

Jump to bottom
Jakob E. Bardram edited this page Nov 15, 2023 · 61 revisions

The figure below illustrates the overall runtime architecture of CARP Mobile Sensing (CAMS). The architecture consists of three main layers:

  • Client Manager (middle layer) – the main runtime layer of CAMS
  • Deployment Services and Data Manager (top layer) - accessing deployment configurations and uploading data
  • Sampling Packages (bottom layer) - a set of sampling packages accessing data from the underlying layers

CAMS builds on top of a set of Flutter plugins that access sensors and services in the underlying OS, external wearable devices, and cloud-based services. This architecture is designed to achieve the non-functional software architecture goals of being highly extensible, cross-platform, and maintainable.

carp_mobile_sensing_architecture

1. Client Manager Layer

This is the "core" CAMS runtime and comprises the following core runtime components:

  • The SmartPhoneClientManager is the core runtime of CAMS. It is a singleton. It holds a set of registries, controllers, and services which support the execution of data sampling:

    • DeploymentService - the deployment service this client is using, i.e., the service handling study deployment configurations
    • DataManagerRegistry - a registry of available DataManagers.
    • SamplingPackageRegistry - a registry of available SamplingPackages
    • DataTransformerSchemaRegistry - a registry of available DataTransformerSchemas
    • DeviceController - a controller of connected Devices
    • AppTaskController - a controller of AppTasks
    • NotificationController - a controller of the OS-level notification system

runs one or more StudyDeploymentController, which is based on adding a study to the SmartPhoneClientManager.

  • The StudyDeploymentController can be configured by specifying a DataEndPoint (which again loads an appropriate DataManager ), if any data transformation (incl. privacy protection) should be applied, along with settings for obtaining permissions automatically and sending notifications. Once configured, a StudyDeploymentExecutor is responsible for executing the study deployment.

  • The StudyDeploymentController use a set of registries to look up an appropriate data manager, relevant sampling packages, data transformers, and sensing probes for executing the sensing study deployment protocol.

2. Service Layer

The service layer (top layer) holds

3. Sampling Layer

The sampling layer (bottom layer) holds

  • A set of SamplingPackages, which can collect a specific type of measure. CAMS comes with two built-in sampling packages (the DeviceSamplingPackage and SensorSamplingPackage), but most sampling packages are available as external packages which are used in the app, as needed. In this way, an app only needs permissions to access probes (and hence sensors), which are needed in a specific app. A sampling package can also collect data from external devices (e.g., the Polar heart rate monitors) and in this case, the sampling package holds a DeviceManager which knows how to handle devices on runtime. Such devices can also be online services, such as a WeatherServiceManager. The carp_context_package is an example of an externally loaded sampling package, which are available on pub.dev.

  • Each sampling package contains one or more Probes, which can access the underlying sensor and collect the data. Access to sensor data is typically done using a Flutter plugin. Note that these Flutter plugins are external to CAMS and is loaded as needed by the sampling package. For example, the carp_context_package make use of the weather plugin to access weather data (as a web service).

Clone this wiki locally