Mercedes-Benz vs. F-35
A while ago I attended a discussion about vehicle software development and maintenance. The presenters discussed the increased complexity in automotive software, especially in in-vehicle infotainment (IVI) and the advantages of remote over the air firmware update (FOTA).
To demonstrate the magnitude of the problem, one of the speakers used oft-cited statistics contrasting the number of lines of code (LOC) in the software in a modern car and of a military aircraft. The statistics (attributed to IEEE) were:
- Current generation aircraft 1.7 Million LOCs
- Next generation aircraft (F-35) 5.7 Million LOCs
- Modern passenger car 100 Million LOCs
Do these figures mean that the software in a passenger car packs more functionality than an F-35? As complexity increases exponentially with the number of lines of code, do the numbers indicate some 500-fold increase in the complexity of vehicle software?
While there’s no doubt that software in today’s cars is rich in functionality, the direct comparison with airborne software isn’t that straightforward at all.
Configuration and Variant Management
The main reason for bloated software in cars is the unwieldy number of options and configurations offered with most cars, especially luxury models. These options, especially consumer-facing systems such as infotainment, navigation and comfort features are software controlled and interact with yet other under-the-dash software driven subsystems.
A common challenge across automotive manufacturers is that they operate under an unwritten assumption that they need to be able to manufacture and sell every conceivable permutation of options, or, in automotive parlance, features. Automakers do not have a good grasp of consumer options that are more relevant and desirables. Moreover, option packages can change throughout the life of the model to match market preferences, offer competitive features and pricing, or introduce new systems.
The result is a massive corpus of software code, often poorly testes, designed to handle any conceivable permutation even though many of them are not offered or never sold to consumers.
Software Quality Standards
The other reason for large lower quality software is the fundamental differences between the automotive and aerospace industry when it comes the quality standards. For example, strict coding standards require that airborne code is inspected to be free of dead code: code that is not reachable or never called by other functions and therefore never utilized.
Automotive Software Development
Automotive software development does have its challenges, which aren’t common in aerospace. In particular, the speed to market and the cycle time of software features, especially of infotainment systems is an order of magnitude faster in automotive than in aerospace. Time and resource pressures and shrinking profit margins greatly limit the ability of automotive companies to meet the quality standards employed in aerospace.
The automotive industry does need to improve the quality of software, and FOTA is an effective technology to deliver software updates. But next time we discuss software complexity, let’s not use lines of code to insinuate that a Mercedes-Benz is more sophisticated and complex than an F-35.
Image: Number 48 (Jackson Pollock, 1949)