Red Hat's Partnership With GM: From Edge to Data Center and Back Again

When Matt Hicks announced Red Hat's collaboration with General Motors at last week's Red Hat Summit in Boston, he started with the observation that "software innovation is no longer constrained to the data center." That's true enough. The often repeated mantra, "all companies are software companies," is rapidly being expanded to add, "and all devices run software."

What's largely not repeated yet is the notion that software that's created to be used outside the confines of a data center will generally generate workloads inside the data center.

Hicks, who is Red Hat's EVP of products and technologies, hinted at this in his announcement of the deal with GM.

"The merger of physical machines and software is happening right now, and the ability to innovate across traditional boundaries is critical," he said.

Simply put, this means that a great amount of the data being generated by software designed for connected devices, such as robotic machines in factories, oil exploration platforms in remote locations, as well as automobiles on streets and highways, will need to be pushed to edge locations, and then on to more centralized locations such as public and private clouds.

Creating the infrastructure to move data from GM's vehicles to the Internet, and then across the Internet to where it's needed, will be Red Hat's primary task in this partnership with GM.

Related:Red Hat Brings Cloud Capabilities to the Edge

"We tend to think of Red Hat as sort of an infrastructure provider," Hicks told Data Center Knowledge, "so we're a piece of a solution almost all the time."

Collecting the data, and building the platform to run in its vehicles, will be GM's part of the bargain, because "they're going to know more about lane detection capabilities, blind spots, collision avoidance, and parallel parking than we will ever know," according to Hicks.

Automobiles as rolling servers

GM's goal is to replace the myriad assortment of CPU and microcontroller powered components that are currently spread throughout its vehicles with a single platform, called Ultifi, that GM is developing in-house. This includes the computerized safety features that have become part of the automotive landscape in the 21st century, as well as sensor driven components to keep a vehicle's powertrain working at peak performance.

The automaker says that in addition to handling a vehicle's essential functions, the platform will also come with consumer facing features such as weather and mapping apps, and potentially things like facial recognition features for recognizing when children are present, to activate door locks. It will also connect to an app store that will make available consumer-facing applications from third-party developers.

Hicks said that consolidating all of these components into a single platform will not only simplify the manufacturing, design and maintenance processes while providing additional resiliency, it will be more cost effective and reduce supply chain issues for GM as well

"For a long time, especially in automotive, everything was custom fabricated with very specialized componentry to do each function in the car," he said, "and I think worldwide we have experienced the challenges of that with the semiconductor shortage. With technologies like Arm as a really capable hardware standard that you can modify, we're seeing serverlike hardware that's able to fit in embedded devices, and Linux supports Arm very well."

He mentioned Linux because Ultifi will run on Red Hat's In-Vehicle Operating System, which is an embedded operating system for cars. Basically, it's a minified version of Linux that pares the company's Red Hat Enterprise Linux server distribution from about 4,000 packages to about 200, and is customized to meet the needs of automakers and fleet owners.

"An automotive OEM like GM can actually leverage Arm on very standardized hardware in their vehicles," Hicks said. "They actually have general purpose operating system capabilities, based on open source, to actually get more out of that infrastructure. That's the trend that we're seeing, that this hardware is moving from very proprietary and specialized, to general purpose platforms that will drive everything from electric vehicle functionalities to eventually autonomous driving."

Integrating its automotive OS with GM's custom platform will be the least of what Red Hat will contribute to this project, however. The heavy lifting is in developing the cloud infrastructure to which the vehicle will connect.

From vehicle to cloud

When we talk about the edge, we're generally talking about compute located near cell towers that can be used to communicate with what's now commonly called the "device edge" – these can include cell phones, factory robots, and in this case automobiles, that depend on the towers as their on-ramp to the Internet. For connected vehicles, GM and Red Hat will be taking advantage of 5G technology, which can delivers latencies in the 5ms-10ms range and lower.

"The edge locations that they talk to will probably be very close, the telephone pole or one hop away," Hicks said, "but the apps you write will also have to be very close to that. For the latency benefits of 5G, you can't make a callback to a public cloud. Our ability to run OpenShift workloads at the edge, very close to these use cases, is one of the reasons we have stayed so deep within 5G."

Although much, perhaps most, of the mission critical computing for connected automobiles will take place at the edge, he said, massive amounts of data will also need to be sent to centralized public or private clouds for more intensive compute.

"The best example I usually bring up is machine learning model training," he said. "You will collect and probably act on data at the edge. A car that's driving itself will have to act on data that doesn't go beyond the car, but then you will probably also stream that data back to retrain models, and then push the new models all the way back to the edge. That's massive amounts of data; that's massive amount of infrastructure to build the new models."

Pushing data from centralized locations will also be necessary, Hicks said, for keeping the software on the vehicles updated.

It takes a village to build a connected car

Even with an on-vehicle platform and operating system in place with a cloud infrastructure to support it, there are other issues. Vehicles will undoubtedly have to deal with null zones, regions where there is no wireless connectivity, which can extend for many miles in some rural areas. Also, keeping the software up-to-date and patched against security vulnerabilities is complex, both in terms of finding the optimum situations for downloading and applying patches, and dealing with with failed updates.

For the latter, Hicks said, safety concerns dictate that the software will have to be able to accurately determine on its own whether the update was successful and roll back to the previous state if necessary – and do so on-the-fly, and in a way that could never pose a danger to its passengers or other traffic.

This is also very much a community project that involves many more organizations than merely GM and Red Hat, he said. This includes working closely with semiconductor companies like NVIDIA, to make sure they're up to speed on the machine learning side, partnering with public clouds for integrations with OpenShift, and with telcos for optimizing 5G connectivity.

"Obviously, we do data centers pretty well, so if the need is to be able to work in private data centers, we're there," Hicks said.

"We don't know where this is going at this point, but we know that the applications to enable these use cases are going to touch all of these environments. You have to be able to understand the large data center component, you're going to have to be able to write 5G localized edge applications, and you're gonna have to do work in the device. We want to be a platform that makes all of that easier for developers and easier to maintain going forward."

GM plans for Ultifi to start rolling out in its vehicles in 2023.