ITPD20120278A1 - INTELLIGENT ROAD INFRASTRUCTURE - Google Patents

Description

INTELLIGENT ROAD INFRASTRUCTURE

DESCRIPTION

INTRODUCTION This patent relates to road infrastructures and in particular concerns a new road infrastructure and road infrastructure management method.

EXISTENCE OF ITS SYSTEMS Road infrastructures equipped with computer systems for the production, management and exchange of data called ITS (Intelligent Traffic System) are known. These computer systems allow road managers to detect, acquire and manage information of various kinds relating to the infrastructure. The information may, at the discretion of the road managers, be transmitted to users in various ways. The goal of ITS systems is to enable road users to be better informed, to make safer, more coordinated and smarter use of transport networks.

EXISTING PATENTS US 2007/0021906 concerns a road with an information system based on the Internet protocol where a road user sends a specific signal in order to establish a connection with a server and the user can download information on the road in real time, as a function of its current coordinates. While this patent relates to specific dialogue protocols between a moving vehicle and a ground system, the present invention relates to a computer network which allows, among other things, road users to connect to it with their own mobile devices. The computer network supporting the road, however, maintains its characteristics and ensures the advantages described below even in the event that there are no users connected with their mobile devices. This also means that access to the road and to the main services it offers is not precluded to those who are not equipped with particular technologies on board their vehicle.

US2009 / 0105932 illustrates a method for providing traffic information, which, unlike the present invention, is not based on the existence of a specific computer network superimposed on the road infrastructure; moreover, the present invention is not designed to convey only information relating to the state of traffic.

EP 1879150 relates to a method of transmitting information in a traffic monitoring system, comprising a main unit and a mobile device. The mobile device receives a signal from the head unit to initiate a broadcast on a dedicated channel. This patent therefore requires a specific technology, while the present invention, thanks to its opening characteristics, allows the use of different types of devices via cable or radio to access or contribute to the flow of information.

PROBLEMS OF CURRENT ITS SYSTEMS: REDUNDANCES The current ITS systems with which roads are currently equipped have some drawbacks. The current infrastructure and traffic monitoring and regulation systems have not in fact been conceived with a unitary and reciprocal integration perspective, such as to allow redundancy in a simple way. On the contrary, the practice of keeping specific functions separate involves costly redundancy of communication systems and equipment, each dedicated to a specific technology for a specific function. The high cost of implementing the redundancy of each single system consequently obliges to keep the redundancy to the minimum number, thus decreasing the safety and robustness requirements.

PROBLEMS OF CURRENT ITS SYSTEMS: CONSTRAINTS TO DESIGN It is currently impossible to rely, from the moment of designing the road infrastructure, on a single and open system for the management of technologies for monitoring and regulating the infrastructure and of traffic. Currently it is in fact necessary to conceive the infrastructural project already linked to a specific existing technology, unnaturally binding an infrastructural project to IT specificities susceptible to change much more rapidly than the useful life of the work.

The same problem arises in cases where subsequent changes to the infrastructure are required that are not foreseen in the initial plan of the work and in the maintenance operations of the work itself. The closure of existing technologies in fact obliges the maintenance technician to be linked to them for the entire life of the work, with risks of supply, obsolescence and poor cost control of the devices adopted.

PROBLEMS OF CURRENT ITS SYSTEMS: CLOSURE AND LACK OF INTEROPERABILITY Current ITS systems are â € œclosedâ €, ie all the devices that make up the subsystems can communicate with each other in a coherent but exclusive way. All the data on which the action of each individual subsystem is based come from devices of the subsystem itself and are used for the purposes of the ITS system. The subsystems can interact with each other through communication standards but do not naturally interact outside the ITS network, except through specific service portals. This closed supply chain does not allow effective, efficient and rapid direct interaction between different systems, making road management expensive, complicated and slow, often with the need for direct interaction by one or more operators.

PROBLEMS OF CURRENT ITS SYSTEMS: CONSEQUENCES OF THE LACK OF INTEROPERABILITY The closure of current ITS systems, in fact, is characterized by the closure of one system in relation to another: a system does not know ex-ante the existence, the characteristics and the functionalities made available by other systems possibly present on the same infrastructure. Consequently, a system cannot normally and easily inform, alert or activate actions on such different systems.

The reciprocal closure of the current systems not only poses problems at the level of operational interoperability but also at the level of information and representation of the road model as a whole: the impossibility of easily and effectively integrating the data of all the subsystems makes it difficult obtain derived data and be able to construct coherent representations on the state of the road works as a whole at a given moment.

Finally, the systems are closed to external users and users. In fact, a system cannot be interrogated or provide information directly to general users, the internet, third party services, etc.

