- A History of Increasing Complexity
- Mechatronic System Organization
- Amplifiers and Isolation
- Scope: The Unit Machine
- Control
- Real-Time Software
- Nasty Software Properties
- Engineering Design and Computational Performance
- Control System Organization
- Software Portability
- Operator Interface
- Multicomputer Systems: Communication
- The Design and Implementation Process
This chapter is from the book
This chapter is from the book
This chapter is from the book
1.13 The Design and Implementation Process
In the best of circumstances, the design of the control system will be completely integrated with the design of the physical target system itself, a process sometimes called control-configured design. In this way, control system considerations can be built in from the start, resulting in systems that perform better and are more reliable. Probably more often, the design of the target system is complete, and perhaps even built, before the control system design is started.
1.13.1 Performance Specification
In either case, the control system design process starts with an assessment of the system complexity and a judgment as to whether its operational goals are attainable. Given an aPrmative judgment, a detailed performance specification is produced.
This starts from the original design goals of the target product, but will add spec-ifications on startup and shutdown, transient behavior, response to disturbances, detection and response to system faults, safety, operator functions, maintenance modes, and so on. For projects in which the target system and control systems are designed simultaneously, this process often reveals ways in which changes in the basic system design can make control much easier to apply. Issues such as the types of motors and other actuators used, means of coupling power delivery to the target for the power, and decisions on use of software-based coordination versus mechanical couplings all relate strongly to control system design decisions.
Approval of the specification by all concerned parties is a major design step. It aPrms in detail how the system is expected to behave. This specification is different from the original specification in most cases because the original specification is concerned mostly with productivity issues—how many or how much will be made and what quality level will be maintained. The control system specification contains much more because it considers all modes of system operation, not just normal production mode.
This specification is the basis for the control system software design. It also is the basis for control system acceptance testing. Development of an acceptance test at this stage is crucial. Otherwise, a divergence of expectations can cause real frustration and disappointment as the project nears its delivery date. Changes in the specification or acceptance tests need to be negotiated and agreed on as they arise.
Concurrent control system and target system design shows its benefits as early as the development of the performance specification. With control engineering input at this stage, unnecessarily strict specification items can be ameliorated and areas where performance can be improved without significant cost increases can also be identified. Unnecessary strictness usually refers to situations in which the cost is very high to achieve small increments in performance.
With the specification in hand, the rest of the design and implementation process becomes a series of translation and test steps, with each step either getting closer to the final product or causing a reversal to the previous step because of unexpected problems that were found.
A warning about testing: It's hard! Testing your own creation to destruction and finding faults in your own design are very diPcult. Human nature is against it and as the designer, you know too much! Independent testing or quality control groups do a better job, but even in that case, colleagues and friends are involved. That said, continuous "tough" testing will perform wonders toward creation of a reliable and safe product on a predictable timetable.
1.13.2 Design Documentation
The first step in this process is to develop a formal design document. While the specification must be complete enough to fully describe the system's operation and specify the acceptance testing procedures, it does not generally describe the detailed operation of the control system. A formal design document does this using some sort of modular organization, often combined with one or more diagrammatic notations to describe data flow, operational modes, and so forth. The formal design documentation describes the system engineering aspect of the control system, as discussed in section 1.9. In addition to the functional description, it also must specify tolerances for accuracy of calculations, timing of responses to events, precision of external signal conversions, and other such issues that will affect performance.
Design review represents the testing stage for the formal design documentation. Despite its detailed nature, the methodology used for the design documentation must be simple enough to be understood by a wide spectrum of concerned individuals, not just engineers and programmers. A comprehensive design review at this stage will expose a surprising number of misunderstandings and conflicting expectations as to how the system should behave. Reconciling these differences early is incalculably valuable!
1.13.3 Simulation
Simulation should be the next step—"should" is used advisedly, because the simulation step is often skipped. Although it is hard to pin down properly controlled studies, there is reasonably wide belief that including a simulation step in the design process is an overall time saver. There are two reasons for skipping a simulation stage. First, in order to simulate the control system operation, the target system must be simulated. Taking the time to simulate the target system can seem to be an unneeded delay in getting the job done. Second, there may not be a suitable portable environment for implementing a simulation. Thus, when the simulation is done, the control software will have to be translated into another implementation medium.
The first argument is false economy. Any problems uncovered in the friendly environment of simulation can be solved far more economically than in the real physical environment. Even one such problem can probably more than pay for the cost of developing the simulation. Because any variables within a simulation can be logged and examined (i.e., the simulated system can be exhaustively instrumented), and because the asynchronous nature of the real system is simulated in a strictly synchronous computing environment, performance issues, computational sensitivities, unduly tight synchronization tolerances, logical errors in the design, unexpected interactions, and so on, can be found with relative ease. Fixing them may also be relatively easy, or may require extensive discussion, return to the design documentation stage, or even renegotiation of the performance specification.
The second argument has more merit, but even the cost of rewriting the control software is probably outweighed by the advantages of doing a simulation. The two ends of this spectrum are when the simulation is complex enough to need a dedicated simulation environment which does not readily interface with the language of the control software and when the control system software will use a proprietary environment such as a real-time operating system or programmable logic controller (PLC) that is not readily reproduced on a general-purpose computational system (PC or workstation). Avoiding this situation if at all possible is a reason why control software portability is a priority in picking implementation tools.
Simulation is particularly important when the control system is in concurrent development with the target of the control. Not only is the actual system not yet built and thus not available for software development use, but lessons learned in testing the simulation can be fed back to the target system design process.
Testing the simulation starts with validation of the simulation of the target system. The nature of the testing is dependent on the level of detail of the model. The general rule is to use no more detail in the model than is necessary to test the control software.1 Much more detailed models will probably be used by the target system designers, but for different purposes. Only when the control system has been validated against this simple model should it be integrated with the more complex model for use in concurrent system design.
With the simulation validated, the simulated control system software is first tested on a module-by-module basis. Tests should follow the performance speci-fications as well as the design documentation and should include exceptional circumstances as well as normal operation. After module-level testing is complete, the module integration is started, one module or as few modules at a time as possible. Again, testing at each stage follows the same guidelines used for module testing.
1.13.4 Laboratory Prototype
"There's many a slip twixt the cup and the lip" (from Greek mythology2). As valuable as simulation is, it doesn't tell the whole story. The next stage of testing utilizes laboratory conditions and equipment to test what has been learned from simulation on real hardware. Laboratory computers provide an excellent platform for this stage because of easy programmability, powerful processors, and large numbers of readily available products that can be used for software development, testing, and visualization. Problems resulting from asynchronous behavior, noisy signals, external interference, grounding problems, and less than ideal behavior of the target hardware all are exposed during this process. Production system economics are not a major issue, although some estimation of the computing resources that will be needed for the production system can be determined.
Testing follows the same model as was used for the simulation. The wide variety of analytic and data visualization tools available should be exploited to the fullest for diagnostic purposes. Easy file creation, network connectivity, and other convenient tools allow control system engineers to draw on skills throughout the organization to solve the diPcult problems.
1.13.5 Production Prototype
The choice of a production computational environment is dominated by economics. The economics is a trade-off among the cost per unit of the computing hardware, the amortized cost of software development, and the value of short time to market. The result of the tradeoff is dramatically affected by the number of units expected to be produced.
Very large production runs magnify the importance of computing hardware cost. Hardware cost is minimized by using computing hardware with the minimum amount of specialty processing (such as floating point math hardware) and by making sure the maximum proportion of CPU cycles are used productively with the minimum memory footprint. This is inimical to rapid software development. Optimizing software for full CPU usage and doing mathematics (for example, a PID (proportional-integral-derivative) controller or a filter) with integer arithmetic add substantially to the software development cost.
Time to market is the joker in this deck. For systems with low numbers of units produced and high cost per unit, using powerful production computing facilities is consistent with both overall cost reduction and minimizing time to market. For high unit productions systems, however, these goals are in conflict. A hybrid solution that is possible is some cases where time to market is critically important and production runs will be very large, is to use more powerful computing resources in early production units, accepting less margin in return for rapid market entry, replacing the computer with a more highly optimized version later.
The target processor for the production prototype phase will have the same computing capability as the final production version, but substantially better diagnostic capability. It may also not fit in the same space as the final production unit.3 Depending on the relative capabilities of the production target processor and the laboratory computer, there may be a substantial amount of software modification for this stage (or not, if the system under development is, for example, an expensive machine destined for a high production manufacturing environment). Once that has been done, the test cycle is essentially the same as for previous stages. In this case, however, the data acquisition and analysis tools will be much more primitive so more effort will have to be devoted to that process. If software changes have been made at this stage (for example, switching from floating point math to integer math) special attention will have to be paid to those parts of the control system affected by the changes.
1.13.6 Production System
Many of the problems during the development of the production version of the control system are physical. The preproduction prototyping should have validated the production software since its computing environment should be nearly identical to the production computer. The physical environment is considerably different, however. Changes in component configuration, wiring, and other details can cause unexpected problems. Diagnosis and debugging is yet more diPcult than at the production prototype stage because the production computer system has been optimized for cost, so the extra diagnostic facilities have been removed.
If this design procedure has been followed rigorously, however, the commissioning process should be straightforward. Because diagnosis and debugging are so diPcult at this stage, the importance of control system refinement and debugging at earlier stages is readily apparent. In addition, with concurrent design of the control and the target, many problems have been removed at the source through redesign.
1.13.7 Maintenance
Product release is the climax, but, reality is maintenance! For much commercial software, maintenance is the largest part of the total cost of the software over its commercial lifetime. The best way to control the cost of maintenance is through careful execution of the design process. Poor design and the resulting haphazard implementation inflate maintenance costs exponentially. First, the software does not work properly on release. Poor specification and testing mean that it probably only works for the few situations that were run in the development lab. Once in customers' hands, however, the software must function in circumstances that were never tested or anticipated. It is no surprise that, for many of these situations, the control system fails and the machine malfunctions. This leads to the worst kind of debugging—under the gun (and perhaps at the customer's work site).
Even under the best of circumstances there is maintenance to be done. While the number of outright failures will be much lower if the control system software has been properly designed and implemented, customers will inevitably find ways of using the product that were not part of the original plan. These will require software upgrades and bug fixes in the period immediately following product release.
The bottom line (both literally and figuratively) is that effective long-term use of control system software depends heavily on the utilization of consistent design procedures, appropriate to the level of complexity of the software. This is just as true for the mental health of the engineers responsible for the maintenance!