This presentation was created for the SATURN conference series and does not necessarily reflect the positions and views of the Software Engineering Institute.
Egemin N.V. is a Belgian manufacturer of Automatic Guided Vehicles (AGVs) and control software for automating logistics services in warehouses and manufactories using AGVs. In a joint R&D project, Egemin and the DistriNet research group have developed an innovative version of the AGVs control system aimed to cope with new and future system requirements such as flexibility and openness. In this project, a multiagent system approach is applied for modeling and implementing a decentralized control system. Instead of a centralistic approach, where one computer system is in charge of numerous complex and time-consuming tasks such as routing, collision avoidance, or deadlock avoidance, in this project the AGVs are provided with a considerable amount of autonomy. This allows obtaining a system that is far more flexible than the current software. The AGVs adapt themselves to the current situation in their direct vicinity, order assignment is dynamic, the system can cope with AGVs leaving the system (e.g. for maintenance) or adding new AGVs, and so on. To develop the AGV application, we used the evolutionary delivering life cycle. This life cycle model situates architectural design in the middle of the development activities.
To describe the functionality of the software system, we defined scenarios together with the main stakeholders of the system. Some scenarios are initiated by an external actor, e.g. a scenario that describes the life-cycle of a task that enters the system; other scenarios describe interactions among parts in the system, e.g. a scenario that describes collision avoidance of automatic vehicles on crossroads. For the expression of quality requirements we used quality attribute scenarios. In particular, to elicit quality attribute scenarios, we organized a quality attribute workshop with the main stakeholders involved in the project. During this two-day workshop we generated a utility tree to define and prioritize the relevant quality requirements precisely. Particular experiences here came from the specification of quality attributes such as flexibility and openness that were important quality goals of the project.
For architectural design, we used techniques from the Attribute Driven Design (ADD) method. The ADD method is a recursive decomposition method that is based on understanding how to achieve quality goals through proven architectural approaches. At each stage of the decomposition we selected architectural drivers together with appropriate architectural approaches to satisfy the drivers. We extensively used a reference architecture for situated multiagent systems as an asset base for selecting architectural solutions. This reference architecture is developed at DistriNet Labs and incarnates our expertise with architectural design of various situated multiagent system applications. The software architecture of the AGV application is documented by different views, each view belonging to a viewtype. We used views from the standard viewtypes: the module viewtype, the component-and-connector viewtype, and the deployment viewtype.
For the evaluation of the software architecture we used the Architecture Tradeoff Analysis Method (ATAM). The main goal of the ATAM is to examine whether the software architecture satisfies system requirements, in particular the quality requirements. We applied the ATAM for one concrete application, in casu a tobacco warehouse transportation system that was used as a test case in the project. The ATAM that took one day was a valuable experience. For the first time, the complete group of stakeholders discussed the architecture in depth. Participants agreed that their insights were improved on: (1) the importance of software architecture in software engineering; (2) the importance of business drivers for architectural design; (3) the importance of explicitly listing and prioritizing quality attributes with the stakeholders; (4) the strengths and weaknesses of the architecture and architectural approaches. One interesting discussion arose from the tradeoff between flexibility and performance. Various decisions in the software architecture aim to improve flexibility in the system, yet the decentralized nature of the multiagent system implies an increase of bandwidth occupation. Field tests after the ATAM proved that the communication cost remains under control even in worst-case scenarios.
A number of critical reflections about the ATAM were made as well: (1) a thorough and complete architectural evaluation using the ATAM of a realistic industrial application is not manageable in a single day; (2) coming up with a quality attribute tree proved to be difficult, time consuming, and at times tedious. A lack of experience and clear guidelines of how to build up such a tree hindered and slowed down the discussion; (3) while the general AGV software architecture was developed with several automation projects in mind, the ATAM evaluated it within the scope of a single automation project. Clearly, the ATAM is devised to evaluate a single architecture in a single project. However, this difference in scope hindered the discussions because some architectural decisions were motivated by the product line nature of the architecture; (4) we experienced a lack of good tool support to document architectures. Currently, drawing architectural diagrams and building up the architectural documentation incurs much overhead. Especially changing the documentation and keeping everything up-to-date (e.g. cross references and relations between different parts of the documentation) turned out to be hard and time consuming. Good tool support would be helpful.
Developing the AGV application with a multiagent system approach was a valuable experience for both partners in this project. Egemin learned a lot about the potential as well as the possible implications of applying multiagent system technology in AGV systems. For us at DistriNet, this real-world application showed that multiagent systems can make a difference when qualities such as flexibility and openness are important goals for a system. Finally, we gained a better insight in the relationship between multiagent systems and software architecture.