Key Benefits

  • Substantial productivity gain
  • Seamless integration achieved
  • Sophisticated rules monitor and automatically update PFD and PID objects
  • Individual categorised lists and specification sheets published

PFD to PID Expansion

The PFD to PID expansion technology is suited for all vertical industries and is required when the conceptual (PFD) world meets the physical (PID) world, i.e. when a front end tool integrates with a detailed design tool.

This particular project looks at the issues of integration between different vendor applications and how a solution was derived based on the capabilities and limitations of each specific application.

Our brief from this particular customer was to achieve full integration between Aspen Basic Engineering and Intergraph's SmartPlant Foundation applications, and manage the data objects based on the engineering needs.

Background

What is vital is to have an understanding of the processes and mechanisms of delivering engineering both internally and externally. Simulation and conceptual design is a small part of the design and is usually carried out by specialists or a small number of the engineering team.

PFD to PID Expansion

The bulk of the engineering is concerned with making the design physical, producing the deliverables that support the physical "real" design and making this available to other disciplines and ultimately downstream applications.

PFDs represent conceptual objects which, once physical, are reported on and updated on the P&IDs. Datasheets which specify the equipment define the physical objects and as such hang off P&IDs not the conceptual PFD.

Line lists, valve lists, instrument lists, plant item lists etc. all have very little, if any, meaning or value when based on PFDs and they are never revisited. This represents a challenging issue in modelling this workflow in Aspen Basic Engineering and SmartPlant Foundation.

For this implementation to be feasible it was critical to decide where the expansion of the conceptual world should lie. We were aware that the physical pumps without question will always be in the physical world but was it enough to have just the one pump in the conceptual world? Was seamless integration enough for PFD to PID expansion with the respective objects residing in their respective applications?

Analysis

The analysis phase focused on where the boundary between the conceptual and physical world should lie. This was predominately dictated by the tools in use and the work processes and practices.

For this customer the PFD truly depicted the conceptual world with naming of equipment to indicate the existence of the physical world objects, i.e. P-100 A/B in reality is P-100A and P-100B. Understanding the capabilities of the vendor applications and the requirement of mapping one object in the conceptual world to multiple objects in the physical world was a challenge to say the least.

Furthermore, using the out of the box technology allowed data to flow either way, which gave issues if multiple data objects are mapped to one conceptual object.

Feasibility

From extensive prototyping and testing we had to determine how a one-to-one correlation could exist between the conceptual and physical worlds as it was not evident from the integration capabilities of either application.

PFD Pump

It seemed that one conceptual and multiple physical objects in their respective applications was not enough to achieve seamless integration. Although SmartPlant foundation literature suggested expansion was possible through integration and that objects (duty and standby) are always synchronised.

Expanding the use of Aspen Basic Engineering to P&IDs raises the exposure of data and gives ownership across discipline, project and company. This application then becomes the centre for the design, not an intermediary in the design process. Automatic expansion seemed more feasible in the conceptual world and then using the child (physical) objects to attain the one-to-one correlation required for integration.

Implementation

We decided to implement the expansion technology in Aspen Basic Engineering. The automatic expansion technology was driven from the creation and modification of PFD objects.

Rules monitored when a PFD object was created in Aspen Basic Engineering and by default created its respective physical PID object. More sophisticated rules then monitored name changes and number in service and standby fields to automatically update physical objects to always align with the conceptual object.

Explorer Expansion Window

Categorising the conceptual and physical objects allowed filters to be applied to display the required physical or conceptual objects in the list. It is this list which is then published to SmartPlant foundation to create the one-to-one map in the SmartPlant Foundation database.

The categorisations also allowed individual specification sheets for the physical objects in Aspen Basic Engineering and these can also be published to SmartPlant. IPPD provided a framework for this automatic expansion technology and the customer used this as a starting point to layer their extensions.

The customer gained exceptional benefits by automating the expansion technology in Aspen Basic Engineering. The integration gave rise to quality and error free data flowing from one application to another.