PROBLEMS OF CURRENT ITS SYSTEMS: CONSEQUENCES FOR THE OPERATING CENTRAL The current â € œclosed circuitâ € ITS systems collect and convey information to the control center each on its own account. For example, considering four subsystems, energy and lighting, variable message panels, CCTV cameras, weather stations, each of these subsystems conveys proprietary data to its own terminal in the control room. There are therefore four terminals, one for each system, and sometimes a specific operator is also required for each system. This approach does not allow communication between different systems, except through the interaction with the operators of the control center. Furthermore, a system that bases its operation on human interaction is scarcely automatable, involves inefficiencies and can be subject to errors.

PROBLEMS OF CURRENT ITS SYSTEMS: INJECTION AND WITHDRAWAL OF DATA FROM AND OUTSIDE Closing the system also limits the passage of information to external users: you have to go through the control center, which selects and filters, often manually, the information to be given to users. This information can be entered on a web service, which connects to the internet and finally reaches users, or it can be limited to the content of a variable message panel, with the result that the only way to access it is to pass through proximity of the panel and to read its contents. Also in this case, the information transmission chain is unstable and there are situations in which there is a risk of introducing errors of interpretation or understanding.

THE SOLUTION TO THE PROBLEM: UNION OF ROAD WORKS, IT NETWORK AND DIGITAL PLATFORM To overcome all the aforementioned drawbacks, a new type of intelligent road infrastructure was designed, which was created together with a widespread computer network and a digital platform intended to virtualise the physical infrastructure. Said digital platform, governed by specific software, consists of a data transmission network, a plurality of servers and a plurality of devices and sensors distributed along the road infrastructure, connected to each other with or without cables. Each server, device or sensor is physically located in a specific stretch of road, but can collect, store, sort or retain information relating to other points on the network than where it is installed. Furthermore, each device is home to redundant software and information, in order to guarantee data recovery in the event of accidents, failures or power outages and to represent widespread intelligence.

THE SOLUTION ALSO FOR EXISTING ROADS The new infrastructure resulting from the superimposition of a road network and an open computer network can also be created by superimposing a computer network on an already existing road network, on which some infrastructural interventions must in any case be planned for the ™ installation of the computer network and equipment connected to it.

THE OPEN NETWORK The new road and IT infrastructure is characterized by an open approach to solve the problem of the closure of current systems: the goal is to allow all the ITS devices installed on it to interoperate efficiently with each other. even if equipped with different communication protocols, as well as allowing these devices to interact with third parties even outside the infrastructure itself: these third parties include companies, organizations, other non-ITS objects but also individuals and users, through their electronic devices, smartphones or tablets, the web, etc ... The system conceived for the present invention in any case allows the network administrator to control the authorizations of each device in the network and of each user, in order to ensure control over access to data, raw or processed. This aspect makes it possible to meet the needs of protection of sensitive data, security of data in transit on the network and certification of specific information.

THE ADVANTAGES OF OPENING The main advantage of the open system of the present invention is that of allowing road managers, road users and third parties, such as law enforcement agencies, to collect and inject data into the system, with appropriate permissions and with the connections normally available to everyone for internet access (cable networks, GPRS networks, HSDPA networks, wi-fi networks, bluetooth connections, etc). This opening also guarantees the possibility of integrating existing technologies and introducing new technologies in the design and management of a road infrastructure, as well as making the dialogue from / to each physical device located on the infrastructure itself simple and immediate.

The opening also makes it possible to make the work expandable, modifiable and maintainable, making its systems evolve in accordance with the state of the art and without limiting constraints deriving from pre-existing technologies.

The opening also allows in-vehicle sensors or usersâ € ™ electronic devices to contribute to the flow of data.

Even in the control center, operators have an integrated view of all systems, with a synoptic picture of the entire road network that more faithfully represents the state of the network.

TYPES OF DATA IN THE OPEN NETWORK The open system of the present invention contains two types of information: the â € œdataâ € collected by the system (for example read by the sensors) and the â € œactuationsâ € received (commands sent to the actuators). The collected data, which can be used by the system or transmitted to third parties, are not only granular and simple data such as those collected by the sensors, for example the air temperature at a given point, but can be advanced information, calculated by the system ITS by integrating masses of data, such as the flow of traffic in a given section. The practical impact of the open approach compared to the traditional approach is the transformation of the road from a â € œblack boxâ € to a â € œdata bankâ € of information to be used to create and provide services to third parties. The data is exposed and can be consulted through interfaces and standard data formats commonly used for exchanging information on global networks, such as XML / Javascript / JSON or REST, etc.

The information relating to the implementations, in the same way, represents the set of actions, events and commands that the system intrinsically generates or that it receives from the outside. This information is also stored by the system and can be used within the system or made available to third parties through appropriate communication interfaces.

