ACOSO: Agent-based COoperating Smart Objects Website!

ACOSO: Agent-based COoperating Smart Objects

ACOSO at a Glance

ACOSO (Agent-based COoperating Smart Objects) is a middleware providing an agent-oriented programming model for Cooperating Smart Objects (CSOs) and tools for their effective development. While the design of the architecture is platform independent and can be realized on several agent-based platforms (e.g. JADE, Jadex, MAPS), actually, the middleware implementation relies on the JADE middleware that provides an effective agent management and infrastructure of communication. So, the SOs can be implemented as JADE or Jadex agents and an ecosystem of CSOs therefore forms a multi-agent system (MAS). With regard to the most common desiderable features identified within the smart object middlewares context, ACOSO fullfills the following requirements:

  • Heterogeneity and Application Development: Applications that use smart objects should be programmed independently from SOs produced by specific SO vendors. For instance, if an application is based on a "smart chair", it should be able to use smart chairs built by different SO vendors. Moreover, applications should be able to exploit SOs that will be built in the future. This implies to employ a standardized approach or, if not applicable as de-iure standardization is a very long process, to exploit software layering-based (dynamic) adaptation techniques between application and smart object levels.
  • Augmentation Variation of Smart Objects: SOs provide a set of services that can vary in number and types both among different SOs and similar SOs. In particular, different SOs can provide the same services whereas two similar SOs can provide different services. Thus, SOs cannot be crisply classified only by the object type. Moreover, they are unlike to provide standard interfaces. Augmentation variation of SOs is an important requirement as it defines how SOs can variate their augmentation by providing diversified services that can change during their lifecycle. This implies to design not only methods to dynamically add/modify/remove SO services but also how they will be actually furnished.
  • Management of Smart Object: An effective management of SOs is crucial in IoT applications where tons of distributed SOs could potentially interact with each other and/or be used to fulfill a final goal. Applications and SOs should be therefore able to dinamically adapt as SOs could continuously change for different purposes: augmentation variation, mobility, failures, etc. Thus, the matching among SO services and application requirements should be done often at run-time. Discovery services are therefore strategic in such a dynamic context to look up and retrieve SOs according to their static and dynamic properties.
  • Evolution of Smart Object Systems: Applications and SOs should be simply and rapidily prototyped and upgraded through proper programming abstractions. The evolution can be driven by programming, by learning, or by both. In particular, evolution by learning is usually based on smart self-evolving components (applicationlevel components and smart objects) able to self-drive their evolution on the basis of some learning model.
  • Support for Proactivity and Cooperation: The capabilities of autonomously fulfill goals and cooperate with the surrounding environment become crucial to effectively model a complex and dynamic system in which SOs should act to the best of their possibilities. In this direction, a distributed agent-based architectural model represent a viable solution in order to provide proactivity and coordination to the CSOs.

In the following Figure are shown theAgent-based Platform architecture.

The ACOSO platform for CSO development and deployment is composed of three layers:
  • The High-level CSO Architecture layer, which is the abstract layer formalizing CSOs.
  • The Agent-based Middleware layer, which implements the High-level CSO Architecture through a specific agent framework. Currently, JADE, JADEX and MAPS, atop different Javaenabled computing devices (PCs, mobile devices and SunSPOT sensors), are used.
  • The WSAN Programming and Management layer, which programs and manages the network of sensors and/or actuators embedded in a CSO. Currently, this layer is based on the Building Management Framework (BMF), for the management of the wireless sensor and actuator networks (WSANs), and on the Signal In-Node Processing Environment (SPINE), for the management of body area networks (BANs) and small-scale star-based sensor networks. Moreover, MAPS is used for managing WSNs based on SunSPOTs.
Figure 3 shows the JADE and MAPS-based CSO architecture.
CSOs are agents based on JADE (either simple JADE agents or encapsulated JADEX agents) or on MAPS.

JADE-based CSOs are managed by the AMS (Agent Management System), communicate through the ACL-based message transport system, and use the Directory Facilitator (DF) to look up CSOs and other agents. The DF, which supports dynamic agent service discovery, was purposely modified/extended in ACOSO to allow searching CSOs on the basis of their specific metadata: type, services, location, and static and dynamic system properties. Currently, the extended JADE DF handles requests sent from the JADE-based CSOs and serves them by querying the remote interface of an external CSO discovery service. MAPS-based CSOs are intended for small-sized smart objects (running on SunSPOTs sensors). In particular, being specifically wrapped by JADE agents by means of the JADE-MAPS gateway, they can interact with JADE-based CSO agents (and viceversa). The main components of the CSO architecture are::
  • The Task Management Subsystem, which manages the reactive and proactive tasks of CSOs. In particular, tasks are event-driven and state-based software components encapsulating specific objectives to fulfill through actions involving computation, communication, sensing/actuation, and storage.In JADE-based CSOs, tasks are defined as JADE Behaviours or JADEX Plans so their execution is based on the mechanisms provided by the basic JADE behavioral execution model or planoriented JADEX execution model, respectively. In MAPS-based CSOs, tasks are implemented in multi-plane state machines representing agent behaviors that are executed by the MAPS execution engine. Tasks are driven by events, so external CSO communication, signals/data to/from the CSO devices, data to/from the knowledge base (KB) are formalized and managed as well-defined internal events.
  • The Communication Management Subsystem, which provides a common interface for CSO communications. In particular, message-based communication is based on the ACL-based MessagingService whereas publish/subscribe coordination is the TopicManagementService. The subsystem is internally organized in handlers. In JADE-based CSOs, the CommunicationManagerMessageHandler, which is implemented as Behaviour in JADE and as Plan in Jadex, captures the ACL messages targeting CSOs and translates them into internal events. Moreover, the TCPAdapter and UDPAdapter manage communication with external networked entities based on TCP and UDP, respectively. In MAPS-based CSOs, the CommunicationManagerMessageHandler is based on MAPS events. The Jade/MAPS Gateway is able to translate ACL messages into MAPS events and viceversa so that Jade-based and MAPS-based CSOs can seamlessly communicate.
  • The Device Management Subsystem, which manages the sensing/actuation devices that belong to the CSO. It is organized in a DeviceManager handling several DeviceAdapters. In JADE-based CSOs, two DeviceAdapters are currently defined: the BMFAdapter, which allows to manage WSANs based on BMF, and the SPINEAdapter, which allows to manage BANs through SPINE. BMF and SPINE are based on IoT standard communication protocols such as IEEE 802.15.4, ZigBee, and 6LowPan. In MAP-based CSOs, the DeviceManager exploits the on-board sensors/actuators through the MAPS resource manager.
  • The KB Management Subsystem, which supports CSOs through a knowledge base (KB). It consists of a KBManager, which manages and coordinates different KBAdapters, and a KBAdapter, which manages a KB containing the knowledge of the CSO. KB can be local and/or remote and archives information that can be shared among tasks.