Our client is a market leader in oil field logistics and transload services.  They own and manage a nationwide network of transload terminals where they store and move millions of pounds of proppant (frac sand), crude, and other materials to and from trucks, railcars, silos, and other containers.  Their services are a critical element in the energy supply chain in North America.

In addition to managing transload terminals, our client has expanded their services, to become a full, end-to-end multi-modal logistics provider. They have added their own trucking fleet and proprietary proppant frac sand storage and delivery system for the well site.

Problem

The company’s custom frac sand storage and delivery solution is a game-changer for well site operations. It is a mobile solution that can easily be set up on well sites at remote locations. Where well operators previously managed small, pallet-sized sand containers with a forklift, their system provides modular storage with a maximum capacity of over 3 million pounds, all of which is belt-fed directly to the frac mixer, dramatically reducing downtime during drilling.

Additionally, their system tracks inventory in real-time, automatically requesting more proppant from a company-owned loading facility, delivered by company-owned trucks. With this system in place, our client is able to take full responsibility for the provision of proppant at the well site. However, with this responsibility comes liability. The logistics company contracts with its clients to guarantee availability of proppant at the well site, similar to a Service Level Agreement for a mission-critical IT service or system. Drilling an oil well requires the coordination of multiple teams of people from different companies on-site, operating millions of dollars worth of equipment. If the logistics company’s equipment malfunctions or they fail to deliver enough sand in time, the logistics company must compensate their client for the lost productivity of their people and equipment on site.

The sand delivery system has proven to be exceedingly reliable. However, any system can malfunction, especially when operating in extreme conditions, like outdoors in a remote location, in very cold or very hot weather, as is common in the oil fields.

They needed a way to track any of these down time events, for billing, as well as for analysis to prevent future issues. Additionally, they needed to be able to track down time events for which they were not liable, in case the client made an erroneous claim.

Initially, these events were phoned in to the dispatch team, and logged in a spreadsheet. However, this was time-consuming and error-prone. They needed to be able to track exact start and end times for these down time events, to categorize them effectively, for later analysis. They needed to have the operators on site be able to log such events directly themselves. And they needed to collect a sign off from a representative of the client, in case the issue was disputed later. Also, while data needed to be recorded on site at remote locations with unreliable network connectivity, the data needed to be stored in a central repository in the cloud for easy access to use in billing, reporting, and analytics.

Solution

The bulk sand operators on site were already using ruggedized Android tablets to access equipment maintenance schedules, the company time clock app, and other resources, so we built a mobile app that could be deployed to these existing devices.

The app used our custom Fulcrum Framework platform, which combines best of breed technologies for an extremely flexible solution. We provide a flexible UI that looks great on phones, tablets, and desktops. Our framework allows us to build a single application code base which can be deployed to nearly any platform: including Windows, Mac, and Linux desktop applications; Android and iOS mobile applications; and of course web browsers as a Single Page App (SPA) or Progressive Web App (PWA). And we use a cloud-hosted NoSQL database to provide a flexible back-end data store in the cloud.

First, we had to structure the application so it could function completely autonomously while offline, in case the tablet being used does not have network connectivity at the time. We used PouchDB to store all application data locally on the device and then sync it to a CouchDB datastore in the cloud. While running online, data will appear in the datastore almost immediately, as syncing runs automatically. But when the app is offline, it will store the data locally and wait for a connection to be restored. Once the connection is restored, syncing automatically resumed. We configured the syncing to run every 5 minutes, rather than continuously, in order to conserve bandwidth, since these devices often connect to the Internet through slow and expensive satellite connections. However, we also provided an interface in the UI to see when the app was last synced, and initiate a manual sync if needed.

The app is integrated with the client’s other existing systems, including their employee database, allowing the operators to use a shared login. Once logged in, the operator is presented with a list of ongoing events which are causing downtime, and which might cause downtime in the future. They can also see past events, and log new ones. This allows for a smoother handoff between shifts, which is important since well sites run 24 hours a day, and employees need to be able to go home and get some rest.

The app is also integrated with the client’s equipment and job site data. This allows events to be tied to a particular job, and when an event relates to a particular piece of equipment, the user can select it from a list of the components deployed at that job site.

Once an event is resolved, the operator can mark it complete, and record the time. All completed events are presented in a report which the operator can show to the customer representative. Both the operator and the customer representative electronically sign off on this report.

The events, categories, start and end times, and signatures are all synced to the cloud, where they can be fed into the client’s reporting and analytics systems. Management can easily see all open events across the operation, or for a particular client or region. They can look for patterns, like the same piece of equipment malfunctioning repeatedly. And they can accurately track any down time liability they incur, in order to compensate the customer.

Result

Where downtime events were previously claimed by the logistics company’s clients, this system allows the client to be proactive instead of reactive, reporting downtime to their customers, instead of receiving reports from them. They also have accurate start and end times, along with other details about the event, so they don’t have to take the client at their word if the report is exaggerated. Best of all, they are able to analyze the data and prevent downtime events before they start.

Our client is a market leader in oil field logistics and transload services.  They own and manage a nationwide network of transload terminals where they store and move millions of pounds of bulk sand, crude, and other materials to and from trucks, railcars, silos, and other containers.  Their services are a critical element in the energy supply chain in North America.

Problem

This transload company contracted with one of their clients to install 4 200 ft silos to store frac sand and more quickly process inbound and outbound loads from one of their facilities. The silo installation included a pit and bucket elevator system for unloading railcars, truck scales and gate valves for loading trucks, and an automation system to control all this equipment remotely from an onsite scale house.

The facility is owned operated by the transload provider, but the silos would be owned by the client and used exclusively for their product. The silos were constructed because this was one of the busiest terminals in the region, with an extremely high volume of trucks.

The facility is located in a small town on one of its major thoroughfares, and the long line of trucks waiting to be loaded had caused traffic blockage for the entire town, much to the annoyance of local residents.

The silos were designed to be managed using an piece of industrial automation software called a SCADA (short for “supervisory control and data acquisition”). This significant investment in mechanical equipment and software promised to increase throughput for the terminal. However, since the SCADA was provided by their client, the transload company had no control over the software, and limited access to its data.

Our client has a custom terminal management application, which we helped them build, and which manages inventory, bills of lading, transload billing, and all other aspects of on-site terminal operations. It also feeds data to report systems used by management and customers to make strategic decisions.

Any loads into and out of the silos needed to be tracked in the terminal management application in order to maintain accurate inventory, and to generate correct bills of lading. Additionally, the terminal management application needed to feed data into the SCADA system about the trucks being loaded through the silos, to ensure the correct product was loaded on each truck.

Solution

The SCADA system implemented at this site had limited integration capabilities. However, it was configured to write out a log of trucks unloaded and railcars loaded to a local MySQL database, in two separate tables. The system also had the ability to consume an XML feed of incoming trucks.

We had previously built the client a custom microservice service in Node.JS. It ran on an appliance installed at each of their facilities, and collected data from truck scales, interfacing with the terminal management application in the cloud through a REST API.

We modified this service, adding a microservice to provide the XML feed the SCADA required, pulling data from the terminal management application. We also added a service which would repeatedly poll the SCADA database for new and updated records in the relevant tables. Any new loads would be translated to the format required by the terminal management system’s REST API, and forwarded to that system, in as close to real time as possible.

Result

This project had a very tight deadline but we were able to execute quickly and deploy our solution within just a few days. Our client’s operators on-site were able to run the automation system and load trucks far more quickly, increasing throughput while decreasing traffic.

The automation system received the truck and product data it needed to correctly assign products. The operations team was able to generate bills of lading through the terminal management application, utilizing all the optimizations already present in that system.

Since all load and unload events occurring at the silos were automatically logged in the terminal management application, they were able to track inventory without manual double entry, saving time and avoiding errors.

The transload provider was able to exceed expectations for their client, and the terminal became the most productive site in the client’s entire logistics network.