Data Model Overview

The Rollouts update server data model has enough flexibility to define complex software structures, e.g. operating system, runtimes, apps, different kind of artifacts on one side and simplicity compared to the capabilities of a full blown configuration management.

It does define a hierarchy of software that starts with a distribution, which can have (sub-)modules and these may have multiple artifacts on one side. However, it does not consider any kind of dependency definitions between modules or artifacts. As a result dependency checks if necessary have to be done outside Rollouts, i.e. on the device itself or before the entity creation in Rollouts by the origin.

Provisioning Target Definition

A Provisioning Target is a neutral definition that may be an actual real device (e.g. CCU, embedded sensor) or a virtual device (e.g. vehicle, smart home).

The definition in Rollouts depends on the transactional behavior that is necessary on the device side. A vehicle might be updated device by device or as a whole.

Software Structure Definition

The structure defines the model of the supported software by the provisioning target.

  • Distribution Set Type: defines a package structure that is supported by certain devices.
  • Consists of Software Module Types both for
    • Firmware - device can have only one module of that type (e.g. the operating system).
    • Software - device can have multiple modules of that type (e.g. applications or add-ons).

Software Content Definition

  • Distribution Set: can be deployed to a provisioning target.
  • Software Module: is a sub element of the distribution.
    • e.g. OS, application, firmware X, firmware Y
  • Artifact: binaries for a software module. Note: the decision which artifacts have to be downloaded are done on the device side.
    • e.g. Full Package, Signatures, binary deltas

Example use cases

Connected gateway

A simple example is described here. In this case the provisioning target supports only a firmware or operating system. You can see in the example the two columns of the model; the structure that is supported by the provisioning target and the concrete content instances. Multiple artifacts allow the usage of pre-compiles binary deltas and extra signature files though.

Gateway

Connected sensor

The connected sensor is even more simplified as it supports only one firmware file.

Sensor

Connected vehicle

A more complex example uses the full model. Multiple modules, both firmware and software applications.

Vehicle

Distribution Sets as universal packages

In this scenario, a distribution set fits to multiple targets. This is typically the case if the scenario is primarily driven by a defined firmware set. Maybe modular but even then with a similar module setup on large groups or categories of devices.

Unified Package

Distribution Sets for individual targets

In this scenario, a distribution set is individual for a target at a certain point in time. This is typically true in store scenarios where devices get modules assigned or unassigned on an individual basis. Here with every module assignment change a new distribution set is created. As a result the meaning of the distribution set changes from an “unified package” to a device specific setup.

The distribution set serves together with the update/action history as a complete change history. However, keep in mind that while Rollouts provides the necessary infrastructure for this use case it does not offer a store for customers to buy modules for their devices.

App Store

Entity Relationships

The public defined entities and their relation which are reflected in the public API.

Entity Relationships

Entity Definitions

A detailed description of the entities and their attributes are listed in the developer guide.