D for safety critical applications

Imperatorn johan_forsberg_86 at hotmail.com
Tue Feb 9 19:59:02 UTC 2021

On Tuesday, 9 February 2021 at 16:58:35 UTC, Gregor Mückl wrote:
> 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.

Correct. Safety and security are not really related. And even 
under the word safety there are different kinds of safety. For 
example the definition of a safe state is very different in 
different environments. For example in the nuclear sector some 
doors must *open* on failure while in some other sector they must 

Also in the mobile sector (I've worked as a control systems 
developer for harvester heads) the definition of a safe state can 
be both to freeze all valves etc, but also to release all energy 
of the system depending on various factors (PLD cat3 iirc in that 

So it's a complex topic that's for sure 😁

Today I work as a systems architect on a radio remote control 
company and safety is (unsurprisingly) important ofc.

I'm not really sure we need a certified compiler (although we 
currently have one for certain products). We have a dialog w most 
certification "institutions" and tbh some times I'd say we know 
better then they do what is really safe (depends ofc). There are 
also other techniques like black channel/box etc etc but that's 
another topic.

I'm writing on the phone atm, I can elaborate on what our 
requirements would be later. But one reason I looked into D in 
the first place was actually @safe and the things Walter talked 

I have hope for D being useful for us.

More information about the Digitalmars-d mailing list