By Chin Beckmann (CEO, DSP Concepts)
What do these coupes, minivans, crossovers, SUVs, hatchbacks, and sports cars have in common?
Despite the different sizes, shapes, and features, if you strip away all the sheet-metal and accessories, you’ll find they’re all built on Volkswagen Group’s MQB platform, a system of standardized, interchangeable parts that can be efficiently combined to create a wide variety of vehicles. It’s estimated that the MQB platform has helped cut the time needed to design and build a new vehicle by up to 30%.
The key feature of this vehicle platform is that it supports a variety of motors (gasoline engines, diesels, electrics, and plug-in hybrids) and transmissions that can be swapped into the same “socket” in the system. To support this, each powertrain component was designed to be roughly the same size and to use the same mounting points. This greatly reduces the amount of one-off engineering work, system complexity, time, and overall cost of creating a new vehicle model or variant.
This concept of product-platforming isn’t unique to the automotive industry. Many electronics manufacturers also need to efficiently support a range of products and product-variants, and have also turned to scalable, reusable platform designs to maximize efficiency and product margins.
For example, a high-end soundbar might have an on-screen display (OSD), 3 HDMI ports, and advanced audio features like Dolby Atmos or stereo-to-surround upmixing – and carry a retail price that supports the relatively expensive bill of materials (BOM) needed to deliver all those features.
However, this same OEM will typically also offer a number of other soundbar variants at lower price points, each with a reduced set of features, e.g. no OSD, no HDMI support, and a reduced set of audio features.
In an ideal world, this family of soundbars would be supported by a single set of reconfigurable hardware and software – allowing the BOM cost to be efficiently optimized for each variant – by depopulating the ICs and software that are only necessary to support high-end features. Unfortunately, there are a number of real challenges to developing platforms with this kind of flexibility.
Challenge 1: Develop a Embedded Software architecture that supports multiple ICs
Unlike apps on your smartphone or laptop, the embedded software in advanced consumer and automotive infotainment systems is very likely to be distributed across a number of different processors – for example, an application processor (AP), micro-controller (uC), and specialty audio and video ICs.
These processors may be discrete ICs mounted on the printed circuit board (PCB), or they may be integrated into a single System on Chip (SOC) package. Either way, to be scalable, the software architecture needs to support well-encapsulated functional subsystems. The interfaces and protocols that connect those subsystems must also be designed to allow different implementations in different variants (e.g. a message might be passed between subsystems using a shared memory buffer on a high-end variant, while on the low-end variant, that same message may need to travel over SPI).
The sound system in a given vehicle also needs to be scalable, regardless of whether or not the chassis are similar. A premium system may use additional processing on the amplifier while a lower-end system is limited to processing on the head unit, which usually contains a Linux- or Android-based SoC. To successfully override this problem, the sound system design needs to be consistent across product variations so that Engineers can easily deploy new features and enhancements across product lines.
Challenge 2: Create portable software components
Companies invest in product platforms primarily to maximize the return on engineering resources by developing components and systems that can be reused to create multiple products. For generic software components like a state-machine for a user interface, it’s not very difficult to create portable, reusable code. The real challenge lies in components where, beyond good encapsulation, realtime performance is also a priority.
Creating high-performance software modules isn’t a hard problem to solve in and of itself; all IC vendors supply utility libraries optimized for their silicon’s particular instruction set. The real challenge is developing software components that are both well-optimized for one particular IC and are able be ported to other ICs without significant effort or loss of performance. Remember: a primary goal is to reuse, not rewrite.
Challenge 3: Develop technical proficiency with multiple software environments
With platformed embedded systems, your team will likely need to come up to speed on multiple build environments. Although Malcolm Gladwell’s “10,000 hours” probably aren’t needed to master a new software build environment, it does take real time to go through the crawl-walk-run progression. Even in today’s world of internal Wikis, stack overflow, and YouTube tutorials, there’s no substitute for experience when it comes to being able to efficiently develop and debug software in a new environment.
This may not pose much challenge to your more experienced embedded software developers, who specialize in – and get paid for – their ability to work with a variety of IDEs and build tools. However, for the rest of the team, time spent learning, using, maintaining, and debugging IC-specific tools and source code is time that they’re NOT spending using their own superpowers. Signal processing, audio, and acoustics engineers are there to deliver value-adding, differentiating audio features – and the IC-specific tools are just a ‘necessary evil’ that slow them down.
How Do You Overcome These Challenges?
Go slow to go fast
In car racing, an inexperienced driver may decide to pass in a corner by braking late and diving past their competitor. The savvy, disciplined racer that gets passed with this move is unperturbed – they continue to slow early and stay on their racing-line; because they have vision to know that on the following straightaway, they’ll almost immediately retake the lead from their now out-of-position and nearly-stopped competitor.
In the tech world, it can be tempting for high-powered engineers to dive straight into solution space before really understanding the full scope of the challenge ahead of them. When setting out to create an embedded processing platform, it’s critical to avoid this “Ready, Fire, Aim!” approach. Instead, teams should be methodical when generating, reviewing, and getting buy-in on a solid set of product-line requirements. To do this, they must understand the following:
- The range of features that will be needed at Gen-1 launch
- Which features are must-have for high/mid/low end variants
- Lifespan expectations – how many product generations should the platform support?
- Rates of change – which features/components will likely need to be updated between generations? Which are unlikely to change during the platform’s lifetime?
- Internal success criteria – define a set of qualities by which candidate architectures can be compared.
Traditional audio development methods are simply not future-proof — they lack flexibility for real-time tuning to acoustics and real-time measurements of algorithms optimization, which limits the pace of innovation that can be achieved in product design. Savvy companies strategize their adoption of new technology and processes to be future-proof while needing to be mindful of a processor’s limited 2-year shealf life, which may be getting shorter as innovation transpires and changes in feature/power requirements are made at a fast pace.
Be clear about your core competencies and value propositions
To get the most out of your current team of allstars, it’s critical they invest their time in activities that will deliver real value. To that end, it’s important to be explicit about how your product-line differentiates. Which functions of your platform contribute to those unique, differentiating values, and which are more ‘boilerplate’ technologies? For example, hardware brands often approach us here at DSP Concepts for specific help deploying embedded audio features across their smart home product line. Making smart build/buy decisions – and choosing technology partners that complement your team’s core competencies – can make or break product schedules and budgets.
Focus on the interfaces
A platform can be defined as a group of subsystems connected by interfaces. As one starts exploring possible platform architectures, it’s common to start with a functional block diagram of subsystems (e.g. HMI, power management, audio processing, etc.). Don’t stop there though, the subsystems are only half the picture. To arrive at a scalable, well encapsulated system design, it’s important to also create a high-level sketch of the interfaces:
- What type of data is consumed / produced?
- What are the status and control signals, if any, that are needed or generated?
- Are subsystem interactions event-based? Asynchronous? Synchronous? Polled?
- Can either component initiate exchanges or is there an “interface master”?
- Does the interface need to be full duplex with data flowing both directions?
Then, when it is time to dive into solution space, be sure to approach your protocols and interfaces with the same modular mindset. Ideally, to have the most flexible, scalable platform, your interfaces should be defined in a way that’s independent of the underlying hardware/transport layer implementation. (On a high-end system, perhaps a message passes from one subsystem to another via shared memory, but in a low end system, that same message might have to be passed over SPI.)
Emphasize the Value of Simplicity
In school-to-home communications, they target a 5th grade reading level in an attempt to make sure that parents of all backgrounds can be fully present in their kids’ education. There is a similar philosophy for software development — don’t write code that a freshman in college can’t understand.
Abstraction is necessary, but overly complex abstractions (e.g. templates and multiple inheritance) should be avoided unless they are absolutely necessary for the job at hand. This gives you the best shot at recompiling across targets and expands the pool of engineers that will be able to efficiently manipulate your codebase over time.
Use standardized technologies where possible
The corollary to “Ready, Aim, Fire” syndrome is the ‘Not Invented Here’ bias of many engineering teams. While home-grown solutions can be highly effective and be a perfect fit for a specific problem, they typically also carry some hidden costs.
First, the work isn’t finished when the first design is up and running – that’s just the start. To be a real reusable asset, it also needs to be well tested and documented. As developers come and go, new folks will need to get up to speed on your custom components, layers, protocols, etc. Beyond that, it’s rare for a first-generation design to be flawless – so your budgets and schedules will need to accommodate the ongoing engineering and opportunity costs of maintenance.
To avoid these problems, it’s generally advisable to choose standardized technologies and components where possible. Since the technology provider bears the burden of ongoing maintenance, you’ll be able save internal resources for initiatives that deliver truly differentiating value – not reinventing the wheel. Also, when you need to bring on developers or consultants, using standardized technologies broadens the pool of experienced candidates and allows your new team members to hit the ground running.
Final Thoughts
By reducing the amount of one-off engineering work, system complexity, time-to-market, and overall cost to create new product variants, scalable platforms allow OEMs of all types to go to market in a highly efficient way. All that value doesn’t come easily though, and it’s critical to invest in early stage planning.
When thinking through a product platform, start with the fundamentals: take the time to define the range of product capabilities and scalability requirements. Then, as your team starts sketching out possible platform architectures, be sure to give the interfaces the attention they deserve. Finally, take a fresh look at your team’s core competencies and make smart build/buy decisions by choosing standardized technologies where possible and technology partners that can support your business’ roadmap.
