Multiple-vendor projects are not trivial to take from start to finish; they can easily get derailed or stuck. More communication between the teams can speed up the product release, but might also slow it down. In this article, we will tell you about a real-life project where we had to collaborate with another developer’s team to develop a parking assistance solution. In the end, we provide best practices on how to create a productive environment for multi-vendor collaboration.
The hero of this story was a 360-degree camera parking assistance system. Its mission was to help car drivers avoid blind spots and to secure the parking process. To accomplish its mission, the system should have been able to produce high-quality spherical video and operate offline. Technically, it was a merging of four camera feeds in real time to create a seamless video.
The entire idea of this solution belonged to a startup that already had some experience with IoT projects and typically worked with a single vendor from Asia. But for this project, they invited Softeq to assist with firmware development, while the hardware and its architecture remained on the other vendor from Asia. By doing this, the startup wanted to get an international team with more manageable documentation. (When all the documentation is written with a logographic writing system, it's difficult to support the product internally and almost impossible to change the vendor.)
The project kicked off with a common meeting among all the participants: the client, the hardware team (Asia), and the firmware team (Softeq). We agreed on and documented the basic set of features, as well as divided responsibilities for all project stages. The hardware team was responsible for the hardware architecture and component cost optimization. In tandem with them, the Softeq team was to develop the accompanying firmware.
We jointly decided to use the i.MX processor family as a basis for the solution. The hardware team was to choose the processor series that would underpin the product functionality. The development kit they provided was based on the i.MX 6 processor. After that, we began to develop the firmware using the chosen processor.
The good thing about the i.MX processor family is that the manufacturer provides full documentation and usage examples. We can easily find the needed information, which speeds up the development process.
Softeq developers’ team lead
As the project began, there were changes in the customer team, and the product owner left. The coordinator responsibilities, like creating the roadmap and controlling its implementation, were divided among several people.
In such situations, chances are high that teams may distance themselves from the agreed product vision. But there was no time to wait, so we moved on.
Softeq project manager
In the perfect world, when two vendors work remotely, they’re expected to work in sync and collaborate on all critical aspects of the future solution—and that means a lot of communication. Clear communication ensures there will be seamless integration of the various parts along with steady product development. In our situation, we had multiple product owners on the customer side and several vendors as well. This meant that we’d need even more communication than usual to be sure our priorities were correctly defined.
To get down to firmware development, we needed detailed information about camera interfaces, resolution, fps rate, video data storage before merging, etc. from the remote hardware team.
Our hands-on experience proved that developing firmware without understanding hardware may lead to inconsistencies between these two foundational parts, and the bring-up would fail.
Softeq development team lead
The hardware team in turn wanted to have firmware available so that they could start designing hardware, so they should start selecting minimum satisfying components and design the product hardware part. As a result, they would deliver their part with minimum expenses from their side.
Apparently, the teams had different understandings of what an efficient solution design process should look like. Depending on which deliverable would be produced first—firmware or hardware—the solution will be either efficient or low-budget. The client decided to take the efficiency path, so costs increased slightly. The hardware team provided us with all the necessary documentation, and we started developing firmware.
In the process of firmware development, we figured out that merging four video streams required a more powerful processor than the one initially agreed on—the i.MX 6. The next-generation i.MX processor would have been a much better option, but it was twice as expensive as the previous one. Understandably, the client had some doubts and asked for possible alternatives.
The Softeq team came up with an alternative implementation option that would not require replacing the processor with a more powerful one. This approach would require moving the video merging process to the cloud. In this case, the solution would only be able to operate online: The user, for example, might not be able to use the system somewhere in the forest. However, this would be a significant change in the original product concept, and the option was therefore rejected.
The only way out of the situation seemed to be to find a completely new processor, which would reduce the hardware cost.
Softeq project manager
The hardware team managed to find a less expensive processor equivalent to the i.MX 8. This processor was developed and produced by a Chinese company and all documentation was available in Chinese only. So the client faced the situation they had wanted to avoid by hiring Softeq. Ultimately, however, when we tried porting the already-developed firmware part, it became clear that the new processor didn’t meet the necessary technical requirements.
A promised feature of the equivalent processor was the built-in stitching of multiple video streams requiring no additional programming. But it didn’t function correctly in our case, and we had to implement a custom stitching algorithm. From our experience, such algorithms are very power-intensive and require a graphics accelerator. The i.MX family processors feature a graphics accelerator, but their equivalent doesn’t. So this low-cost option didn’t work for us.
Softeq development team lead
In the end, we all agreed to continue development based on the more powerful i.MX 8 processor. In the end, the final hardware cost exceeded the target cost by at least 40%, and product release was delayed due to poorly coordinated communication between all stakeholders.
The good news was that the developed part of logic could be easily ported to the i.MX 8 processor.
Softeq project manager
Multiple-vendor collaboration isn’t an easy undertaking, but it is manageable. The following guidelines can help you keep your project on track:
If you’d like help with verifying costs from an external hardware manufacturing vendor or building a firmware and hardware solution from scratch, send us your request at ask@softeq.com.