We developed the hardware and software parts of the system for collecting, processing and analysis of data on fuel, engine operation and traffic
A company with its own fleet and divisions. To control fuel she needs data on cars, tanks, gas stations, drains, engine operation and downtime.
Build a reliable chain from level measurement fuel in the tank to understandable statistics - including work without the Internet and late loading of data.
We worked out the connection of the FLS and the transmitter, protocols and file exchange, algorithms processing, local server, database, web interface and desktop application.
Physical indications, vehicle condition, events and reports are collected in one system. The user sees not raw signals, but processed fuel consumption picture
Companies with their own fleet often try to control fuel only through waybills, receipts or totals. This approach doesn't show what happened within the period: when the level rose, when it fell sharply, whether the engine was running and whether it was moving car
Installing a sensor by itself also does not solve the problem. The signal contains fluctuations, duplicates and outliers. Temperature changes the volume of fuel. The car can run outside network zones, and the data will arrive on the server later. Without treatment, sudden change is easy mistakenly mistaken for draining or refilling
Tell us about the project — we will break down the task and propose an implementation approach.
The team worked not only with the interface and server. First we had to determine how FLS is connected to the transmitter, what data is recorded, how it is stored on route and how the system distinguishes a real event from a measurement error.
We described the point structure, file formats, states, intervals, events and recalculation rules.
We worked on several FLS for the car, RS-485, transmitter, MAC binding, SD card and Wi-Fi.
Set filtration, temperature correction, filling and draining thresholds, engine and movement
Linked local data collection, server processing, PostgreSQL, web and desktop interfaces
Implemented backend, web interface and desktop application for local operation
A FLS is installed in each tank. If the car has several tanks, the transmitter polls several sensors via RS-485. It records fuel level, temperature, voltage, engine status and movement, and then saves the data to an SD card or transfers it via Wi-Fi and UDP
We will show how to connect interfaces, business logic, data and external systems.
FRS closes the path from physical measurement to analysis by vehicle, department, day and month.
The transmitter reads the data of each tank via RS-485. Use: the entire fuel system of the car is taken into account in its entirety.
Points are saved by date and time on the SD card and transmitted when communication is established. Benefit: route does not depend on the Internet.
The system removes duplicates and outliers, takes into account temperature and fuel type. Benefit: less false events.
Abrupt changes are checked over time, engine and threshold of a particular vehicle. Benefit: events are visible separately from normal flow.
The motor is identified by voltage or flag, movement - by accelerometer or motion. Benefit: expense gets work context
Data is aggregated by day and month, available filters and export. Benefit: the report is generated from already calculated metrics.
The user selects the division, vehicle and period. The screen shows the initial volume, consumption, balance, level change graph and table by day.
The employee sees the cars of the selected department, their identifiers, activity and time of last synchronization. From here the car is added or edited
Tabular view shows department code, machine, users, roles, local servers and access points. It is suitable for searching and mass structure inspection
We will analyse the functionality and build a clear interface structure.
Defining goals, studying the audience, forming requirements and setting tasks. This helps to understand what the business needs and what results are expected.
Creating the solution architecture, thinking through user scenarios, interfaces and logic. At this stage the 'framework' of the future product is formed.
Programming the server and client parts, connecting databases, integrating with external services. This is where the idea turns into a working product.
Checking functionality, performance, compatibility and security. Fixing bugs before the product reaches users.
Deploying the product (for example, publishing in stores or launching on servers), configuring the environment and starting marketing or internal processes.
Updating functionality, adapting to new business tasks, fixing bugs and keeping the product up-to-date.
FRS linked the measurement devices, transport and analytical system. Control is based not on manual reconciliation, but on sequential processing of time points and customizable rules for each machine
Several FLS can operate in one car through a common transmitter.
Points are accumulated locally and downloaded after returning to base
Filtration, temperature and engine condition taken into account before classification
Daily and monthly statistics are calculated in advance and ready for sampling and export.
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19We build enterprise solutions using a powerful, proven, and
versatile tech stack designed for performance, scalability, and
security. Our expertise spans
We will propose a suitable structure and prepare the first sketch of your future project — with no obligation to start development.
You get a visual concept you can discuss with your team.
He will review your project and business objective, prepare recommendations and the first sketch.
An honest conclusion.If the solution can be improved without a full rebuild, we will tell you so.
