ASPDIN: An Expert System for the Design of Different Types of Concrete

By the middle of the last century, taking advantage of the rise of computing and the emergence of artificial intelligence (AI), people began to think about solving complex problems that required knowledge, intelligence and reasoning, using the computer. The possibility of including thought and reasoning in a machine woke up the euphoria of the researchers of that time. One of the fields of AI that relates thinking, logic, reasoning and knowledge, is that of expert systems (for design, diagnosis, planning, etc.). Expert systems are designed to solve complex problems by reasoning with and about specialized knowledge, like an expert. Clearly, expert systems are the most mature and widely used commercial application coming out of artificial intelligence. Thousands of expert systems have been developed worldwide and applied to different knowledge domains, such as finance, manufacturing, industries, management, airline scheduling, customer services, and military design [1-3]. Expert systems in industry are interesting because they offer four major advantages with respect to a human expert: a) increased distribution of expertise. They allow having any number of experts (copies of the software) in any place at the same time; b) longevity. Their lifetime is practically infinite; c) objectivity. They are never influenced by environmental factors that may hinder their decision-making capabilities, such as hasty decisions, emotions, cost of material, competitive factors, etc.; and e) cost. They can be used 24 hours a day, 365 days a year at no additional cost. On the other hand, the main disadvantage of these knowledge-based systems is the well-known knowledge engineering bottleneck: the knowledge acquisition process, which implies the transformation of tacit knowledge—which resides in the heads of experts—into explicit knowledge. To solve this major problem, which is also key to this project, we use the KAMET II Methodology of Cairó & Guardati [4]. This methodology represents a modern approach to creating diagnosis-specialized knowledge models that can be run on Protégé 2000, the open source ontology editor and knowledgebased framework; for details see Noy et al. [5].

This paper presents some of our attempts to build a new expert system that brings together and includes all of these ideas. Aspdin-named in honor of Joseph Aspdin, who was a British cement manufacturer who obtained the first patent for Portland cement in 1824-is an expert system that focuses on the intelligent design of different types of concrete: hydraulic, bacterial, cellular lightweight, high strength, architectural, etc. The system also optimizes the use of additives and cement, which, besides being the most expensive raw materials used in the manufacture of concrete, when employed in certain types of concrete add a lot of complexity to the decisionmaking process in terms of achieving the desired workability, mechanical strength, and durability (permeability, weathering, shrinkage, cracking, etc.). The quality of concrete depends precisely on the proportions of cement, additives, water, and air, considering the type of concrete that is being designed and the environment in which it will be used, see Arioz et al. [6]. In Mexico, companies like Cemex, Apasco, Cruz Azul, and Moctezuma have hundreds of manufacturing plants that each day produce about 1,000 cubic meters of concrete, where each cubic meter weighs about 2,400 kg. The per capita consumption in emerging countries is currently 400 kg per person per year. To illustrate the large size of cement production in these companies, recently Cemex, which is among the three major world producers of cement (1: Lafarge, 2: Holcim, 3: Cemex, 4: Heidelberg Cement, 5: Italcementi), signed various agreements to: a) provide 27,000 m3 of ready-mix concrete for the Airbus-350 long-range, wide-body, jet airliner assembly facilities near the southwestern city of Toulouse, France; b) provide over 30,000 m³ of different types of specialty ready-mix concrete for a bridge which crosses the Llobregat River near the Barcelona airport in Spain, c) provide 40,000m³ of specialty ready-mix concrete for the construction of the Baluarte Bicentennial Bridge in the Northern Mexican states of Sinaloa and Durango (Baluarte is one of the world’s tallest, 390mts, and most complex bridge mega-structures); d) supply 48,000 cubic meters of ready-mix concrete for the new construction of the Kaiserschleuse Bremerhaven, in Germany, one of the largest lock projects in Europe; e) provide 250,000 cubic yards of ready-mix concrete for the more than US$1 billion Port of Miami project in south Florida; and f) supply over 500,000 tons of cement for a major expansion of the Panama Canal. An expert system for the intelligent design of concrete would undoubtedly be a valuable tool for world-class companies like this. Aspdin can design different types of concrete for different environments, compare the results with those obtained by human experts, show the reasoning followed to reach the solutions it produces, and answer questions justifying its reasoning and conclusions.

