Toyota and Apex.AI have partnered to develop a production-ready platform for autonomous vehicle development. Engineers will be able to use Apex.OS, its software development kit (SDK) and application programming interface (API) to create safety-critical software for automotive systems.
Traditionally, creating vehicle software is tricky because it involves the integration of numerous third-party systems—each with its own proprietary hardware and software.
“If you look at vehicles today, there is really a zoo of different hardware and software components that an OEM sources from different suppliers,” said Jan Becker, Co-Founder and CEO of Apex.AI. “That poses a challenge when these systems should talk to each other or when you want to update all of the software over the air.”
Apex.OS provides an SDK that abstracts all the common functions engineers need to produce the software logic that controls the various systems on a vehicle. It gets brakes from Company XYZ, and sensors from company ABC talking to the logic created by the OEM. This common use of API and interfaces across the whole vehicle simplifies development by standardizing how third-party hardware and software communicate.
Becker noted, “All that automakers, and Toyota specifically, are striving for is a uniform software architecture and uniform APIs across the vehicle. If you compare that to a cellphone, both Apple and Android provide an SDK for app developers. That SDK provides common simple interfaces to all app developers. So, if an app has a keyboard, there is an already-made function for a keyboard. If you want to read in data from the internet, access the speaker, or display something on screen, there are already-made functions.”
Jan Becker, Co-Founder and CEO of Apex.AI, and his team introduce Apex.OS.
Engineering.com sat down with Becker to discuss how this common communication system for the automotive industry works.
Why Does the Automotive Industry Need Universal SDKs?
“If you go back 10 to 20 years,” said Becker, “you had dozens to a couple of hundred mostly disconnected small computers called ECUs (engine control units) spread out across the vehicle. Then the ECUs became connected, in the second generation, through a CAN bus (control area network bus). What we now have is many of these connected computers. That creates a very complex system. The tiny computers spread around the vehicle are being integrated into fewer, larger high-performance computers as powerful as today’s desktops with a GPU.”
This creates a scaling issue. Engineers will need to create complicated functions to control the advanced driver assistance systems (ADAS), autonomous systems—even the infotainment systems on the car. As a result, working with distributed systems won’t work.
Think of it this way: Engineers need a common connective tissue that makes sensors from Company ABC talk to an image classifier made by AI Company QRS. Now the classifier needs to tell the car’s internal logic, made by the OEM, that there is a stop sign ahead. Finally, the car’s logic needs to talk to the braking system, made by Company XYZ, and tell it to engage.
To get these distributed systems to communicate, engineers need a common language. This is where Apex.OS comes in.
“These computers need to run complex software to implement the complex functionality,” said Becker. “That software needs to be safe, run in real-time and needs to be reliable. Automakers haven’t figured that out yet and that’s exactly what Apex.AI is providing. Automakers are aware how to write simple software in a safe and reliable way—but not how to write complex software in a safe and reliable way.”
To protect against system crashes and operational failures, Apex.OS has achieved TÜV NORD certified functional safety according to the highest level of ISO 26262.
Becker noted, “A braking system you would buy today would also be certified to [this level], the difference is we have applied that for very complex software systems, and no one has done that before.”
System Safety for Vehicle Software and Hardware: Memory Overflow
“For complex software you have multiple parallel processes, reading in data from multiple sensors spread out around the vehicles, maybe eight cameras and four-to-six LIDAR and RADAR. There is a lot going on in parallel,” said Becker. “So, system safety procedures are needed to ensure that everything runs smoothly.”
“[Automotive SDKs] are ready-made functions that allow you to read in and process the data,” added Becker. “You can have parallel tasks and processes that can communicate in a safe way, so they don’t negatively interact with each other. The most important processes can be locked in so they will work in real time.”
Becker goes back to the phone example to explain how programming for consumer products and safety critical products differs. As you open and close apps, space is made in the phone’s memory dynamically. This is done because the phone has a finite amount of memory and you never know how much of that memory is needed by any app at any time. Things will open and respond faster if they are in memory. However, they will respond slowly if they need to be recalled to memory.
Obviously, this setup won’t do in an automotive scenario. You want your emergency brakes to respond instantly, not wait to be recalled by memory. The Apex.OS automotive SDK gets around this by predefining, at start-up, how systems have access to points in memory. This setup also avoids issues such as memory overflow.
“Allocating and deallocating memory takes time,” said Becker. “If you do it on the fly, the system doesn’t run in real-time anymore. And, you don’t know if the memory you are allocating is in one chunk. If it’s not, you start to have memory fragmentation which poses other issues. From a functional safety perspective, if you allocate memory dynamically, you can’t guarantee that you will never run out of memory—which is an issue if something like an emergency system needs to brake and you don’t have that memory.”
System Safety for Vehicle Software and Hardware: Zero Copy Memory Access
How programs access data will also differ in vehicle software. Traditionally, to ensure processes work independently without affecting each other, programs will share data and save it in separate locations. This way, Software A can’t affect the data Software B is working with. But transferring and saving data is time consuming, especially when you’re working on the level of megabytes per millisecond.
“Every time you copy data it takes time, and the larger the data the more time it takes. If you share complete videos of LIDAR images, that takes a lot of time. So, we supply SDKs with no-copy communication in a safe and secure way,” Becker said.
The way that Apex.AI initiates communication is through a lock-out method. This way, multiple programs can still work on the same data, without copying it, and without interfering with each other’s processes. “Obviously, you don’t want one program to overwrite what the other is already in the process of reading,” explained Becker. “You make sure that the read-write instances are locked against each other.”
In other words, when Software A is reading and writing to the memory in data, Software B is locked out from accessing it. Once Software A finishes its processes, it unlocks the data. Now the next program in the queue, Software B, locks that memory portion as it reads and writes to it. As a result, no other program can access the memory until Software B is finished.
How Automotive System Safety and System Security Differ
System safety covers how engineers avoid and deal with safety hazards with respect to implementation. In contrast, system security deals with how engineers avoid and deal with the consequences of external influences that are imposed upon the system.
Both are related. In fact, Becker noted that memory overflow (mentioned in a previous system safety section) is a common point of cyberattack. Here, a part of memory that should be bound isn’t. If you exceed the memory you can land in a memory segment that is reserved for another program.
“The solution to that, in a real-time system, is that the critical function is allocated at start up and only reused during the runtime. This avoids memory overflow as the hacker can’t exceed memory, as it’s bound,” Becker explained.
However, system security can’t be performed by Apex.AI alone because it is a system level problem. As a result, they work with their customers to ensure that everything is securely accessed across the system.
“One vulnerability is enough to make the whole system unsafe,” Becker clarified. “The system-wide security approach would be to look, with the customers, what are the entry ways into a system from the outside—like a modem to the internet and infotainment electronics running Wi-Fi or Bluetooth. We haven’t programmed those, so we consider them unsafe. So, we build layers of security, like an onion.”
With this onion-like setup, hackers can’t go from the infotainment system to the braking system because they are isolated from each other.
Another way to ensure vehicle security is to continuously update these systems as they are in the field. Most vehicles do not have this ability, but Becker explained that Tesla is many years ahead on this. The reason is because early on Tesla owned the majority of its software components. Apex.AI provides this feature to its customers, a common interface that can be reused for different components, car models, and functions, so engineers can control and update the code as needed.
To learn more about autonomous vehicles, read: Innoviz Introduces Automotive Perception Platform for Autonomous Vehicles.