Functional Model Diagram Clause Samples

Functional Model Diagram. ‌ The functional model diagram is depicted in Figure15: Functional Model and is derived as follows: • From the main abstractions identified in the domain model (Virtual Entities, Devices, Resources and users) the “Application”, “Virtual Entity”, “IoT Service” and “Device” FGs are derived. • With regards to the plethora of communication technologies that the IoT-A ARM needs to support, the need for a “Communication” FG is identified. • Requirements expressed by stakeholders regarding the possibility to build services and applications on top of the IoT are covered by the “IoT Business Process Management” and “Service Organisation” FGs. • To address consistently the concern expressed about IoT security and privacy, the need for a “Security” transversal FG is identified. • Finally, the “Management” transversal FG is required for the management and/or interaction between the different functionality groups. The functional model contains seven longitudinal functionality groups complemented by two transversal functionality groups (Management and Security). These transversal groups provide functionalities that are required by each of the previously discussed longitudinal groups. The policies governing the transversal groups will not only be applied to the groups themselves, but do also pertain to the longitudinal groups. As an example: for a security policy to be effective, it must ensure that there is no functionality provided by a component that would circumvent the policy and provide an unauthorised access. Next, the relationship between the FGs is defined. As can be seen from Figure15, the functional model is a layered model and the main communication flows between the FGs are depicted with arrows. Since the transversal FGs (Management & Security) interface with most of the other FGs, their relationships are not explicitly depicted. In the reminder of this section, each of the FGs will now be described in more detail (with exception of the Application and Device FGs since trying to capture their properties would be so generic that it does not add any value):