---
source_files:
  - Common/DTS.Common/Enums/SliceSimpleArm/SSACommands.cs
generated_at: "2026-04-16T03:20:30.657524+00:00"
model: "Qwen/Qwen3-Coder-Next-FP8"
schema_version: 1
sha256: "c8e9763507d9b807"
---

# SliceSimpleArm

## 1. Purpose  
This module defines the core command and response enumerations used for communication with a *SliceSimpleArm* (SSA) subsystem—likely a hardware control interface for a data acquisition or sensor system. It establishes a standardized protocol vocabulary: `SSACommand` enumerates the set of actionable operations that can be sent to the device (e.g., arming, starting recording, diagnostics), while `SSAResponse` enumerates the structured responses the device may return, including success/failure states and specific error conditions (e.g., `NoSensorsFound`, `DiagnosticsFailedOffsetTolerance`). This enables type-safe, consistent messaging between software layers interacting with the SSA hardware.

## 2. Public Interface  
The module exposes only two public enums; no classes, methods, or properties are defined.

- **`SSACommand`**  
  *Type:* `enum`  
  *Values:*  
  - `ConfigureDevice` – Request device configuration.  
  - `Diagnostics` – Trigger internal self-diagnostics.  
  - `Arm` – Prepare the device for data acquisition (e.g., enable sensors, set state to armed).  
  - `StartRecord` – Begin recording data.  
  - `CheckForArmed` – Query whether the device is currently armed.  
  - `Disarm` – Deactivate the armed state (e.g., disable sensors, reset state).  
  - `Download` – Request data or logs from the device.  
  - `SetLowPowerMode` – Transition the device into a low-power state.  
  - `Trigger` – Initiate an external or software-triggered event.  

- **`SSAResponse`**  
  *Type:* `enum`  
  *Values:*  
  - `Unknown` – Default/uninitialized response.  
  - `Status` – General status update (non-specific).  
  - `Pass` – Command executed successfully.  
  - `Fail` – Command failed for an unspecified reason.  
  - `SystemNotArmed` – Operation requires the system to be armed (e.g., `StartRecord`), but it is not.  
  - `NoSensorsFound` – No sensors detected during configuration/diagnostics.  
  - `NoEIDsFound` – No Event Identifiers (EIDs) found—likely in configuration or metadata.  
  - `UnknownEIDFound` – An unrecognized EID was encountered.  
  - `NoDASConnected` – Data Acquisition System (DAS) is not connected or detected.  
  - `ExceptionThrown` – An unexpected exception occurred during command processing.  
  - `DiagnosticsFailedOffsetTolerance` – Diagnostics failed due to sensor offset exceeding tolerance.  
  - `DiagnosticsFailedShuntCheck` – Diagnostics failed during shunt calibration check.  

## 3. Invariants  
- `SSACommand` and `SSAResponse` are *mutually independent* enums; no implicit mapping between command and response values is defined here (e.g., `Arm` does not imply a specific response value).  
- All enum values are explicitly named and non-numeric; no implicit integer values are relied upon in this file.  
- No runtime validation or enforcement of command/response semantics is present in this module—validation logic (if any) resides elsewhere.  
- The `Unknown` value in both enums likely serves as a sentinel for uninitialized or unparseable states.

## 4. Dependencies  
- **No external dependencies** are declared in this file (no `using` statements beyond `namespace` scope).  
- This module is part of `DTS.Common.Enums.SliceSimpleArm`, implying it is consumed by higher-level modules (e.g., communication layers, device drivers, UI) in the `DTS.Common` assembly or dependent projects.  
- Likely consumers include:  
  - Device communication handlers (e.g., serial/USB/I²C drivers) that serialize/deserialize `SSACommand`/`SSAResponse` values.  
  - State machines or controllers managing the armed/disarmed lifecycle.  
  - Diagnostic or logging utilities that interpret `SSAResponse` codes.

## 5. Gotchas  
- **Ambiguity in command semantics**: The enum names (e.g., `Trigger`, `Download`) do not specify *how* or *when* they should be used (e.g., is `Trigger` synchronous? Does `Download` require prior `CheckForArmed`?). These rules are not defined here.  
- **No versioning or extensibility guidance**: Adding new commands/responses may break backward compatibility if serialized representations (e.g., over a wire protocol) are assumed fixed.  
- **`Status` vs. `Pass`**: The distinction between `Status` (generic update) and `Pass` (explicit success) is unclear—consumers may conflate them.  
- **`UnknownEIDFound` vs. `NoEIDsFound`**: The difference between these two responses is not documented—consumers must infer whether `NoEIDsFound` implies *zero* EIDs were expected/required, while `UnknownEIDFound` implies *unexpected* EIDs were present.  
- **No error hierarchy**: All failures are flat; no grouping (e.g., "configuration errors", "hardware errors") is provided, potentially complicating error handling.  
- *None identified from source alone.*