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