7.2.1.1 Security

Security is a key quality attribute of every distributed system [4] and guarantees that the things and services are secured from un-authorised access, and data and messages are secured from being corrupted while transmission and are persisted according to required security parameters of a specific system. The security quality attribute for an IoT subsystem and a WoT system can be broken down into three main sub-attributes: (i) Access Control, (ii) Communication Security and (iii) Persistence Security. Access Control guarantees that things and services are accessible only by authenticated client services to protect these from unauthorised access and only the allowed level of information is revealed to the clients based upon their access level in the authorization hierarchy. Communication Security guarantees that the data and messages are encrypted while transmission so that these are protected from stealing. Persistence Security guarantees that the data is stored in an encrypted manner both by the things and by the services, and encryption keys are securely handled so that even if some of the things or services are confiscated, the data is protected from malicious use.

7.2.1.2 Availability

The WoT concepts primarily focus on the application layer [1] and require to guarantee the availability of all the composite things and services. Hence, an IoT or a WoT architecture has to ensure smooth operation of the services even if some of (i) the things and services are out of operation, (ii) the communication channels are broken or (iii) the things, services and communication channels are attacked by an insider (e.g., by any of the thing or service) or by an outside (e.g., a hacking attack or a denial of service attack [7]). Availability is also important from deployment perspective. If the things and services in IoT cannot perform the desired operation, then new things are to be activated and new service instances are to be deployed and instantiated on hosting infrastructure.

7.2.1.3 Scalability and Elasticity

Scalability and elasticity of an IoT or a WoT system is required to complement the availability. The number of active devices in an IoT system can vary and the data that is generated by the devices can increase or decrease. As a result, the corresponding server side services need to be scaled up or down. There can be a large number of things and services in a WoT system as well as the users that interact with the things and services. A highly scalable and elastic infrastructure such as Infrastructure as a Service (IaaS) cloud can be viable option to achieve scalability and elasticity [4] in the WoT systems.

7.2.1.4 Reliability

Guaranteeing reliability of the things and services in an IoT or a WoT system can play a vital role in adoption of the system. Reliability requires that a specific configuration of the things and services in a WoT system can be able to complete the desired operations and the produced results are correct. Therefore, an IoT or a WoT system should allocate services to the things in an IoT mesh according to the requirements of the operations and should have redundancy mechanisms in place to guarantee variability of the produced results. Fault tolerance approaches such as Byzantine Fault Tolerance model can be used for reliability verification [8].

7.2.1.5 Multi-tenancy

Multi-tenancy is an important characteristic of the system and requires providing isolation among the data and services belonging to different tenants (user groups). Multi-tenancy is handled in different manners including: (i) Access control based on the tenants' roles that they can perform in a system and the type of data they can access [9,3]. (ii) Sharing services among the tenants having similar quality constraints [10]. (iii) Scheduling tasks on the resources that can achieve the desired quality [11]. (iv) Periodic monitoring of the services for their suitability to the tenants' requirements [12]. An IoT or a WoT system has to comply with the multi-tenancy requirements.

7.2.1.6 Interoperability

Interoperability quality enables a software system to work with other software systems [13]. Interoperability of things and services in a WoT system is important to facilitate their composition and provisioning. Interoperability is also critical from infrastructure perspective that is used to host the services in a WoT system. For example, if heterogeneous IaaS cloud infrastructures are used to host the services, their capability to host the IoT subsystems constituting a WoT system is important so that an appropriate IaaS cloud, which matches the security and reliability constraints can be chosen. A number of architecture tactics can be adopted in the IoT subsystems architectures and the corresponding WoT system architecture to support interoperability. For example, proxies and services' facades can hide the internal details of how the subsystems are deployed and migrated among IaaS clouds during their life-cycle [14]. Autonomous conversion of information associated with an IoT service semantics into service syntax can facilitate services' interoperability [15]. Adopting a layered architecture approach can be useful to compartmentalise the IoT subsystems' services and to provide interoperability among the services belonging to similar layers of the federated clouds [16]. A strategy to delegate tasks to the optimal services configuration and dynamically allocating hosting IaaS cloud resources can facilitate the process of achieving interoperability [17].

7.2.2.1 Selecting an Appropriate Reference Architecture

While selecting the RA as a tool kit for standardization that is to be used as a baseline for analysis and design of the concrete IoT subsystem architectures, the first step is to analyse the essential quality requirements of the domain. Once the essential quality requirements are determined, all of the candidate RAs should be analysed for (i) whether a RA under consideration support the essential quality requirements or (ii) whether the RA supports addition of new components or modification of existing components corresponding to a specific quality attribute without impacting the overall quality of the architecture (for scenarios) when there is no direct support for a specific quality attribute in the RA. A RA providing a closest match with respect to the above mentioned conditions can be selected for the analysis and design of the IoT subsystems' architectures.

7.2.2.2 Using the Selected RA for Analysis and Design of Concrete IoT Subsystems and WoT System

