Spying on trucks

No matter how trite it may sound, in the twenty-first century trucks are not just carrying goods from point A to point B, but rather complex systems of components connected by a network. The collection of information from these components, complemented by the capabilities of modern mobile devices that can determine their location through the GPS system, and have mobile communications, reveals rather large possibilities for optimizing traffic, managing a fleet of vehicles, and, in a sense, even the behavior of drivers. All this is called transport telematics, which this article is devoted to.



I have to warn you that I have not used the Russian language for the last 25 years too often, so please do not be surprised if the construction of sentences or the words used seem strange.



I have already worked for a total of 13 years in the field of transport telematics, for 5 years I helped to monitor garbage collectors, 8 years for fuel tankers. In these two options had a lot in common, but also a lot of different.

First, a little about the general

The first and main function is tracking via GPS. It can be seen where the truck drove, you can determine where he lost his position, and where he found it again, almost in real time.



If there is no connection with the server, the track is recorded in the memory of the onboard computer. In the absence of GPS reception, indirect monitoring is possible through the positions of GSM towers. At one time, we had a partnership with OpenCellId - an open data bank of GSM base station locations (read more about this here ), where I filled about a million coordinates every week, but unfortunately the partnership was closed when OpenCellId was sold to an Indian company that turned the service even for promoters, and in fact our system alone gave about a quarter of all the coordinates they received.



When you go offline, data is not lost, it is simply recorded less often so that the internal memory is not too full. The amount of track data also depends on how fast the truck travels. Typically, the frequency of data collection increases in proportion to the speed, so that the track on the map looks smoother, but some customers are not interested in data where the car drives at high speed — in such cases, the car is usually located on the highway, where nothing interesting happens. .



The second main function, which is often implemented separately from the first — so much so that additional iron is used for this — work directly with the driver. The tablet screen shows a list of tasks for the driver with the addresses of customers to which he should go. Usually, the driver is obliged to select one task from the list, “launch” this task, and when executing the “finish” task, it is possible to enter additional data.

Thus, in the office in real time you can see what the driver is specifically busy when he started work, when the work was done. Thanks to this opportunity in the office, it will be possible to calculate how much the driver has gained, and how much this particular trip has cost the company. At the same time, all the necessary information, which until then was only on paper, immediately and automatically goes to computer systems. For this additional work, the driver is given several conveniences, such as: automatic activation of navigation to the target or the ability to immediately print out all the necessary papers, instead of filling out forms.



Next comes the monitoring of the FMS and various sensors. Modern trucks have a fairly sophisticated digital engine management system, and to facilitate the collection of information for these on-board computers, seven European truck manufacturers have together created the FMS (Fleet Management System) format, a standardized interface for connecting (read only) to the engine management system via CAN-Bus, in which in real time there are the main parameters of the truck, such as speed, mileage, fuel consumption in a certain standard format.



Basically, this information is used to check the quality of work of drivers - how economical they are going, but it is also realistic to catch thieves. For example, if the level of fuel in a tank falls faster than usual, especially if the truck is at that time, then the situation is unequivocal.



In addition, some of the information comes from the digital tachograph - an instrument mandatory in the European Union that records the working periods of drivers and the speed limit of the vehicle. Thus, without connecting to the tachograph, you can directly find out when a particular driver got behind the wheel or finished work. Different sensors are, as a rule, digital inputs, so you can check that where it is turned on (headlights, seat belt, etc.). An elementary example for such sensors is that the on-board computer monitors the handbrake, and only if the brake is turned on, stops blocking the phone - many companies that carry dangerous goods, prohibit drivers from talking on the phone while driving.



Since GSM modems are used in telematics devices, it means that in principle they can be used as mobile phones, then the driver will not need to provide a means of communication. At the same time, it is possible to control how this communication tool will be used - the very blocking of the phone with the handbrake, which I wrote about above, the blocking of the phone outside the home network, the permission to call only to certain numbers.



