IoT Capabilities Composition and Decomposition: A Systematic Review

As billions of IoT devices join the Internet, researchers and innovators increasingly explore IoT capabilities achieved via service composition or reuse of existing capabilities via service decomposition. Many systematic literature reviews (SLRs) were produced on this subject; however, two issues remain to be addressed: i) a reference taxonomy of the different aspects of IoT capabilities composition and decomposition is needed, and ii) many formal questions (e.g., standards role, formal representations applications, state-space explosion countermeasures, etc.), technical questions (e.g., composition process types and automation levels synergies, service decomposition categories, the role of AI/ML, etc.), and QoS questions (e.g., privacy, interoperability, and scalability challenges and solutions, etc.) remain unanswered. We introduce this work by discussing notions of IoT capabilities composition and decomposition in a layered IoT architecture while highlighting the strengths and weaknesses of existing SLRs. We identify unanswered questions through gaps in related work and motivate these questions using the PICOC methodology. We explain the search methodology and organize the topic questions using the proposed reference taxonomy. The identified research questions are answered, and trends and gaps that need additional attention from the research community are highlighted. This effort benefits city planners and end-users of IoT systems as it contributes to a better understanding of the role of composition and decomposition of IoT capabilities in building value-added services or reusing existing ones for resource optimization. For researchers, this effort contributes a reference taxonomy for the topic and sheds light on important questions while highlighting corresponding trends and gaps requiring further attention.


I. INTRODUCTION
In this section, we highlight the context and background for the IoT capabilities composition and decomposition topic (subsection I-A), define related vocabulary, concepts, and functions while explaining the relationship between these components through a layered architecture and an illustrative usecase (subsection I-B), indicate motivations and key contributions included in this effort (subsection I-C), and provide the timeline and the organization of the SLR study (subsection I-D).
The associate editor coordinating the review of this manuscript and approving it for publication was Wei-Wen Hu .

A. CONTEXT AND BACKGROUND
IoT applications bring significant opportunities for different stakeholders (end-users, developers, city planners, etc.) and in numerous smart-city domains (intelligent buildings, smart transportation, smart health, etc.). Innovating new services or reusing existing ones represents two key drivers for different stakeholders, especially developers. Developing novel services requires access to and aggregating basic sensor, service, or device data. IoT capabilities composition aggregates basic data streams from connected devices, sensors, and systems into a composite and value-added service.
An example of IoT capabilities composition is discussed in [224], where authors combined -through a composition function-basic sensor data, including temperature, humidity, VOLUME 11, 2023 This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/ air quality, and Wi-Fi signal strength, to innovate a new composite service that they defined as well-being in a smart building.
As for reusability, one service can provide input to different IoT applications or cyber-physical systems: An API for weather conditions can be leveraged and reused (or recycled) across many applications such as hiking recommendation services (when and where to hike), cyber-physical systems such as autonomous vehicles (determine a travel time and plan), employer's notification systems (send alerts to employees about telework options when weather conditions don't facilitate onsite presence). Service decomposition aims to determine basic reusable services in a complex and valueadded service.
The processes, functions, and components involved in capabilities composition or decomposition can meet formal (standards, formal specification, and verification, etc.), technical (communication, process type, automation level, etc.), or QoS (scalability, interoperability, privacy, etc.) challenges that we identify and address in this effort through the systematic literature review approach.

B. CONCEPTS AND DEFINITIONS
In this subsection, we shed light on concepts that will be mentioned throughout this effort (IoT, CPS, capabilities classification, composition and decomposition functions), provide a layered architecture that highlights the relationships between the components and functions above, and discuss all these elements through an illustrative use case for clarity.

1) INTERNET OF THINGS AND CYBER-PHYSICAL SYSTEMS
The Internet of Things (IoT) [208] is a network of devices connected through the Internet network. This network aims to allow connected devices -IoT devices-to send and receive data in a way that enables sensing and actuation and, as a result, enables innovative services in multiple domains, including health, transportation, and intelligent buildings.
Cyber-physical systems (CPS) [38] are engineered systems that integrate physical and digital components with real-time feedback and control loops. CPSs are found in many domains, such as transportation, intelligent buildings, and healthcare. CPSs rely on advanced sensors, actuators, and programs to track and control physical processes, often in sophisticated and dynamic environments. CPSs pose new challenges due to the connectivity component, exposing them to cybersecurity and privacy attacks.
IoT and CPS devices are converging concepts and have multiple synergies in terms of connectivity and compositionality; hence, we might use both expressions interchangeably as explained in [1].

2) IoT OR CPS CAPABILITIES
A capability is a feature, service, measurement (temperature, humidity, pressure, etc.), or state of an IoT or a CPS device. IoT capabilities can also refer to full-fledged complex applications provided by one or multiple devices interconnected at the network layer and orchestrated at the application layer.

3) CAPABILITIES CLASSIFICATION
Capabilities can be classified into two categories based on how their features can be measured.
i) Tangible capabilities: provide a quantitative metric, such as temperature or round-trip time [12]. Tangible capabilities are usually a characteristic of basic/atomic services such as sensors or network probes. Keeping an open mind when defining what is atomic and what is a composite service is necessary, as certain full-fledged services and applications can be defined as atomic in the context of an even more complex system.
ii) Abstract capabilities: are typically complex services not measured using traditional units. These abstract capabilities are recognized across multiple domains, including smart cities (quality of life [14]), IoT infrastructures (scalability [15]), and smart transportation systems (traffic jam prediction accuracy and driver risk level [16]). Abstract capabilities measurements are often user or programmer-defined in a way that simplifies and makes their assessment intelligible.

4) COMPOSITION AND DECOMPOSITION FUNCTIONS
IoT capabilities composition is the art of aggregating existing IoT capabilities to come up with a novel service with added value [19], whereas decomposition aims to reuse a subset of the capabilities of a complex service or distribute its computation [166]. A general diagram is provided in Figure 1, which shows how IoT capabilities are modeled, composed, or decomposed.
To formally explain the different concepts of the topic, let us consider the example of IoT capabilities Ca1, Ca2, and Ca3 and two functions, Cf , and Df , representing IoT capabilities composition and decomposition functions, respectively. Ca1, Ca2, . . . , Can the atomic capabilities that generate the composite capability Cc. Cc can be considered atomic in the context of a service or an application with a higher level of complexity. In [20], single-function components that are reusable by other city services are packaged and published as standalone components or atomic services, considered as single functional blocks that consume data and implement a feature, such as managing, enriching, or filtering input, and are similar to the concept of a microservice in terms of being a reusable, self-contained piece of software targeting a specific task. In the same effort [20], eight atomic services addressing smart city challenges in data analytics, evaluation, integration, validation, and visualization were pointed out (parking data prediction atomic service, traffic flow predictor; 2 atomic visualization services; 1 data elaboration atomic service; and 3 data transformation atomic services). Functions performed on atomic capabilities include the composition function Cf , and the decomposition functions Df , which can be synchronous [21], asynchronous [22], serial or sequential, probabilistic or alternative, parallel, circular, or cyclic [2], [23]. The success of Cf and Df requires multiple processes, including computations, filtering, ranking, composing, and verifying atomic and composite features [21].

5) A LAYERED MODEL FOR IoT CAPABILITIES COMPOSITION AND DECOMPOSITION
Researchers in [24] organized service composition into three layers: physical, virtual object, and service composition. This model represents the composition/decomposition problem because it does not include networking complexities. In [2], the authors based their composition survey on a layered architecture that also considers network and application aspects. In [25], the proposed layered approach, which represents the journey of a capability message, has three levels: i) an information level where the message parameters and temporal scope are defined; ii) a representation protocol level where the message is serialized as a JSON object and made ready for composition by a composition engine; and iii) a session layer where the composite capability is securely delivered to a client or service. A smart home composition framework was proposed in [26] and [27], which uses the Majord'home platform as SDN middleware between the data plane layer, where IoT sensors objects reside, and the service composition layer. Other layered models for the composition and decomposition of IoT capabilities were discussed in [15], [16], and [28].
Based on the efforts mentioned above, we propose in Figure 2 a layered architecture that focuses on composition and decomposition operations and illustrates a hierarchical architecture within which devices, capabilities, applications, and required functions to transition from one layer to another are highlighted: Modeling Mf (turning devices capabilities into composition-ready objects or data models), Composition Cf (aggregating basic capabilities into complex services or applications), and Decomposition Df (reusing/recycling the same atomic capability across multiple complex services).
The bottom layer is the Devices, which provides raw and non-composition-ready capabilities. The next layer is the Capability model or object layer, where the atomic capabilities are composition-ready using different data models. The third layer is the Composite Capabilities layer that incorporates value-added services composed of aggregated capabilities. These composite capabilities are generated using processes or engines that leverage composition-ready capabilities models to aggregate atomic capabilities and provide novel and composite features which can be further composed into more complex entities or Applications (e.g., a1, a2, . . . , an in Figure 1), which represent the fourth or upper layer. These applications can be decomposed into less complex or atomic capabilities, or their computation can be distributed across multiple nodes [13]. Composite capabilities can also be decomposed into atomic capabilities via decomposition processes.

6) ILLUSTRATIVE USE CASE
We use the definitions and explanations mentioned above and the formal description in I.A. 4 in the context of a use case to explain the IoT capabilities composition and decomposition topic. Let's consider two applications from Figure 2: a1, a mountain hiking recommendation application, and a2, a highway travel recommendation application. a1 and a2 rely on APIs that provide atomic capabilities specific to these applications. For a1, Cc1 provides oxygen density at a particular altitude. For a2, Cc3 provides express lane fees based on traffic congestion. a1 and a2 also rely on APIs that provide input to both applications: Cc2 can be a product of the decomposition of a complex service or application such as a1 or a2. Cc2 provides weather information for both applications a1 and a2 in a way that enables them to output a recommendation on whether or not to hike (a1) or whether or not to travel (a2).
Cc1, Cc2, and Cc3 are atomic vis-a-vis a1 and a2 -services with a higher complexity-; on the other hand, Cc1, Cc2, and Cc3 are a composition of multiple elemental/atomic capabilities. For example, Cc2 is a composition of Ca3 (might provides temperature information), Ca4 (might predict precipitation), and Cak (might predict the fog level).
Composition is a bottom-up process that leverages lower-level atomic capabilities to build value-added capabilities that can be composed to create even more complex capabilities or applications. Decomposition is a top-bottom process that analyzes existing composite capabilities components to determine reusable functions or distribute computation.   Figure 2 trace composition and decomposition paths. Figure 3 and Figure 4 highlight a high-level, step-by-step approach to the composition or decomposition of IoT/CPS capabilities.

C. MOTIVATIONS AND CONTRIBUTIONS 1) MOTIVATIONS OR PROBLEMS TO ADDRESS
After defining the concepts related to capabilities composition and decomposition, we present in this subsection different motivations or problems that encouraged us to perform this SLR study. While working on new frameworks for capabilities composition in IoT and CPS [193] and studying related use cases [224], we recognized that this topic could be better organized under a taxonomy with three major aspects: Formal, Technical, and QoS. This taxonomy is the first motivation or problem to be addressed for this work as it helps simplify this topic's numerous aspects and subaspects (Section IV-A). The second motivation behind this study relies upon pointing out -for each of the aspects aboveimportant questions that were not given enough attention or were not addressed at all; Section III explains in detail the motivation behind answering each SLR question, and Section V discusses these questions, provides corresponding answers, and highlights trends and gaps in the topic.

