Part 20: File Transfer
| Document number | OPC 10000-20 |
|---|---|
| IEC designation | IEC 62541-20 |
| Colloquially | Part 20 |
| Group | Utility |
Part 20 defines how files move over OPC UA: a FileType object with open, read, write and seek methods, a directory type for creating and deleting files, and a temporary-file mechanism for generating a file on demand. It is how firmware, recipes, nodesets and log files travel.
The FileType object
A file is an Object in the address space, not a byte array in a Variable. FileType exposes Open, Close, Read, Write, GetPosition and SetPosition methods, plus properties for Size, whether it is writable at all, whether it is writable by the current user, how many clients have it open, and its MIME type. Open takes a mode and returns a file handle; every subsequent call passes that handle. The handle belongs to the session that opened it, so it dies with the session.
Open modes and reading in chunks
The open mode is a bit mask combining read, write, erase-existing and append. Read and write are not usefully combinable on most implementations, so pick one. Reads are bounded by the server's maximum message size and chunking limits, which means a large file has to be pulled in a loop of modest reads - tens of kilobytes at a time is the pragmatic range - rather than in one call that will come back as BadResponseTooLarge or BadEncodingLimitsExceeded.
Directories and temporary files
FileDirectoryType lets a client enumerate a file system exposed by a server and create, delete, move and copy entries, which is what a log-download or a recipe-management interface is built on. Separately, a temporary-file transfer type covers files that do not exist until you ask for them: a method generates a file for reading - a report, an exported nodeset, a diagnostic bundle - and another generates one for writing, followed by a commit that hands the uploaded content to the server. The commit is asynchronous and reports its progress through a file-transfer state machine.
What uses it
The device information model's software-update mechanism moves firmware through Part 20. Nodeset export from a live server, recipe and program download to a machine, certificate and trust-list distribution, and log or diagnostic retrieval all use the same object types. That is the reason to learn it: it is rarely the headline feature of an integration and frequently the part that decides whether commissioning is a one-day job or a week.
What it defines
| Concept | What it is |
|---|---|
| FileType | The object type representing one file, with methods rather than a value attribute. Everything file-shaped in OPC UA is one of these. |
| Open and Close | Open takes a mode bit mask and returns a handle scoped to the session. Close releases it. Failing to close leaves the file open until the session ends. |
| Read and Write | Transfer a bounded number of bytes at the current position. Bounded by the server's message and chunk limits, not by the file size. |
| GetPosition and SetPosition | Explicit seek within an open handle, which is what makes resuming an interrupted large transfer possible instead of starting again. |
| Size, Writable and UserWritable | Whether the file can be written at all and whether this session may write it - the same capability-versus-permission split as AccessLevel on a Variable. |
| OpenCount | How many handles are currently open on the file. A non-zero count after a client crash tells you a handle is stranded until its session times out. |
| MimeType | Declares what the content is, so a generic client can decide whether to show it, save it or hand it to a parser. |
| FileDirectoryType | Directory objects with methods to create files and directories, delete them, and move or copy entries. The basis of any log or recipe browser. |
| Temporary file transfer | Methods that generate a file for reading or for writing on demand, for content that is produced rather than stored - reports, exports, diagnostic bundles. |
| File transfer state machine | Tracks an asynchronous commit through its states, so a client polls the transfer rather than blocking on a method that cannot return in time. |
Do you need to read it?
Anyone doing firmware or recipe management over OPC UA, and anyone extracting a nodeset or a diagnostic bundle from a live server. Client developers need the chunking discipline; commissioning engineers need to know a file interface exists at all, because it is often the only supported way to get a configuration into or out of a device.
Traps that trace back to this part
- The open mode is a bit mask and combining read with write generally fails. Open for reading or for writing, and where you need both, do two transfers. Servers differ on which combinations they accept, so treat anything beyond a single mode plus append or erase-existing as unsupported.
- A file handle belongs to the session. A client that crashes or reconnects without closing leaves OpenCount elevated and, on some servers, the file locked until the session times out - which can be an hour. Close handles in a finally block, and set a realistic session timeout on a client that transfers files.
- Read size is limited by transport limits, not by the file. Asking for a ten-megabyte file in one Read returns BadResponseTooLarge or BadEncodingLimitsExceeded, which looks like a permissions or a corruption problem. Loop with modest reads and use SetPosition to resume.
- A temporary-file commit is asynchronous. The method returns having started the transfer, not having completed it, and the outcome arrives through the transfer state machine. Client code that treats a Good result from the commit as success will report a successful firmware update that never applied.
Last verified 7 September 2026 against OPC UA 1.05.07. The specification parts themselves are published by the OPC Foundation. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.