System Architecture

Architecture Diagram

The system is made of the following components:

  • Tag - RFID tags and programming
  • Capture - Devices to read the embedded RFID tags
    • Static - A semi-permanent reader to provide continuous readings of the tags
    • Mobile - A handheld reader to provide spot checks for isolated tags or monitoring long term curing after static readers are removed
  • Transmit - Cellular and internet backbone, along with any middleware from external systems
  • Store - A collection of subsystems living on a Titan server or in AWS/GCP that stores data and provides it to clients
  • Context - Existing Titan ERP that can provide information about batches/customers/billing, etc
  • Present - End clients that display the data collected by the tags

Tag

RFID Tag

Titan has, in partnership with HID, created a custom RFID tag based on the Axzon Magnus-S3 M3D processor, installed with the antenna and casing from a HID EXO-2000

It has the following primary features

User Memory

128 bits of user memory is available for writing metadata about customer/load/etc

Temperature Measurement

The Axzon provides a factory calibrated temperature reading from -40 to 125°C (-40 to 257°F) at 0.5°C accuracy. It is stored as a 12 bit number providing 4096 possible values, providing a theoretical 0.04°C resolution.

It is calibrated at the factory between 30-60°C, which is appropriate for this use.

The calibration can be manually set by the user if desired, but is not expected to be required for this application

Moisture Sensing

The Axzon uses an antenna impedance matching circuit to adapt to varying real-world installations that would normally de-tune the antenna. It accomplishes this by using a variable capacitor that can be tuned between a range of values. This is done for RF performance to maximize reading distance

As a side effect of this antenna tuning, it's possible to detect the presence of moisture around the antenna. This is done by taking a reading of the matching circuit at a baseline time (initial installation in wet concrete) and comparing it to later readings. It is not clear how accurate this reading is, but can be assumed to provide a coarse (perhaps +/- 10%) relative humidity.

Kill Switch

If desired, a kill command can be sent to the chip, which will permanently disable the tag from reading. This is a one time use and non-reversible. This feature is not expected to be used.

Programming

It will useful to program the RFID tag with user/batch information to assist in making sense of the readings later.

This can be accomplished two main ways

At Time of Mixing

A desktop programmer can be used to program the RFID tag with user/batch data by the plant operator at time of mixing. This is the most "seamless" workflow, but requires a desktop reader.

At Time of Installation

The static reader can be used to write data to the tag, albeit at a much closer range (RFID read range is further than write range by a factor of about 3). This is less seamless since the coordination between QA/Driver/Installers will likely be more dynamic than at the time of mixing.

Capture

RFID reader(s) will be required to read the tags after embedding in concrete. This will be accomplished with either a semi-permanently installed reader, or with a handheld reader.

Handheld

A handheld reader such as the Technology Solutions 3166 can be connected to a smartphone via bluetooth. Technology Solutions provides an SDK to allow a phone app to be developed that can forward the readings to the storage endpoint. The handheld reader is outside of the scope of the initial design review.

Static

It is expected that the preferred method to read the tags will be to mount or install a series of readers at the site, which will read the tags continuously, store the readings, collate the readings, and efficiently push them to the storage endpoint. This is the most complex of the components, and has the most possible options. See the more detailed Static Reader page for detailed design considerations

Transmit

The data needs to be transmitted from the readers at the site to the storage endpoint. This can be as simple a just using the cell network directly to the endpoint (in the case with the handheld/mobile option), but can optionally include 3rd party web tools. For example, Particle Webhooks will be used by the Particle Boron/Photon to provide secure, configurable and reliable delivery of data to the storage endpoint.

Store

The storage system will consist of the following subsystems:

  • Database
    • Stores data long term
    • Efficient searching and retrieving of data
  • Processor
    • Runs the business logic
    • Authentication
    • Shaping raw temperature readings into PSI values for a given load
  • GET/POST API Endpoints
    • Interfaces that external systems use to interact with the data

Context

Existing Titan ERP system. Holds information that is useful but not required for the core product.

  • e.g., Customer billing information lives in the Context system, and may be used by the Storage processor to block access to data if customer hasn't paid their bill

Present

A mobile or desktop app can display the information stored in the storage system. Out of scope of initial design review.