← Back to project catalogue
GP-CS-0CPDLI9Computer ScienceReady

Memory-Safe Language Migration Decision Framework for Safety-Critical Software

A completed computer science study for selecting and sequencing memory-safe language migration in safety-critical software while keeping timing, interfaces, tool qualification, platform support, verification, and lifecycle evidence visible.

Memory-Safe Language Migration Decision Framework for Safety-Critical Software project visual
GP-CS-0CPDLI9 · Computer Science
  • Python 3.12
  • NumPy
  • pandas
  • Matplotlib
  • Docker

Software compatibility

Python 3.12.14 or later on macOS, Linux, and Windows

The released results use the frozen 30 August 2026 evidence catalogue, pinned Python packages, 20,000 uncertainty draws per strategy, and random seed 20260830. Changed evidence positions require a fresh validation run.

Project definition

Problem statement

Memory-safe languages can prevent broad defect classes, but safety-critical migration also changes interfaces, timing, resource use, tool evidence, dependencies, verification assets, and the safety case.

The engineering problem is to choose a migration boundary and sequence that reduces total system risk without treating language choice as a certification claim or ignoring legacy behaviour and platform constraints.

Project objectives

  • Compare ten migration strategy archetypes across eight governing risk drivers.
  • Apply hard gates for driver applicability, memory prevention, timing evidence, interface evidence, and tool qualification.
  • Compare automotive, industrial, medical, and airborne or space safety contexts.
  • Map fourteen validation criteria across eleven migration workflow stages.
  • Quantify evidence-position uncertainty with 20,000 fixed-seed draws per strategy.
  • Retain complete results, figures, tests, references and editable documentation.

Project structure

Project components

01

Strategy register

Compares qualified Rust adoption, risk-prioritised replacement, narrow C interfaces, SPARK Ada, managed partitions, restricted C and C++, hardware support, isolation, full rewrite, and strengthened retention.

02

Risk-driver model

Tests untrusted input, concurrency, temporal errors, hard real-time, ABI dependencies, certification, constrained hardware, and supply-chain risk.

03

Decision framework

Scores twelve declared evidence dimensions and rejects inapplicable or weak strategies through explicit hard gates.

04

Assurance analysis

Keeps tool qualification, library evidence, platform support, interface contracts, equivalence, timing, and lifecycle maintenance visible.

05

Workflow FMEA

Ranks 154 stage-criterion combinations from inventory and pilot selection through verification, release, and safety-case maintenance.

06

Verification pipeline

Regenerates the study, tests the model, validates the documents and reproduces the analysis in Docker.

Methodology

Project workflow

  1. 01
    Define the safety context

    State the system boundary, integrity target, hazard links, timing constraints, platform, and accepted evidence route.

  2. 02
    Inventory legacy risk

    Rank components by exposure, privilege, memory defects, interfaces, change activity, and consequence.

  3. 03
    Select a migration boundary

    Compare candidate strategies and retain failed gates, alternatives, assumptions, and boundary risks.

  4. 04
    Run a representative pilot

    Compare behaviour, timing, resources, interfaces, unsafe code, dependencies, and verification evidence.

  5. 05
    Stage release and review

    Update the safety case, deploy with rollback, monitor residual risk, and review the decision when evidence changes.

Demonstration scenario

The retained analysis compares risk-prioritised Rust replacement, qualified Rust for new code, SPARK Ada, narrow C interfaces, full rewrite, containment, and strengthened retention. It shows why a language with strong prevention can still fail a timing, platform, interface, or qualification gate.

Engineering

Tools and method

Declared inputs
Python data structures retain every strategy position, risk-driver link, safety context, evidence case, gate, and decision boundary.
Deterministic analysis
NumPy and pandas generate all 1,280 strategy, driver, context, and evidence cases.
Risk analysis
Validation criteria, assurance crosswalk, and FMEA expose unsafe boundaries, timing gaps, qualification assumptions, and release risks.
Uncertainty
Fixed-seed Monte Carlo and one-factor sensitivity test stability of the declared evidence positions.
Evidence
CSV, JSON, PNG, PDF, and Word files retain the complete analysis, source catalogue, and report.
Release verification
Tests, linting, vulnerability audit, document QA, repository validation, and Docker verify the handover.

Testing

Evaluation

Evaluation measures

  • Screening score and hard-gate result by strategy and risk driver
  • Memory prevention, timing, qualification, library, platform, interface, verification, effort, skills, supply chain, resource, and maintenance positions
  • Strategy reversals across balanced, certification-first, incremental-risk, and hard real-time scenarios
  • Severity-weighted validation gaps and workflow FMEA priorities
  • Assurance requirement crosswalk by strategy
  • Monte Carlo intervals and evidence-position sensitivity

Project boundaries

  • All numerical inputs are literature-informed evidence positions rather than measurements from one software system.
  • The study does not certify a compiler, library, product, process, or safety case.
  • It does not claim universal defect reduction, migration cost, schedule, or performance.
  • Public standards are cited by identifier and metadata without reproducing protected clauses or tables.
  • A real programme requires its own code inventory, hazard analysis, target measurements, qualification evidence, and independent review.

Included

  1. 01Complete Python source and declared decision configuration
  2. 021,280 strategy, risk-driver, safety-context and evidence cases
  3. 03Ten migration strategies and eight governing risk drivers
  4. 04Four decision scenarios with hard applicability and assurance gates
  5. 05Fourteen validation criteria, a 154-cell workflow FMEA and a 130-cell assurance crosswalk
  6. 06Twelve generated figures and one attributed government literature figure
  7. 0793-page project report in PDF and editable Word formats
  8. 0815-page project and defence guide in PDF and editable Word formats
  9. 09Fifty annotated references with evidence boundaries and source matrix
  10. 10Automated tests, repository validation and Docker reproduction

Project record

No information is collected on this page.

Permanent project ID
GP-CS-0CPDLI9
Catalogued
21 Aug 2026
Completed
30 Aug 2026
Verified
30 Aug 2026
Demonstration
Included in repository

Handover

After purchase

  1. 01
    Payment is confirmed

    The project is marked unavailable and cannot be purchased again.

  2. 02
    Repository access is granted

    The buyer's submitted GitHub account receives access to the private repository.

  3. 03
    The purchase record is delivered

    The certification sheet is prepared from the reviewed buyer details and sent privately by email.