The use of prototyping in control system design is not as common as that of prototyping in product design. However, the benefits are similar: reduced design lifecycles, a clearer understanding of requirements, encouraging brainstorming, better collaboration, and benchmarking against corporate best practices. We briefly explore the advantages of process automation prototyping and provide a sample of just what can be achieved in eight hours with prototyping software.

Where is control system prototyping today?

A recent survey by IHS (Factory of the Future, August 2015) of 369 automation and engineering professionals involved in the specification and design of control systems highlighted the following:
  • Only a third of respondents used commercial off-the-shelf software for prototyping their control design;
  • A third of respondents use no prototyping tools at all, and use manual processes, for example, marked up P&IDs;
  • The average programming budget costs for changes after design specification was approximately 23 per cent;
  • Most control systems design projects go over budget and that prototyping is part of the solution as well as having numerous other benefits.

So why aren’t we maximising the use of prototyping for control systems?

Prototyping is routinely used for product development as well as in modern software application development, from websites to enterprise business applications (in conjunction with the Agile development approach). It would seem to be a good fit for some of the more pressing challenges that exist in process automation:
  • The engineering design life cycle of process automation is still largely manual
Control system requirements capture consists of engineers writing specification documents based on input from process engineers. These documents are then subjected to a review cycle from various stakeholders. When the document is signed off, an automation engineer interprets the pseudocode as he sees fit, and programs the chosen platform. A large number of technical queries come out of the programming effort, as do a large amount of errors. With prototyping, design specifications may be generated faster, saving money: better software starts with better requirements. It is impossible to demonstrate the requirements back to the client for verification before development begins, without some form of prototype.
  • No strong FEED (front end engineering design) without proprietary system knowledge
A good FEED will reflect all of the client’s project-specific requirements and avoid significant changes during the execution phase. However, how can a good automation FEED take place without access to specialists trained in a particular proprietary target automation platform? Often that platform has not been decided upon yet, or an emulation of that platform is not available. Where is the equivalent of the 3D CAD model for enabling collaboration? Prototyping allows for teams to quickly collaborate and iterate on application prototypes to explore ideas, test hypotheses, and validate designs before even entering the development cycle.
  • Standard automation function libraries designed for reuse are platform specific
A quality library of mature standard module templates that can be reused time and time again is extraordinarily valuable in terms of labour saving. However there is no easy way currently to import a standard template from one proprietary platform to another. A control system independent prototype helps leverage the benefit of standard templates.
  • Cheaper; better; the quickening of the manufacturing life cycle
The demand for increased speed of manufacture and decreased time to manufacturing profitability is resulting in challenges to traditional project execution. The concept of prototyping is integral to Agile project execution methodologies.
  • Greater cost certainty required
Project managers need greater cost certainty on their software budgets as software projects have a reputation for going over budget (approximately 30 per cent according to the quoted IHS study). Is it possible to build a detailed project plan that accurately captures a complete development cycle prior to starting development? Prototyping helps reduce project schedule risk by improving planning and work estimation. Without shared understanding of a common vision, it’s difficult to plan and estimate the overall development effort.

Sample prototyping walk-through

[caption id="attachment_24781" align="alignright" width="300"]aauto-3 Fig. 1: Screengrab from the ISA-s88/95 rapid prototyping software spike prototype from hal software[/caption] So what could a process or automation engineer reasonably expect to be able to wireframe out in eight hours using an ISA-S88 based prototyping package with its own generic type library? If we take a very simple process consisting of buffer makeup in a buffer tank, then transfer out to a hold tank, a simple wireframe could provide the following detail:
  • The entire physical module defined in terms of a generic type library control modules and equipment modules;
  • The entire procedural model consisting of fill, transfer out, transfer in phases, operations and procedures;
  • The associated formulae and campaign.
The resulting detail would be insufficient for a functional design specification but would be better than a user requirement specification. Here is the summary for the above eight-hours wireframe:

Physical model and formulae

[caption id="attachment_24781" align="alignright" width="300"]aauto-3 TABLE 1: DEPICTS THE NUMBER AND TYPES OF MODULES DEFINED IN THE 8 HOURS WIREFRAME ISA-S88 PHYSICAL MODEL[/caption] All of the above physical and procedural model elements are now captured forever in a model and can be exported directly to documentation in addition to being optimised over time. A rough ‘rule of thumb’ for a project manager is eight hours to wireframe a simple ISA-S88 batch procedure. [caption id="attachment_24783" align="alignright" width="300"]aauto-5 TABLE 2: DEPICTS THE NUMBER AND TYPES OF MODULES DEFINED IN THE 8 HOURS WIREFRAME ISA-S88 PROCEDURAL MODEL[/caption]

Conclusion

Prototyping will not suit everybody involved in the control system design space. Some will already have internal tools that perform this function adequately. Others may have detailed proprietary control system libraries that are not easy to import and export out of prototyping tools, thus reducing the value of prototyping to some extent. Still others may not be changing anything in their ecosystem for many years to come and therefore have no requirement. However, prototyping can be a great enabler for design collaboration  provided the prototyping platform is easy to use and available to all disciplines in order to maximise the ‘network effect’. (The more people that use it, the more valuable the output becomes.)