Once a RA is selected, it can guide the analysis and design of the concrete architectures of the IoT subsystems, which then can lead to the concrete architecture of a WoT system. First step after selecting a RA is to analyse it for its adoption for the given IoT domain with respect to the core business and quality requirements. The analysis includes identification of the RA's subsystems and components that can be incorporated in the concrete architecture. There can be three cases for the analysis: (i) Identification of the RA elements (subsystems and components) that can be incorporated in the concrete architecture without tailoring and modification. (ii) Identification of the RA components that can be incorporated in the concrete architectures but require tailoring. (iii) Identification of the elements that are not presented in the RA but are needed because of the IoT domain and critical quality requirements.

Based upon the analysis, individual IoT subsystems can be designed using the IoT RA. Then the IoT RA along with the additional elements that are incorporated in each of the IoT subsystems, are used for the design of the concrete WoT system's architecture, which can facilitate interaction of things and services across multiple IoT subsystems. While designing additional elements (which are not presented in the RA) for the concrete architectures, existing design patterns [19] and architecture styles as well as architecture patterns can be used [20].

7.3.2.1 Using IoT RA Architecture for Design of Concrete IoT Subsystems for Smart Homes

After selecting the IoT RA, the students groups were asked to use the RA as a baseline for the design of the concrete IoT architectures for the specific business and quality requirements (as elaborated in Section 7.3.1). Following design strategies were adopted for designing the concrete architectures.

• IoT RA layers were analysed to identify main layers of the IoT subsystems' architectures.

• The components of the IoT RA that could be directly adopted in the concrete IoT architectures were analysed and adopted. For example, Authentication and Authorisation components from the Security layer were adopted directly into the concrete architectures.

• The components that required tailoring or specialisation were modified according to the requirements of the target concrete architectures. For example, Communication layer of the IoT RA is used to identify the components for end-to-end communication, network communication and hop-to-hop communication. These components were needed to have specializations for the specific types of communication protocols that were to be used by the concrete IoT architectures.

• Additional components were added for the layers of the IoT RA that were only providing a skeleton of the architecture. For example, components for the specific services were added into IoT Services layer and components for managing and deploying services were added into Virtualization Management layer.

• To incorporate the desired quality attributes in the concrete IoT architectures, multiple architectures styles and patterns [20] as well as design patterns [19] were used.

Fig. 7.3 shows a representative concrete IoT system architecture for management of the devices in the smart homes designed to achieve business and quality requirements related to devices management in the smart homes. As shown in the figure, the layers and components from the IoT RA have been tailored and modified. Devices layer provides interfaces to connect to and receive information from different types of the sensors. This layer also provides interfaces through which devices and actuators in smart homes can be controlled. Communication layer includes components for Http and TCP/IP, Mobile communication (such as 4G) and Sensor Framework (to accommodate device specific communication protocols). Other layers of the architecture interacts with the devices via Communication layer.

Security layer includes components for Authentication, Authorization, Integrity verification, Confidentiality handling of the data and secured collection of data from the devices (via Device Management component). IoT Service layer includes components corresponding to specific devices in the smart homes. For example, House Access Control component manages access to the home by the householders, Climate Control components control indoor temperature and Pet Feeding components put food and water into pet food utensils. Virtual Entity layer manages devices (turning the devices on and off), data and event logging, and recovery of system configuration if some of the devices malfunction. IoT Process Management layer handles definition and execution of the rules and processes for management of the smart homes. Management layer provides Graphical User Interfaces (GUIs) and tools, which users can use to manage and control the devices.

Fig. 7.4 shows deployment configuration of the IoT subsystem in a distributed arrangement, in which the components are hosted on in-house infrastructure as well as on external hosting platforms to adequately handle system failure scenarios. The devices and sensors can be connected to only in-house components. The communication between internally hosted and externally hosted components is filtered through a firewall to protect the locally hosted subsystem from undesired access. Connection to the external systems (e.g., online stores for ordering of the items) is managed by externally deployed components to minimize internal system exposure to the external world.

A number of architecture and design patterns were used to achieve quality attributes. Table 7.2 lists commonly used architecture and design patterns in different IoT subsystems.

7.3.2.2 Web of Things Architecture to Manage Constituting IoT Subsystems

Contrary to concrete IoT smart home architectures, which focus on providing different types of smart home services, connectivity with the respective devices and sensors; Web of Things (WoT) architecture focuses on the application layer [1]. Fig. 7.5 shows a high level view of the WoT system architecture designed to support smart home IoT subsystems. The WoT system architecture was designed using concrete IoT subsystem architectures and abstracting the application layer. The WoT system architecture focuses on provisioning of the IoT subsystems' components and services on the suitable hosting infrastructure, provide interfaces for interaction of the subsystems with external systems, managing Quality of Service (QoS) [4] parameters that are used for provisioning and composing IoT subsystems to provision a system configuration that can satisfy desired business, functional and quality requirements. The concrete IoT subsystems can either be hosted using a WoT system or can be managed using a WoT system.

