Software Safety vs Update Flexibility
Partition safety-critical software from updateable functions with mandatory rollback capability so post-launch changes can be deployed without re-qualifying the entire safety case.
CyberTRIZ analysis · Space contradiction RMA020 · one of 8,235 worked contradictions published by CyberTRIZ.AI
Regulations
Business Context
Flight software must be tightly controlled because defects can affect critical spacecraft functions. Extensive verification and configuration controls reduce software risk but can make post-launch updates slow and difficult. At the same time, long-duration missions may require software changes to correct defects, respond to degradation, improve performance, or support new objectives.
Space TRIZ Resolution
Software architecture should isolate updateable functions from safety-critical core functions. Modular software, partitioning, staged deployment, rollback capability, simulation environments, and controlled activation allow changes to be introduced without exposing the complete spacecraft to unnecessary risk.
Applicable TRIZ Principles
Principle 1 – Segmentation separates critical software from frequently updateable functions.
Principle 11 – Beforehand Cushioning maintains validated fallback configurations and rollback capability.
Principle 15 – Dynamics allows software capability to evolve while preserving protected core functions.
Expected Outcome
Strong flight-software safety
Greater post-launch update flexibility
Reduced update-related mission risk
Longer software operational relevance
Decision Indicators
Early indicators include:
Necessary software corrections are delayed because updates are difficult to qualify.
Minor changes require complete flight-software reverification.
Update failures cannot be rolled back safely.
Safety-critical and noncritical functions share unnecessary dependencies.
Missions avoid useful software improvements because of configuration risk.