AMTech – The M2MBridge

The AMTech M2MBridge is a node.js service that implements the AMTech IOT Protocol.  The M2MBridge can run in a variety of devices; for our demos we currently have it running on a Raspberry Pi 3 using Ubuntu MATE.

The M2MBridge includes a core and an extensible plugin architecture, plus a growing set of plugins.  The bridge is a common component of most real-life IOT applications connecting edge devices to the sensor and reasoning layers of the AMTech platform, providing intelligence at the edge, and supporting security, access control, auto-configuration and other key properties of real-life deployments.

Here is a sketch of the Bridge Functionality:

Picture5

We used the M2M Bridge to control RFID antennas in the ProgressNEXT Conference App at Las Vegas and in our recent NativeScript MeetUp in our Palo Alto office.  In both setups the bridge used the LLRP plugin to control the RFID readers, which were connected to the antennas via coax cable.

In the case of ProgressNext, the bridge was running on a laptop and was controlling 3 RFID readers, connecting to them via the hotel internet.  In the case of our MeetUp, we used just one RFID reader that was connected directly to the Raspberry Pi 3 via an ethernet wire.

BridgeSetups-1

The MeetUp setup was logistically simpler: we configured the pi3 as a DHCP server and it could talk directly to the RFID box; at Las Vegas we had to work with the IT administrator of the hotel to whitelist the laptop and the RFID readers so they could talk to each other.

BridgeSetups-2In both deployments the bridge connected to an AMTech tenant to receive configuration data and to push observations and receive commands.

The AMTech M2M Bridge functionality includes:

  • Support for many devices andM2M protocols – e.g. SNMP, LLRP (for RFID), iBeacon and eddystone, etc
  • Support for device-to-device and device-to-cloud communication – e.g. LoRa, BLE, etc
  • Centralized management of IOT devices and gateways
  • Configurable Edge Intelligence
  • Configurable Auto-Discovery
  • Access Control and Customization of observations at the edge.

One of the nicest features of the M2M Bridge is the centralized management of IOT devices and gateways: when a M2M Bridge instance starts, it connects to its corresponding AMTech tenant to extract the configuration details from there, which makes it very easy to adjust the configuration of the production of observations (events).  Another very useful feature is the ability to clone a configuration so multiple M2M Bridge instances inherit the properties from a master setup.

Using RFID Tags in a Meetup

Last week we hosted the NativeScript SV MeetUp at our office in downtown Palo Alto.  The meeting focused on using NativeScript in combination with CloudBase but we added RFID tags to spice the event, and I think the result was very successful.

The use of RFID tags was a variation on how we used them for the ProgressNEXT Event in Las Vegas earlier in the year.  We prepared holders for all the attendees, with space for their name at the front and an RFID tag at the back.

IMG_8216

We used the EOS-300 R6 RFID Paper Tag.  This one has 96 bits unique, serialized data that we used as a UID (for the progressNEXT event we used a GRAI encoding, but for this MeetUP I didn’t want to go through the extra step of customizing the tags).

Tageos_EOS_300_R6__84303.1460131319.480.480

We also added a small pokemon to each badge.

IMG_8202

We later used some larger pokemons (from TakaraTomy) as part of the raffle (more on that below).

IMG_8219

The active elements of the setup included some RFID antennas

IMG_8171.jpg

connected to an RFID reader via coax cables…

IMG_8170.jpg

connected to a Raspberry Pi 3 that was running an M2MBridge Gateway from AMTech

IMG_8173.jpg

The M2MBridge supports many edge protocols, including LLRP, which it uses to control the reader.  The bridge generates observations that correspond to the RFID tags read, which are then sent to an AMTech tenant, where we run some simple rules to create objects when a new tag (i.e. a new MeetUp attendee) is detected.

The AMTech tenant was also configured to provide Notifications (JSON objects pushed through a WebSocket).  We connected a Node.js app to it (on Modulus) that we used to randomly select UIDs (from the RFID tags) for the raffle.

The 96-bit UIDs are unique but somewhat unwieldy, so we wrote a shorter unique number at the back of each tag and we mapped the UIDs to these.  We called those numbers at the raffle and everything worked like a charm.  A cuter, but more time-consuming approach, would have been to name each tag after the name of the pokemon character in their holder.  Pikachu, I choose you!

 

 

 

Come for NativeScript, Angular and CouchBase – Stay for a Pokemon

This Thursday (Jul 28, ’16), we are hosting a MeetUp at 6pm at our location in downtown Palo Alto (Google Maps – MeetUp info).  Mehfuz and Nic will show how to create native cross-platform Apps using NativeScript and CouchBase.

