This glossary is a collection of terms we often use in our documentation. Feel free to propose further terms which should be defined here.
Bosch IoT Suite
The Bosch IoT Suite provides middleware capabilities needed to build sophisticated IoT applications from top to bottom. It is provided as a set of cloud services.
Bosch IoT Suite package
A pre-configured instance composed of at least two Suite services. See https://docs.bosch-iot-suite.com/asset-communication
The Bosch IoT Suite portal provides authorization functionality like creating OAuth2 clients. See https://accounts.bosch-iot-suite.com/oauth2-clients/
Developers can define Clients for a specific Scope.
This component is not subject to be made available like the other Bosch IoT Suite services, but is usable implicitly for all service instances subscribed as a package.
Bosch IoT Things
Bosch IoT Things is the name for this service offered in the cloud. The
service provides a Managed inventory of digital twins for IoT device
Find details at Introduction > Functionality.
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.
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:
See Basic concepts > Namespace.
Asset - or IoT Asset
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.
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.
A thing is the digital representation of an IoT device or any type of
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 Basic concepts > Things.
A thing may optionally contain a definition describing which model the thing adheres to. It holds a fully qualified identifier.
The pattern for a valid identifier is
The identifier could reference a device abstraction (e.g. an “Information Model” created with Eclipse Vorto).
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
See HTTP API v1 > ACL.
A feature represents a set of properties and functionalities of a
thing. The structure and meaning can be specified by referencing a
See Basic concepts > Things and features.
A feature may optionally contain a definition describing which model the feature adheres to. It holds a fully qualified identifier.
The pattern for a valid identifier is
The identifier could reference a device abstraction (e.g. a “Function Block” created with Eclipse Vorto).
Deviating from the definition field at the thing level, the feature definition field is an array, and thus can hold a comma separated list of multiple definitions.
A feature may consist of a distinct set of properties, which are functional or logically coherent.
The feature properties can represent:
properties(e.g. values as reported by a physical device)
desiredProperties(e.g. values set via a remote management UI, aiming to trigger the device integration layer to change the device configuration).
Each property itself can be either a simple scalar value or a complex object. Allowed is any JSON object.
A policy enables fine-grained access control for things and other
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 > Policy.
A connection in general describes that two parts are linked with each other. In our context, we use the term connection to describe the linking of your Things service instance with other endpoints/servers to integrate them with each other.
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.
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.
Messages can be used to transport arbitrary data between IoT devices and
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 and 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.
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.