And putting it in a shared folder is just about as bad. You would be surprised by how often crucial code elements (which are painstakingly guarded secrets during development) are handed off to contract manufacturers (CM) without basic security hygiene.
Having spent a lot of time on both sides of this table, I can understand why. The needs and the underlying toolchains of the developer and manufacturing worlds are very different.
Developers are used to high frequency iterations to fine tune their software. Tools like GitHub and agile practices like Continuous Integration/Continuous Deployment (CI/CD) encourage a working atmosphere with many pieces of code rolling up into a release package that changes on a weekly or even daily basis.
CMs want to lock down a design so they can optimize the efficiency of production: improving yield, speeding up the line, and saving money. It is not very easy to get things to a tightly-managed production line. CMs are also worried about security and don’t relish the idea of a developer in another part of the world having the power to push an update to their line.
So there is an impasse; a vexing incompatibility between these two groups. Fundamentally, they are geared differently, like putting a micro screwdriver head into a 13A hammer drill.
One way of overcoming this is to send the developers to the production line where they can build trust with the CM and work it out on the fly how to hand off the code, sometimes using a USB thumbdrive. This can have a large toll on the team’s efficiency and might not even be possible during times of crisis.
Another way is to build a deployment mechanism in-house. This is the approach that has worked in the past for a number of San Francisco hardware firms like Fitbit, JUUL, and Square. The cost of doing this is very high though and still often requires travel of the team building it to the factory (overseas) in order to get it all working smoothly. In speaking with engineers close to these efforts we often hear that it is a distraction from engineering the product itself and hard to maintain once it is built because it is not a revenue source. Nor is it something very many people ever actually see and touch. It’s an afterthought.
At BCD, we saw the potential to make it an area of prime focus and built the Production Line Tool (PLT) and PLTcloud to capitalize on it. We saw a way to create a standard piece of hardware that can go to both the development teams and the factory line and access a secure cloud to deploy firmware updates to the line directly and also get a live feed from the line as units are being flashed in production. By putting our brand on, we are putting our foot down and letting our clients know that we will document and support these tools. It’s our job. With the PLT, you can securely log into PLTcloud, upload your firmware (or connect to Github Actions), deploy to the group of their choice, and Boom! it is available to the PLTs on the production line for flashing the devices being built. Each time a unit is flashed, a report is created and accessible from PLTcloud, or within Slack if you prefer. If you are interested to learn more about the PLT, you may visit our product page: getPLT.com