75

This infographic shows the different number of lines that some software applications (or a general type of them) have on average.

The number of lines shown for an average modern high-end car strikes me as implausible. I know modern cars have lots of control of several aspects related to the car and I also know that the languages used for programming them (C and assembly) are more verbose than more high-level programming languages, but still I don't see a car software taking notably more code than a huge social network like facebook, a full operating system with lots of features like Windows Vista, or a professional IDE like Microsoft Visual Studio. It looks like there are rather fewer things to control in car software.

Maybe those lines refer to the lines in assembler code, if that were the case it would be plausible to me, but then in reality the number of coded lines would be let's say around 6 times lower, which would put it with the Boeing 787 software, which I think would make more sense.

Are around 100 million lines the amount on average of lines in source code that programmers have to code in order to create the software for an average high-end car?

29
  • 110
    A lot of large embedded systems have either a whole linux kernel or a windows nt kernel running. I'm pretty sure they counted that
    – Sklivvz
    Sep 25, 2017 at 14:28
  • 12
    I don't know if this claim's particularly meaningful. Whenever a program's compiled, the compiler can select a trade-off between code size and performance (e.g., as in this question from StackOverflow). For example, you can precompile a square root function into a look-up table for typical 64-bit floats, resulting in over 1.8-quintillion LOC (because, yes, you included negatives mapping to NaN 'cause why not?).
    – Nat
    Sep 25, 2017 at 15:21
  • 16
    Based on my (limited) experience this number may be even less meaningful than usual, because a fair bit of safety critical code is generated from formally verified models via model-driven development. So maybe there is a bunch of C or Assembly code that no human is ever allowed to directly touch.
    – xLeitix
    Sep 25, 2017 at 15:47
  • 33
    Source code that is generated is not source code
    – jk.
    Sep 25, 2017 at 16:05
  • 46
    One should note, however, that LOC is not a especially useful measure for the inherent complexity of some system.. Sep 25, 2017 at 16:20

4 Answers 4

75

Ford has said that the F150 pickup has 150 million lines of code.

According to the New York Times:

Twenty years ago, cars had, on average, one million lines of code. The General Motors 2010 Chevrolet Volt had about 10 million lines of code — more than an F-35 fighter jet. Today, an average car has more than 100 million lines of code.

So, even if the car isn't particularly high end, it could have that many lines.

According to Embedded Systems Security: Practical Methods for Safe and Secure Software (2012):

One of the first embedded systems within an automobile was the 1978 Cadillac Seville's trip computer, run by a Motorola 6802 microprocessor with 128 bytes of RAM and two kilobytes of ROM. ...
In contrast, even the lowest-end automobile today contains at least a dozen microprocessors; the highest-end cars are estimated to contain approximately 100 microprocessors. With infotainment systems running sophisticated operating systems such as Microsoft Windows and Linux, the total embedded software content can easily exceed 100 million lines of code.

25
  • 51
    Keep in mind that this often includes open source projects, not all of which are used in the operation of the vehicle, but are likely compiled along with the rest of the binaries. If you check the back of the owner's manual for modern cars, there are often pages and pages of open source license acknowledgements. Sep 25, 2017 at 16:12
  • 25
    Judging by how slow they are, more than half of that is in the typical new car entertainment/navigation system.
    – T.E.D.
    Sep 25, 2017 at 16:25
  • 11
    It might be worth separating the explicit claim (about lines of code) from the implicit claim (about human-written lines of code), since the great bulk of the reported metric's auto-generated, e.g. by Stateflow (image).
    – Nat
    Sep 25, 2017 at 16:32
  • 98
    Also, the number of lines of code in a system isn't a sign of sophistication or something to be impressed about - it's often a sign of bloat and poor design. So basically Ford is bragging about having poor engineering... 10+ MLOC to run a radio and touchscreen is absurd, even if you include the kernel LOC count, etc.
    – SnakeDoc
    Sep 25, 2017 at 18:01
  • 29
    Ford sounds like a reliable source, but the quote is probably written by some expertise-free dude in the marketing department who believes that more of something is better. That is a pretty good reason to discount it as a reliable source. I think this answer needs better sources.
    – matt_black
    Sep 25, 2017 at 18:44
45

LOC is a particularly bad metric, because it raises the question of what is a line of code. Do you include whitespace and comments? Compiler directives? Preprocessor definitions? How about lines containing only braces? Do you include makefiles or whatever scripts do the building? And in the end, does the number of LOC truly relate to the complexity of the code? This white paper provides a summary of many of the issues around this question, of which I've quoted a few above.

Also consider that some languages lend themselves to shorter code than others, whether due to the common C style convention of parentheses on separate lines, the standard language library providing additional features by default, or the language itself including features which in other languages are handled by library functions. This is the core of work by Halstead amongst others. This comparison between Perl and VB.net is one example. This comparison across multiple languages demonstrates what the author calls the "expressiveness" of languages, where bugfixes in more "expressive" languages such as Python appear to need fewer LOC changes on average than languages such as C.