2) CONTRIBUTIONS
The key contributions of this study can be summarized in two points: i) Providing a reference taxonomy for researchers to better cover, organize, and understand the different aspects and sub-aspects of the IoT capabilities composition and decomposition topic.
ii) Addressing important problems and questions that -to the best of our knowledge-have never been addressed. These problems include uncovering the main reasons for native support for composition and decomposition capabilities by standards and reference architectures; understanding how problems such as state space explosion are solved when modeling complex IoT capabilities; identifying service decomposition benefits to end users and platform builders; understanding the role of AI/ML in improving service decomposition capabilities or processes; and pointing out how interoperability, scalability, or privacy concerns -expressed by end users or other entities-are addressed.
This study provides many benefits for different stakeholders: For IoT platform users, it shows the importance of composition functions in creating value-added services and highlights decomposition functions' role in resource optimization or cost-saving, directly impacting end-users. For programmers and researchers, this study highlights different solutions to hiccups service composition can face at the formal modeling and verification level. Finally, for city planners and associated IoT companies, this study can help solve formal, technical, and QoS problems related to service composition in different smart city domains and in a way that addresses citizens' or customers' needs.

D. TIMELINE AND THE SLR ORGANIZATION
This effort began in April 2018 and will cover the publications on the topic until May 2022. Our interest has grown in service composition while studying composition frameworks [193] and the composition of novel capabilities in the smart building domain [224]. This survey adopts the SLR methodology: Section I introduces the topic of the study; Section II provides related work and highlights the strengths and weaknesses of previous efforts; Section III explains the SLR methodology, including the primary studies selection process and pointing out research questions; Section IV presents the taxonomy of the study, as well as the primary studies, results in a tabulated format; Section V provides answers and a discussion of the SLR questions mentioned in Section III and highlights trends and gaps in the topic as well as threats to this SLR's validity; and Section VI concludes this study by highlighting main achievements while mentioning benefits to different stakeholders and providing a glimpse into our future work.

II. RELATED WORK: STRENGTHS AND WEAKNESSES
In this section, we discuss related work, especially previous SLR studies and Literature reviews that addressed an aspect or more in the topic of IoT capabilities composition and decomposition. Based on the discussion of each SLR and literature review, we revealed components for research questions that received little to no attention in previous efforts (see Table 1). The topics discussed in this SLR can be placed under three aspects: Formal, Technical, and QoS. Some aspects and relative sub-aspects (see Taxonomy in Figure 10) were given substantial attention; therefore, they will not be addressed in this SLR, while other sub-aspects were scarcely or not surveyed at all: we picked some of the less addressed or non-addressed topics and crafted corresponding SLR questions.

A. FORMAL GAPS
Regarding the Formal aspect, many previous works tackled corresponding sub-aspects, including IoT composition standards and frameworks [4], [9], [213], composition algorithms (heuristic, meta-heuristic, exact, hybrid) [178], formal verification tools, techniques, and properties verification such as correctness [5], [10] or security [7]. None of the SLR surveys addressed the motivation behind native support for composition or decomposition guidelines and mechanisms by standards, frameworks, and architectures (RQ1). In addition, previous SLR questions did not comprehensively explain the main properties of formal representations in service composition from a modeling and formal verification perspective (RQ2). Discussing recent formal trends in service composition, including the properties type, formal modeling approaches, formal verification tools, and implementations, requires an up-to-date revision (RQ3), and the question of state space explosion and how it was tackled and to what extent it was solved was not discussed in previous efforts, which this SLR study attempts to address (RQ4). We put service composition sub-aspects that relate to standards, frameworks, architectures, and formal verification techniques and challenges under the Formal aspect bucket.

B. TECHNICAL GAPS
For the Technical aspect, the sub-aspects previously discussed include service composition in the cloud [6] and industrial environments [196], composition service types, attributes, domains of application [3], composition planning and strategies [11], [195], [228], composition platforms [213], and composition models, techniques, and tools [177], [217]. However, none of these efforts have addressed some Technical sub-aspects, including stakeholders' concerns regarding service composition (RQ5). Similarly, no SLR question comprehensively discussed the nature of composition platforms and how composition implementations differ within these different categories of platforms (RQ6). In addition, the relationship between composition automation levels and composition process types was not highlighted in previous SLRs (RQ7). In addition, the role of communication protocols in composing services at different layers of IoT environments needs to be discussed (RQ8). A comparative study of the different roles data models perform in service composition is also lacking (RQ9). From a measurability perspective, composite services typically reflect a metric that is difficult to assess using conventional metrics, and this aspect is also missing in the studied SLRs (RQ10). Similarly, the decomposition of services for reuse or resource optimization has never been surveyed (RQ11). Finally, the role of artificial intelligence and machine learning (AI/ML) in capabilities composition, either in the composition process or the nature of capabilities themselves, was not surveyed. To the best of our knowledge, this is the only manuscript that address it (RQ12).
By looking at what was covered in previous SLR efforts as well as the existing literature, we identified QoS questions that were not addressed previously; this includes scalability challenges in terms of service composition (RQ13). Although the authors in [2] and [195] discussed which composition efforts provided high, low, or no scalability, they did not address the challenges that face composition approaches to satisfy increased levels of scalability (in terms of latency, computation, etc.). Similarly, in [5] and [196], ensuring a high level of scalability while maintaining a low response time and low verification cost are examples of scalability challenges for service composition that need to be addressed. Another significant aspect that was not given a comprehensive assessment was the interoperability challenges and solutions (RQ14). Different efforts addressed specific areas of the interoperability question, which is the case with SLR [3], which mentioned some interoperability challenges, including differences in network protocols, data models, and service types. SLR [3] also defines a fully interoperable composition as ''service type heterogeneity.'' Similarly, SLR [2] suggested open-source frameworks and a dynamic service composition ensuring interoperability. SLR [5] addressed formal verification challenges related to the interoperability of to-be-composed IoT capabilities. SLR [228] mentioned the integration, selection, and discovery of services as challenges to interoperability. By answering (RQ14), we provide a consolidated response to interoperability challenges and solutions. Finally, an aspect of crucial importance in the age of data sharing is the privacy challenges and solutions when composing services. Although many studies have addressed this concern from a composition perspective [230], [231], none of the SLR surveys addressed privacy-related service composition questions. We address this aspect in RQ15, try to understand how different research efforts improve privacy in terms of service composition and explain how new technologies such as blockchain can be leveraged to improve privacy. Table 1 aggregates survey efforts that tackled IoT and CPS capabilities composition based on the survey type, the year when the research was conducted, the topics covered in the survey, the covered period of the study, and strengths as well VOLUME 11, 2023  as gaps in each study that inspired the SLR questions in this work. The takeaways concluded from Table 1 include: i) a strong interest in answering specific questions related to the topic (SLR surveys) compared to simply summarizing aspects related to it (Literature reviews), ii) there is a strong interest in the Technical aspect of the topic compared to Formal and QoS aspects, and iii) the topic of IoT capabilities composition and decomposition is still trending as it was continuously discussed as early as 1992 until this year (2022) and still attracts the interest and curiosity of researchers. To complete our related work analysis, SLR efforts investigated in Table 1 proposed a total of 41 SLR questions. None of the questions in our survey have been addressed previously. Figure 5 shows the distribution of the previous SLR questions based on the aspect under which they fall. The questions related to the methodology were geared toward the SLR methodology itself or were too general to organize under a specific aspect.

III. RESEARCH METHODOLOGY
The SLR approach uses an objective research methodology to answer specific research questions based on relevant papers on that topic. SLR reviews require expertise in the domain of study, search in different databases, and require years to produce. However, literature reviews can use subjective research methods to summarize topics using informal approaches. The SLR approach was deemed the most suitable for conducting this survey, as the main goal is not to summarize aspects of the studied topic but to address specific unanswered questions related to formal, technical, and QoS sub-aspects of IoT capabilities composition and decomposition. The guidelines proposed by Kitchenham [226], [229] were used, as well as guidelines from the SLR studies in the related work for respecting the SLR methodology: III-A formulating the research questions based on the PICOC approach [226], [227], [233], and III-B explaining the search process while highlighting inclusion and exclusion criteria, III-C performing Quality assessment, III-D discussing the effort limitations, III-E collecting data, III-F analyzing data, and III-G executing the SLR approach.

A. FORMULATING THE RESEARCH QUESTIONS
Based on the gaps and weaknesses of related work, formal (RQ1-RQ4), technical(RQ5-RQ12), and QoS(RQ13-R15) questions -that were not addressed in previous SLR effortswere pointed out, and the list of these questions was elaborated in Table 2 along with corresponding motivations.

B. EXPLAINING THE SEARCH PROCESS AND THE INCLUSION/EXCLUSION CRITERIA 1) EXPLAINING THE SEARCH PROCESS
The research questions (RQs) in Table 2 and the corresponding taxonomy aspects and sub-aspects presented in Figure 10 are the foundations of this SLR review because they guide the search process by guaranteeing that the selection of primary studies is directly related to the SLR questions. The search process was performed in 6 stages: • a) In Stage 1, the SLR questions and the corresponding taxonomy aspects and sub-aspects are identified.
• b) In Stage 2, the search databases are selected, and the corresponding search string and filtering formula are composed as illustrated in Figure 6. The search string was constructed as follows: → We started by crafting the main search sentence of the topic : Service Composition or Decomposition in IoT. Titles, Abstracts, or Keywords must contain the words (or corresponding synonyms) that compose the main search sentence.
→ For every word in the main search sentence, we identified a number of synonyms: -Service: Capability, Feature, Function.
-Decomposition: We couldn't find relevant synonyms to this word, and we ended up using it exclusively to prevent false positives.
→ Plural forms of certain words are considered. For example, in the search string, the words Capability or Capabilities can be searched through the expression: Capabilit*.
→ For each SLR question, the primary studies filtering formula can be expressed as follows: main search sentence + Population keywords (Check Table 3, 3rd Column).
→ For each database (SCOPUS and Google Scholar), we created corresponding search strings (check Figure 6). It's worth mentioning that document type, language, and subject area limitations were automatically added to the SCOPUS main search sentence' search string before filtering on Population keywords from Table 3.
• c) In Stage 3, we executed the SCOPUS search string for the main search sentence, which focused on the title, abstract, and manuscript keywords as explained in Stage 2, this yielded 2805 manuscripts.
• d) In Stage 4, the search results from Stage 3 are narrowed by applying different filtering keywords in column Population from Table 3. For example, QoS/privacy-related primary studies were extracted by adding different related keywords (privacy, private, etc.) to the search string of the main search sentence. Performing filtering on the different aspects and sub-aspects resulted in 553 manuscripts. Some papers contained keywords related to the research questions, but only 50 primary studies were kept as they substantially address one or more RQ in a specific paragraph or as the main topic of the primary study [256].
• e) In Stage 5, more relevant manuscripts were included using the forward and backward snowballing techniques based on the 50 primary studies in Stage 4 to find more answers to the research questions, which required reading the full text of these publications instead of focusing on the abstract, title, or keywords, which added 103 more manuscripts. • f) In Stage 6, and for completion, 29 additional manuscripts were included using the search script crafted for the Google Scholar database. Figure 9 highlights the search stages: the 182 primary studies are highlighted in the Ref column from Table 4 to 18, with some primary studies providing answers to more than one RQ. The primary studies for each RQ are highlighted in Table 3 column Primary Studies. For more details about the primary studies examined in this effort, readers can refer to [256], where we put together the list of primary studies, as well as related information (citation ID in this manuscript, year of publication, the source database, how each study was extracted (Main Search, Snowballing, Manual), publisher, as well as its role in answering a Research Question (RQ) in this SLR.). For the other referenced material in this manuscript, publications and links mentioned when introducing certain concepts, web sources, and Git repositories are not counted as primary studies, but they are components for explanation and completion.

