The framework is particularly relevant as Computer Vision becomes increasingly important in robotics and artificial intelligence. A visual system does not merely produce an image or identify an object. In a robot, visual information can influence decisions and physical actions. A detection or segmentation error could therefore lead to incorrect navigation, an unsafe actuator response, or a missed inspection target.
Why a Working Demonstration Is Not Enough
Traditional Computer Vision assignments can place heavy emphasis on visible success. A notebook receives credit because it executes, a detector appears successful because it produces a bounding box, or a group project passes because a demonstration works under carefully prepared conditions.
According to Iskandar, such demonstrations can conceal important weaknesses. Students may not fully understand the code, parameters may have been adjusted without a clear baseline, data changes may go undocumented, and a system that works in one environment may fail when lighting, camera position, motion blur, background, or computing conditions change.
The proposed framework treats these failures as valuable learning evidence rather than something to hide. False positives, false negatives, missed detections, unstable contours, and processing delays can reveal weaknesses in data, assumptions, algorithms, or operating conditions. Students are expected to document such failures, investigate possible causes, and test targeted revisions.
Eight Stages Structure the Learning Process
FAIL-SAFE stands for eight stages that organize a semester-long Computer Vision project around decisions that a robot must make:
- Frame — define the robot's decision, users, environment, consequences of errors, and operating constraints.
- Audit — examine data sources, permissions, environmental coverage, class balance, and potential risks.
- Isolate — establish a baseline and change one variable at a time.
- Log — record failures, evidence, possible causes, and revisions.
- Stress-test — test the system under adverse conditions rather than only ideal conditions.
- Account — distinguish group production from each student's individual mastery.
- Formalize — establish thresholds, operating limits, and fallback behavior.
- Explain — document the system so another person can rerun, evaluate, and responsibly reuse it.
The sequence is deliberate. Students cannot credibly claim that a system has improved without first establishing a baseline. They also cannot claim robustness without testing difficult conditions or demonstrate individual competence simply through a successful group presentation.
Assessment Adds Four Layers of Evidence
The design produces three major outputs: the eight-stage FAIL-SAFE workflow, a 4P evidence architecture, and a collection of course artifacts designed to make technical performance and student reasoning visible.
The four evidence domains are Performance, Process, Person, and Protection.
Performance covers technical behavior, including functional results and real-time indicators such as latency and frames per second. Process records how the system was developed through experiments and failure logs. Person evidence checks whether individual students can explain and modify the components they worked on. Protection addresses risks, limitations, and appropriate fallback actions.
This approach also addresses unequal participation in group projects. Instead of assuming that every group member understands the complete system, the framework uses individual code tracing, randomized viva questions, contribution evidence, and live reruns to verify individual mastery.
The diagnostic framework also requires students to test lighting, blur, occlusion, camera angle, background, and system load. It calls for error portfolios covering false positives, false negatives, degraded conditions, and runtime problems rather than reporting only the best images.
Generative AI Becomes Part of the Accountability Process
The framework also responds to the growing use of generative AI in programming education. Rather than focusing exclusively on detecting whether AI produced code, the model emphasizes whether students can explain, test, critique, and take responsibility for the code they submit.
Students are expected to disclose and verify AI assistance. Individual questioning and code tracing can then test whether the student actually understands the resulting system. This connects academic integrity with the professional responsibility expected from future robotics and AI engineers.
Safety is similarly built into the learning process. Students must connect confidence levels, processing speed, and failure modes to the robot's response. An algorithm card should specify intended and excluded uses, evaluation conditions, residual risks, and fallback behavior. Knowing when a system should not be deployed is treated as evidence of engineering maturity, not failure.
Practical for Universities With Limited Resources
The framework does not depend entirely on expensive robotics equipment. The paper notes that early experiments can use offline datasets and low-cost cameras, while performance profiling can be conducted on available laptops. Safety demonstrations can also use simulation or low-energy robot responses. The key requirement is disciplined evidence rather than sophisticated hardware.
For universities, the model could potentially be adapted beyond Computer Vision. Iskandar notes that the same sequence can be applied to machine learning, embedded systems, control, data science, and other robotics courses. The resulting artifacts may also help programs connect learning outcomes, student work, and assessment decisions during curriculum review.
However, the paper does not claim that FAIL-SAFE has already improved student learning. The work is a conceptual design study based on curriculum mapping, literature synthesis, artifact prototyping, and an internal alignment audit. It did not involve student scores, interviews, or personal data, and its effectiveness still needs to be tested in future classroom research.
Academic Perspective
For Didik Iskandar of Universitas Cendekia Abditama, the central shift is from grading only the final product to examining the reasoning and evidence behind it. The framework establishes a professional expectation that Computer Vision results should be explainable, reproducible, bounded by known conditions, and connected to responsible action.
0 Komentar