Bosch IoT Rollouts

Data Model Definitions

Table of contents:

Entity relationships

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

images/confluence/download/attachments/1680491207/data_model-version-1-modificationdate-1635419167000-api-v2.png


Entity definitions

A detailed description of the entities and their attributes are listed in the API references.

Rollouts data model

The data model of the Bosch IoT Rollouts update server 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 Bosch IoT Rollouts, i.e. on the device itself or before the entity creation in Bosch IoT 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 Bosch IoT 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.

A Target can have, next to its defined properties (e.g. controller ID, target type, name, description, security token), a generic set of attributes and meta data, both in key:value format. Target attributes are owned and managed by the device whereas target meta data are managed by the operator. If a target is defined to be of a certain target type, then during the assignment of a distribution set, a compatibility check will be performed between the target type and distribution set type.

Software model definition

The model 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

  • Both Distribution Set and Software Module contain next to a defined set of properties (e.g. version, name) flexible Metadata in key:value format. In case of Software Module the targetVisible flag allows providing a Metadata element to the target as part of an update. This is supported by DDI and DMF API.

Examples

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.

images/confluence/download/attachments/1680491207/SmartHomeController-version-1-modificationdate-1618845647000-api-v2.png

Connected sensor

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


images/confluence/download/attachments/1680491207/Connected_Sensor-version-1-modificationdate-1618845661000-api-v2.png

Connected vehicle

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

images/confluence/download/attachments/1680491207/SmartHomeController2-version-1-modificationdate-1618845672000-api-v2.png


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.

images/confluence/download/attachments/1680491207/firmwareEqual-version-1-modificationdate-1618845701000-api-v2.png

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 a “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 Bosch IoT Rollouts provides the necessary infrastructure for this use case it does not offer a store for customers to buy modules for their devices.

images/confluence/download/attachments/1680491207/appStore-version-1-modificationdate-1618845728000-api-v2.png