Home > Articles > Hardware

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!

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020