Automation project costing using a model

The preliminary design stage of a large engineering project by an engineering and procurement contractor (EPC) will typically cost 2% of the detail design stage. The preliminary design should give the client 95% cost certainty for the detailed design.

Typical project design breakdown by discipline for a ‘brownfield’ expansion of a process heavy existing plant is as follows: (presuming no land cost and no significant civil works)

Engineering design project breakout
Engineering design project breakout

It can be particularly difficult for an EPC to estimate the Automation cost. Often, the Automation chunk of the work will be undertaken by a third party System Integrator (SI), and not the EPC.

It is estimated that it will cost the SI 2% of the value of the prospective tender to quote a fixed price for the work. Modelling at this early stage can reduce risk of cost overrun through better work estimation and requirements capture. SI’s sometimes look to reverse engineer the quotation and documentation from a wireframe built on the target proprietary control platform. If they have the platform and resources familiar with it, this can greatly aid the quotation process. If they don’t have the platform, they could use a prototyping system.This will still take some time to program, but comparision details are outlined in the table below.

Comparison of programming a DCS system v Prototyping system ; length of time taken to program a type v time taken to prototype it.

DCS v Prototype programming comparison
DCS v Prototype programming comparison
Some typical programming  times for S88 module ‘instances’ for a DCS system (The standard templates are already available –this is often only the case on existing sites with an advanced standards library).

Broadly speaking, a DCS can be programmed in half the time of a PLC / Batch / SCADA system combination primarily because of the nature of its integrated database. However DCS systems are not necessarily designed for conceptual design whereas a prototyping system is expressly for that purpose so we would expect it to be faster for FEED. In addition, if the SI sells services on more than one platform, then the prototyping approach to FEED could be used for all of those platforms, and the prototyping model could in turn be  re-used time and time again for other  FEED quotations.

The above table outlines software configuration / generation only. Testing typically takes the same amount of time again. Design and test documentation generation can take twice this amount of time. Model based prototyping systems can automatically generate this documentation.

What might the prototype output look like and how might it  be used for estimating the programming effort? The figures from above are added in order to calculate the amount of programming required:

Solution summary report table
Solution summary report table

If the model is created by an SI and the SI fails to win the project, the model is there as a starting point for the next job, as well as being a source of training videos and control system emulation to be used in training courses.  If the model is created by a client as a budgeting guideline, it helps strengthen their hand regarding negotiation with suppliers as they now have a good idea of how much programming will cost.

Summary

System integrators have internal metrics for working out how long it will take to program a scope of work. Clients usually do not have these metrics. Prototyping the job requirements brings a degree of transparency to pricing and cost estimation that would not otherwise exist for the client, the EPC, and the System Integrator.


See Spike in action or try it yourself, no sign up or login required.