Home

Detailed Design Specification Team: Always Home Project: Smart

1. Figure 2 Ul Layer Decomposition Chart 2 5 2 UI Layer Description The UI layer receives input from the user through our software interface the Web GUI and Android GUI It also receives input from the user through our hardware such as the doorbell camera and microphone This layer will be responsible for transmitting input to other layers as well as displaying results from other layers This will include transmitting audio and video into meaningful values to properly stream video This layer will utilize our three different interfaces the hardware the web and mobile device 2 6 Processing Layer 2 6 1 Processing Layer Decomposition Chart Android App D 9 9 M r Q x lt Figure 3 Processing Layer Decomposition Chart 2 6 2 Processing Layer Description The Processing Layer will focus on converting and evaluating our data It will perform task to take the input from the GUIs and Hardware and convert the data to information that can be transferred to other components in our system It will have to be able to take data and prepare it for output 15 DDS Version 0 1 ALWAYS i HOMe Detailed Design Specification Smart Door 2 7 Network Layer 2 7 1 Network Layer Decomposition Chart Web App d2 DT yIOMJIN Figure 4 Network Layer Decomposition Chart 2 7 2 Network Layer Description The Network performs tasks to convert and evaluate data in terms of information from mobile website and microcontr
2. Figure 12 Video Server Subsystem Overview 52 DDS Version 0 1 ALWAYS iisHOMe EH Detailed Design Specification Smart Door 3 4 3 3 Video Server Subsystem Principles Interactive The Video Server subsystem is a key component that facilitates interaction between the user and guests at their door by establishing a link between the Smart Door Device and the user s Android device Interaction between the two end users would be impossible without the Video Server Subsystem to link the two users over the internet Responsiveness The overall System cannot be responsive unless the Video Server operates quickly Since this subsystem links the two end users any slow response here will be detrimental to the user experience Reliability The overall Smart Door System can only be as reliable as the Video Server subsystem Any interruption of service by the Video Server will bring down the entire system Communication The Video Server subsystem is one of the critical components supporting communication functionality within the Smart Door System Without the Video Server subsystem communication is impossible 3 4 3 4 Host Stream Module Description 3 4 3 4 1 Host Stream Description Host Stream Module will enable the microcontroller to stream to the Video Server This module is a small Real Time Messaging Protocol RTMP server set up to run on the end users home computer 3 4 3 4 2 Host Stream Function The Primary functionality of this mod
3. q Smart Door Detailed Design Specification 3 4 3 8 5 Log Videos Actions Module Processing Series of if statements to complete log retrieval of videos and notifications if communication is on channel VS 6 log the notifications on Server HDD if communication is on channel VS 5 if communication is a request for stored video retrieve MPG4 video file from Server HDD else if communication is a video to store on Server HDD store MPG4 video file from Server HDD 3 4 4 Web Application Subsystem 3 4 4 1 Web Application Subsystem Principles Usability The Web Application system must be easy to operate in order for users who may not be technologically sophisticated to be able to use the Smart Door product Reliability The Smart Door device must operate smoothly without fatal crashes Security The Web Application must be hacker resistant 3 4 4 2 Web Application Subsystem Diagram me i IC y View Request Communications Interface D Web App Web Controller Server HDD Communications Figure 13 Web Application Subsystem Overview 58 ALAN Spe DDS Version 0 1 Detailed Design Specification Smart Door 3 4 4 3 Request Interface Module Description 3 4 4 3 1 Request Interface Description The Request Interface module is the interface between the Web GUI s incoming request and the Web Application module The module will parse the request and determine which
4. __hook amp CSource MyEvent pSource amp CReceiver videoListener __hook amp CSource MyEvent pSource amp CReceiver doorbellListener void unhookEvent CSource pSource __unhook amp CSource MyEvent pSource amp CReceiver audioListener 44 ALWAYS iis HOMe DDS Version 0 1 Detailed Design Specification Smart Door __unhook amp CSource MyEvent pSource amp CReceiver audioListener __unhook amp CSource MyEvent pSource amp CReceiver doorbellListener 3 3 4 5 Data Processor Module Description 3 3 4 5 1 Data Processor Description The Data Processor module it responsible for routing all information flowing between the video server and the microcontroller The Data Processor module will be part of the C application running on the microcontroller 3 3 4 5 2 Data Processor Function The Data Processor module will route control messages to and from the microcontroller Depending on network availability the Data Processor module will route video and notifications to either the video server or Microcontroller HDD 3 3 4 5 3 Data Processor Interfaces MCA 1 MCA2 fin Sensor Signals variables RAW Audio and Video Stream from Data Interpreter MCA3 Lu Control messages and mp3 Audio stream from Server Communication Manager 3 3 4 5 4 Data Processor Physical Data Structure lock_State Variable to represent the lock unlock state of the Door
5. 3 2 2 5 5 Speaker Interface Module Processing e While loop to listen for output Si while no digital sound data from the Microcontroller wait and listen if digital sound data is received proceed to transmit to speaker 3 2 2 6 GPIO Interface Module Description 3 2 2 6 1 GPIO Interface Description The General Purpose Input output interface is a group of generic pins on a chip whose behavior as an input or an output can be controlled through software The GPIO interface can be found on the microcontroller or externally plug into the Microcontroller The pins can be programmed as input where data from some external source such as door lock doorbell lock sensor etc are being fed into the system to be manipulated at a desired time and location 3 2 2 6 2 GPIO Interface Function The General Purpose Input Output interface provides an ease of access to the devices internal properties The pins available on the GPIO interface can be programmed to be used to either accept input or provide output to external devices such as get signal from lock sensor or Open Close sensor etc 26 ALWAYS mHOMe DDS Version 0 1 Detailed Design Specification Smart Door 3 2 2 6 3 GPIO Interface Module Interfaces Ul 14 Digital command data stream from the Microcontroller App to Door Lock Ul 15 Im o Digital notification data stream from Door Sensor Ul 17 fin Digital status data stream from Lock Sensor w3 fin Digita
6. Unlock lock 1 lock2 unlock 3 2 1 5 4 Android Function Chooser Processing Je each button will have a similar layout for the function call Public File Monitor File video AppMonitor call the Mobile Application function return video return back to the layout view 3 2 2 Hardware Subsystem 3 2 2 1 Hardware Subsystem Description The Hardware subsystem consists of the hardware devices in the Smart Door system and the Microcontroller BUS that accesses them These devices include a Microphone Camera Speaker Doorbell Lock Sensor Door Sensor and Door Lock The functionality of this subsystem is to convert analog input into digital signals and create analog input from digital signals This conversion is a built in function of the microcontroller so this subsystem represents how our system will access and use that functionality 23 DDS Version 0 1 ALWAYS mHOMe Fl Detailed Design Specification Smart Door Figure 7 3 2 2 2 Hardware Subsystem Diagram 46 0 Microphone amera Ul 11 Hardware Subsystem Overview 3 2 2 3 Hardware Subsystem Principles Interactive The hardware subsystem is one of the three user visible parts of the application The Hardware subsystem enables communication between the user and their guests through the connected devices This subsystem represents the end of the communications chain where the analog input and output are received and transmitted Thus
7. nnnrrrvrnnnrnnnnnrnrvrnrrnsnrnnnnnenr 74 5 5 Network Layer Requirements Traceability mat 74 5 5 1 Network Layer Requirements Traceability Matrix Analysis cccsccccccecessesssseeeeeeeseesees 75 5 5 2 Network Layer Requirements Traceability Matrix Finding 75 5 6 Data Storage Layer Requirements Traceability matt 76 5 6 1 Data Storage Layer Requirements Traceability Matrix Analysis ccccccssssssssceseesseesees 77 5 6 2 Data Storage Layer Requirements Traceability Matrix Findings 00sssseesnssesesereernsssseeee 77 6 Acceptance Plan Assumptions Relative to Detailed Design 77 6 1 Packaging and Installation cc cccccccccssssssssecececeseeseseseeeeecsseescsaeeeeececessesseaeeeeeessesseaeaeeeeeesseseees 77 6 1 1 RTMP Server Ipnstallation EEN 77 Ee elle 77 6 3 Acceptance Criteria c cscccccacccceevenscchessaccscsshsedes san ccgilschsscke edd Eed banene EEN Eder Ed 77 Te ele ie Le e 78 Tele Nee ee Le Ee ahaa eit nee ee 78 DDS Version 0 1 ALWAYSitsHOMe Detailed Design Specification Smart Door Document Revision History Revision Revision Number Date 02 17 2014 Rough Draft First draft submitted for initial review 2 28 2014 Revised following presentation 3 1 2014 Baseline update corrected jmo Updated TOC Description Rationale DDS Version 0 1 ALWAYS ii HOMe q Detailed Design Specification Smart Door List of Figures Figure 1 Subsystem Decomposition Chart
8. 56 DDS Version 0 1 ALWAYSIDEHOMe EH Detailed Design Specification Smart Door 3 4 3 7 5 Android Communication Manager Module Processing Minimal processing if else statement to route communications if communication on P 1 channel forward communication to Command Message Processor or Host Stream module if communication is on VS 2 channel forward communication to Android GUI Subsystem 3 4 3 8 Log Videos Actions Module Description 3 4 3 8 1 Log Videos Actions Module Description The Log Videos Actions module is a video codec and converter located on the server with the associated logic to execute the codec 3 4 3 8 2 Log Videos Actions Module Function The Log Videos Actions module will convert the incoming stream to an mp4 file and store it on the server 3 4 3 8 3 Log Videos Actions Module Interfaces h 264 Stream MPG4 Stream Sensor data and notifications from Microcontroller App Subsystem IN MPGA Stream to Host Stream Subsystem i O LIN MPG4 Stream Sensor data and notifications from Server HDD Subsystem 3 4 3 8 4 Log Videos Actions Module Physical Data Structure Erem mpg4 Video mpg4 File Digital video file lock Unlock Variable to represent the unlock essage being sent to the Door Lock lock Lock Variable to represent the lock essage being sent to the Door Lock call_MetaData Timestamp Integer representing alll type Float for duration 57 DDS Version 0 1 ALWAYS iisHOMe
9. Packaging Requirements Performance Requirements Size Temperature Control Mounting Casing Software Acquisition Included Components Team Logo System Configuration System Setup xX x xX xX Notification Time Latency gt lt gt lt gt lt gt lt Response Time Data Transmission Live Video Feed gt lt gt lt gt lt gt lt gt lt gt lt gt gt lt gt lt gt lt Data Transmission Audio Transmission Recording Log Log Availability X X X x Recording Log Storage Capacity Power Power Supply Power Power Source Emergency Backup Battery 1 0 Ports Operating Environment Account Setup x x K x Video Log Downloads X X x x Video Photo Resolution System Availability D x x D Notification Limit Initialization Time Mounting Height Microphone Sensitivity Safety Requirements Camera Mounting Microphone Mounting Camera and Microphone Weather Safety Receptacles Maintenance and Support Requirements Software Updates x x x x User Manual Open Source D Other Requirements Web Interface Support Portable Source Code x x x x Notification Control Table 12 Network Layer Requirements Traceability Matrix 74 ALWAYS iiHOMe DDS
10. 9 Figure 2 Ul Layer Decomposition Chart 15 Figure 3 Processing Layer Decomposition Chart 15 Figure 4 Network Layer Decomposition Chart 16 Figure 5 Data Storage Layer Decomposition Chart 16 Figure 6 Ul Layer Overview rer tezes iega reesi sedes Eege ee saiae SiE MELDE asiad aie siae ee 18 Figure 8 Hardware Subsystem Overview ccccccccccscsssessnsececececeeseseeaeeeeecsecesesasaeeeseceseeseeaeaeeeeecesseseaeaeeeesens 24 Figure 9 Web GUI Subsystem Overview ssssiisn Krasin ri aaen aE EE aa EOR 29 Figure 10 Processing Layer Overview siistisi sisis eiee raaes raea sreda e irere S EEs Err ar EEES 33 Figure 12 Microcontroller Application Overvlew 42 Figure 13 Network Layer Overview cccecsessscccececessesnsaececececessesaeaeeeeecssessesaeaeseeecsecesesaeaeeeeecesseseasaeeeesens 51 Figure 14 Video Server Subsystem Overview cccesecsesseceeececessesnaeceeececeesesasaeceeecsesesesaeaeeeeecesseseaeaeeeesens 52 Figure 9 Web Application Subsystem OVervieWw ccscssscccccscsssessnsececececeeseasseeeeecsssensasaeeeeecesseseasaeeeeeens 58 Figure 16 Data Storage Layer Overvleuw sst sett ELLE ELLE LE LES LE SELE SELE DELETE LEE ELEG 63 Figure 17 Server HDD Subsystem Overview ccccessessseceeececessesnaecececscessesaeaeseeeceesesesaeaeeeeecesseseaeaeeeeeens 64 Figure 18 Microcontroller HDD Subsystem Overview cccccccesssssssccecececsssesneaeceeecessesesaeaeseeecesseseaeaeeeesens 65 6 DDS Version 0 1 ALWA
11. CSS file in the Content folder Video File Mp4 Static video in the SOL database 3 2 3 3 5 Web Display Module Processing A while loop that buffers data to be sent to the user while data buffer data transmit buffer 3 2 3 4 View Constructor Module Description 3 2 3 4 1 View Constructor Description The View Constructor runs razor syntax code to create dynamic HTML pages The View Constructor uses data that is passed down from the Web Application to create the content in the HTML code The module holds HTML templates for logging in logging out downloading videos pairing device monitoring live video listing videos and for account configuration 30 ALWAYS iiHOMe DDS Version 0 1 Fi Detailed Design Specification Smart Door 3 2 3 4 2 View Constructor Function The main function of the View Constructor is to construct the entire HTML file and retrieves all the necessary files for the web display to send to the user The HTML templates are the most important part of this module because they enable the user to trigger web applications functionality 3 2 3 4 3 View Constructor Module Interfaces Iw Data object with the templates the constructor need to execute WG1 OUT Files that the web display needs to transmit 3 2 3 4 4 View Constructor Module Physical Data Structure The Login Logout template allows the user to enter credentials and exit his or her account In the logging in aspect of th
12. HDD Subsystem to Physical HDD Recorded Notifications and MPG4 Files from Physical HDD to Microcontroller HDD Subsystem Table 1 System Level Data Element Description 10 DDS Version 0 1 ALWAYS mHOMe ed tess Detailed Design Specification Smart Door 2 4 System Level Producer Consumer Relationships Producer Consumer Table Table 2 System Level Producer Consumer Relationships 2 4 1 1 Producer Consumer Analysis From our ADS we were able to analyze how the system communicates and which ones actually create what for each layer The biggest analysis is how the table is symmetrical on each side showing that they all have a similar one to one relationship 2 4 1 2 Producer and Consumer Findings The main findings we found is the external hardware produces the most so we will need the communication on that layer to be able to convert the data well The final thing is we see that the server level is where cross communication happens 11 ALWAYS its HOMe DDS Version 0 1 Detailed Design Specification Smart Door Table 3 Detailed Design View of Web Producer Consumer Relationships 2 4 2 1 Web Producer Consumer Analysis After comparing the mobile and hardware the web relationships are not as complex as the other It is the only one that doesn t have a one to one mapping Finally the chart doesn t show a symmetric consumer producer side showing the items do not go in and out of the same module 2 4 2 2 Web P
13. Hardware being passed to the Microcontroller App Audio Data and Lock Unlock commands from Microcontroller App to the Hardware Raw Data from Camera to the Hardware Subsystem Raw Data from Microphone to the Hardware Subsystem Audio Stream from Hardware to User at the Door Lock Unlock Signal from Hardware Subsystem to the Door Lock Raw Data from Door Sensor to the Hardware Subsystem Raw Data from Doorbell to the Hardware Subsystem Raw Data from Door Lock to the Hardware Subsystem Information Requests and Commands from Android App to Video Server Video Audio Streams and Sensor Information from Video Server to Android App Video Audio Streams and Sensor Information from Microcontroller App to Video Server Information Requests and Commands from Video Server to Microcontroller App Recorded Notifications and MPG4 Files from Microcontroller App to Microcontroller HDD Recorded Notifications and MPG4 Files from Microcontroller HDD to Microcontroller App Information Requests from Web App to Server HDD Recorded Notifications and MPG4 Files from Microcontroller HDD to Microcontroller App Information Requests and MPG4 Files from Video Server to Server HDD Recorded Notifications and MPG4 Files from Microcontroller HDD to Microcontroller App Recorded Notifications and MPG4 Files from Server HDD Subsystem to Physical HDD Recorded Notifications and MPG4 Files from Physical HDD to Server HDD Subsystem Recorded Notifications and MPG4 Files from Microcontroller
14. Producer and Consumer Findings rrrnnnnnorvrnrrnnnnnnnnrnrvrnrrnsnnnnnnrnrsnnssnsnnnnnnrnnsrnssnsnnnn 14 25 DIN UE 15 2 5 1 Ul Layer Decomposition Chart 322222 erne arae een sr dee 15 2 5 2 Ul Layer Despriptiop eege SEENEN a SEENEN SEENEN beneccs 15 2 6 Processing l y oser een EE ENEE EEN 15 2 6 1 Processing Layer Decomposition Chart 15 2 6 2 Processing Layer Description ireren en anaE REER EETA ERERKEN 15 2 7 Network E EE 16 2 7 1 Network Layer Decomposition Chart 16 2 7 2 Network Layer Description 0 ccccccssssececececessescaecececeseesenaeaeceeeceseesaeaeceseesseeseseaeeeeeesseeeegs 16 2 8 Data Storage Layer sed ERENNERT AEN EA EEEE 16 2 8 1 Data Storage Layer Decomposition Chart 16 2 8 2 Data Storage Layer Description 16 3 Detailed design Specifications 25 EDEL EEN EAAS 17 2 DDS Version 0 1 ALWAYSIREHOMe Detailed Design Specification Smart Door 3 1 Overall Detailed Design principles assumptions and trade off parameters 3 1 1 Overall Detailed Design Princdples 17 3 1 2 Trade off Parameters anois a a a erne 17 SUN 18 3 2 1 Ul LAVEr e EE 18 3 2 1 Android GUI SUDSYyStem E aae aaia fraser Adele 18 3 2 2 Hardware SUbSyStem ccccccccccecsssesseecececsceeseaaaesececeseesesaeaeeeeecessesaaaeeeesessessesaaeeeeeesseeeees 23 3 2 3 Web GUISUbSySteEm uaaars endrende menne EEEO AE ete Ene ER drer SE 29 3 35 PROCESSING Lay eh sr ss SE 33 3 3 1 Processing Layer OVErview REENEN
15. backups when they are uploaded by the system 3 5 3 4 Retrieve Server Data Module Function Retrieve HDD data module s functionality is handled natively by the Linux OS 3 5 3 5 Retrieve Server Data Module Interfaces Na UN MPGA Stream Sensor data and notifications from the Web App Subsystem N2 our N3 IN MPGA Stream Sensor data and notifications from the Video Server Subsystem Nna our pi Lou ps2 In MPGAStream Sensor data and notifications from the Server HDD 3 5 3 6 Retrieve Server Data Module Physical Data Structure mpg4 Video mpg4 File Digital video file satus_Notify Timestamp Integer representing a particular status call_MetaData Timestamp Integer representing call type Float for duration of call 3 5 3 7 Retrieve Server Data Module Processing 64 DDS Version 0 1 ALWAYS RgiHOMe Detailed Design Specification Smart Door 3 5 4 Micro Controller HDD Subsystem 3 5 4 1 Micro Controller HDD Subsystem Principles Security Digital and physical security measures on the Server HDD will help to keep the users data safe Interactive No interactive functionality of the Smart Door system is possible without somewhere to store the data supporting that functionality Reliability The overall Smart Door performance relies strongly on the reliability of the Server HDD Any delay or failure of this system will completely disable all functionality of the Smart Door system Usability The Smart Door system w
16. complete successfully unless each participating module adheres to its interface requirements 4 2 2 Component Level Testing Component level testing will test the functionality and internal data communication of each individual subsystem Component level testing will not include interfaces across subsystem or architectural layer boundaries These interfaces will be tested during Integration testing 67 ALWAYS iisHOMe DDS Version 0 1 q Detailed Design Specification Smart Door 4 2 2 1 Test Assumptions 4 2 2 1 1 Component level testing assumes that each module within the subsystem has passed module level testing 4 2 2 1 2 Component level testing assumes that each subset of related modules within a subsystem has passed unit level testing 4 2 2 2 Test Requirements Requirements will be generated for each subsystem based on the system level requirements they are intended to fulfill according to the requirements traceability matrix Additional functional requirements will assure that the subsystem fulfills its function within the overall system 4 2 2 3 Test Dependencies 4 2 2 3 1 Component level tests are intended to test the subsystem s internal functionality This means that the component level tests are dependent on the module and unit level tests being passed successfully 4 2 2 3 2 Component level tests depend on each module adhering to its defined interface requirements in order for communication testing to complete successf
17. of this table indicates how important the proper development of the Processing Layer is to the success of the Smart Door The main issue here is the high level of interrelatedness between the modules of the Processing layer During the module and subsystem design Always Home strove to imbed simple and logical data flows in order to reduce the complexity of the system Unfortunately the distributed nature of the system was working against us achieving our goal This matrix illustrates how the problem of high coupling manifested itself in the Processing Layer Although the modules process and manipulate data in isolation from each other their extensive communication structures re introduce the problems we sought to avoid by dividing the system the way we did 5 5 Network Layer Requirements Traceability matrix Customer Requirements Network Layer Requirements Traceability Matrix Web App Video Server S FEE Request Server HDD z To Microcontroller Communication Command Message View Communications Web Controller SE Android Communication Manager Interface Communications Manager Processor Log Videos Actions Smartphone Application Control Snapshots Taken Keep Activities Log Emergency Power Supply Video Monitoring System Portability Smart Phone Paring Motion Sensor Local Storage Hardware Security Z Wave Lock Unlock Open Source x x x x Nonintrusive
18. the design of the system must be transparent enough to enable personal interaction over a long distance Responsiveness The hardware subsystem has to function quickly in order for the system to be responsive Any delay or failure of this system will completely disable the communication functionality of the Smart Door system Reliability The overall Smart Door performance relies strongly on the reliability of the hardware subsystem Any delay or failure of this system will completely disable the communication functionality of the Smart Door system 3 2 2 4 USB Interface Module Description 3 2 2 4 1 USB Interface Description The USB Interface Module is a connection interface i e a USB Hub device to provide connection between the Microcontroller and Microphone Camera 3 2 2 4 2 USB Interface Function DDS Version 0 1 The main function of the USB interface is to provide stable 2 way communication between the Microphone Camera and the Microcontroller 24 ALWAYS its HOMe Detailed Design Specification Smart Door 3 2 2 4 3 USB Interface Module Interfaces Ul 11 me Digital video data stream from the attached camera Ul 12 IN o Digital audio data stream from the attached microphone Digital video and audio data streams to be passed to Microcontroller App 3 2 2 4 4 USB Interface Module Physical Data Structure Digital Signal Digital video data stream from the attached camera Digital Signal Digital audio data stream from t
19. Data Structure door_State Variable to represent the open close of the Door lock_State Variable to represent the lock unlock state of the Door Lock Stop monitoring message 55 DDS Version 0 1 ALWAYS iisHOMe Detailed Design Specification Smart Door 3 4 3 6 5 Command Message Processor Module Processing if else statement to route communications if communication on VS 1 channel forward communication to Microcontroller Communication Manager if communication is on VS 8 channel forward communication to Android Communication Manager Subsystem 3 4 3 7 Android Communication Manager Module Description 3 4 3 7 1 Android Communication Manager Module Description The Android Communication Manager module will be a part of our software component running on the server 3 4 3 7 2 Android Communication Manager Module Function The Android Communication Manager module s function is to format messages for communication with the registered Android device 3 4 3 7 3 Android Communication Manager Module Interfaces MP3 Stream and command messages from Android App Subsystem h 264 Stream MPG4 Stream Sensor data and notifications to Android App Subsystem C mn N h 264 Stream and MPG4 Stream from the Host Stream module Sensor data and notifications from the Command Message Processor module 3 4 3 7 4 Android Communication Manager Module Physical Data Structure h624 Stream h 264 Stream Digital Video data stream
20. Detailed Design Specification HOMe Team Always Home ALWAYS Project Smart Door DD Team Members James Lunsford Khuong Nguyen Juan Duarte Jay Otterbine Last Updated 2 15 2014 q Detailed Design Specification Smart Door Table of Contents EIERE H Document Revision History 5 bero ee 6 Vistot ET 7 NNEN ee Lee EE 8 2 ee lee e EE 8 2 1 Architecture DESCHIPU oner ae e reeds re ege ee EE EECH ere ge 8 2 2 Subsystem Module Decomposition Chart 9 2 3 Data Element Description 10 2 4 System Level Producer Consumer Relationships ccccccccsssssssscecececessessceceeeessessessaeeeseesseseees 11 2 4 1 1 Producer Consumer AnallySis cccccccsssssossececessesssesensececessessaasacsecececsesseanacseceseeseassanacees 11 2 4 1 2 Producer and Consumer Findings rrrrnnnnorvrrrrnsrnnnnnnnrvrnrrnsnnnnnnvnnvnnsrnsnrnnnnnnnnnnssnsnsnnnnrnnnsnssrnnnnn 11 2 4 2 1 Web Producer Consumer Analvsls 12 2 4 2 2 Web Producer and Consumer Findings cccccccessessssececececseseceeaecececeseeseceaeeeeeeesseseneaeeeeeens 12 2 4 3 1 Android Producer Consumer Analysis cccccccecssssssssececececssseseaeeececesseseaeaeceeecesssseaeaeeeeeens 13 2 4 3 2 Android Producer and Consumer Findings ccsecsessccececeeeesesseaeeeeeceseesecneaeeeeecesseseceaeeeeeens 13 2 4 4 1 Hardware Producer Consumer Analysis rarrrrrrnnrannnnrnrvnnrrnsnnnnnnvnnvnnsrnsnrnnnnrensnnssnsnnnnnnrnnnenssrsnnnn 14 2 4 4 2 Hardware
21. Door device this implies that the requirements will only be satisfied upon installation of the device Unfortunately this means that Always Home will be unable to verify these requirements in any meaningful way We can mount the device to show that is possible to fulfill the requirement with the prototype but for the requirement to be satisfied for any given end user they must be able to follow directions and install the device correctly 72 DDS Version 0 1 ALWAYS mHOMe Detailed Design Specification Smart Door 5 4 Processing Layer Requirements Traceability matrix Processing Layer Requirements Traceability Matrix Android Push Android Command Video Server Communication Data Data Startup Server Communication Local Data Activity Notifications Interpreter Stream Manager Interpreter Processor Manager Manager Access Customer Requirements Smartphone Application Control Snapshots Taken Keep Activities Log Emergency Power Supply Video Monitoring System Portability Smart Phone Paring Motion Sensor Local Storage Hardware Security Z Wave Lock Unlock Open Source Nonintrusive Packaging Requirements Size Temperature Control Mounting Casing Software Acquisition Included Components Team Logo System Configuration Performance Requirements System Setup Notification Time Latency Response Time Data Transmission Live Video Feed Data Transmission Audio Transmission Recording Log
22. Expression http WebApp http 3 3 Processing Layer 3 3 1 Processing Layer Overview UI 10 UIS ul UIS arr nt mante op Mk IKA l Android Interpreter av aa 6 wad wad Cu wm Server Communication M r i 2201d A WAG ACA Figure 9 Processing Layer Overview 33 DDS Version 0 1 ALWAYS ii HOMe Detailed Design Specification Smart Door 3 3 2 Processing Layer Data Element Description Table 7 Processing Layer Data Element Description 3 3 3 Android Application Subsystem 3 3 3 1 Android Application Subsystem Principles 3 3 3 2 Android Application Subsystem Diagram 4 UI7 UIS 5 Android Activity AA 1 AA3 Android Push Notifications Command Video Stream Interpreter AAG 34 DDS Version 0 1 ALWAYS ii HOMe EE Detailed Design Specification Smart Door 3 3 3 3 Android Activity Manager Module Description 3 3 3 3 1 Android Activity Manager Module Prologue 3 3 3 3 1 1 Description The Android Activity Manager Module will package the output and unpackage the input from the Android GUI 3 3 3 3 1 2 Function The main function of this will be getting the classes of the door lock video and audio 3 3 3 3 2 Android Activity Manager Module Interfaces h 264 Stream Push Notifications System Status User Input Push Notifications 3 3 3 3 3 Android Activity Manager Module Physical Data Structure This will be a live video from the mi
23. Lock Digital audio streams to be passed to the Hardware subsystem Flag for WIFI connection status door_State Variable to represent the open close of the Door 45 DDS Version 0 1 ALWAYS iis HOMe Fl Detailed Design Specification Smart Door 3 3 4 5 5 Data Processor Processing Event Listeners will wait for any data If an event is received begin transmitting the data Example code is adapted from msdn microsoft com E class dataProcessor public handle A V streams void audioVisualListener digital A V signal if network is available Encode the A V signal as a h 264 stream action pass the h 264 to the server communication manager else Encode the A V signal as a MPG4 stream action pass the MPG4 stream to the local data access module handle user interaction at door void doorbellListener digital sensor signal if network is available action pass the signal to the server communication manager else action pass the signal to the local data access module void hookEvent CSource pSource __hook amp CSource MyEvent pSource amp CReceiver audioVisualListener __hook amp CSource MyEvent pSource amp CReceiver doorbellListener void unhookEvent CSource pSource __unhook amp CSource MyEvent pSource amp CReceiver audioVisualListener __unhook amp CSource MyEvent pSource amp CReceiver doorbellListener 46 ALWAYS is H
24. Log Availability Recording Log Storage Capacity Power Power Supply Power Power Source Emergency Backup Battery 1 0 Ports Operating Environment Account Setup Video Log Downloads Video Photo Resolution System Availability Notification Limit x x Initialization Time X X X Mounting Height Microphone Sensitivity Requirement Satisfied by Android Device Safety Requirements Camera Mounting Microphone Mounting Jamera and Microphone Weather Safety Receptacles Maintenance and Support Requirements II Software Update x x x x User Manual Open Source Other Requirements Web Interface Support Portable Source Code Notification Control Table 11 Processing Layer Requirements Traceability Matrix 5 4 1 Processing Layer Requirements Traceability Matrix Analysis The processing layer requirements traceability matrix is the densest matrix created during the analysis of requirements This implies that much of the development effort will be focused in this area Of the 73 DDS Version 0 1 ALWAYS mHOMe Detailed Design Specification Smart Door requirements satisfied within this layer only the Lock Unlock requirement is satisfied by a single module The rest of the requirements are satisfied jointly by three to ten modules 5 4 2 Processing Layer Requirements Traceability Matrix Findings The dense nature
25. OMe DDS Version 0 1 Detailed Design Specification Smart Door 3 3 4 6 Server Communication Manager Module Description 3 3 4 6 1 Server Communication Manager Description Server Communication Manager Module Manager is the portion of the C application responsible for communications with the Video Server Subsystem 3 3 4 6 2 Server Communication Manager Function Server Communication Manager Module Manager will package and transmit data to the server 3 3 4 6 3 Server Communication Manager Module Interfaces MCA 3 OUT Control messages and mp3 Audio stream from Video Server Subsystem McA4 IN Sensor state variables and Audio Video Streams to upload to Video Server McAs in Recorded Control messages and MPG4 Video streams to upload on Video Server Pa Im Control messages and mp3 Audio stream from Video Server Subsystem 3 3 4 6 4 Server Communication Manager Module Physical Data Structure lock_Signal Integer used to represent the signal to activate the lock mpg4 Video mpg File Digital video data stream from the Microcontroller HDD 3 3 4 6 5 Server Communication Manager Module Processing 47 DDS Version 0 1 ALWAYS iisHOMe Fl Detailed Design Specification Smart Door JE Event Listeners will wait for any data If an event is received begin transmitting the data Example code is adapted from msdn microsoft com class serverCommunication public handle A V s
26. Table 5 Detailed Design View of Web Producer Consumer Relationships 2 4 4 1 Hardware Producer Consumer Analysis The Hardware has the most consumers and producers all due to the hardware communication Next the application layer deals with converting a lot of data to be sent to the server Finally this is the only one that communicates with a local hard drive so it can store things locally if there is no internet connection 2 4 4 2 Hardware Producer and Consumer Findings The main findings we found is the Hardware could be our bottleneck of our system because of the raspberry pi may not be able to handle everything The producer and consumer chart doesn t show how frequent these actions happen so it will be hard to determine if the microcontroller will be strong enough for this until we make the prototype Finally this has the highest complexity because it involves communicating back and forth with the most modules layers because it takes into account when there is no internet connection 14 DDS Version 0 1 ALWAYS itisHOMe Fl Detailed Design Specification Smart Door 2 5 UI Layer 2 5 1 Ul Layer Decomposition Chart E 9 ult uz ES 2 t Android Android Event el Display Layout Handler Web Display Request Handler Wessen 7 2 Ba r TEY Tock Web GUI Android GUI rz 7 LI W lisenser wie View Constructor
27. The Microcontroller Application subsystem is responsible for all the message passing stream encoding and startup procedures of the microcontroller Always Home has generalized this component as an application but some of the startup procedures will actually be initialized with registry keys and the streaming will use the Linux library avconv from Libav The command messages stream initialization and video storage functionalities will be controlled by the custom C application Always Home has designed 41 DDS Version 0 1 ALWAYS mHOMe Detailed Design Specification 3 3 4 2 Microcontroller Application Subsystem Diagram L Ul 10 UI9 A Data Interpreter Microcontroller App MCA 1 MCA2 SE SECH ES MCA3 MCA4 MCAS MCA6 MCA7 P6 PS P3 P4 v Figure 10 Microcontroller Application Overview 3 3 4 3 Microcontroller Application Subsystem Principles DDS Version 0 1 Interactive The Microcontroller Application Subsystem supports the interactive principle by facilitating the communication between users of the Smart Door The Microcontroller Application Subsystem will convert raw video data into a usable h 264 stream and pass it to the Video Server Subsystem Responsiveness The Microcontroller Application Subsystem supports the Responsiveness principle by translating inputs from the Hardware subsystem and interacting with the Video Server subsystem The Microcontroller Application Subsystem will inter
28. Version 0 1 q Detailed Design Specification Smart Door 5 5 1 Network Layer Requirements Traceability Matrix Analysis Although the Network Layer satisfies fewer requirements than the UI Layer it still contributes to the satisfaction of over forty percent of the requirements levied on the smart door This layer works closely with the Processing Layer and has a similar issue with each requirements being satisfied by four to nine modules This is an extremely high level of cohesion that will have to be closely watched during implementation of the project 5 5 2 Network Layer Requirements Traceability Matrix Findings The nature of the network layer is that it facilitates the communication and data flows between the disparate parts of the Smart Door system It is this aspect of the system design that causes this layer to be so critical to the success of the project Once again the modules in the Network Layer are tightly coupled by their data flows and great care must be taken during implementation phase to keep the various modules independent 75 DDS Version 0 1 ALWAYS mHOMe Detailed Design Specification Smart Door 5 6 Data Storage Layer Requirements Traceability matrix Data Storage LayerRequirements Traceability Matrix Store Retrieve Server Store Retrieve Server HDD 3 d Microcontroller HDD Data Microcontorller Data Customer Requirements ET Pt DER E Smartphone Application Control pf pp Ek SnapshotsTaken pp Keep A
29. YS itisHOMe q Detailed Design Specification Smart Door List of Tables Table 1 System Level Data Element Description ccccccccccecessssssseceeececeesessaeceeecsseeseasaeeeeeeeseeseeasaeeeesens 10 Table 2 System Level Producer Consumer Relationships c ccccsccccssecesssecsseeecssecesseecesseecsaeeeesaeeeeseeeeees 11 Table 3 Ul Layer Data Element Description cccccccssssececeeecessesscaeceeeeecessesaeaecececusessesaeaeeeeseeseeseaeaneeeeens 18 Table 4 Processing Layer Data Element Description 34 Table 5 Network Layer Data Element Description 51 Table 6 Requirements Traceability Mat 70 T bl 7 Acceptance ei EE 77 DDS Version 0 1 ALWAYS iiHOMe q Detailed Design Specification Smart Door 1 Introduction The Detailed Design Specification Document provides detailed information regarding the design aspects of the Smart Door System Included in this document are the architecture overview detailed design specs layer definitions layer subsystems and modules and testing plan For each section in this document we will provide detailed information on how the Smart Door System is implemented 2 Architecture Overview 2 1 Architecture Description One of our design principles for the Smart Door product architecture is simplicity We strove to develop a product architecture that is as simple as possible while still fulfilling the requirements levied upon the Smart Door system In order to complete
30. aces 3 3 3 6 3 Push Notification Module Data Structure 3 3 3 6 4 Push Notification Module Processing receivedEvent function id var pushNotification window plugins pushNotification if device platform android device platform Android pushNotification register successHandler errorHandler senderlD 834841663931 ecb onNotificationGCM else pushNotification register this tokenHandler this errorHandler badge true sound true alert true ecb app onNotificationAPN S provided by phonegap exampleActivity 3 3 3 6 5 Video Stream Module Description 3 3 3 6 5 1 Description Video Stream Module will pull a video and audio stream that is posted to the server 3 3 3 6 5 2 Function The primary functionality of this module is to allow other subsystems in the mobile app to have access to a video and audio stream 39 DDS Version 0 1 ALWAYS iis HOMe beer EH Detailed Design Specification Smart Door 3 3 3 6 6 Video Stream Module Interfaces 3 3 3 6 7 Video Stream Module Physical Data Structure 3 3 3 6 8 Video Stream Module Processing JE This is sample code that is provided by android device for media G Creates a media file in the code Environment DIRECTORY PICTURES directory The directory is persistent and available to other applications like gallery zk zk param type Media type Can be video or image re
31. controller needs to handle the request 3 4 4 3 2 Request Interface Function The main function of the Request Interface is to parse the request and the data in it and pass it to the controller in an order that the controller knows how to use 3 4 4 3 3 Request Interface Module Interfaces 3 4 4 3 4 Request Interface Module Physical Data Structure 3 4 4 3 5 Request Interface Module Processing J parse request variables get controller get method call controller method with variables wi Requestinterface http variablesList pareseRequest http controller getController http method getMethod http WebController controller method variablesList 3 4 4 4 Web Controller Module Description 3 4 4 4 1 Web Controller Description The Web Controller module runs C Sharp code to accomplish predefined task on the server The web controller will receive a controller name method name and variables The controller will execute a predefine C Sharp function which will use the variables passed by the View Communications module 59 DDS Version 0 1 ALAN Spe Fa Detailed Design Specification Smart Door 3 4 4 4 2 Web Controller Function The main function of the Web Controller is to retrieve and store data in the server The most important part of this module is the predefine controller files it executes The file it executes enables the user to register devices to account monitor download video de
32. cription The Android Command Interpreter will handle the messages that are passed back and forth on the mobile device such Unlock lock and it will also pass information down to the server 3 3 3 5 1 2 Function The primary functionality of this module is know if the door is locked unlock and to be able pass any other messages such as requesting things from the server 37 ALWAYS ts HOMe DDS Version 0 1 ig Detailed Design Specification Smart Door 3 3 3 5 2 Android Command Interpreter Door Module Interfaces 3 3 3 5 3 Android Command Interpreter Module Physical Data Structure 3 3 3 5 4 Android Command Interpreter Module Processing Va This will be getting messages from the server AndroidRequest this will ask the server to start the microcontroller for processes Int UnlockLockMessage this will return a type int of the door being unlocked or locked 3 3 3 6 Push Notifications Module Description 3 3 3 6 1 Push Notification Module Prologue 3 3 3 6 1 1 Description The Push Notification Module will handle the events of what to be pushed and presented to the UI 3 3 3 6 1 2 Function The primary functionality of this module is to choose the events of either incoming call or missed call This will handle it be able to prepare for presentation 38 DDS Version 0 1 ALWAYS it HOMe beer oor Detailed Design Specification Smart Door 3 3 3 6 2 Push Notification Module Interf
33. crocontroller This will be live audio from the microcontroller Unlock lock In 1 lock 2 unlock 35 DDS Version 0 1 ALWAYS iisHOMe 19 Detailed Design Specification Smart Door 3 3 3 3 4 Android Activity Manager Module Processing This will be getting things from the classes and passing it AndroidProcessingLayer this will call the getters of the classes 3 3 3 4 Server Communication Manager Module Description 3 3 3 4 1 Server Communication Manager Module Prologue 3 3 3 4 1 1 Description The Server Manager Module will communicate with the server to be able to communicate with the microcontroller 3 3 3 4 1 2 Function The main function of this is to be able to pull the video and audio feeds as well as the status of the door lock 3 3 3 4 2 Server Communication Manager Module Interfaces 36 DDS Version 0 1 ALWAYS ii HOMe e e Detailed Design Specification Smart Door 3 3 3 4 3 Server Communication Manager Module Physical Data Structure 3 3 3 4 4 Server Communication Manager Module Processing This will be getting video and audio from the server as well as door atatus Int ServerUnlockLock this will return the status of the door ServerVideoAudio this will call the set in the video and audio class 3 3 3 5 Android Command Interpreter Module Description 3 3 3 5 1 Android Command Interpreter Door Module Prologue 3 3 3 5 1 1 Des
34. ctivities Log Emergency Power Supply Video Monitoring System Portability Smart Phone Paring Motion Sensor Local Storage Hardware Security Z Wave Open Source Nonintrusive Packaging Requirements Size Temperature Control Mounting Casing Software Acquisition Included Components Team Logo System Configuration Performance Requirements System Setup Notification Time Latency Response Time Data Transmission Live Video Feed Data Transmission Audio Transmission Recording Log Log Availability Recording Log Storage Capacity KL 5 LE LE Power Power Supply Power Power Source Emergency Backup Battery 1 0 Ports Operating Environment Jf pp Account Setup Video Log Downloads Video Photo Resolution System Availability Notificationtimith pp P Initialization Time Mounting Height Microphone Sensitivity Safety Requirements Camera Mounting Microphone Mounting Camera and Microphone Weather Safety Receptacles Maintenance and Support Requirements Software Updates User Manual Open Source Other Requirements Web Interface Support Portable Source Code Notification Control Table 13 Data Storage Layer Requirements Traceability Matrix 76 DDS Version 0 1 ALWAYS mHOMe Detailed Design Specification Smart Door 5 6 1 Data Storage Layer Requirements Traceability Matrix Analysis As is
35. droid app Two way audio communication between door and Smart Door android app Smart Door system returns to sleep mode upon completion of interaction Video logging and ability to retrieve videos using the Smart Door web app Smart Door system portability and ease of installation Smart Door system does not interfere with normal operation of door Smart Door system supports multiple Smartphones Table 14 Acceptance Criteria 77 DDS Version 0 1 ALWAYS it HOMe Fl Detailed Design Specification Smart Door 7 Appendices 7 1 N A No Appendices exist for this document 78 DDS Version 0 1 ALWAYS iis HOMe
36. e Call e End Call 3 2 1 4 2 Android Event Handler Interfaces User input such as Button Presses and Ul 6 Android System Actions AG 2 OUT Function Calls 3 2 1 4 3 Android Event Handler Physical Data Structure OnClick ActionListener This will control our button when they are pressed 3 2 1 4 4 Android Event Handler Processing each button will have a similar layout button setOnClickListener new View OnClickListener public void onClick View v Call function 21 DDS Version 0 1 ALWAYS iisHOMe Detailed Design Specification Smart Door 3 2 1 5 Android Function Chooser Description 3 2 1 5 1 Android Function Chooser Prologue 3 2 1 5 1 1 Description The Android Function Chooser will control all the functionality of what the buttons do 3 2 1 5 1 2 Function The primary functionality of this module is to have functions and functions that call the Android Application layers functions for following buttons e Login Screen Send e Monitor e Door Lock Unlock e Accept Call e Decline Call e End Call 3 2 1 5 2 Android Function Chooser Interfaces Formatted User requests Video data from Smart Door device KE SE ee 22 DDS Version 0 1 ALWAYSIREHOMe Detailed Design Specification Smart Door 3 2 1 5 3 Android Function Chooser Physical Data Structure Video File This will be a live video from the microcontroller Audio File This will be live audio from the microcontroller
37. e and it also identifies components that are not being used by the currently defined system architecture to fulfill any requirements This is very valuable for verifying and simplifying the system 69 DDS Version 0 1 ALWAYS mHOMe Detailed Design Specification Smart Door 5 2 System Level Requirements Traceability Matrix Requirements Traceability Matrix Hardware ween Android Gui Microcontroller App Android App Web App Server HDD Microcontroller HDD Customer Requirements Smartphone Application Control Snapshots Taken Keep Activities Log Emergency Power Supply Video Monitoring System Portability Smart Phone Paring Motion Sensor Local Storage Hardware Security Z Wave Lock Unlock Open Source Nonintrusive HEKS IMicrocontrolle Web Gui Android Gui Microcontroller App Android App WebApp boer Eesen em i Size Temperature Control Mounting Casing Software Acquisition Included Components Team Logo System Configuration Performance Requirements MicrocontrolelWeb Gui AndroidGui___ Microcontroller App Android App WebApp Serveres lseermop em System Setup Notification Time Latency Response Time Data Transmission Live Video Feed Data Transmission Audio Transmission Recording Log Log Availability Recording Log Storage Capacity Power Power Supply Power Power Source Emergency Backup Ba
38. e module the system will take in and username and password and send it to the server The password will be hashed Login Logout using SHA 1 at the client side and the salted in the server The module will also CSHTML file p E 2 Template have a link to the registration page for new users and a remember me checkbox to allow the user to stay logged in by keeping his or her session alive The log out aspect will destroy the user s session and the user will be redirected to the public home page Download The Download template identifies to the server which video file the user would Video CSHTML file like to download Template The pair device template allows the user to enter smart door device keys and Pair Device CSHTML file generate mobile device key The system can identify the owner of the device and Template map the calls correctly with this information SENDE The monitor template gives the user the ability to see through the smart doors onitorin live MELDE CSHTML file camera at any time The module will need the user to specify which smart door Template device he would like to look at The video template allows the user to see when video interactions occurred between the smart door device and the mobile device It gives a link to the List Videos CSHTML file video a button to download the video and a button to delete the video The Template table will have a search input so that the user can find a particular interaction quickly Acco
39. ence for our users To do this we will have to limit what they can do with the system and minimize all user input we can For our decision for the overall system we will try to keep true to our key principles If time for development becomes an issue we will remove the portable principle to make it easier for us to keep it made for only one particular area 17 ALWAYS mHOMe Detailed Design Specification Smart Door e The last one is security of the system These involve making a sturdy product The trade off is we would have to install it ourselves to make sure it is secured on the surface for security Since we do not cover installation according to our SRS we cannot guarantee the user will follow these principles 3 2 UI Layer 3 2 1 UI Layer Overview 2 d Microphone Camera Andr Andr Event 11 JSB Interface emm Speaker Interface an Manage S Microcontr r ICE Sag ERE E JS J1 17 5 Web GUI Android GUI 70 Figure 6 Ul Layer Overview 3 2 1 1 UI Layer Data Element Descriptions Table 6 Ul Layer Data Element Description 3 2 1 Android GUI Subsystem 3 2 1 1 Android GUI Subsystem Principles Communication The Android GUI has to be interactive to allow communication between the mobile device and hardware to satisfy the key part of our project Usability The Android GUI will be simp
40. ensure product viability 4 1 3 Feasibility This is similar to the requirements analysis and review except this focuses on our team s ability to meet project requirements If the team is unable to deliver a product that meets its specifications then we will need to determine how feasible the feature is that is not meeting requirements This is a combination of Risk Management but requires a QMP for qualitative and quantitative analysis 4 1 4 Documentation Documentation is critical to the success of our product It not only increases the longevity of the product by allowing other developers to extend its capabilities but it also acts as a risk mitigation tool for identifying design and implementation mistakes Our documentation should be of such quality that all members on the team are able to discern each other s design from their description 66 DDS Version 0 1 ALWAYS iisHOMe q Detailed Design Specification Smart Door 4 1 5 Coding Review and Analysis The coding review will help the team in two areas First it will allow additional team members to verify and validate the implementation to reduce errors and confusion Second we will all have knowledge of the system which will make our design process more cohesive It essentially serves to reinforce our product design 4 2 Key Test Assumptions Requirements dependencies 4 2 1 Module Unit Level Testing Module and Unit level testing are iterative processes We will conduct mod
41. er The Startup Manager module will consist of one or a series of registry entries to control how the microcontroller boots and what programs are run at startup 3 3 4 8 2 Startup Manager Function The Boot and Crash Recovery module will enable the Smart Door app to be run at start up and communication with the server to be established 3 3 4 8 3 Startup Manager Interfaces 3 3 4 8 4 Startup Manager Module Physical Data Structure 50 DDS Version 0 1 ALWAYS iisHOMe i EZ Detailed Design Specification Smart Door 3 3 4 8 5 Startup Manager Module Processing The startup manager will not have any code to run The registry entries that it represents will cause the C application to begin running 3 4 Network Layer 3 4 1 Network Layer Overview Android Comrmuscation NINI NJ N Figure 11 Network Layer Overview 3 4 2 Network Layer Data Element Description Table 8 Network Layer Data Element Description 51 DDS Version 0 1 ALAN Spe Detailed Design Specification 3 4 3 Video Server Subsystem Smart Door 3 4 3 1 Video Server Module Description The Video Server Subsystem is facilitates interaction between the Smart Door device and the users android phone To accomplish this goal the Video Server hosts h 264 streaming video converts the h 264 video into MPG4 for storage passes hardware information messages and processes commands from the Android 3 4 3 2 Video Server Diagram LJ ik 2 P1 P2 P3 P4
42. er Communication Manager Structure h624 Stream h 264 Stream Digital Video data stream mpg4_Video mpg4 File Digital video file door_State Variable to represent the open close of the Door 54 DDS Version 0 1 ALWAYS itsHOMe EH Detailed Design Specification Smart Door 3 4 3 5 5 Microcontroller Communication Manager Module Processing J if else statement to route communications if communication on P 3 channel if communication is a stream forward stream to host stream module else forward message to communications message processor if communication is on VS 4 channel forward communication to Hardware Subsystem 3 4 3 6 Command Message Processor Module Description 3 4 3 6 1 Command Message Processor Module Description The Command Message Processor module will be a part of our software component running on the server 3 4 3 6 2 Command Message Processor Module Function The Command Message Processor module s function is to relay commands between the Android Device and the Smart Door device 3 4 3 6 3 Command Message Processor Module Interfaces ven JN MP3 Stream and command messages from Android Communication Manager module MP3 Stream and command messages from Command Message Processor module Sensor data and notifications to Android Communication Manager module Sensor data and notifications from Microcontroller Communication Manager module 3 4 3 6 4 Command Message Processor Module Physical
43. er a long distance Responsiveness Interactions will not be meaningful unless the system responds quickly enough so that it does not hinder the normal flow of conversation between users Portable The system must be designed to be portable and easy to install This includes both the software and physical components Usability The system must be easy to set up and operate in order for users who may not be technologically sophisticated to be able to use the Smart Door product Simplicity In order to meet a large majority of our requirements the Smart Door system must be simple Simple to set up simple to configure simple to operate overall the system must be simple Security The Smart Door device must be theft resistant 3 1 2 Trade off Parameters We have identified seven trade offs correspond to seven detailed design key principles DDS Version 0 1 In terms of interactive we have to keep interactive no matter what because that is the whole point of our system For responsiveness it is needed but the trade off is how much time we will have to work on it to get a good response time We determined the specification on a good response time in our SRS Portable will make our system easy to install but this one could be optional to do To do this the system will be able to mount on any door but that might not be the case because of having to power it Usability and Simplicity goes hand in hand where it makes the system better experi
44. evel Testing ses sense en keen ktr ken k rn ker k rets rr teser erne snes k renee 67 3 DDS Version 0 1 ALWAYSIREHOMe Detailed Design Specification Smart Door 4 2 2 Component Level Testing u aenesenuabenedetusbdnsuelades been skele 4 2 3 Integration Testing eerste Eege eder eit 68 4 2 4 System Verification Testing sisenesid sanai aiae aE EERE SEE 68 4 3 Brief Test Case Description for Function TEStING c cccccccessssessseeececeseeseaeaeceeecesesseaeaeeeesens 68 4 3 1 Expanded in Test Blannen enge ege Eeer 68 5 Requirements Traceability Matrix issnin eisrean eiiean aai e aani 69 5 1 Requirements Traceability Matrix PUrpose rrrrrnnnnrnrvvnnrnannnnnnrvnvennsnannnnnnrvnnrsrsnnnnnnnnrsnnssnsnnnnnnrnnn 69 5 2 System Level Requirements Traceability Matt 70 5 2 1 System Level Requirements Traceability Matrix Analvsis se esssnnnnee 70 5 2 2 System Level Requirements Traceability Matrix Findings c c cccccccesssssseeceeeeecessessaeees 71 5 3 Ul Layer Requirements Traceability mat 71 5 3 1 Ul Layer Requirements Traceability Matrix Analysis cc ccccccccsssssssceeeescesssssaeeeseesseeeees 72 5 3 2 Ul Layer Requirements Traceability Matrix Findings cc ccccccccsssssssceceesesssesssaeeeeeeeseeeees 72 5 4 Processing Layer Requirements Traceability matt 73 5 4 1 Processing Layer Requirements Traceability Matrix Analvsis 73 5 4 2 Processing Layer Requirements Traceability Matrix Findings
45. evident by the sparseness of this table the storage layer is both simple and contributes to the satisfaction of very few requirements The simplicity of these modules does not mean that they are not important The requirements satisfied by the HDDs and the functionality they provide are both crucial to the overall systems performance and usability 5 6 2 Data Storage Layer Requirements Traceability Matrix Findings The HDDs are simply connected hardware and all specified functionality is supported by drivers installed with the operating system 6 Acceptance Plan Assumptions Relative to Detailed Design 6 1 Packaging and Installation 6 1 1 RTMP Server installation The RTMP server will be automatically installed as part of the overall software install and the installer will prompt the user for any information that cannot be obtained through Windows APIs 6 2 Acceptance Testing Each Acceptance Criteria will have a unique functional test to be carried out by a sponsor representative Successful completion of all ten acceptance tests will constitute acceptance of the product These tests will be specified in the Smart Door test plan 6 3 Acceptance Criteria Wakes and notifies upon connected doorbell being pressed Wakes and logs the status of the connected door upon connected door opening or closing Live video monitoring capability within the Smart Door android app One way video communication between door and the Smart Door an
46. he attached microphone Digital Signal Digital video data streams to be passed to Microcontroller App Digital Signal Digital audio data streams to be passed to Microcontroller App 3 2 2 4 5 USB Interface Module Processing leg A while loop will wait for input data If data is receiving begin transmitting the data Ki while no digital data stream wait and listen if data is received Proceed to transmit to Microcontroller 3 2 2 5 Speaker Interface Module Description 3 2 2 5 1 Speaker Interface Description The Speaker Interface Module is a connection interface that establishes connection between the Speaker and the Microcontroller i e USB sound cards that build in or externally plug into the Microcontroller via USB port 3 2 2 5 2 Speaker Interface Function The Speaker Interface allowing a single driver to work with the various USB sound devices on the market and establishes connections between the speaker and the Microcontroller 25 ALWAYS iisHOMe DDS Version 0 1 Detailed Design Specification Smart Door 3 2 2 5 3 Speaker Interface Module Interfaces UI 13 Digital audio data stream to be passed to the Speaker Fr Digital audio data streams from the Microcontroller App 3 2 2 5 4 Speaker Interface Module Physical Data Structure audio In Digital Signal Digital audio data stream from the Microcontroller App Digital Signal Digital audio data streams to be passed to the Speaker
47. ill not be usable as anything other than a doorstop without somewhere to store the system data 3 5 4 2 Micro Controller HDD Subsystem Diagram Micro Controller HDD Figure 16 Microcontroller HDD Subsystem Overview 3 5 4 3 Store Retrieve HDD Data Module Description The Microcontroller HHD stores the microcontroller OS configuration data and offline data The Microcontroller HHD Stores all data backups when there is a lack of WIFI signal 3 5 4 4 Retrieve HDD Data Module Function Retrieve HDD data module s functionality is handled natively by the Linux OS 3 5 4 5 Retrieve HDD Data Module Interfaces 65 DDS Version 0 1 ALWAYS iisHOMe Detailed Design Specification Smart Door 3 5 4 6 Retrieve HDD Data Module Physical Data Structure 3 5 4 7 Retrieve HDD Data Module Processing 4 Quality Assurance 4 1 Overview 4 1 1 Purpose The Quality Management Plan QMP is necessary to ensure product design and implementation meets specifications It will be used as a way to validate and verify our product solves the original problem given This includes our requirements and those of our stakeholders 4 1 2 Requirements Analysis and Review This is a continual review process that ensures that specified requirements are still feasible and within the scope of our design The SRS requirements are not engraved in stone The team will constantly monitor our requirements and receive stakeholder feedback to
48. ing USB Interface Speaker Interface and GPIO Interface 3 2 2 7 2 Microcontroller BUS Interface Function The Microcontroller BUS Interface serves as a bridge to connect different interfaces to the Microcontroller 3 2 2 7 3 GPIO Interface Module Interfaces awi Im Digital data stream from USB Interface HW2 Digital data stream to Speaker Interface HW3 IN Digital data stream from the GPIO interface 4 IN Digital data from the Microcontroller ing OUT 3 2 2 7 4 GPIO Interface Module Physical Data Structure audio In Digital Signal Digital audio data stream from the Microcontroller App Digital Signal Digital audio data streams to be passed to the Speaker Digital Signal Digital command streams to GPIO Interface data Out Digital Signal Digital data streams to be passed to the Microcontroller App Digital Signal Digital command streams from the Microcontroller App Digital Signal Digital data streams from the GPIO Interface 28 DDS Version 0 1 ALWAYS mHOMe Fl Detailed Design Specification Smart Door 3 2 2 7 5 Microcontroller BUS Interface Module Processing The Microcontroller BUS Interface will use a while loop The while loop will handle messaging from connected peripherals while no signal wait and listen if receive command message from Microcontroller Identify signal path Send command streams to the right peripherals if receive data message from peripherals Send data packets to Mic
49. ion Smart Door even though UI may not be critical for the projects functionality it is quite important for the customers acceptance of the Smart Door 5 2 2 System Level Requirements Traceability Matrix Findings Based on our analysis we will prioritize our development as described below First we will develop initial functionality of the Microcontroller Application Android Application and Video Server subsystems This will allow us to verify video and audio streaming capabilities early in our implementation phase of development Following the verification of a working data path and video streaming capabilities we will continue to refine these modules and develop the remaining modules 5 3 UI Layer Requirements Traceability matrix UI Layer Requirements Traceability Matrix Display Layout Android Event Android Functi Web Display View Constructor Request Handler Sitz E ee USB Interface Microcontroller BUS GPIO Interace Speaker Interface Manager Handler Handler Customer Requirements Smartphone Application Control Snapshots Taken Keep Activities Log Emergency Power Supply Video Monitoring System Portability Requirement Satisfied by Smart Door Devi Smart Phone Paring Motion Sensor Local Storage X Hardware Security Requirement Satisfied by Smart Door Device Z Wave Lock Unlock X X Open Source X Nonintrusive Requirement Satisfied by Smart Doo
50. it validate it and hand it to the Server HHD in an order to execute a SQL command 3 4 4 5 3 Server HHD Communications Module Interfaces 61 DDS Version 0 1 ALWAYS iisHOMe z Detailed Design Specification Smart Door 3 4 4 5 4 Server HHD Communications Module Physical Data Structure 3 4 4 5 5 Server HHD Communications Module Processing JE validate statement and variables if valid execute command i ServerHHDCommunications SQL Variables Command sqIValid SQL Variables If Command valid ServerHHD Command 3 4 4 6 View Communications Module Description 3 4 4 6 1 View Communications Description The View Communications module is the interface between the Web Application outgoing request and the Web GUI subsystem The module will transfer the instruction the controller created to the Web GUI 3 4 4 6 2 View Communications Function The main function of the View Communications is to pass the data received from the Web controller to the Web GUI and to validate that the data has the correct format and syntax 3 4 4 6 3 View Communications Module Interfaces 3 4 4 6 4 View Communications Module Physical Data Structure DDS Version 0 1 ALWAYS itsHOMe Detailed Design Specification Smart Door 3 4 4 6 5 View Communications Module Processing E validate data loop send data Si ViewCommunications Instructions For each object in Instructions If valid inst
51. l command data from the Microcontroller App W4 General digital data to be passed to the Microcontroller App UI 16 Im O Digital notification data streams from Doorbell 3 2 2 6 4 GPIO Interface Module Physical Data Structure Digital Signal Digital command data stream from the Microcontroller App to Door Lock Notification1_In Digital Signal Digital notification data streams from Door Sensor Notification2_In Digital Signal Digital notification data streams from Doorbell Status_In Digital Signal Digital status data stream from Lock Sensor Digital Signal Digital command data stream from the Microcontroller App Data_Out Digital Signal Digital data stream to be passed to the Microcontroller App 3 2 2 6 5 GPIO Interface Module Processing TE The GPIO Interface will use a while loop The while loop will handle messaging from connected peripherals Ki while no signal wait and listen if receive command message from system Process and send command signal to peripherals if receive data message from peripherals Send status message received from peripherals to system 27 ALWAYS EmHOMe DDS Version 0 1 Detailed Design Specification Smart Door 3 2 2 7 Microcontroller BUS Interface Module Description 3 2 2 7 1 Microcontroller BUS Interface Description The Microcontroller BUS Interface is built in the Microcontroller This interface establishes and utilizes different connections to other interfaces includ
52. le to use and have buttons for the users to click to start actions in our system This way any user can use our application 18 DDS Version 0 1 ALAN See Detailed Design Specification Smart Door Responsiveness The Android GUI will need to be responsive for the buttons in order to make users feel like the application is working 3 2 1 2 Android GUI Subsystem Diagram 2 Ul 5 Se UI6 L Y Android Android Event Display Layout Handler r G2 Manager Android Android GUI e Function Chooser 3 2 1 3 Android Display Layout Manager Module Description 3 2 1 3 1 Android Display Layout Manager Module Prologue 3 2 1 3 1 1 Description The Android Display Layout Manager will display predefined screens on the application 3 2 1 3 1 2 Function The primary functionality of this module is to have the following screens 1 Login screen 2 Home screen 3 Call Screen 3 2 1 3 2 Android Display Layout Manager Module Interfaces Android GUI screens and buttons Video Audio Door unlock lock push notification 19 DDS Version 0 1 ALWAYS mHOMe Detailed Design Specification Smart Door 3 2 1 3 3 Android Display Layout Manager Module Physical Data Structure Video File This will be a live video from the microcontroller Audio File This will be live audio from the microcontroller Unlock lock Int 1 lock 2 unlock 3 2 1 3 4 Android Display Layout Manager Module Processing Call Screen The othe
53. lete video login logout create web account and generate a mobile key 3 4 4 4 3 Web Display Module Interfaces Object with the data need to construct the view Variables need to run the controller method SQL statement that needs to be validated Response of a SQL statement 3 4 4 4 4 Web Controller Module Physical Data Structure ALL Data e 3 Function parameters converted from strings to an arbitrary data type SQLStatement A string which will be sent to the Server HHD Communications ListOfData A list of instructions that will be sent to the Web GUI Set The register device to account file is triggered by a request from the Web GUI to egister 2 8 store an association in the SQL database The file will validate that the model for Device to CS File Recount the data structure is correct and that it is a safe SQL variable The monitor file takes the request for a stream of a video file stored in the Server Monitor CS File HHD to the Web GUI Download CS File The file will send the Web GUI the video file it has requested from the Server HHD Video Der video CS File The file will remove a video file from the Server HHD The file authorizes and de authorizes users of the system The file will hash the password inputted and apply the salt of the username inputted and compare the Login Logout CS File hashed and salted passwords together If the password combination works then it creates a session for the user and grants the user acces
54. m upon booting the microcontroller 3 3 4 4 Data Interpreter Module Description 3 3 4 4 1 Data Interpreter Description Data Interpreter module is the software side of the hardware interface to devices controlled by the Microcontroller BUS 3 3 4 4 2 Data Interpreter Function The Data Interpreter module accepts three types of digital signals from the Hardware subsystem The sensor signals are converted into Boolean values to be used for decisions by the software logic in the Data Processor module The audio and video signals are simply passed to the Data Processor module to be converted and routed 3 3 4 4 3 Data Interpreter Interfaces 43 DDS Version 0 1 ALWAYS iisHOMe snart EH Detailed Design Specification Smart Door 3 3 4 4 4 Data Interpreter Physical Data Structure 3 3 4 4 5 Data Interpreter Module Processing f Event Listeners will wait for any data If an event is received begin transmitting the data Example code is adapted from msdn microsoft com Ki class dataInterpreter public void audioListener digital audio signal action pass the signal to the data processor module void videoListener digital video signal action pass the signal to the data processor module void doorbellListener digital sensor signal action pass the signal to the data processor module void hookEvent CSource pSource __hook amp CSource MyEvent pSource amp CReceiver audioListener
55. ment Satisfied by Smart Door Device Requirement Satisfied by Smart Door Device Requirement Satisfied by Smart Door Device Notification Control A H er pa Table 10 Ul Layer Requirements Traceability Matrix 71 DDS Version 0 1 ALWAYS mHOMe q Detailed Design Specification Smart Door 5 3 1 Ul Layer Requirements Traceability Matrix Analysis The UI Layer is critical for the Customer and Performance categories of requirements The modules in this layer support the fulfillment of forty three requirements As the entire system has fifty three requirements the UI layer supports approximately eighty percent of the requirements in the system 5 3 2 UI Layer Requirements Traceability Matrix Findings Within this layer a Three issues that stand out as areas of concern Firstly every module contributes to Response time which implies that it will be very hard to succeed in meeting our goals Since the response time will be shared amongst many modules the variance per module must be extremely low in order to keep the overall variance within our goal The second concern is that the microcontroller bus has too many responsibilities Since all the communications must flow though this module we must take care during development to assure that the timing and structure of the communications does not exceed the bandwidth of the BUS Finally many of the requirements are marked as satisfied by the Smart
56. oller It also serves a way to process data from storage to meaningful information It will perform the task of processing the different types of data from our different interface into a uniform data that can be used by other components in our system This is the backbone of our system that will handle the bulk of the processing 2 8 Data Storage Layer 2 8 1 Data Storage Layer Decomposition Chart Micro Controller HDD Figure 5 Data Storage Layer Decomposition Chart 2 8 2 Data Storage Layer Description The Data Storage Layer will store information either locally or remotely on a server This is where the information will be held until it needs to be access This is where the storage of the videos will be for user to see past ones and live ones 16 DDS Version 0 1 ALWAYS ii HOMe q Detailed Design Specification Smart Door 3 Detailed design Specifications 3 1 Overall Detailed Design principles assumptions and trade off parameters 3 1 1 Overall Detailed Design Principles When team Always Home was developing the Detail Design Principles we identified seven fundamental detail design principles that contribute to the Smart Door project s successful development These are Interactive The smart Door devices primary purpose is to facilitate interaction between two people who are separated from each other by a large physical distance The design of the system must be transparent enough to enable personal interaction ov
57. ore on the Microcontroller HDD Control messages and mp3 Audio stream from Video Server Subsystem 3 3 4 7 4 Local Data Access Module Physical Data Structure Boot procedures registry entries from the Microcontroller HDD Audio stream from users android device 3 3 4 7 5 Local Data Access Module Processing ZS Event Listeners will wait for any data If an event is received begin transmitting the data Example code is adapted from msdn microsoft com e class localDataAccess public handle A V streams void mpg4Listener digital A V event action pass the MPG4 file to the Microcontroller HDD handle user interaction at door void notificationListener notification logs action pass the signal to the Microcontroller HDD 49 DDS Version 0 1 ALWAYS itisHOMe 19 Detailed Design Specification Smart Door void hookEvent CSource pSource __hook amp CSource MyEvent pSource amp CReceiver mpg4Listener __hook amp CSource MyEvent pSource amp CReceiver notificationListenerr void unhookEvent CSource pSource __unhook amp CSource MyEvent pSource amp CReceiver mpg4Listener __unhook amp CSource MyEvent pSource amp CReceiver notificationListener 3 3 4 8 Startup Manager Module Description 3 3 4 8 1 Startup Manager Description The Startup Manager module is responsible for the system startup procedure of the microcontroll
58. our architecture while achieving this goal we have developed a three layer functional architecture where the processing layer has been extended The layers we have defined for the Smart door functional architecture are UI Layer Process Layer Server Layer and Storage Layer In addition to a functional architecture the HW component subsystem in the UI layer will include a physical architecture description This was found to be necessary due to a large number of requirements levied on the physical design and layout of the Smart Door device The defined layers and the subsystems within them fully support the requirements and functionality defined for the Smart Door system DDS Version 0 1 ALWAYS mHOMe Detailed Design Specification Smart Door 2 2 Subsystem Module Decomposition Chart et Figure 1 Subsystem Decomposition Chart DDS Version 0 1 ALWAYS iis HOMe Detailed Design Specification Smart Door i 2 3 Data Element Descriptions System Level Data Element Description Data Element Description Webpages displayed on users Monitor from Web GUI User Input into Web GUI User Input passed to Web App from Web GUI Webpages and messages to be displayed by Web GUI from Web App Interactions displayed on users Android Device User Input into Android App User Input passed to Android App from Android GUI Interactions to be displayed by the Android GUI form the Android App Raw Data from the
59. pret inputs from the door mounted hardware and send notifications to the Video Server so that the Video Server can notify devices Additionally the Microcontroller Application Subsystem will turn on the camera and microphone for monitoring upon receiving a signal from the Android Application via the Video Server Usability The Microcontroller Application Subsystem supports usability by enabling communication between users of the smart door system Communication is the core functionality of the smart door system and it would not be possible without the Microcontroller Application Subsystem Communication The Microcontroller Application Subsystem supports the communication principle by providing the physical link between users of the smart door system Without the Microcontroller Application Subsystem there would be no 42 ALWAYS iis HOMe Detailed Design Specification Smart Door way for the person at the door to communicate remotely with the owner of the house Requirement Satisfaction The Microcontroller Application Subsystem supports requirements satisfaction by providing a framework for the functionality described in the SRS document Usability The Microcontroller Application Subsystem supports usability by providing the necessary communication between layers to support designed functionality of the system Reliability The Microcontroller Application Subsystem supports Reliability by enabling the automatic launch of the system progra
60. r 2 screens will be very similar with a layout Si Call Screen The other 2 screens will be very similar with a layout Kl lt xml version 1 0 encoding utf 8 gt lt resources gt lt string name app name gt Smart Door lt string gt lt string name button_end gt End lt string gt lt string name button_accept gt Accept Call lt string gt lt string name button_decline gt Decline Call lt string gt lt string name title activity main gt Call lt string gt need Video stream here to be place on the background lt resources gt lt Button android layout width wrap content android layout height wrap content android text Qstring button accept gt lt Button android layout width wrap content android layout height wrap content android text string button decline gt lt Button android layout width wrap content android layout height wrap content android text string button end gt 20 ALWAYS iiHOMe DDS Version 0 1 Detailed Design Specification Smart Door 3 2 1 4 Android Event Handler Module Description 3 2 1 4 1 Android Event Handler Prologue 3 2 1 4 1 1 Description The Android Event Handler will control all the action listeners for the button when they are pressed 3 2 1 4 1 2 Function The primary functionality of this module is to have actionlisteners for following buttons e Login Screen Send e Monitor e Door Lock Unlock e Accept Call e Declin
61. r Device Packaging Requirements Size Requirement Satisfied by Smart Door Device Temperature Control Requirement Satisfied by Smart Door Device Mounting Requirement Satisfied by Smart Door Device Casing Requirement Satisfied by Smart Door Device Software Acquisition Included Components X X Team Logo Requirement Satisfied by Smart Door Device System Configuration X X Performance Requirements System Setup Notification Time Latency Response Time Data Transmission Live Video Feed Data Transmission Audio Transmission Recording Log Log Availability Recording Log Storage Capacity Power Power Supply Power Power Source Emergency Backup Battery 1 0 Ports Operating Environment Account Setup Video Log Downloads Video Photo Resolution System Availability Notification Limit Initialization Time Mounting Height Microphone Sensitivity Safety Requirements Camera Mounting Microphone Mounting Camera and Microphone Weather Safety Receptacles Maintenance and Support Requirements Software Updates User Manual Open Source Other Requirements Web Interface Support Portable Source Code Requirement Satisfied by Smart Door Device Requirement Satisfied by Smart Door Device Requirement Satisfied by Smart Door Device X X X X X Requirement Satisfied by Smart Door Device X Requirement Satisfied by Smart Door Device Require
62. rocontroller App 3 2 3 Web GUI Subsystem 3 2 3 1 Web GUI Subsystem Principles Simplicity In order to meet the Smart Door Project Overall Principles the Web GUI must be simple to navigate simple to configure and simple to operate Complete The Web GUI Subsystem must fully describe the Web Application Subsystem functionality Security The Web GUI Subsystem must be hacker resistant 3 2 3 2 Web GUI Subsystem Diagram Web Display Request Handler View Constructor Web GUI Ul 4 Ul 3 Figure 8 Web GUI Subsystem Overview 29 DDS Version 0 1 ALWAYS ii HOMe Detailed Design Specification Smart Door 3 2 3 3 Web Display Module Description 32331 Web Display Description The Web Display is in charge of sending the compiled HTML file and the corresponding JavaScript and CSS files It can also send video and image file to the user It handles the transportation of the data back to the user s computer 3 2 3 3 2 Web Display Function The main function of the Web Display is to move the data created by the view constructer to the user that requested the data 3 2 3 3 3 Web Display Module Interfaces Files streams to the users browser application ue fin Data object containing a list of file 3 2 3 3 4 Web Display Module Physical Data Structure HTML File HTML A HTML file that was created by the View Constructor JavaScript File Static JavaScript file in the Scripts folder CSS File Static
63. roducer and Consumer Findings The main findings we found is the web is loosely coupled compared to the rest of the system The main connection comes from the database instead of from the server layer The other finding is there is no application layer in the web because the server is its application layer Finally there is only one line Web GUI line to show communication between the modules in that subsystem 12 ALWAYS is HOMe DDS Version 0 1 e Detailed Design Specification Smart Door Android Producer Consumer Table Table 4 Detailed Design View of Web Producer Consumer Relationships 2 4 3 1 Android Producer Consumer Analysis The Mobile analysis with this is there are more producers in the application layer because of factoring how message will be transferred for the door lock status The next thing this shows is the server layer consumes more information because it is taking a lot more input from the mobile and hardware layer 2 4 3 2 Android Producer and Consumer Findings The main findings we found is the Android is heavily reliant on the server for its communication to the hardware Without that the android device becomes useless The other finding is the application layer produces more because it is creating a lot things such as converting video file types and placing them into java classes 13 DDS Version 0 1 ALWAYS iisHOMe ed tess Detailed Design Specification Smart Door Hardware Producer Consumer Table
64. ruction Continue Else Return 0 sendinstructions Instructions 3 5 Data Storage Layer 3 5 1 Data Storage Layer Overview S eh SC feet Server HDD Micro Controller HDD Figure 14 Data Storage Layer Overview 3 5 2 Data Storage Layer Data Element Description No new inter layer data communications to describe 3 5 3 Server HDD Subsystem 3 5 3 1 Server HDD Subsystem Principles Security Digital and physical security measures on the Microcontroller HDD will help to keep the users data safe Interactive No interactive functionality of the Smart Door system is possible without somewhere to store the data supporting that functionality Reliability The overall Smart Door performance relies strongly on the reliability of the Microcontroller HDD Any delay or failure of this system will completely disable all functionality of the Smart Door system Usability The Smart Door system will not be usable as anything other than a doorstop without somewhere to store the system data 63 DDS Version 0 1 ALWAYS ii HOMe Ld Detailed Design Specification Smart 3 5 3 2 Server HDD Subsystem Diagram N1 N2 N3 N4 ef A Store retrieve e l ardinda Server HDD DS 2 Ce 1 W s Server HDD L Figure 15 Server HDD Subsystem Overview 3 5 3 3 Store Retrieve Server Data Module Description The Server HHD stores the Server OS configuration data and online data The Server HHD Stores all data
65. s to the system and his information GR eer The file allows new user to create accounts with the system The file will need to CS File make sure that the password is of sufficient length and format The file will need to Account i make sure that the username enters is unique to the system Gates The file will generate and map a GUID to identify the mobile devices paired with Fil D D D D Mobile Key CS File this account and store the association in the Server HHD DDS Version 0 1 ALWAYS mHOMe Detailed Design Specification Smart Door 3 4 4 4 5 Web Controller Module Processing JE read C sharp file run file if successful pass instructions to view communications WebController controller method variables ControllerObject Open controller Instructions ControllerObject run method variables If Instructions success ViewCommunications Instructions 3 4 4 5 Server HHD Communications Module Description 3 4 4 5 1 Server HHD Communications Description The Server HHD Communications module is the interface between the Web Application and the Server HHD subsystem The module will parse the SQL Statement and determine if it follows the correct syntax The module will also make sure that the variables are not harmful and send the command to be executed 3 4 4 5 2 Server HHD Communications Function The main function of the Server HHD Communications is to parse the SQL and the data in
66. scccccessbaceads DELS Eaa 33 3 3 2 Processing Layer Data Element Description rrrrrrrnnnnnnnrvvvrnnrrannnnnnrnnnernsrannnnnnrvnnssnsnnnnnnnnnn 34 3 3 3 Android Application Subsystem c cccccccssssssssssecesecesessesesseceeecssesseasaeeeeeeuseeseasaeeeeeesseesees 34 3 3 4 Microcontroller Application Subsvstem 41 34 Network LAV OM 2 czscsseccisccetesssaseiezscatenastassbaceceacibesas E A T 51 3 4 1 Network Layer Overvlew 51 3 4 2 Network Layer Data Element Description 51 3 4 3 Video Server Subsvstem erri issno kea senner essaa kenisi s ii 52 3 4 4 Web Application KEE 58 3 5 Data Storage L yer rr e eaa e EE ee eeh ed 63 3 5 1 Data Storage Layer Oyepnlew ee RkEENEEREEEENEEREEENEEEEE ENEE EREEENEEEREE SNE EREE ENEE EeER cons EEEE 63 3 5 2 Data Storage Layer Data Element Description 63 3 5 3 Server HDD SUbSyStEMi iesse SNE ENEE 63 3 5 4 Micro Controller HDD Subsystem c cccccccesessssssecececesseseaeeeceeecesseseaaeseeeescessesneaeeeeeesseeegs 65 A e EI TE le E 66 ZE ET 0 GE EEE E a E 66 4 1 1 Mie Le TEE 66 4 1 2 Requirements Analysis and Review c cccccccesssssssecececessesenseseceeecesseeeaeseeeeseessesneaeeeeeesseeeegs 66 4 1 3 St le lte EE 66 4 1 4 Documentation sisri cironi assentar n eins re EEN REEE ESEN AES 66 4 1 5 Coding Review and Analyse 67 4 2 Key Test Assumptions Requirements dependencies rrrrnarnvannnvrrrrvrrrrnvnnennvnrrnvrrrrvrsennvnsenvesrnnr 67 4 2 1 Module Unit L
67. treams void audioVisualListener digital A V event action pass the h 264 stream to the Video Server handle user interaction at door void doorbellListener doorbell event action pass the signal to the local data access module void hookEvent CSource pSource __hook amp CSource MyEvent pSource amp CReceiver audioVisualListener __hook amp CSource MyEvent pSource amp CReceiver doorbellListener void unhookEvent CSource pSource __unhook amp CSource MyEvent pSource amp CReceiver audioVisualListener __unhook amp CSource MyEvent pSource amp CReceiver doorbellListener J5 3 3 4 7 Local Data Access Module Description 3 3 4 7 1 Local Data Access Description Local Data Access module is a portion of the C application 3 3 4 7 2 Local Data Access Function The Local Data Access module is responsible for storing and retrieving local data Local data will include video streams and interaction records that are recorded by the system when there is no network present Other data is boot record and system information required by the Startup Manager module 3 3 4 7 3 Local Data Access Module Interfaces DDS Version 0 1 48 ALWAYS its HOMe Detailed Design Specification Smart Door MPG4 Files and notifications from the Data Processor Boot logging Information Recorded MPG4 Files and notifications to store on the Video Server HDD MPG4 Files and notifications to st
68. ttery 1 0 Ports Operating Environment Account Setup Video Log Downloads Video Photo Resolution System Availability Notification Limit Initialization Time Mounting Height Microphone Sensitivity ae IMicrocontrolie Web cui Android Gui Microcontroller App Android app Web App ae Eesen em i Camera Mounting Microphone Mounting Camera and Microphone Weather Safety Receptacles Maintenance and Support Requirements Microcontrolle Android Gui Microcontroller App i Server OS MC HDD Software Updates User Manual Open Source Other Requirements Microcontrollen Web Gui Android Gui Microcontroller App Android App Server OS Web Interface Support Portable Source Code X Notification Control Table 9 Requirements Traceability Matrix 5 2 1 System Level Requirements Traceability Matrix Analysis Always Home used the Requirements Traceability matrix in order to verify that all requirements had been fulfilled and prioritize development order of subsystems and modules As shown in the Requirements Traceability Matrix above the UI layer contributes to the fulfilment of forty one requirements As the entire project is only subject to fifty requirements this means that the UI layer must support eighty two percent of the projects requirements This would indicate that 70 DDS Version 0 1 ALWAYS mHOMe Detailed Design Specificat
69. turn A file object pointing to the newly created file public static File getOutputMediaFile int type To be 12safe you should check that the SDCard is mounted using Environment getExternalStorageState before doing this if Environment getExternalStorageState equalsIgnoreCase Environment MEDIA_MO UNTED return null File mediaStorageDir new File Environment getExternalStoragePublicDirectory Environment DIRECTORY_PICTURES CameraSample This location works best if you want the created images to be shared between applications and persist after your app has been uninstalled 40 ALWAYS HOMe DDS Version 0 1 i Detailed Design Specification Smart Door Create the storage directory if it does not exist if mediaStorageDir exists if mediaStorageDir mkdirs Log d CameraSample failed to create directory return null Create a media file name String timeStamp new SimpleDateFormat yyyyMMdd HHmmss format new Date File mediaFile if type MEDIA TYPE IMAGE mediaFile new File mediaStorageDir getPath File separator IMG timeStamp jpg else if type MEDIA TYPE VIDEO mediaFile new File mediaStorageDir getPath File separator VID timeStamp mp4 else I return null return mediaFile 3 3 4 Microcontroller Application Subsystem 3 3 4 1 Microcontroller Application Subsystem Description
70. ule is to make a H 264 video stream available to view by the user s android device and to transcode the stream into an mpg3 file for viewing and downloading 3 4 3 4 3 Host Stream Module Interfaces h 264 Stream or MPG4 Stream to Android Communication Manager module ven Im h 264 Stream from Microcontroller Communication Manager module MPG4 Streams to Log Videos Actions module MPG4 Streams from Log Videos Actions module 3 4 3 4 4 Host Stream Module Physical Data Structure h624 Stream h 264 Stream Digital Video data stream mpg4 Video mpg4 File Digital video file mp3 Stream Digital audio data stream 53 DDS Version 0 1 ALWAYS iisHOMe Detailed Design Specification Smart Door 3 4 3 4 5 Host Stream Module Processing 3 4 3 5 Microcontroller Communication Manager Description 3 4 3 5 1 Microcontroller Communication Manager Description The Microcontroller Communication Manager module will be part of our software component running on the server 3 4 3 5 2 Microcontroller Communication Manager Function The Microcontroller Communication Manager routes communications to Host Stream Module or Communication Message Processor module as is appropriate 3 4 3 5 3 Microcontroller Communication Manager Interfaces h 264 Stream MPG4 Stream Sensor data and notifications from Microcontroller App P3 Subsystem Ppa out vsa IN MP3 Stream and command messages from Command Message Processor module 3 4 3 5 4 Microcontroll
71. ule level testing upon the completion of each module and we will conduct unit level testing upon the completion of related modules Module level testing will be defined as validating and verifying the internal functions within each module upon the completion of implementing the module Unit testing will be defined as testing the interfaces and data transfer between two related modules Modules are defined as related if they exchange any messages or information between each other Module and Unit level testing will not include interfaces across subsystem boundaries These interfaces will be tested during Integration testing 4 2 1 1 Test Assumptions 4 2 1 1 1 Module level testing assumes that the module has been completely implemented and debugged 4 2 1 1 2 Unit level testing assumes that each participating module has been implemented and debugged 4 2 1 2 Test Requirements Requirements will be generated for each module based on the system level requirements they are intended to fulfill according to the requirements traceability matrix Additional functional requirements will assure that the module fulfills its function within the subsystem 4 2 1 3 Test Dependencies 4 2 1 3 1 The Module level tests are intended to have no external dependencies since they are only testing internal functionality of a module 4 2 1 3 2 Unit level testing will depend on the proper implementation of each participating module Additionally unit level testing will not
72. ully 4 2 3 Integration Testing 4 2 3 1 Test Assumptions 4 2 3 2 Test Requirements 4 2 3 3 Test Dependencies 4 2 4 System Verification Testing Verification testing will confirm that Always Home designed and implemented the Smart Door system in such a way that the system as a whole meets all of the system level requirements Validation confirms that the Smart Door meets the needs of the stakeholders and will occur upon completion of the Acceptance criteria outlined in section six of this document 4 2 4 1 Test Assumptions 4 2 4 2 Test Requirements 4 2 4 3 Test Dependencies 4 3 Brief Test Case Description for Function Testing 4 3 1 Expanded in Test Plan The functional testing plan will be defined in the Test Plan document to be delivered with the prototype 68 DDS Version 0 1 ALWAYSIREHOMe q Detailed Design Specification Smart Door 5 Requirements Traceability Matrix 5 1 Requirements Traceability Matrix Purpose Team Always Home will use the requirements traceability matrix for two purposes requirements verification and system analysis For requirements verification the matrix verifies that all requirements are being fulfilled and that there are no unused modules For system analysis the matrix helps to identify modules which are overly complex have high coupling or other issues The requirements verification task identifies particular requirements which are not being met by the currently defined system architectur
73. unt The account configuration template allows the user to change his or her Configuration CSHTMLfile password The module also allows new users to create a new account Template 31 DDS Version 0 1 ALWAYS mHOMe Detailed Design Specification Smart Door 3 2 3 4 5 View Constructor Module Processing ZS parses data from the Web App executes main template executes sub templates Send generated file to the web display Si ViewConstructor data dataList getDataObjects data htmlfile for each file execution in datalist run interpreter or executefile add results to htmifile WebDisplay htmlfile 3 2 3 5 Request Handler Module Description 3 2 3 5 1 Request Handler Description The Request Handler forwards the HTTP request to the Web Application 3 2 3 5 2 Request Handler Function The main function of the Request Handler is to pass the http request if it follows the correct syntax 3 2 3 5 3 Request Handler Module Interfaces nm HTTP request from the user browser UI3 OUT Valid HTTP Request 3 2 3 5 4 Request Handler Module Physical Data Structure Request HTTP A String containing a request for the Web Application 32 DDS Version 0 1 ALWAYS itisHOMe F fort Detailed Design Specification Smart Door 3 2 3 5 5 Request Handler Module Processing fe regular expression send request Ki RequestHandler http regularExpression http regex if match regular

Detailed Design Specification Team: Always Home Project: Smart

Contents

Download Pdf Manuals

Related Search

Related Contents