progressive domain focalization in intelligent control systems

*Corresponding author. Tel.: #34 91 336 30 61; fax.:#34 91 564 29 61; e-mail: [email protected].

Control Engineering Practice 7 (1999) 665}671

Progressive domain focalization in intelligent control systems

Ricardo Sanz!,*, Idoia AlarcoH n", Miguel Segarra!, Jose A. Clavijo!, Angel de Antonio!

! Universidad Polite&cnica de Madrid, c/Jose& Gutierrez Abascal 2, 28006 Madrid, Spain" Universidad Auto& noma de Madrid, Spain

Received 18 August 1998; accepted 22 January 1999

Abstract

Advanced information-processing technologies are providing advanced controllers with capabilities to tackle control problems ofintrinsic complexity. Methods to cope with the di$culties of software-intensive control system development are needed, becausequality issues in control software are of extreme importance. Architecture-based development provides a clear pathway to controllerquality, focusing on component-based control system development. In the case of intelligent controllers, advanced control mod-ules (expert, fuzzy, neural, etc.) can be built to be reusable. In the ideal situation, application construction would be a matter ofmerely plugging the controllers into an architectural framework, followed by a simple customization. ( 1999 Elsevier Science ¸td.All rights reserved.

Keywords: Intelligent control; Industrial process control; Architectures; Software engineering; Distributed computer control systems

1. Introduction

Complete autonomy is the "nal, distant target of manyof the research endeavors being undertaken in automaticcontrol. Autonomy for a system means being capable ofperforming the assigned tasks without relying on externalhelp. This paper presents a constructive approach toautonomy. This means trying to achieve a methodologyto build up the required level of intelligence to performa speci"ed collection of tasks, using a modular-functionalapproach (Sanz et al., 1994) instead of evolutionary orself-organizing approaches.

1.1. The concept of autonomy and intelligence

The characterization of autonomy or intelligence hasbeen a matter of disagreement for decades. However,these terms can have simple engineering meanings, evenwhen they refer to attributes that are not classicBoolean-valued concepts. The concepts of autonomy andintelligence are pure fuzzy concepts. They refer to thedegree to which some property is present within a system,always bearing in mind that these properties should be

analyzed only in terms of the tasks to be accomplished bythe system.

This means that autonomy and intelligence are notintrinsic properties of entities but are relations betweenthem in relation to the performance of activities; there-fore they are not absolute and measurable properties ofan isolated system. What can be concluded is that onesystem can behave more intelligently or more auton-omously than another performing a speci"c activity. In-telligence is usually related to the capability to solvecomplex tasks. This means that intelligence is consideredto be greater in those systems that perform better atsolving tasks that are more complex. Autonomy is re-lated to the capability to perform the tasks in an indepen-dent, unaided way.

Intelligence level comparisons should be established asa function of the quality of the results for speci"c tasks.So it is necessary to talk about intelligence in terms ofspeci"c tasks like "nding objects, controlling arms, or-dering boxes or perceiving targets, and not as a globalproperty of a system.

The same type of analysis can be carried out for auton-omy. A system S

1can be said to be more autonomous

than another system S2

when performing task ¹, ratherthan S

1which is an autonomous system. Obviously, in

ideal conditions, systems will be fully autonomous if theyare capable of doing the assigned tasks without anyexternal assistance. The expression intelligent autonomous

0967-0661/99/$ - see front matter ( 1999 Elsevier Science Ltd. All rights reserved.PII: S 0 9 6 7 - 0 6 6 1 ( 9 9 ) 0 0 0 1 2 - X

systems therefore refers to systems that solve more com-plex tasks than others, obtain better results, and need lesshelp from external entities to achieve these results.

In accordance with the trend in the arti"cial intelli-gence community to require the embodiment of trueintelligence to have a context, it is possible to say that thetrue search for arti"cial intelligence is the search that isbeing undertaken by control engineers. Control systemsare arti"cial minds for arti"cial bodies that have a task todo in the real world; minds that have been built witha purpose } and are therfore arti,cial } and that performwell in the tasks assigned to the entity } and are thusintelligent.

1.2. Intelligent control systems

The basis for autonomous intelligent behavior is thecontroller of the autonomous system; there are obviouslyintrinsic physical capabilities, necessary to perform thetasks assigned to the autonomous system, that would beneeded in any system (for both autonomous or externallycontrolled systems). The control system of an intelligentautonomous machine is an arti"cial mind in the senseused by Franklin (1995).

