1. Software Architecture

Updated to API level 1.x

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.

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

• The SmartPhoneClientManager can be configured by specifying what deployment service, device controller, and notification controller to use, and other parameters.

• Study deployments that should run on a SmartPhoneClientManager can be added, which will create and host a SmartphoneDeploymentController for each study.

  • The SmartphoneDeploymentController can be configured by optionally specifying a DataEndPoint and a DataTransformer.

  • The SmartphoneDeploymentController uses the set of registries in the SmartPhoneClientManager to look up an appropriate data manager, relevant sampling packages, data transformers, and sensing probes for executing the sensing study deployment protocol.

When the SmartPhoneClientManager has been configured and the study has been added, data sampling can be controlled by starting or stopping all studies on a client. This can also be done or a per-study level, by using the start and stop methods on the SmartphoneDeploymentController.

2. Service Layer

The service layer (top layer) holds

• The Deployment Service, which is able to manage and deploy the StudyProtocol.

• Data manager services, which know how to store, save, or upload data, such as the SQLiteDataManager.

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).