Overview

Titan has produced a novel way to embed low-cost RFID sensors into curing concrete, and has demonstrated that the temperature and moisture readings from these tags can be used to measure the compressive strength of a the curing concrete directly instead of using the typical time based strength-gain curve.

In order to make this novel approach actionable, a system needs to be designed to capture, store, associate, and display this data.

Altamus has been contracted to provide architecture design direction and suggestions on how to move the product from lab tests, to prototypes, to fielded units in a way that minimizes re-designs and re-integrations, so that any work done in developing a Minimum Viable Product can be used directly to improve the future product

Executive Summary - Suggested Route to MVP

Role Selection Reasoning
Capture Edge30R + Boron Using the Edge 30R and the Mercury API used to control it provides flexibility to choose different permutations of readers down the road.
It also likely provides the best read performance of the various reader options, based on HID reputation.
The Boron provides "It Just Works" connectivity with the outside world at a reasonable operating price.
Both components are low enough power when idle to enable battery operation.
Transmit Particle Webhooks The Particle Webhooks allow flexibility and HTTPS security with storage endpoints without having to change firmware on the device.
If firmware improvements are made, Particle provides easy ability to update the devices remotely.
This type of application is what Particle was targeting when they created their system.
Store EC2 + RDS EC2 VM to run business logic and API, RDS database to store data. Straightforward, affordable, scalable.
View Flutter Bare-bones Flutter app to provide cross platform display capabilities

The system will require the following high level components to provide the above functionality

Architecture

At a high level they are:

  • Tags
  • Capturing
  • Transmitting
  • Storage
  • Context
  • Presentation

More information can be found at the Architecture Section

Proposed Final Product Workflow

The future theoretical RCrete system will have the following proposed workflow.

This is not in scope for the MVP, but is considered in development of the MVP.

  • Customer orders batch of concrete
  • Order is logged into existing Titan ERP/CRM
  • Plant operator mixes batch
  • Plant operator programs tags with metadata (batch ID, customer ID, etc)
  • Plant operator provides tags to driver
  • QA associate sets up static readers at expected locations at site
  • Driver delivers tags to QA associate
  • Driver pours concrete while QA associate places tags as strategic locations
  • With readers already set up, initial values for moisture sensing can be logged automatically
  • Readers read data from tags on programmed interval and send data to server
  • Server presents users on desktop/mobile with relevant data
  • Concrete reaches maturity
  • Static readers are removed for reuse elsewhere