[SystemSafety] Language issues, control systems

M Mencke menckem at gmail.com
Mon Apr 27 15:55:45 CEST 2015


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

> -----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 TechFak.Uni-Bielefeld.DE
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20150427/3521be8f/attachment.html>


More information about the systemsafety mailing list