An Ontological Architecture for Principled and AutomatedSystem of Systems Composition

Abdessalam Elhabbash, Vatsala Nundloll,Yehia Elkhatib, Gordon S. Blair

a.elhabbash@lancaster.ac.ukSCC, Lancaster University, UK

Vicent Sanz MarcoFCRL, Osaka University, Japan

ABSTRACTA distributed system’s functionality must continuously evolve, es-pecially when environmental context changes. Such required evo-lution imposes unbearable complexity on system development. Analternative is tomake systems able to self-adapt by opportunisticallycomposing at runtime to generate systems of systems (SoSs) thatoffer value-added functionality. The success of such an approachcalls for abstracting the heterogeneity of systems and enablingthe programmatic construction of SoSs with minimal developerintervention. We propose a general ontology-based approach todescribe distributed systems, seeking to achieve abstraction andenable runtime reasoning between systems. We also propose an ar-chitecture for systems that utilize such ontologies to enable systemsto discover and ‘understand’ each other, and potentially compose,all at runtime. We detail features of the ontology and the archi-tecture through two contrasting case studies: one on controllingmultiple systems in smart home environment, and another on themanagement of dynamic computing clusters. We also quantitativelyevaluate the scalability and validity of our approach through exper-iments and simulations. Our approach enables system developersto focus on high-level SoS composition without being constrainedby deployment-specific implementation details.

CCS CONCEPTS• Computer systems organization → Architectures; • Com-puter systems organization Self-organizing autonomic com-puting;

KEYWORDSself-adaptation; context awareness; ontology; runtime composition;system of systems

ACM Reference Format:Abdessalam Elhabbash, Vatsala Nundloll, Yehia Elkhatib, Gordon S. Blairand Vicent Sanz Marco. 2020. An Ontological Architecture for Principledand Automated System of Systems Composition. In . ACM, New York, NY,USA, 11 pages. https://doi.org/0000001.0000001

Permission to make digital or hard copies of all or part of this work for personal orclassroom use is granted without fee provided that copies are not made or distributedfor profit or commercial advantage and that copies bear this notice and the full citationon the first page. Copyrights for components of this work owned by others than ACMmust be honored. Abstracting with credit is permitted. To copy otherwise, or republish,to post on servers or to redistribute to lists, requires prior specific permission and/or afee. Request permissions from permissions@acm.org.SEAMS 2020, May 25–26, 2020, Seoul, South Korea© 2020 Association for Computing Machinery.https://doi.org/0000001.0000001

1 INTRODUCTIONComputing systems have evolved from the basic picture of con-nected PCs and mobile devices to the complicated picture of theinter-connected collections of heterogeneous systems. These sys-tems include Internet of Things (IoT), clouds and micro-clouds,ad-hoc networks (MANETS, VANETs, FANETs), smart grids, amongothers. Each of these systems contains a set of heterogeneous com-ponents that implement diverse functions communicating usingdifferent protocols. Furthermore, these various systems often needto interact and collaborate to achieve their goals. For example, iso-lated rescue teams need to opportunistically compose and accesseach others services (e.g., data look-up) to exchange information;deployed environmental IoT systems process their data on a micro-cloud in their vicinity and offload certain processing to the cloudwhen needed; etc. In this sense, larger systems are constructedthrough the interaction of smaller ones, a practice known as Systemof Systems (SoS) composition or construction [21].

The inherent characteristics of SoSs make the development ofthese systems a challenging task [28]. By definition, a SoS is a com-plex system built from a (potentially large) number of sub-systemsthat in turn are made up of different components, and so on. More-over, SoSs are typically deployed in environments where contextchanges. This is where the need arises to veer from a strict work-flow path that has been defined at design time, and form a morecomplex system in order to maintain the intended abstract behavioror to be able to provide new behavior that is only possible throughuniting with other systems in the new context. Such examples in-clude disaster recovery, adaptive IoT applications, volunteer andcrowd computing, military defense operations, and other formsof cyberphysical systems. Furthermore, the development of SoS isdynamic in nature. This is grounded in the knowledge that systemsare persistent and long-living [30]. As such, their objectives andfunctionalities evolve over time as they are constantly added, mod-ified, or removed at different time scales. This might also predicatechanges in architectural and functional dependencies.

Despite the challenges posed by the above characteristics, cur-rent approaches of constructing SoSs assume that developers havein-depth knowledge of the internal structure of each system and itscomponents [24]. Taking into account the above challenges and thecharacteristics of SoSs, it might be obvious that such approachesare deficient. We argue that the construction of SoS needs to beautonomous and dynamic. Systematic approaches for internal andcontext awareness are required to attain this goal. All systemsshould be able to accumulate knowledge about their own structureand behavior. Then, systems should exchange and be able to under-stand such knowledge at runtime so that they can opportunisticallycompose and form complex SoSs.

SEAMS 2020, May 25–26, 2020, Seoul, South Korea A. Elhabbash et al.

In order to achieve this objective, there is a need for semanticsto comprehensively describe the system structure, capturing theinformation required for dynamically composing systems such asthose relating to communication (e.g., unique identifiers), servicediscovery, quality of service, physical properties (e.g., power leveland location), environmental properties, etc. We refer to this com-prehensive structure description of a system as a holon [6]. A holonis constantly modified to reflect the system structure and to containany new or modified information, and then published to aid discov-ery and reasoning about composition. When holons compose, theyform a new holon that represents the SoS. This newly constructedholon will now have its own specification, which is published sothat the system can further compose with other SoSs and so on.

The above holon ecosystem requires means of utilizing system(or holon) description in order to reason about SoS construction atruntime in a programmatic and adaptive manner. One solution is toadopt ontologies to specify the holons. Ontologies are engineeringtools for formal and explicit specification of a shared conceptualiza-tion [10]. They provide vocabularies that can be used to representknowledge that can be utilized programmatically to understandthe corresponding contents, mainly system parameters, offeredservices, and requirements. These are expressed through standardconcepts, allowing other holons to understand the described holonand, accordingly, make decisions about how to interact with it.

In [6] we proposed the vision towards the construction of dis-tributed SoSs using holons, then in [29] we defined the basic con-ceptual structure with particular focus on IoT deployments. In thispaper we build on these works by putting forward an architecturefor realizing the holons and how they compose. The paper inves-tigates how ontologies can be used to capture the holons’ spaceto enable autonomous SoS construction. Once specified, the holondescription can be published through broadcasting to other sys-tems. The description is compiled by receiving systems in order tounderstand the functionality of the sending system, reason aboutit, and determine how to communicate with it.

Briefly, the main contributions of this paper are as follows:

• A framework for specification, compilation, dissemination, andmodification of the holons (§4–§6)

• A qualitative evaluation of the proposed approach using twodifferent case studies that motivate the need for dynamic SoSsconstruction and configuration (§7–§9).

• A quantitative evaluation of the scalability and validity of theproposed approach (§8,§10).

2 PROBLEM SPACE AND RELATEDWORKThe SoS concept has featured in the literature for over two decades [21].However, composing SoS from already existing systems at runtimeis still an area that requires more research.

