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
wrote:
> 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