ITMI20091438A1 - PROCEDURE AND MANAGEMENT AND CONTROL SYSTEM OF INDIVIDUAL VEHICLES, IN PARTICULAR OF SINGLE MOTOR VEHICLES, TRUCKS AND BUSES OF FLEETS OF MOTOR VEHICLES, TRUCKS AND BUSES RESPECTIVELY. - Google Patents

Description

DESCRIPTION OF THE INDUSTRIAL INVENTION WITH THE TITLE:

"PROCEDURE AND MANAGEMENT AND CONTROL SYSTEM OF INDIVIDUAL VEHICLES, IN PARTICULAR OF INDIVIDUAL MOTOR VEHICLES, TRUCKS AND BUSES OF FLEETS OF MOTOR VEHICLES, TRUCKS AND BUSES RESPECTIVELY"

DESCRIPTION

The present invention relates to a method and a system or device for the management and control of individual vehicles, in particular of individual motor vehicles, lorries and buses of corresponding fleets.

More specifically, in one of its first embodiments, the present invention relates to a procedure and a system for the management and control of car sharing cars, belonging to fleets of private companies or of the public administration, mainly electric cars. , but also of conventional vehicles, with an innovative model of access, localization, addressing, tracking, registration, as well as economic-commercial.

As is known from a market study conducted internationally, it appears that almost all car sharing companies, with a few exceptions, are at a loss.

in Italy, all the car sharing companies are publicly owned, and stand only for state or municipal contributions that make up for the losses at the end of the year.

moreover, car sharing has not yet “broken through” and the number of season tickets and daily trips is absolutely modest and, in fact, this service is not able to solve the urban mobility problems of large cities.

The limitations of the current system are due to the cumbersome operating model and the lack of flexibility that would allow citizens to fully satisfy the need for erratic mobility.

The current system is designed for medium-long journeys, even outside the city.

It is not a system conceived for the urban circuit, to favor short trips, even shorter than an hour, in order to maximize the number of daily trips and therefore the users served, for each individual car. Currently, cars are parked in covered garages or affiliated car parks. The user makes the reservation with a telephone call to the operations center, which sends the reservation to the car, which can then be taken only by that user.

alternatively, the user can make a reservation by connecting to the website.

In other words, a reservation is required to allow the use of the car by the user.

This represents a limitation of the system as it prevents the diffusion of cars on public squares, where the user can pick up the car independently, when he wants and for the time he wants.

moreover, this method actually means that usually only one reservation is made per day. Statistically, the Italian averages say that a car does not circulate for more than 5 hours, but there are also hundreds of monthly trips of 1 or 2 hours or a day, and therefore that they invoice very little, thus representing a deadweight loss for the management company, since, when the car is booked, it is difficult to book by a second person within the same day.

A second major limitation is represented by the subscription modalities that do not facilitate the diffusion of the service. The user must go in person to the headquarters of the car sharing company to sign the contract, or do everything by phone and wait for the postal delivery times for the card. With this method it is also impossible to subscribe tourists, who go to a city even for one or a few days.

Ultimately, the aforementioned state of the art situation does not in fact make it interesting to invest a car sharing fleet.

The invention also relates, in a second embodiment thereof, as previously mentioned, to a process and a system for the management and control of the journeys of trucks and buses, preferably included in small or large fleets, as prescribed by the Italian regulations and European.

From this aspect, it is also known that the law prescribes the obligation, imposed on the transporters and operators of these fleets, to provide and archive data relating to drivers, departure and arrival times, driving times. and rest, at the speeds maintained during the march, and so on.

This obligation is currently fulfilled by the latest generation of digital tachographs which make it possible to cover the entire process of recording data relating to trucks, their loading and unloading, and their storage, up to the evaluation and planning of subsequent journeys. according to the hours already worked. Thus the trip data records can be read by the police in case the truck is stopped for normal routine checks.

The same data must also be downloaded every 21/28 days from the tachograph via a USB key and from a key to the transport company's computer.

This process obviously has the drawback of the truck being stopped and the indispensable presence of a company employee, equipped with a company card and a driver.

Therefore this process is cumbersome and expensive in terms of working hours.

It must also be borne in mind that, ultimately, the purpose of archiving is to allow the competent authorities to carry out checks not only directly on the road, but also a posteriori, which checks are obviously random and therefore allow to discover, with high investigation costs, only a relatively low number of infringements.

The Applicant has realized that, in order to improve road safety and the prevention of possible accidents due to excessive speed or fatigue of the driver for not respecting rest times, the known management and control system of trucks and buses à ̈ likely to be substantially improved.

In light of the aforementioned drawbacks relating to the management and control of cars in car sharing and of trucks and buses preferably belonging to respective fleets, the task of the present invention is to provide a method and a management and control system for individual vehicles , in particular of single cars, trucks, and buses belonging to fleets of cars, trucks and buses respectively which can be applied indifferently, as conceived, or with only minimal changes, both for the management and control of cars in car sharing and for the corresponding management and control of trucks and buses of respective fleets.

Within the scope of the aforementioned task, a main purpose of the present invention is to provide a process and a system of the type indicated, allowing the user to pick up a car in full autonomy, when desired, for the desired time, and in self-service mode.

A further object of the present invention is to provide a process and a system that allow to identify exactly and substantially instantaneously, with extremely simple and easily adaptable hardware and software means, specific areas, such as for example city areas or provincial, state or motorway roads. , and to associate them with speed limits actually imposed on each single stretch of the planned route.

Another object of the present invention is that of realizing a similar procedure and system able to immediately detect any infringement and send in real time to the competent authorities the notification of the infringement, with the name of the driver and all the data recorded during the journey.

A further object of the present invention is to provide a similar process and system susceptible of easy further improvements, providing for the integration of a minimum number of additional hardware components capable of further contributing to saving lives, in particular by detecting the presence of alcohol or of drugs in the driver's breath.

A further object of the present invention is to provide a process and a system suitable, where desired, to limit the speed or even stop the vehicle, under the control of specific rules, perhaps still to be established, governing these faculties in its modalities. applications.

Not least object of the present invention is to provide a system or device, for carrying out the inventive process, which can be easily mounted on a car or truck, or other commercial vehicle and connected to the electronic control unit of such vehicles which it includes an extremely small number of component parts, is extremely reliable in operation, requires almost no maintenance and can be manufactured by the industry at a competitive cost.

According to an aspect of the present invention, the aforementioned aim and objects, as well as other objects, which will become more evident hereinafter, are achieved by a method and by a management and control system of single vehicles, in particular of single motor vehicles. , trucks and buses included in respective fleets according to the appended claims.

Further characteristics and advantages of the inventive method and system or device will become clearer hereinafter from the following detailed description of embodiments of the invention, illustrated, by way of non-limiting example, in the accompanying drawings in which:

Fig. 1 is a schematic diagram, in block form, of a management and control system or device that can be installed "on-board" on the vehicle, operatively connected to an integrated remote control unit, including, preferably, operatively

coupled, a central server or database, an operations center and an administrative center;

Fig. 2 illustrates a schematic front view of the on-board device of the present invention, which can be installed on cars, trucks and / or buses, and can be interfaced with the driver of such motor vehicles;

Fig. 3 is a perspective view of Fig. 2, showing the connections, for example lateral, for connecting the on-board device according to the invention to the control unit of said motor vehicle;

Fig. 4 is a schematic view of a smart-card, or user intelligent card specifically provided for the activation of the on-board device of Fig. 2 and 3;

Fig. 5 is a schematic block diagram of the internal circuitry of the on-board device of Figs. 2 and 3;

Fig. 6 is a front view of an interfacing device, or so-called totem, for interfacing with the user for the execution of a plurality of user functions, as will be described in more detail below;

Fig. 8 is a perspective view of the onboard device according to the present invention mounted on a car, for example electric, of a fleet of similar cars in car sharing managed and controlled by the method and the management and control system according to the present invention;

Fig. 9 is a further perspective view, similar to Fig. 8, schematically illustrating the onboard device mounted on a truck;

Fig. 10 illustrates a first embodiment or configuration of software modules included in the inventive system, installed on a single machine which therefore operates as a single server for the collection, recording, display of data, management of car rental in car sharing and of single trucks and / or buses;

Fig. 11 illustrates a view similar to Fig. 10, representing a second possible configuration of the software modules, in which it is possible to provide a variable number of customer stations with the Viewer module and the renting or rental module, in which , specifically, the communication between the server and the customer takes place over TCP connections, so the server can be located separately from the customers both in the customer's structure and in the case of an external structure, this possibility allowing the activation of the system even in cases where the customer does not have access to an adequate internet line for receiving data from all UTR devices;

Fig. 12 is a schematic block diagram illustrating the main macroblocks of the device or system according to the present invention;

Fig. 13 is a further representation of possible power control and regulation configurations for the inventive system;

Fig. 14 represents a further schematic block configuration of keyboard possibilities, power supply, backlighting lights of LCD panels, user guests, as well as communication systems;

Fig. 15 is a further possible scheme of a microcontroller included in the inventive system;

Fig. 16 the further luster of photo-input, analog input and analog output for the inventive system;

Fig. 17 illustrates further possible circuit configurations of digital input, power output, and relay output of the inventive system;

Fig. 18 illustrates a possible, partially with discrete components and partially with integrated components, of an RFID reader constituting a basic component of the inventive system;

