Main Navigation Menu

Expediting design reviews through prototyping

Having a prototype can speed up a review both in terms of having a more accurate requirements capture in the first place, but also 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 prototype. This may make sense in a fast track project where a system integrator is not yet engaged, but resources are available.

S88 physical model - control module review

S88 physical model – control module review

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)

 

S88 Physical model - Equipment module

S88 Physical model – Equipment module

 

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.

Optimization WordPress Plugins & Solutions by W3 EDGE