Agent technology has attracted the attention of academia in many domains in the past decade. It is probably due to the fact that computer systems have been becoming complicated with distribution and openness characteristics. Agent-based systems, or multi-agent systems in general, are contemporary paradigm for software development.6,9,11 Ashri et al.2 claimed that “the underlying concept of decentralized, autonomous control expressed through agents that are able to communicate and cooperate to achieve goals is especially appealing for applications in heterogeneous and dynamic computing environments.”
Jennings6 refers agent-oriented software development approach to as “decomposing the problem into multiple, autonomous components that can act and interact in flexible ways to achieve their set objectives.” Jennings6 also advocates that agent-oriented software development approach offers the following advantages:
- Decompose a complex problem effectively so that the problem space can be divided into smaller sub-problem space;
- A natural way of modelling such systems because they are, most often, decentralized in nature; and
- Interaction among agents is appropriate for modelling the dependencies that exist in complex systems.
In the instrumentation and measurement domain, application of agent technology is still in its infancy. Dobrowiecki et al.5 discussed how measuring instruments are related to artificial intelligence, in particular agent technology. They presented a general idea of agent-based system which is “to order a service from an agent and to delegate any responsibility of direct control, rather than to monitor closely the progress of the problem solving”. Amigoni et al.1 claimed that agent techniques have evolved and improved over the years such that “impacts on measurement systems whose nature and conceptual interpretation have radically changed.” Real-life applications of agent technology in this domain are not well documented. It is not easy to find a successful application of agent-based instrumentation and measuring system, although PC-based distributed instrumentation and measuring systems are not uncommon.3,4 In fact, they are usually configured as client-server systems.
In this article, two real-life agent-oriented applications which are embedded measuring systems will be reviewed. In fact, the two cases are commercial products and have already been mass produced. The reasons why such distributed approach is used will be revealed. In fact, one of them is limited by the outlook design so that two individual functional units (which are agents) have to be built for each final product. On the other hand, the other one is decomposed into different independent units to simplify the software development and product design, which is a collaborative work by three independent companies. Main issues, including difficulties, that came across during the course of development of the two cases with respect to agent-oriented design will be addressed in this article.
Case 1. Product A
The first product (refer to as Product A hereafter) is an embedded measuring device with timepiece functions. Core functions of Product A are listed in Figure 1(a). Please note that Figure 1(a) is an aggregate functions list. In fact, by looking at 1(a), the most economical way to implement Product A is simply using a single electronic module with off-the-shelf micro-controller available in the market. In other words, there is no need to adopt agent-oriented software technique for implementing Product A from electronic engineering point of view. However, the rationale of doing so is not originated by the complexity of the system. In fact, the major driver is the restriction of the outlook design of Product A.
Product A consists of a measuring unit, which is used to acquire raw data from a sensor circuit, and a display and user interface unit, which is used to display measurement related information, and timepiece information. These two main units are connected by a very thin tube, which can only accommodate a few small-gauged wires. The main design challenge is that the display and user interface unit is put in an oval housing with a transparent display, that is, not too much space for placing printed circuit board. Consequently, battery must be installed in the measuring module but not in the display and user interface module. In this connection, there are three choices for electronic design the first two are single-chip designs and the last one is agent-oriented design:
- All electronic components are put in the measuring unit: However, there is insufficient space for wiring to drive the display and user interface unit because the number of wiring is more than 20 for direct display driving. Even if a standalone display driver is put in the display and interface unit, the number of wires passing through the thin tube is still more than 10.
- An alternative is to put majority of the electronics in the display and interface unit and only let sensors and battery wires through the small tube (minimum six wires). However, there is not enough space as discussed before to put all electronic components in the display and user unit, which is restricted by its outlook design with transparent display. Another problem with this configuration is that the sensor signals have to go through a relatively long distance so that the electrical signal is easy to pick up noise which means the quality of the measuring system would be degraded.
- The third choice, which is also the one being selected finally, is to decompose the single-chip design into two-chip and independent-unit design, while each measuring unit and display and interface unit employs a single micro-controller as control. The aggregated features in Figure 1(a) are then divided as in Figure 1(b) and will be discussed later. This is in fact an agent-oriented approach to implement Product A.
In this connection, the electronic part is divided physically into two subsystems. By adopting the agent-oriented technique, the two parts are called User Interface Agent (UIA) and Measuring Agent (MA) hereafter. Each agent works independently and they share data through a four-wire communication channel with dedicated communication protocol. Data are sent in serial format. The aggregated list in Figure 1(a) is decomposed into two main parts as shown in Figure 1(b), which can also be regarded as the block diagram of the final system. The responsibility of each agent is self-explanatory as shown in Figure 1(b).
One benefit by adopting the agent-oriented approach is that a micro-controller which is specifically designed for timepiece applications could be selected for the UIA. This micro-controller or similar items from the same series is not powerful enough so that it could not be employed for implementing the aggregated function lists. In the agent-oriented approach, this low-power micro-controller could be employed to handle sub-set of the function list and could also improve the battery life of the whole system substantially (from two years, if a single-chip solution is employed, to four years). It is a chicken and egg question to argue if we need such a long battery life we used agent-oriented approach which was not restricted by battery life, but we can gain this benefit if we attach to the agent-oriented approach.
Case 2. Product B
The second product, Product B, is much more complicated than Product A in terms of software architecture and functionality of the whole system. Software and hardware development of Product B involves three independent companies while each company deals with one portion of the software and hardware development. The final product is a result of the coordination of different portions of the design, which idea is just an agent-oriented approach.
The final product consists of two main individual units: (i): an embedded measuring device with a measuring system and radio frequency (RF) communication capability; (ii): a receiver plus an interacting unit that is connected to a display (such as a TV, or an LCD monitor) for sophisticated end user applications, which is of course related to the sensor data that is collected by part (i). Part (i) and part (ii) are physically separated.
Part (i) is further divided into two units (or agents):
- (a) Measuring Agent (MA): A measuring system which collects sensor signal and converted it into useful data;
- (b) Transmitter Agent (TA): An RF communication unit which is used to transmit processed data for part (ii) usage and receive signal from part (ii).
MA and TA of this embedded system are communicated through a wired media, like the one discussed for Product A.
On the other hand, part (ii) also consists of two units (or agents):
- (a) Receiving Agent (RA): An RF communication unit which can communicate with the TA with a predefined communication protocol. It also serves as a bridge between part (i) and the Interactive Agent to be discussed;
- (b) Interactive Agent (IA): is a generic unit for end-customer applications. This is connected to a television or other display units with interacting functions. This is designed to work with different types of RA (not only the one to collect sensor signal in this study) as games, for computing, or educational purposes.
RA and IA are connected by header connectors, which is a generic standard of the IA to accommodate different types of RA. Although RA and IA are separable units, they must be used altogether and once an RA is sat on an IA, they are essentially a single working unit. As discussed, Part (i) and (ii) are communicating through the air with RF signal. One issue should be highlighted which is that both TA and RA are able to transmit and able to receive RF signal. However, in most of the communication cycles, major task of TA is sending data while major task of RA is receiving data. Therefore, their names are just for simple classification here.
Since the system was decomposed into different units at the very beginning in the development cycle, an aggregated functions list will not be provided. On the contrary, functions list of individual agents are listed in Figure 2, which are self-explanatory. Since the focus of this article is not on the technical design of each agent and the communication protocol for both products, they are omitted in this article.
The reasons why the product is divided into three parts for development is due to the fact that the three parties are focusing on its own technological development, for example, the one who develops MA is an expertise in related measuring systems, while the core competence of the one who develops TA and RA is on RF development. And the one who develops IA is focusing on the interactive TV computing, and sales and marketing of the finished products. By decomposing the whole development, each party contributes its own core competence in order to push the product into market. This is an example of strategic partnership and collaboration, even though temporarily, as discussed in many supply chain literature.7,10 In fact, the three companies had been working independently during the course of the whole product development, except when they were meeting and working with each others to define the specification, communication protocol and the structure of information they share. In other words, each agent is working independently and the performance of the whole system relies on the coordination and communication among the agents.
Issues of Developing Agent-Oriented Software
From these discussions, both Product A and Product B adopted agent-oriented software technique for implementation, although “agentization” is not strictly required for Product A from electronic and software point of view. No matter how, Product A was eventually devel oped with agent-oriented approach due to outlook restriction. Both products have been mass-produced for quite a long period of time (around 1 year). In the literature, key characteristics of agent can be summarized as autonomy, interaction (or communicative), and adaptation.6,12 Again, the focus of this article is not on the technical design of each agent, the characteristics of the two products from these perspectives are summarized in Table 1. The rest of this section sets out to discuss the major issues came across in developing Product A and Product B, with focus on the agent-oriented approach.
A. Software Development. When developing the above agent-oriented software for different agents, the overall debugging work was in fact easier than debugging a software that incorporating all features. The major reason behind this is due to the fact that functionality of each individual agent is less complicated than the whole system counterpart (Figure 1(a) against Figure 1(b)). Of course, we cannot conclude that developing individual software is simpler than the aggregated one by just looking at the function list of each agent. At least some routines are duplicated in individual software (for example, power on reset, interrupt handling routines) which need to be rewritten in different agents. As a matter of fact, some of these routines (and some others) could be shared by other agents (or software) this is in fact a distinctive feature of either object- or agent-oriented programming so that part of the software can be reused.2,8
In spite of its simplicity in individual software development, debugging of an agent-based system is not as easy as the aggregated system, which consists of a single chip and does not require communication media among agents. The major difficulty is to assure the communication functions work as well as what expected. This problem is not only arisen in the development phase, some communication problems, which are not software bug at all, were found even after a several batches of mass production. These reported problems were mainly due to problem in synchronization in communication, which led to “no response” in some circumstances, or “act wrongly” in others, or even “hanged” in some situations which require a reset of the whole system. The problem is not easy to figure out in the development phase because there are virtually infinite combinations of components tolerance to be considered. Of course, this is not an excuse but the rationale behind this is that a robust communication protocol is desired for any agent-oriented development. Interestingly, the same problem occurred less frequently in Product B, probably due to the fact that its development involved different parties and any weaknesses in term of communication were able to be figured out in the development stage compare with Product A, which is a 100% in-house development.
In regard to software development, another interesting observation from Product B was that its development lead time was shorter than a single-chip product development of a similar product. We can use the “division of labor” concept in production systems to explain this observation. Different agent-based software could be development in parallel. Consequently, developing, say, four agents at the same time is equivalent to one-third of the development lead time of a single-chip solution. Not only less program code is required for each agent software, the architecture of each agent is also simpler than the single-chip counterpart. To extend this principle, an agent-oriented approach could speed up development lead time, if it is designed properly. Of course, cost is another consideration and decision-makers should make a compromise between cost and lead time. Below is a discussion on the cost aspect of the two cases.
B. Cost issues. Since a single-chip design consists of a higher-level micro-controller which cost more than the one used in the agent-oriented system, the overall unit cost, especially for Product B, is even lower. Of course, if a product is already simple enough, the chance to get cost saving by adopting agent-oriented approach is not high (Product A is just a typical example). However, the more complex of a product or system, the higher is the chance to reduce cost by adopting agent-oriented approach. In fact, this is in line with Jennings’6 argument as stated above. An effective way to represent a system implies the system cost could be lower by a proper design.
In term of production environment, the agent-oriented models are not as fractious as expected. In fact, functionality of each individual agent is not complicated so that each of which could be tested with a simple tester. The overall labour cost incurred is as low as a similar product which is implemented with single-chip solution. In addition, the overall scrap rate of the product in term of dollar per sales is also less than the single-chip counterpart. This is because whenever a unit is failed, most of the time one of the agents (one of the electronic units in other words) is required to be scrapped. This is a major driver to keep the overall cost of Product A at an acceptable level. In short, unit cost and running cost of the agent-based design for Product B is even lower than a single-chip counterpart; while the unit cost and running cost of Product A is roughly the same as a single-chip solution.
Conclusion
Through the experience in developing Product A and Product B, it is obvious that software development can be handled easier than developing the system as a whole. It is also easily for production because each individual agent is easier to test at jig and fixture level than testing a very complicated system. Even if automation is taking into consideration, investment for a number of individual automated testers could, in most cases, cheaper than a complicated automated tester. Maintenance of the small-scale testers should be easier than maintenance of a complicated one. In addition, in certain cases (Product B for example), the overall system cost is in fact lower than a single chip counterpart. This reason is very straightforward because micro-controller is a large proportion of the system cost, and the cost of two simple micro-controllers is cheaper than a single but high-level counterpart. In other words, both running cost and initial investment of agent-oriented system may lower than the single-chip counterpart.
Of course, a coin has two sides. Agent-oriented approach is not free from problems and some of them have been discussed in this article. Put it simple, if a system is already simple enough, or there is no such a need to develop an agent-based system (like the case if a product is similar to Product A, but without the outlook restriction), it is absolutely no need to consider agent-oriented approach. In fact, a careful cost-benefit analysis should be conducted before a decision is made in regard to selection of agent-oriented approach or not. In addition, agent-oriented approach relies on the coordination of agents, which in turns relies on a robust communication protocol. If the development of such protocol involves different parties (like Product B), extra effort has to be paid and such overhead is certainly a consideration.
No matter how good an approach is, pros and cons always coexist. It is not so simple to make a decision that a certain approach should be adopted. After reading this article, however, readings should be able to recognize the benefits of agent-oriented approach.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment