Keywords

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

A major goal of this Guidance Chapter is to provide guidance for system architects. In other words, we aim at explaining the usage of the IoT ARM. One of the major focus areas of this guidance is the derivation of domain-specific architectures from the ARM. For other potential usages of the IoT ARM see Chap. 3. The structure of the technical part B of this book is depicted in Fig. 5.1.

Fig. 5.1
figure 1

Chapter structure for the guidance to the ARM

Full size image

On about 250 pages, this book provides a technical description of the IoT ARM together with multifaceted guidance to the user of the IoT ARM. In the various chapters, we cover various interests of the user, such as generating architectures by aid of the IoT ARM (Chaps. 6, 11 and 12), and how to use the IoT Reference Models presented in Chap. 7. We also shed light on how other IoT architectures relate to the IoT ARM (Chap. 12 sections about reverse mapping ETSI M2M, EPC Global, Ucode, BUTLER), and we also illustrated, how already existing systems can be mapped onto the IoT ARM (Chap. 12, Sect. 12.6). Notice that by its very nature this part of the book is not an insulated part of the IoT ARM, but it provides many pointers back to the IoT Reference Model (Chap. 7) and the IoT Reference Architecture (Chap. 8 including Carrez et al. 2013). Also notice that while many of the Sections of the Chapter are oriented toward the generation of concrete architectures, they can also be consulted when using the IoT ARM along any of the other avenues listed in Chap. 3. One example is Chap. 6, Sect. 6.9, which covers the design-choice process for translating qualitative requirements into view requirements. This process is not only of importance for the generation of concrete architectures but comes also to pass when identifying the differences between architectures (Chap. 3, Sect. 3.5), outlining avenues toward interoperability (Chap. 3, Sect. 3.6), and generating system roadmaps (Chap. 3, Sect. 3.7).

1 Chapter Structure

As you can see in Fig. 5.1, the technical part of this book consists of seven chapters in total. The starting point to guide and architect through the development of concrete architectures based on the ARM is Chap. 6, “Process”. Chapters 7 and 8 describe the ARM specification by their IoT Reference Model and IoT Reference Architecture. Adjacent to Chap. 7, “IoT Reference Model” you will find the Chap. 9, “Reference Manual” in which the usage of the respective models is explained further. For guidance on the IoT Reference Architecture Chap. 9 provides material about the usage of perspectives. Typical management and service-centric scenarios are illustrated in Chap. 10, “Interactions”. Chapter 11, “Concrete Architecture” illustrates the process of creating a domain specific concrete architecture along the process described in Chap. 6 for an example use case. The technical part of this book is concluded by Chap. 12, “Testimonials” that contains reverse mappings to IoT related standards and initiatives as well as an example for a business case evaluation of an IoT enabled use case.

1.1 Chapter 6 “A Process for Generating Concrete Architectures Process”

Provides the reader with detailed guidance on how to derive concrete architectures from the IoT ARM as briefly introduced in Chap. 3. It presents the process steps architects need to follow in order to generate an IoT architecture. That chapter also contains extensive treatises on how to use the IoT-A unified requirements (UNIs; see [Appendix, requirements]); on the common contents of an IoT threat analysis; and, last but not least, on how qualitative requirements are translated into design choices concerning their impact on designing the functional view, the information view, and the deployment view (see Chap. 8). Furthermore it is analysed in that chapter how compatible the presented IoT architecture generation process is with other well-known architecting methods.

1.2 Chapter 7 “IoT Reference Model”

Contains several sub-models the IoT Reference Model is made of, such as the IoT Domain Model, the IoT Functional Model, the IoT Information Model, the IoT Communication Model, as well as the IoT Trust, Security, Privacy Model. The IoT Reference Model provides the concepts and definitions on which the IoT Reference Architecture (see Chap. 8) can be built.

1.3 Chapter 8 “IoT Reference Architecture”

Provides architectural views and perspectives that are relevant for IoT systems. After a short introduction about views and perspectives the chapter presents the IoT Functional View, the IoT Information View and the Deployment & Operation View of the ARM. As explained in Sect. 8.3 of that chapter, the functional view of a concrete architecture typically consists of three viewpoints: functional decomposition (viz. the logical structure), interfaces, and behaviour. In Sect. 8.4.1 of Chap. 8, we provide an overview of the functional decomposition of an IoT system. More information on this logical viewpoint is provided in Carrez et al. (2013) of the ARM [Use cases, sequence charts and interfaces], and the interfaces of the FCs proposed in the functional decomposition are detailed in the same Appendix. That Appendix also contains a rudimentary interaction analysis, viz. illustrations of how the FCs can be interacted with and what the outcome of each interaction is. Chapter 8 also presents the architectural perspectives of the ARM which address quality aspects of the system to be designed, e.g. scalability and availability.

