Glossary

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

Suite authorization

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 assets.
Find details at Introduction > Functionality.

Solution

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.

Namespace

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 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.

Digital Twin

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.

Thing

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 Basic concepts > Things.

Definition

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 namespace:name:version.

note The identifier could reference a device abstraction (e.g. an “Information Model” created with Eclipse Vorto).

See Basic concepts > Things.

Attribute

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.

ACL

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 HTTP API v1 > ACL.

Feature

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

Definition

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 namespace:name:version.

note The identifier could reference a device abstraction (e.g. a “Function Block” created with Eclipse Vorto).

note 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.

See Basic concepts > Feature and its definitions.

Properties

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

Policy

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 > Policy.

Information model

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.

Tenant

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.

Protocol

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

Command

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.

Event

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.

twin

See Basic concepts > Events.

Message

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 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.

See Basic concepts > 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.

live

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.

Imprint Legal info Privacy statement