Department of Computer Science and Engineering The University of Texas at Arlington. Team: Door Keepers. Project: Smart Garage

Transcription

1 Department of Computer Science and Engineering The University of Texas at Arlington Team: Door Keepers Project: Team Members: Anup Patel Santosh Shrestha Wasyhun Tesfaye Adrian Echavarria Last Updated: Sunday, August 3, 2014, 10:25 PM

2 Table of Contents Table of Contents... 2 Document Revision History... 4 List of Figures... 5 List of Tables Introduction Overview Product Concept Project Scope Key Requirements Meta Architecture Architectural Vision Guiding Principles Assumptions Tradeoffs Layer Definition Interface Layer Controller Layer Physical Layer Inter-Subsystem Data Flows Overview Data Flows Producer-Consumer Relationships Interface Layer Subsystems GUI Input Subsystem GUI Output Subsystem Application Networking Subsystem Controller Layer Subsystems Microcontroller Networking Subsystem Microcontroller Subsystem /3/ :25 PM Page 2 of 38 Door Keepers

3 6.3 Data Accessor Subsystem Physical Layer Subsystems Command Signaler Subsystem Door Sensor Subsystem Video Sensor Subsystem Requirements Mapping Operating System Dependencies Interface Layer Controller Layer Physical Layer Testing Considerations Interface Layer Controller Layer Physical Layer /3/ :25 PM Page 3 of 38 Door Keepers

4 Document Revision History Revision Number Revision Date Description Rationale 0.1 4/23/2014 First Draft Combining sections together 0.2 4/24/2014 Update before Submission Last minute updates 0.3 4/27/2014 Subsystem Changes Additional explanations and word changes 0.4 4/29/2014 More Subsystem Changes Further updates, big section 0.5 5/5/2014 Major Changes Section overhauls and corrections 0.6 5/5/2014 Minor Grammar Changes Reading through draft fixing grammar 0.7 5/5/2014 Section Updates More updates to sections 0.8 5/6/2014 More Updates More updates to sections 1.0 5/6/2014 Final Edits Last minute changes 2.0 6/10/2014 Major revisions for Baseline Edits based on feedback and comments 2.1 8/3/2014 Baseline revisions Edits from DDS and feedback 8/3/ :25 PM Page 4 of 38 Door Keepers

5 List of Figures Figure 1: Product Concept... 6 Figure 2: High Level Layer Diagram Figure 3: Subsystem Data Flow Diagram Figure 4: GUI Input Data Flow Figure 5: GUI Output Data Flow Figure 6: Application Networking Data Flow Figure 7: Microcontroller Networking Data Flow Figure 8: Microcontroller Data Flows Figure 9: Database Controller Data Flow Figure 10: Command Signaler Data Flow Figure 11: Door Sensor Data Flow Figure 12: Video Sensor Data Flow List of Tables Table 1: Key Requirements... 8 Table 2: Data Flow Descriptions Table 3: Producer-Consumer Matrix Table 4: GUI Input Public Interfaces Table 5: GUI Output Public Interfaces Table 6: Application Networking Public Interfaces Table 7: Microcontroller Networking Public Interfaces Table 8: Microcontroller Inter-layer Interfaces Table 9: Database Controller Public Interfaces Table 10: Command Signaler Inter-layer Interfaces Table 11: Command Signaler Public Interfaces Table 12: Door Sensor Inter-layer Interfaces Table 13: Door Sensor Public Interfaces Table 14: Video Sensor Inter-layer Interfaces Table 15: Video Sensor Public Interfaces Table 16: Requirements Mapping /3/ :25 PM Page 5 of 38 Door Keepers

6 1 Introduction 1.1 Overview The Architecture Design Specification (ADS) document will provide a high level overview for the architecture of the. The document will primarily focus on concepts such as project scope, layer definitions, data flows, and subsystems. We will be avoiding implementation concepts in this document, but rather focus on explaining the internal design of the and its client server model. 1.2 Product Concept The is a wireless garage management system that allows the homeowner to remotely control functions of their garage from a personal computer or a smartphone application. Users of the will be able to remotely open or close the door, view the status of the door, view an image of the door, and toggle the light. A future expansion of the application would include controlling multiple units. Figure 1: Product Concept 8/3/ :25 PM Page 6 of 38 Door Keepers

