6 ms·

"One option for making auto software safer is to open it to public scrutiny. While this might sound counterintuitive, some experts say that if automakers were f

"One option for making auto software safer is to open it to public scrutiny. While this might sound counterintuitive, some experts say that if automakers were forced to open up their source code, many interested people — including coding experts and academics — could search for bugs and vulnerabilities. " This is simply not going to happen. Firstly, the majority of automotive control systems on an ECU are running generated code from toolschains such as CATIA Systems, Dymola, MapleSim, OpenModelica, SCICOS, SimulationX, Vertex etc etc etc. To validate against vulnerabilities requires in-depth knowledge of a particular manufacturer's modeling practices & standards. The code is not readable, the model is. Which relates to the second reason, the IP in these models is very closely guarded. Competitive advantage and product differentiations are pretty much all software now. Even suppliers and manufacturers share black box models & systems back and forth for fear of leaking IP. In a world where say BMW hands Bosch a set of requirement, Bosch supplies BMW HW and BMW validates in simulation and analysis with neither getting insight in to the other's design. You're telling that needs to now be done in the open?

Zigurd 11y ago
There are a lot of bad reasons for "closely guarded" IP: 1. The government told you to put spyware in e.g. your mobile baseband processor 2. Your GPU violates a lot of patents 3. You ECU implements dark patterns w.r.t. emissions testing Make regulations requiring publishing the code, and require making the toolchain available to code can be verified vs. the shipped image. Proprietary software isn't a valid excuse when the stakes are to poison the environment.
nmrm2 11y ago
I agree with you -- the push for opening up code to public scrutiny is politically and economically unfeasible. But that doesn't mean nothing can be done -- a more palatable regulatory regime might require oversight a la the aerospace industry, but emphasizing the use of formal methods over expensive and arbitrary process hoop-jumping.
- radiorental 11y ago
  Agreed, here's what aerospace arrived at (organically too) https://en.wikipedia.org/wiki/DO-178B https://en.wikipedia.org/wiki/DO-178B
  - kaftoy 11y ago
    No problem for that. Are you ready to pay to have that? Because stuff like that does not come cheap. Quite sure we can find some numbers on the Internet, probably you are not the first people in the world to think of implementing aerospace regulation in the automotive business :-). I am pretty sure in an industry where saving 12$ / unit (trough some improvement for example) is considered a GIGANTIC gain, applying some super strict aerospace standards will take the car prices to unacceptable levels.
    - nmrm2 11y ago
      Okay, then car companies can open source their ECU (and other safety-critical) software. No one is recommending copy/pasting aerospace regulations. In part because we're now 10-30 years further along in basic and applied CS research than we were when those regs were drafted. What makes aerospace regulations expensive is the process, not the analysis. The attitude that formal methods are completely untenable is painfully sutck in the 1990's. For god's sake, Facebook runs portions of their code base through static analyses, as does Google. If websites are important enough to establish the safety of using formal methods, then the software running are ours sure as hell is. In any case, thing is sure: as software becomes an integral part of high-level safety-critical control decisions, it needs to either be taken seriously by car companies and trusted by the general public. Formal methods and static analysis are the only way we know of for establishing trust in software systems without revealing their source code or relying on black box testing (the downsides of which are demonstrated by both the Toyota UA and VW emissions testing cases). If you know of a third option, then by all means...
      - kaftoy 11y ago
        True, maybe a little bit more openness would not hurt nobody. Probably would help people trust automakers more and not go nuts when a scandal goes live like the VW. Never seen any banks open their strategy to the public after so many of them fucked us over a few years ago. It's not like I can copy their strategy and go make me another bank. But going back to automotive, because that's what I do for a living. The process is quite strict and controlled. Efforts is done and periodic audit is done too to ensure adherence to ASPICE (http://vda-qmc.de/en/software-processes/automotive-spice/ http://vda-qmc.de/en/software-processes/automotive-spice/) and other regulations, including customer audits, which are tough. We do have internal processes, coding (and not only) methods, source control, configuration management (features, bug tracking) across all project and generic development base. The basic workflow is follows a V-cycle path: - receive requirements. - requirements engineering, experts involved; - test design based on requirements; - internal design of whatever kind (models etc.); - design reviews, simulations (if models), all kind of analysis; - implementation (if not code generation); - code reviews; - static analysis ((pc-)lint, klocwork to name a few); - module tests (unitary tests (ptu), tests on the HW with simulated signals - aka tetsbench tests); - integration tests; - system validation tests (requirements tests), hardware-in-the-loop tests, close loop tests; - dependability tests run on the car. In parallel the system is calibrated and calibrations are used during validations. For every version going into production (because some are just interim steps for validation purpose), there's a lot of testing going on on features already tested before. SW execution is monitored by SW. The micro is monitored in some interesting ways and on top of that an IC is monitoring all the... other monitors. Lots of stuff is done to ensure RAM/ROM consistency, process execution monitoring, signal acquisition plausibility. Many inputs/executions diagnostics are requested by the laws, but a lot more are done for system robustness. Not gonna talk about HW design and validations. They have their own set of regulations and standard tests to fulfill, which I don't know that good. This is where the car maker takes over from the supplier and does their own set of tests (which I don't know in much detail): - tens/hundreds of thousands of miles on a fleet of vehicles, recording all that happens and future analysis follows - cold trip, hot trip plus various trips to test response to different altitudes, sea side effects etc. - lots of garage testing - regulations tests (the car must respect various regulations of the countries it targets... OBD regulations, CARB, EU stuff, etc.) A lot of other tests are carried out in different phases of production. For example a special SW which runs on the production line is designed to test all circuitry one last time before flashing the real working SW. Too many people have the impression this SW is build "on our knees" (an expression that sounds good in my native language), but this is far beyond that. The threat of car recalls (which is, in the end, charged to the supplier causing it, or the car maker if it is his fault) and fucking up all the profit is not stuff engineering plays with. There are over 1k engineers working on engine ECU R&D in various locations (from system design to SW and tests).
ejdyksen 11y ago
Well, what you're saying is that they wouldn't open source it voluntarily. This is why we have regulations: to make people and companies do things that they wouldn't do voluntarily.
- radiorental 11y ago
  But isn't this analogous to asking Microsoft to open source their OS because of vulnerabilities. I do not disagree with you. These are safety critical systems, I just don't see how companies could be forced to share IP. What is more likely in my view is something similar to the validation standards in aviation: https://en.wikipedia.org/wiki/DO-178B https://en.wikipedia.org/wiki/DO-178B
  - msandford 11y ago
    Yes it is. And if hundreds or thousands of people had died from windows vulnerabilities and tremendous environmental damage had been done, that might well have happened. Most of the security breaches are due to people doing stuff really wrong not just a late patch. And even then I haven't heard of anyone dying as a result yet. People have probably died (if you believe public health stats) as a result of increased NOx production of these vehicles. There's also been a lot more pollution. Big, big pollution problems have caused substantial changes to things, like the creation of the EPA here in the US.
    - gambiting 11y ago
      >>if hundreds or thousands of people had died from windows vulnerabilities and tremendous environmental damage had been done Then people would stop using Windows, simple as that.
      - nmrm2 11y ago
        Just like people stop mining for coal or iron when it causes loss of life and environmental damage? The people being harmed by software vulnerabilities are rarely the people who made an informed decision to use a certain piece of software. People who shop at Target can't meaningfully be said to make a choice to trust Target's software -- it's not something the average consumer things about. So although "should" is an understandable prescription, "would" is a bit unrealistic...
msandford 11y ago
> This is simply not going to happen. It's not going to happen unless legislated. That's the whole point. Currently there is no legislation forcing it to happen, but in the future there might be. That might be a good idea, even if the various companies involved don't want to do it.

Zigurd 11y ago

There are a lot of bad reasons for "closely guarded" IP: 1. The government told you to put spyware in e.g. your mobile baseband processor 2. Your GPU violates a lot of patents 3. You ECU implements dark patterns w.r.t. emissions testing Make regulations requiring publishing the code, and require making the toolchain available to code can be verified vs. the shipped image. Proprietary software isn't a valid excuse when the stakes are to poison the environment.

nmrm2 11y ago

I agree with you -- the push for opening up code to public scrutiny is politically and economically unfeasible. But that doesn't mean nothing can be done -- a more palatable regulatory regime might require oversight a la the aerospace industry, but emphasizing the use of formal methods over expensive and arbitrary process hoop-jumping.

radiorental 11y ago
Agreed, here's what aerospace arrived at (organically too) https://en.wikipedia.org/wiki/DO-178B https://en.wikipedia.org/wiki/DO-178B
- kaftoy 11y ago
  No problem for that. Are you ready to pay to have that? Because stuff like that does not come cheap. Quite sure we can find some numbers on the Internet, probably you are not the first people in the world to think of implementing aerospace regulation in the automotive business :-). I am pretty sure in an industry where saving 12$ / unit (trough some improvement for example) is considered a GIGANTIC gain, applying some super strict aerospace standards will take the car prices to unacceptable levels.
  - nmrm2 11y ago
    Okay, then car companies can open source their ECU (and other safety-critical) software. No one is recommending copy/pasting aerospace regulations. In part because we're now 10-30 years further along in basic and applied CS research than we were when those regs were drafted. What makes aerospace regulations expensive is the process, not the analysis. The attitude that formal methods are completely untenable is painfully sutck in the 1990's. For god's sake, Facebook runs portions of their code base through static analyses, as does Google. If websites are important enough to establish the safety of using formal methods, then the software running are ours sure as hell is. In any case, thing is sure: as software becomes an integral part of high-level safety-critical control decisions, it needs to either be taken seriously by car companies and trusted by the general public. Formal methods and static analysis are the only way we know of for establishing trust in software systems without revealing their source code or relying on black box testing (the downsides of which are demonstrated by both the Toyota UA and VW emissions testing cases). If you know of a third option, then by all means...
    - kaftoy 11y ago
      True, maybe a little bit more openness would not hurt nobody. Probably would help people trust automakers more and not go nuts when a scandal goes live like the VW. Never seen any banks open their strategy to the public after so many of them fucked us over a few years ago. It's not like I can copy their strategy and go make me another bank. But going back to automotive, because that's what I do for a living. The process is quite strict and controlled. Efforts is done and periodic audit is done too to ensure adherence to ASPICE (http://vda-qmc.de/en/software-processes/automotive-spice/ http://vda-qmc.de/en/software-processes/automotive-spice/) and other regulations, including customer audits, which are tough. We do have internal processes, coding (and not only) methods, source control, configuration management (features, bug tracking) across all project and generic development base. The basic workflow is follows a V-cycle path: - receive requirements. - requirements engineering, experts involved; - test design based on requirements; - internal design of whatever kind (models etc.); - design reviews, simulations (if models), all kind of analysis; - implementation (if not code generation); - code reviews; - static analysis ((pc-)lint, klocwork to name a few); - module tests (unitary tests (ptu), tests on the HW with simulated signals - aka tetsbench tests); - integration tests; - system validation tests (requirements tests), hardware-in-the-loop tests, close loop tests; - dependability tests run on the car. In parallel the system is calibrated and calibrations are used during validations. For every version going into production (because some are just interim steps for validation purpose), there's a lot of testing going on on features already tested before. SW execution is monitored by SW. The micro is monitored in some interesting ways and on top of that an IC is monitoring all the... other monitors. Lots of stuff is done to ensure RAM/ROM consistency, process execution monitoring, signal acquisition plausibility. Many inputs/executions diagnostics are requested by the laws, but a lot more are done for system robustness. Not gonna talk about HW design and validations. They have their own set of regulations and standard tests to fulfill, which I don't know that good. This is where the car maker takes over from the supplier and does their own set of tests (which I don't know in much detail): - tens/hundreds of thousands of miles on a fleet of vehicles, recording all that happens and future analysis follows - cold trip, hot trip plus various trips to test response to different altitudes, sea side effects etc. - lots of garage testing - regulations tests (the car must respect various regulations of the countries it targets... OBD regulations, CARB, EU stuff, etc.) A lot of other tests are carried out in different phases of production. For example a special SW which runs on the production line is designed to test all circuitry one last time before flashing the real working SW. Too many people have the impression this SW is build "on our knees" (an expression that sounds good in my native language), but this is far beyond that. The threat of car recalls (which is, in the end, charged to the supplier causing it, or the car maker if it is his fault) and fucking up all the profit is not stuff engineering plays with. There are over 1k engineers working on engine ECU R&D in various locations (from system design to SW and tests).

ejdyksen 11y ago

Well, what you're saying is that they wouldn't open source it voluntarily. This is why we have regulations: to make people and companies do things that they wouldn't do voluntarily.

radiorental 11y ago
But isn't this analogous to asking Microsoft to open source their OS because of vulnerabilities. I do not disagree with you. These are safety critical systems, I just don't see how companies could be forced to share IP. What is more likely in my view is something similar to the validation standards in aviation: https://en.wikipedia.org/wiki/DO-178B https://en.wikipedia.org/wiki/DO-178B
- msandford 11y ago
  Yes it is. And if hundreds or thousands of people had died from windows vulnerabilities and tremendous environmental damage had been done, that might well have happened. Most of the security breaches are due to people doing stuff really wrong not just a late patch. And even then I haven't heard of anyone dying as a result yet. People have probably died (if you believe public health stats) as a result of increased NOx production of these vehicles. There's also been a lot more pollution. Big, big pollution problems have caused substantial changes to things, like the creation of the EPA here in the US.
  - gambiting 11y ago
    >>if hundreds or thousands of people had died from windows vulnerabilities and tremendous environmental damage had been done Then people would stop using Windows, simple as that.
    - nmrm2 11y ago
      Just like people stop mining for coal or iron when it causes loss of life and environmental damage? The people being harmed by software vulnerabilities are rarely the people who made an informed decision to use a certain piece of software. People who shop at Target can't meaningfully be said to make a choice to trust Target's software -- it's not something the average consumer things about. So although "should" is an understandable prescription, "would" is a bit unrealistic...

msandford 11y ago

> This is simply not going to happen. It's not going to happen unless legislated. That's the whole point. Currently there is no legislation forcing it to happen, but in the future there might be. That might be a good idea, even if the various companies involved don't want to do it.