The significant body of work looming here is the Service Ori-ented Architecture (SOA) legacy. SOA allows a system to expose itsfunctionalities as services, and then SOA composition technologiescan be applied to form a SoS; cf. [3, 5, 42]. We argue that suchSOA-based automation is not suitable for the following three mainreasons. First, SOA does not readily provide concepts that capturephysical system properties such as the context they are operating in.

The service composition supported by SOA is mainly functionality-based composition. However, SoS composition is wider than this, asit also requires knowledge about system properties and context toreason about the composition. Second, services in SOA are assumedto be published in a repository that an orchestrator can consult toselect services from. This assumption is not valid in the general SoScontext which is fully distributed. Third, SOA-based SoS developersare expected to know a lot about individual systems, or invest sig-nificant time learning them. Fig. 1 illustrates the tasks performedby the vendors, developers, and the system for SOS composition.Developers are required to acquire knowledge about the APIs andproperties of the elementary systems they need to compose. Then,they need to leverage that knowledge to design and implement theSoS, and finally deploy it. This requires the developer to focus onthe elementary systems instead of the whole SoS.

Figure 1: Comparing the responsibilities in current SoS com-position approaches and in the proposed one.

There has also been other non-SOA efforts. These include facili-tating discovery and composition using cellular infrastructure [11]and network middleboxes [7]. Such approaches, though, requirespecific infrastructure deployment for mediation and, more impor-tantly, still assume too much on the part of the developer in terms ofreasoning about discovered systems. This final task is crucially dif-ficult without means of identifying these systems’ modus operandi.Someworks have chosen to do this at design time (e.g., [23]) throughanalyzing qualitative mission objectives of systems, but these arehard to express in a programmatic way that enables automatedreasoning at runtime.

The closest work to ours also defines the notion of a holon [18,32], but is focused on goal-driven service composition withoutmeans of allowing holons to reason and self-compose.

Agent-based ontological approaches have been proposed, e.g., [1,2, 12, 34]. However, these works are less systematic than our holonontology. Moreover, they also do not indicate how composition isreasoned about in a heterogeneous environment.

3 RESEARCH STRATEGYBased on the above, our ultimate goal is to shift the developers’focus from learning the internals of elementary systems to thinkingat the level of the SoS. As shown in Fig. 1, holons allow devel-opers to focus on defining high-level workflows of the SoS. Theelementary systems need to autonomously discover each otherand compose to serve the requests. The achievement of this goalrequires (1) a comprehensive description of the atomic systems(their services, properties, and context) that enable autonomouscomposition between systems; and (2) an architecture the exploitssuch descriptions and supports SoS composition and adaptation.

An Ontological Architecture for Principled and Automated System of Systems Composition SEAMS 2020, May 25–26, 2020, Seoul, South Korea

Our research seeks to answer the following three questions.RQ1: What are the right abstractions to represent different sys-

tems within a SoS framework?RQ2: What systems principles and techniques are then required

to support SoS composition?RQ3: What extensions are required to support SoS composition

and adaptation in heterogeneous, large-scale environments?Our work uses an ontological approach towards real-time rea-

soning around the composition of systems of systems. This is madepossible by an architecture we have built for comprehending whatan SoS is made up of, if composition is required, and how such com-position would take place. Moreover, the architecture automaticallyactions the low-level mechanics that enable the composition. Tovalidate the feasibility and utility of our architecture, we adopt ahybrid experimental evaluation strategy that comprises of quali-tative assessment of controlled testbed experiments (specificallyin the domains of IoT and infrastructure management) as well asquantitative assessment of real open-source systems.

4 THE HOLONIC LIFECYCLEA holon starts as an atomic one then might evolve to being com-posite. An atomic holon represents a single system that providesone or more functionalities. A composite holon includes functionali-ties provided by a number of systems interacting with each othereither directly or through others. In order for holons to compose,atomic holons need to be comprehensively specified by the systemdeveloper. After that, the system will be dynamically constructedas the holons iterate in their lifecycle. The four stages of a holon’slifecycle (Fig. 2) are outlined below.

Run Time(Section 6)

Design Time(Section 5)

Specification Dissemination

Compilation

Modification

Figure 2: A holon’s lifecycle

Specification. A system developer uses an ontology to createthe holon from a number of elementary descriptions. This includesa holon identifier, the physical properties of the system (e.g., powerlevel), quality of service (e.g., availability and reliability), environ-mental properties (e.g., location), policies (e.g., routing protocol),services (e.g., sensing temperature), among others. All these arespecified using our ontological model, described in §5.

Dissemination. A created holon disseminates its specificationso it can be discovered. Different dissemination strategies can beadopted: push, pull, and lookup. In the push strategy, the holonperiodically broadcasts its latest description. In contrast, a pullstrategy uses heartbeat signals; i.e., the holon periodically sends‘Hello’ messages to establish interaction with other systems, whichcould then request the full holon description. This strategy reducesoverhead, so is useful in energy-constrained environments. In thelookup strategy, the holon registers its description with a registrythat can be consulted by other systems to obtain the holon. Thisstrategy is to be used when infrastructure assistance is guaranteed.We adopt the push strategy for the scope of this paper.

Compilation. This aims at understanding other holons andtheir functionalities. This is achieved by parsing received descrip-tions (in the form of XML representations), and identifying thefunctionalities contained within, and how they interact with that ofthe received holon. Compiling these functionalities into one holonrepresenting a new SoS comprising of the interacting holons.

Modification. Holons can change at runtime due to a change inthe physical system (e.g., update of a service) or due to a structuralchange (e.g., composition to a new holon). In either case, the holondescription will be modified to reflect the change. Upon obtaininga modified version of a holon, the receiving holon will recompileits own holon and disseminate it. This will convey the changes tothe whole SoS.

5 THE ONTOLOGICAL MODEL5.1 BackgroundFor a holon to be able to compose with another holon at runtime, itneeds to advertise its own definition in a systematic way that canbe easily understood by the receiving holon. For this, the definitionneeds to embody the different concepts surrounding the holon,triggering the need for an appropriate structure to represent it. Inthis respect, an ontology seems to be the best technique to capturethe definition and behavior of a holon. An ontology is a formal andexplicit specification of a shared conceptualization. It models someaspect of the world (called a domain), and provides a simplifiedview of certain phenomena in this domain. The description of thedomain is based on a vocabulary that explicitly defines its concepts,properties, relations, functions, and constraints.

For our purposes, the ontology will be used by a holon to ad-vertise its services, the types of input parameters required for saidservices, and the types of outputs they produce, if any. Furthermore,the ontology is used to identify the physical properties of the holonsuch as the power level (infinite/finite), location, operating system,mobility, etc.

Whilst an entirely new ontology can be developed from scratch,we deemed it more constructive to look at existing ontologies andextend suitable ones, i.e., the ones that contain the semantics re-quired to describe holons, if and where necessary. In order to iden-tify the most appropriate ontology to represent holons, we looked atdifferent sensor and observation ontologies. We started with thosesurveyed by the W3C Semantic Sensor Network (SSN) IncubatorGroup [39]1, and continued with our own study of others. Table 1shows the main ontologies that we reviewed.