7 1.3 Project Scope The primary concept of the system shall be to check if a garage door is open or closed via an internet application. The homeowner should be able to get on their computer or open an Android smartphone application and after logging in, the system should return a status on the door. Whether the door is open or closed, the homeowner will be able to close it if it is open, or open it if it is closed. Basic installation consists of: 1. Plugging in the unit to the home router physically to do first-run configuration, such as associating it with the wireless home network and setting up a user account. 2. Positioning and securing the unit near the garage door opener using the included bracket. The unit is self-contained with a camera. 3. Installation of the wiring to the opener and to the unit's sensors. These sensors will need to be positioned on the garage door opener's track. Once these phases are complete, the unit can be controlled via web browser in the local home network. Use of the app will need additional configuration in the app and unit. 1.4 Key Requirements The following requirements are those that are defined in our System Requirements Specification (SRS) document with a development priority of 1. Number Requirement Description 3.1 Door Status View if the door is open, jammed, or closed. 3.2 Door Control Remotely open or close the garage. 3.3 Mobile Application Control the system from android smartphone Control 3.5 Security Notification The system should notify the homeowner if the garage is opened without using the system. 4.1 Recovery Disk System software delivered on cd. 4.2 Parts Listing user should have a list of all parts required to make the system work. 4.3 Accessing the System should be accessible via Smartphone or Web Application 4.4 Full User Manual Documentation of how the entire system works. 4.5 Quick User Guide Documentation of how the homeowner can quickly setup the system. 4.6 Smart Phone The application can be downloaded from Google Play. Application 8/3/ :25 PM Page 7 of 38 Door Keepers

8 . 5.1 Garage Response Time The garage should respond to commands from the application within 10 seconds. 5.2 Status Update Time The system should update garage status within 15 seconds. 5.3 Camera The system should provide a image feed. 5.4 Door Sensors The existing home garage system should have door sensors in place for obstructions. 6.1 Unit Installation The homeowner must follow instructions to avoid electrical shocks. 6.3 Application Security The application must be password protected. 6.4 Electrical Safety The system must have labels to alert the user of electrical shock possibilities. 7.1 User Manual Documentation on how to install the system. 7.2 Installation/System The installation should not require modification to the existing Setup garage system. 7.4 Software System Update should be deployable by the homeowner. Support/Upgrades 8.1 Customer Facing The system should be usable without using command line or any Interface terminals. 8.3 Customer Device The homeowner will be able to create an account to access the Account system. 8.5 Software System Setup The homeowner will need to download the application and configure it. 8.6 Garage Open/Close The garage should open and close within 45 seconds. Time 8.7 Browser Support The system should work with all browsers that utilize html5 and JavaScript technology. 8.8 Notification Center All notifications should appear within the android notification center with a date and time. Table 1: Key Requirements 8/3/ :25 PM Page 8 of 38 Door Keepers

9 2.1 Architectural Vision 2 Meta Architecture The Door Keepers have taken a simple approach for designing the architecture of the. The hardware component for the homeowner will need to stay basic for easy installation to any garage, and the software component will be designed for easy operation. We have developed our architecture with the following layers: Interface, Controller, and Physical. Through these layers, instructions will be sent from the homeowner through the Internet to the and status information will be returned. 2.2 Guiding Principles The guiding principles for the are the following: Simple to Install, Simple to Use, Modularity, Reliability, and Updatability Simple to Install The should be easy to install from the homeowner s point of view. It will have a single connection to the existing home garage door opener, and two lines to additional sensors for tracking the door s status. The unit itself will come assembled with the camera built in, and include a mounting bracket for quick installation near the garage door opener Simple to Use The will have a simple user interface from the start. Once the homeowner has connected to the unit after installation, they will go through a simple process via GUI on a website or an Android application. After they set up their product, they will have a basic GUI interface to operate the functions of the garage Modularity The will be designed so the hardware and software components are independent of each other. If a software update is released for the in the future, it will not affect the hardware itself including operation or compatibility. 8/3/ :25 PM Page 9 of 38 Door Keepers

