paint-brush
PCB Development or Enclosure Design: Which Comes First?by@andreysolovev

PCB Development or Enclosure Design: Which Comes First?

by Andrey SolovevApril 3rd, 2024
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

Electronics consist of two key elements – a printed circuit board and an enclosure. Customers will often have to order these two elements from different contract developers although some companies offer both these services.
featured image - PCB Development or Enclosure Design: Which Comes First?
Andrey Solovev HackerNoon profile picture


Let’s assume that you want to design a new electronic device. Electronics consist of two key elements – a printed circuit board and an enclosure. Customers will often have to order these two elements from different contract developers although some companies offer both these services. So here you face a critical problem – which of them should be developed first? You’ve got two options.

Start with PCB design

One option is to develop the PCB first and only after that design the enclosure. This approach is acceptable if the appearance and ergonomics of the device do not play a vital role. In this case, electronics developers are not limited by the shape or size of the housing. They can create a PCB of simple shape (rectangle, square, or circle) and adequate size, using the most optimal layout solutions and components. When the circuit board is ready, you can move on to designing the enclosure or even use an off-the-shelf housing with minimal changes. It will save you money, but don’t expect much in terms of aesthetics. But before choosing an off-the-shelf enclosure, consult with the developers to make sure it is suitable in terms of size, material, and shape.


Here is an example of an off-the-shelf enclosure. It’s simple and not very attractive but very durable.


Iterative approach

Contrary to what one may expect, this option doesn’t mean that you should design the enclosure first and only then develop the electronics. PCB design is an iterative process. Consequent changes to the electronics may require changes to the enclosure and vice versa. So, this approach rather implies developing both these elements in parallel. This option is preferable when the appearance of the device and its ergonomics are as important as its functionality.


The iterative approach takes more time and money compared to the first option but results in an optimal combination of functionality, ease of use, and aesthetics. Therefore, this approach is usually a better option.

What can you do at each PCB development phase to make enclosure design easier?

Phase 1: Requirements gathering

The more thoroughly you describe the requirements for your device, the less rework the project will need. Detailed requirements also ensure there will be no misunderstandings between the customer and the development team. One should describe not only the functionality of the electronics but also the appearance of the device. Therefore, it is advisable to have a 3D model or at least a sketch of the enclosure by this phase. It will allow the team to estimate the feasibility of the project, select optimal solutions, or warn the customer if the enclosure requires redesign.

How can you help?

Do not make the team wait because they cannot start the development without your project requirements. The sooner you provide the engineers with all the necessary information, the sooner the work will begin. Contract developers often ask new clients to fill out a special questionnaire and list the following requirements.


  • Functional requirements

Here the customer should explain as clearly as possible what the future device should do. Describe its main functions and features. Don't worry about how they can be implemented from the technical point of view – that's the developer's job. Explain what purpose the product serves or its intended applications. Give one or two use cases. If your idea is not unique, list analogous goods available on the market and explain how yours should differ from them.


Let’s imagine a customer ordering custom electronics development from a contract design house. Here is an example of how he or she could describe functional requirements for his project:


The team should create a pair of devices for displaying information during sports events. The pair consists of a control panel and a scoreboard that displays the information. The system is designed for sports such as soccer, basketball, football, and baseball.


  1. The control panel should be able to transfer data to the scoreboard: team names, score, current half-time, etc.
  2. The control panel and the scoreboard must be two independent devices.
  3. The scoreboard should be able to display indicators of different types and sizes, i.e., the scoreboard should be modular.


  • Non-functional requirements

They describe the features of the device that are not directly related to its functionality but are important for some reason. Here you should indicate anything you find vital, for example:


  • desired power source;
  • whether the device should have a display;
  • whether the product needs peripheral devices and which ones (for example, a camera);
  • whether the device should be able to store data;
  • whether the product should transmit data and which technology you prefer – Ethernet, Wi-Fi, GSM, etc.
  • desired size and shape of the PCB.


The latter is directly related to the enclosure design for your future product. Developers can implement one and the same functionality using different approaches: make a double-sided PCB or a board of six layers; use standard and cheap components or small and expensive ones, mount the components on a rigid PCB or a flexible one, etc. That’s why they would be glad to have a 3D model or a sketch of the enclosure to minimize the possibility of making the wrong choice.


Printed circuit boards can have complicated shapes. Developers need to know about such requirements in advance.


Here is an example of non-functional hardware requirements for the project mentioned above:

1.1. The control panel should be able to transmit data to the scoreboard wirelessly. 1.2. The scoreboard should be able to receive signals from a distance of at least 152 m. 1.3. The delay between pressing a key on the control panel and updating the information on the scoreboard should be about 50 ms. 2.1. The scoreboard should be connected to the control panel before starting work. 2.2. The control panel should have an external power source and battery backup. The battery life depends on its size, which will be determined when we get to the enclosure design. 2.3. The scoreboard should have an external power source. 2.4. The control panel should be the size of a standard full-size keyboard. The user should be able to place it on a table and use it with two hands. At the same time, it should be small and light enough so that the user can carry it in one hand and press the keys with the other hand. 3.1. The elements of the scoreboard should be easy to connect. 3.2. Incorrect connection of the components should not cause serious problems.