1.4 Chapter 9 “Reference Manual”

Contains reference manuals on the IoT Domain Model, the IoT Information Model, the IoT Communication Model, and the usage of Perspectives. While the Process Chapter outlines, how and when the modules of the IoT ARM (for instance the information model) can instruct the architecting process, the pertinent Section in the Reference Model, viz. Section 7.4, might not contain sufficient information on how to use the models of the IoT ARM. The respective reference manual section complements the guidance on the use of the model.

1.5 Chapter 10 “Concrete Architecture”

In order to further elucidate the guidance provided in the Process chapter, we discuss for a concrete example (pay-by-license-plate parking) how the IoT ARM can be utilised for the generation of a domain-specific architecture.

1.6 Chapter 11 “Interactions”

As can be appreciated by looking at already existing IoT systems, the operation of such systems generally involves sequences of FC interactions. Since the IoT ARM covers a huge range of usage domains and an even larger range of architectures that can be derived from it, it is, unfortunately, beyond our capabilities to detail every possible FC interaction sequence for every possible architecture. However, in order to provide the reader at least with a general understanding of how such interactions can look like, we provide analyses for some few usage scenarios. These scenarios are divided into management-centric and service-centric scenarios.

1.7 Chapter 12 “Testimonials”

As discussed in Chap. 3, generating domain-specific architectures is not the only purpose of an ARM. Another important use is the identification of differences in architectures (see Chap. 3, Sect. 3.5). In Chap. 12 we provide examples for this usage. We looked at two IoT-related standards (ETSI M2M, EPC Global, uCode, and BUTLER), and we also showed how an already existing system, viz. the MUNICH platform, can be analysed with the concepts provided by the IoT ARM. The numerous examples provided in Chap. 12 are meant as an inspiration for how the reader can perform her own reverse mapping of existing architectures onto the IoT ARM. Furthermore, the high degree to which the mapping of our new framework onto already existing architectures and systems actually works is an initial indication for both the comprehensiveness and the utility of the IoT ARM. Additionally Chap. 12 presents a business evaluation example for an IoT enabled use case in the healthcare domain.

2 ARM History and Evolution

This third and final full version (v3) of the IoT Architectural Reference Model builds upon the intermediary version (v2) release end October 2012. Following its dissemination a third feedback process took place and eventually led to this version, where much technical improvements and new material can also be found. Therefore this version is not only a great improvement to the former full version 2 but also a consolidated version that takes into account many received comments (spread among three distinct feedback processes) from external stakeholders, from external technical experts, from internal partners involved into the other technical Work Packages of IoT-A and finally from the projects involved in the IERC AC1 activity chain on Architecture.Footnote 1

Compared to IoT ARM v2, the technical improvements touch all aspects of the Models, Views and Perspectives – respectively found in Chaps. 7 and 8 – already introduced in former versions of the ARM. But it is also worth mentioning that Chaps. 6, 9, 10, 11, and 12 on Guidance has been drastically improved; for instance it provides now also a very precise and comprehensive description of the whole process about deriving a concrete architecture out of the ARM (see Chap. 6). This chapter is a central part of this ARM master piece (300+ pages); it is fully dedicated to making this ARM useful to IoT system developers, by providing best-practice guidance and a large set of Design Choices that provide the system architects with concrete option when designing a concrete architecture out of the IoT ARM. This chapter also provided some elements of validation materialised through a “reverse mapping” exercise, applied to existing IoT Architectures.

As said above, this book is the final version of the ARM from the IoT-A “era”. Still the project reckons that the ARM should live longer than just those 3 years project life-time; ensuring the sustenance of the ARM is therefore a major concern for IoT-A, and something that we definitely must organise and drive.

The IoT ARM is not a “Style exercise” aiming at staying on the corner of someone’s desk. In order to fully reach its objective, which is wide-spread adoption by IoT system architects, the IoT ARM needs to be challenged even more and eventually improved. Only then it will reach its full maturity. From November 2013 onward, the ARM will be taken care of by the IoT Forum (which was officially founded in June 2013), within the “Technology” Working Group. Through this work, we will identify specific ARM “profiles” and make relevant design and technology choices needed to specify the profiles (e.g. “Semantic Interoperability” profile with a number of related technologies, functional components and interfaces, languages, semantic information model, etc.).

It is of the utmost important that industrial actors step into this activity and drive it, as they are the ones which will put the ARM into practice in the context of their own businesses. Sustaining the ARM and specifying profiles is a compulsory step on the path leading to standardisation.