2) INCLUSION CRITERIA
From a content perspective, the inclusion criteria require: • Relevance to the 15 formal, technical, and QoS research questions or the taxonomy sub-aspects.
• The manuscript addresses an RQ or taxonomy sub-aspect as the main component or at least in a specific section/paragraph.
• The manuscript exists in the SCOPUS or Google Scholar Database.

3) EXCLUSION CRITERIA
• SCOPUS main search: non-peer-reviewed publications and document type limitations: sources that are not Conference Papers (cp), Articles (ar), Book Chapters (ch), or Books (bk).
• Google Scholar Manual Search: respected the same criteria as in the SCOPUS main search while tolerating a few important technical reports.
• All databases: document Type limitations: MS or PhD dissertations, white papers, SLR and Literature reviews, documents that are not in the field of Computer Science, Engineering, or Mathematics, and manuscripts written in languages other than English.
• All databases: the full text of the candidate primary study does not provide sufficient information to allow classification of the studied sub-aspect properties. • All databases: for manuscripts selected manually or using snowballing, the full text of the candidate primary study could not be obtained by contacting the authors or other means.

C. QUALITY ASSESSMENT
The six steps followed in the research process were intended to ensure that only relevant and high-quality manuscripts were selected as primary studies. Techniques to ensure quality include full-text reading, forward and backward snowballing, and manual selection of relevant papers that add value to the RQs answers. We were inspired by the quality assessment elements proposed in IEEE Access SLR [228] to VOLUME 11, 2023  ensure that the selected articles respect a minimum quality threshold of 75% of the criteria below : i) Validating the data source: Queried databases and journals are well-known and trusted by the research community through indicators such as the impact factor.
ii) Relevance to the research domain (IoT and Cyberphysical Systems).
iii) Presence of substantial information: The sole presence of RQ keywords doesn't imply inclusion. iv) Primary studies selected provide solid contributions that address the SLR objectives.
To ensure that the SLR is inclusive, efforts that do not originate from well-known -but genuine and trustedpublishers were included; only 16% of the primary studies were obtained using a manual search on the Google Scholar database to ensure that the majority of primary studies were systematically selected while guaranteeing a level of quality and completeness by including manually selected -and RQ relevant-manuscripts. Although important, the number of citations was not taken into consideration as an exclusion criterion as that would discriminate against high-quality or newer publications that might have important data; the same reasoning applies to the year of publication of the manuscripts, which could limit the scope of the study with no concrete benefit. The resulting primary studies were published between 2006 and 2022, with more than 70% being published between 2015 and 2022, and for each SLR question, the majority of primary studies that address them span this period which would reveal the latest advances in the topic and provide up-to-date answers to the identified SLR questions. Figure 7 (A) shows the number of publications per year; this distribution shows that more than 70% of scientific publications on this topic were published after 2015; hence, the continued relevance of the topic in recent years. Figure 7 (B) shows the count of primary studies publications per publisher, primary studies from less-known publishers -representing 21% of primary studies-to achieve a higher level of completeness and to account for the importance of these studies, while 79% of the manuscripts were extracted from well-known publishers (ACM, ELSEVIER, IEEE, and SPRINGER) to guarantee a high level of quality.

D. LIMITATIONS
The limitations of this SLR are as follows: • Not including manuscripts ruled out by exclusion criteria.
• Some formal, technical, and QoS sub-aspects (referred to in the taxonomy as Other Formal, Other Technical, and Other QoS) are not discussed (out of scope) • Databases queried (Only SCOPUS and Google Scholar).
• Some papers were probably not considered due to human error while generating results using the search strings or while selecting papers.
• Although we strongly believe that we extensively covered the studied sub-aspects, relevant papers after May 2022 might have been missed due to the consolidation phase.

E. DATA EXTRACTION
Data in the Results section were extracted from 182 primary studies; the methods used included filtering on the SCOPUS and Google Scholar databases. Keywords leveraged for extraction include those related to research questions but also: (i) title, (ii) names of authors, (iii) year of publication, (iv) Publication venue and related quality index (v), and approaches, criteria, and parameters for each sub-aspect or research question.
Extracted data were placed in tables by referencing the primary studies, as well as other columns, to classify and compare the different studies based on each RQ requirement. For accuracy purposes, the extracted data were reviewed by the main author and agreed upon by the co-authors.

F. ANALYZING DATA
Answering the research questions of this SLR required analyzing tabulated data resulting from data extraction and synthesizing their content based on the RQ requirements and response elements. The main output of the analysis is exposing techniques, constraints, solutions, and other aspects and properties that provide elements for answering each RQ. All documents were subject to classifications in the tabulated data for each RQ, and this classification was re-evaluated by all authors for refinement.

G. EXECUTION
This SLR was conducted in five incremental updates; the first execution was done in April 2018 (yielded 61% of the 182 primary studies), the second in February 2020, the third in June 2021, and the 4th in December 2021 after the reviewers' feedback, and the last update was performed on May 30th, 2022, with a full reevaluation of the abstracts. After the last update, a re-evaluation of the primary studies identified a total of 11 false exclusions, which were later included in the final result of 182 selected documents.

IV. RESULTS: TAXONOMY AND SURVEYED ASPECTS DATA
In this section, we IV-A propose a taxonomy for the IoT capabilities composition and decomposition topic based on the studied RQs, as well as an overview of references VOLUME 11, 2023 cited in this effort, including primary studies. Then, in subsection IV-B, we provide extracted data for the Formal sub-aspects, which answers formal questions RQ1-RQ4. In subsection IV-C, the extracted data that would answer Technical questions RQ5-RQ12 is provided, and finally, in subsection IV-D, we provide tabulated data for the QoS sub-aspects that would help answer RQ questions RQ13-RQ15.

A. A TAXONOMY OF THE SLR RESEARCH QUESTIONS ASPECTS AND SUB-ASPECTS AND EXTRACTED DATA DISTRIBUTION 1) TAXONOMY
Based on related work and our experts' opinions, the issues and research questions addressed in this survey are organized based on three aspects: Formal (RQ1-RQ4), Technical (RQ5-RQ12), and QoS (RQ13-RQ15). We were inspired by previous SLRs on how they organized topics into taxonomies [3], [4], [6], [7], [8], [11], [195], [196], [213], and we proposed in Figure 10 a taxonomy for the IoT capabilities composition and decomposition topic (root), with an indication of which sub-aspect relates to which research question. The taxonomy would help in the search/filtering steps and guide the discussion and trend analysis. We believe that the proposed taxonomy can be extended by researchers to become comprehensive (with the inclusion of the other formal, technical, and QoS sub-aspects not discussed in this SLR) and can be leveraged by researchers to build a full picture of service composition formal, technical, and QoS sub-aspects. The taxonomy's three aspects (leaves) and corresponding sub-aspects (sub-leaves) discussed in this SLR are as follows: •Formal Aspect: We include service composition-related standards, frameworks, and reference architectures as well as formal verification -which includes formal specification languages, formal verification techniques, and challenges-under one aspect as they all aim to provide knowledge and common ground for representing or building a certain concept (composition algorithms fall under this aspect but are not addressed in this effort). The Formal aspect of the taxonomy contains the following RQs-related / sub-aspects: building composite capabilities based on a certain standard, framework, or reference architecture (RQ1); highlighting formal representations properties (RQ2); identifying trends related to formal verification of capabilities composition or decomposition (RQ3), and studying formal verification constraints (the state space explosion problem) (RQ4).
•Technical Aspect: represents sub-aspects including service composition domains and stakeholders (RQ5), service composition platform nature (RQ6), service composition automation and process type (RQ7), communication protocols leveraged in service composition (RQ8), capabilities data models (RQ9) and measurability aspects (RQ10), the role service decomposition plays in distributing capabilities or computation (RQ11), and the role of AI/ML in crafting novel services or improving the service composition/decomposition process (RQ12). Other Technical sub-aspects not discussed in this SLR include service discovery and selection.
•QoS Aspect: The taxonomy adopted in this survey considers QoS as a full-fledged aspect of the IoT capabilities composition and decomposition topic. One reason is that, for example, as more capabilities are composed into value-added services and applications, concerns such as privacy (RQ15) are of great concern because composition formulas and preferences might give away stakeholders' personal preferences [218], [219]. In addition to privacy, scalability (RQ13) and interoperability (RQ14) are two QoS sub-aspects that we will address as they relate to the identified research questions.
As indicated above, some Formal (composition algorithms, etc.), Technical (service selection, service discovery, etc.), and QoS (security, cost, energy efficiency, fault tolerance, response time, etc.) sub-aspects are not discussed in this SLR as the main topic or research question; they are represented in the taxonomy as ''Other (Formal, Technical, QoS) Aspects.'' These other sub-aspects were either sufficiently discussed in the previous SLRs or were outside of the scope of this SLR. One goal of this SLR study is to encourage researchers to use and be inspired by the proposed taxonomy to build a comprehensive picture of IoT or CPS service composition and decomposition.

2) MANUSCRIPTS ROLE AND DISTRIBUTION
In the following subsections, tabulated results extracted from the primary studies -related to the research questions presented earlier-are exposed. This effort cites 256 items, including : • 182 primary studies that met the inclusion/exclusion/ filtering criteria as highlighted in Figure 9. These primary studies are referenced in column Ref from Table 4 to Table 18.
• 16 references to SLR and Literature reviews that represent the related work; however, these papers do not figure in this section's comparative analysis and discussion, nor were they used to provide answers to the SLR questions.
• 14 references were leveraged to explain certain aspects of the SLR methodology or to introduce or explain certain topics.
• 32 references to GitHub repositories were cited for enriching the discussion around certain composition platforms implementations and projects, formal verification tools, and source code. GitHub repositories also include [256], which contains extra details about the primary studies leveraged in this SLR.
• 12 online references that point to certain IoT composition tools or formal verification software.
The results of this SLR search are presented in the form of tables, which would be instrumental in answering the SLR questions in the discussion section. The next three subsections (IV-B, IV-C, IV-D) contain data extracted for each aspect and sub-aspect mentioned in the taxonomy and relate to the SLR questions we seek to answer. Each sub-aspect of the taxonomy is introduced, and we identify which data -or Table-answers which RQ while explaining the columns in the tabulated data and specifying whether these tables provide answers to more than one RQ.

B. FORMAL ASPECTS
In this subsection, data related to the Formal sub-aspects of IoT/CPS capabilities composition and decomposition are extracted to answer RQ1, RQ2, RQ3, and RQ4.
First, the standards, frameworks, and reference architectures supporting the composition and decomposition concepts of IoT and CPS capabilities are addressed. Next, the key characteristics and implementations of the algebraic and graphical formal representations were analyzed. Formal verification techniques used to verify composite services, as well as tools and technologies that support such operations, are presented. Finally, the state-space explosion was given special consideration, with efforts and methods for solving this issue being discussed.

1) STANDARDS, REFERENCE ARCHITECTURES, AND FRAMEWORKS
Standards, reference architectures, and frameworks provide foundations and guidance for building IoT or CPS platforms while respecting and guaranteeing certain aspects and constraints of interest to stakeholders. We list the different IoT and CPS capabilities frameworks that provide guidance on how to build composition environments with some criteria in mind [29]. Frameworks, standards, and reference architectures that propose composition/decomposition guidelines ensure that platforms built have certain beneficial properties (listed in column Composition/Decomposition Enabled Properties in Table 4), which would serve as a reason and motivation for the native support of composition/decomposition guidelines. Table 4 shows primary studies that addressed this subaspect, and its data will be used to answer RQ1.

