A few weeks ago, I was honored to represent Sibros and participate in a panel discussion at “Futurescapes Detroit: Acceleration of the Software Defined Vehicle & Impact of 5G”, a one-day event hosted by TechMahindra in partnership with AWS at Ford Field in Detroit.
I joined a group of fellow industry veterans to discuss the future of software-defined vehicles and 5G networks. I had the pleasure of great minds and company including:
- Nisarg Modi, Head of WW Business Development, Connected & Autonomous Vehicles, AWS
- Chuck Gray, Vice President, Vehicle Component and System Engineering, Ford
- Alex Kocher, President, Automotive Business Segment and Managing Director, Elektrobit
- Mahbubul Alam, CEO & Co-Founder, TrustedMobi
Below is a quick recap of our discussion along with some takeaways, specifically from the software viewpoint.
Competition is Fierce and Getting Fiercer
We all know the automotive industry is undergoing unprecedented transformation, being largely driven by C.A.S.E. (Connected, Autonomous, Shared and Electrification) mega-trends and changing consumer ownership preferences.
Rising costs and declining sales (global auto sales fell more than 4% in 2019) are putting global automakers under massive pressure to innovate and create new customer-centric ecosystems, products and services.
The competitive landscape has changed dramatically: heavily funded startups have infiltrated the marketplace, focused on producing best-of-breed all Electric Vehicles and delivering new transportation-as-a-service offerings.
Automakers must not only compete on improving traditional aesthetics and performance capabilities, but also on cutting edge tech features (infotainment and driver assisted safety packages) — all while ramping up R&D investments in electrification and autonomous driving.
Software is the Silver Lining
Yet core to this all is one common theme and opportunity — OEMs must embrace the idea of the Software-Defined Vehicle and more specifically, be mindful of the following imperatives:
- OEMs and their suppliers need to accelerate innovation in creating software-driven services that result in great customer experiences
- OEMs must find ways to securely update software beyond traditional maps and apps, with minimal disruption to the customer
- Vehicle software must be hardware agnostic at the level where software can be released, managed and updated independently of each other
As a result, OEMs must shift to operating like tech companies utilizing a software-first mentality by prioritizing software and gaining control over its full lifecycle, from vehicle R&D to its last mile. Although Sibros is a product-based company at its core, advocating a software-first approach in all we do for our clients is something we are very passionate about.
Prior to Sibros, I had the privilege of being part of the early engineering team at Tesla that was responsible for its software systems. One of the driving forces behind Tesla’s loyal customer base and high satisfaction ratings was its ability to deliver superior software experiences; whether that was working around hardware issues, increasing battery capacity or activating a self parking feature, all overnight and over-the-air.
Granted, Tesla did have a leg up in the software game as compared to traditional OEMs by the very nature of being a startup. Tesla had no legacy code, it was able to begin its journey as a software centric organization, it gained a friendly customer base from the get go and had a slow ramp up in production. Even then, it took Tesla over 10 years to perfect its overall software strategy around development, testing, validation and OTA software deployment and data collection.
Today, Tesla has built close to a million vehicles (as of the date of this writing Tesla just made its 1,000,000th car) across just a handful of models. Traditional OEMs on the other hand build several million vehicles per year across several dozen models requiring many more software configurations. So how did Tesla achieve software-first excellence at scale and how can other OEMs do the same?
What’s an Automaker to Do?
First we must rethink how we approach automotive software configurations. Most of the configurations that are meaningful for software updates relate to the powertrain and chassis systems. While there are a lot of variants for body systems as well, those are more easily managed. There are between 80–150 ECUs in a vehicle, so it’s important to have the same interface between components. What happens to the component internally is not relevant to the rest of the system unless there are key limitations or behavioral changes that cannot be expressed via the interfaces. Therefore, not all the combinations need to be tested on a real vehicle — only the ones that have powertrain, chassis or safety system updates.
Secondly, OEMs should engrain true software life cycle management within their traditional vehicle development life cycle processes. Vehicle life cycles involve very large numbers of people focused on delivering a new vehicle right up to its launch. After it launches, those team members move on to the next vehicle or milestone. However, with software there is a need for continuous program management over the software life cycle that works in harmony with the life of the vehicle. The same team should be responsible for maintaining the software of the vehicle over the lifetime of the vehicle so that it can learn and gather feedback from its designs and make the appropriate changes in future vehicles or models.
When speaking about automotive software, often we think about the customer benefits and cost savings of Over-the-Air (OTA) software updates. OTA has been around for years, however for most is limited to only updates for the main Telematics Unit or infotainment apps. However Deep Updates (let’s call this the ability to deliver upgrades or fixes to literally anythingthroughout the vehicle) is a base requirement to play in today’s new Software-Defined Vehicle era. We as an industry at large are not there yet. This is evidenced by the huge spike in software related recalls which is up 30% year-over-year globally and has hit all-time highs. OEMs can consider this low hanging fruit to prevent easily controllable costs with a proper software-first mentality and strategy. OTA updates alone are estimated to save the auto industry up to $35 billion by 2022 according to IHS Markit.
Time for Radical Change…
All of this points to the need for a radical change — there needs to be a single software team inside the walls of an OEMs organization and software needs to be a first class citizen. The team managing OTA should be a dedicated team for the whole company. This is where it helps to partner with companies like Sibros as this is our main bread and butter — to provide products that help enable this both functionally and technically. Of course, there is a counter-part inside the OEM that also builds the software changes that are required to be deployed. It is recommended that they be the same team across multiple models and model years so that learnings and developments on one platform can be carried over to future generation vehicles.
When we think about the Software Defined Vehicle there are some fundamental challenges that must be universally addressed. Sibros was purpose built to manage these in a closed loop manner between vehicles, networks and the cloud as follows and in no particular order:
- Multiple Vehicle Architectures
- Software Lifecycle Management
- Software Configuration Management
- Software Inventory Management
- Validation & Testing
- Hardware and Software Dependencies
- Data collection and logging
- Team & Program Management
As OEMs also advance to higher levels of autonomous driving, another aspect of software becomes critical, that being data collection. Without proper data collection we do not know what’s happening inside the vehicle and it’s hard to know what software patches or improvements should be applied. Without proper data collection, self-driving cars will never become a legal, mainstream reality. The problem lies within the sheer volumes of data (daily petabytes) autonomous driving generates and the respective restrictions in bandwidth, storage and network constraints required to process and interpret it in near real time. At Sibros, we’ve developed algorithms to selectively log snapshots of vehicle usage data that are meaningful to debug and diagnose issues, as well as efficiently analyze data and apply correct software patches and updates.
These are just a few of the challenges and opportunities we discussed during this panel discussion. If any of these points resonated with you, I personally invite you to engage with me and the Sibros team for a fruitful discussion about it. You can contact us or learn more by visiting www.sibros.tech.