The following section of this paper describes the KAMET II methodology used in Aspdin to model the knowledge acquired from multiple knowledge sources. Section 3 discusses the design of concrete and why this is such a difficult task. Section 4 is a description of the Aspdin system, its implementation, and architecture. Section 5 presents an analysis of how Aspdin could evolve from an academic prototype to be used in a beneficial manner in an industrial setting. Section 6 presents some conclusions about the project.

The knowledge acquisition (KA) process does not involve mining from the expert’s head and writing rules for building knowledge-based systems (KBS), as it was considered twenty years ago when KA was often confused with knowledge elicitation, and modern engineering tools did not exist. The KA process has changed since then. It should be considered a cognitive process that involves both dynamic modeling and knowledge generation activities. KA should be seen as a spiral of epistemological and ontological content that grows upward by transforming tacit knowledge into explicit knowledge, which in turn becomes the basis for a new spiral of knowledge generation; for details see Cairó & Guardati [4]. Knowledge undoubtedly is a fluid mix of framed experience, values, expertise, and insight that can be useful and applied to solve a problem. However, we have a well-known problem (the design of concrete) which on the other hand is extremely difficult to solve. Knowledge is often tacit, residing in the minds of individuals, and therefore difficult to make explicit. That is the reason we use the KAMET II methodology. It represents a modern approach to building diagnosis-specialized knowledge models that can be run with Protégé-2000, the open source ontology editor and knowledge-based framework [5].

The KAMET II life-cycle model (LCM), shown schematically in Figure 1, provides a graphical framework for managing the knowledge acquisition process. The graphical framework also helps to set up and facilitate ways to characterize and organize knowledge acquired from multiple knowledge sources, share knowledge, implement the required actions, review the project situation, identify risks when objectives are not reached, monitor project progress, and check quality control; for details see Cairó & Guardati [4]. In fact, KAMET II is based on the search for the efficient transformation of tacit knowledge into explicit knowledge, see Sun et al. [7]. The KAMET II life cycle consists of four welldefined stages: the strategic planning of the project, initial model building, feedback model building, and final model building. Each stage involves a process of knowledge transformation (Figure 1).

The first stage is the socialization stage in which ideas, views, experiences and knowledge should be shared between teamwork through face-to-face interactions. This process is necessarily context-specific in terms of who participates and how they participate. Social, cultural and historical contexts are important for human beings, as such contexts provide the basis for interpreting information to create meaning, see Nonaka et al. [8]. The externalization process takes place in the second stage. It is the time for transforming tacit knowledge into explicit knowledge. When tacit knowledge is made explicit, knowledge is crystallized. This means knowledge can be shared with others, and therefore become the basis for a new process of knowledge generation, see Nonaka & von Krogh [9]. The third stage is the perfect time for combination-the process of converting and combining multiple “chunks” of explicit knowledge into more complex and systematic sets of explicit knowledge. Finally, the internalization process takes place in the last stage. It involves the transformation of explicit knowledge into tacit knowledge again. The knowledge expressed in models and the experience gained in implementing the various processes, is now absorbed by team members and the cycle can begin again.

Concrete is a composite material used in construction due to its initial fluid state in which it can be shaped at will, and its final, resistant, rigid state. The main ingredients used in the creation of concrete are cement, water, and aggregates. Differences in the relative proportions of these ingredients can cause the resulting concrete to exhibit varying properties. However, predicting the exact behavior of the concrete given the proportions of the ingredients is not a trivial task, even for experts, because other factors that are hard to control or foresee (e.g., speed of pouring, environmental conditions, etc.) also exert some influence over the final properties of the material. The way in which the three main ingredients of concrete interact is that the cement, when combined with water, forms a paste whose task is to hold together the aggregates, a process known as hydration. Some of the important properties taken into account when mixing concrete are its strength, its workability, its durability, and its cost. Concrete has a relatively high compressive strength, but much lower tensile strength, so it is often reinforced with high-tension materials (such as steel). The workability of concrete refers to how easy it is to mold in its freshly poured state. The durability of concrete relates to how well it resists the passage of time, once hardened, despite potentially destructive environmental forces (e.g., variable temperatures, corrosion from sulfates, salinity, etc.).