2) COMPOSITION ALGEBRAS AND FORMAL REPRESENTATIONS
Algebra or formal representations can be used to shape algorithms for composition and can be leveraged as formal specifications in formal verification tools for assessing different properties of interest [178]. Formal descriptions of objects and their interactions, leading to composing and decomposing IoT capabilities, are performed using algorithms that rely on the algebraic representations of objects and services. Algebraic representations can also be derived from graphical representations using conversion [63].
In this paragraph, data that would help partially answer RQ2 is extracted, that is, recognizing the main properties of formal representations leveraged in service composition. Table 5 presents the efforts that have discussed formal representations and composition algebra. The data extracted from Table 5 provides an idea of how these formal representations are leveraged, whether graphical or algebraic in nature, and their important characteristics. For completion, a column for the source code related to composition algebra was provided to help the researcher use and explore implementations and use cases of these formal representations.

3) SERVICE COMPOSITION FORMAL VERIFICATION ASPECTS
Formally verifying composed IoT services properties is a mechanism that aims to verify the properties of atomic or composed IoT capabilities using models in the format of formal specifications and running these models in tools to verify certain properties (deadlock freeness, correctness, fairness, etc.) [26]. The formal verification process is performed after the capabilities specifications are sketched to describe composed services using compatible composition algebra. The capabilities of IoT objects are typically described using a data model. This model is then converted into an algebraic language, which is translated into a formal specification VOLUME 11, 2023   language supported by a formal verification tool. The formal specification is later subject to a formal verification technique (model checking, equivalence checking, theorem proving) to verify -using a formal verification technique -that a certain property is met. The formal verification workflow for service composition is illustrated in Figure 11.
In this paragraph, data that would help partially answer RQ3 is presented, that is, recognizing formal verification techniques, applications, and tools leveraged in service composition. This would also help in understanding the extent of the use of these techniques in research, service prototyping, or industrial applications. Table 6 aggregates primary studies that would contribute to answering this question; it provides data related to formal verification techniques, the properties they address, their domains of application, and the tool used to perform formal verification.

4) STATE SPACE EXPLOSION
As the number of state variables in the composite system increases, the size of the system's state space increases exponentially, which makes it challenging to formally verify composed systems' properties. This is called the ''state explosion problem.'' Much of the research on model checking over the past 30 years has involved developing techniques to address this problem [187].
Any composite system can have a large number of states. The size of the state space of a composed IoT system tends to grow exponentially as a function of the number of its capabilities, processes, and variables. The base of exponentiation depends on the number of local states of a capability or a variable and the number of values a capability or variable may store [28]. State-space methods have motivated researchers to efficiently reduce the number of states while remaining faithful to system design.
Previous surveys did not give this topic the attention it deserves and classified it as an open research problem [5]. Table 7 aggregates the efforts that tackled the problem of state space explosion in service composition and based on which an answer for RQ4 will be provided, i.e., the different methods for resolution and the extent of success of such methods in solving the state-space explosion problem in service composition.

C. TECHNICAL ASPECT
In this subsection, the Technical sub-aspects of the composition and decomposition of IoT capabilities are discussed. Domains of application, stakeholders' concerns, and real-world implementations (e.g., AWS GreenGrass + Lambda [28], [110], [126]) or efforts that provide substantial code-base or interesting prototypes (e.g., MCC  Cloudlets [30]) were explored. IoT platforms for service composition and related communication protocols, data models, schemas, and engines will be discussed. The composition process types and automation, as well as the measurability of the novel capabilities, are investigated. Novel Technical subaspects, including the decomposition of capabilities and the use of AI/ML in composing smart services or improving the composition process, are key contributions of this subsection.
This subsection provides data that answer the technical questions RQ5 to RQ12.

1) DOMAINS AND STAKEHOLDERS
The applications of IoT composition cover multiple domains, including cities, buildings, transportation, health, farming, and manufacturing [23], [41], [121]. Different stakeholders have diverse expectations and requirements regarding building or leveraging composite capabilities. These stakeholders include end-users [117], developers [16], and city managers [120], to mention a few. Table 8 aggregates the efforts that addressed domains of applications of the capabilities composition or decomposition and highlights the stakeholders' interests in each domain for each use case. Data in Table 8 are instrumental in answering RQ5, i.e., Understanding the major stakeholders' concerns regarding composing capabilities in different domains.

2) COMPOSITION PLATFORMS, ENGINES, AND IMPLEMENTATIONS
Composition platforms addressed the composition and decomposition of IoT capabilities at different complexity layers, including edge [30], fog [122], and cloud [60] layers. The takeaway that can be concluded by studying composition and decomposition in these layers is the fact that the complexity of a service increases when its atomic capabilities are composed of edge devices, creating a fog service, or composed of fog services to create cloud services. However, this same complexity can overwhelm the upper layers, particularly the cloud layer [119]. Offloading computations through decomposition from the cloud nodes to the fog nodes or even to edge devices can prove necessary to perform capabilities in the most computationally-efficient manner. Table 9 classifies platforms based on the composition engine, the nature of the platform (simulation, centralized, decentralized), as well as the composition layers targeted (edge, fog, cloud), and provides the reader with implementation details and source code references. The data in Table 9 were used to answer RQ6, that is, understanding the technical differences in capabilities composition implementation in different platforms.

3) COMPOSITION PROCESS TYPE AND AUTOMATION LEVEL
The process type refers to how the composition is triggered or processed and what its workflow looks like. Services can be composed in a serial [26], parallel [16], rule-based [147], VOLUME 11, 2023 VOLUME 11, 2023 or flow-based fashion [32], among other process types. Composition is a complex process that involves several steps, including discovery, selection, filtering, composing, verifying, and delivering. Some of these steps can be automated or semi-automated (requiring the input of a user or another entity). Similarly, each composition process has a set of tasks, each with a certain level of automation. Different efforts have tackled the composition process type and automation level independently; in this effort, we try to find synergies and relationships between these two Technical sub-aspects. Table 10 highlights efforts that addressed composition process types and the automation level as well as manifestations for each topic. Data in Table 10 will be instrumental in answering RQ7, i.e., understanding how composition processes differ in terms of the automation level.

4) COMMUNICATION PROTOCOLS IN SERVICE COMPOSITION
From a communication perspective, capabilities composition and decomposition platforms adopt multiple communication paradigms and play different roles that vary depending on various contexts, and factors, including power consumption [24] or the environment type (production [27], simulation [136], ..), among other factors. Table 11 presents primary studies that tackled the communication protocols in service composition, their use cases, and their workflows. Table 11 data will be leveraged to answer RQ8, i.e., the role communication protocols play in the composition or decomposition of IoT/CPS capabilities.

5) DATA MODELS OR SCHEMAS
The capability extracted from a device must be properly represented using a data model or schema to facilitate composition or decomposition. Efforts that tackle IoT capabilities composition typically tend to use data models based on known formats such as JSON, XML flavors, WSDL, HTML, and other options to represent IoT capabilities [150]. Device characteristics are described through ontologies that provide a shared vocabulary to model different objects and concepts, and their relationships [151]. Table 12 presents these efforts, and based on the results obtained from it, RQ9 is answered, i.e., understanding the roles of the different IoT data models and schemas leveraged in capabilities composition or decomposition.

6) MEASURABILITY
Atomic and composite capabilities differ in terms of measurability approaches, domains of interest, composed systems, and whether these capabilities are functional or QoS-related [15]. Table 13 contains primary studies that focused on measurability aspects of atomic and composite services; it also provides concrete composition examples and presents the capabilities measurability efforts based on the nature of the composite system, the measurable metric, the capabilities type, functionality state, and how capabilities are measured. Table 13 will also help address RQ10, that is, how can non-tangible composite capabilities be measured?

7) DECOMPOSITION
The decomposition of IoT services and capabilities is the process of deconstructing a complex service into small services or atomic capabilities [31], [251]. This process contributes to cost-efficiency, scalability, and interoperability between IoT systems when complex services are built with decomposability in mind. Based on the research we performed, decomposition efforts are either i) capability oriented: which means a complex feature is decomposed into sub-features or atomic capabilities for reuse by other systems, or ii) computation oriented: a complex service might run in the cloud and consume more resources than allowed by a single service, decomposing computation allows its distribution on fog or edge devices in a way that renders resource consumption more efficient.
Decomposition is challenging because the building blocks of complex services might not be easily decomposable, especially when their APIs lack loose coupling support [119]. Decomposition also comes with nonfunctional challenges such as scalability, frequency of data generation, and security requirements. Table 14 aggregates service decomposition primary studies, and the data it contains will be leveraged to answer RQ11. i.e., exposing the benefits of building IoT platforms and complex services with decomposition in mind.

8) AI/ML
Researchers have addressed AI and ML use in service composition from two perspectives. The first perspective is capability-oriented [20], where the AI/ML capabilities are aggregated into value-added features with AI/ML capabilities. The second perspective is process-oriented [32]: AI and ML improve the composition process, especially service selection, where filtering criteria are considered for picking a particular capability over another. Table 15 illustrates the primary studies related to IoT capabilities composition that tapped into the AI/ML potential, and based on the data it presents, RQ12 is answered, i.e., understanding the role AI/ML techniques play in shaping novel capabilities or improving the composition process.

D. QoS ASPECT
This subsection investigates the important QoS sub-aspects of scalability, interoperability, and privacy in service composition or decomposition. A unified approach is followed for studying these QoS properties via the SLR questions RQ13, RQ14, and RQ15, respectively. For each concern, the context of the study is presented, challenges encountered against its realization, and how researchers tackled this concern in their service composition efforts. This subsection will provide input for answering QoS questions RQ13, RQ14, and RQ15 based on the tabulated results in Tables 16, 17, and 18.

1) SCALABILITY
Scalability in the context of capabilities composition is the ability of a particular IoT composition platform, composition algebra, or a composition technical implementation, to function correctly regardless of the number of composite capabilities [45]. Table 16 shows the capabilities compositions scalability challenges and the different ways researchers addressed those challenges. Data in Table 16 is extracted from primary studies that discussed scalability challenges in the context of service composition and provided solutions to those challenges. Table 16 will also help address RQ13, i.e., recognizing the main scalability challenges and adopting solutions to improve scalability in composition platforms.

2) INTEROPERABILITY
Enabling the full compositionality potential of the future CPS and IoT platforms requires enhanced interoperability between software and hardware elements, supported by new reference architectures, standard definitions, and lexicons [121], [173]. Addressing this challenge requires broad collaboration to develop a consensus around key concepts and build a shared understanding of the underlying composition technologies [255]. Interoperability in the context of IoT composition refers to the ability of a particular platform to compose capabilities from devices with different data models or that, in general, are not compatible or not built for straightforward composition. Table 17 aggregates efforts that addressed interoperability aspects, challenges, and potential solutions; as a result, VOLUME 11, 2023  it will help answer RQ14, i.e., understanding interoperability challenges and adopting solutions to improve interoperability aspects in composition platforms.

3) PRIVACY
For IoT/CPS to be trusted by different stakeholders, privacy must be preserved when sensitive and Personally Identifiable Information (PII) is exchanged [84]. IoT and CPS capabilities are typically associated with privacy requirements, especially in applications that involve personal data collection; therefore, there is a need for anonymization techniques as well as encryption and secure data storage. In [174], privacy is also considered the key to maintaining the success of capabilities composition in the cloud and its impact on sharing information for social networking and teamwork on a specific project. One way to keep this success is to allow users to choose when and what they wish to share and to allow encryption and decryption facilities to protect specific data. Table 18 is an aggregation of primary studies that discussed the capabilities composition privacy aspects, challenges, and solutions adopted to address privacy. Data in Table 18 will constitute a basis for addressing RQ15, i.e., recognizing VOLUME 11, 2023  privacy challenges that arise while composing capabilities in IoT platforms and understanding the different solutions the researchers adopted to improve privacy and tackle its challenges.