The term intelligent control systems, as used by mostresearchers in the automatic control community, groupstogether a heterogeneous collection of control systemswhose complexity ranges from that of the simplest fuzzycontroller to a complete integrated control system for anentire plant. For many authors, intelligent control isrelated to the type of technology employed in the con-struction of the controller, usually soft computing: ex-pert, fuzzy or neural systems.

Intelligence means the capability to perform tasks andto achieve better results. Usually, for tasks of relativecomplexity, soft computing systems attain better resultsthan conventional controllers. However, in many cases,conventional control systems (i.e., mathematical control-lers) perform better. In these situations such controllersshould be considered more intelligent than their softcomputing counterparts, even when the latter are refer-red to as intelligent controllers.

Heterogeneous controllers, those that employ mixedtechnologies, are common, and the only way to achievecohesion } and thus "nal controller quality } is to use anarchitecture based development.

2. What is meant by 99architecture::?

There are many de"nitions of software architecture.Almost all of them agree on the basic idea that it is a partof the design of some software product. The disagreementoccurs when trying to identify what that part entails.

As a thought experiment, think about the design ofa complex system: it is almost always a hierarchical

description. In that description, there exists a root nodethat contains a basic portrait of the whole system. Deepernodes in the description tree provide progressively de-tailed descriptions of subsystems. For complex softwaresystems the same type of hierarchical description isneeded. The architecture of such a system is some sort ofsubtree founded on the hierarchy. The actual extent isa matter of preference. For some, even the last leaf of thetree is part of the architecture; for others, only the "rstechelon of nodes.

2.1. Architecture-based development

The software engineering community, and in particu-lar the autonomous systems community concerned withthis research, is becoming progressively more aware ofthe importance of software architectures. Architecture-based development is seen as a &&good way'' to achievehigh levels of software quality, especially those related tothe non-functional requirements of the software systems(Garlan, 1995).

Architecture-based development o!ers promising per-spectives, necessary for autonomous control system de-velopment. Some of the advantages are (Clements, 1996):

f Systems can be built in a rapid, cost-e!ective mannerby importing (or generating) large, externally de-veloped components.

f It is possible to predict the global qualities of the "nalsystem by analyzing the architecture.

f The development of product lines sharing the samearchitectural design is easier and cheaper.

f Separation from the interface and implementation atthe component level enhances modularity.

f Restrictions on design variability make the design pro-cess more productive and less prone to faults.

Based on domain analysis (Kang, 1990), generic archi-tectures have been proposed to address a wide spectrumof applications in a speci"c domain. Fig. 1 shows thearchitecture-based process proposed by the US Ad-vanced Research Projects Agency STARS project(STARS, 1996). The development is divided into twoseparate phases:

f Domain engineering: the e!ort shared by a completecollection of products in a product line (Its "nal resultis threefold: a domain model, a generic architectureand some reusable components.);

f Application engineering: the process of producing thereal applications (the products in the product line).

A great level of e!ort has been put in recent years intoaddressing the architectural problems for all types ofsoftware systems. In the case of autonomous systems,many generic architectures have been proposed, andcomponents developed. It is noticeable that most of themuse a layered approach based on three levels of control.

666 R. Sanz et al. /Control Engineering Practice 7 (1999) 665}671

Fig. 1. The ARPA STARS architecture-based development process.

2.2. The magic of three

The concept of layering is quite natural from anengineering point of view. What is not so immediatelyobvious is that in many cases, the proposed number ofrelevant layers is three. This seems to be the magicnumber for layered intelligent control. Some examples ofthese 3-tier layered architectures include:

HINT: Heterogeneous Integration Architecture (Alar-coH n et al., 1994). The three intelligence levels speci"ed forthe HINT blackboard-based system are:

f operational: in charge of continuous state maintenance;f tactical: in charge of task-level-related activities (for

example, problem solving);f strategic: in charge of achieving high level objectives

(production optimization, quality, safety, etc.).

The reasoning and decision component of the COSYagent architecture, proposed by Haddadi (1996) is com-posed of three layers:

f strategic: what to do;f tactical: how to do it;f executional: when to do it.

3T is a three-tier (hence the name) architecture forintelligent robots (Bonasso et al., 1996). The layersproposed are:

f a dynamically reprogrammable set of reactive skillscoordinated by a skill manager;

f a sequencing capability to activate or deactivate skillsto accomplish speci"c tasks;

f a deliberative planning capability with deep reasoning.