Fig. 19 illustrates a further, partially with discrete components and partially with integrated components, of the GSM complex included in the inventive system;

Fig. 20 illustrates yet another cultural configuration, partially screened and partially integrated, of a GPRS complex included in the inventive system;

Fig. 21 illustrates a further design configuration relating to the assembly of a single GPS module; And

Fig. 22 illustrates still further, partially integrated and partially discrete, for the backlight assembly of the LCD panels of the inventive system.

With specific reference now to the aforementioned drawings, the invention will be described with reference to two currently preferred embodiments thereof, which however must not be considered in a limiting sense and, in particular, both exemplifying the method and the management device or system. and control of single vehicles, in particular of single cars, trucks and buses of respective fleets of any size, importance and destination.

With reference to Fig. 1, the inventive device or system comprises an on-board device, generally indicated by the reference number 1 operatively interconnected, preferably, with a central server or database 2, in turn operatively bi-directionally interconnected with a central operating preferably 3 and also operatively interconnected bidirectionally, with an administrative center.

Of course, the aforementioned links will preferably be implemented in a "" way.

As can be seen, the central server or database 2, the operations center 3 and the administrative center 4 are included, preferably but not necessarily, in an integrated remote control unit.

In this regard, however, it is also possible to install the administrative center in a remote position with respect to the operations center, for example in the administrative buildings of the company managing the inventive system.

Naturally, the on-board device 1 will also be installed remotely by the aforementioned units 2, 3, 4, ie on the desired vehicle, to move with it.

In Fig. 1, the on-board device 1 comprises, as in a single box-like housing 5, a display assembly 6, for example of the LCD type with touch screen, or any other suitable type, having, on its front face, that is the one facing the driver of the vehicle, at least one slot 7, a set of buttons 8, optional, and a set of warning lights 9, for example with LEDs.

According to an important aspect of the present invention, the inventive system includes a Smart Card or Intelligent Card which, in Fig. 4 has been generally indicated by the reference number 8, and which constitutes the user card, in which they are stored, preferably permanently, all data relating to the specific user or driver.

The smart card 8 is in particular foreseen to be inserted in the slot 7 of the on-board device 1, to activate the functions of the system and of the inventive process.

Fig. 5 illustrates a general block diagram of the on-board device 1.

This device comprises an on-board computer 10, a set of electronic cards 11, interfaced with said computer 10, in a per se known way, the cards being specifically designed for GPS, voice / data connection, connection to the electronic control unit of the car or truck (not shown), for battery charge control, speed limitation and other functions.

The device 1 further comprises a set of GPS and GPRS and / or RFID antennas, 12, an LCD display, also preferably of the "touch screen" type 13, an acoustic unit 14, preferably a hands-free speaker between user and central, as well as a set of warning lights 14, preferably including at least one green LED and one red LED (to indicate whether the car is free, reserved or with a flat battery).

According to the present invention, the onboard device has been specifically designed to perform the following functions: 1) recognize the user by reading the card through a special device (RFID antenna) or inserting the reader; 2) top up the credit via virtual pos in which, for the top-up operation, after the user has been recognized, the credit still held by the user appears on the display 13 and the question whether he wishes to top up. If the choice is yes, the computer 10 connects, for example via the Internet, to the reserved area of the company website to be redirected to a protected page of the bank and the user can make the payment by providing the data on the credit card; B) enable the car to drive; 4) set a destination and navigate; 5) allow the user to park the car while keeping it occupied or leave it permanently available to other users; 6) manage the fare pricing, by withdrawing the amount from the preloaded sum; 7) monitor the state of charge of the batteries and warn the user and the operations center when it is time to go to a car park to change the car. For this purpose, the operations center 3 will be able to guide the user to the nearest car park that has a car available. The navigator can also provide the same functions; 8) limit the speed in certain areas, identified by the control or operational center 3, such as historic centers, pedestrian areas, parks and gardens, hospitals, cemeteries and fairs, private areas, but, in particular, for trucks and buses, also municipal, provincial and state roads and highways; 9) send, in particular for trucks and / or buses, the notification of exceeding certain parameters such as permitted speed, driving times or the concentration of finished substances to the system server; 10) to provide a list of destinations as points of tourist, commercial, cultural or sporting interest in a city; 11) provide a list of tourist tours, food and wine tours or shopping routes; and advantageously 12) present advertising banners on the display 6. Touching the banner allows the navigator to lead the user to the business shop that has inserted the advertisement, this possibility advantageously allowing to make the rental of the machine even more profitable; 13) present and scroll through communications and messages sent by the operations center 3; 14) present and scroll the info-mobility messages, such as coming from the public administration or other similar bodies; 15) to present, in particular for trucks and / or buses, messages for the drivers of such trucks and buses in the event they are about to commit an infringement relating to speeding, driving under the influence of alcohol, or under the influence of drugs; 16) speak hands-free with the operations center 3 and, moreover, in a particularly advantageous way, surf the internet.

Advantageously, the aforementioned points 8) to 15) can be managed and modified from the aforementioned operations center 3.

Thus, the on-board device 1 communicates directly and is strictly connected with the central server 2 of the system, with the operations center 3 and with the administrative center 4, which are able to perform various functions, which can be grouped, as an indication but not limited to, in the following management areas: lA) data and customer management; 2 A) price lists management; 3A) management of fleets and individual cars with maintenance card; 4A) management of reservations; 5A) management of tourist and institutional sites, 6A) management of tourist areas and tours; 7 A) management of advertising banners and messages; 8A) management of the travel archives of trucks and buses; 9A) management of infringements.

The central server 2, or database, is, specifically, a computer containing software capable of: 1B) receiving connections from remote telemetry units and user software modules; 2B) record all the telemetry data received in the database; 3B) view the data on cartographic support and interact with the operator to query the information; 4B) automatically send proof of infringements to the competent authorities and to the individual transport companies for notification or information; and 5B) periodically send the travel data to the transport companies that own the fleet.

With regard to the operations center 3, the tasks assigned to it will advantageously be the following: i) vehicle tracking and flow recovery; 2C) control of the position of all vehicles; 3C) calculation of usage times; 4C) historical recording of all data; 5C) activation for use of the vehicle; 6C) interconnection to info-mobility systems; 7 C) making voice calls to the driver of the vehicle; 8C) immediate detection of an emergency signal from a vehicle; 9c) immediate detection of any impact report; 10C) search for all the vehicles present within a certain distance from a point indicated on the map, indicating the status of the green or red LED; and also, advantageously, Ile) transmission of messages (info-mobility messages, road directions, service order, warnings) both to a specific vehicle and to all vehicles at the same time; 12C) signaling to the user that the battery charge is running out, so as to drive this user to the nearest parking lot to replace the car; 1BC) locking of the vehicle in case of improper use after having warned the user with voice connection; 14C) management of the vehicle fleet or fleet with control of the vehicles available, in use and recharging; 15C) optional booking of the car, with insertion of the personal details of the booking party; LED change from green to red; 16C) definition of specific areas with imitation of speed or access to city areas; 17C) automatic signaling in the presence of particular events such as for example a vehicle leaving a predefined perimeter or route and, specifically for trucks and buses, maximum speed exceeded, driving time exceeded, driving under the influence of alcohol drugs and so on.

With regard to the administrative center 4, it has been specifically designed to be preferably installed in the offices of the management company, and being able to preferably, but not exclusively, perform the following functions: 1D) insertion of customer data; 2D) insertion of customer payments; 3D) reading of the same information available for the operations center 3; 4D) management of price lists; 5D) customer administration management such as traffic report, internet browsing action report, card recharge collections, invoicing, reporting; 6D) invoicing by mail or post to customers; 7D) registration of monuments, tourist, commercial or institutional sites with insertion of texts, photos, addresses and other info; 8D) definition of tourist, food and wine, or night clubs by linking together the records of the sites of interest loaded, in which operation the navigator will lead the user along the entire chosen path; 9D) interconnection with other operational systems to guarantee the use of the service to subscribers and other car sharing or transport companies, such as railways, municipal transport companies, etc. ; 10D) management of advertising banners; 11D) management of banners for the presentation of cultural, sporting and social events organized by the municipality; and 12D) touching the banner relating to a cultural event or a advertised exercise by activating the navigation function for the guided tour to the selected events, the banner being advantageously sent by the operating center to each on-board device via GPRS.

With reference to Fig. 6, a device, so-called totem, will now be described, generally indicated by the reference letter T, which has been specifically designed, according to a further peculiarity of the invention, to facilitate registration as much as possible. to the car sharing service, allowing the citizen or other foreigner to subscribe, immediately and without the need for human intervention, 24 hours a day, 365 days a year, in a plurality of places chosen from those with the greatest number of visitors, airports , stations, subways, squares, towns etc. The totem T is advantageously designed to have IP 67 protection to allow outdoor positioning and is equipped with a high illumination screen or touch screen, generally indicated by the reference number 16, to be visible even in full sun.

This totem basically represents a "virtual office" that emulates the functions of a real office, and is therefore able to subscribe new users in an automated way.

Totem T is also designed for the issuance of other smart cards, in particular as the so-called electronic tickets are provided, ie electronic travel tickets valid for local public transport companies and railways.

