Site: Nippon Steel Corporation
Electronics Research Laboratories
5-10-1 Fuchinobe
Kanagawa 229, Japan

Date Visited: March 26, 1992

JTEC Attendees:



Dr. Hiroshi Iwasaki


Nobukuni Nakano

General Mgr.,
Computer Systems Lab

Yoshiteru Iwata

Mgr. Software Technology Center

Yutaka Miyabe

Sr. Researcher,
Computer Systems Lab

Osamu Dairiki

Sr. Researcher, Software Engineering Group
Leader, Knowledge Engineering Group
Leader, Computer Systems Lab


We visited Nippon Steel's Electronics Research Laboratory (ERL). Unlike NKK, where we visited an actual steel mill, this visit was really to one part of a large software house, doing advanced development and providing its own ES tools. Nippon Steel has approximately 1,000 research scientists in four research laboratories, of which about 235 are in ERL. ERL itself has five laboratories and one center. We interacted with members of the Computer Systems Laboratory (CSL), which has about 50 people. Subjects covered by CSL include:


During our visit we discussed the answers to the questionnaire and saw several demonstrations of KBSs and other advanced software that is being developed at CSL.


Nippon Steel has developed 100 to 130 expert systems for internal use (very few for external use). About 30 percent of these are in routine use. Although most of the current applications are diagnostic/troubleshooting systems, the fastest growing area is in planning and scheduling.

Our hosts selected three representative applications, two of them diagnostic and one for process control. The first is a system for process diagnosis, used in the Oita works. The system is used in three factories for troubleshooting electrical and mechanical equipment, and has resulted in a reduction of production costs, development costs, and/or plant operators. The knowledge base contains about 160,000 knowledge "fragments" (comparable to about 50,000 rules). The system was developed with Nippon Steel's own shell called ESTO, written in C++, and runs on networked Sun workstations. About 20 man-years went into its development, over a two year period. The economic payback of this system is estimated to be about $2 million annually. The reliability of Sun hardware has been a problem in keeping the systems in use.

The second representative system provides supervision of blast furnace control. This is a large system, with 5,000 to 6,000 production rules. It was built on top of Hitachi's commercial EUREKA plus a "neuro simulator" tool called AMI developed internally, and runs on a minicomputer. AMI was used to build a neural network for preprocessing (pattern matching) the raw data before it is input to the expert system. Improvements in decision making and in quality of product have been the principal paybacks. About 14 man-years were expended in development, over two years. Maintenance of the KB has been a major problem, one not easily understood by people who were not involved in its construction.

The third system is a design expert system for designing shaped beams. This is a large system, containing 3,000 production rules and 500,000 lines of code, in LISP, FORTRAN and C. The system was built using ART (from Inference Corp.) and runs on networked Sun workstations. Twenty technical people (4 domain experts, 16 knowledge engineers) developed the system over an 18 month period. Principal payback is in reduction of the design cycle time by 85 percent and an increase in design accuracy of 30 percent. The estimated economic return is $200,000 annually. The system is felt to be too expensive, requiring a copy of ART at each new site. When developing systems that use multiple sources of knowledge (experts) Nippon Steel has adopted a structured development method, much the same as used in conventional software development, which is intended "to avoid unnecessary confusion." For diagnostic systems, Nippon Steel uses its in-house tool, ESTO, which is designed to accommodate incomplete and inconsistent knowledge from multiple knowledge sources.

Of 28 systems developed within the past two years, 60 percent can be characterized as using a combination of a rule-based inference engine plus added code written in a conventional language, typically C. A few systems integrate rule-based, fuzzy and neural network methods. Commercial tools were found to be inadequate in the way they permit access to external functions written in conventional languages, which motivated Nippon Steel to develop its own tools.

Our hosts reported that they do not have a structured training program, and as a result they have seen the development of many poorly organized expert systems.

The company cited many reasons for selecting an expert system application, among which are to acquire know-how, to capture and distribute expertise, to improve revenues and to reduce costs.

Nearly all systems are integrated with other systems, e.g., data processing, and they are working to establish an inter-factory LAN to facilitate this integration.

