Sensing and control systems’ best practices, for development and troubleshooting, usually result in faster, less costly and improved quality and product control systems.

Best practices have been defined in theHarvard Business Reviewas “straightforward, actionable advice for novice managers, seasoned leaders and people at all levels in between.” This definition emphasizes “actionable advice” over more rigid restrictive definitions requiring repeatable, replicable, nonidiosyncratic features.

Four practices stand out among those that I have seen applied successfully in system development.

1. Simplify/Relax Specifications in Planning Stage

For planning an online optical sensing system for quality and product control, with nine or 10 sensors and four local computers, I met with the technical folks. The goal was to improve the measurement system while improving the cost-benefit ratio without sacrificing performance.

One of the stated requirements was to sense and store data from all sensors every 10th second (or 100 milliseconds) including data processing, storage and monitor-display times. This number was plausible but apparently picked out of thin air. At this speed, each photosensing unit had to sense and provide other functions in a time span of less than 100 milliseconds.

The sum of the acquisition times for all photosensors must be less than 100 milliseconds. At least three standard imaging cameras (with acquisition times of 30 milliseconds each) were considered for determining ovality of a critical implantable medical component or a total of 90 milliseconds. In addition, sensing time for common industrial sensors is often 10 milliseconds or more.

With seven more single photosensors (possible acquisition times of these single industrial photosensors can be 10 milliseconds) the total acquisition time would be 90+70 or 160 milliseconds, which is greater than 100 milliseconds needed for total acquisition of 0.1 second (or 100 milliseconds). In addition, other operations have time requirements including inputting numbers into files, sensing data to a central computer for processing and storage, maintaining and changing the visual displays on a video monitor, self-calibrating procedures and self-monitoring procedures.

The initial design specifications could be made to work, with more complex, expensive hardware and software, and with attention paid to the actual response times. However, it appeared better to reduce costs and build in safety margins for existing issues, as well as allow for anticipated but unidentified new issues that often occur in new projects.

In a meeting with technical folks, I asked how long it takes, when the current system detected a problem, for corrective action to be taken. The reply: about 5 minutes.

I suggested that data be collected once per minute. Everyone agreed. This would significantly expand the time allowed for sensing, data processing, communications and display, as well as reduce the storage requirements without reducing functionality.

This, and other similar practical simplifications of specifications, reduced the cost of the system by more than 30%. It simplified hardware, software and development. It permitted some expansion of the system functionality. The system was completed and satisfactorily tested on schedule.

The system was completed, tested and used by production-line operators. It met the General Manufacturing Practices requirements and has been used satisfactorily for years with data collection taken from sensors once per minute.

2. Use a Master Craftsman During Troubleshooting of a Malfunctioning System

Having appropriate tools available during troubleshooting can increase effectiveness. Such tools should include a combination of appropriate human, testing and modification capabilities.

In particular, rapid, effective lower-cost troubleshooting has been obtained by having a master craftsman available during tests and redesigns. The master craftsman should have the tools and skills to modify components of the system as useful design changes are identified.

The system in question was an optical communication system used with a computer-controlled brain-surgery system to remove brain tumors. The patient’s head was imaged in three-dimensions by X-rays, and the image was saved digitally. The patient’s head was then mechanically held in place. The display monitor showed the saved image of the inside of the patient’s head as well as the superposed location of the tip of the surgical knife.

The position of the surgical knife was transmitted to a remote receiver, 5 to 10 feet away, using a light emitting diode source on the knife. However, the receiving optics of this communication system had been unreliable and the goal of this trouble-shooting was to identify and eliminate the cause.

The procedure was straightforward. Several functional tests were done on the communication receiver for different relative locations of the surgical knife and the receiving station.

I then proposed a modification of the receiving optics. The system engineer who had been working on the system showed me the system and the available resources.

The corporate master craftsman and I discussed the modifications that were thought to be required. This consisted of using the existing components to point out the perceived problem, providing a hand-drawn sketch and talking him through the modifications. Then the engineer and I left so that the master craftsman could work without interruption. He was encouraged to contact us if he had any further questions.

When we returned, the optics had been modified and inserted into the communication system: the system now worked in geometries which, before, had provided unreliable reception. Having shown that this approach was productive, we then went through two more modifications. Each modification improved the signal-to-noise ratio. Nominally, we were there.

I then was told to provide a report with calculations/computing results for what had been done, as well as for any additional modifications that might prove advantageous.

The real-time adjustment process of master craftsman work with the consultant shortened the time to bring this product to market. There was no proposal by me for system troubleshooting as well as designing, fabricating and testing the initial modifications. The proposal preparation and subsequent evaluation by the company can take weeks, if not months.