In anticipation of the diffusion of these electronic tickets, which should guarantee the interoperability of the various means of transport, freeing the traveler from the need to have many different tickets but, on the contrary, use a single smart card.

Thus, the totem has also been specifically designed to allow the user to pay to a single entity, and for this purpose the microchip of the user card will recognize the user and the trips he makes on various circuits, thus registering a database that therefore, it allows the computer system to periodically issue the prospectus and report on the accounts for the crediting of the fees pertaining to the individual transport companies. However, since various transport companies are stored on the microchip of the user card, as an alternative it is possible to credit the amount that the user has uploaded directly to a specific company.

This option has the advantage of avoiding returns and end-of-month adjustments between the various operators and allows the user to have a single card to travel on all rail - road modes, but has the disadvantage that it requires the user to make as many top-ups as there are operators.

In particular, the totem was also specifically designed to perform the following functions 1E): to present basic information on the characteristics of the service on its 16, LCD touch screen, the same as those present on the service website; 2E) alternatively, provide internet connections to connect to the car sharing company's website; 3E) allow the immediate registration of new subscribers through the following functions: 3.1E the driving license, for example introduced in slot 17 of the totem, and register the new subscriber in the computer archive; 3.2E enter personal data of the new subscriber from the keyboard 18 on the touch screen display; 3.3E enter data relating to the credit card, to be kept as a guarantee in case of accidents; 3.4 And insert the email for shipment, contract, invoice, communication etc. ; 3.5E accept the contractual clauses by keyboard confirmation; 3.6E insert the pin on the smart card, and store its number in the database; 3.7E issue the service subscription card, with the user's name printed; 3.8E assign the pin that allows the new subscriber to access the reserved area of the website; 3.9E transmission of all these data to the database residing on the server; 4E) connect to the site to allow the user to top up his credit, even if it would be preferable to do so from the edge of the car to avoid queues at the totem pole; 5E) speak with the operations center 3 to obtain assistance with registration; 6E) to allow the issuance of other smart cards, ie so-called electronic tickets, for example through an additional slot 19, ie electronic travel tickets valid for local public transport companies and railways.

Thus, from the foregoing it will be clear to the expert in the field that the inventive operating model clearly differs from that of the other car sharing companies so as to eliminate all the causes that have hitherto limited the diffusion of this system and negatively affected the results. budget. Briefly, and summarizing, the characterizing points of the process and of the inventive system are subscription modalities, including automated ones, with emission totems T placed in points of great influx; no subscription fee for the service; payment of the rental preferably only based on the time of use and not on the kilometers traveled; no obligation to book, you can see the car free on the public road and you can take it immediately; payment via pos vi rtual on the totem or on the on-board computer; freedom of parking; freedom to leave the car on a parking lot other than the one where the car was taken; car parks located in the open, on the public road, widespread in the points of greatest affluence of the public; airports, railway stations, port terminals, subways, main city squares etc; availability of tourist guide navigation, inclusion of tourist, food and wine tours, shopping, georeferenced institutional and cultural points of interest; software that automatically warns the user of the need to change cars due to battery exhaustion, with a second level of guard through the intervention of an operator of the operations center; credit granted to the user which allows him to finish the ride even when the prepaid credit is exhausted; only one or two car models for the fleet, so as to optimize the formats for advertising decorations on the bodywork, advertising thus becoming a fundamental source of revenue, useful for reducing the rental cost and thus allowing access to the service to a larger number of citizens; software for inserting advertising banners on the navigator screen; software allowing to transmit audio or video info-mobility messages on the navigator; and, last but not least, software designed for the recognition of subscribers and other car sharing circuits and authorization to use the car, as well as accounting for periodic debits or credits with other operators.

For the management of the fleets of trucks and buses, the inventive procedure and system allows to identify and map exactly specific areas, such as for example city areas or provincial, state or motorway roads, and associate to them the speed limits actually imposed on each individual. treatment.

The system is therefore able to immediately detect any infringement and send the infringement report in real time to the competent authorities, showing the name of the driver and all the data recorded during the journey.

To complete, and as an appendix, a further detailed description is attached hereafter, supporting the intense studies of the Applicant to arrive at the inventive process and system previously described, which detailed description is herein specifically related to the software aspect of the 'invention.

However, the Applicant believes that this detailed description, in the light of the enclosed circuit diagrams, is more than sufficient to allow the person skilled in the art to implement the invention, also in the hardware aspect, in the light of the previous teachings and with habitual adaptation. routine.

APPENDIX

For the development of the software, the protocols of type 0 (fleets of cars in car sharing) and type 1 (fleets of trucks and buses) and, correspondingly, of type 0 and type 1 devices were considered.

Among the main features of the MuxHub the following should be mentioned:

â € ¢ management of the communication protocol with the devices and the Viewer module and recording of the exchanged strings;

»Recording of the routes taken by the devices, times of departure, stop and arrival.

â € ¢ management of user authentication, calculation and registration of residual credit and transmission of the same to the device (residual credit not applicable in type 1 devices)

â € ¢ verification of the presence of the device inside the configured areas;

â € ¢ management of exceeding certain parameters (speed, driving times, concentration of certain substances); and recording of error logs;

â € ¢ management of travel extensions (only for type 0 devices);

â € ¢ management of penalties (only for type 0 devices); â € ¢ management of device disconnections and reconnections.

The module is implemented in C # for .NET 2.0.

2. Fundamental concepts

Racing and credits

Any number of devices, even of different types, can be connected to the MuxHub at any given time. Furthermore, several instances of the same module can be running, at a given moment, on different servers, and each device stacks) choose to connect to a certain server or to another, in particular, a presence-based architecture is recommended of at least two MuxHub instances running at the same time (see below, in the "Connections and disconnections" section).

Each device introduces itself to the MuxHub establishing a TCP connection and sending a string of type "AO" (see below for details on the protocol) with the specification of the type and number of the device, any other string (not of type "AO" ) sent at the beginning of the session is considered wrong by the MuxHub, and therefore discarded.

The sending of the "AO" type string is obtained, on vehicles, by turning the dashboard key.

After the presentation of the device, in the type 0 and 1 protocols, authentication can take place and the start of the run, in these cases, each user is assigned a card. In the type 0 protocol the card can be loaded again: it is an RFID tag to which a code is associated, and a prepaid credit is associated with the code from which the cost of the trips is deducted in real time. A credit line associated with a single customer is defined; if this is nil, it is instead considered a generic default credit line. The authentication request by a device is signaled to the MuxHub with a string of type "A15". The string of type "A15" contains the indication of the RFID code acquired by the reader on board the device; MuxHub associates this code to the customer and to the remaining credit, accessing information contained in the PostgreSQL database. the MuxHub then responds to the string of type "A15" communicating the outcome of the authentication and the residual credit associated with the card, in this authentication process, MuxHub recognizes any anomalous situations, which determine the authentication failure (and the impossibility of part of the customer to start the ride):

â € ¢ card blocked or not enabled;

â € ¢ user not enabled;

â € ¢ residual credit below zero (considering the overdraft);

â € ¢ vehicle "extended" by another card (see below).

in case of positive authentication, the device allows the customer to actually start the run, which is signaled to the MuxHub with a string of type "Al9".

At the time of the start of the race, an activation fee is charged from the remaining credit of the card; however, a card can be set as "exempt" from activation, in which case the cost is not charged.

Again in type 0 and 1 protocols, the end of a run is instead signaled with a string of type "Al 7".

Inside the race, that is, in the period between an "Al9" signal and an "A17" type signal, the cost of the trip is counted, which is deducted at regular intervals, according to a price list registered on the database, by credit associated with the customer's card. Status and position messages

The device can send "Al 2" type strings containing information on the current position, with a periodicity depending on the speed and the variation of the forward direction; it can also periodically send "All" type strings, containing information on the current state of the vehicle.

The MuxHub checks, each time it receives a string of type "Al 2", if the device is in one of the configured areas (for example: parking lots, forbidden areas, limited speed areas, areas outside the maximum allowed perimeter, highways, state or municipal roads) and notifies the device itself (see section 8).

In protocols of type 0 and 1, the strings of type "All" and "Al 2" are sent both during the runs (ie between a string of type "Al9" and a string of type "Al7"), and beyond out of the races.

The strings of type "All" are instead present in general, in all three protocols.

Events

The system manages, for devices of type 0 and 1, the occurrence of "events", that is "anomalous" or "suspended" situations, which should, under normal conditions, persist only for a limited time, i.e. up to a instant defined as the "expiration" of the event, an event that has not been "closed" before its expiry is considered expired, and generates a penalty which is deducted from the credit of the card concerned, at the time of the subsequent authentication of the card. If an event is "closed" before its expiration, it does not generate penalties.

Examples of events are: for the type 0 protocol, travel extensions (type 6 events), failure to connect a vehicle's battery charger (type 3 events), failure to return to parking (type 4 events); for the type 1 protocol, the duration of a run exceeding the maximum allowed duration, rest time not respected, exceeding the allowed speed, exceeding the concentration parameters for some substances.

Events are logged on the database. Each event has a creation date / time and an "expiration" date / time, which is calculated by adding a time to the creation date / time that depends only on the type of event.

Extensions

Extensions are special events defined only for type 0 devices.