Please note that the customer does not yet have an enclosure or even a sketch. However, he or she already has some idea about the size of the device, which was shared with the team in paragraph 2.4.


  • Operating conditions

In what environment do you plan to use your device? Is it indoors or outdoors, in the rain, in extreme cold or heat? When possible, list specific environmental conditions and their parameters:


  • Temperature
  • Humidity
  • Pressure
  • Vibration
  • Hazardous areas: explosive environment, areas with high content of aggressive corrosive agents or other chemicals, etc.


If you’re building a consumer-grade product, it is sufficient to indicate that it should operate under normal conditions: a temperature of 25±10°C, relative air humidity from 45% to 80%, and atmospheric pressure from 84 to 106.7 kPa.


The customer mentioned above wants his or her control panel to be used mainly indoors, which corresponds to normal conditions. But the scoreboard has to stay in the open air. Here is how the customer can describe the requirements for this part of the system:


  1. The scoreboard electronics should be able to operate on the hottest summer days when the temperature inside the enclosure reaches about 65°C.
  2. In addition, the scoreboard should be able to operate in the rain. I would rather that the indicator elements do not require special protection from water. Alternatively, you could use a conformal coating.


  • Certification requirements

Almost any electronic device intended for commercial sale must meet quality and safety requirements.


If you are not an expert, handling this matter on your own may be very difficult. Contact the notified body responsible for product certification in your country to learn about specific requirements or hire a private business that specializes in this field.


Legislation in this area often requires devices to have a sufficient level of protection from certain factors: moisture, dust, fire, electromagnetic noise, electrostatic discharge events, etc. Requirements depend on the type of the device and its area of application. Make sure to share this information with both electronics developers and enclosure designers.

Phase 2. Project Estimation

Engineers cannot move on to the next project phase before they collect the requirements. When you provide all the information about the functions, features, and operating conditions of the product, they can estimate the project from a technical perspective.


Estimating a simple project takes little time. But complex projects may require more time and effort, sometimes even an additional research phase that can help developers answer the following questions:


  • Is it possible to create your device at all?
  • How to design it?
  • If there are more than one solution, which one is optimal?
  • How much will the product cost?
  • How much will the project cost you?
  • How long will it take to develop your product?
  • Is the proposed enclosure design compatible with the PCB?


After that, the team will be able to tell how long the development will take. Simple projects usually take about 150 hours. Complex projects may take about 500-700 hours or even longer.

How can you help?

The best thing a customer can do at this phase is to give the team enough time. Additional research allows engineers to identify many less obvious problems at an early stage of the process. If you skip this step, the project may require serious modifications and alterations later, which means even more work, time, and money.


Phase 3: Development

This is when the actual development begins. Engineers create a PCB schematic, select components, and build a 3D model of the board. Then the PCB is manufactured and tested. If necessary, the team also creates software for the device.


Many developers create a second iteration of the PCB after that. The first version of the board almost always contains faults and shortcomings. In addition, components sometimes behave in a way different from what their documentation says or begin to affect adjacent components in an unexpected way. In this case, the components have to be replaced. The team can eliminate most of these problems when creating the second iteration. The second version of the PCB often requires modifications as well, but they are usually minor fixes.

How can you help?

At this phase, you will most likely have to choose between appearance and functionality. You may have to give up some functions and features of the device in favor of its appearance, or vice versa, sacrifice the ease of use for the sake of functionality. Make sure you have an enclosure prototype by the time the PCB is ready for testing.

Phase 4: Testing and Debugging

At the final stage, engineers place the PCB inside the enclosure prototype to test how the device functions under appropriate operating conditions. If developers discover any issues, they find the cause and fix them.

How can you help?

Customers can and should test the product too. You should check not only the functionality of the product but its ease of use as well. After that, the enclosure may undergo further changes, mostly for the sake of ergonomics.


For example, the customer may want to change the location of buttons or LEDs. This will require changes in both the enclosure and electronics design. Moreover, if the previous iteration of the device didn’t have any LEDs, and now the customer wants to add some, the developers will have to create an additional PCB for controlling the LEDs. This is a minor change, but it still requires time and effort. Nevertheless, you may find such changes absolutely necessary even if they solely improve the product’s ergonomics.


Two prototypes of an enclosure for an electronic device.


Highlights

If neither the PCB nor the enclosure for your future device has not been designed yet, you have two options.


  • When the appearance of the device is not particularly important, you can first design the PCB and only then design the enclosure for it. Alternatively, you can use a cheaper off-the-shelf enclosure.
  • If the design of the enclosure is no less important than the functionality of the device, it is recommended to prepare at least a sketch of the enclosure first. After that, both the enclosure and the electronics should be developed in parallel.


Make sure to clearly communicate product requirements, including desirable PCB shape and size, to the team to avoid problems with enclosure design. It is also important to give engineers enough time to estimate the project and conduct additional research if necessary. It will highlight potential problems at the very beginning of the work. As development progresses, you may have to choose between the appearance and functionality of the device. Lastly, when the prototype of the device is complete, you should test it to check its ease of use. After that, you may want to make certain changes to both the enclosure and PCB design.


This approach allows you to reach a compromise between the appearance and functionality of the product while minimizing risks.