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.
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.
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.
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;
|RDS-PP Code||Breakdown Level||Description|
|-UM001||P1||Supporting Leg 1|
|-UM002||P1||Supporting Leg 2|
|-UM003||P1||Supporting Leg 3|
|-UM004||P1||Supporting Leg 4|
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;
Now that the structure of the code is defined we can use this to our advantage. Lets look at this in more detail:
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.
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.
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;
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.
Consider your stakeholders and the impacts on them.
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.
There must be no question in the organisation that adopting RDS-PP is the goal and that quality is key.
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.
The technical manager of the project should be idealistic but practical. Someone who can see the potential of RDS-PP and understand how to maximise its benefit for the organisation keeping in mind all other constraints.
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;
The individual themselves must have the following attributes;
RDS-PP can be described as a language of structure and logic. It is important that those performing the implementation are suitably minded to ensure that a consistent and well thought out approach is followed.
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;
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;
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;
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.
Do not try and grab all the cookies from the cookie jar or you will end up with none. In other words; Determine what level of implementation of RDS-PP works best for your organisation, where it should be applied and then do that well. Exclude all branches or offshoots that your organisation does not need or benefit from.
The scope of work can vary depending on the project however it will typically follow this sequence;
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.
Make sure your asset designation team members are involved in all aspects of the scope of work. This will ensure that they can catch issues early on and resolve them before they grow beyond control. They must also be given the authority to reject work which does not meet the necessary requirements.
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.
Looking for RDS-PP training for you and your team...
Last Updated: 27 September 2022