Simulation and Verification of Control Systems

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.

Some simulators allow you to "speed up time". Explain the advantage of this when testing a thermostat's behavior over a full day.

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.

In the simulation, the LED blinks with perfect timing, but in the actual build, it blinks irregularly. Give two electrical causes that the simulator idealises (resistor tolerances, loose breadboard contacts) and explain how to troubleshoot each one.

In a simulator such as Tinkercad, a student directly connects a red LED between a 5.0 V digital output pin of a programmable board and ground (GND), without placing any resistor. On the screen, the simulator shows the LED turned on with a current of 115.0 mA and displays no error message.

1. a) If the LED manufacturer sets its maximum continuous current at 20.0 mA and a forward voltage drop of 2.0 V, and the board has a limit of 40.0 mA per pin, predict what will happen to the real components if you assemble that physical circuit and what unrealistic mathematical simplification the simulator is making.
2. b) Calculate the standard commercial value (E12 series) of the resistor you must insert so that the LED operates safely at a current of 15.0 mA.

Write two test cases for a program that sounds an alarm when a door opens: specify the input simulated and the expected output in each case.

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.

A program counts people entering a room (sensor A) and leaving it (sensor B). Design three test cases intended to catch typical errors: two people walking in together, someone entering and leaving immediately, and a sensor triggering twice due to contact bounce.

Explain what a "stress test" is for a control system and propose one for a parking lot program: state what extreme conditions you would simulate and what correct behavior you expect.

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).

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 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.

A greenhouse has two independent irrigation zones (Zone A: delicate seedbed; Zone B: general crop) managed by a microcontroller that receives data from two soil moisture sensors, a digital rain sensor, and a flow sensor in the main pipe. Design a verification plan to simulate the system before commissioning. You must define 5 comprehensive test cases that include priority conflict situations and supply failures. For each case, detail: exact simulated inputs, expected state of the solenoid valves and alarms, and what material or agronomic damage that test prevents.

The flowchart in the figure controls an automatic light depending on a sensor (LDR), but the contents of one block are missing. State what that block should do and describe what the system does when the sensor reading is 150 and when it is 800.

What is a bug or glitch in a control program? Give two simple examples (a condition written backwards, an incorrectly set threshold) and the effect each would have.

In the simulation of an irrigation system for a school garden bed, you have programmed this control loop:

REPEAT FOREVER:

humidity = read_sensor()

IF humidity < 30 % THEN:

activate_solenoid_valve()

wait(10 seconds)

deactivate_solenoid_valve()

END REPEAT

When running it in a simulator that models the physical absorption of water with an infiltration delay of 2 minutes, the solenoid valve opens and closes non-stop for dozens of consecutive cycles, waterlogging the soil.

1. a) Justify why the program generates this behavior in the simulation despite including an explicit deactivation instruction.
2. b) Redesign the algorithm (in pseudocode or a flowchart) to solve the problem without removing the sensor reading or changing the solenoid valve.

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.

In your own words, explain what it means to verify a program and how it differs from "just testing it briefly to see if it works".

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.

Explain what debugging a program means and name a simple technique for doing it in a simulator (stepping through code line by line, monitoring variable values).

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.