No amount of MISRA or ISO26262 or tests or any kind will help if the people doing the software are direct out-of-the-university mechanical engineers or physicist, who had at most one or two semesters of some kind of programming course.
The reality is that this is the current state of affairs. Most of people doing software for cars have not the foggiest idea what software is really about.
All the software I read is just impossible to understand. And no standard help in many cases.
Some examples I've seen in code:
- Use of kind of hungarian notation to the point that a loop variable was named something like "uibe32bb_i_lns"
- Comments in other human languages that were not english
- Use of recursion
- Have seen a call like name1::name2::name3::name4::name5::name6::name7::name8::name9::name10::name11::name12::name13::name14.
The names where some kind of hungarian notation, those calls where everywhere in the code.
- Lines more than 1000 characters wide, as a rule
- Files north of 100kB of code
I can go on and on and on....
Some examples of exchanges with people:
1) Software architect, of a ECU: one programer asks for the memory and CPU budget for a function. The reply was "I'm the architect, I've no idea what you are talking about"
2) System chief architect, for a very important project of a big auto-maker: one engineer says something about software errors. The architect interrupts, and explains that the software never makes an error. Because a computer only does what it is told to make. -- that is terrible enough, for example ignoring the possibility or a SEU, but he goes further, to say that any kind of test is not necessary, because, SW, as stated, makes no errors.
Some general points:
- 99% of people in "SW" do not know what gdb is. They debug by "cout <<"
- I found nobody who knows what tail recursion is
- 90% are only able to program, to some extent, in one of C++ or Python, but no other language.
- Mentioning Ada, Lisp, Forth will trigger a waterfall of insults saying those are old and should never be used.
I keep buying the most basic cars. I'm genuinely terrified to think in anything automatic in my car.
In their defense, gdb is a pain in the ass to use if your editor doesn't come with integrated support. The debugger that comes with CLion/Visual Studio is perfectly adequate. Ada is useful for automotive. Lisp and Forth, not so much (especially since Lisp isn't usually used in hard real-time applications). This isn't the 1980s, MCUs aren't that memory constrained. Knowledge of obscure programming languages doesn't necessarily make you a better software engineer. I want my
automotive embedded engineer to have a solid grasp of computer architecture, real-time safety protocols, and defensive programming. I don't see a problem with a Korean/Japanese car manufacturer having their documentation in a non-English language. As long as they do everything in-house and don't outsource to India like Boeing I have no problem with it.
> In their defense, gdb is a pain in the ass to use if your editor doesn't come with integrated support. The debugger that comes with CLion/Visual Studio is perfectly adequate.
I meant, they do not know what a debugger is. As stated, they use "cout << "At line 26, after call to xx" as debugging tool. For gdb there are plenty of python extensions, and GUIs, even web front-end, that are not bad... but it may be difficult for some people, I understand that.
> Ada is useful for automotive. Lisp and Forth, not so much (especially since Lisp isn't usually used in hard real-time applications). This isn't the 1980s, MCUs aren't that memory constrained.
Well, first, they do not have the foggiest idea what Ada is. That is my problem. Once somebody suggested we should look into it, for L4 autonomous driving. He was laugh at, and it was said "it is a dead language from the 60, like Cobol or Fortran, nobody has used it in 50 years, there are no compilers for it!!!". I've seen forth being used in some 8-bit uC in the automotive industry still. Now is 99% gone, but was very much used. Lisp, can be used in hard real-time. BTW another thing always hanging around is the "hard real-time" for automotive. It is interesting, because other than for airbags, ignition and injection, you are talking about 100ms response times, which can be achieved very easily.
> Knowledge of obscure programming languages doesn't necessarily make you a better software engineer.
I'm not taking proficiency in the languages, I'm talking knowing it exist, having an idea of what is possible. I mean, I know no good C programmer that is not at least aware or the existence or Rust. And no, 90% of the programmers writing safety critical SW have no idea that a language called rust is available.
> I want my automotive embedded engineer to have a solid grasp of computer architecture, real-time safety protocols, and defensive programming.
Well, again, another example, with a chief software architect, in an ECU, so embedded: I ask "do we have some kind of stack monitoring?" Reply: "What?! we have no stack, stack is a data structure, ..." goes on with a long explanation of what stack, queue and tree are, and when are used... My personal opinion is, if you search for people that "know" only C++, and have no idea of asm, that is what you get. That is my experience at least.
> I don't see a problem with a Korean/Japanese car manufacturer having their documentation in a non-English language. As long as they do everything in-house and don't outsource to India like Boeing I have no problem with it.
I'm talking in-code comments, not documentation. But anyway, honesty, thinking you can do everything in-house today, and you will be able to maintain that in that way for the next 10 or 20 years when you have to maintain the code, sounds optimistic to me, at least.
But again, I'm talking code I had to read, and maintain... so... yes... I'm talking a case, where it was BAD to have not english comments.
You are not reading it correctly. It is not code as everyone knows it. It's like an electrical circuit with variable names attached to each conductor, and the code propagates information like electricity would.
There's tools dedicated to this, able to draw pictures of such code circuits (e.g. Simulink, Ascet). And such pictures can be automatically translated into c-code, that looks even worse than anything translated manually.
In the end, of course the tests prove that the code works like the picture of the circuit shows, and therefore the car must work correctly! This avoids the need for anyone working on only the code to understand a car.
In reality, things usually work in the end only because of how simple everything is and high number of iterations.
I think you are referring to something like Ascet. I know it.
I consider that code to be an intermediate representation that I'm not supposed to understand, maintain, or even test.
I’m talking about human written code, meant to be read, maintained, debugged and tested by other humans.
Modeling programs as circuits also makes them significantly easier to formally verify too! These sorts of synthesis tools are really cool, though writing traditional software in them is extremely painful.
you would be more terrified after interaction with security engineers at OEMs - people who hold keys for the OEM's entire kingdom with admin access to everything running outdated OSs/systems well past last day of support date
The reality is that this is the current state of affairs. Most of people doing software for cars have not the foggiest idea what software is really about.
All the software I read is just impossible to understand. And no standard help in many cases.
Some examples I've seen in code: - Use of kind of hungarian notation to the point that a loop variable was named something like "uibe32bb_i_lns" - Comments in other human languages that were not english - Use of recursion - Have seen a call like name1::name2::name3::name4::name5::name6::name7::name8::name9::name10::name11::name12::name13::name14. The names where some kind of hungarian notation, those calls where everywhere in the code. - Lines more than 1000 characters wide, as a rule - Files north of 100kB of code I can go on and on and on....
Some examples of exchanges with people:
1) Software architect, of a ECU: one programer asks for the memory and CPU budget for a function. The reply was "I'm the architect, I've no idea what you are talking about"
2) System chief architect, for a very important project of a big auto-maker: one engineer says something about software errors. The architect interrupts, and explains that the software never makes an error. Because a computer only does what it is told to make. -- that is terrible enough, for example ignoring the possibility or a SEU, but he goes further, to say that any kind of test is not necessary, because, SW, as stated, makes no errors.
Some general points: - 99% of people in "SW" do not know what gdb is. They debug by "cout <<" - I found nobody who knows what tail recursion is - 90% are only able to program, to some extent, in one of C++ or Python, but no other language. - Mentioning Ada, Lisp, Forth will trigger a waterfall of insults saying those are old and should never be used.
I keep buying the most basic cars. I'm genuinely terrified to think in anything automatic in my car.