With INTERRAP Fischer (1994) proposes an agentarchitecture with three layers:

f a behavior based layer;f a local planning layer;f a cooperative planning layer.

The theory of Hierarchical Intelligent Control systems(Saridis, 1995) proposes the following layers:

f an execution level: hardware and software controllers;f a coordination level;f a knowledge based organization level.

The contents of the layers seem quite similar in mostcases. This triple layering is a conceptualization ofcommon human modes of behavior:

f Reaction: a reaction follows a perception immediately;f ¹ask: a sequence or a tree of triplets (perception,

action, follow-up);f Plan: neither real perception nor real action, but mak-

ing task trees for the future.

The completeness of this partitioning is questionablebut that does not necessarily matter, because all theseschemata o!er distilled architectural know-how that canbe reused in other applications. All of them are examplesof a design pattern (reaction-task-plan) that involvespecially tailored designs for layered systems that arethemselves designed for the purpose of controlling othersystems.

2.3. Further problems

In the case of the layered architectures mentionedabove, when real applications in industry are involved,

R. Sanz et al. /Control Engineering Practice 7 (1999) 665}671 667

the layering concept is still maintained as a principle. Butin the "nal implementation, the layering is not as clear asit should be. It is not easy to determine either the numberof layers or their relationships. In many real implementa-tions, the commissioning engineers solve real problemsby ignoring (or even rejecting) the clean layered design,and by implementing ad hoc solutions to speci"c sectionsof the system under development.

Component reusability is not as high as it should be ifcredence were given to the claims of the connoisseurs ofthe architectural method. The "nal niches where thesesystems are applied are too narrow to allow thoroughreuse of generic components, mainly due to the baddesign and implementation of the components them-selves. Great e!orts in the adaptation and constructionof speci"c elements are needed if even the generic archi-tectural design is to be reusable.

3. The complexity of intelligent control systems

The conventional approach to intelligent control sys-tems is to employ an o!-the-self architecture, normallybased on the type of tool employed in the construction ofthe intelligent system itself; for example blackboard-based if using HINT software, or distributed if employingRT-Works (a commercial product).

But there are still many problems to be solved whenusing o!-the-shelf designs:

f Feature issues: real-time operation, distributed, hetero-geneous or intelligent systems, etc.;

f Development issues: analysis, design, implementation,integration, testing, maintenance, etc.;

f Support issues: operating systems, protocols, arti"cialintelligence tools, etc.

New trends in software architectures for complex con-troller implementation are appearing in order to tacklethese problems (Sanz, 1998).

4. A constructive approach to arti5cial minds

This research is based on a simple hypothesis: that thefoundations of intelligent behavior can be independent ofthe task at hand. This leads to a reuse-intensive, compon-ent-based, modular approach to the construction of arti-"cial minds. There are mind mechanisms that can bereused in several di!erent tasks and/or systems. The levelof task independence can vary from mechanism to mech-anism, but they can be constructed with propertiesof modularity and composability (van der Linden andMuller, 1995).

Whole autonomous systems, elementary mind mecha-nisms or basic implementation technologies can bemanaged with a design space approach (Shaw and

Garlan, 1995) in which di!erent orthogonal propertiesare used to classify various designs for arti"cial minds.Some of the dimensions of this design space are:

f Analytical vs. designed: Some arti"cial mind designs arebased on models of biological systems; and are builtusing an analytical approach. But the types of minds inthis research are designed minds: models of minds thatdo not necessarily resemble known models of biolo-gical systems, but that have been designed for a speci"cpurpose.

f Top-down vs. bottom-up: Some arti"cial minds arecreated using high-level cognitive approaches, forexample expert systems, while others are built usingsubcognitive approaches, for example neural networks.In the latter case, some form of learning or adaptationis necessary to achieve a speci"c functionality.

f Simplicity vs. complexity: A mind for a welding robot isnot the same as a mind for a submarine explorationrobot. Complexity, as mentioned before, is the mainissue in higher intelligence.

f Constructive vs. evolutionary: Minds can be construc-ted from their parts; producing a somewhat static "nalstructure, or can be evolved from simple componentsevolution and adaptation.

The objective is to achieve a way of constructing com-plex, design-based minds. The construction of an auton-omous system is then based on the use of a globally,top-down designed mind architecture, together witha constructional, building-block approach to the prob-lem of integrating the mind's components. The construc-tional way is the most e!ective way to achieve reallycomplex arti"cial minds, in terms of the money and timespent in their construction. It follows the classical&&divide-and-conquer'' method of engineering to tacklecomplexity.

