Top down and Bottom up Engineering are two different design methodologies used for design of complex engineering systems. You probably use one, both or a combination of these methods on a daily basis without consciously thinking about it. Both design methods have their individual advantages and disadvantages when applied to Systems Engineering. Understanding the differences can help select the most cost effective approach or, if the approach has already been selected for you, help you identify what issues you are likely to expect.
In short bottom up engineering is probably simpler and initially more flexible to change. It allows a faster initial learning curve on the basics and can be great whilst getting some base level knowledge. Top down engineering is more reusable and repeatable with lower whole of life costs. It has greater initial complexity but enables faster design iterations with less ongoing engineering requirements. Perhaps it's a kick back to our university days ("Bottoms Up!") or perhaps because engineers like solving problems more than planning on solving problems, that the Bottom Up approach is our usual first tactic. However bottom up engineering becomes more difficult and costly to change the further into a design you go.
Like all good dance floors, the selection process should start with some "Man in the Mirror" moments. One of the first parts of the process is identifying "Where are we now?" in terms of your engineering life cycle and business knowledge base. For example IEC 61850 is great for repeatable and reusable engineering. If I have an ageing asset and one legacy relay has failed, going through the process of System Requirements Specification to upgrade it to a 61850 based design is probably not viable. Alternatively if you are replacing a switchyard a Top Down design that reduces ongoing engineering and costs over whole of life for the asset is ideal. If your business doesn't have the knowledge base or experience in Top Down Engineering, Fast specialises in this aspect of design and can help specify your required system.
Top Down Engineering
As mentioned Top Down design is more about being reusable and repeatable with lower whole of life costs. It has greater initial complexity and starts with the big questions like:
- What does the end product look like in terms of layout and functionality?
- Can the overall system be broken down into repeatable/reusable subsystems or components?
- Can these subsystems be broken down further describing their functionality?
- What are the performance requirements of the individual subsystems?
- What data is expected out of the system and how should it look (including naming, timing and precision specifications)?
Further reading on the System Specification stage is covered in System Specification
As top down is more interested in the "What" than the "How" it typically has greater flexibility for changing subsystem components and implementation tools later. eg. swapping one IED model for another that better implements your specified functionality. Top down sets firm goal posts for pass/fail criteria during product research, procurement, prototyping and commissioning stages.
Fig. 1 Example of Top Down Engineering Flow
Templates can be used as building blocks for larger Templates by repeating the process to create a library of products that meet the functional specifications. Modular systems could be implemented from multiple templates.
Bottom Up Engineering
Most Bottom Up projects start with a conversation along the lines of "We have this old relay that has failed and we want to replace it with this new one. Can you make it work?" They will even put extra emphasis on the words old and new to make one sound the villain and the other the hero. The bottom up engineering method is essentially a "start with a product and make it work" approach. On occasions when issues are discovered late in the process you may find yourself committed to a product and then end up negotiating system performance requirements with stakeholders that are less than ideal.
Some initial questions that can lead you down the Bottom Up approach are:
- Are we replacing a product that has failed in service? The device that was here was performing fine.
- I don't really know much about this product and I'm not sure what I want but how do I make it work?
- Is there a System Specification in place that we just need a new product for?
- Is this a minor system upgrade with no System Specification for the current implementation?
- Do we need to reverse engineer the legacy system to confirm documentation and performance criteria?
The Bottom up Engineering approach commences with System Integration of a lower level component via an iterative approach into a more complex system. Iterations tend to be evaluated via a pass/fail approach on perceived or specified performance criteria. This approach is ideal for a minor System Engineering upgrade or replacement (with or without a previously developed System Specification) and legacy systems that are often lacking adequate records and documentation. In some circumstances reverse engineering may be necessary to discover data and analysis of the System being upgraded or replaced.
- Design begins with the practical application of the project
- +Best applied to brownfield sites or "one offs" (in most cases)
- +Informal learning environment (practical problem solving)
- +More rapid results on simplistic designs
- +Good for product familiarity and product research (depending on how soon you discover "features" of a product)
- +Reduced implementation costs for minor projects
- -Change management for engineering standards is significantly more difficult (if possible at all)
- -Changes to the system architecture increase impact (costs) the further into the design you go (sometimes significantly)
- -Completed system results are not available until late in the design
- -Increased whole of life costs
Fig. 2 Example of Bottom Up Engineering Flow
Brenton Ford
SCADA Para Professional, FAST Engineering
Wade Harris
Senior SCADA Engineer/Director, FAST Engineering
Contact Us About This Article
