Toyota Arene, vehicle "Operating Systems," and What it all Means
public domain
Michael DiazToyota this week announced new vehicle software platform “Arene” to handle low- and high-level software on their vehicles. It intends to put Arene “in its own vehicles by 2025” and “will open Arene to other developers” and even potentially “monetizing its vehicles OS through a licensing model.” What does this all mean? What’s it got to do with autonomy, safety, and why now?
Whereas 5 years ago cars would be totally fine to have some odd 50 embedded controllers and one weak infotainment computer, the future 5 years from now is unclear, if not trending towards the opposite. Because if you’re going to have to put in something with 8 Intel chips and 4 nVidia GPUs to run your autonomous control stack, you may want to consider using it to eliminate those 20 embedded controllers.. But OEMs also want this thing to support future apps you haven’t thought of yet because your customers want this car to improve over time like they heard Teslas do.
The onus is on the OEM (e.g. Toyota) to put together some mix of software that can pave the way for all this. So that’s what Toyota is putting together as Arene, regardless of the name’s meaning, and I hope it’s not the one about hydrocarbon because that would really light your fire. They’re not alone. GM is doing this too with its Ultifi (read the self-promotion here) which GM itself says includes something Linux-based. Volkswagen has vw.os and Daimler has MB.OS and surely every other OEM is doing it as well.
Operating Systems and Software Platforms
Many of the articles reporting on Arene are calling it an “operating system.” Operating systems are specific software that sit atop computer hardware and upon which application programs run. Operating systems provide abstraction services like memory and disk management so that it’s easier for application developers to write programs without worrying about hardware-level instructions and interfaces. Common examples are Windows, mac OS, and a huge variety of Linux distributions that exist. But these are only a subset of OSes. So-called General Purpose Operating Systems. They are contrasted with Realtime Operating Systems discussed below though there is some overlap. Software platforms are much less strictly defined and can include an operating system as well as supporting software infrastructure, libraries, geared toward supporting development of new software.
What’s in today’s cars???
To talk about what operating systems exist in cars today we should split car computers into two categories: Infotainment and embedded controllers. Rough cut, you can think of these two as “nice-to-haves” vs. “need-to-haves.” If your car’s screen / radio / CarPlay / maps / etc. went out - you’d be OK and you could still get places. If the computer controlling your car’s powertrain failed - you’d be stranded.
The first group (nice-to-haves, infotainment, radio, etc.) by now run on some OS that resembles a laptop or phone’s OS. It’s probably a custom linux-based OS that’s lightweight but it runs application programs that the manufacturer / selected third parties write for it. Things like your car’s radio app. Or even the CarPlay / AndroiAuto app that connects to your phone. Or the Navigation app. It runs the network manager for your in-vehicle hotspot. That sort of thing. These are General Purpose Operating Systems or a highly-capable real-time OS. But it’s all on an operating system that’s much more like your laptop’s than the operating system for the second category…
Real-time Operating Systems (or Embedded operating systems) are the operating systems for your embedded controllers like your powertrain controller, stability, or ABS controllers, or even HVAC controllers. These controllers are low-cost computer hardware but purpose built to have just enough memory / RAM / processing power to come in a tight Bill of Materials budget while meeting the technical requirements of the features they are providing.
These little computers primarily run one program (e.g. the Engine control software). Think an int main(..) function and in it you’re just registering all of your time-scheduled functions which, with the help of the RTOS interrupts get triggered at the correct time frequency. I’m not downplaying the complexity here. As automotive controllers have had to do more and more and work with more sophisticated powertrains and actuators the skills necessary to package so many complex algorithms in a tiny box with limited resources and on a tight budget of time and money is extremely challenging. And traditional automaker management likely still thinks “Software is free” by the way so there is no lavish treatments for those programming these things like there is for the people making big budget phone apps.
Also, embedded software has to be robust (no software crashes allowed here!) and they are time-sensitive. The Adaptive Cruise Control feature needs to adjust the brakes or propulsion frequently enough so that you don’t risk hitting the car in front of you. Its code MUST complete execution at some pre-designated rate - like every 10 ms. Real-time OSes feature time guarantees and support time-based function scheduling based on hardware interrupts driven by the hardware clock.
Time-sensitive, reliable code execution is what counts for embedded controllers, their operating systems, and the program it executes. This is much different from your laptop or even infotainment system which care much more about capacity to support multiple programs, support easier future program creation for future applications, external hard drive and device support, etc.
Note there are a handful of real-time operating systems that are highly-capable and really begin to resemble traditional general purpose OSes. BlackBerry QNX Neutrino is a seminal example. You wouldn’t install such a heavy real-time OS on a traditional engine controller because it’s still overkill - but it might be the OS for your infotainment system wherein you won’t utilize the RTOS’s real-time guarantee and instead use it more like a light-weight general purpose OS to run infotainment features and apps.
So what does Toyota’s Arene do?
Details are, as usual, limited but we can draw from the announcement’s content, from some of Toyota’s recent acquisitions, and from industry trends and hype to infer what this is about. And from that we can talk about the implications.
The announcement specifically calls out autonomous applications as well as low-level and high-level functions. The truth is that although nearly all critical (“need-to-have”) vehicle features have been traditionally done in embedded controllers with basic real-time OSes the industry is at a turning point where more-capable, higher-power, more-expensive compute devices are suddenly in play on cars. Reasons for this range from autonomy features being computationally complex, higher-power electrical systems such as EVs, and emerging business models such as robotaxis justifying higher costs, respectively. The result is a perfect storm of thrusts: OEMs want to deliver autonomous features; High-performance compute hardware is necessary so it’s coming to cars; The market is demanding experiences (like continuous improvements) that trends towards hardware and software that has to be somewhat future-proofed against additional features and apps that weren’t there when the car was shipped.
Is Arene an Operating System? It’s an entire software platform that surely includes some sort of OS (highly capable with real-time capabilities) but likely much more: Things like software libraries for internal (and maybe someday external) developers to use to do things like send messages between application programs, upload/download data through secure connections, provide data encryption and access services, cybersecurity functions, perform at-the-edge AI/ML functions with optimized libraries that Toyota will maintain, provide the walled garden for 3rd-party apps to run in.
We can look at two of Toyota’s venture arms: wholly-owned subsidiary Woven Planet and Toyota Ventures - and their investments in recent years to deduce even more. They bought Renovo - who was also working on a software platform. This wasn’t an operating system (though commonly mislabeled as such) but another platform geared towards edge computing (doing more and more of the AI process on the car) and unlocking value in vehicle data (cloud mining and curating of data collected from the fleet of vehicles). Here’s some BlackBerry material on some collaborative work using Renovo’s platform on BlackBerry’s QNX Neutrino operating system (finally using the term correctly).
“the term Operating System is being thrown around as haphazardly as AV robotaxi deployment dates and OEM target dates to ‘go all EV.’ ”
The second related investment was this year into APEX.ai which makes Apex.OS. Again, not an operating system but if anything I think this article is showing that the term Operating System is being thrown around as haphazardly as AV robotaxi deployment dates and OEM target dates to “go all EV.” Apex.OS is a forked version of ROS2 (or Robot Operating System 2 -- also not an operating system but a collection of libraries, programs, inter-application communication abstractions and ecosystem) that claims to have been rigorously improved in terms of safety, certification, and quality such that it is worthy of production deployments.
Based on the above, Toyota’s Arene platform will likely ride heavy on safety-certified libraries for implementing complex algorithms, proven DDS-based application communication protocols, and data interfaces built to support cloud ingestion of consumer vehicle fleet data so that Toyota can use the harvested data to improve their products. Both Renovo and Apex products have a history of compatibility with RTOS - a must for safety-/mission-critical applications so Arene will likely begin to pave the way towards bringing critical control software onto the high-performance compute devices of tomorrow which are necessary for advanced autonomy features as well as after-sale introduction of consumer-facing apps and safety-critical features.
There’s probably internal plans to cut costs by consolidating the 50-100 embedded controllers of a typical car under one or a few x86 or ARM supercomputers. It may do this all on one sophisticated RTOS or with multiple OSes on a hypervisor. By establishing and committing to a universal software platform and its interfaces as an OEM, this means suppliers don’t have to reinvent the wheel with you every year and that means you can more easily grow and maintain holistic vehicle functionality. Whether this will lead to easier lives for suppliers or more competitive bidding between suppliers is yet to be seen. If there’s anything we’ve learned from the roll-out of AUTOSAR a few years ago, it could be very difficult for suppliers (and OEMs) if that relationship isn’t well developed and established. Perhaps some of the struggles with AUTOSAR have led the way to OEMs rolling out their own, custom solutions.
Final thoughts
Safe to assume the above will be the case not just for Toyota Arene, but also for GM Ultifi, Daimler’s MB.OS, Volkswagen’s vw.os, and all the rest yet to be announced. There is much uncertainty in the above. Some worry that this consolidation will present safety issues because there will be so much more software infrastructure than the already-complex systems of today’s cars. And companies are still developing their current systems to meet established and evolving functional safety best practices. Based on comments I’ve heard, some wonder if the effort and money being thrown around in developing these software platforms is a poor investment given the pressure to do so comes at least as much from the unproven autonomous vehicle business cases and desperate scramble for OEMs to “keep up with the Joneses” (or Musks) as they do customer demands. Yet another unanswered question is whether traditional OEMs can hire the software talent needed to do this much less pull it off right.
All in all, the importance of getting the OEM and supplier development agreements established earlier, ensuring requirements are fully specified, sharing and perhaps collaborating on system and sub-system test scripts are provided and shared, and maintaining customer communication continuously throughout development will be more important than ever. It will be far too easy to fall victim to earlier release of less-baked, less-safe products with the tagline “which will continue to be updated.”
We’re always happy to help. Reach out to talk about this and how we can help you get ready for the onslaught of autonomy, vehicle operating systems, post-release improvements, and so much more.
How does this wave OEM-built software platforms impact you? What concerns do you have about it in your area of the auto industry? How about concerns as a consumer?