ABSTRACT
Complex software systems like Internet of Things (‘IoT’) platforms are asynchronous in nature and rely on various software and hardware components with varying degrees of reliability and connectivity. This creates a challenge when creating a dependable and robust system. Flow Service Quality (‘FSQ’) Engineering practices have been proposed to address some of these challenges and improve the availability and reliability of these complex systems, but to date there are few examples of such solutions being implemented. In previous work we identified that a commercial IoT mapped very well to an IoT Architectural Reference Model (‘IoT-ARM’). We also investigated FSQ engineering and how it fit into the IoT-ARM. Lastly, we proposed an implementation for how the commercial IoT platform could implement FSQ. In this paper, we will document how FSQ was implemented into a commercial IoT Platform. We evaluate the functional improvements and capabilities it provided to the users of the system through use of a use case and feedback from users of the system.
86 INTRODUCTION
IoT (‘Internet of Things’) (Madakam, 2015) platforms perform many complex Flows involving asynchronous flows of data and control. These Flows include data collection, data archiving, alarms and notifications, report generation, data analytics and providing data visualization. Historically, similar systems were much more rigid, synchronous, and domain-specific. Consider Supervisory Control and Data Acquisition (‘SCADA’) systems. Used primarily in
manufacturing, they provide much the same functionality that the IoT platform provides, the system provides command and control to a manufacturing environment on a private network. In these industrial environments, machines and equipment connect to actuators, programmable logic controllers (‘PLC’) or similar devices. Analog and digital signals from the equipment connect to the PLC allowing for the PLC to hold various readings and information in memory registers. Power to the equipment flows through the PLC allowing changes in memory registers of the PLC to turn equipment on or off. In this environment, the SCADA system connects to the PLC, reads memory registers, and monitors various activities on the equipment. The SCADA system can control the equipment by reading and modifying registers in the PLC. This
environment is quite rigid with the SCADA system being connected directly to the PLC. If the SCADA system loses a connection to the PLC, it will know immediately and can alert operators of the system accordingly. If the SCADA system attempts to write to a register in the PLC and the connection to the PLC is lost, or the write to the PLC fails, the SCADA system knows and can immediately notify the operator that the write failed (Figure 3.1). All activities in the system including such read and write operations are expected to execute in near real time.
87
Figure 3.1 - Depiction of synchronous interaction between a client application and SCADA system.
IoT platforms can provide many similar functions to those a SCADA system provides. Instead of PLCs, IoT platforms tend to connect to sensors and actuators, but in general they have many similarities to a SCADA system. They will collect and archive data to a historian. Perform some analytics, reporting, and allow for visualization of the information by end users. There are differences because IoT platforms are more decentralized with many of the systems services hosted remotely in the cloud. Clients access the system through the Internet using web browsers and mobile devices. This results in a more unreliable and unpredictable environment. Where various software and hardware components in a SCADA system are connected and fixed, within an IoT platform software components, services, and hardware may be added or removed from the system at any time. These components and services could have various degrees of reliability
88
and latency in response. As such, IoT platforms are very asynchronous in nature with loose coupling. This creates complexity when one considers reliability. When an IoT system turns on an actuator it will not return an immediate indication of success or failure. It will return that it received the request, and then determine what services and components are needed to satisfy the request asynchronously… adding "intelligence" to the system. Often there is no mechanism to notify the client that the intended target device received the write, only that the IoT platform successfully received the write value request (Figure 3.2). There is no mechanism to indicate to the system that it should continue to retry the request for a period of time, or use alternate services for satisfying the request.
Figure 3.2 - A depiction of an asynchronous request in an IoT system with no confirmation of delivery.
In such an environment is the need for quality. The actuator will be turned on
89
immediately or within the next 60 minutes? If the actuator is unavailable, is it OK for the IoT platform to continue to try to access the actuator for a period of several hours to satisfy the request? How is the client ultimately notified of the result?
To understand these issues and to provide possible solutions, we applied the concepts of Flow-Service-Quality (‘FSQ’) (Hevner et al., 2009). FSQ identifies that modern software systems, like IoT platforms, are complex in nature. They are asynchronous, made up of many components with varying degrees of performance and reliability. Hardware and software components of these systems are developed by multiple vendors leveraging a diverse set of protocols and standards often without any cooperation or knowledge of each other. FSQ
promotes the idea of an architecture whereby these complex problems are addressed. This paper leveraged previous work to briefly investigate the design of IoT platforms and identify where FSQ capabilities live in such an architecture. It looks at a proposed implementation of FSQ in a commercial IoT Platform. It investigates how the FSQ functionality is being used in the
commercial platform and identifies what customer problems it has addressed. Lastly, the paper reaches out to existing IoT system integrators that use the commercial IoT platform and asks for their feedback on the implementation of FSQ, and how they could leverage it to improve the solutions that they provide to their customers. (This is the research question. It could be in the abstract as well.)
90