At the end of a run by a vehicle (ie to a string of type "Al7"), it can be "extended" on request. In this case, the customer "locks" the vehicle for a number of hours (confi gurable from the database), and at the subsequent authentication only the card that carried out the extension will be authenticated; the period elapsed between the extension and the subsequent authentication will be counted for the purposes of the credit, according to the usual price list.

The extension (type 6 event) is "closed" when the person who has extended the use of a vehicle authenticates again on the vehicle, before the event has expired, in this case of authentication the activation cost is not charged.

If a vehicle is not extended at the end of the journey, the MuxHub checks if it has arrived from the vehicle, with an "All" type string, notification of the connection of the charger cable, and, with an "Al2 type string. ", The notification of the presence of the vehicle in a parking lot: each failure to notify automatically causes the generation of an event, respectively of type 3 (charger cable not connected) and 4 (return not in parking).

The type 3 event is closed when the MuxHub receives a string of type "Al 1" which notifies the successful connection of the cable, while the type 4 event is closed when the MuxHub receives a string of type "Al 2" which notifies the entry of the vehicle into the parking lot.

The response of the MuxHub to a string of type "AO" contains the indication whether the vehicle is currently extended or booked; in the event of a reservation, the vehicle automatically performs an authentication request ("A15"), a start of the journey ("A19") and immediately ends the journey ("Al7") requesting an extension.

Connections and disconnections

During a ride, the connection of a device to the MuxHub always remains active, except in abnormal conditions (for example, lack of GPRS signal coverage).

In the devices on board vehicles (type 0), outside the run, the device switches off automatically after a certain number of minutes of inactivity, and subsequently, after a certain pre-established time, it switches on again automatically, sending to the MuxHub an "AO" string and an "Al2" string. When the connection drops due to lack of GPRS coverage, the device attempts to reestablish the connection by repeatedly sending an "AO" string and an "Al 2" string, until a response is received from the MuxHub. Again in this case, in parallel, the device manages a "local authentication" (accepting only the last card used on the vehicle) in order to allow an emergency trip to move to an area covered by the GPRS signal. The strings possibly buffered by the device during the disconnection period ("All", "Al 2" and possibly "Al7") are sent to the MuxHub in a single packet, after the reconnection. The MuxHub manages these signals sent "deferred", reloading the status of the run that was left open and interrupted.

In type 0 and 1 devices, the MuxHub ignores any "Al7" type strings that arrive after the run has already been completed and any "A15" type strings that arrive after the run has already started . Still in these types of devices, the sending of strings of type "Al9", on the other hand, is the responsibility of the device, in the sense that the MuxHub manages the receipt of a string of type "Al9" regardless of whether it was preceded by a string of type "Al5" and relative authentication; this in order to manage any disconnection cases that occur between an "A15" string and an "A19" string.

If an architecture has been set up that foresees the presence of two MuxHub rooms simultaneously running on different servers, the devices can be configured to attempt, in the first instance, to connect to the primary server, and, after a certain number of failures , to a secondary server. This precaution guarantees the continuity of the service in case of crash of the MuxHub module on one of the servers. By appropriately varying the logic of choosing the MuxHub server on the device side, it is also possible to obtain a load balancing effect on the server side.

3. Brief description of the code

Below is a brief description of a technical nature on the architecture of the MuxHub module and on the structure of the source code.

As already mentioned, the architecture implements a dynamically loaded plugin mechanism, each of which contains the implementation of a specific protocol or transmission mechanism.

Runner (main class)

The main method. cs of the Program class looks for a MuxHub file. xml and, if it finds it, it loads from it some settings necessary for the execution of the program; if it doesn't find it, it generates it using the hardwired settings in the code.

It then launches the Main method of the Runner class (if the program was launched from the command line with the "service" option, it is launched as a service, otherwise it is not a service). The Mairi method of the Runner class is the starting point of the MuxHub module.

It loads the PostgresDB.dii assembly as a plugin, gets the types defined in it and their constructors.

It then creates two instances of the NewConnectionHandler delegate of the ConnectionsListener class, pointing to the NewVehicleConnection and NewViewerConnection methods of the Runner class as their respective parameters.

While instantiating the delegate, the Main method also instantiates two objects (tcpsln and tcpsOut) of the same ConnectionsListener class, to which it passes the numbers of the respective ports used (taken from the settings) and the references to the newly created delegate instances.

in this way the constructor of the ConnectionsListener class is invoked, which creates the neh event, assigning it the instances of the delegates passed as parameters, initializes the respective ports used by the StartListen method of the ConnectionsListener class and starts the threads with the same Stamisten method. This method listens on all IP addresses and the specified port and accepts connections from Clients by creating the corresponding socket and raising the neh event when a Client connection is detected.

in this way the NewVehideConnection and NewViewerConnection methods, referenced by the NewConnectionHandler delegate, are executed respectively when the event is raised, that is, when a device or a Viewer instance establishes a connection to the MuxHub.

Finally, the Mairi method starts a thread for updating subscribers and starts the web server module.

Connect with the Viewer

the NewviewerConnection method, which is executed when a new connection is detected by a Viewer instance, loads the viewerSTD.dll plugin.

The plugin manages a series of delegates (Disconnected viewerEventHandler,

DataRequestEventHandler, SendToVehicleEventHandler, AuthenticateUserEventHandler, ResetAlarmEventHandler) to which the management methods OnDisconnectviewer, OnDataRequest, OnSendToVehicles, On-AuthenticateUser, OnResetAlarm that actually carry out the management of the module Mux ViewHandler are subscribed.

the subscribers update thread (connected Viewer modules) continuously checks (through the VehiclesReceiver CollectDiff method) if something has changed in the attributes of the devices compared to the previous update of the Viewer instances. To do this, an internal XML file (string innerXML) is built starting from the data present in the device dictionary, containing only the changes that occurred after the last transmission to the Viewer instances; this XML string thus packaged is then sent to the Viewer module through the existing TCP connection.

Receiving strings from devices

The NewVehicleConnection method, which is executed when a new connection is detected by a device, allocates it to an object of the vehiclesReceiver class, which inherits, in cascade, from the AsyncReceiver and QnetStream classes, which manage the asynchronous reception of strings.

in particular, the OnReceiveData method of AsyncRecei -ver is executed when a new string is detected in reception; this method calls the vehiclesReceiver ProcessString method, which in turn handles the parsing of the received string.

The ProcessString method performs the following operations: 1. divides the string into parts based on the vi roligator separator;

2. if the string is made up of less than two parts, it signals a reception error ("invalid packet...");

3. if the string does not begin with "AO" and an object of type Vehicle has not yet been instantiated, it signals a receipt error ("unknown vehicle");

4. if there is no ('vehicle object but the string begins with "AO", then consult the dictionary of the devices present in the memory using the vehicle ID: if the device is already present then a new one is allocated Vehicle type object with the attributes taken from the dictionary, otherwise the object is instantiated using the attributes taken from an XML file and the dictionary is updated in memory; in any case the vr attribute of the new object is set with a reference to the object Current VehiclesReceiver;

5. Now that an object of the Vehicle class exists, the string is processed by the Process method of the same class.

The Process method manages the processing of the string sent by the device, and returns a response string. To do this, it uses a Swatch instruction that selects the type of string and for each type invokes the corresponding method that will handle the specific case by generating the response string (see below, in the sections dedicated to the specific types of managed strings).

4. Interface with the Viewer module

The MuxHub module allows the connection of cartographic viewers (Viewers) that connect via TCP to port (confi gurable) 4568.

the protocol used is based on structured XML messages containing a list of only the vehicles for which some data has changed compared to the previous transmission, and only the data that have changed inside.

Viewers connect by initially exchanging handshaking, authentication, and configuration strings. a configuration file contains the list of fleets with their fleet identifier and the list of users for each fleet with their password.

MuxHub and Viewer are designed to exchange XML messages in compressed form using a library that specializes the Stream class.

Currently the Viewer module can send commands to single vehicles or to the entire fleet by means of strings preceded by the target vehicle ID.

The Viewer module deals with the visualization of the fleet with indication of the position and status of each vehicle. The visualization is based on a georeferenced cartography which is used as a support for tracking the positions and routes of the vehicles.

The functions of this module are aimed at the technical and logistical management of the fleet, not at the administrative functions which are instead managed through a specific web application. The only features of this type to be implemented on the Viewer module are the display of the code of the user who is using the vehicle and the list of reservations for a vehicle.

5. Web server

There is a class that implements a simple web server, used to allow both an HTTP monitoring of vehicle activities, and to list and download the recordings of the journeys made by each vehicle.

6. Interface with the database

The MuxHub module accesses a PostgreSQL database with PostGlS extension, in which there are different types of data necessary for fleet management.

There is a web administration interface that allows the consultation and modification of the data in the database.

Below is a complete list of the 45 tables present.

areas

vehicle areas

Î “3 drivers

Î card

: 1 catd_ci editi

; j <"> j card jdjjid

t Î “j customers

Φ f% clientsjrard

/; dientijatturazìone

3⁄4! \ 3 clients i_social_reasons

3⁄4 i] credits

F <51> credits_operations

t i j events

* Î “1 fleet

<;> Î “3 user_fleets

:] geometryjrolumns

YES Î ̄ ή implants

ÃŒS Î “3 plants _placed

t <* ""> Ï ‹itmeraries