Based on this investigation, the ontologies that we found suit-able for extension are (in chronological order): CoDAMOS, Swamo,A3ME, and Ontonym. We concluded to use CoDAMOS [31] dueto its inherent predisposition for modification, making it easilyextensible for defining context-aware computing infrastructuresvarying from small embedded devices to high-end service platforms.Furthermore, CoDAMOS’s concepts closely match the kind of def-initions we want to create for a holon. For example, the Serviceconcept - i.e., having a service profile - can be used to define the

1It should be noted that we did not specifically opt for the SSN ontology – despite itbeing a complete ontology about sensors and their measurements – as our focus is notlimited to a sensor-based system, but is rather more on capturing the abstract natureof a holon and on how to reason over whether a holon is atomic or composite.

SEAMS 2020, May 25–26, 2020, Seoul, South Korea A. Elhabbash et al.

Table 1: Survey of existing sensor-based ontologies

Ontology Comments on Suitability Suitable?CoDAMOS Easily extended to accommodate new

definitions of devices and systems✓

OntoSensor The organization of concepts and propertiesis not transferable to a different context

✕

MMI Not well tested in other contexts ✕

SensorML Basic and without concept documentation ✕

O&M Expressive representations of time andspace are not available

✕

Swamo Describes autonomous agents forsystem-wide resource sharing, distributeddecision-making and autonomic operations

✓

SDO Not available for use ✕

A3ME Can be easily extended ✓

Ontonym A set of ontologies for representing corepervasive computing concepts

✓

Sensei Some properties are not completely defined ✕

types of services provided or required by a holon. Note, however,that this does not imply that the other shortlisted ontologies cannotbe used. Indeed, A3ME [13] (to pick just one other ontology) couldbe merged with CoDAMOS to describe further concepts related toholonic design; for instance, the APIPublic CoDAMOS concept canbe further described asGlobalAddress, LocalAddress, orOtherAddressusing the Address concept of A3ME.

For this paper, we use CoDAMOS as the basis ontology with theaim of answering our research questions (§3), and in particular RQ1:is it possible to define something as abstract as a holon using anontology, which is inherently prescriptive and unambiguous?

5.2 ExtensionsAmong its various concepts, there are four basic CoDAMOS con-cepts that stand out in terms of designing holons: User, Environment,Platform, and Service. The User concept has a profile, a role, anda task. The task can have activities and/or uses a service. The En-vironment concept defines a location (relative or absolute), a time,and an environmental condition (e.g., temperature, pressure, hu-midity, lighting, noise). The Platform concept has an Environmentand can provide a Service (used by User). The Service concept has aprofile, a model, and grounding. A Software concept links to Servicethrough a property called providesService, and can be differentiatedas middleware, VM, or OS. The Task concept makes use of a Service.Other resources such as memory, network, power or storage canalso be modeled accordingly.

Fig. 3 summarizes how we extended CoDAMOS to accommodatethe requirements of a holon. The Profile is extended to show profilepreferences for routing messages in a system such as Ordering,Reliability and Delay. A new concept Node is added to capture thetypes of nodes encountered in a system: physical and abstract. Thisallows systems to be organized in a hierarchical way with physicalsystems at the very bottom of the hierarchy as leaf holons, andabstract systems as their parents, and so on till a root holon atthe very top. All of these are added as concepts under the Holonconcept. Furthermore, Service Properties has been extended toaccommodate routing properties such as Delay, Reliability andOrdering. For implementing these extensions we used Protégé [25],an open-source ontology editor.

Figure 3: Our extensions to the CoDAMOS ontology, en-abling the representation of holons to form SoSs

5.3 ApplicationFor demonstration, we show how two holons can be composedusing their underlying description. As such, the starting point iswhere each holon defines itself using the ontology: its properties,the services it provides, and the parameters being used. Thesedescriptions are broadcasted by each respective holon.

On receiving such broadcast, holons will compose with eachother if they meet the criteria for composition, for instance: ifa holon H1 is requiring a service X , and it encounters anotherholon H2 that is providing such service, then H1 can initiate thecomposition procedure withH2. OnceH1 gets composed withH2, itneeds to update its definition to reflect its new state as a composedholon, i.e., a SoS, that is now providing service X . This update iscarried out at runtime through creating an instance of the holonconcept (called, say, H3) to represent the new holon that has beenencountered, and it also holds the definition of H2 in this case.

Moreover, the ontology retains the ability to infer new knowl-edge based on the domain information provided. For example, thereis a defined concept called composedHolon that is used to identifywhether a holon is a simple or composed one. In this context, giventhat a holon has been composed to another holon, the ontologyreasoner can determine whether this holon is a composed one. IfH2 gets out of reach, then the ontology of the composed H1 will beupdated to accommodate this change, simply by removing the H3instance and clearing composedHolon.

6 SOS CONSTRUCTION MODELThis section provides the mechanics of using holonic ontologies inorder to reason about their composition to form a SoS at runtime.At a high level, our approach is first to transform a holon to berepresented as weighted tree that reflects its interaction with otherholons. Then, upon receiving a request for a service, the tree isused to find through which holon the service can be accessed. Thissection also presents the architecture that realizes the approach.

6.1 Composition modelEach holon needs to build a model that represents its awarenessabout the existence of other holons (i.e., systems) and their ser-vices. This model (called the composition model) is used to interact(compose) with the other systems by accessing their services. Thecomposition model of a holon is represented as a weighted treeT rooted by the holon and with a depth of three. The childrenof the root are the holons that are directly reachable by the rootholon. The leaf nodes represent the detected functionalities thatare provided by or accessed through the children holons. Each leafnode i is assigned a weight that represents the cost of accessing

An Ontological Architecture for Principled and Automated System of Systems Composition SEAMS 2020, May 25–26, 2020, Seoul, South Korea

the corresponding functionality Fi . For simplicity, in this paperwe define the cost as the distance between the root and the holonproviding Fi in terms of the number of intermediate holons. Othercost functions such as delay, reliability or aggregated Quality ofService (QoS) can also be used. It is worth mentioning that a holonis not aware where a functionality Fi is located. However, the holonis aware of the cost of accessing Fi and through which holon can Fibe accessed. Fig. 4 shows an example of a holon connected to threeother holons in its neighborhood. Functionality F2 can be reachedthrough both H1 and H2, but it is less costly to access through H1.

Figure 4: Composition/interaction modeling example.

The compositionmodel is frequently updated during the lifecycleof the holon. Updates include adding/removing new holon branches,and updating the services of current ones. Adding and updatingare performed upon receiving holon ontologies, while removingis carried out if the ontology is not received during a certain timeperiod (we set this to be three times the dissemination period).

6.2 Reasoning architectureWe assume that a system developer will create the atomic holonusing the ontology described in §5. Once deployed, the holon livesin the described lifecycle (§4). Fig. 5 offers a high level view ofthe architecture that realizes SoS construction using the holonicapproach. The architecture consists of five main components.

Figure 5: System architecture

OWL parser. This component receives ontologies from sur-rounding holons and parses them, creating objects that representeach holon and its functionalities. We adopt OWLAPI V5.1 [15] toparse ontologies and extract the knowledge therein.

Fig. 6 displays an overview of the mapping of ontology elementsto a holon object. For each Class element, a Java class is created torepresent it. For example, a Java class Service represents the ontol-ogy Service concept, Profile represents the Pro f ile concept, andso on. The Instance elements of the ontology are instances of theClass elements. The instances are linked together using DataTypeor Object properties. Such structure is mapped as attribute objectsof the Holon object. For example, assume the ontology contains anelement servicei that is an element of class Service . This instance

