Translating New Product Requirements into Hardware Architecture

Translating New Product Requirements into Hardware Architecture


Defining initial hardware architecture requires many decisions, most of which impact a variety of different stakeholders and requirements – including multiple design tools – circuit design, PCB layout, mechanical design, spreadsheets, etc. that are used to track different elements of the design. It sometimes seems that by the time you determine the impact of a decision on all the requirements, the design has changed to a point that your decision is irrelevant.

Combining different sources of information

Sometimes I come across people who struggle to understand why translating new product requirements into an initial hardware architecture is frequently such a difficult task. After all, much of the design is frequently pre-existing such as SOCs, reuse blocks, previous-generation enclosures, etc.  So it seems like defining the initial hardware should be a relatively easy process of connecting these blocks together and creating whatever else is needed, right? Seems logical.

But we also know that it’s much, much more difficult than that. Requirements come from many sources such as users, marketing, manufacturers, financial and other stakeholders and they consist of many different attributes such as features, size, weight, battery life, cost, delivery date, etc.

The importance of a cross-functional process

Many professionals have to deal with collating information from different sources to put together plans and make the right investment decisions. But the challenge for hardware engineers or system architects (whomever is responsible for that initial concept creation), is much greater. You might be used to having to deal with all these fragmented sources, but that doesn’t mean there isn’t a better way. A way that all your effort can be reused and integrated into the realization of the product. I’m talking about integrating logical design, multi-board 2D planning, 3D space planning and parameter trade-off analysis into a single interface that allows you to make a more informed decision about what features and functions to include or not. Making it possible to simultaneously consider the effects of alternate approaches on functionality, price, performance, size, weight and other targets with very little time and effort.

I guess seeing is believing, and to save copious quantities of words, I figured you might just find it easier to check out one of our webinars that shows how this works in reality. The webinar is called “Creating and Optimizing a Hardware Architecture.”

In this webinar, you’ll be walked through a typical example involving designing a power supply and you’ll see how this cross-functional approach of electronics hardware architecture planning can be simplified.

As a prerequisite to this, you can also watch the webinar introductory webinar on this topic entitled “Hardware Architecture Design and Validation.”

Bob Potock
Bob Potock
Vice President of Marketing, Zuken USA, Inc.
Bob Potock is Vice President of Zuken USA marketing and is passionate about Zuken's leadership role in Digital Engineering. Bob is developing new solutions to address today's growing product complexity that include expanding the partner ecosystem and the adoption of Digital Engineering methodologies. Bob lives in Colorado and enjoys hiking, fishing, golfing, and time in the mountains.