V. DISCUSSION
Section III describes the adopted SLR methodology, and Section IV presents the results with tabulated data that would help provide answers (AQs) to the pointed-out SLR questions (RQs). In this section, V-A the data from Section IV is analyzed and consolidated to provide answers to SLR questions RQ1-R15, and V-B trends, gaps, and threats to the validity of this study are indicated.

A. ANSWERING SLR QUESTIONS
In this subsection, we provide answers to the SLR questions by referencing relevant primary studies while highlighting in figures trends for topics of interest. IoT/CPS standards, frameworks, and reference architectures not only define data sharing, interoperability, and security specifications of exchanged messages over a composition platform but also incorporate mechanisms for composing or decomposing novel capabilities in different platforms.
[82], realizability [86], deadlock freeness [94], consistency [100], non-conflict [58], conformance [56], completeness [100], fairness [26], trustworthiness [41], and communication properties such as unmatched send messages [21]. It is worth mentioning that verification of some of these properties can be automatically achieved when other properties are verified. This is the case in [98], where safety was verified through the non-reachability of deadlock states by leveraging the PROMELA formal specification. Figure 13 presents the main properties of formal representations as learned from the primary studies results in Tables 5 and 6.

3) AQ3: WHAT ARE THE CURRENT TRENDS IN FORMAL REPRESENTATIONS MODELING AND FORMAL VERIFICATION?
Five trends were pointed out from the data extracted in Tables 5 and 6. These trends are represented in Figure 14 as follows: formally verified functional properties (A), formal verification tools (B), formal verification techniques (C), formal representations modeling approaches (D), and formal representations -used in service composition-source code availability (E).
For formal verification techniques, model checking [53], [81], [102], [104], [105], [107], [113], [116], [235] represents the major technique for assessing properties of interest (74% of primary the studies in Table 6), while equivalence checking [87], [114] and theorem proving [111], [234] represent the remaining 26%. 70% of formal representations are algebraic, while graphical or hybrid representations representing are used in 30% of the identified primary studies: the use of algebraic solutions in most primary studies can be explained by the fact that they can be easily translated to formal specifications compared to their graphic counterparts, which require additional interpretations and transformations (e.g., in [86], BPMN 2.0 is converted to LOTOS NT, and the latter is transformed to the formal specification LTS using the CADP tool). Verifying certain properties of composite systems is the main goal of formal verification. From this perspective, correctness remains the most verified property (%31 of primary studies). At the same time, safety, security, deadlock freeness, and reliability -combined-are addressed in 38% of the primary studies that addressed formal properties assessment. Properties such as privacy can be considered emerging properties in which researchers need to invest more effort (formally verified in one manuscript [115]), which also explains why it was studied in a specific RQ (RQ15). In terms of formal verification tools, CADP, TLA+, Maude, CoQ, and MWB [93] combined represented 55% of the tools leveraged in the primary studies, followed by Isabelle, UPAAL, CWB, NUSMV, and PRISM (5% each). These tools are used by both the research community and industry stakeholders. From an implementation perspective, the data in Table 5 shows that 75% of the formal representations can be traced to a Git repository containing substantial examples of formally specified models for different composite systems. This provides resources to inspire researchers to model and verify the properties of novel services. Figure 14 highlights all these trends.

4) AQ4: WHAT ARE THE DIFFERENT WAYS FORMAL VERIFICATION TECHNIQUES AND TOOLS TACKLED THE STATE-SPACE EXPLOSION PROBLEM IN SERVICE COMPOSITION?
Data extracted from primary studies in Table 7 show that the state space explosion problem in service composition can be tackled using three different approaches: a) Model simplification: This approach works better for models that cannot be decomposed into simpler problems. Examples of this approach include [188] (where a pi-calculus composition algorithm was simplified using an approach called unification that eliminated the state space explosion problem), [96] (where the state space was reduced by using Boolean functions instead of explicit representations with more states), [56] (where the FDR2 algorithm replaced the old FDR, yielding simpler models and as a result fewer states), [44] (where the algebra's order was reduced causing fewer states), [164] and [189] (where machine learning is used to determine the optimal service composition, which in turn simplifies the model), and [49] (the model was simplified by anticipating and eliminating errors in systems with a large state space). b) Model decomposition: This approach works better with models with a large state space that can be decomposed into simpler problems, making model checking much simpler and preventing state space explosion. Examples of this approach include [54], where the CADP toolbox uses software mechanisms to decompose the model to be verified, also [58], where the size of the specification was reduced as a result of decomposing the model, and [237], where the model was decomposed into multiple sub-models, each with a smaller state space that can be checked individually, thereby reducing the state space and as a result preventing the state space explosion problem. c) Resource management: This approach leverages available hardware or cloud resources to alleviate the computation of formally specified models or to implement measures against eventual crashes when the state space computation exceeds the available resource capacity. Examples of this approach include [100], where the TLA specification makes use of multi-threading and allows access to multi-core processing or by offloading and distributing computation among multiple AWS EC2 cloud instances, or [190], where the simulator manages the state space explosion problem by stopping the simulated model to prevent crashes when the space is too large, which doesn't reduce or eliminate the state space explosion problem. To conclude this analysis, the outcomes of these three approaches vary from reducing the state space explosion problem by making the model work for low-scale models, eliminating it if the model's state space is small enough to not cause the state space explosion, or managing it by preventing crashes in formal verification tools. The trends in Figure 15 (A) show that model simplification remains a widely adopted approach to tackle the state space explosion problem, and in 65% of the cases, the problem is reduced, as Figure 15 (B) shows. Table 8 presents data from a set of primary studies that focused on different stakeholders' concerns regarding composing or consuming composite capabilities in different domains. To better understand these trends, we put up Figure 16, which matches pointed-out stakeholders and domains with corresponding concerns. Although Figure 16   doesn't represent a full picture of the pointed-out domains, stakeholders, and concerns, it highlights key relationships and synergies between these sub-aspects. Three main stakeholders were recognized: users, developers, and city planners (or platform managers), with the majority of efforts focusing on users (47%) and developers (42%) concerns.

5) AQ5: WHAT ARE THE DIFFERENT STAKEHOLDERS' CATEGORIES AND CONCERNS WHEN COMPOSING OR CONSUMING COMPOSITE CAPABILITIES IN DIFFERENT DOMAINS?
For Users, the friendliness of composition platforms from a GUI perspective represents an important concern, this is the case for smart buildings applications such as [117], and this has been mentioned in other domains, including smart transportation [197], [199]. Customization and ease of use are also user concerns in the smart manufacturing domain [203]: customers use recommendation algorithms to customize products during pre-production in terms of cost, reliability, and delivery time, among other criteria, [125], [181]. Users also expect energy-efficient composite systems in smart cities [165], [178], [179], [180], less human interaction and more automation in composition platforms processes [23], ease of use of composition platforms [26], [27], cost reduction or zero-cost implementation [121], trustworthiness concerns that include the human/user factor in smart manufacturing [41], accessible safety assessment especially for critical metrics such as security in smart cities [216], safety in smart transportation applications, data privacy in smart health applications [119], environment friendliness and security [216] for smart buildings and cities.
For Developers, most concerns relate to the ease and time to develop, customize, prototype, and publish composite services. This typically requires ready-to-use APIs or at least available and less complex software objects for hardware and communication components. Ease of development, customization, prototyping, and publishing of services for developers were pointed out as concerns in applications related to the domains of smart health [119], environment monitoring [51], and smart cities [20], [120]. Other developers' concerns that are worth mentioning are collaboration and interoperability in smart manufacturing [124], smart transportation [64], and environment monitoring domains [51]. These concerns contribute to a faster and easier composite service development process.
For City Planners and Platforms Managers, four concerns were identified: customization of services to clients, which is the case for insurance companies that can use composition platforms such as Dracena to generate costumer-specific fine-grained recommendations on insurance fees [16]. Another concern is cost reduction. An example of such concern is addressed in [120], where city planners encouraged developers to adopt modular and reusable designs for composite services for cost optimization purposes. An additional identified concern is ensuring trustworthiness in smart manufacturing. An example of this concern was mentioned in [41], where researchers proposed a cloud manufacturing platform that considers trustworthiness pillars as indicated by standards such as the NIST CPS Framework. Finally, energy efficiency in smart cities was recognized as a major concern by both users and platform managers in [165], [178], [179], and [180].

