Control–feedback–abort loop

The concept of the CFA loop was developed by T. James LeDoux, ‘Jim’, a Senior Consultant and software QA / test expert and owner of Alpha Group 3 LLC, a test management consulting company. In 1986, Mr. LeDoux, with assistance from Mr. Warren Yates, a former engineer from General Dynamics, Inc., found that using a Control and Feedback concept for analyzing group and system dynamics was not providing them with the full picture when systems were going out of control. In 1996, Jim LeDoux and Dr. Larry W. Smith, Ph.D., president of Remote Testing Services, Inc., discussed the issue at length and came to the conclusion that some other form of control must be present when a system goes out of control, even if the control is unintended.

In 1997, Mr. LeDoux used the change of behavior a person exhibits when driving a car at the time a police car pulls in behind them to describe how a change of control occurs. He demonstrated this phenomenon at a 2003 Product Development and Management Association (PDMA) meeting in Denver by showing the action of the first control (traffic, signs and speed) being aborted by the driver and a second control (police car, signs and speed) becoming the primary control. In 2004, Mr. LeDoux worked with Dr. Susan Wheeler, Ed. D., a former Instructional Design Consultant with Nims, Inc. and the present Director of Technology Services at Illinois Central College, to identify the range of uses for the CFA Loop. The CFA Loop is now being used to analyze system activities in several Fortune 100 companies. A discussion of its use is also included in the management book “Takeoff!: The Introduction to Project Management Book that Will Make Your Projects Take Off and Fly!” by Dr. Dan Price, D.M.[3] ISBN 978-0-9707461-1-5

It was found that strong similarities existed between the concept of ‘Control Charts’ and the CFA Loop. The difference in the two concepts was that control charting is used as a dynamic measurement of present conditions. The CFA Loop is used to analyze how a closed-loop system is supposed to work and what are the expectations when alternate controls take over by either intent or accident. A comparison of the CFA Loop and its relationship to Control Charts are presented in a later section of this discussion.

Figure 1 shows a model of the CFA loop. The CFA loop consists of three main elements – The Control element, the Feedback element and the Abort element. Within any system, the lack of any one of these three elements will result in the system failing at some point in time. The term ‘system’ used in this document can represent any environment, task, process, procedure or system in a physical, organizational or natural structure where an entity will respond to influences. It has been found, through experience, that even trees appear to follow the CFA model. The diagram in Figure 1 can be used as an analysis diagram by inserting functions of the controls, feedbacks and aborts in each of the related circles defining the system being analyzed. (Example: Control – Workflow requests, Feedback – Results of requests, Aborts – Requests that failed, workflow exception path)

The CFA model can be used effectively with 3-sigma control charts. CFA loops and Control Charts share the same functionality, which will be discussed later in this document.

Figure 1 – The CFA loop

As mentioned, the CFA Loop consists of three elements – Control, Feedback and Abort. First, we will discuss the Control element of the loop.

The feedback element

The Feedback element feeds back information on the present state of the system. Due to the fact that the Feedback element is always reading the present state of the system, the feedback element has the basic characteristic of always being in a ‘dynamic’ state. This means that the feedback is reading constantly changing conditions. No system is ever in a non-changing condition except if it is off, no longer functioning or dead. Look at a computer in a wait state. It is still performing administrative activities even while it waits for some activity to happen. Change is the constant state of the Feedback element.

For this reason, the Feedback element needs to provide information to the Control element at intervals necessary to provide the Control element time to adequately respond to the changing environment. This interval period is called ‘sampling’, which will be discussed later in this document.

Figure 3 – CFA Loop – Feedback Element

The communication between the Control element and the Feedback element is performed by way of the ‘Primary Path’ (see Figure 4). The Primary Path is a bidirectional path that allows for the Control Element to request a sample of the information and the Feedback element to respond.

Figure 4 – CFA loop – primary path

The abort element

The abort element (see Figure 5) is so named because it responds to conditions that resulted in the primary path being ‘aborted’. The Abort element then takes over the act of control until conditions can be brought back into acceptable parameters.

Figure 5 – CFA loop – abort element

The ‘Alternate Path’ (see Figure 6) is used for communication between the Alternate Control (Abort) and the Feedback. The Feedback at this point may be a different set of feedbacks than was defined for the primary path.

Figure 6 – CFA loop – alternate path