10 2.2.4 Reliability The should be reliable and responsive. The homeowner should be able to connect to it at any time of the day and check the status of their garage or perform various functions on the garage itself Updatability The will be easy to update for any homeowner. The SD Card will be able to be removed and will contain software for the on it. If the user needs to update, the SD Card will need to be plugged into a computer, and the application will self-update the data on the card. 2.3 Assumptions In order for the Door Keepers to develop the, we will need to assume each homeowner has certain features already in their home or on their garage system. The following is a list of assumptions that the homeowner will need to have: Internet The homeowner must have a high-speed internet connection which will allow the Smart Garage to connect to the external world, and the homeowner to connect to the Smart Garage from outside the home network Internet Router The homeowner must have some form of wired or wireless router to provide internet access to the. The router must also be capable of UPNP or Port Forwarding. If a wireless router is not available, the homeowner must have an Ethernet wall jack available nearby, or a CAT5/6 cable must be run to the unit directly from the router Garage Door Opener The homeowner must have a compatible garage door opener. Supported models will be documented in the user manual. 8/3/ :25 PM Page 10 of 38 Door Keepers

11 2.3.4 Power Tools The homeowner must have a standard 115V outlet for the unit nearby the existing garage door opener system. The homeowner must have some basic tools such as a Phillips screwdriver to unscrew terminals on the back of the garage door opener and connect our product to it. 2.4 Tradeoffs Below are some tradeoffs that we will need to consider when designing the architecture Simplicity Vs. Security The system has a very simple design and concept but this limits our security options. If a homeowner is installing the for a secondary security solution, they would most likely want to verify if their garage door is closed. If the garage is opened under the wrong conditions, a security alarm should go off in the existing security system for a homeowner. For our developmental purposes, we have chosen not to allow expansion to a homeowner's security system because the complexity of interfacing with various types/brands of security systems is beyond the scope of this project Installation: above the opener Vs. at the control switch Initially, we had discussed installing the behind the Garage Door opener control switch as this was the best approach to accessing the garage door functions directly. This was a simple approach and was the easiest for a homeowner to install, but we have a few limitations with this method. With most homes having the control switch mounted on the walls, this would limit our camera video feed as it would be an angle shot compared to being mounted directly above the garage opener. If we installed the Smart Garage at the wall with the control switch, the view of the door may get obstructed by a parked car. Therefore, we chose to install the unit above the garage door opener with direct view to the garage door. If the homeowner chooses to expand in the future with another unit, they would simply place another product above the other units in his garage in the same manner. 8/3/ :25 PM Page 11 of 38 Door Keepers

12 3 Layer Definition This section describes the overall structure of architecture layers. The architecture of has been divided into three different layers: Interface Layer, Controller Layer and Physical Layer. The high-level block diagram of the layers is given below. The function, purpose, interface and interaction of each layer with the other layers will be explained later in this section. Figure 2: High Level Layer Diagram 3.1 Interface Layer This layer is responsible for all interactions of the with the homeowner, either through the smartphone app or the web GUI, by providing a user friendly interface to access all the functions of the. The homeowner will give inputs: logging in or out, provide configuration information, and choose commands, such as opening/closing their garage door or viewing its status. The results of the actions requested will also be output through this layer. 8/3/ :25 PM Page 12 of 38 Door Keepers

13 This layer is also responsible for sending and receiving data from Controller Layer. All the information provided by the homeowner will be sent to the Controller Layer and all the responses will be received from the Controller Layer through the Internet. 3.2 Controller Layer The Controller Layer is the brain of the. It includes the Microcontroller, Data Accessor, and Microcontroller Networking subsystems. This layer is responsible for processing all the actions initiated by the homeowner on the smartphone app or web GUI and keeping records of all the settings and notifications in the. Input sent from Interface Layer (via Application Networking over the Internet) and Physical Layer (processed sensor data via the Sensor Reader) is received, processed, and acted upon accordingly by the Microcontroller. The output of these actions is sent back to the Interface Layer through the Internet, to the Physical Layer's Command Signaler for execution of the command on the hardware devices, or to the Database Controller subsystems for data retrieval or storage. 3.3 Physical Layer The Physical Layer handles the execution of the homeowner s commands and retrieval of signals on/from the hardware/external components of the with two subsystems, the Command Signaler and Sensor Reader. The external hardware components are external devices that are independent of the system. The Physical Layer interacts with these external devices either to send data in one-way analog to digital or digital to analog streams. The digital to analog communications are converted by the Command Signaler, while the analog to digital communications are converted by the Sensor Reader, both using relay switches. 8/3/ :25 PM Page 13 of 38 Door Keepers

