[SystemSafety] Language issues, control systems
RICQUE Bertrand (SAGEM DEFENSE SECURITE)
bertrand.ricque at sagem.com
Mon Apr 27 17:25:00 CEST 2015
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 sagem.com
From: systemsafety-bounces at lists.techfak.uni-bielefeld.de [mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de] On Behalf Of M Mencke
Sent: Monday, April 27, 2015 4:19 PM
To: Peter Bernard Ladkin
Cc: systemsafety at lists.techfak.uni-bielefeld.de
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 gmail.com<mailto:menckem at gmail.com>>:
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 gmail.com<mailto:menckem at gmail.com>>:
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.
2015-04-27 15:12 GMT+02:00 Peter Bernard Ladkin <ladkin at rvs.uni-bielefeld.de<mailto:ladkin at rvs.uni-bielefeld.de>>:
-----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<http://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 TechFak.Uni-Bielefeld.DE<mailto:systemsafety at TechFak.Uni-Bielefeld.DE>
#
" 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."
#
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20150427/f272632d/attachment-0001.html>
More information about the systemsafety
mailing list