[SystemSafety] The limits of safe code reuse

[paul_e.bennett at topmail.co.uk]

On 13/09/2019 at 8:52 AM, "Daniel Grivicic" <grivsta at gmail.com> wrote:
>
>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.

As one who has worked in your sector and many others besides, I have
re-used software modules quite often. Especially when I get my choice
of programming and development environment. 

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

It is good you recognise the difficulties from the outset.  You should
always be asking yourself 'how much do I trust this module'

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

First of all, your development environment should be very well controlled
and backed by a secure repository to contain the already known good
modules that you can re-use with only a check that they were teh good
choice for the new application (part of the selection review).

Secondly, ensure that you have a rock solid review and test regime that
is very stringent about the acceptance of new modules into that secure
repository.

Choose programming environments that fully support the composition
inspection and testing of modules individually with minimal reliance on
test stubs (whiuch if used should be included with the module source
and identified as the approved test.

Document all modules in your repository and keep that documentation
as a sort of catalogue of what you have there, so that selection of
modules becomes easier. Much like selecting hardware electronic
components.

If any of the modules you use are from COTS sources, perform checks
much like you would on expected high quality 'goods inwards' and
review the provided back-up documentation, any certifications and 
run your own acceptance testing with a review of the results before
you accept them. Of course, the bigger the COTS package, the more
gargantuan the inspection, test and review effort will become.

Regards

Paul E. Bennett IEng MIET
Systems Engineer
Lunar Mission One Ambassador
-- 
********************************************************************
Paul E. Bennett IEng MIET.....
Forth based HIDECS Consultancy.............
Mob: +44 (0)7811-639972
Tel: Due to relocation - new number TBA. Please use Mobile.
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************