5 ms·

> I'd expect that if any ECU software was to be released that we'd finally realize how bad things really are and that there would be a massive amount of work do

> I'd expect that if any ECU software was to be released that we'd finally realize how bad things really are and that there would be a massive amount of work done on making sure these pieces of critical software would be as safe as they could possibly be. toyota/denso michael barr testimony cough edit: oh, there's even slides now, you don't even have to read the court transcript https://www.safetyresearch.net/Library/BarrSlides_FINAL_SCRUBBED.pdf https://www.safetyresearch.net/Library/BarrSlides_FINAL_SCRU...

jacquesm 3y ago
Yes, that's one of the better known cases. But I've looked at similar stuff under NDA and I'm more than a little bit uncomfortable with some of the stuff that I've seen. The scariest kind of developer to me are the ones that believe that they and only they are able to create safe software without outside scrutiny of what they produce. Of course that scrutiny would have exposed emissions cheating software right on day #1.
- intern4tional 3y ago
  This comment chain appears to have a fundamental misconception of what constitutes safe and what does not. Automotive standards and automotive coding standards approach safety in a different way than most people think (and given your comments I would say this includes you). If you're curious, you can have a look at some rules to evaluate automotive code that are published here: https://github.com/github/codeql-coding-standards https://github.com/github/codeql-coding-standards In short, the rules do not aim to eliminate failure or crashes, but rather make the crash predictable and uniform when a crash occurs so that it can be dealt with. This is further complicated by where and how the automotive manufacture chooses to implement safety controls. It is entirely possible to have a bunch of unsafe code running somewhere on a car, and simply have a small safety shim around said code that prevents the unsafe code from impacting the safe operation of the vehicle. With that in mind, let's take the example that you use here of emissions cheating software. Emissions is likely not considered safety relevant (it might not even be QM, it just might be some code) and so no safety requirement applies to it. So, no real scrutiny would happen there regardless, at least from a safety perspective. See, validating that software passes a particular safety certification is time and money intensive and manufacturers therefore keep the amount of code that they qualify as safe to a minimum. This means as an example that the infotainment systems of many manufacturers are not safety relevant and no safety function should exist on or interact with them. A few other things to consider from other threads: - Telsa doesn't necessarily follow or adhere to safety standards. They (Telsa) are explicitly non-compliant in some cases, and this is partially why there are investigations into their practices. - Industrial robotics code is just as bad if not worse than most automotive software from what I've seen. As you note, its that these robots are not under manual control - None of this prevents the software from being open source. There are plenty of safety qualified open source projects. This simply limits who can contribute and how contributions are managed. The main reason why many things in automotive are not open source is that the ECU manufacturer isn't interested in doing so, and the Tier 1/2/3 that does the implementation is even less so.
  - jacquesm 3y ago
    There is a difference between what I with my layman-user cap on would consider unsafe (say, releasing purposefully harmful software into the environment or software with bugs like phantom braking) and what I with my embedded software programmer cap on (machine control, aerospace related) would consider to be unsafe. I spend a lot of my time reading root cause analysis on software failures and my only conclusion is that this is a very immature industry with a lot of players that should probably not be trusted as much as we do. As for safety shims: for instance, watchdog timers are often used for this purpose, to bring a system that is exhibiting buggy behavior to behave more predictable. Personally I would consider any watchdog error that was not directly related to a hardware fault (say a bitflip) as a failure and I'd like to have my car report such failures. Tesla being non-compliant is precisely my point: they get away with that because they don't have to open up their code to scrutiny. But I'll bet that if they would that their marketing department would not be able to spin stuff the way they do at present. All of those would take into account the relevant context and I think that's where things go off the rails here: embedded software developers do not get to claim the high ground around what they consider safe or unsafe given the code from that world that I've had my eyes on. If anything it is amazing that it works as well as it does, the only two industries that get a pass based on my experience so far is medical embedded and avionics. Everybody else has the exact same problems as any other software project and would benefit from opening themselves up to scrutiny.
    - intern4tional 3y ago
      > Tesla being non-compliant is precisely my point: they get away with that because they don't have to open up their code to scrutiny. This is an inaccurate assumption. ASIL compliance is something that you can publicly state, and Tesla explicitly does not. Most automotive products that do follow such standards generally state such. (Example: https://www.aubass.com/products/cp_top.html https://www.aubass.com/products/cp_top.html - search for ASIL D) Making something open source does not in any way make it safe, unless your enforcement plan is having lawyers look into it and in which case you end up with lawsuits and likely endless litigation that results in a closed platform again. Tesla's calculation is that no one will enforce safety controls or standards compliance on them, and to be fair to date they (Tesla) are right. > Personally I would consider any watchdog error that was not directly related to a hardware fault (say a bitflip) as a failure and I'd like to have my car report such failures. This is an opinion and does not properly account for the multitude of scenarios that must be dealt with in automotive. Automotive, unlike aerospace, rarely has failover hardware or in some cases even A/B partitions on the disk for failover in software. Add in the need to process signals in real time and you will encounter situations where use of a health check (watchdog timer) is an appropriate response, and the use of one should not need to be reported. > embedded software developers do not get to claim the high ground around what they consider safe or unsafe given the code from that world that I've had my eyes on. They (embedded software developers) don't make such claims; when something is safety certified, an external third party does the validation and verification and asserts that an implementation and processes are either safe or not. In the EU this is usually done by TUV (https://www.tuv.com/world/en/ https://www.tuv.com/world/en/) or Horiba-Mira (https://www.horiba-mira.com/ https://www.horiba-mira.com/). This gets extremely complex as this is often hard tied to the hardware (support for a safety island, how memory is managed on the SOC, etc) and the overall E/E architecture (selected messaging protocol for the backbone) and layout of the vehicle. Analyzing a system of systems to determine all the possible impacts and make sure that the chance of failure is small enough to be acceptable is a hard problem to solve and not one any single engineer does.

