How to integrate fuel monitoring into Fleet Management System

Transcription

1 How to integrate fuel monitoring into Fleet Management System

2 How does the typical Fleet Management System work? In order to find the ways to incorporate the fuel control system into the general transport monitoring system, first of all you need to understand an internal structure of the typical Fleet Management System. Let's start at the very beginning. Our customers as being the vehicle owners want to obtain real information about their fleet operation. Indeed, vehicles are permanent assets of an enterprise, so the fleet needs to be brought under control. The best way to meet these customers' demands is to mount the on-board AVL (automatic vehicle locator) in the vehicle. AVL transmits data to the server. The server, in its turn, generates the reports the customer will view. The Figure below demonstrates the technical tools to satisfy customers' needs. AVL has an ability to gather various pieces of vehicle information. The GPS receiver being a part of AVL, allows you to determine the time and location of a vehicle. GSM modem built in AVL, transmits data to the server by means of the cellular connection. Along with GPS feature, AVL is capable of reading a wide range of various data. With this aim in view, additional AVL's inputs are normally provided for reading digital and analogue parameters, and there is also a port for reading CAN bus data (vehicle information highway), etc.

3 All data are packetized and regularly sent to the server for being stored and processed. GSM network is transparent for communications. Everything that is sent from AVL, arrives at the server, and vice versa. All further Figures will show the channel from AVL to the server as the direct channel. The Figure below presents the main data exchange in the channel. AVL transmits the collected data to the server. As a rule, the data are grouped in a packet which keeps like a container the information about data collected. These data include location, speed, input voltage, CAN bus data, etc. The server sends commands to AVL, such as "enable / disable AVL's digital output", and also upon receiving information it sends back acknowledgements. Besides client functions, the server performs also administrator functions. The system administrator has to establish connections with new clients, and to provide clients' connection / disconnection to / from machines. The administrator is also responsible for analyzing system's load and printing service bills to customers. All this is known as a system's operator level. All this makes an integral part of the system-based business. The Figure demonstrating the system administrator level is presented below.

4 Certain Fleet Management Systems are also connected to other servers, e.g., to the insurance company server, to the server of the controlling authority for transportation of hazardous goods or to the public transport server. The administrator's duties also include distribution of information to the external servers. A full picture of a typical Fleet Management System is presented below. To make the following pictures more understandable, we will depict all server-related activities as a single block titled "Initial IT infrastructure".

5 An external server may be also represented by various connected to ERP customers' tools.

6 Integration of Fuel Monitoring Solution into the Fleet Management System Thus, we have got the full picture about how the Fleet Management System works. For the purposes of the integration we must optimize on-board equipment operation by adding a fuel level sensor connected to AVL and thus providing an additional opportunity of processing data and displaying reports (as it is demonstrated in the server-related block). Making changes to the on-board equipment There are several ways of connecting the fuel level sensor to AVL. The easiest and fastest way to de this is to connect the sensor via an analogue input. In this case, a vacant analogue AVL input should be engaged. The fuel level sensor «knows» how to adjust itself to the input scale of AVL's analogue input, therefore there are no losses during data transmission. Configuration of the on-board equipment acquired the form as it is shown in the Figure below. If need arises to place several sensors on several tanks, sensor concentrators or a digital connection protocol are applied. In doing so, the general principle of integration remains unaltered. When in operation, AVL measures its analogue input voltage and transmits appropriate data to the server. Data packets include voltage values at the fuel level sensor output as being the analogue input data. See the Figure. Since this input previously was not engaged in the system, the data from this input are rejected by the system having therefore no effect on the results. Making changes to the "server-related block" In order to serve the client requests we need to implement the infrastructure for fuel data processing and the system of fuel reporting. For this purpose, we are going to add the Cloud Service Omnicomm online to the already existing Initial IT infrastructure. The Cloud Service Omnicomm online possesses all necessary tools for receiving / storing / displaying and presenting data to the user. Here, the system administrator level is also available.

