AMTech – An Overview

June 27, 2016

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.


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 and, 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.

AMTech – Observers and Reasoners

June 26, 2016

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.


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.


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.


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.


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.


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).


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.


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.


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).



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

AMTech – 2 Minute Overview

June 14, 2016

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

June 14, 2016

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.

AMTech IOT Platform

June 14, 2016

In the last few months my team and I have been involved in several projects using the AMTech IOT platform.  We had a good experience with the platform but it can benefit from additional overview and examples material, so…


  • ProgressNEXT App
  • CSUMB – Quantifying the BIT Building

Overview and Tech Details

CSUMB ’15 – Connected Merchant

June 9, 2016

Version 2

I recently finished mentoring a team at CSUMB for their Capstone project and that reminded me I never found the time for a post on the project in 2015… so here it is.

Cal State University Monterey Bay (wikipedia, website) is one of the newest campuses in the Cal State system.  They are in the old Fort Ord campus, and they were founded in 1994.  Its a beautiful campus, they have a lot of space to grow up and a very ambitious and yet doable master plan.   Most of their student body is from the surrounding communities, and they have a collaboration with local industry and community colleges.  Part of the graduation requirement is a Capstone project.  I had met some CSUMB students through YHacks in Fall ’14, through them I met Prof Sathya Narayanan and later I signed as a mentor.

The team for the 2015 Capstone project was

  • Will Adams
  • Amit Panchal
  • Nelson Lee
  • Will McCabe

Here is the obligatory selfie, with the team L-to-R:


The project was a Connected Merchant.  Here is its Project page from the ’15 Capstone Festival Website; the poster has a good job of describing the project and the technologies:


The set up for the project was a Resort Town with Merchants that cater mostly to Visitors mostly arriving during summer or other vacation intervals.  We sketched a solution that would be administered by The City and would benefit both Merchants and Visitors and would be part of a package that a City would offer to its registered Merchants.  The combined solution would include IOT sensors, mobile Apps for Visitors and Merchants and server-side services managed by the City.

The Merchant stores would be instrumented with beacons (iBeacon or Eddystone).  These sensors provide a Bluetooth Low Energy signal at regular intervals that can be detected by smartphones and can then be used to provide indoor location.

The Visitor mobile app is used by visitors when they arrive to the town and can provide information on the events, navigation within the town, using GPS and beacons, a list of Merchants, and navigation within a store using the beacons. The Visitor app also supports communication with the Merchant and with the City Administrator.

The Merchant app is used to get information on foot traffic and other analytics.  It can also be used to communicate with the Visitors and the City Administrator.  And can be used to provide information on sales and other material of interest to the visitors.

The City Manager Dashboard is used to manage the content for the Merchant, to talk with the Merchants and the Visitors, and to update city content like events, etc.

For this project we used a combination of technologies, reflecting the state of the different Progress projects

  • The main visitor app was a NativeScript app.  This was a pre-1.0 version of NativeScript (see roadmap) but still worked well enough.
  • The merchant app was also written in NativeScript.
  • The city dashboard was written as a web app.
  • Content was kept using the Telerik Platform BackEnd Services.
  • Node.js, on Modulus, was used to provide real-time chats with the two mobile apps and with the Web app using websockets.
  • Beacons were detected using a mobile app.  We had to use a Hybrid app since at this point NativeScript didn’t support this.

A very successful project.  Many congratulations to Nelson, Amit, Will and Will, and thanks to Sathya for driving this program forward.


CS Education Coordinator Position at CSUMB

May 9, 2016

The Cal State University Monterey Bay has an opening for a CS Education Coordinator.  CSUMB is one of the newest CSU campuses, in the location of the former Fort Ord.  I’ve worked with Prof. Sathya Narayan in the last couple of years, mentoring 2 Capstone teams and interacting with several students in Hackathons and internships.  The teaching team at CSUMB is doing an excellent job, they have two very pretty new buildings (LIT and BIT), and the location is gorgeous.

Check with Prof Sathya if you are interested in the position.  And feel free to ping me if you want additional context.   You can also check out my Flickr albums on CSUMB (Capstone 2016, Capstone 2015, visit to CSUMB).

Below is the post from Sathya.

CS Ed Coordinator Position

Estimote Plugin for NativeScript

April 4, 2016


Mehfuz has published a NativeScript plugin for Estimote.  The plugin works for iOS and for Android.  When in iOS, the LocationCore event will be delivered to the app.  If the app is not in the foreground, the event will be stored in local storage and can later be delivered to a cloud location using background sync.

Cesar Galvan will be leveraging this plugin in our CSUMB Capstone project to implement a mobile app for the Capstone Festival (May 20th).  The app will be aware of different locations inside the new BIT building and will help attendees and presenters navigate the event.

Repo is at, with ASL2 license.

Using Slack in a Large Hackathon

March 5, 2016

Earlier this week Developer.Telerik.Com published a note I wrote about a recent experience of using Slack in a large Hackathon.   Check it out here.


Why Wombats?

February 4, 2016

My G+ avatar is a Womby, a wombat.


Yesterday I was in a concall and Womby was mistaken for a squirrel (!).  I educated the offending party but it took me a bit to find the correct references so I’m collecting them here:

Why Wombat?

  • They are interesting animals
  • A group of Wombats is called a Wisdom (ha! I didn’t know that!)
  • They have history as jargon, particularly this and this
  • At Sun, we used Wombat in the past in several projects, from as way back as JavaBeans and JSP and many other places.  There the original instigator was Graham Hamilton ([1]). Jerome Dochez ([2], [3]) and myself ([4]) also included Wombats. Graham, Jerome and I were all part of the original JavaBeans team and there also scattered references to other Java documents like ([4])
  • I believe the “original” source of Wombats at DEC is via Datatrieve (DTR); see Datatrieve and Wombats (from IBPhoenix). Jim Starkey was the original designer of Datatrieve and, I believe, the original injector of Wombat.

Personally I was introduced to Wombats by Graham, who worked at DEC before joining Sun.  I met Jim after the MySQL acquisition by Sun but didn’t realize his relationship to wombats at the time.

DTR was a 4GL language (not dissimilar to OpenEdge in spirit).  Below is the output of



And here is Jim Starkey and Wombat



Get every new post delivered to your Inbox.

Join 104 other followers