DATA PROCESSING WITH APPLICATION INTERFACES IN THE OPEN NETWORK Infrastructure managers or third parties can also develop specific technologies to interact with users (in particular electronic devices, smartphones and tablets of users) offering targeted information on the journey, optional services related to travel, parking, service areas, refueling, insurance, security, etc. or commercial proposals. This is achieved by making the application interfaces (API) of the digital platform available to third parties: it is therefore possible to introduce countless applications and services that make use of data from ITS systems in many areas, particularly to the benefit of users but also services and third parties in general. The application interfaces allow you to interact with the platform both by requesting and receiving data collected, stored or processed by the digital platform, and by sending data, actions and commands to the digital platform. The platform implements appropriate defenses and security controls to ensure that access to data (or the ability to send data and implementations) is allowed only to certain actors in accordance with certain terms of service and security requirements.

THE SUPER-PROTOCOL The basic concept of the open network is the possibility that all the ITS devices and systems located along the work communicate and interoperate with each other. The communications between all the devices of the computer network described above take place through a specific super-protocol, or single protocol, which solves the existing problems of non-communication between the different IT systems available today for monitoring and regulating the infrastructure and traffic and at the same time allows to increase the number of subjects who actively participate in the flow of information. This super-protocol of open dialogue is built on top of the single communication protocols of the ITS devices and is exposed to the outside of the new infrastructure. through the APIs previously described. The ITS systems currently existing in the new computerized road infrastructure can therefore be interfaced with each other through said common super-protocol, which therefore allows the interaction of said systems and the integration of the data produced by them. The super-protocol pervades the entire digital infrastructure and resides in specific devices, defined gateways and described below, which represent the physical connection between the individual devices, with their specific cabling and their proprietary communication code, and the computer network. common. This super-protocol is conceived in such a way as to allow the control of the data flow, which must always respond to legal requirements such as the protection of sensitive data. The possibility of intercommunication by the various devices and the improved possibility of access to data by road users or third parties, therefore, do not imply the uncontrolled and uncertified movement of information, but on the contrary involve an orderly flow of data placed available to those authorized to consult them.

The super-protocol provides all the dialogue tools that allow interfaced devices, systems and applications to:

- declare and describe themselves, correctly entering the digital platform;

- declare and describe the data or services that you are able to provide to the platform or the commands and implementations that you are able to receive from the platform;

- declare and describe the levels of privilege, security and control that are required to provide data or receive commands from / to third parties or from / to the digital platform;

- request and access the data of the digital platform, whether they are native (coming from sensors) or derived through processing or integration of information;

- send commands, data and actuations to the digital platform;

- interact directly with the ITS devices and systems of the digital platform;

- interact with services and applications on the digital platform; - interact with users and third parties who insist on the digital platform. These operations are allowed through the super-protocol, always in accordance with appropriate control and security measures that ensure that each actor involved on the digital platform acts in accordance with pre-established access and control privileges.

THE ADVANTAGES OF THE SUPER PROTOCOL This super-protocol allows to solve the current ITS problems, previously exposed:

- the super-protocol, allowing the integration of multiple ITS systems, makes it possible to create redundancy systems, even with high numbers and robustness, with a lower cost than current redundancy systems, with low numbers and robustness;

- the super-protocol allows ITS devices even of different generations / producers / standards to interoperate efficiently, thus increasing the possibility of choice during the construction of the infrastructure, probably with a reduction in control costs on a single integrated system as well as in maintenance operations and in any expansion and modification operations; - the super-protocol, making possible the massive and complete integration of data relating to the road infrastructure, makes it possible to create more capable, efficient applications and services at a significantly lower cost than similar products currently available on the market;

- the super-protocol, making possible the interaction of third parties without requiring in-depth knowledge of ITS systems and devices and their specific protocols, reduces development times and costs for applications and solutions that rely on the infrastructure.

EXAMPLE OF USE OF THE SUPER PROTOCOL The characteristics of the new infrastructure will be better clarified by the following description with reference to the drawing tables, attached as a non-limiting example.

Figure 1 shows a schematic example of a proposed implementation for ITS systems in the new road infrastructure, where ITS systems (1, 2, 3, 4), for example, weather sensor network (1), message panels variable PMV (2), cameras (3) and energy / lighting (4) each communicate with their own code and specific wiring: (5) for the weather sensor, (6) for the variable message panel, (7) for the camera and (8) for the energy / lighting. Thanks to the gateways (9), described below and an integral part of the present invention, all the devices can connect to the common computer network by interacting with the super protocol, indicated by a dashed line (10). Moreover, thanks to this common super protocol, the systems can interact with each other also directly, as indicated with a continuous curved line (11) which shows for example the direct interaction between the camera system (3) and the PMV system (2), without go through the control center (12). In this control center (12), the operators have an integrated view of all the systems, with a synoptic picture of the entire road network that more faithfully represents the state of the network. In order to also exemplify the control of the data flow, and in particular the direct link (11) between the variable message panel (2) and the camera (3), consider that the variable message panel, in the case where the camera frames a stationary vehicle, it will not be able to represent the relative warning (accident, queue, etc.) unless the control center personnel responsible for carrying out the checks have recognized and certified the situation described. The variable message panel, on the other hand, can directly query the camera to receive, for example, data on lighting conditions and adjust the brightness of the message accordingly.

