I cannot add "oops" timers to any call to any function that involves a piece of hardware. This would apply to the mythical "one giant program" or the modular architecture of ACP. It would result in a massive inflation of code and complexity. If the camera lockup was a USB lockup I don't know what to do. This looks like a camera freeze, which would render all of the software frozen. Or maybe it's stuck in the camera logic itself? Who knows?
The alternative would be to add code to every call that involves hardware (mount, dome, focuser, rotator, camera, guide camera, etc.) to have some sort of beacon signal sent to a separate program which would insisting on every device "having ACP phone home" periodically. Now this "angel" program needs to be configured to know about every hardware device and its timing characteristics so it knows how often ACP needs to phone home. And this assumes that the initial call to start some operation (exposure or slew or focus change) succeeds in returning and it is the completion that never happens. Is that what's happening? Are we sure? What if it's a USB lockup. We're done!
ACP-1485 - Watchdog Program for ACP
With the above said, there is already logic in ACP that attempts to set and monitor a "sanity timer" for cameras since they are notoriously troublesome. Looking at your log, it appears that the camera lockup was right at the beginning of the exposure.
06:11:27 (using Fast Readout readout mode)
06:11:27 (starting exposure) <--- missing
Does this happen frequently? Is this the first occurrence? The sanity timer hasn't even been started. This happened when the exposure was initially requested. MaxIm didn't return an error for the request which would be "**Failed to start the exposure" but the camera never transitioned from idle to waiting to one of the expose states. If this happens frequently, I have some tracing code that we can activate to pin down what's happening inside the camera, or if it's a USB lockup. That's the place to start.