RDS-PP for wind farms: teaching AI to read the standard

A modern wind farm changes hands with tens of thousands of documents: turbine manuals, electrical schematics, inspection reports, commissioning protocols, SCADA signal lists. Every one of them is supposed to reference the plant structure through a designation code, and in the wind industry that designation system is RDS-PP. In practice, the codes are missing, malformed, or buried in title blocks of scanned drawings, and somebody gets the job of sorting the pile. That job is now automatable, but only if the software actually understands the standard first. So the standard comes first.

Where RDS-PP comes from

RDS-PP, the Reference Designation System for Power Plants, is published by VGB PowerTech (today vgbe energy), the European association of electricity and heat generators. It did not appear from nowhere. Its predecessor, the KKS (Kraftwerk-Kennzeichensystem), was developed by VGB from the early 1970s, first applied at a plant operator in 1976, and published as a guideline in 1978. KKS identified plant equipment with a 15 to 17 character alphanumeric code across four breakdown levels, from the total facility down to individual operating equipment. Two generations of European power plant engineers learned to read it, and a large share of the thermal fleet still runs on it.

In 2007 VGB published RDS-PP as the successor. The important difference is not the letters; it is the foundation. RDS-PP applies the structuring principles of the international IEC/EN 81346 series, so a designation follows a cross-industry structuring standard rather than a convention unique to power plants. The RDS-PP publications and reference tables themselves remain licensed vgbe material. IEC 81346-1 defines the structuring rules, and IEC 81346-2 defines a classification of objects with letter codes, several hundred classes organized in three levels. RDS-PP entered international standardization as ISO/TS 16952-10 in 2008; that document was withdrawn in 2015 and the subject carried into the 81346 series, currently ISO 81346-10:2022 for power supply systems. It is formally a recommendation rather than a legal mandate, and VGB holds the trademark, but in one sector it became the de facto baseline: wind.

The application guideline that did that is VGB-S-823-32, "RDS-PP Application Guideline Part 32: Wind Power Plants", published in March 2014. Wind was a young industry without a KKS legacy, projects are built by international consortia that need one common language, and operators buy turbines from multiple OEMs. Today RDS-PP designations show up in wind turbine purchase contracts, handover requirements, and O&M systems across Europe, which is exactly why the document problem lands on operators' desks.

How a designation is built

An RDS-PP designation is a sequence of blocks, and each block is introduced by a prefix sign that declares which aspect of the plant you are talking about. The public descriptions of RDS-PP cited under Sources list nine of them (prefix sets vary between editions of the underlying standards; IEC 81346-1:2022, for example, added a type aspect):

Illustrative summary prepared from the cited RDS-PP sources, primarily the German Wikipedia article on RDS-PP. This is not a complete or edition-independent specification; check meanings and usage against the standards, guidelines, and editions applicable to your project. No letter-code or system-key tables from the vgbe guidelines are reproduced in this article. For publication and licensing information, see vgbe's identification-system page.

Within a block, letters classify and numbers count. The letters come from the IEC 81346-2 object classes and from the RDS-PP application guideline tables for the sector. To give a feel for the class logic at the top level of IEC 81346-2, as publicly summarized: B covers sensing objects such as temperature or pressure sensors, C covers storing objects such as batteries and tanks, E covers emitting objects such as heaters and lamps, and M covers driving objects such as motors and turbines. A full identifier can carry up to three parts: the conjoint assignment (which plant or unit), the reference designation itself (the function, product, or location chain), and a specific designation such as a signal or terminal.

Read one from left to right and it is a path through the plant: this site, this functional system, this subsystem, this piece of equipment, this signal. The same physical gearbox can be reached through the function aspect (its role in the drive train), the product aspect (the gearbox as a manufactured thing), or the location aspect (where in the nacelle it sits). That multi-aspect view is the whole point of 81346, and it is also what makes naive text matching insufficient: the same object legitimately appears under several designations depending on which question you are asking.

The problem operators actually have

Contracts increasingly require handover documentation to be tagged with RDS-PP designations. What arrives is messier. OEM manuals reference internal part numbers. Subcontractor reports carry the code only in a drawing title block, as pixels. File names encode a designation in one folder and a project manager's mood in the next. Older assets in the same portfolio still use KKS, or a homegrown scheme, or nothing. The operator's asset management system, meanwhile, wants every document attached to the right node of the plant structure so that a technician searching for the yaw system of turbine 14 finds the inspection reports for exactly that yaw system.

Consultancies exist that specialize in cleaning this up, and for structure design and governance that expertise is worth paying for; SøDera in Denmark is one example of a firm built around RDS and IEC 81346 work. The repetitive part of the job, reading each document and deciding which designations it belongs to, is a document intelligence problem. Here is how we would build it.

An architecture for RDS-PP detection

1. Extract text and layout, not just text

Extract in tiers: plain text extraction where the document allows it, escalating to a layout-aware service such as Azure AI Document Intelligence for scans and for documents where the plain pass comes up empty. Layout matters because designations concentrate in specific places: drawing title blocks, headers and footers, tables of contents, equipment lists. A designation found in a title block identifies the document; the same string in a body paragraph may only be a cross-reference. Keep the positional metadata; you will need it to weight matches later. Also harvest the cheap metadata: file name, folder path, PDF properties. In real handover packages, a meaningful share of designations lives in file names alone.

2. Detect candidates with a grammar, not a language model