sand) or coarse-grained (e.g., gravel). Their strongest impact is on the strength of the concrete. However, they also influence the cost: the more that coarse-grained aggregates are used, the larger the volume of the spaces between the grains, and thus the larger amount of cement that has to be used to paste the grains together, increasing the cost. The most common form of cement is Portland Cement, whose name stems from the fact that its physical properties are similar to those of the limestone from the Isle of Portland, near Dorset, in England. The process of creating Portland Cement through a combination of various forms of calcium silicate and calcium sulfate, plus a few additional minor constituents, was developed in the early- to mid-19th Century. It has been attributed to Joseph Aspdin, his son William, and an employee of the elder Aspdin, Isaac Johnson; for details see Francis [10]. This is the origin of the name we have given to the system described in this paper, Aspdin. The amount of water used in mixing concrete affects its strength and its workability. The more water that is used, the higher the workability, but the lower the strength. Additives are often included in the mix with the three basic ingredients to increase workability despite the use of relatively low amounts of water, or to increase strength despite the use of relatively high amounts of water. The additives can also affect durability. Cement has three components, which exert an influence on the physical properties of the concrete it is used in: alite (3CaO.SiO2), belite (2CaO.SiO2), and ettringite (a combination of 3CaO.Al2O2 with 4CaO.Al2O3.Fe2O3). The amount of alite influences the initial strength of the concrete (during the first week after pouring), and also the amount of heat produced during hydration. The amount of belite influences the long-term strength of the concrete and has a lesser degree of influence on the heat produced during hydration. The amount of ettringite practically doesn’t affect the strength of the concrete, but this substance absorbs some of the additives commonly used in concrete and thus neutralizes the potential benefits of their presence, so the more ettringite that is present, the more additives that will need to be used, thus adding to the cost of the concrete.

The additives that are used in the mixing of concrete can be classified into plasticizers, air entrainments, retarders, and accelerators. Plasticizers increase the workability of freshly poured concrete and are often used to reduce the water content while maintaining workability. This treatment can increase the strength and durability of the concrete. Air entrainments add tiny air bubbles to the concrete which serves to reduce damage due to potential periodic freeze-thaw cycles in the environment, therefore increasing the durability of the concrete. On the other hand, the more that air is added to the concrete, the more its compressive strength is reduced. Retarders and accelerators slow down and speed up the hydration process, respectively. This allows for more control of the duration of the transition period before the concrete hardens permanently. For instance, a retarder might be used in a difficult or large pour in which partial setting before the pour is complete is not desirable. It might also be used when the pour is performed in high-temperature zones, where concrete hardens faster. These varied and complex interactions between the components used in, and the properties exhibited by, concrete result in the design of a mix of concrete being an art form rather than an exact science. Thus, the task lends itself to the possibility of being enhanced, and its results improved, through the use of an expert system.

The development of the Aspdin system can be divided into three partially overlapping phases: settling on project objectives, knowledge acquisition and modeling, and system implementation. This section describes each of these phases in detail.

Project objectives

A series of group interviews was carried out between the Aspdin knowledge engineers and domain experts who are also the potential users of the system to reach consensus on the specific objectives that the project should meet, see McLafferty [11]. The domain experts were all employees of a large construction company in Mexico. Since some of the experts that were interviewed were not highly computer-literate, a document describing the purpose and characteristics of expert systems in general was distributed to the participants. The initial interviews were conducted informally, usually over lunch, to ease any potential tensions that could arise between the domain experts and the Aspdin knowledge engineers. Interviews were held separately with concrete experts, cement experts, and additives experts. The following subsections present some of the main issues raised in each of these group interviews.

Concrete experts

1. It’s difficult to predict the behavior of a mix of concrete. In the long term it would be useful to have a virtual lab in which a given mix of concrete’s behavior could be simulated computationally.

2. The maximum strength of concrete is reached roughly four weeks after pouring it. Since the experts that are monitoring a given batch of concrete cannot wait this long, the strength at three days is usually taken as a reference measure, and if it not sufficient the amount of cement in that mix is increased.

3. Construction companies have invested millions of dollars on their employees’ training, research, and attendance in conferences. What happens if one of these employees has an accident or retires? Where does all of the money, time, and effort invested in them go?

4. If there are any errors in the design of a given mix of concrete, experts would like to be able to detect them rapidly in order to correct the problem and avoid unnecessary expenses or even lawsuits.

5. There are certain facts and skills that all human experts in a given domain should know and have, irrespective of whether they have a computational tool that can do the job or not. Full dependence on automated systems is viewed with mistrust due to the generalized feeling that machines can sometimes fail. A computational tool for aiding/guiding during the process of designing a mix of concrete, rather than a system that tries to be fully autonomous, is desirable.

Cement experts

1. Cement is a complex substance. Small changes to its chemical composition can produce large changes in its behavior during hydration and its interaction with additives.

