Implementation of RDS-PP code: How to Guide Referenced Designation System for Power Plants

What is RDS-PP?

Reference Designation System for Power Plants (RDS-PP) is an industry standard approach to asset coding. In the simplest sense RDS-PP is a standardised way of structuring your assets, their primary systems, sub-systems and components in a form that allows you to uniquely identify them.

Once defined, RDS-PP code provides the basis for a multitude of other functions to be performed. These can be anywhere from management of asset data, to maintenance management, for reliability analysis, or for use in systems for performance and reporting. Whatever the intended end use RDS-PP coding provides the common link between all your systems.

Looking for RDS-PP Training?

RDS-PP is complex subject. If you or your team would like to know know more about it then our RDS-PP training could help. We have experience in training personnel in all aspects of RDS-PP. We can help you whether it's with gaining a basic working knowledge of the subject or all the way up to learning deep implementation concepts. Contact us to find what we can do for you. Click here to contact us today.

Why implement RDS-PP?

Using a defined Reference Designation System (such as RDS-PP) is an excellent way to structure your assets and the data associated with them. This is particularly important for large projects or asset portfolios.

Keeping track of asset information such as performance data, maintenance history, documentation (reports, manuals, technical data etc.) are just some of the reasons to adopt a system which allows standardisation of asset structures and naming.

When RDS-PP coding is implemented every component or device becomes uniquely identifiable. As part of the process, components are then also located within a standardised hierarchical structure. This structure is specially developed to logically reflect the function and system association of that component or device.

How does RDS-PP Work?

To understand how RDS-PP works we can use the simple example of a chair. A chair’s function is to “provide support” to the person sitting on it. The legs are part of that “system” therefore must be products of that system. The hierarchical structure in this example would be something like this;

Table 1. Table of simplified furniture example - RDS-PP Hierarchy

We can therefore identify the fourth chair leg of Chair No.1 with completely unique coding. The full code for this will be =WBM10 UM001-UM004

The code itself is independent of language. Meaning it can be applied anywhere in the world and can be understood by anyone who has a basic level of understanding of how the designation system is structured. Most importantly the code is part of a logical hierarchy which means that it can be incorporated into any system for monitoring, maintenance management, performance analysis, reporting or reliability analysis etc.

In this single code we are provided with the following information;

• The “Basic Function” of the object is related to providing support. This is indicated by the use of the letter code “UM” at the F2 level of the hierarchy.
• This is the “fourth” support. Therefore there are at least four supports.
• These supports are “Products” (indicated by the prefix “-”) meaning they are part of a “Basic Function” (which in this case is Chair No.1)
• The chair is part of the overall system “Furniture” (WBM10)

Now that the structure of the code is defined we can use this to our advantage. Lets look at this in more detail:

What if all the chair legs were of different design and had different maintenance requirements?

• We now have four unique codes we can assign maintenance documentation, instructions and activities to in our maintenance management system. This allows us to distinguish between each chair leg (or “object”)

What if all the fourth chair legs are the exact same across all chairs?

• We can use the various RDS-PP codes for those objects and associate them to the same documentation. This means only a single set of documentation needs to be maintained.

What if Leg 4 fails?

• We can determine how this impacts the system overall. For example, when Leg 4 on Chair No.1 fails then it fails to provide it’s “Basic Function” of “support”.
• We also know that there is no impact on Chair No.2 as that is structured under an entirely different sub-system.
• We can record and analyse this data in future to find recurring issues or faults.
• The structure itself will allow improvements in reliability of all systems by allowing personnel to use probability and statistics to determine likelihood of failures and therefore impact on production.
• The universal nature of the RDS-PP standard also means that companies can share failure and reliability data anonymously across the world. By combining this data it allows meaningful statistical analysis of failures to be performed. The results of this can then be shared back with the participants to improve their operations.

How can we find out where we are spending most of our resources or money?

• By assigning costs and work activities to the correct coding it is possible to understand a great detail of where money is spent and why. This can be aggregated from Product level to the very top and analysed as appropriate for each level of the hierarchy.

How can I find out how many chair legs I have overall?

• Because we know that chair legs are coded “UM___-UM___” and we also know that only chair legs exist under “WBM10” we can search and filter any database to highlight the codes we are looking for.

