Scenario Flows
Scenario flows is central concept of Quantotto Environment Monitoring. They are represented by DAG (Directed Acyclic Graph) like objects and allow defining scenario detection pipelines from capture origin (streams) to actions.
We will cover scenario building blocks and then describe how to connect them when composing Scenario Flow.
Building Blocks
When constructing Scenario Flow you will use the following types of objects:
Building blocks (with exception of Streams) are plugin based and can be extended beyond the built-in set. You can review the list of built-in plugins and get details on how to get started creating your own here.
Streams
This is origin of captured data. Stream can denote one device or group of devices (such as, devices from specific site, devices of specific type, just a group of distinct devices). If it makes sense for your Scenario Flow, different types of devices (video / audio) can be combined under the same stream.
Classifiers
Classifier is a parameterized instance of Detection Plugin that will scan data frames from capture devices and detect specific objetcs (such as faces, barcodes), categories (in case of neural net classifiers), or anything else that classifier was designed to detect.
Classifiers can be chained as we will explain in Composing Scenario Flow section. This enables more robust environment monitoring.
Triggers
Trigger acts on continuous stream of results from Classifier/s and allows various logical oprands as well as more complex conditions and compositions.
If there is a match, trigger will fire and generate Trigger Report that will be sent towards Actions layer.
Trigger can accept one or more Classifiers as their input depending on trigger plugin design.
Reviewing the list of available trigger plugins and going through examples of Scenario Flows will solidify the concept further.
Actions
When certain conditions are met (i.e we detected a specific situation monitoring environment with help of Classifiers and Triggers), triggers will fire and we will want to act on these detections. It can be a simple Action of creating a log entry, sending an alert or integrating with some third party systems. That’s where Actions come to play as part of Scenario Flows.
Scenarios UI
Quantotto Management Console’s Scenarios screen allows admins to manage and compose Scenario Flows leveraging building blocks that we mentioned above.
Scenario Flows can be grouped together. This creates more hierarchical structure and also plays a role in Scaling Server Side deployment. Single or multiple Scenario Groups can be assigned to specific deployment cluster/s to spread the load.
Tree View
On the left side of Scenarios screen, you will see tree view displayed with Scenario Flows disp;ayed under one or more Scenario Groups. Scenario Group is shown as folder and Scenario Flows are leaf objects.
Enabled Scenario Flows will have a checkmark icon left to their name. You can create / rename / delete Scenario Groups using context menu commands. Scenario Flows can be created / deleted / enabled / disabled through context menus.
When Scenario Flow is selected, its greph will be shown on the right pane. This graph can be modified and saved. Specifics of composing Scenario Flow graphs are discussed in the next section.
Composing Scenario Flow
Working with Scenario Flow graph will consist from a few UI operations:
- Invoking context menus
- Dragging and dropping objects
- Editing object properties
Next sub-sections will describe how to:
- Add new node and edit its properties
- Connect nodes (adhering to connectivity rules) and edit connection properties
Adding New Node
When you right click on the graph pane, context menu will come up with available node types to add: Streams, Classifiers, Triggers and Actions. All nodes, except for Streams, will have sub-menus listing relevant plugins or objects to choose from. After clicking on desired object menu, new node will be added to Scenario Flow and its Properties page will automatically show. You can also invoke the same Properties dialog by double-clicking on existing node or right-clicking and choosing “Properties” from context menu.
Actual Properties will depend on node type. “Name” and “Description” will be there for any node. The rest will differ.
- Streams:
- Devices: this is a tags list field where you enter device URIs prefixes. Each time you finish typing new prefix, press
key to add it to the list. URI prefixes allow you reach any specificity level you need to cover range of devices. Here are a few example: - “video://main”: all video devices from “main” site
- “beacon://”: all beacon sensor devices across all sites
- “video://main/cam1”, “audio://main/mic1”: “cam1” camera from “main” site and “mic1” microphone from “main” site
- Devices: this is a tags list field where you enter device URIs prefixes. Each time you finish typing new prefix, press
- Classifiers will have no additional parameters to configure as it was done when creating and/or training classifier based on Detector plugin in the Classifiers UI screen
- Triggers:
- Trigger parameters: each plugin will expose its own list of parameters and these will be displayed dynamically. Please consult plugin documentation for more information about its configuration and parameters meaning.
- Observables: ordered tags list of trigger variable names. Each denotes an input from specific classifiers’ results stream. Each Classifier -> Trigger connection creates an input observable and connection property will specify which observable exactly it refers to (trigger var property)
- Actions:
- Action parameters: similar to trigger, action plugins will expose their unique parameters. Please consult plugin documentation for more details.
NOTE: alert_and_log built-in Action must be added to Scenario Flow in order to generate Events / Alerts that are displayed in the Events screen and feed some of the Dashboard cards.
Connecting Nodes
In order to create connection from node A to node B, you should drag node B and drop it on node A. UI will check if connectivity rules are adhered and, if yes, connection Properties dialog will be displayed. In case that nodes are not connectable, user will receive an error message box.
Connectivity rules are summarized in the below table.
| Destination | Stream | Classifier | Trigger | Action | |
|---|---|---|---|---|---|
| Source | |||||
| Stream | X | V | X | X | |
| Classifier | X | V | V | V | |
| Trigger | X | X | X | V | |
| Action | X | X | X | X |
For example, it is OK to connect Stream with Classifier, but it is NOT allowed to connect Stream to Action.
Stream can be source node only. Action can be destination node only.
Connection Properties
Common Properties for all connections are “Name” and “Description”. The rest of the properties will be dynamic and determined by Source and Destination nodes. Additional properties will show when Classifier is connection source (no mattter which destination) or when Trigger is destination (no matter which source).
- Classifier source:
- condition: boolean expression that will be evaluated on classifiers results to decide whether Frame Pipeline should send specific result to destination node
- Trigger destination:
- trigger_var: name of trigger variable that this connection represents. Normally, trigger source is a classifier, so it is recommended to give it the same name as source classifier.
NOTE: Please refer to Frame Pipeline documentation for more information on how Scenario Flows are processed by Server-Side components.
Doc TODO: Examples