Through-Stack Development (Part 3)
Let’s talk a bit about complexity.
Almost any given automotive ECU (Electronic Control Unit) is a complex beast by itself, with its number of requirements ranging somewhere between a couple of hundred for a simpler ECU to thousands for a full-featured Infotainment System. Now, at Link Motion we tend to think of ourselves as being in the “box reduction business” – essentially combining the features from multiple ECUs to a single box. This of course means our product needs to not only meet all the requirements needed from each of those ECUs separately, but also any arising from possible interactions of having them all under one roof.
Adding to the map of the problematique, we have the fact that no two vehicle architectures are the same. So, not only do we have a product that’s quite complicated by itself, it needs to be different for each client. And anybody who’s worked with such complex systems can easily tell you that small changes can often have far-reaching consequences, not unlike the proverbial butterfly of storms.
“Now, at Link Motion we tend to think of ourselves as being in the “box reduction business” – essentially combining the features from multiple ECUs to a single box.”
It’s no wonder then, that one of our slogans has been “Rage Against Complex”, since one of our ambitions is to handle that complexity on our side, so that our clients don’t have to.
One of the ways Link Motion is quite different from more traditional Tier-1 suppliers in its product area, is that we don’t start designing a whole new system from scratch when a new client comes knocking. Instead, we continuously work on our baseline / reference product by pre-empting client feature needs and creating an expandable, yet modular, system architecture to cover them. Thus, when a new client comes calling, the most important question for us is “What does the client want, that’s not yet a part of our baseline?”.
One way of thinking about this, is that our baseline product is somewhat related to a “platform” product, which tends to be a bit of a combination of both, a sought-after Holy Grail and a curse-word in product development. From one perspective, it’s the perfect way to ensure that all our work is re-usable, also benefiting everything else we do in the future. From the other, if a product tries to do EVERYTHING, it easily gets bloated, unfocused and un-optimized.
The reason we call it a Baseline Product, and not a platform, is exactly because it does NOT try to do everything. We’ve mapped out a range of features it can cover, designed how those can be reached, and meanwhile have concentrated most of our work on implementing and optimizing the core functionalities. As a client projects start, we come back to the question I noted above and start defining what part of the new features we want to expand into our baseline, and what part becomes part of a client product variant. Depending on the answers, variants can come in many flavors – HW variant, SW variant, User Interface (UI) variant etc.
“ We’ve mapped out a range of features it can cover, designed how those can be reached, and meanwhile have concentrated most of our work on implementing and optimizing the core functionalities.”
The real key to how we manage all the complexity, can be found in how we’ve brought ALL of our Safety Items (Hazard and Risk Analysis, Safety Goals etc.), each type of Requirement (from Stakeholder to Implementation level), Designs (System, SW and HW Architecture) and even Verifications / Tests linked together into one single source of truth. This is achieved by our ongoing partnership with Jama Software.
The result of all this work is that when a client comes asking for a specific feature, we can easily do a full impact analysis to see what parts of the system will be affected if these two Requirements need to be changed or introduced. This allows us to provide feature-specific pricing, transparency to the cost structure and ultimately negotiate a deal that’s optimal in both features and price for both parties.