The impact of a new technology like KB systems can be measured both by the depth and the breadth of its impact. Later in this chapter we discuss the breadth of KB systems applications that we observed in Japan. This section provides insight into the depth of KB systems impact by describing three examples of systems which appear to have made significant changes in the way in which organizations conduct their daily business. In all cases, KB technology was used to augment and replace traditional computational technology for reasons of speed, reliability, and quality of solutions.

Case 1: Modular House Configuration (Sekisui Heim)

The Company. Sekisui Heim is a housing division of Sekisui Chemical Company. Begun in 1947, Sekisui Chemical was the first to develop plastic molds in Japan. Its current annual revenue base is $1.35 billion, 50 percent of which comes from Sekisui Heim.

In 1971, Sekisui Chemical created the Heim division to build modular houses. Unlike prefabricated houses, modular houses are semi-custom houses designed and constructed out of modules. Sekisui Heim promises to have a house ready for occupancy in two months from the time a customer signs a contract with a design on hand. Of the two months, 40 days are allocated for on-site work -- from ground breaking to completion -- with a five-man crew. More than 80 percent of the house is built in a factory. Sekisui has six highly automated factories, each of which can complete enough components for a house every 40 minutes. The six factories are distributed throughout Japan to meet the special needs of the respective regions. Sekisui Heim, currently the fourth largest house builder in Japan, builds about 20,000 houses per year.

The Problem. A class of houses is designed by the Sekisui architects. Instances of the house can be constructed out of modules called units. The units come in six sizes (1.2 m and 2.4 m widths, and 3.6 m, 4.5 m, and 5.4 m lengths) that are designed to be transportable on trucks. The units can be subdivided into smaller compartments, placed side by side to form a larger compartment, or stacked to form multiple stories. Within the constraints imposed for a particular house class (e.g., a particular roof design may be required for a particular class), the customer can design a house to suit his or her desires and needs. A room can be of any size as long as it can be configured from the units; the exterior walls can be made from a variety of different materials such as stucco, hardwood, and cement; the openings between rooms can be of many different sizes; and so on.

The most popular class of houses is called Parfait, of which more than 45,000 units have been sold. It is a contemporary looking two-story house with a flat roof. For a house with a floor space of 1600 square feet, the average cost is about $69,000 -- a unit cost of less than $45/sq. ft.

After the house has been designed, all the necessary parts must be identified and delivered to the factory floor in a timely manner. An average house requires about 5000 unique parts. Sekisui has 300,000 different parts in stock. Prior to the installation of an expert system (to be described in the next section), every time a new house design was introduced, there was an error rate in parts selection of about 30 percent for the first six months. As time went on the error rate decreased to about 5 percent. The high initial error rate made the introduction of new products highly problematic, and the steady-state error rate of 5 percent cut into profits. Some kind of computer-based help was needed to make Heim a viable business.

In 1984 Sekisui heard about expert systems and made a strategic decision to invest in the technology. Since the company was not familiar with the technology, it bought a 70 percent share in a small start-up company, named ISAC (International Sekisui AI Corporation). ISAC was started by the developer of a PROLOG language called K-PROLOG, currently the best-selling PROLOG in Japan. ISAC does about 40 percent of its business with Sekisui, building applications for both for the housing division and for other parts of Sekisui Chemical.

Sekisui Heim formulated a long-range plan for the development of computer programs for its business. Three kinds of capabilities were envisioned which were to be integrated into a tool kit to help with the complete process from design to production of modular houses:

  1. An intelligent CAD tool to help with the development of new designs
  2. A room layout consultant and other consultation systems to help in sales
  3. Production control and other expert systems to help with the actual manufacture of units

The first expert system to be put in routine use, HAPPS, identifies and selects the necessary parts for a given house design and schedules the delivery of the parts to the right place on the factory floor at the right time. Sekisui Heim has also developed an expert system for sales personnel to help customers with room layouts, but it is experiencing limited acceptance by the sales force.

The HAPPS System. HAPPS is an expert system that selects and schedules the delivery to the factory floor of the correct parts for steel frame houses. There are two other versions for wood frame and high-rise houses, called TAPPS and MAPPS. Once the house design is finalized by the customer, it is passed on to the factory. There, various types of information about the house are entered into the system. The interface uses a number of menu-driven windows that display the 'legal' options available for different parts of the house. Figure 2.4 shows the different options for stairs. The display shows the layout of the rooms and available options as icons, making the specification easy and clear.

Figure 2.4. User Interface For Selecting Some Design Options

The necessary information for parts selection is gathered in the following order:

  1. House class name, house name, name code, address, etc.
  2. Sizes of the various units and their arrangements
  3. Eaves for first and second floor: type and color, position of gutter pipes
  4. Entry way and stairs: the shape and location of the entry way, the shape and position of the stairways, step-down location, if any; type of windows, rooms to be soundproofed, etc.
  5. Interface between units (such as doorways) and corridors
  6. Other information, such as the order in which the units are to be manufactured

