In the architecture phase technical leads from the different disciplines work with marketing and business teams to define a product. Important information that guides the architecture of the electronics is determined such as the intended lifespan, the intended volumes, environmental conditions, and cost targets. The outcomes of the architecture phase for electrical engineering are architecture of the electronics, schedule, required resources (people and expenses), and electronics cost estimates.
What exactly is meant by architecture of the electronics? This means the design defined at the block diagram level. So, it means partitioning of PCAs, cabling and I/O technologies defined, power subsystem defined, processors, memory, key analog circuits defined. But, it does not mean that schematics have been created or that details of the design have been worked out.
Key Information to Determine
- Lifespan – How long will this product be sold to customers, and how long will it be supported beyond that?
- Annual Volumes – Do we plan to sell 100 of these a year or 1 million?
- Cost Targets – Given the expected price of the product to customers, what cost range is acceptible for the electronics?
- Environmental Conditions – Will the product be used in a temperature controlled environment? Will it be exposed to liquids or excessive dust? Will it be used near industrial equipment producing lots of electromagnetic interference?
- Leverage Points – Parts developed for other products and purposes that can be adapted to the current project.
Outputs of the Architecture Phase
- Detailed Block Diagrams – Shows the blocks of circuitry and how they connect, and covers power subsystem, PCA partitioning, and cabling.
- Is/Is Not List – lists functionality of the electronics that is planned to be included in the product and functionality that is planned to not be included.
- Power Estimation – estimate of the power consumed by the product, and the estimated power consumed from each power rail within.
- Obsolescence Analysis – identification of and plans for electronic components that may go obsolete during the lifespan of this product. Also, includes identification of multiple suppliers where available.
- Cost Estimate – estimate of the cost of the electronics based on expected product volumes and taking into account overhead in manufacturing, supply chain, and sales.
- Schedule – initial estimated schedule showing people, tasks, dependencies between tasks, and milestones (checkpoints)
Block Diagrams
Block Diagrams convey alot of information and provide a common reference for design teams. When creating block diagrams, I recommend to create both detailed diagrams of the electronics and also simple diagrams showing just high-level info. The detailed drawings are important to the design teams who need to be clear on all the details. The simplified drawing are usesful for management and other folks associated with the project, but who are not doing implementation. They need to see the big picture and the major pieces and do not need to be distracted by excessive detail. Also, I think it is a good practice to create a system diagram, but also focused diagrams. If warranted, you may want to create block diagrams of the power subsystem, reset circuitry, feedback control loops, clock subsystem, etc.
Example Block Diagram – MIPS Processor Pipeline
.svg#/media/File:MIPS_Architecture_(Pipelined).svg)
By Inductiveload – Own work, Public Domain, Link
Is / Is Not List
Is / Is Not Lists are used to capture the feature set of a new design as agreed upon by the development team. It details clearly what features will be included, and it is also states what features will not be included, especially ones that were discussed and decided against by the development team. Sometimes an ‘Is Maybe’ column is included. This is a place to list feature options that are still undecided, and the idea is to work towards moving those items to ‘Is’ or ‘Is Not’ by the end of the Architecture Phase.
Below is an example and a link to an Excel template. The example shows a few features one might consider when developing a new computer motherboard, code named project Saturn, because naming projects after planets is not overdone yet :).
Power Estimation
It is quite difficult to accurately estimate power consumption. EEs often end up using maximum specified power specs for each chip, adding some more power budget for parallel resistors and for dynamic signal driving, which is a guess based on how many I/Os are powered by a particular rail. Then, with the loads on the lowest level rails in the power hierarchy determined, we use the specified efficiency of DC:DC converters to calculate the load on upstream rails in the hierarchy.
POUT = PIN * EFFICIENCY
Rearrange: PIN = POUT / EFFICIENCY
This process will usually lead to a design that works, but which has significant excess power capacity, because not all the chips in the design draw max power at the same time, not even close. Alot of excess power capacity should be avoided, because it adds needless cost to the design, and because then more power is available to do bad things when short circuits occur such as melt wires. You really want to right-size your power subsystem.
The best way to improve your estimate is through leverage. If you are leveraging previous designs that have been implemented, look up the measured power data, or measure it yourself if you have to, and use that as a basis for your estimation. Another way to improve your estimate is to employ simulation software. Companies that make complex chips such as Microcontrollers and FPGAs often provide software for the purpose of calculating a more accurate power estimate.
Cost Estimate
Electronics Architecture Design Review
Near the end of the architecture phase, it is important to host a design review of the electronics architecture with the broader engineering community. Review the architecture with the EE team, mechanical engineering, software/firmware engineering, other R&D disciplines, and also review with manufacturing and supply chain folks. If you work in a large company, you may also want to review the architecture with key folks from other divisions to gather feedback from their unique perspectives and discuss leverage and cooperation opportunities.
I recommend to keep design review meetings small and focused. Have separate reviews with different disciplines. The reason I think large meetings trying to cover ME, FW, EE all at once don’t work well is that people stop paying attention during discussions that are irrelevant to them, and then when something relevant finally does come up, they miss it.
Next: Investigation Phase