3⁄4 â – ¡itinsrarìes_sites

3⁄4! Î “3 listjingue

iti v: ì listjivello

i + i Î “9 listJtype_areas

i + i Fi listjd views

t Î "3

3⁄4 ±] <â € ™> l * Jido price lists

iti Î “3 lBtinì_km

t '<"> 1 ììstini_status

t) <'> the Jernpo price lists

you <"> the nations

you <;> 3 reservations

3⁄4 F3 appearances

® f <â €> j social_reasons

ti FI sitejcategories

yes Pâ € j 3⁄4tes

ti H spatìal_ref_sys

"H tag

3⁄4 P3 times

3⁄4 i l! users

<â € ¢> 1 Î “3 vehiclejnaintenance

3⁄4 f3 vehicles

ti Î “3 vehicles_corse

i + i Î “3 vehicles_status

S Î “3 vocabulary

The information in the tables is about

fleets and vehicles, registered customers, cards and credits,

social networks and price lists, events and extensions,

tuate, configured areas, points of interest and itineraries,

reservations, configured times, defined languages and vocabulary-

rio of messages in language, etc.

Connections to the database are handled by the methods of the PostgresDB class; these are in turn invoked by the methods of the Vehicle class in charge of managing the different types of strings sent by the device.

The string management method of type "AO" (see below) allocates to an object of the PostgresDB class (the constructor of this class creates an object of the Settings class whose static attributes are the database connection parameters).

Below are listed some of the tables present, and the way in which the data present in them are modified by the MuxHub for the different protocols accepted.

Areas

The areas table is populated with the records corresponding to the areas defined on the territory. The areas can be of various types, for example: maximum perimeter of use, parking, prohibited area, restricted speed area, highways, ring roads, expressways, state roads, municipal roads.

The definition and insertion of the areas is possible through the Viewer module, while the control of the presence of a device in one of the defined areas is performed by the checkzones method of the PostgresDB class of the MuxHub, each time a position string is received (see beyond) . The vehicle areas table records the count of devices (running and not running) present in each of the defined areas. The counters are updated by the updatecount stored procedure, which is run periodically and which is based on the position (latitude and longitude) and status (running or not running) data present, for each device, in the vehicle_status table (see below ).

Customers, cards and credits

The customer table is populated with the customer master data defined in the system. When entering a new customer through the web interface, a card and a company name can be associated with the new customer. The personal data of cards and company names are contained respectively in the card and company name tables, while the customer card and company name tables play a role in the interconnection tables.

Each card relating to type 0 protocols is associated with a reference "credit", in the sense that more than one card can, in theory, be associated with the same credit. The credit information is present in the credit table, while the interconnection is managed by the credit card table.

finally, a "short" progressive number is associated with each card, replacing the complete code of the card; the associations between cards and short progressives are recorded in 1 a table 1 a card id uid.

Some methods of the PostgresDB class perform readings on the data of the tables just mentioned, in particular: at each operation on a credit the getRagSoc and getldCredit methods are invoked, which return, respectively, the company name given the customer and the ID of the credit given the code of the card; at the time of the authentication request presented by a device (string of type "A15", see below), the isEnableUser and isEnableCard methods are invoked, which check, respectively, if a user is and if a card is enabled and not blocked; at the start of a ride, the I-sFreeCard method is invoked, which verifies whether a card is exempt from the cost of activation or not; for type 0 protocols, at each presentation of the device (string of type "AO", see below), the getLastRun method is invoked, which checks if there is a run still open and associated with a device; each time the tracking file is saved (see section 7) the getcarduid method is executed to retrieve the short progressive number of a card; finally, the Getllser method returns the user starting from the card code, and is called by the CheckCustomer method, in turn invoked upon receipt of an authentication request, at the beginning of a run and, for type 0 protocols, the presentation of a device that reconnects after a period of disconnection (see "Connections and disconnections" in section 2).

Credit transactions

The table of credits operations accounts en and all the operations performed on the credits present in the credit registry.

in each phase of the journey that involves an operation on the credit of a card (activation, completion of the journey, application of a penalty, etc.), a new record is inserted in the table and the credit record is updated in the credits table in question. The first of these operations is performed by the insertOperation method of the PostgresDB class, while the update of the credit table is performed by the SaveCredit method of the same class.

The getCardCredit method reads the current credit of a card, and is invoked every time it is necessary to know the current credit for a possible subsequent modification, finally, the getldCredit method returns the iD of the credit given the card, and is invoked at each operation performed on a credit.

Events

The events table contains all the events generated in correspondence with "anomalous" or "suspended" situations, which, normally, should persist for a limited time, that is up to an instant defined as the "expiration" of the event (see "Events "in section 2).

Several methods of the PostgresDB class perform read or write operations on this table. In particular: the getExtVehicle method is invoked, for type 0 protocols, at the presentation of a device and at the authentication request, and verifies if the device is in the extension phase; the CreateEvent method is invoked at the end of a run in the event of anomalous situations (extension, return not parked, failure to connect the battery charger, etc.) and creates the corresponding event; the CheckExpiredEvents method, invoked at the authentication request of a device, finds the events that have already expired associated with a card, manages them by deducting the credit, ie by applying the corresponding penalties and closing them using the CloseExpiredEvent method; the CloseNonExpiredEvent method is executed in all cases in which it is necessary to close an event that has not yet expired, because the anomalous condition has ceased; finally, the getEventDuration method is invoked at the end of a run and returns the time elapsed since the start of an event, in order to calculate the associated cost.

7. File management

The MuxHub module manages some files that are generated and modified during system operation. The files managed and the methods for managing them are described below.

Vehicle tracking file

The device enabled to transmit its position periodically sends this information through a string of type "Al 2", combining it with the exact time detected by the GPS. This information is recorded for historical use in a localization file, which is managed by the Save Track method of the vehicle class. In particular, the method writes the current time and the new coordinates to the file, only if these have changed from the previous ones.

the file is of type .txt and is saved in a directory whose name depends on the fleet code and the date (... <fi octa code> NYYYMMDD /). Inside the file, the lines are saved in the following format:

<Server date / time>, <GPS date / time>, Longitude, Latitude

The date / time of the GPS to that which is then considered for the purpose of displaying on the Viewer.

The information captured during the ride of a vehicle (ie between two strings A15 and Al7) is saved in a text file whose name and <vehicle ID> <short card ID> <ride ID> .txt.

Any movement of the vehicle outside the session of use is recorded in another file, the name of which will be <vehicle ID>. txt.

Historical file of the strings exchanged

The SaveHistory method of the Vehicle class manages a file containing information on all the strings exchanged between the device and MuxHub. For each string sent, in one direction or another, the information is recorded in the file and this is saved. Other types of information are also logged in this file (for example, the stop of the credit update timer).

Tag file

The SaveTags method of the Vehicle class, invoked in the case of Al8 signals, manages a file containing information about the tag (key code). This method is currently never invoked.

8. Device-MuxHub communication protocol

The MuxHub module allows 0 connection of devices via TCP connections on port (configurable) 4567 and with protocol defined for Eurochip TPS-100 cards based on CRLF-terminated strings.

The communication protocol between the devices and the MuxHub module is implemented, on the MuxHub side, through the management methods of the different types of string, belonging to the Vehicle class, which are described below.

Each string sent from the device to the MuxHub begins with a string of the type "An", where n is an integer that identifies 0 type of string sent. The strings sent by the MuxHub to the devices instead begin with strings of the type "Cn", where n is an integer that identifies the type of string sent; the only exception is constituted by the acknowledgments that the MuxHub sends to the devices to confirm the reception only of the "Ari" type strings, and which also begin with an "An" string (with the same n sent by device).

Each string sent by the device contains, among its fields, a handle generated by the device itself drawing from a progressive sequence; any string sent by the MuxHub as a response or as a consequence of that string will contain the same handle.

Strings sent from devices to the MuxHub

"AO" (Connection Login)

Syntax:

AO, <handle>, Device Type>, <Vehicle ID or Facility ID / Location ID>, <Renter ID>, <tag code>, <tel number> CR LF

Reply:

AO, <handle>, 00, <extra string>

The string of type "AO" signals to the MuxHub that a device has been activated, is connected to the server and is starting to work.

<devicetype »indicates the type of device (and protocol), as described in the introduction CO, 1).

<Vehicle ID> for vehicles (type 0 and 1), it is the identification code of the device on board the vehicle;

<Charterer ID> is the charterer or fleet code;

<tag code> is the serial number of the transponder that activated the device. The maximum length is 24 bytes, encoded in hexadecimal ASCII, ie the string "AA" corresponds to the hexadecimal number OxAA or 170 decimal. It is not mandatory (typically it is omitted, since it is sent with the authentication request).

<tel number> is the number of the SIM used to activate the GPRS connection. This number is required when emptying the voice call to the device. The maximum length of 15 characters, the number is sent exactly as read from the parameter list, without filling with "0" if the total number of characters is less than 15.

<extra string> is a string, sent in the MuxHub response, made up of key-value pairs, in the form chiavel = valorel & key2 = value2 &. . . . The following table describes the fields expected in the <extra string> string.

Parameter name Type Description

TIME date Date and time in YYYYMMddHHmmss format

MODE int Mode relating to the fleet (1 = Fiera di Milano, 2 = city map) RES string ID of the card that booked the device