14 4 Inter-Subsystem Data Flows 4.1 Overview This section describes the data flow between the subsystems across layers. Each flow of data is marked with an identifier to be described later in this section. There are three layers within the system: Interface, Controller, and Physical. The is also interacts with other external units, the database and hardware units, in the process of handling homeowner s commands. Figure 3: Subsystem Data Flow Diagram 8/3/ :25 PM Page 14 of 38 Door Keepers

15 4.2 Data Flows The following table describes each data flow as enumerated in Figure 2. Element Description HI1 Homeowner s GUI input, includes login and screen/option selection. IL1 GUI Input sends homeowners inputs to the Application Networking for transport. IL2 Application Networking initiates a connection to the Internet and sends the data to the Microcontroller Networking. IL3 Data from Application Networking is sent to GUI Output. IL4 The data received from the Application Networking are formatted and displayed to the Homeowner. IN1 Microcontroller Networking received the data from Application Networking IN2 Application Networking received the data from Microcontroller Networking CL1 Microcontroller Networking sends the data incoming from the Internet to the Microcontroller for processing. CL2 The Microcontroller issues commands to the Command Signaler. CL3 Data and/or queries are sent from the Microcontroller to the Data Accessor. CL4 Data Accessor accesses the Database and sends the queries or data to store. CL5 Data Accessor responds to the Microcontroller with the completed query results. CL6 The Microcontroller sends data or responses to Microcontroller Networking. CL7 Microcontroller Networking sends the data/responses and uses the already-established connection over the Internet. DB1 The Database sends results of the query to the waiting Data Accessor. PL1 The Command Signaler creates an analog signal to activate the Door Opener. PL2 The Command Signaler creates an analog signal to activate the Light. PL3 The Command Signaler creates an analog signal to activate the Buzzer. PL4 The Door Sensor formats incoming signals from the Door Sensors for the Microcontroller. PL5 The Video Sensor creates a video feed from the Visual Sensor to be accessible via the Internet. EH1 A raw video feed from the Visual Sensor is sent to the Video Sensor for processing. EH2 Door Sensors send raw signals for the Sensor Reader for processing. Table 2: Data Flow Descriptions 8/3/ :25 PM Page 15 of 38 Door Keepers

16 4.3 Producer-Consumer Relationships The following table shows the subsystem data flow path in a Producer-Consumer matrix. From this matrix we can see how much interaction there is between the subsystems. The most complex subsystem is the Microcontroller: it must chat with four other subsystems, accepting data from three and sending data to a slightly different three. By delegating most of the client-server communication out to separate subsystems in the Interface and Microcontroller Layers, we allow the layers to be loosely coupled as each Networking subsystem will know what the other wants to accept regardless of how the GUI or Microcontroller gathers their data. Table 3: Producer-Consumer Matrix 8/3/ :25 PM Page 16 of 38 Door Keepers

17 5 Interface Layer Subsystems This section describes the Interface Layer in more detail. The layer consists of three subsystems, named GUI Input, GUI Output, and Application Networking. Homeowners select from the commands either via the touch screen on a smartphone (for the app) or through a web browser using the mouse, keyboard, or other interface (for the web GUI). Updates are displayed through the web GUI s or smartphone application s screens. The GUI Input takes the homeowner s actions of the button presses and inputs, sorts and converts it into data that can be read by the microcontroller, and sends the sorted data to the Application Networking for transport. The Application Networking receives the data from the GUI Input and transports it to the Microcontroller Networking in the Controller Layer using an Internet connection. It also receives updates and responses from the Microcontroller Networking via the Internet and sends it to the GUI Output. The GUI Output receives the updates and responses from the Application Networking, sorts and converts the data into an appropriate format, and updates the GUI on the homeowner s devices. 5.1 GUI Input Subsystem General This subsystem takes the actions of the GUI buttons and inputs on the homeowner s smartphone (via the app) and/or computer (via the website), sorts and converts the input into data that can be read by the microcontroller, and sends the data to the Application Networking for transport. Figure 4: GUI Input Data Flow 8/3/ :25 PM Page 17 of 38 Door Keepers

