Programming languages and F1

[Masato]

I have a strange question how important is programming in F1? When a say programming i mean high level languages like Java and C.

This is a area that is increasing in terms of importance or F1 is more about Calculations phisycs and working with softwares like CFD and CATIA

Is a strange question but i´ve talking with some of my teachers in university and they said that engineering these days is much about programming (i´m in telecomunications area) so i would like to know how imporante is the work of a programmer ( like those in software companys) in F1

Best regards

[beelsebob]

There's enormous scope for programming in F1.

Here's a few examples:
• The new power units require complex modelling to figure out what the best way to break, to accelerate, to spin up the turbo, etc.
• Each team requires incredibly efficient CFD software. The FIA gives them a flop budget, so they need to have the absolute most efficient software they can manage to write.
• The teams need to write simulators, so they need physics models, of pretty much everything going on on the car.

Basically, if you'd like to get into F1, writing code is not a bad plan. In these teams where people are going to write extremely performant code, no one is going to be writing code in managed languages like Java or C# - the overhead of garbage collection (or even automated reference counting systems) is too significant. Because of that, you should look at learning languages that allow you to do your own memory management, work directly with pointers, etc. Thus, C and C++ are good starting points. You probably want to look at APIs like OpenGL, OpenCL, CUDA, DirectX, DirectCompute, AMD stream etc to find out how to write the kind of highly efficient physics code that these guys will be working with. It'll also be worth looking at functional programming, as the idea of referential transparency is incredibly important in how efficient parallel programs work. SAC (Single Assignment C), is worth looking at, because while it is very academic, it will teach you a lot of important details of how physics problems can be efficiently modelled.

Hope that helps.

[Tim.Wright]

Not just F1 but engineering in general. If you limit yourself to hand calcs or excel, you will be severley limiting the scope of your analysis. I'd argue almost to the point of being pretty useless.

In terms of post processing of recorded data (say track data from a test), some form of programming interface is absolutely indispensible.

Also, when you are getting very into detail in a lot of problems, its often more time-efficient to use a programming interface of a given software rather than the GUI - for example adams can be controlled manually or through its own command language. Same with many CFD and FEA solvers.

[Jef Patat]

In the past I have been working for New Holland engineering department. Mainly for forage and combine harvesters, but also for grape and sugarcane harvesters. I didn't write controller software myself, but I was closely involved. My job was programming the in cab monitor of which you can think as a very advanced dashboard display.

One of the most important things in controller design is 'hard real time' behavior. Therefore the most important skills are to understand the concepts of real time operating systems, languages that allow to work realtime (C/C++ are most used) and how to schedule work to operate real time. OSs used at that time were CMX RTOS and Greenhills Integrity. Of course that choice highly depends on available hardware.

Now, that hard core is becoming more and more old school, it's still necessary, but less than it used to be. These days development is more model based. The leader in that field is MatLab. Designs are modelled and code is automatically generated, which moves the effort from programming/debugging to solving the problem though models (this is a very very basic explanation). After the modeling step things can be tested through Software in the loop and hardware in the loop (for example dSpace).

To give you an idea of the strength of these methodologies: the complete software can be made and tested without even having hardware. You can feed real world data, from testing for example, to the model, change parameters, change the model, and see what the effects are without the need of doing any real life testing.

And this is just for controller units. Many other programming needs to be done in F1, DSPs, FPGAs, desktop software, ..

[Jersey Tom]

I have a strange question how important is programming in F1? When a say programming i mean high level languages like Java and C.

Since when is C a high level language? Maybe some years ago, but I don't know if I'd call it that now relative to a lot of other stuff out there. (I suppose this could spawn off it's own debate...)

In any event - not a strange question at all. As others have said, good software engineer is quite important across motorsports, automotive engineering, and engineering in general. I'd say you'd find experience in one language or another in quite a few job postings.

CFD is just one piece of it, there's much more.

Depending on what you're doing... there's need for knowledge of SQL, C#/VB/.NET, C/C++, Fortran, Matlab / Simulink, Modelica, Python - to name a few.

Basically, if you'd like to get into F1, writing code is not a bad plan.

"Writing code" is one thing, but software engineering is another. Important distinction. Personally I'd be much less inclined to hire someone who just has experience hacking through C++ code (even if they're fairly proficient working on their own), compared to knowing how to implement good design patterns, etc.

In these teams where people are going to write extremely performant code, no one is going to be writing code in managed languages like Java or C#. [...] Thus, C and C++ are good starting points.

I don't think I'd agree with that statement. There are some things which are performance critical from a CPU cycle and memory access standpoint - but not all things are like that. There is so much more to software development than just core solvers.

