In a previous blogpost, we presented how Thomas Concrete Group, a world-leader company in the concrete industry, was implementing its first IoT solutions. The goal was to start offering more digital services to their customers, something that is still not the norm in traditional industries like construction.
Their first IoT implementation allowed customers to track the delivery of their concrete. Now, the company offers a new digital service: the possibility of monitoring the concrete curing process in real-time.
The curing of concrete has high importance in the construction process, as it will influence the final strength of the concrete. The curing starts immediately after the concrete is poured, continuing for days or even weeks; in order to get good results, the concrete's temperature needs to be maintained at proper levels during this period. To monitor this temperature, thermocouples are usually inserted inside the concrete, and measurements are performed regularly to track the evolution of the curing.
In the Thomas Concrete setup, these sensors are now digitalized. Customers can consult the temperature readings anytime, accessing the information through a web portal and a mobile app. And for further convenience, customers can check not only the temperature measurements but how the actual strength of the concrete is evolving in real-time, being able to generate PDF reports with the results.
The PDF reports include data like this one, which allows customers to see how the temperature has evolved over time. Each line in the graph corresponds to different sensors, placed in measuring points. (This is real data from an actual project; names and IDs are hidden for confidentiality.)
Tracking temperature data: the architecture
As we mentioned before, CrateDB was the solution chosen by Thomas Concrete for its first IoT project, which resulted in the tracking of their delivery trucks. Indeed, the truck-tracking use case required a database with really high ingestion capabilities, as the trucks generate a constant stream of events; CrateDB was a clear fit for that high ingestion use case.
The technical requirements for this second IoT use case differed significantly from the first one though. The curing of concrete is a slow process that can last weeks, and it was now very important to assure the reliability of every data point. However, the Thomas Concrete team decided to also use CrateDB for this second IoT implementation, for several reasons.
The first one was that their experience with CrateDB was very positive, with a performance that kept proving excellent in the truck-tracking use case. Second, the scalability properties of CrateDB would come in handy for this use case as well; by now, the curing monitoring service is only available to their European customers, but Thomas plans to expand it to the US too. Third, CrateDB had some specific strengths relative to the new project. For example, CrateDB's support for edge modules was especially useful for this use case, as it was important to offer a reliable service even in locations with bad connectivity. An edge deployment was the ideal solution to assure that no data was lost.
After some PoCs and real-world testing, the final architecture was shaped into what's represented in the diagram below. It is based on an event-driven approach, with the raw sensor data continuously being ingested to CrateDB through Azure IoT Hub as the entry point. The services and CrateDB are hosted in a Kubernetes cluster with 3 nodes and 12 cores, a setup easy to scale.
The architecture includes project-specific, on-site gateways, with the sensors communicating through the Sigfox protocol. The solution is ready for multiple protocols, however, to keep it as flexible as possible; that's why both Sigfox and LoRa are included in the diagram.
Every data point is processed and contextualized together with casting measurement data, order data, and so forth, ensuring that the data that persists is of high quality. Besides, to allow the automatic generation of the PDF reports, the integration also stores in the specific information needed for calculating the strength, like material rows and product information.
The next section presents a few more details on how this automatization was set up.
Generating live reports with strength data
Before this digital solution was launched, Thomas Concrete used stand-alone software to calculate the strength of the concrete. This software was developed inside Thomas Concrete Group as a proprietary solution, using barely any commercial software (a commercial library is used for visualizing the results in the UI, but no commercial software is used in the calculations).
Through this digital service, customers can check not only the temperature of the concrete but how its strength is evolving over time. This strength is calculated with software developed by Thomas Concrete Group. (This is real data from an actual project; names and IDs are hidden for confidentiality.)
Before, strength reports were produced manually, but the new implementation required the automatic generation of PDF reports with real-time data. Traditionally, reports like these would be generated by a background job, which in a cloud-native environment would translate to something like an Azure Web Job. However, the team at Thomas saw problems with this approach. Using a background job for generating the reports could cause delays for the user in certain scenarios, as for example if the user edited the stop date in the UI and then navigated back to download a report.
Rather than having customers waiting for the background process, TGC decided to build a system that generated the report on the fly immediately after pressing "download". This approach required a good enough performance so that the user doesn't feel that it's taking too long to get the pdf. Thanks to the previous experience of Thomas Concrete with CrateDB, they were confident that this performance would be maintained over time, even with high volumes of data stored and scaled across markets.
With the design defined, the legacy software solution was finally "modernized"—the result is a programmatically consumable REST API serving the strength measurement results on the fly. It is hosted in a highly available AKS cluster, with Azure API Management for load balancing and ingress, and with the subscription and role-based pricing model applied as an authorization check in an HTTP pipeline middleware.
Wrap up
Let's finish with the words of Kristoffer Axelsson, Principal Solution Architect for Thomas Concrete Group:
"Thanks to CrateDB's great indexing, dedicated data types, and subsequent great performance, we could execute the optimal architecture and solution for the use case: an event and data-driven architecture, with the performance and scalability necessary for storing time-series data over time. The SQL query syntax capability of CrateDB also played a part in achieving this great outcome, as it made it easy for the team to write good performing queries using existing know-how."