18 5.1.2 Assumptions The homeowner has a method of input, either touchscreen for the smartphone app or keyboard and mouse for the web browser GUI. The homeowner has an internet connection for both their devices (smartphone or computer) and their unit Responsibilities This subsystem must take the homeowner s actions on the GUI presses and input, perform data conversion into an appropriate format, and send it to the Application Networking for transport Subsystem Inter-layer Interfaces Subsystem Public Interfaces Path Method Description Information Required Information Returned HI1 inputlistener Waits for the homeowner s input. Input selections, as strings or buttonpresses Table 4: GUI Input Public Interfaces 5.2 GUI Output Subsystem General This subsystem receives updates and responses from the Application Networking, sorts and converts the data into an appropriate format for display on the GUI, and updates the GUI on the homeowner s smartphone (via the app) and/or computer (via the website). The updates includes the garage door status updates, selection and configuration screens, and video feed. 8/3/ :25 PM Page 18 of 38 Door Keepers

19 Figure 5: GUI Output Data Flow Assumptions The homeowner has an Internet connection for both their devices (smartphone or computer) and their unit Responsibilities This subsystem must receive responses and updates from Application Networking, perform data conversion into an appropriate format for displays on the GUI, and update the GUI on the homeowner s smartphone (via the app) and/or computer (via the website) according to the responses it received, such as current status of the garage door, selection and configuration screens, video feed, and show any errors that occur Subsystem Inter-layer Interfaces Subsystem Public Interfaces Path Method Description Information Required Information Returned IL2 guiupdate Updates the GUI according to received data The data/results of the action initiated. Table 5: GUI Output Public Interfaces 8/3/ :25 PM Page 19 of 38 Door Keepers

20 5.3 Application Networking Subsystem General This subsystem communicates the application/client side with others in the system. It utilizes the Internet TCP/IP protocols to facilitate the data transportation between the application/client side and processing/server side units. It receives data from the GUI Input and transports it to the Microcontroller Networking of the Controller Layer using an Internet connection. It also receives updates and responses from the Microcontroller Networking via the Internet and sends it to the GUI Output Assumptions Figure 6: Application Networking Data Flow The homeowner maintain an Internet connection both for their devices (smartphone or computer) and their unit. The Microcontroller Networking is accessible via TCP/IP Responsibilities This subsystem must transport the data received from the GUI Input to the Microcontroller Networking using an Internet connection and must also send the responses and updates received from the Microcontroller Networking (via Internet) to the GUI Output. 8/3/ :25 PM Page 20 of 38 Door Keepers

21 5.3.4 Subsystem Inter-layer Interfaces Subsystem Public Interfaces Path Method Description Information Required Information Returned IL2 mcsend Initiate Internet Data from GUI Input. connection and sends the data received from GUI Input to the Microcontroller Networking IN2 mclistener Waits for data/responses coming from the Microcontroller Networking Data/responses from Microcontroller Networking Table 6: Application Networking Public Interfaces 8/3/ :25 PM Page 21 of 38 Door Keepers

22 6 Controller Layer Subsystems This section describes the Controller Layer in more detail. The Controller layer is the data processing and control unit for the. It consists of three subsystems, Microcontroller Networking, Microcontroller, and Data Accessor. The Microcontroller Networking receives the data sent from Application Networking of the Interface Layer via the Internet and sends it to the Microcontroller for processing. It also receives updates and responses from the Microcontroller and sends it to the Application Networking using over the Internet. The Microcontroller receives data from the Microcontroller Networking and processes it accordingly. It may send database retrieval requests to the Data Accessor and/or command executions to the Command Signaler of the Physical Layer based on the received data of requests. It then finally sends the results of the processed requests back to the Microcontroller Networking for transport. The Data Accessor receives commands from the Microcontroller and interacts with the external database to process the command and sends the result of the process back to the Microcontroller. 6.1 Microcontroller Networking Subsystem General This subsystem communicates the processing/server side unit with others in the system. It utilizes the Internet TCP/IP protocols to facilitate the data transportation between the application/client side and processing/server side units. It receives data from the Application Networking via Internet and transports it to the Microcontroller for processing. It also receives updates and responses from the Microcontroller and sends it to the Application Networking using an Internet connection. 8/3/ :25 PM Page 22 of 38 Door Keepers

23 Figure 7: Microcontroller Networking Data Flow Assumptions The homeowner maintains an Internet connection both for their devices (smartphone or computer) and their unit. The Application Networking is accessible via TCP/IP Responsibilities This subsystem must send the data it received from the Application Networking (via Internet) to the Microcontroller and must transport the responses and updates received from the Microcontroller to the Application Networking using an Internet connection Subsystem Inter-layer Interfaces Subsystem Public Interfaces Path Method Description Information Required IN1 applistener Waits for data from the Application Networking. CL7 appsend Sends the Microcontroller response/updates responses/updates received from the Microcontroller to the Application Networking. Table 7: Microcontroller Networking Public Interfaces Information Returned Data from the Application Networking 8/3/ :25 PM Page 23 of 38 Door Keepers