EXT string ID of the card that extended the device

The TIME field communicates the current date and time to the device, for the purpose of synchronization between the server and the Client.

The MODE field communicates to the device the mode that it must activate, according to the fleet to which the device itself belongs.

The RES field communicates to the device the identification of the card that has possibly reserved the device. the EXT field communicates to the device the ID of the card that possibly extended the device.

The management method of this type of string instantiates an object of the PostgresDB class the constructor of this class creates an object of the Settings class whose static attributes are the database connection parameters) and recognizes the device using the getVehiclelnfo method of the same class ( this method queries the vehicles table from which it obtains information on the devices that are returned to the string management method "AO"). the management method also manages the loading of information relating to any run left open; this allows to manage the case of re-connection after a period of disconnection of the device, and allows to continue The run not finished, the loading mechanism of the suspended run uses the getLastRun method of the PostgresDB class: if the last run started by the device presented by the string "AO" has not been completed, it is assumed that the string indicates the resumption of such a trip, whose status (the particular ID of the trip, dates / times of the start of the trip, return credit -duo , customer) is then reloaded, the management method finally invokes the Save Track method of the vehicle class.

"A3" (Attention request)

Syntax:

A3, <handle> CR LF

Reply:

A3, <handle>, 00 CR LF

The type string "A3" sends the MuxHub a request for attention from the operations center. The management method of this type of string sets the HelpRequested attribute of the Vehicle class to true (currently not used) and returns the response string of type "A3".

"Al 1" (State)

Syntax:

All, <handle>, <time>, <status string> CR LF Response:

All, <handle>, 00 CR LF

The string of type "All" communicates the current state of the device to the MuxHub.

<time> represents the time the status was sent (the format to HHmmss).

<status string> is a string made up of key-value pairs, in the form chiavel = valorel & key2 = value2 &. . . . , with a format similar to encoding URL parameters.

Parameter name Type Description

VBATT Int Battery voltage in mV

ABATT Int Battery current in A

DIN1 int Status of digital input 1

DIN2 int Status of digital input 2

BCOL int Battery charger cable connection

The message is sent at the scheduled rate only if at least one value has changed and only the values changed with respect to the previous transmission are transmitted. For analog data, an interval of insensitivity to changes is considered (eg 100 mv on battery voltage). In case of sending in response to a string of type "eli", all the values included will be transmitted, even those not modified.

This type of string replaces the string "All", which is kept only for compatibility with Eurochip devices.

The management method of this type of string sets some attributes of the Vehicle class with the values passed with the string (VBATT, ABATT, DINl, DIN2, BCOL).

If the BCOL value is 1, that is, the battery charger cable has been connected (see Section 2), the battOK attribute of the Vehicle class is set and, if the run is finished, the eventual anomalous event related to failure to connect the battery charger cable. finally, the management method returns the response string of type "All"

"AI2" (Position)

Syntax:

A12, <handle>, <time>, <latitude>, <longitude>, <bearing>, <speed>, <altitude>, <extra location string> CR LF

Answers:

A12, <handle>, 00 CR LF

if required: C14, <delay>, <beep>, <beep interval>, <message> CR LF if required: C17, <limit enable>, <limit value> CR LF

The string Al2 communicates the current position of the device to the MuxHub.

<time> represents the time of the GPS fix (the format and HHmmss).

<latitude> and <longitude> represent the latitude and longitude values in degrees (nn.nnnnn); are float values encoded with Anglo-Saxon decimated separator (.). For these values the code has been modified to accept values in standard format and not in centesimal format; furthermore, the indicators of the cardinal points are not accepted.

<bearing> represents the direction in degrees (integer from 0 to 360).

<speed> represents the speed in kilometers per hour.

<altitude> represents the altitude in meters.

<extra location string> is a string made up of key-value pairs, in the form chiavel = valorel & key2 = value2 & with a format similar to the encoding of URL parameters.

The following table describes the fields provided in the <extra location string>.

Parameter name Type Description

NSAT int Number of satellites with which the HDOP fix was made int Accuracy of the horizontal fix in meters

VDOP int Accuracy of the vertical fix (altitude) in meters

CN int House number where the vehicle is located

RDN string Name of the street where the vehicle is located

The string of type "Al 2" is sent in any case at the expected cadence (variable based on various parameters, for example the speed, the variation of the hearing, etc.). This string replaces the string "A2", which is kept only for compatibility with Eurochip devices.

The management method of this type of string sets some attributes of the Vehicle class with the values passed with the string (time, latitude, longitude, bearing, speed, altitude, extralocationstring).

Subsequently, the method invokes a web Service for the reverse geo-coding of the coordinates received with the string of type "Al2", in order to obtain the address of the device in the GPSLocation variable.

The method now invokes the Save Track method of the Vehicle class.

Then the checkZones method of the 1st class PostgresDB is invoked, which checks the position with respect to the configured areas, in particular it is checked if the device is in a parking lot, in a forbidden area, in an area with limited speed , outside the permitted perimeter or on the road. If one of these conditions is true, an information message is sent to the device, through a string of type "014"; in particular, if the device has entered a car park, the parkOK attribute of the Vehicle class is set, and if the ride is over, any open event linked to the failure to return to the car park is closed; on the other hand, if the device is in an area with limited speed, a string of type "017" is sent to the vehicle which forces the speed limitation (currently set at 50 km per hour).

If, on the other hand, the device is on the road, the speed is checked in relation to the type of road and, if the speed is higher than the permitted one, a string is sent to the database.

finally, the management method returns the response string of type "Al 2".

â € œA13 "(Internal alarm condition)

Syntax:

A13, <handle>, <time>, <alarm code>, <alarm message> CR LF

Reply:

A13, <handle>, 00 CR LF

The "Al3" type string signals to the MuxHub the presence of alarm conditions detected by the hardware on board (for example battery anomaly, motor overheating, etc.).

<time> represents the time the problem was detected (the format is HHmmss).

<alarm code> is a unique alarm code (in the event of an alarm signal it is a positive integer value; any signaling of the end of an anomalous condition is communicated with the same fault code with a negative sign ).

<alarm message> is an optional text description of the alarm, thà ̈ pile) possibly also contain additional information to specify the problem (for example the engine temperature).

The number and type of possible alarms are not yet defined.

A string of type "Al3" transmits only one alarm: if there are more alarms at the same time, more messages are sent.

the management method of this type of string sets some attributes of the vehicle class with the values passed with the string (timeReq, errCode, errMsg). Then it returns the response string of type "A13".

"Al 5" (Authentication required)

Syntax:

A15, <handle>, <time>, <key>, <check> CR LF

Answers:

A15, <handle>, 00 CR LF

<handle>, <response>, <name>, <language>, <check response>, <extra string> CR LF

<handle>, <time>, <credit>, <check response> CR LF (only O in case of successful authentication)

The string of type "Al5" signals to the MuxHub the request of a customer to use the device; through this string the device transmits the RFID code acquired by the reader to the MuxHub.

<time> represents the time the key was read (the format is YYYYMMddHHmmss). <key> represents the serial number acquired by the reader.

<check> represents the randomly generated check code.

In the initial specifications of the protocol, an additional Extra String field was provided in the string "015", which is not, however, now generated.

the server must respond to an authentication request with:

* a string of type "A15" to confirm receipt of the request;

* a string of type "C15" to provide the authentication result;

«A string of type" C16 "to communicate the residual credit (only in the case of successful authentication).

(See below for the syntax of the "C15" and "C16" type responses)

Authentication can fail for the following reasons:

* existing user but disabled;

* user does not exist;

* existing user but insufficient credit (also considering any credit line);

* user not enabled because the vehicle is currently "extended" by another user (see string "A17").

In the case of credit below zero but covered by a credit line, the authentication will still have a positive outcome.

The receipt of the string of type "A15" does not mark the start of the run, but only the authentication request; it can be followed by a further string (of type "A19") by the device, only in the case of successful authentication, which will communicate the request by the customer to actually start the run.

The management method of this type of string verifies whether the authentication request has arrived after a reconnection following a disconnection period, or after a simple connection of the device. In the first case, it is verified whether the RFID code presented is the same that had interrupted the run previously, or another: if it is the same, the authentication request is useless and is ignored, while if it is different, the end of the current run (resumed after disconnection) is forced (by invoking the string management method of type "Al 7") and the new authentication is managed.

Subsequently, the management method recognizes the customer associated with the card requesting authentication, using the CheckCustomer method, which instantiates a new object of the User class and invokes the GetUser method of the PostgresDB class; this method queries the database and captures the properties of the selected customer in the attributes of the User object.

Then the method checks if the client and the card are enabled (checking the information on the database through the isEnableUser and isEnableCard methods of the PostgresDB class); otherwise, authentication fails.

Then the method checks if the device has been "extended" and, if so, by which RFID code; if it is extended by a code other than the one now asking for authentication, it fails.

finally, the method, in all cases, retrieves (through the getCardCredit method of the PostgresDB class) / 7 residual credit associated with the card requesting authentication, and calculates (through the CheckExpi redEvents method of the PostgresDB class) the amount of the associated penalties to any expired events, charging them to the card in question.

finally, it returns the response strings of type "A15", "C15" and "C16".

"At 9" (Start of the race)

Syntax:

A19, <handle>, <time>, <key>, <check> CR LF

Answers:

At 9, <handle>, 00 CR LF

The string of type "A19" signals the actual start of the run to the MuxHub.

<time> represents the time the key was read (the format is YYYYMMddHHmmss). <key> represents the serial number acquired by the reader.

<check> represents the randomly generated check code.

Starting from the reception of this string, the calculation of the time of the journey begins, for the purpose of calculating the cost of the journey itself. Furthermore, at this moment the timer used for the spontaneous and periodic sending of the customer's remaining credit is started.

The calculation of the time (and the cost of the trip) and the operation of the timer for spontaneous sending of the residual credit will end with the receipt of the string of type "Al7"; the credit sending timer will end in any case 2 minutes after the last contact established with the vehicle.

The method of handling this type of string checks if the previous authentication (management of the string of type "A15") was successful and if there is currently no open run; if these conditions are not both true, nothing is done and we go directly to the generation of the "A19" type response, otherwise we proceed with the management of the string, as described below.

If the device has been "extended" (certainly from the same RFID code that is starting the run, otherwise the authentication would have failed), the cost of the extension is calculated (through the getEventDuration method of the PostgresDB class), according to the 'usual price list of races; moreover, through the InsertOperation method of the PostgresDB class, the activation operation is recorded on the operations credits table and the credit on the credits table is updated through the SaveCredit method of the PostgresDB class.

Conversely, in case of non-extension, the cost of activation is charged to the credit of the card, except in the case of an "exempted" card (case verified through the IsFreeCard method of the PostgresDB class); moreover, through the InsertOperation method of the PostgresDB class) the activation operation is recorded on the operations credits table and the credit on the credits table is updated through the SaveCredit method of the PostgresDB class.

If the run has not yet started, the SetCorsa method is invoked (with parameter true).

the SetCorsa method of the Vehicle class, invoked with parameter true in case of string "Al5", and with parameter false in case of string of type "Al 7", sets some attributes of the drun object, relative to the current "ride".

if the parameter is true, the method sets the customer ID with the user ID associated with the current Vehicle object, the vehicle ID with the current Vehicle object ID, the start time with the time current, latitude, longitude, battery voltage and user credit with the values taken from the current Vehicle and User objects. It also starts the timer that regulates the spontaneous sending of the remaining credit to the vehicle.

in case of false parameter sets the same attributes, registering them as final attributes. It also adds the number of kilometers traveled; finally calculates and records in the drun object the time elapsed between the first string of type "Al9" and the first string of type "A17" and (using the getCostTime method) the total rate, it also invokes the UpdateCredit method to calculate the value credit at the end of the run.

The drun object is used by the endCorsaVehicle and startCorsaVehicle methods of Postgres DB (heir of IpluginAuth), with the aim of inserting and updating the record relating to the race on the database table of race vehicles (respectively at the beginning and at the end of the race).

Finally, the management method closes any events that have not yet expired and generates the response string of type "Al9".

"A16" (Request for residual credit)

Syntax:

A16, <handle>, <time>, <check> CR LF

Answers:

At 6, <handle>, 00

<handle>, <response>, <name>, <language>, <check response>, <extra string> CR LF

<handle>, <tirae>, <credit>, <check response> CR LF

The string of type "Al6" signals to the MuxHub the request to receive the updated value of the residual credit.

<time> represents the time the key was read (the format and HHmmss)

<key> represents the serial number of the card.

<check> represents the randomly generated check code.

the server must reply with an "Al6" string to confirm receipt of the request and with a "C15" string to provide consent. The string "C16" will also contain a control field resulting from a hashing formula calculated on ti me, idkey and check.

The management method of this type of string invokes the updateCredit method of the Vehicle class, which calculates the updated credit of the card. This method calculates the time elapsed from the start of the run, and the corresponding cost, calculated thanks to the getcostrime method of the PostgresDB class. Then set the cost attribute in the run object (drun); then it calculates and sets the residual credit attribute in the currently instantiated object of the U-ser class. Finally, it saves the updated credit relating to the card in the database.

The response that the A16 string handling method sends is made up of three strings, of type "Al6", "C15", and "C16".

"A17" (Term of use of the vehicle)

Syntax:

A17, <handle>, <time>, <key>, <reservation>, <check>, <extra string> CR LF

Reply:

A17, <handle>, 00

The string of type "A17" signals to the MuxHub the stop of the vehicle and the end of the run.

<time> represents the time the key was read (signed YYYYMMddHHmmss).

<key> represents the serial number acquired by the reader.

<reservation> represents the number of minutes the vehicle has been booked (0: immediate release, -1 unlimited reservation).

<check> represents the check code thà ̈ is calculated as follows:

ID XOR (time MOD 65536)

where ID is the numeric value calculated as the sum of the ASCII values of the characters making up the key string.

The following table describes the fields expected in the <extra string> string.

Parameter name Type Description

TIME date Date and time in YYYYMMddHHmmss format

The receipt of the string "Al 7" marks the end of the calculation of the time of the trip, for the purpose of calculating the cost of the trip itself, moreover at this moment the timer used for the spontaneous and periodic sending of the residual credit of the trip is stopped. customer.

When the vehicle is stopped, the user will be presented with the choice whether to abandon the vehicle or extend the ride for a predetermined number of hours. The duration of the eventual extension of the run is of a number of hours fixed in the times table of the database.

the management method of this type of string captures the key code and the "reservation" field.

If the instantiated object relating to the current run is not null, that is, a string of type "A17" had not already been received, the eventual extension of the run is managed (that is, in the case of <reservation>, it invokes the Reserve method Vehicle of the PostgresDB class, which inserts in the database extensions table a record corresponding to the extension carried out, with the columns valued relating to the vehicle, the card and the current date / time); the Setcorsa method is then invoked with the parameter false, and then a string "C16" is sent with the updating of the final credit. finally, the response string of type "Al 7" is sent.

Obsolete strings

The following strings are obsolete and not used: â € ¢ string "Al" (status)

«String" A2 "(position)

»" AIO "string (ignition of the dashboard key) â € ¢" Al8 "string (tag reading)

Strings sent from the MuxHub to devices

"C15" (Response to an authentication request)

Syntax:

C15, <handle>, <response>, <name>, <language>, Ccheck response>, <extra string> CR LF

sends the response to an authentication request ("Al5") or to a credit request ("A16"). response> represents the numerical value indicating the outcome of the authentication:

0 OK, authentication successful (machines)

1 existing but disabled user (machines) 2 Non-existent user (machines)

3 Out of credit (machines)

5 Vehicle extended by other customer (machines) <name> represents the user's full name, used to be shown on the display. <language> is a two-character string (ISO national code) indicating the user's language:

IT Italian

UK English

DE German

FR French

<check response> is a calculated check value

on the data of the message Al 5 second The following rule:

<id> XOR (<check> (<time> MOD 10))

where <check> is the value of the field passed with the string

Al5 or Al6, and <id> is the numerical value calculated as

sum of the ASCII values of the characters making up the key string. The value of <id> is calculated through the LoginSum method of the vehicle class, while the LoginCheckCalc method of the same class calculates the entire value of <check response>.

<extra string> is a string consisting of

key-value pairs, in the form chiavel = valueel & key2 = value2 &. . . . with a format similar to encoding URL parameters.

The following table describes the fields provided in the

string <extra string>.

Parameter name Type Description

PICKUP int Only for type 1 protocols; it is 1 if the authentication request is related to a withdrawal, and 0 if it is related to a return

"C16" (Transmission of residual credit)

Syntax:

C16, <handle>, <time>, <credit>, <check response> CR LF Transmits the remaining credit to the device, it is transmitted spontaneously at regular intervals (30 seconds), or in response to a string of type "A15", or in response to a string of type "A16".

<time> represents the time of transmission in HHmmss format.

<credit> represents the residual value on the user's account, in euro cents.

check response> represents the control value which, in the case of spontaneous sending, is calculated as <id> XOR (<credit> * (<time> MOD 10))

while in case of sending requested by the vehicle (through the A16 string) it is calculated as

<id> XOR (<credit> * (<time> MOD 10) <check>) where <check> is the value of the field passed with the string Al6, and <id> is the numeric value calculated as the sum of the values ASCII of the characters making up the key string, the value of <id> is calculated through the LoginSum method of the Vehicle class, while the LoginCheckCalc method of the same class calculates the entire value of <check>.

Other strings sent from the MuxHub to devices

in addition to the strings sent to the devices as a response to the received strings, the MuxHub module is able to send strings regardless of what is received by the devices.

Currently the MuxHub module has methods that handle this submission, but those methods are never invoked from other parts of the code.

in particular, the strings sent are:

this <delay> CRLF: forces a reset of the board with software reload

cu CRLF: Forces retransmission of the complete string of device status data

ci2 CRLF: forces retransmission of the complete string of device position data

ci3 CRLF: signals to the device the availability of updates

C14 <delay, beep, beep interval, text> CRLF: send a message to the device

C17 <limitEnable, limitValue> CRLF: enable OR disable the speed limitation on the motor

C18 <blockEnable, delay> CRLF: forces the vehicle engine to stop (minimum delay 30 seconds)

ci9 CRLF: forces the retransmission of the user code (A15)

CONCLUSIONS AND INDUSTRIAL APPLICABILITY

