3 ms·

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 m

by 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).

by nmrm2 11y ago

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).