Using requirements planning in embedded systems design: Part 4 - Defining the system-level design

If all of the steps in Part 1, Part 2 and Part 3 have been followed, the system level of the design has been generated. All the information has been retrieved from the requirements document, and the designer should have a clear picture of how the design must operate.

What happens now is the top, or system, level definition of the system.

Tasks will be created and the various functions will be assigned to them. A communications plan will be developed to handle data transfers between the tasks. A system timing analysis will be performed to determine the system timing tick.

The system modes and priorities will be analyzed, and a system-level error detection and handling system will be defined. Basically, a complete high-level blueprint for the system will be generated, with module specifications for each of the tasks and major systems in the design.

Task Definition
The first step in the system-level design is task definition. Task definition is the process of gathering the various software functions from the requirements document dissection together and grouping them into a minimal number of tasks. Each task will be a separate execution module, with its own specific timing, priority, and communications pathways.

Because of this, the functions within the module must be compatible, or at least capable of operating without interfering with one another. Now a typical question at this point is “Why a minimal number of tasks—why not create a task for every function?”

That would eliminate the need to determine whether or not the various functions are compatible. However, there are two main problems: overhead and synchronization. Overhead is the amount of additional code required to manage a function, the switch statement, the timing handler, and any input/output routines required for communications.

Synchronization is the need for some of the software functions to coordinate their function with other functions in the system. Placing compatible functions into a single task accomplishes both goals, the overhead for a group of functions is combined into a single task, and because the functions share a common task, they can coordinate activities without complex handshaking.

An example would be combining a cursor function and a display-scanning function into a common task. Putting the two functions together reduces the additional code by half, and it allows the designers to coordinate their activity by combining them into a single execution string.

In this context, there are valid reasons why some of the functions should be combined into a common task. This is not to say that all software functions should be combined into common tasks.

After all, the whole purpose of this design methodology is to generate software that can execute more than one task simultaneously. And there are very good reasons why some software functions are so incompatible that they can’t or shouldn’t be combined into a common task. Part of task definition is to analyze the various software functions and determine which, if any, functions should be combined.

So, how does a designer decide which functions are compatible and which are not? The simplest method is to start combining similar functions into tasks, and then determine if the combination is compatible.

To do this, start by writing the name of each function on a piece of tape. Drafting tape works best because it is designed to be stuck down and taken up repeatedly without much trouble.

Next, take a large piece of paper and draw 10–15 large circles on it, each about 5–8 inches in diameter. The placement of the circles is not critical; just distribute them evenly on the paper. Then take the strips of tape with the function names, and place them within the circle on the sheet of paper. Try to group like functions together, and try to limit the number of circles used.

Don’t worry at this point if some circles have more names inside than others do. We are just trying to generate a preliminary distribution of the functions.

Once all the functions have been distributed into the circles on the paper, take a pencil (not a pen) and name the circles that have pieces of tape in them. Use a name that is generally descriptive of the collection of functions within the circle.

For example, if a circle contains several functions associated with interpreting and executing user commands, then COMMAND would be a good label. Try not to be too specific, as the exact mix of functions will most likely change over the course of the analysis for compatibility.

And don’t be concerned if all the functions are moved out of a specific circle. The names are just for convenience at this point. The final naming and grouping of functions will be decided at the end of the process.

Now that a preliminary grouping is complete, we can begin evaluating the compatibility of the various software functions within each circle. The first step in the process is to place the strips of tape equidistant around the circumference of the circle.

If there is not enough room for the tape to lay along the circle, place it on the circle, extending out radially like a star. Next, draw a line from each function to all of the other functions, and then repeat the process for any functions that are not connected to all the other functions.

This web of lines defines all the possible relationships between all the functions in the circle, one line for each relationship.

Now that we know all the different combinations to examine, we need a set of basic criteria on which to base our decisions. The criteria will be based on timing, priorities, and functionality.

However, the designer should remember that the criteria are just guidelines, not hard and fast rules. The final choice will come down to a judgment call on the part of the designers as to which functions should be combined.

For some functions there will be one criterion that states that two functions should be combined, and another that states they should not. This should not come as a surprise; no single set of rules will apply to 100% of all designs. When this happens, the designer should review the reasons given for compatibility and incompatibility and decide which is more important.

For example, two functions could have completely different timing and priorities, which would demand that they couldn’t be combined. However, if they are also mutually exclusive in execution (they never execute at the same time), then they could be combined into a common task without conflict.

The task will simply have to adjust its timing and priority level based on which function is currently active. It would then be up to the designer to decide whether the combination is worth the trouble, or if one or both of the functions should be shifted to another task.

(Note: If two functions are combined against the recommendation of one or more criteria, the designer should note the reason in the design notes and make sure that the verbiage is included in the header comments for the resulting task. This will save any later engineer the trouble of determining why one of the compatibility criteria was disregarded.)

If the designer finds a function that is incompatible with most or all of the other functions in a circle, it should be moved to another circle with similar functions, and evaluated there.

The new circle should be an existing named task, but if it cannot be placed in an existing circle, it can be placed in a new empty circle as a last resort. Remember, we are trying to minimize the total number of tasks, but if the function is completely incompatible, it needs to have its own task.

There will also be cases in which a function should be separated into its own task for priority reasons, specifically if the task is intermittent in operation. Sometimes a priority handler that can make use of this lone function characteristic to reduce the processing load on the system. Against that possibility, the intermittent task should be labeled and set within its own circle for later evaluation.