Reuse

Adopting OSS/FOSS (Open Source / Free Open Source) software

it is analogue to reuse of proprietary software.

Reuse - Risks

Risks

Safety- damage to human beings- damage to things- economical damage for the user/client- economical loss for the entity that reused the software to create

its application

Security- code is known, easier to find security flows but also to hack- malicious code inserted during development

Historical cases of damage & reuse of software

Therac 25irradiation machine for oncology

Killed 6 patients and injured some others.

Software from a previous model was reused in connection to new hardware and substitution of a mechanical control/safety lock with a new software module plus other software design and code issues

There are other cases related to software involved in radiation therapy causing damage.

They come to attention because it is the medical field, Radiation is strictly regulated and the International Atomic Agency is involved in Quality and Controls

Historical cases of damage & reuseAriane 5 ESA rocket reused software of Ariane 4

On 4 June 1996, the maiden flight of the Ariane 5 launcher ended in a failure. Only about 40 seconds, at an altitude of about 3700 m, the launcher veered off its flight path, broke up and exploded.

This was caused by an exception during data conversion from 64-bit floating point to 16-bit signed integer value. The floating point number which was converted had a value greater than what could be represented by a 16-bit signed integer. This resulted in an Operand Error.

The specification stipulated that in the event of any detected exception the processor was to be stopped. The exception which occurred was not due to random failure but a design error.

Historical cases of damage in relation to reuse

Ariane 5

Risks in reuse of software

Reusing software will it work fine ?

Use with new/upgraded/additional hardware....

Use with new /updated/additional software....

Use in new environment/context

Different users

It is uncertain also when previous SW was tested/certified

Software may need new certification/ testing when you reuse it, this holds also for certified components

Reuse readiness level

NASA developed a Reuse Readiness Levels (RRLs) framework based on the following categories:

a. Documentation: Information which describes the asset and how to use it.

b. Extensibility: The ability to modify/adapt an asset beyond its current scope

c. Intellectual Property Issues: Do we have the license to reuse the software asset?

d. Modularity: The degree of separation and independence of the reusable asset from other

assets

e. Packaging: The packaging of a reusable asset as an independent whole that can be

distributed and installed as a unit

f. Portability: The ability to reuse an asset in multiple platforms

g. Standards Compliance: The conformance of the asset to established tech. standards

h. Support: availability for the maintenance, evolution, extension and problem

assistance

i. Verification and Testing: The degree to which the asset has been tested and its

functionality and quality are verified.

Reuse readiness level

NASA Reuse Readiness Levels (RRLs) for standards compliance.

RRL-1: No standards compliance

RRL-2: No standards compliance beyond best practices

RRl-3: Some compliance with local standards and best practices

RRL-4: Standards compliance, but incomplete and untested

RRL-5: Standards compliance with some testing

RRL-6: Verified standards compliance with proprietary standards

RRL-7: Verified standards compliance with open standards

RRL-8: Verified standards compliance with recognized standards

RRL-9: Independently verified standards compliance with recognized standards.

Reuse readiness level

NASA Reuse Readiness Levels (RRLs).RRL 1 – Limited reusability; the software is not recommended for reuse.

RRL 2 – Initial reusability; software reuse is not practical.

RRL 3 – Basic reusability; the software might be reusable by skilled users at substantial effort, cost, and

risk.

RRL 4 – Reuse is possible; the software might be reused by most users with some effort, cost, and risk.

RRL 5 – Reuse is practical; the software could be reused by most users with reasonable cost and risk.

RRL 6 – Software is reusable; the software can be reused by most users although there may be some

cost and risk.

RRL 7 – Software is highly reusable; the software can be reused by most users with minimum cost and

risk.

RRL 8 – Demonstrated local reusability; the software has been reused by multiple users.

RRL 9 – Demonstrated extensive reusability; the software is being reused by many classes of users over

a wide range of systems

Model of reuse for OSS/FOSS

Black box the OSS/FOSS is used as it is, or minor modifications

Grey boxModifications of the code at interface level and/or involve but a small

portion of the source code. A study and in-depth understanding of the code may be required, so far involving a considerable investment

White boxthe OSS/FOSS is studied, to implement new developments, adaptations,

customizations and bug fixes, mix with proprietary software, mix with other OSS/FOSS with other license.

Assessment for reuse of OSS/FOSSOther issues to be considered:

MaintainabilityCompatibility with the existing technology and skillsScalabilityPortabilityTransferabilityFunctionality, with respect to the new user/environment/product needs Security, availability and robustnessFlexibility of interfaces and possibility to upgradeEase of installation and upgrade Interoperability and ability to run on sundry operating systemsInteroperability and ability to run on sundry hardware Development DocumentationNon executable codeQuality parametersReliability, maturity and robustness

How does OSS/FOSS? Evolve?

It dies (no more upgrades, updates)

It changes licensing scheme

Forking - orphanage

It flourishes

The core developer group evolves to commercial/ICT enterprise

How evolves OSS/FOSS?

Previous EU projects OSS quality & reuse

None of these projects considered robotics

OPENCOSS http://www.opencoss-project.eu/

to produce the first European-wide open safety certification platform for the railway, avionics and automotive markets

OPEN-SME http://opensme.eu/project

Processes for Open-Source Software Reuse

FLOSSMETRICS http://www.flossmetrics.org/

database with information and metrics about OSS/FOSS

Possible Proposal

To create a Topical group in euRobotics aisbl

To create a European Robotics OSS/FOSS observatory of safety and security incidents, bugs, issues, study cases

To create a EU working group /observatory for assessment and evaluation of OSS/FOSS reuse in Robotics

To contribute to the new trends and approaches to software certification in favor of OSS/FOSS

New Licenses schemes in relation to certification efforts and costs

To be proposed as topic for Horizon 2020

End of the presentation

Thanks for your attention.