2. Experts in designing a mix of concrete can erroneously jump to the conclusion that problems that may occur are due to bad quality cement, when it may be actually due to a small variation in the chemical composition of the cement.

Additives experts

Experts in designing a mix of concrete can erroneously jump to the conclusion that problems that may occur are due to bad quality or incorrectly functioning additives, when in fact the additive may be fine. The design of the mix of concrete, the way in which the ingredients were handled physically, or changes in the substances used, are more likely causes of any such problems.

2. Because the chemical composition of the cement used determines its interaction with any additives, it is difficult to give an exact specification for the additives a priori. Usually quantities are specified within a given range of values rather than giving exact values, and in situ tests used to fine-tune the amounts.

Common issues: All domain experts emphasized the common attitude on the part of employees of resistance to adopting the use of new computational systems in their daily tasks. In order to increase the probability that any such system will be employed, desired qualities are that it be easy to use, user-friendly, and interesting. Potential users of a system such as Aspdin were mentioned by all the experts as being primarily employees in charge of quality control in the different concrete mixes produced by the company and the people originally in charge of designing the mix of concrete.

Knowledge acquisition and modeling

In addition to the preliminary interviews conducted for the purposes of articulating the specific objectives of the project, further interviews were conducted with an expert on cement chemistry and an expert on additives during the knowledge acquisition phase. The knowledge obtained from these human experts was supplemented with knowledge obtained from several papers and published sources [12-17]. In the end, the knowledge engineering effort focused on acquiring knowledge necessary for two tasks: on the one hand, designing a given mix of concrete, and on the other, diagnosing a mix of concrete whose behavior is not the desired one. As a result of this knowledge-acquisition phase, we developed many models, two of which are shown in Figures 2 and 3 as examples, using the KAMET II modeling language. An explanation of the corresponding model is given after each of these figures (Figure 2).

Figure 2 models the problem of having damage to aggregates due to freeze-thaw cycles (P1.1). In the figure, A14 and A23 represent two antecedents of this model. A14 indicates low winter temperatures and A23 indicates the fact that the concrete was set 10-15 years previously. S4, S24, and S48 represent symptoms of this problem. S4 indicates the presence of cracks, S24 indicates decoloration or change of color, and S48 indicates extensive damage in the lower parts of the sample taken for analysis. V9 and V28 represent values. V9 indicates D-type cracks and V28 indicates a higher degree of cracking than of decoloration. V9 is the value of symptom S4. Dotted rectangles in KAMET II group together elements, and the label placed in their upper-right-hand corner indicates the exact number of elements of the group that must be present. The cloud-like component of the figure represents the assigning of a name, in this case P.1.1, to the inner dotted rectangle. The purpose of this is to be able to refer to or reuse this entire node in another model without having to repeat its interior details. V28 is the value of the node labeled P.1.1. The outer dotted rectangle represents the fact that either V9 and S4 must be present, or V28 together with P.1.1 must be present, in addition to S48 and the antecedents A14 and A23, in order to conclude that problem P1.1 (shown in the rounded rectangle in the lower-left-hand corner) is very likely to occur (where MP is a linguistic label indicating that something is very likely) (Figure 3).

Figure 3 models the problem of deterioration due to aggressive water (P2.4). Antecedent A27 in this figure indicates the fact that the structure carries a water current. The dotted rectangle in this figure has a 1+ in its upper-right-hand corner, which indicates that at least one of the two symptoms (S16 and S17) included in the rectangle must be present. Symptom S14 indicates dissolving of the paste exposing the aggregates, S16 indicates the presence of holes on the surface, and S17 indicates the presence of grains of sand on the surface of the concrete. The presence of the antecedent and symptoms described above would allow us to conclude that problem P2.4 (shown in the rounded rectangle in the lowerleft- hand corner) is likely to occur (where P is a linguistic label indicating that something is likely).

System architecture and implementation

The Aspdin system consists of several sub-systems: the user interface, the operational module, the data base, the inference engine, and the knowledge base. Figure 4 shows this system architecture (Figure 4).

The user interacts directly with the graphical interface. The inference engine was built using the AgentOCX extension of the Eclipse platform. The knowledge base contains the domain knowledge acquired and modeled using KAMET, i.e., task-related domain knowledge. The database contains declarative domain knowledge: it acts partially as a glossary of terms and partially as a provider of domain knowledge to the user and/or to the operational module. For instance, if the operational module receives information from the inference engine that an additive might be required in the mix of concrete, the data base is queried as to what additives exist for the given situation, this list of options is presented to the user to choose from, and then the data base is queried again to provide the inference engine, via the operational module, with information on the characteristics of the additive that was selected [18].

