Salesmen and Marketeers are fond of the Sales Funnel. Basically, it represents a sales process wherein a prospect starts at the top of the funnel with many options to chose from. Under the skillful guidance of the salesman, who is deploying the marvelous materials of the marketeer, the prospect eliminates options as he moves down the funnel. Finally, when he emerges from the end of the funnel, only one option is left standing – the salesman’s product!
We engineers have a similar funnel that we might call the Engineering Funnel. Our funnel contains things like code, devices, and ideas, rather than people. I liken the top of this funnel to wandering through a dense forest in a thick fog – so thick that I keep ping-ponging from tree to tree because I can’t see them coming. As we move down the funnel, options decrease and so does the fog. Finally the fog clears completely and we emerge from the end of the funnel into a beautiful clearing where the golden solution rests on a pedestal in the center. Life is good again!
Focusing now on programming, which is about 80% of new IoT and embedded device development, an ugly truth is that some programmers have longer funnels than others. This is where partitioning (Ref. 1) can help. A good manager knows his people and will put his best programmers on the most critical partitions. In fact, some of the most important partitions may be proven code from current products and require little or no work. When the Day of Reckoning (aka System Integration) comes, not all partitions are equal – some programmers are still in the fog.
If trying to assemble a monolithic body of code, this can be disastrous – the weakest links will cause the most trouble. The advantage of partitioning is that a product release can be made when the important partitions are working well and the less important partitions are are having difficulties. When a hiccup occurs an MMF is likely to stop the partition, report the problem, and reboot the partition. This is not unlike a hack, and in fact could be a good test of the security recovery code!
Startup of manufacturing is not a step function nor is sales. They both ramp up. The purpose of a product release is to allow the ramps to start with something that does its primary functions ok. Non-essential functions need not be working properly. For example, if the control panel suddenly lights up like a Christmas tree (as one of my projects did after delivery in the middle of the Gulf of Mexico) then goes back to normal (after the partition is rebooted), this can be tolerated for a while by manufacturing, sales, and even customers – they all have their own ramp-up problems. Thus, there are a few months to fix the weak partitions without cutting into the Market Window (another fond concept) and costing the company market position and revenue.
I think the basic concept to take home is: Don’t aim too high — partition the code and focus on delivering the most important partitions working well first. There is a certain built-in tolerance and elasticity in the process of bringing a new product to market. But the other actors do need something real to work with.
Reference
Ralph Moore, Achieving Device Security, Micro Digital, January 2022.
Copyright © 2022 Micro Digital, Inc. All rights reserved.
Micro Digital Blog 