# 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*](https://docs.softwaredefinedautomation.io/app/4.-core-concepts-and-features/pipelines/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.&#x20;

**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](https://docs.softwaredefinedautomation.io/app/4.-core-concepts-and-features/security-hub/vaults-and-secrets).

**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