CouchBase is an open-source, distributed (shared-nothing architecture) multi-model NoSQL document-oriented database; NativeScript is an open source platform for building cross-platform Native mobile applications using JavaScript and CSS.  NativeScript leverages a high performance bridge between any native platform API and JavaScript which can be used to create Plugins that extend the platform.  Mehfuz and Nic will show how to use the CouchBase plugin in an app where information created by one user in one smartphone can automatically be shared with another user in another smartphone.

Mehfuz will also show how to use his Estimote plugin; combined with the CouchBase plugin, the iBeacon data read by one phone is automatically synchronized to the other.

We are sprinkling a slight IOT overlay on the MeetUp.  We took some of the RFID configuration we used in a Conference App earlier this year and we now have them connected to a Raspberry Pi 3.  UPS-willing, the plan is to add some RFID tags to the badges for the MeetUp and show you how a modern Data Speed Layer (like AMTech.Solutions) can be used to track an asset (you) on a space.

Following the Pokemon Go mania, I’ve ordered some Pokemon figures as prizes for the attendees. Raichu arrived yesterday, others to follow (update – All Pokemons are here; check the Flickr Album).  See you on Thursday.

28419385672_803def6a39_k

Capstone ’16 Project at CSUMB – The BIT Building

I mentored a Capstone project at Cal State University Monterey Bay (CSUMB) this last Winter.   The project involved quantifying the BIT building using a combination of video cameras running Computer Vision software (Placemeter), iBeacons (Estimote) and GPS, all connected using the IOT Platform from AMTech, and a solutions stack from Progress: Modulus, NativeScript and Telerik Platform.

bit-building

My post at Progress Blogs has more details.

AMTech – An Overview

This is an overview of the IOT Platform, expanding on The Elevator Pitch and The 2 minute Overview.  Additional notes are available here.

The Big Picture: Two AMTech Examples

AMTech is usually part of a larger software solution; two recent examples are the BIT Building at CSUMB and the ProgressNEXT Conference App.

Quantify the BIT Building at CSUMB

The goal of the Quantify the BIT building project is to track activity in the most recent  building in the CSUMB campus.  The project uses sensor data from 3 sources: iBeacons and GPS, mediated through  a smartphone app, provide identity/location data, while IP Cameras provide anonymous traffic data thanks to a Computer Vision startup Placemeter.  Below is the arch diagram for the project:

Picture1

The general structure of the system follows the Lambda Architecture: the sensor data is collected into an “Immutable data store” for analytics and reporting and is also fed into a “Speed Layer” for real-time processing.  In the CSUMB case, MongoDB was used for the immutable data store (Hadoop is a common solution), and AMTech for the speed layer.  Real-time content and rules are programmed into the AMTech platform and are then exposed to the Application Layer through CRUD operations on Things and through Notifications.

The functionality of the solution is implemented through these layers.  For example, the Mobile App recognizes the iBeacons and will post relevant events to the AMTech system. The event triggers a number of actions on Things and can generate a notification that is received and interpreted by the Server-side logic.  Together the system tracks occupancy and can present room occupancy data when requested by the end user, or it can push a notification if the room occupancy gets beyond a threshold.

ProgressNEXT Conference App

Another project where we used AMTech was the ProgressNEXT conference app where we used RFID tags to track participants at the venue in Las Vegas.  In this case we used another piece of the platform, the M2MBridge.  This project was the first AMTech-based project and we did not use include an immutable store, though it would have been useful.  The general architecture is as follows:

Picture3

The M2MBridge is an Open Source Node.js application with a Plugin system that can be used to manage and control a variety of sensors and actuators.  The M2MBridge was critical for this application: during the ProgressNEXT conference, the M2MBridge was interacting with 3 RFID readers that were themselves controlling 8 RFID Antennas.  The bridge talked to the readers using LLRP and then pushed the results to the platform using REST and WebSockets.  The bridge is very flexible and performant; it could easily have handled many more antennas.  AMTech supports different ways of managing M2MBridge instances so it is very easy to replicate installations and to manage many sensors.

The complete ProgressNEXT solution includes a mobile app and sever-side content and logic.  As in the case of the CSUMB application, the interaction between AMTech and the Application Layer is through REST and WebSocket calls.

A PAAS and a SAAS

AMTech is a multi-tenant platform that is both a PAAS and a SAAS.  As a PAAS, a creator user defines types for Things and Observations, and deployable Activities that act on them.  The Activities define the Rules that act on things and observations, the Notifications they can generate, and Actors, corresponding to roles and associated permission.