It's often just as (or more) important to be able to develop libraries and applications quickly, where something like C# or other flavors of .NET are excellent. There are times when I'd much rather have something done in say C# today than several days or a week later in C++ which executes marginally faster.

[alexx_88]

From my research on the matter, it appears that teams tend to offer jobs that focus on data analyzing and gathering, with very little to no offerings in the area of low-level, performance-critical programming, such as the ERS controllers. My feeling is that they outsource those to their suppliers of those systems, which actually does make sense since F1 teams don't have the necessary experience to develop them.

I'd say that your best bet is focus on relatively common stuff, like .NET, C#, SQL and on projects that tend to resemble what F1 teams need: acquiring and processing of large sets of data.

Regarding CFD, I know that some kind of programming language experience is desired, ranging from C++ to the simulation tool's own scripting language, but that seems to be a rather niche area.

[Jef Patat]

The problem with this topic is that the question is too vague. Programming in F1, what does that mean? It can go from low level drivers, realtime OSs, (and as I mentioned, these are probably not used a lot), model based design, data analysis, server side programming, web programming, proprietary software programming, extension programming of existing software, ...

Every equaly vague answer about programming will be correct.

In these teams where people are going to write extremely performant code, no one is going to be writing code in managed languages like Java or C#. [...] Thus, C and C++ are good starting points.

I don't think I'd agree with that statement. There are some things which are performance critical from a CPU cycle and memory access standpoint - but not all things are like that. There is so much more to software development than just core solvers.

It's often just as (or more) important to be able to develop libraries and applications quickly, where something like C# or other flavors of .NET are excellent. There are times when I'd much rather have something done in say C# today than several days or a week later in C++ which executes marginally faster.

I think your argument makes no sense. beelsebob is mentioning performant code, you are talking about ease of development. Where performance matters you won't be talking managed or interpreted languages, there's just too much overhead.

[Jersey Tom]

I think your argument makes no sense. beelsebob is mentioning performant code, you are talking about ease of development. Where performance matters you won't be talking managed or interpreted languages, there's just too much overhead.

I read his assertion or what's being implied as code development in F1 / racing / whatever is all performance critical, and nobody would be using managed languages in general.

What I'm saying is that software development in racing is much broader scope than just FE solvers and things of that nature. I'd go so far as to say in many cases there's much more development done in managed or high level languages than low level.

If you can get NASTRAN off the shelf, why waste time reinventing the wheel writing your own FE solver? Same could be said for core CFD or MBS code. Bigger gain is doing all the support infrastructure both up- and down-stream of that.

[Kiril Varbanov]

Every equaly vague answer about programming will be correct.

Indeed. Hence, I'd add MatLab to the equation. In fact, many of the teams are already using it.

[beelsebob]

I think your argument makes no sense. beelsebob is mentioning performant code, you are talking about ease of development. Where performance matters you won't be talking managed or interpreted languages, there's just too much overhead.

I read his assertion or what's being implied as code development in F1 / racing / whatever is all performance critical, and nobody would be using managed languages in general.

What I'm saying is that software development in racing is much broader scope than just FE solvers and things of that nature. I'd go so far as to say in many cases there's much more development done in managed or high level languages than low level.

If you can get NASTRAN off the shelf, why waste time reinventing the wheel writing your own FE solver? Same could be said for core CFD or MBS code. Bigger gain is doing all the support infrastructure both up- and down-stream of that.

Don't get me wrong, there's certainly plenty of tasks involving twiddling with databases, and writing back end software in C# and the like... But.

