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/device-management/
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 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 and
Attributes that describes the thing in more detail.
See 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.
The identifier could reference a device abstraction (e.g. an “Information Model” created with Eclipse Vorto).
See 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.
Metadata
A thing may optionally contain metadata information, e.g. about single feature properties, complete features and also attributes or other data stored in a digital twin (thing). This metadata can contain additionally information which shall not be treated as part of the twin’s value, however may be useful to provide some context of the twin’s data.
Metadata has not its own API but can only be updated/set while modifying the state of a twin as a side effect. By default, metadata is not returned at API requests, but must be asked for explicitly.
See Eclipse Ditto documentation.
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 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.
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.
See Concepts > Feature and its definitions.
Properties
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.
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 Concepts > Policy.
Connection
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.
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.
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.
See 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 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.
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.
Announcement
An announcement is published to announce something before it happens, for example to report that a subject in a policy entity is about to expire.
Example: See Policy > Subject expiry.