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.
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]
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).
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.
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
[1] Adnan Ahmed and Syed Shahram Hussain. 2007. Meta-model of resilient information system.
[2] Aintzane Armentia, Unai Gangoiti, Rafael Priego, Elisabet Estévez, andMarga Marcos. 2015. Flexibility support for homecare applicationsbased on models and multi-agent technology.Sensors15, 12 (2015),31939–31964.
[3] Qazi Mamoon Ashraf and Mohamed Hadi Habaebi. 2015. Autonomicschemes for threat mitigation in Internet of Things. Journal of Networkand Computer Applications49 (2015), 112–127.
[4] QAZI MAMOON Ashraf and MOHAMED HADI Habaebi. 2015. Introducing autonomy in internet of things. Recent Advances in ComputerScience, WSEAS Publishing(2015), 215–221.
[5] Qazi Mamoon Ashraf, Mohamed Hadi Habaebi, Gopinath Rao Sinniah,Musse Mohamud Ahmed, Sheroz Khan, and Shihab Hameed. 2014.Autonomic protocol and architecture for devices in Internet of Things. In2014 IEEE Innovative Smart Grid Technologies-Asia (ISGT ASIA). IEEE,737–742.
[6] Marco Autili, Amleto Di Salle, Francesco Gallo, Alexander Perucci, andMassimo Tivoli. 2015. Biological Immunity and Software Resilience:Two Faces of the Same Coin?. InInternational Workshop on SoftwareEngineering for Resilient Systems. Springer, 1–15.
[7] Alessandro Bassi, Martin Bauer, Martin Fiedler, and Rob van Kranen-burg. 2013.Enabling things to talk. Springer-Verlag GmbH.
[8] Eleonora Borgia. 2014. The Internet of Things vision: Key features,applications and open issues.Computer Communications54 (2014),1–31.
[9] Ashik Chandra. 2010. Synergy between biology and systems resilience.(2010).
[10] Petar Čisar, Sanja Maravić Čisar, and Branko Markoski. 2014. Implementation of immunological algorithms in solving optimization problems. Acta Polytechnica Hungarica11, 4 (2014).
[11] OpenIoT Consortium et al. 2013. OPENIoT project description.
[12] Dipankar Dasgupta and Nii Attoh-Okine. 1997. Immunity based systems: A survey. In1997 IEEE International Conference on Systems, Man,and Cybernetics. Computational Cybernetics and Simulation, Vol. 1.IEEE, 369–374.
[13] Soumya Kanti Datta, Christian Bonnet, and Navid Nikaein. 2014. AnIoT gateway centric architecture to provide novel M2M services. In2014 IEEE World Forum on Internet of Things (WF-IoT). IEEE, 514–519.
[14] Sofie De Rouck, An Jacobs, and Mark Leys. 2008. A methodology forshifting the focus of e-health support design onto user needs: a casein the homecare field.International journal of medical informatics77,9 (2008), 589–601.
[15] Kemal A Delic. 2016. On resilience of iot systems: The internet ofthings (ubiquity symposium).Ubiquity2016, February (2016), 1.
[16] Bruno Dorsemaine, Jean-Philippe Gaulier, jean-philippe Wary, NizarKheir, and Pascal Urien. 2015. Internet of Things: A Definition Taxon-omy. https://doi.org/10.1109/NGMAST.2015.71
[17] Vangelis Gazis, Manuel Goertz, Marco Huber, Alessandro Leonardi,Kostas Mathioudakis, Alexander Wiesmaier, and Florian Zeiger. 2015.Short paper: IoT: Challenges, projects, architectures. In2015 18th Inter-national Conference on Intelligence in Next Generation Networks. IEEE,145–147.
[18] Kashif Habib and Wolfgang Leister. 2015. Threats identification forthe smart internet of things in eHealth and adaptive security counter-measures. In2015 7th International Conference on New Technologies,Mobility and Security (NTMS). IEEE, 1–5.
[19] Ji-De Huang and Han-Chuan Hsieh. 2013. Design of gateway for mon-itoring system in IoT networks. In2013 IEEE International Conferenceon Green Computing and Communications and IEEE Internet of Thingsand IEEE Cyber, Physical and Social Computing. IEEE, 1876–1880.
[20]Cristovao Iglesias, Claudio Miceli, and David Silva. 2019. A DomainModel for Personalized Monitoring System Based on Context-AwareData Fusion. In2019 22nd International Conference on InformationFusion (FUSION). IEEE, 1–5.
[21]Sidra Ijaz, Munam Ali Shah, Abid Khan, and Mansoor Ahmed. 2016.Smart cities: A survey on security concerns.International Journal ofAdvanced Computer Science and Applications7, 2 (2016), 612–625.
[22] Anton Jansen and Jan Bosch. 2005. Software architecture as a set ofarchitectural design decisions. In5th Working IEEE/IFIP Conference onSoftware Architecture (WICSA’05). IEEE, 109–120.
[23] Chris A Kaiser, Monty Krieger, Harvey Lodish, and Arnold Berk. 2007.Molecular cell biology.WH Freeman.
[24] Bhaskar Krishnamachari and Sitharama Iyengar. 2004. DistributedBayesian algorithms for fault-tolerant event region detection in wire-less sensor networks.IEEE Trans. Comput.3 (2004), 241–250.
[25] Fang-Yie Leu and Zhi-Yang Li. 2009. Detecting DoS and DDoS attacksby using an intrusion detection and remote prevention system. In2009Fifth International Conference on Information Assurance and Security,Vol. 2. IEEE, 251–254.
[26] Huichen Lin and Neil Bergmann. 2016. IoT privacy and securitychallenges for smart home environments.Information7, 3 (2016), 44.
[27] Dong Liu, Ralph Deters, and Wen-Jun Zhang. 2010. Architecturaldesign for resilience.Enterprise Information Systems4, 2 (2010), 137–152.
[28] Ivano Malavolta, Henry Muccini, and Smrithi Rekha. 2014. Enhancingarchitecture design decisions evolution with group decision makingprinciples. InInternational Workshop on Software Engineering for Re-silient Systems. Springer, 9–23.
[29] Friedemann Mattern and Christian Floerkemeier. 2010. From theInternet of Computers to the Internet of Things. InFrom active datamanagement to event-based systems and more. Springer, 242–259.
[30] Enzo Mingozzi. 2013. BETaaS: Building the Environment for the Thingsas a Service. In4th ETSI M2M Workshop.
[31] Pramod Nagalgaonkar, Dhanraj Biradar, and Gaikwad Ranjit Shar-nappa. 2015. Review on Fault Detection and Recovery in WSN.Inter-national Journal of Advanced Research inComputer Science and SoftwareEngineering5 (08 2015).
[32] Peter Parham. 2014.The immune system. Garland Science.
[33] Hunor Sándor, Béla Genge, and Gheorghe Sebestyén-Pál. 2015. Re-silience in the Internet of Things: The software defined networkingapproach. In 2015 IEEE International Conference on Intelligent ComputerCommunication and Processing (ICCP). IEEE, 545–552.
[34] Mojtaba Shahin, Peng Liang, and Mohammad Reza Khayyambashi.2009. Architectural design decision: Existing models and tools. In2009 Joint Working IEEE/IFIP Conference on Software Architecture &European Conference on Software Architecture. IEEE, 293–296.
[35] Jeff Tyree. 2005. Architectural design decisions session report. In5th Working IEEE/IFIP Conference on Software Architecture (WICSA’05).IEEE, 285–286.
[36] Emmanouil Vasilomanolakis, Jörg Daubert, Manisha Luthra, VangelisGazis, Alex Wiesmaier, and Panayotis Kikiras. 2015. On the securityand privacy of Internet of Things architectures and systems. In2015International Workshop on Secure Internet of Things (SIoT). IEEE, 49–57.
[37] Ovidiu Vermesan, Peter Friess, et al.2014.Internet of things-fromresearch and innovation to market deployment. Vol. 29. River publishersAalborg.
[38] ADDM4RIOTA Website. 2019. Retrieved March 7, 2019 from http://addm4riota.labnet.nce.ufrj.br
[39] Suitability of software architecture decision making methods for group decisions
[40] A study on group decision-making in software architecture
[41] Quantifying the value of architecture design decisions: lessons from the field
[42] Pooling of Unshared Information in Group Decision Making: Bi-ased Information Sampling During Discussion