DATA FLOWS THROUGH THE SUPER PROTOCOL The super protocol was conceived so that communications between road users, devices and infrastructure managers can be guaranteed within the infrastructure object of the present invention. To create the system, all the â € œfunctionsâ € involved in the system were cataloged and analyzed, explaining the communication needs between each element and the others in a network diagram. These â € œfunctionsâ € represent a broader concept than simple devices, users or other figures such as the network manager or road user. â € œFunctionâ € is in fact a macro-area in which non-homogeneous concepts are inserted. For example, the functions relating to â € œmonitoringâ €, dedicated to knowing what is happening on the road, are mainly represented devices for surveying and measuring (temperature, speed, etc.); the â € œthematic campaignsâ € function, on the other hand, represents, in the context of certification and publication of data, for example, a press campaign to raise awareness on road safety. The latter, although not strictly part of the road infrastructure, must be based on traffic data, accident statistics, indications on average speed, meteorological data, etc. and therefore it represents a particular method of accessing and retrieving information collected, processed and stored in the system in question. The result is the diagram in Figure 2, in which each box represents a specific source or destination of data and each link represents a flow of information. These flows can be electronic (for example two systems that communicate with each other) or not (for example the road user reading a variable message panel), they can represent simple interactions (the sampling of a temperature data provided by a sensor) or complex (access to a historical database through a particular query aimed at obtaining specific information). The diagram is not exhaustive, as it is in the philosophy of the system the possibility to add further devices or to involve an even greater number of figures; nevertheless it is believed to have considered a number of functions such that all the relationships highlighted between these functions are exhaustive of all the various types of information flows necessary for the correct functioning of the network conceived.

FUNCTIONS, DEVICES AND RELATIONS In the image in FIGURE 2 the 34 boxes marked with the letter A, from A1 to A34 represent the monitoring functions: the devices installed along the road perform surveys and measurements, even automatically. Specifically they identified: weather and environment group: (A1) rain detection, (A2) wind detection, (A3) snow detection, (A4) fog detection, (A5) ice detection, (A6) cameras video surveillance, (A7) smoke detection, (A8) air pollutant detection, (A9) noise detection, (A10) flood and flood detection, (A11) brightness detection; road body group and appurtenances: (A12) monitoring of landslides and rock falls, (A13) monitoring of the stability of the road platform, (A14) monitoring of the stability of works of art; road surface group: (A15) detection of the veil of water on the pavement, (A16) detection of the roughness of the pavement, (A17) detection of the regularity of the pavement; traffic group: (A18) vehicle counting, (A19) vehicle classification, (A20) instant or average speed detection, (A21) vehicle license plate recognition, (A22) vehicle spacing detection, (A13) ( A29) detection of accidents, (A30) detection of fire, (A31) detection of obstacles, pedestrians or animals in the carriageway, (A32) presence of dangerous goods in transit, (A33) detection of queues; emergency group: (A34) SOS columns.

The 4 boxes identified with the letters B, from (B1) to (B4) represent the planning and scheduling of interventions on mobility: management group: (B1) tariff policy interventions, (B2) campaigns to suppress conduct contrary to the code of the road (â € œenforcementâ €), (B3) interventions for reasons of public order; traffic group: (B4) infrastructural and maintenance interventions.

The 5 boxes identified with the letters C, from (C1) to (C5) represent the definition of the tariff policies: tariff profile group: (C1) distance traveled, (C2) congestion level, (C3) day and time slot, ( C4) customization of the toll (for example exemptions); toll archive group: (C5) historical database.

The boxes identified with the letters D, from (D1) to (D4) concern the management of the different ways in which the toll is collected: single group: (D1) payment with devices on board the vehicles, (D2) payment at the service areas, (D3) payment via computer via the internet, (D4) subscription payments.

The boxes identified with the letter E, from (E1) to (E7) concern the control, that is the processing and activation in real time of measures and interventions on traffic and mobility: scenario simulation group: ( E1) ordinary events, (E2) group of extraordinary events (disasters, public order events, ...); group for the definition of control interventions: (E3) ramp metering, (E4) closing of sections, (E5) dynamic management of the emergency lane, (E6) lane control (control of the use of lanes), group of traffic archives: ( E7) historical database.

The boxes identified with the letter F, from (F1) to (F12) concern the identification of risk scenarios with the activation of preventive, active and passive safety interventions: weather and road conditions group: (F1) poor grip, (F2) poor visibility, (F3) strong wind; claims group: (F4) accident, (F5) fire; other hazards group: (F6) vehicle in the wrong direction, (F7) obstacle in the roadway, pedestrian, animal; (F8) singular points and maneuvers, (F9) dangerous goods, (F10) infrastructural risk factors; monitoring group: (F11) incident monitoring; archive group: (F12) historical database of risk scenarios.

