The Design Process

The design process is illustrated in Figure 2.1. This figure is based on our experience developing multiple and diverse embedded control systems from stereo amplifier controllers, to autonomous robots, to industrial gate controllers. We employ a running scenario to illustrate the design process.

Scenario: You have been hired as a consultant by a small engineering firm that designs and manufactures industrial gate controllers such as those found at parking lots to control access.

The firm has been successfully manufacturing the controllers for a number of years based on analog Application Specific Integrated Circuit (ASIC) technology. ASIC technology is based on custom designed integrated circuits. Fabrication of an ASIC device usually requires a lead time of 6 months and a large set up cost to turn out the first custom IC. From then the cost of the IC is amortized over the production run of the IC.

Establish detailed system requirements

Review system description to determine HW and SW partition

and interface

Thoroughly document system operation via Structure Chart, UML Activity Diagrams, schematic

test plan, comments, etc.

Correct and refine system and test plan

yes

no System performs

correctly and meets all requirements?

Obtain detailed system description

Use structure chart to partition system into black boxes

Work out details of program flow with UML activity diagram

Develop first iteration of code from UML activity diagram

Construct safe, low power HW test bench to simulate system

Develop test plan to exhaustively verify system requirements

Compile, download, and execute program

Exhaustively test system based on test plan

FIGURE 2.1: The design process

THE DESIGN AND DEVELOPMENT PROCESS 17

The president of the company, a gifted analog design engineer, has contacted you to convert the company’s proprietary control algorithms from an analog (operational amplifier) implementation to a microcontroller-based system. The president is intrigued by the short lead time to develop a microcontroller-based project and the ability to customize each algorithm design if need be. You have had several meetings to discuss the overall picture of how the gate controller will operate. You have received a ten page text document describing what the controller is supposed to do. The motor used to open and close the gate in this specific application is a large, high power direct current motor. You will be using pulse width modulation (PWM) techniques to activate the motor. You are responsible for implementing the control algorithm.

All of the details concerning interfacing the low power microcontroller to the gate control hardware are being handled by another engineer.

Theory: Where do you begin on such a difficult, complex project? A natural reaction might be to panic. Instead, constructively use your creative energy to logically and methodically overcome the design challenge by the design process provided in Figure 2.1.

For starters you should gather all of the available information on the desired system.

You already have a lengthy project description to read and absorb. As you read through the documentation make a list of questions where answers are not covered in the description. The answers should be obtained from the president and the other engineer who is working the project interface issues. You may end up iterating multiple times with the company representatives to develop the overall system description. This would also be a good time to do some homework and review concepts that are unfamiliar to you. For example, if you are not familiar with PWM motor control techniques, now would be a good time to review the concepts. Today, considerable technical background information may be obtained from the Internet.

Once you have absorbed all of the information, you should develop a detailed list of system requirements. In other words, what is the system supposed to do. For a microcontroller-based system, it is often helpful to take a scenario-microcontroller-based approach. That is, you provide a list of required system activities and what the controller is supposed to do for each of these activities.

Scenario: In the case of the gate control system, the gate will be activated by a number of pushbutton switches including open, close, emergency open, system lock, and emergency shutdown. For each of these inputs, you should develop a detailed list of required actions. Your requirements list should also include how the system will react to other circumstances such as a malfunctioning gate, an incorrect input sequence (pushing the gate close button when the gate is already closed), and also an incorrect sequence of inputs (two pushbuttons depressed at the same time).

Theory: Once the requirements list is completed (you will probably add additional require-ments as the project progresses), you will actually begin trying to figure out how to implement the design. An effective tool to start partitioning the design is based on the techniques of top-down design, bottom-up implementation. In this approach, you start with the overall system and begin to partition it into systems. At this point of the design, you are not concerned with how the design will be accomplished but how the different pieces of the project will fit together.

A handy tool to use at this design stage is the structure chart. The structure chart shows the hierarchy of how system hardware and software components will interact and interface with one another. You should continue partitioning system activity until each subsystem in the structure chart has a single definable function.

