Internet of Things – Architecture © - 47 -
While the physical view is of course central to IoT, the overwhelming variety of
physical objects, and also what of their aspects one is interested in, makes it
impossible to present a common model for all IoT use cases. Therefore, the
physical view is not covered in the IoT Reference Model or in the IoT Reference
Architecture. However, it is discussed in more detail in the ―Guidance‖ Chapter,
i.e. in Section 5.2.
Last, but not least, the IoT-centric part of the context view was chosen to be
referred to as IoT Domain Model (see Section 3.3). The background for this
nomenclature deviation is that we (a) see the IoT Domain Model at the focus
point of any IoT architecture and that we (b) want to highlight the difference
from the ―traditional‖ context model with our name choice, and we also renamed
the context view to the IoT Context View in order to highlight this change. How
IoT Domain Model and context view relate to each other is discussed in more
detail in the ―Guidance‖ Chapter (see Section5.2.4).
Notice that the computational view in RM-ODP is the same as the functional
view in the IoT ARM, and that the deployment view in the IoT ARM equals a
combination of the engineering view and technology view in RM-ODP. For a
description of all three views, see [Raymond 1995]. RM-ODP also features an
enterprise view, which addresses the roles of all system users. We recognise
that such a view is important, but we chose a different approach to this topic.
Users and their roles are instead defined in the foundational model of the IoT
ARM, the IoT Domain Model (see Section 3.3). As discussed above and in
Section 5.2, we fuse the IoT Domain Model with the context view. This is then
called the IoT Context View. Thus, in essence, we chose to fuse the context
and enterprise view.
It is important to notice that our choice of views does not imply that others are
not important for the generation of concrete architectures. For instance, the
operational view is a very important one (see [Rozanski 2012]), but it is not
explicitly covered in this document, since the operation view solely belongs to
the implementation of an architecture, and implementation is not within the
scope of the IoT ARM (see Appendix C).
Communication is usually modelled as part of the functional view, but since the
―thingness‖ of the IoT ARM use cases has particular implications for
communications, we chose to introduce two models for functional aspects: the
IoT Functional Model (see Section 3.5) and the IoT Communication Model (see
Section 3.6).
As discussed in detail by Rozanski and Woods, views do address technical
aspects, while stakeholder requirements are more often than not formulated as
qualitative requirements. Their solution to this issue, which we adopt in this
document, is to introduce architectural perspectives [Woods 2005]. These