The big question we are asking in our quest to find answers to Distributed Artificial Intelligence potential is application of techniques engineers develop in standards and development tools that make them accessible to industrial users. The best techniques will not be widely used unless they are embedded in tools designed to support industrial activities.
Now that multiple products are becoming available, market forces will join up with technical excellence in determining the platforms best suited for products to be built in the future. Engineers who are alert to these market forces and who pay special attention to packaging and deployment of their results will see their work have the most lasting impact on the field.
This brief survey of agent systems utilised in product proposed systems must be practical, and the tools used to develop them must be packaged. Industrial systems are driven by the need to solve a practical problem, rather than curiosity about the possibility of some technology. The criterion for success in an industrial project is not how clever the technology is, or what one has learned about that technology, but how well the system solves the problem that it addresses.
The orientation to practical problems means that engineers in industry must be first of all experts in the products they manufacture, the processes they control, or the services they render. Agent technology is for them a means to an end, a tool. The more the tool fades into the background and lets them concentrate on the requirements of the problem at hand, the more likely they are to use it.
As with other technologies, detailed application issues are more likely to be discussed in venues associated with the application domain than in those dedicated to the underlying technology, and as a result the best case studies will be scattered throughout a wide range of sources.
Ultimately, application expertise is best communicated by hands-on experience not reports so engineers motivated to learn more about this area should establish joint projects with industrial partners around application problems of industrial scope and complexity, where the objective is to improve the operations of industry users rather than to generate cumbersome reports.
Practical design engineering applications of Distributed Artificial Intelligence are characterised by agents tech focus on a particular capability e.g., communication, planning, learning and seeks practical problems to demonstrate the usefulness of this capability. The engineer has a practical problem to solve, and cares much more about the speed and cost-effectiveness of the solution than about its elegance or sophistication.
To the engineer, it offers an overview of the kinds of problems faced, and some examples of agent technologies have made their way into practical application. To the engineer it explains why agents are not just the latest technical fad, but a good match to the characteristics of a broad class of real problems to include selected development projects that are not yet industrial strength.
Agents represent industrially important concepts or are being conducted in a way likely to lead to deployable technology. Also emphasises agent applications in manufacturing and physical control over other fielded industrial applications such as information-gathering agents, network administration, or business planning agents.
Like any other technology, agents are best used for problems whose characteristics require their particular capabilities. Agents are appropriate for applications that are modular, decentralised, changeable, poorly structured, and complex In some cases, a problem may exhibit or lack these characteristics, but many industrial problems can be formulated in different ways.
In these cases, attention to the characteristics during problem formulation and assessments can yield a solution that is more robust and adaptable than one supported by other technologies. Agents are pro-active objects, and share the benefits of modularity enjoyed by object technology. They are best suited to applications that fall into practical modules.
An agent has its own set of state variables, distinct from those of the used in real-life mission space.. Some subset of the agents state variables is coupled to some subset of the mission work space state variables to provide input and output. An industrial entity is a good candidate for agency if it has a well-defined set of state variables that are distinct from those utilised in mission space, and if its interfaces can be clearly identified.
The state-based view of the distinction between an agent and its mission space suggests that functional decompositions are less well suited to agent-based systems than are physical decompositions. Functional decompositions tend to share many state variables across different functions.
Separate agents must share many state variables, leading to problems of consistency and unintended interaction. A physical decomposition naturally defines distinct sets of state variables that can be managed efficiently by individual agents with limited interactions. The choice between functional and physical decomposition is often up to the engineer.
Emphasising the physical dimension enables more modular applications. Because the agent characterises a physical entity, that entity can be redeployed with minimal changes to the agents code. As a result, the cost of reconfiguration drops dramatically, and reusability increases.
Decentralisation is important because an agent is more than an object; it is a pro-active object, a bounded process. It does not need to be invoked externally, but autonomously monitors its own mission space and takes action as it considers appropriate. This characteristic of agents makes them particularly suited for applications that can be decomposed into stand-alone processes, each capable of doing useful things without continuous direction by some other process.
Many industrial processes can be organised in either a centralised or a decentralised fashion. Centralised operations focus on a central authority and elaborate bureaucracy to manage the flow of control down and information back up.
There is an alternative approach. The power of decentralisation has recently been made clear in the contrast in performance. Modern industrial strategists seek to eliminate excessive layers of management and push decision-making down to the very lowest level, and are developing the vision of the "virtual enterprise," formed for a particular market opportunity from a collection of independent firms with well-defined core competencies.
It is increasingly common for the manufacturer of a complex product to purchase much of the content in the product from other companies. For example, an automotive manufacturer might buy seats from one company, brake systems from another, air conditioning from a third, and electrical systems from a fourth, and manufacture only the chassis, body, and powertrain in its own facilities.
The suppliers of major subsystems in turn purchase much of their content from still other companies. As a result, the "production line" that turns raw materials into a vehicle is a network, or "supply chain," of many different firms. Agent-based architectures are an ideal fit to such an organisational strategy.
Agents are well suited to modular problems because they are objects. They are well suited to decentralised problems because they are pro-active objects. These characteristics combine to make them especially valuable when a problem is likely to change frequently.
Modularity permits the system to be modified one piece at a time. Decentralisation minimises the impact that changing one module has on the behaviour of other modules. Modules alone are not sufficient to permit frequent changes. In a system with a single digital thread of control, changes to a single module can cause later modules, those it invokes, to malfunction.
Decentralisation decouples the individual modules from one another, so that errors in one module impact only those modules that interact with it, leaving the rest of the system unaffected. From an industrial perspective, the ability to change a system quickly, frequently, and without damaging side effects is increasingly important to competitiveness.
In manufacturing, the product that suit’s the requirements of the most customers has a tremendous advantage. One of the most effective means to determine the features that customers like is to turn out as many different product variations as quickly as possible, sampling customer response and adjusting new offerings accordingly.
This strategy is responsible for the precipitous drop in the time-to-market for many products. The time from product concept to first production in vehicles has decreased markedly. Agent-based architectures permit reuse of much existing code and self-configuration of large portions of the system, reducing both the cost and the time needed to bring up a new factory.
An early deliverable in traditional systems design is an architecture of the application, showing which entities interact with which other entities and specifying the interfaces among them. For example, installation of a conventional system for electronic interchange among trading partners requires that one know the providers and consumers of the various goods and services being traded, so that orders can be sent to the appropriate parties.
Sometimes, determining this information in advance is extremely difficult or even impossible. Consider an electronic system to support open trading, where orders are made available to any qualified bidder. Requiring the system designer to specify the sender and recipient of each transaction would quickly lead to getting stuck in details.
From a traditional point of view, this application is poorly structured. That is, not all of the necessary structural information is available when the system is designed. Agents naturally support such an application. The fundamental distinction in an agent's view of the world is between "self" and "environment." "Self'' is known and predictable, while "environment" can change on its own within limits.
Other agents are part of this dynamic, changing environment. Depending on the complexity of individual agents, they may or may not model one another explicitly. Instead of specifying the individual entities to be interconnected and their interfaces with one another, an agent-based design need identify only the classes of entities in the system and their impact on the environment.
Because each agent is designed to interact with the environment rather than with specific other agents, it can interact appropriately with any other agent that modifies the environment within the range of variation with which other agents are prepared to deal.
Some applications are intrinsically under-specified and agents offer the only realistic approach to managing them. Even where more detailed structural information is available, the better course may be to pretend that it isn't. A system that is designed to a specific domain structure will require modification if that structure changes.
Agent technology permits system design to the classes that generate a given domain structure rather than to that structure itself, thus extending the useful life of the resulting system and reducing the cost of maintenance and reconfiguration.
One measure of the complexity of a system is the number of different behaviours it must exhibit. For example, a manufacturing job shop might produce a given part in several different ways, depending on which machines are used and in which order. The number of possible behaviours in this simple example depends exponentially on the number of different machines in the shop.
For a shop with only a few machines, one might code a separate subroutine for each possible routing, but this approach quickly becomes prohibitive as the shop grows. This example shows combinatorial complexity. The number of different interactions among a set of elements increases much faster than does the number of elements in the set.
By mapping individual agents to the interacting elements, agent architectures can replace explicit coding of this large set of interactions with generation of them at run-time. Not all of these will be useful behaviours, and one can imagine poor agent designs in which none of the generated behaviours will be appropriate.
However, appropriately designed agent architectures can move the generation of combinatorial behaviour spaces from design-time to run-time, drastically reducing effort and cost of the system to be constructed.
Modification of a system during its life can increase its complexity as well as making it poorly structured. By adopting an agent approach at the outset, systems engineers can provide a much more robust and adaptable solution that will grow to meet business requirements.
Information agents have access to multiple, potentially heterogeneous and geographically distributed information sources and do work ranging from relatively simple in-house information systems to large-scale multi-source systems.
One of the main tasks of the agents is an active search for relevant information in non-local domains on behalf of their users or other agents including retrieving, manipulating, and integrating information available from multiple sources. Agents support users in fulfilling certain tasks by hiding the complexity of a difficult task, train/teach human users, and perform sub-tasks for user.
Realistic application of Responsible Agents for Product/Process Integrated Design will have one or two dozen component agents and on the order of a hundred characteristic agents. In the current implementation, agents are not created, destroyed, divided, or fused during operation, but as the system matures, designers will need a way to add both component and characteristics agents to the community as a design is refined.
Agents communicate digitally, and currently use point addressing. Messages do not persist outside of agents, and agents do not move over the network. Fixed market protocol is used but also provides for the humans behind component agents to communicate directly with one another using Standard work orders.
The initial configuration of component agents and characteristic agents is defined when the system is initialised, but component agents can engage in markets for other characteristics as the system runs.
The fundamental challenge in applying agents to both planning and control is satisfying a global criterion on the basis of parallel local decisions. In spite of the natural benefit that centralisation has in dealing with control criteria. Case studies show that many users have found agents an even better approach.
Operational systems must be maintained, and it is much easier to maintain a set of well-bounded modules than to make changes to a large programme. The move toward supply chains means that the manufacturing system is geographically distributed, and agent decentralisation reduces communication bottlenecks and permits local parts of the enterprise to continue operation during temporary lapses in connectivity.
Competitiveness increasingly depends on adjusting system operations frequently to track customer requirements, benefiting from how agent systems can be changed. The ability of agents to deal with poorly structured systems is less important in the operation of an engineered system than in its design.
However, the ability of agents to deal with dynamically changing structures means that digital communication can now be applied to manage systems such as networks of trading partners that formerly required extensive manual attention. The increased complexity that agents can manage also extends the scope of operational problems to which they can be applied.
1. What in a system becomes an agent?
Classical engineering techniques lead many systems designers toward "functional decomposition." For example, manufacturing information systems typically contain modules dedicated to functions such as "scheduling," "materiel management," and "maintenance," suggesting that these functions should be assigned to distinct agents. Most industrial agent applications are additions to existing systems, and functionally oriented legacy systems may be most easily attached by encapsulating them as functional agents. A watchdog agent may usefully monitor the behaviour of a population of physical agents for important system states that local agents cannot perceive.
2. How Does each agent model the world?
Any agent that functions in a changing world must model that world internally. However, agents differ in the how developed the knowledge representation and reasoning are used for this task. Some agents model aspects of their world explicitly, so that they can reason about the model. In other agents, these models are hard-wired and often distributed throughout the agent's architecture.
3. How do agents differ in the scope of what they model?
It depends if agents individuate other agents or not and whether they model the world as it is now, or as the agent wants the world to be.
4. How are agents structured internally?
The different agents in a system may be identical, heterogeneous, or sharing some common modules and differing in others. They may or may not remember past states, and their internal code may or may not change over time.
5. How many agents are there?
Both the number of different agent categories and the total number of individual agents are important characteristics of a given system, as well as whether the agent population can change while the system is running.
6. What communication channels do agents use?
The channels through which information moves from one agent to another can differ in medium, ie the shared physical space vs. a digital network, addressing broadcast, subject-based, agent-to-agent, whether messages persist after being sent, and locality-- if agents need to move "close" to one another in order to exchange messages.
7. What communications protocols do agents use?
A communications protocol determines how conversations among agents are structured. Some agents simply give orders to one another and expect them to be received. Others vote, negotiate, or engage in more complex dialogues based on speech-act constructs.
8. How is the configuration of agents relative to one another established?
The configuration of an agent community describes on how well each agent knows each other and the resulting surface structure over which information and materiel move among them. This structure may be set in advance by the system driver and remain unchanged as the system operates, or the agents may be able to discover new relationships and reconfigure themselves while running.
9. How do agents coordinate their actions?
Agents are autonomous in that they do not have to be invoked in order to execute. However, in a useful system there is coordination with one another. In different coordination levels, commands flow down from higher levels and status information flows back up. Coordination emerges from how agents interact through mechanisms such as dissipative or constraint propagation.
10. How mature is the application?
Maturity levels differ, for example system has been demonstrated against a simulation of its intended domain scenario, or the system has been demonstrated in a commercial practice, sold and supported as a commercial product.
Now that multiple products are becoming available, market forces will join up with technical excellence in determining the platforms best suited for products to be built in the future. Engineers who are alert to these market forces and who pay special attention to packaging and deployment of their results will see their work have the most lasting impact on the field.
This brief survey of agent systems utilised in product proposed systems must be practical, and the tools used to develop them must be packaged. Industrial systems are driven by the need to solve a practical problem, rather than curiosity about the possibility of some technology. The criterion for success in an industrial project is not how clever the technology is, or what one has learned about that technology, but how well the system solves the problem that it addresses.
The orientation to practical problems means that engineers in industry must be first of all experts in the products they manufacture, the processes they control, or the services they render. Agent technology is for them a means to an end, a tool. The more the tool fades into the background and lets them concentrate on the requirements of the problem at hand, the more likely they are to use it.
As with other technologies, detailed application issues are more likely to be discussed in venues associated with the application domain than in those dedicated to the underlying technology, and as a result the best case studies will be scattered throughout a wide range of sources.
Ultimately, application expertise is best communicated by hands-on experience not reports so engineers motivated to learn more about this area should establish joint projects with industrial partners around application problems of industrial scope and complexity, where the objective is to improve the operations of industry users rather than to generate cumbersome reports.
Practical design engineering applications of Distributed Artificial Intelligence are characterised by agents tech focus on a particular capability e.g., communication, planning, learning and seeks practical problems to demonstrate the usefulness of this capability. The engineer has a practical problem to solve, and cares much more about the speed and cost-effectiveness of the solution than about its elegance or sophistication.
To the engineer, it offers an overview of the kinds of problems faced, and some examples of agent technologies have made their way into practical application. To the engineer it explains why agents are not just the latest technical fad, but a good match to the characteristics of a broad class of real problems to include selected development projects that are not yet industrial strength.
Agents represent industrially important concepts or are being conducted in a way likely to lead to deployable technology. Also emphasises agent applications in manufacturing and physical control over other fielded industrial applications such as information-gathering agents, network administration, or business planning agents.
Like any other technology, agents are best used for problems whose characteristics require their particular capabilities. Agents are appropriate for applications that are modular, decentralised, changeable, poorly structured, and complex In some cases, a problem may exhibit or lack these characteristics, but many industrial problems can be formulated in different ways.
In these cases, attention to the characteristics during problem formulation and assessments can yield a solution that is more robust and adaptable than one supported by other technologies. Agents are pro-active objects, and share the benefits of modularity enjoyed by object technology. They are best suited to applications that fall into practical modules.
An agent has its own set of state variables, distinct from those of the used in real-life mission space.. Some subset of the agents state variables is coupled to some subset of the mission work space state variables to provide input and output. An industrial entity is a good candidate for agency if it has a well-defined set of state variables that are distinct from those utilised in mission space, and if its interfaces can be clearly identified.
The state-based view of the distinction between an agent and its mission space suggests that functional decompositions are less well suited to agent-based systems than are physical decompositions. Functional decompositions tend to share many state variables across different functions.
Separate agents must share many state variables, leading to problems of consistency and unintended interaction. A physical decomposition naturally defines distinct sets of state variables that can be managed efficiently by individual agents with limited interactions. The choice between functional and physical decomposition is often up to the engineer.
Emphasising the physical dimension enables more modular applications. Because the agent characterises a physical entity, that entity can be redeployed with minimal changes to the agents code. As a result, the cost of reconfiguration drops dramatically, and reusability increases.
Decentralisation is important because an agent is more than an object; it is a pro-active object, a bounded process. It does not need to be invoked externally, but autonomously monitors its own mission space and takes action as it considers appropriate. This characteristic of agents makes them particularly suited for applications that can be decomposed into stand-alone processes, each capable of doing useful things without continuous direction by some other process.
Many industrial processes can be organised in either a centralised or a decentralised fashion. Centralised operations focus on a central authority and elaborate bureaucracy to manage the flow of control down and information back up.
There is an alternative approach. The power of decentralisation has recently been made clear in the contrast in performance. Modern industrial strategists seek to eliminate excessive layers of management and push decision-making down to the very lowest level, and are developing the vision of the "virtual enterprise," formed for a particular market opportunity from a collection of independent firms with well-defined core competencies.
It is increasingly common for the manufacturer of a complex product to purchase much of the content in the product from other companies. For example, an automotive manufacturer might buy seats from one company, brake systems from another, air conditioning from a third, and electrical systems from a fourth, and manufacture only the chassis, body, and powertrain in its own facilities.
The suppliers of major subsystems in turn purchase much of their content from still other companies. As a result, the "production line" that turns raw materials into a vehicle is a network, or "supply chain," of many different firms. Agent-based architectures are an ideal fit to such an organisational strategy.
Agents are well suited to modular problems because they are objects. They are well suited to decentralised problems because they are pro-active objects. These characteristics combine to make them especially valuable when a problem is likely to change frequently.
Modularity permits the system to be modified one piece at a time. Decentralisation minimises the impact that changing one module has on the behaviour of other modules. Modules alone are not sufficient to permit frequent changes. In a system with a single digital thread of control, changes to a single module can cause later modules, those it invokes, to malfunction.
Decentralisation decouples the individual modules from one another, so that errors in one module impact only those modules that interact with it, leaving the rest of the system unaffected. From an industrial perspective, the ability to change a system quickly, frequently, and without damaging side effects is increasingly important to competitiveness.
In manufacturing, the product that suit’s the requirements of the most customers has a tremendous advantage. One of the most effective means to determine the features that customers like is to turn out as many different product variations as quickly as possible, sampling customer response and adjusting new offerings accordingly.
This strategy is responsible for the precipitous drop in the time-to-market for many products. The time from product concept to first production in vehicles has decreased markedly. Agent-based architectures permit reuse of much existing code and self-configuration of large portions of the system, reducing both the cost and the time needed to bring up a new factory.
An early deliverable in traditional systems design is an architecture of the application, showing which entities interact with which other entities and specifying the interfaces among them. For example, installation of a conventional system for electronic interchange among trading partners requires that one know the providers and consumers of the various goods and services being traded, so that orders can be sent to the appropriate parties.
Sometimes, determining this information in advance is extremely difficult or even impossible. Consider an electronic system to support open trading, where orders are made available to any qualified bidder. Requiring the system designer to specify the sender and recipient of each transaction would quickly lead to getting stuck in details.
From a traditional point of view, this application is poorly structured. That is, not all of the necessary structural information is available when the system is designed. Agents naturally support such an application. The fundamental distinction in an agent's view of the world is between "self" and "environment." "Self'' is known and predictable, while "environment" can change on its own within limits.
Other agents are part of this dynamic, changing environment. Depending on the complexity of individual agents, they may or may not model one another explicitly. Instead of specifying the individual entities to be interconnected and their interfaces with one another, an agent-based design need identify only the classes of entities in the system and their impact on the environment.
Because each agent is designed to interact with the environment rather than with specific other agents, it can interact appropriately with any other agent that modifies the environment within the range of variation with which other agents are prepared to deal.
Some applications are intrinsically under-specified and agents offer the only realistic approach to managing them. Even where more detailed structural information is available, the better course may be to pretend that it isn't. A system that is designed to a specific domain structure will require modification if that structure changes.
Agent technology permits system design to the classes that generate a given domain structure rather than to that structure itself, thus extending the useful life of the resulting system and reducing the cost of maintenance and reconfiguration.
One measure of the complexity of a system is the number of different behaviours it must exhibit. For example, a manufacturing job shop might produce a given part in several different ways, depending on which machines are used and in which order. The number of possible behaviours in this simple example depends exponentially on the number of different machines in the shop.
For a shop with only a few machines, one might code a separate subroutine for each possible routing, but this approach quickly becomes prohibitive as the shop grows. This example shows combinatorial complexity. The number of different interactions among a set of elements increases much faster than does the number of elements in the set.
By mapping individual agents to the interacting elements, agent architectures can replace explicit coding of this large set of interactions with generation of them at run-time. Not all of these will be useful behaviours, and one can imagine poor agent designs in which none of the generated behaviours will be appropriate.
However, appropriately designed agent architectures can move the generation of combinatorial behaviour spaces from design-time to run-time, drastically reducing effort and cost of the system to be constructed.
Modification of a system during its life can increase its complexity as well as making it poorly structured. By adopting an agent approach at the outset, systems engineers can provide a much more robust and adaptable solution that will grow to meet business requirements.
Information agents have access to multiple, potentially heterogeneous and geographically distributed information sources and do work ranging from relatively simple in-house information systems to large-scale multi-source systems.
One of the main tasks of the agents is an active search for relevant information in non-local domains on behalf of their users or other agents including retrieving, manipulating, and integrating information available from multiple sources. Agents support users in fulfilling certain tasks by hiding the complexity of a difficult task, train/teach human users, and perform sub-tasks for user.
Realistic application of Responsible Agents for Product/Process Integrated Design will have one or two dozen component agents and on the order of a hundred characteristic agents. In the current implementation, agents are not created, destroyed, divided, or fused during operation, but as the system matures, designers will need a way to add both component and characteristics agents to the community as a design is refined.
Agents communicate digitally, and currently use point addressing. Messages do not persist outside of agents, and agents do not move over the network. Fixed market protocol is used but also provides for the humans behind component agents to communicate directly with one another using Standard work orders.
The initial configuration of component agents and characteristic agents is defined when the system is initialised, but component agents can engage in markets for other characteristics as the system runs.
The fundamental challenge in applying agents to both planning and control is satisfying a global criterion on the basis of parallel local decisions. In spite of the natural benefit that centralisation has in dealing with control criteria. Case studies show that many users have found agents an even better approach.
Operational systems must be maintained, and it is much easier to maintain a set of well-bounded modules than to make changes to a large programme. The move toward supply chains means that the manufacturing system is geographically distributed, and agent decentralisation reduces communication bottlenecks and permits local parts of the enterprise to continue operation during temporary lapses in connectivity.
Competitiveness increasingly depends on adjusting system operations frequently to track customer requirements, benefiting from how agent systems can be changed. The ability of agents to deal with poorly structured systems is less important in the operation of an engineered system than in its design.
However, the ability of agents to deal with dynamically changing structures means that digital communication can now be applied to manage systems such as networks of trading partners that formerly required extensive manual attention. The increased complexity that agents can manage also extends the scope of operational problems to which they can be applied.
1. What in a system becomes an agent?
Classical engineering techniques lead many systems designers toward "functional decomposition." For example, manufacturing information systems typically contain modules dedicated to functions such as "scheduling," "materiel management," and "maintenance," suggesting that these functions should be assigned to distinct agents. Most industrial agent applications are additions to existing systems, and functionally oriented legacy systems may be most easily attached by encapsulating them as functional agents. A watchdog agent may usefully monitor the behaviour of a population of physical agents for important system states that local agents cannot perceive.
2. How Does each agent model the world?
Any agent that functions in a changing world must model that world internally. However, agents differ in the how developed the knowledge representation and reasoning are used for this task. Some agents model aspects of their world explicitly, so that they can reason about the model. In other agents, these models are hard-wired and often distributed throughout the agent's architecture.
3. How do agents differ in the scope of what they model?
It depends if agents individuate other agents or not and whether they model the world as it is now, or as the agent wants the world to be.
4. How are agents structured internally?
The different agents in a system may be identical, heterogeneous, or sharing some common modules and differing in others. They may or may not remember past states, and their internal code may or may not change over time.
5. How many agents are there?
Both the number of different agent categories and the total number of individual agents are important characteristics of a given system, as well as whether the agent population can change while the system is running.
6. What communication channels do agents use?
The channels through which information moves from one agent to another can differ in medium, ie the shared physical space vs. a digital network, addressing broadcast, subject-based, agent-to-agent, whether messages persist after being sent, and locality-- if agents need to move "close" to one another in order to exchange messages.
7. What communications protocols do agents use?
A communications protocol determines how conversations among agents are structured. Some agents simply give orders to one another and expect them to be received. Others vote, negotiate, or engage in more complex dialogues based on speech-act constructs.
8. How is the configuration of agents relative to one another established?
The configuration of an agent community describes on how well each agent knows each other and the resulting surface structure over which information and materiel move among them. This structure may be set in advance by the system driver and remain unchanged as the system operates, or the agents may be able to discover new relationships and reconfigure themselves while running.
9. How do agents coordinate their actions?
Agents are autonomous in that they do not have to be invoked in order to execute. However, in a useful system there is coordination with one another. In different coordination levels, commands flow down from higher levels and status information flows back up. Coordination emerges from how agents interact through mechanisms such as dissipative or constraint propagation.
10. How mature is the application?
Maturity levels differ, for example system has been demonstrated against a simulation of its intended domain scenario, or the system has been demonstrated in a commercial practice, sold and supported as a commercial product.
RSS Feed