CROSS-REFERENCE TO RELATED APPLICATIONS
-
This patent application claims priority from
Italian patent application no. 102024000020827 filed on September 18, 2024 , the entire disclosure of which is incorporated herein by reference.
TECHNICAL FIELD
-
The present invention relates to an improved monitoring of the distance between vehicles for the management of vehicles adapted to transport dangerous goods. In detail, the present invention relates to a management system for the road navigation of vehicles adapted to transport dangerous goods, to an infrastructure comprising the management system, to a method for managing the road navigation of a plurality of vehicles and to a corresponding computer program product.
-
In particular, the present invention has the aim to prevent two or more vehicles transporting dangerous goods from passing or stopping at a close distance and allows analyzing the dynamic risk in real time thanks to the monitoring of the passage of the dangerous goods.
-
The present invention is preferably, even if not exclusively or limitedly, applied to heavy vehicles, preferably trucks or vans.
BACKGROUND OF THE INVENTION
-
As is known, vehicles adapted to transport dangerous material or substances or goods (such as for example flammable, or irritant, or toxic, or other material / substance) are commonly called ADR ("Accord européen relatif au transport international des marchandises Dangereuses par Route") vehicles.
-
The ADR agreement regulates the international transport of dangerous goods by road and specifies strict rules for transporting the same.
-
In fact, although such vehicles play a crucial role in the goods distribution logistics chain, facilitating the movement of substances necessary for several industries, the transport of such goods involves serious risks that require a meticulous management and supervision. In particular, it can happen, for example, that two vehicles transporting dangerous substances find themselves at a close distance both during the driving and during the stop, with the increased risk of an accident with potentially critical consequences. Furthermore, it can also happen that two vehicles transport substances that are not dangerous in themselves but would be if they came into contact with each other; in this case, undesired and potentially very serious accidents could occur in the case where such vehicles caused an accident between them, with spilling and mixing of the substances that they are transporting.
-
It should be noted that in one single motorway monitoring section in Italy alone, more than two thousand ADR vehicles travel each year with a headway of less than 10 s (i.e. with a relative distance less than 200 m from each other, if assuming a speed of 72 km/h), raising serious concerns for potential safety accidents.
-
The risks connected to the passage of ADR vehicles on the motorway require a management of the safety in real-time which provides for solutions for mitigating the risks and supporting the possible emergency. Known solutions exploit advanced technologies for facilitating the proactive risk mitigation and ensuring a rapid response to the emergencies or potential dangers. While the current solutions are based on the video or image recognition, the scientific community and the industry are exploring new methods based on monitoring through global navigation satellite systems (GNSS). The tracking of the ADR vehicles can be obtained also by exploiting the cellular network infrastructure, which in the new 5G generation includes specially provided technologies for the radio-location which exploit dedicated positioning signals. However, these known systems require the installation of expensive and complex hardware, often provided by third-party companies and thus difficult to customize as a function of the various situations.
-
The object of the present invention is to provide a management system, an infrastructure comprising the management system, a method for managing the road navigation and a corresponding computer program product which overcome the drawbacks of the prior art.
SUMMARY OF THE INVENTION
-
The objective of the present invention is to satisfy the above-mentioned needs.
-
The aforementioned objective is achieved by a management system, an infrastructure comprising the management system, a method for managing the road navigation and a corresponding computer program product, as defined in the appended claims which form integral part of the present description. In particular, this allows obtaining an improved road management of the ADR vehicles, defining a new approach based on the "Vehicle-To-Everything" (V2X) communications.
BRIEF DESCRIPTION OF THE DRAWINGS
-
In order to better understand the present invention, a preferred embodiment is now described, by way of mere non-limiting example, with reference to the accompanying drawings, wherein:
- Figure 1 shows a block diagram of an infrastructure comprising vehicles of the ADR type and a management system of the road navigation of the vehicles, according to an embodiment of the present invention;
- Figure 2 shows block diagrams of the data structures of data received and generated by the management system of Figure 1, according to an embodiment of the present invention;
- Figure 3 schematically shows details of the infrastructure of Figure 1, according to an embodiment of the present invention;
- Figure 4 schematically shows further details of the infrastructure of Figure 1, according to an embodiment of the present invention;
- Figures 5a and 5b show examples of graphs and Figure 5c shows an example of a graphic representation, generated in use by the management system of Figure 1, according to an embodiment of the present invention; and
- Figure 6 shows a block diagram of a method for managing the road navigation of the vehicles, according to an embodiment of the present invention.
-
In the following description, elements in common with the different embodiments are indicated by the same reference numerals.
DETAILED DESCRIPTION OF THE INVENTION
-
Figure 1 shows a management system 10 for managing the road navigation of one or more ADR vehicles 12, which ensures a safer circulation of such vehicles adapted to transport dangerous goods (such as for example flammable, irritant, toxic, radioactive, corrosive or other material / substance).
-
Herein, dangerous substances mean substances that are dangerous in themselves for humans, animals or the environment, as well as substances that, although not dangerous in themselves, would be if they came into contact with one another (e.g. due to spilling or mixing of one or more of such substances between one another) or with substances normally present in the surrounding environment (e.g. air or water).
-
One or more of the ADR vehicles 12 can be an autonomous driving vehicle, or a traditional vehicle with human driver. Non-limiting examples of such ADR vehicles 12 include trucks and vans.
-
In the following, the management system 10 can also be called ADRTrack 10.
-
The management system 10 is operatively coupled to one or more of such ADR vehicles 12, in order to communicate with them and manage their movements and road circulation.
-
In detail, Figure 1 shows, by way of example, N ADR vehicles 12, where N can be equal to 1 in the case of control of one single ADR vehicle 12 or greater than 1 (e.g. in the case of a fleet of ADR vehicles 12). In the following, the ADR vehicles 12 are also more simply called vehicles 12.
-
Together, the management system 10 and the vehicles 12 form an infrastructure, in particular of the road type, still more in detail of the motorway type.
-
The management system 10 and the vehicles 12 thus communicate in use, thereby allowing a communication of the "Vehicle-To-Everything" (V2X) type, for example based on known technologies of the "Cooperative Intelligent Transportation System" (C-ITS) type.
-
The management system 10 allows monitoring and controlling the circulation of the vehicles 12 so as to maintain a safe spacing between the vehicles 12 and enable the safe navigation thereof in tunnels or other critical road sections.
-
In particular, specific control functions of the vehicles 12 can be managed through the management system 10 in the case of abnormal events and can include, for example, sudden reductions in the speed of the vehicles 12 or quick stopping of the vehicles 12 (e.g. in accordance with the current "Hazardous Location Notification - Slow or Stationary Vehicle", HLN-SV, regulations of the European "C-Roads" project).
-
For such purpose, the management system 10 tracks the position of the vehicles 12 in real time and, when the vehicles do not comply with predefined distance criteria, generates and transmits consequent warning messages for the vehicles 12 through the V2X technology, as is better described in the following.
-
In detail, the vehicles 12 generate input data which are received at the input by the management system 10, whereas the management system 10 generates at the output, output data which are received at the input by the vehicles 12 and which are used for controlling the vehicles 12.
-
In greater detail, the input data can comprise messages of the "Cooperative Awareness Messages" (CAMs) type or messages of the "Decentralized Environmental Notification Messages" (DENMs) type, based on the communication standards defined by the "European Telecommunications Standards Institute" (ETSI). The CAMs mainly include information available through the CAN network of the vehicle 12, for example are indicative of the position, speed and acceleration of the vehicle 12. The DENMs are messages activated by events and are usually utilized, for example, for indicating an accident or a closed lane ahead of the vehicle. In the following, the CAMs are considered herein by way of example.
-
Whereas, the output data can comprise messages of the "Infrastructure-to-Vehicle Information Messages" (IVIMs) type. The IVIMs are usually sent to the vehicles for warning them concerning the road signals, for example with regard to the speed limits and the information about the road works.
-
As is shown in Figure 2, both the input data and the output data can include additional information when the vehicles transmitting or receiving them are vehicles 12 of the ADR type. For this reason, it is possible to also call these data extended input data and extended output data, respectively (and thus extended CAMs/DENMs and extended IVIMs, respectively).
-
This additional information is indicative of the transport of dangerous goods by the vehicles 12. In detail, it is indicative of one or more of the following pieces of information: type of dangerousness of the goods transported (e.g. explosive, flammable, toxic, etc.); Kemler code of the goods; UN ("United Nations") number of the goods; quantity of goods actually transported; contact information of the manufacturer or distributor of the goods; and contact information of the recipient of the goods. Preferably, the additional information is indicative of a plurality of these pieces of information, for example is indicative of the Kemler code, of the UN number, of the quantity of goods actually transported and of the contact information of the manufacturer/distributor and recipient of the goods.
-
In fact, the Kemler code and the UN number allow the emergency services to intervene without risks in the case of accident, as they already know the type of goods and their degree of dangerousness. The quantity of goods transported allows distinguishing the vehicles 12 that are actually transporting dangerous material from those that in reality are empty or anyway only partially filled. The information about the company of arrival and/or origin, such as the telephone number and the street address, is useful for promptly contacting it in the case of emergency in order to obtain further data useful for the rescuers. Finally, the final destination of the goods is useful in the case of deviations or re-routings.
-
As is shown in Figure 2, each input data packet (herein the CAM data are considered by way of example, indicated by reference numeral 14) can comprise a set of predefined data (e.g. comprising a header 14a, a basic container 14b, a highfrequency container 14c and an optional low-frequency container 14d, all of known type) and, when the vehicle is an ADR vehicle 12, also a special vehicle container 14e that contains the additional information on the goods transported, which was previously described.
-
Similarly, each output data packet (herein the IVIM data are considered by way of example, indicated by reference numeral 16) can comprise a set of predefined data (e.g. comprising a header 16a, a management container 16b and an optional geographical location container 16c, all of known type) and, when the vehicle is an ADR vehicle 12, also a dangerous goods container 16d that contains information relative to the alert level for the ADR vehicle 12 and determined by the management system 10, as is better described in the following.
-
These extended CAMs and IVIMs enable alerting both the management system 10 and the surrounding vehicles concerning the presence of ADR vehicles 12, with particular attention to the presence and the details of the dangerous goods they are transporting. This enables monitoring the distance between the vehicles 12 and their movement status (e.g. slow, stationary or broken down) and assigning the alert level, as well as notifying optional or alternative maneuver suggestions (for example maintain the distance, slow down or change route).
-
The communication between the vehicles 12 and the management system 10 occurs according to technologies known per se.
-
In particular, Figure 3 shows details of the vehicles 12 and of the management system 10, useful for the mutual exchange of the input data and of the output data and in general for their operation.
-
In greater detail, each vehicle 12 can include the following equipment: a route data determination device 22, a memory unit 24, a data transceiver device 26 and a data bus 28 of physical (wired) or wireless type. Through the data bus 28 the route data determination device 22, the memory 24 and the data transceiver device 26 are connected to one another for transferring information. Furthermore, the vehicles 12 can naturally also have a digital road map of their own.
-
The route data determination device 22 makes it possible both to determine in real time the actual position of the respective vehicle 12, and (optionally) to view a digital road map (through the display of the vehicle 12). The route data can also contain other data besides the positions of the vehicle 12, for example the traveling direction and/or the speed and/or the acceleration. The determination of the position can occur, for example, through a receiver of a satellite navigation system (for example GPS), possibly integrated with inertial sensors on board the vehicle.
-
The route data determination device 22 can be connected to the memory unit 24 in terms of possibility of data transfer, through the data bus 28. The memory unit 24 of the vehicle 12 allows the progressive storage of the kinematic information of the vehicle 12, which describes the route of the vehicle 12 in a time interval.
-
The data transceiver device 26 can have a transmission unit by means of which it establishes a (wireless) connection with the management system 10, arranged in a fixed position outside the vehicle 12. For example, the connection can occur through an architecture of the cloud 20 type.
-
In greater detail, such connection can be based on a V2X connection with C-V2X or ITS-G5 technologies, or on a cellular connection (e.g. 4G or 5G) or other radio technology that supports the transmission of messages such as the ETSI ones described above and adapted to exchange the mentioned data. Figure 4 shows an example of such V2X connection, wherein the vehicles 12 and the other vehicles (indicated herein by reference numeral 45) traveling along a same road section 46 are connected to one another through cloud 20 through a base station (e.g. of 5G type) 47 and/or through RSU C-ITS 48 and a traffic control center 49.
-
By means of this connection, the data of the route which are recorded in the memory 24 can be transmitted to the management system 10, for example at regular intervals.
-
Alternatively, the position data of the vehicle 12 may not be stored in the memory 24, but are transferred in a continuous manner and in real time to the management system 10.
-
The management system 10 can comprise at least one data transceiver unit 23 and a control unit 25, coupled to each other.
-
The control unit 25 is an electronic-type processing unit (e.g. a microprocessor, a CPU, etc.) which includes the blocks of the management system 10 which are shown in Figure 1 and which are better described in the following.
-
Optionally, the management system 10 can further comprise a digital road map (not shown) stored in a data memory of its own (not shown).
-
During the journey, the route data determination devices 22 determine the respective actual positions of the vehicles 12. These are then transmitted to the management system 10. The management system 10 collects route data transmitted by each vehicle 12 in a specially provided memory area. The route data include the position and, optionally, other data such as the speed of the vehicles 12, or data relative to the monitoring of the substances transported. In real time, or at regular intervals close to one another in time, the route data are utilized for representing, on the digital road map at the level of the management system 10, the routes and the current positions corresponding to each vehicle 12.
-
For example, each vehicle 12 can be uniquely identifiable by means of a unique code, which enables associating such vehicle 12 with the data / information generated at the level of the vehicle 12 and transferred by such vehicle 12 to the management system 10 through the cloud 20. In this manner, the management system 10 knows the position of each vehicle 12 and can uniquely associate the information received from each vehicle 12 with such vehicle 12.
-
For the purpose of transmitting the data from each vehicle 12 to the management system 10, the data transceiver device 26 and the data transceiver device 23 are implemented according to any available technology.
-
In detail, the implementation of the communication between vehicles 12 and management system 10 through the cloud 20 enables spreading the route information of each vehicle 12 in an optimal manner, for example by sending at the same time the position information of each vehicle 12 to the other vehicles 12, which can view it on their own navigator on display, and to the management system 10. In the same manner, the management system 10 can send selected information only to some vehicles 12 (e.g. identified through a unique code) or send in broadcast useful information to all the vehicles 12 connected to the cloud 20.
-
Furthermore, the vehicles 12 that receive such output data can react in at least one of these modes:
- showing on display in the passenger compartment of the vehicle 12 the information relative to the routes suggested by the management system 10, so that the driver can keep it into account during the driving choices;
- automatically setting a new route on the navigator of the vehicle 12 which keeps into account the information relative to the routes suggested by the management system 10, so as to avoid traveling on unsuggested road sections;
- in the case of an autonomous driving vehicle, the autonomous driving system automatically sets and follows a new route, keeping into account the information relative to the routes suggested by the management system 10, so as to avoid traveling on unsuggested road sections;
- in the case of an autonomous driving vehicle, the autonomous driving system automatically sets a speed of the vehicle 12, so as to slow down or speed up the vehicle 12 in order to maintain a given distance from the other vehicles 12 which are following or preceding it.
-
With reference again to Figure 1, the modules of the management system 10 (in particular, of its control unit 25), which allow generating the IVIMs starting from the processing of the CAMs received, are now described in detail.
-
In detail, as is shown in Figure 1, the management system 10 comprises, coupled to one another: an (optional) ADR filter module 30; a (an optional) map matching module 32; a distance monitoring module 34; a (an optional) threshold verification module 36; a (an optional) dashboard support module 38; and an (optional) output generation module 40.
-
The ADR filter module 30 receives the CAM events, acquires the information content thereof and selects among these only the CAMs coming from the vehicles 12 of the ADR type.
-
In detail, the ADR filter module 30 first of all controls if the message received is actually of the CAM type, verifying the correctness of the fields/containers thereof. Then, the type of vehicle that generated the CAM (ADR vehicle or other vehicle) is controlled, filtering all the messages not sent by the ADR vehicles, and the dangerousness of the goods transported is controlled. Once it has been confirmed that the CAM actually comes from an ADR vehicle, the useful information (e.g. that present in the special vehicle container 14e) is extracted so as to generate a respective ADR event for each CAM event confirmed by the ADR filter module 30, for example utilizing as key the identification of the vehicle 12.
-
In order to verify the position and the status of the vehicles 12 generating the detected CAMs (e.g. a motorway section), the map matching module 32 acquires the ADR events and, based on these, implements a map matching algorithm of a type known per se and based on a graphic representation of the road to be travelled (in the following, by way of example a motorway). In particular, by calculating the distance on a graph, it is possible to determine the specific road section (as well as the lane) on which the vehicle 12 is circulating. Furthermore, possible abnormal behaviors of the vehicle 12 are detected starting from the CAM information, such as the activation of the emergency lights, the sudden decelerations, the stationary status, etc. For example, if the vehicle is detected on a motorway section, it is classified as motorway ADR vehicle (HADRV) and the respective CAM information is generated at the output as a respective map event, comprising the details relative to the road travelled (e.g. type of motorway, motorway branch and lane). Furthermore, if the HADRV decelerates and activates the right direction indicator, it is classified as vehicle likely exiting the motorway; in this case, the map matching module 32 subsequently performs a new control for verifying if the HADRV remained on the motorway or actually exited it. Finally, the possible unreachable vehicles (i.e. which no longer send CAMs) are classified as "non-responsive".
-
Each graph is a directional graph composed of road vertices (or nodes) and edges (or arcs). The road vertex represents a point in the road network (for example, an intersection) with the relative main road information, such as road coordinates, road identifier and road type, motorway mileage and possible additional information. The coordinates of the vertex can be extracted from the known "Open Street Map" tool. The road edge connects two vertices and allows navigating in the graph maintaining the information on the distance between two neighbor vertices. For example, such distance is calculated in advance by utilizing the haversine distance. In order to calculate the distance of a vehicle starting from the road graph, the two graph points, which are nearest neighbors (or first neighbors) to the vehicle, are identified and the distance of the vehicle from the line passing through the two points is calculated.
-
An important function of the management system 10 concerns the monitoring of the distances between the ADR vehicles. For such purpose, the distance monitoring module 34 acquires the map events and calculates the distance, along the road, between vehicles 12 which are identified as being neighbors to one another (e.g. with relative distance between the ADR vehicles which can be comprised between 300 m and 2 km, as a function of the specific situation and as is better described in the following).
-
In detail, every time a vehicle 12 enters a motorway section, the distance monitoring module 34 verifies the presence of other HADRVs in the neighborhood. If the proximity of other HADRVs is confirmed, an HADRV group is identified which comprises such HADRV vehicles neighbors to one another and the distance between them is monitored in real time, in particular by utilizing a routing algorithm, also called map matching algorithm, on the graph of the motorway.
-
Furthermore, the type of road to be travelled by the vehicle 12 is also controlled and, if useful, further information is obtained therefrom: for example, if the vehicle 12 is in a tunnel, further information is obtained from the corresponding road vertex of the graph, such as the length and the distance of the vehicle 12 from the entrance of the tunnel. In fact, in tunnels, even if there is no GNSS coverage, the position information can be obtained by combining GNSS data acquired at the entrance of the tunnel with data from on-board inertial sensors or, in infrastructure-equipped road sections of the smart road type, with data obtained through new generation V2X technologies (e.g. 5G network and its evolution) which integrate location functions with communication functions through the transmission of specially provided signals for the multi-lateration/multi-angulation. This information on the distance between vehicles 12 and on possible further information of the vehicles 12 thus forms a respective distance event at the output from the distance monitoring module 34.
-
Similar to the previously described road graph, the HADRV group is represented as a directional graph and composed of HADRV vertices and edges. The vertices comprise additional information on the respective HADRV extracted from the CAM, such as speed and acceleration.
-
Examples of road graphs implemented by the distance monitoring module 34 are shown in Figures 5a and 5b.
-
In order to calculate the distance between the two vehicles 12 along the road network, it is useful to map the vehicles on the road graph and therefore identify the nearest neighbor edge to each vehicle 12. The identification of the edge can be problematic when the distances between the vertices of the graph are not homogeneous and it is thus not possible to be sure that the second nearest neighbor vertex belongs to the nearest neighbor edge of the vehicle 12.
-
The monitoring of the distance is based on a routing algorithm that utilizes the distance of the vehicle 12 with respect to the road graph of the map matching module 32.
-
In detail, for each vehicle 12 of the HADRV group it is useful to calculate distance parameters such as: a distance of the vehicle 12 from the road vertex that is the nearest neighbor to it (typically obtained through the map matching module 32); an angle θ that the considered vehicle 12 forms between the first nearest neighbor vertex and a candidate second nearest neighbor vertex of the graph; and an angle ϕ that the vehicle 12 forms between its orthogonal projection on the considered edge and the candidate second nearest neighbor vertex of the graph.
-
In detail, if θ ≥ ϕ (e.g. Figure 5a), the considered road edge is actually the one traversed by the vehicle 12 and the candidate second nearest neighbor vertex belongs to the nearest neighbor edge and is thus actually the second nearest neighbor vertex to the vehicle 12 of the graph. Otherwise, if θ < ϕ (e.g. Figure 5b), it results that the candidate second nearest neighbor vertex does not belong to the nearest neighbor edge and is not thus actually the second nearest neighbor vertex to the vehicle 12 of the graph. Selecting the correct edge and the correct second nearest neighbor vertex is very useful for the following routing algorithm. Consequently, this control on the angles θ and ϕ is executed after the definition of the road graph in order to verify if the corresponding road graph is actually a correct representation of the real situation; otherwise, the considered edge and second nearest neighbor vertex are varied and the control is repeated until the correct road graph is obtained.
-
Once the correct road graph is obtained, the distance monitoring module 34 utilizes the following criteria in order to calculate the distance between a first vehicle 12 that precedes (indicated by V in Figure 5a) and a second vehicle 12 that follows (indicated by T in Figure 5a) on a same road section. These criteria are now described referring to the (correct) graph of Figure 5a.
-
Firstly, H is defined as the projection of T on the edge represented by the segment AB that joins the two road vertices A and B, and H' is defined as the projection of V on the edge represented by the segment DE that joins the two road vertices D and E.
-
The routing algorithm calculates respective first distances AT and DV of the vehicles T and V from the respective nearest neighbor vertices A and D of the graph, as well as respective second distances TB and VE of the vehicles T and V from the respective second nearest neighbor vertices B and E of the graph.
-
Furthermore, the routing algorithm calculates the distances AH and DH' between the projections H and H' and the respective nearest neighbor vertices A and D of the graph.
-
Based on these distances, the routing algorithm calculates the distance TV between the two vehicles T and V.
-
In particular, the distance TV is calculated starting from the (known) distance AD between the vertices A and D of the graph that are nearest neighbors to the vehicles T and V, and as a function of the previously calculated distances.
-
In particular, for the second vehicle T it results that: in the case AT < TB, the distance TV is calculated by subtracting AH; if instead AT ≥ TB, the distance TV is calculated by adding HB. Furthermore, for the first vehicle V, it results that: in the case DV < VE, the distance TV is calculated by adding DH'; otherwise, if DV ≥ VE, the distance TV is calculated by subtracting H'E. The distance TV is thus calculated considering both these contributions defined by the positions of the vehicles T and V with respect to the vertices of the graph, besides considering the distance AD.
-
For example, in the exemplifying case of Figure 5a where AT < TB and DV < VE, it results that TV = AD-AH+DH'.
-
The properties of the graph are useful also for the detection of an overtaking of the vehicles T and V. In fact, if the relative distance is negative or may not be calculated, it results that the second vehicle T overtook the first vehicle V, becoming the new head vehicle. The determination of the overtaking is managed by reordering the graph corresponding to the HADRV group (i.e. updating the first neighbor vertices to the new positions of the vehicles T and V) when a corresponding overtaking information is received by the management system 10 for notifying the occurrence.
-
This approach for calculating the distances based on the previously described map matching allows compensating possible inaccuracies in the determined positions of the vehicles, for example acquired through GPS receiver. In the absence of this, it would instead be possible to have a conditioning of the route data, indicated for example by the so-called "unclear" routes generated by the GPS error tolerances.
-
A practical example of this scenario for calculating the distances between the vehicles 12 through map matching is shown in Figure 5c.
-
With reference again to Figure 1, the threshold verification module 36 is now described.
-
The threshold verification module 36 receives the distance events and, based on these, generates a corresponding alert signal.
-
The alert signal is indicative of an alert level determined as a function of the situation detected by the management system 10. As considered by way of example in the following, the alert signal is indicative of an alert level that varies between a minimum value (e.g. 0), indicative of minimum danger or no danger, and a maximum value (e.g. 3), indicative of maximum danger. Consequently, the alert signal is indicative of a high danger level when a danger condition for the vehicles 12 occurs (e.g. two vehicles 12 on the same road section are too close for the safety requirements to be respected in the case of accident).
-
In detail, the threshold verification module 36 generates an alert event indicative of this alert signal, so that a corresponding IVIM can be generated comprising the alert signal, as is better described in the following. This allows notifying the presence of vehicles 12 that are too close, also based on factors such as the type of road (e.g. tunnel or open route) and the status of the first vehicle (i.e. of the vehicle that precedes), in order to signal to other vehicles and bodies the local alert level due to the presence and proximity of the ADR vehicles, as well as possible maneuver advice for the drivers.
-
The alert signal is generated by the threshold verification module 36 based on a comparison between the distance events (e.g. the calculated distances between the vehicles T and V or the calculated distance between the considered vehicle and the entrance of a tunnel) and one or more predefined thresholds. In particular, the calculated distance between the vehicles T and V is compared with a first threshold distance and the alert signal is generated in a corresponding manner. Optionally, the distance of the vehicle from the entrance of a tunnel can also be compared with a second threshold distance and generate the alert signal also as a function of such comparison.
-
In detail, the thresholds utilized by the threshold verification module 36 depend on one or more of the following factors: type of road, in particular tunnel or open route; type of goods transported by the vehicles 12; intensity of the traffic on the considered road section; and type of driving, in particular regular driving or abnormal driving. Preferably, the thresholds utilized by the threshold verification module 36 depend on each of these factors, or at least on the type of road and on the type of driving.
-
More in detail, the condition of abnormal driving can still be sub-classified into two or more of the following classes: slow vehicle; stationary vehicle; vehicle malfunction.
-
In greater detail, the alert level is usually higher in a tunnel than on the open route and is usually higher for an abnormal driving than for a regular driving (in detail, it increases as the degree of abnormality detected increases). Similarly, the distance threshold is usually greater in a tunnel than on the open route and is usually greater for an abnormal driving than for a regular driving (in detail, it decreases as the degree of abnormality detected increases).
-
For example, the alert level varies from 0 to 3 (e.g. corresponding to no warning, mild warning, serious warning and alarm, respectively). Similarly, the corresponding advice level to be provided to the driver can vary for example from 0 to 4, where 0 indicates no advice to be provided or more generally to be careful when driving, 1 to maintain the distance from the vehicle 12 that precedes, 2 to slow down, 3 to stop, 4 to change route. In particular, the alert level 0 corresponds to the advice levels 0 and 1, the alert level 1 corresponds to the advice level 2, the alert level 2 corresponds to the advice level 3 and the alert level 3 corresponds to the advice level 4.
-
As main conditions of the vehicle, an abnormality herein is considered every time its status is not regular (i.e. greater than 0).
-
By way of non-limiting example, the following distance thresholds can be utilized:
- in the case of an open route and regular driving, approximately 1 km between the vehicles 12 for having an advice of level 0 (e.g. be careful when driving);
- in the case of an open route and abnormal driving with a slow or stationary vehicle, approximately 2 km between the vehicles 12 for having an advice of level 1 (e.g. maintain the distance) and approximately 300 m between the vehicles 12 for having an advice of level 2 (e.g. slow down);
- in the case of an open route and abnormal driving with vehicle malfunction, approximately 2 km between the vehicles 12 for having an advice of level 3 or 4 (e.g. stop or change route);
- in the case of a tunnel and regular driving, approximately 1 km between the vehicles 12 for having an advice of level 0 (e.g. be careful when driving), approximately 300 m between the vehicles 12 for having an advice of level 1 (e.g. maintain the distance) and approximately 1 km between the considered vehicle 12 and the entrance of the tunnel for having an advice of level 2 (e.g. slow down for delaying the entrance in tunnel);
- in the case of a tunnel and abnormal driving with slow or stationary vehicle or vehicle malfunction, approximately 2 km between the vehicles 12 for having an advice level 3 or 4 (e.g. stop or change route) and approximately 1 km between the considered vehicle 12 and the entrance of the tunnel for having an advice of level 3 or 4 (e.g. stop or change route).
-
Optionally, these distance thresholds can be further increased in the case of vehicles 12 that transport dangerous goods when combined together, and can be further reduced in the case of vehicles 12 that transport goods that are not dangerous when combined together.
-
Similarly, these distance thresholds can be further increased in the case of heavier road traffic, and can be further reduced in the case of lighter road traffic.
-
Furthermore, the output generation module 40 receives the alert events and generates corresponding output data, herein IVIMs and in detail extended IVIMs. This allows managing the notifications towards the surrounding vehicles, in particular towards the ADR vehicle that follows, allowing controlling the functions thereof, as is better described in the foregoing (e.g. enabling the latter to decelerate, stop or modify its route if necessary).
-
In particular, the dangerous goods container 16d of the IVIM is filled in with the information contained in the corresponding alert event and thus indicative of the specific alert level.
-
The IVIM is addressed to the target vehicle by means of the identification of the vehicle.
-
For example, when the warning notification towards a vehicle begins because there is a danger condition, the IVIM can be updated at the speed of the CAMs, utilizing at each instant the new calculated distance and continuing until the danger condition is no longer valid (for example due to an overtaking or increase in the distance between the vehicles). In this case, a further closing IVIM can be transmitted to the vehicle of interest.
-
Finally, the dashboard support module 38 is operatively coupled, in use, to a dashboard 42 external the management system 10 and for example managed by a fleet owner of the vehicles 12 or by a body in charge of managing or monitoring the same.
-
For example, the dashboard support module 38 and the dashboard 42 are coupled through a REST API 44, it also external the management system 10.
-
For example, the dashboard support module 38 sends to the REST API 44, for example through a GeoJSON list, the positions of the vehicles 12 in movement within the motorway network. The REST API 44 then sends these aggregated data to the dashboard 42, which allows the viewing thereof through its display and optionally further processed data.
-
In particular, the map can show the locations of the ADR vehicles, for example identified by different colors based on the different alert levels (e.g. blue for none, yellow for mild warning, orange for serious warning and red for alarm). Specific icons can be utilized for denoting vehicles that are experiencing abnormal behaviors. General information on the vehicle, including the type of dangerous material transported, can be visible; for example, it is possible to access these details by selecting the vehicle to be viewed, through a pop-up window with additional information.
-
This thus allows monitoring in real time the ADR vehicles in movement within the road network and controlling possible notifications of vehicles that are too close or in an abnormal operating status.
-
At the level of implementation details, the ADRTrack 10 can be based on "Apache Kafka" technology, of a type known per se. Furthermore, the ADRTrack 10 can be implemented through Python language by utilizing the corresponding "Confluent Kafka" library.
-
In use, the management system 10 implements a management method 50 for managing the vehicles 12, shown in Figure 6.
-
In detail, the steps of the method are evident in view of the previously described operation of the management system 10. For this reason, they are not described herein again in detail but only briefly summarized.
-
In greater detail, the method comprises: at step S01, receiving the input data, in particular the CAMs, by the management system 10; at step S03, (optionally) filtering the input data through the filter module ADR 30; at step S05, (optionally) verifying a map matching of the positions of the vehicles 12 through the map matching module 32; at step S07, calculating the distance between the vehicles 12 through the distance monitoring module 34; at step S09, generating the alert signal as a function of the comparison operated by the threshold verification module 36; at step S11, (optionally) generating the output data, in particular the IVIMs, through the output generation module 40; and, at step S13, (optionally) sending the information to the dashboard 42 through the dashboard support module 38.
-
This method 50 is also implementable through a corresponding computer program product, storable in the management system 10 and designed so that, when executed, the management system 10 becomes configured to execute the method 50.
-
The operation of the management system 10 was verified in an extensive manner. For example, the scenario where two vehicles 12 (e.g. trucks) follow each other with variable speeds was simulated. In a first simulation, the head truck maintains a constant speed, whereas the following truck leaves after approximately 75 s and accelerates up to reaching a distance less than 1 km from the head truck; in this case, the management system 10 controls the second truck so as to make it decelerate, for distancing it from the first truck. In a second simulation, the second truck arrives at this danger abnormal status after 45 s; in this case, the management system 10 can send to the second truck alert messages at each overtaking. In a third simulation, the head truck enters a tunnel and the following truck, leaving after 100 s, comes close to the entrance of the tunnel; at this point, the management system 10 activates the alert notification, so as to make it decelerate. In all these cases, it was verified that the management system 10 significantly reduces the risk of road accidents.
-
Based on an examination of the characteristics of the invention implemented according to the present invention, the advantages that it allows obtaining are evident.
-
In particular, the ADRTrack 10 exploits the messages of the CAM and IVIM type for improving the road safety, optimizing the management of the transport of dangerous materials so as to safeguard the safety of people and environment. In fact, the management of the ADR vehicles represents a significant challenge on the road networks, given the intrinsic risks associated with the transport of dangerous materials on the road networks.
-
Finally, it is clear that modifications and variations can be made to the invention described and illustrated herein without thereby departing from the scope of protection of the present invention, as defined in the appended claims.
-
For example, the different embodiments described can be combined with one another so as to provide further solutions.
-
Furthermore, the management system 10 can also implement tracking filters, for example tracking of the Bayesian type, for improving the precision of the monitoring of the distance between the vehicles 12.
-
Furthermore, il management system 10 can implement detection techniques of the driving abnormalities, for identifying and notifying potential dangerous driving behaviors (e.g. to the drivers but also to the suitable road control bodies).
-
Although the foregoing mainly describes the case of vehicles 12 on the motorway section defining an HADRV group, it is evident that what previously described applies in a manner entirely similar also to other types of roads (e.g. provincial roads, etc.) and that thus the HADRV group can be generalized to any group of ADR vehicles that are first neighbors to one another along a respective road section (i.e. to a pair of ADR vehicles that are traveling along a road section without other ADR vehicles interposed between them).
-
Furthermore, the number of vehicles 12, as well as the number of groups of vehicles 12, can vary with respect to what previously described. In particular, the operation of the management system 10 allows obtaining the information on the alert level for each group of vehicles 12 considered.
-
Furthermore, although so far a tunnel has been mentioned as a risk site for the vehicles 12, the previous considerations can be generalized to any risk site placed along the road section and through which the vehicles 12 must pass (e.g. the tunnel). Such risk site is defined as an environment or a zone that the vehicles 12 traverse during their journey and that poses greater risks for the safety of the vehicles 12, or which increases the potential damage of a possible accident of one of the vehicles 12 with respect instead to a standard case (e.g. with respect to the case of open route).