6) AQ6: WHAT ARE THE TECHNICAL DIFFERENCES IN CAPABILITIES COMPOSITION IMPLEMENTATION IN DIFFERENT PLATFORMS?
Primary studies pointed out in Table 9 were selected to answer this question as they provide sufficient implementation details, including where the services are implemented from an IoT layer perspective, which composition engine is used, and implementation instructions that would highlight more details about the technical differences in implementation.
From a platform nature perspective, four implementation trends were recognized: a) Cloud/fog implementations: The implementation of these platforms leverages cloud services, communications, and capabilities to provide value-added services. Examples of such implementations include MCC Cloudlets [30], where researchers have created virtual objects representing edge devices at the fog level. These virtual objects were later composed into applications in the Central Cloud. Networking between the edge, fog, and cloud components is ensured via OpenStack, and the repository for virtual objects is maintained at the fog level. Thing Orchestration [191], along with Cloud CAMP [132] are two other examples of composition performed at the cloud level. Another example of the use of cloud computing capabilities to compose novel services or applications can be found in both commercial solutions: AWS GreenGrass [126], and Microsoft Azure IoT [128], [129]. AWS GreenGrass leverages Lambda scripts to compose value-added services and applications by connecting different AWS services; this requires the installation of the different GreenGrass dependencies and certificates related to the target devices and services. Similarly, Microsoft Azure IoT relies on the Azure IoT Hub cloud component to connect and compose capabilities and services at the cloud level. This also requires the installation of different Microsoft Azure components and command line capabilities. A rulebased cloud solution, IFTTT [37], has also been presented as a cloud composition service. Users can set sensing or actuation rules anywhere on their apps, and the IFTTT service composes the desired rules or outcomes. Finally, Fiware [29] is also a cloud composition platform that leverages multiple plugins, including the Entity Composer Plugin, to compose capabilities provided by devices or services at the edge or fog level, which requires special agents to be installed on edge devices or services to allow the composition of capabilities at the cloud level. b) Edge/Local containers implementations: Edge implementations rely on edge devices to perform a subset of compositions and computations when these edge devices satisfy minimum computation requirements. Edge computing or composition can also be leveraged to minimize delays in safety-critical applications. This is the case for [241], where mobile edge servers are proposed as a solution for composing capabilities at the edge when the edge servers have sufficient computational power. When edge servers are overwhelmed, only then do cloud center nodes take over the composition computation. This type of composition is typically suited for delay-sensitive applications such as smart transportation applications. Another example of the use of edge computing to perform service composition is highlighted in [51], where authors discussed Home Assistant: free and open-source software for home automation designed for central control in smart homes. Home Assistant is hosted on a local machine and doesn't require internet connectivity. Edge devices and the Home Assistant node are located in the home LAN and are managed in a way that ensures privacy and security. mPlane is another measurement platform that can be used for network measurements, and compositions at the edge [12] and requires a local node running the composition engine (Supervisor) on a competent machine connected via different types of APIs (TCP/IP, REST) to network probes, services, and clients. A similar concept is highlighted in [140], where the Vert.X toolkit is used to create and compose local microservices, with the ability to call remote atomic capabilities via different APIs such as Axios. Finally, the publication [13] highlights an example of edge/local composition using a composite engine (Fast IoT Composer) running on a local machine to compose smart home services. It can be concluded that edge/container composition only serves as a substitute for cloud composition when the resources associated with edge/container nodes are sufficient to perform the composition computation. From a performance perspective, edge composition is faster and provides faster results and services than its cloud counterparts. Finally, it is also safe to assume that edge/local containers computing provides more privacy when the data doesn't leave the user's vicinity. c) Simulation/prototyping implementations: These platforms compose simulations or prototypes for composite services and systems. Examples of these platforms include [118] and [136], where a CPS representing an autonomous vehicle for safety assessment was simulated in UCEF using atomic components called federates that communicate using the pub-sub HLA protocol. Another example can be found in [64], where services and sensors can be fetched using REST APIs from Node-RED's web interface, which enables the simulation and prototyping of composite services. It is worth mentioning that Node-RED can be used for production as well for less-complex home applications, but other mature solutions are well-optimized for such purposes, such as Home Assistant. Trends in Figure 17 show that from a platform nature perspective, cloud composition platforms represent (43%) of the primary studies identified: this can be explained by the fact that most studied compositions are computation-intensive and need resources that typically reside in the cloud. In addition, cloud platforms are mostly commercial with high maturity and reach as opposed to edge/container solutions which are mostly academic efforts. Edge or local containers composition solutions represent (36%) of primary studies, whereas service composition simulation platforms represent only (21%) of primary studies. The primary studies in Table 10 were selected as they provided input on the composition level and the composition process type. By analyzing Table 10 columns, especially the automation and process type manifestation columns, the  depth of complexity and automation in each process type can be learned. Two trends were pointed out: a) Low complexity processes => Require no/basic user input: These processes facilitate the automation of composition owing to their low complexity, and they are ready to exploit APIs and interfaces to atomic services [26], [27] or by automating complex composition steps, including data collection, and composition [17], [32], [33], [46], [64]. Rule-based processes can be considered the least complex of all composition process types because they only require setting up simple rules or composition goals by the user from a GUI to trigger desirable events [21], [147], [148]. b) High complexity processes => Require user or developer input and programming These processes have a higher level of complexity since they require extra programming to achieve the composition goals. Examples of such composition process types include process or programming-based composition processes, which -as the name suggests-require manual programming or crafting composition scripts to achieve the compositions goal [51]. Asynchronous or parallel compositions also show a higher complexity level than their synchronous counterparts, which was indicated in [16] and [12] where additional development on specific highly programmable platforms is required. Finally, some flow-based composition processes can have a high automation level but still require user input on specific QoS parameters to successfully achieve the goal of the composition, as in [13], where user input is required during the service selection step to recognize specific atomic services that meet certain QoS properties of interest. Figure 18 aggregates these trends and shows that among the 14 primary studies addressed in Table 10, 28% are semi-automatic for their higher complexity and their need for user or developer input. In comparison, 71% of the primary studies were automatic for their lower complexity and their need for basic or no user input to achieve the composition goals.  Table 11 contains the primary studies that provide insights into the role of communication networks in service composition or decomposition. Three categories of roles were pointed out.

a) Communication roles:
This role is manifested in i) enabling a wide variety of services such as microservices (Vert.X's Axios, [140]) and pub/sub Java federates (HLA [136], [118]) to communicate and exchange data with composition engines to build composite services, or in [211], where smart connected IoT devices leverage the mashup paradigm to communicate and exchange data, leading to value-added services through compositions in WSNs. ii) facilitating the communication of heterogeneous IoT networks through transparent access (CoAP/HTTP, [160]); iii) enabling the discoverability of IoT devices capabilities (mDNS, [21]); iv) simplifying interfaces and enabling flexible network management (SDN, [27], [41]); v) acting as middleware between publish-subscribe brokers and services (MQTT, [122], [147]); and vi) offering commands that enable requesting, receiving, composing, and storing data by leveraging multiple network components (mPlane protocol, [12]). b) QoS-related roles: This role is observed in (CoAP, [24]) which allows communication between energy and computation-constrained devices, or in (SVOM, a CoAP-based protocol, [24]) which captures the status of registered devices to achieve fault management. In [210], energy efficiency was enabled in SOA composite applications in WSNs by leveraging the NOC paradigm. Similarly, in [169], an EPCglobal-compliant middleware was proposed to facilitate communication between IoT devices in a way that ensures scalability, elasticity, service decomposition capabilities, multi-threading, and cloud virtualization. c) Process roles: In addition to communication and QoS roles, two process roles were identified in primary studies that communication protocols facilitate in service composition: i) enabling asynchronous communications (REST, [22]), and ii) enabling service decomposability by tracing back interests requests to reveal which capabilities (atomic or composite) exchange data with the composition engine or clients (NDN [161], [162]). Primary studies used in the discussion below were selected because they provide the reasons behind using a given data model for composing capabilities. These primary studies also provided concrete examples of such data models, as shown in the last column of Table 12, where a subset of the data models used and their attributes are represented. Some attributes are shared by most data models, including capabilities ID, location, and timestamp. Based on the data provided in Table 12, the following data models and schemas roles were pointed out: a) Modeling services, composition, decomposition, processes, and operations: The ease of composing atomic capabilities is one of the key enablers for creating value-added applications, which can only be done through the use of data models that facilitate this task by representing capabilities data and operations. This is highlighted in [25], where JSON VOLUME 11, 2023 is used to model mPlane capabilities thanks to its simplicity, parseability, and efficiency. JSON is also used to represent services, bindings between services, as well as the strength of these bindings [26], [27], [192]. In IFTTT [21], JSON Web of Things (JWT) is used to model objects and composition rules. The same applies to WSDL [44], [209], which is typically used with SOAP and XML [201], [206] schemas to describe and enable the discovery of web-services. BPEL data models describe composite services processes and enable their deployment in three steps: process template creation, process composition, and process installation. Another flavor of BPEL, WS-BPEL [156], [205], describes services and their execution and compositions [153], with BPEL-TC upgrading the features of WS-BPEL to include composition and decomposition requirements for temporally customized web services [155]. OWL-S enables nested classes description to model functional and non-functional properties of IoT devices [157], [183], and OWLS-TC4 provides simple capability aggregation mechanisms for non-complex compositions [123]. Finally, HSML/HTML [51] describes the state of IoT services whereas SSN [158] represents context information for capabilities including deployment attributes. The attributes of data models illustrated in Table 12 show synergies and common attributes (id or name, timestamp or start time, location or ip, etc.) between most of the different data models when it comes to describing services. b) Enabling formal specification: After adequate translation, some data models can enable formal specification. The translation process complexity varies in terms of difficulty from one data model to another. Examples of data models converted into a formal specification include JSON [64], which was used for a service description of the Node-RED object detector, which was later converted into semantically comparable service vector descriptions (VSA: Vector Symbolic Architecture). Another example of this role can is found in OWL-S [110], which enables services description (service profile, service processes) based on which a TLA formal specification is defined. Some efforts mentioned challenges that complicate the conversion of data models to formal specification: an example of such complications can be found in WSDL [44], which cannot be converted into formal specification because of its lack of implementation details and logic. c) Facilitating interoperability between different platforms through integration APIs: To allow different platforms to compose their capabilities when their data models differ, an interoperability bridge between these platforms must be established. Data model integration APIs are one of the bridge techniques used in service composition to accommodate this requirement. Examples of such techniques can be found in [152], where JSON-LD was easily integrated with other Context Information Management (CIM) platforms, and RDF/XML (Resource Description Framework) was used to integrate APIs with external XML platforms to ensure backward compatibility. XML has also been used in mPlane [25] to allow integration with external platforms using XML data models. d) Documenting services and debugging processes and compositions: YAML's improved human readability and writability, making it suitable for documenting and debugging [25]. e) Special roles: WoTDL [149] is an alternative to existing WoT models such as OWL-S and WSDL, which are unsuitable for describing AI planning concepts for automatic WoT compositions.

10) AQ10: HOW ARE ATOMIC OR COMPOSITE CAPABILITIES QUANTIFIED OR MEASURED?
Data from the primary studies identified in Table 13 is used to shed light on the measurability aspect of service composition. Regarding atomic or composite capabilities, the following measurability trends were recognized: a) Atomic capabilities: → The are typically concrete and tangible capabilities with standardized metrics and units.
→ They are typically generated by devices by converting physical environment information to a digital form and associating it with a standardized unit.
→ Cannot be further decomposed into other atomic capabilities.
The best example of atomic capabilities measurability approaches that satisfy the trends above is illustrated in [15], where functional atomic capabilities (temperature, humidity, carbon dioxide, wind speed) and non-functional atomic capabilities (RTT, latency, and drop rate) of a thermal comfort system were measured using different weather and home sensors as well as system performance probes. b) Composite capabilities: → Are typically abstract/non-tangible capabilities; the metrics and units used are user-defined and non-standardized.
→ Are generated by combining and aggregating atomic capabilities in a way that end users can assess.
→ Can be decomposed into atomic capabilities. Examples of composite capabilities measurability approaches that satisfy the elements above include the two non-functional capabilities mentioned in [26] and [27]: i) ''Tool Usability:'' was assessed using many atomic factors derived from the user's experience including the number of clicks to achieve a composition task and the easiness of interacting with the UI. ii) ''Platform Performance:'' was assessed by assessing and aggregating multiple factors, including the time for the deployment and the time to generate a specification, as well as the number of states and bindings processed by the platform. Examples of functional composite capabilities include Traffic Jam Trend prediction [16] (composed based on speed and location atomic capabilities provided by the SUMO simulator probes) and Thermal Comfort [15] (composed based on atomic capabilities provided by weather sensors: temperature, humidity, carbon dioxide, and wind speed). The functional and non-functional composite capabilities identified in Table 13 follow the trends mentioned above. It can be concluded that measurability trends apply regardless of whether atomic or composite capabilities are i) functional (inherent features of IoT devices and represent their main output. For example, a temperature sensor provides a functional capability: measuring temperature, which is a measurement that can be expressed with a quantitative value and a unit (Celsius or Fahrenheit)) or ii) non-functional (QoS and performance metrics associated with the IoT devices -or the infrastructure they run on top of-rather than their main feature itself, these non-functional properties include the SLA level, latency, redundancy, scalability, interoperability, security, and privacy, among other non-functional features [167]). As for the composite IoT capabilities network infrastructure, measured aspects include service quality and network capacity [198], [200] by tracking resource utilization. Other non-functional measurements in web-services platforms include performance, resource utilization, dependability, fidelity, response time, availability, and cost [212], [215]. Finally, an interesting example of measuring latency in mPlane is worth mentioning as latency measurement in this example is a functional property as it represents the main feature of mPlane as a network performance measurement platform [12]. This same metric (latency) is considered a non-functional property in other platforms, such as the thermal comfort measurement platform [15], as it doesn't contribute to the calculation of comfort but rather provides an idea of the platform's performance. The primary studies in Table 14 showcase publications focused on service decomposition. This is a particularly interesting topic that has not been investigated in previous SLRs. Based on collected data, the following main benefits were pointed out: a) Capabilities reusability: Platforms with decomposition support benefit from this property as a decomposed complex service into atomic capabilities can see its atomic services reused in other compositions, omitting the need for implementing redundant services and saving relative costs. This is the case in a hierarchical IoT platform [170] where complex capabilities are decomposed and reused to complete the pieces of another service with higher complexity. Another example of reusing capabilities owing to built-in decomposition mechanisms can be found in [119]: a microservices-based platform allows larger services to be decomposed into small, focused, self-contained services with loose coupling, which facilitate their reuse. The same case applies to using Domain-Driven-Designs (DDD) to decompose monolithic software [171], which makes it possible to use pieces of monolithic software in other compositions. Finally, in [51], the FSM model-driven services decomposition broke their linkage, which enabled their reusability.

