Using requirements planning in embedded systems design: Part 5 - Managing communications between tasks

The next step in the system level of the design described in Part 1, Part 2, Part 3 and Part 4 of this series is to map out the communications between the various tasks and peripherals in the system. This accomplishes a couple of things for the design.

1) It helps provide the designer with a rough estimate on the amount of data memory that the system will require   

2) It defines all of the variables in the system, which is not specific to a task so they can be defined in a common header file.

3) It provides a quick check for a very troublesome systemic communications problem called state lock.

The method employed to generate the communications plan is graphical, just like the method used in the task definition phase of the system-level design. The type of diagram used to map out the communications pathways is called a data flow diagram.

It consists of a collection of 1- to 2-inch circles, each circle representing a peripheral or task within the system. The circles will be the sources and destinations for information moving around the system.

Between the circle are arrows that represent the data pathways along which the information will flow. The direction of the arrow indicates the direction of the data flow. The resulting diagram should show graphically all the communications between the various tasks within the system.

Any significant data storage associated with the various tasks are also noted on the diagram. A variable list and dictionary is then compiled, based on the information in the data flow diagram. The resulting documentation will then form the basis of all system-level variable definitions. So, designers are encouraged to be as accurate as possible in both the diagram and the resulting variable documentation.

(Note: The usefulness of the data flow diagram does not end once the variable list and dictionary is completed. It also a graphical representation of all system-level data storage that is a convenient reference diagram during the component and implementation phases of the design.)

To start the diagram, take large piece of paper and draw a 2- to 3-inch circle for each of the tasks and peripherals in the system. Try to evenly space the circles on the entire sheet, with as much space between the circles as possible. Then, label each circle with the name of its associated task or peripheral.

(Note: Don’t try to optimize the placement of the circle at this point in the design, as the diagram will be revised at least once during the course of this exercise. Just make sure that there is a circle for each source and destination for data in the system.)

For systems that link two or more subsystems by communications pathways, place circles in the diagram for the tasks in both systems. Separate them on the diagram, with a boundary line to show the separation of the two systems, and label the tasks charged with communications between the systems. A short heavy line is used to indicate the system-to-system communications pathway.

Once all the circles have been placed on the diagram, use the communications information from requirements document dissection and the function listing in the task list, to draw arrows between the circles to represent information passed between the various tasks and peripherals. The arrows denote the various task-to-task and task-to-peripheral communication pathways.

Start the arrow at the circle representing the task, which contains the sending function, and place the head of the arrow on the circle representing the task, which contains the receiving function. Each of the arrows should then be labeled with a name descriptive of the information being passed along the pathway. Figure 3.12 below shows an example of a data flow diagram for our alarm clock project.

Figure 3.12: Alarm Clock Data Flow Diagram.

(Note: The direction of the arrow should indicate the direction of the information flow. Some data pathways may have handshaking flags, which will pass in both directions as part of their communication. However, the direction of the arrow in this diagram is to indicate the direction of the actual communications, so even though handshaking may return, the direction of interest is the direction in which information is actually moving.)

For pathways that transfer information from one sending task to multiple receiving tasks, start each pathway arrow at the same point on the sending task’s circle to indicate that the same information is being sent to multiple destinations. Then, place the head of each arrow on the circle of each receiving task. Figure 3-4a below shows this form of data pathway.

Figure 3.13(a): One Source, Multiple Destinations.

It is also acceptable to branch an arrow off from an existing arrow, partway down its length. In fact, a very handy method of showing the distribution of data from one task to multiple other tasks is to create pseudo distribution bus in the diagram, originating at the sending task, with arrows branching off to the receiving tasks as it passes near.

Our only purpose here is to clearly indicate that multiple receivers are listening to a common sending task. There are no hard and fast rules to the diagram, and the designer is encouraged to generate whatever form of shorthand is convenient.

In the very likely event that the diagram starts to become cluttered and confusing, try overwriting the pathways with different color pens to distinguish one pathway from another in the diagram. Be careful not to overwrite two crossing pathways with the same color as this will only add to the confusion. Also, make sure that pathway arrows only cross at right angles, to further reduce confusion.

If the diagram becomes too cluttered or confusing, it is perfectly acceptable to redraw it on a larger piece of paper and relocate the circles that are causing the problem. Remember, I did say that we would be redrawing this diagram at least once, and probably more than once.

Plus, after making a few of the pathway connections, the designer will have a better feel for where the task and peripheral circles should be located to simplify the connections. Just remember to follow same procedure and verify that no pathways are inadvertently left off the diagram.