This is the first in a series of blog posts from our Automotive Lead, Xander Cesari, about the challenges of developing vehicle software in the automotive industry. Subscribe to our newsletter to get updates about future posts or email xander.cesari@pictor.us to get more information about Pictorus!

Searching for the Magic in Automotive Engineering

I’ve been criss-crossing the automotive industry for almost a decade searching for the solution to the challenge of developing excellent software for controlling hardware. My quest has taken me to every corner of the industry from California to Detroit, including Stellantis to calibrate the Hemi V8 and launch the new Ram 1500, Karma and Rivian where I helped designed the on-board diagnostic systems, and developing controls for a hybrid electric side-by-side at Pratt Miller/Oshkosh. In the early years I was just searching for an engaging challenge but I realized that I didn’t just want something exciting to work on; I wanted to work in an exciting way!

Automotive hasn’t rethought or even optimized our control software development process or tools in decades. Many of my peers share the same intuition: the industry just isn’t nailing the software aspect. I’ve watched the tech industry rapidly iterate its own software process, new tools and methodologies to generate new paradigms, languages, and approaches. Meanwhile in automotive many of our most-used development tools predate the internet: Mathworks Simulink was built in the 1990s (and feels like it) while the C language at its foundation is 30 years older than that! Developing at the boundary between software and hardware is a thorny problem and not many tools can support even the most basic safety critical embedded workflow. But to do it well we have to rethink not just what we engineer but the very process of engineering the hardware-software interface.

I can’t fault my prior employers: when a company makes products it’s not always a good investment to reinvent processes. Their incentive is to build the highest quality, most innovative, or best value products with the tools available to them. It will take a company dedicated to the challenge of writing software for hardware to solve this fundamental problem. A company of frustrated controls and embedded experts building not just add-ons or integrations but a whole new platform with a new language. That company is Pictorus and it’s been the culmination of my career to join the team and try to solve this problem that vexed me for so long.

If It Works… Fix It?

The existing toolchain for embedded and controls development in the automotive industry is primarily based around Model Based Design. MBD controls are found in every car on the road today and allows complicated physics-based control systems to be designed and refined visually in simulation before being compiled into embedded code. The predominant software that provides this workflow to automotive is Mathworks Simulink. After wrestling with a painfully clunky UI it compiles to memory unsafe C code that runs on deeply embedded and difficult to debug processors. Verification and validation is difficult but possible with expensive industrial hardware-in-loop testers. Developer efficiency is low but we’re churning out code. So why change?

Because we’re taking way too much time, spending way too much money, and all to generate software that’s barely good enough for our current concept of what a car should be. But tomorrow is coming fast and the market, regulators, and the financial constraints will render our current best practices woefully inadequate. Our process needs to allow us to develop software efficiently (even agilely?) alongside the hardware design process, develop and update features more quickly and with more integration, and do it with safety and security.

Cars That are Necessary but Not Sufficient

What is necessary to build a modern car is a highly difficult engineering process. Designing efficient and complicated drivetrains, controlling their dynamic electronics, and manufacturing the metals, glasses, rubbers. It’s a commodity business with tight margins and regulatory hurdles that requires a complicated intercontinental supply chain. These are challenging manufacturing and design processes that have taken decades to invent, optimize, and master.

But what is necessary is no longer sufficient for making a modern car. The quantity of code in a modern vehicle has increased until they’re now one of the most software-driven pieces of technology with which we interact. This will require three significant shifts in the digital automobile; the processes we used to codevelop hardware and software, the ecosystem and quantity of connected features on the car, and the security and safety of the whole system.

Breaking the Hardware Development Speed Limit with Software

The way we develop automotive software has to change. More specifically, the time constant of automotive software development has to change. The typical car product lifecycle is 5-8 years, with a mid-cycle refresh halfway through. But if your iPhone 16 had the same UI as an iPhone 11 you wouldn't be a loyal customer for long. The product lifecycle of vehicle software has to evolve at an entirely different time constant than the hardware. The customer expects new features and services, updated aesthetics, and security to be competitive each model year, long after the heavy manufacturing of the hardware has been locked down.

This is also true for the development process. Tooling up sheet metal stamping dies can take months, factory line changeovers are planned years in the making. Developing a competitive powertrain with all the simulation, testing, casting, and calibration starts years in advance. The much-maligned "waterfall" process is a necessity when the hardware timeline is driven by these long lead time constraints. Meanwhile the software industry has delivered innovation after innovation on the tidal wave of agile process - fast development cycles, fast feedback from the customer. And unlike the deployed hardware of the automobile the software development cycle never slows down; continuous updates and feature additions are just as important post-launch as pre-launch. Even more critical will be software updates to address any security vulnerabilities, just like safety-related hardware recalls.