b) Resource optimization:
The decomposition of complex capabilities leads to resources optimization not only in terms of costs associated with deploying novel services [168] but also in terms of reducing network congestion as monolithic services consume more bandwidth compared to atomic capabilities [31]. The same concept applies to [169], where computation-intensive virtualized services leverage decomposition to optimize computation. Another case of resource optimization was encountered in [13] where decomposition leads to the identifying energy-efficient atomic capabilities that can be later used to compose efficient complex services.
In addition to capabilities reusability and resource optimization (main benefits), other benefits of building composition platforms with decomposition in mind were mentioned, including stakeholders acceptance as described in [168] where platform users can benefit from the reduced cost of exploitation due to reusability and resource optimization. Other benefits include improved QoS parameters such as platforms agility, flexibility, and scalability [166]. Improving collaboration between capabilities has also been pointed out as a benefit of decomposition in [64]. Finally, the traceability of the atomic capabilities that contribute to a certain composite service was mentioned as a benefit in Information-Centric Networks (ICN) such as Named Data Networks (NDN) [161], [162]. Figure 19 shows the distribution of the main benefits of building composition platforms with decomposition in mind as extracted from Table 14. Efforts that leveraged decomposition to break complex services into atomic capabilities for reusability purposes represent 72% of primary studies. In contrast, efforts focused on computation decomposition for resource optimization represent the remaining 28%. The role of Artificial Intelligence (AI) and Machine Learning (ML) in service composition was not surveyed in previous service composition SLRs. We presented primary studies that tackled this particular aspect in Table 15; these primary studies show the roles AI/ML techniques play in service composition, including: a) Composing capabilities with AI/ML features. Primary studies in Table 15 highlight this role. In [250], AI/ML capabilities were implemented in a smart transportation platform that analyzed incoming vehicle data to build real-time automated driving features. In [20], complex atomic capabilities with AI/ML features were built and made available to developers to compose smarter systems and platforms in smart cities or smart transportation domains. Examples of these atomic capabilities with AI/ML features include multiple predictors such as noise level and free parking area predictors. Another example of the role of AI/ML in building complex capabilities was referred to in [31], where a cloud facial recognition composite service leveraged AI/ML atomic capabilities at the fog level,  including facial features extraction, data fusion, data filtering, and face detection algorithms. Finally, in [120], an example of reusable AI/ML smart city services was studied in the context of a collaborative platform. This platform enables the composition of smart city services based on atomic AI capabilities, such as traffic and parking estimators. b) Improving composition platforms and processes. This is the most common role among the pointed out AI/ML primary studies aggregated in Table 15, which shows how AI/ML can play a role in improving composition platforms as in [247], where AI/ML is leveraged to improve maintenance of IoT composition platforms and in [248] where AI/ML techniques were used to improve security. To improve the composition processes, in [32] and [33], an AI-based classification method applied to a pipeline consisting of ML services was used to maximize the classification accuracy, leading to an improved service selection process. Similarly, a service composition technique called AI Planning was used in [163] for automatically composing well-described web services into feasible workflows and selecting and organizing web services based on location. Reference [159] is another primary study where genetic algorithms were used in SOA-based environments to perform service selection based on QoS properties defined by the user. Finally, another example of AI/ML-based service selection was presented in [172], where a reinforcement learning agent was used in the dynamic of Mobile IoT to perform service selection based on user-defined criteria (including spatial cohesiveness, number of handovers).
A secondary role of AI techniques in service composition was discussed in [115], the CompoSecReasoner framework leveraged AI algorithms to assess, monitor, and verify properties such as security, privacy, and dependability. The components of the CompoSecReasoner framework also ensure dynamic system composition verification, property validation, and metrics-based automated administration.
Based on the primary studies in Table 15, Figure 20 shows the distribution of the main roles of AI/ML techniques in service composition: i) improving composition processes (67%) and ii) composing AI/ML enriched or improved capabilities (33%). As novel services with high value require the composition of multiple atomic capabilities, scalability can arise as a challenge if the platform fails to scale for performance, QoS, network, or other constraints. Based on data from Table 16, the growing number of services, users, and providers, generating or requesting composed and valueadded services represent the main causes for scalability issues. These challenges and potential solutions are discussed to provide answers to RQ14.

• a) Scalability Challenges in service composition
In [166], IoT BigData analytics platform scalability was impacted by a large number of devices, services, and users. Similarly, a large number of wearable smart health devices cause scalability issues not only from a computation perspective but also from a budget perspective [249]. For [175], the training data originating from multiple providers overwhelmed the training and composition algorithms in the secureSVM platform. Similarly, large user requests are considered the root of overwhelming a WS-BPEL-based online travel recommender [154]. Another example of the scalability issues caused by high numbers of IoT objects was mentioned in [26] and [27], which not only impacted IoT smart home applications deployments but also generated a large state space that caused the state space explosion problem when formally verifying composite capabilities properties. In [207], composition algorithms that did not scale for reasons associated with large user quantitative constraints were the subject of analysis. Finally, ultra-large numbers of services were also identified as the root of scalability issues in [45], [46], and [47].

• b) Scalability Solutions in service composition
To address scalability challenges in the above primary studies, researchers have adopted the following solutions: i) Properly adjusting and dimensioning resources: An example of such a solution was adopted in [166], where researchers proposed a dynamic solution for dimensioning resources, including storage and processing, to anticipate scalability issues. Another example of such an approach was pointed out in [154], where researchers proposed redundancy and load balancing at the computation and network resources level to tackle higher loads and user requests for composite services. ii) Adopting optimized and enhanced composition algorithms to overcome scalability issues: This is the case in [207], where CP-net algorithms were proven to have a better capacity to handle compositions that require a large number of user constraints. Similarly, an optimized Gradient Descent Optimization algorithm was used in [175] for training and composing data, creating a platform that scales with a large number of data providers. Another example was identified in [26] and [27], where CADP's parallel algorithms and composition capabilities were leveraged to overcome scalability issues when formally verifying properties of interest.
iii) IoT capabilities layers, data, computation, and workflows management: Adopting a layered architecture that distributes computation across different layers (cloud, fog, edge) was adopted as a solution in [249] to handle the large amount of data generated by smart health wearable devices. The research around the DX-MAN composition platform also provides an example of this solution [45], [46], [47] where researchers highlighted scalability requirements that, when applied to data and workflows associated with IoT devices, contribute to better scalability, these requirements are: explicit control flow, distributing workflows among multiple compute nodes, localization transparency, decentralized data flow, separation of control, data, and computation, and workflows variability. iv) Building IoT composition platforms based on scalability-aware frameworks: frameworks with scalability recommendations and guidelines can help researchers, developers, and composition platforms providers build platforms that scale from the get-go. An example of this approach is illustrated in the NIST CPS Framework [38], [39], [40], where building IoT/CPS capabilities composition platforms with the NIST CPS Framework guidelines in mind -especially those related to trustworthiness-would provide elements to enhance scalability in terms of network constraints and in the case of large numbers of users.

14) AQ14: WHAT ARE INTEROPERABILITY CHALLENGES AND SOLUTIONS WHEN COMPOSING CAPABILITIES FROM HETEROGENEOUS ENVIRONMENTS?
Capabilities in IoT or CPS may originate from heterogeneous devices and services. This can create a challenge when attempting to compose these capabilities to innovate valueadded capabilities. Primary studies in Table 17 discussed both challenges and solutions to interoperability. These aspects are presented below to provide answers to RQ14.
• a) Interoperability challenges in service composition Two main challenges to service composition interoperability were identified: i) Heterogeneous services, systems, networks, and components: lead to a lack of communication/network interoperability. This was recognized as a challenge in multi-platform environments discussed in [255], where the lack of interoperability impacts load distribution. The same issue was noticed in the NIST CPS Framework enabled platforms when it comes to heterogeneous components, and systems [38], [39], [40], or IoT Systems with different architectures [36]. Similarly, researchers in [18] and [121] mentioned two challenges, one technical, related to the various device interfaces in heterogeneous IoT systems and platforms APIs, and the second organizational, illustrated by the heterogeneous service APIs that prevent communication between organizations. Another case of this challenge was identified in [173] and [254] related to the heterogeneity of communication protocols and the challenges it represents to interoperability, and in [34] where heterogeneous APIs of certain IoT systems and platforms contribute to the lack of interoperability and as a result constitutes challenges to service composition.
ii) Heterogeneous and unstructured semantics and data: Unstructured and heterogeneous data and data models were exposed as a challenge in the NIST CPS Framework [38], [39], [40], and in [166] as a challenge to easily compose useful analytics in IoT platforms. Similarly, the researchers in [18] and [146] discussed syntactic and semantic challenges, including various data formats, data encoding, data models, and ontologies as a hindrance to composing cross-domain IoT services. The lack of compatibility between data formats and data models standards and specifications also falls under the same umbrella as discussed in [202] and [173].

• b) Interoperability solutions in service composition
Two leading solutions were identified to address the interoperability challenges mentioned above.
i) Standardized or custom communication APIs and suitable interfaces were identified as a solution for bridging interoperability gaps and challenges in [18] and [173] and would solve related technical and organizational concerns. In [255], understanding the load each platform interface handles in a multi-platform environment and providing suitable interfaces that fairly distribute this load is key to improving interoperability between the different platforms. In [34], providing standardized interfaces was pointed out as a measure to achieve interoperability in IoT across stakeholders and producers/consumers. Another similar solution was identity in ARM-based IoT platforms [36], by using the IoT ARM tool to allow fair interoperability by enabling bridges between systems that don't share the same architecture. [121] is another effort that adopted the same strategy; the ''Information Management Adapter'' was introduced to facilitate interoperability between smart farming systems within an NGSIv2-FIWARE implementation, and in [204] a hard-coded adapter was used to mitigate the diversity issues related to sensor platforms by picking compatible devices. Finally, standards such as the NIST CPS Framework [38], [39], [40] proposed standardized APIs to achieve external interoperability and, as a result, facilitate service composition in cyber-physical systems.
ii) Standardized or common description languages and data semantics: is a technique adopted in multiple efforts such as [163] to ensure capabilities are composable by leveraging data homogenization techniques to exploit both structured and unstructured IoT devices data in analytics. In [173], lightweight and reusable interoperability models were used to support the composition of a broad range of applications, and in [18], unified data formats/encoding were leveraged to address syntactic and semantic challenges to facilitate service composition. Similarly, researchers in [146] leveraged W3C SSN-compliant semantics (JSON-LD) in the VITAL platform to ensure interoperability across diverse IoT streams and domains, and in [121] a ''Data Interoperability Zone'' was introduced to ensure data interoperability between smart farming systems within an NGSIv2-FIWARE implementation. In [202], a technique that wraps service semantics into middleware at the application layer automatically generates APIs allowing interoperability without modifications to existing standards, devices, or technologies. Finally, The NIST CPS framework [38], [39], [40] proposed providing common languages for describing services to ensure an easy composition of CPS capabilities. Figure 21 shows the above trends related to interoperability challenges and solutions in service composition. Primary studies in Table 18 focused on privacy challenges and solutions in service composition.
• a) Privacy challenges in service composition Four categories of privacy challenges were identified: i) Non-trusted objects/Devices Challenges: non-trusted objects anonymously joining composition platforms can lead to privacy issues when collecting or processing IoT Data. An example of this challenge was highlighted in IoT-A-based composition platforms such as Fiware [29].
ii) Data Challenges: data in IoT or CPS composition platforms can reveal private information when labeled, exchanged, or composed. In [38] and [39], the NIST CPS framework highlighted the privacy threat that originates from composing or aggregating certain types of CPS data, which may present little or no privacy concerns in isolation. Another example of data challenges leading to privacy concerns is found in [175], where the use of labels on data to allow Machine learning classification might compromise privacy if those labels contain privacy-sensitive elements. In [176], the ever-growing number of IoT devices generating privacy-sensitive information is considered a privacy concern if the data are not properly processed throughout its life cycle: a Special case of this issue is discussed in [219] where the ever-growing number of medical IoT devices constitutes a privacy sensitive challenge if the data are not properly handled.
iii) Platforms Design challenges: platforms that lack privacy components by design are the most vulnerable to different privacy challenges as discussed in [18]. In other instances, Privacy policies might be in place. Still, their technical implementation is neither supervised nor adhered to by developers, who typically focus more on functionality and less on ethical values related to the use of communication technologies [34]. Cross-domain IoT platforms can also advertise good QoS metrics, including privacy. Still, these metrics might not be credible, especially when profitability is threatened [230], and In [115], researchers stressed the need for IoT design and management frameworks that implement mechanisms for tangibly assessing privacy. iv) Legal challenges: This case is particularly crucial when the composite system's requirements include nonrepudiation [36]. This goes against the users' or devices' privacy which is an ''Element to Protect.''