This is of course a very basic example. In reality this hierarchy is applied to complex systems across all engineering disciplines. However the principles remain the same throughout. The simple examples apply to much more complex installations. Instead of a chair leg it could be anything from a motor drive, pump unit, electrical device, fire suppression system or a communications network.

RDS-PP Implementation; What you need to know

There are some key things to know before you apply RDS-PP in your operations. These points will help you navigate the common issues encountered by most organisations when they adopt a Reference Designation System. Each section is concluded with a single rule. These rules can be considered the “Golden Rules” of RDS-PP implementation.

User & Stakeholder Acceptance

More often than not RDS-PP will be adopted as an improvement over an organisation’s existing asset designation system whether that system is in an orderly state or not. This means it will be replacing some form of system already in use. This is a crucial point which will underpin almost all aspects of the project from its conception to daily usage in future.

With this in mind it is important that all organisational units are considered during the initial stages of development. An assessment of impact should be made on each;

• Identify which organisational units will be affected by the change.
• Determine how they may be impacted by the new system.
• Does it result in any additional workload on their end?
• Is a representative from that organisation unit necessary to support or consult during the process?
• How will this change their systems and their ways of working?
• Are there any significant reasons why RDS-PP should not be implemented?
• Does the organisation have a training plan to introduce their teams to RDS-PP?

These are just some of the questions necessary to answer before proceeding with the project. Buy-in from all stakeholders is a critical aspect of any project like this and has a direct impact on the quality achieved at the end.

Support from Senior Management

Implementation of RDS-PP coding in principle is not as difficult as you might expect. Where the difficulty lies is in the level of quality and cultural “buy in” necessary to be maintained throughout the administration of the project. This can be a substantial task and requires a strong supporting commitment from Senior Management to back those moving in the most positive direction.

Technical Management

The project should be managed by the most appropriate technical or engineering unit within the organisation. Here a single competent individual can be appointed to steer the project. It is recommended that this person not be deeply involved in the implementation of coding itself as it is their role to ensure that the project moves in the right direction. To be clear the goal should not simply be to “complete the project”. As many assets will be operated over a 20-30 year lifespan a forward thinking mindset is required. The goal is to implement a high quality system which can be utilised by the organisation over that time period. It is important therefore that this individual has the foresight to envisage how RDS-PP will integrate with the company’s day to day activities now and in future.

Technical Team

Depending on the size of your project the technical team implementing the work may be anywhere from one individual to several. The level of work and resources required is dictated by a number of factors;

• By far the No.1 is the “depth” of coding intended (i.e. code everything “down to the bolts” or stay at a higher level). Remember you can have an exponential expansion of the asset designations every time you seek to define deeper levels. Therefore it is very important to constantly evaluate why you are coding certain assets, to what depth and where you see the maximum value in doing so.
• The amount of assets or installations which require coding (i.e. the size or extent of your portfolio)
• The complexity of those installations.
• How much asset data is expected to be sourced and married to the RDS-PP designations (secondary work). This also includes things like mapping of RDS-PP systems to any pre-existing data or records (should any retrospective referencing be required).

The individual themselves must have the following attributes;

• A technical education or bias. As RDS-PP is applied mainly in the field of power generation, it is important that the individual possess the technical knowledge necessary to understand and code the various systems which exist in this area.
• The person must be highly orderly, logically minded, have a keen eye for detail and be thorough in their work. This applies to all aspects of the work from field inspection to construction of the asset database back in the office.
• Be able to interpret a vast array of technical drawings and documentation and relate these to the real conditions on site.
• Finally, the individual should be able to understand the significance of how their work feeds into the overall operations of the company and during the course of their work make practical decisions where RDS-PP is appropriate and where it is not.

Definition of Scope

Before starting a project it is important to try to envisage what you expect to get at the end. This will determine how you structure your project, your scope of work and how you prioritise your efforts to accomplish the best outcomes.

Ask yourself the following;

• What do you want to accomplish by implementing the new system?
• Which of the key benefits does your organisation want most from RDS-PP?
• Is it even necessary? Is your organisation going to be managing or maintaining these assets for their life?

