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.

![[press.png]]

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