For an automation project, what design methodology should you follow? Emerson’s Scott Turner provides some thoughts for your consideration.
A well-designed scheme or strategy is generally more robust and fit for purpose than a control function configured without any real design emphasis. Failure routines are more considered, as are interactions to other items of configuration in your integrated system. Therefore, the design stage should receive the focus it deserves.
When considering the design of your strategy or scheme one, of the first considerations is what design technique to use? There are a large number of design philosophies and methodologies available for use, from evolutionary prototyping, through agile software development to the more formal structured systems analysis and design method. They all have their individual merits and challenges, depending on the context in which they are used, and not all of them are suitable to the design of our control schemes and strategies. As a rough guide, there are two main techniques, which are worth considering for our object-orientated systems. The first is the rapid application development technique (RAD) which is generally more suitable to the design of smaller discrete items (for example composites within control module classes, or dynamos on a process display) and the structured analysis and design technique which is generally more suitable to the design of systems which can be broken down into component parts (for example equipment modules or phases).
The rapid application development technique is more suitable for situations where solutions need realising quickly and in a more iterative manner (for example during factory acceptance testing) and the structured analysis and design technique is more suitable for situations where the waterfall model is being followed (for example during project execution).
The principals of rapid application development are that following definition of the requirements, the design and configuration of the prototype logic are performed in parallel. When the prototype performs as required, it can then be readied for use by annotating the code and by applying your company or project configuration standards to the prototype.
The principals of the structured analysis and design technique are more structured as the name implies. The requirements are first decomposed into building blocks, which interact with each other; the interactions are then designed in full, followed by the design of the processes, which occur within the building blocks. In some cases, the building blocks themselves may be decomposed and the cycle repeated.
Update: Scott provided me some great pictures which I’ve included in the post.