24 6.2 Microcontroller Subsystem General This subsystem is the central processing unit of the. It may issue commands for the hardware hooked up to the Command Signaler, send responses and status updates back to the Microcontroller Networking, or interact with the Database for data retrieval or storage commands via the Data Accessor. It receives the data of the homeowner s requests from the Microcontroller Networking, performs data identification and processing, and sends it to Command Signaler of the Physical Layer for command execution and/or to the Data Accessor for data retrieval and/or storage in the database. It also receives data from Sensor Reader of the Physical Layer and the response from Data Accessor, and sends it back to the Microcontroller Networking for transport. Figure 8: Microcontroller Data Flows Assumptions The microcontroller will support the programming languages implemented in the Smart Garage, which may include Java, Python, PHP, SQL, C#, or other languages. 8/3/ :25 PM Page 24 of 38 Door Keepers

25 6.2.3 Responsibilities This subsystem is responsible for processing incoming data and issuing commands or responses. It receives data from the Microcontroller Networking, processed signals from the Sensor Reader, and results from the Data Accessor. It issues commands to the Data Accessor for storing or retrieving data, triggers external hardware connected with the Command Signaler, and sends responses back to the Microcontroller Networking Subsystem Inter-layer Interfaces Path Method Description Information Required Information Returned CL2 sendcommand Sends a command to the Physical Layer for processing by the Command Signaler. The ID of the device to be activated. PL4 sensorlistener Waits for processed data coming from the Sensor Reader Subsystem Subsystem Public Interfaces Table 8: Microcontroller Inter-layer Interfaces Processed data from the sensors. 8/3/ :25 PM Page 25 of 38 Door Keepers

26 6.3 Data Accessor Subsystem General This subsystem interacts with an external Database for data retrieval and storage requests coming from the Microcontroller. When receiving a request from the Microcontroller it makes database queries to the Database to retrieve or store data from/into it and sends the results data back to the Microcontroller. The external database is either connected via the network or is a separate process running on the hardware Assumptions Figure 9: Database Controller Data Flow The database has enough space to store the homeowner s data into it, and is accessible by the system Responsibilities This subsystem is responsible for accepting data retrieval and storage requests, making data queries to retrieve or store data, and sending the result back to the Microcontroller Subsystem Inter-layer Interfaces 8/3/ :25 PM Page 26 of 38 Door Keepers

27 6.3.5 Subsystem Public Interfaces Path Method Description Information Required Information Returned CL4 dbstore Makes database queries to store data in the database. Data to be stored in the database CL4 dbretrieve Makes database queries to retrieve data from the database. DB1 dblistener Wait for results from the database. Data retrieval requests from the Microcontroller Table 9: Database Controller Public Interfaces Query results sent from the database 8/3/ :25 PM Page 27 of 38 Door Keepers

28 7 Physical Layer Subsystems This section describes the Physical Layer in more detail. The layer consists of two subsystems: Command Signaler and Sensor Reader. The Command Signaler executes commands requested from the Microcontroller, converts digital to analog signals, and applies these signals to the External Hardware it is connected to. The Sensor Reader processes incoming raw signals from its External Hardware, and sends the processed data to the Microcontroller. 7.1 Command Signaler Subsystem General This subsystem initiates External Hardware, by performing command execution through converting a command from the Microcontroller into an analog signal to trigger the hardware s actions. It utilizes digital to analog relays to execute commands and trigger the external hardware. The External Hardware is connected via onboard digital to analog relays through lengths of wire or soldered on. The Command Signaler is directly connected with the Controller Layer via onboard port. Figure 10: Command Signaler Data Flow 8/3/ :25 PM Page 28 of 38 Door Keepers

29 7.1.2 Assumptions The relays used for this subsystem are compatible with the external hardware and can supply enough voltage for the necessary amount of time. The external hardware has been wired properly Responsibilities This subsystem must accept commands from the Microcontroller and convert them into analog signals to controller the external hardware Subsystem Inter-layer Interfaces Path Method Description Information Required Information Returned CL2 microlistener Waits for commands from the Microcontroller Commands to activate the external hardware Table 10: Command Signaler Inter-layer Interfaces Subsystem Public Interfaces Path Method Description Information Required Information Returned PL1 actgarage Initiates the garage door opener, so the door opens or closes. PL2 actlight Initiates the Smart Garage unit light, so the light turns on or off. PL3 actbuzzer Sounds the buzzer on the unit, to alert anyone nearby that the door is about the act. Table 11: Command Signaler Public Interfaces 8/3/ :25 PM Page 29 of 38 Door Keepers

