Before describing the ADDM4RIOTA we will present our definition for Resilient IoT Application that was used to develop it. Because despite the considerable interest from the industry and academia, there is no consensus about one definition. Thus, in view of the resilience requirements raised in the previous section, and also on the definition of IoT as introduced by [16] and on the definition of the Resiliency of system as introduced by [15], we adopt the definition of Resilient IoT application as;

"""Group of infrastructures interconnecting connected objects and allowing their management, data mining and the access tothe data they generate to reach common goals with capability 1) monitoring the system constantly, 2) to detect new and old threats that can damage the system, 3) to protect the application resisting external and internal threats, 4) to recover to stable state and/or adapt structure to work with minimum resources and 5) to memorize all the impacts that threats can cause on IoT Services, Resources and Devices to allow faster and more effective responses to deal with future threats."""

The ADDM4RIOTA was developed aiming to attend this definition and help reduce the difficulty to design of Resilient IoT application. For this, the meta-model proposed brings: i)the main threats described in the literature to speed up the threats identification procedure in the design process; ii) the tactics, constraints and properties of resilience represented as first class to make explicit and allow to capture potential alternative resilient solutions, iii) architectural design decisions principles, such as Issues (IoT Threats), Solutions (Resilient Countermeasures) and Decisions, to support the decision of select or reject resilient countermeasures to mitigate the threats; and iv) Group decision Making principles to driving the way stakeholders make collaborative decisions.The ADDM4RIOTA is divided into four packages. This was done in order to facilitate the understanding and use of the meta-model. The four packages are: Inputs (colorful elementsin dark orange), Issues (colorful elements in red), Countermeasures (colorful elements in green) and Decisions (colorfulelements in yellow). The Figure above depicts all packages, the main elements and the relationships between them. The Inputs package contains classes to represent the elements ofan IoT application domain model such as IoT Critical Objectsthat are affected by IoT Threats. The Issues package formalizes the concept IoT Threats and request Resilient Countermeasures as possible solution. The Countermeasures package describes the concept of a Resilient Countermeasuresthat mitigates IoT Threats. Lastly, the Decisions package formalizes the decisions concept to select and reject a resilient countermeasure for addresses IoT Threats. The followingwill explain in detail each package.

Input Package

The Inputs package is described in Figure below. This package defines all ADDM4RIOTA inputs as IoT critical objects. It represents an element that can be affected by IoT threat and was proposed in [24]. These IoT critical objects can be identified in an IoT application domain model. It can be generated by any domain meta-model, such as IoT Domain Model (IoT-DM) and Personalized Monitoring System Domain Model (PMS-DM) [7,20]. Through the Input package we can identify the critical objects in an IoT application domain model identifying the elements in an application that have the highest chance of being affected by a threat and therefore damages the functioning of the system. A Critical Object can be IoT Hardware and IoT Software components[7]. The IoT Hardware components are classified as: Device,Tag, Sensor and Actuator. The IoT software components are classified as: Active Digital Artefacts, Passive Digital Arte-fact, Service, Resource, Network Resource and On-Device Resource. Details about these components can be found in[7, 20]

Issue Package

The Issues package is highlighted in Figure below and has 15 elements. This package brings a set of concepts, entities and relationships that allow describing the main IoT threats that can damage an IoT application. In ADDM4RIOTA a IoT Threat is an action that takes advantage of security weaknesses in an IoT Application and has a negative impact on it. The Motivation and Cause elements describe the IoT Threat. A Motivation why the IoT Threat is a problem, and the Cause of this IoT Threat. IoT Threats can originate from three primary sources: Nature source, Hardware source and Humansource. In [38] can be found a detailed description of each of these threats type that compose the enumerations: Table 1 - Physical Layer Threat Type (PLTT), Table 2 -Nature Threat Type (NTT), Table 3 - Hardware Threat Type (HTT), Table 4 - Network Layer Threat Type (NLTT)and Table 5 - Application Layer Threat Type (ALTT).

Countermeasures Package

