Assets
Overview
Assets in Sift represent physical or virtual entities that generate time-series data through their Channels. They can represent a wide range of systems, from tangible objects such as vehicles and hardware testbeds to intangible systems like simulators or continuous integration (CI) pipelines. In essence, Assets are the sources of telemetry data, meaning any entities that produce structured measurements over time.
Asset modeling
Asset modeling in Sift is about deciding which physical or virtual systems should be represented as Assets, and how to structure them to reflect your test setup, telemetry flow, or workflow. Good modeling helps ensure that telemetry is organized clearly, supports analysis features like Rules and Runs, and enables long-term reuse and discoverability.
Workflows
Asset modeling in Sift can vary depending on the kind of workflow you're supporting whether it's a physical test setup or an automated pipeline (for example, an automated simulation pipeline). Some workflows benefit from creating multiple distinct Assets to represent different components, while others work best by reusing a single Asset and using Runs to track variations. This approach ensures traceability, avoids unnecessary Asset proliferation, and makes it easy to manage and review test data. The table below summarizes the two most common Asset modeling strategies in Sift:
| Workflow | Modeling strategy | Example |
|---|---|---|
| Hardware testing | Create separate Assets for the test cell and each test article that produce telemetry. Use a Run to capture test execution involving those Assets. If only one component produces data, it can be the sole Asset, and the Run used to record test context. If only the test cell produces data, it can be the sole Asset, with the test article described in the Run. Include serial numbers or other unique identifiers for physical articles. | The Asset thermal chamber represents the test cell, and vehicle 542 represents the test article. Both are included in a single Run. In cases where only the vehicle logs data, it may be the only Asset. |
| CI or simulation workflows | Reuse a single Asset to represent the simulation or CI job. Avoid creating a new Asset for each job instance. Use Runs to track each build or simulation execution. | The Asset sim runner is reused across multiple pull requests. Each CI build is represented by a separate Run linked to that same Asset. |
Rule evaluation
Rules in Sift are evaluated within the scope of a single Asset (in particular, its Channels). This means any telemetry you want to analyze together using Rules must be grouped under the same Asset. For example, if your hardware-in-the-loop (HITL) setup includes Electrical Ground Support Equipment (EGSE), a simulator, and vehicle hardware, you should model this as a single Asset that includes telemetry from all of these components. It is acceptable for multiple clients or data sources to stream to the same Asset simultaneously, as long as they represent parts of the same system or workflow.
Naming conventions
When naming an Asset in Sift, aim to make the name clear enough that anyone can understand three key things about the Asset just by looking at it: its type, a unique identifier, and a modifier that describes its environment or context. A common and recommended convention is to separate these parts with underscores for readability, for example:
| Token | Description | Example (token) |
|---|---|---|
| type | What kind of system, hardware, or software is this Asset? | capsule, rover, thermal-chamber |
| identifier | What uniquely distinguishes this Asset from others of the same type? | sn542, slc40, jdoe-linux-vm |
| modifier | What environment or context is this Asset used in? | sim, hitl, hootl |
| Example (name) | Type | Identifier | Modifier | Description |
|---|---|---|---|---|
| capsule_sn542_sim | capsule | sn542 | sim | This Asset name tells us it is a capsule (type), specifically unit sn542 (identifier), running in a simulation environment (modifier). |
| rover_slc40_hitl | rover | slc40 | hitl | This Asset name tells us it is a rover (type), located at Space Launch Complex 40 (identifier), being tested in a hardware-in-the-loop environment (modifier). |
| thermal-chamber_jdoe-linux-vm_hootl | thermal-chamber | jdoe-linux-vm | hootl | This Asset name tells us it is a thermal chamber (type), identified by the hostname jdoe-linux-vm (identifier), and part of a hardware-out-of-the-loop test setup (modifier). |
Notes
- Do not include special characters in Asset names.
- Use hyphens to separate words or fill spaces within token names.
- Use lowercase letters in Asset names. This is not required, since Asset names are case insensitive, but it improves consistency and readability.
Metadata and tags
While a clear Asset name is the primary way to organize telemetry in Sift, metadata and tags offer a flexible way to extend that context without changing the name itself. These tools can help mitigate some of the tradeoffs involved in naming Assets especially when you want to encode details that may change or expand over time.
Tags are simple, descriptive labels such as simulation, flight, or regression. They're useful for filtering and grouping Assets by type or purpose.
Metadata consists of key-value pairs such as testbed: avi-qual-chamber-3 or build: 4721. These allow for more structured, queryable details that go beyond what fits in a name.
Unlike Asset names, which are fixed once created, metadata and tags can be updated at any time. This makes them especially helpful for evolving projects or workflows. That said, they are meant to complement a clear and consistent naming convention (not replace it). Most interactions in Sift still begin with an Asset name, so clarity at the naming level remains essential.