As in the United States, applications of KB systems in Japan have evolved from mainly stand-alone systems for diagnostics to a wide variety of problem-solving domains. At the companies the JTEC team visited, we saw or were given evidence of many hundreds of diverse applications. With a few miscellaneous exceptions, all of these systems fall into one of the seven classes listed in Chapter 1.

The remainder of this section will discuss techniques employed for some of these classes of application and give a flavor for their prominence and diversity in Japan.

Diagnosis and Troubleshooting

Definition. Diagnostic systems comprise a broad range of applications that deduce faults and suggest corrective actions for a malfunctioning system or process. Numerous examples can be found in physical (electronic, mechanical, hydraulic, etc.) and biological domains, as well as in abstract domains such as organizations and software.

The functions of a diagnostic system typically include:

Most diagnostic systems automate only a subset of these functions, leaving the other functions to humans or other types of information systems. It is common, for example, for a process control computer to capture measurement data over time and reduce these raw data to metrics. These metrics are then used by that part of the diagnostic system that is implemented with knowledge processing techniques. The capability of learning from past experience is rarely found. Diagnostic systems or classification systems made up a high proportion of the earliest knowledge systems. While the emphasis has now shifted toward planning and scheduling systems which often produce greater benefits, diagnostic systems still comprise 35-40 percent of the total number of fielded systems (Nikkei AI 1992). It is likely that diagnostic systems will continue to represent a substantial proportion of knowledge system applications because tool vendors have produced a number of task-specific shells for diagnostic applications. This will make the development task easier and will broaden the base of people capable of developing diagnostic applications.

Applications. Electromechanical systems are probably the most common domain of diagnostic applications. The JTEC team learned about major applications in electrical distribution system fault isolation, nuclear power plant diagnosis, telephone cross bar switch diagnosis and subway air conditioning diagnosis. Each of these are large systems with substantial benefits. One application at Nippon Steel handles 500 different kinds of electromechanical equipment comprising 25,000 component types (Minami and Hirata 1991).

Japanese steel producers have developed a number of diagnostic expert systems. One important application is the determination of the current state and trends in blast furnaces (see Case 3 earlier in this chapter). While not a complete diagnostic system, the characterization of "state" is the first step in a diagnostic system.

Several applications in the domain of computer systems were mentioned by the Japanese computer manufacturers. These included determining the best means to recover from system failures, and offering advice on software debugging.

In construction, determining the cause of concrete cracking has been automated (Obayashi Corp.). Applications in medical diagnosis and finance were mentioned, but not detailed.

The benefits from diagnostic applications include reduced down time, safe recovery from failures, and accumulation or preservation of knowledge. In the latter case, it was specifically mentioned that the more educated young Japanese do not want to make their careers in certain operational jobs. Capturing knowledge of experienced workers today is essential to future operations using less educated labor. In one case, "the cross bar switch diagnostician," the application avoids the necessity of training replacement personnel for this obsolete equipment.

A number of task-specific shells have been developed for diagnostic applications. These are identified and described in Chapter 3. Research and development in support of diagnostic tasks has resulted in the many task-specific shells reported in that chapter. This work is continuing with emphasis on new forms of diagnostic reasoning. One particularly interesting research effort is a Toshiba project to diagnose unanticipated faults. A conventional heuristic expert system receives data about the system and diagnoses anticipated faults in a conventional way (using shallow knowledge that directly associates symptoms with likely faults). When it is unable to identify the problem, the knowledge system defers to a model-based reasoning subsystem which attempts to reason from first principles. That subsystem in turn utilizes a qualitative, fuzzy simulator to try out hypotheses and further reason from the simulated results.

Planning and Scheduling

A strong emphasis on this class of systems was apparent at many of the sites we visited. Using corporate estimates, somewhere between 30-50 percent of fielded KB systems in Japan focus on planning or scheduling, with a significant recent trend toward more applications. This may be because such systems are used routinely -- factory and airline schedules are created every day, week, or month -- and success is relatively easy to measure in terms of better schedules (the work-in-progress time or resources used to accomplish some tasks is less) or quicker production of schedules. Examples include:

All of the systems we were able to examine in detail used straightforward heuristic scheduling methods. As in the JAL application described above, constraints were described in some formal manner and used to guide an initial placement of tasks, with the most constrained tasks usually scheduled first. Then a variety of straightforward backtracking methods (sometimes called schedule shuffling) were used until a complete and correct schedule was found. In most cases, a complete and correct schedule was good enough; there was little emphasis on optimization of schedules.

