## 3 Elements of the BBCP
### Run Constraints  
The objective of the properties in this category is to constrain the time an instance spends active (in a run state). The interpreter measures the time that the instance spends in an active state using two metrics: instant run time and accumulated run time. The _instant run time_ is the duration of the last occurrence of an instance in a run state, in seconds. The _accumulated run time_ is the sum of all the time that an instance spent in a run state in seconds.  
The property _Minimum Run Time_ prevents an instance from switching back to a stop state during an evaluation unless the instant run time is greater than this property's value, in seconds. The property _Maximum Run Time_, as opposed to _Minimum Run Time_, limits the instant run time to a maximum duration in seconds. If a run exceeds this limit, the instance is immediately switched to a stop state. The last couple of properties are important to prevent edge cases where an instance can spend either too little or too much time in a run state.  
The property _Quota_ is similar to Maximum Run Time but it limits the accumulated run time. The Quota decreases with each second that an instance spends in a run state, hence the name. Once it is depleted, the instance is switched to a stop state and ceases to be evaluated. It will not be evaluated and be able to switch to a run state again unless its Quota is reset. Going forward, we will refer to this specific pattern of behavior as a _Depleted Quota_.  
The _Cooldown_ property defines how long an instance spends with a Depleted Quota before its Quota is replenished and the instance can be re-evaluated. Even though we have constrained the instant run time and the accumulated run time, there could be a need for constraining the instant run time of an instance to a specific duration, which is achieved with _Countdown_. When the instant run time equals the value of the Countdown, the instance is immediately switched to a stop state.  
To summarize how usage constraints and run constraints are utilized, let us think of an example of a surveillance system, more specifically, the software responsible for recording suspicious activity. As per a hypothetical surveillance policy, the software must record at least 10 min of footage with 5 min between recordings. However, if the system sees it fit to do so due to uncontrolled variables, such as a motion sensor, the footage could keep rolling up to 20 min with a maximum daily footage duration of 1200 min (20 h). To replicate this behavior, we can use a Profile Evaluation Rate equal to 0.00333 Hz, as we have to record every 5 min. A Default Run Probability of 1 and a Default Stop Probability of 0.7 can control an irregular switch between states every 5 min. However, to enforce a minimum of 10 min of footage and a maximum of 20, we set the Minimum Run Time to 600 s (10 min) and the Maximum Run Time to 1200 s (20 min). To enforce the maximum daily footage, the Quota is set to 72,000 s (1200 min), and the Cooldown is dynamically set (set by the interpreter) to the time left until the next day. The final result is a behavior that complies with the deliberate requirements of the software in addition to the variability of uncontrolled circumstances that could affect the results. The plot in Figure 5 describes the change in the recording state of the camera according to its usage and run constraints over 3 h.