• b) Privacy solutions in service composition
Three solutions were pointed out to address privacy challenges in service composition: i) Service and component-based solutions : By implementing components and services that enable, manage, and assess privacy within composition platforms. In [29], an IoT-A-based IoT composition platform (Fiware) leveraged the ''Identity Management Functional Component (FC)'' within the ''Security Functional Group'' to issue pseudonyms and manage accessory information to trusted subjects to ensure anonymous operations and as a result protect privacy. In [36], an Identity Management component run by a trusted third party was leveraged for user privacy protection and tracking malicious actions. Similarly, the CompoSecReasoner [115] component addressed privacy through the computation and validation of privacy metrics post-composition. Privacy was computed/estimated based on tangible vulnerability, exposure, and disclosure metrics.
ii) Best practices, Standards, and Regulatory solutions: this solution is illustrated in [38] and [39], where the NIST CPS Framework provides privacy risk management guidelines, including the analysis of privacy risks throughout the entire data lifecycle: creation, collection, composition, exploitation, and disposal. In [176] and [219], The EU's GPDR is proposed as a framework for addressing privacy by enforcing mechanisms of Transparency (how data are processed), Consent (user's ability to opt-in or opt-out), and Erasure (the right of the users to delete data). Human-Centric Computing, proposed in [34], also proposed architectural best practices for developing privacy-aware composition platforms from the development phase, and in [34] and [176], user consent was highlighted as an important component to protect users' privacy when accessing IoT cloud platforms. Similarly, researchers in [230] proposed a history record-based service optimization method (HireSomeII) that protects cross-clouds privacy by evaluating their QoS history records instead of relying on their advertised QoS values, which would enhance the credibility of the composition plans they provide. Another effort that tackled the problem of protecting user privacy in cloud platforms while enhancing other QoS parameters was mentioned in [253], where researchers used privacy-preserving mechanisms to rank compositions based on their privacy preservation level. Other best practices that enhance privacy in IoT composition platforms were discussed in [166], where researchers highlighted recommendations including the anonymization of personal data, encrypting and securing data storage components, and implementing user-customizable data sharing mechanisms.
iii) Technology-based solutions: Including blockchain, encryption, and cryptography as discussed in [175] and [176], where IoT data was encrypted to preserve privacy in an ML/Blockchain-based smart-city composition platform, and in a cloud IoT platform. Blockchain has also been used in [175] and [176] to protect privacy by either storing sensitive data on a distributed ledger, making it difficult to trace or by leveraging the decentralized nature of the blockchain to avoid the case of a single entity managing devices and stakeholders credentials. Decomposition of privacy into atomic properties is another technical solution leveraged in [18] to address privacy concerns in IoT composition platforms. Researchers have decomposed privacy into atomic problems or properties, including authentication, authorization, data protection, unobservability, anonymity, unlinkability, undetectability, and pseudonymity. These low-level atomic properties were studied individually and thoroughly to improve privacy. Figure 22 shows trends related to IoT/CPS service composition privacy challenges (A) and solutions (B).

B. TRENDS, GAPS, AND THREATS TO VALIDITY 1) TRENDS
We can recognize what's trending in a certain topic and how important it is by running an advanced search -using different flavors of each sub-aspect's vocabulary-on the pool of primary studies (182 publications) using the Adobe Advanced Search tool.
The advanced search parses primary studies and searches for keywords related to the different taxonomy sub-aspectsmentions in the bibliography not considered-including some that were not addressed in this SLR. As opposed to the discussion section, we include in this analysis primary studies that not only discussed an aspect thoroughly but also papers that partially addressed it while discussing other sub-aspects. These trends are illustrated in Figure 23.
For the Formal aspect, almost 99% of primary studies mentioned a framework, a standard, or an architecture, which shows the importance of these components in guiding service composition. Although not addressed in this SLR, composition algorithms are a major aspect in the discussed primary studies, with more than 70% of primary studies mentioning at least one composition algorithm. Regarding the covered formal aspects in this SLR, we expect the problem of state space explosion to remain an important challenge in the upcoming decade: in the absence of a substantial effort in optimizing composition algorithms, improvements in computation power will always lead to the innovation of capabilities with higher complexity, keeping the state space explosion problem a continuous concern for the research community.
For Technical sub-aspects, composition process type and data models are the most discussed aspects (more than 95% of primary studies), whereas service discovery and service selection were discussed in only 26% of primary studies or less. This is because we didn't pick primary studies based on these sub-aspects' keywords. For the upcoming years, content-centric networks such as NDN and CCN [161], [162] are gaining momentum with their data caching and interest tracing capabilities, which could revolutionize service composition and decomposition in IoT platforms. VOLUME 11, 2023  Finally, for the QoS aspect, cost, security, and reliability were mentioned in 56% of the primary studies; although they weren't the main subject of this study, this shows their importance and involvement when discussing other service composition sub-aspects.

2) GAPS
As mentioned in the trends section and based on the taxonomy proposed in this SLR study, many formal, technical, and QoS sub-aspects were not addressed through SLR questions but rather discussed partially within other sub-aspects.
For the Formal aspect, although composition algorithms were extensively discussed in [228] -specifically on how to leverage meta-heuristics algorithms to efficiently select capabilities based on user-defined QoS parameters-, service selection remains only one of many service composition steps. An SLR question that addresses how different service composition algorithms efficiently intervene during the other composition steps is a topic researchers need to invest effort in.
Regarding the Technical sub-aspects of service composition, automation and process types in service decomposition, and the level of automation of each step of the composition process are worth investigating by researchers, and we consider these topics as open issues.
For the QoS aspect, the security of composed systems was addressed in many non-SLR/Literature publications, including [115], where authors discussed the security of IoT systems of systems (SoS) and highlighted the importance of calculating the security level of the final/composed system, taking into consideration the security of its subsystems. However, security-specific SLR questions, such as the security mechanisms required during each composition or decomposition step, were not addressed in this SLR study or other SLR studies, making it a gap worth filling by the research community.

3) THREATS TO VALIDITY
This paragraph presents possible threats to the SLR's validity while mentioning some corrective strategies.
For the document sources, only SCOPUS and Google Scholar databases were queried; however, SCOPUS alone generates results from more than 5000 publishers (including the main publishers), which should provide substantial results along with the search performed -for completion-in Google Scholar.
Regarding the SCOPUS and Google Scholar search strings: they were designed in a way that produces as many results as possible, with extra keywords added to filter specific sub-aspects questions. Not using all synonyms for a certain sub-aspect might result in missing a certain study. The search string automates the selection process as much as possible, but given the large number of papers and the different addressed questions, human error/bias during the non-automatic phases of the search process (manual selection, forward and backward snowballing) cannot be completely ruled out.
As for the selection procedure, it was partially automated as some stages require researchers' involvement and refinement (snowballing forward and backward and manual evaluation of the large number of initial results from both databases). The manual stages were repeated to minimize error and bias.
As for the possibility of false negatives, which could cause the exclusion of important studies, we ran the search strings multiple times and during multiple periods while conducting this study, which would reduce the chances of excluding important manuscripts.
As for the focus of the study, this SLR did not exclude non-academic efforts and cited not only scientific and academic publications but also industry solutions (especially in the platform type sub-aspect) to provide comprehensive results.

VI. CONCLUSION
In this section, we highlight this effort's main achievements, explain the study's benefits to different stakeholders, and share our thoughts on ongoing and future work.

A. MAIN ACHIEVEMENTS AND BENEFITS TO DIFFERENT STAKEHOLDERS
As indicated in the abstract, we focused in this SLR on providing two contributions to the topic of IoT capabilities composition and decomposition: i) We contributed a reference taxonomy that researchers and future readers can use to identify/locate components of the topic relative to specific areas of research. The taxonomy frames the different facets of service composition in IoT in three aspects: A formal aspect, a technical aspect, and a QoS aspect. ii) We contributed detailed discussions to fill gaps in the knowledge corresponding to IoT capabilities composition and decomposition by addressing essential and unanswered research questions (RQs) related to the identified taxonomy aspects. Based on the provided answers, different stakeholders can leverage responses to RQs to improve the composition or decomposition processes, enabling better IoT platforms. For example, engineers, developers, and city planners will learn about the various aspects, challenges, and solutions related to the innovation of novel IoT capabilities composition and decomposition platforms. This effort provides valuable guidance on building novel IoT platforms while respecting formal and standard constraints, ensuring technical solutions used are the most suitable and efficient from network performance, process type, and automation perspective. Other benefits include highlighting the importance of AI/ML in improving service composition capabilities or processes and demonstrating the role of service decomposition in ensuring the efficient reuse of capabilities features or enabling efficient computation distribution from the cloud to edge nodes, to mention a few. QoS improvement is another venue where researchers and city planners can leverage this study to enhance scalability, interoperability, and privacy by learning from the challenges and solutions we identified for each QoS concern. This study educates end-users on how the composition of services drives innovation by generating value-added services and making them accessible to the general public, as is the case with well-known platforms, such as IFTTT and Home Assistant. In addition, it highlights general-public concerns that stem from exposing one's capabilities preferences, which could compromise end-users privacy.

B. THOUGHTS ON ONGOING AND FUTURE WORK
While working on this study, an IoT and CPS Composition Framework (ICCF) was proposed [193] to address the problem of rapid prototyping and verifying composite capabilities in the field of smart buildings, with the main contributions made on Formal sub-aspects.
Work on completing the proposed framework is ongoing by studying and improving its technical and QoS sub-aspects based on data in this SLR. Implementing the ICCF framework in the smart building domain was proposed, and measurability aspects were addressed as we suggested a method for measuring well-being or comfort in smart buildings [224].

NIST DISCLAIMER
Certain commercial equipment, instruments, or materials (or suppliers, software, etc.) are identified in this paper to foster understanding. Such identification does not imply recommendation or endorsement by the National Institute of Standards and Technology, nor does it imply that the materials or equipment identified are necessarily the best available for the purpose. Official contribution of the National Institute of Standards and Technology; not subject to copyright in the United States.