[SystemSafety] The limits of safe code reuse

Daniel Grivicic grivsta at gmail.com
Fri Sep 13 09:51:35 CEST 2019


Hello Folks,

I am interested in understanding the limits of software reuse for critical
systems. My application is rail, however, I am very open to understanding
reuse in other disciplines.

Reuse of software is usually not good. Certainly recent discussions have
suggested this. Where is the line for reuse drawn? For example, native
elements are always reused - an IF statement is native and reused in new
applications. I don't re-invent the wheel and develop these native
elements. I reuse them.

If I build a large application (in any language) and try to modularise
this, I may be inclined to reuse these modules/routines/objects in other
subtly or vastly different applications in the future. Such reuse can be
problematic. With solid development control, outcomes of the program in a
new (different) application can be favourable (errors will be limited). Is
there a maximum level of analysed code complexity where an alarm should be
raised when this programmed module is reused?

Further, if I build a function using a full variability language and
package this function within a limited variability package (taking the
definitions of full and limited variability from, say IEC 61508) can this
new function that is now considered a limited variability function be safe
(possibly a loaded word) to use? I can't see inside it to know (eg code
protection is enabled).

If I extend this idea further, a large multinational can develop the
functions and this large multinational pays an independent assessor to
validate the function. I then buy these functions to reuse them in my new
application. Code reuse occurs but is it considered code reuse as I
purchased the functions? I am not reusing them I am 'just' using them.

Thank you for your time and I am really interested in understanding where
these limits may be. Any references or further reading is appreciated.

Cheers,

Daniel.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20190913/97378ae2/attachment.html>


More information about the systemsafety mailing list