The software and hardware processes have to run at different rates of execution, entirely different time constraints. Translating between these two speeds is an unsolved problem for the industry. Allowing each side of the process to run optimally without constraining either will require new developer tools. Doubling down on either the pure-software agility of the tech sector or the confident yet plodding hardware development of the automotive industry will fail; the best of both worlds and new ideas to unite them are required. But while a new approach would save money and time there’s a yet greater appeal; it could result in a radically better product.

Cars That Transport… and Delight

The tech industry and cloud infrastructure has raised the standards of what an interconnected, software-driven product should be.  With the advent of internet enabled smartphones, connected homes, and a cloud of services and data our physical lives are mirrored by an often delightful network of convenience, intelligence, and integration. We can move from our homes, to the office, to our third spaces and good technology should follow us unobtrusively, making available communication with loved ones, the music and content that nourishes us, and security and convenience to live a worry-free life.

Yet all too often that flow stops when we get into our cars. Apple CarPlay or Android Auto is an island of familiar UI surrounded by an infotainment system that might look different, feel different, and not connect hardware features. Is that enough when the car isn’t just a smartphone on wheels but more like a home away from home? A few of the more innovative OEMs have begun to add features with deeper hardware integration like repurposing driving assistant cameras as a security system but every automaker is vying to outcompete in the user-facing features about which customers are increasingly enthusiastic.

However, when you start with a traditional automotive architecture, it can be extremely difficult to expose every piece of hardware in the car to the customer-facing infotainment and connected services. Supplier-sourced modules may not have the level of connectivity required, vehicle topologies are inflexible and low-speed, and the software tools used to program edge modules doesn’t have easy integration with modern software architecture or communications. Even as OEMs are increasingly motivated to drive connectivity to the edge of the vehicle hardware they find they're limited by antiquated software development tools, vehicle platforms, and the agility of their entire development process. They will also find that they’re limited by the requirement to deliver that edge connectivity with safety and security.

Safety and Security Are Forethoughts not Afterthoughts

As the networked features of automobiles expand throughout their systems, so too does the attack surface exposed to hackers. The scrutiny on vehicle cybersecurity is a growing concern from multiple sources: regulatory agencies, national security authorities, and consumer advocacy groups alike. Porsche has already announced premature end-of-life plans for platforms that can’t be made to meet the EU’s upcoming vehicle cybersecurity regulations.

The tension between deep connectivity and cybersecurity has been present in technology since the invention of the internet. But attaching the internet to multi-ton cannonballs that move through our worlds with enough energy to cause real damage raises the stakes immensely. Data breaches are concerning enough; gaining malicious control over a vehicle’s powertrain could be tragic.

Threading the needle between safety/security and connectivity will be one of the defining challenges in the development of future automotive software platforms. Both features and cybersecurity will need to be design constraints from the base electrical architecture design; bus protocols and topologies, gatewaying, and controlled access designed from the ground up for the job. But even deeper than that, the processes, tools, and even programming languages we choose have to support the unyielding constraint of safety and security.

These Are Solvable Problems

Each of these broad areas of challenge is intimidating but not insurmountable. Software innovations from other industries provide inspirations and examples. The unique gauntlets of low-level hardware control and safety critical environments will require both experience and creativity to traverse but they’re not impassable. The ideas, technologies, and desire for new paradigms have created an opportunity for new automotive software development tools to change our industry’s relationship with hardware control.

For many engineers, tools are the waters in which we swim. It's said that fish don't know what the ocean is because why would they? For engineers focused on developing products, tools and processes are the invisible and linear road they travel. If you want a better product simply get better at the tool. Practice it, learn it, hone your skills with it. In the heat of a product development process it's difficult to zoom out and ask if these are even the right tools and the right processes.

This is the situation in which the automotive industry finds itself; lofty goals of software revolution but with tools and processes that are an evolution at best and often plain regressive. It’s time to stop redoubling our efforts at outdated methodologies and tools. It’s time to rebuild our engineering tools so we can rebuild our products. Pictorus is a next-generation controls development platform for the next generation of automobiles. My search is over, my frustration has waned, and I’m finally excited for the future of software and controls development within the automotive industry.