As a SAAS, a follower user can import a set of Activities, and configure them, e.g. by creating specific Things.  Access to the SAAS Services (CRUD Operations on Things and Notifications via WebSockets) are controlled by the Actors associated with each follower user as defined by the SAAS administrator.

Things, Observations and Rules

Things and Observations have properties; some common to all types, others specific to each type.  Common properties include the @type and @id (both URIs and both immutable), a creationTime, the position (in an extended WKT format) and a proximityArea.  Associated with the Things and Observations there is also a user/tenant creator which is used to determine whether the entity is visible for a request, based on the Role (Actor) of the requestor.

For example, 3 of the types defined in the CSUMB application are csumb_Building, csumb_Person and iBeacon, while corresponding Thing instances are csumb:BIT and csumb:LITwombat@gmail.com and alcides_sorto@mumble.com, and csumb:BIT:beacon1 and csumb:LIT:beacon4.   All 3 types have a location – in the case of a csumb_Building a Polygon of GPS coordinates, while the other two are a single coordinate – but while the location of a Building is fixed, and that of a Beacon varies very infrequently, that of a Person changes frequently and may not even be defined.  For example, a person that has been detected through a GPS geolocation will have a specific location, but one detected via an iBeacon will only be known through its proximity to that iBeacon.

BeaconDetected is an example of an Observation.  When a smartphone gets close to an iBeacon, it detects a BLE message that eventually triggers a beaconDetected.  This observation has a property that identifies the iBeacon detected and another that identifies the csumb_Person of the smartphone user

Observations can trigger Rules, and execute Actions.  One of rules in the CSUMB application uses the iBeacon ID in the observation to get the iBeacon Object and from there it extracts its geolocation.  Another rule then uses this location to update the location of the csumb_Person object associated with the Person ID in the Observation.  The updated location can further trigger new rules and actions, including updating an occupancy count on a TrackedSpace enclosing the old (decrement count) and the new (increment count) locations.

Here is a graphical description of one rule: the incoming observation triggers a rule that generates two new observations: FromLocation and ToLocation.

Picture4

A Gateway, a Sensor Network and a Rules System

From another perspective, the AMTech platform has a Gateway, the M2MBridge, and two Cloud-side components, a Sensor Network and a Rules System.  All three interact through Observations sent through Topics (same terminology as with MQTT topics).

Picture5

The M2MBridge is an Open Source Node.js application with a Plugin system that can run in a variety of platforms, including the new Raspberry Pi 3.  The cloud side of the Bridge is a Thing, and so are the Plugins.  These Thing objects can generate Observations and will accept Actions.  For example, at ProgressNEXT, the plugins generated RFID reads.

Picture6

Rules, Observers and Reasoners

Rules in AMTech are called Reasoners.  A Reasoner is defined through an Observer that operates on one or more Topics (think MQTT Topics) supplying events (called Observations) to generate a collection of entities (Thing and / or Observations) on which a sequence of Actions will operate.  Entities are connected through a standards-based Domain Application Protocol.  See Observers and Reasoners for details.

The AMTech DAP

The Entities (Observations and Things) in AMTech are exported using a Domain Application Protocol based on internet standards: REST and WebSockets for transport, JSON for the data, and JSON-LD for the relationships among entities.  See The AMTech DAP for details.

The Implementation – Cassandra, Titan, Kafka and Storm

Underlying the AMTech platform lies several clusters of services.  The things and observations as well as the relationships are kept on an Apache Cassandra cluster, using Titan as the GraphDB.  The Activities run on a Apache Storm cluster, and all these pieces are kept together via Apache Kafka queues.  The result is highly scalable and performant.

Mapping the concepts to the architecture, Entities (Things, Observations, Notifications) are kept on Cassandra, while the Activities are converted into code that is deployed to Storm.  Some Activities are meta-data driven and don’t need a full Deploy, just a Publish.

In addition, the M2MBridge provides a flexible, manageable and configurable gateway to sensors. The gateway is a node.js application and can run on devices like macOS and Raspberry Pi 3.

Additional Services in AMTech

AMtech includes a number of services.  Most notable is support for location and proximity.

Location is provided through OpenStreetMaps, support for WKT, and inclusion of efficient algorithms to operate on locations (e.g. whether a location is contained within another).

Similarly, AMT provides efficient support for operations like extracting all objects that are within a given Proximity area.

AMTech also provides services for Mail, Billing, User management, etc.  More in follow-up posts.

