[SystemSafety] Language issues, control systems

M Mencke menckem at gmail.com
Mon Apr 27 16:04:22 CEST 2015


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

> 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/9ae53e62/attachment-0001.html>


More information about the systemsafety mailing list