This does not mean that the use of evolutionary orbottom-up models should be neglected. These models areextremely useful for building speci"c mind components,and even better than constructional ones in some cases,but their usefulness decreases when the global mindcomplexity increases, obviously due to task complexity.Design-space variability is the main limiting factor foradaptive approaches to complex design problems.

The proposed method for the construction of auton-omous intelligent systems is based on an almost classicalsequence of steps:

f speci"cation of complex tasks;f architectural design;f analysis and decomposition in subtasks;f design of task-solving components;f design of integration components;f construction of task components;f construction of integration components;f component integration.


Fig. 2. Progressive domain focalization. Domain generalization and reuse.

This approach is close to modular-functionalism.Evolutionary or non modular approaches do not scaleup well from the &&toy'' problems in which they are usuallyemployed.

5. A reuse model based on agents

The model proposed for the construction of arti"cialminds is based on the agency model (MuK ller et al., 1997).This model has been selected not because it resembles thehuman mind (Minsky, 1985), but because it o!ers a wideset of engineering alternatives, due to its intrinsic #exibil-ity. Agents can have internal architectures that rangefrom simple live objects to complete BDI architectures(Beliefs, Desires, Intentions).

When searching for a technology to implement auton-omous systems, it is necessary to identify the require-ments asked of that technology. Requirements forautonomy are so varied that no single technology cancope with this variety. Flexibility, extensibility and scala-bility are desirable properties for any type of software.However, in the case of background software for auton-omy, these are not simply desirable but indispensableproperties. Object oriented development o!ers the meansfor the easy adaptation and reuse of prebuilt compo-nents.

5.1. Progressive domain focalization

The way chosen to support this constructional ap-proach is to provide an object framework for intelligentcomponent reuse, where #exibility (adaptability and

extensibility) is the main concern for the developers ofcomponents.

This method is based on a progressive domain focaliz-ation methodology. The main idea is that the separationinto domain and application, proposed by most architec-ture-based development methods, is valid only in crispdomains. As the domains of &&autonomous systems'' areintrinsically fuzzy, domain analysis cannot be performedadequately because the domain is unclear.

The basic idea is to progressively re"ne the domainuntil "nal, deployable applications are reached. Compo-nents can be produced at any subdomain engineeringlevel. In Fig. 2, a development method derived from theSTARS model is presented, with one intermediate sub-domain. The labeling of layers as domain, subdomain andapplication is done to match the original STARS model.In reality however, they can always be considered asdomain activities, as even application engineering can beconsidered as domain engineering with a narrower do-main, if done with reusability in mind.

6. ICa: A CORBA-based scalable approach

To achieve component development in progressivelynarrower domains, the methodology speci"es the imple-mentation of an extendable collection of agents upon anintegrative middleware, using the CORBA model of het-erogeneous integration (CORBA, 1998). The architec-tural methodology is based on the use of these agents toimplement control systems based on design patterns(Buschman et al., 1996) that address speci"c problems inan autonomous controller environment.


Fig. 3. ICa Generic Agent. Promoting component reuse in a progres-sive domain focalization architecture-based development.

The coherent agent implementation framework de-veloped here is called the Integrated Control Architecture(ICa). It o!ers the technology to adapt generic archi-tectural design patterns to speci"c implementations,tailoring arti"cial-intelligence-based architectures to theconcrete tasks required of a particular autonomous sys-tem. The target system can then be built by adding thefunctional modules on top of the basic integration infras-tructure. The modules are constructed by the instanti-ation and adaptation of task-oriented object frameworksto implement the collection of interacting agents that willconstitute the system's arti"cial mind.

A sample collection of agents can be seen in Fig. 3. Thisis the inheritance tree of the agents used to implementfuzzy systems for control and data-validation purposes inthe ESPRIT DIXIT project (Distributed InformationTechnology for Strategic Multiobjective Process Control).

The agents shown in the "gure are:

f ICa Core Agent: the core agent that provides the basicbehavior for all ICa compliant agents.

f ICa MultiThreading (MT) Agent: extensions to thebasic behavior to provide MT behavior to ICa agents;