30 7.2 Door Sensor Subsystem General This subsystem monitors for incoming door sensor information, converting analog signals into data to be sent to the microcontroller for further processing. The door sensors are connected to the Door Sensor subsystem via onboard digital to analog relays through lengths of wire or soldered on Assumptions Figure 11: Door Sensor Data Flow The external hardware is compatible with the relays used. The unit has enough current to constantly power the sensors Responsibilities This subsystem must convert incoming analog signals into an appropriate usable data for the Microcontroller Subsystem Inter-layer Interfaces Path Method Description Information Required Information Returned PL4 sendsensor Data Transmits processed data from the External Hardware Signals from the sensors Table 12: Door Sensor Inter-layer Interfaces 8/3/ :25 PM Page 30 of 38 Door Keepers

31 7.2.5 Subsystem Public Interfaces Path Method Description Information Required Information Returned EH2 doorlistener Waits for incoming sensor signals from the Door Sensors for processing. Formatted door sensor data Table 13: Door Sensor Public Interfaces 8/3/ :25 PM Page 31 of 38 Door Keepers

32 7.3 Video Sensor Subsystem General The Video Sensor Subsystem is responsible for receiving an image from the camera and broadcasting it to the Internet. The camera will be used as a streaming IP camera. The video will not be stored because the will not have a centralized server. The image provided through this subsystem will be displayed in the Interface Layer by extracting it from Internet Assumptions Figure 12: Video Sensor Data Flow The camera used is compatible with the unit's central hardware and operating system Responsibilities This subsystem must utilize the camera and create images to be served to the Internet for viewing the homeowner's garage door. 8/3/ :25 PM Page 32 of 38 Door Keepers

33 7.3.4 Subsystem Inter-layer Interfaces Path Method Description Information Required Information Returned PL5 sendcamdata Broadcasts processed images from the Visual Sensor Hardware Signal from the Visual Sensor Subsystem Public Interfaces Table 14: Video Sensor Inter-layer Interfaces Path Method Description Information Required Information Returned EH1 videolistener Waits for incoming sensor signals from the Visual Sensor for processing. Formatted image data Table 15: Video Sensor Public Interfaces 8/3/ :25 PM Page 33 of 38 Door Keepers

34 8 Requirements Mapping This section will cover how the key requirements for the will be met within the layers of our architecture. Some requirements, such as packaging requirements, fall outside of this architecture, but all key requirements will be listed. This system deals with displaying garage door information through the interface and accepting commands from the homeowner. This means both the Interface and Controller Layers are very important to the use of the system, and encompass most of the requirements. The Physical Layer only deals with external hardware via one-way data streams to enact commands sent from the homeowner and report sensor information. Number Requirement Interface Controller Physical 3.1 Door Status 3.2 Door Control 3.3 Mobile Application Control 3.5 Security Notification 4.1 Recovery Disk 4.2 Parts Listing 4.3 Accessing the System 4.4 Full User Manual 4.5 Quick User Guide 4.6 Smart Phone Application 5.1 Garage Response Time 5.2 Status Update Time 5.3 Camera 5.4 Door Sensors 6.1 Unit Installation 6.3 Application Security 6.4 Electrical Safety 7.1 User Manual 7.2 Installation/System Setup 7.4 Software Support/Upgrades 8.1 Customer Facing Interface 8.3 Customer Device Account 8.5 Software System Setup 8.6 Garage Open/Close Time 8.7 Browser Support 8.8 Notification Center Table 166: Requirements Mapping 8/3/ :25 PM Page 34 of 38 Door Keepers

