Why you should be using model-based systems engineering in your design flow.
Recently, we had a customer request a tool change to add a new design feature to their product.
The product is a small electromechanical kitchen appliance, designed by the customer’s own USA based design team. Think, motor, rechargeable battery, three PCBA, over a dozen custom-built tools, more than 80 line items in the BOM, over one year of engineering before we saw it.
Our role is as the CM, responsible for building and assembling parts per the customer’s design specifications. The change request to add a new feature arose after we built and shipped the first 20 piece engineering build.
After receiving the engineering build, the customer noticed during the review, the product’s design intent is to be portable. Yet, the product was annoying to port around.
Due to a mismatch early in the design process between identified needs, specifications, and detailed design features. A crucial part in the current product revision easily slipped out of it’s intended position during movement. The new feature would reduce slippage and improve the product’s portability.
The changes required to add the new design feature seemed straightforward. Our customer’s design team submitted a change request, which required us to create a dimple in one injection mold tool. Put a notch in another injection mold tool. Finally, when molded parts come out of these two different injection tools. The dimple from one part will fit the notch in the other part. And voila, the product has a new design feature to reduce part slippage.
Meanwhile, the customer’s timeline was tight. They wanted the first order shipped for Christmas. Except for the new feature, they deemed the engineering build good enough. So, they asked us to make the tool change while also releasing 1,000 pieces to production. The intent was to run a small first order which doubled as a pilot build.
Fast forward about a month. All required materials for the initial 1,000 piece build was ready. The customer made a visit to work with us for a final pre-production review. Our engineering team then assembled some finished products with the customer’s design team.
At this point, we found that if we also modified another part, a switch bracket, the new anti-slip design feature would work much better.
By then, we’d already built 1000 pieces of the switch bracket, to meet existing specifications. Now, we’d need to rework the brackets, push back the timeline a week, and also charge a rework fee due to required secondary processing on the brackets. This entire situation made everyone unhappy.
So, from the perspective of a CM who is often building products which we are not responsible for the design. The question becomes, how can we create an environment and processes where a customer adding a new design feature so late in the game, carries a lot less risk of mistakes and oversights?
Asking myself this question has taken me down a path of reflecting on the last 10-years of design and project work that I’ve seen. Most face this type of pain. Something has systematically been missing in nearly every project.
Backing up a bit, I’d like to clarify our current position in the universe. From a top level, typically contract manufacturing companies are segmented into three tiers:
Tier-3 CM’s exist because they will compete for much smaller MOQ’s and total project dollar values, versus larger CM’s. Tier-3’s can generally offer the lowest total cost of engagement because they carry far less overhead. Of course, when you buy near the bare metal, you get the resources you pay for, but that is a topic for another article.
Currently, BOM Quote Manufacturing is a Tier-3 CM. As a Tier-3, we’ve had a few orders over $1M USD, but most are between $50K USD and $500K USD. Product designs we review for quotation with MOQ’s in this budget range fall into a wide distribution of design state and engineering polish.
Some designs are reasonably ready for manufacturing, in that they have documentation like a Product Requirements Document (PRD), 2D-drawings with specifications, and well-defined CAD models. But, many are half-baked with little documentation and a significant amount of hand-waving going on around critical aspects of the electronics design or other IP.
But upon reflection. I’ve come to realize, the critical thing nearly all designs we’ve reviewed and even the ones we’ve built have in common is. Nearly all had a lack of clear focus on systems throughout the design phase, from a systems engineering perspective. This is the at the root of most project problems.
This includes a lack of a standardized systems engineering level review and testing through each design phase and after each design change, to catch misalignment between needs, specifications, features, and requirements at the earliest points in the design process.
What do I mean by that? In my experience working with designs in our market, it is nearly inevitable at some point we’ll discover that the design has some mismatch between one or more of the following:
- needs and specifications
- specifications and manufacturability
- product requirements and specifications
- design features and product requirements
The new product introduction (NPI) phase where we work with customers to go from the initial design documents to shipping their first order, is almost entirely an exercise in discovering mismatches in these areas. When we find mismatches, in the best cases, we measure the negative impact on schedules in weeks. Too often, it is measured in months.
Managing these areas during the design phase lies in the domain of systems engineering. Systems engineering is “a multidisciplinary approach that is intended to transform a set of stakeholder needs into a balanced system solution that meets those needs.” [1]
The point is, most hardware projects that face severe project issues do so due to taking a poor system engineering perspective throughout the design phase.
But, wait a second. How do you do systems engineering level review and testing through each design phase and after each design change, before you even build real systems to place under test?
First of all, unquestionably, you should strive to iterate through physical models and prototypes, to test real assemblies and subassemblies. Are you building a product with speakers? Certainly, you should buy, tear down, and experiment with as many similar products with speakers as you can find.
But the answer I’m looking for here is, you build a systems engineering model, from the very beginning of the design project.
Model-based systems engineering (MBSE) is “the formalized application of modeling to support system requirements, design, analysis, verification, and validation activities beginning in the conceptual design phase and continuing throughout development and later lifecycle phases.” [2]
The model then provides a testable framework to provide feedback through each phase and design change. It should help ensure design consistency, between needs, specifications, requirements, and realized design features.
In leading organizations that are fully bought into MBSE, the model itself can replace many standard design and test documents, or else generate them directly from the model. But, due to working with external vendors and CM’s, in many cases, a hybrid approach is warranted.
If you implement MBSE into your design processes, you should reap an improved design which results in a much smoother NPI phase moving into manufacturing. Because, you will have already discovered or avoided mismatches between needs, specifications, features, and requirements, which are at the root cause of most NPI phase project pain.
Mechanical engineers build their CAD models. Electrical engineers build their schematics, and in our own typical customer demographic, they are probably doing the firmware as well. If somebody is not also building a system model, you’ve got a gap for improvement in your new product development process.
Where can you find out more? Learn about Model-Based Systems Engineering (MBSE)and Systems Modeling Language (SysML) which is a dialect of UML and not too overwhelming to quickly grok. You will need modeling software. There is a range of free and paid software in this MBSE + SysML space, but currently, the paid software is much better than the open source versions.
We at BOM Quote Manufacturing have chosen the Enterprise Architect Unified Edition which includes support for MBSE + SysML modeling. We also plan to contribute to open source development of a python module for SysML and use it in our own library called Modality, a Python framework for creating hardware product test suites from SysML models. Finally, we’ll use the Modality library inside our bomquote.com web portal to support client projects and help move us all toward a better project experience.
Overall, I believe it is time for industry-leading systems engineering design practices to trickle down to the rest of us. It’s time to start integrating model-based systems engineering in your design flow.
Footnotes:
[1, 2] A practical guide to SysML: the systems modeling language / Sanford Friedenthal, Alan Moore, Rick Steiner. — Third edition.