Figure 6: The relationship between main ontology elementsand those of a holon.

can be linked to the Holon concept using an object property ele-ment called hasService . In the Java Holon class, this is mapped byhaving an attribute called service_i of type Service in the Holonclass. Finally, in the ontologyValue elements represent some of theparameters values that are mapped as attribute values of the HolonJava objects. An example is the value ‘25°C’ of theTemperature ele-ment which is assigned to the temperature attribute in the HolonJava object. The OWL parser then passes the created Holon objectto the Compiler.

Compiler. This component formulates a notional model of thedeveloping SoS as seen from the perspective of the receiving holon.This model takes the form of a tree data structure with the receiv-ing holon at the root, with each branch representing a neighboringholon and the functionalities provided either natively by it or in-directly through it. To construct or modify the tree, the Compilercreates a tree branch that represents the received holon object andits provided functionalists as children. The cost of each functional-ity is also updated as this stage. After that, the newly formed branchis attached to the root holon as a child. The Compiler then passesthe constructed tree to the Server/Mediator and OWLRenderer.

Server/Mediator. This component receives requests for thefunctionalities provided by the system and serves them. It usesthe constructed holon tree to specify whether the request can besatisfied by the system or needs to be directed to another holon.If the requested functionality is provided by the holon, then thesystem processes the request and responds to the requester. Other-wise, the system acts as a mediator and redirects the request to theholon that provides the request, waits for the response, and passesback the response to the requester.

OWLRenderer. What this component fundamentally does isrepresent the knowledge of a developing SoS based on interactionwith new holons. The OWLRenderer reads the holon tree datastructure from the Compiler and converts each node and the corre-sponding attributes into the appropriate XML tags that constructa valid ontology (i.e., an inverse mapping of Fig. 6). To render theontology into an OWL description, we also use OWLAPI.

Disseminator. Upon receiving an OWL description represent-ing the holon and the compositions with other holons, the Dissemi-nator publishes this description by broadcasting it – as is the policyin the Push strategy (see §4).

7 CASE STUDY I: AUTONOMIC SMART HOMEIn this case study, we focus on the ontology exchange betweenholons to realize SoS logic. The experimental context here is thatof a smart home application that emerges as a SoS constituting anumber of disparate IoT deployments.

SEAMS 2020, May 25–26, 2020, Seoul, South Korea A. Elhabbash et al.

7.1 Background and challengesSmart Home is an application of IoT that promises the ability forusers to intelligently manage their homes with minimum interven-tion. Devices are utilized to monitor home conditions (e.g., temper-ature, humidity) and the state of appliances (e.g., battery levels) toenable smart management of energy consumption, security, andvarious house keeping functions. However, it is no longer realisticto assume a defined and small scale of smart home deployments. Assmart home systems are increasing in popularity, the dimensional-ity of IoT devices used is increasing as new devices are constantlyoffered in the market and with increased capabilities [40]. Thus,their deployment environments are continually evolving [38], mak-ing self-adaptation a necessity [16, 24].

Furthermore, homogeneity cannot be taken for granted [41]. Thefact that these devices are developed by various vendors means thatheterogeneous technologies and APIs exist. Smart home applicationdevelopers need to learn these various technologies and APIs inorder to develop IoT applications that manage the different aspectsof a smart home in a coherent manner.

Finally, IoT applications generally limit consumers to the prede-termined deployment environments they were designed for [27].Consequently, they are brittle and susceptible to suboptimal op-eration when their context changes, e.g., due to a backhaul net-work fault or a server outage. Under such conditions, centralized(mainly cloud-based) approaches fall short especially in network-constrained conditions [8]. Instead, IoT applications often need away to be able to adapt at the edge without preparation or centralcoordination.

7.2 Overview of our approachIn this case study, we illustrate how the adoption of our ontology-based approach helps to significantly mitigate the mentioned com-plexity. Building on the approach of integrating web services withthe IoT technology to enable remote access of data gathered by theIoT devices (e.g., [33]), we argue that our approach enables the auto-matic discovery of services that are required for an adaptive smarthome management application. As in the web service compositioncase, application developers need to specify the abstract workflowof the application execution where each task in the workflow rep-resents an abstract service. Then, concrete implementations of theabstract services are selected for the workflow realization.

We consider each device as a holon that is described using theontology (probably by the vendor). The management applicationis also considered as a holon that receives other holon ontologies,parses and compiles them, and then uses their services. Applicationdevelopers specify the abstract workflow of the smart home man-agement application. Then, the Server/Mediator component selectsthe concrete services that implement the abstract services of theworkflow. A concrete workflow (the application) is passed to anexecution unit that executes the application and passes the resultsto the smart home actuators. Fig. 7 illustrates the above steps.

7.3 Experimental setupWe developed a proof of concept prototype focused on smart hometemperature management. We assume a smart home that has the

Figure 7: Smart Home Controller

Figure 8: Object properties of the device ontologies.

Figure 9: Prototype workflow

following smart devices: heaters, thermometers, windows, and afridge. The devices provide the services listed in Table 2.

Table 2: Smart home devices and services.

Device Service DescriptionWindow openWindows Opens the windows (by actuators)

closeWindows Closes the windows (by actuators)Thermometer getTemeprature Returns the home temperatureHeater switchHeaterOn Switches on the heating

switchHeaterOff Switches off the heatinggetStatus Returns true if the heating is on

Fridge replaceFilter Tells if the filter should be replacedfoodLevelLow Returns true if food level is low

We created a simple ontology for each of the devices as shownin Fig. 8. We also created an abstract workflow that aims at keepingthe smart home temperature at 22°C, which is depicted in Fig. 9. Theapplication reads the temperature from the thermometers. If thetemperature is less than 22°C, it calls the heaters’ switchHeaterOnservice to switch on the heating and the windows’ closeWindows toclose thewindows. If the temperature is higher than 22°C, it turns offthe heater (calling switchHeaterOff). If the temperature is higherthan 22°C it also opens the windows (by calling openWindows).

7.4 BehaviorFig. 10 shows a snapshot of the controller ontology after parsingthe device ontologies and constructing the SoS tree. The ontology

An Ontological Architecture for Principled and Automated System of Systems Composition SEAMS 2020, May 25–26, 2020, Seoul, South Korea

Figure 10: Object properties of the controller ontology

Table 3: Experimental cases of the workflow in Fig. 9

Temp. Invoked Services10°C getTemperature→ switchHeaterOn→ closeWindows18°C getTemperature→ switchHeaterOn→ closeWindows22°C getTemperature→ switchHeaterOff → closeWindows23°C getTemperature→ switchHeaterOff → closeWindows26°C getTemperature→ switchHeaterOff → openWindows

shows that the controller provides services that are provided by thedevices themselves (see Fig. 8) in addition to servicesSelector,which selects concrete services for the abstract workflow.

The execution starts with reading the temperature from the ther-mometer by calling the getTemeprature service. Table 3 presentsthe experimental cases and the invoked cases for each case. As thetable illustrates, the sequence of invoked services complies withthe abstract workflow provided by the developer to the controller,despite the developer not hard-coding the required connectionsbetween devices. For example, when the temperature is 22°C, theexecution unit invokes the getTemperature, switchHeaterOff,and closeWindows services respectively, which complies with theabstract workflow (Fig. 9).

