Why reuse code for your Linux embedded projects ?
Embedded market pace has been notably affected by end-user expectations and high level market competition. In that context all tech makers want to launch better products on the market, at a faster pace and at a lower cost. The one who can offer that will please customers, CTOs, CFOs and CEOs all at the same time! Dream scenario? Well, maybe not.
You actually have many ways of succeeding here (not exhaustive):
- implementing lean startup methodologies,
- looking for new innovation frameworks,
- use intensively UX design to reduce functional scope while focusing on key features,
- reduce product line for better focus,
- use off-the-shelf products or software bricks
- and reuse your own code which means create your own embedded software platform.
Our focus today is on the last two options.
As the R&D manager or director of innovation, you probably have several products that you develop and maintain.
What if you could reuse 60 to 90% of your code from one product to another?
This would mean saving a lot of R&D effort!
Let’s say you have 5 products you want to develop. And each product in stand alone would cost 1 M€ in software development. Let’s say you found a trick that allows you to re-use 75% on average. That would mean you will spend 1 + 0.25*4 = 2 M€ instead of 5*1 = 5 M€. That means up to 250% saving on your R&D effort!
That is the principle of embedded software code reuse and what I call embedded software platforming. Well, it’s not exactly as profitable as that. Your first product’s embedded software development will cost you more. Building a software platform is more expensive than just doing stand-alone products. You need to include features for your whole product line. But still, it looks like there is a huge potential return on investment here!
Now, let’s see what is behind a “living product” (smart and/or connected) and see what can be platformed, what we can reuse:
- Mechanical
- Embedded
- Hardware
- Firmware and OS
- Embedded Business application
- Embedded UI and Remote UI
- Connectivity
- IT platform and it’s business applications
Mechanical platforming is being intensively used by car manufacturers with success for years: Ford Motor Co. builds the Ford Explorer, Mercury Mountaineer, and Lincoln Aviator on the same platform, covering the mass-market, near-luxury, and luxury SUV segments. The Chrysler PT Cruiser is built on the Neon platform and the Toyota Matrix is built on the Corolla platform. Logic is simple. It is an art of creating several visibly different models from a common platform. It is like creating various pots from the same clay. We can easily imagine the same approach with “living product” even if the form factor can vary more (a car always has 4 wheels!).
On the other hand, in IT, anyone who has been working in the embedded field has seen the “leading IoT platform”, “plug and play”, “tailored to your use”, “time and cost saving”, right ? These off-the-shelf IT platforms are indeed very powerful, and they just make you pay a reasonable amount of money per month or year instead of millions of investments on your own to get the same level of quality, features and security. As IT applications remain pretty much the same for all embedded markets (data management, dashboard, digital twins, AI, device management), these platforms have clearly a good chance to succeed on the market, even if the world is too small for that many “leaders”.
What I would like to focus on now is the embedded device scope.
What makes code reuse in embedded software a tricky but exciting problem is the variety. Everything is custom! “It depends” is the answer I have heard the most in the embedded software industry. Indeed, what commonality is there between a coffee machine, an ultrasound scanner and a mobile-POS?
In that context, can off-the-shelf software platforms cover the main features of your product so that you can focus as much as possible on the business applications? The answer is: “not really”.
Market is creative on all dimensions: use cases, features, form factors, HW technologies, protocols, inter-operability, lifetime.
The embedded software field is covering so many markets and “settings” that it’s hard to see leaders as in IT. There are some technologies that can be seen as technology platforms, as Qt, FreeRTOS, MicroEJ, Sigfox, Lora, Linux Yocto, but no one owns the full software stack.
However, we see that code reuse generally wins in the long term, as they provide unequaled cost and time savings on product innovation. Who would restart development from scratch for each new car model?
This is where an interesting scenario emerges.
Code reuse, taking the best of customization and economy of scale
Embedded software code reuse or platform approach is the best fit whenever you have a roadmap for the next several years, with a product line close to each other in terms of usage, ie: being in the same “setting”. A setting can be: home appliance, medical devices for hospitals, public vending machines, a production line, analyzer, etc. Usually a company has at least one setting including several products, and giant OEMs have many settings with many products in them.
One embedded software code reuse platform for your product range has high potential R.O.I.
Maximize code reuse from one product to another brings:
- Economy of scale on embedded software development
- Shortened new product time to market, thanks to software and hardware developments limited to specific product customization
- Mutualized features improvement on all product line
- No lock-in to one tech provider thanks to a software common code managing a high level of abstraction and compatibility (HW, connectivity, UI, etc.)
- R&D effort becomes a long-term asset, CAPEX versus OPEX.
- Complete ownership of the IP and no “black-box” effect.
- Common code testing framework that allows time savings and constant robustness improvement on the core embedded software platform (any fix benefits to the whole product line)
Challenges of an embedded software code reuse approach
Embedded software code reuse can create inertia
Technically, one of the key downsides of this platforming is the inertia that it creates. It is indeed harder to make an embedded software code platform evolve since it has a lot of dependencies with existing products. Therefore, you will need a powerful software factory to manage that “core” software/hardware and its variations.
Platform everything that is not visible
On the market side, if you push too far the platforming approach, your products may look too similar to each other, weakening your product line appearance and effect to some of your target customers. As for cars, the question is how to create different levels in your product offer with the same basis? To address that stake, you will need to focus your code reuse on non-visible parts of your product (back end, low level, middleware, connectivity, security, OTA, etc.) while keeping a good level of customization on UI and UX.
Choose technologies that have a future
Plus, as a wise and visionary R&D leader, you need to select carefully the technologies you will use, as they will be the backbone of all your products for years. That technology choice phase must take into account: maintainability, penetration in the developer community, pro-active support, roadmap for new features!
High complexity requires experts oversight
Finally, you should work on your embedded software platform with several and experienced architects and product managers, as it required a wide set of technical/business experiences. It is the highest level of complexity to design and develop such a key asset for your company. Having senior architects supporting closely during the complete development cycle is key to ensure the maximum consistency between high level architecture and real software code being developed!