I.

Document Overview

There are multiple design solutions depicted in this document which represent the
evolution of our detailed concept sketches, schematics, and annotated drawings that serve as our
potential solutions to address our prioritized list of design goals and requirements. Our list of
design goals and requirements consists of a listing of the features desired in our final design, our
specifications, our project constraints, and our project parameters.

Our design solutions will be preceded by our reflection and analysis of design goals and
requirements identified with prioritization in the form of a series of decision matrices. The
document will then conclude with our final design and justification for its selection.

II. Reflection and Analysis of Design Goals

Our objective is to develop a mobile parking application that is compatible with Android
and iOS devices that can be used to look up parking space availability at all UNC Charlotte
parking lots and decks on demand and in real time. Our application will require cloud-based
computing functionality for the purpose of providing reference documentation that can be
regularly updated in real time in accordance to the parking space availability readings provided
by our parking space monitoring systems in decks and lots. This is intended to provide updated
and on demand access to parking space availability for all users of the Niner Parking application.

There are two major design components to our project:

1) The parking surveillance system.

a) Final design feature:
i) This surveillance system needs to be able to track the count and specific
parking space availability of all individual UNC Charlotte lots and decks
using graphical position logging.
2) The application and data relay system with respect to the parking surveillance system.
a) Final design feature:
i) The application needs to be able to provide a large number of users over a
wide variety of software platforms regularly updated and accurate data
regarding individual parking space availability and count in all UNC
Charlotte lots and decks.
III. Prioritized List of Design Goals and Requirements

Note: Priority assignments will be given on a 1 - 5 scale where level 1 represents the lowest
design priority while level 5 represents the highest design priority. Priority assignments will be
given in the proceeding design feature listings for instance as a (2) for level 2.

Final Design Technical Specifications:

1. The product should remain inexpensive, costing at most $200 to implement. (3)
2. The p roduct should display a notice upon first launch notifying the user of data collection
policy and will adhere to its users preference for sharing data in accordance to the
official policy on the google play store1. (5)
3. Product will be designed for, and must be able to run and function properly on, an
Android device. (5)
4. Product will be designed to function on a 16:9 portrait orientation of a phone solely. (3)
5. Product will incorporate a mapped graphic Bitmap replication of the parking lots and
decks on campus that will indicate spaces. (3)
6. The product will be designed with the intent of minimizing client-side storage usage, and
should be no more than 20 MB when completed. (1)
7. The product will utilize no more than the power consumption standard of 2,750mAh. (5)
8. The product will transfer anonymous parking availability and usage data using SSL
Certificates to prevent third party data intrusion. (5)
9. The Cloud-based data transfer network for the product will be mounted on a secure UNC
Charlotte server located on the Main Floor of Atkins Library by the direction of Douglas
Lape, one of our key project mentors who is the UNC Charlotte Parking and
Transportation Services Director. (4)
10. The product user interface will be imagefile-mounted and will be formatted as a Bitmap
general graphic user interface (GGUI) image series. (3)
11. The logo for the application will be formatted as a bevelled Icons file as part of the
imagefile-mounted user interface for the product. (2)
12. The product will make use of the Java and Python software programming languages and
their source code interpretation engines. (3)
13. The products Java and Python programming languages must include their respective
imported software packages in the install file for Android devices.(5)
14. The products install file for iOS devices will make use of adaptive Java and Python
programming scripts when transcribing the install file into Swift 3 for interoperability. (4)
Final Design Constraints:

1. The product should ultimately be sold for free as an app through the google play store.
(3)
2. Any data such as user location, name, or any other unique identifier that the app collects
will adhere to the official policy on the google play store1, and will be explicitly stated to
the user and only collected with permission from the user. (5)
3. Product will adhere to all UNC Charlotte rules set for copyright and privacy listed on the
official UNC Charlotte website2. (5)
4. Cloud data network for app product must operate on secure network when anonymously
transferring parking availability data and app usage history. (5)

Final Design Parameters:

