System Overview

SmaCH watches over artworks, in a museum or a store and on the road. Dataloggers placed on the artwork record temperature, humidity and vibration, and raise alerts when a threshold is crossed. This page describes the parts of the solution and the model they share.

Components

graph TB
    subgraph "Users"
        U1[Administrators]
        U2[Super-admins]
        U3[Viewers]
    end

    subgraph "Applications"
        WEB[SmaCH web application<br/>app.smach.science]
        MOBILE[StaRT mobile app<br/>on site]
    end

    subgraph "Services"
        API[SmaCH API<br/>api.smach.science]
        AUTH[Sign-in<br/>id.smach.science]
    end

    subgraph "Equipment"
        DL[Dataloggers<br/>logger + sensor]
        GW[Gateways<br/>cabin or trailer]
    end

    U1 --> WEB
    U1 --> MOBILE
    U2 --> WEB
    U2 --> MOBILE
    U3 -.view only.-> WEB

    WEB --> API
    MOBILE --> API
    WEB --> AUTH
    MOBILE --> AUTH
    MOBILE -.setup.-> DL
    DL -.-> GW

    style U2 fill:#1AFFBB,color:#000
    style MOBILE fill:#0000A5,color:#fff
    style GW fill:#1AFFBB,color:#000
    style DL fill:#1AFFBB,color:#000

Web application

Used by every role, at app.smach.science.

• A dashboard of the monitorings set up or in progress, with their latest alert and position.
• Artworks: description, packaging, base configuration, checklist, and the history of their monitorings.
• Monitorings: the list, filtered by status and type, and for each one its timeline of events and the charts of its alerts. A monitoring’s page updates live when it starts and stops.
• The equipment inventory, for administrators.
• The members of the organization, for its administrators, and the administration console for super-admins. See Managing organizations and users.

StaRT mobile application

Used on site by administrators and super-admins. It lists the artworks ready for a monitoring, detects the dataloggers, sets up the monitoring, starts and stops it, and pushes the events of the session: alerts, positions and notifications. Its calls are described in the StaRT API workflow.

SmaCH API

The web application and StaRT share one API, at https://api.smach.science. Its portal and full reference are at api.smach.science/reference, and its common rules in the API conventions. Accounts sign in through the SmaCH Keycloak at id.smach.science.

Equipment

• A logger is the datalogger box.
• A sensor is the probe plugged into a logger. It carries one to three captors: temperature (degrees Celsius), humidity (percent relative humidity) and a three-axis accelerometer.
• A datalogger is a logger paired with a sensor. It is not an inventory item of its own: the pair is detected at setup and recorded in the monitoring.
• A gateway is a relay installed in the vehicle of a transport, in the cabin or the trailer. A datalogger may name the gateway it reaches.

File storage

SmaCH keeps its files, such as datalogger recordings, in an S3-compatible object storage (Silo). The web application and the API do not read or write it yet. A storage space per organization is in preparation.

Artworks

An artwork is the central resource. Each one belongs to an organization and is named in the API by its reference, a URL-safe key unique within the organization (bayeux-tapestry), rather than by its id.

An artwork carries:

• its description: name, summary, creator, date of creation, medium, size in millimetres, weight in grams, picture, free tags;
• its packaging: an inclosure, the static protection, and a crate, the transport protection, both taken from the inventory;
• a checklist of tasks to verify before a monitoring;
• a base configuration: captor thresholds and logger settings;
• the history of its monitorings.

Configuration

Part	Settings
Temperature, humidity	measurement interval in seconds, minimum and maximum thresholds
Accelerometer	range (2g, 4g, 8g, 16g) and minimum and maximum per axis, in raw device units
Logger	battery alert threshold (percent), storage alert threshold (MB), recording frequency (measurements per hour)

The configuration is inherited on three levels. The artwork holds the base. A monitoring receives a copy at setup, adjusted on site if needed. A datalogger may carry its own configuration, which replaces the monitoring’s for that datalogger alone, for instance stricter thresholds near a fragile area.

Artwork statuses

stateDiagram-v2
    [*] --> draft
    [*] --> ready
    draft --> ready
    ready --> standby: setup
    standby --> monitoring: start
    standby --> ready: stop before start
    monitoring --> ready: stop
    ready --> archived
    ready --> cancelled
    draft --> cancelled

Status	Meaning	Set by
draft	being described and configured	an administrator
ready	ready for a monitoring	an administrator, or the end of a monitoring
standby	a monitoring is set up, waiting for its start	the setup
monitoring	a monitoring is recording	the start
archived	no longer monitored, history kept	an administrator
cancelled	cancelled	an administrator

An artwork is created as draft or ready. An administrator moves it between draft, ready, archived and cancelled. standby and monitoring follow its monitoring: no request sets them, and an artwork in one of them cannot be moved by hand. Archiving is the normal way to retire an artwork and keeps its history. Deleting an artwork deletes its monitorings and their events, and is refused while a monitoring is set up or recording.

Monitorings

A monitoring is one recording session of an artwork. It is either:

• stationary, in a museum or a store;
• transport, during a movement, with gateways in the vehicle.

An artwork has at most one monitoring set up or in progress at a time, and any number of ended ones.

A monitoring records its type, its configuration, its dataloggers (logger, sensor, optional gateway, a note and a position on the artwork) and, for a transport, its gateways with their place in the vehicle.

Monitoring statuses

stateDiagram-v2
    [*] --> pending: setup
    pending --> in_progress: start
    pending --> ended: stop
    in_progress --> ended: stop
    ended --> [*]

Status	Meaning	Artwork
pending	set up, waiting for the start	standby
in_progress	recording	monitoring
ended	stopped, final	ready

Only the setup, the start event and the stop event move a monitoring. An ended monitoring is never restarted and records nothing more. To monitor the artwork again, a new monitoring is set up.

Equipment rules

• Every logger, sensor and gateway named at setup must exist in the inventory of the organization, under the exact identity StaRT reads from the device.
• An item is engaged by one monitoring set up or in progress at most. The inventory shows which items are in service; an item is free again once its monitoring has ended.
• An item that appears in a monitoring, even an ended one, cannot be deleted, nor a packaging assigned to an artwork.

Events

An event is what happens during a monitoring. Each one has a type, a severity (info, warning, critical), the date it happened on the device, a location, and the source that reported it.

Type	Reported by	Content
start	the monitoring	begins the recording
alert	a sensor	the captor that crossed its threshold, the measured values and a message; or a device alert on battery or storage
position	a logger	the location, and optionally rotation, acceleration and speed
notification	a user	a free message and tag
stop	the monitoring	ends the recording

An alert or a position names its sensor or logger, not the monitoring: the API attaches it to the monitoring set up or in progress that engages that equipment.

Users follow events in the web application as they arrive. Alerts are limited per captor in the live view, so a burst arrives as one alert per captor, and the timeline of the monitoring keeps all of them.

Example

The artwork “Bayeux Tapestry” has an inclosure, a transport crate and a base configuration of 15 to 25 degrees, 40 to 60 percent humidity, and accelerometer thresholds of about 10 m/s2 on the 2g range. Over time it receives:

1. a stationary monitoring in its store, now ended;
2. a transport monitoring for the way out, now ended;
3. a transport monitoring for the way back, in_progress, so the artwork is monitoring.

Next steps

• User roles, for who can do what.
• StaRT API workflow, for the calls of the mobile application.