Scenarios: detailed development methodology

How the platform works and what this means for the administrator

Related screen.

The Platform 4.0 architecture package identifies four functional parts: core, model management, sandbox and integrations. In a small installation, services may run on one server; in a distributed installation, central functions and computation are separated across nodes.

flowchart LR
    C[Camera or external source] --> V[Frame acquisition]
    V --> I[Scenario execution on a compute node]
    R[Models and published scenario versions] --> I
    Z[Camera zones and settings] --> I
    I --> E[Event processing]
    E --> J[Log and operator decision]
    E --> N[Notifications and integrations]
    I --> M[Media data]
    A[Test asset] --> S[Sandbox and test run]
    R --> S
    S --> R

The diagram shows functional relationships, not the order of network calls. The architecture uses containerized services, asynchronous messaging, operational and analytical databases, and separate media storage. In the source documentation, these are Docker/Swarm, Kafka, PostgreSQL, ClickHouse, Redis and S3-compatible storage. The system administrator verifies the actual components in the installation.

The practical consequence is that the stream, graph execution, event registration, its image and notification delivery are separate stages. If an image is missing, do not start by changing the model threshold. If the image is available but the event is not registered, check the event creation/sending node and classification.

Development methodology: from a task to a maintainable scenario

Related screen.

Treat a scenario as a small engineering product: it has a goal, inputs, rules, a version, tests and an owner. The methodology helps the next administrator understand why the graph was designed this way.

Step 1. Describe the condition in ordinary language. For Sigma: “A person without a hard hat is in a production zone; the condition is consistently observed rather than appearing in a single frame; each situation requires one initial event and repeats no more often than the agreed interval.”

Step 2. Separate observations from assumptions. The model sees either a head without a hard hat or a head whose status is unknown. The “unknown” class is not the same as “no hard hat”. Likewise, failing to detect a person does not prove that no person is present when video is lost.

Step 3. Record the agreed rules. Which cameras and zones are involved? What marks the beginning and end of an episode? How should occlusion, skipped frames, shift changes and connection loss be handled? What should be sent to the operator? Which parameters may differ between cameras?

Step 4. Find existing resources. Check the model, scenario and block catalogs. Use a suitable version and a shared scenario with local parameters when the logic is the same. A new copy is justified by a different rule, not just a different workshop name.

Step 5. Prepare assets. Start with a short, clear episode, then add operational and boundary conditions. Include positive and negative examples and mark the expected event time.

Step 6. Build the minimal chain. Frame → model → visualization. Make sure the correct classes appear at all. Then add tracks, zones, time and events one stage at a time.

Step 7. Check the contracts between blocks. Input topic type and name, coordinate system, frame identifier, time units and state reset conditions must agree.

Step 8. Test and document the version. Save the parameters, model set, asset and results. “Works” is too general as a comment; “On asset version 1.2, detected 8 of 9 annotated episodes, 1 false event, missed detection when the head was occluded” is better—if that is what was measured.

Step 9. Roll out gradually. Publish the version, assign it to one camera, check the entire path through to the operator’s decision, then expand to more cameras. Keep the previous working version for rollback.

Distinguish four configuration levels:

Group scenarios by task and name blocks by role: “People in the machine zone”, “Confirm missing hard hat”. Use comments to explain debatable decisions and units of measurement. Do not turn one graph into a collection of unrelated rules for the entire enterprise: such a graph is difficult to test and roll back.