This glossary is a collection of terms we often use in this wiki. Feel free to propose further terms which should be defined here.

Bosch IoT Things is the brand for our service offered in the cloud. The service provides a Managed inventory of digital twins for IoT device assets .
Find details at Functionality.

The concept of a digital twin, its definition and thus the expectation vary from one manufacturer to another. At least all publications so far agree upon the task to provide a virtual representation of a physical asset. Adding further information and functionality enriches the digital twin into the more generally assumed holistic view that reflects all capabilities and aspects of a device/product asset.
In the context of Industrial IoT (IIoT) a digital twin is also called (asset) Administration Shell.
Bosch IoT Things is a cloud service implementing such a digital twin / administration shell concept for physical assets.
These digital twins can contain the virtual representation of a physical asset as well as other information and functionality to provide a holistic view accessible by API.

An asset can be anything from a tangible and physical device to the more intangible such as a system or the reputation of a company.
In our context, we define an asset as any item, entity, application or even system of applications that can be registered at the Bosch IoT Suite.

A namespace is used to organize objects of various kinds.
In Bosch IoT Things we use the namespace to separate things from different solution spaces from each other. Therefore, all thing IDs are composed following the pattern: namespace:thing-name.
See Namespace.

A thing is the digital representation of an IoT device or any type of asset.
The entity - also known as digital twin - is used in general to cluster multiple Features and manage the access to the data and functionality the thing represents. A thing may have additional meta data (Attributes) that describes the thing in more detail.
See Things and features.


Attributes describe the thing in more detail and can be of any type. Attributes can be used to find things.

Attributes are typically used to model rather static properties at the thing level. Static means that the values do not change as frequently as property values of features.


An access control list (ACL) holds the current status on who (subject) is permitted to which extent (read, write, administrate) to manage a Thing.
See Access Control List (ACL).

A feature represents a set of properties and functionalities of a thing. The structure and meaning can be specified by referencing a definition.
See Things and features.


A definition can optionally be related to a feature.

A definition derived from a Eclipse Vorto information model can be used for contract-based development.
Contract-based development is especially useful for large-scale and cross-domain solutions.
See Feature definition.


A feature may consist of a distinct set of properties which are functional/logically coherent.

A policy enables fine-grained access control for things and other entities.
This way, the access to the data and functionality of an IoT device can be given or restricted to specific users and applications. E.g. a device owner should be enabled to see and change all properties of his device, whereas other users can be given only read permission to a subset of properties.
A specific policy defines who (authorized subject) is granted/revoked permission (e.g. read or write) on a specific (sub-)resource of a thing/entity.
See Basic concepts > Policies.

The Bosch IoT Things protocol covers two communication channels to address two different aspects of devices and their digital representation: twin and live.


A command is a request to change a thing, its attributes, features, property values, etc.
A twin command is always addressed to the Things service, where the thing entities (also known as digital twins) are stored.
A live command is addressed to a client. The Things service will not process the command, but only route such a command and take care that only clients with a respective permission receive the command.


An event reports that a change has been applied to a thing entity. Important is the “past tense” here; it took already place (it was for example persisted into the data store) and cannot be reversed or stopped.

Example: A property value of a feature is modified.

See Events.


Messages can be used to transport arbitrary data between IoT devices and applications.

To invoke e.g. an operation on a device, a message can be sent to the thing or one of its features.
You can send messages to or from a thing by specifying a subject which defines the meaning of the message. Messages contain custom payload with a custom content-type.

A message does not directly affect the state of a thing entity, but needs to be handled respectively by your device or application.
See Messages.

Example: From an application's perspective, a message can be sent to a thing or one of its features to call e.g. an operation at a device.

Messages do not affect the state of a thing entity or a device. Therefore, Bosch IoT Things does not handle messages like commands: there are no responses which are produced by our service and no events which are emitted for messages. Instead, the message needs to be handled respectively by your solution.

The open source project Eclipse Vorto uses information models for modeling descriptions of devices.
Information models describe the attributes and the capabilities of real world devices. These models can be managed and shared within the Vorto repository. In addition, Vorto provides a code generator extension point where code generators can be plugged in.

A tenant is an organizational element that is mostly representative of a company.

In the context of Bosch IoT Hub each service instance has a unique tenant ID, while some Bosch IoT Permissions instances allow to create multiple tenants.

In the context of Bosch IoT Permissions on user login the service knows for which tenant the user is acting. See Bosch IoT Permissions > Concepts > Basic Entities.

A customer with a Permissions and a Hub service instance will need to handle with two different tenant ID's.

The solution entity allows to manage and configure your Bosch IoT Things service subscription.
It allows to retrieve basic information like the type of service plan you have subscribed. Further, you can list or reserve namespaces and setup connection-based integrations of your service instance.
Connections are used to integrate your service instance with your device connectivity layer, application components, or other systems. You can manage, monitor, and configure connections with Bosch IoT Hub, generic AMQP, MQTT brokers, Apache Kafka servers, etc.