1. Product will strongly and clearly discourage distracted driving and use of the app when
driving. (3)
2. Product will be finished and ready for market testing by April 11th, 2018. (1)
3. Product will be monitored and updated as needed after its release. (2)
4. The user interface for the product must be user friendly and easy to read such that the
graphical user interface for the application is visually pleasing and responsive. (3)
5. The product application must effectively interface with the parking surveillance system
such that no data transfer errors occur when updating parking space availability data
through a secure server. (5)
6. The product will be designed to maximize device battery efficiency during usage. (4)

IV. Decision Matrices

The first step that we needed to accomplish was to determine what type of technology,
and subsequent hardware model, to use for parking availability monitoring in UNC Charlotte
parking decks and lots.

Note: Priority assignments used in the proceeding decision matrices can be found and derived
from Section III of Element D, which details the prioritized list of design goals and requirements
used in the proceeding decision matrices. Primary Matrices are more significant decisions than
Secondary matrices, so they display more details regarding our project evaluation.
Monitoring Technology Selection Matrix: (Table 1, Primary Matrix)
Solutions High Software Cost of Protection Cost of Final Score
Monitoring Integrabilit Maintenan of Privacy Implement
Accuracy y (4) ce (3) (5) ation (4)
(5)

Closed 5*4 4*4 3*5 5*3 4*5 86

Circuit
Television
(CCTV)

Pressure 5*5 4*5 3*5 5*5 4*3 97

Plate
Sensor

Light 5*2 4*3 3*4 5*5 4*3 71

Sensor

Ultrasonic 5*3 4*4 3*2 5*5 4*3 74

Proximity
Sensor

Parking 5*3 4*5 3*4 5*4 4*1 71

Lot Barrier
Gate
Counter

GPS 5*4 4*3 3*1 5*1 4*1 44

Vehicle
Tracking

Matrix Detail:
- Table 1 displays the best general technology solutions the parking surveillance system
discussed in the design goals of Section 2 and their most relevant evaluation criteria.

Solution Detail:
a. Closed Circuit Television (CCTV):
i. The CCTV monitoring system consists of camcorders that are to be mounted on
high poles or protruding beams for generating a continuous digital feed that can
be used to find open parking spaces.
ii. These cameras would be regionally dispersed as each camera can monitor many
parking spaces at a time.
b. Pressure Plate Sensor:
 i. The Pressure Plate sensor would be built into each parking space and would be
sensitive to object that exceed a weight of 400 pounds.
ii. The distribution of pressure plates would be proportional to the number of parking
spaces in a given lot as only one parking space can be monitored by one pressure
plate.
iii. This system could also be used to count incoming and outcoming cars.
c. Light Sensor:
i. The Light Sensor would be used to tell if there is a car over a parking space based
on the blockage of light.
ii. The distribution of light sensors would be proportional to the number of parking
spaces in a given lot as only one parking space can be monitored by one light
sensor.
iii. This system is subject to varying light conditions based on weather and time of
day.
iv. This system has the potential to miss smaller vehicles such as motorcycles.
d. Ultrasonic Sensor:
i. The Ultrasonic Sensor can be used to detect whether a car is over a parking space
using the rate at which ultrasonic sounds bounce off an object within its proximity
sensor range.
ii. This system has the potential to miss smaller vehicles such as motorcycles.
iii. This system could also be used to count incoming and outcoming cars.
e. Parking Lot Barrier Gate Counter:
i. The parking lot barrier gate can be used to count the number of incoming and
outcoming cars based on the number of times that it is raised to keep a running
total of the number of open parking spaces.
ii. There would only be one of these per parking deck.
iii. Not every parking lot on UNC Charlotte has a parking lot barrier gate with which
to mount a counter.
iv. This system cannot be used to monitor individual parking space availability.
f. GPS Vehicle Tracking
i. The GPS vehicle tracker can be mounted to cars such that they can be used to tell
whether a car is in a parking space using electromagnetic signal bouncing.
ii. This can cause suspicion and risk of unlawful monitoring of others.
Application Framework Selection Matrix: (Table 2, Primary Matrix)
Solutions Android-C iOS-Comp Supports Supports Dynamic Final Score
ompatible atible (3) SSL Java and Input
(5) Certificates Python (5) Support (4)
(5)

Bootstrap 5*2 3*5 5*5 5*3 4*2 73