The Aspdin prototype was built around an academic project based on true industry needs. Thus, even if the industry needs were there, the project resources—people, funding, and time—weren’t. The scope had to be minimal, but the fact was that it was a high potential project that could have its use in the cement/concrete industry. The question then was: how could we take ASPDIN to the next level? We asked this question to an experienced project leader on worldwide supervision systems—which include expert systems—in a huge steel company with global presence. We present here a summary of the analysis performed by the expert. As this is not a business paper, we will focus mainly on the engineering aspect of the project.

Proof of concept development: giving Aspdin a chance to succeed

We all know that main industry actors are worldwide companies with thousands of employees, with operations in many countries. To give an example, Cemex, one of the world’s largest building materials suppliers, has production facilities in more than 50 countries, produces more than 80 million tons of cement per year, and has more than 25,000 employees. Aspdin, to succeed, needs to be rethought taking into account this reality and complexity: a POC (Proof of Concept) project could be a good way to ensure the interest and participation of major actors in the cement/concrete industry in order to redefine Aspdin in a sustainable way. The main idea of a POC project is to show what has been done, what could be done and build a partial draft solution according to the actual business requirements of these global, complex, companies. A POC is like a pre-prototype that should evolve very quickly and constantly and that is the base for discussions and teamwork among all stakeholders to give shape to the system that will eventually be implemented. The result of the POC is not a fully functional system, but a good sample of what the system could be if enough resources are allocated. The first version of Aspdin is a very important asset, as it gives credibility to the project because of the knowledge it incorporates, and thus it would definitely be utilized for the POC implementation. This first version must be slightly “reshaped” to ensure its attractiveness and obtain approval from its potential users. It is only by having funding that Aspdin could ever come to life. We will describe, according to our experience, the important aspects that would leave Aspdin in an appropriate state.

Aspdin as an integrated IT solution

Big companies have hundreds of Information Technology (IT) systems. Often, these IT systems are quite heterogeneous because these companies are usually the result of several mergers and acquisitions of smaller companies, each one of them having their own computational eco-systems. Today, the strategy is clear: simplify, integrate and standardize IT systems as much as possible.

1. Simplify systems by taking out unnecessary elements for an easier use, management, and maintenance.

2. Integrate systems so that they work as much as possible as a “whole” to reduce the number of windows, screens, interfaces, and their complexity.

3. Standardize systems to align processes all around the world.

A detailed analysis of existing IT systems in the cement/ concrete industry must then be performed in order to “plug” Aspdin the best way in the middle of this IT eco-system. One key to success is that Aspdin become not just one more system, but a valuable complement/add-on to what’s already available.

Aspdin on-line: An on-line system is aimed at continuously assisting the operations team during manufacturing. These systems are very valuable as they are tightly integrated to the manufacturing processes and can have a large positive impact on costs and quality. Aspdin as an on-line system in a concrete plant could give recommendations on the design of a concrete mixture being produced to optimize it according to quality and quantity requirements of production and parameters of raw materials and weather conditions. In this case it is vital to take into consideration the existing “Level 1”, “Level 2,” or “MES” systems of a plant which should automatically send the data Aspdin requires like the chemical analysis of the cement. A standard communication interface between Aspdin and other systems will be one critical issue.

Aspdin off-line: Concrete production is not always done in a plant: for far away building projects, it might be impossible to transport concrete. In this case, Aspdin could be embedded into a mobile device containing raw-material parameters and adapting the mixture to the current weather conditions. Aspdin can also excel as an off-line solution for simulation purposes and for training people.

Aspdin within a community of global experts: The best way to ensure the success of the POC project is to define a worldwide expert community so that Aspdin can be designed as a true global system. The advantage of a big company is that they have experts from all around the world. We must take full advantage of this. During the POC, the expert community will define the high-level requirements Aspdin must meet. The global community of experts must be created during the POC, as it will be the origin of the system design, but it should last as long as the system exists and is maintained. A system like Aspdin can be a trigger for a tighter collaboration between experts all around the world, leading to an improvement in knowledge and alignment of manufacturing processes. The alignment of processes is one of the biggest challenges of corporations. Members of the global community of experts can be plant process experts in charge of long-term production strategy, plant operators in charge of day-to-day production, and R&D (research and development) experts with more theoretical knowledge.

