The cost function is a cliff, i.e. the machine would not break if I don't cross the limit. Because you reduce the operation area the more you stay away from the cliff, a mechanism which allows me to enlarge the operation is what I would like to investigate.
If it's a case of things breaking then the situation requires a lot more knowledge and understanding of the situation on the ground than you'll get from an open newsgroup posting, unfortunately. A solution that's simple and understandable is likely to be needed, and regulatory algorithms may be strictly deterministic, but their response is dependent on the inputs in complex ways, and unexpected conditions can cause unexpected outputs. I rarely see breakage prevention implemented without some sort of discrete, 'trip' action being applied.
If this is a real plant, then remember that the solution that you implement has to make all the stakeholders comfortable, not just yourself. Practical operating people tend to be a lot more comfortable with a simple, defined action that they can understand than a control response that you can't categorically illustrate without making assumptions about the input behaviour.
If there's any sniff at all of 'safety hazard' here then it's a totally different ballgame again.
Your call obviously, but I'd sleep better at night with a trip in place. That's an important element of your objective function.
There are physical contraints, which needs to be taken into account, certainly. E.g. the system response (PT2) defines the last point in time where the limit governor may react. I could make measurements in order to figure out how much time I have under different circumstances.
But I would appreciate if I would be able to design structure and parameters depending on the system response, first. Unfortunately, for the phrase "limit governor" I didn't find much literature.