From the foregoing it will be noted that the inventive process and system fully achieve the intended aim and objects.

Although the invention has been described with reference to specific embodiments thereof, in particular for the management of car-sharing car and truck fleets, the person skilled in the art will understand that the inventive concepts can also be applied to the management of other vehicles, such as bicycles which are currently becoming more and more widespread in the main European cities, or fleets of electric boats.

Of course, the embodiments described are susceptible of numerous modifications and variations, all of which are within the scope of the inventive concept.

In particular, the hardware aspect as well as the software aspect may be susceptible of further improvements, modifications and variations, without thereby departing from the inventive scope as defined in the attached claims.

Claims (17)

CLAIMS 1. Procedure for the management and control of communications of users of land vehicles, in particular motor vehicles, trucks and buses of corresponding fleets, by means of bidirectional communications of data and commands, with means to a remote management and control center, characterized by the fact that said method comprises at least the step of automatically activating and deactivating said communications, at the beginning and at the end of a journey of said vehicle, by means of user card means with integrated circuitry and with individually rechargeable pre-loaded amount associated, in a personalized way, to each said user to allow any said user to access and drive, under the control of said central means, any one of said vehicles of said fleet, and that said remote management and control central means communicate continuously interactively, in order to all said trip, with a computer device on board of said vehicles. 2. Method according to claim 1, each said vehicle being provided to be driven by a user, characterized in that said method comprises the steps of providing, on board said vehicle, said on-board device including on-board computer means, means interfacing for gps, means for voice / data connection, means for connecting to an electronic control unit unit of said vehicle for controlling the charge of the batteries of said vehicle, means for limiting the speed of said vehicle, display means , gps and gprs antenna means, acoustic means, identification card means reader means adapted to read user card means introduced by said user into said on-board device, to provide, in a remote position from said on-board device, means to central servers, operationally connected to means of an operational center which are in turn operationally connected to means of an administrative center, recognize, when the vehicle olo is a car of said fleet of vehicles, said user by reading said card; recharge the credit of said user via virtual Pos; enabling said car to drive; set a destination and navigate; allow the user to either park the car and keep it occupied or leave it permanently available to other users; manage the fare pricing by withdrawing the amount of the preloaded sum; monitor the state of charge of the batteries of said car and warn the user and the operations center when it is time to go to a car park to change the car; limit speed in certain areas identified by the control center such as historic centers, pedestrian areas, parks and gardens, hospitals, cemeteries and fairs, private areas; provide a list of destinations, tourist, commercial, cultural or sporting points of interest in a city; provide the list of sightseeing tours, food and wine tours or shopping routes and limit, when said vehicle is a truck, bus or similar, the speed of said truck or bus in particular on municipal, provincial, state and highways; send the report of the exceeding of certain parameters, such as permitted speed, driving times, concentration of certain substances, to said system server and present messages for users of said trucks and buses in case they are about to commit an infringement relating to speed, driving times, driving while intoxicated or under the influence of drugs. 3. Process according to claim 2, characterized in that said process further comprises, after said step of providing said list of sightseeing tours, food and wine tours or shopping routes, the further steps of presenting advertising banners on said display, whereby a touch of said banner will allow the navigator on board to lead the user to the shop or the activity that inserted the advertisement; present and scroll through communications and messages sent by said operations center, and present and scroll through information-mobility messages from the public administration or other similar bodies. 4. Method according to claim 2, characterized in that said method comprises the further steps of speaking hands-free with said operating center, and surfing the Internet. 5. Process according to claim 2, characterized in that said steps of limiting the speed in certain areas under the control of said messages are capable of being managed and modified by said operating center means. 6. Process according to claim 2, characterized in that said on-board device is able to communicate with and is strictly connected with said central server means, with said operations center means and with said administrative center means, thus to perform a plurality of functions grouped in a plurality of management areas, called plurality of management areas including at least one user database management area, a management area of price lists, a management area of fleets and individual vehicles, with maintenance card; a management area for reservations; a management area for tourist and institutional sites, for sightseeing tours, and a management area for said advertising banners and messages. 7. Process according to claim 2, characterized in that said plurality of management areas further include at least a management area for the travel archives of said trucks and buses, and an infringement management area. 8. Process according to claim 2, characterized in that said central server means are adapted to receive connections from remote telemetry units and to distribute said connections to user software modules; record all telemetry data received in the database; view the data on cartographic support and interact with an operator to query the information; automatically send documents of proof of infringements to competent authorities and to individual transport companies for notification or information; and periodically send data relating to the journeys of said trucks to transport companies. 9. Process according to claim 2, characterized in that said operating center means are adapted to trace said vehicles, to report their flows, to check the position of all said vehicles, to calculate their use times; record the history of all said data; activate the use of said vehicles; implementing interconnection to info-mobility systems, making voice calls to the user or driver of said vehicle, immediately detecting an emergency signal from said vehicle; immediately detect any impact report; search for all the vehicles present within a certain distance from a point indicated on the map, indicating their status on the green or red LED; transmit messages, in particular information-mobility messages, road directions, service orders, warnings both to a specific vehicle and to all said vehicles at the same time; notify said user that the battery charge of said vehicle is running out, and then drive said user to the nearest parking lot to replace said vehicle, block said vehicle in case of inappropriate use, after having warned said user with connection vowel; managing said fleet of vehicles with control of the vehicles available in use and being recharged, optionally booking a said vehicle by entering the registry of the booking party; and consequent change of LEDs from green to red, define specific areas, with limitation of speed or access to city areas; automatically report, in the presence of particular events, such as a vehicle leaving a perimeter or a predefined route. 10. Process according to claim 2, characterized in that said operating center means are also suitable for signaling exceeding of maximum speed, exceeding of driving time, and driving in a state of intoxication or under the influence of drugs. 11. Process according to claim 2, characterized in that said administrative central means are suitable for carrying out the steps of inserting user data, inserting payment data of said users; read the same information available for said operations center; manage price lists; administratively manage said users with traffic reporting, Internet browsing reporting, and collection and recharging of said cards, billing, reporting. 12. Process according to claim 2, characterized by the fact that said administrative central means are also suitable for carrying out the steps of registering monuments, sites of tourist, commercial or institutional interest with the insertion of texts, photos, addresses and other information, define sightseeing, food and wine tours, shopping or nightlife tours, linking together the records of the sites of interest loaded, to allow the navigator to lead the user along the chosen path; implement interconnection with other operating systems to guarantee the use of the service to subscribers to other car sharing or transport companies such as railways, municipal transport companies, etc .; manage these advertising banners; manage these banners for the presentation of cultural, sporting and social events organized by municipal institutions; and touching the banner relating to a cultural event or a advertised exercise by activating the navigation function for the guided path to the selected event, said banner being sent to said means to the operations center on each said on-board device via GPRS, 13. System or device for carrying out the process according to claim 1, characterized in that said system of a modular unit that can be installed on each said vehicle and operably interfaced with the electrical and electronic system on board of each said vehicle, said system including circuitry for continuous bidirectional communications of data and user commands with remote control management means, said circuitry being activated and deactivated by any user of any said vehicle, at the beginning and at the end of a journey of said vehicle , by means of rechargeable user credit card means with integrated circuitry associated, in a personalized way, to each said user, to allow any said user to access and drive, under the control of said central means, any said vehicle. 14. System according to claim 13, said system including, on board of said vehicle, said on board device, said on board device including computer means, electronic card means interfaced with said computer means for gps, voice connection means and / or data, means for connecting to said electronic control unit of said vehicle, for controlling the charge of its batteries, for limiting the speed and for other functions; touch screen LCD display means, gps and gprs antenna means, RFID antenna means or card reader means, acoustic means, in particular a hands-free loudspeaker between said user and said control unit means, and light signaling means, in particular a green LED or a red LED to indicate if the car is free, booked or with a low battery. 15. System according to claim 13, characterized in that said system includes, operatively functionally bidirectionally connected to said on-board device, central server means, operating center means and administrative center means. 16. System according to claim 15, characterized by the fact that said administrative central means are also able to recognize the user, trips made by said user on various circuits, thus registering a database allowing to periodically issue an accounting report for the crediting of the relevant fees to individual transport companies. 17. System according to claim 13, characterized by the fact that said system further comprises a plurality of independent modular management and control units, which can be installed in a plurality of public places suitable for issuing said cards, electronic tickets or valid electronic travel tickets on request. for local public transport companies and railways, said modular units, each emulating a virtual office capable of presenting basic information on the service characteristics on a dedicated display, said information being the same present on a service website, said virtual office also providing an Internet connection for connecting to the car sharing company's website, and being additionally suitable for immediately registering a new subscriber by scanning the license or registering said new subscriber in a computer archive, enter personal data of the new subscriber from keyboards on the touch display, enter data relating to the credit card of said new subscriber, enter an e-mail address of the same, accept contractual clauses by confirming from said keyboard, enter secret data on said card and memorize a number of the database, issue a subscription card for the service with printing of the user's name, assigning said secret data allowing the new subscriber to access a reserved area of said website, transmitting all the aforementioned data to a database residing on said server; establish a connection to the site to allow the user to top up his credit, speak with said means to the operations center to obtain assistance with registration, and allow the issuance of other cards, or electronic tickets, or electronic travel documents valid for companies of local public transport and rail.