DRIVR features a flexible yet compact data model in order to allow modeling and structuring IoT systems and their activity in the cloud. As an example a physical device could be modeled as a Component in DRIVR, a group of related devices could be modeled as a System. All of those so-called Resources are available via our GraphQL API, some of them are available via our MQTT API.

Domain

DRIVR supports multiple tenants in one instance, they are called Domains. A Domain organizes users, organizations, and systems of one DRIVR customer. Outside of a complex enterprise context, you will most likely use a single DRIVR Domain for your company or organization. A Domain isolates all tenants' data and ensures that you and everybody else can only access data from their respective domain.

Example: Your company Blue Sun, that specializes in manufacturing photovoltaic systems, aims to enable its customers to effectively monitor their systems by leveraging cloud-based technology.

Account

DRIVR knows two types of Accounts: Users and Organizations. Users can be part of an Organization, but don't need to.

Both Users and Organizations can own the respective Domain and one or more Systems.

Example: You can organize your private customers, such as homeowners with a photovoltaic system installed on their roof, as Users, or you can enable your business customers to organize their employees as Users within an Organization.

Metadata Type

DRIVR supports attaching additional structured data on entities. This is supported for different entities by creating a MetadataType and attaching it to a specific entityType. It injects into the GraphQL API these new fields automatically and allows querying as well as updating the data within the entities metadata via GraphQL.

A MetadataType describes one of these metadata fields. It has a data type of BOOLEAN, FLOAT, INTEGER, STRING, TIMESTAMP or UUID.

Example: For the Organization within DRIVR an additional customer number is required for the Blue Sun manufacturer. For this a MetadataType with name "customer number" is added with entityType=ORGANIZATION and dataType=STRING, which provides the ability to update and create Organizations with the "customer number" field.

Component Model

A ComponentModel serves as a template or blueprint for a Component to model different types of devices. ComponentModels are created on a Domain level, so different Domains have different ComponentModels. In a production or factory environment, a ComponentModel describes the blueprint of an item whilst the Component is one specific item coming out of the production line. Depending on your use case, ComponentModels can represent very big things like complete coffee machines or something small like the switch inside of the machine. A good rule of thumb is to model everything that has any electronic functionality like sensors, switches or in a production sense devices talking locally between each other as their own ComponentModel.

ComponentModels have Services attached to them describing the capabilities you wish to model. ComponentModels can have Metadata attached.

Example: Blue Sun manufactures two types of solar panels, the Blue Sun 100 and the Blue Sun 200 as well as an inverter, the Blue Sun INV. Each of them is modeled as a ComponentModel.

Component

A Component maps every entity belonging to a System, for example a device, a gateway, a module, a part or even a virtual device. Components are instances of ComponentModels. They are the actual devices that send and receive time series data. They have Datapoints attached that are described in the Services and Characteristics connected to the ComponentModel of the Component.

Example: Your customer Schwarz Inc. recently ordered an installation of 5 solar panels and 1 inverter. 3 of those solar panels are Blue Sun 100 units, the other 2 are Blue Sun 200 units. The System therfore has 3 Components of type Blue Sun 100, 2 Components of type Blue Sun 200 and 1 Components of type Blue Sun INV.

Service

A Service is an inventory of capabilities that a specific ComponentModel provides. It can be hardware, software, or a combination of both. For example, a hardware Service might describe the functionality of a 4G module in a smartphone or an environmental sensor in a smart home device. A software Service might describe the functionality of a back-end for a web application or an API for an app. It is possible to attach the same Service multiple times to a ComponentModel with a dedicated index per Service.

Each Service can have Characteristics attached to describe which kinds of capabilities the Service provides for anything that implements the specific Service.

Services can be reused for multiple ComponentModels. Services can have Metadata attached.

Example: Blue Sun solar panels all have a Service called "Power Delivery" which shows information about how much power the chosen solar panel currently and historically produces. It is attached to the ComponentModels Blue Sun 100, Blue Sun 200, and Blue Sun Inv.

Characteristic

Characteristics represent parameters and measurements that describe the functionality a Service provides. A single Characteristic can hold information like minimum or maximum values, a symbol (e.g. °C or Volt) or a set of valid values. They are intended to model very basic information which is comparable over multiple Components of different ComponentModels. The same Characteristic could be used for example as a "target temperature" for a heating system which can also be reused as the "target temperature" for a ventilation system in a car or a fridge for medicine or food.