Where it most spectacularly runs into trouble though is when you consider how much is now under software control - and what that software might be. The satnav is one separate module; the email/phone/data interface is another module; the radio is a third module; the dash is a fourth module; aircon is a fifth module; and there's often a central display which coordinates them all. And that's just for the dashboard. This EENews article estimates over 50 electronic control units in a modern car.

Back when I worked on a Ford email/text/data interface, we were using WinCE. I wouldn't be at all surprised to find that they now have Linux and/or Android in there today. And some modules will roll their own OS, if they're running on a tiny microcontroller which doesn't warrant anything else, or if they are safety-related and require a greater level of scrutiny. The LOC for WinCE appears to be unknown, but WinNT had around 10 million and WinXP was up to 40 million. It seems reasonable to assume WinCE is of the same order of magnitude. The Linux kernel itself (as maintained by Linus) is now over 20 million LOC. If you multiply that by the number of devices in the car which might use these OSes (and that actually could be reasonable if they're all using different versions of OSes) then you're easily into the hundreds of millions.

If you only count LOC in C/C++ written by the car manufacturer, it's almost certainly a lot lower. But then the same logic would give the paradox of an Android phone which might have no unique LOC for a manufacturer, even though all manner of stuff has been tweaked in the build. You can't realistically say "this phone has zero LOC" just because it's all built from off-the-shelf libraries; but equally the total LOC in the OS and libraries does not reflect the engineering effort required by a manufacturer.

9
  • 11
    While this is a good point to raise amongst us Engineers, for the layperson there's no reason whatsoever they should care about the precise accuracy of a "LOC" report. The factors of 10 differences being reported are going to wash out any piddly <50%ish differences in how the LOC measurements are taken.
    – T.E.D.
    Sep 26, 2017 at 13:59
  • 3
    @T.E.D. True, but it's important for the layperson to grasp how broken the metric is, even before we decide where to apply it. If they simply assume "well, we can standardise on this is the type of line we'll count, and now life is good", they need to know that the flaws run more deeply than that. Everyone accepts that these kind of metrics are just for ballpark figures, but if you've got 50% error on your ballpark figure then it's clearly not much use.
    – Graham
    Sep 27, 2017 at 10:47
  • It's not "broken", you just have to know how to use it...like any tool. SLOC is best used for delta comparisons using similar codebases and identical calculation methods. There is no code metric that is without problems, and IMHO SLOC at least has the virtue that its trivial to calculate. Its true there are many things we software professionals need to do with code metrics where using SLOC would be like driving a screw with a hammer. However, this is not one of those cases, so there's not much point of raising it as an issue.
    – T.E.D.
    Sep 27, 2017 at 13:44
  • 1
    Agreed, if you have similar code, in the same language, written under the same coding standard and style guidelines (and ideally by the same person), then you may get valid numbers. The more you deviate from this narrow niche though, the less valid it becomes. (As a principal engineer, I often could not usefully compare LOC metrics from a junior engineer and from a senior engineer, because the two would solve problems in different ways.) And when it gets used as a proxy for the complexity of software, as used by the articles the OP references, I think we'd both agree it's badly misused.
    – Graham
    Sep 27, 2017 at 15:39
  • 1
    @PaulJohnson Which is what I said...
    – Graham
    Sep 28, 2017 at 16:15
15

NASA Report on Toyota Camry Unintended Acceleration Investigation mentions 463,473 lines of code only in the engine control module.

4
  • 3
    Not sure what that implies, that 0.5% of 100,000 lines of code.
    – Sklivvz
    Sep 26, 2017 at 5:25
  • @Sklivvz: Compare engine control with a navigation system. Database, route finding, display / touchscreen driver, 3D rendering, GPS, ...
    – DevSolar
    Sep 26, 2017 at 11:13
  • 7
    +1, its sourced and doesn't include lines for extras like navigation, or the robot arm used during manufacture.
    – daniel
    Sep 26, 2017 at 12:01
  • 1
    That is well sourced LOC for a safety critical module, where the code was written well before 2005 (i.e. 15 year old code). Although the code is probably arithmetically generated, it is also performance critical (so you could assume there is not too much bloat). Sep 28, 2017 at 12:02
9

That inforgraphic provides sources for all the data it contains. The number in the particular claim about car software comes from this article, which specifically states that they counted LOC used in infotainment systems, which are typically based on a customized Linux kernel and include popular media codecs and communication stacks like Bluetooth.

As a personal experience, I work on a software used in exhaust sensors. We don't use LOC metric anywhere in the project, but a quick line count on the repository gives around 250'000 lines just for one sensor.

4
  • 1
    ... and may also include Android, Java... Media codecs for sure... Sep 28, 2017 at 10:26
  • How much of those 250k are tests? Sep 28, 2017 at 20:38
  • 1
    @transistor09 none, we don't keep tests in source code. Sep 28, 2017 at 21:57
  • I worked for a car infortainment platform 10 years ago. I can assure you that just the code to display the songs on your ipod (remember ipods?) was many thousand lines of code. And of course the album covers are displayed as icons, probably using a jpeg library... Another thing is: What is a high end car? If you look at Teslas, the LOC count likely jumped an order of magnitude, or two. It probably just jumped by a million after they realized that they better detect white semis doing u-turns on highways. Sep 29, 2017 at 8:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .