Siemens STEP 7 Project File Structure dBase Schema and Folder

Overview

A STEP 7 project (file extension .s7p) is not a single binary blob. It is a structured container of dBase III/IV tables, subfolders, link lists, and resource archives that the SIMATIC Manager uses to rebuild the station, CPU, and program tree shown in the project navigator. The on-disk format is intentionally undocumented by Siemens; only the contents of readme.rtf shipped with STEP 7 release 5.6 give an approximate description, as confirmed in the official Programming with STEP 7 manual. Third-party OPC servers, asset management tools, and version-control bridges must parse these files directly when the SIMATIC Manager cannot be invoked.

This reference documents the container layout as observed for STEP 7 V5.x projects containing S7-300 and S7-400 stations, the role of every dBase file, the relationship IDs between tables, and the practical techniques used to read them without the SIMATIC Manager. It also covers the official alternative path for symbol export (S5 SEQ and DIF formats) and the interaction with ProTool .pdb files in mixed PC-based automation projects.

STEP 7 Project Container Architecture

An .s7p file is a Microsoft Compound File (OLE2) container. Inside the container the SIMATIC Manager stores:

• Root object files: the project metadata (objtyp.dat, master S7RESOFF).
• Subfolders that mirror the logical tree: hOmSave7 (offline/save), hOmLoad7 (online view), OMBSTX (offline blocks), YDBs (symbolic lists), hrs (link resources).
• Hardware subfolders: S7HK31AX (S7-300 hardware catalog), S7HK41AX (S7-400 hardware catalog).
• Project history (s7hstatx) that tracks stations and their relationship to CPU and program folders.

The logical hierarchy inside the container is always three levels deep:

1. S7-Station — one per physical or simulated PLC.
2. S7-CPU — one per CPU inside the station (a station can carry more than one CPU).
3. S7-Program — the program folder containing all blocks (OB, FB, FC, DB, SDB, SFB, SFC, UDT) and the symbol table.

Folder Layout Summary

Top-Down Traversal Logic

To resolve a complete station > CPU > program tree, query the dBase tables in the following order. The logic mirrors what the SIMATIC Manager does internally when it opens the project:

1. List stations by filtering HOBJECT1 in hOmSave7\s7hstatx on OBJTYP.
2. Use the station's ID as SOBJID in HRELATI1 with RELID = 16 to get the child TOBJID that points at the CPU folder.
3. Open HOBJECT1 in S7HK31AX (S7-300) or S7HK41AX (S7-400) and match on UNITID = TOBJID to retrieve the CPU name and its own ID.
4. Repeat the parent-child lookup using RELID = 16 against the CPU's ID to obtain the S7-Program folder ID.
5. Open S7RESOFF.DBF at the project root and locate the program entries that match the TOBJID from step 4.

hOmSave7 Station Database

The station registry lives at hOmSave7\s7hstatx. Two tables drive it:

• HOBJECT1.DBF — master object list. Columns used: ID, NAME, OBJTYP, UNITID, PARENTID.
• HRELATI1.DBF — relation list between objects. Columns used: SOBJID (source), TOBJID (target), SOBJTYP, TOBJTYP, RELID.

The relationship type RELID = 16 is the structural parent-child link used throughout the project tree.

Station Object Type Identifiers

Hardware Folder Queries (S7HK31AX / S7HK41AX)

The hardware folders store the rack, module, and CPU objects. They expose the same column layout as s7hstatx but each subfolder is dedicated to a PLC family:

• S7HK31AX — hardware objects of S7-300 stations (IM, SM, FM, CP).
• S7HK41AX — hardware objects of S7-400 stations (UR, CR, ER, FM, CP).

When resolving the CPU that owns a given program:

1. From S7RESOFF, capture the program's ID.
2. Search S7HK31AX\HRELATI1 for rows where TOBJID = program-ID and TOBJTYP = 1331969.
3. From the matched row, take SOBJID and SOBJTYP and look them up in S7HK31AX\HOBJECT1 to recover the CPU display name.
4. For S7-400 stations, repeat the query in S7HK41AX instead of S7HK31AX.

S7RESOFF and the Program Resource Tree

S7RESOFF.DBF at the project root is the master program-resource index. Each row represents either an offline program folder or a system resource. The column most often needed externally is RSRVD4_L: a 32-bit offset, expressed in bytes, that points into the binary resource archive linkhrs.lnk stored in hrs\.

Typical S7RESOFF columns used by parsers:

Decoding linkhrs.lnk and the OMBSTX Folder Mapping

The folder names inside OMBSTX (where the actual block binaries live) do not match the numeric ID in S7RESOFF. To resolve them, read hrs\linkhrs.lnk at byte offset RSRVD4_L for 512 bytes, then search for the magic byte sequence 01 60 11. The two bytes immediately following the magic form a big-endian 16-bit value that is the hexadecimal subfolder name (for example, 00 1A yields folder 0000001A).

Reference Perl idiom:

if ($filedata =~ /\x01\x60\x11(.{2})/) {
    my @xx = unpack("C2", $1);
    my $folder = sprintf "0000%02X%02X", $xx[0], $xx[1];
}

Symbol Table Files

Symbol tables are stored under YDBs, one subfolder per program. Each subfolder contains SYMLIST.DBF, and the parent SYMLISTS.DBF maps programs to their symbol-table subfolder.

SYMLISTS and YLNKLIST Join

To locate the symbol table of a given program, perform a two-table join:

1. From S7RESOFF, capture the program ID (= xxx).
2. From YLNKLIST.DBF, run: SELECT SOI FROM YLNKLIST WHERE TOI = xxx — result is yyy, the linkage ID.
3. From SYMLISTS.DBF, run: SELECT _DBPATH FROM SYMLISTS WHERE _ID = yyy — result is the subfolder, e.g. \YDBs\zzzz\.

SYMLIST Columns

The _OPHIST operand string follows the classic STEP 7 mnemonic grammar and must be re-parsed to recover absolute addresses; the dBase file does not store the resolved byte/bit address. Multi-element operands (UDT members, ARRAY indices) are flattened to the root operand only.

Block Files (BAUSTEIN and SUBBLK)

Code blocks live inside the resolved OMBSTX subfolder. Two dBase files catalog them:

• BAUSTEIN.DBF — one row per block; columns include BLOCKNO, BLOCKTYP (OB, FB, FC, DB, SDB, SFB, SFC, UDT), AUTHOR, VERSION, CRC.
• SUBBLK.DBF — the sub-block list; useful for instance DBs of FBs and for multi-instance UDT structures.

The block binary itself is a separate .awl / .scl / .db file referenced from BAUSTEIN; its content is a S7-pack container that wraps the compiled code or the source. STEP 7 release 5.6 is the last release that ships with the documented block-container specification.

Reading the dBase Files Programmatically

The dBase files have two quirks that frequently trip parsers:

1. The encryption flag (bit 0 of byte 0 of the header) is often set, even though the file is plaintext.
2. The MDX index flag (bit 7 of byte 28) is frequently set, indicating a companion .mdx file that the SIMATIC Manager keeps but does not require for read access.

Perl (DBD::XBase) Approach

use DBI;
my $dbh = DBI->connect(
    "dbi:XBase:/path/to/folder",
    undef, undef,
    { RaiseError => 1 }
);
my $sth = $dbh->prepare(
    "SELECT ID, NAME FROM S7RESOFF WHERE ID = ?"
);
$sth->execute($program_id);
while (my @row = $sth->fetchrow_array) {
    print "$row[0]\t$row[1]\n";
}

C# / OLE DB Approach

The Microsoft OLE DB Provider for Visual FoxPro / dBase handles the files after the flag workaround above. A robust connection string is:

Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\TempDbf;
Extended Properties="dBase 5.0;HDR=NO;IMEX=1";

MS Access

MS Access 2000 (and later, with the deprecated dBase ISAM) can open S7RESOFF.DBF, BAUSTEIN.DBF, and most of the non-encrypted .dbf files directly. MS Access is the fastest path to a manual audit but cannot be scripted headlessly.

Alternative: Native STEP 7 Export Formats

For consumers that only need the symbol table, the SIMATIC Manager Symbol Editor offers four export formats; two of them are open and reversible:

Use the SIMATIC Manager path Options > Symbol Table > Export or, inside the Symbol Editor, Edit > Select All > Copy to push the table to the clipboard and paste it into Excel. The clipboard format is line-delimited:

LL12ks22   M 245.3   BOOL   description 1
LL12ks23   M 245.4   BOOL   description 2
LL12ks24   M 245.5   BOOL   description 3

ProTool PDB Files in STEP 7 Projects

STEP 7 projects for PC-based automation (WinAC, S7-300 with integrated ProTool/Pro RT) carry an additional set of files with the .pdb extension, which are the project databases of the ProTool/Pro HMI tool. These files are independent of the PLC dBase schema and cannot be parsed with the queries above. Their structure is documented only in the legacy ProTool manuals and is out of scope for the block and symbol parser. The official SiePortal note on PDB files confirms that these belong to the HMI part of the project.

Verification and Troubleshooting Matrix

Engineering Notes and Caveats

• The hOmSave7 and hOmLoad7 trees diverge after the first download from a live PLC. Always read from hOmSave7 if you need the as-engineered offline view.
• STEP 7 V5.6 is the last release with this dBase-based layout. STEP 7 within TIA Portal stores projects in a SQLite-backed archive; the queries in this reference will return zero rows if applied to .ap16 / .ap17 containers.
• The 512-byte record size inside linkhrs.lnk was stable from STEP 7 V5.0 through V5.6; do not hard-code 256 or 1024 byte records observed in older S5 archives.
• Reading the files while the SIMATIC Manager holds an exclusive lock can corrupt the encryption header. Always take a copy first.