Having a model can speed up a design review by having more accurate requirements capture and when eliciting tricky functionality that would not easily be identified as missing, during a document review. Here are 2 examples.
Physical model – control module review
Alarm limits, enable disable, control system template type, engineering unit ranges. All of these issues can in fact be captured and documented in a model. This may make sense in a fast track project where a system integrator is not yet engaged, but resources are available.
In the above sample, its much easier to review alarms, interlocks, ranges etc in a working model.
The next example is more complex and outlines an issue not easily captured or noticed, except through interaction with a system;
Physical model – equipment module missing functionality
In the following design specification, there is a command called ‘cooling’. During the review it was missed that the steam valve should be put into ‘auto’ mode if it was not already interlocked. However, if it was already interlocked, then a user message interaction needs to be sent. This particular change was only retrofitted during commissioning, but could have been captured during a HAZOP style design review utilising a model.(change identified in blue)
Summary
If you are trying to compress an automation project schedule , then better requirements up front (and thus less design review time) is the key, and a large amount of those requirements can be captured independently of target control system knowledge. A model can provide the infrastructure for the requirements capture.
See Spike in action or try it yourself, no sign up or login required.