It helps to have faith in the expertise of the outside troubleshooter for this to work.

3. Use Practical Information on Operations and History

Hands-on experience and day-to-day operating issues can be obtained from engineers and on-line operators who work on quality systems. Be sure to schedule folks to talk with as early as is practical.

In one example, we had designed an online laser-based system to gage the diameter of red-hot tubes-several inches in diameter-that were coming out of an annealing furnace. The design was to be presented to managers of this manufacturing plant.

Before the meeting, I talked to the operations engineer. He told me that they had bought and tested a gaging system to do the job but that he had not seen it since the tests. On further questioning, he said that the only person at my presentation who knew about this was the plant manager.

I presented my design. Nothing unusual was mentioned. At the end, the attendees started to leave, and I approached the plant manager and asked him about the previously tested gaging system. He said that the previous system had burned up.

How could it have burned up? I had been told that there would be significant distance between the optical gaging system and the rapidly moving tubes being gaged. He said that to verify the measurement of the purchased system, they pulled a hot tube off line immediately after measurement and, using rollers, moved it to within several inches from the gaging system. The gaging system melted.

No one had mentioned this event, asked for a verification/calibration system for hot pipes or suggested that heat might be a problem. There are several simple straightforward solutions for such problems that avoid system meltdowns.

4. Control or Exploit the Competitive Corporate Environment

A highly competitive environment is generally the culture in system planning and development at many companies. Improving the employee’s advancement, real or imagined, takes precedence over the selecting the best route to achieving the immediate goal.

It is rare, but I saw one corporation where the corporate culture apparently was one of cooperation. This had emerged from the company’s founding with the corporate goal of improving medical care by improving medical devices. This was a goal in which folks took pride.

In addition, exploiting internal or external competition or a combination of both, outstanding systems can be developed. There are different scenarios for this.

Minimize competitive juices for a common good. In planning for development of a new quality control system for a critical medical device, one corporation formed a group consisting of highly qualified internal and external experts in all involved areas. In other companies, such discussions consisted primarily of attacks citing the weaknesses of the proposed suggestion.

The objectives were described and folks suggested different approaches followed by discussion. The participants suggested non-obvious means to improve the suggested systems using their technological expertise.

The company ethos was to do good by providing solutions that improved medical treatment. Everyone seemed to be proud of this and would spend extra effort and time in areas with which I had contact. This was true for development of quality inspection and control systems.

All suggestions were respectfully considered, and the combined expertise was used to improve all suggestions. This not only improved suggestions, but also encouraged folks to make suggestions that they felt might lead somewhere.

Use the cooperative team ethos where possible. Modify an overly competitive culture for productive ends.

Maximize competitive juices for a common good. Problems at a silicon integrated circuits manufacturing plant halted production. To address this, two different laboratories, at corporate R&D, were assigned the task of solving this problem, with the spoils to the winner. This fired the competitive juices of the engineers in both groups and the problem was solved in a short time. Here, exploiting the competitive approach provided successful rapid results.

Combine cooperation with competitive juices to defeat an internal threat. Easily the most outstanding example where internal cooperation and expertise, in response to an internal threat, led to the invention of the charge coupled device (CCD). The inventors Boyle and Smith won the Nobel Prize. Boyle and Smith were the lab director and department head of silicon/semiconductor development at Bell Labs. They were outstanding technologists and managers.

The threat arose from magnetic bubbles. A single, small magnetic domain, with polarization up or down to represent zero or one, could be moved in a material from one location to another. This permitted digital information to be transferred from one location in a material to another location and to be stored and sensed for polarity. This threatened semiconductor/silicon dominance in digital storage and communications. The threat, it is ironic to note, came from a competing group working on magnetic bubbles within the corporation.

Boyle and Smith met to size up the threat. They invented a means to move electrons from one location to another in silicon, using shaped and movable electric-potential wells that had the same features as the magnetic bubbles but were faster and in much-better developed material that had massive research and development done for silicon transistors. Silicon won: it was no contest.

The different practices discussed for obtaining faster, better development of sensing systems make use of available resources and different management environments. The successful examples discussed illustrate how to exploit or establish resources and how to exploit or modify existing attitudes/procedures to improve the work product.Q

Tech Tips

Four practices stand out among those that we have seen applied successfully in system development:

Simplify/relax specifications in planning stage.

Use a master craftsman during troubleshooting of malfunctioning system.

Use practical information on operations and history.

Control or exploit the competitive corporate environment.