Clever Framework Name That Doesn’t Violate Copyright Laws March 27, 2015

Meeting Agenda Framework Overview Prototype 1 Design Goals Prototype 1 Demo Prototype 2 Design Goals Timeline Moving Forward Questions & Answers Speaker: Lauren

Framework Overview Do we need this or should we go right into prototype 1? Would it make more sense to show this first? Should be discussion formatted – maybe present our current design, start email dialog about changing the design

There’s a hurricane We have sensors monitoring conditions during the storm so we can get an idea of what is hit the hardest People need water, food, and medicine The city has shelters that people are going to for relief How does the city use its food banks, hospitals, weather information, and relief trucks to distribute resources to those shelters?

We connect these resources so that truck drivers know where to send food, food banks know when they will receive more inventory, and city leadership knows the status of these systems and can route according to weather and road conditions Finally the city is back on its feet and city managers want to look back at how decisions were made to modify emergency response protocols for future disasters. First we solved the immediate problem then learned from those decisions to help us in the future We will go into more detail about this diagram when we talk about prototypes

Shaping the Network Graph implementation should use the same concepts as graph design Business logic should be decoupled from connection logic When an edge goes across machines, this should be an implementation detail of the edge This computational graph abstraction applies to any level of the system The graph topology should be static wherever possible The graph topology needs to dynamically support new devices at runtime Bottom two points conflict – be sure to clarify what you mean here.

Is the temperature too high? Processors Output Processor Input Sends Data Is the temperature too high? Receives Data Input Output Note: Rough Diagram Sketch Will likely have some more inputs and outputs coming in (imagine hospital and warehouse scaling diagram) Mention: "These are useful when, say, encapsulating a third-party sensor: when the component starts, use the proprietary sensor API to listen for events; when an event occurs, emit it on an output channel, perhaps after reformatting it in some way to be more useful to other components."

Static Subgraphs I have an idea of what to put here, but slightly unclear.

Pools

Burglar Alarm Pool Front Door Alarm Photo Proximity Data Back Door Alarm Timestamp

Burglar Alarm Pool Front Door Alarm Photo Lobby Alarm Proximity Data Back Door Alarm Timestamp

Speaker: Lauren or Weston

Feature Priority Dynamic Network Topology Framework Scalability Large Scale Data Aggregation Historical Data Storage Robust Connections System Diagnostics UX/UI Should we include a definition of the feature being “complete?” This connects back to having a deliverable specs & reqs Message passing and adapters – P0 features that have been completed (work into list permanently)

Prototype 1 Design Goals and Demo

Essentially a reminder graphic for the prototype Essentially a reminder graphic for the prototype. Should give basic story (hospitals have supplies, request new supplies from warehouse, helicopter finds people and sends info to hospitals), then go to goals slide (next)

Goals Framework Scalability Interaction with Cloud Services to store and produce data Large Scale Data Aggregation Infrastructure Heterogeneous data, multiple inputs and outputs Dynamic Network Topology Introduce new components without reconfiguring The Cloud Service is Azure – store data in a cloud SQL server and produce data by spinning up component instances (or by random generation) Multiple inputs and outputs allowed by our Framework’s BLANK component Dynamic Network Topology – system robustness (pulling new components in if other fails, reconfiguring without taking system down, etc.) Question: Did we achieve goals beyond these listed?

Prototype 1 Demo

INSERT DEMO GRAPHIC Walk through the basic demo scenario (before showing it) What is going to happen, and which pieces are going to highlight the accomplishment of one of those goals? Is there any Azure deployment? If so what pieces? – Database and Central Manager in the Cloud

INSERT SYSTEM BLOCK DIAGRAM Connect what was demoed to the piece of the Framework that was being used. I.E. “When Hospital A was added to the network after initial configuration, X piece of the Framework allowed it to bypass reconfiguration by going through X process instead.” Remember – purpose is connecting demo use case diagram to system use case diagram/architecture

Prototype 2 Design Goals

Goals Complete Large Scale Data Aggregation Robust Connections Synthesize different types of inputs into one or more different types of outputs Increase the amount of data flow Robust Connections Demonstrate transmission failure recovery and unintentional disconnection recovery Network components directly related can tell when a device disconnects System Diagnostics Expand status logging of components, demonstrate logging capabilities of Framework UX/UI Ability to view actions while running the application Historical Data Storage is also on here, but I think that deserves a mention as an in progress item and doesn’t need a bullet point. System Diagnostics – Logger already created, we just need to fine tune what is being logged and find a way to display it in the application (to show it works)

We will introduce a new component (because we want to introduce more types of data -- hetereogeneous) a traffic reporter. This will relay traffic/road information to the central manager who uses this new information to estimate the time it will take for a warehouse to deliver resources. This will help address the Large Scale Data Aggregation by introducing new types of data that affect the central manager's decision of which warehouse toship the resources from. The central manager can begin to predict resource usage of each hospital, using historical usage data. The central manager will have a user interface for resource management personnel to take manual control over the manager's decisions. (Addressing the UX/UI feature)

Updated Timeline Yellow: Will demonstrate progress Green: Will be complete by 4/10