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.

AMTech – 2 Minute Overview

The AMT platform is a multi-tenant PaaS and SaaS IOT system.  The platform includes a gateway, a sensor network and a rule-based reasoning system. The platform was designed for Digital Asset Management but it can be used in other areas.  Things and Events are described through a standards-based DAP (Domain Specific Protocol), which enables automatic discovery and assembly of new elements in the system.

At run-time the cloud side of AMTech runs in several machine clusters, leveraging multiple technologies, including Storm Analytics, Titan/Cassandra GraphDB, and Kafka Queues. The gateway can run in many locations, including a Raspberry Pi3.  AMT is highly scalable and maintains end-to-end security.

Events are called Observations and are organized in Topics (akin to MQTT topics)

Things have properties.   A few properties are special, either managed by the system (detection time) or interpreted by the system (location).

The system has built-in knowledge of location and proximity.  Rules can ask for conditions based on them, and reverse geolocation provides data on addresses, et al.

Rules are called Reasoners.  A Reasoner is defined by an “Observer” that analyzes Observations and Collections of Things, and can execute a Sequence of Actions based on the result of invoking the observer (e.g. Existence, Absence, etc).  The actions can perform CRUD operations on things, send new observations (back into the system), send notifications (for external use), or send Commands (to things).

Rules are organized into Activites.  Activities are the unit of deploy and un-deploy and of access control.  Access control roles are called Actors.

A typical arrangement for AMT configuration is to have a Creator tenant that will define Activites (the PaaS side of AMT) and a Follower tenant that can be used to deploy the system (the SaaS side of AMT).   Each tenant can have multiple users, with different Actor capabilities.

AMTech’s Web-based UX can be used to configure tenants, define users, define and test rules and things.  Most of the concepts of the system have corresponding URIs, and many actions can be done through secure REST operations (e.g. through Postman or CURL).

Observations are consumed by the system through REST and WebSockets and can originate from different sources.  AMTech’s gateway, the M2MBridge, is a node.js based software gateway with a flexible plugin-sytem that supports a variety of protocols, from iBeacons to RFID.

AMTech provides end-to-end security.  Actors are used to define the capabilities of different participants, including sensors, and all Things and Observations are typed, using RDF.

AMTech – The Elevator Pitch

Version 1

MT is a rule system that interprets typed events acting on collections of things.  External entities can send events into the system, typically as a response to a sensor.  The rules can trigger the execution of different actions, including sending new events and creating and modifying things.  External entities can also perform CRUD operations on things, and the system can generate notifications in response to conditions.  The properties and interactions among Things and Events are defined via a standards-based Domain Application Protocol that layers on REST and WebSockets.

Version 2

The AMT platform is a multi-tenant PaaS and SaaS rule system.  The platform was designed for Digital Asset Management but it can be used in other areas.  At run-time it uses a node.js-based Gateway to manage sensor data and runs in a multi-machine cluster, leveraging multiple technologies, including Storm Analytics, Titan/Cassandra GraphDB, and Kafka Queues.  AMT is highly scalable, maintains end-to-end security and support auto-discovery and configuration.