RDS-PP is a formal notation, so the first detector should be a formal one: a parser built from the prefix signs and block shapes. Something in the spirit of:

// Illustrative candidate detector, not the full grammar
const PREFIX = /(#|==|=|\+\+|\+|-|;|:|&)/;
const BLOCK  = /[A-Z]{1,3}[0-9]{0,3}/;      // letters classify, digits count
const CANDIDATE = new RegExp(
  `${PREFIX.source}\\s?(${BLOCK.source})(\\s${BLOCK.source})*`, 'g'
);

// A hit is only a candidate. Validation happens against the
// project's designation register and the guideline letter tables.

The regex finds shapes, and only shapes: it will happily return a partial match from inside a longer token, so candidates need complete-token parsing and boundary validation before any register lookup. A validator then checks every letter group against the class tables of the application guideline and, more importantly, against the project's own designation register, the master list of designations that actually exist in this plant. A syntactically perfect code that is missing from the register is unresolved, not automatically a typo: it may be an error, an outdated register version, or a legitimate code from another scheme, and flagging it for review is half the value of the system. This layer is deterministic, fast, and cheap to run. Use validated rules and the authoritative register as constraints, and route conflicting evidence to review.

3. Classify the codeless documents with a constrained LLM

The hard cases are documents that carry no designation at all: a gearbox oil analysis, a blade inspection photo report, a torque protocol. A human expert reads the content and knows which functional system it belongs to. This is where a language model earns its place, under strict constraints. The label space is not open text; it is the designation register. Retrieve the most plausible register entries with embeddings over the register's descriptions, then ask the model to choose among those candidates using structured outputs, with an explicit none-of-these option and a confidence estimate. The model is never allowed to compose a designation string itself. Generated codes that look valid but name nothing are worse than no answer, because they poison the asset system silently.

4. Fuse the signals and route by confidence

Each document now has evidence from several detectors: validated codes found in content, codes from file name and path, layout-weighted title block hits, and the model's constrained classification. Fuse them with simple explainable rules first: a validated title-block designation wins; agreement between file name and content raises confidence; a model classification alone is never auto-committed above the subsystem level. High-confidence results flow into the asset system automatically, with one standing exception: assignments that feed safety-relevant downstream systems always wait for human approval, whatever the confidence score. Everything else lands in a review queue where a documentation engineer confirms or corrects with two clicks, and every correction becomes an evaluation example. On a portfolio of tens of thousands of documents, moving the human from reading every document to reviewing the uncertain minority is where the economics change.

5. Make the result queryable

Store the designations as structured, faceted fields next to the extracted text in an index such as Azure AI Search. At that point the pile of PDFs becomes an asset-aware library: filter every document for one turbine's drive train, list all inspection reports newer than the last gearbox exchange, or let an AI agent answer maintenance questions with citations into the exact documents for the exact subsystem. The designation system was always meant to be the join key between documents, equipment, and signals; detection just restores the key that the paperwork lost.

What it costs, roughly

Rather than a savings number, here are the cost drivers to model for your own document mix. Layout-aware extraction is priced per page and can dominate the bill for scanned archives, so run the grammar detector on plain text extraction first and reserve full layout analysis for documents where it fails. LLM inference touches only the codeless subset, and its unit cost depends on the model chosen, the excerpt length, and how many candidate register entries go into each prompt; estimate it from a sample of your own documents before committing. Then add the lines that never appear on the token meter: standards licensing, integration with the asset management system, and staffing the review queue. Depending on document volume and quality, the queue can end up the largest line, and it is the correct place for the cost to sit: the humans are looking only at the documents that deserve human eyes.

The Swedish and EU angle

Sweden and the wider Nordic and Baltic region are building out wind at pace, and every project handover, repowering, and portfolio acquisition raises the same documentation questions. Buyers inherit fleets that mix RDS-PP, KKS, and OEM conventions, and the designation cleanup usually surfaces during technical due diligence, at exactly the moment nobody has time for it. On the regulatory side, this architecture describes document-management assistance, not autonomous operational or safety decisions. Assess the intended deployment against the applicable EU AI Act requirements; human review alone does not determine the regulatory classification. An EU-focused deployment requires verifying each service's processing and storage locations, including document extraction, model inference, search, logging, backups, and any external integrations. Azure's EU Data Boundary and EU data zone model deployments provide the building blocks, but the verification is per service, not per cloud.

A checklist if you are starting

• Get an authoritative, versioned designation register from the operator first, and record which register version each decision used. Detection without the plant's actual designation list is guessing.
• Build the grammar validator before touching a model, and measure how far it gets alone on your document mix.
• Constrain any LLM to choose from register entries, never to write designation strings.
• Weight title blocks and file names above body text when deciding what a document is about.
• Calibrate confidence thresholds on expert-labelled examples before trusting anything to auto-commit, keep a review queue, and feed corrections back as evaluation data.
• Require human approval before any assignment that feeds safety-relevant downstream systems.
• Preserve the original documents, the evidence behind each assignment, and a correction and rollback history.
• Handle KKS in the same pipeline; mixed portfolios are the norm, and the architecture is identical with a second grammar.

RDS-PP looks intimidating from the outside, a wall of prefix signs and letter tables. Up close it is good news for automation: a formal, documented structure is the easiest thing in the world to validate against. The standard did the hard part decades ago. The remaining work is reading the documents, and that is exactly what document intelligence is for.