f ICa Real-Time (RT) Agent: extensions to manage real-time issues ("xed priority request scheduling, QoS intransports, etc.);

f ICa Fault Tolerant (FT) Agent: extensions to provideFT behavior (replication, hot spares, mobility/recon-"gurability, persistence, etc.);

f DIXIT Agent: basic behavior for the subdomain ofstrategic continuous process control, the target do-main of DIXIT.

f FL Agent: a fuzzy inference engine and fuzzy know-ledge-base management system;

f RiskMan FFV Agent: fuzzy "ltering and validation ofdata coming from the plant (RiskMan is the name ofa DIXIT demonstrator for emergency management ofa chemical plant.);

f Fuzzy Control Agent: a fuzzy control agent for do-mains more generic than DIXIT (Sanz et al., 1996).

7. Conclusions

Domain focalization is neither linear nor tree struc-tured. It is a directed graph of domain analysis nodeswith focalization relations. This graph can be mapped tothe implementation of generic agents, which are designedand implemented according to user requirements fora speci"c domain. The term user refers not only to the"nal users of a deployed application, but also to thepotential users of the component for building newapplications.

At the time of this writing, some parts of ICa are stillunder development (elements of the RT and FT agents)and addressing the problems of the functional composa-bility of agents and the supporting methodology.

Acknowledgements

The authors would like to acknowledge "nancialsupport from the ComisioH n Interministerial de Cienciay TecnologmHa, the European Commission and theComunidad de Madrid.

References

AlarcoH n, M.I., RodrmHguez-MarmHn, P., Almeida, L.B., Sanz, R., Fontaine,L., GoH mez, P., AlamaH n, X., Nordin, P., Bejder, H., & Pablo, de E.(1994). Heterogeneous integration architecture for intelligent con-trol systems, Intelligent Systems Engineering, Autumn 1994.

Bonasso, R.P., Kortenkamp, D., Miller, D.P., & Slack, M. (1996).Experiences with an architecture for intelligent, reactive agents. In:M. Wooldridge, J.P. MuK ller & M. Tambe (Eds.), Intelligent AgentsII. (pp. 187}202). Berlin: Springer.

Clements, P.C. (1996). Coming attractions in software architecture.Technical Report CMU/SEI-96-TR-008. Pittsburg: CarnegieMellon University Software Engineering Institute.

CORBA (1998). Common Object Request Broker Architecture and Speci-,cation. Revision 2.2. The Object Management Group.

Fischer, G. (1994). Domain-oriented design environments. AutomatedSoftware Engineering, 1(2), 177}203.


Franklin, S. (1995). Arti,cial minds. Cambridge, MA: MIT Press.Garlan, D. (1995). Research directions in software architecture. ACM

Computing Surveys, 27(2).Haddadi, A. (1996). Communication and cooperation in agent systems.

Berlin: Springer.Kang, K., Cohen, S., Hess, J., Novak, W., & Peterson, S. (1990).

Feature-oriented domain analysis (FODA) feasibility study. Tech-nical Report CMU/SEI-90-TR-21. Pittsburgh: Carnegie MellonUniversity, Software Engineering Institute.

Minsky, M. (1985). ¹he society of mind. New York: Simon and Schuster.MuK ller, J.P., Wooldridge, M.J., & Jennings, N.R. (Eds.). (1997). Intelli-

gent agents III. Berlin: Springer.Sanz, R., GalaH n, R., JimeH nez, A., MatmHa, F., Velasco, J.R., & MartmHnez,

G., (1994). Computational intelligence in process control. Proceed-ings of the IEEE International Conference in Neural Networks(ICNN194). Orlando, USA.

Sanz, R., MatmHa, F., GalaH n, R., & JimeH nez, A. (1996). Integration of fuzzytechnology in complex process control systems. Proceedings of theF¸AMOC196. Sydney, Australia.

Sanz, R. (1998). Distributed objects for plant-wide integrated intelligentcontrol. Control =orkshop on Perspectives of Advanced ProcessControl. Sevilla.

Saridis, G.N. (1995). Architectures for intelligent controls. In: M.M.Gupta, & N.K. Sinha (Eds.), Intelligent Control Systems: ¹heory andApplications. IEEE Press.

Shaw, M., & Garlan, D. (1995). Software Architecture. An EmergingDiscipline. Englewood Cli!s, NJ: Prentice-Hall.

STARS (1996). Bridging the gap between domain modeling and domainarchitecture de"nition. Software ¹echnology for Adaptable, ReliableSystems (S¹ARS), Technical Report STARS-PA19-S004/001/00.

Van der Linden, F.J., & Muller, J.K. (1995). Creating architectures withbuilding blocks. IEEE Software, 12(6), 51}60.


progressive domain focalization in intelligent control systems

Documents