jacquesm 3y ago

Yes, that's one of the better known cases. But I've looked at similar stuff under NDA and I'm more than a little bit uncomfortable with some of the stuff that I've seen. The scariest kind of developer to me are the ones that believe that they and only they are able to create safe software without outside scrutiny of what they produce. Of course that scrutiny would have exposed emissions cheating software right on day #1.

intern4tional 3y ago
This comment chain appears to have a fundamental misconception of what constitutes safe and what does not. Automotive standards and automotive coding standards approach safety in a different way than most people think (and given your comments I would say this includes you). If you're curious, you can have a look at some rules to evaluate automotive code that are published here: https://github.com/github/codeql-coding-standards https://github.com/github/codeql-coding-standards In short, the rules do not aim to eliminate failure or crashes, but rather make the crash predictable and uniform when a crash occurs so that it can be dealt with. This is further complicated by where and how the automotive manufacture chooses to implement safety controls. It is entirely possible to have a bunch of unsafe code running somewhere on a car, and simply have a small safety shim around said code that prevents the unsafe code from impacting the safe operation of the vehicle. With that in mind, let's take the example that you use here of emissions cheating software. Emissions is likely not considered safety relevant (it might not even be QM, it just might be some code) and so no safety requirement applies to it. So, no real scrutiny would happen there regardless, at least from a safety perspective. See, validating that software passes a particular safety certification is time and money intensive and manufacturers therefore keep the amount of code that they qualify as safe to a minimum. This means as an example that the infotainment systems of many manufacturers are not safety relevant and no safety function should exist on or interact with them. A few other things to consider from other threads: - Telsa doesn't necessarily follow or adhere to safety standards. They (Telsa) are explicitly non-compliant in some cases, and this is partially why there are investigations into their practices. - Industrial robotics code is just as bad if not worse than most automotive software from what I've seen. As you note, its that these robots are not under manual control - None of this prevents the software from being open source. There are plenty of safety qualified open source projects. This simply limits who can contribute and how contributions are managed. The main reason why many things in automotive are not open source is that the ECU manufacturer isn't interested in doing so, and the Tier 1/2/3 that does the implementation is even less so.
- jacquesm 3y ago
  There is a difference between what I with my layman-user cap on would consider unsafe (say, releasing purposefully harmful software into the environment or software with bugs like phantom braking) and what I with my embedded software programmer cap on (machine control, aerospace related) would consider to be unsafe. I spend a lot of my time reading root cause analysis on software failures and my only conclusion is that this is a very immature industry with a lot of players that should probably not be trusted as much as we do. As for safety shims: for instance, watchdog timers are often used for this purpose, to bring a system that is exhibiting buggy behavior to behave more predictable. Personally I would consider any watchdog error that was not directly related to a hardware fault (say a bitflip) as a failure and I'd like to have my car report such failures. Tesla being non-compliant is precisely my point: they get away with that because they don't have to open up their code to scrutiny. But I'll bet that if they would that their marketing department would not be able to spin stuff the way they do at present. All of those would take into account the relevant context and I think that's where things go off the rails here: embedded software developers do not get to claim the high ground around what they consider safe or unsafe given the code from that world that I've had my eyes on. If anything it is amazing that it works as well as it does, the only two industries that get a pass based on my experience so far is medical embedded and avionics. Everybody else has the exact same problems as any other software project and would benefit from opening themselves up to scrutiny.
  - intern4tional 3y ago
    > Tesla being non-compliant is precisely my point: they get away with that because they don't have to open up their code to scrutiny. This is an inaccurate assumption. ASIL compliance is something that you can publicly state, and Tesla explicitly does not. Most automotive products that do follow such standards generally state such. (Example: https://www.aubass.com/products/cp_top.html https://www.aubass.com/products/cp_top.html - search for ASIL D) Making something open source does not in any way make it safe, unless your enforcement plan is having lawyers look into it and in which case you end up with lawsuits and likely endless litigation that results in a closed platform again. Tesla's calculation is that no one will enforce safety controls or standards compliance on them, and to be fair to date they (Tesla) are right. > Personally I would consider any watchdog error that was not directly related to a hardware fault (say a bitflip) as a failure and I'd like to have my car report such failures. This is an opinion and does not properly account for the multitude of scenarios that must be dealt with in automotive. Automotive, unlike aerospace, rarely has failover hardware or in some cases even A/B partitions on the disk for failover in software. Add in the need to process signals in real time and you will encounter situations where use of a health check (watchdog timer) is an appropriate response, and the use of one should not need to be reported. > embedded software developers do not get to claim the high ground around what they consider safe or unsafe given the code from that world that I've had my eyes on. They (embedded software developers) don't make such claims; when something is safety certified, an external third party does the validation and verification and asserts that an implementation and processes are either safe or not. In the EU this is usually done by TUV (https://www.tuv.com/world/en/ https://www.tuv.com/world/en/) or Horiba-Mira (https://www.horiba-mira.com/ https://www.horiba-mira.com/). This gets extremely complex as this is often hard tied to the hardware (support for a safety island, how memory is managed on the SOC, etc) and the overall E/E architecture (selected messaging protocol for the backbone) and layout of the vehicle. Analyzing a system of systems to determine all the possible impacts and make sure that the chance of failure is small enough to be acceptable is a hard problem to solve and not one any single engineer does.