If you run a robotics-as-a-service (RaaS) business, you already know that managing your robots is complex. So how do you set up a system to see where every robot is, which customer has it, when it was last serviced, and what components it contains?
You might want to create digital twins so you can understand performance patterns or compare module versions. And, as your fleet grows, you’ll likely want to bring in telemetry data to plan maintenance and spot failures before they happen.
You also need visibility into the business side: which customer site a robot is deployed to, the lease agreement in place, and whether the contract terms are being met.
That’s a lot of moving parts to manage in one system. In this blog, we’ll walk through how to structure your data model, using Starhive as the example system to manage your whole RaaS operation: from robots and modules to customers, sites, and leases.
Deciding your Types
In Starhive, a Type is the blueprint for a group of similar Objects. Each Type defines the Attributes and relationships its Objects will share.
For RaaS tracking, your main Types could include:
-
Robots
-
Modules (motor modules, sensor modules, actuator modules, controller modules)
-
Customers
-
Customer sites
-
Lease agreements
-
Maintenance tasks
Example structure for a robotics-as-a-service solution in Starhive.
You can make this as granular as you need. For example, you might decide to include specific sensor types such as LiDAR, cameras, or proximity sensors. The key is to decide how deep you want to go.
Many robotics companies find this is where their existing tools reach their limit. Most off-the-shelf systems can’t model multi-level component hierarchies, and even fewer can handle the customer and contract data within the same environment.
Starhive’s flexible data model lets you do both. You can create unlimited Types and nest components to any depth you need, connecting them to contracts, telemetry, and tasks all within one platform.
Linking Types together
Once you’ve created your Types, you need to define how they connect.
For example, a delivery robot will have one or more sensor modules installed. Each of those modules belongs to a robot, which is deployed at a customer site.
In Starhive, you link these relationships using the Reference Attribute. This allows you to move seamlessly between related data. When viewing a robot, you can see all its installed modules, its assigned customer, and every active lease or maintenance task — all in one view.
Example relationship map which shows how different types related to your robots connect together in Starhive.
When setting up relationships, you can point them in a specific direction (for example, from robot to module or from module to robot) or in both directions. In most cases, one direction is enough; Starhive automatically displays both sides of the relationship and uses them in automations, searches, and queries. It’s primarily a visual decision for clarity.
Deciding your Attributes
Each Type needs its own Attributes. These are the specific pieces of information you want to store for every Object.
Examples:
-
Robot: robot ID, serial number, model version, next maintenance date, current status.
-
Module: module ID, serial number, prototype flag, manufacturer, last maintenance date.
-
Lease agreement: attached file, start and end dates, agreed usage limits, terms for geofencing.
-
Task: assigned technician, due date, description, affected robots
Example of attributes you could add on a robot.
You can also define status Attributes for lifecycle tracking. A robot might move through planned, in warehouse, deployed to site, in maintenance, and retired. A task will have different states such as to-do, in progress, in review, complete, and cancelled. Starhive supports state transitions between these statuses, allowing you to model each stage of your operational workflow and ensure no forbidden transitions can happen, such as a retired robot going back into deployment without approval.
Attributes for live telemetry
To handle live data, you simply add Attributes designed to receive telemetry values.
For example, a Robot Type could have a decimal Attribute for “usage hours” or “operating temperature”. Once added, these Attributes can be updated automatically via your robot’s API.
If you decide later that you want to store new telemetry data, such as “battery voltage” or “wheel rotation speed”, you can just create new Attributes. It takes seconds, and there’s no need for schema migrations or database rework.
This flexibility is what makes Starhive ideal for robotics companies. As your robots evolve, your data model can evolve with them.
Importing data and setting up automations
Once your Types, relationships, and Attributes are defined, you can start importing data.
You can import from CSV, add records manually, or connect to your existing data sources using Starhive’s Import Connections.
Example of a robot in Starhive with all its related data. Everything is accessible from the robot itself.
From there, automations can take over. You can:
-
Send alerts when maintenance or lease renewal dates are approaching.
-
Automatically create maintenance tasks when telemetry exceeds thresholds.
-
Notify account managers when usage limits in a lease agreement are breached.
These automations transform your asset data from static records into a live operational system. One that helps you make decisions faster and stay ahead of maintenance, compliance, and contract issues.
Final thoughts
For Robotics-as-a-Service companies, effective asset tracking depends on more than location data. It requires a structured, flexible data model that connects robots, components, customers, and contracts.
Whatever tool you choose to track everything should ensure that the structure you need to reflect your operations is easy to build. If you’re ready to replace spreadsheets with a scalable structure that can handle the complexity of modern robotics, Starhive gives you the foundation to do it.