35 9 Operating System Dependencies This section will describe critical dependencies, interactions and interfaces regarding embedded operating system that will be used in system. 9.1 Interface Layer The Interface Layer is responsible for user interaction with the system and communication with Controller Layer. The homeowner has two ways to interact with the, either through an Android smartphone application or web browser. Both the Android application and web browser will provide the same functionality and control. Communication with Controller Layer will be maintained by the Application Networking Subsystem. It will process the dataflow in between Interface Layer and Controller Layer via the Internet Smart Phone Application The smart phone app will depend on Android operating system version 2.3 or later. All the input from the homeowner would be done through the buttons and screens within the app s GUI. Programming for Android will be done in a Java IDE. More research needs to be done to find further dependencies for streaming Motion-JPEG and other data transmissions Web Browser GUI The web GUI will work on all major web browsers, including Internet Explorer 9.0+, Mozilla Firefox and Google Chrome. Web page creation will depend on web technologies both client side and server side, which may include HTML, JavaScript, Motion-JPEG, PHP, CSS, and/or AJAX Application Networking Subsystem To send and receive data through the Internet, TCP/IP Protocols will be utilized. These Protocols are automated based protocols which needs to be followed in each data transferring process. 9.2 Controller Layer The Controller Layer will use some form of Linux tailored to the device, such as Raspian or another Linux flavor, and have an internalized web server and database host. Motion-JPEG, PHP, CSS and/or AJAX engines will be required for the server to render pages and serve video, and whose dependencies must be installed in the OS. Records of events and settings will be 8/3/ :25 PM Page 35 of 38 Door Keepers

36 stored in the database. This database will work independently of the rest of the system and utilize MySQL. The Controller Layer will also send and receive data to/from the Interface Layer through the Internet, utilizing the TCP/IP Protocols. 9.3 Physical Layer The Physical Layer deals with external hardware components through one-way communication via relay switches. The OS and programming language runtimes must have the package dependencies installed to know about and use these switches. 8/3/ :25 PM Page 36 of 38 Door Keepers

37 10 Testing Considerations This section describes testing considerations for each layer of the system. The testing considerations should allow the Door Keepers to test each layer separately. To be able to test each layers separately, our team has kept each layer independent and only some of the layers will be able to communicate externally Interface Layer Independence The Interface Layer should not be dependent on any other layer in the system Inter-Layer Communication The Interface Layer will communicate with the homeowner via the application GUI and the Controller Layer via the Internet. All input made by the homeowner is sent over the Internet to the Microcontroller Networking subsystem of the Controller Layer from the Application Networking subsystem. All the responses coming from the Microcontroller Networking over the Internet must be listened for by the Application Networking subsystem. The data sent between these layers must be in a form both can interpret External Communication The homeowner and the Internet are external interfaces for the Interface Layer. The Interface Layer will have to take input from the homeowner either from the Android app or through a web browser. All the input given must be formatted and sent to the Controller Layer over the Internet. When receiving and sending data, the Application Networking subsystem must follow the TCP/IP Protocols. All the data between the Interface Layer and Controller Layer must pass through the Internet. The components involved in carrying the data to and through the Internet, such as routers, modems, and hubs, are external to the Interface Layer Controller Layer Independence The Controller Layer should not be dependent of any other layer in the system. 8/3/ :25 PM Page 37 of 38 Door Keepers

38 Inter-Layer Communication The Controller Layer only communicates with the Interface Layer via the Internet and the Physical Layer via onboard components. The data that comes from the Interface Layer needs to be in a processable format while the data sent back to the Interface Layer must be readable by that layer. The data from the Physical Layer will be signals from sensor and camera that have been processed for use by the Controller Layer. The data leaving the Controller Layer for the Physical Layer will be processed in the Physical Layer. No conversion within the Controller Layer should be necessary in either trip External Communication Sending and receiving data to/from the Interface Layer must pass through the Internet and follow the TCP/IP Protocols. All the components such as, modem, router and all hubs involved will be counted as an external components for the Controller Layer. The database used to store homeowner information, statuses, and other data is external to the system software. The Data Accessor subsystem will be the only subsystem to have functions to access this database Physical Layer Independence The Physical Layer should not be dependent on any other layer in the system Inter-Layer Communication The Physical Layer shall only communicate with the Controller Layer. The data coming from the Controller Layer will be converted into analog signals to activate the relayattached hardware. Incoming relay-signals must be converted to digital before sending to the Controller Layer External Communication The Physical Layer will have to take input from or trigger the External Hardware. Outputs include the garage door opener or buzzer, and inputs are the signals from the sensors. All these communications must be converted either digital to analog or analog to digital before sending or after retrieving data from the External Hardware 8/3/ :25 PM Page 38 of 38 Door Keepers