The boxes identified with the letter G, from (G1) to (G4) concern the execution of maintenance interventions on the road system: single group: (G1) scheduled maintenance interventions, (G2) extraordinary maintenance interventions, (G3) inspections in the infrastructure, (G4) historical database.

The two boxes identified with the letter H, (H1) and (H2), concern short-term (H1) and long-term (H2) construction sites.

The two boxes identified with the letter I, (I1) and (I2), concern the surveillance of works of art: systems of the galleries (I1) and stability (I2).

The 12 boxes identified with the letter J, from (J1) to (J12) concern the optimization and management of the available energy sources: generation and acquisition group: (J1) wind generators, (J2) photovoltaic panels, (J3) hydrogen, (J4) piezoelectric generation, (J5) electricity, (J6) fossil hydrocarbons; distribution group: (J7) hydrogen, (J8) electricity, (J9) fossil hydrocarbons; energy balance group: (J10) generation and acquisition, (J11) energy consumption, (J12) energy balance.

The 7 boxes identified with the letter K, from (K1) to (K7) concern the identification of critical scenarios for the activation of interventions to protect the environment: atmospheric pollution group: (K1) emission, (K2 ) dissemination, (K3) intervention strategies; noise pollution group: (K4) emission, (K5) diffusion, (K6) intervention strategies; environmental impact group: (K7) environmental impact group.

The 5 boxes identified with the letter L, from (L1) to (L5) concern the communication and certification of information, for the disclosure of the manager's actions and policies and the production of assessments and certifications: environmental impact group : (L1) energy saving, (L2) air pollution, (L3) noise pollution; traffic and traffic impact group: (L4) road safety, (L5) thematic campaigns. The boxes identified with the letter M, from (M1) to (M5) concern the car parks and rest areas along the road: group of parking areas: (M1) seat reservation, (M2) distribution of services (energy, connection internet, â € ¦); service area group: (M3) fuel distribution, (M4) hydrogen distribution, (M5) electric vehicle charging.

The two boxes identified with the letter N, (N1) and (N2) relate to the safety of the infrastructure and the prevention of crimes: (N1) relates to safety in parking areas and (N2) to safety on the way.

The 9 boxes identified with the letter O, from (O1) to (O9) concern the actions to support the sanctioning of infringements of the Highway Code: group of infringements: (O1) high speed, (O2) failure to respect the safety distance, (O3) driving in the wrong direction, (O4) reversing, (O5) overtaking, (O6) driving in the emergency lane, (O7) passing with a red light, (O8) failure to comply with the ban on transit of vans and tarpaulins in the event of strong wind; archive group: (O9) historical database.

The 6 boxes identified by the letter P relate to emergencies and emergency response activities: motorway manager group: (P1) traffic auxiliary interventions; other entities group: (P2) police interventions, (P3) health interventions, (P4) fire brigade interventions, (P5) interventions for natural disasters and catastrophes, (P6) mechanical rescue interventions.

The four boxes identified with the letter Q, from (Q1) to (Q4) concern the real-time information transmission functions: (Q1) tariffs in force, (Q2) traffic status, (Q3) risk scenarios, ( Q4) other events. The 13 boxes identified with the letter R, from (R1) to (R13) concern the terminals of the information flows, represented by road users and other subjects external to the system: single group: (R1) road users, (R2) Traffic Police, (R3) central e-call, (R4) medical service 118, (R5) Fire Brigade, (R6) Civil Defense, (R7) mechanical rescue vehicles, (R8) information media, (R9) collection of tolls, (R10) variable message signs, (R11) institutions, (R12) energy generators and suppliers, (R13) lighting systems.

As an example, see box (A1) in the diagram relating to the rain detection system. There is no arrow pointing to the box, as it is a device that does not receive input data, but produces it according to atmospheric conditions. There is a connection with box (F1), i.e. the identification of risk scenarios due to poor adherence, then with box (F2), i.e. the identification of risk scenarios due to poor visibility and with box (O1) relating to infringements of the speed limit, which is conditioned by the presence of rain. Again in the example of box (A1), this does not communicate directly with the variable message panel (R10): the correct data flow foresees that the box (F1) relating to poor adherence, which represents a decision-making process that takes place at the operations room, fill in the box (E6) relating to lane control (ie representative of a specific series of actions to be taken downstream of a decision-making process) and it is the latter that finally feeds (R10). This diagram, therefore, represents not only the mere electrical connections (which must in any case be guaranteed), but also the decision-making processes and the procedures necessary for the circulation of appropriately certified information.

SUPER PROTOCOL SPECIFICATIONS The super-protocol is the common interface and interoperability protocol with which all the connections shown in figure 2 are made, which require the transmission and reception of data and implementation in electronic format. Said super-protocol therefore constitutes the interface of the new infrastructure as a whole and, if on the one hand, it can be declined and translated into the specific / standard language of each ITS device, on the other hand, it can be exposed to the outside through protocols standard, such as XML / Javascript. The super-protocol is the native language of the digital platform of the invention. The platform is a distributed system of heterogeneous digital elements that constitute the internal actors of the platform itself (gateway, server, computers in the control room, etc.) which communicate with each other through the super-protocol.

These elements are characterized by the fact that they have a common firmware / software component (the Operating System or â € œkernelâ € of the platform) which makes them part of the same whole.

A part of the kernel on board the platform actors is intended for communication and allows each of them to:

- understand correctly and completely the super-protocol that governs the platform;

- be able to fully describe itself, its functions, its operating, security and access requirements, its characteristics and its unique identification parameters;

- being able to navigate the platform network, reaching and interacting with each element of the network, be it an internal element or an external element;

- being able to correctly manage the flow of information on the network, requesting, selecting or entering data in accordance with the operating parameters of the platform;

- to be able to request information from the platform and the actors involved in it at a given moment;

- to be able to receive actuations and commands from the platform and from the actors involved in it at a given moment;

- to be able to enter notifications, alarms, urgent information, status changes and in general any form of digital notification signal that must be sent within the platform into the platform.

The super-protocol is the dialogue interface through which the kernels on board the platform actors communicate with each other.

In the event that certain information must be collected (or sent) to systems and elements that do not natively use the super protocol (such as pre-existing ITS systems or third-party elements), appropriate gateways deal with the translation of the super-protocol into the specific protocol.

The translation of the super-protocol into specific protocols does not only take place at the level of the gateways to ITS equipment and systems, but can also take place in other points of the platform, for example where it is necessary to communicate with third parties and with devices such as user tablets, computers external to the infrastructure, websites and so on. In this case, appropriate gateways will translate the super-protocol into the protocols of the devices and end users.

REPRESENTATION OF THE ROAD NETWORK AND IT NETWORK USING A GRAPH The infrastructural network and the IT network superimposed on it are both schematized with a graph for the purposes of infrastructure management, network administration, system representation and location spatial information. A graph is composed of nodes or vertices, entities that correspond to a point in space or time, connected by arcs or lines. The centroid is a particular type of node, placed in a barycentric position with respect to a â € œclusterâ € or group of elements, in which, by approximation, all the elements of the cluster or group are placed; normally the centroid is a generator / collector of elements and, unlike the other nodes, it cannot be crossed. In the most general case, the graph G is defined as a set composed of two different subsets, finite and not empty: the set of nodes, indicated by N, and the set of edges, indicated by A:

G = {N, A}

A road graph is composed of a set of nodes and arcs that are predefined to reproduce the road network to which it refers; if the road network is modified, with extensions or new connections, the graph will also be updated. An example is shown in FIGURE 3, where the nodes (N) and the arcs (A) of a stretch of urban network are shown, in which there is also a centroid (13). In FIGURE 4, on the other hand, the example of a motorway junction is detailed, again distinguishing arches (A) and nodes (N). Note that in the motorway section there is also a variable message panel (14), which, however, is not schematized in the road network. Similarly, the information transfer network will also be based on a graph: the nodes are the physical connections of the IT infrastructure and the arcs are the channels (via cable or without cables) through which the data reaches the nodes and they pass through them to reach the final terminators or centroids of the graph. Figure 5 shows an example of integration between the road graph and the communication network graph associated with the road, with the information arcs (15) and the vehicular arcs (16). In this case the variable message panel (14) corresponds to a specific centroid node (17) in the data network graph.

PATHS IN THE GRAPH Several paths can be defined within the graph which are ordered subsets of nodes or arcs used by an element belonging to the origin centroid to move to the destination centroid. In the road graph the routes represent movements of vehicles in the infrastructure while in the computer graph they concern data movements between devices.

COMPATIBILITY OF THE GRAPH WITH NAVIGATION SYSTEMS AND WITH OTHER INFORMATION ON THE TERRITORY The representation of the road and computer network by means of a graph is designed to be compatible with the graphs used for the representation of road networks in applications dedicated to satellite navigation. Once the road graph has been established, it is also possible to enrich it with environmental and operating data from the infrastructure and apply known algorithms on the subject to improve flows, routes, detours in case of need, traffic regulation.

THE INNOVATION OF THE DYNAMIC GRAPH The innovation of the new infrastructure consists in using a dynamic information graph capable of adapting, in real time, to new conditions of information exchange; An example is given below that better describes the concept exposed. The presence of a sudden and unplanned event, for example an accident (indicated with (18) in FIGURE 6), requires the activation of a series of functions including the location of the event and the timely information to vehicles that arrive. The information of the accident occurred, with the indication of its position on the road, is acquired by the system and processed to operate, in real time, the appropriate and necessary actions, with the creation of a new dynamic node, indicated with (19) in FIGURE 6.