The input information basically describes the compositional relationships among the rooms composed of modules. For example, "an object of type x is located in unit y on floor z." From the specifications of the final product, HAPPS must determine all the parts needed to create the product. This process is called parts explosion. In order to do the parts explosion, rules of the form, "If parts x and y are joined using z method, then use part s," are applied to all the objects specified in the design. The rule base is searched using K-PROLOG's pattern match and backtracking facilities.

The heart of the parts explosion process is the object hierarchy describing the parts and their interrelationships. Figure 2.5 shows the major classes and their position in the class hierarchy. Table 2.1explains the individual classes.

HAPPS was developed on the Sun workstation. The compiled production version is downloaded and runs on the Hitachi Engineering Workstation 2050.

Figure 2.5. Parts Class Structure in HAPPS

Table 2.1
Explanation of the Classes

HAPPS was originally developed using K-PROLOG. However, the maintenance (including additions and modifications of rules and data) of the PROLOG system became a real problem when new product introduction increased to four times per year. To overcome this problem ISAC developed an object-oriented PROLOG called MethodLog, and HAPPS has been implemented in this language. In object-oriented systems, the data description and the procedures associated with the data are encapsulated into entities called objects. The proximity of all the relevant information about a piece of data facilitates maintenance.

The size of HAPPS is about 14,000 lines of PROLOG and 6,000 lines of C code (used primarily for writing the interface and data base access functions). It took a team consisting of four domain experts, two knowledge engineers, and 14 programmers two years to develop HAPPS.

The Payoff. The decision to build HAPPS, TAPPS, and MAPPS was a strategic decision for Sekisui Heim. It enabled the company to put itself in a profit-making position and to expand its product lines. The expert systems reduce the cost of making modular houses, improve the quality of products and services, and reduce the error rate. The steady-state five percent error in parts selection has been reduced to near zero.

The three systems cost approximately 450 million yen($3.5 million at approximately 128 yen/$) to build. The cost figure was calculated using the following formula: 1.5 million yenx manpower x months. Sekisui claims that the savings has been 1 billion yen($8 million) annually.

Case 2: Aircraft Crew Scheduling (JAL)

The Company. Our next example comes from Japan Airlines (JAL), Japan's official international airline, which developed a KB system for crew scheduling (Onodera and Mori 1991). JAL maintains a fleet of over 100 wide-body aircraft: Boeing 747, 747-400, 767, and McDonnell-Douglas DC-10. They have a staff of about 2200 flight crew members (pilots, co-pilots, and flight engineers). The airline must produce a monthly crew allocation schedule taking into account a wide variety of constraints. These include crew training (for aircraft and route qualification), restrictions on maximum number of takeoffs and landings, vacation and meeting needs, crew turnaround times at various destinations, and many other needs and preferences. The schedule for a given month needs to be produced by the 25th of the preceding month to give adequate warning to crew and maintenance personnel.

The Problem. Before the development of the KB scheduling system, called COSMOS/AI, about 25 human schedulers were involved in solving the crew allocation problem. The hardest schedule (for JAL 747s) took 20 days to prepare (with a great deal of overtime). Moreover, the schedulers needed about a year to become expert in the problem. A related, very important issue was maintenance of scheduling knowledge, that is, updating information on planes, crews, government regulations, etc. In the summer of 1986, JAL decided to investigate various automated approaches for improving its solution to the crew scheduling problem. The airline developed two automated approaches to the problem, one a traditional operations research-based scheduling system (in cooperation with Hitachi), and the other a knowledge-based systems approach (with NEC).

The System. Testing of both systems began in the summer of 1988. The KB system was easily the system of choice for two major reasons: first, it produced better schedules because it was far better able to represent complex, yet informal constraints on crew preferences and other related factors. Second, it was much easier to maintain.

Technically, the JAL scheduling system uses straightforward heuristic scheduling methods. It builds crew pattern blocks that include pre-flight rest time, flight time, mandatory time at the destination, and a return flight. These blocks are then placed on the flight schedule, along with other time allocations like crew testing, vacations, and training, in order of most-constrained allocations first. When a problem occurs, time allocations are shuffled, moving the least constrained blocks first. The most complicated problems (the 747s) take two to three hours for a single scheduling run. Constraining factors which must be considered in producing the schedule are shown in Figure 2.6. The human experts still make final adjustments to the schedule.

The Payoff. The KB system became fully operational in February, 1990. It has reduced the number of human schedulers from 25 to 19 in a time when JAL operations increased by five to ten percent. Moreover, these 19 schedulers are now also assisting in other crew management tasks, reducing the actual scheduling manpower effectively to the equivalent of 14. The aforementioned 747 schedule now takes a maximum of 15 days to produce, with no overtime required, compared with 20 or more days, including overtime, to do the job previously. Training time has been reduced to two months. Overall, scheduling productivity has approximately doubled.