The WoT architecture presented in Fig. 7.5 was designed following separation of concerns and layered architecture approaches [20]. The architecture has three interface layers named as IoT Devices Management Interfaces, External System Interaction Interfaces and WoT System Management Interfaces. IoT Devices Management Interfaces are used to receive input from the sensors of an IoT system and controlling devices and actuators. For example, in an IoT subsystem used for temperature control in a smart home, the hosted components and services can receive temperature readings from temperature sensors and can turn on heating or cooling system accordingly. External System Interaction Interfaces are used to connect hosted IoT subsystem services with external systems. For example, in an IoT smart home subsystem for security management, the subsystem interacts with emergency police services and notify home owners in case of a break-in or burglary. WoT System Management Interfaces are used to define tenants, their desired QoS parameters and specify Service Level Agreements (SLAs) [4] of the IoT subsystem.

The core WoT system components are classified into two categories: (i) the components that are responsible for IoT subsystems selection and their composition for desired QoS parameters and (ii) the components that are responsible for the provisioning of the subsystems' components/services on dedicated or virtualized infrastructure. Profiler and Matchmaker component maintains profiles of all the components/services of the hosted IoT subsystems using Profiling Ontology Manager, autonomously compose components/services and build on-the-fly interfaces using Autonomous Service Composer and Facade Builder. Ontology meta-models and service selection ontologies [25] can be used for profiling of the components/services. The interfaces are exposed via IoT Services Facade and Sensors or Actuators Data Input/Controller Interfaces intermediate layers. Multi-tenant QoS Manager is used to maintain desired QoS parameter for each specific tenant so that the services can be composed and provisioned accordingly. Deployment and Execution Manager is used to deploy the IoT subsystem components on either dedicated or virtualized infrastructure (e.g., IaaS or PaaS clouds [4]). Deployment and Execution Manager can be tailored using the RA for services selection and deployment on the cloud [25]. For cases in which some components/services of an IoT system are partially deployed on in-premise infrastructure and partially on off-premise infrastructure, the locally hosted and remotely hosted components can interact via IoT Services Facade.

7.3.3.1 Organization of the Evaluation Sessions

Evaluation sessions for the evaluation of the IoT subsystems' architectures were organized in a way that stakeholders involved in the design of an IoT architecture covering one part of the domain (business requirements), evaluate IoT architecture designed to satisfy another part of domain (business requirements). For example, as presented in Table 7.1, Group 1 focused on IoT subsystem for management of devices and appliances in smart homes to have efficient utilization of electricity and water, Group 2 focused on IoT subsystem for safety management and fire extinguishing process in case of a fire incident, and Group 3 focused on IoT subsystem for access control and security of the smart homes. Group 1's architecture was evaluated by Group 2, and Group 2's architecture was evaluated by Group 3 so that Group 2 can have insight to both of the device management and security subsystems. The architecture design documents were shared with the group who was to evaluate the architecture before the evaluation session. For example, Group 1's architecture documentation was shared with Group 2 and Group 2's architecture documentation was shared with Group 3.

7.3.3.2 Architecture Evaluation Activities

Architecture evaluation activities consisted of three stages. (i) Before the evaluation session, the groups prepared a short architecture evaluation questionnaire on quality attributes considered in the architecture design, key architecture design decisions, strengths and weaknesses of the design decisions, sensitivity and trade-off points, and risks and non-risks in the architecture [26]. (ii) During the evaluation sessions, the group whose architecture was evaluated presented the architecture while the group who was evaluating the architecture asked questions based upon their initial preparation as well as from integration perspective of their own architecture. During the architecture presentation, design artefacts were analysed for evaluation of the IoT subsystem architectures as well some new artefacts specific to architecture evaluation such as architecture utility trees [21] were generated to present architecture design decision corresponding to quality attributes. During the architecture evaluation sessions, sensitivity points, trade off points, architecture risks and architecture non risks were discussed. (iii) After the individual architecture evaluation sessions, a joint session was conducted in which each group briefly presented their IoT subsystem architecture, quality attributed those were considered in the architecture and feedback it received during the individual architecture evaluation session. Each group member also prepared a written report on the evaluation of the architecture that the group member had evaluated in the architecture evaluation session. The report was shared with teaching staff, who was responsible for design and analysis of the WoT architecture. Table 7.3 shows commonly reported missing quality requirements, risky design decisions, sensitivity and trade-off points, and common improvements suggested in the IoT subsystem architectures during the evaluation sessions.

7.3.3.3 Improvements in IoT Subsystems Architectures

All the groups improved IoT subsystems architectures of their respective subsystems based upon the changes suggested during architecture evaluation sessions. While improving the architectures, the findings from the individual evaluation sessions as well as joint follow up evaluation session were considered (as described in Section 7.3.3.2). A change log was maintained by each group to track (i) what changes had been made in the architecture, (ii) what was the source that triggered the change (i.e., feedback from individual evaluation session or finding from joint session) and (iii) traces to the relevant place of the architecture documentation where changes had been made.