Proposal - start [kondor.etf.rs]

Description of work
WP Leader: BGDUNI
T2.1 HW Infrastructure (TL: BGDUNI) – The common idea is to use the standard
hardware for core implementation of this system. That means that most of the system should
run on typical server hardware that is capable to satisfy performance and storage
requirements. The only exception is the specific hardware for the potential acceleration of
certain blocks (DMS) that will be implemented with FPGA technology, if analysis shows that
this acceleration is necessary. Also, in this task it will be considered all hardware devices
(sensor nodes, mobile and smart phones...) that could be either provider of input data for the
system, or just used for interaction with the users (display of information, request for
information). Outcome of this task is important for specification of communication
infrastructure in T2.2 as well as for software specification in T2.3. As a result of activities in
this task, it will be create the report that discusses all hardware devices considered for using
in this project, with specification of hardware requirements necessary for system built and
specific acceleration hardware.
T2.2 Communications infrastructure (TL: BGDUNI) – This system architecture should
support integration with input data suppliers through different communication channels, and
in the same time to provide response to the users via various communication protocols and
standards. This list of communication channels and protocols includes WSN protocols
(ZigBee, Bluetooth, IEEE 802.15.4, or its modifications), mobile oriented services (GSM,
SMS, GPRS, alarms, pagers), Internet services (Cloud, GIS, Finances, Digital Marketing,
public available web services). In the same time it is necessary to publish information through
wide possible protocols and standards (HTML, WML, web services, RDF, REST). Since this
list of communication protocols could be very long, the main objective of this task is to
specify principle mechanism of connecting various data sources (communication protocols
and standards) to our system using plug-in mechanism. Practically, it is a definition how to
interpret received data and to store them to the internal unified format enabled for later
searching and retrieving from higher blocks in the architecture. Similarly, necessary protocols
and formats for publishing customer information should be specified. Typically, this should
include a well known format as HTML, WML, specification for offered web services,
specification for the semantic web structured data, description of the alerting or subscribing
services on certain information through asynchronous web services and similar. In order to
achieve interoperability with other systems, it will be consider formats with semantically
annotated data that is suitable for an easy exchange of information (RDF). The outcome of
this task is in correlation with the results of WP1 (use case analysis) and also with T2.1. and
T2.3. The result of this task is the report with the specification of communication channels
and protocols used for input and output to our system.
T2.3 SW Infrastructure (TL: BGDUNI) – The objective of this task is to specify all
necessary software components and interfaces among them, while considering all software
platforms that could be used. This system consists of several software components each
responsible for different tasks. The common idea for the system architecture is to use service
oriented architecture. But, as a common ground and most likely the most important part of the
whole system is the system integration layer, responsible for integrating of all available
sources of data while storing collected data in the common data format. Experience from the
previous projects (semantic sensor layer - integration of sensor networks in Prosense FP7
project) will help in specification of this part. The idea is to use data format which saves data
values, but also keeps additional information (time, location, and others), and also data about
data types which is stored in appropriate meta data. With this approach, collected data could
be retrieved and semantically searched using an easy and uniform interface, which hides
specifics of the source and format of original data. All relevant parameters could be saved on
this way and used later for processing (tracking of relevant events in the system, user
behavior, usage patterns…). This will be useful for all higher blocks in architecture that
should perform very complex algorithms on gathered data. These complex components in the
system include:
Software agents, responsible for monitoring processes in the system based on the data from
various sources
Data mining system (DMS) that performs various complex algorithms (based on neural
networks, decision trees...) in order to predict requests to the system, input data, and hence
response of the system. If analysis in this task shows that performing necessary algorithms