1. Home
  2. Countermeasure
  3. Model-based System Verification

Model-based System Verification

Model-based system verification compares observed spacecraft behavior with behavior predicted by a physics-based or hybrid model to identify discrepancies inconsistent with mission-defined physical, configuration, and operational constraints. It can detect unexpected or physically implausible sensor values, state transitions, actuator effects, and command outcomes, but it does not independently establish that a command was authorized or that an anomaly was caused by a cyberattack. The verification architecture should use an independently protected model, diagnosis engine, configuration baseline, and, where feasible, diverse or separately validated input sources. A model driven solely by the same compromised sensor values, state estimates, command history, or software pathways as the monitored system may reproduce the adversary-controlled state rather than detect it. Model-based verification therefore complements authentication, command authorization, data integrity, fault management, and security monitoring rather than replacing them. The fidelity of the physics model determines the sensitivity and specificity of the verification, with higher-fidelity models capable of detecting subtler anomalies at the cost of greater computational resources. The model should provide sufficient fidelity for the defined verification objectives without introducing unnecessary complexity or sensitivity to poorly characterized parameters. Higher fidelity may improve detection of some anomalies but does not automatically improve sensitivity or specificity and may increase computational cost, model-maintenance burden, or false alerts caused by model mismatch.

ID: CM0066
Tier: III
Onboard SV CM 
Created: 2022/10/19
Last Modified: 2026/08/06

Pre-Operations Government

Acquisition requirements should address model-based system verification as a recommended anomaly detection capability for missions where sensor data integrity and command sequence legitimacy are security-critical concerns, with specifications defining the required model fidelity, the state variables subject to continuous verification, the discrepancy thresholds that trigger anomaly alerts, and the computational resources allocated to the verification function. Requirements should specify that the physics model used for verification be maintained as a separate, integrity-protected software component that cannot be modified through the same pathways used to update the operational flight software, ensuring that an adversary who compromises the operational software cannot simultaneously corrupt the verification model to conceal malicious state changes. Contract language should require that the model-based verification architecture be documented as a security engineering deliverable, including the physics model scope and fidelity, the data inputs used to drive the model, the comparison logic and alert thresholds, and the response actions triggered by detected discrepancies. Autonomous responses must be limited to actions shown to remain safe under credible model error, sensor failure, data loss, and false-alert conditions, with more disruptive responses requiring corroboration or ground authorization where mission timelines permit. Evaluation criteria should assess offerors' proposed physics model fidelity for the mission's specific dynamics, their approach to maintaining model currency as the spacecraft configuration evolves, and their demonstrated experience integrating physics-based verification into flight or ground system security architectures. Verification should include testing that demonstrates detection of injected sensor anomalies and implausible command sequence effects within the specified response time and discrepancy threshold parameters.

Pre-Operations Developer/Supplier

Physics model selection and development must be scoped to the verification objectives, balancing model fidelity against the computational resources available on the target platform, whether the verification function is implemented onboard the spacecraft, in the ground system, or in both. The model must be initialized and continuously updated with accurate spacecraft state data, including orbital elements, attitude, mass properties, and actuator states, so that the predicted state trajectory remains an accurate reference against which observed data can be compared; model divergence due to stale initialization or unmodeled state changes will generate false positive alerts that degrade operational utility. The architecture must avoid relying exclusively on the same potentially compromised value for both the observed state and the model reference where independent or diverse evidence is available. Discrepancy thresholds must be calibrated to account for the expected uncertainty in both the physics model and the sensor measurements, setting alert sensitivity high enough to detect security-relevant anomalies while low enough to avoid alert fatigue from benign model-sensor divergence caused by environmental variations, sensor noise, or unmodeled dynamics. The verification function must be architecturally isolated from the software and data pathways it is designed to monitor, so that a compromise of the monitored systems cannot simultaneously disable or corrupt the verification capability. Where complete independence is not achievable, common-mode compromise scenarios and compensating controls must be explicitly assessed. Model updates required to reflect approved configuration changes, such as propellant consumption, deployable extension, or payload reconfiguration, must be processed through a controlled update pathway that maintains model integrity while keeping the model current with the spacecraft's evolving physical state.