Understanding CAN/CSA ISO/IEC 14776-362-07: SCSI Primary Commands – 3 (SPC-3) – Scope, Technical Requirements, and Compliance

The CAN/CSA ISO/IEC 14776-362-07 standard is the Canadian adoption of the international ISO/IEC 14776-362:2006, commonly known as SCSI Primary Commands – 3 (SPC-3). This standard defines the fundamental command set, device model, and protocol interactions for SCSI logical units, forming the foundation upon which all SCSI device-type-specific command sets (e.g., SBC for block devices, SSC for stream devices) are built. Engineers designing, implementing, or testing SCSI storage subsystems must thoroughly understand this document to ensure interoperability and compliance across serial and parallel SCSI transport layers.

1. Scope and Applicability

SPC-3 specifies the primary command architecture for all SCSI devices, independent of the transport protocol. The standard covers:

• Command descriptor blocks (CDBs) – structures for commands that are common to all SCSI logical units.
• Device server model – behavior of the logical unit when processing commands.
• Status and sense data – response mechanisms to report success, failure, and error conditions.
• Mode parameters – configuration pages that control device behavior.
• Log pages – historical and statistical data collected by the device.

The standard is transport agnostic and applies to SAS, Fibre Channel, iSCSI, and legacy Parallel SCSI implementations. Its requirements are mandatory for any device claiming SCSI compliance.

2. Technical Requirements and Command Set

2.1 Command Descriptor Blocks (CDBs)

Every command begins with a CDB of 6, 10, 12, 16, or 32 bytes, depending on the operation. The first byte is the operation code, which identifies the command. SPC-3 defines the following categories of primary commands:

• Inquiry commands – report device identification, version, and supported features.
• Mode Sense/Select – access and change device configuration parameters.
• Log Sense/Select – retrieve device statistics and diagnostic logs.
• Report LUNs – discover available logical units in a target.
• Test Unit Ready – check if the logical unit is ready for operations.
• Request Sense – retrieve sense data after a CHECK CONDITION status.

2.2 Status and Sense Data

After executing a command, the device server returns a status byte in the FCP_RSP or equivalent. SPC-3 defines eight status codes, the most common being 00h (GOOD) and 02h (CHECK CONDITION). When a CHECK CONDITION is returned, the initiator must issue REQUEST SENSE to retrieve the sense data, which includes a sense key, additional sense code (ASC), and additional sense code qualifier (ASCQ). SPC-3 specifies the format and content of sense data, including fixed and descriptor formats.

3. Implementation Highlights

3.1 Device Model and Command Queuing

SPC-3 introduces a modern device server model with support for tagged command queuing (up to 256 tasks). The standard defines task attributes (SIMPLE, ORDERED, HEAD OF QUEUE, ACA) that govern command execution order and queuing behavior. Hardware and firmware developers must implement the task management model correctly to avoid data integrity issues, especially in multi‑initiator environments.

The model also includes:

• Logical unit number (LUN) reporting through REPORT LUNS and address methods defined in SPC-3.
• Asymmetric logical unit access for active‑active storage controllers.
• Events and asynchronous notification (e.g., unit attention conditions).

3.2 Compliance Levels

SPC-3 is part of a larger SCSI standards suite. Compliance with earlier versions (SPC‑1 and SPC‑2) is maintained through evolutionary design. A device claiming SPC-3 compliance must support all mandatory primary commands and meet the conformance requirements in Annex B of the standard. Vendors often characterize their implementations as “SPC‑3 compliant” after passing the following test categories:

• Command descriptor block parsing and validation.
• Status and sense data formatting.
• Mode and log page handling.
• Task management functions (ABORT TASK, CLEAR TASK SET, etc.).

4. Compliance and Certification Notes

While no single global certification body exists for SCSI, the INCITS T10 Technical Committee maintains the standard and publishes technical corrections. Many storage vendors use industry‑standard test suites (e.g., the SCSI Test Suite developed by the Storage Networking Industry Association – SNIA) to validate SPC-3 compliance.

When designing a product to be marketed as “SPC‑3 compliant,” developers should:

1. Thoroughly review Clause 4 (Device Model) and Clause 5 (Commands).
2. Implement all mandatory commands with correct handling of CDB fields, status, and sense data.
3. Test with multiple initiator types and verify queuing behavior under load.
4. Monitor the T10 web site for proposed changes and project updates.

This article is current as of 2026. Although the SCSI standards continue to evolve (e.g., SPC‑5, SPC‑6), the core architecture established in SPC‑3 remains the baseline for modern SCSI implementations. Engineers working on storage controllers, HBAs, or solid‑state drives will find that SPC‑3 knowledge is indispensable for troubleshooting and ensuring backward compatibility.