Receiving and sending SMS is also there, because of which sometimes you have to listen to complaints from drivers who are often near the border - there are constantly messages about tariffs, which led to a dilemma - without an additional black list, you can only disable SMS reception completely (simply removing the SMS table from data bank), but then the message will not come at all.



There is one more useful function connected with the use of a GSM modem - upon receipt of a signal from the Emergency Data Recorder (EDR - Event Data Recorder) the on-board computer can automatically dial a specific phone number.

And now a little about the differences

For garbage trucks the main thing - where to go and how much to pick up. Accordingly, a rather important task was to connect the scales, which are built into the elevator of garbage containers and automatically weigh them when lifting. For this weight, business customers are billed for work.



Drivers, in turn, can give a bonus for fast work, respectively, you need to know how long it took to shake out the container, and how quickly after the arrival of the garbage truck at its destination, the container was picked up.



To do this, it was necessary to connect the lift control joystick to the digital input, which was not always as simple as it seems at the planning stage. One day, a technician rummaged around in an electric truck for so long that the driver was tired of waiting, and he went home, but we stayed with the technician. Everything is connected, it seems to work, and the signal goes, but we could not do a full check without a driver.



The next morning, we were waited by a huge separation from the client's side - the technician did something wrong, and the lift lifted the container only half the height required. Another time there was a problem with the electrics of the truck, because of which I had to pull out one of the fuses. After that, the truck completely ignored the ignition key and did not turn off altogether, and worked idly until the diesel in the tank ran out.



Since there are a lot of producers of add-ons for garbage trucks, a rather large number of different protocols for the scales built into the elevator, respectively, and for each of them we had to write separate functions. In some scales there was no interface for telematics at all, the only information output was on their special printer via RS232. There already had to solder the Y-cable and pull the necessary information out of the data stream for the printer.





Scale check



There was also a task to train new drivers who still do not know the route. It was done this way: an experienced driver drives along the most optimal route, his GPS track is recorded, manually optimized for the number of points, and then sent to the navigation system of beginners.



At that time, navigators did not have the ability to download recorded tracks, so we had to set each point “manually”, monitor the navigation system, and when there were meters left before this point, replace it with the next one so that the navigator did not have time to joyfully announce the achievement of the goal. But it was possible to post a window on the navigator with the information, it was used for comments, in which the driver could see the features of the target - as it is most convenient to call in, ask someone for papers, etc.



For gasoline tankers, the requirements are different; there is more emphasis on the fact that drivers have a bad tendency to steal fuel. And if in Western Europe it is rather a lonely business, then in Eastern gasoline theft is handled by whole gangs that send their drivers to transport companies.



It is impossible to cross this case, so most of the anti-theft functions are made in order to catch the thieves at the crime scene. The main tool for this is geofences. Simple - draw circles on the map around the places where certain actions are allowed. If these actions are performed outside the specified location, an alert is sent to the administrator.



Next is the monitoring of the very actions that can be very much. The flaps of the tank draining system, the draining of the liquid from the tank, an open safety belt, and even a stop longer than 5 minutes are opened. Monitoring the drain system most often catches drivers who want to make money at someone else's expense: several days ago there are alerts that the fuel is being dumped outside the geofence. The track shows that the driver in the place where he spent plums, should not have been. The next day the police were waiting for him there.



Another option - the gas tank, which gives a continuous signal when it is closed. If the signal disappears - the gas tank is open, or the signal cable is cut off - it means that someone slowly wants to drain the fuel while the driver is sleeping. The system beeps, the driver wakes up and drives the thieves with the help of such and such a mother.

About used technique

Aplicom F-Series



When I began my work with transport telematics in 2003, there were practically no suitable comparatively universal devices on the market for which I could write my own programs. The choice at the time, by and large, was limited to the Aplicom C series / F series and Owasys Owa2x.



The first device was made by people from Nokia, worked on their own operating system (OS95A), which was a version of the OS for old Nokia phones, even those that had two lines of text screen. The development was carried out on the C99 by the CodeWarrior ARM compiler, and was rather inconvenient due to the outdated compiler, and because of the rather primitive operating system, which was actually compiled along with the program I wrote for the device.



The second device was made by people from the Spanish branch of Ericsson, had a slightly faster processor, but one port RS232 is smaller and worked under a rather ancient Linux. The development was carried out in the same ancient GCC (2.95.3) with all the ensuing consequences (bugs, non-working functions of the language, frankly crap support for C ++ and poor code optimization).



Aplicom subsequently ported Linux to their machines, but by that time it was too late. The biggest disadvantage of the Aplicom devices was the lack of a file system, writing to Flash memory was more or less directly in cells, yes, and by the way, the manufacturer didn’t recommend writing to this memory at all.



On the other hand, Owa2x had one big advantage - Linux - and a huge number of flaws - only two RS232 ports, which made even elementary debugging through the console difficult, a CAN-Bus controller that hung regularly, using one internal RS232 port and for GPS and for GSM using a multiplexer, which is why GPS hung up when GSM started or stopped, the file system, which was unpacked into a RAM disk at each start, because of which it was impossible to permanently replace any system file, and dessert, dock entatsiya, whose use was lower than that of toilet paper.



When I visited the manufacturer’s office and showed them all these problems (which they didn’t decide later, just saying that they are now doing new hardware - Owa3x, in which everything will be better), I left them uplikomovskuyu documentation to take an example ( started taking about 6 years later, when they were already doing the next generation - Owa4x).





Flashing Owa2x



When Owa3x came out, at first I was very happy. There was a newer compiler (GCC 4.3), a faster processor, three RS232 ports, and, finally, a microSD card slot. Now it was possible to put the program on the card, so that later, if anything, it could simply be replaced. However, I was happy early.



Architecture errors such as the unpacking file system and the same multiplexer for GPS and GSM remained, with the first error becoming more serious - the firmware became much larger, and the modem still supported only GPRS, the version with UMTS support was much more expensive, and 2011



People made iron, as they used to. Then it turned out that MicroSD cards pour in, if you regularly write to them. They live for about a year, after that they die, and the program stops starting. At first they tried to do several sections on a card, and one - where the program is read-only. It did not help, and rather it was counterproductive - the controller of the cards was not designed for such perversion.



Now the program is in the internal memory of the device, and the data is on the card only, so if the card stops working, it is simply changed. I didn’t do that before, because there were often problems with the internal memory file system, files were regularly broken that the manufacturer was able to fix with firmware in the end.





Owa3x



Two years ago, I decided to do a serious refactoring and rewrite a part of the program, because before that it simply had unsystematically accumulated all sorts of functions. At the same time, I decided to get rid of the dependence on boost, which greatly fanned both the source code and the binary, and standardized the approach to solving problems, and then the boost function was often used, the c ++ function, or the classic from C to achieve the same effect.



Boost was the easiest to get rid of by rewriting the program for C ++ 11, which at the same time would simplify much more - which is only one cost based for for kilometer iterators.



As it turned out, C ++ 11 support under GCC 4.3 is absolutely wry, even minimal programs using STL were not compiled. There was an official response from the manufacturer that another compiler is not supported on this hardware, but 4.7.3 works unofficially if you download the appropriate libstdc ++, which worked more or less, but it was unreal.



I had to cross already with a hedgehog here - I took GCC 4.8.3 (4.9 would have failed, changed something in ABI), put libstdc ++ in it from my GCC 4.3 and copied alternately system include files that had errors , from there until it is compiled. Oddly enough, the whole structure has earned, and not bad.



The resulting mixture of libraries and includes may have been used for some time in clang, but the binaries were not optimal and there were more errors — clang sometimes compiled calls to some functions that the old library simply did not have, but at least in this way there were stylistic mistakes that GCC forgave.

Tales by the fire

• When I started working in this area, I was an absolutely green student trainee. The company in which I got a job, just sold what was, by and large, a PowerPoint presentation, and I was immediately sent to this case.
  
  
  
  Apparently, my new employer did not take all this seriously, despite the fact that the client would have to take the program after three months, and the intern who started writing it before me quit.
  
  
  
  I didn’t know how to program in C at all, before that I had written only dosovsky programs on Turbo Pascal, mainly for feedbook bibiessocks. C language terribly struck me - this is how many opportunities to shoot yourself in the foot!
  
  
  
  After a while, things went wrong, and the program, although it was written very crookedly, earned, but I was godlessly late. At that moment I was lucky that just at that time a new German system of road pricing was introduced, which, by and large, is also such a monitoring of transport, and its developer TollCollect was also very late, becoming the laughing stock of the whole country. Against this background, customers took our delay for several months with understanding.
  
  
• Imagine that the onboard computer died during the update of the program that it downloaded via the mobile connection. Something did not work at all, the computer stopped loading. There is nothing to do, you have to go to the truck, put an update on it manually through the serial port.
  
  A client representative took me to the base where the truck was located, from which she had the keys. But, as it turned out, she did not have the keys to the internal doors of the base, and it was already evening time, everyone had gone home. She pulled a few clips out of the pile of papers and tried to break the lock while I was standing on the shuhera. In the end, nothing happened, and one of the drivers had to be called to the base, but the attempt was definitely counted.
  
  
• Once, a server that received data from on-board computers stopped working for several hours. When colleagues restored everything, and the server started working again, complaints about the work of the on-board computers did not stop coming - customers did not see where the trucks are, did not see if new data came on the screens of the drivers. As it turned out, everything worked as it should, just for those few hours my devices collected a lot of data, and it took quite a lot of time to send all this data to the server, and according to the FIFO principle, the data were currently the latest in the queue.
  
  
• A client from one of the Arab Emirates complained that the system did not work well, but he did not mention any specific examples. When my colleagues and I arrived at the site, we were very surprised by the contrast between the usual German gasoline tank trucks and the trucks that were used there - Renault Kerax, which are usually used on construction sites, with primitive steel tanks made in Saudi Arabia.
  
  
  
  The trucks look as if they had been working on construction sites for 20 years, although they were two or three years old and had very low mileage, because most of the time they were idle, as each driver had his own truck. Inside we were waiting for ragged wires and husks from pistachios in printers.
  
  
• In Romania, a joint project was implemented with a tank manufacturer and manufacturers of a fuel discharge measurement system. A year later, the instruments gradually stopped working for one client, and the measurement system did not work too well. At the same time, the client refused to provide trucks traveling around the country, because of which they had to catch up and flash them manually. For three days I saw all of Romania from edge to edge, only Bucharest was driven around.
  
  

Flashing Owa3x in Vatra Dornei

Conclusion

The era of such specialized on-board computers for transport telematics is gradually coming to an end - they are very specific, produced in small batches and because of this, they are technically far behind modern mobile devices - phones and tablets, in which not only processors are faster and have more memory, but already stand a large number of program blocks that you have to write yourself otherwise — even such basic things as simple connection to the mobile Internet.



And the development of applications on modern tablets without a doubt much more convenient. However, they will not be able to completely replace the classic equipment of transport telematics, so to collect the maximum amount of information, a large number of I / O ports are needed - from ordinary serial RS232 types to specialized CAN-Bus types. To connect all this to an ordinary tablet on Android, you need a large number of peripherals, or indecently expensive small-scale and highly specialized tablets, but even such a device has one serious drawback - the driver can easily turn it off and at the same time all information gathering will stop.



On-board computers, which in the future will remain the role of such informational hubs for tablets, will work while the truck has power (although there are jokers in the workshops that connect them to the ignition) and collect information even when there is no connection.



Many thanks to hdablin user for support and assistance in editing the article.