For example, if your organisation is going to be performing the maintenance of these assets for the next 10+ years then yes it is worth having a standardised coding system in place. If maintenance management is your only focus then there are some key benefits you need to consider;

• Accurate record of assets in a database or register. This will help you keep track of those assets and components. How many, type/make/model of equipment, who the suppliers are, etc.
• Ease of maintenance planning (implement preventive maintenance routines, maintenance instructions, etc.)
• Easy identification of assets in the field and retrieval of associated technical information, documentation, drawings and maintenance records.
• Standardised reporting, reliability and downtime analysis.
• Ordering and spares management.

Alternatively, if your organisation is not performing maintenance on the assets but wants to monitor their performance you may not have the same interest in the benefits listed above. In this case you may only need to consider;

• Accurate record of assets in a database or register.
• Designation only to a higher levels (i.e. “System level”). As you are not performing the maintenance directly you may not need or desire to code the various equipment to great depth. Coding to a higher level may allow you to perform all the analysis you wish for reporting or performance monitoring purposes.

The key is to understand what your organisation really needs, what is a “nice to have” and what you should be excluding in your scope. Do not get caught in the trap of looking for everything. Aim to accomplish what works for your organisation and do that well.

Project Execution

The scope of work can vary depending on the project however it will typically follow this sequence;

Initial desktop investigation.

• Justification for implementation of RDS-PP. What the organisation will gain by adopting RDS-PP.
• How large is the scope? How many assets?
• How much complexity or “depth” of designation is expected?
• Will coding be applied only in electronic database form? or will drawings, equipment labels or protocols also need to be updated?
• Identification of all systems for IT and Operations which may need to be updated with the new coding and impact assessment performed.

Agreement to proceed

• Sign off from management
• Team selection
• Communication of goals

Field Investigation

• Verification of assets, equipment and their configuration. Does this align with company records and engineering drawings?
• Gather any data from the field to support desktop work later.
• Detailed photo survey of all stations, building areas, cabinets and any other assets within the scope.

Generation of the Asset Register/Database

• Collecting asset data (how many plant areas, substations, general infrastructure, systems, generators, transformers etc.)
• Analysing drawings and records (how everything is configured and how systems interact)
• Configuration of assets according to RDS-PP structuring principles
• Coding of assets according to RDS-PP.

Implementation of Asset Register and RDS-PP in Company Systems

• Preparation, upload and validation of RDS-PP structures and coding into the company’s monitoring systems (i.e. maintenance management, SCADA, CMS performance monitoring systems etc.)
• Application of coding retrospectively to historic data or reports (if desired) or mapping of legacy coding to the new RDS-PP coding if necessary.
• Labelling of equipment and plant areas and follow up verification.
• Update of drawings and documentation.
• Training of personnel on RDS-PP.

Ongoing Maintenance (Post Project)

• Change control management.
• Onboarding of new plants or equipment. Development of new codes or structures.
• Update of coding when engineering changes occur.

During execution of all these activities the asset designation team should be directly involved as much as possible. This will ensure that they become completely informed of the assets and systems they are reverse engineering and then ultimately designating. This is necessary for developing the correct structures and for them to understand the significance of any changes to the coding.

If a project is large in scope some of the asset designation work may be provided by contractors or other third parties. This is common where complex electrical packages are delivered from subcontractors or where a significant amount of documentation requires updating with codes. The involvement of other parties introduces quality concerns. Therefore it is very important that the designation team have oversight of any work which is done in respect of RDS-PP coding. They must be afforded the necessary authority to review and reject work which does not comply with the standards or quality expectation of the company.

Conclusion

If these rules are followed this will increase your organisation’s ability to embed RDS-PP effectively into your operations. In doing so your organisational units will be able to leverage this coding and its structure in future to perform a vast number of beneficial functions. It will also allow you to onboard new assets in a standardised way. Ensuring they will be compatible with your existing data, analysis and reporting structures. RDS-PP coding allows your organisation to manage and compare equipment and information throughout the lifecycle of your assets to reduce overall costs and streamline your operations.

RDS-PP Training In Ireland

Click here to contact us about RDS-PP training in Ireland.

Last Updated: 27 September 2022