This Package is highlighted in Figure below and has 24 elements. It brings together a set of technologies available to implement the resilience properties that enable an IoT application to handle an IoT Threat. This Package has five fundamental properties that allow addressing the definition of Resilient IoT Application that are: Monitoring, Protections, Detection, Restoration and Memorization (knowledge base). A Resilient Countermeasure can be classified in four properties: Monitoring, Protections, Detection and Restoration and interacts with knowledge base.

Monitoring:

it performs monitoring on Operational resources, Data flow, Energy Efficiency components and help to protection, detection and restoration to work. The Monitoring of IoT application can be performed by a Gateway. The monitoring data will be stored in Knowledge base forother resilient solution to retrieve and perform the necessitated operations. The monitoring of IoT Application through IoT gateways can be performed using Autonomic Architectures (the architectures that compose the enumeration called Autonomic Architectures kind enumeration are described in Table 15 - Autonomic Architecture Kind (AAK)).

Protection:

it can be implemented through 9 tactics of Redundancy and 29 Self-protection techniques. The Protection update knowledge base when, for example, get a new attacks and retrieve old situation from knowledge base. The tactics that compose the enumeration Redundancy Technique Kind and Self Protection Technique Kind are described in Table 7 - Redundancy Technique Kind (RTK) and Table 8 - Self Protection Technique Kind (SPTK).

Detection:

it detects the vulnerabilities and the weak points of the Resilient IoT Application. The processes of detection is performed by monitoring through the implementation of Detection Techniques (all techniques that compose the enumeration Detection Technique Kind are described in Table 14 - Detection Technique Kind (DTK)) to find some IoT Threat. Detection techniques are algorithms and the vulnerabilities detected will be stored inthe vulnerability list in knowledge base for future Protection and can be utilized by Restoration resilient solution in order to perform restoration and optimization of Resilient IoT Application.

Restoration:

the main responsibility of it is to bring backthe Resilient IoT Application to its normal state after catastrophic situation. The restoration will perform Self-Healing on weakened parts of the Resilient IoT Application and empower them to perform their regular functions. The weak parts will be detected by the detection resilient solution with the help of the monitoring resilient solution. Self-Configuration will be used to reconfigure the components when workload is increased to achieve optimization of Resilient IoT Application. Self-Optimization will also be used in case when full restoration is not achieved by the restoration. The Restoration resilient solution can implement Disaster Recovery Strategy like backup and contingency plans that are the best approaches to secure systems against natural threats. Finally,the restoration resilient solution can implement too Fault Recovery techniques important to deal with IoT Threats in WSN. All techniques to implement Restoration compose the enumeration: Self Configuration Technique Kind, Self-Healing Technique Kind, Self-Optimization Technique Kind,Fault Recovery Technique Kind, Disaster Recovery StrategyTechnique Kind are described in Table 9 - Disaster Recovery Technique Kind (DRTK), Table 10 - Self Configuration Technique Kind (SCTK) , Table 11 - Self Healing Technique Kind (SHTK) , Table 12 - Fault Recovery Technique Kind (FRTK) and Table 13 - Self Optimization Technique Kind (SOTK).

Decision Package

