Pipeline Actions

Pipeline Actions are the building blocks of SDA Pipelines. Each action represents a discrete, deterministic OT operation that can be executed on a single device or across an entire fleet. Actions are orchestrated in the cloud and securely executed through the SDA Gateway, ensuring local OT execution without exposing the control network.

Not all actions are supported by every vendor. Capabilities depend on APIs, engineering tools, and protocol access provided by each platform. Refer to the Pipeline Action Capability Matrix by Vendor for vendor-specific compatibility.

The following sections describe each available Pipeline Action.

Project Backup

Performs an automated backup of a PLC, HMI, or drive by retrieving the project, program, or configuration files from the device. SDA stores the resulting backup in the Project repository, versioned and timestamped. This ensures consistent recovery points, reduces manual engineering work, and maintains historical traceability.

Typical uses:

  • Daily or weekly backup schedules

  • Backup-before-deployment workflows

  • Audit compliance and version retention

  • Capturing changes made at the machine

FTP Backup

Connects to a device or file system over FTP or SFRP to retrieve backup files, configuration sets, program archives, or logs. Ideal for devices that expose file access via FTP but do not support native project backup APIs.

Typical uses:

  • Drive/motion controller backups

  • Robot configuration backups

  • Log and diagnostic file extraction

SMB Backup

Uses the SMB/CIFS protocol to access shared folders on devices or engineering hosts to retrieve backup artifacts. Common in OT environments where Windows-based engineering tools store project files on shared directories.

Typical uses:

  • Backing up projects or recipes stored on Windows panels

  • Retrieving shared configuration files

  • Accessing device-specific project directories

Deployment

Deploys a project version from the SDA repository to one or more devices. This action typically uses vendor-provided engineering software, APIs, or CLI utilities running locally through the Gateway.

Typical uses:

  • Production rollouts

  • Multi-device deployments

  • Automated “build → deploy → validate” workflows

Update Device Firmware

Updates the firmware on supported devices using vendor-approved firmware packages. SDA ensures that firmware files are stored securely and updates run in a controlled, step-based process.

Typical uses:

  • Standardizing firmware across production lines

  • Security patching cycles

  • Automated maintenance windows

Read Variables from Device

Reads runtime variables, tags, or data points from a device. SDA stores the captured values as part of the pipeline execution log and makes them available for downstream steps.

Typical uses:

  • Pre-deployment safety checks

  • Capturing machine state before updates

  • Parameter audits and compliance verification

  • Getting device parameters for an API integration/logic

Write Variables to Device

Writes one or more runtime variables or parameters to a device. Values can be defined statically in the pipeline or dynamically passed from previous steps.

Typical uses:

  • Setting machine parameters

  • Updating counters or timestamps

  • Preparing devices before deployment or testing

Device Snapshot

Captures a point-in-time snapshot of device metadata and operational characteristics. Depending on vendor support, this may include firmware versions, IP configuration, device health, project name, diagnostic counters, and other system information.

Typical uses:

  • Baseline recording ahead of deployments

  • Health checks

  • Asset inventory updates

Rotate Control Password

Updates control-level secret (passwords/credential, certificates, or token) on supported devices. This action ensures consistent credential rotation aligned with corporate security policies. Secrets are stored in a Security Hub - Vault.

Typical uses:

  • Monthly or quarterly password rotation

  • Security compliance workflows

  • Fleet-wide credential hardening

Library Upgrade

Upgrades libraries or code modules inside a PLC project according to vendor-supported mechanisms. This action enables centralized enforcement of library versions and common code standards across engineering teams.

Typical uses:

  • Updating shared function blocks across machines

  • Enforcing standard library versions

  • Preparing projects before deployment

PreviousUsing PipelinesNextPipeline Action Capability Matrix by Vendor

Last updated