Scenario: A structure chart for the gate controller is provided in Figure 2.2. As you can see the main functions are partitioned into subsystems. These functions are further subdivided into their constituent parts.

Initialize system - Variables - PORTs

PWM open profile Monitor for

open limit

Monitor motor safety Process switch/

menu input

Input valid for at least 50 ms

Open_ gate

Close_ gate Emergency_open

FIGURE 2.2: The structure chart for a gate controller

THE DESIGN AND DEVELOPMENT PROCESS 19

Theory: In a microcontroller-based system, many tasks can be accomplished in hardware or software or a combination of both. At this step in the design you need to decide how different portions of the design will be implemented. In general a hardware-based solution is typically faster; however, it is inflexible. On the other hand, a software-based solution is typically slower, but is easily adapted for specific applications.

Scenario: The gate control design is a good example where we let the microcontroller do the majority of the processing. Since the microcontroller will be controlling a slow mechanical system (which is often the case), speed is not a primary concern. Therefore, we will shift as much of the control algorithm to the microcontroller as possible.

Theory: The next step in the design process is to start working out the details of the operation of each subsystem we previously identified. Rather than beginning to code each subsystem as a function, we will work out the information and control flow of each subsystem using another design tool: the Unified Modeling Language (UML) activity diagram. The activity diagram is simply a UML compliant flow chart. UML is a standardized method of documenting systems.

The activity diagram is one of the many tools available from UML to document system design and operation. The basic symbols used in a UML activity diagram for a microcontroller-based system are provided in Figure 2.3.

Starting activity

Transfer

of control Final state

Action state Branch

FIGURE 2.3: UML activity diagram symbols

As we begin developing the UML activity diagrams for the system we can use a top-down, bottom-up, or a , hybrid approach. In the top-down approach, we would begin by modeling the overall flow of the algorithm from a high level. If we choose to use the bottom-up approach, we would begin at the bottom of the structure chart and choose a subsystem for flow modeling.

The specific course of the action chosen depends on the specific project. Often, a combination of both techniques, a hybrid approach, is used. You should work out all algorithm details at the UML activity diagram level prior to coding any software. If you cannot explain system operation at this higher level first, you have no business being down in the detail of the code.

Therefore, the UML activity diagram should be of sufficient detail so that you can code the algorithm directly from it.

Scenario: In our gate controller design we will employ a hybrid approach. We will first model the flow of how the system will respond to the pushbutton switches and develop a menu-based flow to incorporate different pushbutton activity. This is top-down design. We will also work on some of the more complicated subsystems to insure that some of the more challenging technical issues are resolved early in the design process. For example, we will model the flow of the PWM motor control algorithm. A sample of both is provided in Figure 2.4. The details of the specific application illustrated in the figure are not important. What you need to take from these diagrams is the level of detail provided.

Theory: Once the UML activity diagram is completed for the entire project, then coding may commence. Here the detailed algorithms are committed to a microcontroller compatible language (typically C or assembly language.) The C language has the advantage of portability between processors, reusability, readability, and coding efficiency. Assembly language is not portable and is not easy to read; however, applications originally coded in assembly language typically execute faster than those originally coded in C. We recommend C for all but the most time sensitive applications. Again a top-down, bottom-up, or hybrid approach should be followed.

Scenario: For the gate control project, a hybrid approach would be a wise choice. The menuing software could be first written and tested. This would provide a framework for activating the remaining low-level functions in an orderly manner. The lower level functions should be written and individually tested and incrementally brought on line.

Theory: How do you test a microcontroller-based system that will be controlling high power and/or expensive hardware? It is a bit of a dilemma. You need to test the code in actual hard-ware to insure it operates correctly and the interface between the hardhard-ware and softhard-ware is correct However, you might be reluctant to put untested software in an actual hardware control

