Clockwyse Project Design Review Tyler Krupicka, Ketan Reddy, and Jeremiah Zucker
A Quick Refresh on Our Project ● Classroom based digital signage connected to existing alerting infrastructure. With this approach, response time can be reduced and alert coverage can be increased. ● Offering more redundancy than existing systems by hosting platform offsite, decentralized alerting nodes and providing backup alerting infrastructure. ● Clock software will target a wide variety of devices to allow institutions to bring their own hardware thus lowering the cost of entry. ● Developing a web based management interface in conjunction with client software for Android, Chrome OS and Web based systems.
Requirements
1. The system should have a low cost. 2. The system can run on existing on-location hardware if the user does not want to purchase Marketing hardware from Clockwyse. 3. The system can run on non-cutting-edge hardware. Requirements 4. The system should be easy to manage. 5. The system should have multiple redundancies. 6. The system should display alerts in a Number 11 Will Amaze You! noticeable and easily digestible format. 7. The system will support multiple alert providers. 8. The system will be easy to install. 9. The system will be customizable by the users. 10. The system will respond to an alert state with an average time of 15 seconds.
Engineering Requirement A Description: Justification: Solution: Management website will be Users should still be able to send We will have an active Firestore able to put devices into alert alerts if their alerting system goes connection on each device, which state. down. This can also be used for will receive alerts from the testing device operation. management interface. Also considered was using the Firebase Cloud Messaging service to send push notifications to each device.
Engineering Requirement B Description: Justification: Solution: Devices will report in depth A feature offered by other Android and Chrome OS devices will telemetry to website. comparable services, this will make be able to use native APIs to report it easier to maintain the many Battery, Location and Connection devices in use by the system. information. Web clients will have to use Chrome as other browsers do not support similar APIs. Every device will write this telemetry to the database every 30 minutes or potentially on demand.
Engineering Requirement C Description: Justification: Solution: There will be equivalent By having a variety of clients Android will have a native client. The clients available on web, available, we can allow the users of web client will be written as a single Android, and Chrome OS. the service to use any device they page Vue.js application which will be already have (instead of going packaged as a Chrome OS app for through us to obtain a device) to cut Chrome OS based systems. down on cost.
Engineering Requirement D Description: Justification: Solution: On supported devices, alerts In addition to being a common Android, Chrome OS and Web will trigger an audio tone upon feature of alerting systems, this will devices will be able to use native receiving an alert. The tone make notifications more apparent, APIs to play sounds. Unlike Chrome will continue for 30 second especially if someone enters an area OS though, Web lacks the ability to intervals until the alert has after the alert initially triggers. modify system settings to set sound ended. levels and thus will have to have the user set the sound level. The actual sounds that will be played will be bundled with each application.
Engineering Requirement E Description: Justification: Solution: Alerts will cause the device to This will make the alerts more easy Alternating the background color flash between vibrant colors to identify overall. between red and white; colors used until the alert is over. in similar applications.
Engineering Requirement F Description: Justification: Solution: Devices will show a When an alert is present, this will Parsing the “Issued At” field in the timestamp of when the alert make it clear when the alert was alert messages. was issued. started to help determine appropriate course of action. Considered using device timestamp of when alert was received however might cause issues if the alert is received late as well as localization issues.
Engineering Requirement G Description: Justification: Solution: The management website will Other alerting device management Each predefined view will be tied to a have predefined views for websites do not have this feature. filter which will pivot the pre-loaded devices in specific states This will make it easier to triage complete dataset. This information (e.g., in alert, not responding) devices when looking at the will be displayed using the same management website. table component used in the rest of the dashboard.
Engineering Requirement H Description: Justification: Solution: The devices will be As there are many alerting services By implementing parsing for the compatible with all major used by different organizations, generic RSS format used by all alerting providers. there must be a high level of known alerting providers, we will be compatibility in order for the product able to parse a message from any to be successful. alerting provider. Another option considered was to use the CAP endpoint required by schools. However lack of usage served as a deterrent.
Engineering Requirement I Description: Justification: Solution: Devices, if possible, will run in In order to prevent disabling or Android devices can be managed a limited interface mode if interfering with the alerting devices through a device policy which allows enabled. during use, if Android devices are the administrator to enable kiosk used there should be only a limited mode on the device. Additionally, the user interface available. This is Android Management API provides already done on Chrome OS digital the capability to easily control the signage devices. device policy of provisioned devices. Integrating the AMA with the Clockwyse web portal would allow for easy device management to limit interactivity on Android devices.
Engineering Requirement J Description: Justification: Solution: Supported devices will VESA is the standard for most digital Use cases with VESA mounts for mountable using the VESA signage devices on the market now. devices without native VESA standardized mounts. mounts. Most Chrome OS devices have integrated VESA mounts.
Engineering Requirement K Description: Justification: Solution: The theme of the application Customizing the look and feel is Allow primary and secondary theme will be able to be set by the something that has been requested colors to be selected on the user. during demonstrations and no other management interface which will solutions offer this feature. select colors for both the management interface as well as the menu, clock, and alert screens on the application.
Engineering Requirement L Description: Justification: Solution: Clockwyse client devices will An emergency alert system must be Using a mix of HTTP and gRPC respond to an alert state with able to broadcast alerts very quickly (Firestore) requests for native an average time of 15 to ensure optimal response by Clockwyse alerts, the response time seconds. students and faculty. should be under half a second. When polling the RSS feeds, the time between requests will be set to meet an average response time of 15 seconds.
System Architecture
System Overview ● How Endpoint Devices Interact with the Clockwyse System. ● Endpoint devices can be either ChromeOS, Web or Android. ● If active connection to Institutions Alerting Endpoint is lost, alerts can be pushed through Firestore. ● If active connection to Firestore is lost, device will keep functioning as configuration is stored on device. Just lose telemetry and Clockwyse Alerts.
Management Interface
User Roles Role Responsibilities Database Needs Level Administrator Full control over users, Manage users, edit organization, 4 organizations, campuses, and create/edit campuses, create/edit devices. devices. Maintenance Manage deployment of devices Create and edit devices. 3 and regular maintenance. Operator Send alerts. Edit devices. 2 Member View the organization. Read access to everything. 1
Android Client
Android Management API ● The web portal will serve as the interface between the user and the AMA. ● To ensure that device policies don’t become confusing or invalid, the web portal will handle most of the AMA requests behind the scenes. ● Additionally, the AMA may be used to skip the authentication and configuration processes on the Android device through unique provisionment codes.
Chrome OS + Web Client ● Static site deployed to Firebase Hosting. ● Custom versioning scheme to manage updates (via page reload). ● Chrome OS app which sets OS settings and creates webview. ● Connection to Firestore for configuration and alerts. ● Need to build or find RSS parser using fetch.
Final Details
Recommend
More recommend