Go/No Go decision for Aspdin: At the end of the POC we would have a better understanding of the system requirements and complexity, the environment in which it would run and be used, the estimation costs and planning, and, most importantly, the value it could provide to a company. The business model could then be correctly defined in order to obtain approval for a pilot project.

Pilot project development: giving life to Aspdin on-line

Let us assume that the business model is good enough to give the Aspdin team the possibility to start the pilot project. The team would then have, among other things:

1. High-level business requirements that would need to be translated into user requirements: that will be one of the main objectives of the pilot phase of the project.

2. A global community of experts dedicated, at least partially, to the project.

3. A budget and a timeline for the pilot project.

The pilot phase represents a vital step before the full industrialization of Aspdin can begin. The pilot phase’s main objectives are to obtain the detailed functional requirements (a.k.a., user requirements) based on the business requirements the system should meet, and to choose and test the global architecture of the system. Therefore, enough plants must be chosen to validate the system before it can be fully deployed by the company: these plants must be different in their production processes, their technology levels, their culture, and their constraints in order to produce a system that is as global as possible.

Global architecture: There is no doubt: the cloud is becoming a really interesting approach. A deep analysis, gathering independent technical experts and internal experienced experts having good knowledge of the company’s infrastructure must be done to decide whether it’s worth taking the risk of developing a centralized Aspdin system through a private cloud or keeping the typical architecture where the system is installed locally in every plant. Each solution has its advantages and disadvantages. The cloud solution would give Aspdin the opportunity to evolve better and quicker. If well designed, every enhancement, every new version and all knowledge added to the system would be immediately available to all connected plants and users. It would facilitate the deployment of the system and, above all, would reduce maintenance costs by sharing company resources. If the company has a weak IT department, the possibility of using a public cloud should be studied as the Aspdin team could then focus on the system itself and leave the hardware responsibilities and decisions to the experienced cloud provider. In the end, the added value of Aspdin is in its knowledge and not in the hardware it is installed. Of course, the cloud solution has one big risk: if the company’s network is down, the system is down. On the other hand, nowadays it is very rare to get network failures even in remote locations and a system like Aspdin does not need to be available 100% of the time. Nevertheless, if it is pointed out that system availability is a requirement and that the company’s infrastructure is not reliable enough then a hybrid cloud/local approach can be analyzed. The cloud is based on virtualization technology, which gives the opportunity to build ASPDIN virtual machines for every new release that could then be sent to local plants to maximize reliability.

Aspdin knowledge model update through the global community of experts: Aspdin is a knowledge-based system, so knowledge will be its most important aspect and its biggest challenge. Without a reliable knowledge base, Aspdin will fail and die. Fortunately, the Aspdin team can use KAMET. KAMET is a proven methodology for knowledge acquisition. This methodology brings together a set of tools and best practices to transfer knowledge from different and complex sources into an IT system regardless of its technical implementation. Maybe one of KAMET’s weaknesses today is that it has not yet been applied in a large and global context in which strong geographical, cultural, and human barriers exist. A global project like Aspdin would be the best way to demonstrate once and for all the strengths and qualities of KAMET, the most important of which is its capability to model and describe knowledge in a standard and human-oriented way. The only way to obtain a satisfactory knowledge base in a global company is by taking into account its worldwide knowledge: effective communication among the global community of experts is then a sine qua non and KAMET would definitely be a remarkable asset. Also, the Aspdin team will have to face different ways of doing things, different visions, and different sensibilities. It will also face political and cultural issues. To succeed, the Aspdin team will need to effectively manage these conflicts, which are the main reasons of project failures in big companies. KAMET should then integrate the lessons learned throughout the project. Applying the KAMET methodology in a smart and proactive way would ensure the success of this huge challenge.

Full industrial on-line prototype implementation in representative pilot plants: The Aspdin team by this stage would have all it needs to build a pilot system: the architecture, the detailed user and business requirements, and the knowledge. The pilot phase is one key challenge that should never be underestimated. The difficulty is not on the IT side but on the human side: special attention needs to be given to the appraisal of user requirements. We can frequently see in industry that IT people implement things the way they feel instead of doing it the way users require. The pilot phase is the phase in which the team has to be as close to the users as possible. User requirements must be frequently updated based on user feedback (and of course aligned to the budget), and always be detailed and explicit, including textual descriptions, pictures, and diagrams.

The on-line system should be implemented based on the following principles:

1. Provide information only when it needs to “say” something important and accurate. A system that “talks” too much or is inaccurate ends up being ignored.

