Software-Defined Capability vs Hardware Constraints
Establish hardware flexibility boundaries at design time so post-launch software redefinition remains within the validated safety and conformity envelope.
CyberTRIZ analysis · Space contradiction TSI022 · one of 8,235 worked contradictions published by CyberTRIZ.AI
Regulations
Business Context
Software-defined spacecraft can change communications functions, processing strategies, operational modes, and mission behaviors without physical modification. However, software flexibility remains limited by processor performance, memory, interfaces, sensors, actuators, and communications hardware established before launch. Attempting to anticipate every future software requirement can lead to excessive hardware margins.
Space TRIZ Resolution
Hardware should provide strategically selected flexibility rather than maximum capability in every dimension. Reconfigurable processors, programmable interfaces, standardized data paths, and adaptable resource allocation can create multiple future options without requiring dedicated hardware for each potential application.
Applicable TRIZ Principles
Principle 6 – Universality uses common hardware resources for multiple software-defined functions.
Principle 15 – Dynamics reconfigures hardware utilization according to evolving software requirements.
Principle 35 – Parameter Changes adjusts operating parameters to support changing mission functions.
Expected Outcome
Greater software-defined capability
Lower hardware overdesign
Improved lifecycle adaptability
Longer technological relevance
Decision Indicators
Early indicators include:
Software upgrades are prevented primarily by fixed hardware interfaces.
Large hardware margins are included for undefined future functions.
Dedicated hardware exists for functions that could share programmable resources.
Reconfiguration options are limited after launch.
Spacecraft become functionally obsolete while core hardware remains healthy.