InTech

MAY-JUN 2018

Issue link: http://intechdigitalxp.isa.org/i/989516

Contents of this Issue

Navigation

Page 28 of 53

INTECH MAY/JUNE 2018 29 SYSTEM INTEGRATION formatting has been lacking among suppliers. Third-party interface data is not only difficult to transmit through various specialized protocols but also is usually the last thing the supplier de- livers—delaying configuration development and testing until the subsystems arrive at the job site. The inherent complexity of automation re- quires extensive documentation to define the requirements and maintain the resulting assets. The documentation is also very interdependent. A simple change can affect multiple documents. Something as simple as changing an instru - ment tag affects the piping and instrumenta- tion drawing , I/O list, instrument specification sheet, distributed control system (DCS) data - base, field junction box drawing, marshalling cabinet drawing, and loop sheet. As a result, documentation is difficult to keep current and accurate throughout the project. Scope evolution Unlike most other types of projects, automation scope evolves throughout the life cycle of the project—even through commissioning and start- up. Expecting to completely define the scope up front with little or no change is an exercise in frustration. This is where project organizations focused primarily on civil- and mechanical-type projects often stumble, because they fail to make allowances for this characteristic. Design inputs for automation scope come in piecemeal throughout the project as the various project stakeholders perform their detailed en - gineering. Key information regarding the auto- mation details for various packaged equipment modules (skid packages) are not known until deep into project execution after those suppli- ers are selected and perform their engineering work. Some operations requirements are only revealed when the operators have a chance to put their hands on the system during testing and commissioning. There is often a significant gap between the process control requirements as set by process engineering and the definition needed to create the actual system configuration. This is because the process engineers do not speak the configu - ration engineers' language. Translating the pro- cess engineer's control requirements into the format of the configuration functional specifi - cation is required. In addition to requiring an understanding of the underlying process, this translation is a highly specialized task requir - ing resources with deep configuration expertise on the control platforms. A similar translation is required of mechanical, civil, and electrical disciplines as well. Any errors or omissions in the resulting functional specifications cause changes down the line. Schedule constraints The automation scope has numerous depen- dencies on other disciplines involved in the project. These other disciplines are not able to finalize and communicate the automation requirements until they perform their own engineering tasks. For example, before instru - mentation and control valves can be specified, process engineering needs to define the pro - cess conditions and control requirements, and mechanical engineering needs to define line sizes, materials of construction, and any physi - cal installation constraints. These dependencies often cause late changes and schedule compression of the automation engineering effort. Having to absorb all the changes while being expected to hold to the original timeline and budget is frustrating and can lead to skipping steps for the sake of meet- ing expectations. The discipline to properly ex ecute the required engineering while meeting the project schedule and budget requirements is a delicate balance. Automation is always on the critical path for completion. No matter how large the overall project, there is always a task near the end to test and commission the automation system before startup. This can only be done after all construction is completed to keep from violat - ing the integrity of the tested system. When the overall project is late, there is additional pressure to minimize or shortcut commission - ing activities, which can have negative conse- quences if not properly executed. The situation can be even worse in the case of brownfield projects. Most manufacturing facili- ties are under pressure to minimize unit down- time to lessen the impact on production. Without widespread recognition for the importance of thorough automation system testing and com- missioning, it is difficult and stressful to maintain proper checkout discipline when everyone else is pushing to achieve an earlier startup. FAST FORWARD l Specialized project team knowledge and skills are required for inte- grating automation system components and technology. l Automation scope evolves as the design develops and other require- ments materialize through the project's life cycle. l In addition to disciplined project management, there are many good practices that can help ensure successful execution.

Articles in this issue

Archives of this issue

view archives of InTech - MAY-JUN 2018