Characteristics can be reused across Services. Each Service can support any number of Characteristics. Characteristics can have Metadata attached.

Example: We define two Services: Solar Panel service and an Inverter service; plus four Characteristics: Output Voltage, Output Current, Output Power and Surface Temperature. The Solar Panel service holds the Surface Temperature and the Output Voltage; the Inverter Service holds the Output Voltage, Output Current and Output Power. Both Components - the Blue Sun 100 and the Blue Sun 200 use the Solar Panel service, the Blue Sun INV uses the Inverter service.

System

A System serves as a logical group of one or more IoT Components that are usually located at the same geographical location and serve a common system function. A common use case for modeling a System is a group of IoT Components that all communicate locally on the same bus and have one or multiple gateway Components connecting them to DRIVR.

Because a System is only a logical grouping, it can be used for any grouping that makes sense for the individual use case. However, it should be used to model strongly coupled Components.

A System is owned by an Account and can have Metadata attached to it.

Example: Your customer Schwarz Inc. recently ordered an installation of 5 solar panels and 1 inverter, which is represented by a System.

Data Point

A Datapoint stores the actual value for a Characteristic/Service combination for a specific Component at a certain point in time. It is directly attached to a TimeStream.

The Datapoint always has a value from the same DataType as set in the Characteristic. Possible DataTypes are BLOB, BOOLEAN, DATE, FLOAT, INTEGER, JSON, SELECT, STRING, TIME, TIMESPAN, and TIMESTAMP.

Example: At 2:34 pm on May 20th, 2020, the Blue Sun 100 unit with the serial number JFJK-2387482 has an output voltage of 0.5 Vdc.

Time Stream

TimeStreams describe a series of Datapoints which are valid for one specific Component, Service, and Characteristic combination. They are a logical group for the series of Datapoints.

Example: The Blue Sun 100 unit with the serial number JFJK-2387482 has an output voltage in the service power generation.

Distinct Datapoint

DistinctDatapoint is a representation and calculation of Datapoints. They are used to count occurrences of values within Datapoints within a specific time frame for Characteristics or TimeStreams. DistinctDatapoints can round their numerical values, making it easier to group specific values together.

Example: Blue Sun's data scientist wants to know the distribution of the reported output voltages for the Blue Sun 100 unit with the serial number JFJK-2387482 within the last 24 hours.

Aggregated Datapoint

AggregatedDatapoint is a calculation of Datapoints grouped by a TimeStream, Characteristic, Component, ComponentModel, Service, or System. They can be returned for a specific time frame or for all data ever recorded in the specified grouping.

Depending on the DataType of the Characteristic, they calculate the following aggregations:

1. avg: Average value of all aggregated Datapoints for number-like types.
2. sum: The sum of all aggregated Datapoints for number-like types.
3. first: The first element in the aggregate/group. This aggregation works over all data types.
4. last: The last element in the aggregate/group. This aggregation works over all data types.
5. max: The maximum for comparable entities like numbers and dates.
6. min: The minimum for comparable entities.
7. count: The amount of aggregated raw Datapoints.

Example: Blue Sun's data scientist requests the average, minimum, and maximum value of all output voltages from any Blue Sun 100 devices connected to DRIVR between 1 am and 2 pm last Friday.

Distinct Aggregated Datapoint

DistinctAggregatedDatapoints represents and calculates AggregatedDatapoints. Their purpose is to count occurrences of a particular aggregation within a Characteristic or TimeStream for a given result of AggregatedDatapoints.

Compared to AggregatedDatapoints, only a single aggregation type can be returned since DistinctAggregatedDatapoints are intended to measure how often a specific aggregation has occurred within a given group.

Example: Blue Sun 's data scientist retrieves the distribution of the average output voltage of all Blue Sun 100 devices within a 24 hour window, retrieving 50 occurrences of 0.5 Vdc and 40 occurrences of 0.4 Vdc, over 90 Blue Sun 100 devices.

Set Point

A Setpoint is a request to change a specific setting or configuration on a connected device. While the device processes the change asynchronously, the status of the Setpoint can be updated to indicate if it has been processed with ACCEPTED or REJECTED. If a device is offline for an extended time, acknowledgment of the status becomes impossible, and a new request must be sent. Setpoints utilize the same concept of TimeStreams as Datapoints. This means that devices use the same TimeStream to report their current measurement as Datapoints.

