Bosch IoT Insights

In Bosch IoT Insights, software versions of connected devices can be visualized. The information comes from Bosch IoT Rollouts and is based on Vorto models.

Prerequisites

You have added the information block to the device type, refer to Adding and removing information blocks.

Proceed as follows

Open the device for which you want to display the software list.

→ The software version and the hardware version of the device are displayed as well as the status of the update process provided by the Vorto model.

Diagram

This diagram describes the SoftwareUpdatable feature, which needs to be implemented in your device firmware.

Feature and entities contained in the feature

SoftwareUpdatable
`softwareModuleType`	String	required	The type of software(-module) this feature is responsible for	Bosch IoT Rollouts will import all found `softwareModuleTypes` and will use this type in order to find out the feature on which the install operation will be invoked. A software-module type is usually the type of software which is managed by this feature. Examples could be "OS", "bundle", "docker", "feature", "app" or just "software". If one `SoftwareUpdatable` feature implementation is responsible for multiple types, it can decide to represent itself as multiple `SoftwareUpdatable` features on the thing, or can just offer a generic type like "software". It must be ensured, that one thing has only one `SoftwareUpdatable` feature responsible for a `softwareModuleType`
`installedDependencies`	dictionary [String,DependencyDescription]	optional	A list of all installed "pieces of software" which are managed by this feature	A list of "group", "name" and "version" from all artifacts which are managed by this feature (could be potentially updated or removed). The key in the dictionary should be the combined `group.name:version` of the dependency (please see examples below). Examples: For a `SoftwareUpdatable` feature which is managing docker-containers this would be the list of installed docker-containers. For a feature which is managing the operation-system itself, this list would contain only one entry with probably the vendor and/or name and current version of the OS like "ubuntu:20.20". The installed and context dependencies are currently not actively used by Bosch IoT Rollouts but will be used in a planned extension which requires a better understanding of the real state of a device, i.e. when the device gets "offline" modifications (hardware or firmware).
`contextDependencies`	dictionary [String,DependencyDescription]	optional	A list of all other dependencies which do influence the artifacts managed by this feature	This could be e.g. a certain hardware version or processor architectures. The content depends on the project requirements. For example, if there is only one version of hardware out in the field or the updates contain all "drivers" for all kinds of hardware, there is no need to know if the assigned updates are matching the device or not. A better understanding of the real state of a device will be required by a future extension of Bosch IoT Rollouts with update-build support, validity checks of assignments and auto-update proposals. From a device point of view, there is no need to know about dependency relationships (e.g. which software requires which hardware). This is tracked and modeled on the server-side.
`lastOperation`	Entity<OperationStatus>	(required)	The last operation response received from the device	Status updates on this property are recorded by Bosch IoT Rollouts in order to follow the progress of the installation. In case of multi-assignment, this field might be updated in a quick sequence, still Bosch IoT Rollouts will be able to map the updates to the matching assignment with the help of the `correlationId` in the `OperationStatus`. The `lastOperation` may not be present if no operation has been executed so far.
`lastFailedOperation`	Entity<OperationStatus>	(required)	The last operation response which has had an error-status	The `lastFailedOperation` may not be present if there has been no failed operation so far. In case that an operation finishes with FINISHED_ERROR, FINISHED_WARNING or FINISHED_REJECTED, the device should not only update the `lastOperation` but also in addition the `lastFailedOperation`. Background: In case that there are multiple operations running, the `lastOperation` might be overwriting quickly and not be preserved to be used in a thing-search later.

OperationStatus
`status`	Enum<Status>	required	A status describing the current state of the installation on the device	Must be not empty - a status can be sent multiple times e.g. for transmitting different steps in the `message`/`statusCode` within the status "IN_PROGRESS"
`message`	String	optional	Any kind of message giving additional information	Any kind of additional information provided by the device in order to report installation steps or errors.
`progress`	number	optional	A number defining the progress in percentage (0...100)	An optional progress indicator which can be used by 3rd party UIs in order to visualize a progress.
`correlationId`	String	required	The correlation ID passed from Bosch IoT Rollouts with the install/download instruction	This ID is essential for matching the responses of the device to the instructions generated by Bosch IoT Rollouts.
`statusCode`	String	optional	A custom code which can be used for grouping and retrying failed assignments	A custom error code which can be used by the user of Bosch IoT Rollouts in order to filter for devices which might belong to the same retry strategy.
`softwareModule`	Entity<SoftwareModuleId>	(required)	The name and the version of the `SoftwareModule` which is installed	The name and version of the module currently processed. As the name and version of SW-modules are unique across all updates they identify always exactly the same module. This property is only required in the case of an install/download or cancel operation.
`software`	DependencyDescription	optional	In the case of a remove operation status, the currently processed software	Can be used to indicate the currently removed software.