Multi-discipline teams have many different tools for managing projects at their disposal. But if a project uses two different approaches simultaneously, it can be very difficult to get in sync. By merging design processes such as Agile and the V-model, different disciplines can accomplish their work under the same management approach. But getting these disciplines to work similarly is not the same as actually getting them to work together. That requires more than just schedule management.
Electronics hardware and software teams can be particularly challenged in working together at times. Their designs require far more support and interaction than many other cross-discipline teams. Similar education backgrounds and familiarity with technologies allow these groups to often speak the same language. But differences in development timelines, design verification approaches, and failure mechanisms can make their daily challenges look very different. In some organizations, hardware and software teams often trade blame with one another over who has caused delays, misunderstandings, or design issues.
So how do we get these groups to work together more seamlessly?
Tools of the Trade
“We become what we behold. We shape our tools and then our tools shape us.”
— Marshall McLuhan
Tools are important, and when we are handed tools we’re unfamiliar with we tend to struggle. Too often, when circuit boards are passed back and forth from hardware to software, not enough time is taken to understand the tools each team is using. Hardware engineers tend to assume that it’s obvious how to setup and power a board, what loads it needs to be connected to for functional testing, or how to hand-build wire harnesses for communication busses. “Just follow the schematic” becomes meaningless advice when given to those who infrequently need to work with hardware.
Likewise, when the hardware team is finally ready to program and test their circuit boards with the latest production code, software engineers may forget how specialized their work can be. “Just pull the latest code from the repo and rebuild it” can become a multi-day struggle for those unfamiliar with software. And it can be easily forgotten just how many dependencies and libraries are needed to re-compile, forcing engineers to dig through error reports for hours at a time.
This leads to a lot of back-and-forth as those less familiar with hardware or software development try to understand how to work with what they’ve been given. And when the process needs to be duplicated as more people need samples, the number of custom deployments begins to grow exponentially.
Make vs Buy
When deciding between custom development tools (harnesses, debug GUIs, programming headers, etc), thought needs to be given to just how many custom deployments will need to be made if your design is successful. Because the more robust your design is and the easier it is to work with, the more people in your organization will want it. If you are going to hand-build or manage the deployment of each of those systems, you should consider using off-the-shelf tools that can be purchased. That way your “customers” within your own organization can be more independent in setting up and managing their own deployments along with purchasing their own tools.
For example, programming interfaces on PCBs are often customized to reduce their size. But if hundreds of PCBs will have to be flashed and debugged, hand-building the harnesses becomes a bottleneck. Using a more industry-standard connector may sacrifice board space, but it allows people to purchase their own programming setup if they need it, rather than having to wait for you to build another one.
Likewise, if a code release needs to be controlled through a custom GUI, deploying this may be more challenging than you assume. PCs without admin rights, previously installed versions of software, and missing dependencies may force you to spend more time supporting new installations of test code than doing your primary job. Web-based GUIs, scripting, and off-the-shelf debug tools may be in your best interest, even if they may be less capable or flexible.
Obvious Outputs
Whenever a system stops working, one of the easiest ways to determine what failed is to first identify what still works. For this, LEDs and other obvious visual queues are a great idea for both hardware and software. LEDs connected to the outputs of power supplies allow for quick checks of power sources without needing to program the software or take any measurements. And descriptors in your PCB silkscreen can help identity nets and their functions. For example, silkscreen arrows showing data direction can be placed directly over traces to identify TX vs RX lines in serial busses. Test points are also improved when net names can be shown in the silkscreen as opposed to just a test point reference.
Tracking the version of a design is also key in tracking development. Clear labels on a PCB indicating a release version and / or date, build codes, and connector labels provide quick reference to find supporting documentation. Similarly, a software startup “splash screen” or debug terminal output should provide a code revision and build date. That way it’s clear what has been programmed onto the hardware. LEDs or displays connected to microcontrollers can also be used to visually indicate code operation or error states without having to use a debugging tool at all.
Enabling successful deployment
Many new product design projects require cross-functional teams. By pushing your team to provide better tools for their peers along with better designs, a project can more rapidly progress through its design iterations. Examples may include:
- Developing a clear set of plastics for a product may enhance a teams ability to better visualize the final structure
- Using an off-the-shelf mobile app may allow any team member to monitor device status without having to manage physical connections
- Creating a test fixture that simulates typical loads or connections can provide a portable test bed for development.
In product development, success doesn’t just mean your design meets the requirements. Success means people want to use it. External customers are the primary drivers of that metric, but our internal customers – fellow team members – are the first test of the quality of our work. If we can enable others to use our design effectively, we allow others to be more successful. By extension, we free ourselves from having to spend less time debugging and more time designing.
At Moetion Technologies, we pride ourselves on not just designing great products, but enabling our customers with the knowledge and tools needed to really exercise their designs. After all, what good is paying for a new design if you can’t use it the way you want. If you are in need of design support for your products, please don’t hesitate to reach out. And if you have other helpful tips or tricks that you’d like to share, please post them in the comments.
Want help bringing your products to life? Moetion Technologies can provide tools and templates, onsite training or workshops, and strategic planning for every project stage.
Connect today, and we’ll help you put your ideas in Moetion.
Until next time!
Ben Moes
Founder of Moetion Technologies.