AMTech – Observers and Reasoners

A description of Observers and Reasoners in the AMTech Platform.

Also see The Elevator Pitch, The 2 minute Overview, and Overview.  Additional notes are available here.

Rules, Observers and Reasoners

AMTech is a multi-tenant IOT platform targeting mostly Digital Asset Management applications including a gateway, a sensor network and a reasoning system.  The core action of the reasoning system is triggering and executing a rule.

Rules in AMTech are called Reasoners.  A Reasoner is defined through an Observer that operates on one or more Topics (think MQTT Topics) supplying events (called Observations) to generate a collection of entities (Thing and / or Observations) on which a sequence of Actions will operate.  Entities are connected through a standards-based Domain Application Protocol.

This note expands on some of the details of the rule system.

Assessing a Thing x Observation

Observers examine Things and Observations instances and assess whether they are suitable for consideration for the rule.

Picture1

There are several types of Observers depending on whether they consider a collection of Things, a collection of Things in the context of a given Observation, or an Observation.  In all cases, the Observer validates if the specific instances satisfy some given constraints, like whether a property has a given value, is set or unset, has a range, or how it compares to the value of the other entity (e.g. whether the Observation’s property has the same value as that of the Thing).

Types of Observers

Type 1 – Standard Observer

This observer operates on a collection of Things of a given Type, and on one or more Observation Topics of a given Type.  The observer examines an Observation and looks at the possible things, applies the conditions specified in the properties and generates a, possibly empty, sequence of [Observation x Thing] pair for that Observation.

Picture2

The set of Things to consider is all the Things visible based on the Access Information (User/Tenant), which at Reasoner definition time, is set to be either that of the Observation or the plain “anonymous” of the Service.

Reasoners can act on this sequence in one of 3 different ways: For Each, Once if Present, Once if Absent.  See further below.

Type 2 – Observer w/ TargetThings

This is a variation of Type 1, except that instead of considering any Thing (of the given Type), AMT only considers the Things that are mentioned in the Observation via the TargetThings machinery.  As in Type 1, the result is a, possibly empty, sequence of [Observation x Thing] pairs.

Picture3

Type 3 – Observation Filter

This observer only examines Observations; there are no Things involved.  The result is the same Observation, if it passes the conditions in the Observer, or nothing, if not.

Picture4

Type 4 – Thing Filter

This Observer is only used in the UI to help navigate through the set of Things available.  Typical use is to filter by tenant, by type, by location, or by user.  Its result is a set of Things.

Picture5

Reasoners on Things x Observations

The basic operation of a Reasoner is as below: it uses an Observer to get the possibly empty sequence of [Things x Observation] pairs (or Observations or Things), and then it checks on a condition (empty, non-empty) and invokes a sequence of Actions.

AMT needs some Access Information while performing all these operations, and, depending on the type of Reasoner, the Access Information may be that of the Service indicated in the GuestTenant property of the Activity / Service, or that of the Observation being considered.  There are 4 types of Observers:

  • For Each Thing returned by the Observer
  • Once Analyzing only Observations
  • Once in the presence of Things
  • Once in the Absence of Things

The first type can use either the Access Information of the Service or the Observation Information.  The other 3 can only use the Access Information of the Observation.

For Each Thing returned by the Observer

This Reasoner takes the sequence of [Observation x Thing] pairs delivered by the Observer (Type 1 or Type 2), and applies the Actions.  The Access Information can be configured to be either Service or Observation.  The Actions are CRUD on the Thing (not Replace), or Send Observation or Notification, Schedule Observation or Schedule Command (on the Thing).

Picture6

Once Analyzing only Observations

This Reasoner takes the Observation validated the Observer (Type 3), and applies the Actions.  The Access Information can only be configured to be Service.  The Actions are CRUD on a Thing (Only Create a new), or Send Observation or Notification, Schedule Observation.

Picture7

Once in the Absence of Things

This Reasoner takes the Observation validated the Observer (Type 1 or 2), and applies the Actions.  The Access Information can only be configured to be Service.  The Actions are CRUD on a Thing (Only Create a new), or Send Observation or Notification, Schedule Observation.

Picture8

Once in the Presence of Things

Very similar to the previous reasoner, this Reasoner takes the Observation validated the Observer (Type 3), and applies the Actions.  The Access Information can only be configured to be Service.  The Actions are CRUD on a Thing (Only Create a new), or Send Observation or Notification, Schedule Observation or Send a Command (to the Thing).

Picture9

Caveats

Some of the details of the platform can change as newer releases incorporate feedback from more deployements.