Some of these actions concern the transmission of information to the emergency services, to any variable signage, etc .; it will then be transmitted to the centroids or terminators of the graph already provided and designed for this purpose, through the predetermined graph Gp, thus defined:

Gp = {Np, Ap}

where Np is the set of nodes of the design graph and Ap the set of edges of the design graph.

However, since the new infrastructure is an open system, the information must be made available to all users authorized to receive it. Therefore, new terminator nodes or destination centroids to which the information must be transmitted in order to be received will have to be created dynamically (indicated with (20) in FIGURE 6 and representative of the vehicles upstream of the accident).

Therefore the notation of the dynamic graph Gd will be the following:

Gp = {Np, Ap} => event => G = {Np Nd, Ap Ad} where Nd and Ad are the sets, respectively, of nodes and arcs generated dynamically when the event occurs.

The dynamism of the graph structure therefore requires algorithms capable of adapting, in real time, to the new characteristics of the network of nodes and arcs.

EXAMPLE OF DYNAMIC GRAPH As FIGURE 6 schematises an example of an accidental event in a new infrastructure, so FIGURE 7 shows the comparison between a predetermined graph before an event and the dynamic graph after the event. In fact, FIGURE 7 shows a schematization of the example shown with a detail of the part of the information graph affected by the event. Before the event, the information system works in its predetermined configuration: when the information reaches node (21) they are routed, according to their characteristics, to node (22) and to the rest of the network: nodes (23) and (24).

When the incident event occurs, the new node (19) generated by the event will transmit the information corresponding to it not only to the adjacent nodes, as in the previous case, but also to the new user centroid node (20), through the new arc (25), both dynamically generated.

THE DYNAMICITY OF THE GRAPH AND THE RELATIONSHIP WITH INFORMATION An important aspect of this approach is the possibility of the new infrastructure to recursively draw on its own archives and databases: in this way, when appropriate algorithms highlighting the high frequency of generation of â € œtemporaryâ € nodes in the same position, the system itself would be able to propose the creation of a â € œfixedâ € node over time. Likewise, the system could highlight the underuse of a node defined as "static" in the design phase, leaving the manager the choice of making it "dynamic" and making the hardware available in another point of the network.

THE â € œGATEWAYâ € DEVICE The digital network of the new infrastructure is made up of a plurality of devices called doors or â € œgatesâ € distributed along the entire road network. These gateways are responsible for dialogue with ITS systems located along the road network and for managing the flow of digital information on the digital network. Through the gateways, the various existing or new equipment for monitoring and regulating the infrastructure and traffic can be put into communication with each other, using this super-protocol. Gateways are the elements where the function of translating the common superprotocol into the specific protocol of this or that ITS system or equipment takes place. Consequently, the individual gateways implement all the physical hardware, logical and software functional characteristics capable of allowing interaction with ITS systems and equipment.

RELATIONSHIP BETWEEN ITS SYSTEMS AND GATEWAY In the new infrastructure, each ITS system maintains its own specific communication protocol, but instead of communicating directly with the control center, it communicates with a door or â € œgatewayâ € of the new infrastructure. Said port translates the native protocol of the system into said universal super-protocol; the information coming from the various systems, translated into the super protocol, can be easily integrated and therefore can be directed to the control center on a single integrated system.

GATEWAY AND DATA FLOW OUT OF THE SYSTEM Furthermore, each element of the new infrastructure, capable of speaking in the native super protocol, is equally capable of communicating outside the infrastructure, filtering the information automatically. These ports also allow managers, users and third parties in general to interact with the IT network of the infrastructure. Thanks to the gateways, the users of the new infrastructure can access the information of the infrastructure itself: through websites managed by the Control Center / Service Center, similar to what is currently happening and / or through direct connection with automated databases that aggregate and put in relation to each other large amounts of information of the infrastructure, and / or - through the direct connection with said doors or â € œgatewaysâ € that collect point-like and local information. The data are therefore much more usable and can reach users in real time, without the need for interaction by the operators, an interaction that would normally lead to great latencies and therefore great inefficiencies in the current highways and infrastructures.

GATEWAY AND INFORMATION ON THE GRAPH The information on the graph is distributed on board the physical devices that make up the new infrastructure, i.e. the doors or â € œgatewaysâ €, so that each device can have references of its own position, position and role of the nodes and of the information it collects, sorts, sends and shares.

STRUCTURE, REQUIREMENTS AND FUNCTIONS OF THE GATEWAY Said gates or â € œgatewaysâ € of the new infrastructure are hardware / software components designed to be distributed on the infrastructure and which manage the information called â € œlocalâ €, i.e. the information collected, generated or distributed in the areas physically adjacent to the position of each door itself.

