Re: [sc] Reminder about the "Embedded Muse"



Re: [sc] Reminder about the "Embedded Muse"

From: M Mencke <menckem_at_xxxxxx>
Date: Sat, 19 Mar 2011 20:55:14 +0100
Message-ID: <AANLkTinKRy4Fc3Wpwt1Zvf6Dzoh1U2zKT5uGUAN4s3jQ@xxxxxx>
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.

Kind Regards,

Myriam Mencke.


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
> constructs."
>
> 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
>> can
>> 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
>> as
>> 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.
>
>
> PBL
>
> Peter Bernard Ladkin, Professor of Computer Networks and Distributed
> Systems,
> Faculty of Technology, University of Bielefeld, 33594 Bielefeld, Germany
> Tel+msg +49 (0)521 880 7319  www.rvs.uni-bielefeld.de
>
>
>
>
>

Content-Type: text/plain
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