First of all, you might clarify one of your requirements. By utilization do you mean overall execution time for tasks vs. an elapsed interval or are you trying to pinpoint utilization rate by individual task? If the goal is a type of watchdog then you only need to track idle time, since by definition when idle isn't running you are consuming task execution cycles. You will have to add a highest priority task to routinely poll some global to detect the fault or modify the scheduler code to do the same thing. This assumes you don't adopt the programming model so beloved by ST and load up a high percentage of processing in ISR callbacks.
You didn't specify if or what RTOS you are using. FreeRTOS has a mechanism to profile task execution time through a macro style hook in the pre-emptive task scheduler. The hook tracks when task context changes, basically the point in time when an unblocked task with a higher (or round robin) priority is scheduled for the next slice. I use this to track elapsed time (using a spare 16-bit 100usec hardware timer) spent in each task (which can be less than a full slice). This doesn't track time in interrupts so it's not perfect, but it is relatively lightweight in terms of scheduler overhead. Per task stack overflow can be trapped at the same time.
Since the macro hook is in the scheduler, not a task, it runs at the RTOS priority level. This has the benefit of not impacting very high interrupts running above the RTOS priority level. ISR processing time is distributed across whatever task is active, but profiling ISRs in situ can be difficult when latency can impact the application.
Obviously, this technique isn't ideal when normal usage is 97% and fault is 99%. Measurements fall within the margin of error, yielding false positives. But if you're looking for 99% usage (i.e. failed spinlock or infinite loop) when the application should be running at much lower levels, I've found it works quite well. I've used it since FreeRTOS added in the scheduler hooks.
BTW the problem IS poorly worded. It looks at one time slice at a time instead of a time series analysis. Many applications employ burst processing for critical events, which may reach 100% over several slices, followed by a return to idle levels when the event has completed. The problem is worded to imply a time-sharing system, where every user is guaranteed the same amount of time, rather than prioritized execution based on "real time" reaction to events. I sense the Linux influence here (and spare the indignant recriminations, I know there are Linux versions patched up to support real time operation).
Bear in mind no time-slice based monitoring will detect loop type faults in interrupts, especially if spinlocks are present (extremely poor programming practice in an ISR). That's why there are hardware watchdogs. Nor does it handle tasks containing critical sections (i.e. interrupts disabled) with loops that may not terminate, or priority inversion triggering task deadlocks.
Jack Peacock