Sencha 5*3 3*4 5*2 5*2 4*1 51

Touch

Cocoa + 5*2 3*1 5*3 5*4 4*4 64

CocoaTouc
h

jQuery 5*5 3*3 5*4 5*5 4*5 99

Mobile +
Backbone.j
s

AngularJS 5*4 3*2 5*2 5*5 4*4 77

+ Ionic

React 5*5 3*1 5*5 5*4 4*5 93

Native

Matrix Detail:
- Table 2 displays the most commonly supported online web application frameworks,
which we evaluated for their functionality of providing real time updates on parking
space availability.

Solution Detail:
a. Bootstrap:
i. Twitter's mobile-first framework, with a combination of HTML, CSS, JavaScript.
ii. Bootstrap has very little direct support for most Android products.
b. Sencha Touch, Cocoa + CocoaTouch, jQuery Mobile + Backbone.js, AngularJS + Ionic,
React Native:
i. These are other online web application frameworks which have varying degrees
of support for electronic analog input and digital realization of analog data, which
is necessary for determining parking space availability based on our electronic
sensor inputs.
User Interface (UI) Flow Selection Matrix: (Table 3, Secondary Matrix)
Solutions Programmabi UI Appeal (2) Development Data Final Score
lity (5) Time (3) Visualization
Appeal (4)

Single List 5*5 2*1 3*5 4*2 50

Screen UI

Multiple 5*4 2*4 3*4 4*4 56

Screen UI

Fluid Map 5*1 2*5 3*1 4*5 38

Screen UI

Static Map 5*3 2*4 3*3 4*4 48

Screen UI

Infographic 5*4 2*4 3*5 4*5 63

Screen UI

Matrix Detail:
- Table 3 displays the different types of user interface flow layouts that we have the ability
to program. We used this table to evaluate what components we want to use when
developing our application interface.

Independent Screen Count Matrix: (Table 4, Secondary Matrix)

Solutions Graphic Reduction of Data Search Final Score
Busyness and Epileptic Conceptualiz Effectiveness
Appeal (3) Tendency (5) ation (4) (4)

1 Screen 3*5 5*5 4*1 4*3 56

2 Screens 3*4 5*4 4*3 4*4 60

3 Screens 3*2 5*2 4*4 4*2 40

4 Screens 3*1 5*1 4*5 4*2 36

Matrix Detail:
- Table 4 evaluates the compromise between graphic interface appeal, ability to accurately
display data, and ability to easily find parking space information without unnecessary
sight strain in terms of our applications number of independent screen layouts.
Application Usage Data Selection Matrix: (Table 5, Secondary Matrix)
Solutions Conformance Conformance Anonymity Retrieval Final Score
to Google to UNCC (3) Data
Play Store1 Privacy2 Usability (4)
Terms. (5) Terms. (5)

Retrieval of 5*4 5*3 3*1 4*1 42

Names (First,
Last)

Retrieval of 5*5 5*1 3*1 4*3 45

student ID
data

Retrieval of 5*3 5*2 3*1 4*2 36

basic contact
information

Retrieval of 5*5 5*4 3*4 4*4 73

time-frequenc
y usage data

Matrix Detail:
- Table 5 shows the different types of proposed data retrieval which can be executed
through our app under the assumption that each given user has agreed to the Google Play
Store terms and UNCC Privacy terms.

Android Operating System (OS) Version Support Decision Matrix: (Table 6, Secondary Matrix)
Solutions OS Version OS Version OS Version Cloud-Based Final Score
Device Usability (2) Peripheral Interoperabili
Support (5) Support (4) ty (3)

Oreo 5*4 2*5 4*4 3*5 61

Nougat 5*5 2*4 4*3 3*5 60

Marshmallow 5*5 2*5 4*5 3*5 70

Lollipop 5*3 2*5 4*5 3*4 57

KitKat 5*4 2*3 4*4 3*3 51

Jelly Bean 5*2 2*4 4*5 3*3 47

 Ice Cream 5*1 2*2 4*2 3*1 20
Sandwich

Ginerbread 5*2 2*1 4*3 3*1 27