Two nice features of the JAL system are an excellent human interface and full integration with a mainframe-based corporate database that provides constant updates to the KB system. An example of the system's clear output, showing allocation of crew members over a 30-day period, is shown in Figure 2.7. The scheduling system itself is distributed among workstations specialized to the different aircraft types, although the workstations themselves share information on crews trained on multiple aircraft types. The system cost about 500 million yen($3.9 million at 128 yen/$) to build and paid for itself in direct cost savings in about 18 months. JAL views the harder-to-measure savings in increased crew satisfaction and ease of maintenance as equally important.

Figure 2.6. Sources of Knowledge and Constraints Used for JAL Crew Scheduling

Figure 2.7. Example of Output, Showing Crew Assignments For Each Day of the Month.

Case 3: Blast Furnace Control (NKK)

The Company. As early as 1986, NKK Steel Company's Fukuyama Works developed an expert system to predict abnormal conditions within its blast furnace. A blast furnace is a complex, distributed, non-linear process. Conventional mathematical modeling techniques have never been able to predict future dynamic states of the furnace with enough accuracy to support automated control. The system became operational in 1987. NKK and other Japanese steel companies have since developed other knowledge-based blast furnace control systems.

The Problem. Because the blast furnace feeds all other processes in the steel mill, any instability in the operation of the furnace is compounded by the impact on other processes further down the production line. Avoiding unstable operation of the furnace requires characterizing the current state of the furnace and projecting the conditions which will occur over the next several hours while there is still time to make adjustments. Training a skilled blast furnace operator takes many years. Fewer young people want this type of career. Codifying the skill of experienced furnace operators reduces the training requirements.

Several factors contribute to the complexity of modeling a blast furnace. Material within it coexists in all three phases -- solid, liquid and gas. The large size of the furnace leads to long lag times (six to eight hours) before a change in raw-material charging takes effect. The device is inherently three-dimensional -- there are no symmetries to simplify the geometric modeling. Moreover, the flow of material inside the furnace is itself a complex process. The thermal state of the furnace cannot be measured directly, but must be inferred from various sensor measurements. The challenge for the furnace controller is to minimize the uncertainty in the operating temperature. The smaller the uncertainty, the lower the overall temperature needed to produce the pig iron (see Figure 2.8), resulting in very large fuel savings.

The System. An expert system has been developed which successfully models the current state, predicts future trends with sufficient accuracy to make control decisions, and actually makes the control decisions. These decisions can be implemented automatically or the operator can take manual control while still operating through the expert system's interfaces.

The system as a whole consists of three components: (1) a process computer gathers input data from various sensors in the furnace, maintains a process database and generates furnace control information; (2) the "AI processor" provides the knowledge and reasoning for assessing and interpreting the sensor data, hypothesizing the internal state of the furnace, and determining appropriate control actions; and (3) a distributed digital controller uses the furnace control data from the process computer to control the actual blast furnace. A schematic of the system is shown in Figure 2.9. The system is implemented in LISP with FORTRAN used for data preprocessing. The knowledge in the AI processor is contained in 400 rules, 350 frames, and 200 LISP procedures; fuzzy theory is employed in its inference engine. The FORTRAN preprocessor contains 20,000 procedural steps. The system has a cycle time of 20 minutes, compared to the furnace time constant of six to eight hours. Fuzzy set membership is used to relate the temperatures inferred from the instruments to actual temperatures. The membership functions are revised from time to time to tune the performance of the system.

At any time, the operator can select either manual mode or automatic mode. The system continues to make inferences about the state of the furnace even in manual mode. Thus, the operator may manually change a set-point and the system will evaluate the influence of that action and make further inferences.

The Payoff. The blast furnace control application is noteworthy for many reasons. The problem had not been solved previously by other techniques. It was developed by systems engineers, not knowledge engineers. It is in daily operation now at two plants and will soon be installed in two more. The company reports an estimated annual savings of $6 million, a reduction in staff of four people, and an improvement in the quality of the furnace output because of reduced fluctuations in furnace temperature.

The benefits of the expert system, however, have not been separately established. It is considered an integral part of a new furnace control system that was installed the last time the blast furnace was shut down for relining. The JTEC team found that this was a common characteristic of expert systems used as closed loop controllers, viz. benefits are not traced to the component level. This suggests that expert systems have taken their place among the suite of techniques available to the controls engineer and do not require the special attention sometimes afforded new technologies.

Figure 2.8. Fuel Cost Savings

Figure 2.9. Blast Furnace Expert System

Published: May 1993; WTEC Hyper-Librarian