For the process of designing the Smart Home system, there are a few key steps covered in this report. First, the problem statement for this project is defined, which includes defining the boundary of the system, the interfaces needed between the system and outside factors, the needs of the customer, the customer’s constraints, and the requirements and specifications defined by the members of the project team. After that, a detailed design is produced. This is where the functions of the system are defined and broken down into simpler functions, and where solutions to carry out these functions are found. There are generally several different possible solutions to implement each function, so analysis is performed to compare these solutions to find the right one for the project. Risk mitigation is performed and a test plan is created in order to ensure
that the construction of the chosen design proceeds smoothly, and that any potential problems are accounted for. The chosen design components of the IoT Smart Home are expanded upon in the component definition and planned build sections. First the design for the hardware is examined, which includes the physical devices
used to construct the IoT network. After that the server software chosen is analyzed, which looks at the server implementation chosen to allow communication between devices in the network. The development of the mobile user interface is expanded upon after that, which includes the mobile platform used and the plans for the capability of the mobile application. The final plan for the implementation of all of these components are then shown in the building plan and design schematics. As the Smart Home is being implemented, testing and analysis needs to be done to ensure that everything is working as it should and is meeting the customer’s needs. This is separated into testing of the software components and the hardware components. Finally, a bill of materials is produced to ensure that the system can be implemented at a reasonable cost, as well as for the benefit of listing out everything needed to begin construction of the Smart Home system.
2 Problem Statement
The proposed project is to design and implement a system that will monitor specified house data to ensure the house remains secure. It will also be able to control specific functions within the house as well. In order to fulfill
this requirement, our system will need to follow certain guidelines described below. It must operate within the specified guidelines, while also still be reliable and cost effective to make.
2.1 System Boundary
The system boundary diagram above shows what can be controlled within the system and what must be interfaced with outside the system. Everything within the system boundary can be designed and configured
easily and minutely. In the diagram there is the Raspberry Pi, which is the development board used in implementing devices within the smart home. There is also the MQTT Server, which handles the flow of data between devices within the Smart Home’s IoT network. The mobile application is the software developed on a mobile device that the user can use to control and receive updates on devices within the Smart Home. The control circuit
describes the system that controls the power provided to the Raspberry Pi, and allows for the use of power from either a battery or a wall plug. Communication between components describes what methods of transmission between devices are being used within the system, such as through the Internet or through wired connections. Internet Protocols describes how data is formatted when sent through the Internet, and for this project involves the use of MQTT. The code used describes what languages the different components of this project are being developed in, such as Java and Python. The sensors represent the devices within the Smart Home that send their data through the Home’s network to provide up-to-date information on the house’s status. The Raspberry Pi boards used can be loaded with whatever necessary software is needed to run Sensors within the Smart Home, and coded with the desired behaviors. The MQTT Server can be configured to restrict
access to certain known devices, and data sent to and from it can be encrypted to preserve data security. The Mobile Application can be coded to interface with the chosen server and control any chosen devices within the
Smart Home system.
2.2 Interface Requirements and Definition
The systems that cannot be directly controlled need to have the appropriate interface to allow the Smart Home to work with them. Data through the Internet has a possibility of being intercepted for nefarious purposes,
so that data needs to be properly secured through device verification and data encryption. The connection to the Internet is not guaranteed, and steps must be taken to ensure that there is a minimum of downtime if the
system loses access to the Internet through WiFi. The backup cellular hot spot connection is not guaranteed to have good reception, and this should be considered when choosing a provider for this capability. For the power
grid, power outages are a possibility, and backup methods of powering devices should be considered. Government regulations will mainly need to be followed for wireless communication, so FCC regulations must be read and understood to ensure that they are not being broken. These regulations should be simple to follow, due to the fact that only WiFi and 4G signals are being produced by the system.
2.3 State Customer Need(s)
The customer for this project is the ECE Department of IPFW. A few elements are highlighted within the project proposal which guided the development of the design of the Smart Home. The central component of this
proposal is the emphasis of connectivity of the Smart Home over the Internet through an Internet of Things style network. All the devices within the Smart Home need to have a connection to the Internet to allow a remote user to receive information on the state of the house and control devices within it.
2.4 State Customer-Defined Constraints
There are several restraints listed within the ECE Department’s project proposal. In terms of cost a budget of $300 dollars is to be used in the construction of the Smart Home platform. The time constraint is that this
system should be implemented before the end of the fall semester of 2017 at IPFW. Certain sensors need to be implemented in the system, which included detection of gas, humidity, temperature, and water leakage, as
well as control of house lights and power outage detection. Systems for maintaining Internet connection in areas where WiFi are unavailable were also required, which involved the ability to create a cellular connection. The ability to connect to the Smart Home through a mobile device was one of the more important requirements for this project.
2.5 Requirements and Specifications
Building off of the customer’s requirements and restraints, the project team needed to create more concrete goals involving data usage system response time. The latency of messages sent between devices within the
Smart Home and a user’s mobile device should be fairly low, generally less than a second. The data sent from the devices also shouldn’t exceed more than 10 MB per hour to prevent excessive cost of data usage and
slowdown of wireless networks overall. To ensure consistent connection, a 4G hot spot module will be attached to the device control board within the Smart Home that will transmit through the 4G LTE network when WiFi
is unavailable. There will also be an attached circuit to switch to battery
3 Detailed Design
The detailed design is the current plan for the development of the Smart Home, where the functions that the system are expected to perform are broken down and solutions to carry out those functions are considered.
These are described as Functional Requirements (FR) and Physical Solutions (PS) respectively. For each FR several PS’s are analyzed by comparing strengths and weaknesses to determine what is the best way to carry
out each function.
3.1 Product Design Map
The top level of this decomposition shows the most basic functions that the Smart Home needs to work. These include the ability to know the status of the house through the use of sensors, the ability to control aspects of
the house through a mobile application, and the ability to connect all of the components together within a network. The solutions to these functional requirements make up the basis of the Smart Home system.
3.2 Conceptual Design Alternatives
For design alternatives we focused on the high level FR’s, and chose different PS’s that could meet the same needs. The reason for this was the higher level PSs have more weight in the overall project than the lower ones do. Having a problem with a top level design is going to cause many issues once the building starts, and having an alternative ready right away, in case of an error, can help prevent the project from falling behind schedule.
For FR1.1 there exist a few choices on how to connect devices in the Smart Home to the IoT network to allow measurement of data and control over the devices. All of them involve different types of control boards running the appropriate software. The alternatives examined were the Raspberry Pi, TI Launchpad, and the Arduino Yun.
FR1.2 involves choosing server software to allow control over the connection between devices in the IoT network through the Internet. Two alternatives examined were the Mosquitto broker and a cloud service called
PubNub. These both use the MQTT message protocol which is considered ideal in an IoT system.
FR1.3’s alternatives were mainly a choice in which mobile platform to develop on, but it also involved choosing which language to code the application in. The main choices were developing on either Android, Windows,
3.3 Criteria for Selection and Testing Among Alternatives
The Raspberry Pi was the board chosen for the implementation of the Smart Home, and when choosing a board to develop the system’s devices on, several important factors are considered. For one, as opposed
to boards such as the Arduino Yun, multiple processes are able to run at once on the Raspberry Pi. There is also a wide array of libraries available for Python development on the Raspberry Pi, allowing for simplification of
implementation. The server software Mosquitto is chosen over PubNub for several reasons. Mosquitto is open-source, and is attractive due to the fact that developing with it doesn’t incur a cost and can be used flexibly,
but it should also be noted that there is generally more work involved in the implementation of it. PubNub is only free for low traffic volume cases, where exceeding a certain amount of connected devices or sent data can
incur a fee. The mobile application platform has several choices for development, and all seem equally good for development. The main factor in this decision is the availability of the platforms for testing purposes. All of
the team members for this project possess Android phones, so that was what was chosen for development. The particular development environment platform was chosen to be Java JDK, and this was chosen due to the
wide array of libraries available for use in MQTT communication through the IoT network.
3.4 Risk Mitigation – DFMEA
For any project, the team should be aware of any kinds of failure the system might go under and there probability of occurrence. Table 1 provides an insight and a guide to identify the probabilities of these expected and unexpected failures. As shown in Table 1: The red region is the defined to be highly likely, yellow region indicating Occasional failures and the green region indicates the least likely occurring failure regions. These probabilities shown are given rankings to give a weight to these failure occurrence probabilities according to their degree of impact on the final design. 10 being the most likely and the most impactful and, the 1 being the least likely and least impact to the design.
The above table was used, in conjunction with table 1 and table 3 to create Design Failure Mode and Effect Analysis (DFMEA) Table. The purpose of this table is to check how an error can be detected. The green section
is for when a detection will always be detected in someway, the yellow for when a detection is not detected and may allow for further errors, and the red section is for errors that are very unlikely to be detected. As with the
other tables the goal is to end with every potential error have a solution that puts the error in the green zone.
For this project, it is necessary to define what different kinds of failure severities are there and what kind of effect they will have on the final design. These answers are on table 3 above to help define them. Furthermore, different failure severities have been assigned rankings which defines their degree of impact on the final design. The most dangerous level at the top indicated in the red region is ”Hazardous without warning”
and this has been assigned a ranking of 10 and the least dangerous level indicated at the green region is ”None” and has been assigned a ranking of 1. According to this table, the higher the ranking the more severe the failure is.
The goal of the project was to keep every design decision into the green and blue areas as much as possible. Any part that fell into the yellow must be monitored closely to ensure a complete failure will not happen. The red and brown areas were avoided at all cost, as the risk is too high to take for this project. Finally, referring to Tables 1, 2 and 3, the team has been able to compute their DFMEA table (Design failure Mode and Effect Analysis). The mobile application can go through 2 kinds of common failure. The first being disconnection with the server and, the second the application freezing in the middle of running. When the application is disconnected from the server, transaction of useful data is stopped and without these data the entire smart system is dysfunctional, hence the severity of this failure is given a 9. Since this failure occurs rarely it has been assigned 3 and detectability is 8 as it can easily be noticed when the system is not running properly. To
help the user of this problem a user notification would be generated saying ”Cannot connect to server”. Next, when the application freezes the user is not able to be in control of the system, as a result the application shuts
itself down. The severity of this failure is logically very high and has been given a 7. It again doesn’t occur often and has been assigned a probability of 3. Detectability of this issue is very easy, the user will just see that the
application is not working and will shut down and hence it has been given a 7. This issue can be improved by shortening the code of the application which takes less processing power.
3.5 Design Verification Test Plan
In order to verify that the design is meeting requirements, an initial test was performed on software and hardware. The testing started with playing around with a sample android application already available on the Android playstore. Main goal of the initial testing was to see if the team can achieve to control an LED with the mobile application. The application was then registered to a specific MQTT server and so was the sensors. The
team achieved connect an LED and a temperature and humidity sensor. The LED and the surrounding control was set as a specific topic and the application was subscribed to that topic. The team was successfully able
to turn on the LED with a ”1” command and turn off with a ”0” command. Also the ”temp” command resulted in the phone application to receive the current temperature and the humidity sensor. All these commands were
run through the sample application on an android device. With achieving positive results from the initial testing, the team was able to grasp a clearer vision of the potential of this design. Further research on the Internet showed the team a couple of similar IOT designs which allowed them to choose this choice of hardware and software to be the final design.
3.6 Design Validation Test Plan
In order to ensure that the final Smart Home design meets the customers needs, some questions must be asked. For one, is the design able to cope up with new up coming technology? The answer to that is yes. There might be future technological advancements for the sensors and hardware. It is highly unlikely to have a new operating system that is more popular than android. Even if there is then building and designing a new application will require the same amount of time to that of an android application. On the other hand, this design is very adaptable to change. If there are more efficient sensors out in the market, the old sensors can easily be replaced and installed. For the server, it is again the same. It will not take a lot of effort to install a new server as well. But any server being more popular than Mosquito is again highly unlikely, as it is already a free lightweight and incredibly fast server. All this, allows the team to call this design a valid one.
4 Component Definition and Planned Build
The Smart Home system can be separated into three main components. Those are the hardware within the Smart Home, the server software that manages the flow of information through the network, and the mobile application for the user. These components all need to be implemented and connected to each other in order for the Smart Home to perform its most basic functions. The specifics of these components will be described in the sections ahead, as well as how their connections are planned.
The goal of the hardware is to collect data, and be able to control the specific functions that are needed. The main piece of hardware used is a Raspberry Pi with sensors. A circuit with a relay is used to switch between
the wall power and a battery back-up in-case of a power outage; this ensures constant power to the Raspberry Pi and allows constant monitoring even when power is out.
4.1.1 Raspberry Pi
For this project the main piece of hardware used is a Raspberry Pi 2. The reason for choosing came from it being able to run multiple programs at once, while other competitive options can only run one program at a time. This allows for faster response time, and lower CPU usages of the Pi itself. A program can be run only when it is called upon, rather than having only a single program that must run every part of the project when a single item is asked to be updated.
The sensors being used are: a camera, motion detection unit, water sensor, gas sensor, sound sensor, a RF transmitter and receiver kit. Some sensors will work together to achieve a goal while others will work
on their own. For example the motion detector will enable the camera to take a video or pictures when it is triggered. The water and gas sensor will each work alone to send a notification in the event of a change in either one. The RF transmitter and receiver kit will be linked to a wireless outlet switch allowing remote access to an outlet and control the power coming from the outlet.
In order to control where and when sensor information is sent, a server is required. The purpose of the server is to relay information between devices connected to the IoT network. The server needs to be capable of connecting to a variety of sensors and mobile devices securely and efficiently.
To meet our goals for server performance, the MQTT protocol was selected. MQTT stands for MQ Telemetry Transport, and it is a lightweight transport-layer protocol using a publish/subscribe model that allows connected devices subscribed to a given topic to be updated whenever information is published within that topic. This is a commonly used protocol in Internet of Things networks and has become an OASIS standard. This message format is very efficient, with each message sent only containing essential information in the couple bytes of the packet. This protocol is ideal for systems where low bandwidth is desired due to the small amount of overhead as well as the method of distributing messages.
Source: Smart House