It all starts with an I/O Count – how to estimate Automation Systems

It all starts with an I/O count has been my mantra for estimating automation systems over the last nearly 40 years – in my journey from Provox systems at Fisher Controls Leicester, through INFI 90 systems at Elsag Bailey Telford to PCS 7 systems at Siemens Manchester. In the beginning we had one shared office PC running Lotus 123 for generating cost sheets, separate typists produced the proposals on word processors and documents were generally sent and received by telefax (facsimile) and regular post. These days we all have a laptop, iPad and smart phone and the BOM is generated after feeding I/O counts into an on-line web system configurator which will also produce a price and architecture drawing. Everything is by e-mail or file sharing or collaborative teams, and meetings are mostly on-line video conference calls. Nothing is hard copy anymore so surface mail stays in business delivering Amazon parcels I suppose.

Being in sales for most of this time another credo of mine is “nothing happens until we sell something” – this could be as simple as an idea, or engineering services, site surveys, developing User Requirement Specifications (URS) right through to a full-blown Integrated Control & Safety System (ICSS) complete with Process Historian (PH), Advanced Process Control (APC), Web Server and Cyber Security Protection etc. As you can see us C&I guys love our Three Letter Acronyms (TLA)!! Even I/O is an abbreviation for Input/Output of course.

The death of hard copy printed documents also takes away the estimating tool of weighing the RFQ and making a guess at the rough value based on this and the document thickness!! However, from a total I/O count you can use multipliers based on experience to get a very rough budget price. But it is better to have an I/O breakdown into at least AI, AO, DI, DO and 3rd party interfaces, from this you can roughly calculate the number of tags (or Process Objects (PO) in Siemens PCS speak) which helps with engineering estimates. AI+DO will give an approximate idea of the total tags, the AO count alone will give an indication of the Proportional Integral Derivative (PID) control loops required. Also dividing the total I/O by 50 (say) gives an approximate graphic display count.

Good end users and Engineering Procurement Contractors (EPC) will have summarised the I/O count in a Request for Quotation (RFQ) URS document, but less organised clients might just provide Process & Instrument Diagrams (P&ID) for you to take off the instruments and hence I/O, or cable/termination schedules or instrument data sheets or you might even have to go to site and survey the installed field devices if it is a brown field retrofit project. The P&IDs also give an enhanced indication of the number of process graphics/mimics required.

It is better of course to have the I/O not only split into analog and digital inputs and outputs but into hazardous (barriered) and safe area, safety (SIL) and non-Safety, marshalling or remote I/O etc. % spare installed and configured I/O, % spare terminals, % spare rack space, % spare panel space etc. On specifying the number of Human Machine Interfaces (HMI) and other special requirements it is starting to be possible to generate a Bill of Materials (BOM) or Extent of Supply (EOS) – a list of the required hardware, software, licences, and engineering/configuration activities to price against.

Partitioning is also important for a more accurate estimate – basically an I/O breakdown per area of plant and a process description to see if particular areas require a separate controller for process or operational or availability reasons. Does the system require redundant communication networks (these days mostly ethernet based) or redundant servers (these days most are Windows based client/server architecture) or redundant controllers or redundant I/O even? Remember adding redundancy adds complexity and more components to go wrong even if they back each other up. Sometimes the end user might have built-in process redundancy so do not want system redundancy because they can stand a failure with alternative operational methods and routes. Also, I/O redundancy could be considered irrelevant if there is only one sensor/instrument/final control element in the field introducing a single point of failure.

How remote are system components? Can copper cables (up to 100m) be used or fibre-optic (up to 25km in single mode) between devices.

Detailing the 3rd party interfaces to such equipment as package Programmable Logic Controllers (PLC), Motor Control Centres (MCC), Variable Speed Drives (VSD) – what is the protocol – Modbus is still a de facto standard as RTU or TCP versions but also Profibus, Profinet etc. How many points from each interface and are they just for display or to be part of a control scheme in the automation system?

Is it a continuous plant, factory automation or a batch plant? If more Factory and digital signals than process and analogue signals you might consider PLC-SCADA rather than DCS(see my previous featured article "7 Questions to consider when selecting PLC-SCADA or DCS")

How many sequences, how complex are they and how are they defined – cause and effects, ladder logic, flowchart etc.? How many batch recipes, batch units etc. are required? Is it batch to ISA88, is it pharmaceutical using GAMP 5 techniques etc.

Is a historian required? Or a link to other high-level systems? Is Electronic Batch Reporting (EBR) required or a Manufacturing Execution System (MES). What about Cyber Security – what Security Level is required? Does the end user have a standard – or an IT department with a view on IEC62443?? Then there is virtualisation only really cost effective if you have more than 6-8 PCs as client/servers and engineering stations - advantages are reduced space, power, complexity, redundancy, easy software updates, back-up and restore options and better cyber security - Disadvantages are it is more expensive than separate PCs, more complex (=IT training) to administer, now beholden to HP for product life cycles and Hypervisor Operating System (OS) which are generally shorter than Industrial PCs.

The table earlier shows some multiplier factors (mainly for Distributed Control System (DCS) type systems because of my background) based on total hardwired (H/W) I/O plus 50% of the 3rd party interface points, but it is important you develop your own from the experience of bidding different projects and what is the win price. It should be noted that the projects at >10,000 points mostly only exist for new greenfield petrochemical/oil & gas projects which will require barriers and marshalling or universal/configurable I/O – the most expensive type of system. To get down to $200 per point is generally a struggle and can arguably only be achieved by companies taking a holistic total life cycle view of the project. So, take it at <$200 per point and a loss but make ground on variations during the project then service contracts, additions and modifications during the 20 odd year life of the system. Or the company has a “war chest” to fund these sorts of projects because they are targeting this industry/project or they have little current work so they need something to fill their factories and retain their engineers.