Obsidian/.archive/300s School/ME 2150 - High Assurance Cyber-Physical Systems/ME 2150 - High-Assurance Cyber-Physical Systems Final Report.md

Recap of the Wheelchair Cushion Testing Rig Failure

Context
During a summer internship at Pitt’s Wheelchair and Cushion Standards Group, a friend of mine operated an ISO-16840-2 immersion test fixture designed to evaluate wheelchair cushions. The rig uses a hydraulic press fitted with a CNC-machined wooden “buttocks” model, instrumented with an array of pressure sensors, to measure both pressure distribution and press displacement as cushions are compressed.

!

Fatigue Test Incident
In a cyclic fatigue test, the press descends until a target pressure is reached, holds, then retracts to zero, repeating many times. When testing a cheap, air-mattress-style cushion, the material never achieved the setpoint. The controller attempted to compensate by increasing displacement, triggering an over-pressure safety retraction. Because the control logic was not designed for cushions that cannot reach the target pressure, it then aggressively re-applied the previous displacement. This rapid cycle of over-loading and retraction violently rammed the wooden model into the steel frame, quickly breaking the lower sensors and, after only a few seconds, splitting the wooden buttocks apart under what was later estimated to be well over 1,000 lbf (far above the intended 400 lbf). The test only stopped when the emergency-stop button was finally engaged.

Key Cyber-Physical Failures

1. Unvalidated Operating Envelope: The pressure-based controller was never formally verified for use with cushions that fail to meet the target pressure, allowing it to drive the system into an unsafe region.

2. Faulty Assumptions About Sensor Integrity: The over-pressure protection assumed sensors would continue to report accurately under extreme loading; as sensors degraded, the controller applied even more force.

Consequences
No one was injured, but the incident incurred high costs: replacing the CNC-machined buttocks model, purchasing new pressure sensors, and dozens of hours spent recalibrating and re-testing. This failure highlights the importance of high-assurance methods—such as formal proof of safe operating bounds and rigorous digital engineering—to guarantee that a CPS cannot drive itself into a destructive mode, even under sensor faults or unexpected material behavior.

So, how could rigorous digital engineering solve this problem?

The fundamental problem with this testing set up was not an implementation problem. The controller as it was programmed performed the fatigue test exactly as it was asked. This failure wasn’t an implementation bug— the controller did exactly what it was told. The real breakdown occurred at the design stage, where no one had explored all possible operating states or planned for assumption violations.

Here's a simple example. One of the main causes of the failure was that the control system did not anticipate wildly divergent sensor readings. This makes sense for cushions that are operating properly where load would be evenly distributed, but cases where this assumption is violated were never examined. In the case of this failure, this assumption was violated by a subpar cushion, but what if a sensor was never connected to the system? Presumably, the testing fixture would behave this way regardless of the cushion being tested, and situations where sensors may be disconnected briefly for cleaning or moving the fixture may be extremely common scenarios.

After taking the HACPS class, I think the designers of this testing fixture could have made good use of a model checker like TLA+. An analysis of testing system through a series of TLA+ modules could avoid these disaster scenarios where sensors do not prompt correct control. One could do this analysis by examining what 'correct' behavior is:

For the testing fixture as described, a couple things should ALWAYS happen (specifications):

1. The sensors on the bottom of the buttocks should ALWAYS experience more load than the sensors on the side of the buttocks, except at low load conditions where noise is the dominant signal.
2. The sensors on the bottom of the buttocks should never have a difference in pressure from the side buttocks sensors greater than some value \Delta P.
3. Sensors across symmetries (left vs. right buttock) should also always have similar values to one another. If any of these statements are violated, testing should stop immediately.

How do these specifications actually line up to some requirements? Let's investigate:

The buttocks should not destroy themselves with excessive force. This overarching requirement can be refined into some more specific requirements:

1. The testing rig should be safe if a sensor fails. This requirement is satisfied by all of the above specifications, but especially specification number 3. Realistically, all cushions and buttocks will be fairly symmetric, so if for example a sensor fails and reports a bogus value, the complimenting sensor on the other buttock should throw a flag that this specification has been violated, and the testing should stop.

Specification 1 also addresses this requirement. If one of the bottom senors fails in a way that the measurement is much lower than expected, the other side placement sensors will exceed the bottom sensor measurement and stop the testing protocol.

2. A broken or absent cushion should stop testing immediately. If a cushion fails or is not present, the bottom sensors will contact the testing rig frame and increase in pressure while the side sensors will not increase in value at all. The result is that the difference between the bottom and side sensors will increase dramatically with additional force. Specification 2 will prevent failure through this mode, as the \Delta P flag will be thrown and testing will stop.

This analysis could be more rigorously defined and carried out using all sensors and with more sophisticated logic in TLA+, along with actually defining the controller logic that runs the test. Here, we've only discussed failure conditions, but there is all sorts of logic in the real system that decides when the buttocks should descend, and when a new failure fatigue repetition begins. All of these behaviors can be modeled in a model checker like TLA+ and compared against safety specifications to ensure that a failure like the one experienced is not possible from the design level.

AI Use Statement

I used ChatGPT to help me brainstorm and refine the organization and wording of my report, including rephrasing complex paragraphs for clarity, as well as rephrasing my first assignment for conciseness. All final content decisions, technical details, and edits were made by me.