Embedded Files
2.1: Project Plan
What are the task breakdown and project plan?
2.1: Project Plan
What are the task breakdown and project plan?
In order to ensure that a satisfactory prototype can be deployed within the scope of this project period, we need to plan milestones and adapt to any inconveniences that may arise. The milestones and task breakdown are as follows:
Milestone 1:
Collectively brainstorm ideas and concepts on how a prototype can be fabricated. Discuss potential hardware and software requirements as well as resources that can be accessed to develop the knowledge required for putting together the project idea. This includes looking at various potential hardware and software options, understanding and testing software libraries that could be used, reaching out to people that may have insights on our topic, and window-shopping for hardware components.
Milestone 2:
Begin prototype building. After getting a solid idea of how to implement our project, the group should start building a prototype. Split the prototype into components that each group member can work on and discuss who should work on what. Each group member should have something to work on that contributes to the completion of the prototype.
Milestone 3:
Progress check-ins. The group members will check in with each other and discuss any progress or setbacks in their work. Bring up any new ideas or concerns throughout the building stages so that the group can efficiently address them together.
Milestone 4:
Prototype testing and tweaking. After an initial prototype has been fabricated, test and tweak the prototype until it is working as intended. Should there be additional time, work on any additional features and/or parts of the project that are planned to be implemented.
Task Breakdown:
Calvin Zheng -- Backend software library that allows the modules to work together and display as intended
Michael Compagnino -- Compiling required hardware components and building the physical device
Jonathan Kubas -- Compiling required hardware components and building the physical device
Jagnoor Gandhok -- Ensuring modules have a security check for sustained network communications. Assisting in software setup and hardware installation, if possible.
Ninghui Fang -- Setting up the frontend software (user interface) that allows users to interact with the modules
Jordan Fernandes --Backend software library that allows the modules to work together and display as intended
Bailey McNamara -- Setting up the frontend software (user interface) that allows users to interact with the modules
Richard Cahill -- Structuring the network for the modules and helping with the software
2.2: Concepts
What are the design concepts of our project?
2.2: Concepts
What are the design concepts of our project?
Design 1:
Our first design concept describes a transparent display that can be manufactured in various sizes and includes an embedded LCD panel. The LCD panel will not only be able to modulate light passing through the display, but it will also be able to show various widgets like notifications, weather information, smart-device controls, etc.
Design 2:
Our second design concept is to utilize LCD transparent panels to work as an alert system for emergency alerts and information. Because these panels are transparent they can be installed in many locations because they are not intrusive and once there's an emergency they will display important information and the actions required for the public to follow.
Design 3:
Our third design concept is to use a transparent display for businesses to display advertisements, menus, and animations. Our product will allow customers to look into businesses' windows while being able to display products to promote the business.
2.3: Concept Selection
What are the design concept selections?
2.3: Concept Selection
What are the design concept selections?
Chosen Design: Design 2 + 3
In our design concept discussions, we decided that our most viable product could be a combination of concepts 2 and 3. (And, in fact, each of these concepts takes some basis from concept 1!)
The main technology for our project is as follows. We will be creating small LCD displays that can coordinate to display information. These modules would not themselves be windows. The original window would still exist, but our modules could be a clear display placed behind it. (And in fact, they could be placed anywhere else as their users see fit!) We plan to do this in pursuit of some main design tenets: namely, our product should be cheap, modular, versatile, and easy to install. These tenets are chosen so that our product performs as well on the market as possible, and can be easily adopted and adapted to different window sizes without having to rely on a custom sizing system.
Now, moving to our project itself: our main application (i.e., target market) will be a combination of concepts 2 and 3. In other words, our design concept is a combination of a transparent storefront and an emergency alert system. This can be best illustrated through some examples.
For example, if high tides were in effect and the town needs to issue a flood warning, they could dispense alerts to be sent en-masse to all storefronts. This would be a very visible display that could quickly alert people of the situation and what they need to do (such as find shelter). Another possible scenario would be an active shooter situation. (This could be especially applicable to indoor shopping centers, like malls.) In this case, the mall storefronts could light up with an alert for the shooter and directions for the nearest exit.
Each of these applications would involve having alerts "pushed" from a central authority to the displays. This is the main humanitarian motive for our project, but we believe that it alone would not be enough for a viable product. We need a profit motive so that stores would be more apt to adopt these clear displays and participate in the alert system. Therefore, when the displays are not being used for alerts, the stores would have the freedom to use the displays for their own purposes. For instance, they could advertise content on it, or use it to give their store more character and boost sales.
By putting both concepts together, we believe that our product could not only perform well on the market, but even save lives in the process.
Note: See the figures below for preliminary schematics.
Figure 1: Initial Design Schematics Page #1
Figure 2: Initial Design Schematics Page #2
Figure 3: Updated Design Schematics
2.4: Design
What are the system diagram and process flowchart for our project?
2.4: Design
What are the system diagram and process flowchart for our project?
2.5: Analysis
What are the hardware and software specifications of our project?
2.5: Analysis
What are the hardware and software specifications of our project?
2.6: Test Plan
What is our test plan?
2.6: Test Plan
What is our test plan?
Because Clearvoyance is a multi-faceted product with differing disciplines involved, we plan to hold comprehensive tests for each part of our system, starting with our prototype.
Software System
The Clearvoyance system will be controlled by an onboard web app. This application will accept multiple media channels that can be displayed on the prototype's screen. For instance, one channel will be for stores to control the advertisements on their displays, and another would be an "override" channel used for emergency transmissions. From the app, each channel can be controlled by the intended users (by either the stores or agencies) in order to display different media on the screen.
Testing for the control software will be done as follows.
Automatic Testing — As part of program development, we will make use of a robust automatic testing framework in tandem with repository controls. Using this technology for unit tests will ensure that each individual part of our control program is working correctly. (Likewise, we anticipate that our automatic tests could be used as part of system testing, which spans greater spines of features to ensure they're all working together correctly.)
Stress Testing — By virtue of how our system works, we do not anticipate a high-stress situation being a problem. Each channel will have a singular control, and we don't anticipate each Clearvoyance system having a large number of channels on it at once. Regardless, it may be worthwhile to test our system's limits and ensure that it runs smoothly, especially in the case of an emergency situation.
Security Testing — Very critically, we must ensure that our application and our system are secure. This is a testing task that will take place across both hardware and software. On the software side, we will do more research into security testing methods and web application protections. It would also be worth our while to look into network-wise protections on the software's lower level; this could be critical to prevent outside access and injections to our system.
User Acceptance Testing — Lastly, as our product moves closer to release, we will share it with volunteers that want to try it. We anticipate that these meetings will help us understand any usability issues we have and correct them.
Electronic System
In terms of electrical-specific testing, it mostly involves testing the compatibility, functionality, and durability of various electrical components that make up this project. Therefore to ensure the usability of our prototype, we must perform several tests which include, but are not limited to the following:
Life span of the backlight
UV protection of the transparent display
RF emissions
User input sensors, such as the digitizer, trackpad, button array, and rotary encoder
Power consumption of the entire system
Compatibility between the driver board and the LCD display
Electronics components such as capacitors, resistors, diodes, transistors, ICs, etc.
Page updated
Report abuse