Simulation and verification

Explain what a circuit or robotics simulator is and give two advantages of testing on it before building the physical assembly.

Explain the difference between simulating a circuit on a computer and building it on a real breadboard: what is gained and lost with each method.

In the simulator, your program works perfectly, but in the actual build, the motor does not rotate. Give three possible causes that a simulator does not detect and explain how you would check each one on the workbench.

A program must switch on a fan when the temperature exceeds $26\ ^\circ\text{C}$. Define three test cases (input value and expected result) to verify it, including the boundary value of $26\ ^\circ\text{C}$, and justify why this boundary case is important.

Explain what a "boundary case" (or edge case) is when verifying a program and why they are so important. Give an example using a program that decides whether a mark passes from 5 upwards.

Design a verification table for a pedestrian traffic light: states (red, green, flashing amber), inputs (button pressed, time elapsed), and expected output for each state transition.

A team verifies their program only on the "happy path", that is, when everything goes right. Explain what error cases are and write two for a toy cash machine (invalid card, insufficient balance).

A team simulates a black line follower robot: on screen, the algorithm reacts in 0,02 s, the motors respond instantaneously, and the robot completes the circuit at 1,2 m/s without any errors. However, when uploading the same program to the real robot with the same sensors, it oscillates sharply from side to side and ends up losing the line on the first curve.

1. a) Identify and justify three real-world factors that the simulator omitted or idealized and that explain this discrepancy.
2. b) Propose two technical modifications (one in the control software parameters and another in the physical assembly) to compensate for these real effects without replacing the sensors.

A team programs a transport robot for a warehouse. When running the test plan in the simulator, the robot avoids 100% of the obstacles and brakes in front of any person, but the algorithm always resolves obstacle avoidances by reversing, driving down aisles against the warehouse workflow. The teacher states: "The software is perfectly verified, but the system is not validated".

1. a) Technically justify the teacher's statement by applying the operational definitions of verification and validation to this specific case.
2. b) Reformulate the robot's technical requirements specification to ensure that a future verification also ensures its proper validation in the working environment.

A mobile robot uses a front ultrasonic sensor (usable range: 2,0 cm to 400,0 cm) and must stop and turn if it detects an obstacle closer than 20,0 cm. Design a test matrix to verify the code in the simulator before transferring it to the real robot. Your plan must contain at least 4 different test cases that include boundary values and reading anomalies. For each case, you must indicate: simulated numeric input value, expected behavior of the motors, and technical justification of why it is essential to check that specific case.

The light sensor of an automatic blind records these values over a 6-minute period during an afternoon with broken clouds:

• t = 0 min: 780 lx

• t = 1 min: 805 lx

• t = 2 min: 795 lx

• t = 3 min: 812 lx

• t = 4 min: 798 lx

• t = 5 min: 815 lx

• t = 6 min: 820 lx

The system is programmed with the simple rule: "If light ≥ 800 lx, lower blind; if light < 800 lx, raise blind".

1. a) Determine how many movement commands the motor receives in that interval and justify what mechanical and energy consequences this operation entails.
2. b) Design a solution based on a dual threshold (hysteresis) by defining specific numerical values for the lower and raise commands, and demonstrate step by step how your solution responds to the same data series.

A line-tracking robot stops erratically after operating properly for about five minutes. To diagnose the fault, serial port logging is enabled, and these key lines are extracted prior to the stop:

• t = 295,0 s | Distancia: 35,0 cm | Temp_driver: 50,0 °C | V_batería: 7,4 V | Estado: AVANZAR

• t = 298,5 s | Distancia: 34,0 cm | Temp_driver: 78,0 °C | V_batería: 7,2 V | Estado: AVANZAR

• t = 300,0 s | Distancia: 35,0 cm | Temp_driver: 92,0 °C | V_batería: 6,1 V | Estado: PARADA_EMERGENCIA

1. a) Interpret the log data to determine the physical cause of the fault, refuting the team's initial report which claimed the fault was due to a defective ultrasonic sensor.
2. b) Design what additional variables or early warning conditions you should include in the log and in the control code to manage this issue progressively without reaching an abrupt shutdown.