What ConfirmedPrivateTransfer Is
ConfirmedPrivateTransfer is a remote-device-management service in BACnet, defined in Clause 16.2 of ANSI/ASHRAE 135-2024. A client uses it to invoke a proprietary, non-standard service on a remote device. It is a confirmed service: the device returns a result on success or an error on failure. The standard defines the wrapper, not the service inside it; the actual behavior is whatever the vendor assigns to a given service number.
Every request carries a vendor identification code (assigned to the vendor by ASHRAE) and a service number. Together they identify the proprietary operation unambiguously. Any additional parameters, and their meaning, are entirely vendor-defined.
How It Works
The client sends a vendor ID, a service number, and optional service parameters. The device verifies the request and performs the vendor-defined operation, returning a result that echoes the vendor ID and service number plus an optional result block, or returning an error. Because the parameter content is a local matter between the vendor’s devices, a receiver that does not recognize the vendor ID and service number cannot act on the request and refuses it.
Where You’ll See It
- Vendor extensions. A manufacturer exposes a feature with no standard BACnet service, such as a specialized diagnostic or a bulk configuration operation, through a private service number.
- Tool-to-device operations. A vendor’s own commissioning tool drives device-specific routines that the standard services do not cover.
- Interoperability boundary. A third-party client generally cannot use these services meaningfully, because the meaning of the service number and parameters is documented only by the vendor.
ConfirmedPrivateTransfer Error Codes
Clause 16.2 defines the failure return as an Error Type carrying an error class and error code, but it does not fix a situation-to-code table: the specific errors are vendor-defined, since the service itself is. The general error model lives in Clause 18 of the standard. In practice:
- A device that does not implement the requested vendor ID and service number returns an error rather than a result; a common choice is the
SERVICESclass withSERVICE_REQUEST_DENIED. - The error return also echoes the vendor ID and service number and may carry vendor-defined error parameters, so the client can tell which proprietary operation failed and why.
- No response at all is not a service error. A timeout is a transport or addressing problem, not a proprietary-service problem.
Profiles That Require It
No standardized device profile in Annex L requires ConfirmedPrivateTransfer. It is optional, specialty functionality that a vendor adds for its own devices and tools, so support is declared in a device’s PICS (Protocol Implementation Conformance Statement) rather than mandated by a profile.
What Chipkin Provides
The CAS BACnet Stack supports ConfirmedPrivateTransfer in both directions, giving an integrator a hook to define and answer proprietary services. Talk to us about adding BACnet client or server support to your device.