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:
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:
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:LIT, firstname.lastname@example.org and email@example.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.
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).
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.
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.