This case study demonstrates the potential for easing the devel-opment of IoT applications, where application developers do notneed to know the details of smart device APIs. Definition of deviceontologies (by vendors) and an abstract application workflow (bysmart home developer) are sufficient for runtime application syn-thesis and execution by the proposed architecture. Table 4 comparesthe tasks required from the smart home developers to implementthis case study in both the classical and holonic approaches.

Table 4: Tasks required from developers to implement thesmart home case study.

Classical approach Holonic approach

1. Understand the services, APIs, and proper-ties of the devices listed in Table 2.

2. Design the composition of services basedon required functionality and context.

3. Develop code to compose the services.4. Deploy the system.

1. Define the abstractworkflow of the re-quired functionality onthe controller.

2. Deploy the deviceslisted in Table 2.

8 CASE STUDY II: DYNAMIC CLUSTERMANAGEMENT

In this case study we center our attention on holon interaction. Wedemonstrate how holons of similar ontologies (i.e., containing thesame services) and that are in constant movement can interact with

each other despite continuous creation and modification of newSoSs. Our context here is cluster management using Apache Mesos.

8.1 Background and challengesInspired by heterogeneous fog clusters, we set a scenario wheredevice interaction is constant.We use ApacheMesos [14], an orches-tration tool commonly used to manage resources that are sharedbetween different applications and their sub-tasks. In effect, Mesosenables the viewing of data centers and other computing clustersas a single consolidated resource.

Although Mesos is a very useful utility, it was designed mainlyfor shared resources in relatively stable environments such as datacenters. As such, the computing cluster can only change (i.e., growor shrink) through manual modifications to the configuration bythe user. Mesos was not designed to work in an environment wherenode status is constant flux due to movement, unreliable power,or communication outages. These are typical challenges in fogcomputing [35, 37]. Mesos is also designed to work in a hierarchicalfashion, whereby Agents (worker nodes) can only communicatedirectly to the Master but not through other Agents [14, 17].

8.2 Overview of our approachBoth of the above restrictions can be overcome using the holonicontology, which offers opportunistic composition (overcoming thefirst restriction) and horizontal composition between self-describingclusters in the form of holons (second restriction). We draw a sce-nario here to demonstrate this using containers running over anunreliable infrastructure such as edge PoPs [9]. In this scenario,each node can be a Master or an Agent. Following the basic designof Mesos, Masters are responsible for dispatching containers to theAgents, who in turn operate the containers.

8.3 Experimental setupA simple example is given here to illustrate how holons could beused to facilitate the union of Mesos clusters with mobile nodeswithout the need for establishing direct communication. Due to thehigh mobility of nodes during the tests, the composition of SoSsis dynamic, creating several additions and removals of the MesosServices. This is something that would have been prohibitive toaccomplish using Mesos’ manual configuration.

We tested this use case study using 100 devices that can movefreely. Every device is considered a node for Mesos and is individu-ally defined as a holon at the beginning of the experiment. Shortlyafterwards (a minute later), bigger holons begin to be created, con-taining one or more devices. After that, each holon starts an internalprocess of randomized leader election [26] to elect a master fromamongst the constituent devices.

Each holon contains parameters to define its identifier, mobility,and whether or not it is a Mesos Master (e.g., Fig. 11). Additionally,each holon contains three services: AskForMaster is performedevery time two holons reach each other for the first time, whereit would return the ID of the Master. After a holon receives therequest of whom is its Master, it will perform the SendMasterservice to send such ID. BridgeToMaster is used by the nodes tocommunicate with the Master through its Agents. Fig. 12 showsan abstract workflow of the experiment when a node reaches a

SEAMS 2020, May 25–26, 2020, Seoul, South Korea A. Elhabbash et al.

hasParameter NodeA-mobility

providesService NodeA-AskForMaster

providesService NodeA-SendMaster

providesService NodeA-BridgeToMaster

Property assertions: NodeA

Object property assertions

NodeA

hasParameter NodeA-id

hasParameter NodeA-isMaster

Figure 11: The ontology model of Mesos NodeA.

Figure 12: Prototype workflow of Dynamic Cluster Manage-ment when a node reach another node.

Figure 13: Prototype workflow of Dynamic Cluster Manage-ment when a node receive a new ontology.

new node from another Mesos cluster. A second abstract workflowhas been created when a node receives a new ontology, which isdepicted in Fig. 13. Both abstract workflows are used by the nodesto allow dynamic union of Mesos clusters with mobile nodes.

8.4 BehaviorFig. 14a presents the starting point with holons H1 and H2. H1 isformed of four nodes: nodeA, working as a Master, while nodeB,nodeC and nodeD as Agents. On the other hand, H2 is formed oftwo nodes: nodeF, a Master, and nodeE, an Agent. In this case, H1and H2 cannot reach each other.

As nodeC and nodeE come in range of one another (Fig. 14b),they are triggered to exchange ontologies and call AskForMasterand subsequently SendMaster. The orange arrow in the figurerepresents this interaction.

Then, nodeC and nodeE broadcast their new ontologies to neigh-bors (Fig. 14c). Now, H1 and H2 are not just in contact with eachother, they are part of a new super-holon H3, which is the unionof H1 and H2 as all their nodes receive the updated ontology andadopt it as their new ontology.

NodeA-Master NodeF-Master

NodeB-Agent NodeC-Agent

NodeD-Agent

NodeE-Agent

H1H2

(a) H1 is unreachable from H2

NodeF-MasterNodeE-Agent

H1

H2

NodeA-Master

NodeB-Agent NodeC-Agent

NodeD-Agent

(b) C and E come in range, interact

H1

H2

NodeF-MasterNodeE-Agent

NodeA-Master

NodeB-Agent NodeC-Agent

NodeD-Agent

(c) Ontologies exchanged & updated

H3H1

H2

NodeF-MasterNodeE-Agent

NodeA-Master

NodeB-Agent NodeC-Agent

NodeD-Agent

(d) A SoS, H3, is created

Figure 14: How to use holons to construct a SoS of Mesosclusters running on constantly moving nodes.

Table 5: Tasks required from Mesos developers to imple-ment the dynamic cluster management case study.

Classical approach Holonic approachRepeatedly:

1. Select a cluster Master.2. Add nodes to cluster.3. Add services to cluster.4. Remove nodes from cluster.5. Remove services from cluster.

1. Define the cluster node as aholon using the ontology.

2. Implement the cluster Masterelection algorithm.

3. Deploy the holons.

All Agents are sharing the Masters nodeA (from H1) and nodeF(from H2). This is achieved using the service BridgeToMaster, per-formed continuously by nodeC and nodeE while they can reacheach other. The resulting SoS H3 has 2 Master nodes and 4 Agents.Therefore, each of the two Masters can communicate to all Agentsin H3 as if they were connected directly. Similarly, this approach isalso able to deal with Master mobility as long as the basic structureof a Mesos cluster is not broken down.

