[SystemSafety] The limits of safe code reuse

[Peter Bishop]

Yes this is the "rely-guarantee" concept
-the module relies on specified preconditions
-if met the module behaviour is guaranteed to meet its spec.

Although the "guarantee" can be a tough ask.

With regard to what would be a re-usable function, I would say it needs
to be generic,
i.e. unrelated to any specific application.

So function blocks in a PLC style language (PID, FILTER, DELAY) are
obvious candidates
They are widely re-used in a whole range of different applications
and the function preconditions can in principle be imposed by the PLC
application compiler.

Ditto NAG numerical library functions, and typical C library functions,
- but preconditions might not always be available.

More complex generic functions like a SQL server could in principle qualify
but specifying and checking preconditions becomes much more difficult.

Best regards

Peter

On 13/09/2019 10:39, MESSER Robin wrote:
>
> With regards to the statement, “reuse of software is usually not
> good”. It can be good, provided you have a precise and complete
> specification of what the thing being reused does (not how it does it)
> including the interface and any preconditions that must be respected.
> That’s not ‘usually’ available, but if it is then you can benefit from
> not spending effort on developing the same component twice.
>
>  
>
> Robin
>
>  
>
> *From:*systemsafety
> <systemsafety-bounces at lists.techfak.uni-bielefeld.de> *On Behalf Of
> *Daniel Grivicic
> *Sent:* 13 September 2019 08:52
> *To:* systemsafety at lists.techfak.uni-bielefeld.de
> *Subject:* [SystemSafety] The limits of safe code reuse
>
>  
>
> 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. 
>
>
> _______________________________________________
> The System Safety Mailing List
> systemsafety at TechFak.Uni-Bielefeld.DE
> Manage your subscription: https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety

-- 

Peter Bishop
Chief Scientist
Adelard LLP
24 Waterside, 44-48 Wharf Road, London N1 7UX

Email: pgb at adelard.com
Tel:  +44-(0)20-7832 5850

Registered office: 5th Floor, Ashford Commercial Quarter, 1 Dover Place, Ashford, Kent TN23 1FB
Registered in England & Wales no. OC 304551. VAT no. 454 489808

This e-mail, and any attachments, is confidential and for the use of
the addressee only. If you are not the intended recipient, please
telephone 020 7832 5850. We do not accept legal responsibility for
this e-mail or any viruses.

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