2. Every time the system communicates with the user, if the user asks for it, it should explain and describe every single step in the reasoning leading to the information given.

3. The on-line system should never be in closed-loop mode: the user must always have the last word on decisions taken.

4. The system needs to be adapted to the way operations are organized in each plant: for example, many plants have different team shifts in one single day. At every shift change (team change), the system can be of great help if it gives a summary of what happened during last shift and what decisions where taken.

Full industrial off-line prototype implementation within the community of experts: The on-line solution is there to assist operational people with their every-day tasks to improve production, reduce costs, and even prevent accidents. Operational people are rarely experts, and they usually execute the plans made by the experts, which in our case is Aspdin on-line. The off-line solution could of course be used in remote locations where an on-line solution cannot adopt, such as places where the concrete must be mixed on-site using rudimentary tools, where the weather conditions are difficult, and where human expertise is not always available. We can imagine the off-line solution as a companion for small companies or private users. But it can also be a great tool for the community of experts, providing the following benefits:

1. A companion for their consulting activities.

2. A support for training.

3. A simulating tool to understand and analyze complicated scenarios.

Above all, Aspdin off-line could be the best way to keep ASPDIN up to date: by playing with an off-line version of Aspdin, the community of experts can easily keep testing the system. The on-line version will rarely face extreme or changing situations, as it will be used in plants, while the off-line version can be challenged with many other situations.

System validation: giving maturity to Aspdin

System validation is the step in which Aspdin will face the reality and prove its reliability, usability, and, above all, business added value. To succeed in system validation, the system should run several months on site accompanied by an expert. Every recommendation or diagnosis should then be analyzed by the expert to give his/her agreement. If a disagreement occurs, the knowledge in Aspdin must be updated. Also, if a situation was not detected by the system, the expert must understand why and assess if the situation should fall or not within the system’s scope (and make the corresponding changes to the system, if necessary). Finally, to prove its business added value, a detailed assessment must be done at the end of the validation period: the operational costs, production quality evaluation, and any other important elements can be compared to similar past periods within the same plant, or even be benchmarked with plants with similar operational conditions.

User training: getting the most out of Aspdin

Aspdin can only be successful and add value to the business if it is frequently and correctly used. Training is then an important aspect of the project: an on-site training plan has to be created focusing on the business rules. The following principles are strongly recommended:

1. It is the global community of experts that must design and perform the training.

2. The Aspdin team should not be directly involved in the training process, but only be there for assistance.

Worldwide system deployment: setting Aspdin as an industrial standard

‘By this stage, Aspdin is ready to be globally deployed: the system has been validated and has proven to be of great value, the global community of experts is ready to provide on-site training, and political issues and risks have been managed. Only one thing is still missing: the deployment strategy. During the pilot phase, all efforts were focused on producing a state-of-the-art system that matched the business and user requirements. Now that the system is ready, an effort must be made to develop an intelligent strategy to deploy Aspdin appropriately. Two aspects need to be seriously analyzed:

1. The deployment process: the steps and processes for deployment must be thoroughly defined and documented. If Aspdin is to be industrialized, it needs to be deployed quickly and efficiently. We can imagine a deployment team that is fully focused on these steps and processes. In the deployment process, one step that needs to be especially refined is that of plant data acquisition and validation, as Aspdin will only provide accurate information if the data it was programmed with is good.

2. Plants to be deployed first: it is not possible to deploy the system in all worldwide plants at one single moment in time. The right order of deployment will be an important aspect of the success of Aspdin’s industrialization. We can follow simple principles like starting with the plants that will lead to a maximized added value through the use of Aspdin. For example, a list of the ten most problematic plants urgently requiring urgently expert assistance can be made. Company politics are also something to be considered, as a politically influential plant not being given deployment priority can seriously damage the Aspdin deployment process. Finally, even if the idea is to maximize profitability (and therefore Aspdin’s added value), it is also important to remember that “top plants” in which Aspdin would have a smaller added value can still be of great value to Aspdin. Top plants are those that will find weaknesses in Aspdin, increasing the opportunity to keep improving the system.

System maintenance: keeping Aspdin alive

The Aspdin system by this step has been effectively and strategically deployed all over the company. There is no doubt that improvements will be required, bugs will be found, issues will be faced, and new functionalities will be requested.

The lack of maintenance is one big cause of IT systems being abandoned. Worse, maintenance that is wrongly focused or too expensive is also a main cause of systems´ deaths. The following principles can be taken into consideration:

