Follow the “what”, the “how”, and the “validation” as we navigate the ins and outs of the so-called design process.
The Design phase is the step that governs the implementation – actions and tangibles embodied in key components of the product (or simply the product itself), which fulfill one or a set of requirements – and puts it on paper. Why “on paper”? Well, because we want to poke holes at it to see how robust the approach really is before moving forward. “On paper” doesn’t mean it’s all just theory. You could easily test 1, 2,… 5, or more different methods as part of your design exercise and have preliminary results to back up your (or the team’s) final decision. Of course, projects are bounded by time, budget and other factors, so the design involves a trade-off between robustness and time to design sign-off. The more preexisting knowledge you and the team posses coming into a design, the more favorable that trade-off becomes. Understanding the implications of the decisions being made, following best design guidelines and ideally knowing (more or less) what the state-of-the-art looks like in all applicable disciplines, are all key to a successful design. Generally speaking, there is a large spectrum of considerations and constraints, each of which applicable to different technical areas, that teams and designers will need to take into account during the design phase. The specifics and technical depths of these considerations are beyond the scope of this article, but a few of them are listed here, for reference – note that several of these can also be defined as requirements:
Financials (e.g. budget)
Manufacturability according to existing and accessible manufacturing processes
Maintenance and serviceability
Social and environmental impact
System and subsystem interfacing
Health and safety
Risk and reliability
Design codes and laws, when applicable
How?… and Why that Way?
Figure 1 summarizes the different components of the design and implementation process, which can be broken down into at least two categories (or questions): “How?”, and “Why that Way?”. Starting with “How?”, we realize that it is a broad question to answer, because it applies at multiple levels. For instance, “How?” must first answer: what means will be used?… what tools, raw materials, software packages? As a side note: when working in large organizations or on mature products, the choice of tools may be voided all together. This happens when the decision is simply inherited from previous development cycles, where other teams have used and proved the validity of a given tool set, and therefore replacing it may represent a risk more than a potential reward (which is already answering a different question: “Why that Way?”).
Figure 1: Key Elements of Design and Implementation.
Once the tools are selected, How will they be used to deliver a Tangible and ultimately meet a requirement? The Tangibles are the result of the implementation, and will need to be evaluated against one or more requirements, at a component level, or at the system level. In Mechanical Design, for instance, a tangible can be a CAD drawing complemented by an FEA analysis showing low stress during dynamic loading, guaranteeing compliance with the product’s expected lifetime (say a quality requirement). In a Dynamic System operated under closed-loop control, the tuning of a PID controller that satisfies a given input-output response or a performance metric. So, the answer to the “How?” is accompanied by a technical justification or proof of satisfaction of a given requirement. The quality of that proof will vary depending on the effort invested by the team, the project timeline or urgency, budget, and other factors. Typical justifications are:
Simply put, the proposed design allows the fulfillment of one or more requirements. This is the simplest and most common justification, which will likely necessitate additional scrutiny or pre-validation to convince the team, and also yourself, that the design is robust. This can include: pure simulation, mathematical proof, SIL testing, HIL testing, lab testing, real sample testing, and others
One or more requirements have been met and the design has been reviewed and approved by experts through a Design Review. Who are “The Experts”? The team members or stakeholders that have proactively provided feedback to the design owner(s) and have signed off on the design – more on "The Experts" later. This will also need validation, but there is already a higher degree of confidence in the design prior to testing
One or more requirements have been met, the design has been reviewed and approved by several experts, and one or several standards have been followed in the proposed design. Once again, testing is inevitable, but the confidence level on this approach is of course much higher
Note that these two questions – “How?” and “Why that Way?” – equally apply when developing a new product, or when working on a development cycle of an existing product (i.e. a product upgrade).
Standards and Best Practices
Standards and best practices derived over a long time span by industry, competency teams, academia, etc. are powerful tools for any team during a design phase, as they inherently provide some level of justification. They simplify your life and everyone else’s. Telling others you will use a standard component or practice gives teammates a peace of mind; they will more easily agree with you and you will know that what you are implementing has been tested and proven by other specialists in the past. Yes, it’s a win-win! For example, in Programming this may involve selecting the right code structure and using best coding practices to minimize the chances of bugs affecting the code. In addition to serving as an advocate for the robustness of your design, industry standards can also facilitate the implementation process. The more mature a standard is and the wider its use, the more readily available documentation, off-the-shelf components (say parts for your implementation) and support you will find. These benefits may not be as obvious or accessible in industries leading one or multiple technology fields, where innovation, research and development are paramount to their products. This is simply because they don’t exist. And even then, these companies will – sooner or later – start generating their own “best design practices and procedures” for internal use in future development cycles.
A note on Design Reviews: Who are “The Experts”?
In simple terms, a design review is the exercise of evaluating the approach that has been chosen for implementation, to ultimately fulfill a requirement. The final design review is a key milestone of the Product Development Process, where the design is assessed one last time and is signed off prior to implementation. Here, you may be thinking: boring!… but if used correctly, you may replace “boring” with “robust” (or at least attached them together, with a “but” in-between). A good use of a design review can return high gains for you and the team. Earlier, multiple steps and considerations were laid out to help answer the design questions of “How?” and “Why that Way?”. But who gets to judge the accuracy, applicability and technical validity of the answers posted by the lead designer to those questions? Who gets to vote for one design vs another? Who is really capable of suggesting and recommending improvements to the proposed approach? The simple answer is: The Experts in the fields applicable to the design – this design, your design. The experts in the field or fields relevant to the design are not necessarily constrained to people involved in the project (the stakeholders, who are certainly a key part of this group). Highly likely, in medium to large organizations there will be experts spread throughout different teams or departments. With a brief introduction to the subject under question plus a quick review of the requirements (high- or low-level), these experts can provide key insights and help you and your team more easily and successfully navigate through a wide range of technical challenges, and even address doubts about the proposed approach based on their personal experiences and know-how. Think of a design review as the in-person version of an online forum of experts, where regular individuals and other experts describe the problems they are facing within the technical scope of the forum. Whenever a question is posted, more often than not the introduction to the question doesn’t need to be too elaborate and it can immediately and explicitly contain technical jargon, not easily understood by individuals without extensive knowledge on the subject. By raising the question in the forum, you are essentially leveraging the knowledge of many experts that can help you evaluate your design. So next time you call a design review meeting, or simply want feedback on the approach you are planning to take before going to implementation, don’t shy away from engaging experts outside your team or project.
Industry Standards Case Study: Component Selection for Battery Pack Design
Let’s assume that you want to build a battery pack for an E-bike prototype, using Li-based battery cells (say Li-Ion 18650 cells), in a series-parallel configuration. On paper, you are not constrained to a specific voltage for your battery pack. If the power output meets your controller and motor power demands, you should be fine. Correct?… well, let’s see. The required power capacity is >500Wh. According to the calculations in the table, you should be able to meet your requirement by selecting any of the highlighted series-parallel combinations:
7s6p, [8s5p, 8s6p], [10s4p, 10s5p, 10s6p], [12s4p, 12s5p, 12s6p], [13s3p, 13s4p, 13s5p, 13s6p]
Finally, you decide to go with the highest voltage, and you pick a 12s5p configuration (3 holders connected in series yielding a 3-5×4 cell layout), resulting in 44.4Vnom and 777Wh output capacity. You buy all the equipment to solder the pack, and put it together.
Next, a Battery Management System (BMS) is needed for your 12s pack. From an online search you realize that the only BMS board rated at 44.4V costs $100, and the earliest that you can get it is approximately one month from the day ordered, because there is no local supplier and it comes from overseas. Ouch! This completely destroys the budget allocated for the project and the timeline - budget and timeline defined in the requirements phase. What went wrong? As mentioned earlier, industry standards can play a key role in the success of the implementation. A quick online search shows that BMS boards, Motors and E-bike controllers are widely available for the following nominal voltages: 24V, 36V, 48V. So, increasing the size of the pack from 12s to 13s (13s5p) results in 48.1Vnom, which is now an industry standard and thus readily available off-the-shelf. The BMS board for a 13s configuration costs $10, with guaranteed next-day delivery. Success!
While standards can certainly enhance product design, they can also represent biases preventing you and your team from exploring outside-of-the box ideas. So finding the right balance is part of the Systems Engineering exercise.
コメント