The functions of each of these doors are:

- management of direct physical interfacing with the ITS subsystems present in a particular road section, for example lighting, energy, sensors, signs, etc.;

- translation of the protocols and information collected by local devices into the super-protocol;

- management of data entry and exit to / from the infrastructure to third parties through the application interfaces (API Open) of the infrastructure itself;

- management of one's own portion of road representation graph. Each port includes a hardware component and a software component, which can be schematized for example as follows:

- Hardware:

- hardware core or hardware fixed structure: processor, memory, flash, power supply; said structure being identical for each door;

- hardware connectivity through a specific dialogue driver for a specific ITS system, where said dialogue driver is a function of the ITS system to be connected to - eg. RS485, Ethernet, CAN, â € ¦ .;

- Ethernet / fiber optic connector, for connection to the backbone of the infrastructure;

- any hardware for direct connection without cables to users.

- Software:

- Operating system: basic software for basic door operations;

- specific software to create infrastructure abstractions;

- specific software translator for the ITS system to which it is connected, said translator being specific according to the system to be connected;

- possible dialogue software towards users.

EXAMPLE OF GATEWAY USE FIGURE 8 shows the complete set-up of the information flow in an ITS system with doors or â € œgatewaysâ € in the new infrastructure. Each ITS system (1, 2, 3, 4) maintains its own protocol but instead of communicating directly with the control center (12), it communicates with a port (9), which translates the native protocol of the system into said super-protocol (10). The information from the various systems (1, 2, 3, 4), translated into the super-protocol (10), can be easily integrated and thus can be directed to the control center (12) on a single integrated system.

Being integrated, the information of the different systems can freely interact. Furthermore, each element of the new infrastructure capable of speaking in the super protocol (10) is equally capable of communicating outside the infrastructure, filtering information automatically. as a complement to FIGURE 1, FIGURE 8 shows the users (26) of the new infrastructure who access the information through websites (27) managed by the control center / service center (12) or can communicate through direct connection with automated databases or â € œaggregatorsâ € (28) which aggregate and relate large amounts of information to each other.

Users (26) can also communicate through direct connection with said devices called doors or â € œgatesâ € (9), which collect point-like and local information. The data are therefore much more usable and can reach users in real time, without the need for interaction by the operators.

CLOSING FORMULA These are the schematic modalities sufficient for the skilled person to realize the invention, consequently, in concrete application there may be variations without prejudice to the substance of the innovative concept.

Therefore, with reference to the above description and the attached tables, the following claims are expressed.

Claims (1)

CLAIMS 1. Road infrastructure comprising a road network and a computer network for managing said road network, said computer network in turn comprising: â € ¢ a plurality of servers, each dedicated to a section of said road network and capable of collecting, containing and providing information, â € ¢ a plurality of devices and / or sensors and / or ITS systems distributed on said road network and connected to each other with or without cables, characterized by the fact that it also includes a plurality of electronic devices, doors or `` gateways '', for the management of the flow of information, distributed along said road network, and where, through said doors, all the devices and systems of the computer network communicate between them and / or with a control center and / or with third parties, using a specific super-protocol or single communication protocol. 2. Road infrastructure, as per claim 1, characterized in that each of said gates translates the native protocol of the computer network system or device connected to it into said unique super-protocol. 3. Road infrastructure, as per claim 1, characterized by the fact that each of said gates manages data input and output to / from the infrastructure to third parties through application interfaces. 4. Road infrastructure, as per claim 1, characterized in that each of said doors comprises a hardware component in turn comprising: a fixed hardware structure, substantially identical for each door; hardware connectivity devices through a specific dialogue driver for the particular device or system of the computer network; devices for Ethernet connection and / or fiber optic connector, for connection to the backbone of the infrastructure. 5. Road infrastructure, as per claim 1, characterized in that each of said doors also includes the hardware for direct wireless connection to the users. 6. Road infrastructure, as per claim 1, characterized by the fact that the data of said computer network are exposed and can be consulted from the outside through standard interfaces, such as XML / Javascript / JSON or REST, etc. 7. Road infrastructure, as per claim 1, characterized by the fact that the data of said computer network can be consulted by users: through websites managed by the Control Center / Service Center and / or through direct connection with automated databases that aggregate and place in relation to each other large amounts of information of the infrastructure, and / or through the direct connection with said ports. 8. Road infrastructure, as per claim 1, characterized by the fact that the data of said devices or systems of the computer network can be entered from the outside, and can also be collected by sensors on board vehicles or by sensors of the users' electronic devices. 9. Road infrastructure, as per claim 1, characterized by the representation by means of a graph of both the topological characteristics of the road network and of the digital network associated with it; both graphs adapt dynamically to the introduction of new devices in the digital network, to new paths in the road network or to accidental events.