# 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. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.augelab.com/function-blocks/data-logic/flow-control/subsystem.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.