|
A modern industrial control system may contain dozens or even hundreds of software tasks, all competing for a finite amount of memory and CPU time. To speed development of such complex systems, companies will often divide the work among multiple development teams, assigning each team the job of creating a separate software subsystem. Given the parallel development paths, performance issues often arise at the integration phase, when, for the first time, the various subsystems begin vying with one another for system resources. Subsystems that worked well in isolation now respond slowly or simply fail to operate.
Diagnosing and solving such problems is intrinsically difficult. Designers must juggle task priorities, possibly change thread behavior across the system, then retest and refine their modifications. The entire process can easily take several calendar weeks, resulting in increased costs and delayed product.
Resource partitioning offers a way to manage these complex integration issues. Using this approach, the system designer can isolate software subsystems into separate containers, or partitions, and allocate a guaranteed portion of memory or CPU time to each partition. For example, the designer can place a set of threads that have a common purpose (such as motion control) into a partition and allocate the partition 50% of the entire CPU capacity. The partitioning scheduler will then guarantee that this partition always receives its allocated CPU budget.
In effect, each partition provides a stable, known runtime environment that development teams can build and verify individually. If the software processes within a partition perform well during unit testing, they will, with a high degree of confidence, exhibit the same performance at integration time. Unforeseen resource contention among subsystems can be eliminated.
Avoiding Thread Starvation
To understand the need for time partitioning, we must first consider how threads are scheduled in a typical control system. In most cases, the system uses a priority-based preemptive scheduler, which always gives CPU time to the highest-priority thread that has work to do. This type of scheduler is widely used and well-understood, and it helps ensure that time-critical threads always meet their deadlines. It does pose a problem, however: If a given thread is even one priority level higher than another thread, it can potentially starve the less-critical thread of CPU time.
Say you have two threads, A and B, where A has a slightly higher priority than B. If A becomes swamped with work, it will lock out B (as well as any other lower-priority thread) from accessing the CPU. In an industrial control system, A could be the robot arm control loop and B the human machine interface (HMI). If the control loop consumes too many CPU cycles, it will prevent the HMI from displaying updates or make the HMI unresponsive to operator input.
|
