- Email: [email protected]
Progressive Domain Focalization in Intelligent Control Systems
Copyright © IFAC Algorithms and Architectures for Real-Time Control, Cancun, Mexico, 1998
PROGRESSIVE DOMAIN FOCALIZATION IN INTELLIGENT CONTROL SYSTEMS
Ricardo Sanz·, Idoia Alarcon f , Miguel Sega"a·, Jose A. Clavijo· and Angel de Antonio • Universidad Politecnica de Madrid' Instituto de Ingenieria del Conocimiento Madrid, SPAIN e-mail: [email protected]
f
Abstract: Advanced information processing technologies are providing advanced controllers with capabilities to tackle control problems of intrinsic complexity. Methods to cope with the software-intensive control system development are needed, because quality issues in control software are of extreme importance. Architecture based development provides a clear pathway to quality; focusing on component based control system development. In the case of intelligent controllers, advanced control modules (expert, fuzzy, neural, etc.) can be built to be reusable. In the ideal situation, application construction would be a matter of plugging in the controllers and then making a custornization work of them. Copyright © J998 IFA C. Keywords: Intelligent Control, Industrial process control, Architecture, Software
Engineering, Distributed Computer Control Systems.
1.
perform actlviUes; and they are not absolutely measurable properties of an isolated system. What we can conclude is that one system behaves more intelligently or more autonomously than other. Intelligence is related to the capability of solving complex tasks. This means that intelligence is considered greater in those systems than can solve more complex tasks. Autonomy is related to the capability of performing the tasks in an independent, helpless way.
INTRODUCTION
Complete autonomy is the final -quite far- target for most of us. Autonomy means, for a system, to be capable of performing the assigned tasks without recurring to external help sources. Our approach to autonomy is constructive. This means we are trying to achieve a method to build up the required degrees of intelligence to perform a specified collection of tasks using a modular-functional approach (Sanz et aI., 1994). 1. I
We conclude that intelligence relations should be established as a function of quality of results for specific tasks. So we should talk about intelligence in performing specific tasks (finding objects, controlling arms, ordering boxes, perceiving targets, etc.) and not as global properties of systems.
The Concept ofAutonomy and Intelligence
The characterization of what is autonomy or what is intelligence has been a matter of disagreement during decades. For us the terms have simple engineering meanings, because we are aware that these terms refer to attributes that are not classic -boo lean valued- concepts. The concepts of autonomy and intelligence are pure fuzzy concepts. They refer to the degree of presence of some property in a system, always bearing in mind that these properties should be analyzed from the point of view that they have only sense in relation with task accomplishment of the system.
The same type of analysis can be done for autonomy. We must say that A is more autonomous than B performing task T and not that A is an autonomous system!. When we use the expression intelligent autonomous systems we mean systems that solve more complex tasks than others, that obtain better results and that do
This means that autonomy and intelligence are not intrinsic properties but relations among systems that
I Obviously, in ideal conditions, there will be absolutely autonomous and intelligent systems.
53
need less help from external entities to achieve their results.
2.
WHAT IS ARCHITECTURE ?
There are lots of definitions of software architecture. Almost all of them agree in the basic idea that it is a design of something. The disagreement appears when trying to identify that something.
In accordance with some trends in the artificial intelligence community regarding the embodiment need for true intelligence, we believe that the true search of artificial intelligence is the search done by control engineers. Control systems are minds for
As a thought experiment, think in the design of a
Domain Domain Analysis
Reusable
Domain ArcMecture
ComponenV
Generator
Development
Asset
Development
Application DevelOpment based on Reusable
Apphcation
Design
PII~'ecfc~fIcI-~g-:,=i: ArcMecture
Assets
Application
Fig. 1: The ARPA STARS architecture based development process.
artificial bodies; minds that are being built -this is the artificial part- to perform well in the tasks assigned to the entity -this is the intelligence part.
complex system: it is -almost ever- a hierarchical description. It has a basic depiction at the root node and progressively clarifying descriptions at progressively deep echelons. It is the same for complex software systems. For us, the architecture of such a system is some subtree rooted in the root of the hierarchy. The actual extent is a matter of preferences. For some, even the last leaf of the tree is part of the architecture. For others, only the first echelon of nodes.
1.2 Intelligent ConIrol Systems
The basis for autonomous intelligent behavior is the control system of the autonomous entitl. The control system of an intelligent autonomous machine is an artificial mind in the sense used by Franklin (1995). The term Intelligent Control Systems, used by most researchers in the automatic control community, groups an heterogeneous collection of control systems whose complexity ranges from the simplest fuzzy controller to an integrated complete control system for a whole plant. For many authors intelligent control is related to the type of technology employed in its construction (usually expert, fuzzy or neural systems).
2.1 Architecture Based Develcpment The software engineering community, and in particular, the autonomous systems community, is becoming progressively aware of the importance of software architecture. Architecture based development is seen as the "good way" to achieve high levels of software qUality. Especially those referred to non-functional requirements for the software systems.
For us, it means capability to perform tasks achieving better results. Normally, depending on the complexity of the task, the soft computing systems attain better results than conventional controllers. However, in many cases, conventional control systems (i.e. mathematical controllers) perform better. In these situations, we will say that these controllers are more intelligent than their "intelligent" counterparts.
As Clements (1996) say, architecture based development offers promising perspectives that we are trying to achieve for autonomous control systems: •
• • •
Apart from the intrinsic physical capabilities to perfonn the tasks assigned to it.
2
•
54
Systems can be built in a rapid, cost-effecti ve manner by importing (or generating) large externally developed components. It is possible to predict qualities analyzing the architecture Developing product lines sharing architectural design Separation of interface and implementation at the component level Advantages of design variability restrictions
Based on domain analysis, generic architectures are proposed to address a whole bunch of applications in a specific domain. See in Figure 1 to the architecture based process proposed by the ARP A STARS project. Development is divided in two separate phases:
Fischer (1996) proposes with INTERRAP an agent architecture with three layers: • A behavior based layer • A local planning layer • A cooperative planning layer The theory of Hierarchically Intelligent Control systems proposes the following layers:
Domain engineering: One effort shared by a complete collection of instances of a product line. Its final product is threefold: a domain model, a generic architecture and some reusable components. • Application engineering: The process of getting the real applications (the products in the product line). A great level of effort has been put in the last years in addressing the architectural problem for all types of software systems. In the case of autonomous systems, many generic architectures have been proposed and components developed. Stunningly, most of them use a layered approach based on three levels of control. •
An execution level : hardware and software controllers. • A coordination level • A knowledge based organization level The contents of the layers seem quite similar in most cases but without a clear relation between them. The triple layering seems as an externalization of our modes of behavior: •
• . Reaction: A reaction follows immediately a perception. • Task: A sequence (possibly a tree) of terns perception-7 action -7follow-up • Plan: Neither real perception nor real action. Making task trees for the future.
2.2 The magic o/three
The layering concept is quite natural from the engineering point of view. What is not so immediate is that in many cases the proposed number of relevant- layers is three. 3 seems to be a magic number for layered intelligent control, why?
2.3 Still some problems
In the case of the layered architectures mentioned, when going down to real applications in the industry, the layering concept is still maintained as a principle. But in the final implementation, the layering is not as clear as it should be. It is not easy to say neither the number of layers nor their relations. In many real implementations, engineers solve real problems patching the clean layered design, implementing ad hoc solutions to specific sections of the system under development.
Some examples at hand of these 3 tier layered architectures are: HINT: Heterogeneous Integration Architecture (HINT, 1994). The three intelligent levels specified for the HINT blackboard are: Operational: In charge of continuous state maintenance. • Tactical: In charge of task level related activities (by example problem solving). • Strategic: In charge of attaining high level objectives: production optimization, quality, safety, etc. The reasoning and deciding component (RDC) of the COSY agent architecture proposed by Haddadi (1996) is decomposed in three layers: •
Component reusability is not as high as it should be if we give credit to the claims of the architectural method connoisseurs. The final niches where these systems are applied are too narrow to reuse generic components thoroughly. Great efforts in adaptation and construction of specific elements are needed to be able to reuse even the generic architectural design. 3.
• Strategic: What to do. • Tactical: How to do it. • Executional: When to do it. 3T is a three tier (so the name) architecture for intelligent robots (Bonasso et aI., 1996). The layers are:
• • •
THE COMPLEXITY OF INTELLIGENT CONTROL SYSTEMS
The conventional approach to intelligent control system is to employ an off-the-self architecture, normally based on the type of tool employed (For example BB if using HINT or distributed if employing RT-Works).
A dynamically reprogramable set of reactive skills coordinated by a skill manager A sequencing capability to activate or deactivate skills to accomplish specific tasks. A deliberative planning capability with deep reasoning.
But there are lots of matters to solve: • •
55
Feature issues: Real-time, distributed, heterogeneous, intelligent, etc. Development issues: analysis, design, implementation, integration, testing, maintenance, etc .
using subcognitive approaches -for example neural networks. In the last case, some form of learning or adaptation is necessary to achieve specific functionality.
Support issues: Operating systems, protocols, artificial intelligence tools, etc. New trends in software architecture for complex controller implementation are appearing to tackle with these problems. 4. A CONSTRUCTIVE APPROACH TO ARTIFICIAL MINDS •
Our research is based in a simple hypothesis: that foundations of intelligent behavior can be independent of the task at hand. This leads to a component based, modular approach to artificial mind construction (Alarcon et al., 1994). We think that there are mechanisms for minds that can be reused in several tasks. The level of task independence can vary from mechanism to mechanism, but we believe that they can be constructed with modularity and composability properties (van der Linden and Muller, 1995).
•
Simplicity vs complexity: It is not the same a mind for a welding robot that a mind for a submarine exploration robot. Complexity, as mentioned before, is the main issue of intelligence.
•
Constructive vs evolutive: Minds can be built from their parts producing a somewhat static final structure or can be grown up from stupid stuff using some form of stuff evolution.
We want to address the issue of constructiveness of complex, design based minds. We want to use a globally top-down designed mind architecture, using a constructive approach to the mind component integration problem. We believe that the constructive way is the most effective way to achieve really complex artificial minds, in terms of money spent in their construction.
Whole autonomous systems, elementary mechanisms of mind or basic implementation technologies, can be managed with a design space (Garlan, 1995) approach in which different orthogonal properties are used to classify mind designs. Some of the dimensions of this design space are: •
•
This does not mean that we neglect the use of evolutionary or bottom-up models. We think that these models are extremely useful -and even better in some cases- to build specific mind components, but their usefulness decreases when the global mind complexity increases; obviously due to task complexity.
Analysis vs design: Some artificial mind designs are based on models of biological systems; they are built using an analytical approach. From the other side, the type of minds we want to address are designed minds; models of minds that do not resemble known models of biological systems, but that have been designed for a specific purpose.
Our proposed method to autonomous intelligent system construction is based on an almost classical sequence of steps: • • •
Top-down vs bottom-up: Some minds are built using high-level cognitive approaches -for example expert systems- and others are built
Specification of complex tasks Analysis and decomposition in canonical tasks Design of task solving components
----
Domain Engineering
-
c :-ponent
Application Engineering
Fig. 2: Progressive domain focalization. A way to deep reuse and domain generalization.
56
6.
• Design of integration components • Construction of task components • Construction of integration components • Component integration Our approach is near to what Stein calls modular functionalism , because we think that evolutionary or not modular approaches do not scale well from the toy problems in which they are usually employed. 5.
ICA: A CORBA BASED SCALABLE APPROACH
The approach we have taken to achieve this component development in progressively narrow domains, is the implementation of an extensible collection of agents upon an integrative middleware using the CORBA model of heterogeneous integration. The architectural methodology is based in the use of these agents to implement control systems design patterns that address specific problems in an autonomous controller environment. In order to provide a coherent agent implementation framework we have developed ICa. It offers technology to adapt generic architectural design patterns to specific implementations, tailoring artificial intelligence based architectures to the concrete tasks posed to the autonomous system. The system can then be built by means of composition of functional modules atop the basic integration infrastructure. The modules are constructed by instantiation and adaptation of task oriented object frameworks to implement the collection of interacting agents that will constitute the system mind.
A REUSE-BASED CONSTRUCTION MODEL
The model we propose for artificial minds is based in the agency concept. We have selected this model not because it resembles the human mind but because it offers a whole bunch of engineering alternatives, based on its intrinsic flexibility. When searching for a technology to implement autonomous systems, we must identify the requirements posed to that technology. Requirements are so varying that no simple technology can comply with this. Flexibility, extensibility and scalability are desirable properties for any type of software. In the case of background software for autonomy, they are not desirable but indispensable properties.
A sample collection of agents can be seen in figure 3. This is the inheritance tree of agents used to implement fuzzy systems for control and data validation purposes in the ESPRIT DIXIT project.
5.1 Progressive Domain Focalization
The way we have envisioned to support this constructive approach is to provide a framework for intelligent component reuse where flexibility (adaptability and extensibility) are main concerns for component developers.
The agents shown in the figure are:
This method is based in what we call progressive domainJocalization. The concept isn't new at all, it is a classical object-oriented concept. The main idea is that the separation into domain and application proposed by most architecture base development methods is valid only in crisp domains. Autonomous systems domain is intrinsically fuzzy. Domain analysis cannot be performed adequately if the domain is unclear. The basic idea is that what you can do is to progressively focalize domains until final, deployable applications are reached. But components can be produced at any subdomain engineering level. In Figure 2, a development method derived from the STARS model is presented with one intermediate subdomain. The labeling of layers as domain, subdomain and application is done to match it against the original STARS model. In reality, they should be labeled always as domain activities, being application engineering another term to refer to the narrower domain engineering (or the deployment domain).
•
ICa Core Agent: basic behavior for all ICa compliant agents.
•
ICa MultiThreading Agent: Extensions to basic behavior to provide a MT behavior to ICa agents.
•
ICa Real-Time Agent: Extensions to manage real-time issues: fixed priority request scheduling, QoS in transports, etc.
•
ICa Fault Tolerant Agent: Extensions to provide FT' behavior: replication, mobility, persistence, etc.
•
DIXIT Agent: Basic be ha vi or for the subdomain of strategical continuous process control. The target domain of DIXIT.
•
FL Agent: A fuzzy inference engine and fuzzy knowledge base management system.
•
RiskMan FFV Agent: Fuzzy technology based filtering and validation of data coming from plant (RiskMan is the name of a DIXIT demonstrator for chemical plant emergency management).
•
Fuzzy Control Agent: A fuzzy control agent for domains more generic than DIXIT (Sanz et al. (1996).
57
7.
CONCLUSIONS
8.
Domain focalization is not linear nor tree structured. It is a directed graph of domain analysis nodes with focalization relations. This graph can be mapped to the implementation of generic agents, that are designed and implemented bearing in mind user requirements for a specific domain. With users we mean potential users of the component, not only final users of a deployed application.
REFERENCES
Alarcon, M .l., P. Rodriguez, ,L.B. Almeida, R. Sanz, L. Fontaine, P. Gomez, X. Alaman, P. Nordin, H. Bejder and E. de Pablo (1994). Heterogeneous Integration Architecture for Intelligent Control.; Intelligent Systems Engineering, Autumn 1994. Bonasso, R.P., D. Kortenkamp, D. P. Miller and M. Slak. (1996) Experiences with an Architecture for Intelligent, Reactive Agents. In Intelligent Agents Il. M . Wooldridge, J.P. Muller and M. Tambe. Springer Veriag, pp. 187-202.
ICa is still under development of basic components, in particular we are working in the implementation of RT an FT agents, addressing the problems of
Clements, P.e. (1996) Coming Attraction in Software Architecture. CMU/SEI-96-TR-008. Fischer, G. (1994) Domain-Oriented Design Environments. Fischer, G. Automated Software Engineering, Vo!. 1 No. 2, pp. 177-203. Franklin, S. (1995) Artificial Minds. Stan Franklin. MIT Press. Garlan, D. (1995) Research Directions in Software Architecture. ACM Computing Surveys, Vol. 27, No. 2. Haddadi, A (1996) Communication and Cooperation in Agent Systems. Afsaneh Haddadi. Springer. HINT (1994) HINT Manualfor System Developers. HINT Consortium, 1994. Van der Linden, F.1. and J.K. Muller (1995) Creating Architectures with Building Blocks. IEEE Software, November 1995. Sanz, R., R.Galan, AJimenez, F.Matia, J.Ve1asco and G.Martinez (1994) Computational Intelligence in Process Control. ICNN'94, IEEE International Conference in Neural Networks. Oriando, USA.
Fig. 3: lCa Generic Agent. Promoting component reuse in progressive domain focalization architecture based development. functional composability of agents.
Sanz, R., F.Matia, R.Galan and A. Jimenez (1996) Integration of Fuzzy Technology in Complex Process Control Systems. FLAMOC'96. Sydney, Australia, 1996.
The DIXIT project under which this development has been done will finish in July 98 .
58
PROGRESSIVE DOMAIN FOCALIZATION IN INTELLIGENT CONTROL SYSTEMS
Ricardo Sanz·, Idoia Alarcon f , Miguel Sega"a·, Jose A. Clavijo· and Angel de Antonio • Universidad Politecnica de Madrid' Instituto de Ingenieria del Conocimiento Madrid, SPAIN e-mail: [email protected]
f
Abstract: Advanced information processing technologies are providing advanced controllers with capabilities to tackle control problems of intrinsic complexity. Methods to cope with the software-intensive control system development are needed, because quality issues in control software are of extreme importance. Architecture based development provides a clear pathway to quality; focusing on component based control system development. In the case of intelligent controllers, advanced control modules (expert, fuzzy, neural, etc.) can be built to be reusable. In the ideal situation, application construction would be a matter of plugging in the controllers and then making a custornization work of them. Copyright © J998 IFA C. Keywords: Intelligent Control, Industrial process control, Architecture, Software
Engineering, Distributed Computer Control Systems.
1.
perform actlviUes; and they are not absolutely measurable properties of an isolated system. What we can conclude is that one system behaves more intelligently or more autonomously than other. Intelligence is related to the capability of solving complex tasks. This means that intelligence is considered greater in those systems than can solve more complex tasks. Autonomy is related to the capability of performing the tasks in an independent, helpless way.
INTRODUCTION
Complete autonomy is the final -quite far- target for most of us. Autonomy means, for a system, to be capable of performing the assigned tasks without recurring to external help sources. Our approach to autonomy is constructive. This means we are trying to achieve a method to build up the required degrees of intelligence to perform a specified collection of tasks using a modular-functional approach (Sanz et aI., 1994). 1. I
We conclude that intelligence relations should be established as a function of quality of results for specific tasks. So we should talk about intelligence in performing specific tasks (finding objects, controlling arms, ordering boxes, perceiving targets, etc.) and not as global properties of systems.
The Concept ofAutonomy and Intelligence
The characterization of what is autonomy or what is intelligence has been a matter of disagreement during decades. For us the terms have simple engineering meanings, because we are aware that these terms refer to attributes that are not classic -boo lean valued- concepts. The concepts of autonomy and intelligence are pure fuzzy concepts. They refer to the degree of presence of some property in a system, always bearing in mind that these properties should be analyzed from the point of view that they have only sense in relation with task accomplishment of the system.
The same type of analysis can be done for autonomy. We must say that A is more autonomous than B performing task T and not that A is an autonomous system!. When we use the expression intelligent autonomous systems we mean systems that solve more complex tasks than others, that obtain better results and that do
This means that autonomy and intelligence are not intrinsic properties but relations among systems that
I Obviously, in ideal conditions, there will be absolutely autonomous and intelligent systems.
53
need less help from external entities to achieve their results.
2.
WHAT IS ARCHITECTURE ?
There are lots of definitions of software architecture. Almost all of them agree in the basic idea that it is a design of something. The disagreement appears when trying to identify that something.
In accordance with some trends in the artificial intelligence community regarding the embodiment need for true intelligence, we believe that the true search of artificial intelligence is the search done by control engineers. Control systems are minds for
As a thought experiment, think in the design of a
Domain Domain Analysis
Reusable
Domain ArcMecture
ComponenV
Generator
Development
Asset
Development
Application DevelOpment based on Reusable
Apphcation
Design
PII~'ecfc~fIcI-~g-:,=i: ArcMecture
Assets
Application
Fig. 1: The ARPA STARS architecture based development process.
artificial bodies; minds that are being built -this is the artificial part- to perform well in the tasks assigned to the entity -this is the intelligence part.
complex system: it is -almost ever- a hierarchical description. It has a basic depiction at the root node and progressively clarifying descriptions at progressively deep echelons. It is the same for complex software systems. For us, the architecture of such a system is some subtree rooted in the root of the hierarchy. The actual extent is a matter of preferences. For some, even the last leaf of the tree is part of the architecture. For others, only the first echelon of nodes.
1.2 Intelligent ConIrol Systems
The basis for autonomous intelligent behavior is the control system of the autonomous entitl. The control system of an intelligent autonomous machine is an artificial mind in the sense used by Franklin (1995). The term Intelligent Control Systems, used by most researchers in the automatic control community, groups an heterogeneous collection of control systems whose complexity ranges from the simplest fuzzy controller to an integrated complete control system for a whole plant. For many authors intelligent control is related to the type of technology employed in its construction (usually expert, fuzzy or neural systems).
2.1 Architecture Based Develcpment The software engineering community, and in particular, the autonomous systems community, is becoming progressively aware of the importance of software architecture. Architecture based development is seen as the "good way" to achieve high levels of software qUality. Especially those referred to non-functional requirements for the software systems.
For us, it means capability to perform tasks achieving better results. Normally, depending on the complexity of the task, the soft computing systems attain better results than conventional controllers. However, in many cases, conventional control systems (i.e. mathematical controllers) perform better. In these situations, we will say that these controllers are more intelligent than their "intelligent" counterparts.
As Clements (1996) say, architecture based development offers promising perspectives that we are trying to achieve for autonomous control systems: •
• • •
Apart from the intrinsic physical capabilities to perfonn the tasks assigned to it.
2
•
54
Systems can be built in a rapid, cost-effecti ve manner by importing (or generating) large externally developed components. It is possible to predict qualities analyzing the architecture Developing product lines sharing architectural design Separation of interface and implementation at the component level Advantages of design variability restrictions
Based on domain analysis, generic architectures are proposed to address a whole bunch of applications in a specific domain. See in Figure 1 to the architecture based process proposed by the ARP A STARS project. Development is divided in two separate phases:
Fischer (1996) proposes with INTERRAP an agent architecture with three layers: • A behavior based layer • A local planning layer • A cooperative planning layer The theory of Hierarchically Intelligent Control systems proposes the following layers:
Domain engineering: One effort shared by a complete collection of instances of a product line. Its final product is threefold: a domain model, a generic architecture and some reusable components. • Application engineering: The process of getting the real applications (the products in the product line). A great level of effort has been put in the last years in addressing the architectural problem for all types of software systems. In the case of autonomous systems, many generic architectures have been proposed and components developed. Stunningly, most of them use a layered approach based on three levels of control. •
An execution level : hardware and software controllers. • A coordination level • A knowledge based organization level The contents of the layers seem quite similar in most cases but without a clear relation between them. The triple layering seems as an externalization of our modes of behavior: •
• . Reaction: A reaction follows immediately a perception. • Task: A sequence (possibly a tree) of terns perception-7 action -7follow-up • Plan: Neither real perception nor real action. Making task trees for the future.
2.2 The magic o/three
The layering concept is quite natural from the engineering point of view. What is not so immediate is that in many cases the proposed number of relevant- layers is three. 3 seems to be a magic number for layered intelligent control, why?
2.3 Still some problems
In the case of the layered architectures mentioned, when going down to real applications in the industry, the layering concept is still maintained as a principle. But in the final implementation, the layering is not as clear as it should be. It is not easy to say neither the number of layers nor their relations. In many real implementations, engineers solve real problems patching the clean layered design, implementing ad hoc solutions to specific sections of the system under development.
Some examples at hand of these 3 tier layered architectures are: HINT: Heterogeneous Integration Architecture (HINT, 1994). The three intelligent levels specified for the HINT blackboard are: Operational: In charge of continuous state maintenance. • Tactical: In charge of task level related activities (by example problem solving). • Strategic: In charge of attaining high level objectives: production optimization, quality, safety, etc. The reasoning and deciding component (RDC) of the COSY agent architecture proposed by Haddadi (1996) is decomposed in three layers: •
Component reusability is not as high as it should be if we give credit to the claims of the architectural method connoisseurs. The final niches where these systems are applied are too narrow to reuse generic components thoroughly. Great efforts in adaptation and construction of specific elements are needed to be able to reuse even the generic architectural design. 3.
• Strategic: What to do. • Tactical: How to do it. • Executional: When to do it. 3T is a three tier (so the name) architecture for intelligent robots (Bonasso et aI., 1996). The layers are:
• • •
THE COMPLEXITY OF INTELLIGENT CONTROL SYSTEMS
The conventional approach to intelligent control system is to employ an off-the-self architecture, normally based on the type of tool employed (For example BB if using HINT or distributed if employing RT-Works).
A dynamically reprogramable set of reactive skills coordinated by a skill manager A sequencing capability to activate or deactivate skills to accomplish specific tasks. A deliberative planning capability with deep reasoning.
But there are lots of matters to solve: • •
55
Feature issues: Real-time, distributed, heterogeneous, intelligent, etc. Development issues: analysis, design, implementation, integration, testing, maintenance, etc .
using subcognitive approaches -for example neural networks. In the last case, some form of learning or adaptation is necessary to achieve specific functionality.
Support issues: Operating systems, protocols, artificial intelligence tools, etc. New trends in software architecture for complex controller implementation are appearing to tackle with these problems. 4. A CONSTRUCTIVE APPROACH TO ARTIFICIAL MINDS •
Our research is based in a simple hypothesis: that foundations of intelligent behavior can be independent of the task at hand. This leads to a component based, modular approach to artificial mind construction (Alarcon et al., 1994). We think that there are mechanisms for minds that can be reused in several tasks. The level of task independence can vary from mechanism to mechanism, but we believe that they can be constructed with modularity and composability properties (van der Linden and Muller, 1995).
•
Simplicity vs complexity: It is not the same a mind for a welding robot that a mind for a submarine exploration robot. Complexity, as mentioned before, is the main issue of intelligence.
•
Constructive vs evolutive: Minds can be built from their parts producing a somewhat static final structure or can be grown up from stupid stuff using some form of stuff evolution.
We want to address the issue of constructiveness of complex, design based minds. We want to use a globally top-down designed mind architecture, using a constructive approach to the mind component integration problem. We believe that the constructive way is the most effective way to achieve really complex artificial minds, in terms of money spent in their construction.
Whole autonomous systems, elementary mechanisms of mind or basic implementation technologies, can be managed with a design space (Garlan, 1995) approach in which different orthogonal properties are used to classify mind designs. Some of the dimensions of this design space are: •
•
This does not mean that we neglect the use of evolutionary or bottom-up models. We think that these models are extremely useful -and even better in some cases- to build specific mind components, but their usefulness decreases when the global mind complexity increases; obviously due to task complexity.
Analysis vs design: Some artificial mind designs are based on models of biological systems; they are built using an analytical approach. From the other side, the type of minds we want to address are designed minds; models of minds that do not resemble known models of biological systems, but that have been designed for a specific purpose.
Our proposed method to autonomous intelligent system construction is based on an almost classical sequence of steps: • • •
Top-down vs bottom-up: Some minds are built using high-level cognitive approaches -for example expert systems- and others are built
Specification of complex tasks Analysis and decomposition in canonical tasks Design of task solving components
----
Domain Engineering
-
c :-ponent
Application Engineering
Fig. 2: Progressive domain focalization. A way to deep reuse and domain generalization.
56
6.
• Design of integration components • Construction of task components • Construction of integration components • Component integration Our approach is near to what Stein calls modular functionalism , because we think that evolutionary or not modular approaches do not scale well from the toy problems in which they are usually employed. 5.
ICA: A CORBA BASED SCALABLE APPROACH
The approach we have taken to achieve this component development in progressively narrow domains, is the implementation of an extensible collection of agents upon an integrative middleware using the CORBA model of heterogeneous integration. The architectural methodology is based in the use of these agents to implement control systems design patterns that address specific problems in an autonomous controller environment. In order to provide a coherent agent implementation framework we have developed ICa. It offers technology to adapt generic architectural design patterns to specific implementations, tailoring artificial intelligence based architectures to the concrete tasks posed to the autonomous system. The system can then be built by means of composition of functional modules atop the basic integration infrastructure. The modules are constructed by instantiation and adaptation of task oriented object frameworks to implement the collection of interacting agents that will constitute the system mind.
A REUSE-BASED CONSTRUCTION MODEL
The model we propose for artificial minds is based in the agency concept. We have selected this model not because it resembles the human mind but because it offers a whole bunch of engineering alternatives, based on its intrinsic flexibility. When searching for a technology to implement autonomous systems, we must identify the requirements posed to that technology. Requirements are so varying that no simple technology can comply with this. Flexibility, extensibility and scalability are desirable properties for any type of software. In the case of background software for autonomy, they are not desirable but indispensable properties.
A sample collection of agents can be seen in figure 3. This is the inheritance tree of agents used to implement fuzzy systems for control and data validation purposes in the ESPRIT DIXIT project.
5.1 Progressive Domain Focalization
The way we have envisioned to support this constructive approach is to provide a framework for intelligent component reuse where flexibility (adaptability and extensibility) are main concerns for component developers.
The agents shown in the figure are:
This method is based in what we call progressive domainJocalization. The concept isn't new at all, it is a classical object-oriented concept. The main idea is that the separation into domain and application proposed by most architecture base development methods is valid only in crisp domains. Autonomous systems domain is intrinsically fuzzy. Domain analysis cannot be performed adequately if the domain is unclear. The basic idea is that what you can do is to progressively focalize domains until final, deployable applications are reached. But components can be produced at any subdomain engineering level. In Figure 2, a development method derived from the STARS model is presented with one intermediate subdomain. The labeling of layers as domain, subdomain and application is done to match it against the original STARS model. In reality, they should be labeled always as domain activities, being application engineering another term to refer to the narrower domain engineering (or the deployment domain).
•
ICa Core Agent: basic behavior for all ICa compliant agents.
•
ICa MultiThreading Agent: Extensions to basic behavior to provide a MT behavior to ICa agents.
•
ICa Real-Time Agent: Extensions to manage real-time issues: fixed priority request scheduling, QoS in transports, etc.
•
ICa Fault Tolerant Agent: Extensions to provide FT' behavior: replication, mobility, persistence, etc.
•
DIXIT Agent: Basic be ha vi or for the subdomain of strategical continuous process control. The target domain of DIXIT.
•
FL Agent: A fuzzy inference engine and fuzzy knowledge base management system.
•
RiskMan FFV Agent: Fuzzy technology based filtering and validation of data coming from plant (RiskMan is the name of a DIXIT demonstrator for chemical plant emergency management).
•
Fuzzy Control Agent: A fuzzy control agent for domains more generic than DIXIT (Sanz et al. (1996).
57
7.
CONCLUSIONS
8.
Domain focalization is not linear nor tree structured. It is a directed graph of domain analysis nodes with focalization relations. This graph can be mapped to the implementation of generic agents, that are designed and implemented bearing in mind user requirements for a specific domain. With users we mean potential users of the component, not only final users of a deployed application.
REFERENCES
Alarcon, M .l., P. Rodriguez, ,L.B. Almeida, R. Sanz, L. Fontaine, P. Gomez, X. Alaman, P. Nordin, H. Bejder and E. de Pablo (1994). Heterogeneous Integration Architecture for Intelligent Control.; Intelligent Systems Engineering, Autumn 1994. Bonasso, R.P., D. Kortenkamp, D. P. Miller and M. Slak. (1996) Experiences with an Architecture for Intelligent, Reactive Agents. In Intelligent Agents Il. M . Wooldridge, J.P. Muller and M. Tambe. Springer Veriag, pp. 187-202.
ICa is still under development of basic components, in particular we are working in the implementation of RT an FT agents, addressing the problems of
Clements, P.e. (1996) Coming Attraction in Software Architecture. CMU/SEI-96-TR-008. Fischer, G. (1994) Domain-Oriented Design Environments. Fischer, G. Automated Software Engineering, Vo!. 1 No. 2, pp. 177-203. Franklin, S. (1995) Artificial Minds. Stan Franklin. MIT Press. Garlan, D. (1995) Research Directions in Software Architecture. ACM Computing Surveys, Vol. 27, No. 2. Haddadi, A (1996) Communication and Cooperation in Agent Systems. Afsaneh Haddadi. Springer. HINT (1994) HINT Manualfor System Developers. HINT Consortium, 1994. Van der Linden, F.1. and J.K. Muller (1995) Creating Architectures with Building Blocks. IEEE Software, November 1995. Sanz, R., R.Galan, AJimenez, F.Matia, J.Ve1asco and G.Martinez (1994) Computational Intelligence in Process Control. ICNN'94, IEEE International Conference in Neural Networks. Oriando, USA.
Fig. 3: lCa Generic Agent. Promoting component reuse in progressive domain focalization architecture based development. functional composability of agents.
Sanz, R., F.Matia, R.Galan and A. Jimenez (1996) Integration of Fuzzy Technology in Complex Process Control Systems. FLAMOC'96. Sydney, Australia, 1996.
The DIXIT project under which this development has been done will finish in July 98 .
58