3 ms·

As someone who has had a bit to do with safety critical software in agricultural machinery, and I am sure to any one in any other regulated industry this sounds

by nodnyl 8y ago

As someone who has had a bit to do with safety critical software in agricultural machinery, and I am sure to any one in any other regulated industry this sounds crazy. The regulation in many industries for software that can kill is onerous, python on Android for any safety related code in other industries would be the punch line of a joke.

blub 8y ago
To clarify (as a safety hobbyist) why this is a problem: * consumer hardware does not normally fulfil automotive safety requirements. It could for instance go into thermal shutdown or into a degraded mode if the temperature is too high. Additionally, there is no HW redundancy, I assume that if any of the HW components of the smartphone fail, the system cannot continue to maintain its safety properties. * Android is a consumer OS, designed for consumer workloads. A real-time, safety certified OS like INTEGRITY, ThreadX, Nucleus etc should be typically used for such workloads. * The safety-relevant software running on top of the OS is developed with specific toolchains and using specific programming languages. Some requirements [1] for a language used in safety-critical context are defined behaviour, explicit dependability support (e.g. design by contract), predictable timing, suitability for static verification, significant field use, strong typing (not necessarily static typing!), feasibility to restrict the language to a subset (e.g. MISRA, JSF, etc). One of the most popular languages for such software is C, which is not safe and doesn't fulfil several of the above criteria. This is mitigated through tooling, processes, code generation, design validation & verification and so on. [1]: Taken from Embedded Software Development for Safety-Critical Systems, Hobbs. Interestingly the author would personally choose D or Rust for safety-critical development with the condition of having enough confidence in the compilers.
dozzie 8y ago
> [...] to any one in any other regulated industry this sounds crazy. This sounds crazy even to a person who makes living from running software on commodity hardware (x86/x86_64). Android does not sound like a hard real-time OS. I've seen it hang up in a fsckin' coffee machine! I don't want it at the center of two tons of steel that move 100km per hour.

by nodnyl 8y ago

blub 8y ago

To clarify (as a safety hobbyist) why this is a problem: * consumer hardware does not normally fulfil automotive safety requirements. It could for instance go into thermal shutdown or into a degraded mode if the temperature is too high. Additionally, there is no HW redundancy, I assume that if any of the HW components of the smartphone fail, the system cannot continue to maintain its safety properties. * Android is a consumer OS, designed for consumer workloads. A real-time, safety certified OS like INTEGRITY, ThreadX, Nucleus etc should be typically used for such workloads. * The safety-relevant software running on top of the OS is developed with specific toolchains and using specific programming languages. Some requirements [1] for a language used in safety-critical context are defined behaviour, explicit dependability support (e.g. design by contract), predictable timing, suitability for static verification, significant field use, strong typing (not necessarily static typing!), feasibility to restrict the language to a subset (e.g. MISRA, JSF, etc). One of the most popular languages for such software is C, which is not safe and doesn't fulfil several of the above criteria. This is mitigated through tooling, processes, code generation, design validation & verification and so on. [1]: Taken from Embedded Software Development for Safety-Critical Systems, Hobbs. Interestingly the author would personally choose D or Rust for safety-critical development with the condition of having enough confidence in the compilers.

dozzie 8y ago

> [...] to any one in any other regulated industry this sounds crazy. This sounds crazy even to a person who makes living from running software on commodity hardware (x86/x86_64). Android does not sound like a hard real-time OS. I've seen it hang up in a fsckin' coffee machine! I don't want it at the center of two tons of steel that move 100km per hour.