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

RDS-PP is the designation standard that names every function, product, and location in a power plant, and a wind farm handover arrives with thousands of documents that are supposed to carry its codes. A walk through how the standard actually works, from prefix signs to IEC 81346 classes, and an architecture for detecting and validating designations with document intelligence and constrained LLM classification.

- Published: 2026-09-01 · Category: AI & Cloud Infrastructure · Tags: RDS-PP, IEC 81346, Wind Energy, Document Intelligence, Azure AI, Asset Management, Document Classification, Energy Sector
- Author: Technspire AB, Stockholm (https://technspire.com)
- Canonical: https://technspire.com/sv/blog/rds-pp-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, which means a designation is no longer a proprietary power plant convention but an application of a cross-industry standard. 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 was also proposed for international standardization as ISO/TS 16952-10. 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 standard defines nine of them:

| Prefix | Aspect |
| --- | --- |
| # | Conjoint designation (the overall assignment, e.g. the site or plant) |
| = | Function-related designation |
| == | Functional assignment (process-related) |
| + | Installation location |
| ++ | Mounting location |
| - | Product-related designation |
| : | Connection designation (terminals) |
| ; | Signal designation |
| & | Documentation designation |

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 81346-2: 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

Run every document through a layout-aware extraction service such as Azure AI Document Intelligence. 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; 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 names a subsystem the plant does not have is a typo, and catching it is half the value of the system. This layer is deterministic, fast, essentially free to run, and it should always outrank anything a model says.

### 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. 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

The deterministic layers cost close to nothing per document. Layout extraction is priced per page and dominates the bill for scanned archives, so run the grammar detector on cheap text extraction first and reserve full layout analysis for documents where it fails. LLM classification only touches the codeless subset, typically with a few thousand input tokens per document (content excerpt plus candidate register entries) and a small structured output. Under those assumptions, model cost per classified document sits in the tenths-of-a-cent range on current mid-tier models, which means the review queue staffing, not the tokens, is the real cost line. That 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 is comfortable territory: a document classification system with human review is plain workflow automation under the EU AI Act, not a high-risk system, and the whole pipeline runs fine inside an EU data boundary on Azure with models deployed in an EU data zone.

## A checklist if you are starting

- Get the designation register first. 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 code-bearing documents it does most of the work.
- 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.
- Route by confidence, keep a review queue, and feed corrections back as evaluation data.
- 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.

## Sources

- [RDS-PP, Wikipedia (German)](https://de.wikipedia.org/wiki/RDS-PP): standard structure, prefix signs, status, and VGB-S-823-32
- [IEC 81346, Wikipedia](https://en.wikipedia.org/wiki/IEC_81346): the 81346 series, aspects, and object classes
- [Kraftwerk-Kennzeichensystem, Wikipedia (German)](https://de.wikipedia.org/wiki/Kraftwerk-Kennzeichensystem): KKS history and structure
- [SøDera: RDS-PP explained](https://www.soedera.eu/service-rds): an RDS consultancy's view of the operator problem
- [vgbe energy](https://www.vgbe.energy): publisher of RDS-PP and the application guidelines

---

Technspire AB builds AI agents, Azure OpenAI solutions, and production web platforms for Swedish and EU enterprises. Book a call: https://calendly.com/technspire · hello@technspire.com · More articles: https://technspire.com/en/blog · Site overview for agents: https://technspire.com/llms.txt