Workflows

Sequence workflows

The way to operate the SceneControllerModule is to set a sequence workflow, that defines the functionality. The sequence workflow is a set of information that, in combination with the module twin, configures the SceneController.

To configure the SceneController with sequence workflows, create the sequence workflow in an appropriate text editor (for example Visual Studio Code) and use the Direct Command "SetSequences" to upload and save the sequences. After validation, the workflows are saved in persistant storage on the edge device, such that the sequence workflows are always loaded on startup.

Sequences

Sequence workflows have the following structure:

Sequence workflow class diagram

The lights, light settings and scenes are globally defined for all workflow sequences. This means, that it can be used in all sequences.

Light

Lights require a channel, that defines the port on the lighting controller where it is connected. Channel 0 is the first port.

LightSetting

A light setting defines the light level of a light. The possible light levels must be between 0 and 255, where 0 is off and 255 is full illumination.

Scene

A scene is a collection of light settings, that defines the lighting settings for an image acquire operation.

Sequence

A sequence is a collection of steps, that can be executed. Each step represents an action, that carries out a task.

SequenceTrigger

Sequences can be triggered in different ways, and all sequences require a SequenceTrigger that defines how.

Step / Activity

Sequences consists of steps, that all have an Activity. The Activity defines the action that is performed upon execution. A Parameter property defines the settings required by the individual activities.

Workflow State

When the sequence workflow executes, it has an internal state that exists during the lifetime of the workflow. The sequence workflow state is a collection of measurements, that can be of "Analog", "Digital" and "String" type.

Sequence workflows, when they are triggered, always gets populated with the following states:

  • id: Unique instance id that identifies this sequence workflow execution

  • workflowid: Id of the sequence workflow that is executing

  • pixelformat: Pixel format that is configured on the camera

  • imageheight: Image height configured on the camera

  • imagewidth: Image width configured on the camera

  • cameravendor: Camera vendor used

  • cameramodel: Camera model used

The following ways to further populate the sequence workflow state exists:

  • Initial State: When triggering the sequence workflow from a Direct Method, it is possible to set the initial state in the direct method command.

  • SetState Activity: An activity named "SetState" is used to sample a tag measurement, and save it to the workflow state.

  • ExecuteModel: When executing a custom model, the output from the model is automatically saved as workflow states. This means that the model output is available directly after execution. Each custom model execution also gets it's own working folder directory, for storing the files (images, json documents, etc.) that relate to the particular execution. This folder name is also stored as a workflow state called "workingdirectory".

The way to extract workflow states during the execution, is to use one of the following activities:

  • PublishState Activity: Publishes a sequence workflow state as a measurement, sending it to DataDistributionModule, where it is distributed to other subscribers (or cold/hot path storage).

  • WrapResult Activity: Saves sequence workflow states into a file, that is stored in the working directory of the workflow.

Workflow states can also be used in "ConditionalBranch" and "ExecuteModel" activities, or as part of the image file name in the "AcquireImage" activity.

The sequence workflow execution lifecycle: When the workflow sequence is triggered, a new workflow state is initialized with all the default workflow states described above. It is ensured, that an instance of the workflow is not already running. If it is, the current instance is abandoned. The workflow executes activities ordered by the order property. The lowest order is executed first, and no duplicate order is allowed. The possible activities are listed in the figure, and they are resonsible for manipulating the workflow state, acquiring images, setting lighting scenes and similar actions. If an activity fails (camera not online, lighting controller not responding, tag not defined ..) it is possible to define new activity execution path, such that you can implement a "fast fail" strategy (where the workflow fails fast instead of trying to complete every step) or for example retry logic.

Workflow execution

When the workflow is complete, either if there are no more activities, or if an EndWorkflowActivity is encountered, the result of the workflow (succeeded or failed) and statistics about the actual execution flow is logged to Application Insights as a custom event.

Here is an example of a custom event:

{
    "UtcTimestamp": "05/03/2023 19:34:21",
    "moduleid": "SceneControllerModule",
    "deviceid": "tc-edge-cvdev-01",
    "LightingChangeTimeMs": "185",
    "Id": "a5088ea9-9d45-4c28-b6db-b429fcea81cc",
    "ExecutionPath": "0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15",
    "StepsExecutedCount": "16",
    "ModelExecutionTimeMs": "14",
    "MeasurementIoTimeMs": "4",
    "StepsFailedCount": "0",
    "SequenceId": "1",
    "TotalExecutionTimeMs": "512",
    "ImageAcquireTimeMs": "295"
}

The properties are:

  • UtcTimestamp: Timestamp of the workflow execution start in UTC

  • ModuleId: Custom event is comming from the SceneControllermodule

  • DeviceId: Name of the IoT Edge device

  • Id: Unique identification of the workflow instance

  • ExecutionPath: Ordered list of the workflow activity steps that were run during the execution

  • StepsExecutedCount: Number of activity steps run

  • StepsFailedCount: Number of failed activity steps during execution

  • LightingChangeTimeMs: Time spent on communicating with the lighting controller measured in ms

  • ModelExecutionTimeMs: Time spent on executing custom models measured in ms

  • MeasurementIoTimeMs: Time spent on reading and writing to tags measured in ms

  • ImageAcquireTimeMs: Time spent on acquiring and saving images to files, measured in ms

  • TotalExecutionTimeMs: Total time spent on executing the workflow sequence

Last updated

Was this helpful?