As such, the ontological exchange and reasoning of holons al-lows ApacheMesos to transcend its innate design shortcomings andenables it to form a dynamic cluster structure. Achieving such struc-ture through manual configuration (which is the only way possibleusing native Mesos) significantly restricts adaptation and reducescluster efficiency by a factor of 5 compared to using holons. Table 5compares the tasks required from Mesos developers to implementthis case study in both the classical and proposed approaches.

8.5 SimulationsFor evaluating the efficacy of automated expansion of Mesos clus-ters through the use of holon ontologies, we used the Omnet++discrete-event simulation framework [36] to simulate 100 nodes.Weset the node transmission range to 20m and their speed to 1.43m/s ,an average walking speed [20]. Additionally, the nodes used theindividual-level (random walks) [4] as a mobility model.

We used Mesosaurus [22] to create task loads to test the perfor-mance of the formed clusters. Specifically, we seek the length of

An Ontological Architecture for Principled and Automated System of Systems Composition SEAMS 2020, May 25–26, 2020, Seoul, South Korea

0 20 40 60 80 100Simulation time (min)

0

5

10

15

20

25

30

Task

exe

cutio

n tim

e (s

)

Automatic configuration using holonsNative configuration (with scripts)

Figure 15: Computational tasks are completed faster on dy-namic Mesos clusters constructed using holons as opposedto native Mesos cluster configurations.

time required by a Mesos Master to perform a specific task. Thetask created for this experiment is one that a Master with 5 Agentswill normally perform in about 20 seconds. If more Agents areemployed, execution time is expected to decrease.

Fig. 15 plots the average task execution time across all Mesos clus-ters after 20 experiment runs. Using Mesos’ native cluster manage-ment method, task execution time decreases slightly (from ≈ 23s)as Masters expand their clusters through the use of scripts thatadd nodes they encounter in their environment. This improvementin performance, however, eventually plateaus (≈ 20s) as churnoverwhelms Masters through frequent configuration management,despite the use of automated scripts. On the other hand, usingholons introduces some overhead in terms of ontology creation andreasoning. This results in a slightly inflated initial execution time(≈ 27s). However, as nodes encounter others during the lifetime ofthe simulation, Mesos clusters identifying as holons expand dynam-ically according to changes in their environment. Compiling andreasoning overheads soon become relatively insignificant, enablingMesos holons to achieve an average of 17s execution time, a 15%improvement in performance.

9 DISCUSSION OF CASE STUDIESThe above experiments show how we are able to automatically self-discover and compose systems through rich ontological descriptionof elementary systems that are required to realize a SoS. We nowreflect on the research questions we formulated in §3.

9.1 Abstractions for SoS representationHolons offer the ability for systems to richly describe themselves,and independently reason about the change in their environmentand how it might affect their set up and operation. This conceptenables systems to reflect on their existence and how they fit intowhat is around them. This in line with the ethos of reflective mid-dleware [19], which enables systems to build a representation ofitself that it can then adapt. In addition, holonic representation al-lows systems to transfer such knowledge about themselves to othersystems they get in touch with. Along with this, each system is ableto build a representation of the behavior of systems in its vicinityand form more complex systems without prior arrangement.

There is an assumption that each system needs to start with arepresentation of itself in its simplest form as an ontology. Becauseof this, we built our ontological architecture on the most generalizeand easy-to-use ontology available in the literature. Furthermore,using such framework makes it easy to create ontologies, which isa relatively small development overhead of similar or less scale ofdefining a system’s API. However, this enables the system to adaptafter its deployment and unlock a new world of complex systemcreation that facilitates new forms of context-aware applications.

9.2 Techniques for SoS compositionThe presented case studies demonstrated how a developer coulddefine desired behavior at a high level (summarized in Tables 4–5), and a system is subsequently composed of other sub-systemsto align with this behavior. Our architecture allows systems toindependently reason about their environment, and how changesmight affect their set up and operation. This is a powerful conceptas it maintains the separation of concerns, which is crucial foreffective system development, whilst also reaping the rewards ofcomplex system formation through autonomous composition.

Furthermore, the holonic ontology could be applied at differentlevels: at the atomic service level (e.g., temperature sensor), at asystem component level (e.g., smart sensors), or at a higher systemlevel (e.g., smart home controller). This enables developers to writebehavior at different levels of granularity with the same modelingeffort, which is especially beneficial for dynamic environments suchas the IoT where context-dependent behavior could be sought atdifferent levels.

9.3 SoS adaptationThe presented architecture exploits the holonic ontology and main-tains the holonic lifecycle to fully support the vision of autonomousSoS composition and adaptation presented in this paper. The archi-tecture continuously updates the holonic ontology allowing up-to-date SoS state exchange and enables timely response to changes.This allows holons to detect failures and discover new functionali-ties a holon needs to rebuild a SoS. As demonstrated in the clustermanagement case study (§8), adaptation is fully autonomous. Thesystem can, for example, detect the arrival of new working nodesand add them to the cluster.

Furthermore, human involvement is only needed when majorrequirements changes are required, i.e., at the SoS level. For exam-ple, a change in the smart home requirements that demands thedeployment of new devices might require updating the behaviorof the smart home applications, i.e., developers need to adapt theabstract workflows. However, such intervention is guaranteed tobe minimal as developers do not need to know the low-level detailsof post-deployment systems such as device-specific APIs. There-fore, our proposed architecture provides a generic framework forsupporting high-level behavior adaptation to real implementation.

10 QUANTITATIVE EVALUATIONAs mentioned, our proposed framework includes means of parsingholon ontologies to build a tree that represents SoS construction,and subsequently rendering the tree to disseminate the modifiedontologies that reflect SoS evolution. We conducted experiments to

SEAMS 2020, May 25–26, 2020, Seoul, South Korea A. Elhabbash et al.

(a) Parsing time (b) Rendering time

Figure 16: (a) Ontology parsing time as the number of ser-vices per holon increases. (b) Rendering time for holons ofincreasing size (and, thus, ontology complexity) as the num-ber of holons increases.

evaluate the feasibility and correctness of this approach. Specifically,we investigate the time required to parse and render the ontologiesat different scales, and we assess the validity of these stages. Fromthis, we extract conclusions about the ability of using holons tocompose SoS during runtime and at scale. The platform used inthe experiments is Intel Core i7 with 16GB RAM, running LinuxUbuntu 16.04 and Java SE v1.8.0. Results shown are the mean valuesfrom 100 experiment repetitions.

10.1 ParsingThis first experiment focuses on evaluating the parsing time definedas the time of converting a received ontology into a tree (§6). Recallthat that the tree contains the holon object as a root and the servicesprovided by/via it as children. So, we vary the number of children(i.e., services) as the main dimension affecting parsing scalability.In Fig. 16a, we observe that parsing time increases linearly withthe number of services, amounting to < 0.35s for a very complexSoS that provides 1,000 services either directly or indirectly. Wefind this level of complexity to be acceptable, as it indicates thefeasibility of parsing an increasing number of holons in a SoS.

10.2 RenderingWe now evaluate the rendering time defined as the time to converta holon tree into an ontology to be disseminated. We vary both thenumber of neighbor holons (children) and the number of their ser-vices (leaves). The plot in Fig. 16b demonstrates that the renderingoverhead increases both with the number of holons and the numberof services per holon. This is acceptable for SoSs with up to 100services per holon, where rendering overhead is ≈ 5s . However thisquickly inflates for holons with 1,000 or more sub-systems, whereit could take up to a minute to create an ontology that could beused for composition.