If you're asking "how do I get a job programming in F1", you probably don't care about this (maybe I'm making a wrong assumption here though). The boring twiddling with databases code can be written in pretty much any field, and is about as un-interesting in all of them.

The tasks that are rather specific to F1 (and a few other limited fields, like avionics) though, is all high performance stuff. This is where the interesting problems lie, and the things that are actually related to F1 in some way, rather than just being a database engineering job at a company that happens to also make F1 cars.

Finally, re your assertion that you would like someone who can "implement good design patterns". I don't begrudge you this opinion, but I can tell you from being a fairly senior engineer at a very large company in the bay area, people mentioning design patterns in an interview is a big red flag. What we does want to see is competence at design, and critical thinking, along with some ability to get code written. What we don't want to see is people who reel off a bunch of names from the gang of four book.

[WhiteBlue]

If real time program writing is your thing you should work with Merc, Ferrari or Renault's PU departments or you go and join McLaren Microsoft who do all the SECU work.

[Jersey Tom]

Okay, I'll go back on the phrase "design patterns" and just say "professional best practices." Point being, a lot of people can hack together "something that works" on their own in some language of their choice. There are plenty of "coders" out there, but far fewer who are experienced software engineers, and far fewer still who have some blend of both classical and software engineering experience which is really a slam dunk.

I would still say that in my experience, on a race team you're not going to be writing from scratch core solver code when you could save immense amounts of precious time by using an already proven solution (be it NASTRAN, FLUENT, ADAMS...). Yes, you might write some extensions to these (like a tire model) which would indeed be C/C++ or Fortran. Though even then, that may be handled by the vehicle dynamics engineers - where you're expected to have those languages as a skill - rather than a pure programmer.

In any event, winning races isn't about programming the fanciest vehicle model (or what have you). On the contrary I'd argue it's about knowing the simplest you can use, knowing how to use it, and most importantly integrating it efficiently so you can get meaningful value out of the whole process.

Point is there is bound to be plenty of high level and managed language development in there - far from all low level.

(As an aside I'd make the case it's probably easiest to learn a GC'd high level language as your entry point, and later on take on unmanaged lower level stuff when needed. Even in C++11 and onward, it's frequently encouraged to avoid raw pointers or pointers in general!)

[beelsebob]

Okay, I'll go back on the phrase "design patterns" and just say "professional best practices." Point being, a lot of people can hack together "something that works" on their own in some language of their choice. There are plenty of "coders" out there, but far fewer who are experienced software engineers, and far fewer still who have some blend of both classical and software engineering experience which is really a slam dunk.

Agreed, completely.

(As an aside I'd make the case it's probably easiest to learn a GC'd high level language as your entry point, and later on take on unmanaged lower level stuff when needed. Even in C++11 and onward, it's frequently encouraged to avoid raw pointers or pointers in general!)

Indeed GCed languages will be easier to learn. Unfortunately, many people never move onwards from there, and never actually learn how memory management works. This makes people who do understand that well very valuable.

The idea that you should avoid pointers in C++11 is a complete misnomer. While certainly you should favour references, and better yet const references over them, ultimately, at some point, in any non-trivial program, you will need to do some (usually a lot of) heap allocation. It is once again then preferable to use smart pointers over raw pointers much of the time. But that does not mean that you never want to use a raw pointer.

[GrandAxe]

I have a strange question how important is programming in F1? When a say programming i mean high level languages like Java and C.

This is a area that is increasing in terms of importance or F1 is more about Calculations phisycs and working with softwares like CFD and CATIA

Is a strange question but i´ve talking with some of my teachers in university and they said that engineering these days is much about programming (i´m in telecomunications area) so i would like to know how imporante is the work of a programmer ( like those in software companys) in F1

Best regards

Language is not the first thing you should consider. Think about what the job is about before anything else.

F1 is an incredibly innovative sport that demands creativity at every level. It demands wild lateral thinking in a highly structured and repeatable development environment. In F1, programming covers everything from GUI to code that runs engine functions.

The secondary characteristic's of the ideal candidate would be; the patience of a vulture, an eye for detail, immense focus even after long hours and (optionally) a working knowledge of a low to middle level programming language (e.g. Assembly language, C, C++).
You don't want to be a mere technician who can deliver rote about pointers and CPU's like a wind up toy, but falls flat when asked for say, suggestions and solutions to MGU-H integration (just as many on this site just rattle off scripted answers to every question).

The primary characteristic's of the ideal candidate would be; strong lateral thinking abilities, strong problem solving abilities, a love for structure and order; and above all, (as a couple of others have mentioned) an excellent grasp of software engineering. Knowledge of a high level language (e.g. C# or Java) is a bonus.
You basically want a visionary who just happens to know how to structure and integrate diverse systems in code; so you have to aim for a reachable spot on the visionary scale and work your CV, skills and experience toward it.

I have never worked in F1, but I've done enough time with real-time image processing and AI to understand what the creative programmer/developer is likely to be in other areas.

[idfx]

You must know the J2ME is Java-based mobile ( cell phone, digital TV , smartphone , tablet ) . Java is lightweight , but it's hard to program because it is quite robust . It is how to program ; Direct the "root"
C # and C # language excelent , teams use a lot. Programming errors are due ; by conflicting commands or error to declare a variable and generally it blocks everything .
Ex : The car can be slow , because two Variables create a third , and the software does not run the command . Find the error in several lines of code created by someone else is a @ # $ % & .
The development team of software has to be the same simulator and should do the maintenance work with new solutions .
Games development teams can help teams .
LUA and python are more flexible and can be combined with C # and C # assisting in complex commands .
We can create an AI (artificial intelligence ) for car, adapting to specific conditions . Or solve problems separately or integrated management form.
Video games ( xbox , playtation ) can be used to simulate CFD , they have 64 cores . It is an economical alternative.
I think the FIA have to encourage this kind of research interest .