Analysis of the architecture of an automated traffic control system from the US DoT ITS standard
The US standard of intelligent transport systems US Dot ITS describes the full range of automated transport management systems. The standard is so large that it’s unrealistic to cram its description into one or even two posts. Since most of the systems described in it are for us an unattainable bright future, then this should not be done. But what should be done is to consider how it is arranged from the inside, what finds were made by unknown American (oh?) IT specialists, who did a very significant amount of work at the expense of taxpayers.
To make it easier, I propose to consider in more detail one of the systems of the standard, namely, ASTM (automated traffic control system). Moreover, it is now an extremely fashionable topic in our country, where the illusions that computers will be able to replace normal asphalt, and maybe even allow them to do without roads, are still strong.
The following picture shows the main elements of the architecture and the connections between them. Green colored entities that we consider today.
')
It is more convenient for our IT person to always dance on functional requirements. As I wrote earlier, the Americans formulated all possible requirements for ITS elements, supplied them with attributes and tabulated them.
I counted more than 1,400 unique requirements. Of these, about 120 belong to ASUDD, of which only 60-70 can be presented to hypothetical Russian systems. The remaining requirements relate to the most exotic (for example, automatic lanes on highways or the transfer of road signs to the inside of a car) or are related to American specifics, which we cannot realize (integration of railway timetables and plans for coordinating traffic lights on city streets so that traffic does not create traffic jams) .
For example, here are the requirements for the traffic light control subsystem:
Everything seems quite logical, and even there is a standard "cant" in the form of "etc", which is a favorite delicacy of corporate trolls who want to shove an elephant with a hippopotamus into it etc just to ruin the project or squeeze some more money from the contractor. Anyway, the requirements were made by living people, and these requirements are similar to “combat”, taken from real technical targets.
In the original, Americans use the term “Equipment Packages”, some groupings of equipment items that are subject to functional requirements. I propose to use the concept of “Subsystem”, which is closer and more familiar to us, as well as as close as possible.
Subsystems physically implement the functional requirements using hardware, software and communication channels. In the architecture, there is a registry of all the listed elements and a table of relations between all subsystems and hardware / software / networks elements. In order not to overload the picture, I did not draw this connection.
The following are the main subsystems with comments that I would recommend for implementation in our country. Some "exotic" listed below for general development.
And now a little exotic.
TMC Automated Vehicle Operations. Performs remote control of automated highways (along which automated transport moves, “autopilot”).
And here there were difficulties in translation. There is no adequate term in Russian.
TMC In-Vehicle Signing Management (Management of informing the driver through the on-board system displaying traffic signs about driving conditions). It monitors and controls the equipment transmitting the signal for switching the sign in the on-board warning system of the driver crossing the zone of the sign.
TMC Demand Management Coordination (Parking Demand Management). Controls the demand for parking and other paid infrastructure to regulate the price of these services.
TMC Evacuation Support. Supports the development, coordination, and execution of traffic management scenarios and strategies during evacuation during natural disasters. The strategy is developed on the basis of modeling the possible transport demand. The subsystem works in close conjunction with the center for emergency situations (a separate subsystem that is not part of the ASTM)
The list could be continued, but, I am afraid, what has already been listed is more than enough to make even the most persistent readers doze off. Perhaps a small consolation is that I have listed only 21 subsystems, and in total 219 different subsystems are included in the ITS standard! Only the high-level description of information flows between these subsystems takes 3 thick volumes in small print, it is unknown why released by the Americans. After all, to understand this system, looking at the web of links on paper, is impossible in principle. All links are in the Access database attached to the standard, which was used in the preparation of this article.
In fact, in the original they are called Market Packages, and I broke my head trying to find the right translation. As a result, I decided to dwell on the word “process”, since these entities group the dynamic component of ITS, namely, what it does to achieve its goals.
I will not bore you with the enumeration of ASUDD processes, as this will not add additional value to the presented material, but will only catch up with the unnecessary paper sheet. Let me give you an example of a couple of processes, so that you can imagine what the others look like.
Highway management. Providing traffic control on highways. It includes various management strategies, such as restricting access to highways, controlling the speed of flow, managing lanes, entrances and exits, etc. It includes all the necessary equipment and software.
Manage dedicated lanes for ATAP. Providing management of lanes for traffic Includes equipment of traffic lights and vehicles to ensure priority travel for vehicles lagging behind the schedule. Airborne systems include GPS equipment, a door-opening sensor, and a trip computer.
Process specifications are directly related to processes - documents that formally describe each process with detail sufficient to further develop software productions or formulate requirements for suppliers.
Process specifications, in turn, are associated with terminators. Terminators are either end users or other (external) systems with which the process interacts. For simplicity, I translated this term as “users of ASUDD”, meaning by this the business roles that are performed by people responsible for any parameters or parts of the system.
So, the AUDTS architecture completely describes:
In the bottom line, we have a complete set of data for implementing the system in whole or in part, as well as a strategic basis for integration with existing or future systems, for example, with logistics transport centers.
In my opinion, very beautiful.
To make it easier, I propose to consider in more detail one of the systems of the standard, namely, ASTM (automated traffic control system). Moreover, it is now an extremely fashionable topic in our country, where the illusions that computers will be able to replace normal asphalt, and maybe even allow them to do without roads, are still strong.
Basic architecture concepts
Requirements
The following picture shows the main elements of the architecture and the connections between them. Green colored entities that we consider today.
')
It is more convenient for our IT person to always dance on functional requirements. As I wrote earlier, the Americans formulated all possible requirements for ITS elements, supplied them with attributes and tabulated them.
I counted more than 1,400 unique requirements. Of these, about 120 belong to ASUDD, of which only 60-70 can be presented to hypothetical Russian systems. The remaining requirements relate to the most exotic (for example, automatic lanes on highways or the transfer of road signs to the inside of a car) or are related to American specifics, which we cannot realize (integration of railway timetables and plans for coordinating traffic lights on city streets so that traffic does not create traffic jams) .
For example, here are the requirements for the traffic light control subsystem:
- The system should provide remote control of road controllers.
- The system must accept requests for passage from pedestrians
- The system should provide centralized collection and verification of information on the operational status of road controllers.
- The system should ensure the collection of information about the failure of road controllers.
- The system should allow the use of traffic light coordination plans at equipped intersections under the control of MCC personnel, based on data from the detectors, information on traffic flows, incidents, requests for priority passage of special vehicles, data on cargo vehicles with excessive load, information on equipment failures, requests for transition from pedestrians, etc.
Everything seems quite logical, and even there is a standard "cant" in the form of "etc", which is a favorite delicacy of corporate trolls who want to shove an elephant with a hippopotamus into it etc just to ruin the project or squeeze some more money from the contractor. Anyway, the requirements were made by living people, and these requirements are similar to “combat”, taken from real technical targets.
Subsystems
In the original, Americans use the term “Equipment Packages”, some groupings of equipment items that are subject to functional requirements. I propose to use the concept of “Subsystem”, which is closer and more familiar to us, as well as as close as possible.
Subsystems physically implement the functional requirements using hardware, software and communication channels. In the architecture, there is a registry of all the listed elements and a table of relations between all subsystems and hardware / software / networks elements. In order not to overload the picture, I did not draw this connection.
The following are the main subsystems with comments that I would recommend for implementation in our country. Some "exotic" listed below for general development.
- Barrier control subsystem. Remotely manages barriers and other blocking devices.
- Subsystem for collecting traffic information. Remotely collects information from surveillance cameras, traffic flow detectors, and processes and stores this information, as well as traffic information received from external sources. It also provides the provision of collected information to external systems and other ASUDD.
- Environmental monitoring subsystem. Controls weather conditions using information from ADMS, meteorological centers and neighboring ASUDD. Provides information to other subsystems to inform road users and make decisions.
- Highway management subsystem. Provides centralized monitoring and traffic management on motorways, including regulation of access to the highway, intermediate speed control, management of interchanges, lanes, etc.
- The management subsystem of dedicated bands for ATOP. (I chose the term “public transport vehicles” here, although Americans use HOV - High Occupancy Vehicle. This term can also include passenger cars carrying several people) . Carries out traffic management along the selected lanes, prioritizes the ATAP traffic at intersections, fixes violations in the use of the dedicated lanes.
- Incident Detection Subsystem Carries out the identification of incidents and notifies the personnel of the MCC (traffic control center). Remotely monitors traffic detectors, a traffic data acquisition system that provides incident detection. It also provides for the receipt and processing of information on incidents at cargo transfer points, border crossing points, etc.
- Integration subsystem with adjacent ASUDD. Carries out the integration and coordination of road traffic management activities between regional and local ATSUDD, for example, the coordination of traffic lights in the city and the traffic lights on the regional highway.
- Subsystem of management of reversing lanes. Performs remote monitoring and control of reversing lanes by controlling reversing traffic lights, barriers and other means of restricting entry to the lane.
- Traffic control subsystem. Provides the ability to monitor and control traffic flows at intersections equipped with traffic lights. This capability includes the analysis and processing of detector data, the development and application of coordination plans at several intersections within the same control domain.
- Speed ​​control subsystem. Provides remote speed monitoring and overspeed warning system management. It measures the speed of the vehicle and transmits this information to the MCC. It also provides notification to the regulatory authorities of the facts of significant speeding.
- Subsystem for disseminating information about traffic. Provides dissemination of information about traffic, road conditions, ceilings and recommended detour routes. Provides information about incidents, announcements and other transport information to other subsystems, centers, media, etc. It provides information display on the TPI (variable information display), information transfer via radio channel, etc.
- Decision support subsystem. Recommends to the operator a sequence of actions based on current and projected road conditions and traffic conditions. Monitors traffic incidents, special events, maintenance and other events that affect transport demand. Historical data are used to assess the effects of the operator’s actions and make recommendations. Recommended actions may include redefining incident response plans, recalculating coordination plans, applying various management strategies, restricting entry to highways, redirecting transit traffic, and recommending detours for motorists. After the operator agrees on the recommendations, the system applies the script and the MCC equipment performs the necessary actions.
- Subsystem performance evaluation of the road network. Measures the performance parameters of the transport network and predicts changes in transport demand to ensure optimization of traffic flow, management of transport demand, and traffic incidents. It collects both information from transport detectors, as well as information from other ASUDD and related systems, environmental monitoring centers, logistics centers, organizers of mass events, and uses this information to measure the performance parameters of traffic flows. The subsystem also collects information on planned routes in order to predict the development of the transport situation. Planning strategies can be transferred to the user information subsystem, and can also be used for future route planning.
- Subsystem for collecting information about the state of the road network. Provides a collection of real-time information about the state of the transport network across the region. This includes communication and the determination of the possibility of processing data LASUDD in real time. Using queries to local DBMS, the subsystem collects LACUDD information, and then distributes this information between other MCC systems and external systems.
- Subsystem management repair work. Coordinates road network maintenance plans to minimize the impact of repair and maintenance works on the transportation situation. Informs road users about the ongoing repair work through the withdrawal of ads on TPI.
- Subsystem for collecting and storing traffic information. Provides storage of traffic information for future use by staff and for archiving at the federal level.
- The equipment operation support subsystem provides monitoring of equipment operability and failure detection. Informs operation personnel and transmits information to the repair management subsystem. The performance of the entire spectrum of installed equipment is monitored.
And now a little exotic.
TMC Automated Vehicle Operations. Performs remote control of automated highways (along which automated transport moves, “autopilot”).
And here there were difficulties in translation. There is no adequate term in Russian.
TMC In-Vehicle Signing Management (Management of informing the driver through the on-board system displaying traffic signs about driving conditions). It monitors and controls the equipment transmitting the signal for switching the sign in the on-board warning system of the driver crossing the zone of the sign.
TMC Demand Management Coordination (Parking Demand Management). Controls the demand for parking and other paid infrastructure to regulate the price of these services.
TMC Evacuation Support. Supports the development, coordination, and execution of traffic management scenarios and strategies during evacuation during natural disasters. The strategy is developed on the basis of modeling the possible transport demand. The subsystem works in close conjunction with the center for emergency situations (a separate subsystem that is not part of the ASTM)
The list could be continued, but, I am afraid, what has already been listed is more than enough to make even the most persistent readers doze off. Perhaps a small consolation is that I have listed only 21 subsystems, and in total 219 different subsystems are included in the ITS standard! Only the high-level description of information flows between these subsystems takes 3 thick volumes in small print, it is unknown why released by the Americans. After all, to understand this system, looking at the web of links on paper, is impossible in principle. All links are in the Access database attached to the standard, which was used in the preparation of this article.
Processes
In fact, in the original they are called Market Packages, and I broke my head trying to find the right translation. As a result, I decided to dwell on the word “process”, since these entities group the dynamic component of ITS, namely, what it does to achieve its goals.
I will not bore you with the enumeration of ASUDD processes, as this will not add additional value to the presented material, but will only catch up with the unnecessary paper sheet. Let me give you an example of a couple of processes, so that you can imagine what the others look like.
Highway management. Providing traffic control on highways. It includes various management strategies, such as restricting access to highways, controlling the speed of flow, managing lanes, entrances and exits, etc. It includes all the necessary equipment and software.
Manage dedicated lanes for ATAP. Providing management of lanes for traffic Includes equipment of traffic lights and vehicles to ensure priority travel for vehicles lagging behind the schedule. Airborne systems include GPS equipment, a door-opening sensor, and a trip computer.
Process specifications are directly related to processes - documents that formally describe each process with detail sufficient to further develop software productions or formulate requirements for suppliers.
Process specifications, in turn, are associated with terminators. Terminators are either end users or other (external) systems with which the process interacts. For simplicity, I translated this term as “users of ASUDD”, meaning by this the business roles that are performed by people responsible for any parameters or parts of the system.
Summary
So, the AUDTS architecture completely describes:
- Functional system requirements
- Used equipment
- Subsystems
- Processes
- Process roles
- Internal and external information flows
In the bottom line, we have a complete set of data for implementing the system in whole or in part, as well as a strategic basis for integration with existing or future systems, for example, with logistics transport centers.
In my opinion, very beautiful.
Source: https://habr.com/ru/post/121232/
All Articles