Re-Engineering IoT Systems through ACOSO-Meth: the IETF CoRE based agent framework case study Claudio Savaglio*, Teemu Leppänen⁑, Wilma Russo*, Jukka Riekki⁑, Giancarlo Fortino* * Dept. of Informatics, Modelling, Electronics and Systems (DIMES), University of Calabria, 87036 Rende (CS), Italy csavaglio@dimes.unical.it, w.russo@unical.it, g.fortino@unical.it, ⁑ Center for Ubiquitous Computing, University of Oulu, FI-90014, Finland teemu.leppanen@oulu.fi, jukka.riekki@oulu.fi Abstract—The Agent-based Cooperating Smart Objects systems have to cope and perform under the massive SO methodology (ACOSO-Meth) fully supports the systematic diffusion that is expected within the next few years), development of Internet of Things (IoT) systems from analysis to interoperability (IoT systems of different domains have to implementation by tackling their manifold requirements (e.g., synergistically interact despite the heterogeneity of SOs’ self-management, distributed smartness, interoperability). At the communication protocols, data standards, enabling same time, ACOSO-Meth allows the re-engineering of existing technologies, etc.), efficiency (SOs are typically resource- IoT systems, thus enhancing their maintainability, reusability constrained and battery-powered, hence requiring ad-hoc and extensibility. In such direction, this paper (i) first presents working modalities to perform at their best but saving energy), the integration of the resource-oriented agent framework and management (massive scaled IoT systems cannot complying with the IETF Constrained RESTful Environment (CoRE) framework into ACOSO-Meth; then (ii) reports a case constantly rely on human administrators, thus claiming for study to exemplify the re-engineering of a resource-constrained automatic government mechanisms and self-steering SOs). agent application through the ACOSO-Meth metamodel-driven Therefore, tackling such complex, heterogeneous approach. cyberphysical IoT systems without systematic approaches and proper development frameworks is definitively ineffective, Keywords—Internet of Things; Smart Objects; Methodology; error-prone and time-consuming. Software Agents; Resource-oriented Architecture; IETF CoRE. To address the aforementioned issues and support the IoT systems development, different methodologies have been I. INTRODUCTION proposed over the years. Some of them provide domain- The Internet of Things (IoT) relies on the seamless specific and technology-dependent approaches. For example, interaction among humans, conventional computers and Smart [19] and [20] deal with interoperability solutions for industrial Objects (SOs), namely everyday devices augmented with contexts, while [25] focus on the optimal deployment of IoT sensing, actuation, processing, and communication capabilities applications in the Fog. Other methodologies, instead, are [18]. SOs, despite their constrained hardware/software general purpose but do not cover the entire IoT systems resources (i.e., limited memory and processing units, small development process. For example, [21-23] fully support IoT batteries, lightweight operating systems and communication system analysis and design through systematic collections of protocols), are widely acknowledged as fundamental building guidelines, software engineering abstractions and reference blocks for realizing ubiquitous IoT systems and disruptive models, but providing implementation frameworks and tools is services on top of them, in every application scenario. In out of the scope. To bridge the gap, ACOSO-Meth [1] has been particular, SOs are expected to (i) autonomously operate on proposed as a novel full-fledged, application domain-neutral, their local environment, observing and collecting data and agent-oriented, and metamodel-driven methodology. It executing their tasks; (ii) collaborate to provide cyberphysical supports the development of SO-based IoT systems (from the services outside the capabilities of a single SO, sharing preliminary analysis phase to the implementation) as well as re- information and utilizing other SOs' resources; (iii) distribute engineering legacy IoT frameworks to enhance their their smartness and functionality, in a bottom-up fashion, maintainability, reusability and extensibility (features which across the whole IoT system. Such advanced behaviors exactly cannot be underestimated in the constantly evolving IoT match the distinctive software agents’ prerogatives, this is the scenario, where novel devices and services steadily show up). reason for the wide adoption of the agent-based computing In this paper, the ACOSO-Meth approach is exploited for re- paradigm for developing IoT systems in terms of multi-agent engineering a resource-oriented software agent framework systems (MASs) [17]. Indeed, as opposed to cloud-centric and that is based on the IETF Constrained RESTful client/server architectures (which have led to application- Environments (CoRE) [2,4,7]. The agent framework specific, unscalable and isolated IoT silos), MASs are a natural (ROAgent) enables heterogeneous, resource-constrained agent- selection to realize decentralized architectures based on based SOs interoperating in IoT systems in a standardized way. autonomous, interoperable, cognitive entities, just like SOs The integration of ROAgent framework into ACOSO-Meth is [18]. However, beside the promises of an open ecosystem straightforward, effective and sound, since they share the SO- providing innovative cyberphysical services, IoT systems and based vision, IoT system requirements (interoperability, SOs pose challenging development issues like scalability (IoT 81 dynamicity, scalability, etc.) and the enabling paradigms DeviceEvent if the event source is an SO device) and purposes (agent-based and service-oriented computing). (i.e., SystemTasks refer to basic SO lifecycle operations while UserDefinedTasks define specific application-oriented SO The rest of the paper is organized as follows. Sections II operations). and III introduce ACOSO-Meth and ROAgent framework, respectively. Section IV describes the re-engineering of the Implementation phase finalizes the outcomes of the framework according to ACOSO-Meth, whose analysis, design previous stages and its metamodel (JACOSO Metamodel) and implementation metamodels are instantiated on a ROAgent elicits the programming paradigms and technology chosen to based SO application in Section V. Finally, conclusions are realize SO functionalities of communication, augmentation, drawn and future work briefly delineated. service provision and information management. In particular, for the SO implementation ACOSO-Meth relies on JADE, a II. ACOSO-METH FIPA-compliant, open-source and Java-based agent platform whose extensions JADEX and JADE-LEAP also run on Raised from a thorough state-of-the-art analysis aimed at constrained devices (e.g., Java Micro Edition-enabled and the identification of the fundamental development Android-supported devices, motes of wireless sensors requirements, ACOSO-Meth [1] supports the engineering of networks). JADE provides an effective agent-oriented IoT systems through a metamodel-driven approach and the management/communication infrastructure, that comprises an joint exploitation of well-known computing paradigms and Agent Management System (AMS), an ACL-based Message programming frameworks (respectively, agent-based Transport System (MTS) and a Directory Facilitator (DF, computing and ACOSO middleware). Indeed, a set of which has been purposely extended for realizing a dedicated technology-agnostic metamodels, placed at different and dynamic SO discovery service according to the High-Level abstraction levels but strongly interrelated and completely SO Metamodel data). Aiming at interoperability, two sets of decoupled from any specific application context, provide software adapters allow the management of different generality to ACOSO-Meth approach and drive IoT developers communication paradigms (direct message passing, towards the development phases of analysis, design and asynchronous one-to-may communication, etc.) and implementation. augmentation devices (sensors and actuators supporting typical Analysis phase aims at providing an inclusive, but not too IoT standards such as ZigBee, Bluetooth, etc.). complex, high-level SO representation that is compliant with According to well-known and important good practices of emerging IoT architectural standards such as AIOTI and IoT-A software engineering (more than ever crucial for the IoT domain models [21, 22]. Indeed, the metamodel of the Analysis context), the ACOSO-Meth approach guarantees: phase disregards all behavioral elements but highlights those basic features and static/dynamic information (e.g., physical (i) a suitable and customizable degree of abstraction, properties, location, hardware/software characteristics) which essential to address the difficulty of complex IoT systems’ are suitable to describe any SO at a first glance and in every modeling, through a high-level analysis metamodel that is domain. Therefore, the High-Level SO Metamodel of this incrementally refined and detailed; phase represents the basement for the further design and (ii) modularity and maintainability, by delegating SO implementation processes (see Figure 3), which conversely functionalities to loosely-coupled dedicated subsystems; provide technology-dependent solutions for both SO-SO and SO-IoT System interactions. (iii) reusability and extensibility, with a hierarchical classification of Events/Tasks/Adapters, where most of the Design phase focuses, more than on SO data, on SO code can either be directly reused (frozen-spots) or at least functionalities, i.e., communication, augmentation, service customized (hot-spots, programmed by extension) according to provision and information management. Indeed, metamodel of the particular application requirements; the Design Phase highlights the functional components of the SO and their interactions, eliciting adopted computing (iv) interoperability and evolvability, with paradigms and enabling mechanisms, independently from design/implementation choices (e.g., device and specification or low level details. In particular, ACOSO-Meth communication adapters, uniform interfaces) purposefully designs an SO as a software agent according to the ACOSO aimed at accommodating IoT system heterogeneity and its middleware and its agent model (namely, ACOSO-based SO dynamic evolution. Metamodel). SO communication is driven by Events handled These properties together make ACOSO-Meth general and by a CommunicationManagementSubsystem, which provides a flexible enough to facilitate and speed up the development of common interface enabling communication toward the SO novel SOs/IoT systems as well as the advantageous re- itself or toward external entities. Similarly, interactions engineering of existing ones. Indeed, according to both between the SO and its augmentation devices, regardless of identified SO functionality groups (communication, their specific technology or protocols, are handled by a augmentation, service provision and information management) DeviceManagementSubsystem. By means of Tasks, the SO and development principles (modularity, reusability, etc.), exploits these subsystems and reacts to external stimulus, customized design and implementation metamodels of an fulfills specific goals and exploits inference rules on already existing IoT system can be defined starting from the local/remote knowledge bases. Both Events and Tasks are High-Level SO metamodel. As shown in Figure 1, the ELDA specialized, respectively, with regard to their sources (e.g., framework has been partially re-engineered [24] (ELDA-based InternalEvent if the event source is an SO internal component, SO aims at being simulated but no executed), while the 82 ROAgent framework has been fully integrated in ACOSO- of how they are provided. In addition, REST gives the Meth, as reported in Section IV. More details on ACOSO- constraints to define a uniform interface that enables software Meth, in particular about the evolution of SO-related concepts components, e.g. IoT devices and services, to automatically from high-level abstractions to implementable software built distributed applications [9]. The interface is typically components can be found at [1] (e.g., the SO Service first realized with well-known Web protocols, such as HTTP or abstractly presented in terms of Operations and QoS indicators CoAP for the embedded Web, because their request-reply at the analysis phase and then refined at both design and semantics (e.g., GET and POST with resource URIs) are implementation phases as application-level UserDefinedTasks universally known and proven operationally simple. This with related ServiceEvents). allows realizing a uniform interface, as a RESTful API, for the IoT system components, including resource-constrained devices [10]. To comply with ROA, the agent framework integrates software agents and their properties into the system as resources [7]. The uniform interface is realized for the framework through two Web protocols, i.e., HTTP and CoAP. This way, same methods are provided for all system components for accessing agent services through the resource abstraction, but also the agents can interact with other system services using the same interface. Figure 2 illustrates the ROAgent framework architecture and infrastructure components. The FIPA DF (including FIPA Agent and Service Directories) functionality is provided with Distributed Resource Directory (DRD) [3]. Following the uniform Figure 1 Integration of ELDA and ROAgent frameworks in ACOSO-Meth interface, each system component registers its resources (their III. RESOURCE-ORIENTED AGENT FRAMEWORK FOR IOT URIs) into the DRD. System components can then perform runtime lookups to locate needed resources in the system. The The resource-oriented agent framework (ROAgent) [2,7] is Proxy component is a protocol translator between HTTP and conceptually based on resource-oriented architecture (ROA) CoAP protocols, allowing seamless bidirectional resource [9] and its realization is based on two existing standards. First, access through the uniform interface. In [7], two types of the standardized IETF CoRE framework [10] specifications are ROAgent platforms for resource-constrained IoT devices, i.e., followed to integrate resource-constrained embedded IoT Android smartphones and Arduino based embedded boards, are devices into the Internet through optimized embedded Web presented. Both platforms provide the minimum required FIPA protocols. The use of embedded Web services is justified from components, i.e., AMS, MTS and DF (through DRD). In the the interoperability point of view, as Web technologies are platforms, either HTTP or CoAP serves as the combined currently the only viable solution for Internet-scale message transport and agent interaction protocol, realizing the interoperability. Within the embedded Web, resources and RESTful uniform interface. Therefore, the agents’ vocabulary services of IoT devices become browsable and searchable for interactions is limited to the protocol method semantics and across organizational boundaries for both human-machine expressive power, as described in detail in [7]. With regard to interactions and machine-based automatic IoT application agent-based SOs, the framework’s RESTful API and the development. Second, the framework provides a subset of ROAgent architecture were extended in [4] to include SO- FIPA functionality on the IoT devices which operate as agent specific capabilities and high-level abstractions. platforms. The FIPA specifications are followed with regard to agent framework and platforms. However, the ROAgent framework does not fully realize FIPA ACL but, instead, embedded Web protocols are used for agent interactions, as detailed in [7]. This ROAgent framework is currently the only fully REST-compliant agent framework and the only one enabling autonomous agents to interact using embedded Web protocols. Previous work in the context of IoT and software agents has utilized Web services and protocols for interactions [11,13,16], Web documents for hosting agents representations [14,15] and wrappers for translating between ACL and REST interactions [12]. Conceptually, the main abstraction in ROA is a resource, as prescribed by the well-known Representational State Transfer (REST) architectural principles [9]. Generally, everything that has value in the system is abstracted as a resource and identified and addressed through a unique URI. This includes data, IoT devices, their physical components such as sensors, Figure 2. Resource-oriented agent framework other system components and services in the system, regardless 83 To fully benefit from the simplified operational semantics TABLE I. RESOURCE-ORIENTED AGENT ARCHITECTURE provided with the REST principles and the uniform interface, Name Resource URI of the agent the agent architecture needs also to comply with the REST and ROA principles. An agent architecture [2,7] is defined where Tasks (agent programs) all the agent components, state and properties are abstracted as Code Operation Services (agent programs) resources and thus have their own (hierarchy-based) URIs. The benefit is that the resource abstraction allows to distribute Device Data, Sensors, Local resources Actuators, Services browsability, searchability, interoperability, etc. into the system Resource Any system resource: components and utilize them similarly with the uniform Remote System Devices and their interface, regardless of their location. In other words, the agent- resources components, Services, .. based SO functionality can now be distributed in a fully Service content transparent way [4]. Knowledge State Task results, interaction results Table 1 illustrates the resource-oriented agent (ROAgent) base architecture [2,4]. ROAgent itself has a name, i.e., a unique Metadata Location, Physical Properties, Creator, .. identifier, that is the agent URI. In the Code segment, the agent has a set of operations that define the agent functionality and development phases of analysis, design and implementation, provide services. Individual tasks can be integrated into a next described in detail. service. These programs, in turn, utilize the other segments, e.g., knowledge base, and/or interact with local or remote A. Analysis phase resources through their corresponding URIs. The Resource Metamodel at Analysis phase abstracts SO basic features, segment defines the device and system resources that the agent categorized in four main groups, as shown in Figure 3. utilizes in its operation. Lastly, the State segment contains the values of agent properties, such as service content, task and • SO BasicInfo comprises basic SO information and setting. interaction results, and metadata such as physical or virtual Status contains a list of key-value pairs that capture the SO location and agent creator. Each agent component has its own state, e.g., current SO temperature, residual energy, etc.; URIs that are organized in an agent-based hierarchy in the Location represents its geophysical position expressed agent architecture. As an example, through the RESTful through latitude and longitude coordinates and/or location uniform interface, the agent service content can be retrieved by tags; PhysicalProperty is a list of physical properties of the any system component using the request GET /agent_name/ or original object without any hardware augmentation and specifying a service with GET /agent_name/service. Internally, embedded smartness, e.g., SO dimensions, weight; agent starts a task with POST /task and receives its results FingerPrint comprises SO information like the SO though request GET /task. Local resources are accessed by an identifier, the SO creator, the resource URI, etc. agent task through GET /sensor. Similarly, the agent can access • SO Service models a digital service provided by an SO. remote resources with GET /remote_device/sensor or request Each service is characterized by a name, description, type an operation for the resource with POST (e.g., sensing and actuation), input data and output data. /remote_device/actuator. Service is implemented by one or more Operations and by As described in [2,4,7], the ROAgent framework does not one or more QoSIndicators (e.g., latency, accuracy) whose have its own security mechanisms, but it relies on those associated values are provided. In detail, an Operation, provided by the IETF CoRE specifications, e.g., identification, which defines an individual operation that may be invoked authorization, CoAP and lower layer protocol stack security. on a service, has a description, a set of input data types Indeed, from ROAgent perspective, both agent platforms and necessary for its invocation, and an output related to its DRD (which actually handles authentication and authorization) result. with its registered resources are considered trusted. Conversely, • SO User identifies an entity using the services provided by for agent interactions with remote IoT systems (e.g., external an SO. In particular, SO Users can be humans (according Web services) over Internet, resources should be considered to the conventional man-machine use relationship), untrusted and are therefore accessed in a secure manner, e.g., SmartObjects (SOs can take advantage of the services through HTTPS or a proxy to maintain security. exposed by other SOs), or DigitalSystems (representing a generic digital entity, like a web service, software agent, IV. INTEGRATION OF ACOSO AND ROA AGENT FRAMEWORK robot or a more complex system). In this Section we describe the application of ACOSO- • Augmentation defines the hardware and software Meth to the ROAgent-based SO (ROA_SO), which is characteristics of a device that allows augmenting the compliant with the ROAgent framework and fully compatible physical object and making it smart. A device can be with IETF CoRE framework. specialized in one of the following three categories: (i) The integration aims at highlighting ROAgent framework Computer, which represents the features of a processing own features (e.g., support to interoperability, attention for unit of the SO, e.g., PC, smartphone, and embedded resource-constrained SOs) and, at same time, providing a device; (ii) Sensor, which models the characteristics of a higher degree of modularity, maintainability and evolvability. sensor node of the SO, e.g., presence/temperature/light The performed re-engineering process covers the three sensor; and (iii) Actuator, which models the 84 characteristics of an actuator node of the SO, e.g., led, buzzer, switch. Figure 4. ROA_SO metamodel at Design Phase by the agent itself or any an external component, e.g., SO Manager. Figure 3. SO High-Level Metamodel at Analysis Phase Augmentation is provided by the Device and External B. Design phase Resources, e.g., SO sensors, actuators, local and remote computing capabilities. To comply with the ROAagent SO High-Level Metamodel is refined at the Design phase to framework, these components are also modeled as resources. obtain the ROA_SO Metamodel complying with the ROAgent The ROA_SO utilizes the uniform SO_Interface and resource framework, as shown in Figure 4. The SO is modeled as an abstractions to access any of the hardware or software event-driven, lightweight and platform-neutral agent that components it needs, despite their actual location (internal or exploits the resource abstraction and ROAgent architecture for external to the SO). its operations. The SO lifecycle is specified in terms of Behavior. Behavior consists of one or more state machine- SO Communication is performed through the uniform based components named Tasks and coordinated by SO_Interface component, which is built on REST principles, SO_Manager. Tasks can refer to internal system operations i.e., well-known semantics of standardized Web protocols (SystemTask), e.g., management of the SO lifecycle, or to SO (HTTP or CoAP), their methods, the URIs and protocol application-specific agent-based functionalities (ServiceTask). response codes [9]. Inputs required by Tasks are acquired through the uniform interface and resource URIs, providing transparent access C. Implementation phase regardless of resource type and location. Tasks are driven by At this phase, ROA_SO Metamodel is implemented with Events according to the following interaction model. Whenever regard to the heterogeneous ROAgent platforms. On one hand, an external request or a response to an internal request arrives the Android platform is implemented with Java atop the to the SO, it is caught by the uniform interface (SO_Interface), Android OS and provides the hardware/software resources of a which creates an Event wrapping the message and delivers it to modern smartphone. On other hand, the Arduino platform has the SO_Manager. The SO_Manager instructs Tasks responsible very limited hardware components, e.g., a 8-bit microcontroller of the needed resources on how to process either the request or with only a few kilobytes of RAM, and in fact it belongs to the the response to an earlier request. Similarly, such procedure is lowest class of devices, resource-wise, defined in the CoRE followed if, during the request/response processing, the task standards. As shown in [2,8], minimal ROAgent can be need to access other resources. After the request/response has implemented into a such platform through the C programming been processed, an Event is created that contains the output language. The detailed descriptions of the agent platform data, handled again by the SO_Interface and disseminated to implementations are given in [2,7]. the requestor, if needed. This way tasks cooperate internally to the SO and can answer complex or aggregated request. The Implementation phase Metamodel is the following (Figure 5): As done for the Analysis phase, the ROA_SO Design metamodel’s elements are categorized into four main groups: SO BasicInfo are retrieved from the ROAgent knowledge base and task results (the results are the information in the SO BasicInfo reported at the Analysis phase is extended to knowledge base that can be used by others or returned to a contain the ROAgent state, its resource descriptions (from the client). Details of ROAgent task execution and interaction are DRD), e.g., tasks and results, their invoking events and the given in [7]. The knowledge base is updated through the results content description of its knowledge base. of Task execution and ROAgent interactions. Due to limited SO Service provided by the SO are encapsulated in specific hardware resources in the Arduino platform, typically the ServiceTasks. The ROA_SO service content is derived from responses contain only a few bytes of data and rules regulating the ROAgent’s service content, that typically comprises its task Tasks invocation are simple as well, for example sensor data results, and if required, from its knowledge base or through filtering. The platform available memory size further limits the agent’s interactions. In the ROAgent architecture, each service possibility to execute multiple Tasks and the interaction and related tasks are invoked using the uniform SO_Interface capabilities between Tasks and with resources. 85 SO Service content is encapsulated into the ROAgent state and typically composed of the knowledge base, task and interactions results. An SO Service is accessed through the uniform interface by using the ROAgent URI. If the ROA_SO includes several Tasks and Services, the results of each computational component can be retrieved through the URI hierarchy. This way also the distributed MAS-based SO functionality [4] can be realized. Augmentation capabilities refer to the hardware and software components of the SO hosting devices. Android devices typically provide a number of embedded sensors (e.g., accelerometer, gyroscope), but also remote devices (e.g., Bluetooth connected wearables). These all can be modeled as resources for the ROA_SO, whenever the platform provides means to interact with them. In the Arduino platform, due to limited hardware resources, simple sensors and actuators are Figure 5. ROA_SO Metamodel at Implementation Phase easy to integrate through predefined I/O interfaces as resources. For interoperability with the IETF CoRE framework, platforms described in detail in [6]. In addition, a set of stationary are required to register their available resources into the system Arduino-based nodes also execute Wi-Fi scans that provide DRD, so that ROA_SOs can share and discover nearby reference information, in their physical location, of the detected resources. access points and their RSSI's. Now, the precise location over time of the smartphones can be estimated with a similarity SO Communication is managed by the RESTful uniform measure between the access points scan data and nodes scan interface, implemented either as HTTP (for Android) or CoAP data. In [6], we outline the following system operation. The (Arduino) server. In both platforms, SO_Manager and uniform IoT devices, i.e., smartphones and Arduino nodes, have joined interface functionality are implemented as a part of the FIPA the ROAgent framework and registered their resources into the AMS implementation (AMS in Figure 5). This component is DRD. The sensing operation in the devices are controlled by also responsible for handling the communication with the IETF ROAgents, as in [5, 8], which enables the agents to optimize CoRE framework components, e.g., to register ROA_SO the device energy consumption by controlling the sensing resources and possibly to interact with the Proxy. IETF CoRE operation in the devices, e.g., scan period and length. In Proxies are expected to follow the uniform interface, which addition, the SmartMobilityDetector runs in a virtual machine makes the interactions straightforward for ROA_SO. As (VM) in an IoT edge server that performs the computationally discussed above, FIPA ACL is not supported in the ROAgent expensive flock detection and trace calculation operations. framework due to limited resources in the constrained ROAgent platforms, e.g., Arduino. However, to comply with Next, we show how the ACOSO methodology is applied FIPA specifications, an external resource, e.g., a wrapper, can for the re-engineering the SmartMobility case study. be introduced that translates FIPA ACL messages into RESTful interactions for the uniform interface as in [12]. The A. SmartMobility Analysis Phase ROAgent interactions should be then directed into this resource The Analysis phase metamodel of ROA_SO whenever ACL-based interactions are required. SmartMobilityDetector is shown in Fig. 6. As deployed into the ITEE Faculty premises, the SmartMobilityDetector V. CASE STUDY: SMARTMOBILITY exploits, in the infrastructure side, a number of Arduino nodes To demonstrate the effectiveness of ACOSO-Meth in re- (identified as AN#x), which are connected to the ROAgent engineering existing IoT systems that have been previously framework as system resources. This enables them to update developed without a systematic approach, we present a their data to the edge server. Also, the Wi-Fi access points ROA_SO-based IoT application SmartMobility as a case study. (identified as AP#x) are considered infrastructure components and exploited as sensors (Wi-Fi scan). The SmartMobilityDetector is an SO that provides movement traces of individual users and flocks of users within The deployed devices define the SmartMobilityDetector the premises of the Faculty of Information Technology and coverage area (e.g., 100x100x5m). The SmartMobilityService Electrical Engineering (ITEE) at the University of Oulu, service comprises two Operations: Finland. Movement traces are initially based on collecting IndividualMobilityDetection, focused on a single smartphone Android smartphone ID's (i.e., MAC addresses) while they are mobility trace, and FlockMobilityDetection, which first connected to the Wi-Fi access points. To provide indoor high identifies a set of flocks by analyzing the sensor data from the precision location tracking and to perform the flock detection, devices and secondly provides the aggregated mobility trace. the devices are expected to periodically perform a Wi-Fi scan, Both operations are invoked by defining the and this operation returns a data vector of detected Wi-Fi (sub)area/timeframe of interest, and are featured by a certain access points and their respective signal strengths (RSSI) [5]. reliability (calculated as correlation between user data vector The flocks of users are then detected based on similarity and historical movement traces, which provides means for measure of the data vectors of different smartphones, as anomaly detection). Client Web services can access, according 86 to Administrator (security and building maintenance parameters or a ROAgent in a smartphone informs that its operators) requests, the SmartMobilityDetector through the battery level is insufficient to continue participation. uniform interface with its resource URI that includes an ID code for the SO (e.g., SMD#1). Figure 7 SmartMobilityDetector Design Metamodel C. SmartMobility Implementation It is expected that the participating IoT devices run the ROAgent platform, which enables autonomous smart operation and also integration into the ROAgent framework. The IoT edge server implements the SmartMobilityDetector as a VM, thus encapsulating SO functionality into an executable unit that can be migrated in the IoT system infrastructure side, following the common solution for edge computing applications. The ROAgent-based SmartMobilityDetector follows the Figure 6. SmartMobilityDetector Analysis Metamodel architecture shown in Table 1 and it is shown in Figure 8. B. Smart Mobility Design Phase SmartMobilityDetector BasicInfo includes the state of the The refined SmartMobility ACOSO Design metamodel is ROAgent. The knowledge base is implemented in the Android shown in Figure 7. platform as a database and in the Arduino platform as a shared memory component The SmartMobility service is implemented The SO BasicInfo consists of the ROA_SO knowledge base through Operations, i.e., agent programs for flock detection, and lists of participating devices (from DRD based on real-time IndividualMobilityDetection and FlockMobilityDetection. The information) and infrastructure components. The ROA_SO actual SmartMobility implementation is then a composite of knowledge base contains the following information: 1) the Task agent programs and their results, which is responsible collected raw sensor i.e., Wi-Fi scan data from the devices; 2) for event-driven execution of the Tasks. In addition, the task results, i.e., individual movement traces (IndividualTrace ServiceConfigurationTask allows interacting with the Task), detected flocks (FlockDetection Task) and their traces ROAgents in the smartphones and Arduino boards, for (FlockTrace Task), which are shared among Tasks to refine the example, in order to set Wi-Fi scan parameters. information. The SmartMobilityDetector relies on SOConfigurationTask, instead, allows setting the SO internal infrastructure components (Wi-Fi access points and Arduino parameters, such as SO creator, ID, etc. The ROAgent platform nodes) as DeviceResources, the DRD and ROA_SO ROAgent AMS implements the uniform interface, which enables to knowledge base as InternalResource and the pedestrians’ utilize internal (ROAgent state and DRD) and external smartphones as ExternalResource. The ROA_SO services are resources (participating devices) and their data in the service implemented as Tasks of the ROAgent. Tasks are driven by execution. To interact with the heterogeneous IoT devices, it is Events, which are delivered from the resources through the required that the AMS provides both CoAPAdapter (for uniform interface. In details, InternalEvents notify that Arduino boards) and HTTPAdapter (for Android smartphones). smartphones join/leave the framework. DeviceEvents notify This realizes the MTS. As an example, HTTP/CoAP POST that new scan data has been uploaded from the Arduino nodes method is used to set the Wi-Fi scan operation parameters and or that Wi-Fi access point information has changed. GET method (or CoAP OBSERVE method) is used to retrieve ServiceEvents (traceEvent and flockEvent) are exploited data from the devices. The ACLAdapter resource is not whenever a task produces results, which are exploitable by required for the SmartMobilityDetector SO. other tasks. ExternalEvents enable the interaction with the ROAgent running in the smartphones, e.g., when CONCLUSION SmartMobility service sets the required Wi-Fi scanning Complexity and requirements characterizing IoT systems and SOs claim for proper development methodology and 87 frameworks. In this paper the re-engineering of the ROAgent Trunfio (eds.), Internet of Things based on Smart Objects: Technology, framework according to ACOSO-Meth methodology has been Middleware and Applications, pp. 29-48, Springer, Heidelberg, 2014. [5] T. Leppänen, T., J. Alvarez Lacasia, Y. Tobe, K. Sezaki and J. Riekki, “Mobile Crowdsensing with Mobile Agents,” in Autonomous Agents and Multi-agent Systems, vol. 31, no. 1, pp. 1-35, Springer, 2017. [6] J. Alvarez Lacasia, T. Leppänen, M. Iwai, H. Kobayashi and K. Sezaki, “A method for grouping smartphone users based on Wi-Fi signal strength,” in Forum on Information Technology, paper J-032, Information Processing Society of Japan, 2013. [7] T. Leppänen, “Resource-oriented mobile agent and software framework for the Internet of Things”. Doctoral dissertation, Acta Universitatis Ouluensis, C Technica, no. 645, University of Oulu, ISBN 978-952-62- 1813-7, 2018. [8] T. Leppänen and J. Riekki, “Energy Efficient Opportunistic Edge Computing for the Internet of Things”, Web Intelligence, IOS Press, 2018 [Accepted]. [9] L. Richardson & S. Ruby, “RESTful web services”, O'Reilly, 2008. [10] Z. Shelby, “Embedded web services”, IEEE Wireless Communications, vol. 17, no. 6, 2010. [11] P. Leong and L. Lu, “Multiagent web for the internet of things,” in IEEE ICISA2014, pp. 1-4, 2014. [12] L. Braubach and A. Pokahr, “Conceptual integration of agents with wsdl and restful web services”, in Int’l Conf. on Autonomous Agents and Multiagent Systems, pp. 17-34, 2012. Figure 8 SmartMobilityDetector Implementation Metamodel [13] J. Jamont, L. Medini and M. Mrissa, “A web-based agent-oriented approach to address heterogeneity in cooperative embedded systems,” in presented and exemplified with a ROAgent framework–based Trends in Practical Applications of Heterogeneous Multi-Agent crowdsensing application of SmartMobility. In particular, we Systems. The PAAMS Collection, pp. 45-52, 2014. showed that ACOSO-Meth-based re-engineering highlights [14] J. Voutilainen, A. Mattila, K. Systä and T. Mikkonen, “HTML5-based and enhances both functional (e.g., support to interoperability, mobile agents for Web-of-Things,” Informatica, vol. 40, no. 1, 2016. attention for resource-constrained SOs) and non-functional [15] D. Mitrovic, et al., “The Siebog multiagent middleware”, Knowledge- Based Systems, vol. 103, 56-59, 2016 (e.g., modularity, maintainability, evolvability) features of [16] P. Pico, J. Holgado-Terraza, “A Framework for the Development of ROAgent framework, due to the full-fledged, domain-neutral Smart Ubiquitous Real-Time Systems Based on the Internet of Agents and metamodel-driven approach. All the aforementioned and Internet of Services Approaches”, 12th Int’l Conf. on Intelligent features, both functional and non-functional, generate Environments, vol. 21, p. 76, 2016. fundamental benefits for complex and heterogeneous IoT [17] C. Savaglio, G. Fortino, M. Ganzha, M. Paprzycki, C. Bădică, and M. scenarios. The integration of ROAgent framework into Ivanović, “Agent-Based Computing in the Internet of Things: A ACOSO-Meth is straightforward, effective and sound since Survey,” in Int’l Symposium on Intelligent and Distributed Computing, 2017, pp. 307–320. they share the SO-based vision, IoT system requirements and the enabling computing paradigms (agent-based and service- [18] C. Savaglio, G. Fortino, and M. Zhou, “Towards interoperable, cognitive and autonomic IoT systems: An agent-based approach,” in Internet of oriented). As future work, we plan to study the outlined Things (WF-IoT), 2016 IEEE 3rd World Forum on, 2016, pp. 58–63. SmartMobility application in real-world settings at the smart [19] D. Slama, F. Puhlmann, J. Morrish, and R. M. Bhatnagar, “Enterprise university and smart city, to gain deeper understanding on the IoT: Strategies and Best Practices for Connected Products and Services,” challenges of resource-constrained IoT development [26, 27]. O’Reilly Media, Inc., 2015. [20] T. Collins, “A methodology for building the Internet of Things,” 2017. ACKNOWLEDGMENT [21] A. Bassi et al., “Enabling things to talk,” Springer, 2016. This work has been carried out under the framework of INTER- [22] O. Vermesan and P. Friess, “Building the hyperconnected society: IoT, Research and Innovation action - Horizon 2020 European Project, Internet of things research and innovation value chains, ecosystems and Grant Agreement #687283, financed by the European Union. markets,” vol. 43. River Publishers, 2015. [23] F. Zambonelli, “Towards a general software engineering methodology REFERENCES for the Internet of Things,” arXiv preprint arXiv:1601.05569, 2016. [1] G. Fortino, W. Russo, C. Savaglio, W. Shen, and M. Zhou, “Agent- [24] G. Fortino, A. Guerrieri, W. Russo, and C. Savaglio, “Towards a Oriented Cooperative Smart Objects: From IoT System Design to development methodology for smart object-oriented IoT systems: A Implementation,” IEEE Transactions on Systems, Man, and Cybernetics: metamodel approach,” in Systems, Man, and Cybernetics (SMC), 2015 Systems, pp. 1–18, 2017. doi: 10.1109/TSMC.2017.2780618 IEEE Int’l Conf. on, 2015, pp. 1297–1302. [2] T. Leppänen, M. Liu, E. Harjula, A. Ramalingam, J. Ylioja, P. Närhi, J. [25] S. Venticinque and A. Amato, “A methodology for deployment of IoT Riekki, and T. Ojala, “Mobile Agents for Integration of Internet of application in fog,” Journal of Ambient Intelligence and Humanized Things and Wireless Sensor Networks,” in IEEE Int’l Conf. on Systems, Computing, pp. 1–22, 2018. Man, and Cybernetics (SMC2013), pp. 14-21, Manchester, UK, 2013. [26] R. Casadei, G. Fortino, D. Pianini, W. Russo, C. Savaglio and M. Viroli, [3] M. Liu, T. Leppänen, E. Harjula, Z. Ou, A. Ramalingam, M. Ylianttila “Modelling and Simulation of Opportunistic IoT Services with and T. Ojala, “Distributed resource directory architecture in Machine-to- Aggregate Computing,” in Future Generation Computer Systems, to Machine communications,” in 9th IEEE Int’l Conf. on Wireless and appear. Mobile computing, Networking and Communications (WiMob), pp. 319-324, Lyon, France, 2013. [27] G. Fortino, and P. Trunfio, “Internet of things based on smart objects: Technology, middleware and applications,” Springer Science & [4] T. Leppänen, J. Riekki, M. Liu, E. Harjula and T. Ojala, “Mobile Business Media, 2014. Agents-based Smart Objects for the Internet of Things,” in: Fortino and 88 89