7 To make two infrastructures work in parallel, it is essential to duplicate information arriving from AVL. This is indeed possible if data are being delivered to Omnicomm online. To that end, we use the repeater. The repeater features a transparency in regard to data streams arriving from AVL at the Initial IT Infrastructure and vice versa. In other words, incorporation of the repeater into the system does not affect the system's performance. Moreover, the repeater copies all incoming data from AVL and forwards them to Omnicomm online. The reverse direction data stream from Omnicomm online towards AVL is blocked. Transferring data between servers also is out of the question. This contributes to the inalterability in the system operation. Connectable Omnicomm online is only able "to listen for" incoming data from AVL. The repeater itself may be situated anywhere, i.e. in the Omnicomm data centre, at system operator's working place or at any other place with a reliable access to the Internet.

8 Let us turn our attention to the connection procedure and think over the standard solution. The Server infrastructure provides a port which accepts data arriving from AVL. It is shown in the Figure under the title IP Port 1. Thus, in the AVL settings, there is an option to specify the address to which data are to be sent. For establishing connection, the port specified in AVL settings must correspond to the port of the Server Infrastructure. AVL should be tailored to the context of new solution, therefore several configurations must be performed. Since AVL must be connected with the repeater, you need to change settings for AVL output port from IP Port 1 to IP Port 2 (IP port of the repeater). The repeater adjusts itself for transparent data translation from IP Port 2 to IP Port 1 (the Initial IT infrastructure IP port). The Omnicomm online IP port is the port to which the copies of data packets are sent from AVL. In the Figure, this port is designated as IP Port 3. Duties of the system administrator As mentioned above, every server infrastructure has its own administrative functionality. When a new AVL is being connected to the system, the administrator must register it on the both Initial IT Infrastructure and Omnicomm online servers. For convenience of the user, the machine's nickname must be the same on both servers to help the user not to mix them up. Also the needed settings must be made for each server. For example, for Omnicomm online, the analogue input parameters of the device, fuel handler settings and calibration table must be defined.

9 What the customer observes The customer gains the second additional Fleet Management System which is thoroughly functional. The customer need not leave off a habit of working with old system, so he may continue using it without any limitations. Besides this, in the second browser's tab, may be opened additional reporting system which is provided by Omnicomm online. Therefore, the first browser's tab contains the old Fleet Management System hauntingly familiar to the user, whereas the second browser's tab contains a system of additional fuel reports. The Omnicomm online system focuses on vehicle statistics reporting and primarily fuel consumption reporting. The Omnicomm online tab displays the Report SW window. Pay your attention that Omnicomm logos are replaced by your logos. The customer perceives the solution as a single whole delivered by service provider.

10 Combined fleets More often than not, you start trial using provided that your fleet has been already equipped. It means that a portion of your cars does not have fuel level sensors, whereas certain cars do have these sensors. The necessity arises to deal with 2 solution types an old one and a combined one. No problems will occur, and in this case the system will be visualized, as shown in the Figure below. AVL 1 has been installed according to the old scheme not offering a fuel level sensor connection. AVL's configuration presumes transmitting data directly to the IP Port 1, i.е., to the Initial IT infrastructure input port. AVL 2 has been installed according to the scheme offering a repeater usage, so AVL 2 is served by 2 servers. In the Initial IT, an end user will observe all vehicles, whereas in Omnicomm Online, the end user will only observe the vehicles connected via the repeater. In order to monitor a vehicle within the framework of the combined solution, you just need to change the destination port for transmitted data. Safety and localization requirement for personal data Several countries introduce the order of personal data storage, when the data are only permitted to be stored within the territory of the country whose citizens work with the system. This requirement against the background of global transparency for accessing information seems to be a little bit weird, but it must be obeyed. There are 2 solutions. First. The personal data of customers, such as their names, addresses and contacts will be only stored in the Initial IT infrastructure, whereas Omnicomm online is intended for storage of the customers' / vehicles' nicknames and technical setup information alone. In other words, the data being stored in Omnicomm online are not personal and from the viewpoint of an outside observer these data are abstract values. Second. On certain conditions, we are ready to place the Omnicomm online within the territory of the country where the solution will be implemented.