Mitigating Board Complexity with System-level Engineering

Well, there’s no doubt about it: Developing circuit boards is getting more complex.

Demand for faster data speeds is increasing. Boards are becoming more dense. Requirements call for the latest protocols and devices. Packaging constraints call for multi-board and flex-board systems. The surest sign of escalating board complexity lies in the fact that few are designed by a single engineer. Today, most require the coordination of many engineers instead. And overall, this trend shows no sign of abating. Board complexity looks like it will only get worse.
Obviously, all this complexity carries risk, both in terms of time and money. So how do you mitigate it? One answer might surprise you: system-level engineering.

Applicability of system-level engineering

Now it’s true: system-level engineering has not been widely used in board development to date. However, it offers some interesting advantages to anyone faced with increasing design and development complexity, including electrical engineers. This includes methodical practices to:

• Manage and coordinate change, such as the collaboration required of board engineers, package engineers, and electrical systems engineers.
• Plan higher-level board architectures, including board partitioning, in such a way that supports the overall requirements for the board-based system.
• Gain visibility into the implications of change through traceability, whether that is potentially changing a requirement or swapping out a component.

Almost every engineer implicitly does these things in their head. However, different expectations of these items by different members of the design team leads to costly errors. System-level engineering practices and tools help define an unambiguous definition that everyone can follow.

Developing architectures, managing behaviors

One of the most intriguing applications of system-level engineering to board development is creating a systems architecture. More specifically, these architectures define the interconnected behaviors and structure of the system, in this case a multi-board system, in a model. That model is composed of:

• Requirements: statements of need that the design solution must fulfill. This can include weight, power consumption or size of the enclosure.
• Functions: statements generally defining a capability provided by the design solution.
• Logical definitions: the logical definition of the design solution. In this case, a multi-board schematic fulfills this aspect of the model.
• Physical definitions: the physical definition of the design solution. Here, this includes the multi-board layout and the 3D model. Both of which must meet the defined requirements.

The key here is that these different aspects of the model are allocated to one another. A requirement is assigned to a specific function, which fulfills the requirement. The function is assigned to an aspect of the logical definition, which enables the function. The aspect of the logical definition manifests as the physical definition, which supplies that logic. This all results in an interconnected web of requirements, functions, logical definitions, and physical definitions. Altogether, that is a system-level architecture.

Trade studies with many architectures

Where system-level engineering becomes truly powerful is when developing multiple systems architectures. Why? Because they can conduct trade studies to compare and contrast which addresses the top-level requirements most completely, most cost-effectively, or most easily. Many considerations can be taken into account, depending on the measures for success of that board systems development project.

This activity, specifically, is meant to address the problems many board design teams encounter late in the development cycle. Why? Well, early in development projects, engineers must make key decisions, often not having all of the required information for a successful system implementation (e.g., enclosure dimensions or weight). Such decisions represent committed constraints. Later in the development cycle, many design teams realize they have designed themselves into a corner. As a result, they must seek out more radical modifications to the design in order for it to fulfill intended requirements.

Instead, developing and comparing multiple systems architectures allows engineers to understand the trade-offs between their high-level choices. These architectures lay bare the constraints design teams often uncover late in development (e.g., exceeded a power consumption budget). Armed with this information early, the team can make better choices that leave them more flexibility and freedom later in development.

Wrapping it up

There’s no doubt that board systems are getting more complex. System-level engineering can help mitigate those risks. One of the main advantages is developing and comparing systems architectures, which provides visibility into the constraints of design decisions to engineers. That allows them to avoid nasty surprises late in development.