26.03.2015 Views

19SafQB

19SafQB

19SafQB

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

6.3 The iCore Functional Architecture 251<br />

Some typical examples for viewpoints are Functional, Information, Concurrency,<br />

Development, Deployment and Operational viewpoints.<br />

However, architectural decisions often address concerns that are common<br />

to more than one view. These concerns are often related to non-functional<br />

or quality properties. The approach that the project is following is to define<br />

special perspectives to address these aspects of a concrete architecture,<br />

emphasising the importance of stakeholder requirements. Therefore we are<br />

define a perspective as a collection of activities, tactics, and guidelines that<br />

are used to ensure that a system exhibits a particular set of related quality<br />

properties that require consideration across a number of the system’s<br />

architectural views, where a quality property is defined as an externally<br />

visible, non-functional property of a system such as performance, security, or<br />

scalability.<br />

A complete description of the IoT-A approach can be found in documents<br />

on the IoT-A web site (www.iot-a.eu).<br />

6.3 The iCore Functional Architecture<br />

6.3.1 General Overview<br />

In its most generic sense, the interaction with an iCore system is initiated<br />

through a Service Request generated for the purpose of activating data-streams<br />

from IoT objects and continuously processing these to support an end-user/ICT<br />

application with a set of processes monitoring a situation and producing alerts<br />

when particular conditions are met. Such processes, derived from service templates<br />

are orchestrated and bound to relevant IoT objects using iCore functionality.<br />

This is composed of the three main levels where the bottom one is<br />

called Virtual Object (VO) level and is meant to semantically and reliably represent<br />

real-world objects, the middle layer is called Composite Virtual Object<br />

(CVO) level and expected to provide the means for simple aggregation of VO<br />

functionality, whereas the top level, called Service Level (SL) is expected to<br />

map availability of underlying CVO/VO features to the needs of end-users and<br />

associated IoT applications.<br />

Figure 6.2 shows the iCore architecture at a first level approximation, where<br />

a Service Request is transformed via the Service Level functionality into a<br />

Service Execution Request, which is then passed to the lower CVO/VO levels<br />

for the selection and activation of appropriate objects needed for satisfying

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!