In order to stay relevant in the exciting new era of mobility, Automotive Engineering Services vendors need to rethink their value proposition, integration stories, and processes in order to become more agile and capable of “meeting in the middle” automotive OEMs new and old who are obsessed with the ability to innovate at a rapid pace and are reluctant to be locked into legacy solutions and service models.
Let’s face it, our world is changing faster than ever. This present-day agility was largely enabled by advances in computer and communication technologies: computers have helped our R&D organizations iterate faster, the Internet has enabled us to share knowledge globally, and modern wireless has ushered an era of unprecedented mobility.
Coming from a traditional Silicon Valley background, I have been struck by the challenges that traditional industries face when they are required to measure up to the fast innovation and commercialization cycles that are typical in software. My first experience of this kind was as a CTO in a smart-kitchen technology startup. In that role, I was impressed by the ability of our much larger and well-established appliance partners to align impossibly mismatched timelines between the world of “bits” (software) and that of “atoms” (kitchen appliances with life cycles measured in decades). I was also humbled by the challenges that an upstart in the space must overcome: from supply chains that are reluctant or unable to change, to last-century regulations that make the job of meeting the expectations of technology-wielding customers very expensive and all but impossible.
When I chose to transition into self-driving cars, I knew what I was getting into. Still, the disparity between quick, agile iteration in software and established, time-consuming and process-heavy practices in building automotive equipment came into sharp view once again: suppliers were accustomed to waterfall processes that took too long to produce results and led to heavy mark-ups and subpar deliverables; software and hardware parts were difficult to source; metaphorically, different functions spoke different languages and I needed to help translate.
Embedding any new and unproven components—hardware or software—in the critical path is rarely something that we would consider prudent so you should think about how to be flexible by offering a variety of low-risk integration
Despite the inherent hurdles, the automotive industry has made big strides towards embracing the new age of technology you only need to take a look across the latest vehicles on the market to see the dazzling array of modern features on offer, providing navigation, driver assistance, connectivity, and entertainment.
The big challenge
Those features are implemented according to only a handful of archetypes—an HMI system with an attached telecommunications unit (TCU) with a CAN gateway that bridges into firmware, a proprietary ADAS system that operates more or less independently, etc. What is more, the number of credible vendors for any specific subsystem can be counted on the fingers of one hand. As a result, even though a modern vehicle is truly “a computer on wheels”, on some fundamental level that computer has the same capabilities regardless of which manufacturer produced your vehicle. I have found out first-hand that the path around this present state is lengthy, difficult, and expensive. This is inconsistent with the natural cadence and expectations of modern software development and results in siloed, rigid solutions and business models.
To enable broader innovation we need smaller, well-defined functional modules that can be mixed and matched without lengthy negotiation and large NREs, ECU-level interfaces that are based on open standards, and software frameworks and platforms that encourage experimentation rather than lead to vendor lock-in. We need to build an ecosystem that is similar to the one that Android created for smartphones: open-source interfaces, reference designs, and a widely available software platform that fosters a thriving and efficient community of suppliers and OEMs.
in my current role I lead product security at Zoox—one of the foremost autonomous vehicle companies (did I mention we are hiring?). Strengthening our internal cybersecurity R&D organization, keeping track of emerging standards, and bringing in vendors who can augment our efforts are all part of the job.
What makes the work most interesting
To keeps me up at night occasionally is the need to chart our cybersecurity roadmap across a largely unknown risk landscape and juggle perceptions about cybersecurity held by both traditional computer security vendors and automotive security specialists (our needs as an innovator in the field are almost always different from what is available off-the-shelf or pitched to us from either side; we are effectively at the cutting edge of building converged cybersecurity infrastructure, integrating the IT, OT operational technology, and Product security domains).
I would encourage suppliers of Automotive Engineering Services to try and see things from the perspective of OEMs that need to balance functionality, safety, and security for a complicated BOM that contains tens (or hundreds) of ECUs and even more major software dependencies as well as operationalize the technology far beyond building and selling individual products.
Embedding any new and unproven components hardware or software in the critical path is rarely something that we would consider prudent so you should think about how to be flexible by offering a variety of low-risk integration points, dispel concerns about lock-in for your solution by leveraging open-source software, and clearly express the long-term value that you are providing to the finished product as well as to OEM processes. I am excited about the path ahead and about being part of the evolution of the automotive value chain over the coming years! You can find my posts about technology on LinkedIn reach out and share your thoughts!
