## 2 Related Work
### Software Pipeline Frameworks  
It is natural to develop sensor software as a data acquisition/processing _pipeline_ since they typically contain a data source (e.g., a camera), some form of data processing and, often, a network layer (although some sensors are standalone devices that store data locally). There exists a variety of software frameworks for building pipelines in different application domains but none are out-of-the-box a good fit for building a software stack with real-time performance on sensors with edge computing capabilities, in particular, modern SBCs. Internet of Things (IoT) pipeline frameworks (e.g., FIWARE [20]) are mainly designed to work with multiple streams of small data packets, where the computational cost of data serialisation is not a major concern. Other big data frameworks, such as Apache Airflow [33] or Ray [26], are developed for handling large volumes of data across computing clusters, and are not suitable for running in real-time on IoT devices because of large performance overhead and non-trivial compilation steps on embedded systems. Multimedia pipeline frameworks such as GSTreamer [29] are designed for highly-efficient multimedia applications, but their implementation and documentation are difficult to understand for anyone who is not an expert, and thus are time consuming or in some cases not practical to extend to more specialised sensing applications. We elaborate on different existing software pipeline frameworks in the following:  
IoT software frameworks for building sensor runtimes are mainly designed in a light-weight manner, assuming small packets of data, e.g., sporadic IoT events or low volume data streams such as temperature measurements [34]. They do not scale well to larger data streams, such as video processing with machine learning on the edge [35]. FIWARE [20] is an open-source solution with a focus on smart city applications. It makes use of multiple programming languages, and the community provides docker images of various implementations with different run-time requirements. Because of this versatility, extending FIWARE for custom implementation requires full-stack development knowledge of these languages (e.g., Java, Node.js, C++ and Python), which implies a steep learning curve [36]. The limitations of FIWARE have been highlighted by performance evaluations of the platform [37]. Users state a high barrier to entry and the platform shows high performance with low volume event data but introduces latency when operating over larger scale wireless sensor networks. DDFlow [21], a visual and declarative programming abstraction, is a significant contribution to heterogenous IoT networks. Its goal is to provide a flexible programming framework without burdening users with low level hardware and network details, such as load balancing. The runtime interface utilises available resources to dynamically scale and map an IoT application similar to EdgeProg [22]. While DDFlow can be used for multi-modal sensing, the library is very high level and does not currently have the capabilities to facilitate high throughput application pipelines [38]. Other solutions, such as Caesar [23], are either not open-source and lack HW/SW integration, or are simply designed to handle small data loads as is the case with Waggle [25]. In addition, Caesar is limited to activity recognition using cameras as an application only and, while supporting multiple modalities, Waggle relies on the builtin parallelisation and data serialisation libraries in Python, which make it impractical to use for high data throughput applications. The REIP SDK, in contrast, offers multiple parallelisation and data serialisation strategies to best match the application needs (Section 4). Distributed big data frameworks have gained traction and have been under heavy development in academia and industry for their ability to concurrently process large amounts of data.