Re: [SystemSafety] Language issues, control systems

From: M Mencke < >
Date: Mon, 27 Apr 2015 15:55:45 +0200


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

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



The System Safety Mailing List
systemsafety_at_xxxxxx Received on Mon Apr 27 2015 - 15:55:54 CEST

This archive was generated by hypermail 2.3.0 : Tue Jun 04 2019 - 21:17:07 CEST