5 ms·
There are many levels of certification. This project is in Central Europe. A different team uses it in satellite micro controllers in the US, but I am not invo
by volta83 5y ago
There are many levels of certification.
This project is in Central Europe.
A different team uses it in satellite micro controllers in the US, but I am not involved with that.
I don't know of any safety certification process that requires the programming language to have an ISO standard specification.
- pjmlp 5y agoThanks for sharing, I don't mean that they have, more from burocratic point of view, like checklists in RFPs, given conformance with stuff like these https://www.highintegritysystems.com https://www.highintegritysystems.com > Supports IEC 61508, IEC 62304, FDA 510K Hence why imagine Rust might need some kind of good for high integrity computing stamp, be it ISO, ECMA, or something else.
- volta83 5y agoI think what's useful would be to have someone certify the Rust toolchain for some of these. That's what's needed to enable anyone to develop safety critical apps without issues. The problem is that most certification consultancies don't allow you to publish a certification such that everyone can use it. That puts them out of work. The ones that have already certified Rust, make an upfront investment in the certification, and then can certify more users for a lot of money and little effort. Having said this, for pretty much any project, you are going to deal with some of these certification entities anyways (the programming languages used are just a small part of the whole thing). I don't think Rust is cheaper or more expensive than the alternatives for these types of apps. Customer RFPs can ask for anything. If they want it in C++, then that's how it is. Some RFPs actually explicitly ask for Rust nowadays (no C, no C++). But some RFPs ask for FORTH, or assembly, or don't really care at all about the language used. The customer needs to have people trained to "verify" the product that they are getting. If their people only know MISRA C, then that's what they are going to want, and none of this has anything to do with the actual technical pros/cons of any language; it's just a more complex social and engineering thing.
- pjmlp 5y agoI see, thanks.
- steveklabnik 5y agoThank you for bringing this expertise to this thread. I hope more folks learn about the ways these parts of the industry works.
- bregma 5y agoPart of the safety story for compliance with standards like ISO 61508 and ISO 26262 is that you can demonstrate your toolchain had been validated and verified against something. In the case of C or C++, that usually means (among other things) demonstrating compliance with an accepted published standard like ISO 8859 or ISO 14882, and that is usually done through extensive testing with one or more audited and widely-acknowledged conformance test suites. In the case of Rust, that would be "the standard is what the compiler does, so the compiler is by definition 100% conformant." Trivially true, but it will be a challenge to convince your auditors that that is a reasonable safety story. Liability is high when lives are at stake. This stuff is taken very seriously.
- volta83 5y ago> In the case of C or C++, that usually means (among other things) demonstrating compliance with an accepted published standard like ISO 8859 or ISO 14882 Notice that the C++ standard has dozens of open bugs, some of them are actually due to incompatibilities within the standard itself, e.g., because it require implementations to comply to two different things simultaneously, but these are incompatible with each other. So in practice, it is impossible for any C++ compiler to actually comply to the spec. So at the end the only thing any process ends up looking at, is that your compiler has lots of tests, and the process of developing it: do all tests have to pass before each release? etc. Once such a test suite is verified, it becomes somethings others can use to say "my compiler passes it", but in practice, these test suites have bugs, and the test suites of gcc and clang are more comprehensive etc. Even if your compiler passes one such test suite, it won't pass certification if you don't have version control, testing running regularly, etc. The rust compiler has a huge test suite. Every single change to the compiler must pass the test suite on some of the supported architectures, new releases of the compiler are tested against all the tests of the 40.000 libraries available in crates.io to make sure results don't change in code people actually write, etc. > Trivially true, but it will be a challenge to convince your auditors that that is a reasonable safety story. This has been trivial to do in our experience. Just pay the fees. The standard at which the Rust toolchain development operates is much higher than what the highest safety certifications require, because the safety of these certifications is actually very low: their whole purpose is to avoid liability, so most of them are just a way to create a paper trail that shows that your process is not complete trash, so that if someone sues you, you can say that you were operating at the highest standards. Nothing more, nothing less. Nobody is interested in making these standards "good", that's not their purpose. Practically, the only issue is that some certifications require you to certify every toolchain you want to use. So if you bump the stable Rust toolchain version from say 1.49 to 1.50, you need to re-certify. The process for recertifying is quick, since nothing covered during the certification process actually changed, but you have to pay the fees again and again and again. I think this is braindead, but AFAIK all compilers for all languages have this problem.
- myrrlyn 5y ago(there are none)