Integrated Process Plant Design

Background

We are all part of the same engineering community however the relationship between vendors and customer is distinct. Companies deliver engineering solutions. They do this through use of expertise in a particular field (theory, procedures, standards and workflow).

In order to gain cost advantages and aid the delivery of engineering solutions, the use of software tools such as Aspen Basic Engineering and SmartPlant Foundation are used to superimpose engineering knowledge and provide seamless integration.

ISO 15926 is a recognised international standard for the process industry, and is now available to enhance integration and reduce some of the previous integration effort required between applications. However, due to the diverse nature of the industry, all vendor applications require additional customisations (specific to each industry needs) to achieve satisfactory integration.

This specific customer was faced with precisely this issue and workflow procedures were analysed to see which data and how the data flow would be managed without the need of disparate and isolated islands of automation.

Analysis

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

The front end documentation was a clear starting point and indicated the required data flow from one application to another. In addition, the detail documentation also suggested where the source of the data originated from. Both sets of information are required to assist in the mapping of data between the two applications.

Analysis complete and vendor applications in place, it was just a case of exposing and mapping the required properties to achieve seamless integration. Unfortunately it is not as straightforward as this.

Feasibility

Many of today’s engineering applications are data centric meaning the data is represented in terms of "real" objects and properties. Views are layered on top of this data to produce the documentation that engineers readily recognise as diagrams, specification sheets and lists etc.

Due to the data centric nature of today’s applications, mapping of properties involves understanding the intent of the properties, which properties should be mapped and where, and for tools like Aspen Basic Engineering the governing case of the data to be used - (the importing application may not understand the governing case and therefore this needs to be presented to the importing application in a different way).

Furthermore, there are also problems when the conceptual world meets the physical world as modelling this in two different databases and attempting to achieve integration can lead to misalignment. For example, difficulties arise when attempting to map a conceptual pump to its physical duty and standby pump in their respective applications. Or the terminology - Piping System, what does this equate to in the downstream world? Is it a representation of pipe segments?

In some cases one has to find a balance (in terms of cost, educating, maintaining) between what the different vendor tools strive for, i.e. "seamless" integration and the reality of achieving "seamless" integration. Sometimes it can be certainly more cost effective to create file-based integration that is used as a mechanism to achieve "seamless" data flow.

These are just some of the issues that arise when "seamless" integration is required and this is certainly true for the applications adopted by this customer. In addition to this the person responsible for mapping the properties must be proficient with the different tools.

Implementation

IPPD adopted a number of implementation paths for this customer as they required the option of integration in the following ways:

• XML to SPPID - File based integration through XML and import into Smart Plant PID for major equipment.
• Seamless Integration - Integration using the out of the box tools and customisation of SmartPlant and Aspen Basic Engineering for stream data.
• In-house Integration - Integration with their in-house SPIDER warehouse and Aspen Basic Engineering.

XML to SPPID

IPPD always insist that in the ideal world seamless integration should be adopted for different vendor applications to communicate. However, it is not always cost effective to do this due to steep learning curves of the tool set, immediate turnarounds and time to market pressures and the service providers can be inexperienced in one or more of the tool sets - and of course the budgets available to accomplish the services dictate the scope of work and the implementation path.

With these considerations in mind we focused on import of SmartPlant data via the XML file-based route for equipment items. IPPD decided not to configure the different schema component parts of SmartPlant to align the attributes with Aspen Basic Engineering. This can be quite difficult and time consuming for the average user.

IPPD built a knowledge base framework that was able to export the Aspen Basic Engineering data and it was scalable such that further modifications were not required to the rules if additional data was required for export.

Seamless Integration

For the out of the box tools, IPPD configured Aspen Basic Engineering projects to make it "TEF" enabled (SmartPlant compliant), and highlighted and exposed the attributes required for import and export to SmartPlant Foundation (SPF) - this scope of work specifically focused on exporting heat & mass balance data, which also could have been implemented by the above solution.

Furthermore, the out of the box rules were updated and new rules created to ensure the Plant Breakdown Structure (PBS) was imported from SPF into Aspen Basic Engineering.

In-house Integration

The in-house integration to the SPIDER database was a new challenge for IPPD as no obvious automation existed between the two applications. Furthermore the customer requested that they wanted a user interface that allowed them to map datasheets from each of the applications resulting in the ability to view, compare and select which data is transferred.

After consulting with the SPIDER team, IPPD architected a solution that delivered the customers needs. The implementation of this solution was two-fold.

The first part of the solution was to make the same SPIDER lists available in Aspen Basic Engineering. This was the common theme which allowed engineers to compare the datasheets in each of the applications via the interface. These lists were also designed to hold the mappings required for integration with SPIDER.

The second part of the solution was to develop an application for viewing all of this data. The application was developed in a short time frame and is being used to import and export data from Aspen Basic Engineering to the SPIDER database.

Full details on this application are available here.