Although most projects reach the prototype stage (28 out of 30 in recent past), it is difficult to estimate how many actually get to successful operational status. Mr. Dairiki estimates that only 10 percent (Mr. Miyabe estimates 20 percent) really reach successful status on an ROI basis.

Most of the systems that have been developed are small (under 100 rules). It was found that the time to develop large projects increases more than linearly with the number of rules. The in-house consultants advise developers to keep their knowledge bases to within 300 rules, and if more are needed to segment the KB into modules each of which is within 300 rules.

Problems with current technology include slow execution speed for large-scale systems, high cost in time and effort of knowledge maintenance, lack of transparency of the inference process, tedious integration with existing software, and the general problem of knowledge acquisition.

Looking ahead several years, Nippon Steel envisions new expert systems that perform planning and scheduling over multiple factories or production lines. Future diagnostic and process control systems will employ model-based and case-based methods for more in-depth problem description and for recovery following diagnosis, with a capability for closed-loop control. Future planning/scheduling systems will be fully automatic and able to plan with multiple objectives. Future tools (infrastructure) will reduce or eliminate the need for knowledge engineers, will be task-specific within a general problem solving paradigm, will use a standard knowledge representation, and will have a better user interface.


A corporate goal is to increase productivity by the application of knowledge engineering.

Nearly all ESs are integrated into larger systems, e.g., in control applications. There are approximately 2,000 systems engineers at Nippon Steel. The company is one of the ten largest systems integrators in Japan. The ERL brochure shows nine systems built by CSL.

LISP and PROLOG aren't used very much due partly to their heavy resource consumption. Another reason is a result of the lack of programmers in Japan who have a command of these languages.


This is a very eclectic group, mixing rule-based, fuzzy and neural network methods in their applications as they believe they are needed.

Comments about both steel companies (Nippon Steel and NKK): They have lots of applications, most of them small-scale diagnostic systems. The systems are developed by systems engineers out in the steel works. One might postulate that there is a different business model at work here than in the U.S. The large Japanese companies investigate new technologies by building an internal competence rather than hiring an outside firm.

The company will not invest in an application unless it can retrieve its investment in two years.

The bulk of their applications appear to be small diagnostic ESs, though some are larger. As at NKK, they are developed by (plant) engineers, not researchers.

The group we visited at Nippon Steel was actually part of a computer group, and not directly involved with steelmaking. However, they have helped the steel people build some applications and were quite knowledgeable about those applications.

This laboratory is more like a U.S. software research group than anyplace else we visited. Applications are built primarily by people connected directly with the application, with the help of the knowledge engineering group. They have built a diagnostic shell of their own, based on a maximum entropy type of formalism (Minami and Hirata 1991).

They had a very large supply of high performance engineering workstations (top of the line Suns and SGIs). We saw one demo of a deformation solid modeler ("computer clay"). In many ways this group is reminiscent of a corporate computer science lab like Schlumberger's; their charter is to do advanced information processing including AI, graphics, etc.

Mr. Dairiki was very candid. He said that the reason for the low failure rate of projects is that they redefine the goals of a project that's not going so well; maybe its goal becomes familiarizing themselves with the technology. In selecting projects they want to get a payback in two years. Many successful projects don't actually get used; they met the need but the need wasn't vital enough. He thinks they need to do a better job of requirements analysis, etc.

As at NKK, a real project at Nippon Steel is developed with heavy contribution by people from the field. In the diagnostic system listed as representative, 20 foremen and 3 software engineers developed the application.

How do people get started on an AI project? They don't get formal training. Usually they buy the "best shell at that time" and take the training course (some of them) and plow through the manuals. Then they jump into building a system largely through on-the-job training. This sometimes leads to FORTRAN written as rules, but the systems work.

Two applications were mandated, those listed as "given policy" in the answer to question 11. These were done to maintain a "high tech aura", e.g., to answer a system that NKK had publicized.

Sometimes projects aren't stopped soon enough because they don't realize that they don't understand the problem they're attacking.

Overall, this group was very impressive. Since expert system development is a field activity, this group can concentrate on building tools that will leverage these activities. They have already done some of this with their diagnostic shell. It might be that this model of research and development gets at the important questions more effectively than the U.S. model of development in industry and research in universities.

Published: May 1993; WTEC Hyper-Librarian