Content-Type: text/plain; charset=ISO-8859-1
Thank you for your opinions [Kevin + Peter]. Looks like there are a lot more
points to take into account than I initially thought. I'll analyse and
discuss your points with some colleagues before taking any further steps.
On 19 March 2011 18:45, Peter Bernard Ladkin <ladkin@xxxxxx>wrote:
> On 3/19/11 4:35 PM, M Mencke wrote:
>> For the moment I think the best thing to do would be to follow the ESA
>> guidelines in order to comply with the EN 50128, as this standard permits
>> the use of other languages (Table A. 15, and Section B.62) as long as
>> evidence can be shown of a number of features such as providing for block
>> structure, translation time checking, parameter checking, etc. And by
>> complying with the ESA guidelines, these features will be included.
> I don't have the current valid version of EN 50128, but I have access to a
> draft of the upcoming version from 2010. Java is indeed in the list in Table
> A.15 of textual programming languages. In clause D.54, which is specifically
> referenced for Java in Table A.15, as "Recommended" for SIL 2 (but not
> "Highly Recommended"). There are four specific features which "the language
> should provide for". Three of them you named, block structure, translation
> time checking, parameter checking, and the fourth is "run time type and
> array bound checking".
> Does Java have run time type and array bound checking?
> The standard also specifically refers to subsetting for Java (clause D.35),
> "The language is examined to identify programming constructs which are
> either error-prone or difficult to analyse, for example, using static
> analysis methods. A language subset is then defined which excludes these
> So the standard is also expecting you to exclude Java constructs which "are
> difficult to analyse, for example, using static analysis methods".
> I don't know whether the situation is the same or similar with the valid
> version of EN 50128, but it looks to me as though the situation is not quite
> as simple as you are hoping it will be. It looks as though you will need to
> ensure your Java code is statically analysable. I am not so sure that is so
> easy :-)
> I might point out that the same requirements apply to C. However, there are
> plenty of used and usable C static analysers around, some of which I
> understand are quite good.
> Additionally, if vendor specific solutions are required, implement
>> them. A later step could be to make it compatible with JSR 302 but that
>> only be done when the draft is completed.
> If you have code which works, and which has already passed assessment
> against EN 50128, why would you want to spend resources rewriting it in
> another dialect and then requalifying it?
> My main concern was that we write the code according to a standard which
>> ensures compliance with EN 50128 for a railway system which has SIL 2
>> functions (if it is good enough to be a SIL 4, even better).
> To me, that looks as if it will not be very easy if you do it in Java.
> .... we would automatically
>> comply with the [new version of the] standard if we used Java + coding
>> guidelines, as in this
>> version, Java already appears in Table A.14 Textual Programming Languages
>> a "Recommended" language for SIL 0 - SIL 4 systems.
> I think you would have to do a lot more than just use "Java + coding
> guidelines" if you want to comply with the standard. Compliance is also not
> "automatic", for you don't get run-time type and array bound checking
> automatically just by using Java + coding guidelines, nor do you necessarily
> get code you can statically analyse.
> Peter Bernard Ladkin, Professor of Computer Networks and Distributed
> Faculty of Technology, University of Bielefeld, 33594 Bielefeld, Germany
> Tel+msg +49 (0)521 880 7319 www.rvs.uni-bielefeld.de
X-Original-Content-Type: text/html; charset=ISO-8859-1
[The content of this part has been removed by the mailing list software]
Received on Sat 19 Mar 2011 - 19:55:24 GMT