1. Establishing Level1 operations guides is the best way to prevent the maintenance team from receiving “dumb” requests for assistance. When an error occurs with the Aspdin system, plant users should be asked to follow simple and fast actions (like a reboot) before calling the Aspdin service center.

2. Establishing Level2 operations guides is the best way for the maintenance team to treat the most common issues that cannot be solved directly by users.

3. A cloud solution is the best way to have cheaper maintenance costs. The Aspdin system could be centralized, having the possibility to run production environments and test environments in parallel. This way, every new version of Aspdin could be tested by the global community of experts and the IT team for all deployed plants before being put into production.

In this paper we presented a new expert system that focuses on the intelligent design of different types of concrete, Aspdin. The system also optimizes the use of additives and cement which, besides being the most expensive raw materials used in the manufacture of concrete, add a lot of complexity to the decisionmaking process when employed in certain types of concrete. The quality of concrete depends precisely on the proportions of cement, additives, water, and air, considering the type of concrete that is being designed and the environment in which it will be used. We would like to conclude this paper by stating that this is one of our first attempts at applying expert systems technology to a highly complex industrial requirement such as the design of concrete. We believe that the principles illustrated here have a wider applicability and should be employed in a wider variety of industries. We would like to make the Aspdin expert system well-known in industry. This would permit its explicit knowledge to become a vehicle for the generation of tacit knowledge when the industrial community realizes that this is a good way to solve engineering problems and begins to use the same ideas in other domains.

None.

No conflict of interest.

1. Bahrammirzaee A (2010) A comparative survey of artificial intelligence applications in finance: artificial neural networks, expert system and hybrid intelligent systems. Neural Computing and Applications 19(8): 1165-1195.
2. Wen W (2010) An intelligent traffic management expert system with RFID technology. Expert Systems with Applications 37(4): 3024-3035.
3. Liao S (2005) Expert System methodologies and applications –a decade review from 1995 to 2004. Expert Systems with Applications 28(1): 93-103.
4. Cairó O, Guardati S (2012) The KAMET II Methodology: Knowledge Acquisition, Knowledge Modeling, and Knowledge Generation. Expert Systems with Applications 39(9): 8108-8114.
5. Noy N, Sintek M, Decker M, Crubézy M, Fergerson R, et al. (2001) Creating semantic web contents with protégé-2000. IEEE Intelligent Systems 16 (2): 60–71.
6. Arioz O, Kilinc K, Tuncan M, Ramyar K, Tuncan A (2013) An Experimental Study on the Evaluation of Concrete Test Results. Nondestructive Testing of Materials and Structures 6: 347-352.
7. Sun R, Merrill E, Peterson T (2001) From implicit skills to explicit knowledge: a bottom-up model of skill learning. Cognitive Science 25(2): 203-244.
8. Nonaka I, Toyama R, Konno N (2000) SECI, Ba and Leadership: A Unified Model of Dynamic Knowledge Creation. Long Range Planning 33(2000): 5-34.
9. Nonaka I, von Krogh G (2009) Perspective-Tacit Knowledge and Knowledge Conversion: Controversy and Advancement in Organizational Knowledge Creation Theory. Organization Science 20(3): 635-652.
10. Francis AJ (1978) The Cement Industry 1796-1914: A History, David & Charles, Newton Abbot, United Kingdom.
11. McLafferty I (2004) Focus group interviews as a data collecting strategy. Journal of Advanced Nursing 48(2): 187-194.
12. Silfwerbrand J (2012) Sustainable concrete is more than just durable concrete. Structural Concrete 13(1): 1-2.
13. Li M, Li V (2011) High-Early-Strength Engineered Cementitious Composites for Fast, Durable Concrete Repair—Material Properties. Materials Journal 108: 3-12.
14. Berndt M (2009) Properties of sustainable concrete containing fly ash, slag and recycled concrete aggregate. Construction and Building Materials 23(7): 2606-2613.
15. Bickey J, Hooton R, Hover K (2006) Performance Specifications for Durable Concrete. Concrete International 28(9): 51-57.
16. Mather B (2004) Concrete durability. Cement and Concrete Composites 26(1): 3-4.
17. De Schutter G (2002) Fundamental study of early age concrete behaviour as a basis for durable concrete structures. Materials and Structures 35(1): 15-21.
18. Libby JR (1990) Modern Prestressed Concrete: Design Principles and Construction Methods (4th edition), Springer Verlag, Berlin, Germany.