Models, Assets, and Providers

Models, assets, and providers form the core data architecture in Beacon Tower. Models define the structure of data (like a blueprint), assets are instances of those models (representing actual devices), and providers connect physical devices to the platform.

• Definitions
• Concept
• Use Cases
• Best Practices
• Workflows

Definitions

Term	Definition
Model	A digital definition that describes the structure of telemetry, properties, and commands that assets can send and receive.
Asset	An instance based on a model representing a physical device, equipment, or logical entity that generates or processes telemetry data.
Provider	An external data service (e.g., Azure IoT Hub) that connects physical devices to Beacon Tower.
Provider Client	An individual device connection within a provider, corresponding to a specific device or data source.
Binding	A mapping that defines how data flows from a source asset or provider client to a target asset.
Provider Template	Pre-configured settings for creating new device connections.

Concept

Models

A model defines the structure of a group of devices. Usually you have one model per product type, and often specific models for different firmware versions if they support different telemetry, properties, or commands. The model is created once, and then assets are created based on that model.

Draft vs Published

Models have two states: draft and published. A draft model can still be edited but cannot be used to create assets. A published model is used to create assets but can no longer be edited. This means a model cannot be improved or updated after it is published; instead, a new version of that model needs to be set up. Then the corresponding assets can be migrated to the new version.

Major and Minor Versions

Models use semantic versioning with major and minor versions (e.g., 1.1, 1.2, 2.1). For example, 2.1 means major version 2 and minor version 1.

Version Type	When to Use	Example
Minor	Adding new telemetry, properties, or commands	1.1 → 1.2
Major	Removing or renaming existing items (breaking changes)	1.2 → 2.0

Beacon Tower automatically detects breaking changes and suggests a major version bump when needed.

Some functionality (like alarms and dashboards) does not consider minor versions, meaning that as long as you keep the same major version, you do not need to update the dashboard or alarm if assets only migrate to another minor version. This reduces the amount of administration required when making minor changes to models.

Migration

Since a model cannot be updated, you need to migrate an asset from an old model to a new model if you want to change its telemetry, properties, or commands. This applies to both major and minor version changes. A migration consists of selecting the old model, which assets you want to migrate, and then the new model to migrate to. You can start a migration either from a model or a specific asset.

Assets

In its simplest form, an asset represents a physical device. But an asset is an abstraction that allows it to be used in more complex ways. For example, you can have an asset source data from multiple other assets, allowing more complex assets (e.g., a factory line asset consisting of multiple machine assets). The abstraction also allows you to switch out the physical device providing data while keeping the asset. This allows replacement of a faulty physical device at a location while keeping the asset and its history.

Providers and Provider Clients

Providers in Beacon Tower are specific integrations to a data source. The most common one is the IoT Hub provider, but other providers can use cloud solutions, files, APIs, or any other type of solution as their data source. The provider translates the source data into the common language in Beacon Tower of telemetry, properties, and commands. Providers are often custom built to allow integration with customer-specific systems.

Provider clients are specific connection instances to a device, making use of a provider for communication. Provider clients are a one-to-one representation of devices delivering data into Beacon Tower. Provider clients are automatically created when creating an asset based on a provider. Normally, provider clients do not need to be managed in standard use cases.

Bindings

Bindings are created on models and are then applied to assets when creating them. A binding specifies the relationship between assets and other assets or provider clients. In its simplest form, it ensures telemetry and properties move from a provider client to a specific asset. But a binding can also contain transforms or logic, allowing unit conversion or calculations to be done as part of that data transfer.

A model can also support multiple bindings, meaning that assets of the same type can source data from different providers depending on which binding is used. Another possibility is that multiple assets can bind to the same data source, meaning that you can have two assets obtaining data from one provider client.

Use Cases

Basic Use Case

The standard use case is that you create a model per product type, and then you create an asset for each new device you onboard. Since this also creates a provider client automatically, the process is quick once the model is properly set up.

Create Customer-Specific Assets

Often there might be telemetry, properties, or commands you do not want a customer to be able to access. The easiest way to achieve this is to create two different models: one for you and one for your customer with less information. You can then create two assets, one based on each model, but link both of them to the same provider client. This allows both assets to receive data, but the customer asset will only receive the data that its model is configured with.

Best Practices

• Plan model structure: Design your telemetry and properties before publishing the model
• Use meaningful names: Choose names that clearly describe what the data represents
• Match device data: Ensure telemetry names match exactly what the device sends
• Add display names: Provide user-friendly names for all items
• Include units: Add semantic types and units for proper visualization
• Version carefully: Use minor versions for additions, major for breaking changes
• Keep display names descriptive: Use names that users can understand without technical knowledge
• Assign dashboards early: Link appropriate dashboards so users can immediately visualize data
• Secure connection strings: Treat connection strings like passwords; only share with authorized personnel
• Use consistent naming conventions: Establish naming patterns for Asset IDs across your organization

Workflows

Model Workflows

Creating a New Model

1. Navigate to Administration > Models
2. Click Add Asset Model
3. Enter the model details:
   • Model ID: Unique identifier (letters, numbers, underscores)
   • Version: Starting version (typically 1.1)
   • Display Name: Human-readable name
   • Model Type: Asset, Provider, or Component
   • Description: Optional description
4. Add telemetry by clicking the Telemetry tab:
   • Click Add
   • Enter Name, Display Name, Schema
   • Optionally add Semantic Type and Unit
5. Add properties by clicking the Properties tab
6. Add commands by clicking the Commands tab
7. Click Save to save as draft
8. When ready, click Publish
9. Select the Organization to publish to
10. Confirm publication

Importing a Model

1. Navigate to Administration > Models
2. Click Import Asset Model
3. Select a JSON file containing the model definition
4. The model is imported as a draft
5. Review and publish when ready

Exporting a Model

1. Navigate to Administration > Models
2. Click the actions menu on a model row
3. Click Export
4. The model is downloaded as a JSON file

Creating a New Version

1. Navigate to Administration > Models
2. Find the published model to update
3. Click the actions menu
4. Choose New Minor Version or New Major Version
5. A draft is created with the new version number
6. Make your changes
7. Save and publish

Note: Use major versions for breaking changes (removing/renaming items). Beacon Tower detects breaking changes and auto-suggests major version bumps.

Migrating Assets to a New Model Version

When you update a model, existing assets remain on the old version. Use migration to move them:

1. Navigate to Administration > Models
2. Click Migrate Assets on the target model, or
3. Open a model and click Migrate Assets in the toolbar

Asset Workflows

Creating an Asset with Provider Data Source

1. Navigate to Administration > Assets
2. Click the Add Asset button
3. Enter an Asset ID (unique identifier, no spaces)
4. Select the Model for your asset
5. Enter a Display Name
6. Optionally add a Description
7. Click Next
8. Select Provider as the data source type
9. Choose the Data Provider (e.g., IoT Hub)
10. Enter the Physical ID for device identification
11. Enter a Display Name for the provider client
12. Select the Authentication Type
13. Select a Provider Template
14. Click Next
15. Select the Organization (if you have access to multiple)
16. Click Next to review
17. Verify all information and click Create

After creation, copy the connection string from the asset view page to configure your physical device.

Managing Asset Dashboards

1. Open the asset view page
2. In the Dashboards card, view currently assigned dashboards
3. Click Add to link additional dashboards
4. Select dashboards from the available list
5. Click the remove icon next to a dashboard to unlink it