Agile manifesto: Engineering, procurement, construction firm vs. systems integrator
The agility described in the “Manifesto for Agile Software Development” has clear advantages, but what does it mean for production facility automation?
In February 2001, a group of software developers met at the Snowbird resort in Utah to discuss lightweight development methods. They published the Manifesto for Agile Software Development.
This agility that they describe has clear advantages for traditional software development, but what does it mean for the automation of a production facility?
Automation as executed by an engineering, procurement, and construction firm (EPC) is often treated as just another department with a set of deliverables due at a specific time in the project. Just like the equipment specs and the piping design, the control system code is due before the startup and written according to a specification (scope) agreed upon by the customer. A common phrase in this environment is that the project will have a "no change" mindset. Any change in the original scope is considered bad and the customer is penalized with change orders for adapting.
A good systems integrator (SI) isn’t as bound in the structure often imposed on an EPC. A good SI values working with the customer to develop the right software solution. And they do this using many of the agile techniques, whether they call them that or not. The reason for this difference in attitude is experience. In addition to large greenfield projects that have clear beginning (FEL), middle (detailed design), and end (startup), SIs have experience supporting the ongoing operation of facilities. They’ve lived with operators and the perils of "fire and forget" programming. They also understand the difficulty in defining an automation scope. The operator or process engineer may think they know what they want, but until they’ve seen the plant in operation or at least run through a good simulation, they don’t have all the answers.
But how does a good SI put agile techniques into practice on a greenfield project? Agile software development promotes the rapid development of working software. Obviously you can’t startup a plant with a "rough draft" of control code, but you can test it in simulation. The keys are simulation and customer interaction. The iterative process of creating working software, testing it in simulation, and then collaborating with the customer on improvements is the backbone of agile process control code development.
This post was written by Scott Hayes. Scott is a senior engineer at MAVERICK Technologies, a leading automation solutions provider offering industrial automation, strategic manufacturing, and enterprise integration services for the process industries. MAVERICK delivers expertise and consulting in a wide variety of areas including industrial automation controls, distributed control systems, manufacturing execution systems, operational strategy, business process optimization and more.
MAVERICK Technologies is a CSIA member as of 3/5/2015
Do you have experience and expertise with the topics mentioned in this content? You should consider contributing to our CFE Media editorial team and getting the recognition you and your company deserve. Click here to start this process.
