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.
>>
>> 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 - 16:19:13 CEST
This archive was generated by hypermail 2.3.0 : Thu Apr 25 2019 - 04:17:07 CEST