The Decision is taken of Rationale form. Designers must associate a Rationale to each design decision in order to keep track of the reasons behind the decision in order to allow that the Stakeholders achieve its Concern. A Decision contains attributes such as description, state (that represents the current state of the decision, for example, idea, tentative, decided, rejected, etc.), timestamp specifying when Decision was created . Each decision can be related to some other decisions. Examples of relationships include: constrains, enables, conflictsWith, alternative, exclude, overrides, dependOn, relatedTo, subsumes and boundsTo. The comprises relationship exists when an high-level decision is composed of a set of more specific decisions; differently from all the other relationships (which are represented as simple reference), it is represented as a composition reference because the lifetime of comprised decisions must correspond to the lifetime of the comprising decision. A Group represents a collection of stakeholders (e.g., software architects, developers, designers, testers, users, etc.) who have regular contact and mutual influence when working together to achieve a common set of goals. The memberships relationship represents the participation of each stakeholder in the group. Each group member can have also a set of Concerns identifying the key design problems related to IoT Threat. Basically, concerns can be seen as the means to evaluate a set of possible decisions in order to choose among a set of alternatives to addresses the IoT Threats. For example, typical concerns can be “low user effort”, “security”, “simplicity”, “low cost solution”, and so on. In our case the Concerns are focused on get the best decision to solve an IoT Threat. A group or group member can be either responsible for or interested in a set of design decisions. GroupMemberships connects the stakeholder with a particular group. It would be useful to account for hierarchy or expertise differences among stakeholder, i.e., a ranking. Indeed, it would be useful to prioritize stakeholders based on some criteria like seniority or expertise to make the process more robust. However, since some organizations may have flat structures where all stakeholders enjoy equal priority, the ranking attribute is optional. Also, each member of a group can optionally have a role within the group she belongs to; this attribute can be used by a reasoning engine so that it can prioritize decision makers, senior architects, and so on. This attribute is kept optional so to limit the amount of mandatory information. Each stakeholder can belong to multiple groups. A GroupDecisionSession represents a single continuous meeting, or a series of meetings of a group of stakeholders. Each group decision session has a set of objectives because in any decision making exercise, every member needs to be clear about the objectives before the start of the process. In addition to the set of established objectives, the main outcome of a group decision session is the set of design decisions identified, modified or, more in general, related to it. Also, each group decision session has an history log and a set of references in order to allow session members to carefully record all the activities performed. Conflicts are inherent to Group Decision Making (GDM): appropriate conflict resolution strategy could be applied to the used software architecture decision making method [39]. In this context, the conflictResolutionStrategy attribute uniquely identifies the conflict resolution strategy applied in the group decision session. The most popular strategy is the collaborative style of conflict resolution [40]. Stakeholders participating in GDM shall be enabled to indicate preferences. For example, in [41] the alternative scenarios are scored and the stakeholders vote the alternatives and the voting method has been chosen to enable the groups to arrive at consensus in a timely manner. According to this, each group decision session has a preferenceProcess attribute describing the process used for recording the preferences of each stakeholder. Preference processes can be based either on a ranking, scoring, or a rating system. The GDMMethod is referenced by a group decision session and it represents the specific architecture design decision method used for evaluating the various design decisions considered during the session. Some popular GDM methods are: Brainstorming: This is a semi-formal method were participants discuss the issues and brainstorm solutions. The discussions are moderated by a leader. Voting: Participants indicate their preferences on a pre-determined set of alternatives through votes. Nominal Group Technique (NGT): This technique involves allotting time to individual participants to think and present their viewpoints (preempting the others from speaking) and then discussing as a group. Delphi Technique: This is an iterative process involving several rounds of discussions with each round involving feedback from previous iterations. Analytic Hierarchy Processing (AHP): This is a structured technique that involves pairwise comparison of alternatives and criteria and weighing the alternatives based on the criteria before making a decision. GDM methods can be shared across different group decision sessions within the whole organization/project. Each stakeholder participating in a group decision session is linked to the session itself via a SessionMembership element. This intermediate element keeps track of the satisfaction level that the stakeholder achieved during the session. Indeed, literature points that satisfaction of group members is a key factor [39] since it is an important indicator of the success of the GDM process. Moreover, a description of the experience of the stakeholder while participating to the group decision session is recorded, together with an indication of their preferred choices. Preference refers to the preferred choice of alternative/decision for a stakeholder. A Preference is composed of its cardinal value (so that it can be easily compared with respect to the preferences of other stakeholders within the group) and its description. Also, stakeholders often come with certain preferential biases before the GDM process [42] and during the discussion as more and more information is exchanged, stakeholders tend to revisit their preferences; along this line, the preGroup boolean attribute is true when the preference has been expressed before the group decision session. A Decision is made selecting a Resilient Countermeasure that should be used to solve the described IoT Threat. How described before a Resilient Countermeasure can be of four types Monitoring, Protections, Detection and Restoration