To demonstrate that the Feedback may be another set of feedback elements, we look at the following example.

Let’s use the act of driving the auto once more for our example (see Figure 7). When a driver is driving the car, the primary path is the Control element (gas pedal) and the Feedback element (speedometer and street signs). Once a stop sign is detected ahead, the driver will take the foot off the gas pedal (primary control) and press the brake pedal (alternate control). Note that the driver is no longer looking at the speedometer or street signs once the auto gets to the stop sign. The driver is looking for other cars that may cross his path. In other words, the driver is looking for a different set of feedback sources. Once he feels it is safe to go, he will go back to the primary control and feedback and the primary path.

Figure 7 – CFA for automobile speed adjustment

The Control Loop Diagram is a chart that provides a list of each of the conditions we discover during the analysis of the interaction of the specific item in question. A basic Control Loop Diagram is shown in Table 1.

Table 1 – Control loop diagram template

The Control Loop Diagram provides a vehicle for the CFA Loop to be used effectively. The following is a sequence that allows for us to create the CFA Loop analysis information and convert it into a Control Loop Diagram. The process is:

A. Identify the perspective of the CFA Loop.

It is important to know what the perspective is. We may be looking at the environment from a specific perspective (i.e. from the viewpoint of a Test Manager looking at defects or a Development Manager looking at versions.) The perspective will determine what is to be the Control and what is providing the Feedback for the analysis.

B. Identify what is controlling the environment.

C. Identify the Feedback components.

By identifying the controlling environment and the feedback elements, we can identify the parameters of the primary path.

D. Identify the conditions that would lead to an abort of the primary path.

The abort conditions can give us an insight into the limitations and boundaries the primary path must operate within.

E. Identify the processes the Control will use to manage the environment.

The interaction between the control and feedback elements can now be analyzed and the resulting information can be mapped into the Control Loop Diagram.

F. Identify the processes used when the Abort is given control.

An example of the CFA loop – control loop diagram relationship

The following CFA Loop and Control Loop Diagram exhibit the relationship between a Version Control/Defect Reporting CFA Loop (Figure 8) and its associated Control Loop Diagram (Table 2).

Figure 8 – CFA loop for version control/defect reporting

A Control Loop Diagram for the CFA Loop with a focus on Version Control as the Control element (see Table 2) should look similar to the following table (mapped during an analysis brainstorming session):

Table 2 – Control Loop Diagram

Control Charts have a very close relationship to the CFA Loop. Control Charts are used to provide a means of tracking the trend and condition of a specific measured item. The Control Chart (see Figure 9) uses the standard deviation of sampled items to determine whether the item is in-bounds (within acceptable conditions) or out of bounds (outside of acceptable conditions). The +3s is also identified as the Upper Defined-Control Limit or UDL. The -3s is also known as the Lower Defined-Control Limit or LDL.

Figure 9 – Control chart limits

Those items that are in bounds are considered to be in control (see Figure 10). They can be the Control element of the CFA Loop.

Figure 10 – Control chart in-bounds area

Those items that are out of bounds are said to be out of control (see Figure 11). The out of bounds areas can also be identified as the Abort element of the CFA Loop.

Figure 11 – Control chart out-of-bounds area

Remember that it was mentioned earlier in this document that the CFA Loop and the Control Chart share the similar functions, the difference is in the use and objectives. We have already seen the Control and Abort similarities.

Let’s look at a Control Chart (see Figure 12) and compare the information in the Control Chart with the CFA Loop elements.

Figure 12 – Control chart showing use

The ‘in bounds’ area is our Control element. As long as our data points, sometimes called items, are within the ‘in bounds’ area, we are said to be in control. The data points are the Feedback element. The ‘out of bounds’ areas are the Abort elements. Notice that data point 4 is in the ‘out of bounds’ area, which should lead to control being passed to the Abort element in order to take action to bring the future data points back into control. During the analysis of the system operation using the CFA Loop, the abort mechanism should have been clearly identified so that when the system goes out of bounds during operation, the alternate control should have been activated and the alternate action should be no surprise to the system designers.

The benefit of using control charts is due to its ability to report dynamic conditions of a system in operation. By data point 2, we should be able to see that if the data follows the trend set by the previous data points, the data will go out of control at some point. This ability to see the trend allows for the chart user to take early action to ensure that the system stays in control or to monitor automated abort processes used to bring the system back into control.