Modularity in Medical Software

Session details
Experience level: 
Intermediate
Session Track: 
Session Type: 
Standard
Your Vote
Community Voting: 
0
Your rating: None

Your vote will help the program committee know the favorite proposals

Log in here to vote

Modularity in Medical Software

Medical software traditionally drives critical functions of medical devices using some IoT or Edge-like architecture. 

Per state-of-the-art and applicable laws, modular medical software requires segregation in order to avoid unintended interaction across such modules. 

This presentation will briefly explain the process requirements to medical software and then turn to Java techniques for implementing some implementation requiremenets.

Regulatory frameworks for safety-critical domains -e.g. medical devices- enable multifunctional software and modular software, yet in order to achieve this in a safe and performant way, they call for separating – also: “segregating”- independent items of such software.

Segregation - being the protection from unintended influence between software items - is an important constructive measure towards software architectures for safety and performance of software systems.

This presentation explains requirements regarding segregation towards modularity in medical software and further refines the segregation goals for the use with the JAVA programming language. 

I.    INTRODUCTION
This paper explains and categorizes practical approaches to Segregation – a term referring to constructive measures aiming at avoiding or reducing unintended interaction between software items.

The term Segregation is used in IEC 62304 Amd1:2015 Medical Software – Software Lifecycle Processes. for expressing an important measure towards software reliability.   

In that standard IEC 62304, the definitions in clause 3 do not define Segregation, but implies it by introducing the terms software items and software unit, which identify elements of static software decomposition i.e. the software architecture.

II.    SEGREGATION IN IEC 62304
The technical measures for Segregation are required (i.e. Segregation is used) by clauses four and five (4.3d and 5.3.5)  of IEC 62304 – in the implementation of soft-ware for medical purposes or, in health software, per revision two of IEC62304.

Clause 4.3d does not specify any characteristics of the required segregation and uses the term merely to state a requirement, the implementation of which allows – according to IEC 62304 – the manufacturer to assign different safety classes to software items within the same overarching software items.

Clause 5.3.5 does not formally define segregation, but states in an example given in an informal note, that effective segregation avoids shared resources (for the software items being segregated).

By this clause, manufacturers shall demonstrate an adequate segregation between a protective measure and performance-related software units. Amendment 1 of that standard adds a sentence to Annex B, into clause B 4.3:

Segregation is not restricted to physical (processor or memory partition) separation but includes any mechanism that prevents some software item from negatively affecting another.

The adequacy of a Segregation is determined based on the risks involved and the rationale which is required to be documented.

As a conclusion, IEC 62304 requires segregation as a measure to protect each soft-ware unit in safety class C from unintended influence from all other software units, but leaves much room for interpretation on the sufficient measures in design, coding and deployment to substantiate the segregation claim.

Since the term of software item comprises the concept of software unit – being the smallest unit of decomposition – any technical influence between software items must have its origin in one of the software units of the interacting items. Therefore, the assessment focuses on segregation of software units.

Note that, in recent work for newer versions of IEC 62304 (i.e. amendment of 2015 and drafts for a full revision), segregation is considered an architectural measure towards information security – avoiding  the propagation of malicious content across different software units.

What is effective Segregation? If we rephrase the definition from [62304], then Segregation is effective if the individual software items as well as the integrated system maintain their functionality and quality attributes related to risk control even under adverse conditions.

What is an adverse condition in the context of effective segregation?

  • Faults: For Segregation to be effective in the presence of faults, we can not prevent faults from happening; we have to process the errors; and we must exclude failures.
  • Limited Resources, Resource Competition: the set of available resources is always limited. Segregation is effective with respect to limited resources if we can guarantee that all resources needed to perform the tasks related to risk control can always be provided when needed, regardless of the load on the system, the load in the system environment, and the cooperative or non-cooperative behavior of any software item competing for the limited resources.
  • Performance Dependencies, Limited Performance: risk control may require a guaranteed performance for critical tasks. Segregation is effective with respect to performance if we can guarantee that all performance criteria related to risk control are always met, regardless of the load on the system, the load in the system environment, and the cooperative or non-cooperative behavior of any software item competing for processing time and contributing to a risk related process.

Despite the correctness of the respective unit design and implementation, some critical software unit being part of a software system executed on the same computing platform requires segregation.

For software, the regulatory requirements of safety and performance (despite their functional correctness) translate to:

  • non-blocking execution of each critical unit (NB),
  • performant computation of each critical unit and (PC),
  • integrity of data within, into and from each critical unit (ID)[CONC].

III.    JAVA APPROACHES TO SEGREGATION 

Programming support

  • Avoid interaction through shared parameters
  • Avoid interaction through shared instances 
  • Avoid uncontrolled iterations and recursions
  • Ensure Scalability of Computation
  • Ensure Graceful Degradation (Local)

2.    Design Support

  • Ensure enough resources when entering critical methods
  • Ensure Consistent Computation in Critical Sections…
  • Ensure Parameter Integrity 

3.    Platform Support

  • Avoid interactions between software running in different threads
  • Avoid interactions between data transactions
  • Guarantee sufficient assignment of scarce resources
  • Dispatch and Respond to Events in Parallel
  • Queued Computation
  • Ensuring Consistency of Persistent Modifications from User Interactions
  • Ensuring Consistency of Persistent Modifications from User Cooperations
  • Cooperative Sharing of Resources
  • Graceful Degradation
  • Cooperative Tactics for Performance: 
  • Guaranteed Allocation of CPU

The presentation will also propose a constructive approach towards building guaranteed-segregation designs in Java – while at the same time preserving general applicability and scalability.

Objective of the presentation: 
In this session, Java techniques protecting from unintended cross-interaction between classes will be presented.
Attendee pre-requisites - If none, enter "N/A": 
N/A

Our Sponsors

Our Other Events

Eclipse events are hosted all over the world!

  • EclipseCon Europe 2019