D for safety critical applications

Gregor Mückl gregormueckl at gmx.de
Tue Feb 9 16:58:35 UTC 2021

On Tuesday, 9 February 2021 at 15:37:42 UTC, FeepingCreature 
> On Tuesday, 9 February 2021 at 15:10:55 UTC, Dominikus Dittes 
> Scherkl wrote:
>> I know, here are a lot of people that have very little trust 
>> in thoughts that someone else put into something, but it's 
>> their choice: use something certified or spent a lot of time 
>> to prove it yourself.
>> If you proof it yourself anyway, a certificate maybe really 
>> useless for you.
> I don't see how a certificate relieves you of the 
> responsibility to consider the safety and quality of your tools 
> yourself.
> You use a certified compiler. The certified compiler produces a 
> bug. As a result, a product that you released doesn't work. 
> Does that mean that it isn't your problem? No, of course it 
> doesn't! It's still 100% on you to fix it. With that said, I 
> don't understand what you are paying for. Are you paying for 
> the vendor to think about security? But why would you want to 
> use a tool from a vendor who doesn't think about security to 
> begin with? One way or another, the buck stops with you, not 
> the vendor.

I think there is a slight misconception in this thread that the 
certification is for the end product only when it is focused a 
lot on the processes that result in it. That also means that the 
vendor providing a certified product is under certain 
obligations. One of them is enabling the user of the tool to use 
it properly (e.g. a safety manual), another one is an obligation 
to manage defects. AFAIK this involves a process for notifying 
customers of critical bugs.

Nitpick: safety != security. Safety in this context means that 
the resulting product does not experience silent or undetected 
malfunctions. Security is resilience towards dedicated attacks on 
a system. These are different things, even though they overlap to 
some degree.

The reality is that a lot of ISO 61508 compliant environments are 
safe (i.e. the factory *will* shut down safely if things break), 
but terribly insecure (a hacker can take over and mess with tons 
of parameters).

> It's not that if you consider the safety and security of your 
> tools yourself, the certificate is useless for you. It's that 
> you have to consider the safety and security of your tools 
> *whether or not* they're certified.

This. You need to invest considerable time and effort to 
establish processes and toolchains that are compliant. A tool 
certificate is no good if the processes around it are not 
compliant. There are many ways in which you can be non-compliant 
with a compliant toolchain. The impact of a certificate on your 
own processes is simply that tool qualification has already 
happened elsewhere.

More information about the Digitalmars-d mailing list