Example: At 5:48 pm on April 22th, 2020, the service technician updates the configuration for the Blue Sun INV unit to charge the newly installed battery pack to 90% before feeding electricity into the grid. The Blue Sun INV device reports a battery charge status of 70% At 5:49 pm on April 22th, 2020 on the same TimeStream as a Datapoint.

Distinct Metadata Value

DistinctMetadataValue is a feature that enables aggregation and counting of the Metadata assigned to specific entities. Similar to DistinctDatapoints, it counts the number of values within a given filter.

Example: The Blue Sun company would like to know how many devices have been sold during each promotion they have run. DRIVR stores a buyingPromo key in the Metadata for each device sold during a promotion. By using DistinctMetadataValue, they can query and return the number of devices sold during each promotion.

Event Model

An EventModel serves as a template or blueprint modelling the different types of events that might occur on a System or Component. For example, these can be device warnings, errors, or maintenance events. If an EventModel is configured to be attached to a Component, it may optionally be limited to a specific ComponentModel.

DRIVR understands two types of events: RANGED and SINGLE_POINT. RANGED is an EventModel blueprint that contains a time range specified by dedicated "time" and "end time" timestamps. SINGLE_POINT is an EventModel which contains a single timestamp.

EventModels have a severity which can be one of ERROR, INFO, SUCCESS, or WARNING. EventModels can have Metadata attached.

Example: For the Blue Sun devices, the EventModel is generated with type SINGLE_POINT event modelling an Operation Mode change, and a RANGED EventModel that models an Overvoltage device alert.

Event

An Event is an actual instance of an EventModel which is attached to a specific System or Component. Depending on the attached EventModel's type, it has a "start time" and "end time" timestamp or only one specific "time" element.

Events can have Metadata attached. They have a status of ACTIVE or RESOLVED, which is automatically populated depending on the RANGED or SINGLE_POINT event type. SINGLE_POINT event types do not have a status set. RANGED event types are set from ACTIVE to RESOLVED when they are updated with an "end time" timestamp. Events support manual acknowledgement to track which people have seen it and are taking care to resolve or handle it.

Example: For the Blue Sun 100 unit with the serial number JFJK-2387482 the firmware should be updated. As a prerequisite the device should be removed from the system and rebooted several times. The service technician creates a Maintenance Event with start time and end time, and performs the device upgrade.

Event Aggregation

EventAggregation in DRIVR allows to gain more insights into emitted Events by counting and grouping their occurances over a certain time frame. This helps to understand how often a certain alert has occured over a timespan for a device type.

Example: For all deployed Blue Sun 100 units the Blue Sun's data scientist wants to find patterns over all Events to increase the reliability, longevity of the connected devices, and to find serial faults as early as possible. In order to achieve this they use the event aggregation in DRIVR to count the occurances of suspicious events for the last week and groups them by Blue Sun 100 ComponentModel.

Data Source

As an enterprise, you likely have multiple applications in use beyond DRIVR. DataSources describe other applications that sync and reference entities within DRIVR.

DataSources must set an identifier. It is intended to store which system they are known under: the foreign key, their code, or ID.

Example: The Blue Sun company has a CRM system that has all Organizations in it. A DataSource with name CRM is created, and the Organization Greenergy Inc., which recently bought a couple of Blue Sun 200 units, has a DataSource reference with the ID 12345 of the company of the CRM system.

Role

DRIVR supports a complex authorization system. The Role describes a set of permissions a User has. Roles can be attached to a specific context where they can be assigned. DRIVR by default has the following roles:

1. Domain Admin: The administrator of a Domain. They can read and write everything within the Domain.
2. Domain Maintainer: A role that allows access to all entities within the Domain but does not allow granting additional edit rights on the Domain level.
3. Domain Analyst: A read-only role for all entities within a Domain.
4. System Maintainer: A read/write access to all entities of a specific System.
5. System Analyst: A read access of all entities of a specific System.

More roles can be added dynamically.

Example: The Blue Sun company has service technicians going to customers for maintaining their installed devices. They create in DRIVR a Service Technician role. It is configured to be assignable to the System entity type.

Role Assignment

The RoleAssignment is a connection between a Role, an Account, and an Entity. The Role configuration asserts the entity that can be used for the assignment. This can either be a System or a Domain.

Example: The Blue Sun company assigns a Service Technician called Jane Doe for the System that its customer Schwarz Inc. bought so that the technician can support Schwarz Inc. with their system.