Nexus Discovery

From wiki.gpii
Jump to: navigation, search

Overview

The Nexus Discovery features automate steps needed to attach and configure devices within the Nexus. And they enable the Nexus to react as devices are connected and disconnected from it.

A working configuration of Nexus-attached devices requires the following to be set up:

  1. Peers constructed within the Nexus for each attached device
  2. WebSocket connections between the peers and devices
  3. Connections between peers within the Nexus

The discovery features aid in each of these steps:

  • An Infusion grade is provided to help in the writing of Nexus device connection code:
    • construction and destruction of Nexus peers
    • establishment of WebSocket connections
  • Nexus Co-Occurrence Engine
    • configured with "recipes" describing sets of Nexus component scenarios together with instructions for how to react to those scenarios
    • for example if a sensor peer and a reporting peer are both present in the Nexus, create a third component relaying model values from the sensor to the reporter

Co-Occurrence Engine

The Nexus Co-Occurrence Engine monitors the components present in the Nexus and can create components, connect them together and destroy components based on the presence, or absence, of component groupings described in Co-Occurrence Engine "recipes". Each recipe contains:

  • A "reactants" section, describing components to match against
  • A "product" section, describing a component to be created when all of the reactants are present in the Nexus

Reacting to connection and disconnection of devices

Within the Nexus, connection and disconnection of devices are expressed as the construction and destruction of peers. When a device is connected, a peer is constructed. And when a device is disconnected, the peer is destroyed.

The Co-Occurrence Engine watches for components being constructed and destroying within the Nexus. When a new component is created, the Co-Occurrence Engine checks its recipes for reactant matches, creating any products as appropriate. When a Nexus component is destroyed, all recipe products that use the destroyed component as a reactant are also destroyed.

Recipe Reactants

The reactants section describes each component that is required by the recipe. Each reactant has:

  • A name
  • A match description, with rules that each component within the Nexus are checked against

In the current implementation, a single match type is provided that tests against component grade name. In the future more match types will be provided.

An example reactant entry:

phSensor: {
    match: {
        type: "gradeMatcher",
        gradeName: "gpii.nexus.atlasScientificDriver.phSensor"
    }
}

Recipe Products

The product section specifies:

  • The path at which the product will be created
  • The grade options for the product

An example product section:

product: {
    path: "sendPhSensor",
    options: {
        type: "gpii.nexus.scienceLab.sendPhSensor"
    }
}

Referencing Reactants within the Product grade

When the Co-Occurrence Engine creates a recipe product component, it configures a section in the product called "componentPaths" with entries pairing each reactant with its component path. The product may then use these component paths, for example via expander calls to fluid.componentForPath, to reference the reactant components.

Sample Recipe and Product grade

Recipe:

{
    reactants: {
        phSensor: {
            match: {
                type: "gradeMatcher",
                gradeName: "gpii.nexus.atlasScientificDriver.phSensor"
            }
        },
        collector: {
            match: {
                type: "gradeMatcher",
                gradeName: "gpii.nexus.scienceLab.collector"
            }
        }
    },
    product: {
        path: "sendPhSensor",
        options: {
            type: "gpii.nexus.scienceLab.sendPhSensor"
        }
    }
}

Grade defaults for the ""gpii.nexus.scienceLab.sendPhSensor" product:

{
    gradeNames: [ "gpii.nexus.recipeProduct" ],
    componentPaths: {
        phSensor: null,
        collector: null
    },
    components: {
        phSensor: "@expand:fluid.componentForPath({recipeProduct}.options.componentPaths.phSensor)",
        collector: "@expand:fluid.componentForPath({recipeProduct}.options.componentPaths.collector)"
    },
    modelRelay: {
        source: "{phSensor}.model.sensorData",
        target: "{collector}.model.sensors.phSensor",
        forward: {
            excludeSource: "init"
        },
        singleTransform: {
            type: "fluid.identity"
        }
    },
    listeners: {
        "onDestroy.removePhSensor": {
            listener: "{collector}.applier.change",
            args: [ "sensors.phSensor", null, "DELETE" ]
        }
    }
}

Example application: an inclusive science lab

We would like to use the Nexus in a science lab environment to make scientific sensor data available in a machine processable form so that it can be presented in personalized ways, with each lab participant interacting with the data in a manner that best suits them. For some this might be a visual numeric display; while for others text-to-speech, a visual graph, or sonification would be the best.

We would like to support a variety of sensor types and to be able to adapt as sensors are connected and disconnected dynamically.

To make this work we will need:

  • A running Nexus
  • Sensor drivers that connect sensors of various types to the Nexus
  • Data presentations
  • A Nexus configuration of components and Co-Occurrence Engine recipes

Sensor drivers

The sensor drivers will watch for the connection of sensors, for example to a USB port, and react by:

  • Making a connection to the sensor (such as over USB)
  • Connecting to the Nexus and constructing a peer for the sensor
  • Establishing a WebSocket connection with the Nexus peer
  • Streaming data from the sensor to the Nexus peer

Nexus configuration

We will configure the Nexus with:

  • A component called the "scienceLabCollector", used to gather the sensor data and make it available for interaction and presentation
  • A collection of Co-Occurrence Engine recipes, one for each sensor type, that connect sensors to the collector component

For example, a pH sensor recipe would contain:

  • A reactants sections matching a pH sensor peer component and a collector component
  • A product section specifying a product that relays the value of the pH sensor to the collector

Connecting a USB pH sensor

If we connect a USB sensor, such as a pH sensor, to a computer running a device driver as described above. The data will be relayed to the collector component within the Nexus in the following steps:

  • The driver will notice the new device and make a connection to it over USB
  • It will query it for information such as its type (pH in this case)
  • The driver will connect to the Nexus and construct a peer for the sensor
    • Establish a WebSocket connection with the Nexus peer
    • Send pH readings to the Nexus peer
  • The Co-Occurrence Engine will receive notification of the new sensor peer
    • It will consult its collection of recipes and see that there is one covering the situation of a pH sensor and and collection component
    • The appropriate product component will be created to relay the sensor data to the collector

Disconnecting the sensor

When the sensor is disconnected from the USB port, the driver will react by destroying the Nexus peer that it created. And in response, the Co-Occurrence Engine will destroy the product created above, removing the connection between the sensor and collector.