10.3 ValidationIn this subsection, we validate the output of the parsing and ren-dering operations using two experiments.

In the first experiment we adopt the process depicted in Fig. 17a.We create ontologies for 100 holons with random values for eachof their parameter and service values. We then pass the ontologyfiles to the OWLParser, which creates the holon trees. The trees arethen passed to the OWLRenderer to render them into ontologies.

Figure 17: Our twomethods to validate ontology parsing andrendering experiments. Parsing and rendering are deemedvalid when the information returned by the queries match.

We then query (using OWLAPI) both the created ontologies andthe rendered ones to check if the results are equivalent. For all 100ontologies, the returned values were indeed equivalent.

In the second experiment, we adopt the process portrayed inFig. 17b. Here, we synthesized 100 compiled trees, each representinga SoS. We then passed the trees to the OWLRenderer to render theminto a SoS ontology for each tree. Thenwe queried both the renderedontologies and the created trees to compare the results. Again, forall of the 100 cases, the returned values were equal.

11 CONCLUSIONWe propose an approach for the dynamic construction of distributedsystems of systems (SoSs). The approach is based on two key ideas.First, we define the concept of a holon as a self-describing sys-tem, which could span from atomic to complex distributed sys-tems. Holons need to be prepared for autonomic integration withother holons. This is achieved by comprehensively describing themusing an ontology that enables both self-awareness and context-awareness. Second, an architecture for SoS construction is proposedto make use of the holon description to discover, reason about theirfunctionalities, and integrate them to form more complex SoS.

We demonstrate the feasibility of our approach through twocase studies that implement contrasting SoS construction scenarios.The cases studies show that our approach reduces the developmentcomplexity of SoS by abstracting system heterogeneity using holondescriptions and their autonomic manipulation at runtime. We alsoevaluate scalability and validity through experimentation, conclud-ing that our approach is realistically feasible with performanceexhibiting a linear trend for manipulating and reasoning aboutdescriptions.

This novel contribution has strong potential to be applied invarious application fields beyond those covered in our case studies.Similarly, our architecture could be modified to cater for domain-specific interactions if particular situational-awareness are needed.Moreover, we are extending this work by building tools that allowvery high level specification of desired SoS construction behaviorand evolution.

12 ACKNOWLEDGMENTSThis work was supported by CHIST-ERA under UK EPSRC grantEP/M015734/1 (DIONASYS).

An Ontological Architecture for Principled and Automated System of Systems Composition SEAMS 2020, May 25–26, 2020, Seoul, South Korea

REFERENCES[1] R. Agarwal, D. G. Fernandez, T. Elsaleh, A. Gyrard, J. Lanza, L. Sanchez, N.

Georgantas, and V. Issarny. 2016. Unified IoT ontology to enable interoperabilityand federation of testbeds. In World Forum on Internet of Things (WF-IoT). 70–75.https://doi.org/10.1109/WF-IoT.2016.7845470

[2] Muhammad Intizar Ali, Pankesh Patel, Soumya Kanti Datta, and Amelie Gyrard.2017. Multi-Layer Cross Domain Reasoning over Distributed Autonomous IoTApplications. Open Journal of Internet Of Things (OJIOT) 3, 1 (2017), 75–90.

[3] R. R. Aschoff and A. Zisman. 2012. Proactive adaptation of service composition.In Symposium on Software Engineering for Adaptive and Self-Managing Systems(SEAMS). ACM, 1–10. https://doi.org/10.1109/SEAMS.2012.6224385

[4] Hugo Barbosa, Marc Barthelemy, Gourab Ghoshal, Charlotte R James, MaximeLenormand, Thomas Louail, Ronaldo Menezes, José J Ramasco, Filippo Simini,and Marcello Tomasini. 2018. Human mobility: Models and applications. PhysicsReports (2018).

[5] Luciano Baresi and Liliana Pasquale. 2010. Live Goals for Adaptive Service Com-positions. InWorkshop on Software Engineering for Adaptive and Self-ManagingSystems (SEAMS). ACM, 114–123. https://doi.org/10.1145/1808984.1808997

[6] Gordon S Blair, Yérom-David Bromberg, Geoff Coulson, Yehia Elkhatib, Lau-rent Réveillère, Heverson B. Ribeiro, Etienne Rivière, and François Taïani. 2015.Holons: Towards a Systematic Approach to Composing Systems of Systems.In Workshop on Adaptive and Reflective Middleware (ARM). Article 5, 6 pages.https://doi.org/10.1145/2834965.2834970

[7] Abdessalam Elhabbash, Gordon S. Blair, Gareth Tyson, and Yehia Elkhatib. 2018.Adaptive Service Deployment using In-Network Mediation. In InternationalConference on Network and Service Management (CNSM). 170–176.

[8] Yehia Elkhatib. 2015. Building Cloud Applications for Challenged Networks. InEmbracing Global Computing in Emerging Economies, Ross Horne (Ed.). Commu-nications in Computer and Information Science, Vol. 514. Springer InternationalPublishing, 1–10. https://doi.org/10.1007/978-3-319-25043-4_1

[9] Yehia Elkhatib, Barry F. Porter, Heverson B. Ribeiro, Mohamed Faten Zhani,Junaid Qadir, and Etienne Rivière. 2017. On Using Micro-Clouds to Deliver theFog. Internet Computing 21, 2 (2017), 8–15. https://doi.org/10.1109/MIC.2017.35

[10] Dieter Fensel. 2001. Ontologies: A Silver Bullet for Knowledge Management andElectronic Commerce. Springer.

[11] Gábor Fodor, Erik Dahlman, Gunnar Mildh, Stefan Parkvall, Norbert Reider,György" Miklós, and Zoltán’ Turányi. 2012. Design aspects of network assisteddevice-to-device communications. IEEE Communications Magazine 50, 3 (March2012), 170–177.

[12] M. G. Gillespie, H. Hlomani, D. Kotowski, and D. A. Stacey. 2011. A knowledgeidentification framework for the engineering of ontologies in system compositionprocesses. In Conference on Information Reuse Integration. 77–82. https://doi.org/10.1109/IRI.2011.6009524

[13] A. Herzog, D. Jacobi, and A. Buchmann. 2008. A3ME - An Agent-Based Middle-ware Approach for Mixed Mode Environments. In International Conference onMobile Ubiquitous Computing, Systems, Services and Technologies (UBICOMM).191–196. https://doi.org/10.1109/UBICOMM.2008.78

[14] Benjamin Hindman, Andy Konwinski, Matei Zaharia, Ali Ghodsi, Anthony DJoseph, Randy H Katz, Scott Shenker, and Ion Stoica. 2011. Mesos: A Platform forFine-Grained Resource Sharing in the Data Center.. In Symposium on NetworkedSystems Design and Implementation (NSDI). USENIX.

[15] Matthew Horridge and Sean Bechhofer. 2011. The OWL API: A Java API forOWL Ontologies. Semantic Web 2, 1 (2011), 11–21.

[16] Danny Hughes. 2018. Self Adaptive Software Systems are Essential for the Inter-net of Things. In International Symposium on Software Engineering for Adaptiveand Self-Managing Systems (SEAMS). ACM, 21–21.

