> For the complete documentation index, see [llms.txt](https://docs.augelab.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.augelab.com/function-blocks/blocks-reference/data-logic/flow-control/subsystem.md).
# Subsystem
This function block acts as a self-contained workflow container. Use it to group related processing steps into a separate, editable workspace so complex scenarios stay organized and easier to manage.
## 📥 Inputs
`No default inputs`\
This block does not declare inputs by itself. Inputs can be created by adding input sockets inside the subsystem workspace and exposing them at the block boundary.
## 📤 Outputs
`No default outputs`\
This block does not declare outputs by itself. Outputs are defined by child blocks placed inside the subsystem and exposed as the subsystem outputs.
## 🕹️ Controls
`Open Subsystem Editor`\
Open the subsystem workspace to add or edit the contained workflow. (Typically available by double‑clicking the block or via the block context menu.)
`Expose Input`\
Create an input socket inside the subsystem and expose it on the block boundary so the parent flow can feed data in.
`Expose Output`\
Create an output socket inside the subsystem and expose it on the block boundary to send results back to the main flow.
`Run / Debug Inside`\
Run and debug the contained workflow independently from the main scenario to validate its behavior.
## 🎯 Key Features
* Encapsulation: Group preprocessing, detection, tracking, and export steps into a single reusable unit.
* Local workspace: The subsystem has its own editable canvas so you can design complex behavior without cluttering the main flow.
* Clear boundaries: Expose only the inputs and outputs you need, keeping the main graph simple.
* Isolated testing: Open and run the subsystem workspace to debug or validate sub-flows independently.
* Reusability: Build a tested subsystem once, then reuse it across multiple projects.
## ⚙️ How it runs
* When the scenario executes, the subsystem runs its internal workflow.
* Data flows into the subsystem through the input sockets you exposed inside it.
* Child blocks inside the subsystem compute their results in sequence.
* Outputs that you exposed inside the subsystem are collected and returned to the parent flow as the block outputs.
* If a child block inside the subsystem reports an error or an invalid state, the subsystem will reflect that status so you can locate and fix the issue inside the workspace.
## 📝 Usage Guidelines
1. Add a `Subsystem` block to your main flow to hold a complex sequence (acquisition → processing → export).
2. Open the subsystem workspace (`Open Subsystem Editor`) and add the needed blocks.
3. Inside the subsystem, expose only those inputs and outputs required by the parent flow.
4. Test the subsystem independently using the internal run/debug controls before integrating it into the main scenario.
5. Reuse and duplicate subsystems for similar tasks to speed up development.
## 💡 Tips and Tricks
* Group a complete camera pipeline inside a subsystem: use `Camera USB` or `Camera IP (ONVIF)` → preprocessing blocks like `Image Resize` / `Blur` → detectors such as `Object Detection` or `Find Object` → visualization with `Draw Detections` → storage with `Image Logger` or `Image Write`.
* For tracking flows, place `Object Detection` (or `Object Detection - Custom`) and `Object_Detection_Tracker` inside a single subsystem so tracking logic and post-processing stay together.
* Encapsulate heavy AI steps like `Super Resolution`, `Depth Estimation (DepthAny. V2)`, or `Background Removal (RMBG-1.4)` inside subsystems to make it easy to enable/disable or replace models without disturbing the main flow.
* Use subsystems to implement multi-stage analysis: e.g., ROI selection with `Image ROI Select` → shape analysis with `Find Contour` / `Measure Position Distance` → result formatting with `Data to JSON`.
* When building intersection or traffic analytics, keep detection and tracking in one subsystem and aggregation/export (for example the `Traffic Intersection Analysis` block or `CSV Export`) in another to separate concerns.
* For data passing and local state, combine subsystems with `Data Write Local` and `Data Read Local` to maintain local memory without polluting global flow.
* When troubleshooting, open the subsystem and run only its contents to quickly identify which internal block is causing invalid or unexpected outputs.
## 🛠️ Troubleshooting
* `No outputs appearing`\
Confirm you have exposed outputs inside the subsystem. If nothing is exposed, the block will not return data to the parent flow.
* `Inputs not received`\
Make sure you created and exposed input sockets inside the subsystem and that the parent flow is connected to those exposed inputs.
* `Child block reports invalid`\
Open the subsystem workspace and inspect child blocks. Errors inside the subsystem will surface there—fix the child block configuration or replace the problematic block.
* `Performance issues`\
If the subsystem contains heavy processing (AI models, super-resolution, large batch operations), consider profiling inside the subsystem and moving non-essential processing to separate, on-demand subsystems.
* `Need to reuse or version`\
Duplicate the subsystem and keep one testable copy. This makes it safe to try different parameters or models without affecting the production flow.