Matrix Detail:
- Table 6 displays all of the major Android OS versions released over the past 7 years. The
table is intended to compare the scoring of each of the Android OS versions to help us
determine which versions we will voluntarily support for the operation of our application,
Niner Parking.

Solution Detail:

All Major Android OS Version Releases Since 20113: (Figure 1)

Versio Code Release API DVM/AR Distribution First
n name date level T devices
to run
version
8.1 Oreo October 27 ART Pixel,
25, 2017 Pixel XL,
Nexus 6P
8.0 August 26 ART 0.2% N/A
21, 2017
7.1 Nougat October 25 ART 2.0% Pixel,
4, 2016 Pixel XL
7.0 August 24 ART 15.8% Nexus 5X,
22, 2016 Nexus 6P
6.0 Marshmallo October 23 ART 32.0%
w 5, 2015
5.1 Lollipop March 9, 22 ART 21.0% Android
2015 One
5.0 Novembe 21 ART 2.1.0 6.7% Nexus 6,
r 3, 2014 Nexus 9
4.4 KitKat October 19 DVM (and 14.5% Nexus 5
31, 2013 ART 1.6.0)
 4.3 Jelly Bean July 24, 18 DVM 1.0% Nexus 7
2013 2013
4.2 Novembe 17 DVM 3.3% Nexus 4,
r 13, 2012 Nexus 10

4.1 July 9, 16 DVM 2.3% Nexus 7

2012
4.0 Ice Cream October 15 DVM 0.6% Galaxy
Sandwich 19, 2011 Nexus
2.3 Gingerbread February 10 DVM 1.4.0 0.6% Nexus S
9, 2011

Single-Board Computer Decision Matrix: (Table 7, Secondary Matrix)

Solutions Peripheral Android OS iOS Support Cost of Final Score
Support (5) Support (5) (3) Implementati
on (4)

Raspberry Pi 5*5 5*5 3*4 4*3 74

3

ASUS Tinker 5*3 5*4 3*3 4*2 52

board T7

VEX 5*4 5*3 3*1 4*5 58

Cortex-
based
Microcontroll
er

SOPINE A64 5*4 5*3 3*1 4*3 50

Arduino Uno 5*5 5*2 3*2 4*2 49

Matrix Detail:
- Table 7 displays our best candidate single-board computers which we intend to use for
securely interfacing and uploading parking surveillance data to our UNC Charlotte server
mount located on the main floor of Atkins Library by the direction of Douglas Lape, one
of our key project mentors who is the UNC Charlotte Parking and Transportation
Services Director.
Solution Detail:
a. Raspberry Pi 3
i. Sample List Price: $36.99
b. ASUS Tinker board T7
i. Sample List Price: $68.55
c. VEX Cortex-based Microcontroller
i. Sample List Price: $249.99
ii. Special Exception Note: Our school, the Charlotte Engineering Early College,
already possess a number of these devices and their respective sensor
technologies which our group can utilize for the development of the parking
surveillance system as part of our Niner Parking application.
d. SOPINE A64
i. Sample List Price: $34.99
e. Arduino Uno
i. Sample List Price: $99.95

V. Multiple Design Solutions with Concept Sketches, and Annotated Drawings

Data Flow Infrastructure: (Figure 1)

Mobile Application Storyboard: (Figure 2)
Selected UI Flow Types: (Figure 3)
jQuery Mobile + Backbone.js Framework Construction: (Figure 4)

VI. Final Design

In addition to the final design specifications which were established in Section II of

Element D, we employed the use of decision matrices in Section IV for the purpose of
determining the remaining technical framework specifications for the two key technical
components of our project: The parking surveillance system and the application-data relay
system that operates with respect to the parking surveillance system.

Defense of Final Design Choice:

In our first matrix, consisting of Table 1, we decided to use the Closed Circuit Television
(CCTV) and Pressure Plate Sensor technologies for parking surveillance monitoring because
these technologies best hold under a variety of weather conditions, they have multiple flexible
applications in parking lot and deck monitoring, and they have the potential to be used together
to independently gather information on parking space availability and evaluate uncertainty in
parking space availability count. We plan on independently prototyping both the CCTV and
Pressure Plate monitoring technologies to evaluate their performance and most appropriate use.
Our second matrix, consisting of Table 2, focused on the selection of a web application
framework that would be best-suited to securely transfer data through a Cloud-operative server.
Our final web application framework choice is jQuery Mobile + Backbone.js. We chose this
application framework since it had the widest interoperability range of all the web application
frameworks that we evaluated. Our demands of interoperability included software support for
analog to digital input feed processing, wide data input support for peripherals such as Pressure
Plates, and a variety of Operating System (OS) support between the Android OS and iOS.
 As a group, we evaluated that our best solutions for our third matrix, Table 3, were to
have the Multiple Screen User Interface (UI) and Infographic Screen UI Flow (See Figure 3 for
information on UI Flow Types) for our front-end application interface. We came to this
conclusion because the combination of multiple screen and infographic screenflow best achieves
the communication of extensive graphical data regarding parking space availability while
satisfying our design criteria of creating an application that is visually appealing and pleasing to
use. Our fourth matrix, consisting of Table 4, also deals with our proposed use of these UI Flows
in which we chose to have our application interface be composed of two independently operable
screens. We chose to not make our number of independently operable screens greater or fewer
because we did not want our application of become too visually busy but we still wanted to
reasonably present graphical access points in our application for all of the UNC Charlotte
parking lot and deck infographics. Our UI flow will rely on the multiple screen UI for changing
the presentation of parking data based on the users preference and serve as a selection menu for
accessing a series of Infographic UIs that graphically show which parking spaces are available.
As a result, these two UI Flows best complement each other of all the possible graphical UI flow
orientations posed in Table 3.
We used our fifth decision matrix, consisting of Table 5, to evaluate what information we
will retrieve from the users of our application. We decided that we would only retrieve data
about the frequency of our application users app usage and the times during the day in which
they most heavily utilize the application for the purpose of improving our applications
operational efficiency. Our decision centered around retrieving such data anonymously and we
refrained from retrieving more user data because it would not be possible to do so without
violating the Google Play Store1 policy and the UNC Charlotte Privacy2 policy.
Our sixth matrix, consisting of Table 6, shows all of the possibly compatible Android OS
versions for which we considered developing our application to be functional (See Figure 1 for
listing of all Major Android OS Releases). We decided to limit our application support to Jelly
Bean through Oreo Android OS versions because the remainder of the given support versions
would not have been able to support the full functionality of our application in that they would
not support peripheral data retrieval through the jQuery Mobile + Backbone.js web app
framework.
Lastly, our seventh matrix, consisting of Table 7, focused on our groups decision of
which single-board computer to use in prototyping our electrical system for facilitating our
cloud-based peripheral data feed. We chose to use a VEX Cortex Microcontroller for developing
a prototype of our parking surveillance system because it was the most cost-effective and
functional option since it simplified our input periphery construction by using other VEX input
sensors. The VEX Controller most of all, however, is available at no monetary cost through our
school, the Charlotte Engineering Early College. As the the sensors can be provided through our
school as well, we will be able to most cost-effectively utilize the VEX Cortex Microcontroller
while maintaining our implementation budget restriction of $200.
VII. Conclusion

Over the course of our concept sketching, annotation development, and our decision
matrix evaluations, we have completed the process of solidifying the technical design
specifications for our Niner Parking system. Our concept maps and storyboards will serve as a
guide by which our key technical advisor, Mr. Ramchandra Pendyala, will be able to provide us
feedback and helpful software development direction as we move forward in developing the two
major technical components of our project: The parking surveillance system and the
application-data relay system that operates with respect to the parking surveillance system.
Citations:
1. Google. (n.d.). Personal and Sensitive Information | Privacy, Security, and Deception -
Developer Policy Center. Retrieved October 21, 2017, from
https://play.google.com/about/privacy-security-deception/personal-sensitive/
2. UNCC. (n.d.). COPYRIGHT, TRADEMARK, & PATENT LAW RESOURCES. Retrieved
October 23, 2017, from
https://legal.uncc.edu/legal-topics/copyright-law-links-and-resources/copyright-law-educ
ational-setting
3. History. (n.d.). Retrieved December 03, 2017, from
https://www.android.com/history/#/donut