switch(new_PORTB) {

case 0x01: process_valid_input();

pwm_open( );

case 0x80: process_valid_input();

system_shutdown();

keep_going = 0;

break;

default: ; //all other cases }//end switch

old_PORTB=new_PORTB; //update PORTB keep_going = 1?

FIGURE 2.4: A hybrid approach to gate design. The UML activity diagram is provided for the menuing algorithm and also the low level PWM motor control algorithm. The details of the specific application illustrated in the figure are not important. What you need to take from these diagrams is the level of detail provided

21

Vcc = 5.0 V

FIGURE 2.5: Low cost hardware simulator

system until you are sure it operates correctly. What to do? A low cost hardware simulator will serve as a stand-in for the actual expensive hardware system until you are sure the software is operating correctly. An inexpensive hardware simulator is illustrated in Figure 2.5. System inputs can be simulated with low cost tact or dual inline package (DIP) switches. Output control signals can be viewed by illuminating light-emitting diodes (LEDs). Also, in certain applications you can monitor the output signals with an oscilloscope or a multichannel logic analyzer. Also, sending status “prints” to a host PC or a liquid crystal display (LCD) from the microcontroller is an effective method of displaying ongoing status during algorithm testing.

Scenario: For the gate control algorithm, system inputs can be simulated with low cost tact switch inputs. System output control signals may be sent to LEDs to indicate system status during program execution. Feedback signals from the actual gate hardware can be simulated with potentiometers for analog signals and switches for digital signals. The PWM signals may be verified with an oscilloscope or logic analyzer.

THE DESIGN AND DEVELOPMENT PROCESS 23

Theory: Once a low cost simulator has been developed to test the system, a detailed test plan must be developed. Tests should be developed to verify that the system meets all of its requirements and also intended system performance in an operational environment. The test plan should also include scenarios in which the system is used in an unintended manner. As before a top-down, bottom-up, or hybrid approach can be used to test the system.

Once the test plan is completed, actual testing may commence. The results of each test should be carefully documented. As you go through the test plan you will probably uncover a number of run time errors in your algorithm. After you correct a run time error, the entire test plan must be performed again. This insures that the new fix does not have an unintended affect on another part of the system. Also, as you process through the test plan, you will probably think of other tests that were not included in the original test document. These tests should be added to the test plan. As you go through testing, realize that your final system is only as good as the test plan that supports it!

Once testing is completed, you might try another level of testing where you intentionally try to “jam up” the system. In other words, try to get your system to fail by trying combinations of inputs that were not part of the original design. A robust system should be intolerant to this type of testing. It is imperative that you design robustness into your system. When testing on a low cost simulator is complete, the entire test plan should be performed again with the actual system hardware. Once this is completed you should have a system that meets its requirements!

Scenario: For the gate controller testing a formal, exhaustive test plan was developed to document controller operation under approximately 50 different operational scenarios. The controller response to each scenario was carefully documented. When a run time error was discovered, it was corrected, and the test plan reaccomplished from the beginning. The scenarios covered anticipated operational scenarios as well as potential misuse of the system. This provided for a robust design. When the testing was completed, a prototype control unit was sent to the company for “jam up” testing. The goal was to test the system in an anticipated real world environment and try to get it to fail. Once this stage of testing was completed, the prototype controller was installed in an operational field unit and exhaustively tested in an actual operating environment.

Theory: With testing completed, the system design should be thoroughly documented. Much of the documentation will have already been accomplished during system development. Doc-umentation will include the system description, system requirements, the structure chart, the UML activity diagrams documenting program flow, the test plan, results of the test plan, system schematics, and properly documented code. To properly document code you should carefully comment all functions describing their operation, their inputs, and outputs. Also,

comments should be included within the body of the function describing key portions of the code. Enough detail should be provided such that code operation is obvious. It is also extremely helpful to provide variables and functions within your code names that describe their intended use.

You might think that completed system documentation is not worth the time or effort to complete it. Complete documentation pays rich dividends when it is time to modify or repair an existing system. Also, well-documented code may be often reused in other projects. This provides for the efficient and timely development of new systems.

Scenario: As mentioned earlier, good documentation pays rich dividends during the main-tenance phase of a deployed system. When a system update is required, it is easy to readily identify the portion of the system requiring update. Also, a properly documented system is readily adapted to new, similar designs. You just received an e-mail from the company presi-dent. He was so pleased with your first controller project that he has hired you to design three more similar systems.