Declining prices for 32-bit chips and the maturity of dual-core architectures are triggering a shift to higher-powered microcontrollers. The use of these devices is also prompting electronic engineers to speed up their transition from proprietary software to programs that run on commercial operating systems.
The 8- and 16-bit CPUs (central processing units) that once dominated vehicle systems could be handled with proprietary operating systems (OSs), but usage of these proprietary OSs is declining as 32-bit chip costs plummet. Strategy Analytics Inc. predicts that the high-end chips will account for 58% of the $7.6 billion automotive microcontroller market in 2015.
This transformation is prompting a transition from proprietary to commercial software. “The more 32-bit chips are adopted, the greater the need for an OS,” said Andy Gryc, Auto Industry Field Application Engineer at QNX Software Systems.
As these processors take over, a growing number of designs are shifting to multicore devices. They provide more performance than single-core units with lower power consumption and less heat generation. As dual-core devices gain prevalence, engineers are beginning to use them to handle many tasks that have previously used dedicated controllers, further increasing the need for a commercial OS.
“With multicore chips, companies want to collocate general-purpose technologies like navigation systems with critical applications like a backup camera displayed on the same screen,” said Gordon Jones, Vice President of Green Hills Software’s Embedded Virtualization Business Unit. Most real-time OSs (RTOSs) make it straightforward for engineers to run multiple tasks simultaneously.
OS providers QNX and Microsoft Auto are already strong players in this emerging market. Linux advocates are pulling together in a consortium that is promoting the Linux-based Genivi as an open-source infotainment solution. Intel is now a competitor after acquiring Wind River Systems, and Green Hills is also vying for market share.
Infotainment was one of the first applications that used commercial OSs, because this environment changed rapidly as more consumer devices attached to radio head units. Engineers did not have time to devise proprietary OSs, and many commercial alternatives already had links to consumer products.
Now, commercial software is moving into other segments that are undergoing dramatic change. “Instrument clusters are going to high-resolution multifunction displays, so that’s an application that’s moving to OSs,” Gryc said.
Multicore chips also let engineers mimic various microprocessors, running software written for an Intel CPU on a Freescale controller, for example. That helps speed time to market by leveraging code written for another control architecture.
“With increasing pressure to lower cost of manufacturing and increase functionality, device developers are turning to new multicore architectures and virtualization” Jones said.
Electric powertrains and battery-management systems are also areas that are shifting to commercial OSs. Engineers are creating complex new applications that don’t have legacy software that links to proprietary alternatives. Timeframes are also short as automakers jockey for dominance in what’s expected to be a solid growth area.
Body electronics are also following this trend. “In body electronics, we’re seeing more and more OSs,” said Steve Traicoff, Project Engineer for Embedded Software at Vector CANtech Inc. “That used to be a simple area, but as we get more features, there’s more need for an RTOS.”
Many factors drive the decision to move to commercial software. One is that using this software ties in to the current desire to reuse code that is proven effective in the field.
“Customers want an OS that’s not hand rolled so they can port one application to another and go from one hardware platform to another,” Traicoff said. Vector has supported OSEK (German for "Open Systems and their Interfaces for the Electronics in Motor Vehicles") operating systems for years, and is adding more support software from commercial RTOS providers.
When product developers are selecting an OS, they are usually interested in squeezing it into as little space as possible. “Size is very important for an OS,” Gryc said. “The speed of an OS is not as important as the speed of the processor.”
Though speed isn’t a key differentiator during normal operation, vehicle owners do not want to wait for software to load in at startup. “Boot time is really important for automotive devices,” said Walter Sullivan, Program Manager on the Microsoft Auto team.
As consumers bring in more software that has not been tested for automotive reliability levels, developers want to make sure that problems with one program do not impact other functions. That is typically done by partitioning applications into certain parts of memory and guaranteeing key jobs that they’ll have the necessary CPU cycles to keep functioning at all times.
“We have a microkernel architecture with drivers and other elements that run as applications," Gryc said. "The applications are modular and easily separated. Clusters are more critical than infotainment; if the speedometer locks up or gauges go wild, that’s a more serious safety issue than if you can’t access your iPod.”
“One barrier for multicore comes from the OS standpoint. You can run one OS on each core, but the OS guys are just getting to the point that they can do symmetrical multicore processing with one OS splitting cache and data flow across the various cores,” said Nathan John, System LSI Manager for NEC Electronics America’s automotive strategic business unit.
Though commercial software is seeing solid acceptance in many new applications, it is not taking over in all of these emerging segments. Safety-related products must be engineered to meet a range of safety standards, so some Tier 1s still use proprietary software.
“There are stringent demands for diagnostics and other process,” said Richard Blachford, Principal Product Engineer at TRW Automotive. "That’s why we do a lot of our own products."