[17] Dharmesh Kakadia. 2015. Apache Mesos Essentials. Packt Publishing Ltd.[18] M. Kit, I. Gerostathopoulos, T. Bures, P. Hnetynka, and F. Plasil. 2015. An Ar-

chitecture Framework for Experimentations with Self-Adaptive Cyber-physicalSystems. In Symposium on Software Engineering for Adaptive and Self-ManagingSystems (SEAMS). ACM, 93–96. https://doi.org/10.1109/SEAMS.2015.28

[19] Fabio Kon, Fabio Costa, Gordon Blair, and Roy H. Campbell. 2002. The Case forReflective Middleware. Commun. ACM 45, 6 (Jun 2002), 33–38. https://doi.org/10.1145/508448.508470

[20] Robert V Levine and Ara Norenzayan. 1999. The pace of life in 31 countries.Journal of Cross-Cultural Psychology 30, 2 (1999), 178–205.

[21] Mark W. Maier. 1998. Architecting principles for systems-of-systems. SystemsEngineering 1, 4 (1998), 267–284.

[22] Mesosphere. 2016. Mesosaurus. https://github.com/mesosphere/mesosaurus.[23] Behrokh Mokhtarpour and Jerrell Stracener. 2017. A Conceptual Methodology

for Selecting the Preferred System of Systems. IEEE Systems Journal 11, 4 (Dec2017), 1928–1934.

[24] Henry Muccini, Mohammad Sharaf, and Danny Weyns. 2016. Self-Adaptationfor Cyber-Physical Systems: A Systematic Literature Review. In Symposium onSoftware Engineering for Adaptive and Self-Managing Systems (SEAMS). ACM,75–81. https://doi.org/10.1145/2897053.2897069

[25] Mark A. Musen et al. 2015. The Protégé Project: A Look Back and a Look Forward.AI Matters 1, 4 (Jun 2015), 4–12. https://doi.org/10.1145/2757001.2757003

[26] Koji Nakano and Stephan Olariu. 2000. Randomized Leader Election Protocolsin Radio Networks with no Collision Detection. In Algorithms and Computation.Springer Berlin Heidelberg, Berlin, Heidelberg, 362–373.

[27] Anne H. Ngu, Mario Gutierrez, Vangelis Metsis, Surya Nepal, and Quan Z. Sheng.2017. IoT Middleware: A Survey on Issues and Enabling Technologies. Internet ofThings Journal 4, 1 (Feb 2017), 1–20. https://doi.org/10.1109/JIOT.2016.2615180

[28] Claus Ballegaard Nielsen, Peter Gorm Larsen, John Fitzgerald, JimWoodcock, andJan Peleska. 2015. Systems of Systems Engineering: Basic Concepts, Model-BasedTechniques, and Research Directions. Comput. Surveys 48, 2 (2015), 18:1–18:41.https://doi.org/10.1145/2794381

[29] Vatsala Nundloll, Yehia Elkhatib, Abdessalam Elhabbash, and Gordon S Blair.2020. An Ontological Framework for Opportunistic Composition of IoT Systems.In International Conference on Informatics, IoT, and Enabling Technologies (ICIoT).IEEE.

[30] Kai Petersen, Mahvish Khurum, and Lefteris Angelis. 2014. Reasons for bot-tlenecks in very large-scale system of systems development. Information andSoftware Technology 56, 10 (2014), 1403–1420. https://doi.org/10.1016/j.infsof.2014.05.004

[31] Davy Preuveneers, Jan Van den Bergh, Dennis Wagelaar, Andy Georges, PeterRigole, Tim Clerckx, Yolande Berbers, Karin Coninx, Viviane Jonckers, and KoenDe Bosschere. 2004. Towards an Extensible Context Ontology for AmbientIntelligence. In European Symposium on Ambient Intelligence. Springer, 148–159.

[32] Luca Sabatucci, Carmelo Lodato, Salvatore Lopes, and Massimo Cossentino. 2015.Highly Customizable Service Composition and Orchestration. In Service Orientedand Cloud Computing, Schahram Dustdar, Frank Leymann, and Massimo Villari(Eds.). Springer International Publishing, 156–170.

[33] M. Soliman, T. Abiodun, T. Hamouda, J. Zhou, and C. H. Lung. 2013. Smart Home:Integrating Internet of Things with Web Services and Cloud Computing. InInternational Conference on Cloud Computing Technology and Science (CloudCom),Vol. 2. IEEE, 317–320. https://doi.org/10.1109/CloudCom.2013.155

[34] Jean-Baptiste Soyez, Gildas Morvan, Rochdi Merzouki, and Daniel Dupont. 2017.Multilevel Agent-Based Modeling of System of Systems. IEEE Systems Journal11, 4 (Dec 2017), 2084–2095.

[35] Luis M. Vaquero, Felix Cuadrado, Yehia Elkhatib, Jorge Bernal-Bernabe, Satish N.Srirama, and Mohamed Faten Zhani. 2019. Research Challenges in NextgenService Orchestration. Future Generation Computer Systems 90 (Jan 2019), 20–38.https://doi.org/10.1016/j.future.2018.07.039

[36] András Varga and Rudolf Hornig. 2008. An overview of the OMNeT++ simulationenvironment. In Conference on Simulation Tools and Techniques for Communica-tions, Networks and Systems. ICST, 60.

[37] Blesson Varghese, Philipp Leitner, Suprio Ray, Kyle Chard, Adam Barker, YehiaElkhatib, Herry Herry, Cheol-Ho Hong, Jeremy Singer, Fung Po Tso, Eiko Yoneki,and Mohamed Faten Zhani. 2019. Cloud Futurology. IEEE Computer 52, 9 (Sep2019), 68–77. https://doi.org/10.1109/MC.2019.2895307

[38] Bahtijar Vogel and Dimitrios Gkouskos. 2017. An Open Architecture Approach:Towards Common Design Principles for an IoT Architecture. In European Con-ference on Software Architecture (ECSA). 85–88. https://doi.org/10.1145/3129790.3129793

[39] W3C SSN XG. 2011. Review of Sensor and Observations Ontolo-gies. https://www.w3.org/2005/Incubator/ssn/wiki/Review_of_Sensor_and_Observations_Ontologies.

[40] K. Xu, X. Wang, W. Wei, H. Song, and B. Mao. 2016. Toward software definedsmart home. IEEE Communications Magazine 54, 5 (May 2016), 116–122. https://doi.org/10.1109/MCOM.2016.7470945

[41] Ibrar Yaqoob, Ejaz Ahmed, Ibrahim A. T. Hashem, Abdelmuttlib I. A. Ahmed,Abdullah Gani, Muhammad Imran, and Mohsen Guizani. 2017. Internet of ThingsArchitecture: Recent Advances, Taxonomy, Requirements, and Open Challenges.IEEE Wireless Communications 24, 3 (2017), 10–16. https://doi.org/10.1109/MWC.2017.1600421

[42] Xinfeng Ye. 2006. Towards a Reliable Distributed Web Service Execution Engine.In International Conference on Web Services (ICWS). IEEE Computer Society,595–602. https://doi.org/10.1109/ICWS.2006.131