Data Model Definitions
Table of contents:
Entity relationships
The public defined entities and their relation which are reflected in the public API.
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.
Connected sensor
The connected sensor is even more simplified as it supports only one firmware file.
Connected vehicle
A more complex example uses the full model. Multiple modules, both firmware and software applications.
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.
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.
