[Opinion] Virtual Verification and Automated V&V

Yu Seong-jae, an executive at MathWorks Korea, wrote an opinion piece for IT Daily titled "Virtual Verification and Automated V&V," with the subheading "Faster Implementation, More Important Verification." The piece introduces a recent conversation with a university professor.

In that conversation, the professor said that some students in the lab tended to prefer direct C++ implementation over model-based automatic code generation. They favored using coding agents, citing the immediate speed advantage in implementing research tasks.

However, the article notes that this is a single lab case and cannot be generalized, and that model-based development and direct implementation do not always mean one is superior to the other. The key point of the case is not which tool is better.

The article points out that implementation costs are falling rapidly, but explains that coding-agent authoring software can also be linked to model-based virtual environments for verification. It concludes that even as implementation becomes easier, responsibility for checking results and verification remains unchanged.

Defense and aerospace systems for aircraft, unmanned systems, guided weapons, and satellites and launch vehicles have long life cycles and strict certification requirements. As a result, finishing development is not simply a matter of writing executable code; it must be followed by steps that demonstrate whether requirements are met, whether the system is safe under unexpected conditions, and whether existing functions are preserved after changes. Verification & Validation, or V&V, is expanding to cover this demonstrative role.

As AI output generation accelerates, the number of items to be verified also increases, widening the scope of V&V and shifting the new development bottleneck from implementation to verification. In this context, the value of a digital twin lies not only in generating a virtual model, but in connecting requirements, architecture, design, code, and test results through a digital thread and accumulating verifiable evidence. The digital thread is presented as a means of linking requirements, architecture, models, code, and test results to enable traceability of change impact and verification evidence.

The causes of system defects are varied and not limited to a single line of code. Ambiguity in requirements can also cause defects, physical model assumptions may differ from the real environment, and even components that work properly on their own can behave unexpectedly once integrated. Verification should therefore begin not after implementation is complete and a pass-or-fail judgment is made, but during the process of turning requirements into executable test conditions. The scope of test scenarios includes nominal operating conditions, boundary values, sensor deviations, communication delays, environmental changes, and component failures, and expected results and allowable ranges must be clearly defined for each condition.

An important principle in this process is not to keep test scenarios as separate documents detached from requirements. The relationship between requirements and test conditions, the test execution model, software versions, and result criteria must be connected and managed together. Model-based design provides a function that links control algorithms and plant models in a closed loop, thereby enabling scenarios to be executed at the system level. The condition of connecting software to the same test environment applies equally to human-written software and AI-generated software, and the scope of verification extends beyond individual function behavior to determining whether the entire system meets its intended behavior.

Physical testing is constrained by time, cost, test facilities, and safety, making it difficult to reproduce all possible operating conditions and fault combinations in the real world. By contrast, virtual environments allow systematic variation of inputs and parameters and repeated execution of large-scale scenarios, giving them an advantage in verifying diverse cases.

However, to use such results as a basis for judgment, it is necessary to distinguish a digital twin from a simple simulation model, and to define the purpose and valid scope in advance. In addition, comparison with measured data and confirmation of the required accuracy are needed, and in defense and aerospace especially, model reliability affects test strategy and certification responses. Large-scale virtual testing with an unvalidated model can accelerate the repetition of incorrect assumptions.

Accordingly, the principle for using virtual verification is to first clearly define the model's valid scope. Virtual verification should be used to supplement physical testing within that valid scope and to preemptively identify high-risk conditions.

Virtual test results are not grounds for reducing physical testing, but a criterion for selecting conditions that must be confirmed physically and for determining test priorities. In a virtual environment, vulnerable areas and high-risk conditions are detected in advance, while physical tests focus on representative test conditions and differences between the model and the actual system. Differences observed in physical testing are used to adjust model parameters and refine the model's valid scope.

As a result of this verification framework, development in as little as 12 months was presented as possible. German satellite startup Reflex Aerospace used the MATLAB and Simulink toolchain for the development of an attitude and orbit control system, or AOCS, simulator. In the process, it used Aerospace Toolbox and Aerospace Blockset.

The simulation incorporated orbital propagation, attitude dynamics, and Earth's magnetic field, which is classified as an effect of the space environment. Stateflow was also used to model satellite operating modes, transitions between modes, and logic for responding to abnormal situations.

Reflex Aerospace carried out verification of the satellite attitude and orbit control system in stages, linking model-based virtual verification, large-scale simulation, PIL, HIL testing, and flight data analysis. In the process, it expanded the scope of virtual verification on a large scale, used Parallel Computing Toolbox to accelerate large simulation campaigns, and efficiently explored several thousand scenarios. It also ran separate Monte Carlo simulations to evaluate the robustness of the control algorithm against uncertainty. Verification was performed hierarchically, from subfunction-level tests to system-level functional tests based on Simulink Test, and test cases defined from the requirements at the start of development were reused throughout development.

It then used Simulink Coder to automatically generate C code for onboard software and conducted PIL and HIL testing to verify whether the runtime behavior of the generated code matched the behavior confirmed in simulation. After the first satellite, SIGI, was launched in 2025, it used Curve Fitting Toolbox to perform data analysis and post-processing and confirmed whether actual satellite performance matched simulation predictions. In addition, once SIGI entered orbit, flight data could be used to validate and improve the simulation model.

The key point of this case lies not in the 12-month result itself, but in the verification structure that made the speed possible. Verification was not omitted; rather, the verification point was moved earlier into the virtual environment, made possible by establishing a repeatable verification structure at each stage of software, processor, hardware, and real operational data.

The core element of test automation is evidence, not the number of tests. Running many tests automatically does not complete V&V; the results must be accumulated in a traceable form of evidence. To do this, records are needed for each requirement's test scenarios, the models used, the software versions, and the result criteria.

The area where the real value of the digital thread emerges is verification. Connected requirements are converted into test conditions and criteria, and tests are rerun after selecting those affected by changes. When a test fails, requirements, architecture, models, software, and the test environment must all be traced, and this process requires the ability to distinguish causes.

The role of this connected structure is to extend automated V&V beyond simple repeated execution. When such a structure exists, automated V&V can be used as an evidence system for certification and design decisions.

AI can be used to propose boundary conditions, suggest test candidates, and detect anomalies in large volumes of results. However, if AI generates both the implementation and the expected results and then judges pass or fail on its own, the same error can be reflected on both sides. AI analysis is therefore not a substitute for verification evidence and is appropriately used as a support tool to help identify areas for human review.

As automated V&V expands, an important point is that large-scale test execution technology alone is not sufficient. The key is to judge whether a physical model is valid for software evaluation, whether test scenarios truly verify requirements, and whether the causes of result differences should be attributed to modeling assumptions or software errors.

For this reason, it is argued that model and physical understanding alone are not enough, and software writing ability alone is not enough. What is required for sound judgment is not expertise in a single field, but the ability to integrate multiple elements at once.

The capabilities needed include understanding the valid scope of models, understanding system behavior, understanding requirements traceability, understanding the software verification framework, and understanding the certification framework. In an environment where automated V&V is expanding, such combined capabilities become increasingly important.

The analysis concludes that, as AI accelerates code and model generation and the value of combined capabilities rises with AI advancement, future competitiveness will no longer be determined by whether output generation is faster. The decisive factor going forward will be the uninterrupted connection of the flow from requirements to test to evidence to certification, and the role of the digital twin is to provide the foundation for improving both development speed and reliability along that flow.

Source: IT DAILY · Yu Seong-jae
Original: https://www.itdaily.kr/news/articleView.html?idxno=241388

References

• https://www.itdaily.kr/news/articleView.html?idxno=241388