Internet of Things Architecture

Figure 114 : Service Description MUNICH platform.

The sensing service ̳ObjectInventoryServiceOPtable‘ exposes the Resource
RFIDInventoryOperationTable hosted on the Sensor that observes the
area OperationTable during the operation. The duration is determined by the
Op123Schedule. The output of the service is described in a domain specific
operation-ontology by the class ListOfRFID that defines a list of identifiers the
RFID reader has detected. The service can be invoked by accessing the service
endpoint objInventoryOPtableRestSE that provides a RESTful web
service on the endpoint host optablehost. An HTTP GET method call on port
4355 on the root path ̳/‘ of this host will return the list of identifiers the RFID
sensor has read.

The use case is driven by events using asynchronous communication. Events
are sent to the Event History network resource every time an RFID reader
recognises a change in the number of RFID-tags in its observation area by
using IoT Service storeEvent(event). The Event History resource
provides another IoT Service that allows the subscription to notifications about
the change in the status of towels, e.g. from unused to in use.

The structure of an Event data type is given as follows:

 Origin: {RFID reader instrument table; RFID reader operation table; RFID

reader waste bin}

 Type: {RFID tag gone; RFID tag added; unrecognised tag}

 Time stamp

The sequence diagram below illustrates the interactions between Physical
Entities and Functional Components of the architecture. The doctor takes a new
towel out of the box on the instrument table and uses it in the patient‘s abdomen
located on the operation table. The system detects the move of the towel from
the instrument to the operation table by the disappearance of the respective
RFID tag that is attached to the towel together with the appearance of the same
RFID tag on the operation table. The Event Storage Service evaluates these