Re: [SystemSafety] Language issues, control systems

From: RICQUE Bertrand (SAGEM DEFENSE SECURITE) < >
Date: Mon, 27 Apr 2015 17:25:00 +0200


From an IEC 61508, I see inserting HIM and humans in the safety function as something that would be close from an extrapolation. At high SIL requirements (>=3), it would be a very, very, complicated and expensive extrapolation. It is not even granted that it would be possible to achieve something.

I got in the past an application in a large French city. It was after the disaster of the Mont-Blanc tunnel. They wanted to equip the tunnels of this city with PCs in the control room to lower barriers at the entrances and to turn on red lights to avoid vehicles entering in the tunnel in case of an accident. They wanted the PCs and the application to be SIL3 (initially SIL4). The supplier sold it and they bought it. I don’t even think it complies to SIL-15…

Bertrand Ricque
Program Manager
Optronics and Defence Division
Sights Program
Mob : +33 6 87 47 84 64
Tel : +33 1 58 11 96 82
Bertrand.ricque_at_xxxxxx

From: systemsafety-bounces_at_xxxxxx Sent: Monday, April 27, 2015 4:19 PM
To: Peter Bernard Ladkin
Cc: systemsafety_at_xxxxxx Subject: Re: [SystemSafety] Language issues, control systems

Or to put things simply: Imagine you are developing a product in England for a client in "anywhere" (Russia, France, China, anywhere) and this client wants the system to be usable by human operators both in English and in the native language of the country. How do you deal with the Safety issues of the translation of the HMI? How is this usually done? Is there a standard/accepted way?

Regards,

Myriam.

2015-04-27 16:04 GMT+02:00 M Mencke <menckem_at_xxxxxx Just to clarify another point, when I say "translator", I am referring to a human translator (somehow I doubt if the results of automatic translation software would be sufficient for HMI commands).

2015-04-27 15:55 GMT+02:00 M Mencke <menckem_at_xxxxxx Hi Peter,

Regarding your last point, it is assumed that there are no ambiguities in the source phrases, as they have been written by native speakers familiar with the system and its intended operating environment, or they could be proven in use. Whether they are ambiguous or the "best choice" for representing the command unambiguously to the human operator would be a different issue to examine in the human factor studies, as this is an issue which can be applied to analyse commands in a single language.

Assuming that the source phrases are correct (whether or not they are optimal is a separate issue), if you examine ambiguities in the output phrases, I think it could reduce the level of error. For example, if both translators translate the same phrase in the source language to different phrases in the output language (say "hold train" and "stop train" or similar), it would be necessary for them to discuss/research it or request outside help for every case, until a consensus is reached. This does not seem to be an optimal solution, which is why I'm interested in knowing how this problem is usually dealt with.

Just to clarify, I am referring to natural languages, not programming languages.

Kind regards,

Myriam.

> Would it be valid, for example, to use two translators and then cross-check the resulting
> translations, analyzing inconsistencies?

You could do that, but it wouldn't help where there were ambiguities in either the source phrases or the output phrases.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Myriam,

On 2015-04-27 11:51 , M Mencke wrote:
> I was wondering if anybody has any experience with SIL certifications where the final product
> should be usable [by a human operator] in two different [natural] languages.

That's an interesting issue.

In IEC 61508-type system conceptions, it is safety functions that are assigned SILs. The HW associated with executing that safety function gets a reliability condition for "random" failures, and the SW gets a list of "recommended techniques" for its development, and who knows whether the unit as a whole fulfils its given reliability condition thereby. Any human reliability condition, that, say, an HMI is read correctly, is not addressed as far as I see in any part.

There is a working group, IEC SC65A WG17, that convenes to discuss and develop human-factors conditions associated with functional safety, and I think this would be one. I don't know whether they are addressing it yet, but at least one of the members, Karsten Loer, is on this list, so I imagine he could raise it.

> ..... My question is if there are any potential hazards associated with an incorrect
> translation, what would be the best way to go about mitigating them?

It depends on how the translations are generated. If they are fixed phrases (ASCII in memory, say) and any are incorrect, that would be a systematic error. Best mitigation would be to check that all the phrases are right after implementation and before deployment. If the phrases are dynamically generated, given particular sensor input, then the translator itself is a piece of SW and surely the best mitigation would be to ensure that it is correct by construction during implementation.

> Would it be valid, for example, to use two translators and then cross-check the resulting
> translations, analyzing inconsistencies?

You could do that, but it wouldn't help where there were ambiguities in either the source phrases or the output phrases.

PBL Prof. Peter Bernard Ladkin, Faculty of Technology, University of Bielefeld, 33594 Bielefeld, Germany Je suis Charlie
Tel+msg +49 (0)521 880 7319<tel:%2B49%20%280%29521%20880%207319> www.rvs.uni-bielefeld.de>

-----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJVPjWkAAoJEIZIHiXiz9k+pUcH/1CrV6Oky25UnY2DK107aE3r Ixzxhr/gyd5343NIZAbzXTjJFv+lPeZzFnIat/vffXx5Wci2uvvlGljEtp8SqGvk xnNj+qttToj+fbubx6+5WIjIal3tocCDs1OnI4csm82tm/zFekqiYu4ZpNs1vC1o RvdW9kSplqCK0+wCTrqkLw/Z46uEbEiu1FYifnxdS2JhMz76397zwtJNyq3JYXgz 2Yr7mZLq5nLyCXd5/4gIPtS4fmX0BwiL32Xi0y8FytHUalrrCyn31phdGhVgy5hD J52S0gCbxkrnHgm3PmadRUi/hKM1TsXTdi8RBwyUW0l1+Z+3gF1v9OTfenL3sb8= =b9U2
-----END PGP SIGNATURE-----



The System Safety Mailing List
systemsafety_at_xxxxxx

#
" Ce courriel et les documents qui lui sont joints peuvent contenir des informations confidentielles, être soumis aux règlementations relatives au contrôle des exportations ou ayant un caractère privé. S'ils ne vous sont pas destinés, nous vous signalons qu'il est strictement interdit de les divulguer, de les reproduire ou d'en utiliser de quelque manière que ce soit le contenu. Toute exportation ou réexportation non autorisée est interdite Si ce message vous a été transmis par erreur, merci d'en informer l'expéditeur et de supprimer immédiatement de votre système informatique ce courriel ainsi que tous les documents qui y sont attachés."



" This e-mail and any attached documents may contain confidential or proprietary information and may be subject to export control laws and regulations. If you are not the intended recipient, you are notified that any dissemination, copying of this e-mail and any attachments thereto or use of their contents by any means whatsoever is strictly prohibited. Unauthorized export or re-export is prohibited. If you have received this e-mail in error, please advise the sender immediately and delete this e-mail and all attached documents from your computer system." #


The System Safety Mailing List
systemsafety_at_xxxxxx Received on Mon Apr 27 2015 - 17:25:11 CEST

This archive was generated by hypermail 2.3.0 : Fri Apr 26 2019 - 06:17:07 CEST