While several sites mentioned a need for reactive re-scheduling methods, we did not observe a currently operational system with those capabilities. However, the elevator-group control system described below may be considered an example of a highly reactive scheduling system. Within the United States, iterative improvement methods like simulated annealing are now being used to effectuate "anytime" re-scheduling. These methods very quickly produce a complete, but possibly poor, schedule, and improve the schedule until available time runs out, always maintaining a correct schedule when interrupted.

Configuration of Manufactured Objects from Subassemblies

The JTEC team saw very little application of ESs to configuration-type problems such as those that occur in design or manufacturing. The most prominent examples were the systems developed at Sekisui Heim for modular housing, discussed above, and a system developed at NTT for design of private telecommunication networks. Fujitsu is planning expert systems for computer integrated manufacturing (CIM), but did not elaborate. NEC has investigated rule-based and algorithmic approaches to LSI design and developed EXLOG, a system for synthesizing customized LSI circuits and gate arrays (Iwamoto, Fujita et al. 1991).

Process Monitoring and Control

The most significant example of a knowledge-based system for control was the one installed in 1987 at the NKK blast furnace, as described above. Since that time the steel and construction industries in Japan have been very active in developing knowledge-based control systems. These systems are characterized by their high degree of integration with conventional information processing systems and the widespread use of fuzzy control methods.

A second excellent example of a control system is one developed by Mitsubishi Electric for controlling a group of elevators. The AI-2100 Elevator-Group Control System, as it is called, uses a fuzzy rule base, divided into off-line and on-line types. Off-line rules are used as a sort of default set, independent of hall calls (i.e., the signals generated when passengers waiting in the halls push the up or down buttons). Off-line rules, for example, determine the number of elevators that should be near the ground floor, near the top, or near the middle of the building, depending on the time of day. On-line rules are invoked in response to hall calls, and aim to prevent bunching of cars in the same locations, thereby minimizing the average waiting time for passengers. Results of an extended simulation of a group of four elevators servicing a 15-story building revealed that the average waiting time was reduced by about 15 percent over a conventional elevator control system. The percentage of waits over 60 seconds dropped by almost a factor of two (Ujihara and Tsuji 1988). Since the degree of irritation felt by waiting passengers increases nonlinearly with waiting time, the reduction in psychological waiting time is quite significant. An optional feature of the system is a learning function, which allows the control system to adapt to changing traffic patterns and predict future conditions.

Examples from the construction industry of process monitoring and control KBSs are Obayashi Corporation's systems for automatic direction control of a shield tunneling machine and the swing cable control system (see site reports in Appendix E for more details).

Software Engineering

Applications of knowledge-based techniques to software engineering were one of the areas this JTEC panel was asked to cover. Improving the process of developing software is potentially one of the most highly leveraged applications for new technology.

Several Japanese companies indicated that 5-10 percent of their applications were in the development, testing or management of software. However, the panel's site visits were not structured to explore software engineering applications in any depth. We did not visit any software factories and we saw only three brief demonstrations of software-related applications. This in itself is an interesting outcome since several of the industrial research laboratories we visited had titles such as Software Engineering Research. Most research in those laboratories is focused upon new forms of software, as opposed to the use of knowledge-based techniques to support the development of conventional procedural software.

Applications. The examples the JTEC team saw included the generation of procedural programs from a state/event matrix and from a problem model. Both of these applications utilize transformation technology to transform a declarative specification into procedural code. Both operate at the individual program level, rather than the system level. With respect to the state of the art in the United States, there is nothing novel in either of these applications.

Another example was NEC's application of case-based reasoning to the retrieval of software quality improvement ideas. The case base has been developed over many years, which in itself is a unique contribution. Historically, the case base, which is company confidential, has been published in a book that is updated annually. However, the book has now become too large to be effective and an electronic case library has been established. The library indexes 130 attributes, and there are some clever techniques to minimize the number of index items which the user confronts. The JTEC team did not view this application as a convincing example of case-based reasoning, as there was no repair logic in the application. However, the main goal of the project was reformulation of the corporate knowledge to permit effective machine access, and the goal appears to have been successfully achieved.

At the University of Tokyo, Professor Ohsuga mentioned the possibility that knowledge- processing technology can be used to support conversion of declarative programs to procedural programs. The actual example we saw was the very small-scale program generator mentioned above.

Comparative Assessment with the U.S. None of the applications this JTEC team saw or heard about represent innovations beyond U.S. applications. The use of knowledge-based techniques for supporting the development of conventional software does not appear to be a priority task in the companies we visited.

Published: May 1993; WTEC Hyper-Librarian