Core concepts
Core concepts
Understand the main objects and data flow in Embeint HTF.
HTF separates test execution at the jig from oversight in the application. These are the main pieces you will work with.
| Term | Meaning |
|---|---|
| Organisation | The team and access boundary for people, projects, and stations. |
| Project | A product line or test programme. Projects group stations, firmware images, DUT records, and results. |
| Station | A provisioned test jig with its own identity, credentials, status, and run history. |
| Run plan | The ordered stages and settings that tell the station what to do for a DUT. |
| DUT | The device under test, identified by the ID supplied for a run. |
| Stage | A unit of work such as erasing, flashing, validating, or calling a service. |
| Run | One execution of a plan for a DUT, with an outcome, stage results, events, and logs. |
How a run moves through HTF
- An operator or service starts a run for a station and DUT.
- HTF sends the run command to the connected station over MQTT.
- The Python runtime executes the configured stages and reports progress, logs, and results.
- The application stores the result so the team can inspect the run later.
Station identities are separate from human users. Each station has its own credentials and can access its own station operations. Human access is managed through organisation, project, and station permissions.
Where to go next
- Station configuration explains the YAML plan and stage types.
- Run results and logs shows how to investigate failures.
- DUT records and IDs covers production identifiers.