Application-centric development of IoT ecosystems
Many companies are currently struggling with realizing and maintaining cost-efficient IoT ecosystems. A first major reason are expensive implementation cycles due to the lack of high level sensor integration support for application developers. A majority of IoT sensors currently on the market only offers a low level API. Hence, application programmers are confronted with low level connectivity and data format details for each type of sensor they want to integrate. Consequently, instead of focusing on business logic, they need to spend a lot of time/coding on sensor integration and data capturing. Second, problems arise after deployment. In many IoT ecosystems, sensors and actuators need to be replaced from time to time due to limited lifetime or harsh conditions in which they are deployed. Many IoT integrations offer no or at least very limited flexibility when sensors need to be replaced. For instance, a temperature sensor from one manufacturer can often not be replaced by another (more robust or cheaper) one from another manufacturer due to lack of flexibility during system design. Vendor lock-in is often mentioned as one of the major problems in current IoT deployments.
This PhD proposes a paradigm shift in designing IoT ecosystems. Today, a lot of trouble is caused due to sensor centric development. This means that sensors and actuators (i.e. infrastructural components) are selected in a very early stage, and thereafter, designers start to think about wrapping around software applications. However, the end-user applications typically survive the lifetime of low cost, on-the-edge IoT sensors. Moreover, the situation cannot be compared to traditional IT system software in which peripherals are accessible system-wide (i.e. by all applications). Hence, (plug-and-play) support at OS level is logic for PC peripherals (like printer, USB stick, screen…). On the contrary, the scope of IoT devices is often limited to the specific IoT app. Moreover, the diversity of IoT devices is much bigger than the diversity in workstation peripherals. Hence, application level efforts are needed for connectivity, access control… This PhD project focuses on application-centric IoT ecosystem design. This implies that IoT components are only selected in a second step, and feasible architectural decisions must support flexibility with respect to sensor selection and integration after the IoT ecosystem is actually deployed. To realize the app-first approach, the following research questions need to be tackled in this PhD:
What sensor/actuator abstractions are appropriate towards application developers? What are the functionalities and tasks that middleware must provide to support these abstractions?
Can application programmers reason in terms of assets (i.e. objects at application level) instead of sensors? Can the architecture hide the underlying sensor complexity completely towards application developers?
Which are feasible architectural decisions that can lead to increased flexibility with respect to sensor selection/replacements, and hence contribute to vendor lock-in avoidance?
Can the software architecture also support the realization of other non-functional concerns like dynamics and security?