System Requirements

The scope of system requirements will cover the software architecture. Our aim here is to define system requirements for software architecture needed to implement our framework into an IoT service platform. However, we take into account portability and scalability of software assuming that the underlying hardware can be chosen according to the system load.

Figure 24: Schema of System Requirements

We attempt to define requirements for a software prototype of IoT service platforms that leaves the possibility to be ported or scaled over various underlying hardware architectures. System requirements could be divided into two main software layers: application and persistent storage. The application layer contains the use cases defined for classes and instances of People, Places, Things, and Applications. The persistent storage layer stores the digital information needed for application logic (Figure 24). Each component and its sub component must be layered. In Figure 24, each entry to the system must start from the top layer (Authentication) and must be treated by at least one component on each layer. System requirements for implementation of our framework are further detailed by component.

1. Application

1.1. Authentication. The system must have an authentication layer. The authentication layer must feature user authentication and provide authentication through an Application Programming Interface (API) for Things and Applications. The user interface must allow users to register on the platform. User authentication must allow registered users to authenticate using their login and password. It must also provide password reminder functionality. The authentication for accessing the API module must not use authentication by login and password. The system must prevent Applications and Things to use user credentials.

Applications and Things must use a separated authentication mechanism based on access tokens. The access tokens must be unique for each Application or Thing. Both authentication mechanisms should be implemented over a secure network layer (e.g. Secure Sockets Layer – SSL). Software modules that are below authentication must be accessible only after authentication and should be used over secured channels.

1.2. Things and Applications API. The system must feature a software layer for connecting hardware components over the Internet. Hardware components can be IoT enabled devices (Things).It should also allow external software components i.e. Applications that are executed on networked computers to access digital information stored on the IoT service platform. This component of the system must implement the communication verbs READ and SEND as defined in chapter 4.6.1.

1.3. User Interface. User interface must allow Place Masters to create Virtual Places and Hybrid Virtual Places. In addition, it must provide search function for Virtual Friends, Things, and Applications. It must provide an option to register Virtual Friends, Things, and Applications to any Virtual Place of a Place Master. It must also provide a possibility to remove Virtual Friends, Things, and Applications from any Virtual Place of a Place Master. The user interface must allow Place Masters to see

and monitor the stream of messages exchanged between People, Things, and Applications. It must allow Place Masters to send messages to Virtual Friends, Things, or Applications. The user interface must allow Place Masters to delete their Virtual Places. The user interface must as well allow developers to register Applications, search for Things connected to the IoT service platform and display their API.

The Things displayed to developers must not contain any personal information about Place Masters or People. This software component must implement communication verbs REGISTER and UNREGISTER as defined in chapter 4.6.1.

1.4. Access Control List (ACL) Manager. ACL manager must be a software layer invoked on requests from either user interface or Things and Applications API. It must allow Place Masters to have full control over the virtual instances of Virtual Places, Virtual Friends, and Virtual Things that they register. It must filter and distinguish the role of People in each Virtual Place (i.e. Place Master vs. Virtual Friend). It must equally prevent all People, Things, and Applications to read, update or delete any digital information from the virtual places where these instances are not registered by Place Masters. It must be designed to uniquely identify any Thing or Application by reading their access tokens and finally, it must be designed to uniquely identify People based on their access credentials (i.e. login).

1.5. Socialization Manager. Socialization manager must be a software layer designed to maintain social networks of People, Places, Things, and Applications. It must be designed as a registry for these components. This software layer must map the instances of People, Places, Things, and Applications from and to the persistent storage.

Socialization Manager has to implement the interaction verbs NOTIFY, UPDATE, and DELETE as defined in chapter 4.6.1. It can be used only after passing the authentication, user interface, and ACL layers. It must execute required actions received from user interface in order to record relationships between People, Places, Things, and Applications as defined by Place Masters. This component must generate the stream of messages from persistent storage to the user interface or Things and following data: People, Places, Things, and Applications profiles, messages, Virtual Places and access credentials. It uses at least one database for access credentials and at least one for collections of

instances and messages. Adequate database management system must be chosen in order to be scaled on networked hardware. It should provide high availability and support for big data storage. Collections of People, Places, Things, and Applications must be logically arranged in order to provide consistent and accurate data to the software components in higher layers of the system. Ideally, the data should be stored in the same format as it could be delivered through the Things and Applications API in order to avoid unnecessary data format conversion that could increase system load.

These system requirements define the behavior of the system and its underlying components. They do not address the technical requirements, system performance, or hardware architecture. At this stage, the focus is on a software prototype that should lead to the testing of the framework’s concepts.

Architectural choices will be defined according to system requirements.