Clockwyse Project Design Review Tyler Krupicka, Ketan Reddy, and - - PowerPoint PPT Presentation

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

Marketing Requirements

Number 11 Will Amaze You!

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 hardware from Clockwyse. 3. The system can run on non-cutting-edge hardware. 4. The system should be easy to manage. 5. The system should have multiple redundancies. 6. The system should display alerts in a 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:

Management website will be able to put devices into alert state.

Justification:

Users should still be able to send alerts if their alerting system goes

• down. This can also be used for

testing device operation.

Solution:

We will have an active Firestore connection on each device, which will receive alerts from the management interface. Also considered was using the Firebase Cloud Messaging service to send push notifications to each device.

Engineering Requirement B

Description:

Devices will report in depth telemetry to website.

Justification:

A feature offered by other comparable services, this will make it easier to maintain the many devices in use by the system.

Solution:

Android and Chrome OS devices will be able to use native APIs to report Battery, Location and Connection

• 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:

There will be equivalent clients available on web, Android, and Chrome OS.

Justification:

By having a variety of clients available, we can allow the users of the service to use any device they already have (instead of going through us to obtain a device) to cut down on cost.

Solution:

Android will have a native client. The web client will be written as a single page Vue.js application which will be packaged as a Chrome OS app for Chrome OS based systems.

Engineering Requirement D

Description:

On supported devices, alerts will trigger an audio tone upon receiving an alert. The tone will continue for 30 second intervals until the alert has ended.

Justification:

In addition to being a common feature of alerting systems, this will make notifications more apparent, especially if someone enters an area after the alert initially triggers.

Solution:

Android, Chrome OS and Web devices will be able to use native APIs to play sounds. Unlike Chrome OS though, Web lacks the ability to modify system settings to set sound 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:

Alerts will cause the device to flash between vibrant colors until the alert is over.

Justification:

This will make the alerts more easy to identify overall.

Solution:

Alternating the background color between red and white; colors used in similar applications.

Engineering Requirement F

Description:

Devices will show a timestamp of when the alert was issued.

Justification:

When an alert is present, this will make it clear when the alert was started to help determine appropriate course of action.

Solution:

Parsing the “Issued At” field in the alert messages. Considered using device timestamp

• f when alert was received however

might cause issues if the alert is received late as well as localization issues.

Engineering Requirement G

Description:

The management website will have predefined views for devices in specific states (e.g., in alert, not responding)

Justification:

Other alerting device management websites do not have this feature. This will make it easier to triage devices when looking at the management website.

Solution:

Each predefined view will be tied to a filter which will pivot the pre-loaded complete dataset. This information will be displayed using the same table component used in the rest of the dashboard.

Engineering Requirement H

Description:

The devices will be compatible with all major alerting providers.

Justification:

As there are many alerting services used by different organizations, there must be a high level of compatibility in order for the product to be successful.

Solution:

By implementing parsing for the generic RSS format used by all known alerting providers, we will be able to parse a message from any 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:

Devices, if possible, will run in a limited interface mode if enabled.

Justification:

In order to prevent disabling or interfering with the alerting devices during use, if Android devices are used there should be only a limited user interface available. This is already done on Chrome OS digital signage devices.

Solution:

Android devices can be managed through a device policy which allows the administrator to enable kiosk mode on the device. Additionally, the Android Management API provides the capability to easily control the 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:

Supported devices will mountable using the VESA standardized mounts.

Justification:

VESA is the standard for most digital signage devices on the market now.

Solution:

Use cases with VESA mounts for devices without native VESA

• mounts. Most Chrome OS devices

have integrated VESA mounts.

Engineering Requirement K

Description:

The theme of the application will be able to be set by the user.

Justification:

Customizing the look and feel is something that has been requested during demonstrations and no other solutions offer this feature.

Solution:

Allow primary and secondary theme colors to be selected on the management interface which will select colors for both the management interface as well as the menu, clock, and alert screens on the application.

Engineering Requirement L

Description:

Clockwyse client devices will respond to an alert state with an average time of 15 seconds.

Justification:

An emergency alert system must be able to broadcast alerts very quickly to ensure optimal response by students and faculty.

Solution:

Using a mix of HTTP and gRPC (Firestore) requests for native Clockwyse alerts, the response time 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,

• rganizations, campuses, and

devices. Manage users, edit organization, create/edit campuses, create/edit devices. 4 Maintenance Manage deployment of devices and regular maintenance. Create and edit devices. 3 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

Risks

Risk Difficulty Source of Failure Proposed Solution

Bring your own device support. Allowing the customers to use their

• wn devices makes troubleshooting

device specific issues difficult. Old devices might break compatibility and negatively affect the response time

• f the system.

Create a list of supported devices that are guaranteed to meet the needs of the system. Telemetry Limitations It may be difficult to display useful device status information. Different operating systems and versions may cause discrepancies in device status information. Identify useful metrics and cross-reference between devices. Android Management API Integration The API requires a corporation and product review to be an official EMM without restrictions. Incorporation is expensive, and review could add extra burden. Failure to do so could limit functionality. Research bare-minimum incorporation needed to prevent delays later. System Reliability Emergency alerting systems must be reliable across all components. Any failure could put response times in

• jeopardy. Failures are dangerous for

affected students. Design for redundancy in every component, and surface failures quickly.

Testing Plan

• Unit tests for each subsystem.
• Integration tests to ensure appropriate response times and functionality.
• With automated deployment and git hooks, testing can occur automatically

to prevent adding breaking changes to the codebase.

• Upon a complete implementation of the system, the full suite of integration

and acceptance tests will be used to verify that the system fulfills all of the marketing requirements.

Specification Management Interface Integration Tests Device Integration Tests Acceptance Tests

A - Management website will be able to put devices into alert state. 14 Clockwyse Native Alerts B - Devices will report in depth telemetry to website. 15, 16, 17 3 Device Telemetry C - There will be equivalent clients available on web, Android, and Chrome OS. Acceptance tests pass on each platform. D - Alerts will trigger an audio tone on supported devices upon receiving an alert and for 30 seconds intervals after until the alert has passed. 9 E - Alerts will cause the device to flash between vibrant colors until the alert is over. 8 F - Devices will show a timestamp of when the alert was issued. 13 Clockwyse Native Alerts G - The management website will have predefined views for devices in specific states (e.g., in alert, not responding) . 15, 16, 17 H - The devices will be compatible with all major alerting providers. Provider Compatibility I - Devices, if possible, will run in a limited interface mode if enabled Limited Device Interactivity J - Supported devices will mountable using the VESA standarized mounts. n/a n/a n/a K - The theme of the application will be able to be set by the user. 4

Specifications Testing Table

Materials

Part Description Cost ($) Our Cost($) Availability Google Firebase / Cloud Platform Variable* 0** On Demand From Google Refurbished Acer 21.5” Chromebase 205 On demand from Acer, approximately 10 days for shipping. Chrome Web Store Developer Account 5 On Demand From Google Google Play Developer Account 25 On Demand From Google Generic Android Tablet ~150 Consumer OTS AOPEN Chromebase Tablet ~300/350 TBD Direct from AOPEN or Google Play Store, approximately 10 days for shipping

Current Progress

Gantt Chart

Q’s and Maybe A’s