Presentation is loading. Please wait.

Presentation is loading. Please wait.

MARCH 27, 2015. Meeting Agenda  Prototype 1 Design Goals  Prototype 1 Demo  Framework Overview  Prototype 2 Design Goals  Timeline Moving Forward.

Similar presentations


Presentation on theme: "MARCH 27, 2015. Meeting Agenda  Prototype 1 Design Goals  Prototype 1 Demo  Framework Overview  Prototype 2 Design Goals  Timeline Moving Forward."— Presentation transcript:

1 MARCH 27, 2015

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

3 Prototype 1 DESIGN GOALS

4

5 Goals  Dynamic Network Topology  Introduce new components without reconfiguring  Framework Scalability  Interaction with Cloud Services to store and produce data  Establish Infrastructure to Aggregate Data  Multiple inputs and outputs, heterogeneous data  Historical Data Storage  Persistent data storage in database

6 Prototype 1 DEMO

7 Mobile deviceDisconnected Subgraph

8 5 10

9 5 -10

10 0 10 -5

11 5 0 5 10 -5

12 5 5 10 -5 5

13 5 0 10 5 0

14 -20 0 10 5

15 -20 0 10 5

16 -10 0 5 0

17 -5 0 0 0

18 0 0 0 10

19 0 0 0 5 0

20 Framework Overview

21

22

23 Shaping the Network  Graph implementation should use the same concepts as graph design  Business logic should be decoupled from connection logic  This computational graph abstraction applies to any level of the system  New devices must be able to connect to the network at runtime

24 Quick Prototype 0 example: show the components in the Photo Collector device, the edge configuration for the application, and the resulting graph that the framework produces Isn’t this the same as the previous photo? Don’t get the difference…

25 Components We support three types of components:  Processors: an atomic unit of C# code  Subgraphs: a fully encapsulated graph, embedded as a node in a larger graph  Pools: a collection of same-type components, whose members can change at runtime Behavior Output channelsInput channels

26 Processors A processor is a C# class:  Input channel  provides a callback function to the framework to receive incoming messages  Output channel  requests a callback function from the framework to send output messages  Start and stop methods  manages any services it encapsulates Consider the processor that encapsulates the connection with the Kinect:  On start, the processor uses the Kinect SDK to start a connection.  When it receives a photo request, the processor uses the Kinect’s Camera API to take a photo, and outputs the resulting photo.  On stop, the processor uses the Kinect SDK to stop the connection.

27 Subgraphs So I’m still not entirely sure how to demonstrate this, but one option might be: ◦Show the photo collector device in its entirety ◦Show that the Kinect-Wunderbar-BusinessLogic section can be encapsulated as a subgraph that acts as a camera ◦Show the photo collector device with just this opaque camera component and its connection with the monitor

28

29

30

31

32 Use the CM as a pool example here plz

33

34 What’s in an Application?  The Component Classes  Processor Classes  Subgraph Classes  Pool Classes  The Application Graph  Notes: instances of your components  Edges: Connections between the nodes

35 Prototype 2 DESIGN GOALS

36 Goals  Complete Data Aggregation  Synthesize different types of inputs into one or more different types of outputs  Increase the amount of data flow  Robust Connections  Demonstrate transmission failure and unintentional disconnection recovery  Network components directly related can detect device disconnects  System Diagnostics  Expand status logging of components, graphical network topology tool, and diagnostics tool

37

38

39


Download ppt "MARCH 27, 2015. Meeting Agenda  Prototype 1 Design Goals  Prototype 1 Demo  Framework Overview  Prototype 2 Design Goals  Timeline Moving Forward."

Similar presentations


Ads by Google